E426ae39056ea8d2d4f371f9d8f40eb5
TCP 四次挥手的那些细节

TCP 四次挥手的那些细节

请先思考如下的问题

  • FIN_WAIT1 能持续多久?
  • TIME_WAIT这个状态的意义是什么?
  • FIN_WAIT1状态只会出现在 client 端么?
  • 。。。。。。

TCP 四次挥手

如下的动图描述的非常的清晰:

img

img

这里写图片描述

这里写图片描述

FIN_WAIT1 能持续多久?

或者说当客户端发送 Fin 之后由于网络原因 server 端的 ack 没有达到,那么客户端会重试多少次?

  • ESTAB状态发送FIN即切换到FIN_WAIT1状态;
  • FIN_WAIT1状态下收到针对FIN的ACK即可离开FIN_WAIT1到达FIN_WAIT2.

一般情况下,服务器间的 ACK 确认是非常快的,以至于我们凭肉眼往往观察不到 FIN_WAIT1 的存在。

然而,这是真的吗?我们之所以得到FIN_WAIT1持续1个RTT这个结论,基于两个假设,即:

  1. TCP的对端是一个正常的TCP端;
  2. 两端TCP之间的链路是正常的,可达的。

如果针对FIN的ACK迟迟不来,那么必然要有一个等待的极限,这个极限在Linux内核协议栈中由以下参数控制

实际上,控制客户端重发FIN的关键参数是 tcp_orphan_retries 文档上默认值的建议是8。TCP每一次超时,都会对下一次超时时间进行指数退避,这里的次数量就是要经过几次退避的时间。即便是ACK永远不来,FIN_WAIT1状态也不会一直持续下去的,这有效避免了有针对性截获ACK或者不发送ACK而导致的DDoS,退一万步讲,即便是没有DDoS,这种做法也具有资源利用率的容错性,使得资源使用更加高效。

FIN_WAIT1状态只会出现在 client 端?

错!将主动断开的一方和被动断开的一方分开描述会更清晰。FIN_WAIT1 即可能出现在服务端,也可能出现在客户端,关键看哪一端主动关闭连接。常见的如 Nginx 服务器,如果使用的是短连接,那么服务端会主动关闭连接,如果使用的是长连接,那么可能就是客户端主动关闭连接了。

出现TIME_WAIT(2msl)出现,以及TIME_WAIT这个状态的意义,msl是多长时间

top Created with Sketch.