TCP TIME_WAIT
状态解释
如下图，TCP和谐握手姿势（下图摘抄至网络）
在下图中，纠正一些错误问题，个人认为关闭连接发起端进入到TIME_WAIT的状态时，等待的超时是60s，Linux默认的（至少CentOS7是这样的，源码位于tcp.h文件中定义的）超时结束正式CLOSED
TIME_WAIT状态是主动发起关闭连接一方存在的状态（有可能是客户端，也有可能服务端主动关闭）至少服务端主动关闭见到，但是不理解为什么主动关闭
大致过程是
- 发起方主动关闭，发送fin包至对端，同时状态转为FIN_WAIT1
- 对端接收方收到发起方的终止连接fin包后，并回执给发起方ack包，俗称确认包，同时状态转为CLOSE_WAIT状态
- 发起方收到接收方的回执ack包后，同时状态转为FIN_WAIT2，此时发起方等待接收方的最后一个关闭连接的fin包
- 在这个过程中，接收方有可能没有将数据处理完，在这个状态下一半称之为TCP连接半关闭状态，等到接收方处理完相应的数据，会回执给发送方最后一fin包
- 发送方接收到接收方回执的最后一个fin包正式关闭连接，同时将确认关闭连接的ack包发送给接收方，并进入TIME_WAIT状态，进入到TCP_TW_TIMEWAIT_LEN定义的超时时间，默认60s
- 接收方收到最一个ack包后，正式关闭此方的连接CLOSE
原因
造成大量TIME_WAIT的原因是什么
- 在生产环境存在大量的短连接请求
- 特别是HTTP请求中，如果connection header设置为close，通常由服务端主动关闭（未验证）
- 由于TIME_WAIT有超时设置，所以在服务器不断累积，产生很多TIME_WAIT连接
影响
对系统的资源开销的影响
- 消耗大量socket套接字
- 消耗系统资源上下文切换
- 消耗TCP网络资源的开销端口
- 消耗文件句柄
作用
TIME_WAIT的作用是什么