源抑制与智能转发-CSDN博客

1984年，Nagle，RFC896

初学网络时，几乎都学过 ICMP 源抑制，但互联网上几乎没有 ICMP 源抑制报文。它为何被取消了？

拥塞的成因有两个：

• 主观成因：每条流均想独占带宽，没人想排队，一旦汇聚必然排队，大家要排队，队列趋长，内卷化。
• 客观成因：统计复用系统的固有属性，随机到达过程导致。提高控制精度可缓解，但不能根本解决。

考虑主观成因，不能期望端到端拥塞控制起作用，每个端的潜意识都想做手脚避开拥塞控制。不能指望端都会正确合理响应 ICMP 源抑制报文，甚至无法保证它们会响应。

ICMP 报文不确保被转发，端主机不保证响应，要它何用？干脆在系统中内置端到端算法。拥塞控制算法成了系统的一部分，用户不易修改。

系统保证预防拥塞崩溃的 AIMD 机制不被破坏。懂 Linux 内核的可随意改算法，但大部分人不能，最近，QUIC 将拥塞控制实现在库里，撕开一个大口子，小白都可以改算法，这不是好事。

总之，类似源抑制的拥塞控制机制，很难控制拥塞，它就 “失传” 了。

另一方面，在 IDC 内部，各种 PFC，INT 令人眼花缭乱，NPCC(主动拥塞控制)如火如荼，所谓智能交换机也就是 “可将拥塞信息直接反馈到发送端”，这不就是源抑制么？它又回来了？
重点还是合作 or 博弈。

IDC 不存在动手脚的发送端，即便只是有服务器改大了初始窗口，经理也会派人改回去，IDC 处在一个可控状态，经理勒令所有发送端必须合作。因此，在 IDC 不存在拥塞控制领域遍布的博弈论，运筹学，社会学背景。

不是源抑制回来了，是场景变了。Internet 和 IDC内网往相反方向看就对了，Internet 在胖端瘦网中获益，IDC 则在胖网瘦端中获益，这么看，智能交换机还不够智能，反压算什么，直接疏导啊。

交换机能缓存数据吗，类似 Kafka 既存储又转发，交换机可支持 “拉” 吗？或者只在最后几跳 “拉”？交换机可缓存数据代为重传吗，类似 I-TCP，Snooping TCP 那般？这鞋子能跳舞吗？… 可不仅仅源抑制。

说起智能交换机，其实 Internet 也能玩，特别是 lastmile。不过要换个名字，叫智能转发吧，或智能交换机也可统一叫做智能转发。

像 I-TCP，Snooping TCP 这种需要定制 AP，场面过大。可接入 PCDN，雾计算场景，盒子做重传代理，就能解决重传延时过久的大部分问题。无论怎样，Internet 的智能转发还是更接近端，部署在 lastmile 尽头，这里也是人们在运营商和内容商之外，唯一可玩点儿花样的地方。

浙江温州皮鞋湿，下雨进水不会胖。