TCP三次握手和四次挥手

TCP协议定义

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义。

网络模型

网络协议.png

TCP/IP.jpg

TCP数据格式

TCP数据格式.jpeg

TCP分组格式图.jpeg

• 序列号
  SYN未置位：标识用户数据去中xx个字节的序号
  SYN置位： 标识初始发送的序列号
• 确认号
  ACK置位：表示接收到的一个报文段的序号+1，即目的主机希望下次接收到报文段的序号值，序列号=前一个seq+报文段len。
• 控制位
  URG：URG=1 --> 紧急指针字段有效
  ACK： ACK=1 --> 确认号字段有效,TCP规定在连接建立后所有传达的报文段ACK都须置为1
  PSH：PUSH- 推送，数据交互
  RST： 复位TCP连接
  SYN：三次握手建立TCP连接有效。SYN=1，ACK=0 表示这是一个连接请求报文段，若对方同意建立连接，则相应报文段使用SYN=1，ACK=1
  FIN： 用来释放一个TCP连接 。FIN=1，表明此报文端发送方数据已经发送完毕，要求释放连接。

三次握手

用途

建立TCP连接

握手作用

确认双方的接收和发送能是是否正常，初始序列号，交换窗口大小以及MSS等信息

示意图

三次握手.png

1. 客户端发送SYN报文，请求建立连接，进入SYN_SENT状态，等到服务器确认
2. 服务端收到SYN报文，发送ACK确认报文给客户端，同时发送SYN报文，即SYN+ACK，服务器进入SYN_RCVD状态
3. 客户端收到SYN+ACK报文，发送ACK包给服务端，客户端进入ESTABLISHED状态。服务器收到客户端发送的ACK包之后也进入ESTABLISHED状态，三次握手完成

三次握手示例.png

1. 第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。
2. 起始包的seq都等于0
3. 三次握手中的ack=对方上一个的seq+1
4. seq等于对方上次的ack号

为啥要三次握手

1. 确认双方接收数据和发送数据的能力。
2. 序列号可靠同步。
如果是两次握手，服务端无法确定客户端是否已经接收到了自己发送的初始序列号，如果第二次握手报文丢失，那么客户端就无法知道服务端的初始序列号（ISN，动态随机），那 TCP 的可靠性就无从谈起。
3. 阻止重复历史连接的初始化。

• 客户端由于某种原因发送了两个不同序号的 SYN 包，我们知道网络环境是复杂的，旧的数据包有可能先到达服务器。如果是两次握手，服务器收到旧的SYN 就会立刻建立连接，那么会造成网络异常。
• 如果是三次握手，服务器需要回复 SYN+ACK 包，客户端会对比应答的序号，如果发现是旧的报文，就会给服务器发 RST 报文，直到正常的 SYN到达服务器后才正常建立连接。
• 客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待。

4. 安全问题。
TCP 新建连接时，内核会为连接分配一系列的内存资源，如果采用两次握手，就建立连接，那会放大 DDOS 攻击的。

四次挥手

四次挥手.png

1. 发起包，客户端进入状态。TCP规定，即使FIN不携带数据包也消耗一个序号。
2. 收到FIN包，发出确认包，并带上自己的序号seq=v，服务端进入状态。此时，客户端不再发送数据，但还可以接收服务端发送的数据（如果服务端有数据发送）。接收到服务端发送的ACK后，进入。
   3.发送完数据后，向客户端发送包, 半连接状态下服务器可能有发送了一些数据（假设seq为w）。此时服务器进入状态
3. 收到服务起发送的FIN包后，发出ACK确认包，此时客户端进入。此时TCP连接还没释放，必须经过后，进入状态。而服务端收到客户端发送的确认包后就进入了CLOSED状态，服务端结束TCP连接的事件要比客户端早一些。

四次挥手.png

1. TCP除了主动发起连接的第一个SYN包，ACK=0，其它所有TCP包都设置ACK= 1 标志位。
2. 接到对方数据，如果没有数据要发送，需要用一个ACK确认对方，如果ACK丢，不会为ACK重传。
3. 如果有数据要发送，顺便捎带ACK，确认对方的数据，如果数据丢，会重传数据。

三次挥手.png

在实际应用中由于延迟确认（也就是确认报文由下一个发送报文携带，一起传送过来），第二次挥手ACK与第三次挥手FIN合并成了一次。

为啥要四次握手

1. 主动关闭方发送 FIN 包后，接收端可能还要发送数据，不能立即关闭服务器端到客户端的数据通道，所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送，只能先确认ACK，然后服务器待无需发送数据时再发送 FIN 包，所以四次挥手时必须是四次数据包的交互。
2. 服务端端收到FIN请求后要先应答ACK。
3. 等发完未发的数据，然后再发FIN。

常见问题

1. 什么是半连接

• 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立连接。服务器会把这种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
• 一直没收到第三次握手，服务端发重传包，达到规定次数，从半连接队列里删除。（发重传包间隔时间一般指数增长）
• 全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

3. 为啥要等2MSL

MSL：maximum segment lifetime——最大报文生命周期,报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

1. 网络中可能存在发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
2. 2MSL的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。
3. 保证Client发送的最后一个ACK报文段能够顺利地到达Server
4. 保证本次连接所有报文从网络中消失。（不影响下一次连接）

4. 为什么需要 TIME_WAIT 状态？

1. 防止具有相同四元组的旧数据包被收到；

有相同端口的 TCP 连接被复用后，被延迟的相同四元组的数据包抵达了客户端，那么客户端是有可能正常接收这个过期的报文，这就会产生数据错乱等严重的问题。
经过2MSL这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

2. 保证被动关闭连接的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；

最后的ACK如果丢失，客户端直接进入close，服务端一直在等待ACK状态。当客户端发起建立连接的SYN请求，服务端会发送RST报文回应，连接建立会关闭。

如果 TIME-WAIT 等待足够长的情况就会遇到两种情况：
服务端正常收到四次挥手的最后一个 ACK报文，则服务端正常关闭连接。
服务端没有收到四次挥手的最后一个 ACK报文时，则会重发 FIN关闭连接报文并等待新的 ACK报文。

5. TIME_WAIT 过多有什么危害?

1. 内存资源占用；
2. 对端口资源的占用，一个 TCP 连接至少消耗一个本地端口；如果发起连接一方的 TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。

参考

网络7层协议，4层，5层？理清容易混淆的几个概念
网络五层协议
TCP数据段格式+UDP数据段格式详解
TCP三次握手问的这么详细
TCP四次挥手详
小谈TCP协议中的Ack和Seq号