酷应用

互联网协议的演变之路

百家作者：InfoQ 2017-12-14 03:29:12

作者｜Mark Nottingham

译者｜核子可乐

网络协议诞生至今，已经发生了哪些变化、未来还将迎来哪些演进，这会给网络带来怎样的影响，以及网络又会如何左右协议的设计思路？

写在前面

自上世纪九十年代互联网开始得到广泛使用时，大多数流量还仅使用少数几种协议：IPv4 对数据包进行路由、TCP 负责将这些数据包转化为连接，SSL（以及之后的 TLS）进行连接加密，DNS 命名所接入主机，再加上核心应用协议 HTTP。

多年以来，这些核心互联网协议的变化可谓微乎其微。HTTP 增加了一些新的标头与方法，TLS 缓慢完成小幅修改，TCP 终于能够实现拥塞控制，DNS 也引入了 DNSSEC 等功能。但更准确地讲，这些协议本身在相当长的历史周期内几乎没有发生什么显著变化（除了 IPv6，其已经在网络运营商层面得到高度关注）。

也正因为如此，希望了解甚至控制互联网的网络运营商、供应商以及立法者们广泛采取众多基于上述协议的实践手段，旨在借此实现问题调试、服务质量改善以及政策执行等等。

如今，核心互联网协议正在发生重大变化。尽管将继续与整体互联网保持兼容（否则这些新协议将根本不会被采用），但其仍有可能对并不熟悉网络协议或者认为网络协议不会变化的用户产生严重影响。

我们为何需要推进互联网演变？

驱动互联网演变的因素可谓多种多样。

首先，核心互联网协议存在的诸多局限已经非常明显，特别是在性能方面造成了重大问题。由于应用与传输协议的自身结构存在不足，网络资源无法得到有效利用，而这又导致最终用户面对糟糕的性能感受（特别是在延迟方面）。

正因为如此，业界开始抱有强烈的动机以演变或替换这些现有协议——因为大量事实证明，即使是极小的性能收益也会对用户体验产生巨大影响。

其次，随着时间的推移，互联网协议的演进工作变得越来越困难，而其原因主要源自对网络资源的各种非预期性使用方式。举例来说，试图对响应进行压缩的 HTTP 代理使得我们很难部署新的压缩技术 ; 中间件中的 TCP 优化机制亦使我们很难对现有 TCP 作出改进。

最后，考虑到 2015 年曝出的爱德华 - 斯诺登事件，如今我们开始越来越多地在互联网之上使用加密技术。这实际上可以算是另一个话题，但与之密切相关的是，加密技术已经成为我们能够用于确保协议持续发展的最佳工具之一。

在今天的文章中，我们将立足上述历史背景，观察网络协议已经发生了哪些变化、未来还将迎来哪些演进，这会给网络带来怎样的影响，以及网络又会如何左右协议的设计思路。

HTTP/2

HTTP/2 (基于谷歌的 SPDY) 堪称这场浪潮中的最大变化——其于 2015 年实现标准化，核心特征在于能够将多条请求复用至同一 TCP 连接之上，这意味着能够在不造成拥塞的前提下立足客户端消除请求队列需求。HTTP/2 如今已经得到广泛部署，且受到各大主流浏览器与 Web 服务器的通力支持。

从网络的角度来看，HTTP/2 作出了一系列显著的变化。首先，这是一项二进制协议，因此任何使用 HTTP/1.1 的设备都无法与之兼容。

这种不兼容特性又给 HTTP/2 带来了另一项重量级功能——即在客观上要求全程加密。由于无法支持 HTTP/1.1，HTTP/2 能够有效避免由前者带来的中间人干扰，或者去标头乃至屏蔽新协议扩展等可能给支持工作带来巨大麻烦的问题。

HTTP/2 还要求配合 TLS/1.2 以完成加密操作，同时会将被判定为不安全类别的密码套件列入黑名单（即仅允许其使用临时性密钥）。具体请参阅本文中的 TLS 1.3 部分以了解更多相关信息。

最后，HTTP/2 还允许将多台主机的请求合并至同一连接当中，这将有效减少用于页面加载的连接数量，进而降低控制情境拥塞以提高性能水平。

举例来说，我们可以为 www.example.com 建立连接，但也可以利用其处理指向 images.example.com 的请求。未来的各类协议扩展可能还将允许向连接当中添加更多其它主机，无论这些主机是否在其原始 TLS 证书当中列出。因此，届时连接上的流量很可能将仅限于其初始目的——而无法被作为它用。尽管存在上述变化，但值得注意的是，HTTP/2 似乎并不存在严重的互操作性问题，亦未受到来自网络的干扰。

TLS 1.3

TLS 1.3 正在经历最后的标准化流程，且已经得到了一定程度的实际性支持。

但千万别被 1.3 这样的表述所迷惑——TLS 1.3 实际上已经属于全新版本，其中经过彻底修改的握手机制使得应用程序数据自起始阶段即开始流通（通常被称为‘0RTT’）。新的设计采用临时性密钥交换，旨在替代原有静态密钥机制。

这样的调整已经引起部分网络运营商与服务供应商的关注——特别是那些需要了解连接内部实现机制的相关方。

举例来说，银行的数据中心需要满足可见性监管要求。通过嗅探网络中的流量并利用服务器静态密钥进行流量解密，银行数据中心能够记录合法流量并识别恶意流量——包括来自外部攻击者的流量乃至源自内部员工的数据窃取行为。

TLS 1.3 并不支持对流量进行拦截的特定技术，其临时性密钥甚至会将此作为一类特定攻击行为加以防护。这意味着对于既需要利用现代加密协议、又需要监控自有网络的网络运营商而言，目前的状况使其陷入了两难的尴尬境地。

目前就此已经出现了诸多争议，包括是否应当遵循监管要求中提出的静态密钥使用指导、是否可利用其它替代性方案获得相同的效果，以及是否应当削弱整体互联网安全性以换取相对少数网络的合规能力等等。事实上，目前我们仍然有能力对 TLS 1.3 中的流量进行解密，但这要求相关方访问临时密钥——这显然与临时密钥的设计目标有所冲突。

就目前而言，TLS 1.3 似乎不会进一步改变以适应此类网络 ; 但已经出现了一些建立新的协议以满足上述需求的传闻。据称这一新协议将允许第三方观察用例细节信息，甚至开放更多功能。但这种主张能否得到市场肯定，尚有待进一步观察。

QUIC

在对 HTTP/2 的研究当中，有证据表明 TCP 已经成为阻碍传输效率的一大弊端。由于 TCP 属于一项有序传输协议，因此单一数据包的丢失即有可能阻止后续缓冲区内的数据被顺利交付至应用程序。对于多路复用协议而言，这样的情况很有可能给最终性能造成严重影响。

QUIC 试图在 UDP 之上有效重建 TCP 语义（以及部分 HTTP/2 流模式）。与 HTTP/2 类似，QUIC 最初源自谷歌公司的内部项目，而目前此项目已经由 IETF 接手——其初始用例为 HTTP-over-UDP，下阶段发展目标为截至 2018 年年底前成为行业标准。由于谷歌已经将其引入 Chrome 浏览器以及自家官方网站，因此 QUIC 目前已经占据互联网整体流量中的 7% 以上。

除了由 TCP 转向 UDP 以实现流量大小调节能力（以及其它潜在的网络调节指标）之外，谷歌 QUIC（简称 gQUIC）与 IETF QUIC（简称 iQUIC）皆要求对执行流程进行加密 ; 目前不存在任何非加密形式的 QUIC。

iQUIC 采用 TLS 1.3 为会话建立密钥，而后利用这些密钥加密每个数据包。但由于其基于 UDP，因此原本在 TCP 中得到公开的大量会话信息与元数据将在 QUIC 中接受加密。

事实上，iQIUC 目前的“短标头”——用于除握手数据包之外的全部数据包——仅公开数据包编号、可选连接标识符以及一个用于描述加密密钥轮换计划与数据包类型等状态的字节（此字节最终也可能被加密）。

其它的全部信息都将进行加密——具体包括 ACK，这将大大增加流量分析攻击活动的实施难度。然而，这同时意味着我们无法通过观察连接本身被动估计 RTT 与丢包情况——因为其中包含的信息不足以支持这种判断。观察能力的缺失引起了运营商们的高度关注，他们认为这种被动的测量能力对于理解并调试自身网络服务至关重要。

为了满足这类需求，运营商们建议设置所谓“Spin Bit”——即存在于标头当中、并在每次流量往返时进行一次翻转的 bit，观察者将能够借此估算 RTT。由于其与应用程序自身的状态不再关联，因此除了能够用于粗略估算网络位置之外，该 bit 似乎不会泄漏关于端点的任何其它信息。

DOH

DOH 堪称互联网协议领域的最新变化成果——即 DNS over HTTP。目前已经有大量研究表明，网络通常利用 DNS 作为实施管理政策的手段（包括网络运营商以及其它规模更大的权威机构）。

我们之前已经讨论了利用加密以限制这种控制能力，但其在某种程度上讲仍然存在缺陷——其能够被与其它流量区分开来 ; 例如利用其端口编号以阻断访问。

DOH 能够很好地解决这个问题。其会将 DNS 流量搭载至现有 HTTP 连接之上，这意味着不再需要任何鉴码机制。要阻断指向该 DNS 解析器的访问，网络只能直接屏蔽全部指向该网站的全部访问。

举例来说，如果谷歌公司在 www.google.com 上通过 DOH 部署其公开 DNS 服务，而某位用户通过配置浏览器的方式对其加以使用，则希望阻止这种使用行为的网络必须彻底屏蔽全部谷歌访问请求（这主要由谷歌自身的服务托管方式所决定）。

DOH 目前才刚刚兴起，但已经在行业之内引起了高度关注并得到一定支持。我们仍在继续观察各类网络与政府机构如何利用 DNS 机制实施自身管理政策。

“僵化”与“润滑”

下面回到动机层面的讨论，其中的一大重点在于协议设计者们如何解决由网络流量处理假设所带来的问题。

举例来说，中间件由于默认将 TLS 1.3 当作较早版本而引发不少新的问题 ; gQUIC 则将多个对 UDP 流量进行限流的网络（理由是其可能属于有害或者低优先级流量）纳入黑名单。

当一项协议由于扩展点“冻结”而无法继续演进时，我们将其状态描述为“僵化”。TCP 本身就是一种僵化实例 ; 因为大量中间件需要在 TCP 上执行大量处理任务——包括对未能识别的 TCP 选项进行阻断，或者“优化”拥塞控制机制。

只有阻止此类“僵化”问题，才能确保各类网络协议通过持续演变以满足未来互联网的发展需求 ; 否则，悲剧将再度重演——即尽管意图良好，但某些个别网络行为仍会对互联网的整体健康造成负面影响。我们可以通过多种方式防止此类僵化问题 ; 如果相关数据已经被加密，则只有使用密钥才能对其进行访问，这将有效防止额外干扰。而如果某一扩展点未经加密，但具体使用方式决定其可见性不高（例如 HTTP 标头），则同样不太可能受到干扰。

在协议设计者无法使用加密机制且扩展点使用频度不高的情况下，人为使用扩展点将有助于解决此类问题——我们将这种方式称为“润滑”。

举例来说，QUIC 鼓励端点在其版本协商当中利用一系列假值以避免其被假设为永远不会发生变化（这类情况在 TLS 实现场景中经常出现，并往往带来显著问题）。

网络与用户

除了避免僵化问题之外，上述变化也反映出网络与用户之间不断变化的互动关系。长久以来，人们一直将网络视为正面——或者至少是中立性质的环境。但情况如今已经开始变化，特别是在政府监督日益升级与 Firesheep 等攻击活动的双重冲击之下。

如此一来，互联网用户的整体需求与获取网络内一定程度数据流量的监管要求就构成了日益升级的紧张关系。其中受影响最为明显的当数企业网络这类希望对用户施加管理政策的网络体系。

在某些情况下，企业网络可通过在用户设备上安装软件（或者 CA 证书，或浏览器扩展）的方式达成目标。然而，当无法接入网络或者无法访问客户计算机的情况下，问题就变得很难解决。考虑到 BYOD 已经变得非常普遍，而物联网设备更是极少提供适当的控制接口，情况已经非常非常复杂。

因此，IETF 内部围绕协议发展议题出现了大量讨论，旨在寻求能够谐调企业及其它“分支”网络相互竞争的问题，进而为整体互联网带来助益。

参与其中

为了能够让互联网在发展道路上走得更加长远且更加平稳，我们需要为最终用户提供价值、避免僵化问题，同时保持网络持续运行。目前正在推进的各项变化需要满足这三项目标，但很明显当下的网络运营商参与度还远远不够。

如果这些变化影响到了您的网络——或者即使没有——我们仍然诚挚邀请您加入 IETF 参加我们的会议、参与邮件讨论，或者提交议案草稿以表达您的反馈意见。

最后，感谢 Martin Thomson 与 Brian Trammell 对本篇文章提出的评审意见。