计算机网络的新黄金时代（三）：无线网络

（本文系笔者根据 2022 年 12 月 12 日在北京大学的演讲整理，首先将会议录音使用科大讯飞语音识别转换成口水稿，然后用 GPT-4 加以润色，修正语音识别的错误，最后人工加入一些新的思考）

第一篇：计算机网络的新黄金时代（一）：数据中心
第二篇：计算机网络的新黄金时代（二）：广域网

无线网络是一个非常广阔的领域，对应华为的两大产品线，一是无线，二是消费者 BG。无线主要就是我们熟悉的 5G 和 Wi-Fi，而消费者 BG 做的是包括手机在内的各种智能终端。

在上一章广域网开头我们就提到，当前的传输协议对无线网络和广域网的带宽并没有充分利用，导致很多应用实际上无法体验到 5G 和 Wi-Fi 标称的数百 Mbps 高带宽，这就是我们常说的 “最后一公里” 问题。随着无线网络的性能越来越接近有线网络，一些原本适用于数据中心的优化将适用于无线网络。之前我们提到分布式系统，想到的都是数据中心，而现在家中这么多终端设备和智能家居设备，也组成了一个分布式系统，未来有可能一个家庭就是一个迷你数据中心。

无线性能接近有线

无线网络的性能优化

为什么 5G 比 Wi-Fi 的频谱利用率高呢？就是因为 5G 是中心化的分配时隙，Wi-Fi 是载波监听（CSMA）模式的抢占，看到没人发包自己就去发，如果跟其他人冲突了就过一段时间重发。抢占模式理论上的频谱利用率就不会很高，大家可能记得计算机网络课本上学过的 ALOHA 协议，它的最大信道利用率只有 18%；即使把时间分成固定长度的时隙，最大信道利用率也只有 37%。但是我们短期内又没办法修改 Wi-Fi 的协议，因此只能尽量减少不必要的冲突。

我们发现，TCP 协议默认情况下每 2~3 个数据报文都会返回一个 ACK 报文，一方面为了确认数据报文已经收到，另一方面为了做拥塞控制和流控。在数据中心内通信的一些场景，我们希望把每 2~3 个报文返回一个 ACK 改成每个报文都返回一个 ACK，以便做更精细粒度的拥塞控制。但在无线网络的场景中，由于我们的主要问题是频谱利用率低，我们希望减少 ACK 的数量。在 TACK 这个研究工作中，我们通过减少 ACK 的数量，让每个 ACK 携带更多的信息，达到提高频谱利用率的效果。

TACK 提供了两类 ACK，一类是 “即时 ACK”，加快对丢包等事件的响应；另一类是 “周期 ACK”，是每过一段时间触发一次，而不是每收到两三个报文就触发一次。这样，既不会减慢拥塞控制信息的反馈速度，又减少了 ACK 的数量，减少了不必要的信道冲突。

另一项关键技术是 Link Turbo，就是把 5G 和 Wi-Fi 两种物理信道一起使用。提升带宽倒是其次的，更重要的是提高可靠性。比如我们微信消息半天发不出去，或者视频会议中间卡顿，都是用户很难忍受的。单独使用 5G 或者 Wi-Fi，有时 5G 信号好，Wi-Fi 信号差，有时则反过来。此外，经常出现信号看起来很强，但实际丢包率很高的场景，例如连上了不能上网的公共 Wi-Fi。

解决此类问题的方法就是同时利用 5G 和 Wi-Fi 来发送数据。这里 5G 是泛指运营商的蜂窝网络，也包括 4G。一种最简单的方式是把每个数据报文都通过 5G 和 Wi-Fi 发送两遍，但这样显然会浪费一倍的带宽，而且在 Wi-Fi 信号较好时也会浪费较多 5G 流量。因此，Link Turbo 持续测量每种无线信道的性能，并决定如何把数据在各种无线信道之间分配，以及决定是否使用 FEC 编码的方法冗余发送数据。

让流量同时走 Wi-Fi 和 5G 有一个重要问题，就是服务器怎么知道这两条路上来的报文是同一个连接的呢？在服务器看来，同一个手机 Wi-Fi 和 5G 的公网 IP 几乎肯定是不同的。上一章 QUIC 中有个 Session ID，可以支持连接迁移，但是它做得还不够彻底，并不能支持数据包同时从两个源 IP 到达。为了解决把一个连接拆分成多个子连接的问题，一个关键技术就是 MP-TCP（Multi-Path TCP，多路径 TCP）。

最理想的情况就是左图所示，服务器或者数据中心的网关支持 MP-TCP 协议，这样手机终端拆分出的多个子连接在服务器或者网关就可以被聚合起来。但事实是，MP-TCP 虽然已经标准化了很久，也进入了 Linux 内核，很多服务器和云厂商的网关并没有启用它。因此，这种部署形态仅对服务器端支持 MP-TCP 的特定应用有效。

如何在服务器或者云网关不支持 MP-TCP 的情况下，让应用能够用上 MP-TCP，解决无线网络 “最后一公里” 的问题呢？右图中的代理就是一种可能的部署形态。应用或者终端操作系统设置运营商部署在边缘或城市数据中心的代理服务器，在代理上聚合并终结 MP-TCP，再通过标准的 TCP 协议连接到真正的服务器。这种方案适用于任意应用，但代理服务器的带宽等成本较高。

大家也许已经知道，无线网络的带宽目前已经很高，达到甚至超过很多有线网络了。例如 Wi-Fi 6 的理论速率可以达到 1 Gbps 以上。使用测速工具测出来的 5G 全国平均下行速率达到 335 Mbps，是 4G 平均下行速率的 10 倍；5G 平均上行带宽没有下行那么高，但也达到了 70 Mbps，这个上下行的不对称是 5G eMBB 天生的。相比之下，虽然大城市里家庭宽带动辄几百 Mbps 甚至上 Gbps，但全国来看平均下行带宽只有 94 Mbps。也就是说，5G 的平均速率已经超过了家庭宽带。使用 5G 传输大量数据的最大障碍在于流量成本，目前还没有降到跟有线网络同样一个量级。

随着我们的管道越做越大，管道充分利用可能不一定是最关键的，更重要的是达到 “准确定性” 的时延和带宽，提升服务质量。这跟数据中心流量调度的思路是一样的，不管是优先发送小流，还是用 coflow 的概念协同优化一组流的完成时间，在无线网络中，也需要来自应用的更多信息才能更好地对流量进行调度。

在端云网络一节中我们提到一个问题，目前的拥塞控制协议很难感知到实际可用的带宽，因此慢启动和突发流量的表现不好。我们如果做一个大胆的假设，在大多数端云传输中，广域网和数据中心网络都不是瓶颈，那么主要瓶颈就是无线接入网络，这时只要硬件根据信号强度、干扰、共享的终端数量等信息估计出可用的带宽，就可以估计出端云传输的最大可用带宽。如果有多个应用同时访问网络，也可以在终端上做一个智能调度的服务，根据服务质量（QoS）等信息来做调度，而不是让各个连接分别独立争抢共享的无线带宽。

至少在家庭局域网的范围内，无线网络的带宽已经达到 Gbps 级别，可以组成高带宽、低时延的家庭分布式系统。数据中心的带宽是 100 Gbps 级别，时延是微秒级别，而终端无线网络的带宽是 Gbps 级别，时延是毫秒级别。但考虑到终端 CPU 的算力远远低于服务器 CPU，Gbps 级别的带宽使用传统的 TCP/IP 协议栈已经占用了手机等终端不少的 CPU 资源。因此才会出现我们买了相对便宜的一些家用路由器之后，达不到标称的千兆转发带宽。由于终端 CPU 的睡眠模式功耗限制了唤醒时延，TCP/IP 协议栈的延迟也达到了毫秒级，超过了基带芯片和无线空口的时延，因此也是值得优化的。

因此，我们也在尝试把内存语义从数据中心扩展到终端，让手机等终端的无线网卡支持类似 RDMA 的内存语义，从而减少软件协议栈的开销。我们发表的 WIP 论文表明，假设无线网卡支持内存语义，TCP/IP 协议栈所占的终端功耗显著降低，客户端降低到 1/3，服务端降低到 1/5。期望未来的无线网卡芯片能够将无线内存语义真正实现。

讲到这里，想起我博士期间思考过的一个探索性问题，用一些手机的 SoC 芯片组成的阵列是否有可能达到相当于服务器 CPU 或者 GPU 的算力呢？我们评估之后发现，如果所计算的任务是容易并行的，那么用手机 SoC 芯片甚至还有一定的性价比优势。这就像系统领域的一篇著名论文 “FAWN: A Fast Array of Wimpy Nodes”，用一些很弱的节点组成高性价比的存储阵列。但如果所计算的任务是不容易并行的，比如比较大的深度学习模型训练或推理，那么关键瓶颈点就在 SoC 之间的通信上了。

手机 SoC 并不像服务器上的 PCIe 板卡一样可以通过有线连接随意组合，只能通过性能有限的无线接口组成松耦合的系统。但我们并不需要真的用一大堆手机 SoC 芯片去替代 NVIDIA A100，对于很多智能家居中的分布式应用来说，Wi-Fi 6 的无线性能已经足够了，只要我们把 AP 布局合理，把无线理论性能充分利用起来，“家庭数据中心” 一定会逐渐成为现实。

5G to B

说到 5G，很多人认为它只是用于消费者领域。其实 5G 在 B 端的应用场景更为广阔，在此我简单举几个场景作为例子。

港口中的集装箱堆垛是靠龙门吊来搬运货物的，传统上需要操作工人爬到龙门吊顶上高高的操作室，俯视下面的集装箱堆垛来进行操作，操作工人长时间俯身工作，很容易出现腰肌劳损。使用 5G 技术后，操作室的实时图像传送到中控室，操作工人坐在办公室里就能控制龙门吊精准移动。

这样的实时操控需要 10 毫秒级别的时延，传统的 4G 技术是不能满足需求的。Wi-Fi 的覆盖距离又太短，不能满足数百米的远程控制需求。同时，港口场景对 5G 上行带宽要求比较高，因为实时高清图像需要从龙门吊通过 5G 上传到中控室。这跟消费者领域的下行带宽超越上行带宽是不同的需求。

在矿山场景中，煤矿工人都是非常辛苦的，而且经常面临危险。我们的理想是让矿工 “穿西装打领带” 地远程操控作业。首先，需要矿工远程控制无人开采车，有的是图里这样在地面上开采，有的是在地下的煤层中开采。其次，需要各种矿井内的传感器，包括图像、有害气体、风速、压力、温湿度等。最后，还需要矿区周界的安防监控。

与港口场景类似，矿山场景的实时操控也需要 10 毫秒级别的时延，同时也是对上行带宽的需求高于下行带宽。

在铁路场景中，首先需要智慧机务，也就是高铁上的列车运行监控系统（LKJ）、机车车载安全防护系统（6A）、列车网络控制系统（TCMS）采集包括音视频、各种传感器数据在内的信息，通过车载网关上传到铁轨旁边的基站，然后再走有线线路汇总到路局控制中心，持久存储下来。一列列车需要的带宽高达 1.5 Gbps 以上，而且需要在 350 km/h 高速运行的高铁上不间断发送，对 5G 上行的考验是非常大的。为此，列车车载网关的天线开发了自动对准基站的机制，实现高速运动场景下的高速传输。

有了高效的车地通信机制，除了智慧机务，还有望解决高铁上运营商信号差的问题，通过车载 Wi-Fi 等方式为乘客提供更好的互联网体验。

此外，铁路线路被非法入侵一直是一个安全隐患，周界入侵检测系统可以通过雷达、视频等方式检测入侵，并通过轨旁基站上传。

以上这几个 5G to B 的应用其实也是在物联网的范围内。目前物联网在学术界也非常火，但很多学生对物联网的了解仅限于智能家居里面摄像头、门锁、开关、温湿度传感器这类简单的控制系统和传感器，因此很难想到有挑战的问题。要做好物联网研究，一定要深入到产业里面，制造业、港口、矿山、铁路、机场、森林等工业里面的传感器可谓琳琅满目，对性能指标的要求很多是非常苛刻的，有很多值得研究的问题。

卫星通信

最近（2022 年 9 月）华为和苹果最新发布的手机都支持卫星通信，加上马斯克的星链，卫星通信又火起来了。卫星轨道按照轨道高度，划分为 vLEO、LEO、MEO、GEO 等。在卫星通信领域，“占频保轨” 是很关键的，因为通信频率和卫星轨道是稀缺资源，先到先得。因此各国都在加紧构建卫星星座，上世纪的铱星虽然商业上失败了，但它的频率和轨道资源仍然是非常宝贵的。

100 公里是卡门线，再往下就是各国的领空了。
100~500 公里是超低轨（VLEO，Very Low Earth Orbit），这个区间主要用于做高清图像卫星，蜂窝通信的补充，以及 6G 通信的探索性验证。
500~2000 公里是低轨（LEO，Low Earth Orbit），主要是用于军事和通信，例如最早的铱星，现在马斯克的星链（Starlink），苹果卫星通信用的 Globalstar，以及 Amazon 的 Kuiper，都在这个区间里面。这个区间是相对拥挤的，低轨目前已经有 4000 多颗星，绕地一周的时间是 1.5~4 小时。低轨卫星的优势是发射相对容易，通信时延短（5~10 ms），可以使用较为空闲的数十 GHz 的 Ka 和 Ku 频段来通信，而且手持设备用 1W 的功率就可以实现通信。缺点是经过服务的国家和地区上空时间短，只有 5~8 分钟，并且多普勒频移比较严重。
2000~10000 公里是中轨（MEO，Medium Earth Orbit），主要用于陆基通信的补充和海事通信，目前全球有 200 多颗星，绕地球一周的时间是 12 小时。
10000 公里以上是高轨（HEO，High Earth Orbit），其中包括约 36000 公里的地球静止轨道（GEO，Geostationary Earth Orbit），GEO 轨道上的卫星是相对地面上的观察者静止的，这样与之通信的卫星天线就不需要移动。HEO/GEO 主要用于定位、导航类。例如中国的北斗就是由 2.1 万公里和 3.6 万公里的星座构成的，美国的 GPS 是由 1.9 万公里的 24 颗卫星构成的，欧洲的伽利略是 2.4 万公里的星座。目前全球一共有 500 多颗星。华为手机的卫星通信就是基于北斗的短报文服务。HEO/GEO 的优点是服务时间长，缺点是发射需要的火箭技术高，通信时延高（HEO 在 200 ms 以上，GEO 在 250 ms 以上），一般需要手持设备 5W 的发射功率才能实现通信，并且由于大气对高频吸收的影响，只能跟地面基站无线网络一起挤 1~4 GHz 的 L/S 频段。

以上超低轨、低轨、中轨和高轨的划分是比较主观的，物理上并没有很明显的分界线，例如有的人认为北斗 2.1 万公里的轨道属于中轨（MEO）。

目前手机直连卫星通信只能用于紧急救援场景，不能用来日常打电话或者浏览网页。主要原因是与卫星通信所需的发射功率太大，比如传统的卫星手机是 2W，有一个很大的外置天线，蝶形天线（大锅）是 4W，而消费电子终端允许的发射功率只有 0.2~0.4W，因为发射功率太大对健康是有影响的。因此，要在普通手机上用较低的发射功率提供跟传统卫星手机相同的通信能力，是需要很高的技术的。

支持卫星通信的手机首先把数据发送到卫星，卫星转发到信关站。信关站就是固定在地面上的一口大锅，它的功率比一般的蝶形天线大很多，因此带宽可以达到 Gbps 的级别。然后信关站再转发到核心网。Starlink 也提出了使用卫星之间的激光通信来将数据转发到信关站没有覆盖的区域。但不管怎么转发，信关站的建设成本是远远超过运营商基站的，因此大城市中海量的移动网络带宽需求还是需要以地面蜂窝网络为主。

鸿蒙分布式超级终端

随着无线性能接近有线，家庭数据中心的概念成为可能。我们希望把家庭中的各种设备组成一个 “分布式超级终端”，从用户的角度看可以实现数据和服务在各个终端间无缝流转，从开发者的角度看可以用统一的 API 来进行开发，无需关心通信的细节。

鸿蒙分布式超级终端的概念包括 1+8+N，其中 1 是手机；8 是各种智能设备，目前包括 PC、平板、电视、音响、眼镜、手表、智能驾驶中的车机、耳机；N 是多个场景，包括移动办公、智能家居、运动健康、影音娱乐、智能出行等。

分布式超级终端中的通信主要是通过分布式软总线，“软” 的意思就是用软件实现的。软总线的概念由来已久，例如 Linux 的 D-Bus 就是一种软总线，用于进程间通信。鸿蒙的分布式软总线是把总线的概念延伸到了整个家庭的分布式系统。它的主要挑战是：

设备数量众多；
设备间的连接方式复杂，并且由于房屋结构的关系，无线信号干扰、衰减、遮掩的问题也较多；
使得设备之间的互联互通更加可靠、安全；
基于业务和网络状态进行服务质量优化和合理调度。

鸿蒙分布式软总线支持发现、连接、组网、传输四种基本能力。

发现指的就是设备发现，如何找到整个网络中所有的终端设备。发现并不是看起来那么简单，比如有源的 RFID 标签，为了节约电池功耗，它不可能持续发送信号，只能周期性地发送；而手机为了节约功耗，也不可能不停地扫描 RFID 标签，是每间隔一段时间扫描一段时间。那么 RFID 标签和手机应该分别使用怎样的周期来发送和扫描信号呢？这就是很有讲究的。
连接指的是通过分布式软总线来连接周边的通信设备。一种设备可能同时具备 Wi-Fi、蓝牙等不同通信能力，Wi-Fi 也有不同频段，那么如何选择合适的通信媒介，以及在信号较差时如何动态切换？
组网指的是把不同能力和不同特征的分布式设备组成一张动态网络。一种智能家居设备可能可以通过 Wi-Fi 连接无线 AP，也可以通过蓝牙连接手机，这两个连接需要识别出同一个智能家居设备，而且其他的手机需要有能力控制该智能家居设备，这就要求网络中的每个设备都具备统一注册认证、统一寻址路由的能力。当业务需要时，需要建立任意两个设备之间的通信通道。
传输就是指的传输层，包括拥塞控制、丢包重传、服务质量保证等，根据链路上的通信媒介、业务负载提供合适的传输层协议。

刚才我们讲了鸿蒙分布式软总线的四种基本能力，接下来我们讲它面向应用开发者的接口，也就是通信原语。我在这里不会讲具体的 API，只讲通信原语的四个基本类型。

消息：用于实时性和可靠性要求极高的短数据，例如控制类的指令。
字节：用于时延要求不高的基本业务数据传输，与 TCP socket 类似。
文件：主要用于设备间文件的传输和同步。通常需要较大的传输带宽，但实时性要求不高。鸿蒙提供了分布式文件系统的抽象，可以打开一个远程的文件并对它进行读写。在传统的智能家居中，只有提供 NFS 之类协议的 NAS 设备才能实现文件共享。在鸿蒙中，任何文件都可以做到共享访问，并且提供了统一的权限管理机制。在不需要实时同步的场景中，也可以先写入本地副本，再在合适的时候同步到源端设备。
流：一般用于音视频流的传输，既要求高带宽，又要求低时延。这跟类似 TCP socket 的字节流是不同的，音视频流是分为很多帧的，上一章我们也讲过不同帧和音视频流之间的差异，因此它比顺序传输的字节流结构更复杂。

分布式软总线的四种通信原语跟我们前面讲的数据中心内存语义（消息、远程内存访问、RPC）有些类似，但也不是完全相同的。数据中心内存语义并没有区分不同语义的优先级，每种语义的不同事务可以有优先级的区分；而鸿蒙分布式软总线的不同通信原语天生就有不同的优先级。

下面我们通过一个例子，说明鸿蒙分布式软总线的应用场景。这个场景是把电视屏幕的画中画功能当作智能门锁的猫眼用。当门铃按下的时候，门锁需要发现支持画中画功能的电视，然后建立门锁上摄像头到电视屏幕中画中画的高速传输通道。详细步骤如下：

步骤 1：智能门锁上电后，分布式软总线启动发现流程。
步骤 2、3：分布式软总线发现智慧屏设备后，启动组网流程，完成智能门锁与智慧屏之间的可信认证。
步骤 4.1、4.2、4.3：分布式软总线分别向智能门锁和智慧屏上报对方设备上线。
步骤 5、6：当客人按下门铃时，智能门锁的门锁业务请求分布式调度启动智慧屏画中画。
步骤 7：智能门锁的分布式调度将 “启动画中画” 的指令封装为消息，请求分布式软总线将该消息发送至智慧屏的分布式调度。
步骤 8、9：分布式软总线通过消息传输功能将 “启动画中画” 指令发送到智慧屏的分布式调度。
步骤 10：智慧屏的分布式调度收到 “启动画中画” 指令后，启动画中画 FA（Feature Ability，元服务）。
步骤 11：智慧门锁的门锁业务请求分布式软总线将捕获的摄像头画面传输至智慧屏画中画。
步骤 12、13：分布式软总线通过流传输功能，将门锁侧摄像头画面发送至智慧屏，智慧屏的画中画收到门锁摄像头画面后，在画中画 FA（元服务）中播放。

分布式软总线中提供了 “分布式变量” 的抽象，方便开发者进行分布式编程。分布式变量可以看作是在鸿蒙分布式超级终端中的 “全局变量”。

举一个例子，在电视或者平板上看视频的时候，有播放状态、进度、音量、速度等控制属性，在手机等其他智能设备上可以控制这些属性，这就是所谓的多端控制。它的实现原理就是分布式变量。

与传统的共享内存不同，分布式变量不是基于内存地址的，而是基于对象的，每个对象使用 session ID 和 object ID 来索引。基于对象相比分布式共享内存有很多优点，首先是避免了分布式共享内存中内存分配、并发访问的原子性问题，所有对象访问都是由对象管理节点处理的；其次是以对象为粒度访问比以字节为粒度访问的效率更高；最后是以对象粒度做缓存的分布式缓存一致性代价更低。

分布式变量除了提供读写的基本能力，还提供了通知机制，这在分布式系统中也是非常关键的。分布式对象提供了监听数据变更的能力，可以感知其他对象对共享对象数据的变更；还提供了监听状态变更，可以感知 session 内新增和删除对象的事件。例如，音量被其他终端设备修改的时候，播放视频的设备需要感知到该分布式变量的修改，并通知扬声器修改音量。

以分布式软总线作为基础，可以把家庭中的智能设备组成鸿蒙分布式超级虚拟终端，支持分布式设备虚拟化、分布式数据管理、分布式任务调度、一次开发多端部署。

分布式设备虚拟化就是把一个设备虚拟化成另一个设备，比如把智慧屏虚拟化成手机，或者把手机虚拟化成游戏手柄。在视频通话场景，为了在做家务的时候接听视频电话，可以把手机和智慧屏连接，并将智慧屏的屏幕、摄像头、麦克风和音箱虚拟化成本地资源，替代手机自己的屏幕、摄像头、麦克风和扬声器，实现一边做家务，一边通过智慧屏来视频通话。在游戏场景，可以把手机虚拟化成智慧屏的遥控器，借助手机的重力传感器、加速度传感器、触摸屏，把手机当作游戏手柄来用。

手机投屏其实不是新技术，现在有三大主流投屏协议：DLNA、Airplay 和 Miracast，我们一方面支持现有协议以便兼容非鸿蒙生态的设备，另一方面研发自己的分布式设备虚拟化协议，实现除了视频流、语音流、控制流之外的通用设备虚拟化能力，并能更加充分地利用无线带宽，适应多变的无线网络环境。

分布式数据管理就是把数据在多个屏幕之间共享，与分布式变量不同，它可以提供更高级的冲突解决、数据索引能力，实现增删改查和订阅能力，也支持数据加密和访问控制。例如在协同办公场景，可以把手机上的文档投屏到智慧屏上，但这不是一个简单的视频投屏，而是把这个文档用分布式数据管理的方式在智慧屏的文档协同编辑应用上打开。在智慧屏上进行各种文档编辑操作时，文档的最新状态也可以被同步到手机上。手机和电脑也可以同时操作文档，文档协同编辑应用通过分布式数据管理框架进行冲突解决。在照片分享场景，多个手机、智慧屏、平板等可以通过家庭局域网共享照片，而无需将照片上传到云端，可以大大加速照片分享的速度，同时又能通过登录同一账号保证安全性。

分布式任务调度就是把一个应用在不同鸿蒙设备之间迁移，例如上车后把手机上的导航 App 迁移到智能汽车的车机上，用车载大屏和车载音箱方便操控，下车后从车机迁移回手机上。注意这里不是用手机投屏实现的。在外卖场景中，可以把手机上下单的订单信息迁移到手表上，从而随时可以查看外卖的配送状态，注意此时手表上是运行着外卖 App 的一个子任务，而不是外卖 App 把状态信息推送到手表。

我们可以看到，鸿蒙设备分布式协同的一些需求用分布式设备虚拟化（也就是手机投屏的加强版）、分布式数据管理、分布式任务调度三种方案都可以解决。具体使用哪种方案，取决于应用的需求。例如手机上的导航 App 如果用手机投屏的方式投影到车机上，那么将导航 App 将持续消耗手机的电能，而且投屏本身也会耗电；如果用分布式任务调度的方式把应用迁移到车机上，虽然迁移过程会消耗几秒时间传输应用状态数据（通过类似虚拟机迁移的增量迁移技术，可以使应用的暂停时间达到亚秒级），但在导航过程中将不再消耗手机的电能。文档协同编辑也可以用手机投屏或者分布式数据管理来实现，但手机投屏方案中手机上的文档编辑 App 在电脑上的使用体验不一定好。

一次开发，多端部署也是鸿蒙生态的一个典型特征，它支持使用 ArkTS（TypeScript）、JavaScript 和 Java 语言来进行开发，提供了丰富的多态组件，以便在手机、平板、智能穿戴、智慧屏、车机上显示不同的 UI 效果，提供栅格化布局和响应式布局，就像我们现在 Web 前端的很多框架一样，可以在 PC 和移动端分别用合适的布局来显示。除了响应式 UI 布局，将 App 运行在多种设备上的另一个挑战是不同设备的硬件资源和功耗要求不同，例如手表比手机的要求就严苛得多。鸿蒙通过组件化和小型化的设计方法，支持多种终端设备按需弹性部署，适配不同的硬件资源和功能需求。

以上关于鸿蒙分布式超级终端的知识都可以在鸿蒙开发者社区查到，如果大家感兴趣，可以进一步学习鸿蒙的 API，在支持鸿蒙的智能设备上开发属于自己的应用。

本章小结

以上就是无线网络部分的内容。

手机、PC、穿戴设备、智能家居、智能车等智能终端的无缝协同、5G to B 等工业互联网应用都需要稳定的低时延和高带宽，这需要无线协议栈优化，甚至无线内存语义以支持 Gbps 级别的带宽。此外，通过鸿蒙的 “分布式超级终端” 编程框架，可以使能更紧密的分布式协同，实现数据和服务无缝流转。

结语

今天，我们讲到了数据中心、广域网、无线网络领域的一些最新进展。从 “把数据中心作为一台超级计算机”、“全国一体化大数据中心” 到 “鸿蒙分布式超级终端”，网络都是其中非常关键的组成部分。以往我们认为总线仅仅是单台服务器、单台设备内部的高速互联硬件，而如今高性能的数据中心网络和鸿蒙分布式软总线模糊了服务器和终端设备的边界，“总线网络化” 和 “网络总线化” 成为历史的潮流。未来的硬件总线需要吸收网络领域的设计以便扩展到更大的规模，而网络和通信原语的设计需要吸收高速总线的思想以提高性能。

我认为，网络和系统领域创新的两大驱动力是应用需求和硬件能力。

如今，在数据中心领域，AI、大数据、高性能存储、科学计算等对算力和存储容量的需求增长速度超过摩尔定律，使得我们需要越来越大的集群来做分布式并行计算，而网络是其中的关键瓶颈。在终端领域，工业互联网、AR、VR、高清实时音视频、分布式协同等应用也对广域网和无线网络的带宽和时延，特别是稳定的带宽和时延，提出了新的需求。
而在硬件能力方面，网络的性能尚未见顶：数据中心网络即使用了 RDMA，与 NVLink 等高速总线的性能之间仍有一条巨大的鸿沟；广域网的路由器交换性能远未达到光纤容量的上限；终端领域的 Wi-Fi 6、毫米波、卫星通信等也有巨大的挖潜空间。
再看软件，事实上厚重的软件协议栈和落后的传输协议远远不能充分利用现有硬件的能力，不管是数据中心还是广域网，内核的 TCP/IP 协议栈都浪费了数倍到数十倍的硬件能力。这是由于传统网络协议栈运行在通用处理器上，假定通用处理器的算力增长符合摩尔定律，但这已经不再是事实。随着异构算力和存储性能的快速增长，网络协议栈愈发成为瓶颈，因此需要软硬件协同设计，重新定义通信原语，也就是重新划分软件和硬件各自负责的事务。

因此，我认为计算机网络也进入了一个黄金时代，其中有无数的问题等待我们一起探索，特别是其中的软件部分，软硬件协同设计和软件协议栈优化都将是未来 10 年的重要课题。

计算机系统的三驾马车是计算、存储、网络。作为系统基础架构的一部分，网络往往是坏了的时候才会被人想起。只要哪个应用挂了，大家往往第一时间想到的就是网络问题。这说明我们的网络目前还不够鲁棒，而且故障定位、故障自愈的能力还不够强。但我认为网络的可靠性问题一定是可以解决的。就在短短 20 年前，我们还经常需要到处找地方上网。今天，网络已经几乎无处不在，但信号不好还是常事。未来，断网也许将成为罕见的事故。即使百年之后，我相信网络仍然会作为计算机系统的基石，成为万物互联的智能世界背后默默奉献的力量。

数据中心、广域网、终端无线网络通信中的问题我们基本上都在研究，也有一些初步成果，但还没有正式发布，因此今天讲的主要是学术界和工业界现有的一些技术。感兴趣的同学欢迎来我们计算机网络与协议实验室实习或者工作，我们拥有非常强的一支团队，承担公司战略项目的研发工作，我相信其中的技术是世界领先的。

（全文完）