State: 表TCP连接状态
ESTABLISHED 指TCP连接已建立,双方可以进行方向数据传递
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话, 那么你也就可以close 这个SOCKET,发送 FIN 报文给对方,也即关闭连接。所以你在CLOSE_WAIT 状态下,需要完成的事情是等待你去关闭连接。
LISTENING: 指TCP正在监听端口,可以接受链接
TIME_WAIT: 指连接已准备关闭。表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2 状态。
FIN_WAIT_1: 这个状态要好好解释一下,其实FIN_WAIT_1和 FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报 文。而这两种状态的区别是:FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN 报文,此时该SOCKET即进入到FIN_WAIT_1 状态。而当对方回应ACK 报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况 下,无论对方何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2 状态还有时常常可以用 netstat看到。
FIN_WAIT_2:上面已经详细解释了这种状态,实际上FIN_WAIT_2 状态下的SOCKET,表示半连接,也即有一方要求close 连接,但另外还告诉对方,我暂时还有点数据需要传送给你,稍后再关闭连接。
LAST_ACK: 是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了
SYNC_RECEIVED: 收到对方的连接建立请求,
这个状态表示接受到了SYN报文,在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态,很短暂,基本上用netstat你是很难看到这种状态的,除非你特意写了一个客户端测试程序,故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时,当收到客户端的ACK报文后,它会进入到ESTABLISHED状态。
SYNC_SEND: 已经主动发出连接建立请求。与SYN_RCVD遥想呼应,当客户端SOCKET执行CONNECT连接时,它首先发送SYN报文,因此也随即它会进入到了SYN_SENT状态,并等待服务端的发送三次握手中的第2个报文。
上述状态的定义与TCP规则定义的TCP状态图一致,可以对照如下两张TCP建立与终止链接的状态转换图进行理解。
附图1. TCP建立连接之状态转换图
TCP中断连接之状态转换图
netstat -b 显示在创建每个连接或侦听端口时涉及的可执行程序,需要管理员权限,
这条指令对于查找可疑程序非常有帮助。
$ netstat -b 活动连接 协议 本地地址 外部地址 状态 TCP .: .:http CLOSE_WAIT TCP .: .: ESTABLISHED TCP .: nrt19s11--f7:http ESTABLISHED [chrome.exe] TCP .: .: SYN_SENT
netstat -n -o
-n 以数字形式显示地址和端口号。
-o 显示拥有的与每个连接关联的进程 ID。
$ netstat -n -o 活动连接 协议 本地地址 外部地址 状态 PID TCP .: .: CLOSE_WAIT TCP .: .: ESTABLISHED TCP .: .: SYN_SENT
netstat -s -p
-s 显示每个协议的统计。默认情况下,显示IP、IPv6、ICMP、ICMPv6、TCP、TCPv6、UDP 和 UDPv6的统计;-p 选项可用于指定默认的子网。
-p proto 显示 proto 指定的协议的连接;proto 可以是下列任何一个: TCP、UDP、TCPv6 或 UDPv6。如果与 -s 选项一起用来显示每个协议的统计,proto 可以是下列任
何一个: IP、IPv6、ICMP、ICMPv6、TCP、TCPv6、UDP 或 UDPv6。
$ netstat -s -p tcp IPv4 的 TCP 统计信息 主动开放 = 被动开放 = 失败的连接尝试 = 重置连接 = 当前连接 = 接收的分段 = 发送的分段 = 重新传输的分段 = 活动连接 协议 本地地址 外部地址 状态 TCP .: .:http CLOSE_WAIT TCP .: .: ESTABLISHED TCP .: bogon: SYN_SENT $ netstat -s -p udp IPv4 的 UDP 统计信息 接收的数据报 = 无端口 = 接收错误 = 发送的数据报 = 活动连接 协议 本地地址 外部地址 状态
TCP连接建立
首先要说明的是要明确TCP连接建立的过程需要3次握手,下面举例说明各种状态存在的时刻:
1. 首先在服务器A上开启FTP服务,开始侦听来自远端TCP端口的连接请求,这个时候查看服务器A状态为:LISTENING
2. 在客户端B上向A发送FTP连接请求,这个时候数据包同步位置1,这是TCP三次握手的第一步。在发送后没收到确认时,在客户端B上其状态为:SYN-SENT。此时客户端B启动连接定时器。如果在75秒内没有收到应答,则放弃连接建立。
3. 在服务器A上收到从B上发送的SYN同步包后,确认,然后再向B发送SYN的同步包,此数据包同时将TCP标记中的同步位和确认位置1,它既对第一步中的客户端同步数据包进行确认,表示愿意与客户端同步,同时再对客户端主机进行同步请求,这是TCP连接的第一步。这个时候在服务器A上,状态为:SYN-RECEIVED。此时服务器A启动连接定时器。如果在75秒内没有收到应答,则放弃连接建立。
4. 在客户端B上接收到从A上发过来的确认同步包后进行确认,此数据包中将TCP标记中的确认位置1,表示这是一个确认数据包,此时在客户端B状态转换为:ESTABLISHED
5. 服务器A接收到从B发过来的确认包后,状态转换为:ESTABLISHED
此时TCP连接正式建立。
TCP连接关闭
6. 应用程序在在连接不需要的时候,通过客户端B向服务器A发送的终止信息的FIN包后,客户端B处于FIN-WAIT-1状态。
7. 从服务器A接收到客户端B发送的终止数据包,它告诉客户端B已成功接收客户端的上数据包,此时等待应用程序来关闭连接,此时服务器A进入CLOSE_WAIT状态。
8. 客户端B接收到带有确认位的数据包后,对此进行确认,同意关闭TCP连接此时客户端B转移到FIN-WAIT-2状态。当连接从FIN-WAIT-1状态转移到FIN-WAIT-2状态时,将一个FIN-WAIT-2定时器设置为10分钟。
9. 服务器A在应用程序同意终止连接后,向客户端B发送终止FIN包,此时服务器状态转为LAST-ACT。
10. 客户端B在接收到从服务器A发送的终止包后,同意终止连接,然后再向服务器端发送确认信息,此时客户端B转向TIME-WAIT状态。当连接进入TIME-WAIT状态时,该定时器被激活。
11. 服务端A在收到客户端B的确认后,关闭连接,服务器A状态转向CLOSED。
12. 客户端B在TIME-WAIT定时器超时时,与该连接相关的内核数据块被删除,连接终止,转向CLOSED状态。
此时TCP连接正式关闭。
TCP连接关闭时需要四次握手才能够完成,如下图所示:
产生CLOSE_WAIT状态的一方,是属于被动关闭的一方,用简单的话对解释上图(主动关闭方为A,被动关闭方为B):
A发一条FIN(关闭)请求给B,说我要关闭了; B回应一条ACK(确认)请求给A,说我知道了,你关吧,此时B就会进行CLOSE_WAIT状态; B发送一条FIN(关闭)请给A,说我要关闭了; A收到发送一条ACK(确认)消息说,你关闭吧。
|