104 lines
3.7 KiB
Markdown
104 lines
3.7 KiB
Markdown
|
---
|
|||
|
|
tags: [笔试, 微派, TCP, 网络, 协议]
|
|||
|
|
create time: 2026-05-16 15:05
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 07 - 单选题 5：TCP 滑动窗口
|
|||
|
|
|
|||
|
|
## 题目
|
|||
|
|
|
|||
|
|
关于 TCP 的**滑动窗口机制**，以下说法**正确**的是：
|
|||
|
|
|
|||
|
|
| 选项 | 内容 |
|
|||
|
|
|------|------|
|
|||
|
|
| A | 滑动窗口大小由接收方根据其可用缓冲区大小动态通告给发送方 |
|
|||
|
|
| B | 滑动窗口只解决拥塞控制问题，与流量控制无关 |
|
|||
|
|
| C | 滑动窗口一旦确定就不能再改变 |
|
|||
|
|
| D | 发送窗口的上限等于接收窗口 + 拥塞窗口 |
|
|||
|
|
|
|||
|
|
<details>
|
|||
|
|
<summary>点击查看答案与解析</summary>
|
|||
|
|
|
|||
|
|
### ✅ 正确答案：**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)，取两者的较小值作为实际发送窗口。
|
|||
|
|
|
|||
|
|
</details>
|