性能测试性能测试基础TCP通信过程的状态码与过程

　　TCP通信过程
　　如下图所示，TCP通信过程包括三个步骤：建立TCP连接通道（三次握手）、数据传输、断开TCP连接通道（四次挥手）。
　　这里进一步探究TCP三路握手和四次挥手过程中的状态变迁以及数据传输过程。先看TCP状态状态转换图。
　　上半部分是TCP三路握手过程的状态变迁，下半部分是TCP四次挥手过程的状态变迁。
　　CLOSED：起始点，在超时或者连接关闭时候进入此状态，这并不是一个真正的状态，而是这个状态图的假想起点和终点。
　　LISTEN：服务器端等待连接的状态。服务器经过socket，bind，listen函数之后进入此状态，开始监听客户端发过来的连接请求。此称为应用程序被动打开（等到客户端连接请求）。
　　SYNSENT：第一次握手发生阶段，客户端发起连接。客户端调用connect，发送SYN给服务器端，然后进入SYNSENT状态，等待服务器端确认（三次握手中的第二个报文）。如果服务器端不能连接，则直接进入CLOSED状态。
　　SYNRCVD：第二次握手发生阶段，跟3对应，这里是服务器端接收到了客户端的SYN，此时服务器由LISTEN进入SYNRCVD状态，同时服务器端回应一个ACK，然后再发送一个SYN即SYNACK给客户端。状态图中还描绘了这样一种情况，当客户端在发送SYN的同时也收到服务器端的SYN请求，即两个同时发起连接请求，那么客户端就会从SYNSENT转换到SYNREVD状态。
　　ESTABLISHED：第三次握手发生阶段，客户端接收到服务器端的ACK包（ACK，SYN）之后，也会发送一个ACK确认包，客户端进入ESTABLISHED状态，表明客户端这边已经准备好，但TCP需要两端都准备好才可以进行数据传输。服务器端收到客户端的ACK之后会从SYNRCVD状态转移到ESTABLISHED状态，表明服务器端也准备好进行数据传输了。这样客户端和服务器端都是ESTABLISHED状态，就可以进行后面的数据传输了。所以ESTABLISHED也可以说是一个数据传送状态。
　　上面就是TCP三次握手过程的状态变迁。结合第一张三次握手过程图，从报文的角度看状态变迁：SYNSENT状态表示已经客户端已经发送了SYN报文，SYNRCVD状态表示服务器端已经接收到了SYN报文。
　　下面看看TCP四次挥手过程的状态变迁。结合第一张四次挥手过程图来理解。
　　FINWAIT1：第一次挥手。主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服务器端，这里以客户端执行主动关闭为例），终止连接时，发送FIN给对方，然后等待对方返回ACK。调用close（）第一次挥手就进入此状态。
　　CLOSEWAIT：接收到FIN之后，被动关闭的一方进入此状态。具体动作是接收到FIN，同时发送ACK。之所以叫CLOSEWAIT可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。前面已经说过，TCP关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到FIN后也需要调用close关闭，这个CLOSEWAIT就是处于这个状态，等待发送FIN，发送了FIN则进入LASTACK状态。
　　FINWAIT2：主动端（这里是客户端）先执行主动关闭发送FIN，然后接收到被动方返回的ACK后进入此状态。
　　LASTACK：被动方（服务器端）发起关闭请求，由状态2进入此状态，具体动作是发送FIN给对方，同时在接收到ACK时进入CLOSED状态。
　　CLOSING：两边同时发起关闭请求时（即主动方发送FIN，等待被动方返回ACK，同时被动方也发送了FIN，主动方接收到了FIN之后，发送ACK给被动方），主动方会由FINWAIT1进入此状态，等待被动方返回ACK。
　　TIMEWAIT：从状态变迁图会看到，四次挥手操作最后都会经过这样一个状态然后进入CLOSED状态。共有三个状态会进入该状态
　　对于测试来说，例1：我们通过一个例子来分析TIMEWAIT，执行如下测试指令：netstatnawktcp｛S〔NF〕｝END｛for（ainS）printa，S〔a〕｝返回如下的状态码：TIMEWAIT814CLOSEWAIT1FINWAIT11ESTABLISHED634SYNRECV2LASTACK1常用的三个状态是：ESTABLISHED表示正在通信，TIMEWAIT表示主动关闭，CLOSEWAIT表示被动关闭。
　　如果服务器出了异常，百分之八九十都是下面两种情况：
　　1。服务器保持了大量TIMEWAIT状态
　　2。服务器保持了大量CLOSEWAIT状态
　　1。防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
　　2。可靠的关闭TCP连接。在主动关闭方发送的最后一个ack（fin），有可能丢失，这时被动方会重新发fin，如果这时主动方处于CLOSED状态，就会响应rst而不是ack。所以主动方要处于TIMEWAIT状态，而不能是CLOSED。另外这么设计TIMEWAIT会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。
　　关于MSL引用下面一段话：
　　【MSL】MSL為一個TCPSegment（某一塊TCP網路封包）從來源送到目的之間可續存的時間（也就是一個網路封包在網路上傳輸時能存活的時間），由於RFC793TCP傳輸協定是在1981年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一個byte出現要等4分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將TIMEWAIT狀態的續存時間大幅調低，好讓連線埠（Ports）能更快空出來給其他連線使用。
　　再引用网络资源的一段话：
　　【TIMEWAIT】值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIMEWAIT状态，可想而知，对于访问量大的WebServer，会存在大量的TIMEWAIT状态，假如server一秒钟接收1000个请求，那么就会积压2401000240，000个TIMEWAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIMEWAIT，所以对于新的TCP连接请求，判断是否hit中一个TIMEWAIT不会太费时间，但是有这么多状态要维护总是不好。HTTP协议1。1版规定default行为是KeepAlive，也就是会重用TCP连接传输多个requestresponse，一个主要原因就是发现了这个问题。
　　也就是说HTTP的交互跟上面画的那个图是不一样的，关闭连接的不是客户端，而是服务器，所以web服务器也是会出现大量的TIMEWAIT的情况的。
　　解决思路：让服务器能够快速回收和重用那些TIMEWAIT的资源。
　　下面来看一下我们网管对etcsysctl。conf文件的修改：对于一个新建连接，内核要发送多少个SYN连接请求才决定放弃，不应该大于255，默认值是5，对应于180秒左右时间net。ipv4。tcpsynretries2net。ipv4。tcpsynackretries2表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒net。ipv4。tcpkeepalivetime1200net。ipv4。tcporphanretries3表示如果套接字由本端要求关闭，这个参数决定了它保持在FINWAIT2状态的时间net。ipv4。tcpfintimeout30表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。net。ipv4。tcpmaxsynbacklog4096表示开启SYNCookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭net。ipv4。tcpsyncookies1表示开启重用。允许将TIMEWAITsockets重新用于新的TCP连接，默认为0，表示关闭net。ipv4。tcptwreuse1表示开启TCP连接中TIMEWAITsockets的快速回收，默认为0，表示关闭net。ipv4。tcptwrecycle1减少超时前的探测次数net。ipv4。tcpkeepaliveprobes5优化网络设备接收队列net。core。netdevmaxbacklog3000
　　修改完之后执行sbinsysctlp让参数生效。
　　net。ipv4。tcptwreuse和net。ipv4。tcptwrecycle的开启都是为了回收处于TIMEWAIT状态的资源。
　　net。ipv4。tcpfintimeout这个时间可以减少在异常情况下服务器从FINWAIT2转到TIMEWAIT的时间。
　　net。ipv4。tcpkeepalive一系列参数，是用来设置服务器检测连接存活的相关配置。
　　例2：分析与解决CLOSEWAIT
　　TIMEWAIT状态可以通过优化服务器参数得到解决，因为发生TIMEWAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。
　　但是CLOSEWAIT就不一样了，从上面的图可以看出来，如果一直保持在CLOSEWAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。所以如果将大量CLOSEWAIT的解决办法总结为一句话那就是：让开发查代码。因为问题出在服务器程序里。
　　如果你使用的是HttpClient并且你遇到了大量CLOSEWAIT的情况，以下举例说明一下：
　　TOMCAT出现如下信息，说明服务器发生了大量得CLOSEWAIT：org。apache。http。conn。ConnectionPoolTimeoutException：Timeoutwaitingforconnection
　　linux运行：netstatnawktcp｛S〔NF〕｝END｛for（ainS）printa，S〔a〕｝
　　时间一长tomcat就无法继续处理其他请求，从假死变成真死了。
　　执行命令后，发现CLOSEWAIT的数量始终在400以上，一直没降过。
　　分析：
　　简单来说CLOSEWAIT数目过大是由于被动关闭连接处理不当导致的。
　　我说一个场景，服务器A会去请求服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完资源后服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，连接状态我们可以看到是TIMEWAIT。如果一旦发生异常呢？假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后自己并没有释放连接，那就会造成CLOSEWAIT的状态了。
　　所以很明显，问题还是出在后台程序里头。
　　参考：https：blog。csdn。netshootyouarticledetails6615051
　　参考资料《UNP》《TCPIPVol。1》