终于搞懂了 TCP 的 11 种状态 ，太不容易了…

本来想写运维过程中，nginx 服务器中 time_wait 的相关测试及解决方法的，然后发现TCP 的状态需要先铺垫一下，于是就整理了这篇文章。

网上很多大佬整理TCP三次握手、四次挥手，看到过很多人写，但其实从运维角度来说，我们分析 TCP 链接状态的时候，首先是用 netstat 或 ss 来查看。

之后才会根据 TCP 状态的情况进行抓包分析，进一步确认一些问题，所以我们首先看到的会是 TCP 的状态，那么就需要很清楚的了解 TCP 的11种状态代表着什么。

TCP 的11种状态分别对应 TCP 三次握手过程的5种状态和TCP四次挥手断开过程中的6种状态。

如上图，就是11种状态，在整个TCP建立连接和断开连接的整个过程

下面我用 tcpdump 抓了个完整的客户端和服务端的三次握手和四次挥手的包，可以对应上面的状态图

下面分开来详细看，首先是三次握手

上面这个图就是完整的三次握手过程

• 首先由 client 发出请求连接，即SYN=1 ACK=0，TCP 规定 SYN=1 时不能携带数据，但要消耗一个 seq，所以声明自己的seq=x

• 然后 Server 进行回复确认，即 SYN=1 ACK=1 seq=y ack=x+1

• 最后 Client 再进行一次确认，但不用SYN了，即ACK=1 seq=x+1 ack=y+1

整个过程中对应的TCP状态如下：

• CLOSED ：初始状态，表示TCP连接是”关闭着的”或”未打开的”

• LISTEN ：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接

• SYN_RCVD ：表示服务器接收到了来自客户端请求连接的SYN报文。这个状态是在服务端的，但是它是一个中间状态，很短暂，平常我们用netstat或ss的时候，不太容易看到这种状态，但是遇到SYN flood之类的SYN攻击时，会出现大量的这种状态，即收不到三次握手最后一个客户端发来的ACK，所以一直是这个状态，不会转换到ESTABLISHED

• SYN_SENT ：这个状态与SYN_RCVD状态相呼应，，它是TCP连接客户端的状态，当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随机进入到SYN_SENT状态，并等待服务端的SYN和ACK，该状态表示客户端的SYN已发送

• ESTABLISHED ：表示TCP连接已经成功建立，开始传输数据

以上就是三次握手的五种TCP状态，单从客户端服务端角度来区分的话，CLOSED和ESTABLISHED会在客户端和服务端都出现，而LISTEN和SYN_RCVD通常是出现在服务端，SYN_SENT出现在客户端

但通常在服务器和客户端并不是绝对的，比如 Nginx 的服务器中，Nginx 通常作为 web 代理服务器，它既是服务端，也是客户端，所以在查询统计 TCP 状态的时候，最好通过匹配端口来区分是客户端的还是服务端的，来更精确的定位问题。

接着看四次挥手的状态

• FIN_WAIT_1：这个状态在实际工作中很少能看到，当客户端想要主动关闭连接时，它会向服务端发送FIN报文，此时TCP状态就进入到FIN_WAIT_1的状态，而当服务端回复ACK，确认关闭后，则客户端进入到FIN_WAIT_2的状态，也就是只有在没有收到服务端ACK的情况下，FIN_WAIT_1状态才能看到，然后长时间收不到ACK，通常会在默认超时时间60s(由内核参数tcp_fin_timeout控制)后，直接进入CLOSED状态

• FIN_WAIT_2：这个状态相比较常见，也是需要注意的一个状态，FIN_WAIT_1在接收到服务端ACK之后就进入到FIN_WAIT_2的状态，然后等待服务端发送FIN，所以在收到对端FIN之前，TCP都会处于FIN_WAIT_2的状态，也就是，在主动断开的一端发现大量的FIN_WAIT_2状态时，需要注意，可能时网络不稳定或程序中忘记调用连接关闭，FIN_WAIT_2也有超时时间，也是由内核参数tcp_fin_timeout控制，当FIN_WAIT_2状态超时后，连接直接销毁

• CLOSE_WAIT：表示正在等待关闭，该状态只在被动端出现，即当主动断开的一端调用close()后发送FIN报文给被动端，被动段必然会回应一个ACK(这是由TCP协议层决定的)，这个时候，TCP连接状态就进入到CLOSE_WAIT

• LAST_ACK：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK的状态，当收到对方的ACK之后，就进入到CLOSED状态了

• TIME_WAIT ：该状态是最常见的状态，主动方在收到对方FIN后，就由FIN_WAIT_2状态进入到TIME_WAIT状态

• CLOSING ：这个状态是一个比较特殊的状态，也比较少见，正常情况下不会出现，但是当双方同时都作为主动的一方，调用 close() 关闭连接的时候，两边都进入FIN_WAIT_1 的状态，此时期望收到的是ACK包，进入 FIN_WAIT_2 的状态，但是却先收到了对方的FIN包，这个时候，就会进入到 CLOSING 的状态，然后给对方一个ACK，接收到 ACK 后直接进入到 CLOSED 状态。

以上就是四次挥手的6种状态，了解了每个状态的详细含义，就可以在性能调优及故障排查中快速定位问题，调整相关参数。

如文章开头说的一样，整理这篇主要是铺垫后面想整理的 nginx 中常见的 TIME_WAIT 的问题，TIME_WAIT 必须快速回收处理吗？TIME_WAIT 多少算多，会有什么影响，什么时候会产生大量的 TIME_WAIT，除了快速回收和重复利用，还有什么方法可以解决TIME_WAIT 的问题，下篇文章继续！

来源：本文来源于公众号运维研习社。

倒计时1天，GNSEC 2020 全球新一代软件工程线上峰会马上就要开始了！

抓紧最后的机会，扫描下方二维码立即报名

近期好文：

一个因 CA 根证书过期引起的故障，真相竟然是…

一文搞懂什么是 vlan、三层交换机、网关、DNS、子网掩码、MAC地址

投稿邮箱：[email protected]，或添加联系人微信：greatops1118.

点击阅读原文，进入“GNSEC 线上峰会”官网

点个“在看”，一年不宕机