第 5 章 传输层

先把整章压缩成一张逻辑图：

网络层
解决：主机 → 主机
        ↓
传输层
解决：进程 → 进程
        │
        ├── 端口、复用、分用
        │
        ├── UDP
        │     ├── 无连接
        │     ├── 首部 8B
        │     └── 检验和
        │
        └── TCP
              ├── 面向连接、可靠、字节流
              ├── TCP 首部
              ├── 三次握手
              ├── 四次挥手
              ├── 序号 + ACK + 重传
              ├── rwnd：流量控制
              └── cwnd：拥塞控制
                       ├── 慢开始
                       ├── 拥塞避免
                       ├── 快重传
                       └── 快恢复

从资料的“考点追踪”看，真正需要做到看到题就能推的是 TCP：三次握手在 2011、2012、2016、2019、2023 等年份被涉及；连接释放的字段、状态和时间分析在 2016、2020—2024 多次出现；序号确认机制又出现在 2011—2013、2025；流量控制和拥塞控制也长期高频。

一、传输层到底解决什么问题

1. 网络层已经能通信了，为什么还要传输层？

这是理解整章的入口。

假设你的电脑 IP 是 192.168.1.10，同时运行：

Chrome
微信
QQ
Steam
邮件客户端

网络层依靠 IP 地址只能解决：

“这个 IP 数据报应该交给哪台主机？”

但数据到了你的电脑以后，还有一个问题：

“到底应该交给 Chrome，还是微信？”

所以不同层解决的问题是：

因此：

IP 地址找到主机，端口号找到进程。

传输层还负责复用、分用、差错检测，并根据 TCP/UDP 的不同提供可靠或不可靠的逻辑通信。

二、端口、复用和分用

1. 端口号

端口号长度是 16 bit，因此端口号空间共有

即 0～65535。

按资料的分类：

常见端口尤其值得记：

例如，你浏览网页：

客户端：
IP = 10.0.0.5
临时端口 = 52100

服务器：
IP = 1.2.3.4
HTTP端口 = 80

请求可以表示成：

10.0.0.5:52100 → 1.2.3.4:80

服务器响应则反过来：

1.2.3.4:80 → 10.0.0.5:52100

需要特别记住：端口号只有本地意义，TCP 和 UDP 的端口号空间也是相互独立的。同一台主机完全可以同时存在 TCP 53 和 UDP 53。

2. 复用和分用

发送端很多进程可以共同使用 TCP 或 UDP，这叫复用。

Chrome ─┐
QQ ─────┼→ TCP → IP
邮件 ───┘

接收时则反过来：

        ┌→ Chrome
TCP ────┼→ QQ
        └→ 邮件

根据目的端口号把报文交给相应进程，叫分用。

这里经常和前面几层的 SAP 混着考：

资料中特别强调了这一点。

三、TCP 与 UDP 的根本区别

不要简单背“TCP 可靠，UDP 不可靠”，要知道为什么。

一个非常重要的理解是：

TCP 可靠不是因为 IP 可靠。IP 本身仍是不可靠的。

TCP 是在不可靠 IP 上面增加了：

序号
确认
重传
计时器
流量控制
拥塞控制
连接管理

最后才“构造”出一个可靠的逻辑信道。

四、UDP

UDP 相比 TCP 简单很多，但 408 特别喜欢考首部解析和检验和。

1. UDP 特点

UDP 的基本思想可以理解为：

“我知道 IP 不可靠，但我不替你建立复杂的可靠机制。我只加上端口和差错检测，然后尽快发出去。”

因此它没有：

连接建立
ACK
重传
字节序号
流量控制
拥塞控制

这也是 UDP 首部特别短的原因。

五、UDP 首部——选择题常考

UDP 首部固定 8B：

  0               15 16              31
 +------------------+------------------+
 |      源端口       |      目的端口     |
 +------------------+------------------+
 |       长度        |       检验和      |
 +------------------+------------------+
 |                 数据                 |
 +--------------------------------------+

每个字段都是 2B。

尤其要记住：

UDP 的“长度”是UDP 首部 + UDP 数据的总长度。

因此：

资料题库里就有一道典型题：

UDP首部：
CB84 000D 001C 001C

拆开：

CB84 | 000D | 001C | 001C
源端口  目的端口 长度   校验和

其中：

所以 UDP 数据部分不是 28B，而是

这类“十六进制首部解析题”很典型。

六、UDP 检验和——很容易错

这是 UDP 最值得认真掌握的地方。

1. 什么是伪首部

计算 UDP 检验和时，不只是计算：

UDP首部 + UDP数据

还临时构造一个伪首部。

其中包含 IP 层的一些关键信息，例如：

源 IP
目的 IP
协议号
UDP 长度

所以实际用于检验的逻辑结构类似：

伪首部
+
UDP首部
+
UDP数据

但是注意：

伪首部不是 UDP 数据报的一部分。

它：

不会向网络中发送
不会交给应用层
只在发送端、接收端计算检验和时临时使用

而且不仅 UDP 用，TCP 计算检验和也使用伪首部。这是题库明确反复考的坑。

2. 检验和基本过程

考试理解为 16 bit 反码运算即可。

发送端基本过程：

伪首部
   +
UDP 首部（校验和字段先置0）
   +
UDP 数据
   ↓
按 16bit 分组
   ↓
反码求和
   ↓
结果按位取反
   ↓
填入校验和字段

如果数据字节数为奇数，要补一个 0 用于计算。

接收端再对这些内容进行相同的反码运算，以判断是否发生差错。

这里还有一个经典坑：IPv4 UDP 中，检验和字段全 0 可表示“不使用 UDP 检验和”；如果真正计算出的校验和恰好为全 0，为避免含义混淆，发送时改为全 1。题库专门考过。

七、TCP——整章绝对核心

TCP 的特点先记成一句话：

面向连接、可靠、全双工、面向字节流。

尤其“面向字节流”是后面 seq/ack 的根本。

应用程序可能一次给 TCP：

1000B
500B
800B

TCP 不保证这三个“块”原样发送出去，而是把它们看成连续字节流：

字节0 字节1 字节2 …… 字节2299

然后根据需要切成 TCP 报文段。

因此：

TCP 的序号编号对象是字节，不是报文段。

这一句话非常重要。

八、TCP 报文段首部

TCP 固定首部为 20B，可以带选项，所以首部通常写成：

+---------------------+---------------------+
|      源端口          |       目的端口       |
+---------------------+---------------------+
|                    seq                    |
+-------------------------------------------+
|                    ack                    |
+------+--------+-------------+-------------+
|首部长 | 保留   | 控制位      | 窗口         |
+------+--------+-------------+-------------+
|       检验和         |       紧急指针       |
+---------------------+---------------------+
|            选项 + 填充                     |
+-------------------------------------------+
|                 数据                       |
+-------------------------------------------+

高频字段：

TCP 首部长度字段的单位是 4B。

最小首部：

最大值为 15：

所以选项最大：

这个“TCP 首部最小长度”在资料中也被标注为真题考点。

九、最重要的两个字段：seq 与 ack

这是 TCP 大多数计算题的起点。

1. seq

假设：

seq = 301
数据长度 = 100B

那么数据字节是：

301 ～ 400

所以下一个 TCP 数据报文段：

seq = 401

一般规律为：

但是 SYN 和 FIN 是特殊的：

SYN、FIN 即使不携带普通应用数据，也要消耗一个序号。

2. ack

这是最容易做错的地方：

ack=N 不是说“我收到了第 N 个字节”。

而是：

“N 以前已经连续收好了，我现在希望你从 N 开始发。”

即：

意味着：

这一段连续数据已经被正确接收。

例如接收方连续收到了：

501 ～ 700

那么：

资料明确把“序号 + 确认号”列为长期真题重点。

十、累计确认

TCP 通常采用累计确认。

假设发送：

A：[0~2]
B：[3~5]
C：[6~7]

结果：

A 到达
B 丢失
C 到达

虽然 C 到了，但连续字节仍只有：

0~2

所以接收方仍发送：

而不能发 ack=8。

这就是所谓：

ACK 只确认连续、按序到达的字节流。

因此 ACK 丢失也不一定意味着一定要重传。如果后面一个更大的累计 ACK 到达，就可以顺便确认前面的数据。资料配套题对此也专门进行了考查。

十一、TCP 三次握手——★★★★★

这是必须做到闭眼能推的一部分。

假设客户初始序号为 x，服务器初始序号为 y。

客户端                                  服务器
CLOSED                                  LISTEN
  │
  │ SYN=1
  │ seq=x
  │──────────────────────────────────────>
  │                                      SYN-RCVD
  │
  │             SYN=1, ACK=1
  │             seq=y, ack=x+1
  │<──────────────────────────────────────
  │
  │ ACK=1
  │ seq=x+1, ack=y+1
  │──────────────────────────────────────>
ESTABLISHED                         ESTABLISHED

第一握：

SYN=1
seq=x

客户端：

CLOSED → SYN-SENT

SYN 不能携带普通数据，但消耗一个序号。

所以客户端下一个序号：

第二握：

SYN=1
ACK=1
seq=y
ack=x+1

服务器：

LISTEN → SYN-RCVD

服务器既确认客户端：

又发出自己的同步请求。

服务器的 SYN 也消耗一个序号。

第三握：

ACK=1
seq=x+1
ack=y+1

客户端进入 ESTABLISHED；服务器收到后也进入 ESTABLISHED。

第三握可以携带数据；若不携带数据，这个纯 ACK 不消耗普通数据序号。

十二、为什么必须三次，不能两次？

这部分不要背“因为 TCP 规定三次”，要理解。

三次握手实际上需要确认：

A 能发送
A 能接收

B 能发送
B 能接收

第二次握手结束后，客户端已经知道：

客户端 → 服务器：正常
服务器 → 客户端：正常

但是服务器还不知道：

“我发给客户端的 SYN+ACK，客户端到底有没有收到？”

第三次握手让服务器最终知道：

服务器 → 客户端 的链路也确实正常

同时还能防止某些旧的、失效的连接请求突然到达服务器后，让服务器误建立连接并浪费资源。

十三、TCP 连接由什么唯一确定

不是“端口号唯一确定 TCP 连接”。

一个 TCP 端点可写成：

IP地址 : 端口号

即 Socket。

一条 TCP 连接由四元组确定：

源IP
源端口
目的IP
目的端口

所以 Web 服务器完全可以：

服务器:80 ↔ 客户A:50001
服务器:80 ↔ 客户B:50002
服务器:80 ↔ 客户C:61000

同时建立大量连接。

因此：

同一个服务器端口可以服务很多 TCP 连接。

题库里专门出现了“TCP 连接数是否等于端口数”这一类陷阱。

十四、TCP 四次挥手——★★★★★

三次握手建立的是一个全双工连接。

可以想成有两根逻辑管道：

A ─────→ B
A ←───── B

FIN 只表示：

“我这一方向不再发送数据。”

并不代表另一个方向也立即关闭。

所以一般需要双方分别关闭一次，这正是四次挥手的本质。

1. 完整过程

假设客户端主动关闭：

客户端                                    服务器

FIN=1, seq=u
─────────────────────────────────────────>
FIN-WAIT-1                             CLOSE-WAIT

              ACK=1
              seq=v, ack=u+1
<─────────────────────────────────────────
FIN-WAIT-2

              FIN=1, ACK=1
              seq=w, ack=u+1
<─────────────────────────────────────────
                                       LAST-ACK

ACK=1
seq=u+1, ack=w+1
─────────────────────────────────────────>
TIME-WAIT                              CLOSED

等待 2MSL
   ↓
CLOSED

第一次 FIN 消耗一个序号，所以：

这也是为什么最后 ACK 常用：

seq=u+1

第三次服务器 FIN 也消耗一个序号，因此最终确认：

十五、四次挥手状态一定要会

主动关闭方主要状态链：

ESTABLISHED
     ↓
FIN-WAIT-1
     ↓
FIN-WAIT-2
     ↓
TIME-WAIT
     ↓
CLOSED

被动关闭方：

ESTABLISHED
     ↓
CLOSE-WAIT
     ↓
LAST-ACK
     ↓
CLOSED

其中最重要的是：

CLOSE-WAIT

意思是：

“对方已经不发了，但我自己可能还有数据没发完。”

所以 TCP 进入半关闭。

TIME-WAIT

只有主动关闭方通常需要进入。

它要等待：

资料给出了两个原因：

第一，保证最后一个 ACK 丢失后，对方重发 FIN 时，主动关闭方还能再次 ACK。

第二，让网络中残留的本连接旧 TCP 报文段全部自然消失，以免干扰随后建立的新连接。

十六、四次挥手时间题——★★★★★

资料给出的标准考试模型中，如果服务器收到 FIN 后已经无数据可发：

从主动关闭方发出第一次 FIN 开始，

服务器进入 CLOSED 的最短时间为：

主动关闭方进入 CLOSED 的最短时间为：

这里特别容易把“服务器 CLOSED”和“客户端 CLOSED”混为一谈。

被动关闭方收到最终 ACK 就可以 CLOSED。

主动关闭方还要等待 2MSL。

十七、TCP 如何实现可靠传输——★★★★★

可以概括为：

差错检测
+
序号
+
确认
+
超时重传
+
快速重传

可靠的目标是：

无差错
不丢失
不重复
按序交付

十八、超时重传

发送方发送一个需要确认的 TCP 报文段后启动重传计时器。

如果：

发送数据
↓
等待 ACK
↓
计时器超时
↓
仍没收到有效 ACK

就重传。

问题是网络 RTT 会变化，因此 RTO 不能固定得太死。

TCP 会测量 RTT，并维护加权平均往返时间 RTTS，然后设置合适的 RTO。

RTO 太小：

网络只是稍慢
↓
发送方误认为丢包
↓
大量无意义重传

RTO 太大：

真的丢包
↓
等很久才重传
↓
性能差

因此核心原则是：

RTO 要适应网络 RTT，通常略大于估计 RTT。

十九、3 个冗余 ACK 与快速重传——★★★★★

假设发送方依次发送：

1 2 3 4 5

其中：

2 丢了

于是接收方收到：

1
3
4
5

因为它缺少 2，所以虽然 3、4、5 来了，它仍不断告诉发送方：

“我仍然在等 2。”

每收到一个失序报文段，就立即发送相同的冗余 ACK。

于是发送方会看到：

正常ACK
重复ACK
重复ACK
重复ACK

当收到3 个冗余 ACK后：

立即重传丢失的数据

不用等 RTO 超时。

这叫：

快重传 Fast Retransmit

非常重要：

触发快速重传是 3 个冗余 ACK，不是“总共收到 3 个相同 ACK”。

实际通常是：

1 个正常 ACK
+
3 个冗余 ACK
=
4 个相同确认位置的 ACK

资料专门强调了这一陷阱。

二十、流量控制——★★★★★

1. 它到底控制谁？

流量控制解决的是：

接收方来不及处理。

例如：

发送方：
10 Gb/s

接收方应用：
只能消费 1 Mb/s

即使整个网络毫不拥塞，接收缓存最终也可能爆掉。

所以：

流量控制保护的是接收方。

2. rwnd

TCP 接收方维护：

rwnd

即接收窗口。

它代表：

“我的接收缓存目前还能接收多少数据。”

接收方在 TCP 首部的窗口字段里告诉发送方。

发送方就不能发送超过这个窗口的未确认数据。

例如：

rwnd = 400B

意味着发送方当前最多保持大约 400B 的窗口数据处于未确认状态。

资料把基于滑动窗口的 TCP 流量控制标注为 2016、2021 真题考点。

二十一、零窗口与持续计时器

如果接收缓存满：

rwnd=0

发送方必须停止继续发送普通数据。

之后接收方应用程序读取一些数据，缓存重新有空间：

rwnd>0

于是接收方发送窗口更新报文。

但如果这个更新报文丢了：

发送方：
“对方说窗口还是0，我继续等。”

接收方：
“我已经说窗口打开了，我等你发送。”

于是双方死锁。

TCP 用持续计时器解决。

收到 rwnd=0
↓
启动持续计时器
↓
超时
↓
发送零窗口探测报文段
↓
接收方返回当前 rwnd

这样即使原来的窗口更新报文丢失，通信也能恢复。

二十二、流量控制和拥塞控制千万不要混

这是高频概念题。

一句话记：

rwnd 看接收方，cwnd 看网络。

资料也明确用这个角度区分二者。

二十三、TCP 拥塞控制——本章最重要的算法部分

需要掌握两个变量：

cwnd
拥塞窗口

ssthresh
慢开始门限

按照这份资料的 408 计算模型，TCP 的四个核心算法是：

慢开始
拥塞避免
快重传
快恢复

二十四、慢开始 Slow Start

名字叫“慢”，但实际上增长一点也不慢。

假设：

cwnd = 1 MSS

第一轮发 1 个 MSS。

全部确认回来以后：

cwnd = 2 MSS

下一轮发 2 个。

然后：

1
2
4
8
16
...

所以从“传输轮次”的宏观视角看：

近似指数增长。

为什么叫慢开始？

不是因为增长速度慢，而是：

TCP 一开始不敢一下子向网络投入特别多数据，而从很小的窗口试探。

二十五、ssthresh

不能永远：

1 → 2 → 4 → 8 → 16 → 32 → 64 → ...

否则很快就把网络压垮。

所以设置：

ssthresh

当：

cwnd < ssthresh

使用慢开始。

达到门限以后转入拥塞避免。

按资料口径，cwnd=ssthresh 时一般按拥塞避免处理。

二十六、拥塞避免 Congestion Avoidance

慢开始：

1
2
4
8
16

拥塞避免变成：

16
17
18
19
20
...

也就是每经过一个 RTT 左右，只增加约 1 MSS。

所以：

慢开始：指数增长 拥塞避免：线性增长

从考试模型看可以写成：

每个传输轮次近似执行一次。

这叫：

加法增大。

资料中拥塞避免算法被标记为 2009、2017、2020、2022、2023 等年份的考点。

二十七、发生超时怎么办——★★★★★

假设某时刻：

cwnd = 24 MSS

随后重传计时器超时。

按本资料的 408 模型：

然后：

重新慢开始：

1
2
4
8
12
13
14
...

也就是：

超时
↓
ssthresh 减半
↓
cwnd 回 1
↓
重新慢开始

为什么处理这么狠？

因为超时意味着：

网络可能真的发生了比较严重的拥塞。

二十八、3 个冗余 ACK 又怎么办——★★★★★

如果发送方收到 3 个冗余 ACK，通常说明：

某一个段丢了
但是后面的很多段仍然能到

所以网络可能没有“完全堵死”。

于是：

第一步，快重传：立即重传疑似丢失段。

第二步，按资料所用的快恢复模型：

再令：

然后直接进入拥塞避免。

例如：

原 cwnd=16

收到3个冗余ACK

ssthresh=8
cwnd=8

然后：
8 → 9 → 10 → 11 ...

不会：

8 → 1 → 2 → 4 → ...

这就是“快恢复”。

二十九、一张图把拥塞控制全部串起来

              TCP连接刚建立
                    │
                    ▼
               cwnd = 1
                    │
                    ▼
                慢开始
          cwnd 指数规律增大
                    │
           cwnd达到ssthresh
                    │
                    ▼
               拥塞避免
           cwnd线性规律增大
              /           \
             /             \
          超时             3个冗余ACK
           │                    │
           ▼                    ▼
ssthresh=cwnd/2          快重传丢失段
cwnd=1                   ssthresh=cwnd/2
           │             cwnd=ssthresh
           ▼                    │
        慢开始                  ▼
                            拥塞避免

这个图会做，整个 5.3.6 基本就掌握了。

三十、真实发送窗口还要同时受 rwnd 和 cwnd 限制

这是综合题中极重要的一步。

假设：

cwnd = 16KB
rwnd = 6KB

你不能发送 16KB。

因为接收方只允许 6KB。

反过来：

cwnd = 4KB
rwnd = 20KB

你也不能发送 20KB。

因为网络拥塞控制只允许 4KB。

因此发送窗口上限是：

这是 TCP 综合计算题最重要的公式之一。

三十一、408 综合题到底怎样把这些知识串起来

资料里的 2016 真题就是非常典型的“大杂烩”：服务器接收缓存 20KB、MSS 为 1KB、RTT 为 200ms、客户端初始序号 100、初始慢开始门限 32KB，然后连续问三次握手、接收窗口、拥塞窗口、实际发送窗口、下一个序号、平均传输率以及连接释放时间。

这类题不要一个小问一个小问孤立做，而应该在草稿上维护一张状态表：

并且每一轮都检查三个问题：

① cwnd 现在是多少？
② rwnd 现在是多少？
③ min(cwnd,rwnd) 是多少？

然后才决定这一轮到底能发多少。

这比只盯着拥塞窗口可靠得多。

三十二、MSS 的意义

MSS 是：

Maximum Segment Size，最大报文段数据长度。

重点是：

MSS 通常指 TCP 数据部分最大长度，不包含 TCP 首部。

例如：

MSS = 1000B
文件 = 24000B

如果恰好全部按 MSS 分段，则需要：

个数据段。

然后再结合：

cwnd
rwnd
RTT

分析需要多少轮。

题库里就有一个 24KB 文件、MSS=1000B、RTT=10ms、rwnd=6000B 的综合例子。

三十三、本章最常见的“序号算错”模式

假设服务器握手时：

SYN=1
seq=1000

因为 SYN 消耗一个序号，所以服务器的第一个数据字节：

如果之后客户端最终发：

ack=6001

就意味着服务器数据连续收到了：

1001 ～ 6000

应用层数据量：

题库里恰好有这种题。

因此建议看到 TCP 序号题，直接记：

以及：

三十四、TCP 的几个计时器

这一块主要是选择题。

题库直接出过“TCP 有哪些计时器”，四个都属于 TCP 相关机制。

三十五、把整个第五章压缩成做题体系

你复习这一章时，不建议平均用力。按这份资料和题库反映出来的考频，可以按下面顺序掌握：

1. 第一优先级：TCP 的 seq/ack。一定做到给出初始序号、数据长度、SYN、FIN 后能立即算下一个序号和确认号。
2. 第一优先级：三次握手 + 四次挥手。不仅背字段，还要会状态变化、SYN/FIN 是否消耗序号、TIME-WAIT 和 2MSL 时间计算。
3. 第一优先级：流量控制 + 拥塞控制综合。永远先写

再做轮次计算。 4. 第一优先级：慢开始、拥塞避免、快重传、快恢复。看到超时和 3 个冗余 ACK，要立刻区分两条处理路线。 5. 第二优先级：TCP 首部。20B、最大 60B，seq、ack、窗口、ACK/SYN/FIN/RST 等字段必须认识。 6. 第二优先级：UDP 首部与检验和。UDP 8B；长度包含首部；伪首部不发送；TCP/UDP 都使用伪首部计算检验和。 7. 第三优先级：端口、Socket、复用分用。概念简单，但选择题很容易用“一个端口只能建立一个连接”“TCP 和 UDP 端口冲突”等错误说法迷惑你。

如果从一道 TCP 综合题的固定解题顺序来记，第 5 章可以最终压缩为：

先看连接阶段
→ SYN / FIN 是否占序号

再算 seq / ack
→ TCP 按字节编号

再算流量控制
→ rwnd

再算拥塞控制
→ cwnd、ssthresh

再取真正窗口
→ min(rwnd,cwnd)

再按 RTT 推传输轮次

最后若断开连接
→ 四次挥手 + TIME-WAIT + 2MSL

掌握这条链以后，第 5 章很多看似复杂的综合题，本质上都只是把这几套机制叠在一起。