很多同学复习到计算机网络传输层这一章，都会有一种奇特的挫败感：概念都认识，流程图也看过，可一到做题，面对那些带序号、确认号、窗口、重传的题目，还是不知道怎么下笔。我当年也这样，甚至第一遍学完连"三次握手为什么是三次而不是两次"都讲不清楚。后来把这一章的命题逻辑和底层原理彻底理顺之后才发现，传输层不是靠背出来的，是靠"推"出来的——推一次序号变化、推一次窗口增长、推一次超时重传，比看十遍书都管用。
这篇内容就围绕考研计算机网络中传输层这一章来展开。我会先带你看清楚这一章在试卷里怎么出题、为什么值得你花最多时间，然后从端口、UDP报文、TCP报文段这些基础角色开始，逐步拆解三次握手、四次挥手、可靠传输、流量控制、拥塞控制这几大核心机制，最后用几个高频错题演示做题思路，再分享一些我在复习过程中踩过的坑和总结出来的记忆方法。无论你是刚开始第一轮还是已经进入刷题阶段，这篇都能给你一条清晰的复习主线。
1. 传输层的试卷定位：为什么这一章值得投入最多时间
1.1 考点密度高到几乎每年必考
如果你翻过近几年计算机考研的真题，会发现传输层是计算机网络里出题性价比最高的一章。选择题里，TCP报文段首部字段、UDP特点、端口分配、可靠传输机制都是常客；大题里，三次握手和四次挥手的序号推导、拥塞控制的窗口变化计算，隔三差五就会出现，而且一通百通——弄懂了这一章的底层逻辑，后面应用层的HTTP、HTTPS、DNS，以及网络安全的很多题目，都会变得轻松不少。
我统计过一份自己刷题时的考点分布表，大致是这样：
| 核心考点 | 常见出题方式 | 难度 | 出现频率 |
|---|---|---|---|
| TCP三次握手/四次挥手 | 大题推导+选择题 | 中 | 极高 |
| TCP报文段首部字段 | 选择题 | 低 | 高 |
| UDP特点与首部 | 选择题/简答 | 低 | 中 |
| 可靠传输(GBN/SR/TCP) | 计算题+选择题 | 中高 | 高 |
| 流量控制 | 选择题+大题小问 | 中 | 中 |
| 拥塞控制(四种算法) | 大题计算+选择题 | 高 | 极高 |
| 端口及复用分用 | 选择题 | 低 | 中 |
从这个表能看出来，传输层不是"看一眼就能拿分"的章节，但也绝不是"死活学不会"的章节。它的难点集中在需要动态推导的部分，尤其是连接建立与释放、窗口变化，这些一旦你把原理补齐，做题就是流水线操作。
1.2 先搞懂传输层站在哪：它管的是"进程之间的通信"
很多同学容易混淆传输层和网络层的职责，这里我打个比方。网络层负责的是"两台主机之间怎么把数据送到"，相当于快递公司帮你把包裹从城市A运到城市B，至于包裹到了之后该交给谁，它不管。传输层负责的是"包裹到了之后，该交给这台主机上的哪个应用进程"，相当于快递站点的分拣员，得按收件人姓名把包裹送到具体的人手里。
对应到协议栈里：数据从应用层产生后，交给传输层加上TCP或UDP的首部，再交给网络层封装成IP数据报。传输层通过端口号来区分同一台主机上不同的进程，这就是所谓的复用与分用——多个应用可以共用下面的网络层发送数据（复用），收到数据后按端口号交给正确的应用（分用）。
如果这个定位没搞清楚，后面学那些首部字段和连接管理时会一直觉得飘。先把"传输层是端到端、进程到进程"这十个字刻在脑子里，再看什么都顺了。
1.3 一条复习主线：让数据包走一遍
我建议你复习传输层时，拿一张纸画一条完整的链路：应用层产生一个HTTP请求报文 → 传输层用TCP封装，加上源端口、目的端口、序号、确认号等 → 网络层加上IP地址 → 链路层再封装成帧。每走到一层，就问问自己：这一层加了什么信息？这些信息解决什么问题？
传输层加的首部里，端口解决"交给谁"，序号和确认号解决"有没有丢、有没有乱"，窗口和标志位解决"发多快、怎么建立和关闭连接"。这些字段不是孤立存在的，它们全都在为"可靠地、高效地、正确地把一个应用进程的数据交给另一个应用进程"服务。想通了这条主线，传输层的60%内容已经拿下了。
2. 端口、UDP与TCP报文段：先把所有出场角色认熟
2.1 端口号与套接字：进程的"门牌号"
端口号是一个16位的整数，范围0到65535。考研常考的是它的分段：
- 熟知端口（0~1023）：由权威机构统一分配，比如FTP的21、SSH的22、DNS的53、HTTP的80、HTTPS的443、SMTP的25。
- 登记端口（1024~49151）：给非熟知的应用或厂商使用，需要在IANA登记。
- 客户端端口（49152~65535）：客户端进程临时选取，通信结束后释放。
这里有一个特别容易踩坑的细节：TCP和UDP的端口号空间是相互独立的，也就是说TCP的80端口和UDP的80端口可以同时存在，它们之间不影响。所以写题时看到"某个端口被占用"，一定要先问是TCP还是UDP，别想当然。
再进一步，套接字（socket）由"IP地址:端口号"组成，可以唯一地标识网络中的一个进程端点。TCP连接的两个端点就是两个socket，注意连接的端点，而连接本身是套接字对。这个定义在选择题里出现过不止一次。
2.2 UDP报文段：8字节首部，简单但不等于容易拿全分
UDP的全称是用户数据报协议，它做的事情非常朴素：复用分用、差错检测。首部只有8字节，但考研最喜欢在这个"简单协议"上设陷阱。
UDP首部四个字段各占2字节：源端口、目的端口、长度、校验和。其中长度字段指的是UDP用户数据报的总长度（首部+数据），最小值是8，也就是数据为空的情况。注意UDP报文长度字段只有16位，所以一个UDP数据报的最大长度是2^16 - 1 = 65535字节，再加上IP首部就是65547字节左右。这个值在计算题里偶尔会作为干扰项出现。
UDP校验和的计算是重点中的重点。它校验的范围不只是UDP首部和数据，还要加上一个虚构的"伪首部"。伪首部包含源IP地址、目的IP地址、协议号（17）、UDP长度。它既不出现在UDP报文段里也不往上传输，只在计算校验和时临时拼接，目的是防止IP层的源地址、目的地址、协议字段出错时，数据被投递到错误的主机或协议栈。
一句话记住：伪首部是"借用IP层的地址信息，给UDP加一道跨层安全锁"。
2.3 TCP报文段首部：20字节固定部分，比你想的好背
TCP报文段的首部没有UDP那么好应付，默认固定部分是20字节，考研不仅要理解字段含义，还要会做计算题，比如报文段长度推导、数据偏移的换算。
固定部分按顺序是：源端口（2B）、目的端口（2B）、序号（4B）、确认号（4B）、数据偏移（4位）、保留（6位）、标志位（6位）、窗口（2B）、校验和（2B）、紧急指针（2B）。
序号和确认号是全章的"灵魂字段"。序号是本报文段所发送数据的第一个字节的编号。确认号是期望收到对方下一个字节的序号，它有一个特别容易错的推论：确认号n表示对方序号n-1及之前的所有字节都已正确收到。举例来说，A发送一个seq=90、长度20字节的报文段，B如果收到了，回的确认号应该是110，而不是90或91。这个"确认号=期望的下一个字节序号"的语义，贯穿三次握手、四次挥手、流量控制、可靠传输所有内容。
六个标志位我用场景记忆法帮你串：SYN和FIN管连接的建立与释放，ACK表示确认号有效，PSH是催促接收方尽快交付，RST用于异常时强制复位连接，URG和紧急指针配合处理紧急数据。其中SYN和FIN都会消耗一个序号，纯ACK报文不消耗序号——这个细节几乎每年都有题在考。
数据偏移字段占4位，单位是32位字（4字节），它表示TCP首部的长度。如果数据偏移字段值是5，说明首部是5×4=20字节，即没有选项的标准首部；如果值是6，首部就是24字节，多出来的4字节是选项。考试里给你一个十六进制报文段让你推算数据偏移和首部长度，用的就是这个公式。
2.4 UDP和TCP一次看明白
很多同学分不清什么时候该用TCP、什么时候该用UDP，我把关键差异列出来：
| 对比项 | TCP | UDP |
|---|---|---|
| 连接状态 | 面向连接 | 无连接 |
| 可靠性 | 可靠交付 | 尽最大努力交付 |
| 数据传输单位 | 字节流 | 报文 |
| 首部大小 | 20字节以上 | 8字节 |
| 流量控制/拥塞控制 | 有 | 无 |
| 支持交互 | 全双工 | 一对一、一对多、多对一、多对多 |
| 典型应用 | HTTP、HTTPS、SMTP、FTP | DNS、DHCP、视频直播、语音通话 |
注意"面向报文"和"面向字节流"的差异：UDP不对应用层报文做拆分合并，应用层给多长，UDP就原样发多长；TCP则把应用层数据当成连续的字节流，发送方可以按TCP段大小切割，接收方按字节序号重组，数据块之间的边界由TC P自己决定而不是应用层决定。这个区别在选择题里反复出现，属于白送分题，但总有人丢。
3. TCP连接管理：三次握手与四次挥手是所有大题的"题根"
3.1 三次握手：本质是一次双方收发能力的确认
三次握手的过程相信大家都看过流程图，但我要强调的是，它不是"按规矩发三个包"这么简单。它真正解决的问题是：让通信双方都确认"我能发、你能收；你能发、我能收"。
用具体数字走一遍，假设客户端A的初始序号ISN是x，服务器B的初始序号ISN是y：
第一次：A→B，SYN=1, seq=x。A进入SYN_SENT状态。这个报文告诉B两件事：我要建立连接，我的起始序号是x。
第二次：B→A，SYN=1, ACK=1, seq=y, ack=x+1。B进入SYN_RCVD状态。B既确认了A的SYN（ack=x+1表示B期望A的下一个字节序号是x+1），又同步了自己的序号y。
第三次：A→B，ACK=1, seq=x+1, ack=y+1。A进入ESTABLISHED状态。B收到后也进入ESTABLISHED，连接建立。
注意这里有一个细节：第一、第二两个报文里SYN标志都消耗一个序号，所以ack是x+1和y+1；第三次的ACK如果不携带数据，seq保持x+1，但不再额外消耗对方窗口空间。第三次握手报文丢失怎么办？B会超时重传SYN+ACK，A再重发ACK。这个场景在选择题里经常出。
为什么不是两次握手？这是考研的高频问答题。关键原因是防止"已经失效的连接请求报文"突然又传到服务器。设想A发送的第一个连接请求在网络中超时，A重传了一个请求并成功建立连接，数据传完关闭。可旧的那个请求这时才到达B，如果只有两次握手，B会以为又来了一次新连接，于是分配资源并回复确认——结果A根本不理会，B的资源就被白白占用了。三次握手时，A收到B的SYN+ACK后不会发送第三次ACK，B等不到确认就不会建立连接。一句话：三次握手既防止了失效请求浪费服务器资源，也保证双方对初始序号达成一致。
3.2 四次挥手：两个方向的关闭必须分开做
TCP连接是双向的（全双工），所以关闭也必须"每条链路各关一次"。这就是为什么挥手需要四次。
第一次：A→B，FIN=1, seq=u。A进入FIN_WAIT_1，表示A不再发送数据了，但A仍然可以接收数据。
第二次：B→A，ACK=1, seq=v, ack=u+1。B进入CLOSE_WAIT，A收到后进入FIN_WAIT_2。注意这次只是确认收到FIN，B自己的数据还没发完，所以这一方向还不能关。
第三次：B→A，FIN=1, seq=w, ack=u+1。B进入LAST_ACK。这时B才最终确认自己也没有数据要发了，请求关闭B到A的方向。
第四次：A→B，ACK=1, seq=u+1, ack=w+1。A进入TIME_WAIT，B收到后进入CLOSED。A要等2MSL后才真正CLOSED。
很多同学第一次学到这里都会问：第二次和第三次为什么不能合并？原因就是B收到FIN时，可能还有数据要发，它必须先把剩余数据发完才能发FIN。如果B立即没有数据要发，理论上可以把第二次和第三次合并成一个报文，这时就成了三次挥手，但TCP标准允许的是四次，做题按四次走，题目说"ACK和FIN合并"时再另当别论。
3.3 TIME_WAIT和2MSL：最难懂但最好拿分的一个点
TIME_WAIT状态让很多刚接触传输层的同学一头雾水：第四次ACK都发出去了，连接不就是断了吗，为什么还要等2MSL？
这里有两条理由，都是考点。
第一，保证最后一个ACK能到达B。如果这个ACK在网络中丢失，B在LAST_ACK状态下会超时重传FIN。A在TIME_WAIT期间还能收到这个重传的FIN，于是重新发送ACK，确保B能够正常关闭。如果A立刻进入CLOSED，ACK丢了就没人管了，B会一直重传FIN，本来能正常关闭的连接变成了"半死不活"状态。
第二，让本连接中所有迟到的报文段在网络中消失。假设A和B很快建立了一个新连接，而旧连接的某个报文段在网络中兜了很久才到达——这个报文段的源端口、目的端口可能和新连接完全一致，新连接就会收到"穿越来的脏数据"。等待2MSL（一个MSL是报文段最长存活时间，2MSL恰好让一个报文段在传输方向上存活的最长时间+回应方向的最长时间都过去），旧报文就会在网络中消失，新连接就不会被污染。
3.4 状态变迁和异常场景：大题里的隐藏考点
三次握手四次挥手除了考流程，还会考状态名和异常处理。你把下面这张状态表记熟，选择题基本不会失手：
| 状态 | 发生在哪一步 | 含义 |
|---|---|---|
| LISTEN | 服务器初始 | 监听端口等待连接 |
| SYN_SENT | A发出SYN后 | 主动打开，等待确认 |
| SYN_RCVD | B收到SYN后 | 收到连接请求，等待第三次握手 |
| ESTABLISHED | 连接建立后 | 数据传送状态 |
| FIN_WAIT_1 | A发出FIN后 | 等待B的ACK |
| FIN_WAIT_2 | A收到B的ACK后 | 等待B的FIN |
| CLOSE_WAIT | B收到FIN，回ACK后 | B等待应用层关闭 |
| LAST_ACK | B发出FIN后 | 等待A的最终确认 |
| TIME_WAIT | A发出最后ACK后 | 等待2MSL后关闭 |
异常场景有一个特别经典：如果客户端发出FIN后，长时间停留在FIN_WAIT_2怎么办？这通常意味着服务器的CLOSE_WAIT状态卡住了，也就是服务器应用进程一直没有调用关闭接口，B永远不会发出FIN。真实开发里这种状态大量出现，常见原因是程序忘记关闭socket或线程阻塞。所以面试题问"线上出现大量CLOSE_WAIT"时，答"服务器应用层没正常关闭连接"就切中要害了。
SYN泛洪也值得提一嘴。攻击者发送大量SYN但不完成第三次握手，服务器在SYN_RCVD状态为每个半连接分配资源，资源耗尽后正常用户就连不上服务器了。这就是DDoS攻击的一种。从考试角度，你要能说出"SYN攻击利用的是三次握手的半连接机制"这句话。
4. 可靠传输、流量控制、拥塞控制：三个机制别混成一锅粥
4.1 可靠传输的进化路线：从停等协议到TCP的滑动窗口
可靠传输要解决的问题是：发送方怎么知道数据丢了、错了、乱序了？核心手段就四件——差错校验、序号、确认、超时重传，合起来就是自动重传请求（ARQ）。
最早的停等协议最简单，发一个停一下，收到确认才发下一个。它的信道利用率低到让人着急，假设数据发送时间T_D，往返时间RTT，那么信道利用率≈T_D/(T_D+RTT)。如果RTT远大于T_D，利用率可能只有几个百分点。所以后来才有了滑动窗口机制，允许在未收到确认的情况下连续发送多个报文段。
考研要求重点掌握两种经典滑动窗口协议：后退N帧协议（GBN）和选择重传协议（SR）。GBN允许发送方连续发多个帧，接收方只允许按序接收，只要有一个帧出错，接收方丢弃之后所有到达的帧，发送方超时后从出错帧开始重传所有帧。SR则允许接收方缓存失序到达的正确帧，发送方只重传出错的帧。
这里有个经典计算考点：如果序号字段是n位，GBN的发送窗口大小必须在1到2^n-1之间，SR的窗口大小必须在1到2^(n-1)之间。为什么GBN不能超过2^n-1？你想，如果窗口大小正好等于2^n，发送方发满一整个窗口的帧，如果这些帧的确认全部丢失，发送方超时重发第一帧，这帧的序号和第一次发送的号完全相同，接收方没法区分这是一个新帧还是老帧重传，编号空间就被撑爆了。SR窗口减半是为了避免接收方无法区分新旧序号。
TCP实际使用的协议比GBN和SR都灵活：它按字节编号而不是按帧编号，采用累积确认，接收方收到失序数据后会缓存起来，TCP还通过快速重传机制在收到3个重复ACK时立即重传，而不用傻等超时。偶尔题目里会问"TCP是否能使用选择性确认"，答案是可以的，通过SACK选项实现，但基础教材里最常考的还是累积确认。
4.2 流量控制：接收方为发送方踩刹车
流量控制和拥塞控制的区别，很多同学第一遍学的时候就绕晕了。我的记法是：流量控制管的是"局部上下游"，拥塞控制管的是"全网络路况"。
流量控制的具体动作是：接收方在自己的TCP报文段首部的窗口字段里写入"我还有多少接收缓冲区可用"，这个值叫接收窗口（rwnd）。发送方每发出去一批数据，窗口就变小一点；收到确认后窗口会腾出空间。如果接收方缓冲区满，rwnd=0，发送方就必须停止发送——这就是零窗口。
这里有个额外考点：零窗口之后，如果接收方重新有了空间，发出的窗口更新报文如果丢了，发送方会一直等下去。所以TCP加了一个持续计时器，发送方在零窗口期间定时发送一个"窗口探测报文"逼迫接收方回复当前窗口大小，而不是死等。
流量控制还有个衍生概念叫糊涂窗口综合征，接收方每次只腾出几个字节，发送方每次都发几个字节，报文里大部分空间被首部浪费。解决思路是接收方在窗口小于一定阈值时不开窗，叫"让接收方等待"，发送方则通过延迟发送小报文来避免。考研对这块要求不高，但选择题见过，了解即可。
4.3 拥塞控制：四种算法是每年大题的热门区域
拥塞控制是全章的硬骨头。它的问题是网络层中间路由器的处理能力有限，当太多数据涌入时，路由器缓冲区溢出开始丢包。发送方必须根据网络的"拥堵程度"动态调整发送速率。
请把下面三个名词刻在脑子里：
- 拥塞窗口（cwnd）：由发送方维护，反映网络拥塞程度，单位通常是报文段个数/MSS。
- 慢开始门限（ssthresh）：拥塞窗口增长方式的切换点。
- 实际发送窗口的上限 = min(rwnd, cwnd)。rwnd是接收方能力，cwnd是网络能力。
慢开始：名字很反直觉，它其实是"从小窗口开始，指数级增长"。初始cwnd=1，每经过一个RTT，如果所有报文段都被确认，窗口翻倍：1→2→4→8→16。就像往池塘里扔石子，波纹一层层扩大。当cwnd达到ssthresh（比如16），就不能再指数长了，因为网络快承受不住了。
拥塞避免：窗口从ssthresh开始改为线性增长，每个RTT增加1个MSS，即cwnd从16→17→18→19……此时传输速率缓慢上升，直到某次发生超时。
发生超时后的动作是考研必考：ssthresh被调到当前cwnd的一半，cwnd重置为1，从头开始慢开始。比如cwnd增长到24时超时，ssthresh变成12，cwnd变成1，重新1→2→4→8→12（到达ssthresh线）→13→14……
快重传：发送方连续收到3个重复ACK，不等超时就立刻重传丢失报文段。为什么？3个重复ACK已经足够说明有报文丢了，死等超时是浪费时间的。
快恢复：快重传发生后的处置。主流教材的版本是：ssthresh减半，cwnd直接降到新的ssthresh，然后进入拥塞避免阶段，开始线性增长。有的教材或题目采用老版本，会写cwnd=ssthresh+3，这是因为3个重复ACK表明网络还不是彻底瘫痪，保留了一点余量。考试时如果题目没有明说版本，按你所用复习教材的口径来，遇到自命题历年真题答案有出入，以教材为准。
我把这四种算法的触发条件和动作整理成一张表，做题时对着查：
| 算法 | 触发条件 | 窗口变化 |
|---|---|---|
| 慢开始 | 连接建立或超时后 | cwnd=1，每RTT翻倍 |
| 拥塞避免 | cwnd达到ssthresh | 每RTT线性+1 |
| 快重传 | 收到3个重复ACK | 立即重传，不等待超时 |
| 快恢复 | 快重传之后 | ssthresh=cwnd/2，cwnd=ssthresh，进入拥塞避免 |
想验证自己真懂了，建议拿一张纸，设定初始cwnd=1，ssthresh=16，然后手动推前10个RTT的cwnd值，再在某一个RTT人为制造一次超时，重新推后半段。推完这张表，考试里的窗口变化题就再也不会难住你。
4.4 做题时怎么一眼判断考的是哪个机制
每次看到题目里出现窗口、重传、丢包，先问自己三个问题：
题目里提到接收方缓冲区大小变化了吗？提到了，那是流量控制，考点在rwnd。题目里提到网络拥塞、路由器丢包、慢开始门限了吗？提到了，那是拥塞控制，考点在cwnd和ssthresh。题目里提到序号、确认号、超时重传、乱序到达了吗？那是可靠传输，考点在滑动窗口和ARQ。
我曾经做过一道题，题干给了接收方通告窗口从4096变成2048，然后问发送方窗口怎么变。好多同学张口就答"进入拥塞避免"，完全错了——接收方窗口变小是流量控制，发送窗口跟着缩小就行，跟网络拥塞没有半点关系。反过来，题干说"路由器队列溢出丢包"，那才是拥塞控制的启动场景。
5. 高频错题拆解：把"看着眼熟一做就错"的题彻底拿下
5.1 连接管理序号推导题：先分清楚谁说、谁期待
先看一道经典的三次握手题。主机A向主机B建立TCP连接，A发送的SYN报文段序号seq=500。B回送SYN+ACK报文段，确认号ack=501，同时自己的初始序号seq=2000。问：A再发送的ACK报文段中，seq和ack各是多少？
答案：seq=501，ack=2001。
来，我们拆一下为什么。A的SYN报文序号是500，SYN标志本身消耗一个序号，所以B确认的应该是501（期望A下一个字节的序号）。B在SYN+ACK里说"我的初始序号是2000"，SYN同样消耗序号，所以A回复时，确认号必须是2001（期望B的下一个字节序号是2000之后的2001）。而第三个报文本身不携带数据，seq就是A的下一个待发字节序号501。
这类题你只要记住两句话就永远不会错：第一，SYN和FIN都算一个字节，要占序号；第二，确认号永远等于"对方最后一个已发送字节的序号+1"，也就是期望对方接下来第一个字节的序号。
5.2 拥塞控制窗口变化题：手推比背诵靠谱
再拆一道高频计算题。假设TCP连接初始cwnd=1，ssthresh=16，MSS=1KB，不发生超时，问第4个RTT结束时cwnd是多少？
推一遍：第1个RTT，cwnd=1；第2个RTT，收到确认翻倍，cwnd=2；第3个RTT，cwnd=4；第4个RTT，cwnd=8。很多人会直接填8，但如果我把题目改成问第5个RTT结束时是多少，坑就来了。
第5个RTT开始时cwnd=8，本轮结束时按慢开始翻倍应该是16，而16正好等于ssthresh。按教材约定，当cwnd增长到ssthresh时，慢开始结束、进入拥塞避免，所以第5个RTT结束后cwnd=16，第6个RTT结束后cwnd=17（线性+1），而不是32。
再变一个版本：还是初始cwnd=1，ssthresh=16，假设第5个RTT结束时检测到超时，问新的ssthresh和cwnd各是多少？超时时刻cwnd=16，ssthresh=16/2=8，cwnd=1重新慢开始。这道题在真题里出现过很多次，本质就考"超时=窗口归1+门限减半"这一条规则。
5.3 场景判断题：UDP虽不可靠，为什么还被广泛应用
有一种概念题特别容易让考生答偏：既然UDP不可靠，为什么实时视频、语音通话、直播还在用它？
答这种题要抓住三点。第一，可靠是TCP提供的，但TCP靠确认和重传换可靠，代价是延迟不可控。视频电话里一个画面丢几帧无所谓，重传反而导致画面卡顿，用户感知更差。第二，TCP有拥塞控制和流量控制，会把发送速率降下来，这种"网络不好就放慢速度"的机制不适合实时通信。第三，UDP首部小、无连接建立开销，对高频小请求（DNS查询）和低延迟应用非常友好。
还有一类扩展题问：既然UDP不可靠，为什么有时还要在UDP之上自己做可靠性？答案是为了"按需定制"——想要多少可靠性、多少延迟、多少吞吐，自己写逻辑，而不是被TCP的通用机制绑住。
5.4 选择题易混点速查
刷题时间紧，我把高频易混点直接列出来，考前过一遍能救不少分：
- SYN和FIN消耗序号，纯ACK报文不消耗序号。
- 确认号n代表"n-1及之前的字节都收到了，我期待n"。
- TCP是全双工的，UDP支持一对一、一对多、多对一、多对多。
- TCP不支持广播和组播。
- UDP的伪首部不是真实首部，只用于校验和计算。
- TCP的流量控制是端到端（接收方管发送方），拥塞控制是全局性的（网络环境决定）。
- 收到3个重复ACK触发快重传；只有超时才触发慢开始（除快恢复场景）。
- 初始序号是随机生成的，不是固定从0开始，所以拥塞控制题目要先看清楚题干给出的ISN。
6. 我的复习节奏与几个实用记忆法（个人经验）
6.1 三轮复习怎么安排最高效
第一轮，配合教材把三次握手、四次挥手、滑动窗口、拥塞控制的图亲手画一遍。画图的时候不要照抄课本，要合上书，从"我是发送方、我要干什么"的角度推演。画不出来就说明没吃透，回去重看，再合上继续画，直到能独立画出完整的时序和状态变迁为止。
第二轮，集中刷题。优先刷真题里传输层的所有题目，做题时给自己限时，一道选择题一分钟左右，大题的序号推导控制在十分钟内。做完不要只看对错，重点看解析里"为什么是这个答案"，把错题归类，比如"序号类""窗口类""概念辨析类"，统计自己错得最集中的方向。
第三轮，考前只看两样东西：自己整理的错题本，以及一张A4纸。A4纸上写满我前面列出的易混点、状态表、四种拥塞算法触发条件。考场上你不可能翻教材，但这一张纸能把传输层90%的得分点装进脑子里。
6.2 记忆法来了：让知识点自己长在脑子里
教大家几个我自己用下来很有效的记忆法。
第一，时序口诀。三次握手是"我发SYN你回SYN+ACK我再回ACK"，四次挥手是"我发FIN你回ACK你发FIN我再回ACK"。多念几遍，手记得和嘴记得一起上，考试时推序号就不会漏步骤。
第二，数字联想。三次握手里有一个"3"字辈：三次握手建立连接、三个重复ACK触发快重传、TCP三报文握手（这三个其实是一回事，但你这样串起来记不会混）。四次挥手里有一个"2"字辈：2MSL等待、FIN_WAIT_2状态、两个方向分别关闭。
第三，图像记忆。拥塞控制你把慢开始想象成"阶梯"——每过一个RTT翻倍；拥塞避免想象成"爬坡"——每次只加1；超时是"跳下悬崖"——cwnd归1；快恢复是"折返跑"——ssthresh减半后在原地起跑。有了画面，做题时一看到"超时"两个字，脑中立刻浮现窗口归1的图景，比死记公式管用一百倍。
第四，对比记忆。把流量控制和拥塞控制放在一起，用"一个管接收端缓冲区、一个管网线路由"来锚定；把GBN和SR放在一起，用"一个重传一串、一个只重传一个"来区分；把TCP和UDP放在一起，用"可靠连接VS不可靠无连接"作为总纲。
我自己当年复习到后期，每天晚上睡觉前会闭着眼睛默背一遍TCP首部20字节的字段顺序：源端口、目的端口、序号、确认号、数据偏移、保留、标志位、窗口、校验和、紧急指针，背完直接入睡。坚持两周后，这部分内容再也忘不掉。
传输层学完之后，你再去翻网络层和应用层的很多细节，会发现处处是它的影子。记住，这一章讨厌的地方在于过程繁琐，可爱的地方也在于过程繁琐——正因为过程是有逻辑的、可推导的，你只要亲手推演过几遍，考场上的传输层题目就会变成全卷最稳定的得分点。最后再分享一个小建议：现在放下文章，拿一张纸，把三次握手和四次挥手的报文段画出来，标好每个报文里的seq和ack，画完你会发现，刚才读过的所有内容都已经真正进入你的脑子里了。
