TCP 协议状态解析

我们讲述的都是一些基本的tcp状态，就是使用netstat可以观察到的状态，记录一下，以便出现问题的时候一个思路。先大概叙述一下三次握手和四次握手的机制。

1、建立连接（三次握手）

（1）服务器会处于listen状态，客户端发送一个带SYN标志的TCP报文到服务器。

（2）服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。

因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。

（3）客户必须再次回应服务段一个ACK报文，这个时候两端就处于已经建立连接。

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

（1）客户端发送一个FIN，用来关闭客户到服务器的数据传送。

　（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。

（3）服务器关闭客户端的连接，发送一个FIN给客户端。

（4）客户段发回ACK报文确认，并将确认序号设置为收到序号加1。

3、状态说明

LISTEN: 表示服务器端的某个SOCKET处于监听状态，可以接受连接。

SYN_RCVD: 表示接受到了SYN报文，在正常情况下，服务器端收到客户端第一个报文并且回应客户端之后会进入这个状态，如果客户端一直不回应ACK的话，服务器的socket就会处于这个状态(当客户端可以ping通服务器，可是服务器ping不通客户端的时候会出现这个情况)。

SYN_SENT:与SYN_RCVD遥想呼应，这个状态表示客户端发送了SYN消息给服务器，但是还没收到服务器回应的ACK，所以的话当服务器ping不通的时候回进入到这个状态。

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连接，但另外还告诉对方，还有点数据需要传送给你，稍后再关闭连接。

TIME_WAIT:表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。(这个状态只有服务器主动关闭的时候才会出现)

CLOSING:这种状态比较特殊，实际情况中应该是很少见。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

CLOSE_WAIT:表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，需要回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，需要考虑是否还有数据发送给对方，如果没有，那么可以close这个SOCKET，发送FIN报文给对方，关闭连接。

特别说明一下TIME_WAIT，这个的话只有在服务器主动关闭，并且客户端也给予回应的时候会出现，需要等待2MSL的时候才可以重新使用该socket的端口。所以的话在编程的时候我们一般都需要复用这个端口，setsocketopt的时候需要将SO_REUSEADDR置为1，那样的话就不需要等2MSL的时候就可以立即使用该端口去绑定socket了。

2015年12月11日00:08:20

TCP 协议状态解析相关推荐

TCP协议状态解析和状态统计
一.三次握手和四次挥手 1.建立连接(三次握手) (1)服务器会处于listen状态,客户端发送一个带SYN标志的TCP报文到服务器. (2)服务器端回应客户端的请求,这是三次握手中的第2个报文,这个 ...
第二篇：可靠连接，TCP协议全解析
文章目录一.前言二.TCP报文结构三.TCP连接(重点:三次握手和四次挥手) 3.1 三次握手建立连接 3.2 四次挥手释放连接 3.3 wireshark演示四.TCP可靠连接 4.1 序号 ...
Go基于I/O多路复用的TCP协议流解析实践
在<Go经典阻塞式TCP协议流解析的实践>一文中,我们基于Go经典的阻塞I/O模型实现了一个基于TCP流的自定义协议的解析.这种one-connection-per-goroutine模型 ...
Wireshark工作笔记-TCP的状态解析，以及建立连接与关闭连接
在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG. 其中,对于我们日常的分析有用的就是前面的五个字段. 它们的含义是: SYN表示建立连 ...
连接跟踪TCP协议状态转换
在TCP报文处理函数nf_conntrack_tcp_packet中,根据连接的方向dir.索引index和旧的状态值,由tcp_conntracks全局数组来确定新的TCP状态. int nf_co ...
tcp协议不具备的功能是_TCP协议的状态深度解析,你知道的和不知道的都在这篇文章（干货）...
今天和大家说说,TCP协议的状态解析.大家可以看看下图,接下来我们会详细说明. 发起握手阶段 CLOSED:表示初始状态. LISTEN:表示服务器端的某个SOCKET处于监听状态,可以接受连接. S ...
TCP协议疑难杂症全景解析|硬核
大家好,我是Alex,今天分享一篇好文章,来自好友dog250,本文深入浅出地分析了TCP协议为什么要这样设计的背后原因,解答了几乎所有TCP疑难杂症问题,可以帮助大家查缺补漏,加深对TCP协议的理解 ...
TCP协议疑难杂症全景解析
说明: 1).本文以TCP的发展历程解析容易引起混淆,误会的方方面面 2).本文不会贴大量的源码,大多数是以文字形式描述,我相信文字看起来是要比代码更轻松的 3).针对对象:对TCP已经有了全面了解的 ...
TCP协议的部分解析(1)
本文以TCP的发展历程解析容易引起混淆,误会的方方面面,大多数是以文字形式描述,我相信文字看起来是要比代码更轻松的.针对对象:对TCP已经有了全面了解的人.因为本文不会解析TCP头里面的每一个字段或者 ...

TCP 协议状态解析

TCP 协议状态解析相关推荐

最新文章

热门文章