1、四次挥手主动关闭连接的,才有 TIME_WAIT 状态。
2、第一次 挥手丢失了,超时重传 有重传次数和最后重传完之后等待时间的限制
3、第二次挥手丢失了,ACK 报文是不会重传的,所以如果服务端的第二次挥手丢失了,客户端就会触发超时重传机制,重传 FIN 报文,直到收到服务端的第二次挥手,或者达到最大的重传次数。否则客户端就会断开连接
4、第三次挥手丢失了,超时重传 ,还没收到服务器就断开连接 客户端因为是通过 close 函数关闭连接的,处于 FIN_WAIT_2 状态是有时长限制的,如果 tcp_fin_timeout 时间内还是没能收到服务端的第三次挥手(FIN 报文),那么客户端就会断开连接
5、第四次挥手丢失 服务器超时重传 客户端在收到第三次挥手后,就会进入 TIME_WAIT 状态,开启时长为 2MSL 的定时器,如果途中再次收到第三次挥手(FIN 报文)后,就会重置定时器,当等待 2MSL 时长后,客户端就会断开连接
6、为什么是等待2MSL 报文最大生存时间 MSL 与 TTL 的区别: MSL 的单位是时间,而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间,以确保报文已被自然消亡 2MSL时长 这其实是相当于至少允许报文丢失一次。
7、为什么需要time_wait状态 只有主动发起关闭连接的一方需要time_awit状态
防止历史连接中的数据,被后面相同四元组的连接错误的接收;
保证「被动关闭连接」的一方,能被正确的关闭;(如果出现了最后一个ack的丢失,还有挽救的地步)
8、服务端大量出现time_awit状态的原因——http没有使用长连接、http长连接超时(客户端长时间没有给服务端请求,所以它就主动放弃连接)、http长连接的请求数量达到上限(高QPS的情况下)
9、服务器大量出现close_wait状态 说明服务端的程序没有调用 close 函数关闭连接。主要是代码的问题
10、如果已经建立了连接,但是客户端突然出现故障了怎么办 如果服务端一直不会发送数据给客户端,那么服务端是永远无法感知到客户端宕机这个事件的,也就是服务端的 TCP 连接将一直处于 ESTABLISH
状态,占用着系统资源。 保活机制
11、如果已经建立了连接,但是服务端的进程崩溃会发生什么?TCP 的连接信息是由内核维护的,所以当服务端的进程崩溃后,内核需要回收该进程的所有 TCP 连接资源,于是内核会发送第一次挥手 FIN 报文,后续的挥手过程也都是在内核完成,并不需要进程的参与,所以即使服务端的进程退出了,还是能与客户端完成 TCP 四次挥手的过程。
12、四次挥手能不能变三次
当被动关闭方在 TCP 挥手过程中,如果「没有数据要发送」,同时「没有开启 TCP_QUICKACK(默认情况就是没有开启,没有开启 TCP_QUICKACK,等于就是在使用 TCP 延迟确认机制)」,那么第二和第三次挥手就会合并传输,这样就出现了三次挥手。
所以,出现三次挥手现象,是因为 TCP 延迟确认机制导致的。