零基础入门TCP运输连接管理与报文段首部格式:三报文握手建立连接原理、四报文挥手释放连接流程、保活计时器作用及TCP首部各字段功能全详解
对于计算机网络零基础的学习者来说,TCP 是运输层最核心的面向连接协议,而运输连接管理与报文段首部格式,是理解 TCP 可靠传输、流量控制等核心能力的基础。本文将系统拆解 TCP 连接建立、释放的完整流程,逐字段解析 TCP 报文段首部功能,搭配经典统考例题解析与汇总表格,帮助大家全面掌握核心考点。
一、TCP 运输连接基础知识点
TCP 是面向连接的协议,所有数据传输都基于已建立的运输连接完成,运输连接管理的核心目标是保障连接的建立与释放都能正常、可靠地执行。
-
TCP 运输连接的三个阶段

-
连接建立阶段:通过三报文握手完成,双方协商参数、分配资源
-
数据传送阶段:基于已建立的连接进行可靠的数据传输
-
连接释放阶段:通过四报文挥手完成,释放双方占用的资源
-
-
连接建立需要解决的三个核心问题

-
双方能够确知对方的存在
-
协商通信参数:包括最大窗口值、是否使用窗口扩大选项、时间戳选项、服务质量等
-
分配运输实体资源:包括缓存大小、连接表项目等硬件 / 软件资源
-
二、TCP 连接的建立:三报文握手

核心知识点罗列

-
角色与初始状态
-
主动发起连接的一方为TCP 客户,该行为称为主动打开连接
-
被动等待连接的一方为TCP 服务器,该行为称为被动打开连接
-
通信初始时,两端的 TCP 进程都处于 \\ 关闭(CLOSED)\\ 状态
-
-
握手前置准备 TCP 服务器进程首先创建传输控制块(TCB),存储 TCP 连接的关键信息(如连接表、发送 / 接收缓存指针、重传队列指针、当前收发序号等),之后进入 监听(LISTEN)状态,等待客户端的连接请求。
-
三报文握手完整流程(重点)

-
第一次报文:客户端发送连接请求 客户端创建 TCB 后,向服务器发送 TCP 连接请求报文段。报文首部同步标志位 SYN 置 1,序号字段 seq 设置为初始值 x(客户端自行选择的初始序号),发送后客户端进入 \\ 同步已发送(SYN-SENT)\\ 状态。
重点规则:SYN 置 1 的报文段不能携带数据,但必须消耗一个序号。
-
第二次报文:服务器发送连接确认 服务器收到连接请求后,若同意建立连接,向客户端发送连接请求确认报文段。报文首部SYN 和 ACK 都置 1,序号 seq 设置为初始值 y(服务器自行选择的初始序号),确认号 ack 设置为 x+1(对客户端初始序号的确认),发送后服务器进入 \\ 同步已接收(SYN-RCVD)\\ 状态。
重点规则:该报文同样 SYN 置 1,因此也不能携带数据,且消耗一个序号。
-
第三次报文:客户端发送普通确认 客户端收到连接确认后,向服务器发送普通 TCP 确认报文段。报文首部ACK 置 1,序号 seq 为 x+1(第一个报文消耗了一个序号),确认号 ack 为 y+1(对服务器初始序号的确认),发送后客户端进入 \\ 连接已建立(ESTABLISHED)\\ 状态。 服务器收到该确认报文后,也进入连接已建立状态,双方即可开始数据传输。
重点规则:普通的 ACK 确认报文段如果不携带数据,则不消耗序号,下一个数据报文的序号仍为 x+1。
-
-
为什么不能简化为两报文握手(重点) 采用三报文握手的核心目的,是防止失效的连接请求报文段突然传送到服务器,导致连接错误与资源浪费。
-
失效场景:客户端发出的连接请求在网络节点长时间滞留,触发超时重传;重传的请求成功到达服务器,双方完成连接、传输数据并释放连接。一段时间后,最初滞留的失效请求到达服务器。
-
两报文握手的问题:服务器收到失效请求后,会直接发送确认报文并进入连接已建立状态,一直等待客户端发送数据;但客户端并没有发起新连接,不会理会该确认,最终导致服务器资源白白浪费。
-
三报文握手的优势:客户端不会对失效的连接确认发送第三次确认报文,服务器收不到确认,就不会建立连接,从而避免了资源浪费。
-

经典例题解析(2011 年计算机统考真题)

-
解析:
-
连接请求确认报文的核心特征是SYN 和 ACK 同时置 1,因此可以直接排除 SYN、ACK 均为 0 的 A、D 选项。
-
确认号 ack 是对对方初始序号的确认,规则为对方序号 + 1,因此 ack = 11220 + 1 = 11221,该逻辑 B、C 选项均符合。
-
序号 seq 是服务器自身选择的初始序号,可任意指定,与客户端的初始序号无绑定关系。选项 C 中 seq=11221 是合法的初始序号,符合规则;选项 B 的 seq 与客户端初始序号重合,无规则依据,且本题正确选项为 C。
-
-
答案:C
三、TCP 连接的释放:四报文挥手

数据传输结束后,通信双方都可以主动发起连接释放,TCP 通过四报文挥手完成连接释放,确保双方数据都能完整传输。
核心知识点罗列
-
角色与初始状态
-
主动发起释放的一方执行主动关闭,被动响应的一方执行被动关闭
-
释放前双方都处于 \\ 连接已建立(ESTABLISHED)\\ 状态
-
-
四报文挥手完整流程(重点)
-
第一次报文:主动方发送释放请求 假设客户端为主动关闭方,客户端应用进程通知 TCP 释放连接,发送连接释放报文段。报文首部FIN 和 ACK 都置 1,序号 seq=u(等于客户端之前已传送数据最后一个字节的序号 + 1),确认号 ack=v(等于客户端之前已收到数据最后一个字节的序号 + 1),发送后客户端进入 \\ 终止等待 1(FIN-WAIT-1)\\ 状态。
重点规则:FIN 置 1 的报文段,即使不携带数据,也要消耗一个序号。
-
第二次报文:被动方发送普通确认 服务器收到释放请求后,发送普通确认报文段。报文首部ACK 置 1,序号 seq=v,确认号 ack=u+1,发送后服务器进入 \\ 关闭等待(CLOSE-WAIT)**状态。 客户端收到该确认后,进入**终止等待 2(FIN-WAIT-2)\\ 状态。
重点:此时客户端到服务器方向的连接已经释放,进入半关闭状态—— 客户端不再发送数据,但服务器如果还有未发送完的数据,客户端仍需要接收,该状态会持续一段时间。
-
第三次报文:被动方发送释放请求 当服务器应用进程没有数据要发送时,通知 TCP 释放连接,发送连接释放报文段。报文首部FIN 和 ACK 都置 1,序号 seq=w(半关闭期间服务器可能又发送了数据,因此序号更新为 w),确认号 ack 仍为 u+1,发送后服务器进入 \\ 最后确认(LAST-ACK)\\ 状态。
-
第四次报文:主动方发送普通确认 客户端收到服务器的释放报文后,发送普通确认报文段。报文首部ACK 置 1,序号 seq=u+1(第一个 FIN 报文消耗了一个序号),确认号 ack=w+1,发送后客户端进入 \\ 时间等待(TIME-WAIT)**状态。 服务器收到该确认报文后,立即进入**关闭(CLOSED)状态;而客户端需要经过2 倍 MSL(最长报文段寿命)\\ 的时间后,才会进入关闭状态。
-
-
TIME-WAIT 状态等待 2MSL 的意义(重点) MSL 即最长报文段寿命,RFC 793 标准建议为 2 分钟,实际网络中可根据情况使用更小的值。等待 2MSL 有两个核心作用:
-
保证最后一个确认报文能到达服务器,让服务器正常关闭 如果最后一个 ACK 确认报文丢失,服务器会超时重传 FIN 释放报文;若客户端直接关闭,就无法收到重传的 FIN 并回复确认,服务器会一直处于 LAST-ACK 状态无法关闭。2MSL 的时间足够让客户端收到重传的 FIN、重新发送确认,并重置计时器,确保服务器正常关闭。
-
确保本次连接的所有报文段都从网络中消失 经过 2MSL 后,本次连接持续时间内产生的所有报文段都会在网络中过期消失,不会出现在后续新的 TCP 连接中,避免旧报文干扰新连接。
-
-
保活计时器的作用 用于解决 TCP 连接建立后,客户端主机突然故障,服务器无法收到数据却一直等待、浪费资源的问题。

-
工作规则:
-
服务器每收到一次客户端的数据,就重新设置并启动保活计时器
-
若计时器超时(定时周期内未收到数据),服务器发送探测报文段,之后每隔 75 秒发送一次
-
若连续发送 10 个探测报文段都没有收到客户端响应,服务器判定客户端主机故障,主动关闭该连接
-
-

四、TCP 报文段的首部格式
TCP 报文段由首部和数据载荷两部分构成,TCP 的全部功能都通过首部各字段实现。TCP 首部分为 20 字节的固定首部,和最大 40 字节的选项扩展部分,首部总长度最大为 60 字节。

核心知识点罗列
-
固定首部核心字段(重点)
字段分类
字段名称
长度
核心功能与重点说明
端口字段
源端口
16 比特
填写源端口号,标识发送报文段的应用进程,是运输层分用的核心依据
目的端口
16 比特
填写目的端口号,标识接收报文段的应用进程,熟知端口对应标准应用层协议(如 HTTP 对应 80 端口)
序号相关
序号(seq)
32 比特
指出本报文段数据载荷第一个字节的序号;TCP 面向字节流,每个字节都有序号,取值范围 0~2³²-1,序号到最大值后循环回 0
确认号(ack)
32 比特
指出期望收到对方下一个报文段第一个字节的序号,同时是对之前所有收到数据的确认;确认号 = n,代表序号 n-1 及之前的所有数据都已正确接收。只有 ACK 标志位为 1 时,确认号才有效;连接建立后所有报文段 ACK 必须置 1
首部长度
数据偏移
4 比特
以 4 字节为单位,指示数据载荷起始位置距离报文段起始处的偏移,本质就是首部长度。最小值为 5(二进制 0101),对应 20 字节固定首部;最大值为 15(二进制 1111),对应 60 字节最大首部
保留位
保留字段
6 比特
预留用于未来功能扩展,当前必须置为 0
标志位(6 个)
URG(紧急位)
1 比特
置 1 时代表本报文段有紧急数据,紧急指针字段有效;紧急数据会优先发送、优先交付给应用进程,无需排队
ACK(确认位)
1 比特
置 1 时确认号字段有效;TCP 连接建立后,所有传输的报文段都必须将 ACK 置 1
PSH(推送位)
1 比特
置 1 时接收方收到报文后,会尽快将数据上交应用进程,不必等到接收缓存填满
RST(复位位)
1 比特
置 1 时代表 TCP 连接出现异常,必须释放连接后重新建立;也可用于拒绝非法报文段、拒绝打开连接
SYN(同步位)
1 比特
连接建立时用于同步序号;SYN=1 代表该报文是连接请求或连接请求确认报文
FIN(终止位)
1 比特
用于释放连接;FIN=1 代表发送方数据已发送完毕,要求释放连接
流量控制
窗口字段
16 比特
以字节为单位,指示发送本报文段一方的接收窗口大小,是接收方控制发送方发送速率的依据,实现流量控制。实际发送窗口大小,取接收窗口和拥塞窗口中的较小值
校验
校验和
16 比特
用于检验整个 TCP 报文段在传输过程中是否出错,计算校验和时需要在报文前添加 12 字节的伪首部
紧急数据
紧急指针
16 比特
以字节为单位,URG=1 时有效,用于指明本报文段中紧急数据的长度
-
选项与填充字段
-
选项部分最大 40 字节,用于扩展 TCP 功能,常见选项包括:
-
最大报文段长度(MSS):指定 TCP 报文段数据载荷的最大长度
-
窗口扩大选项:扩大窗口尺寸,提升网络吞吐率
-
时间戳选项:两个核心功能 —— 计算往返时间 RTT、防止序号绕回(处理序号超范围的情况)
-
选择确认选项:实现选择确认功能,提升重传效率
-
-
填充字段:因为数据偏移以 4 字节为单位,首部总长度必须是 4 字节的整数倍。如果选项长度 + 20 字节固定首部的长度不能被 4 整除,就用填充字段补 0 进行对齐。
-

五、核心知识点汇总表格
表 1:三报文握手过程汇总
|
报文顺序 |
发送方 |
核心标志位 |
序号 seq |
确认号 ack |
发送后状态 |
关键规则 |
|
1(连接请求) |
客户端 |
SYN=1 |
x(客户端初始序号) |
- |
SYN-SENT |
SYN=1 报文不可携带数据,消耗 1 个序号 |
|
2(连接确认) |
服务器 |
SYN=1, ACK=1 |
y(服务器初始序号) |
x+1 |
SYN-RCVD |
SYN=1 报文不可携带数据,消耗 1 个序号 |
|
3(普通确认) |
客户端 |
ACK=1 |
x+1 |
y+1 |
ESTABLISHED |
无数据则不消耗序号;服务器收到后也进入 ESTABLISHED |
表 2:四报文挥手过程汇总
|
报文顺序 |
发送方 |
核心标志位 |
序号 seq |
确认号 ack |
发送后状态 |
关键规则 |
|
1(释放请求) |
主动方 |
FIN=1, ACK=1 |
u |
v |
FIN-WAIT-1 |
FIN=1 报文即使无数据也消耗 1 个序号 |
|
2(普通确认) |
被动方 |
ACK=1 |
v |
u+1 |
CLOSE-WAIT |
主动方收到后进入 FIN-WAIT-2;连接进入半关闭状态 |
|
3(释放请求) |
被动方 |
FIN=1, ACK=1 |
w |
u+1 |
LAST-ACK |
半关闭期间被动方可能发送新数据,序号更新为 w |
|
4(普通确认) |
主动方 |
ACK=1 |
u+1 |
w+1 |
TIME-WAIT |
被动方收到后立即关闭;主动方需等待 2MSL 后才关闭 |
表 3:TCP 首部标志位功能汇总
|
标志位 |
名称 |
置 1 的含义 |
核心使用场景 |
|
URG |
紧急位 |
紧急指针有效,存在紧急数据 |
高优先级数据插队传输,如远程控制中断信号 |
|
ACK |
确认位 |
确认号字段有效 |
连接建立后所有报文都必须置 1 |
|
PSH |
推送位 |
接收方尽快向上交付数据 |
交互式应用,如命令行、实时聊天 |
|
RST |
复位位 |
连接异常,需要重置连接 |
连接出错恢复、拒绝非法连接请求 |
|
SYN |
同步位 |
连接建立时同步序号 |
三报文握手的前两个报文 |
|
FIN |
终止位 |
发送方数据发送完毕,请求释放连接 |
四报文挥手的第一、第三个报文 |
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐

所有评论(0)