3 次握手：
- 客户端发送 SYN（SEQ=x）报文给服务器端，进入 SYN_SEND 状态。
- 服务器端收到 SYN 报文，回应一个 SYN （SEQ=y）ACK(ACK=x+1）报文，进入 SYN_RECV 状态。
- 客户端收到服务器端的 SYN 报文，回应一个 ACK(ACK=y+1）报文，进入 Established 状态。
打电话例子： A:“喂，你听得到吗？” A->SYN_SEND B:“我听得到呀，你听得到我吗？” 应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED A:“我能听到你，今天 balabala……” B->ESTABLISHED
4 次挥手：
- 某个应用进程首先调用 close，称该端执行“主动关闭”（active close）。该端的 TCP 于是发送一个 FIN 分节，表示数据发送完毕。
- 接收到这个 FIN 的对端执行 “被动关闭”（passive close），这个 FIN 由 TCP 确认。
- 一段时间后，接收到这个文件结束符的应用进程将调用 close 关闭它的套接字。这导致它的 TCP 也发送一个 FIN。
- 接收这个最终FIN的原发送端 TCP（即执行主动关闭的那一端）确认这个 FIN。 既然每个方向都需要一个 FIN 和一个 ACK，因此通常需要 4 个分节。
打电话例子： A:“喂，我不说了。” A->FIN_WAIT1 B:“我知道了。等下，上一句还没说完。Balabala…..” B->CLOSE_WAIT | A->FIN_WAIT2 B:”好了，说完了，我也不说了。” B->LAST_ACK A:”我知道了。” A->TIME_WAIT | B->CLOSED
- 为什么建立连接需要 3 次握手
如果采用两次的话，会出现下面这种情况：
- TCP 的三次握手最主要是防止已过期的连接再次传到被连接的主机。
比如是客户端要连到服务器，结果发送的连接信息由于某种原因没有到达服务器；于是，客户端又发了一次，结果这次服务器收到了，于是就发信息回来，两机就连接。传完东西后，断开。
结果这时候，原先没有到达的连接信息突然又传到了服务器，于是服务器发确认信息给客户端，然后服务器就以为和客户端连上了，这个时候服务器就在等待客户端传东西过去。
- 三次握手改成仅需要两次握手，死锁是可能发生
考虑客户机和服务器之间的通信，假定客户机向服务器发送连接请求，服务器收到这个分组后，回复确认分组。按照两次握手的协定，服务器认为连接已经成功建立了，可以开始发送数据分组。
可是，可能出现一种情况就是，服务器的确认分组在传输过程中被丢失，而此时客户端没有收到确认分组；客户端此时不知道服务器是否已经准备好，不知道服务器建议什么样的序列号，客户端甚至怀疑服务器是否收到了自己的连接请求分组。
在这种情况下，客户端认为连接还未建立成功，将忽略服务器发来的任何数据分组，只等待连接确认应答分组。而服务器发出的分组超时后，重复发同样的分组，这样就形成了死锁。
- 4 次挥手 TIME-WAIT 作用
为什么需要 TIME_WAIT ？有如下几个原因：
- 因为在第四步的时候，客户机发送的ACK可能丢失并导致服务端重新发送 FIN 消息，TIME_WAIT 维护连接状态.
如果执行主动关闭的一方客户机不进入到 TIME_WAIT 状态就关闭连接那会发生什么呢？当重传的FIN消息到达时，因为 TCP 已经不再有连接的信息了，所以就用 RST(重新启动)消息应答，导致服务端进入错误的状态而不是有序终止状态，如果发送最后 ACK 消息的一方处于 TIME_WAIT 状态并仍然记录着连接的信息，它就可以正确的响应对等方服务端的FIN消息了.
- TIME_WAIT 为连接中”离群的段”提供从网络中消失的时间.
考虑一下，如果延迟或者重传段在连接关闭后到达时会发生什么呢？通常情况下，因为TCP仅仅丢弃该数据并响应RST消息，所以这不会造成任何问题。当 RST 消息到达发出延时段的主机时，因为该主机也没有记录连接的任何信息，所以它也丢弃该段。然而，如果两个相同主机之间又建立了一个具有相同端口号的新连接，那么离群的段就可能被看成是新连接的，如果离群的段中数据的任何序列号恰恰在新连接的当前接收窗口中，数据就会被重新接收，其结果就是破坏新连接。
- TCP 面向连接（如打电话要先拨号建立连接）；UDP 是无连接的，即发送数据之前不需要建立连接。
- TCP 提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。
- TCP 通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
- UDP 具有较好的实时性，工作效率比 TCP 高，适用于对高速传输和实时性有较高的通信或广播通信。
- 每一条 TCP 连接只能是点到点的；UDP 支持一对一，一对多，多对一和多对多的交互通信。
- TCP 对系统资源要求较多，UDP 对系统资源要求较少。
HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从 WWW 服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
HTTPS：是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。
HTTPS 协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
HTTPS = HTTP + SSL
HTTP 1.0，HTTP 1.1：
- 长连接 HTTP 1.0 需要使用 keep-alive 参数来告知服务器端要建立一个长连接，而 HTTP1.1 默认支持长连接。
HTTP 是基于 TCP/IP 协议的，创建一个 TCP 连接是需要经过三次握手的，有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用个长连接来发多个请求。
- 节约带宽 HTTP 1.1 支持只发送 header 信息(不带任何 body 信息)，如果服务器认为客户端有权限请求服务器，则返回 100，否则返回 401。客户端如果接受到 100，才开始把请求 body 发送到服务器。
这样当服务器返回 401 的时候，客户端就可以不用发送请求 body 了，节约了带宽。
另外 HTTP 还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。
- HOST 域 现在可以 web server 例如 tomat，设置虚拟站点是非常常见的，也即是说，web server 上的多个虚拟站点可以共享同一个 IP 和端口。
HTTP 1.0 是没有 host 域的，HTTP 1.1 才支持这个参数。
HTTP 1.1，HTTP 2.0：
- 多路复用 HTTP 2.0 使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比 HTTP 1.1 大了好几个数量级。
当然 HTTP 1.1 也可以多建立几个 TCP 连接，来支持处理更多并发的请求，但是创建 TCP 连接本身也是有开销的。
TCP 连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。
关于多路复用，可以参看学习 NIO 。
- 数据压缩 HTTP 1.1 不支持 header 数据的压缩，HTTP2.0 使用 HPACK 算法对 header 的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
- 服务器推送 意思是说，当我们对支持 HTTP2.0 的 web server 请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。
服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。
长轮询，Socket