java usb tools / Bus Hound / USBlyzer / USBTrace / USB Monitor Pro

S

USB 之三 常用抓包/协议分析工具（Bus Hound、USBlyzer、USBTrace、USB Monitor Pro、USBMON等）

 

服务器TIME_WAIT和CLOSE_WAIT详解和解决办法

https://www.jianshu.com/p/54bf4ed83875

TCP报文格式

参考TCP报文段来理解一下第一图的数据传输细节：
事实上SYN J、SYN K ack=J+1，ack=K+1表示的意思是：
1、SYN标志位设置为1，而J表示的是此报文段的序列号seq
2、SYN、ACK标志位设置为1，K表示的是此报文段的序列号seq，ack=J+1表示确认序号设置为上次接收到的报文段的序列号的+1
3、ACK标志位设置为1，ack=K+1表示确认序号设置为上次接收到的报文段的序列号的+1

FIN ACK同理。

1、TIME_WAIT状态本身和应用层的客户端或者服务器是没有关系的。仅仅是主动关闭的一方，在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT。
服务器在处理客户端请求的时候，如果你的程序设计为服务器主动关闭，那么你才有可能需要关注这个TIMEWAIT状态过多的问题。
如果你的服务器设计为被动关闭，那么你首先要关注的是CLOSE_WAIT。

2、原则
TIMEWAIT并不是多余的。在TCP协议被创造，经历了大量的实际场景实践之后，TIMEWAIT出现了，因为TCP主动关闭连接的一方需要TIMEWAIT状态，它是我们的朋友。这是《UNIX网络编程》的作者----Steven对TIMEWAIT的态度。

3、TIMEWAIT是友好的
TCP要保证在所有可能的情况下使得所有的数据都能够被正确送达。当你关闭一个socket时，主动关闭一端的socket将进入TIME_WAIT状态，而被动关闭一方则转入CLOSED状态，这的确能够保证所有的数据都被传输。当一个socket关闭的时候，是通过两端四次握手完成的，当一端调用close()时，就说明本端没有数据要发送了。这好似看来在握手完成以后，socket就都可以处于初始的CLOSED状态了，其实不然。原因是这样安排状态有两个问题， 首先，我们没有任何机制保证最后的一个ACK能够正常传输，第二，网络上仍然有可能有残余的数据包(wandering duplicates)，我们也必须能够正常处理。
TIMEWAIT就是为了解决这两个问题而生的。
1.假设最后一个ACK丢失了，被动关闭一方会重发它的FIN。主动关闭一方必须维持一个有效状态信息（TIMEWAIT状态下维持），以便能够重发ACK。如果主动关闭的socket不维持这种状态而进入CLOSED状态，那么主动关闭的socket在处于CLOSED状态时，接收到FIN后将会响应一个RST。被动关闭一方接收到RST后会认为出错了。如果TCP协议想要正常完成必要的操作而终止双方的数据流传输，就必须完全正确的传输四次握手的四个环节，不能有任何的丢失。这就是为什么socket在关闭后，仍然处于TIME_WAIT状态的第一个原因，因为他要等待以便重发ACK。
2.假设目前连接的通信双方都已经调用了close()，双方同时进入CLOSED的终结状态，而没有走TIME_WAIT状态。会出现如下问题，现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，后建立的连接是原先连接的一个完全复用。还假定原先的连接中有数据报残存于网络之中，这样新的连接收到的数据报中有可能是先前连接的数据报。为了防止这一点，TCP不允许新连接复用TIME_WAIT状态下的socket。处于TIME_WAIT状态的socket在等待两倍的MSL时间以后（之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送途中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两倍的MSL），将会转变为CLOSED状态。这就意味着，一个成功建立的连接，必然使得先前网络中残余的数据报都丢失了。

4、大量TIMEWAIT在某些场景中导致的令人头疼的业务问题
大量TIMEWAIT出现，并且需要解决的场景
在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接。这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。为什么我们要关注这个高并发短连接呢？有两个方面需要注意：

高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短的概念，比如，取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高）
综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。同时，这些端口都是服务器临时分配，无法用SO_REUSEADDR选项解决这个问题。
5、一对矛盾
TIMEWAIT既友好，又令人头疼。
但是我们还是要抱着一个友好的态度来看待它，因为它尽它的能力保证了服务器的健壮性。

6、如何尽量处理TIMEWAIT过多
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
显示TCP各种连接状态的数量，类似如下信息
TIME_WAIT 1920
FIN_WAIT2 5
ESTABLISHED 363
发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决，
vi /etc/sysctl.conf
编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。

简单来说，就是打开系统的TIMEWAIT重用和快速回收，至于怎么重用和快速回收，这个问题我没有深究，实际场景中这么做确实有效果。用netstat或者ss观察就能得出结论。
还有些朋友同时也会打开syncookies这个功能，如下：
net.ipv4.tcp_syncookies = 1
打开这个syncookies的目的实际上是：“在服务器资源（并非单指端口资源，拒绝服务有很多种资源不足的情况）不足的情况下，尽量不要拒绝TCP的syn（连接）请求，尽量把syn请求缓存起来，留着过会儿有能力的时候处理这些TCP的连接请求”。

7、CLOSE_WAIT过多的原因出在程序本身，是由于被动关闭连接处理不当导致的。回到程序中检查连接关闭处理。

 

END