在平常运维服务器的时候，需要查看各种连接状态，所以必须要对TCP连接状态非常熟悉才知道每个状态的意义；只有知道了这些参数的意义才可以相对应的优化。

查看状态命令：

各个状态的意义如下 :

    LISTEN - 侦听来自远方TCP端口的连接请求； 
    SYN_SENT -在发送连接请求后等待匹配的连接请求； 
    SYN_RECV - 在收到和发送一个连接请求后等待对连接请求的确认； 
    ESTABLISHED- 代表一个打开的连接，数据可以传送给用户； 
    FIN_WAIT1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
    FIN_WAIT2 - 从远程TCP等待连接中断请求； 
    CLOSE_WAIT - 等待从本地用户发来的连接中断请求； 
    CLOSING -等待远程TCP对连接中断的确认； 
    LAST_ACK - 等待原来发向远程TCP的连接中断请求的确认； 
    TIME_WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认； 
    CLOSED - 没有任何连接状态；

三次握手四次断开流程示意：

    

更直观的流程示意：

    

关于四次断开：

   a.先由客户端向服务器端发送一个FIN，请求关闭数据传输。

   b.当服务器接收到客户端的FIN时，向客户端发送一个ACK，其中ack的值等于FIN+SEQ

   c.然后服务器向客户端发送一个FIN，告诉客户端应用程序关闭。

   d.当客户端收到服务器端的FIN是，回复一个ACK给服务器端。其中ack的值等于FIN+SEQ

为什么要4次才能断开？ 
   a.确保数据能够完成传输。

   b.但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；

   c.但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后

   d.再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。        

下面看下大家一般比较关心的三种TCP状态:

    SYN_RECV:

    服务端收到建立连接的SYN没有收到ACK包的时候处在SYN_RECV状态。有两个相关系统配置：

    1. net.ipv4.tcp_synack_retries  --> 默认值是5

        

       对于远端的连接请求SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连接请求包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的 SYN+ACK 数目。不应该大于255，默认值是5，对应于180秒左右时间。通常我们不对这个值进行修改，因为我们希望TCP连接不要因为偶尔的丢包而无法建立。

    2. net.ipv4.tcp_syncookies --> 默认值是1

       

     一般服务器都会设置net.ipv4.tcp_syncookies=1来防止SYN Flood攻击。假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）。

    这些处在SYNC_RECV的TCP连接称为半连接，并存储在内核的半连接队列中，在内核收到对端发送的ack包时会查找半连接队列，并将符合的requst_sock信息存储到完成三次握手的连接的队列中，然后删除此半连接。大量SYNC_RECV的TCP连接会导致半连接队列溢出，这样后续的连接建立请求会被内核直接丢弃，这就是SYN Flood攻击。

    能够有效防范SYN Flood攻击的手段之一，就是SYN Cookie。SYN Cookie原理由D. J. Bernstain和 Eric Schenk发明。SYN Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

    观测服务上SYN_RECV连接个数为：7314，对于一个高并发的服务器，这个数字比较正常。 

    CLOSE_WAIT

    发起TCP连接关闭的一方称为client，被动关闭的一方称为server。被动关闭的server收到FIN后，但未发出ACK的TCP状态是CLOSE_WAIT。出现这种状况一般都是由于server端代码的问题，如果你的服务器上出现大量CLOSE_WAIT，应该要考虑检查代码。

    TIME_WAIT

    根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟，即240秒。TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接，将导致服务器端存在大量的处于TIME_WAIT状态的socket， 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力，甚至耗尽可用的socket，停止服务。

    为什么需要TIME_WAIT？TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。

    和TIME_WAIT状态有关的系统参数有一般由3个，本厂设置如下：
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_fin_timeout = 30
    net.ipv4.tcp_fin_timeout，默认60s，减少这个数值以便加快系统关闭处于 FIN_WAIT2 状态的 TCP 连接,建议值为30。
    net.ipv4.tcp_tw_reuse = 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
    net.ipv4.tcp_tw_recycle = 1表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

    

本文转自激情燃烧的岁月博客51CTO博客，原文链接http://blog.51cto.com/liuzhengwei521/1924088如需转载请自行联系原作者

weilovepan520