《TCP连接状态详解以及故障排查》由会员分享，可在线阅读，更多相关《TCP连接状态详解以及故障排查（26页珍藏版）》请在金锄头文库上搜索。
1、我们通过了解 TCP 各个状态，可以排除和定位网络或系统故障时大有帮助。（总结网络上的内容）1、TCP 状态linux 查看 tcp 的状态命令：1）、 netstat -nat 查看 TCP 各个状态的数量2）、 lsof -i:port 可以检测到打开套接字的状况3)、 sar -n SOCK 查看 tcp 创建的连接数4)、tcpdump -iany tcp port 9000 对 tcp 端口为 9000 的进行抓包LISTENING：侦听来自远方的 TCP 端口的连接请求. 首先服务端需要打开一个 socket 进行监听，状态为 LISTEN。有提供某种服务才会处于 LISTENIN
2、G 状态，TCP 状态变化就是某个端口的状态变化，提供一个服务就打开一个端口，例如：提供 www 服务默认开的是 80 端口，提供 ftp 服务默认的端口为 21，当提供的服务没有被连接时就处于 LISTENING 状态。FTP 服务启动后首先处于侦听（LISTENING）状态。处于侦听 LISTENING 状态时，该端口是开放的，等待连接，但还没有被连接。就像你房子的门已经敞开的，但还没有人进来。看 LISTENING 状态最主要的是看本机开了哪些端口，这些端口都是哪个程序开的，关闭不必要的端口是保证安全的一个非常重要的方面，服务端口都对应一个服务（应用程序），停止该服务就关闭了该端口，例如
3、要关闭 21 端口只要停止 IIS 服务中的 FTP 服务即可。关于这方面的知识请参阅其它文章。如果你不幸中了服务端口的木马，木马也开个端口处于 LISTENING 状态。SYN-SENT：客户端 SYN_SENT 状态：再发送连接请求后等待匹配的连接请求: 客户端通过应用程序调用 connect 进行active open.于是客户端 tcp 发送一个 SYN 以请求建立一个连接. 之后状态置为SYN_SENT. /*The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求 */当请求连接时客
4、户端首先要发送同步信号给要访问的机器，此时状态为 SYN_SENT，如果连接成功了就变为 ESTABLISHED，正常情况下 SYN_SENT 状态非常短暂。例如要访问网站 http:/,如果是正常连接的话，用 TCPView 观察 IEXPLORE.EXE（IE）建立的连接会发现很快从 SYN_SENT 变为 ESTABLISHED，表示连接成功。SYN_SENT 状态快的也许看不到。 如果发现有很多 SYN_SENT 出现，那一般有这么几种情况，一是你要访问的网站不存在或线路不好，二是用扫描软件扫描一个网段的机器，也会出出现很多 SYN_SENT，另外就是可能中了病毒了，例如中了冲击波，病
5、毒发作时会扫描其它机器，这样会有很多SYN_SENT 出现。SYN-RECEIVED：服务器端状态 SYN_RCVD再收到和发送一个连接请求后等待对方对连接请求的确认当服务器收到客户端发送的同步信号时，将标志位 ACK 和 SYN 置 1 发送给客户端，此时服务器端处于 SYN_RCVD 状态，如果连接成功了就变为 ESTABLISHED，正常情况下 SYN_RCVD状态非常短暂。如果发现有很多 SYN_RCVD 状态，那你的机器有可能被 SYN Flood 的 DoS(拒绝服务攻击)攻击了。SYN Flood 的攻击原理是：在进行三次握手时，攻击软件向被攻击的服务器发送 SYN 连接请求（握
6、手的第一步），但是这个地址是伪造的，如攻击软件随机伪造了 51.133.163.104、65.158.99.152 等等地址。服务器在收到连接请求时将标志位 ACK 和 SYN 置 1 发送给客户端（握手的第二步），但是这些客户端的 IP 地址都是伪造的，服务器根本找不到客户机，也就是说握手的第三步不可能完成。这种情况下服务器端一般会重试（再次发送 SYN+ACK 给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为 SYN Timeout，一般来说这个时间是分钟的数量级（大约为 30 秒-2 分钟）；一个用户出现异常导致服务器的一个线程等待 1 分钟并不是什么很大的问题，但
7、如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源-数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的 CPU 时间和内存，何况还要不断对这个列表中的 IP 进行SYN+ACK 的重试。此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了 SYN Flood 攻击（SYN 洪水攻击）ESTABLISHED：代表一个打开的连接。ESTABLISHED 状态是表示两台机器正在传输数据，观察这个状态最主要的就是看哪个程序正在处于 ESTABLISHED 状态。服务器出现很多 ESTABLISHED 状态： netstat -
8、nat |grep 9502 或者使用 lsof -i:9502 可以检测到。 当客户端未主动 close 的时候就断开连接：即客户端发送的 FIN丢失或未发送。这时候若客户端断开的时候发送了 FIN 包，则服务端将会处于 CLOSE_WAIT 状态；这时候若客户端断开的时候未发送 FIN 包，则服务端处还是显示 ESTABLISHED 状态；结果客户端重新连接服务器。而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED; 如果客户端重复的上演这种情况，那么服务端将会出现大量的假的ESTABLISHED 连接和 CLOSE_WAIT 连接。最终结果就是新的其
9、他客户端无法连接上来，但是利用 netstat 还是能看到一条连接已经建立，并显示 ESTABLISHED，但始终无法进入程序代码。FIN-WAIT-1：等待远程 TCP 连接中断请求，或先前的连接中断请求的确认主动关闭(active close)端应用程序调用 close，于是其 TCP 发出 FIN 请求主动关闭连接，之后进入 FIN_WAIT1 状态./* The socket is closed, and the connection is shutting down. 等待远程 TCP 的连接中断请求，或先前的连接中断请求的确认 */如果服务器出现 shutdown 再重启，使用 n
10、etstat -nat 查看，就会看到很多FIN-WAIT-1 的状态。就是因为服务器当前有很多客户端连接，直接关闭服务器后，无法接收到客户端的 ACK。FIN-WAIT-2：从远程 TCP 等待连接中断请求主动关闭端接到 ACK 后，就进入了 FIN-WAIT-2 ./* Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程 TCP 等待连接中断请求 */这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能
11、力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于 FIN_WAIT_2 状态，而服务器则一直处于 WAIT_CLOSE 状态，而直到应用层来决定关闭这个状态。CLOSE-WAIT：等待从本地用户发来的连接中断请求 被动关闭(passive close)端 TCP 接到 FIN 后，就发出 ACK 以回应 FIN 请求(它的接收也作为文件结束符传递给上层应用程序),并进入 CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求 */CLOSING：等待
12、远程 TCP 对连接中断的确认比较少见./* Both sockets are shut down but we still dont have all our datasent. 等待远程 TCP 对连接中断的确认 */LAST-ACK：等待原来的发向远程 TCP 的连接中断请求的确认被动关闭端一段时间后，接收到文件结束符的应用程序将调用 CLOSE 关闭连接。这导致它的 TCP 也发送一个 FIN,等待对方的 ACK.就进入了 LAST-ACK. /* The remote end has shut down, and the socket is closed. Waiting for a
13、cknowledgement. 等待原来发向远程 TCP 的连接中断请求的确认*/使用并发压力测试的时候，突然断开压力测试客户端，服务器会看到很多 LAST-ACK。TIME-WAIT：等待足够的时间以确保远程 TCP 接收到连接中断请求的确认在主动关闭端接收到 FIN 后，TCP 就发送 ACK 包，并进入 TIME-WAIT 状态。/*The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程 TCP 接收到连接中断请求的确认 */TIME_WAIT 等待状态，这个状态又叫做 2
14、MSL 状态，说的是在 TIME_WAIT2 发送了最后一个 ACK 数据报以后，要进入 TIME_WAIT 状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。这个状态在很大程度上保证了双方都可以正常结束，但是，问题也来了。由于插口的 2MSL 状态（插口是 IP 和端口对的意思，socket），使得应用程序在 2MSL时间内是无法再次使用同一个插口的，对于客户程序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在 2MSL 时间内，启动 httpd 就会出现错误（插口被使用）。为了避免这个错误，
15、服务器给出了一个平静时间的概念，这是说在2MSL 时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待 2MSL 时间的过去才能进行下一次连接。 CLOSED：没有任何连接状态被动关闭端在接受到 ACK 包后，就进入了 closed 的状态。连接结束./* The socket is not being used. 没有任何连接状态2、TCP 状态迁移路线图client/server 两条路线讲述 TCP 状态迁移路线图：这是一个看起来比较复杂的状态迁移图，因为它包含了两个部分-服务器的状态迁移和客户端的状态迁移，如果从某一个角度出发来看这个图，就会清晰许多，这里面的服务器和客户端都
16、不是绝对的，发送数据的就是客户端，接受数据的就是服务器。客户端应用程序的状态迁移图客户端的状态可以用如下的流程来表示：CLOSED-SYN_SENT-ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到 SYN 报文的 ACK 以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历 FIN_WAIT_1，FIN_WAIT_2 等状态，这些状态的迁移就是前面提到的结束连接的四次握手。服务器的状态迁移图服务器的状态可以用如下的流程来表示：CLOSED-LISTEN-SYN 收到-ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSED在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭
