个人主页Cx330❄️个人专栏《C语言》《LeetCode刷题集》《数据结构-初阶》《C知识分享》《优选算法指南-必刷经典100题》《Linux操作系统》:从入门到入魔《Git深度解析》:版本管理实战全解 《Qt 极境架构》MySQL 核心技术与实战心向往之行必能Cx330的简介目录前言一. TCP 核心知识点回顾二. TCP 发送数据的两种工作模式2.1 串行发送模式停等协议2.2 并行发送模式流水线模式三. 序号与确认序号的深度解析3.1 序号的本质3.2 确认序号的定义3.3 序号的三大核心功能3.4 为什么需要同时有序号和确认序号四. 16 位窗口大小与流量控制4.2 流量控制的工作流程4.3 窗口探测机制五. 标志位字段详解5.1 ACK 标志确认标志5.2 SYN 标志同步标志5.3 FIN 标志结束标志六. TCP 连接管理机制6.1 三次握手建立连接6.2 四次挥手断开连接七. 核心面试题深度解析7.1 为什么断开连接是“四次挥手”结尾前言在上一篇文章中我们初步探讨了 TCP 协议的基本概念以及 TCP 报文头部格式。作为传输层最核心的协议之一TCPTransmission Control Protocol传输控制协议之所以能在复杂、不可靠的网络环境中提供可靠、有序、面向连接的字节流服务依赖于其内部一套严密精细的机制设计。本文将顺着上一篇的脉络深入剖析 TCP 的数据传输模式、序号与确认序号的底层逻辑、滑动窗口与流量控制以及经典的“三次握手”与“四次挥手”连接管理机制。一. TCP 核心知识点回顾在深入细节前我们先简要回顾 TCP 的四大核心特性面向连接Connection-Oriented在发送数据前通信双方必须先建立逻辑连接三次握手。可靠传输Reliability通过校验和、序号、确认应答ACK、超时重传等机制保证数据无差错、不丢失、不重复、按序到达。面向字节流Byte Stream Stream-OrientedTCP 不保留记录边界数据以字节为单位组织成流由 TCP 根据缓冲区情况自行分段发送。全双工通信Full-Duplex建立连接后通信双方可以同时进行数据的发送与接收。TCP 通信双方交换的是完整的 TCP 报文即使是单纯的应答也至少包含一个完整的 TCP 报头不会只发送单独的标志位。可靠性的本质不是 “必须送达”而是 “无论发送成功还是失败发送方都能知道结果”。收到应答表示成功超时未收到应答则判定为失败并重传。TCP 是全双工协议通信双方可以同时发送和接收数据这一特性深刻影响了 TCP 的很多设计包括捎带应答、三次握手等。​接下来我们将重点解构 TCP 是如何将这些特性落到实处的。二. TCP 发送数据的两种工作模式网络传输的效率与可靠性之间始终存在权衡。TCP 在演进过程中经历了从“单件发送”到“流水线发送”的技术跨越。2.1 串行发送模式停等协议停等协议Stop-and-Wait Protocol是最基础的传输模式。工作机制发送方每发送一个数据报文段Segment就必须暂停发送等待接收方的确认应答ACK。只有收到 ACK 后才继续发送下一个报文段若超时未收到 ACK则触发重传。优缺点分析优点逻辑极简对接收方缓冲区要求低。缺点信道利用率极低。设往返时间为 RTT数据传输时间为 Td则信道利用率为​在高延时或高带宽网络高长管道网络中绝大部分时间信道都处于空闲状态吞吐量极差。发送方 接收方 |---- 数据包 1 ----------| |--- ACK 1 --------------| 必须等待 ACK 到达才发下一个 |---- 数据包 2 ----------| |--- ACK 2 --------------|2.2 并行发送模式流水线模式为了充分利用网络带宽TCP 采用了流水线模式Pipelining即滑动窗口机制Sliding Window的前身。工作机制发送方允许在未收到确认的情况下连续发送多个报文段只要总数据量不超过允许的窗口大小。核心优势极大地填补了 RTT 期间的等待空白使网络链路保持满载运行大幅提升了传输吞吐量。实现前提必须引入更加精密的序号Sequence Number与确认序号Acknowledgment Number管理系统以及相应的缓存重传策略。发送方 接收方 |---- 数据包 1 ----------| |---- 数据包 2 ----------| |---- 数据包 3 ----------| |--- ACK 1 --------------| |--- ACK 2 --------------| |--- ACK 3 --------------|​三. 序号与确认序号的深度解析在 TCP 头部中32 位序号Seq与 32 位确认序号Ack是实现可靠传输和顺序控制的关键。3.1 序号的本质字节级编号TCP 是面向字节流的协议。建立连接后传输的每一个字节都会被分配一个递增的整型序号。报文段中的 SeqTCP 报文头部的Seq字段指代的并不是“第几个数据包”而是该报文段所携带数据的第一个字节的序号。示例若某个 TCP 报文段携带了第 1001 - 2000 字节的数据则该报文段的Seq为 1001。初始序号 ISNInitial Sequence Number连接建立时双方会随机生成一个初始序号 ISN而非固定从 0 开始防止历史失效报文在后来的连接中造成数据混淆同时防御 TCP 序列号预测攻击TCP Sequence Prediction Attack。3.2 确认序号的定义累计确认机制Cumulative AcknowledgmentTCP 的Ack字段表示期望下一次收到的字节序号。语义内涵若接收方回复Ack N意味着序号在N-1及之前的全部字节数据均已成功接收且校验无误。示例若接收方成功收到 1001 - 2000 字节则回复的确认报文中Ack 2001重要特性累积确认如果主机 B 收到了 1~1000 和 2001~3000 字节但没有收到 1001~2000 字节它只会回复确认序号 1001而不会确认 2001~3000 字节。这保证了 TCP数据的按序交付。3.3 序号的三大核心功能序号机制解决了并行发送带来的所有问题按序重组Reordering由于 IP 网路是无连接的数据包可能经过不同路径到达导致乱序。接收方根据Seq对乱序报文进行重新排序保证向上层交付有序字节流。去重处理De-duplication若发生超时重传接收方可能收到重复数据包。通过对比Seq接收方可轻松识别并丢弃已存在的重复字节避免数据污染。丢包识别与重传Loss Detection通过检查Ack是否连续接收方可以及时发现缺漏的字节段如乱序到达或中途丢包从而触发快速重传Fast Retransmit或超时重传Timeout Retransmit。3.4 为什么需要同时有序号和确认序号看似“序号”和“确认序号”功能重叠但两者同时存在是 TCP 实现全双工通信Full-Duplex的必要条件捎带应答当主机 B 需要给主机 A 发送数据时它可以把对主机 A 之前数据的 ACK 应答“搭顺风车” 放在自己的数据报文中一起发送。这样可以减少网络报文的数量提高效率。例如主机 A 给主机 B 发送数据序号 1~1000主机 B 正好有数据要发给主机 A它可以在自己的数据报文中同时设置确认序号 1001 和自己的序号比如 5001~6000这种情况下一个报文既是数据报文又是应答报文必须同时包含序号自己发送数据的序号和确认序号对对方数据的确认。四. 16 位窗口大小与流量控制即使网络带宽足够大发送方也不能无限制地发送数据因为接收方的处理能力是有限的。如果发送方发送太快导致接收方的接收缓冲区被填满后续的数据会被直接丢弃造成不必要的网络资源浪费。为了解决这个问题TCP 引入了流量控制机制而 16 位窗口大小字段就是流量控制的核心。窗口大小字段表示接收方当前接收缓冲区的剩余空间大小单位是字节。接收方在发送 ACK 应答时会将自己接收缓冲区的剩余空间大小填入窗口大小字段告诉发送方自己还能接收多少数据。发送方根据这个值调整自己的发送速度窗口大接收方处理能力强发送方可以加快发送速度窗口小接收方处理能力弱发送方需要减慢发送速度窗口为 0接收方缓冲区已满发送方必须停止发送数据4.2 流量控制的工作流程流量控制的核心是依据接收方的处理能力动态调整发送方的发送窗口大小Advertised Window初始阶段双方协商初始窗口大小。数据传输与消耗发送方连续发送数据接收方将数据放入接收缓冲区上层应用逐步从中读取。缓冲区吃紧若上层读取变慢接收缓冲区逐渐填满接收方在 ACK 中将Window Size调小例如从 4090 减至 1000。发送方减速发送方收到 ACK 后缩小自己的发送窗口减少一次性投递的数据量。零窗口Zero Window若接收缓冲区全满接收方将返回Window Size 0。此时发送方必须暂停发送任何非探测数据。主机A发送方 主机B接收方缓冲区大小8192字节 | | |---- 数据1~1000 ----| 缓冲区剩余7192字节 | | |-- ACK(1001, 7192)-| 告诉A还能接收7192字节 | | |-- 数据1001~5000 --| 缓冲区剩余3192字节 | | |-- ACK(5001, 3192)-| 告诉A还能接收3192字节 | | |-- 数据5001~8192 --| 缓冲区剩余0字节 | | |--- ACK(8193, 0) --| 告诉A停止发送 | | | | 应用层读取了4096字节缓冲区剩余4096字节 | | |-- ACK(8193, 4096)-| 窗口更新告诉A可以继续发送 | | |- 数据8193~12288 --|4.3 窗口探测机制当连接陷入“零窗口”状态后若接收方上层应用读取了数据、腾出了缓冲区接收方会发送一个Window Size 0的更新通知。但如果这个更新通知报文在网络中丢失了双方就会陷入死锁Deadlock发送方在等窗口更新接收方在等新数据。为解决死锁问题TCP 引入了窗口探测机制Window Probe零窗口定时器Persist Timer当发送方收到零窗口通知时启动 Persist 定时器。窗口探测包Zero Window Probe, ZWP定时器超时后发送方会强制发送一个仅包含 1 字节数据的“窗口探测报文”。强制回应接收方收到探测包后必须回复当前的 ACK 及最新的Window Size。若窗口仍为 0发送方重置定时器并以指数退避原则继续探测若窗口大于 0则死锁解除恢复正常传输。五. 标志位字段详解TCP 头部包含了 6 个控制标志位Control Bits/Flags用于指示当前报文段的性质与功能。以下重点介绍最关键的三个标志位我们先来看 Linux 内核中tcphdr结构体中标志位的定义位于include/linux/tcp.hstruct tcphdr { __be16 source; __be16 dest; __be32 seq; __be32 ack_seq; #if defined(__LITTLE_ENDIAN_BITFIELD) __u16 res1:4, // 保留位4位 doff:4, // 4位首部长度 fin:1, // FIN标志关闭连接 syn:1, // SYN标志建立连接 rst:1, // RST标志重置连接 psh:1, // PSH标志推送数据 ack:1, // ACK标志确认号有效 urg:1, // URG标志紧急指针有效 ece:1, // ECE标志显式拥塞通知回显 cwr:1; // CWR标志拥塞窗口减小 #elif defined(__BIG_ENDIAN_BITFIELD) __u16 doff:4, res1:4, cwr:1, ece:1, urg:1, ack:1, psh:1, rst:1, syn:1, fin:1; #else #error Adjust your asm/byteorder.h defines #endif __be16 window; __sum16 check; __be16 urg_ptr; };可以看到每个标志位只占 1 个比特位这是 C 语言位段特性的典型应用。下面我们重点讲解三个最核心的标志位5.1 ACK 标志确认标志作用表示确认序号字段是否有效。使用场景除了最初的 SYN 报文所有 TCP 报文的 ACK 标志都应该置 1。含义当 ACK1 时表示这个报文包含对之前收到数据的确认。5.2 SYN 标志同步标志定义当SYN 1时表明这是一个连接请求或连接接受报文用于在建立连接时同步双方的初始序列号ISN。重要规则SYN 1, ACK 0表示发起一个新连接的请求第一步SYN 1, ACK 1表示同意建立连接并同步自身 ISN第二步。包含SYN标志的报文即使不携带数据也会消耗 1 个序列号。5.3 FIN 标志结束标志定义当FIN 1时表明发送方已经没有数据要发送了请求释放/关闭当前单向连接。重要规则发送FIN并不意味着立刻不能接收数据仅代表本方不再发送数据。同SYN一样FIN报文段即使不携带实际数据也会消耗 1 个序列号。其他三个标志位的作用URG紧急指针有效表示报文中有紧急数据PSH提示接收端立即将数据从 TCP 缓冲区推送给应用层RST强制重置连接用于处理异常情况六. TCP 连接管理机制TCP 是面向连接的协议必须在传输数据前“建立连接”在传输结束后“释放连接”。这就是著名的“三次握手”与“四次挥手”。6.1 三次握手建立连接三次握手Three-way Handshake的目标是同步双方的初始序列号ISN确认双方的收发能力正常并协商 MSS、窗口扩大因子等选项。Client (客户端) Server (服务端) | | [LISTEN] |--- 1. SYN1, Seqx -------------------------| (SYN_SENT - SYN_RCVD) |-- 2. SYN1, ACK1, Seqy, Ackx1 ----------| | [ESTABLISHED] | |--- 3. ACK1, Seqx1, Acky1 --------------| [ESTABLISHED]第一次握手 (SYN)客户端向服务端发送连接请求段SYN 1随机生成初始序号 Seq x。客户端进入SYN_SENT状态。第二次握手 (SYN-ACK)服务端收到请求同意连接。回复报文SYN 1, ACK 1确认序号 Ack x 1同时生成自己的初始序号 Seq y。服务端进入SYN_RCVD状态。第三次握手 (ACK)客户端收到 SYN-ACK回复确认段ACK 1确认序号 Ack y 1自己的序号 Seq x 1。客户端进入ESTABLISHED状态。服务端收到此 ACK 后也进入ESTABLISHED状态。此时连接建立完毕。为什么是三次握手面试高频考点这是 TCP 连接管理中最经典的面试题核心原因有两个三次握手是验证全双工通信的最小次数。如果只有两次握手服务器无法确认客户端是否能接收数据。三次握手完成了双方意愿的确认。如果只有两次握手服务器无法确认客户端是否收到了自己的同意报文。三次握手的状态转换深度思考为什么不是两次握手防止已失效的连接请求报文突然传到服务端若只有两次握手若客户端发出的第一个 SYN 在网络中滞留客户端超时重传并建立连接后关闭。过了一会儿滞留的 SYN 到达服务端服务端直接回应并建立连接造成服务端资源浪费半打开连接。确认双方的双向收发能力1次握手双方都无法确认任何事2次握手服务端确认了客户端“能发”客户端确认了服务端“能收能发”但服务端无法确认客户端“能收”3次握手双方均确认了对方“既能收又能发”。6.2 四次挥手断开连接由于 TCP 是全双工通信每个方向的连接都需要单独关闭因此断开连接需要四个步骤Four-way Wave。任何一方通常是客户端均可发起主动关闭。Client (主动关闭方) Server (被动关闭方) | | [ESTABLISHED] |--- 1. FIN1, Sequ -------------------------| (FIN_WAIT_1 - CLOSE_WAIT) |-- 2. ACK1, Seqv, Acku1 -----------------| (FIN_WAIT_2) | | 服务端处理完剩余数据 |-- 3. FIN1, ACK1, Seqw, Acku1 ----------| (LAST_ACK) |--- 4. ACK1, Sequ1, Ackw1 --------------| (TIME_WAIT - CLOSED) | (等待 2MSL 后彻底关闭) | [CLOSED]为什么是四次挥手建立连接时服务器的 SYN 和 ACK 可以合并在一个报文中发送捎带应答但断开连接时不能合并原因是重点解析TIME_WAIT 状态与 2MSL 的必要性MSLMaximum Segment Lifetime报文段在网络中的最大生存时间通常为 30s ~ 2min。等待 2MSL 的两大核心原因保证最后的 ACK 报文可靠到达若第 4 次挥手的 ACK 丢失服务端会重传第 3 次挥手的 FIN。客户端在 2 * MSL 时间内可以接收到重传的 FIN 并重新发送 ACK。清空网络中的“残余报文”经过 2 * MSL去程 回程的最大时间本次连接在网络中产生的所有旧报文段都会自然消亡避免影响后续建立的新连接。七. 核心面试题深度解析在面试与实际工程排查中TCP 断开连接的“四次挥手”是极高频的考点。以下重点剖析两个最核心的延伸问题7.1 为什么断开连接是“四次挥手”建立连接时是“三次握手”为什么关闭连接却需要“四次挥手”对比总结 握手时服务端的SYN连接请求和ACK确认请求可以合并在一起发送即第二次握手。而挥手时由于服务端收到FIN时无法保证数据已经全部发送完毕因此确认关闭ACK与发起反向关闭FIN通常必须分步进行这就导致了四次挥手。结尾在本篇文章中我们系统性地剖析了 TCP 协议的数据传输模式、序号/确认序号机制、基于滑动窗口的流量控制、关键标志位含义、连接管理三次握手与四次挥手以及极具实战意义的面试核心衍生考点。TCP 协议通过这些精心设计的机制在不可靠的 IP 网络之上构建起了稳如磐石的可靠传输通道。然而网络传输不仅仅面临接收方缓冲区的限制还会面临网络路径本身的拥塞问题。回顾全文可以把 TCP 的可靠传输机制串成一条清晰的主线传输效率从停等协议到流水线模式解决了如何充分利用网络带宽的问题。可靠保证通过序号与确认序号实现按序交付、去重和丢包重传。流量控制借助 16 位窗口大小让发送方根据接收方的处理能力动态调整发送节奏。连接管理通过三次握手建立全双工连接通过四次挥手优雅释放两个方向的传输通道。对于准备面试的同学建议重点掌握以下几条为什么需要三次握手两次握手会带来什么问题。为什么断开连接需要四次挥手而不能把 ACK 和 FIN 合并发送。TIME_WAIT 状态为什么要等待 2MSL。TCP 如何通过窗口大小实现流量控制零窗口死锁如何解决。序号和确认序号分别解决乱序、重复和丢包问题的底层逻辑。最后TCP 的可靠性体系还有一个重要拼图那就是拥塞控制。流量控制关注的是接收方的处理能力而拥塞控制关注的是整个网络路径的承载能力。慢启动、拥塞避免、快重传和快恢复等机制将是下一篇文章继续深入探讨的重点。如果本文对你理解 TCP 的核心机制有帮助欢迎点赞、收藏和关注也欢迎在评论区一起交流你在面试或工程实践中遇到的 TCP 问题。