Files
leetcode-go/笔试/微派 Test1/07-单选题5-TCP滑动窗口.md
T

3.7 KiB
Raw Blame History

tags, create time
tags create time
笔试
微派
TCP
网络
协议
2026-05-16 15:05

07 - 单选题 5:TCP 滑动窗口

题目

关于 TCP 的滑动窗口机制,以下说法正确的是:

选项 内容
A 滑动窗口大小由接收方根据其可用缓冲区大小动态通告给发送方
B 滑动窗口只解决拥塞控制问题,与流量控制无关
C 滑动窗口一旦确定就不能再改变
D 发送窗口的上限等于接收窗口 + 拥塞窗口
点击查看答案与解析

✅ 正确答案:A


详细解析

TCP 滑动窗口是什么?

flowchart LR
    subgraph "发送窗口"
        S1["已发送已确认"]
        S2["可发送(空闲)"]
        S3["不能发送(超出窗口)"]
    end
    
    subgraph "时间 →"
        R1["recv"] --> R2["send ACK"] --> R3["窗口右移"]
    end
    
    S1 -.-> 已经成功传输
    S2 -.-> 可以填入新数据
    S3 -.-> 必须等待ACK

核心概念: 发送端维护一个"窗口",窗口内的字节允许发送。当收到 ACK,窗口向前滑动,腾出空间继续发送。

两种窗口机制

机制 控制方 目的
接收窗口 (rwnd) 接收方通告 流量控制 — 防止发送太快撑爆接收缓冲
拥塞窗口 (cwnd) 发送端计算 拥塞控制 — 防止网络被塞满
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),取两者的较小值作为实际发送窗口。