停等协议（Stop-and-Wait Protocol）
停等协议（Stop-and-Wait Protocol）详解
停等协议是最简单的 可靠数据传输协议，用于在不可靠的信道（如存在丢包、延迟、乱序的网络）上实现数据的准确传输。其核心思想是：发送方每发送一个数据包后，必须等待接收方的确认（ACK）才能发送下一个包。如果超时未收到ACK，则重传该包。
1. 停等协议的工作原理
(1) 基本流程
- 发送方：
- 发送一个数据包（Packet #1）。
- 启动计时器（Timeout Timer），等待接收方的ACK。
- 接收方：
- 收到数据包后，校验其正确性（如通过校验和）。
- 若数据无误，返回确认（ACK #1）。
- 发送方：
- 收到ACK #1后，停止计时器，发送下一个包（Packet #2）。
- 若超时未收到ACK，则重传Packet #1。
(2) 关键机制
- 确认（ACK）：接收方返回的应答信号，表示数据已正确接收。
- 超时重传：若发送方在设定时间内未收到ACK，则重发数据包。
- 序列号（Sequence Number）：每个数据包和ACK携带一个序号（通常0或1），用于区分重复包。
2. 停等协议的信道问题与解决
(1) 信道可能的问题
| 问题 | 描述 | 停等协议的应对方式 |
|---|---|---|
| 数据包丢失 | 发送的数据包在中途丢失。 | 超时重传 |
| ACK丢失 | 接收方的ACK丢失，发送方未收到确认。 | 超时重传 |
| 延迟到达 | 数据包或ACK因网络拥堵延迟到达，导致发送方误判为丢失。 | 序列号去重 |
| 信道利用率低 | 发送方必须等待ACK后才能发下一个包，浪费带宽。 | 无直接优化（这是停等协议的固有缺陷） |
(2) 示例场景
- 正常情况：
发送方: 发送 Packet #0 → 接收方: 收到后返回 ACK #0 → 发送方: 收到ACK，发 Packet #1 - 数据包丢失：
发送方: 发送 Packet #0（丢失）→ 超时后重传 Packet #0 → 接收方: 收到后返回 ACK #0 - ACK丢失：
发送方: 发送 Packet #0 → 接收方: 返回 ACK #0（丢失）→ 发送方: 超时重传 Packet #0 → 接收方: 发现重复包（序列号相同），丢弃并重新返回 ACK #0
3. 停等协议的优缺点
(1) 优点
- 简单易实现：只需维护一个未确认的包和计时器。
- 可靠性高：通过超时重传和序列号保证数据不丢失、不重复。
(2) 缺点
-
信道利用率低：
发送方必须等待ACK后才能发送下一个包，导致信道空闲时间长。
计算公式：
[
\text{利用率} = \frac{T_{\text{传输}}}{T_{\text{传输}} + 2 \times T_{\text{传播}}} \quad \text{(假设ACK瞬间返回)}
]
其中：- (T_{\text{传输}})：发送一个包的时间（与包大小和带宽相关）。
- (T_{\text{传播}})：信号在信道中的传播延迟（如光速限制）。
举例：
若传输延迟=1ms，传播延迟=50ms（如卫星链路），则利用率仅为：
[
\frac{1}{1 + 2 \times 50} \approx 1% \quad \text{（极低！）}
] -
不适合高延迟或高速网络：
如卫星通信、光纤高速网络，停等协议会严重限制吞吐量。
4. 停等协议的改进方案
由于停等协议的效率问题，实际网络中常用以下替代协议：
- 滑动窗口协议（Sliding Window）：
- 允许发送方连续发送多个包（窗口大小内），无需逐个等待ACK。
- 典型协议：Go-Back-N、选择性重传（Selective Repeat）。
- 流水线传输（Pipelining）：
- 同时传输多个包，显著提高信道利用率。
5. 实际应用场景
停等协议因其简单性，仍用于以下场景：
- 低速率、低延迟网络：如早期的串行通信（RS-232）。
- 嵌入式系统：资源受限的设备（如传感器网络）。
- 教学示例：帮助理解可靠数据传输的基本原理。
6. 关键总结
| 要点 | 说明 |
|---|---|
| 核心思想 | 发一个包，等一个ACK，超时重传。 |
| 解决的信道问题 | 丢包、ACK丢失、延迟（通过序列号和超时重传）。 |
| 最大缺陷 | 信道利用率低，不适合高延迟或高速网络。 |
| 改进协议 | 滑动窗口、流水线传输（如TCP的滑动窗口机制）。 |
停等协议是理解可靠数据传输的基石，但其效率问题推动了更高级协议（如TCP）的发展。
停等协议所在的网络层次与数据单元（数据包、帧、报文）解析
1. 停等协议属于哪一层？
停等协议是 传输层（Transport Layer） 的协议，主要用于解决 端到端（End-to-End） 的可靠数据传输问题。
- OSI模型定位：第4层（传输层）。
- TCP/IP模型定位：传输层（与TCP/UDP同级）。
为什么不是网络层或数据链路层？
- 网络层（如IP协议）负责 路由和寻址，不保证可靠性。
- 数据链路层（如以太网）负责 相邻节点间的帧传输，同样不保证端到端可靠性。
- 传输层（停等协议、TCP）才是 确保数据从发送方进程准确到达接收方进程 的层级。
2. 不同层级的数据单元对比
网络通信中，数据在不同层级会被封装成不同的形式，名称也不同：
| 层级 | 数据单元名称 | 封装内容 | **示例协议 | 典型设备 |
|---|---|---|---|---|
| 应用层 | 报文（Message） | 应用程序生成的原始数据（如HTTP请求、DNS查询） | HTTP, FTP, DNS | 终端主机 |
| 传输层 | 数据段（Segment） 或 数据报（Datagram） | 报文 + 传输层头（如端口号、序列号） | TCP（段）, UDP（数据报） | 终端主机 |
| 网络层 | 数据包（Packet） | 数据段 + IP头（如源/目的IP地址） | IP, ICMP | 路由器 |
| 数据链路层 | 数据帧（Frame） | 数据包 + MAC头（如源/目的MAC地址） | 以太网（Ethernet）, PPP | 交换机、网卡 |
| 物理层 | 比特流（Bits） | 帧转换为电信号/光信号 | 电缆、光纤 | 集线器、中继器 |
3. 数据单元转换流程（以发送HTTP请求为例）
- 应用层：生成HTTP请求报文（
GET /index.html）。 - 传输层：添加TCP头（源端口
1234+ 目的端口80+ 序列号），封装为 TCP段。 - 网络层：添加IP头（源IP
192.168.1.2+ 目的IP93.184.216.34），封装为 IP包。 - 数据链路层：添加MAC头（源MAC
00:1A:2B:3C:4D:5E+ 目的MAC11:22:33:44:55:66），封装为 以太网帧。 - 物理层：将帧转换为 比特流，通过网卡发送。
4. 为什么停等协议涉及“数据包”这一术语？
- 术语混用：实际中，“数据包”（Packet）常被泛化指代任何层级的数据单元，但严格来说：
- 传输层叫 段（Segment） 或 数据报（Datagram）。
- 网络层才叫 包（Packet）。
- 停等协议的实现：
- 在传输层，停等协议处理的是 段（TCP） 或 数据报（UDP）。
- 但协议设计思想（如序列号、ACK）可应用于其他层级（如数据链路层的ARQ协议）。
5. 其他类似协议的分层对比
| 协议 | 所属层级 | 数据单元 | 功能特点 |
|---|---|---|---|
| 停等协议 | 传输层 | 段/数据报 | 简单可靠传输，逐包确认。 |
| 滑动窗口协议 | 传输层 | 段/数据报 | 连续发送多个包，提高效率（如TCP）。 |
| ARQ（自动重传请求） | 数据链路层 | 帧 | 类似停等机制，但作用于相邻节点（如Wi-Fi）。 |
| IP协议 | 网络层 | 包 | 无连接、不可靠的路由和寻址。 |
6. 关键总结
- 停等协议是传输层协议，解决端到端可靠性，与TCP/UDP同级。
- 数据单元名称严格分层：
- 应用层：报文（Message）
- 传输层：段（Segment）或数据报（Datagram）
- 网络层：包（Packet）
- 数据链路层：帧（Frame）
- 术语混用常见：日常中“数据包”可能泛指任何层级的数据块，但协议设计需明确层级。
理解这些层级和数据单元，是分析网络协议（如TCP vs. UDP、以太网 vs. IP）的基础！