网络层和传输层技术演变 ——25年后的互联网（二）

首先，我们需要考虑互联网层房间里的“大象”。在互联网协议栈层面，有一个根本性的变化本应在20年前就发生，那就是向IPv6过渡。25年前，也就是1998年，我们预测到2025年左右将用完所有剩余的未分配的IPv4地址。这给了我们略多于25年的时间，因此我们并没有紧迫感。我们不需要敲响警钟或发出任何警报。总体目标是以有序的方式推进。

由于我们没有意识到互联网向移动设备转移所带来的真正影响，事情发生了变化。突然之间，我们面对的是一个拥有数十亿用户、使用数十亿移动设备的互联网，而我们对IPv4地址池稳步消耗的舒适预测被抛到九霄云外。从“有的是时间”到“没时间做任何事”，我们只用了1年时间。

从2005年到2010年的5年间，移动服务数量激增，分配的IP地址总数从15亿个地址增加到31亿个，而IPv4地址池的地址总数为37亿个。网络规模扩大了一倍，完成过渡所剩下的时间从20多年缩短到1年多！

此时，所有有序过渡的计划都被抛诸脑后，许多网络管理员争相获取IPv4地址，这进一步耗尽了IPv4地址池。2011年2月，由互联网号码分配局（Internet Assigned Numbers Authority，IANA）运营的中央IPv4地址池耗尽。APNIC（亚太互联网络信息中心）于同年4月耗尽其IPv4地址池，RIPENCC（欧洲网络协调中心）于18个月后耗尽，LACNIC（拉丁美洲和加勒比海地区互联网络信息中心）于2014年耗尽，ARIN（北美互联网注册中心）于2015年耗尽。我们原以为这种情况会促使网络运营商加快IPv6部署计划，但事实并非如此。2011年，使用IP6的互联网用户不到1%。

5年后，随着各区域互联网注册管理机构（Regional Internet Registry，RIR）将其剩余的IPv4地址池用完，整个互联网的IPv6用户数量仅增加到5%。到2023年，这一进程仍在进行，互联网用户中只有约35%拥有IPv6能力。我不确定是否有人愿意预测，这种在油箱耗尽的情况下运行IPv4互联网的反常情况会持续多久。

在没有新的IPv4地址供应的情况下，互联网是如何继续运行甚至发展壮大的？一言以蔽之，答案就是“NAT”。

虽然网络地址转换（Network Address Translation，NAT）的概念在首次发布时并没有引起广泛关注，但在过去的25年里，它得到了大规模的应用，如今NAT已无处不在。互联网的应用架构已经发生了变化，我们现在使用的是客户端/服务器体系架构。

服务器拥有永久的IP地址，而客户端则“租用”公共的IPv4地址来完成交互，并在交互完成后将其归还给公共地址池。分时共享IP地址以及使用TCP（传输控制协议）和UDP（用户数据报协议）中的16位源端口字段，成功地将“准IPv4”地址空间扩展了20位，使IPv4+NAT的地址空间比原来的32位IPv4地址空间大了100万倍。

在实践中，情况要更复杂，在使用NAT来弥补IPv4地址的耗尽方面，一些大型服务提供商的后勤能力已经达到了极限，促使他们过渡到双栈运行模式。该模式依赖的是双协议栈主机在可能的情况下更倾向于使用IPv6的行为，因此双栈部署减轻了IPv4NAT功能的压力。

NAT引发了IP层面的重大变化，改变了对IP地址语义的默认假设。IP地址不再是远程方持久身份的同义词，而是承担了短暂会话令牌的角色。IPv6过渡的缓慢步伐部分归因于地址角色的改变，因为我们不再要求每个连接的设备都分配一个持久的全球唯一IP地址。

IPv6和NAT并不是过去25年中互联网层唯一活跃的领域。我们曾试图改变互联网层的许多部分，但几乎没有任何提议的变革能在网络中获得显著的效果。协议栈中互联网层的功能与25年前并无不同。移动IP（IP Mobility）、多播和IPSec（互联网安全协议）在很大程度上都是互联网层的技术，但却未能在公共互联网市场上获得广泛应用。

服务质量（Quality of Service，QoS）在1998年是一个热门话题，它涉及寻找一种合理的方法，让某些数据包以某种形式快速通过网络，而其他数据包则使用无差别的方式通过网络。我们尝试了各种形式的信令、数据包分类器、队列管理算法以及对IPv4数据包头中服务类型（Type of Service）字段的解释，并详细探讨了集成服务和差异化服务的QoS架构。

然而，QoS一直未能在主流互联网服务环境中占据一席之地。针对这个情况，互联网采取了更为简单的发展方向，对于网络容量不足的问题，我们只需扩充网络即可满足需求。同样的，这反映了通信系统从稀缺转向丰富时的心态转变。我们放弃了在网络、主机协议栈甚至应用程序中安装额外的复杂机制来协商如何共享不足的网络容量。迄今为止，只需为网络增加更多容量的简单方法占据了上风，QoS在很大程度上仍未得到应用。

从电路交换到分组交换的转变从未获得普遍认可。我们曾尝试以各种方式将电路重新纳入IP数据报的架构，其中最引人注意的是多协议标签交换（Multi-Protocol Label Switching，MPLS）技术。

MPLS采用了以前在X.25、帧中继（Frame Relay）和ATM虚拟电路交换系统中使用的标签交换方法，并在IP网络中创建了从每个网络入口到每个网络出口的虚拟路径的集合。最初的想法是，在网络内部，你不需要在每个交换元件中加载完整的路由表，相比于进行目标地址查找，你可以执行一个更小范围的、更快的标签查找。

这种方法在性能上的差异并没有显现出来，在完全加载的转发表中使用32位目标地址来交换数据包，在硬件层面的成本效率仍与虚拟电路标签交换基本相同。

然而，事实证明，MPLS和类似方法对许多网络运营商来说是无价之宝。通用网络设施有许多不同的客户网络，而单一的分组交换环境不允许网络运营商控制向每个客户网络分配公共网络资源的方式。此外，它也不太容易支持对访问域的隔离。MPLS等虚拟电路覆盖为控制资源分配和限制跨网络泄漏提供了机制，对于许多网络运营商来说，这些都是其网络平台采用类MPLS路径的充分理由。

从协议栈的这一层横向看，我们或许应该看看路由技术的演变。上世纪90年代初，路由领域活动频繁，各种路由协议被迅速开发和部署。到1998年，传统的路由技术选择是使用IS-IS或OSPF作为域内路由协议，BGP-4作为域间路由协议。这种情况一直保持到今天。一方面，看到一项基本技术能够在多年的扩展过程中保持相当快的增长速度令人欣慰；但另一方面，看到1998年我们在路由系统遗留的尚未解决的问题在很大程度上至今仍然存在，就不那么令人欣慰了。

在这些未解决问题中，最大的一个是对互联网域间路由系统的信任。互联网的路由系统没有整体的协调。每个网络都会向其相邻网络发布可达性信息，并从这些网络对等点（peers）所提供的可达性信息中选择其认为“最佳”的信息。每个网络对所有其他网络的这种相互信任可以而且已经以各种方式被滥用。

要让每个路由实体都能区分“正确”或“错误”的路由信息，我们提出了大量的倡议，但这些倡议都因为这样或那样的原因而失败了。这一领域的最新成果建立在号码系统的基础上，并使用公私钥来关联持有者持有的地址和自治域号码（Autonomous System Number，ASN）。这允许这些持有者能够签发关于使用这些路由相关号码资源的授权，通过将这些授权与路由系统中传播的信息结合起来，可以检测到未经授权的使用情况。

经过努力，资源公钥基础设施（Resource Public Key Infrastructure，RPKI）已在网络领域获得一定程度的认可，到2023年，大约三分之一的路由对象都有相关的RPKI凭证。这项工作仍在进行中，因为这项工作更具挑战性的方面是将可验证的凭证与路由传播关联起来，既不给路由系统带来沉重负担，又不会使其在运营中过于脆弱。

路由系统长期在不可信任的状态下运行，促使应用层产生了自己的信任机制。现在很大程度上依赖传输层安全性协议（Transport Layer Security，TLS）来确定客户端是否访问了预期的服务器。

鉴于我们几十年来一直无法构建一个安全的路由系统，而在应用层空间，TLS的使用几乎无处不在，这在很大程度上解决了该问题。那么问题是，我们是否还像25年前那样需要这样一个安全的路由系统呢？

互联网层与协议栈上层之间的这种紧张关系也体现在我们处理位置和身份这一长期问题的方式上。IP架构一个最初的简化是将标识、位置和转发的语义打包到一个IP地址中^[1]。

虽然这对简化应用程序和IP网络非常有效，但在考虑移动性、路由选择、协议过渡和网络扩展时，却带来了一些严峻的挑战。如果互联网体系结构允许标识与位置的分离，那么互联网的上述各个方面都将受益匪浅。

在过去10年，特别是在IPv6中，许多工作围绕这个问题展开，但到目前为止，我们还没有找到一种在IP环境中真正让人感觉舒适的方法。在过去10年中，我们似乎一直无法解决的问题是，如果创建了一个使用标识作为交会机制的应用框架，并使用需要位置的IP层，那么如何以高效和足够健壮的方式分配标识和位置之间的映射呢？协议栈的传输层也研究了同样的问题，并提出了一些有趣的方法，我们将在下一节中看到。

1998年，IP架构的传输层由UDP和TCP组成，网络使用模式约为95%的TCP和5%的UDP。经过25年的发展，这种情况终于发生了改变。

在此期间，我们开发了一些新的传输层协议，如数据拥塞控制协议（Datagram Congestion Control Protocol，DCCP）和流控制传输协议（Stream Control Transmission Protocol，SCTP），它们可以被视为对TCP的改进。DCCP将流量控制机制扩展到数据报流；而SCTP在多个可靠流上共享流量控制状态。然而，在感知传输层的中间件不断发展的今天，在公共互联网上部署这些新协议的能力充其量只能算微不足道。防火墙、NAT等类似设备无法识别这些最新的传输层协议，因此，在公共互联网大规模部署此类协议的前景并不乐观。我们似乎还停留在TCP和UDP的世界里。

多年来的实践证明，TCP具有出色的适应能力，但随着网络容量的增加，TCP能否在全球范围内以更快的数据传输速率持续传输数据已成为一个重要问题。为修改TCP流量控制算法，使TCP能与其他并发TCP会话公平地共享网络，同时又能将数据传输速率提升至每秒几个Gbit，并长时间保持该速率，我们已经做了大量工作。

主流的TCP流量控制协议已从传统的RENO型协议转向CUBIC算法。CUBIC试图找到一个稳定的发送速率，然后慢慢增加网络路径的流量压力，以检查网络是否能支持更高的发送速率。对丢包的反应仍然是速率的急剧下降，但没有RENO的速率减半那么剧烈，尽管如此，它仍然是一个对丢包敏感的ack步进式（ack-paced）流量控制协议。

然而，随着BBR（Bottleneck Bandwidth and Round-trip Propagation Time，瓶颈带宽和往返传播时间）协议的引入，情况发生了变化。驱动网络形成网络队列，并进一步导致队列溢出和数据包丢失，是一种粗糙的方法。这里的问题在于，数据包丢失代表着反馈的丢失。而在基于反馈的流量控制协议中，反馈的丢失将导致协议不得不降低发送速率以重建信号流。BBR代表了一种不同的流量控制方式，它试图根据网络队列形成的起始点而不是网络队列的崩溃点来导引流量。这样可以减少流量的延迟，并通过降低对高速内存缓存的要求来降低网络交换设备的成本。

这并不是改变TCP拥塞控制模式的唯一实验领域。低延迟、低损耗、可扩展吞吐量架构（Low Latency Low Loss Scalable，L4S）正在探索另一种方法，它将网络信号纳入流量控制算法。在这种情况下，网络中的数据交换机会在队列形成时将IP头中的显式拥塞通知（Explicit Congestion Notification，ECN）信号写入数据包。该信号的接收者会以类似于丢包的方式降低发送速率。这种方法的优点是不会丢失反馈信号，流量会对拥塞状况的形成而不是队列崩溃的终点做出反应。不过，ECN需要部署ECN标记设备，与BBR等纯协议方法相比，同步网络设备和传输协议行为的工作量要大得多。

传输层领域的其他举措也值得一提。

首先是多路径TCP（Multipath TCP）。我们的观察是，Wi-Fi和蜂窝无线网络服务日益普及，并且大多数移动设备同时具有能够访问这两种网络的能力。一般来说，选择使用哪个网络接口是移动平台为所有活动的应用程序做出的单一决定。当检测到可用的Wi-Fi网络时，设备会优先选择使用该连接进行所有新的连接，因为它认为Wi-Fi服务对用户来说更便宜，运行性能也更高。但是，如果性能是问题。那么适应性也是需要考虑的问题，我们能否允许TCP会话同时使用所有可用的网络，并优化使用通往目的地的多个网络路径，从而优化总的数据吞吐量？

这就是多路径TCP的目标，即把一个TCP会话分成几个子会话，每个子会话使用不同的本地网络接口，从而使用不同的网络路径。这就允许使用单独的TCP状态控制通过各个网络路径的流量，以优化吞吐量。它还允许流量迁移，允许逻辑TCP流量在保持完整性的同时，从一条网络路径切换到另一条网络路径。类似这种多路径行为的有趣之处在于，这种行为最初是由应用程序，而不是主机平台控制的。这是对边缘网络日益增长的容量和多样性的早期应对，也是对如何在传输会话层面应对这种情况的早期回应。

第二是引入QUIC（Quick UDP Internet Connection，快速UDP网络连接）协议，我认为，这是传输能力和功能的根本性改变。简单来说，QUIC就是将TCP和TLS包装成一个UDP封装。不过，我认为这样的描述远远不够。

QUIC在许多方面都是一个更加雄心勃勃的传输协议，它将传输技术提升到了更适合当前应用行为的地步，旨在通过更快的会话建立来改进加密流量的传输性能。QUIC通过支持远程过程调用（Remote Procedure Call，RPC），使传输机制得到进一步发展。

QUIC还全面支持并发会话多路复用，避免了TCP的队头阻塞（Head-of-line blocking，HOL Blocking）。QUIC对有效载荷数据进行加密，但与TLS不同的是，QUIC还对控制数据（相当于TCP报头）进行加密，并通过阻止会话与网络控制交换的完整性，显式地避免了网络中正在显现的TCP协议僵化现象。QUIC具有地址灵活的特点，因为它可以在一个活跃QUIC会话中响应网络层地址的重新编号，当网络路径上存在NAT时就会出现这种情况。QUIC可以在用户态实现，因此应用程序可以控制自己的传输功能，在传输服务的实施质量方面不再依赖于底层平台。有了QUIC，应用程序可以全面控制与网络的交互方式。

从QUIC的经验中我们可以汲取一些教训。首先，任何有用的公共通信媒介都需要保护其传输通信的隐私性和完整性。开放协议代表效率、速度和隐私之间可接受的妥协折衷的时代已经一去不复返，如今，公共互联网上的所有网络事务都需要得到充分的加密保护。QUIC将客户端和服务器之间的数据和控制事务包装到端到端加密状态的模型，代表了当今网络环境的最低功能水平。

其次，QUIC提供了额外所需的传输层功能。TCP和UDP只是更广范围的潜在传输模型的两个功能点。UDP太容易被滥用，所以我们把所有功能都集中在TCP上。问题在于，TCP是作为一个高效的单一流协议而设计的，要在TCP中加装多会话、短事务、RPC（远程过程调用）、可靠的单数据包事务和共享拥塞状态等功能，已被证明是不可能实现的。

目前，应用程序在互联网生态系统中占据主导地位，而平台和网络正在被商品化。我们看到，人们对为其托管的应用程序提供通用传输服务的底层平台失去了耐心，而新的模式是应用程序自带传输的服务。

从更广阔的视角来看，互联网成功的背景在于将提供服务的责任从网络转移到了终端系统。这使我们能够更有效地利用通用网络的基底，并将网络事务分组化的成本转嫁给终端系统。它将创新的角色从庞大而笨重的电信运营商转移到了更灵活的软件世界。

QUIC在此基础上更进一步，将创新角色从平台推向应用，而此时平台在生态系统中的相对重要性正在下降。从这个角度来看，以应用为中心的传输模式的出现是一种不可阻挡的发展趋势，它能提供更快的服务、更多的传输模式和全面的加密。

我们将端到端身份验证的责任推给了传输层以及几乎无处不在的TLS。TLS将自己置于TCP层之上（或在QUIC中与类似TCP的功能合并），客户端将其打算连接的服务名称传递给远程服务器。服务器将它的公钥传递给客户端，客户端使用自己的信任锚对该密钥进行验证。然后，服务器和客户端协商一个会话密钥，并进行加密会话。

TLS几乎在所有方面都很健壮。它的主要弱点在于高度分布式的信任模式，在这种模式下，有数百个不同的可信凭证运营商（Certification Authority，CA，证书颁发机构）和数千个不同的注册代理。这些实体被置于高度可信的角色，它们永远不会说谎。问题是，事实证明它们时常会被破坏。它们通常使用在线服务进行操作，对此类平台的成功攻击可能会被滥用，从而允许签发受信任的公共证书。

我们投入了大量的时间和精力来巩固这一信任框架，但与此同时，我们也一直在努力使这些公钥证书成为一种商品，而不是昂贵的奢侈品。免费CA的引入成功地让所有人都能获得这些证书，但完全自动化的证书颁发流程也容易受到各种形式的滥用。

尽管有这些顾虑，我们还是将服务真实性和会话加密的重任全部交给了TLS，以至于其他相关工作，如IPSec、BGP路由安全和DNS中的DNSSEC，通常被视为可有可无的额外工作，而不是安全工具包中的必需品。