TCP 连接的状态

我们通过了解各个 TCP 状态,可以排除和定位网络或系统故障。

建立连接

TCP/IP 协议中,TCP 协议提供可靠的连接服务,采用三次握手建立一个连接

  1. 第一次握手:建立连接时,客户端发送 SYN 包到服务器,并进入 SYN_SENT 状态,等待服务器确认
  2. 第二次握手:服务器收到 SYN 包,必须确认客户端的 SYN,同时自己也发送一个 SYN 包,即 SYN + ACK,此时服务器进入 SYN_RECV 状态
  3. 第三次握手:客户端收到服务器发送的 SYN+ACK 包,向服务器发送确认 ACK,此包发送完毕,客户端和服务器进入 ESTABLISHED 状态,完成三次握手

关闭连接

由于 TCP 连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向的连接。收到一个 FIN 只意味着这一方向没有数据流动,一个 TCP 连接在收到一个 FIN 后仍能发送数据。首先进行关闭的一房将执行主动关闭,而另一方执行被动关闭。

TCP 的连接断开需要发送四个包,因此称为四次握手。客户端或服务器均可主动发起,在 socket 编程中,任何一方执行 close() 操作即可产生。

  1. 客户端发送一个 FIN,用来关闭客户端到服务端的数据传送,此时进入 FIN_WAIT1 状态
  2. 服务器收到这个 FIN,它发送一个 ACK,确认号为收到的序号加 1, 和 SYN 一样,一个 FIN 将占用一个序号,此时服务端进入 CLOSE_WAIT 状态,客户端接收到 ACK 后进入 FIN_WAIT2 状态(即半连接状态)
  3. 服务器关闭与客户端的连接,发送一个 FIN 给客户端,此时服务端进入 LAST_ACK 状态
  4. 客户端发回 ACK 报文确认,并将确认序号设置为收到序号加 1,此时客户端进入 TIME_WAIT 状态,服务端进入 CLOSED 状态

各个端口状态意义如下

  • LISTENING:侦听来自远方 TCP 端口的连接请求

端口提供某种服务才会处于 LISTENING 状态。提供服务时服务端需要打开一个 socket 进行监听,状态为 LISTEN

例如:提供 www 服务默认开的是80端口,提供 ftp 服务默认的端口为21,当提供的服务没有被连接时就处于 LISTENING 状态。FTP 服务启动后首先处于侦听(LISTENING)状态。处于侦听 LISTENING 状态时,该端口是开放的,等待连接,但还没有被连接。就像你房子的门已经敞开的,但还没有人进来。

LISTENING 状态最主要的是看本机开了哪些端口,这些端口都是哪个程序开的,关闭不必要的端口是保证安全的一个非常重要的方面,服务端口都对应一个服务(应用程序),停止该服务就关闭了该端口。

  • SYN-SENT:客户端 SYN_SENT 状态

客户端通过应用程序调用 connect 进行 active open 时,客户端 tcp 发送一个 SYN 以请求建立一个连接,之后状态置为 SYN_SENT
The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求

当请求连接时客户端首先要发送同步信号给要访问的机器,此时状态为 SYN_SENT,如果连接成功了就变为 ESTABLISHED,正常情况下 SYN_SENT 状态非常短暂。例如要访问网站 http://www.baidu.com,如果是正常连接的话,用 TCPView 观察 IEXPLORE.EXE(IE)建立的连接会发现很快从 SYN_SENT 变为 ESTABLISHED,表示连接成功。SYN_SENT 状态快的也许看不到。

如果发现有很多 SYN_SENT 出现,那一般有这么几种情况,一是你要访问的网站不存在或线路不好,二是用扫描软件扫描一个网段的机器,也会出出现很多 SYN_SENT,另外就是可能中了病毒了,例如中了”冲击波”,病毒发作时会扫描其它机器,这样会有很多 SYN_SENT 出现。

  • SYN-RECEIVED:服务器端 SYN_RCVD 状态

收到和发送一个连接请求后等待对方对连接请求的确认。

当服务器收到客户端发送的同步信号时,将标志位 ACKSYN 置 1 发送给客户端,此时服务器端处于 SYN_RCVD 状态,如果连接成功了就变为 ESTABLISHED,正常情况下 SYN_RCVD 状态非常短暂。如果发现有很多 SYN_RCVD 状态,那你的机器有可能被 SYN FloodDoS(拒绝服务攻击) 攻击了。

SYN Flood 的攻击原理是:
在进行三次握手时,攻击软件向被攻击的服务器发送 SYN_SENT (握手的第一步),但是这个地址是伪造的,服务器在收到连接请求时将标志位 ACKSYN 置 1 发送给客户端(握手的第二步),但是这些客户端的IP地址都是伪造的,服务器根本找不到客户机,也就是说握手的第三步不可能完成。

这种情况下服务器端一般会重试(再次发送 SYN+ACK 给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为 SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源—-数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的 CPU 时间和内存,何况还要不断对这个列表中的 IP 进行 SYN+ACK 的重试。此时从正常客户的角度看来,服务器失去响应,这种情况我们称做:服务器端受到了 SYN Flood 攻击

  • ESTABLISHED:代表一个打开的连接

ESTABLISHED 状态是表示两台机器正在传输数据,观察这个状态最主要的就是看哪个程序正在处于 ESTABLISHED 状态。

当客户端未主动 close 的时候就断开连接:即客户端发送的 FIN 丢失或未发送。这时候若客户端断开的时候发送了 FIN 包,则服务端将会处于 CLOSE_WAIT 状态;若客户端断开的时候未发送 FIN 包,则服务端处还是显示 ESTABLISHED 状态;结果客户端重新连接服务器。而新连接上来的客户端(也就是刚才断掉的重新连上来了)在服务端肯定是 ESTABLISHED ; 如果客户端重复的上演这种情况,那么服务端将会出现大量的假的 ESTABLISHED 连接和 CLOSE_WAIT 连接。最终结果就是新的其他客户端无法连接上来,但是利用 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 再重启,使用 netstat -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等待连接中断请求

这就是著名的半关闭的状态了,这是在关闭连接时,客户端和服务器两次握手之后的状态。在这个状态下,应用程序还有接受数据的能力,但是已经无法发送数据,但是也有一种可能是,客户端一直处于 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:等待远程 TCP 对连接中断的确认

比较少见.
Both sockets are shut down but we still don’t have all our data sent. 等待远程TCP对连接中断的确认

  • LAST-ACK:等待原来的发向远程 TCP 的连接中断请求的确认

被动关闭端一段时间后,接收到文件结束符的应用程序将调用 CLOSE 关闭连接。这导致它的 TCP 也发送一个 FIN,等待对方的 ACK。就进入了 LAST-ACK
The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程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 等待状态,这个状态又叫做 2MSL 状态,说的是在 TIME_WAIT2 发送了最后一个 ACK数据包 以后,要进入 TIME_WAIT 状态,这个状态是防止最后一次握手的数据包没有传送到对方那里而准备的(注意这不是四次握手,这是第四次握手的保险状态)。这个状态在很大程度上保证了双方都可以正常结束,但是,问题也来了。

由于插口的 2MSL 状态(插口是 IP 和端口对的意思,socket),使得应用程序在 2MSL 时间内是无法再次使用同一个插口的,对于客户程序还好一些,但是对于服务程序,例如 httpd,它总是要使用同一个端口来进行服务,而在 2MSL 时间内,启动 httpd 就会出现错误(插口被使用)。为了避免这个错误,服务器给出了一个平静时间的概念,这是说在 2MSL 时间内,虽然可以重新启动服务器,但是这个服务器还是要平静的等待 2MSL 时间的过去才能进行下一次连接。

  • CLOSED:没有任何连接状态

被动关闭端在接受到 ACK 包后,就进入了 closed 的状态。连接结束
The socket is not being used. 没有任何连接状态

原文:大专栏  TCP 连接的状态

原文地址:https://www.cnblogs.com/petewell/p/11601648.html

时间: 2024-08-29 10:59:52

TCP 连接的状态的相关文章

TCP连接的状态与关闭方式及其对Server与Client的影响

1. TCP连接的状态 首先介绍一下TCP连接建立与关闭过程中的状态.TCP连接过程是状态的转换,促使状态发生转换的因素包括用户调用.特定数据包以及超时等,具体状态如下所示: CLOSED:初始状态,表示没有任何连接.LISTEN:Server端的某个Socket正在监听来自远方的TCP端口的连接请求.SYN_SENT:发送连接请求后等待确认信息.当客户端Socket进行Connect连接时,会首先发送SYN包,随即进入SYN_SENT状态,然后等待Server端发送三次握手中的第2个包.SYN

TCP连接的状态与关闭方式,及其对Server与Client的影响

1. TCP连接的状态 首先介绍一下TCP连接建立与关闭过程中的状态.TCP连接过程是状态的转换,促使状态发生转换的因素包括用户调用.特定数据包以及超时等,具体状态如下所示: CLOSED:初始状态,表示没有任何连接. LISTEN:Server端的某个Socket正在监听来自远方的TCP端口的连接请求. SYN_SENT:发送连接请求后等待确认信息.当客户端Socket进行Connect连接时,会首先发送SYN包,随即进入SYN_SENT状态,然后等待Server端发送三次握手中的第2个包.

TCP连接的状态详解以及故障排查

转载自CSDN博客:http://blog.csdn.net/hguisu/article/details/38700899 TCP状态 TCP状态迁移路线图 TCP连接建立三次握手 TCP连接的终止四次握手释放 同时打开 同时关闭 TCP通信中服务器处理客户端意外断开 Linux错误信息errno列表 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 了解TCP之前,先了解几个命令:   linux查看tcp的状态命令: 1).netst

转载:TCP连接的状态详解以及故障排查

FROM:http://blog.csdn.net/hguisu/article/details/38700899 该博文的条理清晰,步骤明确,故复制到这个博文中收藏,若文章作者看到且觉得不能装载,麻烦请告知,谢谢. 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 linux查看tcp的状态命令: 1).netstat -nat  查看TCP各个状态的数量 2).lsof  -i:port  可以检测到打开套接字的状况 3).  sar

zabbix 监控tcp连接的状态

Tcp的连接状态对于我们web服务器来说是至关重要的,尤其是并发量ESTAB:或者是syn_recv值,假如这个值比较大的话我们可以认为是不是受到了攻击,或是是time_wait值比较高的话,我们要考虑看我们内核是否需要调优,太高的time_wait值的话会占用太多端口,要是端口少的话后果不堪设想: 一.我的上一篇已经写了步骤,这里我只是列出脚本: #!/bin/bash #xiaoluo #scripts for tcp status function SYNRECV { /usr/sbin/

netstat查看tcp连接的状态

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}' 原文地址:https://www.cnblogs.com/yeyu1314/p/10082188.html

tcp连接状态以及netstat命令

tcp是可靠的数据传输协议,相对于udp来说,基于udp的通信速度更快,但是没有数据的完整性的保证,更重要的是udp不会保证数据是否到达了目的方. TCP协议建立的tcp连接是有状态的,称之为tcp的有限状态机 SYN_SENT:主动建立连接的一方发起连接建立请求,也就是SYN=1,当发出同步位,状态转换位SYN_SENT SYN_RCVD:服务器端收到了客户端发送的同步报文,按照tcp协议的规定,回复ACK报文同时SYN位至1,此时服务器的状态转换为SYN_RCVD ESTABLISHED:当

配置开发支持高并发TCP连接的Linux应用程序全攻略

http://blog.chinaunix.net/uid-20733992-id-3447120.html http://blog.chinaunix.net/space.php?uid=16480950&do=blog&id=103598 原文见:http://www.cppblog.com/flashboy/articles/47012.html1.修改用户进程可打开文件数限制 在Linux平台上,无论编写客户端程序还是服务端程序,在进行高并发TCP连接处理时,最高的并发数量都要受到

Linux配置支持高并发TCP连接(socket最大连接数)

Linux配置支持高并发TCP连接(socket最大连接数)及优化内核参数 2011-08-09 15:20:58|  分类:LNMP&&LAMP|  标签:内核调优  文件系统调优  高并发调优  socket连接  ip_conntract  |字号大中小 订阅 1.修改用户进程可打开文件数限制在 Linux平台上,无论编写客户端程序还是服务端程序,在进行高并发TCP连接处理时,最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个s