关于timewait状态

四次挥手

1. 主动关闭连接的一方，调用close，协议层发送FIN包，在TCP报头的FIN字段设置为1，意思是我要和你断开链接，主动关闭连接的一方进入到了FIN_WATI_1状态
2. 被动关闭的一方收到了FIN包之后，协议层回复ACK包，在他的TCP报头中将ACK设置为1，表示收到了对方的关闭连接请求，被动 的一方进入到了CLOSE_WAIT状态；主动关闭的一方收到了被动关闭一方的响应，等待对方关闭，主动关闭的一方进入到了FIN_WAIT_2状态；
   这里解释一下，为什么被动关闭的一方收到主动关闭一方的FIN包之后进入的状态是CLOSE_WAIT状态呢，因为此时是传输层，传输层要等待上层的close操作
3. 被动关闭的一方在完成所有的数据传输之后，调用 close操作，此时发送FIN包，在TCP报头中将FIN字段设置为1，表示我要和你断开连接，等待对方的ACK，此时被动关闭的一方进入到了LAST_ACK状态
4. 主动弄关闭的一方，收到了对方的FIN包之后，回复了ACK包，主动关闭的一方进入到了TIME_WATI状态，而被动关闭的一方进入到了CLOSED状态
5. 主动关闭的一方等待了2MSL时间，结束TIME_WATI状态，进入了 CLOSED状态

为什么会有TIME_WAIT状态呢？？？

他的出现主要是为了解决网络丢包和网络不稳定所带来的其他问题：
1. 防止前一个连接的延迟数据包或者是丢失重传数据包被下一个连接使用，可能出现这样一种情况，用户在浏览器访问一个网站的时候，他的IP和端口号假设是192.168.3.2:8080，当用户再次在在浏览器中访问这个网站的时候，使用的IP和端口号恰巧还是192.168.3.2:8080，这个时候延迟数据或者是丢失重传的数据就会被新的 连接错误使用了
2. 防止最后传输的ACK包没有被对方接受，如果被动关闭的一方给主动关闭的一方发送了FIN，此时被动关闭的一方进入到了LAST_ACK状态，主动关闭连接的一方收到请求之后，回复ACK包，但是ACK丢失了，此时被动关闭的一方一直停留在LAST_ACK状态，被动方就会重发FIN包
如果TIME_WATI状态的很短，或者是没有这个状态，如果此时又新建立了一次连接，刚好这个连接是上次使用过的ip和port，这个时候就会收到错误连接的包，连接不成功

如何查看当前有timewait状态有哪些

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

服务器timewait状态问题

Linux能够分配的文件描述符是有限的，服务器需要处理网络的数量巨大的请求，如果存在大量的timewait状态状态，势必会造成系统的资源浪费，甚至是服务宕机。因为服务器是需要客户端建立连接的，通过ip+port的方式，可以理解为是端口号处于timewait状态。服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。