第 13 卷

• 滑动窗口：发送方维护一个“发送窗口”，窗口内的报文段可连续发送，无需等待逐个确认，大幅

提升传输效率；

• 累计确认：接收方无需为每个报文段单独返回ACK，可对“连续接收的多个报文段”返回一个累计

ACK（如连续接收Seq=100、110、120，可返回Ack=130），减少ACK数量；若中间某报文段丢失，接收方仅返回丢失报文段的序列号对应的ACK，触发快速重传。

1. 面向字节流与报文段重组（保障数据完整有序）

TCP是“面向字节流”的协议，发送方将应用层数据视为连续的字节流，分割为合适大小的报文段发送；接收方收到报文段后，根据序列号重新排序重组为完整的字节流，再交付给应用层，确保数据无

重复、按序到达。

✅ 核心总结

TCP的可靠性是“多机制协同”的结果：以“序列号+确认机制”为核心，通过“超时重传/快速重传”解决数据丢失问题，通过“流量控制/拥塞控制”避免接收方和网络过载，通过“校验和”解决数

据篡改问题，最终实现“数据无丢失、无重复、按序到达”的可靠传输目标。

24. 解释TCP的拥塞控制机制

TCP拥塞控制是TCP保障网络稳定性的核心机制，其核心目标是“在不引发网络拥塞的前提下，最大化利用网络带宽”。当网络中TCP连接过多、数据发送量超过网络承载能力时，会出现数据包丢失、延迟

剧增等拥塞现象，TCP通过“动态调整发送速率”的方式避免加剧拥塞，同时在拥塞发生后快速恢复传输效率。TCP拥塞控制主要通过“四个阶段”和“两个核心参数”实现，主流实现为Reno算法（基于

经典的慢启动、拥塞避免等策略）。

一、核心参数铺垫

• 拥塞窗口（cwnd）：发送方维护的“当前可发送的最大数据量”（以报文段为单位），是拥塞控

制的核心调整对象；发送方实际发送数据量取“cwnd”和“接收窗口（rwnd）”的最小值（即 min(cwnd, rwnd)），兼顾网络拥塞和接收方能力；

• 慢启动阈值（ssthresh）：拥塞控制阶段切换的临界值，初始值通常较大（如为65535字节）；当

cwnd ≤ ssthresh时，进入“慢启动阶段”；当cwnd > ssthresh时，进入“拥塞避免阶段”。

二、拥塞控制的四个核心阶段（Reno算法）

• 增长规则：每收到一个ACK（或每经过一个RTT，往返时间），cwnd加倍（如

1→2→4→8→...）；

• 阶段切换：当cwnd增长到等于ssthresh时，慢启动阶段结束，进入“拥塞避免阶段”；
• 核心目的：快速试探网络带宽上限，同时避免初始发送过多数据引发拥塞（“慢启动”并非慢，

而是相对于直接满负荷发送，前期谨慎增长）。

1. 阶段2：拥塞避免（Congestion Avoidance）⸺ 线性增长，平稳利用带宽：

进入该阶段后，网络已接近承载上限，发送方通过“线性级增长cwnd”避免引发拥塞：

• 增长规则：每经过一个RTT，cwnd仅增加1（如8→9→10→...），增长速度大幅放缓；
• 核心目的：平稳利用网络带宽，避免因指数增长过快导致拥塞；
• 阶段切换：若出现“超时重传”（认为网络已拥塞），进入“拥塞发生阶段”；若出现“快速重

传”（收到3个重复ACK，认为个别数据丢失，网络未严重拥塞），进入“快速恢复阶段”。

1. 阶段3：拥塞发生（Congestion Detection）⸺ 快速降速，缓解拥塞：

当发送方因“超时重传”判断网络拥塞时，立即调整参数并降速，避免加剧拥塞：

• 参数调整：① 将ssthresh设为当前cwnd的一半（ssthresh = cwnd/2）；② 将cwnd重置为1；
• 阶段切换：调整完成后，重新进入“慢启动阶段”，再次试探网络带宽；
• 核心逻辑：通过大幅降速（cwnd重置为1）快速缓解网络拥塞，牺牲短期效率保障网络稳定性。

1. 阶段4：快速恢复（Fast Recovery）⸺ 平稳恢复，减少效率损失：

当发送方因“快速重传”（收到3个重复ACK）判断“个别数据丢失，网络未严重拥塞”时，通过快速恢复机制减少效率损失：

• 参数调整：① 将ssthresh设为当前cwnd的一半（ssthresh = cwnd/2）；② 将cwnd设为

ssthresh + 3（因收到3个重复ACK，说明至少有3个报文段已被接收，可直接恢复部分发送能力）；

• 恢复规则：之后每收到一个重复ACK，cwnd增加1；当收到正常的累计ACK后，将cwnd重置为

ssthresh，进入“拥塞避免阶段”；

• 核心优势：无需像拥塞发生时那样重置cwnd为1，避免重新慢启动的效率损失，在保障网络稳定

的同时快速恢复传输效率。

三、其他补充：拥塞控制的优化算法

• CUBIC算法：Linux系统默认拥塞控制算法，基于Reno算法优化，在高带宽、高延迟网络（如数据

中心网络）中表现更优，通过“三次函数增长”替代线性增长，更快达到网络带宽上限；

• BBR算法：Google提出的基于“带宽延迟乘积（BDP）”的拥塞控制算法，不再通过“丢包”判

断拥塞，而是通过“实际带宽和延迟”动态调整发送速率，在弱网络（如移动端）和高延迟网络中性能更优。

1. 为什么说UDP适合实时应用，如视频会议或在线游戏?

UDP（用户数据报协议）是无连接、不可靠的传输层协议，与TCP的“可靠传输”不同，UDP更注重“传输速度”和“实时性”。视频会议、在线游戏等实时应用的核心需求是“低延迟、数据实时到

达”，而非“数据绝对无丢失”，UDP的协议特性恰好匹配这些需求，因此成为这类应用的首选。具体原因可从“UDP核心特性”与“实时应用需求”的匹配度展开分析：

一、UDP的核心特性（适配实时应用的关键）

1. 无连接，启动速度快（减少连接延迟）

UDP无需像TCP那样进行三次握手建立连接，也无需四次挥手终止连接。客户端和服务端可直接发送数据，无需提前协商参数（如序列号、窗口大小），启动延迟极低。

实时应用匹配度：视频会议、在线游戏均需要“快速启动”，如在线游戏玩家进入房间后需立即响应操作，视频会议需快速建立通信链路，UDP的无连接特性可避免连接过程的延迟，提升用户体验。

1. 无确认、无重传，传输延迟低（保障实时性）

UDP发送数据后，无需等待接收方的ACK确认，也不会因数据丢失而重传。数据发送后立即完成，没有TCP重传计时器的等待延迟和重传开销。

实时应用匹配度：实时应用对“数据时效性”的要求远高于“数据完整性”。例如：在线游戏中玩家的移动、攻击操作数据，若丢失后重传，重传的数据已失去时效性（游戏状态已更新），反而会导致

画面卡顿或操作延迟；视频会议中个别帧数据丢失，仅会导致画面短暂模糊，不会影响整体流畅度，而TCP的重传会导致延迟累积，出现“音画不同步”。

1. 无流量控制、无拥塞控制，发送速率灵活（适配实时数据量）

UDP没有TCP的滑动窗口（流量控制）和拥塞控制机制，发送方可根据应用需求自由控制发送速率，不受接收方缓存和网络状态的限制（仅受物理带宽限制）。

实时应用匹配度：视频会议、在线游戏的数据流是“持续且实时的”，需要稳定的发送速率。例如：

视频会议需按固定帧率（如30帧/秒）发送视频数据，在线游戏需按固定频率发送玩家操作数据，UDP 的灵活发送速率可保障数据按预期频率传输，而TCP的拥塞控制可能因网络波动大幅降速，导致视频卡

顿、游戏掉帧。

1. 协议头部简单，开销小（提升传输效率）

UDP报文头部仅包含“源端口、目的端口、长度、校验和”4个字段，共8字节；而TCP报文头部最小