协议深入系列第 2 篇1. 停等协议为什么不行先看一个最直接的对比。如果 TCP 每发一个段，必须等对应的 ACK 回来才能发下一个，这种模式叫停等（Stop-and-Wait）：发1 → 等ACK1 → 发2 → 等ACK2 → 发3 → 等ACK3 → ...这个模型正确，但效率极低。设 RTT = 100 ms，每段承载 1 KB 有效数据，则最大吞吐量：1 KB / 100 ms = 10 KB/s这是不可接受的。根本原因在于：链路的双向传播延迟内，信道上只有一段数据在飞行。RTT 越长，链路利用率越低。滑动窗口要解决的就是这个问题：允许发送方在收到 ACK 之前，连续发送多个段。2. 窗口的定义与两个核心约束窗口的本质是一个允许发送的字节区间。它的左边界由已确认的最大序列号决定，右边界由左边界加上窗口大小决定。发送方能发送的数据范围 = [SND.UNA, SND.UNA + window)其中 SND.UNA 是最早未确认的序列号。但"能发多少"由两个独立变量共同决定：
协议深入系列第 2 篇1. 停等协议为什么不行先看一个最直接的对比。如果 TCP 每发一个段，必须等对应的 ACK 回来才能发下一个，这种模式叫停等（Stop-and-Wait）：发1 → 等ACK1 → 发2 → 等ACK2 → 发3 → 等ACK3 → ...这个模型正确，但效率极低。设 RTT = 100 ms，每段承载 1 KB 有效数据，则最大吞吐量：1 KB / 100 ms = 10 KB/s这是不可接受的。根本原因在于：链路的双向传播延迟内，信道上只有一段数据在飞行。RTT 越长，链路利用率越低。滑动窗口要解决的就是这个问题：允许发送方在收到 ACK 之前，连续发送多个段。2. 窗口的定义与两个核心约束窗口的本质是一个允许发送的字节区间。它的左边界由已确认的最大序列号决定，右边界由左边界加上窗口大小决定。发送方能发送的数据范围 = [SND.UNA, SND.UNA + window)其中 SND.UNA 是最早未确认的序列号。但"能发多少"由两个独立变量共同决定：
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
