第5章 传输层
第5章 传输层¶
整个网络体系结构中的关键层次。TCP 的报文分析、连接管理、流量控制与拥塞控制出选择题和综合题的概率都很大，必须把工作原理吃透。
b_236_3【知识树】第5章骨架¶
- 传输层提供的服务
- 四大功能：进程间逻辑通信、复用分用、差错检测、面向连接/无连接
- 寻址与端口：端口号分类、套接字
- UDP
- 特点与优点、首部 8B
- 检验和（伪首部、二进制反码求和）
- TCP
- 报文段首部与各标志位
- 连接管理：三次握手、四次挥手
- 可靠传输：序号确认、重传（超时/冗余ACK）
- 流量控制：滑动窗口、零窗口探测
- 拥塞控制：慢开始、拥塞避免、快重传、快恢复
b_236_0；PDF 第 236 页 · b_236_25.1 传输层提供的服务¶
三层各自提供什么范围的"逻辑通信"？¶
- 数据链路层：相邻节点之间的逻辑通信
- 网络层：主机之间的逻辑通信
- 传输层：运行在不同主机上的进程之间的逻辑通信
⚠️ 传输层是面向通信部分的最高层，同时是用户功能中的最低层；即使网络层不可靠（丢失、失序、重复），传输层仍能为应用程序提供可靠服务。
💡 "逻辑通信"的含义：对等层之间的通信看似沿水平方向传送，实际上并不存在一条水平方向的物理连接。
b_236_2；PDF 第 236 页 · b_236_6从传输层看，通信的真正端点是什么？¶
是主机中的进程，而不是主机。
从网络层看，通信两端是两台主机（IP 首部指明两台主机的 IP 地址）；但 IP 只能把分组送达目的主机，分组停在主机的网络层，并未交付给具体的应用进程。所以"主机之间的通信"的实质是进程之间的通信，也称端到端的逻辑通信。
b_236_9传输层和网络层的复用分用有什么不同？¶
- 传输层：复用 = 多个应用进程可用同一个传输层协议传送数据；分用 = 接收方剥去报文首部后把数据交给对应的应用进程
- 网络层：复用 = 把不同传输层协议的数据封装成 IP 数据报；分用 = 按首部的协议字段把数据交给相应的传输层协议
💡 一句话：传输层按端口号分用，网络层按协议字段分用。
b_237_2；PDF 第 237 页 · b_237_5传输层和网络层的差错检测范围差在哪？¶
- 传输层：对整个报文（首部 + 数据部分）做差错检测
- TCP：发现出错 → 要求发送方重传
- UDP：发现出错 → 直接丢弃
- 网络层：IP 数据报仅校验首部，不检查数据部分
⚠️ 这是高频对比点。
b_237_6；PDF 第 237 页 · b_237_7四层的"服务访问点"分别是什么？¶
- 数据链路层 → 帧的"类型"字段
- 网络层 → IP 数据报的"协议"字段
- 传输层 → "端口号"字段
- 应用层 → "用户界面"
💡 记忆法："类型—协议—端口—界面"，一层一个入口。
b_238_1端口号的位数和三类范围？¶
端口号长度 16 比特，可表示 2¹⁶ = 65536 个端口号。
- 熟知端口号 0 ~ 1023：IANA 分配给最重要的 TCP/IP 应用程序
- 登记端口号 1024 ~ 49151：未获熟知端口号的应用程序使用，需在 IANA 登记以避免冲突
- 客户端端口号 49152 ~ 65535：客户进程运行时动态分配，又称短暂端口号；通信结束后被系统回收，可供其他进程复用
⚠️ 端口号仅具有本地意义：不同主机的相同端口号没有关联，且 UDP 和 TCP 的端口号彼此独立。
b_238_1；PDF 第 238 页 · b_238_2七个必背熟知端口号？¶
| FTP | TELNET | SMTP | DNS | TFTP | HTTP | SNMP |
|---|---|---|---|---|---|---|
| 21 | 23 | 25 | 53 | 69 | 80 | 161 |
💡 记忆法："21 传文件、23 远程登、25 发邮件、53 查域名、69 简单传、80 上网页、161 网管"。
b_238_0套接字是什么？¶
套接字（Socket）= (IP 地址 : 端口号)
用 IP 地址区分不同主机，用端口号区分同一主机中的不同应用进程，拼接起来就唯一标识网络中某台主机上的一个应用进程，是通信的端点。
⚠️ 两个易错点：同一 IP 地址可参与多个 TCP 连接，同一端口号也可出现在多个不同的 TCP 连接中。 ⚠️ 报文中的源端口构成"返回地址"的一部分 —— B 回复 A 时，其目的端口就是 A 原报文中的源端口。
b_238_8；PDF 第 238 页 · b_238_9TCP 和 UDP 的适用场景？¶
- TCP：面向连接，提供可靠的全双工逻辑信道；靠确认、流量控制、计时器、连接管理保障可靠传输，代价是首部开销大、处理资源消耗高；⚠️ TCP 不提供广播或多播服务。典型应用有 FTP、SMTP、HTTP/1.x 和 HTTP/2
- UDP：无连接，收到数据报也不发确认；在 IP 层之上仅提供两项服务：多路复用与分用、数据差错检测；结构简单、开销小、效率高、实时性好。典型应用有 TFTP、DHCP、RIP；普通 DNS 查询通常也先用 UDP
⚠️ 不能把应用协议与传输层永久一一绑定：DNS 也会使用 TCP；HTTP/3 基于 QUIC/UDP。
b_238_13九个典型应用分别用 TCP 还是 UDP？¶
按王道/408 的传统默认表： - 常按 UDP 记：DNS 普通查询、TFTP、RIP、DHCP、SNMP - 常按 TCP 记：SMTP、TELNET、HTTP/1.x/2、FTP
⚠️ 这不是绝对绑定：DNS 可用 TCP，HTTP/3 用 QUIC/UDP。做选择题先按题目给出的协议版本和场景。
⚠️ 辨析 IP 数据报与 UDP 数据报：IP 数据报在网络层要经路由器存储转发；而 UDP 数据报作为 IP 数据报的载荷，在网络层传输时内容对路由器不可见。
b_239_05.2 UDP¶
UDP 的五条优点？ ★2考¶
- 无连接，没有建立连接的时延；且无须维护连接状态（TCP 要维护发送/接收缓存、拥塞控制参数、序号和确认序号等）
- 面向报文：⚠️ 一次发送一个完整的报文，既不合并也不拆分，保留报文的边界
- 首部开销小，仅 8B（TCP 首部至少 20B）
- 支持一对一、一对多、多对多通信（TCP 仅支持一对一）
- 没有拥塞控制 → 网络拥塞不会影响源主机的发送速率，适合要求稳定速率、容忍少量丢包、不能接受大时延的实时应用
★ 考过 2014、2024
b_241_5"面向报文"给应用程序带来什么负担？¶
应用程序必须自己选择合适大小的报文： - 报文太长 → 交给 IP 层后可能导致分片 - 报文太短 → IP 首部的开销占比过大
两者都降低传输效率。
⚠️ 对照：TCP 是面向字节流的，每个字节都有编号，支持自动拆分与重组，对报文长度无限制。
💡 UDP 不保证可靠交付，但不代表应用不要求可靠性 —— 所有可靠性机制可由应用层自行实现。
b_241_7UDP 首部的四个字段？ ★2考¶
UDP 首部共 8B，4 个字段，每个字段 2B： - 源端口号：⚠️ 需要对方回复时选用，不需要回复时可置为全 0 - 目的端口号：⚠️ 在所有 UDP 报文中都必须有效 - 长度：UDP 数据报的长度（包括首部和数据），⚠️ 最小值是 8（仅有首部） - 检验和：发送方计算写入，接收方检测，有错就丢弃；⚠️ IPv4 中可置为全 0 表示未使用（不建议），IPv6 中强制启用
★ 考过 2018、2021
b_241_15目的端口号不存在时会怎样？¶
接收方 UDP 发现目的端口号不正确（不存在对应该端口号的应用进程）→ 丢弃该报文，并由 ICMP 发送"端口不可达"差错报文给发送方。
💡 这是 ICMP 与传输层唯一的直接联动，常考。
b_242_3伪首部是干什么用的？ ★1考¶
计算检验和时，要在 UDP 数据报之前临时加入伪首部。IPv4 的 UDP 伪首部是 12B；IPv6 伪首部是 40B。
⚠️ 伪首部不是 UDP 的真正首部，只是计算检验和时临时添加在前面，得到一个临时的 UDP 数据报；它既不向下传递给网络层，也不向上递交给应用层。
⚠️ 与 IP 检验和的区别：IP 检验和只检验首部，而 UDP 检验和把首部和数据部分一起检验。
★ 考过 2025
b_242_6UDP 检验和的发送方三步、接收方一步？ ★1考¶
发送方： - ① 把检验和字段置为全 0 - ② 把伪首部 + UDP 数据报看成一连串 16 位字；⚠️ 数据部分长度为奇数个字节时，末尾临时补一个全 0 字节（只在计算时添加，不影响实际发送的内容） - ③ 按二进制反码规则求和，把结果的反码填入检验和字段
接收方：同样组合并补齐后做二进制反码求和 —— 无差错则结果应为全 1（16 位全为 1），否则丢弃。
★ 考过 2024
💡 记忆法："发方填反码，收方得全 1"。
b_242_11二进制反码求和的规则和"回卷"？ ★1考¶
- 从低位到高位逐列计算：0+0=0，0+1=1，1+1=0 并产生进位 1
- ⚠️ 最高位相加产生进位时，要把该进位加到结果的最低位 —— 这个过程称为回卷
教材算例（三个 16 位字）：
01100110 01100000
01010101 01010101
--------------------
10111011 10110101 ← 前两个字相加
10111011 10110101
10001111 00001100
--------------------
1 01001010 11000001 ← 最高位产生进位
+ 1
--------------------
01001010 11000010 ← 回卷后的结果
最后对这个结果取反码，就得到检验和。
★ 考过 2024
b_242_135.3 TCP¶
TCP 的五条特点？¶
- 面向连接 → 引入了建立连接和释放连接的开销
- 每条连接只有两个端点，仅支持一对一通信
- 提供可靠交付：无差错、不丢失、不重复、按序到达
- 支持全双工：两端都设有发送缓存和接收缓存
- 面向字节流：⚠️ 把应用层交下的数据块视为一连串无结构的字节流，不保留应用层数据块的边界
⚠️ 报文长度谁说了算：UDP 报文长度由应用进程直接指定；TCP 根据对方通告的窗口大小和当前网络拥塞程度动态决定一个报文段含多少字节 —— 数据块过长就划分，过短就暂存积累。
b_248_3TCP 首部的最小和最大长度？ ★2考¶
- 前 20B 固定，后面有 4N 字节的选项 → 最小 20B
- 数据偏移（首部长度）占 4 位，单位是 4B，值乘 4 = 首部长度
- 最小值 5（20B）；4 位最大表示 15 → 最大首部 60B（选项最多 40B）
⚠️ 整个 TCP 报文段作为 IP 数据报的数据部分封装。
★ 考过 2012、2021
💡 记忆法："TCP 20~60，IP 也是 20~60，单位都是 4B"。
b_249_6序号和确认序号分别指什么？ ★2考¶
- 序号（4B）：范围 0 ~ 2³²−1，到顶后回绕到 0（模 2³² 运算）；⚠️ 每个字节都按顺序编号，序号字段的值指明本报文段所发送数据的第一个字节的序号
- 确认序号（4B）：期望收到对方下一个报文段中第一个数据字节的序号；⚠️ 确认序号为 N，就表明到序号 N−1 为止的所有数据均已正确接收
两个例题： - 报文段序号 301、数据 100B → 最后一个字节序号 400，下一个报文段从 401 开始 - B 正确收到序号 501、长度 200B 的报文段（501~700）→ B 的确认序号置为 701
💡 计算时画一条字节轴：本段首字节位置写 seq，向右数数据长度，末端下一格就是对方应回的 ack。不要把 TCP 序号误当“第几个报文段”。
★ 考过 2009、2016
b_248_16；PDF 第 248 页 · b_248_17；PDF 第 249 页 · b_249_0；PDF 第 249 页 · b_249_4；PDF 第 249 页 · b_249_5六个控制位分别是什么意思？ ★1考¶
- URG（紧急位）：URG=1 表示紧急指针字段有效，本报文段含紧急数据应优先处理；⚠️ 紧急数据放在数据的最前面
- ACK（确认位）：⚠️ 仅当 ACK=1 时确认序号字段才有效；TCP 规定连接建立后所有报文段都必须 ACK=1
- PSH（推送位）：交互式通信中希望立即得到响应，接收方收到 PSH=1 就立即把数据交付应用进程，不必等缓存填满
- RST（复位位）：RST=1 表示连接出现严重差错（如主机崩溃），必须释放并重新建立；也可用于拒绝非法的报文段或连接请求
- SYN（同步位）：SYN=1 表示这是连接请求或连接接受报文；SYN=1、ACK=0 是连接请求，同意则响应 SYN=1、ACK=1
- FIN（终止位）：FIN=1 表示发送方已无更多数据要发送，请求释放连接
💡 记忆法："URG 插队、ACK 认账、PSH 催货、RST 掀桌、SYN 敲门、FIN 告别"。
★ 考过 2012
b_249_9；PDF 第 249 页 · b_249_10；PDF 第 249 页 · b_249_11；PDF 第 249 页 · b_249_12；PDF 第 249 页 · b_249_13；PDF 第 249 页 · b_249_14；PDF 第 250 页 · b_250_0窗口字段是谁的窗口？¶
窗口（2B，0 ~ 2¹⁶−1，以字节为单位）由本报文段的发送方填写，表示它作为接收方时当前还能接收的最大数据量。
含义："从本报文段的确认序号所指示的字节序号开始，你最多可以连续发送这么多字节"。
例：确认序号 701、窗口值 1000 → 对方可从 701 开始连续发送最多 1000B（序号 701~1700）。
b_250_5TCP 检验和、紧急指针、MSS 的要点？¶
- 检验和（2B）：检验范围包括首部和数据部分；⚠️ IPv4 计算时加 12B 伪首部，与 UDP 的区别是协议字段改为 6、长度字段改成 TCP 长度；IPv6 的 TCP 伪首部为 40B
- 紧急指针（2B）：仅 URG=1 时有效，指出紧急数据的字节数；⚠️ 即使接收窗口为零，仍可发送紧急数据
- 选项（最长 40B）：最初只定义了 MSS（最大报文段长度） —— ⚠️ MSS 指的是 TCP 报文段中数据字段的最大长度（类比：MTU 指帧中数据部分的最大长度）；后来又增加窗口扩大、时间戳等
- 填充：确保整个首部长度是 4B 的整数倍
b_250_1；PDF 第 250 页 · b_250_55.3.3 TCP 连接管理¶
建立连接要解决哪三个问题？连接的端点是什么？¶
三个问题： - 使通信双方确知对方的存在 - 允许双方协商相关参数（最大窗口值、是否使用窗口扩大选项、时间戳选项等） - 为传输实体分配必要的资源（缓存空间、连接表项等）
⚠️ TCP 连接的端点既不是主机、IP 地址，也不是应用进程或端口，而是套接字；一条 TCP 连接由通信双方的两个套接字唯一确定。同一 IP 可参与多个连接，同一端口号也可出现在多个连接中。
连接建立采用客户/服务器模式：主动发起的是客户，被动等待的是服务器。
b_250_2；PDF 第 250 页 · b_250_3三次握手的三个报文段各带什么？ ★5考¶
初始时两端都是 CLOSED，服务器做完准备后进入 LISTEN。 - ① 客户 → 服务器：SYN=1，seq=x；客户进入 SYN-SENT - ② 服务器 → 客户：SYN=1、ACK=1，ack=x+1，seq=y；服务器进入 SYN-RCVD - ③ 客户 → 服务器：ACK=1，ack=y+1，seq=x+1；客户进入 ESTABLISHED，服务器收到后也进入 ESTABLISHED
★ 考过 2011、2012、2016、2019、2023
b_251_2三次握手的三条易错规定？ ★1考¶
- ⚠️ 只有前两次握手的报文段 SYN=1。按王道/普通 408 题设，SYN 报文段不携带应用数据，但仍消耗一个序号；协议扩展场景（如 TCP Fast Open）可在 SYN 中携数据，因此不要写成无条件标准禁令
- ⚠️ 只有第一次握手的报文段 ACK=0（此时还没收到任何报文段）
- ⚠️ 第三次握手的报文段可以携带数据；若不携带则不消耗序号，下一个数据报文段的序号仍为 x+1
时间：从客户发出 SYN 时刻起算，客户最早在 1RTT 后可发送数据，服务器最早在 1.5RTT 后才能发送。
💡 记忆法："SYN 和 FIN 空手也占号，纯 ACK 空手不占号"。
b_251_6四次挥手的四个报文段各带什么？ ★2考¶
- ① 客户 → 服务器：FIN=1，seq=u（=已发送数据的最后一个字节序号+1）；客户进入 FIN-WAIT-1
- ② 服务器 → 客户：ACK=1，ack=u+1，seq=v；服务器进入 CLOSE-WAIT，客户收到后进入 FIN-WAIT-2
- ③ 服务器 → 客户：FIN=1、ACK=1，seq=w（⚠️ w 可能大于 v，因为半关闭期间服务器可能又发了数据），ack 仍为 u+1；服务器进入 LAST-ACK
- ④ 客户 → 服务器：ACK=1，ack=w+1，seq=u+1；客户进入 TIME-WAIT，服务器收到后进入 CLOSED
⚠️ FIN 报文段即使不携带数据也消耗一个序号。
★ 考过 2020、2021、2023
b_252_0什么是半关闭状态？¶
第②步之后：从客户到服务器方向的连接已释放，但从服务器到客户方向的连接并未释放 —— 这就是半关闭状态。
原因：TCP 是全双工的，可视为包含两条独立的数据通路；发送 FIN 的一端只关闭了自己的发送方向，对方仍可继续发送数据。
⚠️ 两条易错规定： - 只有第一次和第三次挥手的报文段 FIN=1 - 后三次挥手的报文段 ACK 都等于 1（每次都要确认之前收到的报文段） - FIN 可以与该方向最后一批数据同段发送；FIN 自身消耗一个序号，且该方向在 FIN 之后不再发送数据
b_252_1；PDF 第 252 页 · b_252_2；PDF 第 252 页 · b_252_3；PDF 第 252 页 · b_252_4；PDF 第 252 页 · b_252_10为什么要等 2MSL？两边释放各要多久？ ★3考¶
TIME-WAIT 状态要等 2MSL（最长报文段寿命的两倍）才进入 CLOSED，目的有二： - 确保客户发送的最后一个 ACK 能够到达服务器（丢了服务器会重传 FIN，客户还能再确认） - 使本连接中所有滞留的旧报文段从网络中自然消失，避免影响新连接
时间计算（服务器收到释放请求后不再发数据，从客户发出 FIN 起算）： - 客户释放连接最短 1RTT + 2MSL - 服务器释放连接最短 1.5RTT
★ 考过 2016、2022、2024
💡 记忆法："客户多等 2MSL，服务器 1.5RTT 就走"。
b_252_5；PDF 第 252 页 · b_252_6；PDF 第 252 页 · b_252_7；PDF 第 252 页 · b_252_8保活计时器是干什么的？¶
防止客户突发故障导致服务器长期无效等待。 - 服务器每收到一次数据就重置该计时器 - 计时器超时仍未收到数据 → 发送探测；达到配置的失败条件后可关闭连接
⚠️ 是否启用、空闲多久开始、探测间隔和探测次数都是操作系统或应用配置，不是 TCP 协议固定常数。原书的 75 秒、10 次只能当某实现示例。
b_252_115.3.4 TCP 可靠传输¶
TCP 靠哪四种机制实现可靠传输？ ★4考¶
检验、序号、确认、重传。（检验机制与 UDP 类似。）
序号：⚠️ TCP 的序号是对字节流中的每个字节依次编号，而不是对报文段整体编号；序号字段值指明本报文段第一个数据字节的序号。
教材例子：发送缓存 10B（0~9），第一个报文段含 0~2 号字节 → 序号 0；后续报文段序号依次是 3、6、8。
★ 考过 2011、2012、2013、2025
b_253_1；PDF 第 253 页 · b_253_3累积确认怎么算确认序号？¶
TCP 默认使用累积确认：确认按序到达的连续字节，确认序号 = 第一个未收到字节的序号。
两个对照例子（数据字节 0~9）： - B 收到第一个和第二个报文段（0~5）→ 期望从 6 号开始 → 确认序号 = 6 - B 收到第一个和第三个报文段（0~2 和 6~7，缺第二个）→ ⚠️ 仍在等 3 号字节 → 确认序号 = 3
⚠️ 发送方缓存区会继续存储已发送但未收到确认的报文段以便重传。接收方可以在合适时机发送确认，也可以在有数据要发时捎带确认。
b_253_6触发 TCP 重传的两种事件？¶
超时和冗余 ACK。
超时：常用标准模型为发送方维护一个重传计时器，跟踪最早尚未确认的数据；计时器到期仍未获确认时重传。不能把它写成“每个报文段各有一个独立计时器”。 - 由于下层是互联网环境，IP 数据报所选路由变化很大，往返时延波动大，所以 TCP 用自适应算法：记录报文段发出与收到确认的时间差 = RTT，维护加权平均往返时间 RTTS，并据新样本动态调整 - ⚠️ 超时重传时间 RTO 应略大于 RTTS，但不能大太多 —— 否则报文段丢失时无法迅速重传，时延增大
b_253_8；PDF 第 253 页 · b_253_9什么是冗余 ACK？几个才触发快重传？¶
冗余 ACK = 再次确认某个报文段的 ACK，而发送方先前已收到过该报文段的确认。
按王道/408 的典型模型：每当比期望序号大的失序报文段到达时，立即发送一个冗余 ACK，指明下一个期待字节的序号。
教材例子：A 发 1~5 号，2 号丢失 → 3、4、5 号对 B 来说是失序报文段 → B 立即发 3 个对 1 号报文段的冗余 ACK，表示自己期望收到 2 号。
收到 3 个冗余 ACK 时，发送方据此执行快速重传。⚠️ 这是强烈的丢失信号而非逻辑证明；现实中的分组重排、延迟 ACK、SACK 和具体 ACK 策略会影响行为。
⚠️ 极易算错：对 1 号报文段的正常确认不算冗余 ACK —— 触发快重传时，发送方一共收到 4 个对 1 号报文段的确认。
b_253_8；PDF 第 253 页 · b_253_125.3.5 TCP 流量控制¶
流量控制靠什么实现？ ★2考¶
TCP 用滑动窗口机制实现流量控制 —— 本质是一种速度匹配服务，匹配发送方的发送速率与接收方的读取速率。
接收方维持一个接收窗口 rwnd，大小根据当前接收缓存动态调整，写入 TCP 首部的"窗口"字段通知发送方；发送方的发送窗口不能超过 rwnd。
教材例子：B 一开始通知 rwnd=400，随后三次流量控制把窗口依次减到 300 → 100 → 0；⚠️ 这三个报文段都设置了 ACK=1（只有 ACK=1 时确认序号字段才有意义）。rwnd=0 后发送方暂停，直到 B 重新发出一个新的窗口值。
★ 考过 2016、2021
b_254_6零窗口通知丢了会死锁吗？¶
会 —— 所以 TCP 为每个连接设有一个持续计时器。 - 只要发送方收到零窗口通知，就启动持续计时器 - 计时器超时 → 发送一个零窗口探测报文段 - 对方在确认该探测报文段时给出当前窗口值 - 窗口仍为零 → 重新设置持续计时器；窗口非零 → 死锁被打破
💡 场景：B 发了零窗口通知后缓存又空出来，发了非零窗口通知却在传输中丢失 —— 若无此机制，双方会互相等待陷入死锁。
b_255_0传输层和数据链路层的流量控制差在哪？¶
- 传输层：端到端，即两个进程之间的流量控制；窗口大小可根据接收方缓存情况动态变化
- 数据链路层：相邻节点之间的流量控制；滑动窗口的窗口大小一般为固定值
💡 记忆法："链路层管邻居、固定窗；传输层管进程、动态窗"。
b_255_15.3.6 TCP 拥塞控制¶
拥塞控制和流量控制的区别（举例说明）？¶
- 拥塞控制：目标是使网络能承受当前负载，是全局性过程，涉及所有主机、路由器
- 流量控制：关注点对点通信中接收方的处理能力，是端到端问题，由接收方用窗口机制抑制发送方
⚠️ 二者都是通过调节发送方的发送速率来实现控制。
教材举例（10Gb/s 链路）： - 一台大型机以 1Gb/s 向一台 PC 传文件 → 带宽充足不拥塞，但 PC 处理能力有限 → 需要流量控制 - 100 万台 PC 各以 1Mb/s 通过该链路传文件 → 问题变成网络总负载是否超出承载能力 → 需要拥塞控制
b_255_4发送窗口到底怎么定？ ★5考¶
- rwnd（接收窗口）：由接收方通过 TCP 首部的"窗口"字段通知，体现接收方的接收能力
- cwnd（拥塞窗口）：由发送方根据当前网络拥塞状况自主维护、动态调整
cwnd 的控制原则： - 网络未拥塞 → 适当增大 cwnd，提高网络利用率 - 检测到拥塞 → 适当减小 cwnd，缓解拥塞
⚠️ 通常只要发送方未按时收到确认（发生超时），就认为网络出现了拥塞。
★ 考过 2010、2014、2015、2016、2025
💡 考试铁律：题目里同时出现 rwnd 和 cwnd 时，发送窗口取两者较小值。
b_255_11慢开始"慢"在哪？怎么涨？ ★3考¶
按王道/传统 408 计算模型，初始 cwnd 常取 1MSS；每收到一个对新报文段的确认就把 cwnd 增加 1MSS，因此每经过一个 RTT 近似加倍，呈指数增长。
演进：1 → 2 → 4 → 8 → …
⚠️ "慢"不是指增长速度慢，而是指从较小的 cwnd（如 1）开始谨慎试探网络状态。
⚠️ 1MSS 是教材例题初值，不是现代 TCP 的固定常数；实际初始窗口可取多个 MSS。题目给初值按题设，未给且明确采用王道模型时再从 1MSS 起算。
为防止无限增长，设慢开始门限 ssthresh：cwnd 增长到 ssthresh 时停止慢开始，改用拥塞避免。
★ 考过 2014、2015、2025
b_255_18拥塞避免怎么涨？两算法怎么切换？ ★5考¶
拥塞避免：每经过一个传输轮次就把 cwnd 加 1（不是加倍）→ 线性增长（加法增大）。
切换规则： - cwnd < ssthresh → 用慢开始 - cwnd > ssthresh → 用拥塞避免 - cwnd = ssthresh → 两者皆可（常规做法是用拥塞避免）
⚠️ 拥塞避免并不能完全避免拥塞 —— 它只是让 cwnd 按线性规律增长，使网络较不容易发生拥塞。
★ 考过 2009、2017、2020、2022、2023
b_256_3检测到拥塞（超时）时执行哪三步？¶
无论处于慢开始还是拥塞避免阶段，只要判断网络出现拥塞（如发生超时）： - ① ssthresh = 当前 cwnd 的一半（⚠️ 但不得小于 2） - ② cwnd 重置为 1 - ③ 重新执行慢开始算法
目的：迅速减少注入网络的分组数量，使发生拥塞的路由器有足够时间把队列中积压的分组处理完。
💡 这就是"乘法减小"：网络频繁拥塞时 ssthresh 下降得很快。
b_256_7拥塞窗口演化的经典例题？ ★4考¶
初始 cwnd = 1，ssthresh = 16： - 慢开始：每轮加倍 1→2→4→8→16；cwnd 到 16 = ssthresh 时改用拥塞避免 - 拥塞避免：每轮 +1，涨到 cwnd = 24 时网络出现拥塞 - 处理：ssthresh = 24/2 = 12，cwnd = 1，重新慢开始 - 之后再涨到 12 时改执行拥塞避免
⚠️ 最容易错的一步：慢开始阶段若 2×cwnd > ssthresh，则下一轮 cwnd = ssthresh 而不是 2×cwnd。 例：第 16 轮 cwnd=8、ssthresh=12 → 第 17 轮 cwnd = 12，不是 16。
★ 考过 2016、2023
b_256_14快重传解决什么问题？ ★1考¶
问题：个别报文段偶然丢失，但网络并未真正拥塞；若等超时才重传，会误判为拥塞并启动慢开始，导致传输效率下降。
快重传的做法： - 接收方不要等到有数据要发送时才捎带确认，而要立即确认 - 收到失序报文段时，立即对最后一个按序到达的报文段发送重复确认（冗余 ACK） - 发送方连续收到 3 个相同的冗余 ACK 就立即重传，无须等待超时计时器到期
★ 考过 2019
b_257_7快恢复和慢开始差在哪一步？¶
收到 3 个冗余 ACK 说明后续多个报文段已成功抵达接收方 → 网络很可能并未严重拥塞。以下按王道 408 简化模型处理： - ssthresh = cwnd / 2（乘法减小，与超时时相同） - ⚠️ cwnd 不重置为 1，而是也设为 cwnd/2（= ssthresh） - 直接进入拥塞避免阶段线性增长
跳过了从 cwnd=1 开始的慢开始过程，所以叫"快恢复"。
教材例子：第 21 轮次 cwnd=16 时收到 3 个冗余 ACK → ssthresh = 8，cwnd = 8，执行拥塞避免。
💡 408 算题口诀："超时：门限减半、窗口归 1、重新慢开始；三个冗余 ACK：门限减半、窗口等于门限、直接拥塞避免"。
⚠️ 经典 Reno 的完整过程更细：3 个重复 ACK 后 cwnd 通常暂时膨胀到 ssthresh+3SMSS；后续重复 ACK 可继续膨胀，收到确认新数据的 ACK 后再收缩。NewReno 对部分 ACK 还另有处理。除非题目明确要求协议细节，408 计算按题设/王道简化模型。
b_257_4；PDF 第 257 页 · b_257_9【疑难点】第5章¶
MSS 设太大或太小各有什么问题？¶
- 太小：网络利用率显著降低 —— 每个 TCP 报文段至少要加 40B 首部（TCP 20B + IP 20B）；极端情况数据仅 1B 时有效载荷占比只有 1/41，再算上帧头尾开销更低
- 太大：IP 层传输时可能超过路径中某段链路的 MTU 而被分片；⚠️ 任一分片丢失，整个报文段都必须重传
⚠️ MSS 的设定与接收方缓存大小或接收窗口无关，主要目的是避免 IP 分片。
原则：MSS 应尽可能大，但以在 IP 层不发生分片为前提。由于互联网路径动态变化，最佳 MSS 难以确定 → TCP 规定默认 MSS 为 536B，即所有主机都应能接收 536B + 20B = 556B 的 TCP 报文段。
b_277_6TCP 用的是 GBN 还是 SR？¶
是 GBN 与 SR 的混合体。
表面上 TCP 用累积确认，类似 GBN；但关键区别： - GBN：接收方丢弃所有失序报文段，发送方要重传从第 k 个开始的所有未确认报文段 - TCP：接收方不丢弃正确到达但失序的报文段，而是缓存，并反复发送冗余 ACK；发送方只重传丢失的第 k 个，后续已缓存的无须重传
⚠️ TCP 还支持 SACK（选择确认）选项：接收方可明确告知哪些非连续数据块已成功接收，使重传行为更接近 SR。
b_277_9为什么超时把 cwnd 置 1，而 3 个冗余 ACK 只减半？¶
因为两种事件反映的拥塞严重程度不同。 - 3 个冗余 ACK：说明后续部分报文段已成功到达（否则触发不了重复确认）→ 网络仍具备一定传输能力，拥塞相对较轻 → cwnd 减半，适度降速 - 超时：意味着连 ACK 都未能及时返回，很可能网络已严重拥塞甚至局部瘫痪 → cwnd 重置为 1MSS，进入慢开始，极其谨慎地重新探测
💡 一句话：超时是重症下猛药，冗余 ACK 是轻症适度退让。
b_278_1为什么不能用两次握手？¶
为了防止已失效的连接请求报文段突然传送到服务器，导致错误建立连接。
场景：A 的 SYN 在网络中长时间滞留，A 超时重传、正常建连、传完数据断开；此后那个旧 SYN 才到达 B。 - 三次握手：B 回 SYN-ACK，A 发现确认序号无效直接丢弃，不回 ACK → 连接建立不起来 - 两次握手：B 收到旧 SYN 就认为连接已建立并等待数据；而 A 根本没有此意图不会响应 → B 长期占用资源，造成浪费
b_278_3为什么初始序号不能固定？¶
若 A 每次都用相同的初始序号（如 1）：A 的某些报文段在网络中滞留较久，A 超时重传并完成通信；这些旧报文段在连接释放后才到达 B，而此时 A、B 已建立一条新连接。
由于新连接仍用相同的初始序号，旧报文段的序号可能落在新连接的有效窗口内 → B 误将其当作新数据接收，造成数据混乱或协议错误。
所以必须采用随时间递增的随机化初始序号，确保迟到的旧报文段序号不会被新连接接受。
b_278_1；PDF 第 278 页 · b_278_3链路无差错、节点不故障，TCP 的可靠交付还有必要吗？¶
有必要。 因为 IP 层本身是无连接且不可靠的，仍可能丢失、失序或重复。典型三种情况： - IP 数据报独立选路，可能到达时失序 - 路由异常可能导致数据报在网中循环，TTL 减到 0 后被丢弃 - 路由器突发拥塞时，来不及处理的数据报会被丢弃
b_278_13【易混点】第5章成对概念对照¶
| 概念 A | 概念 B | 一句话切分 |
|---|---|---|
| 传输层差错检测 | 网络层差错检测 | 首部+数据全检 vs 只检首部 |
| 面向报文（UDP） | 面向字节流（TCP） | 保留报文边界不拆不并 vs 每字节编号可拆可并 |
| 序号 | 确认序号 | 本段第一个字节的号 vs 期望收到的下一个字节号 |
| MSS | MTU | TCP 数据字段最大长度 vs 帧数据部分最大长度 |
| SYN/FIN 报文段 | 纯 ACK 报文段 | 不带数据也消耗一个序号 vs 不带数据不消耗序号 |
| 三次握手 | 四次挥手 | 1RTT 可发数据 vs 客户还要等 2MSL |
| FIN-WAIT-2 | CLOSE-WAIT | 主动方等对方 FIN vs 被动方还能继续发数据（半关闭） |
| 超时重传 | 快重传 | 等计时器到期 vs 收到 3 个冗余 ACK 立即重传 |
| 流量控制 | 拥塞控制 | 接收方定 rwnd（端到端） vs 发送方自定 cwnd（全局） |
| 慢开始 | 拥塞避免 | 每 RTT 加倍（指数） vs 每 RTT 加 1（线性） |
| 超时后 | 3 个冗余 ACK 后 | cwnd=1 重新慢开始 vs cwnd=ssthresh 直接拥塞避免 |
| 持续计时器 | 保活计时器 | 破零窗口死锁 vs 防客户故障占资源 |
【必背数字】第5章¶
| 数字 | 含义 |
|---|---|
| 16 位 / 65536 | 端口号位数 / 端口号总数 |
| 0~1023 / 1024~49151 / 49152~65535 | 熟知 / 登记 / 客户端（短暂）端口号 |
| 21 / 23 / 25 / 53 / 69 / 80 / 161 | FTP / TELNET / SMTP / DNS / TFTP / HTTP / SNMP |
| 8B | UDP 首部长度（4 个字段各 2B）；长度字段最小值也是 8 |
| 12B / 40B | IPv4 / IPv6 计算 UDP、TCP 检验和时使用的伪首部长度 |
| 20B / 60B / 40B | TCP 最小首部 / 最大首部 / 选项最大长度 |
| 4 位，单位 4B，最小值 5 | TCP 数据偏移字段 |
| 2³² | TCP 序号空间（模 2³² 回绕） |
| 2¹⁶−1 | TCP 窗口字段最大值 |
| 536B / 556B | 默认 MSS / 对应的报文段总长（536+20） |
| 3 个冗余 ACK（共收到 4 个确认） | 触发快重传 |
| 1RTT / 1.5RTT | 三次握手后客户 / 服务器最早可发数据的时刻 |
| 1RTT+2MSL / 1.5RTT | 四次挥手客户 / 服务器释放连接的最短时间 |
| 75 秒 / 10 次 | 原书给出的保活实现示例，不是 TCP 固定常数 |
| ssthresh = cwnd/2（不小于 2） | 乘法减小 |
| cwnd = 1 / cwnd = ssthresh | 超时后 / 收到 3 个冗余 ACK 后 |