专栏名称: 程序猿

本微信公众号：imkuqin，为程序员提供最新最全的编程学习资料的查询。目前已经开通PHP、C/C++函数库、.NET Framework类库、J2SE API查询功能。

TCP 才不傻！

程序猿 · 公众号 · 程序员 · 2025-02-18 12:18

正文

来自公众号：小林coding

之前收到个读者的问题，对于 TCP 三次握手和四次挥手的一些疑问：

第一次握手，如果客户端发送的SYN一直都传不到被服务器，那么客户端是一直重发SYN到永久吗？客户端停止重发SYN的时机是什么？
第三次握手，如果服务器永远不会收到ACK，服务器就永远都留在 Syn-Recv 状态了吗？退出此状态的时机是什么？
第三次挥手，如果客户端永远收不到 FIN,ACK，客户端永远停留在 Fin-Wait-2状态了吗？退出此状态时机是什么时候呢？
第四次挥手，如果服务器永远收不到 ACK，服务器永远停留在 Last-Ack 状态了吗？退出此状态的时机是什么呢？
如果客户端在 2SML内依旧没收到 FIN,ACK，会关闭链接吗？服务器那边怎么办呢，是怎么关闭链接的呢？

可以看到，这些问题都是关于 TCP 是如何处理这些异常场景 的，我们在学 TCP 连接建立和断开的时候，总是以为这些过程能如期完成。

可惜理想很丰满，现实很骨感，事实预料呀 。

TCP 当然不傻 ，对以上这些异常场景都是有做处理的。

这些内容在我的「图解网络 PDF」也有说过。

当时也用做实验的方式带大家看 TCP 是如何处理这些异常场景的。

不过，当时这些知识分散到了多个章节，这次就针对读者问的这一系列问题，来详细说说 TCP 是怎么处理这些异常的？

这些异常场景共分为两大类，第一类是 TCP 三次握手期间的异常，第二类是 TCP 四次挥手期间的异常。

TCP 三次握手期间的异常

我们先来看看 TCP 三次握手是怎样的。

第一次握手丢失了，会发生什么？

当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到


     
      SYN_SENT

状态。

在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发超时重传机制。

不同版本的操作系统可能超时时间不同，有的 1 秒的，也有 3 秒的，这个超时时间是写死在内核里的，如果想要更改则需要重新编译内核，比较麻烦。

当客户端在 1 秒后没收到服务端的 SYN-ACK 报文后，客户端就会重发 SYN 报文，那到底重发几次呢？

在 Linux 里，客户端的 SYN 报文最大重传次数由


     
      tcp_syn_retries

内核参数控制，这个参数是可以自定义的，默认值一般是 5。

通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错， 每次超时的时间是上一次的 2 倍 。

当第五次超时重传后，会继续等待 32 秒，如果服务端仍然没有回应 ACK，客户端就不再发送 SYN 包，然后断开 TCP 连接。

所以，总耗时是 1+2+4+8+16+32=63 秒，大约 1 分钟左右。

第二次握手丢失了，会发生什么？

当服务端收到客户端的第一次握手后，就会回 SYN-ACK 报文给客户端，这个就是第二次握手，此时服务端会进入


     
      SYN_RCVD

状态。

第二次握手的


     
      SYN-ACK

报文其实有两个目的：

第二次握手里的 ACK，是对第一次握手的确认报文；
第二次握手里的 SYN，是服务端发起建立 TCP 连接的报文；

所以，如果第二次握手丢了，就会发送比较有意思的事情，具体会怎么样呢？

因为第二次握手报文里是包含对客户端的第一次握手的 ACK 确认报文，所以，如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的 SYN 报文（第一次握手）丢失了，于是 客户端就会触发超时重传机制，重传 SYN 报文 。

然后，因为第二次握手中包含服务端的 SYN 报文，所以当客户端收到后，需要给服务端发送 ACK 确认报文（第三次握手），服务端才会认为该 SYN 报文被客户端收到了。

那么，如果第二次握手丢失了，服务端就收不到第三次握手，于是 服务端这边会触发超时重传机制，重传 SYN-ACK 报文 。

在 Linux 下，SYN-ACK 报文的最大重传次数由


     
      tcp_synack_retries

内核参数决定，默认值是 5。

因此，当第二次握手丢失了，客户端和服务端都会重传：

客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries 内核参数决定。；
服务端会重传 SYN-AKC 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定。

第三次握手丢失了，会发生什么？

客户端收到服务端的 SYN-ACK 报文后，就会给服务端回一个 ACK 报文，也就是第三次握手，此时客户端状态进入到


     
      ESTABLISH

状态。

因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传 SYN-ACK 报文，直到收到第三次握手，或者达到最大重传次数。

注意， ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文 。

TCP 四次挥手期间的异常

我们再来看看 TCP 四次挥手的过程。

第一次挥手丢失了，会发生什么？

当客户端（主动关闭方）调用 close 函数后，就会向服务端发送 FIN 报文，试图与服务端断开连接，此时客户端的连接进入到


     
      FIN_WAIT_1

状态。

正常情况下，如果能及时收到服务端（被动关闭方）的 ACK，则会很快变为


     
      FIN_WAIT2

状态。

如果第一次挥手丢失了，那么客户端迟迟收不到被动方的 ACK 的话，也就会触发超时重传机制，重传 FIN 报文，重发次数由


     
      tcp_orphan_retries

参数控制。

当客户端重传 FIN 报文的次数超过


     
      tcp_orphan_retries

后，就不再发送 FIN 报文，直接进入到


     
      close

状态。

第二次挥手丢失了，会发生什么？

当服务端收到客户端的第一次挥手后，就会先回一个 ACK 确认报文，此时服务端的连接进入到


     
      CLOSE_WAIT

状态。