传输层：TCP的真情告白，UDP的放飞自我

小dora计算机网络闯关记 · Vol.5

"我不只是送包，我是要你收到且完整无缺地感受到！"

------TCP，热恋中永远确认状态的协议

一、传输层是做什么的？

传输层位于网络层之上，是端到端通信的桥梁。它不关心路由和链路，只关心：

✅ 你发了没？我收到了吗？顺序对吗？漏了重发了吗？

两大代表协议：

协议	特点	类比
TCP	面向连接、可靠传输、流量控制、拥塞控制	顺丰快递，签收必问 ✅
UDP	无连接、不保证可靠、无重传机制	平邮明信片，发完随缘 🌀

🧠 小dora类比：

TCP 是"恋爱协议"，从三次握手到四次挥手，步步确认；

UDP 是"洒脱诗人"，我发我爽，你收不收我管不着。

二、端口号：应用层的门牌号

IP地址能找到设备，端口号能找到应用程序。

端口号是 16 位整数，范围 0 ~ 65535

端口号区间	说明
0 - 1023	知名端口（如 HTTP 80，FTP 21）
1024 - 49151	登记端口（软件厂商注册）
49152 - 65535	动态端口（临时分配）

🧠 巧记：

"IP 找人，端口找人干啥；

端口不同，应用不同，别走错门。"

📌 示例：

应用	使用端口	协议
HTTP	80	TCP
HTTPS	443	TCP
FTP	20/21	TCP
DNS	53	UDP（查询） / TCP（区域传送）
SSH	22	TCP
NTP	123	UDP

三、TCP：可靠的化身

核心机制

三次握手：建立连接，确认彼此存在
四次挥手：断开连接，优雅告别
序号 + 确认号：确保数据顺序、避免丢包
滑动窗口：实现流量控制，调节发送速度
拥塞控制：网络拥堵时"踩刹车"，避免爆炸

三次握手过程：

css 复制代码

Client: SYN(x) ───────▶
Server: SYN(y), ACK(x+1) ◀──────
Client: ACK(y+1) ───────▶（连接建立）

每次握手都包含状态同步
握手中交换 ISN（Initial Sequence Number），确认双方通信起点
关键在于"可靠性"而非传输数据本身

🧠 小dora顺口溜：

"你先招手，我再回应，最后我们一起点头。"

⚠️ 防止：

报文重复
半连接攻击

四次挥手过程：

arduino 复制代码

Client: FIN(x) ───────▶
Server: ACK(x+1) ◀──────
Server: FIN(y) ◀──────
Client: ACK(y+1) ───────▶（连接断开）

四次挥手中，FIN 和 ACK 是独立处理的，两次 FIN 各自释放方向通道
Client 最后 ACK 后进入 TIME_WAIT 状态，等待 2MSL 防止历史报文干扰

🧠 巧记口诀：

"我先说拜，你点个头；你再说拜，我再确认。"

四、TCP 的可靠传输机制

机制	功能说明
序号与确认号	追踪哪些字节发送/接收成功
超时重传	未收到确认则重发
流量控制	根据接收端窗口大小调整发送速率
拥塞控制	避免过快发送导致网络崩溃（拥塞窗口）

拥塞控制四阶段：

慢开始：cwnd 指数增长，尝试探测可用带宽
拥塞避免：cwnd 线性增长，避免过快
快速重传：收到 3 次重复 ACK，立即重发丢失数据段
快速恢复：cwnd 减半后直接进入拥塞避免，跳过慢开始

🧠 强化记忆口诀：

"先放慢，试水温；小心走，再提速；

丢了包，马上补；补完后，不再傻快冲。"

五、UDP：简单粗暴，能跑就行

无连接、无序、无确认、不重发
传输单位为"报文段"，不会拆也不会粘
尽管简单，UDP 也有 校验和（Checksum） 提供基本差错检测
适合：语音通话、直播、游戏等时效优先场景

🧠 小dora总结：

"UDP：我不等你，也不找你，来去自如。"

📌 UDP经典应用：

DNS 查询（快速）
VoIP（语音电话）
视频直播（丢一帧不怕）
在线游戏（延迟最怕）

六、应用层协议的选择

应用	协议
HTTP / HTTPS	TCP
FTP / SMTP	TCP
DNS 查询	UDP（响应快）
视频通话 / 游戏	UDP（实时性）

七、小dora知识树 · 传输层总览

复制代码

传输层
├─ TCP
│  ├─ 三次握手 / 四次挥手
│  ├─ 序号 + 确认 + 重传
│  ├─ 流量控制（滑动窗口）
│  └─ 拥塞控制（四阶段）
├─ UDP
│  └─ 无连接、无确认、无序传输
└─ 端口号
   ├─ 公知 / 注册 / 动态端口
   └─ 应用协议选择

📚 例题练习题（附选项解析）

例题 1：TCP 三次握手的主要目的不包括哪项？

选项	分析
A. 确认客户端能发送数据 ✅	❌ 错误，三次握手仅建立连接，不含应用数据传输
B. 确认客户端和服务端都能接收与发送 ✔	正确，双向确认
C. 分配初始序列号 ✔	正确，握手中交换 ISN（Initial Sequence Number）
D. 防止历史连接干扰 ✔	正确，第三次握手确保客户端知道服务端存在

🧠 拓展说明：

三次握手不传应用层数据，主要确保双方 TCP 协议栈"准备就绪"，为可靠传输打下基础。

例题 2：关于 TCP 的拥塞控制，错误的是？

选项	分析
A. 拥塞窗口影响实际发送窗口 ✔	正确，实际发送窗口 = min(接收窗口, 拥塞窗口)
B. 拥塞避免阶段窗口呈线性增长 ✔	正确
C. 快速恢复跳过慢开始 ✔	正确
D. 拥塞避免阶段窗口乘法增长 ❌	错，线性增长才是拥塞避免特征

🧠 拓展说明：

拥塞控制的精髓是"动态适应网络负载"，乘法增长只出现在慢开始阶段。

例题 3：UDP 适合用于以下哪种场景？

选项	分析
A. 电子邮件 ❌	邮件要求可靠，用 TCP
B. 文件下载 ❌	下载需完整性，用 TCP
C. 视频会议 ✅	对实时性要求高，丢少量包可接受，用 UDP
D. 银行转账 ❌	丢一分钱都不行，一定用 TCP

🧠 拓展说明：

UDP 虽然"随缘"，但在直播、游戏中丢几个包比延迟更能被接受。

例题 4：以下关于 TCP 的流量控制说法错误的是？

选项	分析
A. 通过滑动窗口机制实现 ✔	正确
B. 接收窗口由接收端维护 ✔	正确
C. 控制发送速率以防止丢包 ✔	正确
D. 不考虑接收端处理能力 ❌	错误，流控正是为此设计

🧠 拓展说明：

滑动窗口不止控制速率，更重要的是"不让你喂太快我吃撑了"。

例题 5：UDP 不具备以下哪项特性？

选项	分析
A. 无连接 ✔	正确
B. 不保证顺序 ✔	正确
C. 差错检测 ✔	正确（UDP 校验和）
D. 拥塞控制 ❌	UDP 不负责网络拥塞

🧠 拓展说明：

UDP 从不"踩刹车"，它不知道前方堵不堵，开着就冲。