谷歌将用QUIC传输层技术加速互联网

　　安全这个话题，要感谢斯诺登，过去的安全就是攻和防之间的关系，即我们用一种什么样的体系、架构和模式去构建一个密不可破的安全系统。”

　　对IETF工作组忽视外部观察者看起来是一件甚么微不足道的事情的能力感到惊讶。即便如此，IETF标准化的传输协议中出现了一个大规模的讨论，让我印象深刻。这是一个严重超负荷的强迫行为的例子吗？或者这一点代表了设计原则的一个主要观点，并且是关于该设计原则的扩展讨论，而不是使用该位本身？

　　这里考虑的传输协议是QUIC。QUIC最初是由Google开发的，并且正在由其Chrome浏览器和各种Google服务器使用。由于Chrome在互联网上的广泛使用，以及互联网用户对Google服务的广泛使用，明显的推论是QUIC被广泛用于互联网。

　　QUIC是端到端传输控制协议的一个版本，它避免了TCP的传统使用，而是使用UDP。然而，QUIC的行为方式与TCP行为大致一致，并且其意图在许多条件下的功能更具可预测性并且可能产生比TCP更好的结果。

　　它实现这一壮举的方式是将UDP传输层视为与IP本身相同，这主要是UDP的目的，并且使用TCP类协议作为比UDP更低一级的“内部”协议。这里的细节就在这里，在这种情况下，细节是这个UDP有效载荷是加密的。这意味着QUIC的伪TCP会话控制信息隐藏在加密的面纱之内，并且共享的TCP状态是在通信的两个终端系统之间共享但是从网络的所有其他部分被遮挡的秘密。

　　现在如果你上次在1990年看到了对互联网架构的描述，并且从那时起你一直在睡觉，那么这种故意阻塞的端到端传输协议根本不会引起你的注意。网络的交换系统只应该查看外部IP数据包头，内部有效载荷将被两个终端系统独占使用（这解释了IP数据包碎片行为，其中IP数据包头被复制到所有分段数据包，但内部传输协议头只包含在第一个片段中）。如果网络不打算进一步查看IP数据包报头而不仅仅是IP报头，那么为什么传输层协议是否被加密隐藏起来呢？

　　然而，理论和实践在过去的三十年中走向了广泛分歧的道路。自1990年以来，各种形状，大小和角色的网络运营商已经习惯甚至沉迷于深入观察IP数据包。在当今网络中无处不在的防火墙使用内部传输协议端口号来指导接受或拒绝决策。然后是NAT功能，其中协议，源和目的地地址以及源和目的地端口号的5元组被用作翻译表中的查找向量，并且IP和内部传输分组报头被改变在将数据包传递给对方之前的NAT。传输头的这种检查和可能的修改不仅仅是NAT。许多网络运营商使用IP和传输包头执行流量工程功能，数据包拦截和强制代理缓存。各种形式的中间件可能会进入TCP控制字段并操纵这些值来修改会话流量。所有这些活动都很平常，一些网络运营商将此视为其服务的重要组成部分。

　　当Google向IETF提供机会参与QUIC的工作并制定一个可供所有人使用的开放标准时，它激发了IETF内部关于应该从网络故意封闭多少传输信息的争论。QUIC使用的一般原则似乎是尽可能少地暴露出来，而在QUIC头部的简短形式中，剩下的基本上是一个连接标识符和一个数据包编号。QUIC工作组在最近的IETF 101会议上审议过的提案很简单：在QUIC标题的这个开放部分添加一个单独的位。

这一位，“旋转位”旨在被网络路径上的被动观察者用来显示连接的往返时间。该位值的管理非常简单：服务器只是回应在此连接中发送的所有数据包中最后一次可见的值。当客户端发送数据包到服务器时，客户端回应最后看到的位的补码。结果是，当每个方向上连续的数据包序列时，这个旋转位在一个往返时间（RTT）的时间间隔内在0和1之间翻转。这个RTT时间签名不仅在每个末端都可见，而且对任何在路径上的观察者也是可见的。

是揭露这个旋转位“安全”？

　　一些人声称，暴露这一点，以及由流量路径上的旁观者引发连接RTT的相关能力是合理的，并且这里公开的信息不会对用户造成任何特别的伤害。

　　其他人则认为，IP报头之外的任何信息的无故暴露以及UDP报头的基本要素都是不必要的，也是不安全的。没有令人信服的协议原因让这个旋转位被暴露，并且在将该位添加到协议中时如何使用该位是未知因素。Meddlesome中间件的悲惨历史似乎支持这种谨慎的观点，在这种观点中，被视为对免费泄露信息的有用干预成为潜在破坏点甚至潜在的数据泄露点。他们的观点是，即使故意暴露一个据称无害的位，也会使QUIC走上不可逆转的道路。他们指出倡导使用这些比特中的两个，三个甚至更多比特，这些比特可用于揭示丢包率，抖动或更多。

　　让我们提高水平，并考虑一下IETF QUIC工作组内这次辩论所暴露的大问题。这些庞大的不同群体甚至有可能在协议设计领域中仔细考虑约束吗？一系列高度专注的技术人员是否可以研究协议行为的技术问题，这也是对公共通信领域中隐私和暴露之间的妥协问题的一种更广泛理解，并且就如何平衡这些因素达成共识，达成共识。这些日子肯定不太可能。

　　但这些问题绝不是最近的问题。黑客教父郭盛华认为，当我们看到最初的互联网协议设计时，我们看到了类似的平衡这些因素的证据，当时的决策可能永远不会在今天的背景下做出。作为这些不断变化的情况的一个例子，支持互联网许多协议发展的开放互信假设正在以敌意削弱攻击的形式遭到拒绝。这些协议当时设计得不好？如果我们假设部署环境既真实庞大又真正毒害敌对，我们是否会考虑以不同的方式考虑协议？

　　我们是否过多地要求IETF努力开展一个团体摸索一些“粗略共识”的不明确概念？我们应该记住，试图容纳广泛分歧的动机并产生连贯结果的过程与导致53字节ATM单元的非常奇怪的设计选择的设计过程具有相同的基本缺陷。有时候，艰难的选择承认它们之间没有明智的妥协，而且这个过程只能以某种方式做出有争议的决定。虽然个人一直都在做这样的决定，但集体过程包含了大量不同的观点，兴趣和动机，这种决策使得这一决策变得异常艰难。难怪他们经常在任务中失败。

　　Google是否将他们的QUIC实施推向开源领域，并要求IETF流程制定标准的开放式规范？　它在IETF的运输领域肯定引发了应用程序和端到端数据流应该暴露于网络的程度的有用对话，或者甚至是否有任何级别的暴露是太多，但同时目前还不清楚IETF如何利用其流程来做出关于在哪里画线的困难决定。

　　从所有这些出现的观察是，如果要将会话控制状态暴露给网络，并让网络中间件观察并可能篡改该会话状态，那么TCP是端到端传输协议的不错选择。如果您希望将端到端的传输会话状态保持为只有您和您与之通信的一方已知的情况，那么也许您应该使用Google的QUIC版本。QUIC的IETF版本在哪里？目前完全不清楚IETF在这方面的领先地位。

　　愤世嫉俗的观点认为，IETF无法保持端到端的控制状态应该从网络中完全隐瞒，而这个旋转位只是沿着一条必然妥协途径的又一步无条件地将用户的行为暴露给网络。可能还有一种不那么愤世嫉俗的观点，但我不能认为它可能是什么！