计算机网络的新黄金时代（二）：广域网
（本文系笔者根据 2022 年 12 月 12 日在北京大学的演讲整理，首先将会议录音使用科大讯飞语音识别转换成口水稿，然后用 GPT-4 加以润色，修正语音识别的错误，最后人工加入一些新的思考）
广域网主要分为两大类通信模式，一类是端云通信，一类是云际通信。我们先从端云开始讲起。
端云网络
我们一般提到广域网，就认为它是不可控的，运营商的网络设备都不是自己能控制的，还有大量其他用户在并发访问，很难做到确定性。但今天的很多应用又需要一定程度的确定性，比如视频会议、网络游戏，时延高到一定程度用户就会感觉卡顿。如何调和这一对矛盾呢？这就是我们今天的课题。
就像我们在上一章数据中心网络中讲到的，应用实际感受到的带宽与物理带宽差距很大，因此才有优化的空间。我们知道现在 5G 和 Wi-Fi 的理论带宽都是数百 Mbps 乃至上 Gbps，家庭宽带的带宽很多也是几百 Mbps 甚至达到了千兆，理论上 100 MB 的数据一两秒钟就能传输完成。但我们在应用市场里面下载应用的时候，有几次是 100 MB 的应用一两秒钟就能下载完的？另外一个例子，压缩后的 4K 高清视频只需要 15~40 Mbps 的传输速度，听起来远远没有达到带宽的理论上限，但我们有多少网络环境能流畅看 4K 高清视频？这一方面是端侧无线网络的问题，一方面是广域网的问题。要把理论带宽用好，还有很长的路要走。
我当年在微软实习的时候，微软大厦二楼的中餐厅就叫做 “云 + 端”（Cloud + Client），12 楼 sky garden 那里的背景板也写着 cloud first, mobile first，数据中心和智能终端确实是 2010~2020 年最火的两个领域。但可惜的是微软的移动端一直没做起来。华为恰好是在端云两侧都有强大的实力，因此在端云协同优化方面有着独特的优势。
传统互联网应用对带宽和时延的诉求其实并没有那么高，例如网页浏览、文件下载、1080p 的视频点播，100 Mbps 的带宽足够了，时延达到秒级也足以满足用户的需求。
但是，如今的实时音视频（Real-Time Communications，RTC）等新型应用对带宽和时延提出了更高的诉求。例如：
- 4K 高清视频可能需要 1000 Mbps 的带宽。
- 视频会议需要 100 毫秒的时延，否则会感受到视频和声音有显著延迟。
- 直播的时延从之前的分钟级降低到了秒级，直播跟视频会议不同，直播经常有上万人同时观看一个频道，因此需要 CDN 网络层层转发。
- 远程桌面更是需要 10 ms 级别的稳定时延，我曾经用过一段时间远程桌面办公，40 ms 的时延就已经能感受到明显卡顿了。
- 云游戏，比如云原神，跟远程桌面类似，也是需要 10 ms 级别的稳定时延。
我们知道，在光纤里面，10 ms 光只能走 2000 公里，也就是说 10 ms 的往返时延，理论上服务器最远不能超过 1000 公里。而且还要考虑到无线接入网络的时延、网络路由器中的排队时延和数据中心中的处理时延，10 ms 真的是非常苛刻的要求，必须在数据中心选址、无线网络、广域网、数据中心网络、数据中心业务处理等每个环节都锱铢必较，才有可能达成稳定的低时延。
实时音视频需要一系列的关键技术，今天由于时间限制，只讲其中一个有代表性的新型传输协议，QUIC。QUIC 是谷歌等互联网巨头提出的，旨在取代传统的 HTTP，目前最新的 HTTP/3 就是基于 QUIC 的，很多大型网站，比如 Google 和 Facebook，已经支持 QUIC 了。
传统基于 TCP 的 HTTP 协议在广域网传输上有一系列的问题，包括建链时延、拥塞控制、队头阻塞、丢包恢复等等。我们一个一个分别来讨论。
首先是连接建立的时延问题。我们都知道 TCP 需要三次握手，也就是一次往返时延后才能够发送数据。
现在网络上的流量大多数是通过 TLS 加密传输，TLS 在 1.3 之前，加密连接的建立也需要两次往返，主要目的是让客户端验证服务端的身份，并且生成一个用于加密数据的随机密钥。
- 在 TCP 连接建立之后，首先是客户端把自己所要访问的域名、支持的加密算法列表、用于生成随机密钥的随机数发给服务端。这里注意域名是明文传输的，也就是说虽然使用了 TLS，运营商还是能知道你访问的是什么网站的。
- 然后服务端把服务端的 TLS 证书、所选用的加密算法和用于生成随机密钥的随机数发给客户端。
- 客户端验证服务端的证书，然后根据前面的随机数生成用于加密数据的密钥，并且把使用服务端证书中的公钥加密的密钥发送给服务端。
- 服务端使用私钥解开用于加密数据的密钥，这样客户端和服务端都拥有了同一份密钥，而网络上的监听者不可能拿到密钥。
接下来，应用才可以基于这个加密的连接发送数据，也就是客户端发送的 HTTP 请求和服务端返回的 HTTP 响应。
QUIC 把上述 3 次网络往返才能完成的连接建立过程压缩到 0 到 1 次，第一次建立连接的时候只需要一次往返，而后续的连接建立甚至一次往返都不需要。这是怎么实现的呢？
首先，通过无连接的 UDP 来传输数据报文，可以节约 TCP 的连接建立开销。QUIC 内部通过 Session ID 来区分不同的连接，也就是在会话层实现了连接区分，而不是基于 TCP/IP 的五元组来区分连接。
其次，TLS 1.3 对 TLS 1.2 做了改进，在首次建链的时候，把原来需要两次往返的加密通道建立过程缩减为一次。其基本原理是将上述 TLS 1.2 握手流程第 3~4 步的过程和发送数据并行化。我们注意到在上述第 3 步客户端验证完证书、生成对称密钥之后，其实就已经可以开始使用对称密钥加密应用的消息了，因此发送密钥之后就可以流水线化地发送加密的数据。当然，为了前向安全（forward secrecy），这个对称密钥只是在第一个往返中使用，第二个往返及以后的数据将使用支持前向安全的另一个密钥。
最后，在之前建立过连接的情况下，QUIC 协议栈内部的 TLS 1.3 模块会缓存该连接的对称密钥（Pre-Shared Key，PSK）。这样，只要缓存没有过期，客户端仍然可以使用原来的对称密钥来加密数据并直接发送，这样就不需要任何握手，做到 0-RTT 建链。也就是说，QUIC 协议栈内部事实上是维护了长连接的，这叫做会话重用。当然，会话重用也带来了重放攻击的风险，并且削弱了前向安全的特性。
接下来是拥塞控制的问题。广域网上的拥塞控制问题已经研究了几十年，有的是基于丢包的，有的是基于时延的，还有综合以上两者的。
HTTP/3 里面有多种拥塞控制算法可选，今天我们重点介绍一个比较特别的拥塞控制算法，就是谷歌的 BBR，它是为高带宽、高时延、高丢包场景设计的。
传统的拥塞控制算法，比如我们教科书上面学过的 TCP Cubic，很容易导致缓冲区膨胀（buffer bloat）。因为每个连接都是在丢包或者延迟较高时才降低速度，反馈是需要一个网络往返的时延的，这样每个连接在瓶颈链路上都会占用一定的缓冲区，形成一定的队列。当通过一个瓶颈链路的连接数较多时，队列就会比较长，导致端到端时延升高。如果通过瓶颈链路的连接数多到一定程度，队列超过了路由器的缓冲区容量，就会导致丢包。
传统的 TCP Cubic 只有遇到了丢包才会降速，因此队列深度就会一直维持在高位，时延也一直比较高。有没有方法解决这个问题呢？基于时延的拥塞控制算法可以在时延上升的时候就开始降速，而不用等到丢包。BBR 也是一样的，不考虑丢包，而是尝试直接估计 BDP（Bandwidth-Delay Product，带宽和时延的乘积）。BBR 不考虑丢包还有另外一层考量，在广域网上的丢包有时并不是由于拥塞导致的，有些是由于错误导致的，例如无线弱网的情况；有些是由于网络上的中间设备（middlebox）导致的。
如何估计 BDP 呢？做过网络的都知道，带宽和时延是很难同时测准的：测带宽的时候把网络打满了，时延就会很高；测时延的时候需要网络空载，带宽又上不去。BBR 采用了一个交替测量带宽和时延的巧妙办法：绝大多数时间处于带宽探测阶段，也就是全速传输，偶尔尝试多发一些数据，如果时延上来了就说明带宽已经打满，如果时延没有升高说明还可以发得更快。少部分时间切换到延迟探测阶段，降低传输速度，取测得的时延极小值作为基础时延。这样就可以比较准确地估计 BDP，又能及时响应网络变化了。
对于随机丢包的场景，BBR 的表现很好。在 BDP 比较大的情况下，只要有万分之一的丢包率，TCP Cubic 的带宽就只剩下 30% 了；有千分之一的丢包率时，TCP Cubic 的带宽只剩 10%；丢包率达到 1% 时，TCP Cubic 就几乎卡住了。而 BBR 在丢包率 5% 以下时几乎没有带宽损失。
第三个问题是队头阻塞（head of line blocking）。前面在数据中心部分已经讲过，TCP 是字节流的抽象，也就是说所有数据都是有序传输的，同一个域名下面的多个 HTTP 请求或者 HTTP 响应之间就算没有前后依赖关系，也必须按序传输。这样其实是不高效的。
网络通信中的并行性是广泛存在，而又经常容易被忽略的。被忽略的原因是很多系统坚持保序的编程抽象，从而丧失了乱序传输的优化机会。
举个例子，微信的消息就是乱序传输的，有时候我们会发现发送和接收的消息顺序不一致。比如文字、照片和视频就是并行发送的，对方可能先收到文字，再收到照片，再收到视频。如果微信要求消息严格保序传输，那么一旦发送一个几百 MB 的大视频，可能几分钟都没法发送其他消息，这是无法忍受的。
另外一个例子，在视频会议中，音频的优先级是高于视频的，声音断了比视频卡顿一般来说更难以忍受，而且音频比视频的数据量小很多；在视频中，也存在关键帧（I 帧）和非关键帧（P 帧），每个 I 帧之间互相独立，每隔一段时间有一个，而 P 帧则是相对 I 帧的增量。I 帧如果丢了，后续的 P 帧也就无法解码了，因此 I 帧是更重要的。
QUIC 正是利用了网络通信中的并行性，使得每个 HTTP 请求或者 HTTP 流可以乱序独立发送，避免大的请求阻塞小的请求，避免一个请求丢包导致后续所有请求都要等它重传。在 QUIC 中，高优先级的请求可以插队发送，小请求也可以超越大请求，一个请求丢包了不影响不相关的其他请求。
QUIC 把连接建立在会话层上的特性还充分体现在 “连接迁移” 上。传统的 TCP 连接是绑定客户端和服务端 IP 地址的。而在移动环境中，用户可能在 Wi-Fi 和 5G 之间迁移，客户端的 IP 地址可能改变。QUIC 既然已经不依赖 TCP/IP 五元组的概念区分会话，干脆就做得更彻底点，允许客户端 IP 地址变化，根据客户端的 Session ID 来判断是哪个会话。这样，用户就可以在不同的网络间 “漫游” 而无需担心连接中断了。这其实是类似 HTTP 等应用层协议中使用 Cookie 标识用户身份的方法。
QUIC 为了解决无线弱网场景下的高丢包率问题，引入了前向纠错（FEC）机制。前向纠错机制本质上是一种冗余编码，即使丢了一部分报文，也有比较大的概率能够把丢掉的报文恢复出来。前向纠错机制的代价是浪费了额外的带宽，因此 QUIC 会自动根据当前的丢包率选择合适的冗余编码方式。当然，前向纠错机制比较适用于随机丢包，但如果连续丢很多个包，前向纠错机制也回天乏术了。
最后，流量控制（flow control）一直是网络中的关键问题。流量控制的目的是在接收端的应用来不及处理或者接收内存缓冲区不足的时候，能够反压（backpressure）发送端，让它暂缓发送数据。很多人一直分不清流量控制和拥塞控制，拥塞控制的目的是降低多个并发连接经过同一瓶颈链路时带来的排队长度。具体到 TCP 协议中，发送端的 cwnd 就是为了做拥塞控制，rwnd 则是为了做流量控制，实际的发送窗口是两者的较小值。
针对直播等场景，有可能会发生转码跟不上直播的问题，导致卡顿。为了提升用户体验，QUIC 提供了精细流量控制的能力。在转码跟不上的时候，告诉服务端暂停发送直播流，或者采取降低码率等方式。
QUIC 相比传统的 HTTP over TCP 有很多改进，但它也仍然有很多可改进的空间。
在拥塞控制方面，BBR 的慢启动过程仍然需要多次网络往返，但很多请求仅需传输少量数据，慢启动阶段占了大部分甚至全部传输时间，需要更快速地探测到可用带宽。BBR 等通用拥塞控制算法的基本假设是长稳流量模型，也就是连接上有无穷多的数据源源不断地发送。但很多应用的流量是突发式的，如果为它预留带宽则会影响带宽利用率，如果不预留带宽又可能出现丢包或延迟骤增。此外，BBR 依赖对时延和带宽的测量，但一些场景下由于拥塞等原因，时延是经常抖动的，会导致 BBR 的 BDP 计算不准确。
在丢包重传方面，QUIC 采用了前向纠错技术，在随机丢包下表现较好，但在突发丢包下表现较差。此外还有伪丢包的现象，即时延抖动导致时延突然上升，被当作是丢包，导致不必要的重传。
最后，QUIC 只提供加密的可靠传输，要求所有数据都必须到达，但一些实时视音频数据事实上超时后没有必要重传，即使重传过去，对应的帧也已经被跳过了。
通过对 QUIC 等协议的系统优化，我们希望将端云广域网从 “尽力而为” 变为 “准确定性”，之所以我们在确定性前面加了一个 “准” 字，是因为在不可控的广域网上完全的确定性理论上就不可能实现，因此我们希望在大多数场景下对大多数典型业务实现一定的确定性时延、带宽，满足应用的服务质量需求。
云际网络
前面我们以 QUIC 为例，介绍了端云广域网通信协议的一些最新进展。事实上，广域网上除了从用户终端到数据中心的流量，还有很大一部分流量是数据中心之间的，叫做云际网络。
云际网络和端云网络最大的区别是云际网络的可控性一般比端云网络高很多。数据中心间的通信很多是走的专线，专线的带宽和时延都是比较稳定的，丢包率一般也比较低。即使是数据中心之间通过 Internet 通信，其带宽一般也是比较有保证的。此外，云际网络在数据中心出口处的网络交换设备一般是数据中心所有者控制的，因此在流量调度、拥塞控制等方面具有独特的优势。
云际网络的几个典型的应用场景包括：
- 同一 region（区域）内多个数据中心之间的数据同步，距离为数十公里，主要用于提升数据库等应用的可靠性，达到容灾的目的。
- 多个 region（区域）之间的数据同步，包括将各地的数据集中起来进行大数据处理等。
- 从大型数据中心到边缘数据中心和 CDN 服务器传递数据，用于缓存、直播等。
- 将成本较高的计算和存储任务迁移到成本较低的数据中心，在我国，这就是 “东数西算” 国家战略。
我国提出了 “全国一体化大数据中心” 的顶层设计，根据能源结构、产业布局、市场发展、气候环境等，在京津冀、长三角、粤港澳大湾区、成渝，以及贵州、内蒙古、甘肃、宁夏等地布局建设全国一体化算力网络国家枢纽节点，发展数据中心集群，引导数据中心集约化、规模化、绿色化发展。其中，国家枢纽节点之间的高速网络传输通道就是 “东数西算” 工程。
东数西算就像南水北调、西电东输一样，其他国家不一定有相同的战略诉求，也不一定能集中起足够的力量办成这件大事。显然，对时延要求高的任务适合留在东部，而对算力要求高的批处理任务适合放在西部。如何在东西部之间高效的划分任务和高效地传输数据，是一个重要的问题。
通常情况下，用户购买云服务的资源前，不管是 IaaS、PaaS 还是 SaaS，都是先选 Region（区域），而用户对云服务的全球部署、网络拓扑的连接并没有整体概念，所以云厂商需要将资源的分布、价格、使用现状一一呈现给用户，再让用户自行选择服务的部署区域，并自行在区域间进行互联组网。
华为云提出了 Regionless 的概念，期望为云上的租户提供 “全国一体化大数据中心” 甚至 “全球一体化大数据中心” 的编程抽象。
Regionless 就是在云的架构设计上打破 Region 级服务的约束，引入全域调度能力，基于对算力成本最优化、特定云服务及业务负载接入时延，以及应用/应用群之间的通信耦合关系，为用户提供最佳选择。至于具体云服务的资源实例发放到哪一个地理区域，完全由云的智能调度系统动态确定。
这个 Regionless 化的过程中，由华为云来完成调度策略，屏蔽底层资源调度的复杂性。用户无需自己选择地理 Region，就能享受全局服务的全球部署能力。通过这种方式，可以解决东西地区的平滑引流，使得用户在几乎无感知的情况下，将业务负载从东部城市平滑地迁移到西部，比如华为云的乌兰察布数据中心、贵安数据中心。其中涉及到地区层面的架构分层以及全域调度，乃至东部和西部资源的定价差别等等。
为了构建高性能的云际网络，华为云构建了云原生应用接入网络（ADN）。ADN 的底层是专线和 Internet，专线的稳定性高，但在总的租用带宽低的时候成本较高，单位带宽的专线租用成本是随总的租用带宽量降低的。Internet 的稳定性较差，但成本可能较低。这样，高优先级的、时延敏感的流量就更适合走专线，其他流量更适合走 Internet。
为了提高可靠性，专线和 Internet 互为冗余关系，不同的路由路径也是互为冗余关系。由于专线网络拓扑的原因，直连的专线带宽可能不如通过中间节点绕行更大，因此最短路未必是最优路径。流量工程（Traffic Engineering）就是根据用户对流量的带宽需求和优先级，将流量路由到不同的网络路径上。
跟前面讲过的端云网络的 QUIC 一样，云际网络的流量工程也需要用户指定优先级等 QoS（服务质量）需求。在系统设计中，让应用给系统提供提示（hint）是一个常见的优化方式，如果系统缺少应用的信息，那么很多时候根本没办法做好优化。
基于上述的高性能云际网络，我们不仅可以加速跨数据中心服务器之间的通信，还可以加速端侧用户接入云上的业务。包括华为云在内的很多云服务商提供了全球加速覆盖网络（overlay network）。所谓覆盖网络，就是在物理网络拓扑的基础上覆盖一层逻辑拓扑，组成一个虚拟网络。
如上图所示，业务首先通过 Internet 连接到最近的全球加速覆盖网络入口节点，然后覆盖网络将报文路由到对应的数据中心。全球加速覆盖网络属于云际网络，其中经过的是专线或者服务商优化过的 Internet 链路。相比跨区域、长距离的 Internet 网络，很多情况下先接入覆盖网络再在覆盖网络内路由到目标数据中心的服务器，比直接通过 Internet 连接到同一个服务器的时延更低，带宽更高，丢包率更低。这里，端云网络通信被云际网络加速了。
在广域网的管理方面，目前业界已经广泛采用 SD-WAN（Software-Defined WAN）的方法，继承自 SDN（Software-Defined Network）的概念。在 SD-WAN 中，软件统一管理网络设备，网络控制器软件可以通过 RESTful 等标准接口统一管理和配置各种不同厂家的网络设备，从而具有灵活的路由调度能力，支持根据 QoS（服务质量）需求进行负载均衡，支持专线、Internet 等多种接入方式，简化部署、运维。
SD-WAN 也可以管理 CDN 等边缘节点。基于 SD-WAN 的实时视音频传输网络（RTN）的软件控制面统一管理边缘节点和数据中心节点，负责网络质量探测、路径规划、规则配置管理等；而数据面负责数据传输和转发。
本章小结
以上就是广域网部分的内容。
大规模直播和短视频点播、实时音视频通信等应用对广域网传输的稳定性提出了新挑战。互联网巨头纷纷自建全球加速网络，并设计 QUIC 等新型传输协议，实现优质用户体验。此外，由于我国西部能源成本低，东数西算成为国家战略，通过 Regionless 调度，实现 “全国一体化大数据中心”。
端云广域网通信和云际广域网通信中的问题我们基本上都在研究，也有一些初步成果，但还没有正式发布，因此今天讲的主要是学术界和工业界现有的一些技术。感兴趣的同学欢迎来我们计算机网络与协议实验室实习或者工作，我们拥有非常强的一支团队，承担公司战略项目的研发工作，我相信其中的技术是世界领先的。
接下来，我会讲讲无线网络领域的最新技术。