--- tags: [笔试, 微派, TCP, 网络, 协议] create time: 2026-05-16 15:05 --- # 07 - 单选题 5:TCP 滑动窗口 ## 题目 关于 TCP 的**滑动窗口机制**,以下说法**正确**的是: | 选项 | 内容 | |------|------| | A | 滑动窗口大小由接收方根据其可用缓冲区大小动态通告给发送方 | | B | 滑动窗口只解决拥塞控制问题,与流量控制无关 | | C | 滑动窗口一旦确定就不能再改变 | | D | 发送窗口的上限等于接收窗口 + 拥塞窗口 |
点击查看答案与解析 ### ✅ 正确答案:**A** --- ### 详细解析 #### TCP 滑动窗口是什么? ```mermaid flowchart LR subgraph "发送窗口" S1["已发送已确认"] S2["可发送(空闲)"] S3["不能发送(超出窗口)"] end subgraph "时间 →" R1["recv"] --> R2["send ACK"] --> R3["窗口右移"] end S1 -.-> 已经成功传输 S2 -.-> 可以填入新数据 S3 -.-> 必须等待ACK ``` **核心概念**: 发送端维护一个"窗口",窗口内的字节允许发送。当收到 ACK,窗口向前滑动,腾出空间继续发送。 #### 两种窗口机制 | 机制 | 控制方 | 目的 | |------|--------|------| | **接收窗口 (rwnd)** | 接收方通告 | **流量控制** — 防止发送太快撑爆接收缓冲 | | **拥塞窗口 (cwnd)** | 发送端计算 | **拥塞控制** — 防止网络被塞满 | ```mermaid flowchart TD subgraph "发送端的实际窗口" W["有效窗口 = min rwnd, cwnd"] end R["接收窗口 rwnd"] -->|"接收方在ACK中通告"| E[有效窗口] C["拥塞窗口 cwnd"] -->|"发送端算法推算"| E E -.->|限制| SF["发送速率"] style E fill:#f9d09c ``` #### 逐项分析 | 选项 | 正误 | 原因 | |------|------|------| | A | ✅ **正确** | **接收方通过 TCP 首部中的 "Window Size" 字段通知发送方自己还有多少缓冲区可用**。这属于流量控制范畴 | | B | ❌ | **混淆了概念**。滑动窗口同时解决两个问题: rwnd 解决**流量控制**(receiver rate),cwnd 解决**拥塞控制**(network capacity)。说"只解决拥塞"是错误的 | | C | ❌ | rwnd **是动态变化的**! 接收方的缓冲区使用量一直在变,所以在每个 ACK 中都重新通告新的 Window Size。这就是"滑动"的含义之一 | | D | ❌ | 反了! 有效窗口取的是 **min(rwnd, cwnd)**, 即两者中的较小值。不是加和关系。如果 cwnd < rwnd,说明网络瓶颈; 如果 rwnd < cwnd,说明接收方处理不过来 | #### 滑动窗口完整时序 ``` 发送端 接收端 | | |──── data(1-10) ───────────────→│ rwnd = 10000 bytes | │ |←─── ACK 10, win=8000 ─────────│ ACK: 期待下一个序号=10 | │ Window = 8000 bytes |──── data(11-20) ──────────────→│ |←─── ACK 20, win=6000 ─────────│ rwnd 减小(接收缓冲被占用) | │ |←─── ACK 20, win=9000 ─────────│ rwnd 增大(应用层消费了数据) ``` > [!note] 四个关键算法 > - **慢开始 (Slow Start)**: cwnd 指数增长 > - **拥塞避免 (Congestion Avoidance)**: cwnd 线性增长 > - **快重传 (Fast Retransmit)**: 收到 3 个重复 ACK 立即重传 > - **快恢复 (Fast Recovery)**: 不降到 1 MSS,而是减半后继续 > [!tip] 一句话总结 > 滑动窗口 = 流量控制 (rwnd) + 拥塞控制 (cwnd),取两者的较小值作为实际发送窗口。