解析：灵魂拷问 TCP ，你要投降了吗2022/12/27 10:38:22

哦不明白

当客户端想和服务端建立TCP连接的时候，首先首个发的就是SYN报文，然后进入到SYN_SENT状态。在这之后，如果客户端迟迟收不到服务端的SYN-ACK报文（第二次握手），就会触发「超时重传」机制，重传SYN报文，而且重传的SYN报文的序列号都是一样的。icp备案查询的相关资讯可以到我们网站了解一下，从专业角度出发为您解答相关问题，给您优质的服务！

TCP次握手丢包情况首次握手丢失了，会发生什么当客户端想和服务端建立TCP连接的时候，首先首个发的就是SYN报文，然后进入到SYN_SENT状态。

在这之后，如果客户端迟迟收不到服务端的SYN-ACK报文（第二次握手），就会触发「超时重传」机制，重传SYN报文，而且重传的SYN报文的序列号都是一样的。

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

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

在L里，客户端的SYN报文比较大重传次数由__内核参数控制，这个参数是可以自定义的，默认值一般是5。

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

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

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

举个例子，假设__参数值为3，那么当客户端的SYN报文一直在络中丢失时，会发生下图的过程：



具体过程：

当客户端超时重传3次SYN报文后，由于__为3，已达到比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到服务端的第二次握手（SYN-ACK报文），那么客户端就会断开连接。第二次握手丢失了，会发生什么

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

第二次握手的SYN-ACK报文其有两个目的：

第二次握手里的ACK，是对首次握手的确认报文；第二次握手里的SYN，是服务端发起建立TCP连接的报文；所以，如果第二次握手丢了，就会发生比较有意思的事情，具体会怎么样呢

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

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

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

在L下，SYN-ACK报文的比较大重传次数由__内核参数决定，默认值是5。

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

客户端会重传SYN报文，也就是首次握手，比较大重传次数由__内核参数决定；服务端会重传SYN-ACK报文，也就是第二次握手，比较大重传次数由__内核参数决定。举个例子，假设__参数值为1，__参数值为2，那么当第二次握手一直丢失时，发生的过程如下图：



具体过程：

当客户端超时重传1次SYN报文后，由于__为1，已达到比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到服务端的第二次握手（SYN-ACK报文），那么客户端就会断开连接。当服务端超时重传2次SYN-ACK报文后，由于__为2，已达到比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到客户端的第次握手（ACK报文），那么服务端就会断开连接。第次握手丢失了，会发生什么

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

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

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

举个例子，假设__参数值为2，那么当第次握手一直丢失时，发生的过程如下图：



具体过程：

当服务端超时重传2次SYN-ACK报文后，由于__为2，已达到比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到客户端的第次握手（ACK报文），那么服务端就会断开连接。TCP四次挥手丢包情况首次挥手丢失了，会发生什么当客户端（主动关闭方）调用函数后，就会向服务端发送FIN报文，试图与服务端断开连接，此时客户端的连接进入到FIN_WAIT_1状态。

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

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

当客户端重传FIN报文的次数超过__?后，就不再发送FIN报文，则会在等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到第二次挥手，那么直接进入到状态。

举个例子，假设__参数值为3，当首次挥手一直丢失时，发生的过程如下图：



具体过程：

当客户端超时重传3次FIN报文后，由于__为3，已达到比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到服务端的第二次挥手（ACK报文），那么客户端就会断开连接。

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

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

在前面我们也提了，ACK报文是不会重传的，所以如果服务端的第二次挥手丢失了，客户端就会触发超时重传机制，重传FIN报文，直到收到服务端的第二次挥手，或者达到比较大的重传次数。

举个例子，假设__参数值为2，当第二次挥手一直丢失时，发生的过程如下图：



具体过程：

当客户端超时重传2次FIN报文后，由于__为2，已达到比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到服务端的第二次挥手（ACK报文），那么客户端就会断开连接。这里提一下，当客户端收到第二次挥手，也就是收到服务端发送的ACK报文后，客户端就会处于FIN_WAIT2状态，在这个状态需要等服务端发送第次挥手，也就是服务端的FIN报文。

对于函数关闭的连接，由于法再发送和接收数据，所以FIN_WAIT2?状态不可以持续太久，而__控制了这个状态下连接的持续时长，默认值是60秒。

这意味着对于调用关闭的连接，如果在60秒后还没有收到FIN报文，客户端（主动关闭方）的连接就会直接关闭，如下图：



但是注意，如果主动关闭方使用函数关闭连接，指定了只关闭发送方向，而接收方向并没有关闭，那么意味着主动关闭方还是可以接收数据的。

此时，如果主动关闭方一直没收到第次挥手，那么主动关闭方的连接将会一直处于FIN_WAIT2?状态（__法控制关闭的连接）。如下图：



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

当服务端（被动关闭方）收到客户端（主动关闭方）的FIN报文后，内核会自动回复ACK，同时连接处于CLOSE_WAIT状态，顾思义，它表示等待应用进程调用函数关闭连接。

此时，内核是没有权利替代进程关闭连接，必须由进程主动调用函数来触发服务端发送FIN报文。

服务端处于CLOSE_WAIT状态时，调用了函数，内核就会发出FIN报文，同时连接进入LAST_ACK状态，等待客户端返回ACK来确认连接关闭。

如果迟迟收不到这个ACK，服务端就会重发FIN报文，重发次数仍然由__参数控制，这与客户端重发FIN报文的重传次数控制方式是一样的。

举个例子，假设__=3，当第次挥手一直丢失时，发生的过程如下图：



具体过程：

当服务端重传第次挥手报文的次数达到了3次后，由于__为3，达到了重传比较大次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到客户端的第四次挥手（ACK报文），那么服务端就会断开连接。客户端因为是通过函数关闭连接的，处于FIN_WAIT_2状态是有时长限制的，如果__时间内还是没能收到服务端的第次挥手（FIN报文），那么客户端就会断开连接。第四次挥手丢失了，会发生什么

当客户端收到服务端的第次挥手的FIN报文后，就会回ACK报文，也就是第四次挥手，此时客户端连接进入TIME_WAIT状态。

在L系统，TIME_WAIT状态会持续2MSL后才会进入关闭状态。

然后，服务端（被动关闭方）没有收到ACK报文前，还是处于LAST_ACK状态。

如果第四次挥手的ACK报文没有到达服务端，服务端就会重发FIN报文，重发次数仍然由前面介绍过的__参数控制。

举个例子，假设__为2，当第四次挥手一直丢失时，发生的过程如下：



具体过程：

当服务端重传第次挥手报文达到2时，由于__为2，达到了比较大重传次数，于是再等待一段时间（时间为上一次超时时间的2倍），如果还是没能收到客户端的第四次挥手（ACK报文），那么服务端就会断开连接。客户端在收到第次挥手后，就会进入TIME_WAIT状态，开启时长为2MSL的定时器，如果途中再次收到第次挥手（FIN报文）后，就会重置定时器，当等待2MSL时长后，客户端就会断开连接。