TCP状态转换图——简述11个状态

最新推荐文章于 2021-10-24 14:55:38 发布
最新推荐文章于 2021-10-24 14:55:38 发布
阅读量875 收藏
点赞数
分类专栏： 网络 文章标签： 网络协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_37657585/article/details/106715183
版权

1、TCP建立连接需要3次握手

首先，client端会发出一个SYN，server收到之后，会回复ACK，并同时发出一个SYN，client收到后连接就可以建立。三次握手保证了双发通讯正常。

这就和我们打电话一样：

张三：在吗？（向李四发出信息，等待李四响应）

李四：在。   （李四收到信息后，回复张三；到这里只能说明张三的消息，李四可以收到。所以要保证通讯畅通，李四需要向张三发出信息，等待张三回复。） 

张三：收到。 （这里张三回复收到，则意味着李四发出的信息，张三也可以收到。  这样才建立一个可靠的连接）

2、TCP连接断开需要四次挥手

图中的client、service只是为了描述一个连接关闭流程，实际上不管客户端还是服务端都可以主动关闭连接。

为什么需要四次挥手呢？

TCP是全双工通讯，当收到对方发来的FIN包，只意味着对方可以关闭连接了，自己可能还有数据要发送。所以FIN需要单独在发一次。

3、TCP状态转移图

Closed: 是初始状态

Listen：表示服务器的某个socket处于监听状态，可以接受连接

SYN_rcvd：表示收到了SYN报文，这是服务器的一个中间态、很短暂。

SYN_send：客户端发送SYN报文后，会变成这个状态，与SYN_rcvd对应。

Established：表明连接已经建立，这可以说是一个稳定态，使用netstat 可以观察到双方建立的连接。

Close_wait：正常来说，这应该也是一个中间态，它代表着四次挥手中收到对方发来的FIN，回复了ack，在向对方发送FIN之前，就是这个状态。  （很多时候我们会发现程序出问题时出现很多close_wait，这个状态出现就是由于在收到对方关闭连接后，自身未发出FIN包导致。大量的close_wait状态会导致HTTP请求无法响应，你的程序会宕掉，你需要检查一下你的代码了）

LAST_ack：这个状态是被动关闭的一方发送FIN后，等待四次握手中最后一个Ack(也就是主动关闭方发来的ack)之前的状态。

FIN_wait_1：这也是个中间态，基本看不到。当主动关闭方向对方发送FIN报文后，主动方便是FIN_wait_1状态。

FIN_wait_2：接着上面FIN_wait1说的，在主动关闭连接的一方发送FIN报文后，自身成为FIN_wait1，当收到对方的ACK时，变为FIN_wait_2。

TIME_wait：接受到对方的FIN，并回复了ack。此时等待2MSL（MSL为最长报文存活时间，可在操作系统中配置），连接即可关闭。这是一个正常态，存在请求时netstat即可看到。

closing：比较特殊，可能是双发同时关闭连接时会出现的状态。图中可以看到，之后会变为Time_wait，2MSL后连接随之关闭。

4、来看一个HTTP请求的抓包

浮生若梦，忙里偷闲， 使用tcpdump抓包来看看一次HTTP请求TCP连接的建立断开。

一个正常的HTTP请求抓包

tcpdump -i lo -n port 8080 -S

#tcpdump用法自己百度一下

 我们触发一次

15:58:19.333425 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [S], seq 4076194383, win 43690, options [mss 65495,sackOK,TS val 1559458260 ecr 0,nop,wscale 7], length 0
15:58:19.333436 IP 127.0.0.1.8080 > 127.0.0.1.49455: Flags [S.], seq 2069165181, ack 4076194384, win 43690, options [mss 65495,sackOK,TS val 1559458260 ecr 1559458260,nop,wscale 7], length 0
15:58:19.333448 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [.], ack 2069165182, win 342, options [nop,nop,TS val 1559458260 ecr 1559458260], length 0
15:58:19.333548 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [P.], seq 4076194384:4076195143, ack 2069165182, win 342, options [nop,nop,TS val 1559458260 ecr 1559458260], length 759
15:58:19.333562 IP 127.0.0.1.8080 > 127.0.0.1.49455: Flags [.], ack 4076195143, win 354, options [nop,nop,TS val 1559458260 ecr 1559458260], length 0
15:58:19.353547 IP 127.0.0.1.8080 > 127.0.0.1.49455: Flags [P.], seq 2069165182:2069165253, ack 4076195143, win 354, options [nop,nop,TS val 1559458280 ecr 1559458260], length 71
15:58:19.353557 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [.], ack 2069165253, win 342, options [nop,nop,TS val 1559458280 ecr 1559458280], length 0
15:58:19.353835 IP 127.0.0.1.8080 > 127.0.0.1.49455: Flags [P.], seq 2069165253:2069165340, ack 4076195143, win 354, options [nop,nop,TS val 1559458281 ecr 1559458280], length 87
15:58:19.353843 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [.], ack 2069165340, win 342, options [nop,nop,TS val 1559458281 ecr 1559458281], length 0
15:58:19.354004 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [F.], seq 4076195143, ack 2069165340, win 342, options [nop,nop,TS val 1559458281 ecr 1559458281], length 0
15:58:19.354228 IP 127.0.0.1.8080 > 127.0.0.1.49455: Flags [F.], seq 2069165340, ack 4076195144, win 354, options [nop,nop,TS val 1559458281 ecr 1559458281], length 0
15:58:19.354239 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [.], ack 2069165341, win 342, options [nop,nop,TS val 1559458281 ecr 1559458281], length 0

TCP Flag包含8个比特位，分别是：CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。

SYN：在建立连接时标记，三次握手中syn就是这个.

ACK：用来告诉对方数据包已收到，返回的数据中会将顺序号+1.

PSH：（push）表示需要将收到的包交给应用层.

FIN：表示自己已经没有数据要发送了，准备关闭连接.

看一下抓包数据，前三个包，就是三次握手建立连接的过程：第一个包Flags[S] 代表客户端发送的SYN，第二个包Flags[S.]代表服务端返回的ack和向客户端发出的SYN，第三个包Flags[.]是客户端回复的ack.至此三次握手完成，连接建立。

中间的包是请求和响应，来看最后三个包.就是四次挥手来关闭连接。

Flags[F.]代表主动关闭的一方没有数据发送了，向对方发送了FIN来关闭连接。倒数第二个包Flags[F.]表示被动一方回复ack，并且发出FIN表示也要关闭连接了（这里FIN与ack一起发可以理解为TCP自身的优化机制），最后一个包F[.]主动关闭一方回复ack，连接关闭。

再来分析一下Flags[P]包中数据的含义：

15:58:19.333548 IP 127.0.0.1.49455 > 127.0.0.1.8080: Flags [P.], seq 4076194384:4076195143, ack 2069165182, win 342, options [nop,nop,TS val 1559458260 ecr 1559458260], length 759

15:58:19.333548： 这个一看就是收到包时间了

127.0.0.1.49455 ：是发送方的IP和端口

127.0.0.1.8080 ：是服务端的IP和端口

Flags [P.]  ：P代表PSH标志位，表明改包需要推送到应用层，至于这里的.可以理解为一个占位符,不考虑。

seq 4076194384:4076195143 ： tcp报文的seq号， 4076194384是起始值，4076195143是结束值， 4076195143 -4076194384是发送报文长度。

ack 2069165182 ：tcp报文的ack号， ack 2069165182 表明标号2069165181报文已收到。下一个接收的seq号会从2069165182 开始。

win 342 ：表示tcp报文发送方作为接收方还可以接受的字节数，大于这个数，可能就处理不了了。

options [nop,nop,TS val 1559458260 ecr 1559458260]：这里nop是 no operation,可以不考虑；TS val 1559458260是报文的时间戳，这个值与系统时间无关，用来做seq值越界重新从0开始计算时，确认包顺序；ecr 1559458260 这个值用来计算RTT

length 759：这个值表示应用层传来数据的大小（不包括TCP header），与上面seq 4076194384:4076195143相减对应。

最后附上一个带完整数据的请求抓包（与上面抓包对应）

tcpdump -i lo -n port 8080 -SAl
15:56:45.608564 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [S], seq 3763193645, win 43690, options [mss 65495,sackOK,TS val 1559364535 ecr 0,nop,wscale 7], length 0
..............E..<..@.@.x............-.M.-.........0.........
\...........
15:56:45.608581 IP 127.0.0.1.8080 > 127.0.0.1.49075: Flags [S.], seq 3127397756, ack 3763193646, win 43690, options [mss 65495,sackOK,TS val 1559364535 ecr 1559364535,nop,wscale 7], length 0
..............E..<..@.@.<..........-...hM|.M.......0.........
\...\.......
15:56:45.608595 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [.], ack 3127397757, win 342, options [nop,nop,TS val 1559364535 ecr 1559364535], length 0
..............E..4..@.@.x&...........-.M...hM}...V.(.....
\...\...
15:56:45.608705 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [P.], seq 3763193646:3763194405, ack 3127397757, win 342, options [nop,nop,TS val 1559364535 ecr 1559364535], length 759
..............E..+..@.@.u............-.M...hM}...V. .....
\...\...GET /rest/ee7d191e/get?page=1&start=0&limit=15 HTTP/1.1
x-real-ip: 172.16.70.33
remote-host: 172.16.70.33
x-forwarded-for: 172.16.70.33
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
x-requested-with: XMLHttpRequest
accept: */*
referer: http://172.16.70.22/ui
accept-encoding: gzip, deflate
accept-language: zh-CN,zh;q=0.9
cookie: connect.sid=s%3AYbFf2HMeIBrYNw-GY7PH86N0uqRa4Uda.gCS1W0CXVkGAoJg52r7vBWeYvN0615vMSC%2F6aUuro0o
connection: close
user: administrator
sid: YbFf2HMeIBrYNw-GY7PH860uqRa4Uda
ip_address: 172.16.70.33
content-length: 2
Accept-Charset: utf-8
Host: localhost:8080

{}
15:56:45.608715 IP 127.0.0.1.8080 > 127.0.0.1.49075: Flags [.], ack 3763194405, win 354, options [nop,nop,TS val 1559364535 ecr 1559364535], length 0
..............E..4N.@.@............-...hM}.M.%...b.(.....
\...\...
15:56:45.718585 IP 127.0.0.1.8080 > 127.0.0.1.49075: Flags [P.], seq 3127397757:3127397828, ack 3763194405, win 354, options [nop,nop,TS val 1559364645 ecr 1559364535], length 71
..............E..{N.@.@............-...hM}.M.%...b.o.....
\..%\...HTTP/1.1 200 OK
Content-Type: application/json
content-length: 87


15:56:45.718595 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [.], ack 3127397828, win 342, options [nop,nop,TS val 1559364645 ecr 1559364645], length 0
..............E..4..@.@.x$...........-.M.%.hM....V.(.....
\..%\..%
15:56:45.718887 IP 127.0.0.1.8080 > 127.0.0.1.49075: Flags [P.], seq 3127397828:3127397915, ack 3763194405, win 354, options [nop,nop,TS val 1559364646 ecr 1559364645], length 87
..............E...N.@.@............-...hM..M.%...b.......
\..&\..%{"result":{"errorDesc":"Successfully","errorCode":0},"list":[],"totalCount":0}
15:56:45.718897 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [.], ack 3127397915, win 342, options [nop,nop,TS val 1559364646 ecr 1559364646], length 0
..............E..4..@.@.x#...........-.M.%.hN....V.(.....
\..&\..&
15:56:45.719429 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [F.], seq 3763194405, ack 3127397915, win 342, options [nop,nop,TS val 1559364646 ecr 1559364646], length 0
..............E..4..@.@.x"...........-.M.%.hN....V.(.....
\..&\..&
15:56:45.719717 IP 127.0.0.1.8080 > 127.0.0.1.49075: Flags [F.], seq 3127397915, ack 3763194406, win 354, options [nop,nop,TS val 1559364646 ecr 1559364646], length 0
..............E..4N.@.@............-...hN..M.&...b.(.....
\..&\..&
15:56:45.719732 IP 127.0.0.1.49075 > 127.0.0.1.8080: Flags [.], ack 3127397916, win 342, options [nop,nop,TS val 1559364646 ecr 1559364646], length 0
..............E..4..@.@.x!...........-.M.&.hN....V.(.....
\..&\..&

 

Sky、light rain
关注
专栏目录
计算机网络——TCP协议中的三次握手四次挥手以及11种状态转换
千里之行，始于足下
08-14 2万+
TCP的传输连接分为3个阶段：连接建立（三次握手）、数据传送和连接释放（四次挥手）。TCP传输连接的管理就是使传输连接的建立和释放都能正常地进行。
TCP/IP协议专栏——MAC地址详解——网络入门和工程维护必看
weixin_44081384的博客
08-24 7840
1、MAC 地址是硬件标识（Media Access Control Address）。6字节：48bit，3、通常用12位16进制数表示，每两个数之间用冒号隔开。如：00:D0:D0:C0:3F:A0就是一个MAC地址，前6位16进制数00:D0:D0代表网络硬件制造商的编号，由IEEE分配；后6位16进制数C0:3F:A0代表该制造商所制造的某个网络产品（如网卡）的系列号。每个网络制造商必须确保它所制造的每个以太网设备都具有相同的前六位以及不同的后六位。
TCP连接状态图，简单，明了，易懂，经典！！
08-25
TCP连接状态图，简单，明了，易懂，经典！！TCP 三次握手 四次挥手
TCP 状态图
是我
06-08 243
TCP状态图
jiangdewei2012的专栏
02-13 569
a
tcp状态图
mihi1978的专栏
12-17 638
涉及到winsock编程，先上张tcp状态图研究一下。
TCP/IP连接状态图
11-18 752
 需要说明的是:中文图和RFC并不一样,应该是中文书的问题 参见:http://www.rfc-editor.org/rfc/rfc793.txt 注意,图正中间的部份TCP/IP连接状态图 周一, 06/11/2007 - 13:31 — duran
【计算机网络】TCP/IP协议(DNS协议、IP协议、TCP协议、UDP协议、三次握手、四次挥手）
heyiyiya
05-15 1552
TCP/IP协议TCP/IP协议TCP/IP各层作用各种协议与HTTP协议的关系 TCP/IP协议 本文参考《图解HTTP》——上野宣 TCP/IP是Internet上所有网络和主机之间进行交流时所使用的共同“语言”，是Internet上使用的一组完整的标准网络连接协议。 TCP/IP协议，严格来说是一个协议族，里面包括很多协议（Telnet、HTTP、SMTP、TCP、UDP、IP、ARP等），由于TCP协议和IP是结构中最核心的协议，所以统称为TCP/IP协议。 TCP/IP协议族里重要的一点就
简述osi参考模型各层主要功能_简述OSI参考模型中各层的主要功能
weixin_39519619的博客
12-20 8259
简述OSI参考模型中各层的主要功能(2010-03-16 19:52:17)标签：杂谈分类：作业第一层 物理层 第二层 数据链路层 第三层 网络层 第四层 传输层 第五层 会话层 第六层 表示层 第七层 应用层其中高层，既7、6、5、4层定义了应用程序的功能，下面3层，既3、2、1层主要面向通过网络的端到端的数据流。下面我给大家介绍一下这7层的功能：(1)应用层：与其他计算机进行通讯的一个应用，它...
王道考研计算机网络学习心得——第一章-计算机网络体系结构
qq_55648035的博客
10-24 5532
​ 前言   本文主要是我学习计网的心得，用王道考研的原因主要是因为，又有老师教又有直接的资料书，个人觉得方便一点，不用到处找网课，也不用想到底看哪本书好，等这一轮学完了再看别的书，想必也能得心应手一点，希望能得到大家的指正，顺便监督自己学习，由于水平有限，引用部分大多采用书上的内容，如有侵权，就不公开了，就当作是自己的心得。 一、计算机网络概述   1.1计算机网络概念 计算机网络就是将一个分散的、具有独立功能的计算机系统，通过通信设备和线路连接起来，由功能完善的软件实现资源共享和信息传递的系统。简而言
TCP连接状态图解析
永无止境，上下求索
03-19 5131
TCP状态图，展示的是TCP从连接建立到连接关闭的整个生命周期， TCP的状态转换以及处理流程。TCP面向的是端口，Linux里面可以通过 netstat -a命令查看连接状态。笔者遇到Tomcat生成大量CLOSE_WAIT 状态的连接问题，故想了解一下TCP的连接机制。TCP状态图纵览TCP连接本质是点对点的，理论上无所谓服务器，客户端。不过总得有 一个进程等待在那里，对外提供连接的服务
TCP状态转换图
春秋繁露
08-20 664
注：主动、被动 与 服务器、客户端没有明确的对应关系。 这个图N多人都知道，它排除和定位网络或系统故障时大有帮助，但是怎样牢牢地将这张图刻在脑中呢？那么你就一定要对这张图的每一个状态，及转换的过程有深刻 的认识，不能只停留在一知半解之中。下面对这张图的11种状态详细解析一下，以便加强记忆！不过在这之前，先回顾一下TCP建立连接的三次握手过程，以及 关闭连接的四次握手过程。 1、建立连接
TCP三次握手四次挥手详解
dreamylive的专栏
08-28 425
转自：http://molewan.blog.51cto.com/287340/114592 1、建立连接协议（三次握手） （1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。 （2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行
TCP-IP详解:TCP的状态变迁图
热门推荐
深邃 精致 内涵 坚持
09-02 1万+
TCP的状态变迁图 一个连接从开始建立到断开，经历了一连串的状态变化，这次主要分析下它的状态变迁图，首先上经典的状态变迁图
TCP协议解析以及状态图详细分析
zhuoyue01的博客
05-11 672
TCP协议解析以及状态图详细分析 TCP数据报格式 与UDP协议一样TCP协议也有源端口号和目的端口号，通讯的双方由IP地址和端口号标识。32位序号、32位确认序号、窗口大小。4位首部长度和IP协议头类似，表示TCP协议头的长度，以4字节为单位，因此TCP协议头最长可以是4x15=60字节，如果没有选项字段，TCP协议头最短20字节。URG、ACK、PSH、RST、SYN、FIN是六个控制位。16位检验和将TCP协议头和数据都计算在内。紧急指针和各种选项的解释从略。 TCP协议 TCP状态转换 这个图N多
TCP状态转换
程序人生
09-17 2174
TCP状态转换图        TCP连接的建立与终止，以及在连接的不同阶段需要发送的各种类型的报文段，实质上都是由TCP所属的状态决定的。当前的状态会在各种触发条件下改变，状态转换规则可以概括为如下所示的TCP状态转换图：        TCP初始化时从CLOSED状态启动，通常根据是执行主动打开操作（客户端请求）还是被动打开操作（服务器接收请求），TCP将分别转换到SYN_SENT或L...
（四十七）网络——TCP状态转换图、滑动窗口、半连接状态、2MSL
FadeFarAway的博客
01-20 6595
一、tcp状态转换图　　下图对排除和定位网络或系统故障时大有帮助，也帮助我们更好的编写Linux程序，对嵌入式开发也有指导意义。 　　 　　先回顾一下TCP建立连接的三次握手过程，以及关闭连接的四次握手过程： 　　 1、建立连接协议（三次握手） （1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。 （2） 服务器端回应客户端的，这是三次握手中的第2个报文，这
【转载】TCP状态转换图详解
Lionel的专栏
03-31 3508
在前面，已经介绍了TCP协议的三路握手和四次挥手。如下图所示，TCP通信过程包括三个步骤：建立TCP连接通道（三次握手）、数据传输、断开TCP连接通道（四次挥手）。                      ...
TCP协议中的三次握手和四次挥手 状态图
phone1126的专栏
08-06 6229
建立TCP需要三次握手才能建立，而断开连接则需要四次握手。整个过程如下图所示： 1.jpg 先来看看如何建立连接的： 2.png 首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发送报文，并分配资源，这样TCP连接就建立了。 如何断开连接呢？简单的过程如下： 3.png...
TCP连接状态详解与转换图
TCP的状态转换图包含了11种不同的状态，这些状态反映了TCP连接从建立到结束的完整生命周期。 1. **LISTEN**：这是TCP连接的初始状态，服务器在特定端口上监听来自客户端的连接请求。 2. **SYN-SENT**：客户端在...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值