彻底搞懂TCP协议：从 TCP 三次握手四次挥手说起（一）

李玮

疑症（1）TCP 的三次握手、四次挥手

下面两图大家再熟悉不过了，TCP 的三次握手和四次挥手见下面左边的”TCP 建立连接”、”TCP 数据传送”、”TCP 断开连接”时序图和右边的”TCP 协议状态机” 。

要弄清 TCP 建立连接需要几次交互才行，我们需要弄清建立连接进行初始化的目标是什么。TCP 进行握手初始化一个连接的目标是：分配资源、初始化序列号(通知 peer 对端我的初始序列号是多少)，知道初始化连接的目标，那么要达成这个目标的过程就简单了，握手过程可以简化为下面的四次交互：

1）client 端首先发送一个 SYN 包告诉 Server 端我的初始序列号是 X； 2）Server 端收到 SYN 包后回复给 client 一个 ACK 确认包，告诉 client 说我收到了； 3）接着 Server 端也需要告诉 client 端自己的初始序列号，于是 Server 也发送一个 SYN 包告诉 client 我的初始序列号是 Y； 4）Client 收到后，回复 Server 一个 ACK 确认包说我知道了。

整个过程 4 次交互即可完成初始化，但是，细心的同学会发现两个问题：

• Server 发送 SYN 包是作为发起连接的 SYN 包，还是作为响应发起者的 SYN 包呢？怎么区分？比较容易引起混淆
• Server 的 ACK 确认包和接下来的 SYN 包可以合成一个 SYN ACK 包一起发送的，没必要分别单独发送，这样省了一次交互同时也解决了问题[1].这样 TCP 建立一个连接，三次握手在进行最少次交互的情况下完成了 Peer 两端的资源分配和初始化序列号的交换。
  

大部分情况下建立连接需要三次握手，也不一定都是三次，有可能出现四次握手来建立连接的。如下图，当 Peer 两端同时发起 SYN 来建立连接的时候，就出现了四次握手来建立连接(对于有些 TCP/IP 的实现，可能不支持这种同时打开的情况)。

在三次握手过程中，细心的同学可能会有以下疑问：

• 初始化序列号 X、Y 是可以是写死固定的吗，为什么不能呢？
• 假如 Client 发送一个 SYN 包给 Server 后就挂了或是不管了，这个时候这个连接处于什么状态呢？会超时吗？为什么呢？
  

TCP 进行断开连接的目标是：回收资源、终止数据传输。由于 TCP 是全双工的，需要 Peer 两端分别各自拆除自己通向 Peer 对端的方向的通信信道。这样需要四次挥手来分别拆除通信信道，就比较清晰明了了。

1）Client 发送一个 FIN 包来告诉 Server 我已经没数据需要发给 Server 了； 2）Server 收到后回复一个 ACK 确认包说我知道了； 3）然后 server 在自己也没数据发送给 client 后，Server 也发送一个 FIN 包给 Client 告诉 Client 我也已经没数据发给 client 了； 4）Client 收到后，就会回复一个 ACK 确认包说我知道了。

到此，四次挥手，这个 TCP 连接就可以完全拆除了。在四次挥手的过程中，细心的同学可能会有以下疑问：

• Client 和 Server 同时发起断开连接的 FIN 包会怎么样呢，TCP 状态是怎么转移的?
• 左侧图中的四次挥手过程中，Server 端的 ACK 确认包能不能和接下来的 FIN 包合并成一个包呢，这样四次挥手就变成三次挥手了。
• 四次挥手过程中，首先断开连接的一端，在回复最后一个 ACK 后，为什么要进行 TIME_WAIT 呢(超时设置是 2*MSL，RFC793 定义了 MSL 为 2 分钟，Linux 设置成了 30s)，在 TIME_WAIT 的时候又不能释放资源，白白让资源占用那么长时间，能不能省了 TIME_WAIT 呢，为什么？
  

疑症（2）TCP 连接的初始化序列号能否固定

如果初始化序列号（缩写为 ISN：Inital Sequence Number）可以固定，我们来看看会出现什么问题。假设 ISN 固定是 1，Client 和 Server 建立好一条 TCP 连接后，Client 连续给 Server 发了 10 个包，这 10 个包不知怎么被链路上的路由器缓存了(路由器会毫无先兆地缓存或者丢弃任何的数据包)，这个时候碰巧 Client 挂掉了，然后 Client 用同样的端口号重新连上 Server，Client 又连续给 Server 发了几个包，假设这个时候 Client 的序列号变成了 5。

接着，之前被路由器缓存的 10 个数据包全部被路由到 Server 端了，Server 给 Client 回复确认号 10，这个时候，Client 整个都不好了，这是什么情况？我的序列号才到 5，你怎么给我的确认号是 10 了，整个都乱了。RFC793 中，建议 ISN 和一个假的时钟绑在一起，这个时钟会在每 4 微秒对 ISN 做加一操作，直到超过 2^32，又从 0 开始，这需要 4 小时才会产生 ISN 的回绕问题，这几乎可以保证每个新连接的 ISN 不会和旧的连接的 ISN 产生冲突。这种递增方式的 ISN，很容易让攻击者猜测到 TCP 连接的 ISN，现在的实现大多是在一个基准值的基础上进行随机的。

疑症（3）初始化连接的 SYN 超时问题

Client 发送 SYN 包给 Server 后挂了，Server 回给 Client 的 SYN-ACK 一直没收到 Client 的 ACK 确认，这个时候这个连接既没建立起来，也不能算失败。这就需要一个超时时间让 Server 将这个连接断开，否则这个连接就会一直占用 Server 的 SYN 连接队列中的一个位置，大量这样的连接就会将 Server 的 SYN 连接队列耗尽，让正常的连接无法得到处理。目前，Linux 下默认会进行 5 次重发 SYN-ACK 包，重试的间隔时间从 1s 开始，下次的重试间隔时间是前一次的双倍，5 次的重试时间间隔为 1s,2s, 4s, 8s,16s，总共 31s，第 5 次发出后还要等 32s 都知道第 5 次也超时了，所以，总共需要 1s + 2s +4s+ 8s+ 16s + 32s =63s，TCP 才会把断开这个连接。

由于，SYN 超时需要 63 秒，那么就给攻击者一个攻击服务器的机会，攻击者在短时间内发送大量的 SYN 包给 Server(俗称 SYN flood 攻击)，用于耗尽 Server 的 SYN 队列。对于应对 SYN 过多的问题，linux 提供了几个 TCP 参数：tcp_syncookies、tcp_synack_retries、tcp_max_syn_backlog、tcp_abort_on_overflow 来调整应对。

疑症（4） TCP 的 Peer 两端同时断开连接

由上面的”TCP 协议状态机“图可以看出，TCP 的 Peer 端在收到对端的 FIN 包前发出了 FIN 包，那么该 Peer 的状态就变成了 FIN_WAIT1，Peer 在 FIN_WAIT1 状态下收到对端 Peer 对自己 FIN 包的 ACK 包的话，那么 Peer 状态就变成 FIN_WAIT2，Peer 在 FIN_WAIT2 下收到对端 Peer 的 FIN 包，在确认已经收到了对端 Peer 全部的 Data 数据包后，就响应一个 ACK 给对端 Peer，然后自己进入 TIME_WAIT 状态。

但是如果 Peer 在 FIN_WAIT1 状态下首先收到对端 Peer 的 FIN 包的话，那么该 Peer 在确认已经收到了对端 Peer 全部的 Data 数据包后，就响应一个 ACK 给对端 Peer，然后自己进入 CLOSEING 状态，Peer 在 CLOSEING 状态下收到自己的 FIN 包的 ACK 包的话，那么就进入 TIME WAIT 状态。于是，TCP 的 Peer 两端同时发起 FIN 包进行断开连接，那么两端 Peer 可能出现完全一样的状态转移 FIN_WAIT1——>CLOSEING——->TIME_WAIT，也就会 Client 和 Server 最后同时进入 TIME_WAIT 状态。同时关闭连接的状态转移如下图所示：

疑症（5）四次挥手能不能变成三次挥手呢？？

答案是可能的。TCP 是全双工通信，Cliet 在自己已经不会在有新的数据要发送给 Server 后，可以发送 FIN 信号告知 Server，这边已经终止 Client 到对端 Server 那边的数据传输。但是，这个时候对端 Server 可以继续往 Client 这边发送数据包。于是，两端数据传输的终止在时序上是独立并且可能会相隔比较长的时间，这个时候就必须最少需要 2+2= 4 次挥手来完全终止这个连接。但是，如果 Server 在收到 Client 的 FIN 包后，在也没数据需要发送给 Client 了，那么对 Client 的 ACK 包和 Server 自己的 FIN 包就可以合并成为一个包发送过去，这样四次挥手就可以变成三次了(似乎 linux 协议栈就是这样实现的)