都在复习HCIA，那TCP和UDP这两个传输层协议绝对是不能绕开的重点，也是面试和笔试里最容易出题、最容易挖坑的部分。上次我把TCP的三次握手和四次挥手基础流程捋了一遍，这篇是“复习（2）”，重点往深了挖一层，专门针对那些平时看书容易一眼扫过、但考试和实际排障里却经常卡壳的细节，包括协议头部结构、可靠传输的核心机制、TCP与UDP的选型边界，以及一些我在真机上验证过的排查思路。
不管你是刚学完一轮准备刷题，还是已经在做实验、准备项目答辩，这篇内容都值得静下心来看完。我会把那些官方文档里写得比较生硬、不容易记牢的东西，用实际抓包和模拟场景的方式拆开讲，争取让你复习完之后，不光能对付选择题，遇到配置和排障，心里也有底。
1. 传输层复习的整体视角与认知框架
传输层在整个TCP/IP协议栈里算是承上启下的位置。上面是应用层，下面是网络层。网络层负责把数据包从一台设备送到另一台设备，但它是“尽力而为”的，丢包、乱序、重复都不管。传输层则是在两台主机上的应用程序之间建立通信管道，让应用不需要关心底层怎么跑的。这个思路是理解TCP和UDP一切区别的起点。
1.1 为什么复习时要先建立传输层的整体视角
复习的时候，最忌讳就是上来死记报文格式、记住各种标志位的含义，结果过两天全忘。我自己的经验是，先在心里搭一个框架：传输层解决两个核心问题，第一是进程寻址，第二是数据传输质量管理。
进程寻址靠的就是端口号。网络层用IP地址找到主机，但主机上同时跑着HTTP、SSH、DNS各种服务，数据到了主机之后交给谁，就得看端口号了。端口号范围是0-65535，其中0-1023是知名端口，一般分配给HTTP、FTP这种标准服务。1024-49151是注册端口，49152-65535是动态或私有端口，客户端发起连接时，源端口一般会从后面这个范围里随机选。HCIA考试里常拿这个范围划分来出题，像HTTP对应80，HTTPS对应443，DNS对应53，TFTP对应69，这个必须像背自己的生日一样熟。
数据传输质量管理，这是TCP的重头戏。TCP要解决丢包、乱序、重复、流量过大导致网络拥塞这些问题，于是设计了确认应答、序号机制、重传定时器、滑动窗口、拥塞控制一整套配合机制。复习的时候，最好把这些机制串成一条线：发送方发了数据，怎么知道对方收到了？靠ACK。如果超时没收到ACK怎么办？重传。为了减少等待时间，能不能一次发一批？这就是窗口。窗口开多大，既不能把接收方缓冲区塞爆，也不能把网络链路打满？这就是流量控制和拥塞控制分别要解决的问题。把这几个问题串起来，你会发现TCP整个协议的设计逻辑是环环相扣的，背书效率也高很多。
1.2 从HCIA考试大纲看TCP/UDP的考点分布
HCIA对传输层的考察，难度不算特别深，但它考得比较细。从历年真题和考纲趋势看，主要落在这么几个方向上：
- 传输层协议的基本作用与端口号分配
- TCP报文头部各字段的含义，特别是源端口、目的端口、序号、确认序号、窗口大小、标志位
- TCP三次握手与四次挥手的状态迁移过程
- TCP可靠传输的机制，包括确认、重传、序号的作用
- 流量控制与拥塞控制的基本原理
- UDP报文头部结构，以及它与TCP在应用场景上的选择
- 常见应用所依赖的传输层协议，比如HTTP走TCP、DNS通常走UDP但支持TCP、TFTP走UDP
说实话，考试并不要求你手写一个协议栈，但如果你能在脑子里面把一次HTTP访问从输入网址到页面加载全链路拆一遍，能说清楚每一步是靠TCP还是UDP、为什么要这么选，那HCIA这部分的题目对你来说就是送分。后面每讲一个机制，我都尽量往这个全链路里去套，帮你形成条件反射。
2. TCP协议头的关键细节：不仅是背字段，更要理解设计意图
很多教材把TCP报文头画一张大表，几十个字段堆在那里，看着就劝退。其实其中真正需要你深入理解的并不多，关键是抓住那些影响通信行为的字段，理解它们为什么存在。
2.1 核心字段逐个拆解与背诵技巧
TCP报文头最小长度是20字节，这点得记清楚。虽然有一个可选的选项字段可以让头部变长，但考试如果没有特别说明，说的就是20字节固定头部。这和UDP的8字节头部形成鲜明对比，也是TCP开销更高的一种表现。
先说源端口和目的端口，各占16位，也就是各2字节。它们的作用就是前面说的进程寻址。当你用浏览器访问某网站时，目的端口是80或443，源端口是操作系统随机分配的一个高位端口。同一个IP地址下可以同时跑成千上万个连接，就是靠不同的源端口区分开的。
序号字段和确认序号字段，各占32位。这两个字段是TCP可靠传输的灵魂。简单理解，序号表示本报文段中第一个数据字节的编号，确认序号表示期望收到对方下一个字节的序号，同时也表示在这个序号之前的数据都已经正确收到了。注意，确认序号有这个“之前都已经收到”的累积确认特性，这一点后面说滑动窗口的时候会用到。
头部长度字段占4位，单位是4字节，用来表示TCP头部的总长度。因为选项字段不是固定的，接收方必须知道头部到底有多长，才知道数据从哪里开始。这个字段最大能表示15个4字节，也就是60字节，所以选项部分最多40字节。
保留字段占6位，目前置为0。然后是6个标志位，这是考试的重灾区。URG表示紧急指针有效，ACK表示确认序号有效，PSH表示接收方应尽快将这个报文段交给应用层而不用等缓冲区填满，RST用来重置连接，SYN用来建立连接时同步序号，FIN用来释放连接。每一个标志位单独背含义不难，难的是组合场景。比如二次握手时SYN和ACK同时为1，说明这既是握手的第二个报文，又在确认对方的SYN。这四个字背后是协议状态机，需要在实验里看真实报文才能形成深刻记忆。
窗口大小字段占16位，用于流量控制。它表示发送方可以接收的最大字节数，其实就是接收方当前能接收的缓冲区余量。后面讲滑动窗口时会详细展开。校验和覆盖整个TCP报文段，包括头部、数据和伪头部，用于检测传输过程中是否出现比特错误。紧急指针只有在URG置位时才有效，占16位，表示紧急数据在报文段中的结束位置。
提示：背字段不用死记硬背，你自己用抓包软件看一次真实的三次握手报文的十六进制内容，对照字段表逐行解析一遍，比对着书念十遍都管用。后面第4节我会专门讲怎么看。
2.2 端口号分配策略与常见应用对照
端口号这一节知识比较零散，内容不多但确实爱考，主要是考查常见应用默认使用的端口号以及传输层协议类型。下面这个对照表相当实用，复习时可以常拿出来看一眼。
| 应用 | 端口号 | 传输层协议 | 说明 |
|---|---|---|---|
| FTP数据 | 20 | TCP | 主动模式下传输文件数据 |
| FTP控制 | 21 | TCP | 发送控制命令 |
| SSH | 22 | TCP | 安全远程管理 |
| Telnet | 23 | TCP | 明文远程管理，不加密 |
| SMTP | 25 | TCP | 发送电子邮件 |
| DNS | 53 | UDP/TCP | 一般查询用UDP，区域传送用TCP |
| DHCP | 67/68 | UDP | 67是服务器端口，68是客户端端口 |
| TFTP | 69 | UDP | 简单文件传输 |
| HTTP | 80 | TCP | 网页访问 |
| POP3 | 110 | TCP | 接收电子邮件 |
| SNMP | 161/162 | UDP | 网络管理 |
| HTTPS | 443 | TCP | 网页加密访问 |
我在实际做网络管理的时候，遇到过一个挺典型的案例。某客户端反馈内网访问文件服务器特别卡，结果排查半天发现有人把服务器上的FTP服务端口改成了8021，但客户端的连接请求还是发往21，自然一直被拒。这提醒我，端口号在应用层和传输层之间是一个约定，任何一层配错了，另一端很难自己感知出来，只能从抓包报文里去找端口的踪迹。
还有一个细节，DNS明明既支持UDP又支持TCP，为什么平时说它走UDP？因为普通DNS查询报文很小，一个UDP报文就能放得下，用UDP可以减少TCP握手和确认带来的额外往返时延，查询效率更高。但区域传送数据量大，要求可靠性，所以必须走TCP。这个场景对应试来说是个经典对比题目，建议专门记一下。
3. TCP可靠传输的核心机制：确认、重传、滑动窗口与拥塞控制
可靠传输这四个字听起来简单，但TCP在背后做的事情非常多。我在给学生讲这部分时，喜欢打一个比方：TCP的发送方和接收方就像两个快递仓库之间在传一批货物，网络本身可能丢失包裹、可能把包裹弄乱顺序、可能发得太多把链路堵住。TCP要做的，就是在这条不靠谱的“道路”上，设计出一套让双方都能确认“货已安全到达”的流程。
3.1 确认应答与超时重传：可靠传输的基石
TCP的每一个数据报文段都携带序号，接收方收到后，会回复一个ACK报文，确认序号的值为“期望收到的下一个字节的序号”。所以，如果发送方连续发送了字节序号1到1000的报文，接收方回复的确认序号就是1001，表示“我期待你下一个字节从1001开始，也就是1000及以前我都收到了”。收到ACK=1001，发送方就知道前面这批数据安全到达。
但网络链路并不完美。万一报文丢了，或者ACK丢了，发送方不可能一直干等，它启动一个定时器，超时时间到了还没收到对应的ACK，就重传这个报文段。这个定时器的时长确实有讲究，如果定得太短，网络稍微慢一点就会触发大量多余的重传，浪费带宽；定得太长，真正丢包时又恢复得太慢。早期的实现是固定算一个超时时间，后来考虑到网络状态是动态变化的，TCP引入了自适应算法，根据每一条连接的往返时延来动态调整超时时间。HCIA考试一般不会让你现场算超时公式，但需要你理解“超时时间不是固定的，而是跟网络拥塞程度相关”这个思路。
重传还有一种情况是连续收到多个相同ACK。TCP的接收方如果收到一个乱序的报文段，会立刻重传自己期望的那个序号的ACK。发送方连着收到3个同样的ACK，就能大概率判断某个报文段丢了，不用等超时，直接重传丢失的数据。这叫快速重传。用一句话记忆：超时重传是“没等到确认我重新发”，快速重传是“对方连着催我三次，我知道肯定丢了”。
3.2 滑动窗口与流量控制：数据量大小的博弈
如果发送方每发一个报文就停下来等ACK，效率太低，尤其在高带宽、高延迟的链路上会非常浪费。滑动窗口允许发送方在收到ACK之前连续发送多个报文段，窗口大小就是“未收到ACK还能继续发送的数据量上限”。
这个窗口大小并不是发送方自己定的，而是由接收方通过TCP头部的“窗口大小”字段告知的。接收方根据自己的接收缓冲区剩余空间来动态调整这个值，发送方必须遵守对方的窗口上限，否则就会把接收方的缓冲区撑爆，造成丢包。这个机制叫流量控制，目的是保护接收方。
我见过一个因为滑动窗口理解不透导致的真实案例。某公司内部视频点播平台偶尔卡顿，大家都以为是带宽不够。后来在核心交换机上抓包才发现，该服务器的TCP窗口大小被人为配置成了一个很小的固定值，导致发送方每次只能发很小一段数据就得等ACK，吞吐量严重受限。这就是典型的流量控制参数配置错误，虽然服务端、客户端链路都没问题，但传输效率被窗口值卡死了。如果你的网络环境带宽很充裕但传输速率一直上不去，别只盯着链路利用率，抓包看看TCP窗口大小是不是异常。
滑动窗口的“滑动”两个字也很形象。发送方维护一个发送窗口，窗口左边是已经收到ACK的分界，窗口右边是还没发送的数据。每收到一个累积ACK，窗口就向前滑动一段。累积确认的好处是，即使后面的ACK丢了，只要前面更大的确认序号到了，发送方就知道前面的数据都安全了，不需要逐段重传。
3.3 拥塞控制：保护网络不因发送太快而崩溃
流量控制考虑的是接收方的承受能力，拥塞控制考虑的是整条网络的承受能力。即使接收方缓冲区很大，发送方也不能无限制地猛发，否则网络中间的路由器、交换机可能因为处理不过来而大量丢包。
TCP拥塞控制由四个算法配合：慢启动、拥塞避免、快重传、快恢复。
连接建立初期，发送方不知道网络的容量是多少，不能一下就发一个大窗口。慢启动的做法是，拥塞窗口从1开始，每收到一个ACK，拥塞窗口就翻倍。1、2、4、8这样指数增长，迅速探测网络容量。但指数增长是不可持续的，达到慢启动门限值后，就转入拥塞避免阶段，拥塞窗口改为线性增长，每经过一个往返时延才增加1个MSS（最大报文段大小），增长温和得多。
当发生超时重传或者收到重复的ACK时，TCP认为网络可能出现了拥塞。超时是最严重的情况，TCP会把慢启动门限设置为当前拥塞窗口的一半，同时把拥塞窗口重置为1，重新开始慢启动。如果是收到3个重复ACK触发的快速重传，情况比超时要乐观一些，因为后续数据还能到达接收方，所以采用快恢复：门限减半，拥塞窗口从门限值开始，进入拥塞避免阶段线性增长。
复习到这里，可以自己问自己一个问题：如果TCP连接建立后，你立刻往对方发送大量数据，而网络链路的实际带宽很小，会发生什么？答案就是慢启动阶段会触发拥塞控制，让你发送窗口不断被压缩、反复重传，整体速率稳定在一个远低于你预期的水平。这在高带宽远程传输场景中很常见，解决办法不是一味调大TCP发送缓冲区，而是要看链路本身的带宽时延积，优化拥塞控制算法或者调整系统参数。
注意事项：在Windows系统上，如果你在内网传大文件且延迟很低，慢启动对速度的影响不太明显；但如果跨省跨运营商传输，RTT很高，慢启动和拥塞避免会明显拉低吞吐量。Linux下改拥塞控制算法为BBR，通常能带来立竿见影的效果。HCIA阶段不需要你深究BBR，但知道这个思路，做面试答“如何提升TCP传输效率”这类开放题时会更有底气。
4. UDP协议特性：无连接传输远比看起来要复杂
每次讲UDP，都有同学觉得“UDP太简单，不就是发出去就不管了吗”。从报文结构看，UDP确实只有8字节头部：源端口、目的端口、长度、校验和，各占16位，没有序号，没有确认，没有窗口，没有连接状态。但真正到应用选型和工程设计的时候，UDP的“简单”并不是“低端”，它背后是一套取舍逻辑。
4.1 UDP报文结构与无连接状态的本质
UDP头部中，源端口和目的端口的作用与TCP相同。长度字段指的是UDP头加数据的总长度，单位是字节，最小值为8，也就是不带任何数据、只有头部的情况。校验和字段用于校验UDP头部和数据在整个传输过程中的完整性。这里值得注意的一点是，UDP的校验和是可选的，IPv4下可以设为0，表示不校验；而TCP的校验和是强制必须计算的。这个“可选”的设计体现了UDP追求低开销的特点，但在IPv6环境下，UDP校验和变成了强制项，因为IPv6头部不再有校验和，必须依赖上层做差错检测。
无连接状态是什么意思呢？TCP的三次握手创建了连接，两边都维护着序号、窗口这些状态信息。UDP不干这些事，应用程序把数据扔给UDP，UDP封装好报文直接发出去，不收ACK，也不保证数据到达。从协议栈角度看，UDP不需要维护表项，所以开销低、处理快、时延低。这是UDP在实时性要求高的场景里备受青睐的根本原因。
但要注意，应用层并非完全不关心可靠性。UDP本身不可靠，但很多基于UDP的应用在应用层自己实现了可靠机制，比如游戏同步协议、某些自定义视频传输协议。所以“UDP不可靠”这句话，准确点说应该是“UDP协议本身不提供可靠性保障，但不代表上层应用不能自己加”。
4.2 实时音视频、DNS、游戏都想用UDP的原因
最常见的UDP应用是DNS查询。DNS请求和响应通常只有几十字节，一个报文往返就能完成，用TCP反而要额外增加两次握手和挥手开销。以“打开一个网页”为例，如果每次DNS解析都走TCP，那页面上每个域名解析都要多出好几倍的时延，页面加载速度让人无法忍受。所以在绝大多数情况下，DNS选择UDP，只有在特殊场景（区域传送、响应报文超过512字节被迫截断后重试）才转向TCP。
实时音视频通话和直播为什么也用UDP？因为这类应用对时延极其敏感，而对个别丢包相对宽容。你打一个网络电话，偶尔听丢几个字，耳朵可能根本感知不到；但如果网络拥塞导致数据排队、延后到达，通话体验反而断断续续。TCP为了保证可靠传输，遇到丢包会重传、会调整窗口，这些行为都会引入额外的延迟，在实时场景里是致命缺陷。UDP不管这些，发出去就是发出去，到不了就拉倒，把“及时性”放在“可靠性”前面。
游戏对战平台同样偏爱UDP。玩家的移动指令、射击命中判定，都是高频小数据包。一旦使用TCP，某个包丢了就要等重传，后续的数据都得排队，游戏画面就会出现“回跳”或者“瞬移”的现象。用UDP则可以让最新的状态包“干掉”旧的、滞后的包，玩家看到的位置始终是最新状态。
总结一个选型规律，做题和设计时都适用：如果应用允许一定的数据丢失，但丢不起时间，优先考虑UDP；如果应用绝对不允许数据缺失，比如文件传输、网页访问、邮件收发，必须用TCP。顺便说一句，HTTP/3的底层传输改用了QUIC，而QUIC是构建在UDP之上的，这也是为了减少连接建立的开销、避免TCP队头阻塞等问题。可见UDP在现代网络中正在扮演越来越重要的角色，别再用老眼光看它。
4.3 一个容易忽略的考点：UDP的广播与组播支持
TCP是面向连接的，只能实现单播，也就是一台主机和另一台主机之间的通信。UDP无连接，天然支持一对多、一对所有的通信模式。DHCP客户端一开始不知道DHCP服务器的IP地址，它只能通过UDP把请求发送到广播地址255.255.255.255，让网络里的DHCP服务器都能收到。组播应用，比如IPTV直播或者局域网内的设备发现、路由协议的邻居发现（如OSPF的组播地址224.0.0.5），也普遍采用UDP。
HCIA考试里，如果问“哪个传输层协议支持广播”，答案必然是UDP。因为广播和组播没有“建立连接”的概念，报文要发给多个接收者，每个接收者之间不可能各自维护一条连接。这个考点单独记一下，虽然简单，但容易在选择题里和TCP的特性混淆。
我自己练习时经常会做一个小实验：在一台主机上用Python写一个UDP socket，收包地址设为0.0.0.0，端口设为一个固定值；另一台主机向这个网段的广播地址发一段数据。只要网卡配置没问题、防火墙没拦，那条数据就能被收到。用Wireshark抓包，能看到目标MAC是全F、目标IP是255.255.255.255，就是标准的广播帧。要深刻理解UDP和广播的关系，这个实验5分钟就能做完，比看多少文档都直观。
5. 抓包分析实操：用Wireshark验证TCP三次握手与UDP收发
复习传输层协议，最忌讳就是只看字面意思。你背得出“SYN、SYN+ACK、ACK”，能默写报文结构，但不代表遇到真实环境你能看出问题。我强烈建议你打开抓包软件，亲眼看一次真实的握手、挥手和UDP通信过程。这一节我把操作步骤和关键观察点完整写下来，你照着做一遍，很多模糊的理解都会瞬间清晰。
5.1 抓包环境准备与一次完整的HTTP访问复现
准备环境很简单。一台电脑，安装Wireshark，能上网即可。如果你有网络设备模拟器，比如模拟华为设备的eNSP，也可以在里面做，但真实网卡抓包更直观。
步骤是这样的：
- 打开Wireshark，选择你正在使用的网卡接口，开始抓包。
- 打开浏览器，在地址栏输入一个需要走HTTP或HTTPS的网站地址。为了方便分析，最好找一个HTTP站点，因为能看到明文报文内容。
- 停止抓包，在显示过滤器里输入
tcp.port == 80或者直接用http过滤。 - 找到TCP连接建立的那一刻，也就是第一次出现SYN包的位置。
观察点主要有两个。第一，三次握手三个报文的标志位和序号变化。第一个包SYN置1，序号通常是一个随机值，这跟很多教材讲的“从0开始”不一样。第二个包SYN和ACK同时置1，序号是对方随机值加1，确认序号是对方序号加1。第三个包ACK置1，序号是前一个报文的确认序号值。第二个细节，每个报文头部的固定长度都是20字节，如果有选项字段，头部长度字段会显示大于5的值（因为头部长度字段单位是4字节，20字节就是5）。这个细节能帮你快速识别报文中是否带了时间戳、窗口缩放因子等TCP选项。
接着观察挥手过程。关闭浏览器标签页或关掉连接，抓包过滤器改为tcp.port == 80 && (tcp.flags.fin == 1 || tcp.flags.rst == 1)。正常情况下能看到四次挥手：一方发送FIN，另一方回复ACK，然后另一方也发送FIN，最初一方再回复ACK。注意HTTP连接中，如果请求头里有Connection: keep-alive，连接不会立即关闭，你要等超时或者直接关闭标签页才能捕获到FIN包。
5.2 通过抓包观察TCP重传与乱序
光看正常流程还不够，最好能亲眼看一下异常是怎么表现的。最简单的方法是人为制造丢包，比如在Windows或者Linux上用防火墙/网络管理工具丢包。另一个更轻量的方法是在真实网络环境里找一个弱网时段抓包，或者直接找一台信号很差的Wi-Fi设备做文件上传下载，很容易抓到重传包。
在Wireshark中，TCP重传包会显示为“TCP Retransmission”，快速重传会显示为“TCP Fast Retransmission”，重复ACK会显示为“TCP Dup ACK”。当你看到一个序号连续出现多次，且每次都被标记为重传时，就说明网络里确实存在乱序或丢包。此时可以进一步分析往返时延，把时间列显示选项调整为TCP RTT，就能看到每条TCP流的RTT走势。如果重传包总是出现在RTT突然变大的区域，很可能是链路出现了瞬时拥塞；如果重传一直周期性地出现，则可能是链路本身存在丢包，比如无线信道干扰。
排查此类问题时，我一般会先在Wireshark的统计菜单里选择“TCP流图”中的“时序图（Stevens）”，直观地看发送方和接收方的序号变化趋势。如果序号线在某一段出现了回退或者明显停顿，那一瞬间通常就是发生了重传或排队。这个图对分析“为什么文件传输这么慢”这类问题特别有效。
5.3 UDP通信抓包与广播/组播观察
UDP抓包不需要连接建立过程。你可以用命令行工具发送UDP报文。Windows下用PowerShell配合UDPClient发送，Linux直接用netcat命令echo "hello udp" | nc -u 192.168.1.100 9999，目标主机上用nc -ul 9999监听即可。
Wireshark过滤udp之后，能看到报文头部的四元组：源端口、目的端口、长度和校验和。UDP没有状态迁移，所以你能观察到的只有“发出去”和“收进来”两个动作，这也是理解无连接最直观的方式。如果把目的IP改成广播地址255.255.255.255，再抓一次包，就会发现Wireshark里“Info”列显示的正是“Broadcast”。目标MAC帧也会是全F。这个实验能帮你从数据链路层、网络层、传输层三个层面把广播机制串起来。
实操心得：抓包时如果发现UDP包的目标端口明明正确但应用收不到，大概率是防火墙拦截了。Windows下查看防火墙对UDP端口的放行规则不难，但对某些特定广播源IP的过滤会很隐蔽。有一次我调试局域网设备发现，某设备发的组播包其他主机都收不到，最终发现是交换机上开启了IGMP Snooping，且没有配置对应的组播组，交换机把组播流量截断了。这提醒我们，UDP通信问题排查到后面，往往已经不只是传输层的问题，需要往二层组播和交换机配置上扩展思路。
6. HCIA常见题型复盘与高频易错点整理
复习到这一步，知识点基本覆盖了。接下来要把知识转化为做题能力，或者说转化为面试答题能力。这部分我结合我带过的一些备考者普遍踩过的坑，整理一份高频易错点清单，每一条都点出“为什么错”“怎么记才对”。
6.1 三次握手与四次挥手的状态迁移易错点
三次握手的核心状态迁移，需要做到闭着眼睛都能背：客户端CLOSED到SYN_SENT，发送SYN；服务端LISTEN收到SYN，变成SYN_RCVD，回复SYN+ACK；客户端收到SYN+ACK，变ESTABLISHED，发送ACK；服务端收到ACK，变ESTABLISHED。注意，服务端ESTABLISHED状态的建立比客户端晚一个报文的时延。
四次挥手的状态迁移比三次握手更繁琐，也更值得刻进脑子里。主动关闭方发送FIN后进入FIN_WAIT_1；对方收到FIN，回复ACK，进入CLOSE_WAIT；主动关闭方收到ACK，进入FIN_WAIT_2。然后被动关闭方调用关闭操作发送FIN，进入LAST_ACK；主动关闭方收到FIN，回复ACK，进入TIME_WAIT，等待2MSL（最长报文段寿命的两倍）之后才真正CLOSED。被动关闭方收到最后的ACK后直接CLOSED。
TIME_WAIT这个状态非常容易出题。为什么主动关闭方收到最后的ACK后不能立刻进入CLOSED？原因有两个：一是确保最后一个ACK能被对方收到，如果ACK丢了，对方会重发FIN，主动方还有机会再回一次ACK；二是让本连接的所有迟到报文段在网络中自然消失，避免它们干扰后续使用相同四元组的新连接。2MSL就是给这些迟到报文“留够漂没时间”。
有些考生会把FIN_WAIT_2和CLOSE_WAIT搞混。用一句记忆口诀：谁主动关闭谁进FIN_WAIT，谁被动关闭谁进CLOSE_WAIT。CLOSE_WAIT其实是一个很容易积累的异常状态，实战中如果服务器上出现大量CLOSE_WAIT连接，多半是应用程序收到关闭请求后没有及时调用关闭函数释放资源，这个状态排查多了，你会形成条件反射。
6.2 滑动窗口、拥塞窗口与流量控制概念辨析
滑动窗口、拥塞窗口这两个概念，初学者最容易张冠李戴。考试中出题人经常挖的坑就是问“发送窗口的大小由谁决定”。正确答案是，发送方实际能发送的数据量取接收窗口和拥塞窗口的较小值。接收窗口是接收方通告的缓冲区余量，动态反映接收方的处理能力；拥塞窗口是发送方根据网络拥塞程度维护的一个上限，反映网络链路能承载的流量。
讲一个真实工作场景来帮助理解。某单位跨地市专线跑数据库同步，链路带宽是100M，但实际吞吐量始终只有30M左右。一开始以为是接收方服务器性能不足，后来抓包发现接收窗口始终在200KB以上，接收方根本不是瓶颈。再把拥塞控制相关参数调出来分析，才发现因为链路RTT较高，慢启动阶段窗口增长到一定程度后频繁触发拥塞避免，发送速率始终上不来。这说明比较大的接收窗口并不能保证传输速度快，网络本身的带宽时延积和拥塞控制算法共同决定了有效吞吐量。
HCIA考试里，流量控制和拥塞控制的场景题也很常见。比如“如果接收方的TCP窗口大小为0，发送方应该怎么做？”答案不是立刻停止发送，而是可以继续发送零窗口探测报文，定期检查接收窗口是否恢复。这个机制在真实网络中能避免双方死锁。另一个场景是“同步场景下两台设备直接相连，为什么大文件传输速率远低于网卡速率？”答案仍然要指向窗口和拥塞控制，而不是怀疑物理接口坏了。做题时一旦看到“吞吐量上不去”，优先往窗口和拥塞控制方向想。
6.3 UDP高频判断题与选择陷阱
UDP部分容易出现的不是复杂计算，而是判断题和概念题。最常见的陷阱有这么几种：
第一，看到“UDP不提供可靠性”，就直接认为“UDP数据一定会丢”。错。不提供可靠保障，不等于必然会丢包。在稳定的局域网里，UDP报文丢失率很低。但在不稳定的网络里，UDP不会自动恢复，丢没丢要靠应用自己发现。
第二，认为“UDP比TCP快”。这个说法不严谨。在会话很短、数据量很小的场景中，UDP少了连接建立和释放的往返开销，必然更快。但在大数据量可靠传输场景里，TCP可以通过滑动窗口并发捎带、累积确认等手段，在网络质量好的情况下达到接近链路上限的速度。UDP如果由应用层自己实现可靠传输，需要大量状态维护，代码性能和网络利用率不一定超过内核态的TCP实现。
第三，看到“DNS用UDP”，就认为DNS永远不用TCP。实际上DNS查询如果超过512字节且启用了EDNS0，响应超过限制就需要通过TCP重试，更别说区域传送默认走TCP。把DNS写成“仅使用UDP”，就是踩了命题人埋好的坑。
来一道典型选择题自测一下：TFTP和FTP传输文件的区别是什么？答案是FTP走TCP，提供可靠、面向连接的传输，适合大文件和需要断点续传的场景；TFTP走UDP，简单轻量但需要自行处理丢包重传，适合局域网内小文件传输，比如网络设备备份配置文件、PXE引导启动加载固件。把这两个名字放在一起，就是天然的对比例题。
7. 复习路线规划与一次全链路实验设计
知识零散和考点易错都梳理过了，剩下最关键的是把知识变成自己的肌肉记忆。我有几条实打实的建议，按这个路线走，复习效率会比单纯刷题好不少。
7.1 一周内有效的TCP/UDP复习时间表
如果距离考试还有一周，可以按下面的节奏安排：
- 第1天：把所有端口号、TCP头部字段、UDP头部结构整理成一张手写表，逐项过一遍。不需要死背，但要能默写字段和长度。
- 第2天：用Wireshark抓一次完整的HTTP访问，对照报文逐一标注三个握手报文、四个挥手报文的标志位和序号演变。
- 第3天：做一次TCP重传观察实验（弱网环境）和一次UDP广播实验，记录异常现象和排查命令。
- 第4天：集中做HCIA模拟题中的传输层题目，错题归类总结。
- 第5天：把三次握手、四次挥手、滑动窗口、拥塞控制用“讲给小白听”的方式，自己口述一遍，讲到卡壳的地方就是薄弱点。
- 第6天：去网络设备模拟器上配置两个设备之间TCP/UDP相关服务（比如telnet、DHCP、TFTP），观察现象。
- 第7天：完整做一遍全链路实验，梳理从应用层到传输层的数据封装与解封装流程，形成知识闭环。
这个时间表的前提是你已经跟过一轮基础课程，不是从零开始学。如果还处于刚接触HCIA的阶段，建议把时间拉长到两周，先看教材的TCP/UDP章节，再进入上面的日程。
7.2 从应用层到传输层的全链路数据封装实验
设计一个全链路实验，能一次性把HTTP、TCP、IP、以太网的知识串起来。具体步骤如下：
在一台PC上启动Wireshark抓包，浏览器访问一个HTTP网站。打开抓到的第一个HTTP请求报文，依次展开各层头部看一下。以太网头部有源MAC、目的MAC和类型字段，类型字段值0x0800表示上层是IPv4。IPv4头部有源IP、目的IP、协议字段，协议字段值为6表示上层是TCP，值为17表示UDP。TCP头部再往下看，就能看到源端口、目的端口、序号、确认序号、标志位等。如果之前你只是分别看过各层协议，这次可以完整看到“数据从应用层到链路层逐层封装”的过程。数据在每一层都被加上了这一层特有的控制信息，这个思路对理解整个协议栈至关重要。
我建议你用纸笔画一次这个封装图，把每一层的头部字段、当前层的名字、以及上下层的关系都标注出来。画完之后，你再去理解“MTU”“分片”“报文段”“数据报”这些术语，一瞬间就能分清。比如TCP叫“报文段”，UDP叫“数据报”，IP层叫“数据报/分组”，HDLC或者以太网帧才叫“帧”。不同教材术语可能略有出入，但大致对应关系必须清楚。
7.3 实验模拟器中TCP与UDP特性验证
如果你的网络环境里有eNSP或者CMR等模拟器，也可以在里面做实验验证。模拟器里看不到真实网卡抓包那么复杂的场景，但可以做协议级验证，比如在两台路由器之间配置OSPF，观察OSPF hello报文走的协议号（89）和IP组播地址，然后对比OSPF两台设备之间的TCP连接是否存在——其实OSPF压根就不建立TCP连接，它直接通过IP承载。这个对比能让你更清楚地体会“有些协议是直接封装在IP里的，不一定走TCP/UDP”。
再比如配置一个DHCP服务器和客户端，在客户端上抓包，能看到DHCP的四次交互过程。DHCP使用UDP，客户端源端口68，目的端口67；服务器源端口67，目的端口68。而且客户端在没有IP地址时，源IP地址是0.0.0.0，目的IP地址是255.255.255.255，这就是非常典型的无连接、无状态传输场景。你在模拟器里把这条链路抓包逐条看一遍，对UDP无连接特性的理解，绝对比背十遍教材都牢固。
注意：模拟器实验中抓包和真实环境有一定差异，某些超时重传、丢包现象在模拟器里很难复现，所以实验验证还要以真实网络为主，模拟器适合验证协议交互逻辑和配置命令。
8. 常见问题排查思路与故障案例复盘
知识学完，最后落到“会排查”这一步。下面这几个场景是我在实际工作中经常遇到的TCP/UDP问题，也是HCIA或者更高级别面试里喜欢拿来出情景题的方向。每个场景我都会给出排查路径和核心命令思路。
8.1 视频卡顿或下载慢：先看窗口还是先看丢包
遇到视频卡顿或者大文件下载慢，很多人的第一反应是看带宽占用率，甚至直接怀疑链路扩容。带宽占用率确实值得看，但它不能解释“为什么链路明明没跑满，速度却上不去”。这时候抓包分析是最有效的路径。
第一步看丢包率。在两端能互通的前提下，长时间ping对端地址，观察丢包率。如果丢包率大于0，说明链路本身有隐患，可能是无线干扰、光模块光衰、交换机端口错误计数增长。此时优先排查链路质量问题。第二步看TCP重传。用Wireshark对关键路径抓包，统计重传包的比例。如果重传率高，说明TCP层正在为丢包“买单”，吞吐量自然会大打折扣。第三步看窗口。如果丢包和重传都不严重，就要看接收窗口是否被填满，以及发送窗口是否在不停收缩。排查思路为从物理层到传输层逐层排除，和医院看病“先看生命体征、再看具体器官”是一个逻辑。
以我处理过的一次故障为例，某个远程办公室通过专线访问总部的OA系统，经常白屏。抓包发现TCP握手正常，但第一个HTTP响应报文之后，客户端连续回了三个重复ACK，随后服务端就出现了快速重传。进一步ping发现，专线上存在偶发性丢包，时间间隔没有规律。最后运营商排查发现对端交换机的光模块有间歇性故障，换了模块后立即恢复。如果当时只去调应用层超时时间，问题永远解决不了。
8.2 端口不通但ping得通：区分四层可达与三层可达
ping通只能说明网络层是通的，拥有相同三层连通性并不能保证TCP/UDP端口一定能通。原因很简单，端口号是传输层的概念，中间还有防火墙ACL、主机防火墙、服务进程本身是否在监听等多道关卡。
排查端口不通，按照下面的顺序走：
- 在内网直接访问目标IP和端口，尝试用Telnet测试TCP端口，比如telnet 192.168.1.10 80。如果显示连接被拒绝，看目标主机本身的服务是否监听在此端口和IP上。用netstat -ano（Windows）或者ss -lntp（Linux）确认。
- 如果端口在监听，但Telnet仍然失败，检查目标主机的防火墙规则和本机的防火墙规则。
- 如果主机防火墙没问题，继续沿着路径上每一台网络设备查看ACL是否放行了这个端口的流量。
- 最后再确认是否做了端口映射、NAT转换、负载均衡等，导致实际流量被转发到其他IP。
我见过最隐蔽的一次是某网站在IDC机房做了端口映射，外部访问443时被映射到后端某台Web服务器。后来运维人员在防火墙上新增了一条更高优先级的拒绝规则，优先级没有调好，导致443端口从源IP段看起来是“延时不通”，排查了大半天才找到。
UDP端口不通也有类似场景，但比TCP更隐蔽，因为TCP还有SYN/ACK这类反馈，UDP经常是“发出去没响应”。此时可以先确认目标进程有没有监听对应UDP端口，用ss -ulnp查看Linux，再用抓包确认请求包是否到达目标主机。如果包到了但应用没回包，问题十有八九是应用层逻辑或防攻击策略，比如有些网络设备对UDP Flood存在默认限速，流量稍大就会被悄悄丢弃。
8.3 TIME_WAIT与CLOSE_WAIT积累的排查技巧
服务器上时间长了，可能会积累大量的异常TCP状态。其中TIME_WAIT是正常现象，出现在主动关闭方收到对端FIN后，等待2MSL才能释放连接。大量TIME_WAIT多出现在高并发的Web服务器上，并不会直接导致故障，但它会占用一定数量连接表项。如果你发现TIME_WAIT特别多导致新连接无法建立，可以调整系统参数缩短TIME_WAIT超时，或者开启连接复用。更值得警惕的是CLOSE_WAIT堆积。CLOSE_WAIT是被动关闭方收到FIN并回复ACK后，应用层尚未主动关闭连接时的状态。正常情况下应很快被释放，如果大量积压，说明应用代码存在流没关、线程卡死等bug。对照之前Wireshark抓包看挥手过程，也能把这几个状态和实际行为对应起来。
遇到这些状态问题，我的经验是先用ss -ant或者netstat -ant统计当前连接状态分布，再看具体是哪个进程创建的连接。如果是Java应用出现大量CLOSE_WAIT，优先检查HTTP连接池和数据库连接池是否配置合理；如果是Nginx出现大量TIME_WAIT，通常不需要惊慌，调整keepalive参数和TIME_WAIT复用即可。关键判断标准不是“这些状态能不能存在”，而是“它们是否在长时间持续增长”。
9. 写在最后的实操建议
复习TCP/UDP，说到底是复习一种“网络思考方式”。HCIA的考题只是检验点，真正有价值的，是你拿到一个网络现象时，能不能先用传输层视角缩小问题范围，再逐层去定位根因。我在实际用这套思路处理过不少优先级很高的故障，尝到过甜头，所以掏心窝子建议你既要把协议状态机背得滚瓜烂熟，也要给自己创造动手抓包、动手配置、动手看状态的机会。
再分享一个小技巧：你可以把“三次握手、四次挥手、滑动窗口、拥塞控制、UDP广播”这五个主题分别写成一张A4纸上的流程图，每天睡前过一遍，卡壳的地方第二天立刻回到实验里去验证。坚持一周，这些内容就比你硬背一个月更扎实。祝复习顺利，考场上从容应对。
