当数据中心成为数据中转节点(漫谈CDN的加速)

先引用自己的两篇文章：
流水线式的TCP中继代理是如何提高吞吐的 ：https://blog.csdn.net/dog250/article/details/83997773
eBPF/sockmap实现socket转发offload ：https://blog.csdn.net/dog250/article/details/103629054

TCP是一个对长距离大带宽(长肥管道)传输很不友好的端到端协议，它既保证不了效率(对丢包很敏感)，又保证不了公平性(对时延很不敏感)，它只是一个 收敛于刚刚可用 的协议，TCP，是垃圾！

依靠数据中继，TCP可以将传输行为流水线化，慢启动窗口在短RTT内快速打开，对丢包的敏感通过对对时延的敏感来补偿，从而最大化吞吐，这是TCP性能优化的一个创举，而eBPF可以作为TCP数据中继实现的一个具体的技术。

两篇文章所谈的技术相结合，周末我来扯一下这背后的动机和意义。

当我们关注数据包是如何从起点到达终点的时候，我们被告知这一切都基于 IP路由！

TCP/IP分层模型让路由器在数据包逐跳选路的过程中扮演了核心角色。整个互联网看起来是由一堆路由器织成的：

上图中所示的最短路径是通过一种叫做动态路由的协议计算出来的，每一台路由器都会运行这类路由协议并且参与全网任意两点间最短路径的计算，这是一个 全网协作的分布式过程 。

在全网全部路由器分布式协作的前提下，我们可以想象计算结果是 全局最优 的。

如果你非要抬杠说在效果上并不是最优的，那是因为路径度量不准确而导致，并不是路由协议本身的问题，类似Floyd算法和Dijkstra算法都可以从数学上严格证明结果是全局最优的。

路由器仅仅提供选路和转发的功能，它们并不会产生或者消费数据包，那么数据内容是如何产生的呢？

我就简单点说吧，当整张由路由器织成的网络成型时，运营商维护并管理着这张网络，运营上提供 接入服务 并且获得收入，数据的生产者比如说某某门户网站，某某大学接入运营商的网络并且为之付费，从而让自己的数据可以释放到网络上。

另一方面，数据的消费者，也就是普通用户，花钱订阅运营商的上网服务，用这种方式接入互联网，因此运营商将数据的生产者和数据的消费者通过路由器组成的这张网连接了起来。

到目前为之，没有看出这有什么问题。

…

哦，我可能忽略了一点，那就是 提供内容的网站服务器放在什么地方？？

每一个网站的主人都不想让自己成为重资产的经营者，因此运营商可以提供机房和服务器的租用服务，运营商因此构建了大量的机房，这些机房多数和接入层路由直连，少数和汇聚路由器直连以提供更优质的服务：

任何人都可以租用运营商的数据中心服务，构建自己的网站成为一个内容提供者，这大概就是web 1.0时代的事了。

在这个时期，各级运营商提供的IP路由始终如一地免费提供最优路径服务，最优路径成了互联网的属性。

…

大概从web 2.0开始，随着交互的增多，多到移动互联网时代无以复加的程度，流量也随之爆发增长。

按字节付费给运营商已经越来越不划算，这使得这期间诞生的巨头互联网内容提供商开始想另外的对策。

大概就是腾讯，百度，阿里这一批吧。

自己挖地埋光缆显然更不划算，甚至不被gov允许，但是盖两幢房子的钱还是有的。因此类似BAT这类公司开始自建机房，然后仅仅租用运营商最最底层的传输介质。

互联网公司开始部署各大自建节点，越来越密集，其效果就是 让用户在最近的地方获取需要的数据！

这便是cdn了，内容分发网络：

互联网公司的自建DC简直成了既有IP网络的 网中网 ，它们overlay在既有的IP网络上！

好了，现在我们看看这种互联网公司自建的DC是如何打破路径计算的全局最优解的。

所有互联网公司的所有内容都可以分为两种类型：

• 静态内容：永远不变的内容。比如一个固定的视频文件。
• 动态内容：随访问发生变化的内容。比如获取当前的北京时间。

CDN节点几乎都具备缓存能力，因此它们可以把静态内容通过DC之间的虚拟互联路径(或TCP的，或UDP，或临时隧道)提前从源站缓存在离用户最近的那个DC中，当用户访问时，DC的内容可以最短的时间推给用户。

存储和管道永远都是同一件事的两面。 网络是管道，数据库就是存储，沿着空间横向拉伸就是存储，沿着时间纵向拉伸就是网络，我觉得Kafka同时统一了二者，非常之优雅。

我不想谈这个关于静态内容如何缓存以及如何推给用户的话题，这让我觉得非常糟糕。我想大致说下互联网公司如何对待动态内容。

对于动态内容的产生必然是源站参与，因此从客户端到源站之间的通信则是必不可少的，现在的问题是，如何为这次通信寻找一条最优的路径。

注意上图中的互联网公司各个自建DC 简直附着在运营商的路由器上！！ 那么这些DC是不是可以绕开全球BGP以及各运营商IGP的路由呢？

答案是肯定的！比如运营商按照全局BGP/IGP路由提供了下面的全局最优解：

可是，该互联网公司却不认为这条路对自己是最优的，它通过更加精细的指标发现了另外的更好的路径，毕竟一个公司只会考虑自己，它才不会在乎全局呢。

在全局意义上，可能“最短路径”意味着功耗最小，物理距离最短等，但在具体公司的具体业务上，“最短路径”可能指的就是RTT最小，或者丢包率最低，或者多者加权。

通过测量一系列的指标，比方说用TCP或者UDP测量的RTT，丢包率，包重传率等等，这个公司在自私策略的前提下，发现存在另一条路径，通过自家的另一个DC中转，会更优：

这家公司才不会关心这条路具体跨越了哪些路由器，它只关心这条路跨越了自己的哪些DC。

由于这家公司无法控制网络层的IP路由，也就无法控制数据包途径的路径，但是它可以控制传输层路由：

• 它可以事先在各个DC之间构建IP隧道啊！！！
• 它可以在自己各个DC之间按照自己的算法逐跳做DNAT啊！！！
• 它可以在自己各个DC之间做4层/7层代理啊！！！(eBPF的SOCKMAP就可以支持干这个事)
• …

总而言之，这家公司完全可以通过隧道，NAT，Proxy等技术绕开底层的IP选路，从而把从源站始发的数据包导入到自己发现的路径中！

虽然不是标准的IP逐跳路由，但在更高的层次上，如果把DC看作路由器的话，数据包的路由方式和IP路由如出一辙，只不过它是虚拟的而已：

在这种overlay路由中，标准的IP路由寻找下一跳的问题就转换成了 寻找下一段隧道 或者 寻找下一段的TCP连接 问题了。

我来放大某一个DC节点：

…

OK，我们看到，事实上，各个互联网公司是将自己的DC节点当 路由器 来使用了，它被传统的IP网络承载，在这张虚拟的网络上，数据包依然是 逐跳转发 的，只不过跳数的度量是DC节点，而不再是路由器了。

相比于标准的IP路由，这种方式对于一个特定的互联网公司而言，选路更加灵活和精确，只要DC节点部署的足够密集，数据包可以非常灵活的在这些节点之间被转发，直到它到达最终的目的地。

你会质疑，这有什么问题吗？这种办法难道不是比纯粹IP层的物理距离，线路带宽，静态配置的metric更加可信吗？

对也不对！

有一个关键点我没说：

• 按照这种算法计算最优路径的可远不止一家公司！！

因此就根本谈不上所谓的 全局协作！

腾讯有自己的自建DC，百度也有，阿里也有，京东，字节等也差不到哪去，所有的公司都采用自私的策略来计算最优路径，在总体资源有限的情况下，这几家公司的带宽分配就会拼命 内卷！

一切虚拟网络的底层，大多数依然还是那些传统的基础设施，而互联网公司DC的存在，彻底打破了IP路由：

原来的S->D的纯IP层选路，一下子就变成了多个DC之间的多个IP层选路，这势必会让IP路由混淆问题和结论。

除却选路破坏了全局最短路径的收敛，在各个独立的路径，各家还是部署激进的TCP加速算法(注意⚠️它们和拥塞控制算法的本质区别，从名字上就能看得出来)，所谓的加速的本质就是 “尽其所能将数据送到对端” ，所有以此为目的的都是手段，破坏此目标的都可以忽略，这完全破坏了作为一个负反馈系统的网络资源分配机制，该机制要求所有的资源分配都要全局收敛到公平。

“各大互联网公司各自都有自己选路系统和加速算法，却被同一个IP网络承载，资源争抢无法得到控制” 这就是局部拥塞的根源。

只要互联网公司没有自己的物理链路，那么这种局部拥塞就会永远存在 ，腾讯阿里的一帮人玩的越花哨，头条快手的另一帮人就能玩的更花哨，就好像好好的一幢30层的楼房，二楼装了防盗网，三楼就要装，然后四楼就要装，最终全部楼层都装了防盗网，这就是内卷。

这就是国内cdn厂商所谓的加速服务的现状，其实这些都没有意义，只要一个相对激进的厂商退出，所有的都会退出，依靠统一的全局最优选路系统不香吗？部署自己的选路和加速算法，无非就是想让自己此时快一点。

一个TCP协议，together with QUIC and so on，在没有全局视角的前提下，还能折腾成啥样？损人利己或者损人不利己而已，这种端到端协议的首要意义就是收敛到公平，其次才是别的。

不过这种内卷相关的事情，也是国情吧，竞争先于协作，压力先于激励。你肯定不同意我说的，你会说外国的月亮也不圆，但是你会收到正告，所有折腾这种事的公司，都有中国的基因，无论是创始人，还是客户。

需要特别指出的是，Google家的BBR并不在此列，与CUBIC的混部公平性一直在其考虑之列，详情可以直接和其作者联系。

喈夫，土坯房子装修得再好也不能抵御地震，但是住在房子里的人看到豪华的壁纸，却感觉像是住在钢筋混凝土房屋里一样安全无忧！

经理！

最后，有一说一之外还要一分为二，说说自研选路系统和加速算法的必要性和好处。

说真的，现有的全球范围内的运营商维护的那套网络体系，在20～30年前就基本落地了，后来修修补补，肯定是无法满足当前爆发增长的高带宽以及低延迟需求，这正好催生了CDN这种业务：

• 将静态内容通过缓存部署在离用户尽可能近的地方。
• 将动态内容通过自选高带宽低时延路径传输给用户。

以此来规避30年前的陈年TCP协议对长肥管道的不友好性。各大以业务为依托的互联网公司根本无力推进新协议的研发和部署，它们更善于短平快的快速迭代：

• 对于静态内容的传输，拿既有的TCP协议开刀当然是最有效的方式。
• 对于动态内容的传输，在自家DC节点之间构建密集mesh中继/隧道/代理当然OK。

不然还能怎样呢？

放眼世界，如今的互联网内容几乎都集中在各大互联网公司手中，那么话语权当然也在他们那里，Google家自己就有可以完爆运营商的“内网”，国内的腾讯家，阿里家都有这种网络，这些公司在技术层面几乎就和运营商一样在运作，拥有自己的AS号，维护着海量的IP地址以及路由条目，和其它运营商网络peering or 甩热土豆，在技术层面，它们可运营商已经没有什么区别，甚至更有优势。甚至已经有很多公司在铺挖自己的光缆了…

对了，还有，如果你从传统运营商的机房购买了或租用了一个服务器部署了自己的网站，记得再从互联网公司手中购买一个CDN服务：

看起来这里要做广告了，但我就是个卖洗衣膏儿的。

卖洗衣昂膏儿诶卖阿拉洗衣昂膏儿诶…

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

原文链接：https://blog.csdn.net/dog250/article/details/106867424?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165934458816782246446218%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165934458816782246446218&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-13-106867424-null-null.nonecase&utm_term=%E8%87%AA%E5%BB%BAcdn