幕雪

滑动窗口协议工作原理、用途、参数与细节





在网络通信的世界里，确保数据可靠且高效地从发送方传输到接收方是一个核心挑战。网络链路并非完美，可能存在丢包、损坏、乱序等问题。同时，发送方不能一股脑地发送所有数据，以免淹没接收方或网络本身。为了解决这些问题，各种机制应运而生，其中，滑动窗口协议便是解决可靠性与效率矛盾的经典方案之一。

什么是滑动窗口协议？

简单来说，滑动窗口协议是一种流量控制和错误控制的技术。它通过在发送方和接收方之间维护一个“窗口”来实现。这个窗口代表了一系列连续的帧或数据包的序号范围，在这个范围内的数据可以被发送或接收。

发送窗口 (Sender Window)

发送方维护一个发送窗口。这个窗口包含以下几类数据包的序号：

  • 已经发送但尚未收到确认 (ACK) 的数据包。
  • 准备发送的数据包（在窗口范围内）。

窗口的大小（发送窗口大小，SndWnd）决定了发送方在未收到确认的情况下可以连续发送的最大数据包数量。发送方只能发送序号落在其当前窗口内的数据包。

接收窗口 (Receiver Window)

接收方也维护一个接收窗口。这个窗口表示接收方当前准备好接收的数据包的序号范围。

  • 期望按序接收的下一个数据包的序号 (RcvNxt)。
  • 在窗口范围内、可能乱序到达并已被缓存的数据包。

窗口的大小（接收窗口大小，RcvWnd）决定了接收方能够接收的最大乱序数据量以及其处理能力。接收方通常只接受序号落在其当前窗口内的数据包。

“滑动”体现在当数据包被成功发送并确认（发送方）或成功接收并按序交付给上层应用（接收方）时，窗口会向前移动。

为什么需要滑动窗口协议？

为什么点对点的数据传输需要这么一个复杂的机制呢？直接发送所有数据或者每发一个等一个确认不好吗？

解决“停等协议”的低效率

最简单的可靠传输协议是“停等协议”(Stop-and-Wait)。发送方发送一个数据包，然后必须停下来等待接收方的确认。只有收到确认后，才能发送下一个数据包。这种方式在网络延迟较高时效率极低，大部分时间都浪费在等待确认上，传输信道利用率非常低。

滑动窗口协议允许发送方在等待第一个数据包确认的同时，继续发送后续的数据包，只要这些数据包的序号在发送窗口内。这极大地提高了信道的利用率，实现了流水线效应 (Pipelining)。

实现流量控制 (Flow Control)

如果发送方发送数据的速度远超接收方的处理能力，接收方的缓冲区会溢出，导致数据丢失。滑动窗口协议通过接收窗口的大小来限制发送方可以发送的数据量。接收方通过在确认报文中告知发送方其当前的接收窗口大小，从而控制发送方的发送速率。这是一个端到端的控制，防止慢速的接收方被快速的发送方淹没。

实现错误控制 (Error Control)

滑动窗口协议通过以下机制处理网络中可能出现的错误：

  • 确认 (ACK): 接收方发送确认报文告知发送方哪些数据包已成功接收。
  • 超时与重传 (Timeout and Retransmission): 发送方为每个已发送但未确认的数据包设置定时器。如果定时器超时仍未收到确认，则认为数据包丢失或确认丢失，发送方会重传相应的数据包。
  • 序号 (Sequence Numbers): 用于标识每个数据包的顺序，帮助接收方检测重复和乱序的数据包。

不同的滑动窗口协议变体（如 Go-Back-N 和 Selective Repeat）在错误处理和确认策略上有所不同，以在实现复杂度和效率之间进行权衡。

滑动窗口在哪里使用？

滑动窗口协议的思想被广泛应用于计算机网络的各个层次，特别是在需要提供可靠数据传输的协议中。

  • 传输层 (Transport Layer):

    • TCP (Transmission Control Protocol): TCP 是互联网中最著名的使用滑动窗口协议的例子。TCP 的窗口机制非常复杂且强大，它不仅用于流量控制，还与拥塞控制 (Congestion Control) 紧密结合，动态调整发送窗口的大小，以适应网络拥堵状况。TCP 使用累计确认和选择性确认 (SACK) 来提高效率和容错性。
  • 数据链路层 (Data Link Layer):

    • 一些数据链路层协议，如 HDLC (High-Level Data Link Control) 和 PPP (Point-to-Point Protocol)，在面向连接的工作模式下也使用了滑动窗口机制来确保帧的可靠传输和流量控制，尤其是在点对点链路上。

滑动窗口涉及多少参数？

滑动窗口协议的核心参数主要有两个：

  • 窗口大小 (Window Size):

    • 发送窗口大小 (SndWnd): 决定了发送方在未收到确认前最多可以发送的数据包数量。
    • 接收窗口大小 (RcvWnd): 决定了接收方可以接受的数据包序号范围。通常情况下，为避免接收方缓冲区溢出，发送窗口的大小不应超过接收窗口的大小（在流量控制层面）。在 TCP 中，接收窗口由接收方通知给发送方。
  • 序号范围 (Sequence Number Range):

    • 数据包的序号用于唯一标识数据。序号是有限的，会循环使用。例如，如果使用 N 位来表示序号，则序号范围通常是 0 到 2N – 1。
    • 序号范围必须足够大，以避免序号的歧义。一个关键的要求是，发送窗口的大小加上接收窗口的大小（理论上是发送方可能发送但接收方尚未确认的最大范围）不应该超过序号空间的一半。否则，当序号循环使用时，发送方或接收方可能会混淆新的数据包和旧的重传数据包。对于 Go-Back-N 协议，要求发送窗口大小严格小于序号空间的大小；对于 Selective Repeat，要求发送窗口大小和接收窗口大小都小于等于序号空间的一半。

滑动窗口如何工作？（详细机制）

滑动窗口协议的具体工作流程可以从发送方和接收方两个角度详细描述：

发送方操作

  1. 维护窗口状态: 发送方维护三个重要的序号：

    • SndLBA (Send Base / Last Byte Acked): 已发送并收到确认的最后一个数据包的序号的下一个序号。这是发送窗口的下界。
    • SndNxt (Send Next): 下一个待发送的数据包的序号。
    • 发送窗口的上界是 SndLBA + SndWnd - 1。
  2. 发送数据: 当应用层有数据需要发送时，发送方检查当前数据包的序号是否在发送窗口 [SndLBA, SndLBA + SndWnd - 1] 内。

    • 如果在窗口内，发送方分配序号，将数据封装成数据包，发送出去，并将数据包在本地缓存（等待确认）。同时，启动该数据包的重传定时器。然后将 SndNxt 加一。
    • 如果窗口已满 (即 SndNxt == SndLBA + SndWnd)，发送方暂停发送新的数据，等待窗口滑动。
  3. 接收确认 (ACK): 发送方接收来自接收方的确认报文。

    • 确认报文通常包含一个序号，表明接收方已成功接收到该序号（或该序号之前所有）的数据。
    • 根据收到的确认信息，发送方更新 SndLBA。例如，如果收到对序号 N 的确认（在累计确认方式下），意味着序号 N 及之前的所有数据包都已到达接收方。发送方将 SndLBA 更新为 N + 1。
    • 当 SndLBA 更新时，发送窗口随之向前滑动。此时，之前窗口中位于 SndLBA 之前的数据包可以从缓存中移除，并停止相应的定时器。
    • 窗口滑动后，发送方可以继续发送新的数据包（如果应用层有数据且新序号在窗口内）。
  4. 处理超时: 如果某个数据包的定时器超时，说明该数据包或其确认可能已丢失。发送方会重传这个数据包（在 Go-Back-N 中是重传超时数据包及其之后所有已发送的数据包；在 Selective Repeat 中只重传超时的数据包）。重传后，重启该数据包的定时器。

接收方操作

  1. 维护窗口状态: 接收方维护两个重要的序号：

    • RcvNxt (Receive Next): 期望按序接收的下一个数据包的序号。这是接收窗口的下界。
    • 接收窗口的上界是 RcvNxt + RcvWnd - 1。
  2. 接收数据: 接收方收到一个数据包 P。

    • 如果 P 的序号等于 RcvNxt: 这是按序到达的数据包。接收方将 P 交付给上层应用。然后，检查后续缓存中是否有连续的、已按序收到的数据包（序号分别为 RcvNxt+1, RcvNxt+2 等）。将这些连续的数据包一并交付给上层应用，并相应地更新 RcvNxt（向前滑动接收窗口）。最后，发送一个确认报文，报文中的确认序号通常是新的 RcvNxt。
    • 如果 P 的序号大于 RcvNxt 且在接收窗口 [RcvNxt, RcvNxt + RcvWnd - 1] 内: 这是乱序到达的数据包。接收方会缓存这个数据包（如果协议支持乱序接收，如 Selective Repeat）。对于 Go-Back-N，乱序数据包通常会被丢弃。接收方可能会发送一个重复的确认报文，确认它期望接收的下一个按序数据包（即 RcvNxt）。
    • 如果 P 的序号小于 RcvNxt 或超出接收窗口: 这是一个重复的或无效的数据包，通常会被丢弃。接收方可能会发送一个确认报文，告知发送方其期望的下一个按序数据包是 RcvNxt。
  3. 发送确认 (ACK): 接收方在接收到（或处理完）数据包后发送确认。确认策略有所不同：

    • 累计确认 (Cumulative ACK): 接收方发送的确认序号 N 表示它已成功接收并按序处理了所有序号小于 N 的数据包。即使收到了序号大于 N 的数据包，发送的确认序号仍然是 N，直到序号为 N 的数据包到达并被处理。Go-Back-N 协议使用这种方式。
    • 选择性确认 (Selective ACK – SACK): 接收方可以确认不连续的数据块。例如，它可以确认已收到数据包 3、4 和 6，尽管 5 尚未收到。TCP 支持 SACK 选项。这允许发送方只需要重传那些真正丢失的数据包。

滑动窗口大小如何确定？

滑动窗口的大小是一个关键的性能参数。理论上，最优的发送窗口大小应该能够让发送方持续发送数据，填满“信道管道”，从而最大化信道利用率。这个最优大小通常由带宽-延迟积 (Bandwidth-Delay Product, BDP) 决定。

带宽-延迟积 (BDP) = 信道带宽 (bits/sec) × 往返时间 (Round Trip Time, RTT, seconds)

BDP 表示在任何时刻，信道中可能在传输的数据量（以比特为单位）。

理想的发送窗口大小（以比特为单位）约等于 BDP。如果窗口太小，发送方会频繁等待确认，信道未被充分利用；如果窗口太大，可能导致发送方发送过多数据，超过接收方处理能力或网络承载能力。

然而，实际的窗口大小还受到其他因素的限制：

  • 接收方缓冲区大小: 接收方只能接收并缓存有限的数据量。发送方通告的接收窗口大小是其能处理的上限。
  • 网络拥塞: 在 TCP 中，窗口大小不仅用于流量控制，还用于拥塞控制。当网络出现拥塞迹象时（例如，丢包、RTT增加），发送方会减小发送窗口的大小，以减轻网络负担。
  • 序号空间大小: 如前所述，为避免序号歧义，窗口大小受到序号范围的限制。

因此，实际的滑动窗口大小是一个动态调整的过程，特别是在像 TCP 这样的协议中，它会根据接收方的反馈（流量控制）和网络状况（拥塞控制）不断变化。

总而言之，滑动窗口协议通过巧妙地管理发送和接收的数据包序号范围，并结合确认和超时机制，实现了在不可靠网络上的高效可靠数据传输。它是一个基础且重要的网络协议概念。


滑动窗口协议