IDC网络传输优化的罪与罚

IDC网络中，deep buffer是原罪，延时是惩罚。

IDC网路拥塞控制，南辕北辙了。

拥塞的本质是对共享资源的争抢，这件事放到网路上，低效的做法却正常了。

操作系统实现中，针对共享资源互斥，自然而然的做法是细粒度拆分临界区，比如Linux内核per-CPU变量越来越多，诡异的是，在网络中遇到同样的问题，做法却相反。

普遍的共识是尽可能避免访问共享资源。比如，当线程进临界区失败，如还有别的路，便不会死等：

// 版本1
if (!spin_trylock(&my_lock)) {do_something_1();
} else {do_something_2();spin_unlock(&my_lock);
}

除此之外就是饱受诟病的死等了：

// 版本2
spin_lock(&my_lock);
do_something_2();
spin_unlock(&my_lock);

还有更拉胯的做法：

// 版本3
retry:if (!spin_trylock(&my_lock)) {sleep(&tiny_slice);goto retry;} do_something_2();spin_unlock(&my_lock);
}

看看网络如何处理共享资源争抢的：

版本1：从来没有用过，但当一个交换机端口拥塞时，别的端口是可以绕路的。
版本2：最常规做法，遇到交换机端口拥塞，就排队等待，直到轮到自己。
版本3：随机访问常规，如CSMA/CD，CSMA/CA以及更古老的ALOHAnet。

低效的自旋以及更低效的retry显然在网络中绝对正确，这和在操作系统的做法截然相反。为什么不能绕路，回答一般是：

绕路不保证最短路径。
绕路可能导致环路。
TCP数据流会乱序。

有道理，但循环论证了，典型的用原因A的结果B去推导原因A本身。

看下面的做法：

交换机A与C之间拥塞时，经由B到C无疑可行。

上面的做法看起来违反常规，其实这才是常规。如果开车想经A到C，发现A到C之间拥堵了，你会在A死等吗？有一条路到B，而且你确信经B可以到C，你肯定会绕行B，是吗？

但话还没有说完，关键还要看AB，BC的开销是否比排队开销更大，若是，就没必要绕行了，反之，绕行就有收益。

人们花大量的精力去研究buffer大小和IDC网络各指标之间的关系，却从没想过绕开它。既然问题的根源是buffer，拿掉它就是了。

还是思维定势。将广域网的那套搬到IDC网络，显然就有问题了。

广域网距离远，传播延时占比大，排队延时占比小，绕行的开销显然过大，于是最短路径就成了广域网路由的首要追求。

但IDC网络传播延时在100us级，排队延时依然在1ms～10ms级，若避开排队，收益将巨大，IDC网络显然可为避排队放弃最短路径。

来看环路问题。

IDC网络是相对规则的比如CLOS胖树，将同级交换机横向连接，为每个交换机以其在该层的位置进行编号，当数据包到达时，实施以下算法，保证数据包始终逐层向下就能避免环路：

if 下出口拥塞if 当前交换机偏左发往右边交换机else发往左边交换机fi
else从下出口发出
fi

收益是大大减少了交换机的buffer配置：

从两边到中间，交换机buffer逐渐减小，中间交换机可以配置极小buffer。

显然，只有最边上的交换机才可能导致不得已排队，因为不能继续转发了，但有同层至少一半交换机可供尝试，下端口同时拥塞的概率非常低。

至于TCP乱序问题，这个问题不值得讨论，将保序放在传输层本来就不合理，为了保序，带宽便无法池化，甚至在广域网上，一半以上的传输性能问题均和保序有关。

…

网络是数据包尽快离开的地方。所有将数据包驻留在网络的措施都不是拥塞控制的目标。buffer的作用是缓解统计突发，用buffer解决拥塞的思路是错误的，拥塞应该疏导才对。

buffer是必要的，互联网是分组交换网，其两个特征都依赖buffer：

统计复用，需要buffer缓存统计突发。
存储转发，需要buffer平滑转发(比如查表)损耗。

对于广域网和IDC网络两者，buffer的作用向两个极端延展：

bufferbloat往往出现在长肥链路的端点处，由于链路长，危害并不算大，如果deep buffer确实始终诱导数据流用尽它们，bufferbloat导致的IDC网络10ms级的延时将是灾难性的，因此在IDC网络事实上应该避免部署deep buffer。

在IDC网络，要部署shallow buffer。但你又需要buffer来缓解大burst带来的丢包所以必须部署deep buffer不是吗？如何是好？所以说，既然burst非常态，当它发生时，绕路不就可以了嘛，方法就是上面说的。

我描述一下CSMA/CD共享式以太网到交换式以太网的进化，看看到底发生了什么。

当CSMA/CD网络进化到交换式网络后，buffer仍然是一个冲突域，二者本质上一致，所不同的是，交换机将CSMA/CD网络分散的buffer集中在一起，以空间换时间。

CSMA/CD网络站点越多，冲突越频繁，整体效能就越低，对应到交换机，deep buffer意味着可以承载更多的冲突，但更多的冲突也意味着成功发送一个数据包的平均时延会更高。

背后的铁律是守恒律，这也是BBR背后的依据。当bottleneck带宽一定，网络半径一定，该网络统计容量就一定，与接入的站点数无关，如果增加buffer，延时必增加，数据包只是从主机网卡转移到了buffer。

数据包发送成功可能是buffer给的假象，被对端接收才真实。有意思的是，CSMA/CD网络中，冲突意味着发送失败被承认，但在交换式网络却假设即便排在buffer中也算发送成功，显然是掩耳盗铃。

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

IDC网络传输优化的罪与罚相关推荐

IDC网络传输优化随想录
在IDC内部,如果你还遵循传统为广域网而生的拥塞控制逻辑做事,那就错了.当然,我下面说的也不一定都对. 正确的做法就好像我之前说的一种情况的反例,那种情况是,让你优化长肥链路传输,你却在优化spinl ...
如何构建全球实时音视频云及其海外网络传输优化
点击上方"LiveVideoStack"关注我们全球不同国家和地区的网络基建水平参差不齐,如何利用有限的网络资源提供更高质量的音视频通话体验是音视频服务商必须面对的挑战.在此次L ...
IDC网络传输新方法-流体渗透原理
IDC网络传输,本周再开一个脑洞. 学过计算机网络这门课程后,反被迷惑.试着回答下图中的两个问题: 数字表示带宽,黑线表示连接,黑线之间的交点表示交换机. 图画成上面这个样子是为了揭示常识,答案很明确 ...
95-846-820-源码-网络-Flink 网络传输优化技术
文章目录 1.概述 2.Flink 计算模型 Credit-based 数据流控制重构 Task Thread 和 IO Thread 的协作模型避免不必要的序列化和反序列化 Object Reu ...
直播平台源码搭建教程盘点直播技术中的编解码、直播协议、网络传输与简单实现
直播平台源码搭建教程盘点直播技术中的编解码.直播协议.网络传输与简单实现 Live CheatSheet | 直播技术理论基础与实践概论音视频直播的基本流程都是采集 → 编码推流 → 网络分发 → ...
一文盘点直播技术中的编解码、直播协议、网络传输与简单实现
本文节选自 Live CheatSheet | 直播技术理论基础与实践概论,很多内容非作者原创,而是对 Live Links 中列举出的多篇文章的盘点总结,更多直播相关内容可以前往 xCompass ...
【转】一文盘点直播技术中的编解码、直播协议、网络传输与简单实现
首页 > 基础知识 > [转载]一文盘点直播技术中的编解码.直播协议.网络传输与简单实现 [转载]一文盘点直播技术中的编解码.直播协议.网络传输与简单实现十一月 2, 2018 Live ...
直播技术中的编解码、直播协议、网络传输与简单实现
Live CheatSheet | 直播技术理论基础与实践概论音视频直播的基本流程都是采集 → 编码推流 → 网络分发 → 解码 → 播放这五大环节,其中又会涉及平台硬件.编解码.网络传输.服务并发 ...
盘点直播直播平台软件开发技术中的编解码、直播协议、网络传输与简单实现
盘点直播直播平台软件开发技术中的编解码.直播协议.网络传输与简单实现编解码视频封装格式就是我们通常所说的 .mp4,.flv,.ogv,.webm 等,它其实就是一个盒子,用来将实际的视频流以一定 ...

IDC网络传输优化的罪与罚

IDC网络传输优化的罪与罚相关推荐

最新文章

热门文章