TCP通信过程中各步骤的状态---(简单解释)
2017-03-15 09:44
363 查看
状态图 1
状态图 2
对于上面的图 N 多人都知道,它排除和定位网络或系统故障时大有帮助,但是怎样牢牢地将这张图刻在脑中呢?那么你就一定要对这张图的每一个状态,及转换的过程有深刻的认识,不能只停留在一知半解之中。下面对这张图的11种状态详细解析一下,以便加强记忆!不过在这之前,先回顾一下 TCP 建立连接的三次握手过程,以及关闭连接的四次握手过程。
CLOSED: 这个没什么好说的了,表示初始状态。
LISTEN: 这个也是非常容易理解的一个状态,表示服务器端的某个 SOCKET 处于监听状态,可以接收连接了。
SYN_RCVD: 这个状态表示接收到了 SYN 报文,在正常情况下,这个状态是服务器端的SOCKET 在建立 TCP 连接时的三次握手会话过程中的一个中间状态,很短暂,基本上用 netstat 你是很难看到这种状态的,除非你特意写了一个客户端测试程序,故意将三次
TCP 握手过程中最后一个 ACK 报文不予发送。因此这种状态时,当收到客户端的 ACK 报文后,它会进入到 ESTABLISHED 状态。
SYN_SENT: 这个状态与 SYN_RCVD 相呼应,当客户端 SOCKET 执行 CONNECT 连接时,它首先发送 SYN 报文,因此也随即它会进入到了 SYN_SENT 状态,并等待服务端的发送三次握手中的第 2 个报文。SYN_SENT 状态表示客户端已发送 SYN 报文。
ESTABLISHED:这个容易理解了,表示连接已经建立了。
个人理解:
好比两个人对话,总得是一个人问一个人答吧。这个建立过程就好这个相似:首先客户端发连接请求,进入SYN_SENT状态,然后服务器端如果收到了就进入SYN_RCVD状态,你收到了你是不是要应答一下人家,要不然人家以为你没收到,对吧。然后如果客户端收到应答,那是不是就可以进入连接状态了,但是服务器不知道客户端确定收到没收到啊,这时客户端也要发应答包,对吧。这时三次握手终于完成。
这里说一下,阻塞状态,就是没有等到条件的成立就不往下执行,在connect 和 accept两个函数都有阻塞的成分。
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状态。客户端收到了服务器的应答要给响应的,所以发送ACK应答。这是服务器也可以关闭了。
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 连接。
这种状态比较极端:是客户端和服务器端都发起了关闭连接的请求,就会出现closing状态:
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方 close 一个 SOCKET 后发送 FIN 报文给自己,你系统毫无疑问地会回应一个 ACK 报文给对方,此时则进入到 CLOSE_WAIT 状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close 这个 SOCKET,发送 FIN 报文给对方,也即关闭连接。所以你在 CLOSE_WAIT 状态下,需要完成的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送 FIN 报文后,最后等待对方的 ACK 报文。当收到 ACK 报文后,也即可以进入到 CLOSED 可用状态了。
文章中大部分来源于下面链接:http://blog.csdn.net/lianghe_work/article/details/46460463
相关文章推荐
- TCP 通信过程中各步骤的状态
- TCP 通信过程中各步骤的状态
- TCP 通信过程中各步骤的状态
- 简单socket通信过程(TCP)
- Linux网络编程10(2) -- TCP通信过程中的状态
- 对TCP协议通信过程中的TCP_NODELAY选项的通俗解释
- 一个简单的nagos插件脚本 , 监控 TCP 各状态的数量
- MyEclipse6.5整合flex实现与java简单通信过程中遇到的问题和注意事项
- TCP协议连接建立与连接断开过程(含断开时的TCP状态图)
- socket通信 端口状态的解释
- 一个简单的TCP通信的例子
- 简单的socket通信TCP
- java TCP 通信涉及类和执行过程
- linux下socket实现TCP通信的简单程序接口封装
- Linux中TCP连接过程状态简介
- 基于TCP Socket的简单网络通信
- TCP三次握手/四次挥手过程、状态详解
- TCP协议连接建立与连接断开过程(含断开时的TCP状态图)
- TCP三次握手过程与对应的Berkeley Socket APIs的简单介绍
- TCP/IP模型的一个简单解释