Lesson 13 作为总体的网络系统

网络的核心挑战在于共享。在单机内部，操作系统内核可以强制调度 CPU 和内存。但在分布式的互联网中，没有一个上帝来指挥谁该发多少数据。这种缺乏全局协调的共享，必然导致拥塞。

其实这章就是计算机网络著名的拥塞控制

1. 网络拥塞与崩溃

1.1 拥塞的产生

• 根源：网络是分布式、动态共享的。用户需求的总和往往超过网络传输能力的上限。
• 恶性循环：
  1. 流量 > 容量 $\rightarrow$ 路由器缓冲区满。
  2. 排队变长 $\rightarrow$ 丢包。
  3. 发送端超时未收到确认 $\rightarrow$ 重传。
  4. 网络负载进一步上升（包含正常包 + 重传包） $\rightarrow$ 更多丢包。
  5. 拥塞崩溃：有效吞吐量急剧下降，带宽全被重传的垃圾数据占满。

1.2 拥塞 vs 排队

• 排队：是局部的（在某个节点）、暂时的。就像红绿灯前的等待，是拥塞的前兆。

  因为转发的数据需要被处理，在每个节点（主机or路由器）都需要在缓冲区排队等待转发

• 拥塞：是全局的（对于整个网络而言）、持续的。是整体负载超过了整体资源。

  无法确定是哪个节点崩了

• 解决思路：

  • 增加容量（扩容带宽）：不现实，物理受限。
  • 减少负载：唯一可行方案。必须让发送端主动减少发送。

2. 跨层协作：拥塞控制

由于网络层（IP）是“尽力而为”的，它不提供流量控制功能，解决拥塞的重任落在了**传输层（TCP）**身上。

2.1 反馈机制

发送端如何知道网络堵了？

• 网络层：路由器丢弃数据包（这是唯一的信号）。
• 传输层：检测到丢包（超时或重复ACK）或RTT 变大，推断出网络发生了拥塞。

2.2 TCP 拥塞控制算法

这个地方讲得比较简洁，补了一张详细一点的说明图在最后

早期的 TCP 只有流控（rwnd），导致了严重的拥塞崩溃。现代 TCP 引入了拥塞窗口（cwnd）。

核心公式：
$$实际发送窗口 = \min(rwnd, cwnd)$$

• rwnd (接收窗口)：保护接收方，由接收方告知。
• cwnd (拥塞窗口)：保护网络，由发送方估算。

算法的四个阶段：

1. 慢启动：

   • 策略：连接刚建立时，cwnd = 1 MSS（最大报文段）。每收到一个 ACK，cwnd 加倍（指数增长）。
   • 目的：快速探寻网络的容量上限。
   • 结束：当 cwnd 达到慢启动阈值 (ssthresh) 时，转入拥塞避免。

2. 拥塞避免：

   • 策略：每经过一个 RTT，cwnd 只增加 1 MSS（线性增长）。
   • 目的：小心翼翼地试探带宽，避免过快触发丢包。

3. 拥塞发生：

   • 当检测到丢包（超时）时，认为网络严重拥塞。
   • 反应：ssthresh 设为当前 cwnd 的一半，cwnd 重置为 1，重新进入慢启动。

4. 快重传与快恢复：

   • 场景：收到 3 个重复的 ACK（说明包乱序或轻微丢包，网络没全断）。
   • 反应：立即重传丢失的包，不等待超时。ssthresh 减半，cwnd 减半（而不是重置为 1），然后进入线性增长。

2.3 AIMD (加法增，乘法减)

TCP 的宏观行为被称为 AIMD (Additive Increase, Multiplicative Decrease)。

• 没丢包时：线性增加窗口（试探）。
• 丢包时：乘法减少窗口（紧急刹车）。
• 意义：这种策略已被证明是保证多用户公平性和系统稳定性的最佳策略。

3. 案例分析：失败的教训

课程通过两个反面教材，展示了忽视拥塞控制的后果。

3.1 NFS 拥塞崩溃

• 背景：NFS（网络文件系统）基于 UDP，早期设计认为局域网很快，不需要复杂的流控。
• 问题：客户端请求超时 $\rightarrow$ 重发请求。由于 NFS 服务器处理慢，重发的请求进一步挤占了队列。
• 结果：网络利用率极高，但全是重传包，服务器实际处理的有效工作为零。
• 修正：引入指数退避计时器。

3.2 Autonet 广播风暴

• 背景：一个自动配置的局域网系统。
• 问题：链路层使用了双绞线，信号会有回声（Echo）。网桥错误地把回声当成了新的广播包进行了转发。
• 涌现效应：物理层的特性（回声）与链路层的转发逻辑形成了死循环，瞬间占满所有带宽。
• 启示：系统不同层级之间看似不相关的特性，组合在一起可能引发灾难。

---

4. 对照

Lesson 13 Network Systems as a Whole

In previous lessons, we designed the Link Layer, Network Layer, and Transport Layer. Now, we assemble these components together.

The core challenge of this lesson is Sharing. Inside a single machine, the kernel can enforce scheduling; but in the distributed Internet, there is no “God” to direct traffic. This lack of global coordination inevitably leads to Congestion.

This chapter essentially discusses: When everyone wants to use the network, how do we ensure the network doesn’t become paralyzed due to “too many cooks in the kitchen”?

1. Network Congestion and Collapse

1.1 Origins of Congestion

• Root Cause: The network is distributed and dynamically shared.
• Vicious Cycle: Traffic > Capacity $\rightarrow$ Router queues fill up $\rightarrow$ Packet Drops $\rightarrow$ Timeout & Retransmission $\rightarrow$ Higher Load $\rightarrow$ Collapse.
  • Collapse means: The bandwidth is saturated, but it’s full of retransmitted garbage data, and no effective data gets through.

1.2 Congestion vs. Queuing

• Queuing: Local and transient (like a traffic light).
• Congestion: Global and sustained (like a city-wide gridlock).
• Solution Strategy: Increasing capacity is unrealistic; we can only Reduce Load. The sender must “voluntarily” send less.

2. Cross-Layer Collaboration: TCP Congestion Control

The Network Layer (IP) only drops packets and does not handle flow control. The heavy lifting of resolving congestion falls on the Transport Layer (TCP).

2.1 Feedback Mechanism

How does the sender know there is a traffic jam?
Implicit Feedback: No one sends a specific message telling TCP “it’s congested.” When TCP detects Packet Loss (Timeout or Duplicate ACKs) or Increased RTT, it assumes the network is congested.

2.2 Core Algorithm: Congestion Window

Modern TCP introduces the Congestion Window (cwnd), which is “my estimation of the maximum load the network can bear.”
Actual Send Window = min(Receiver rwnd, Network cwnd).

TCP Operation Process (AIMD):

1. Slow Start:
   • At the beginning, the network capacity is unknown, so send 1 packet. OK? Send 2. OK? 4… Exponential Growth, rapidly approaching the limit.
2. Congestion Avoidance:
   • After reaching the threshold (ssthresh), switch to Linear Growth (+1 each time), probing carefully.
3. Congestion Event (Fast Retransmit/Timeout):
   • Once packet loss occurs (receiving 3 duplicate ACKs or timeout), it indicates the limit has been reached.
   • Multiplicative Decrease: Cut the threshold and window in half (or reset to 1), instantly reducing speed to alleviate congestion.

AIMD (Additive Increase, Multiplicative Decrease) is the cornerstone of Internet stability: Add slowly when network conditions are good, cut in half immediately when problems occur, ensuring fairness and preventing collapse.

3. Case Studies and Lessons

• NFS Collapse: Early NFS clients retransmitted immediately upon timeout. As a result, the server couldn’t cope, the network was flooded with retransmission packets, and the system paralyzed. The solution is Exponential Backoff (wait longer before retrying after failure).
• Autonet Broadcast Storm: Physical layer signal echoes were treated as new packets by the link layer and forwarded infinitely, causing a network loop.