TranslateProject/translated/tech/20171212 Internet protocols are changing.md

互联网协议正在发生变化
============================================================

![](https://blog.apnic.net/wp-content/uploads/2017/12/evolution-555x202.png)

当上世纪九十年代互联网开始被广泛使用的时候，其大部分的通讯只使用几个协议：IPv4 协议路由这些数据包，TCP 协议转发这些包到连接上，SSL（及后来的 TLS）协议加密连接，DNS 协议命名那些所要连接的主机，而 HTTP 协议是最常用的应用程序协议。

多年以来，这些核心的互联网协议的变化几乎是微乎其微的；HTTP 增加了几个新的报文头和请求方式，TLS 缓慢地进行了一点小修改，TCP 调整了拥塞控制，而 DNS 引入了像 DNSSEC 这样的特性。这些协议看起来很长时间都一成不变（除了已经引起网络运营商们的大量关注的  IPv6）。

因此，希望了解（甚至有时控制）互联网的网络运营商、供应商和决策者对这些协议采用的做法是基于其原有工作方式 —— 无论是打算调试问题，提高服务质量，或施加政策。

现在，核心互联网协议的重要改变已经开始了。虽然它们意图与互联网大部分兼容（因为，如果不兼容的话，它们不会被采纳），但是它们可能会破坏那些在协议中没有规定的地方，或者根本就假设那些地方不存在变化。

### 为什么我们需要去改变互联网

有大量的因素推动这些变化。

首先，核心互联网协议的局限性越来越明显，尤其是考虑到性能的时候。由于在应用和传输协议方面的结构性问题，网络没有得到高效使用，导致终端用户认为性能不能满足要求（特别是，网络延迟）。

这就意味着人们有强烈的动机来演进或者替换这些协议，因为有 [大量的经验表明，即便是很小的性能改善也会产生影响][14]。

其次，演进互联网协议的能力 —— 无论在任何层面上 —— 会随着时间的推移变得更加困难，这主要是因为上面所讨论的对网络的非预期使用。例如，尝试去压缩响应的 HTTP 代理服务器使得部署新的压缩技术更困难；中间设备中的 TCP 优化使得部署对 TCP 的改进越来越困难。

最后，[我们正处在一个越来越多地使用加密技术的互联网变化当中][15]，首次激起这种改变的事件是，2015 年 Edward Snowden 的披露事件（LCTT 译注：指的是美国中情局雇员斯诺登的事件）。那是一个单独讨论的话题，但是与之相关的是，加密技术是最好的工具之一，我们必须确保协议能够进化。

让我们来看一下都发生了什么，接下来会出现什么，它对网络有哪些影响，和它对网络协议的设计有哪些影响。

### HTTP/2

[HTTP/2][16]（基于 Google 的 SPDY） 是第一个重大变化 —— 它在 2015 年被标准化。它将多个请求复用到一个 TCP 连接上，从而避免了客户端排队请求，而不会互相阻塞。它现在已经被广泛部署，并且被所有的主流浏览器和 web 服务器支持。

从网络的角度来看，HTTP/2 带来了一些显著变化。首先，这是一个二进制协议，因此，任何假定它是 HTTP/1.1 的设备都会出现问题。

这种破坏性问题是导致 HTTP/2 中另一个重大变化的主要原因之一：它实际上需要加密。这种改变的好处是避免了来自伪装的 HTTP/1.1 的中间人攻击，或者一些更细微的事情，比如 strip headers 或者阻止新的协议扩展 —— 这两种情况都在工程师对协议的开发中出现过，导致了很明显的支持问题。

[当它被加密时，HTTP/2 请求也要求使用 TLS/1.2][17]，并且将一些已经被证明是不安全的算法套件列入[黑名单][18] —— 其效果只允许使用<ruby>短暂密钥<rt>ephemeral keys</rt></ruby>。关于潜在的影响可以去看 TLS 1.3 的相关章节。

最终，HTTP/2 允许多个主机的请求被 [合并到一个连接上][19]，通过减少页面加载所使用的连接（从而减少拥塞控制的场景）数量来提升性能。

例如，你可以对 www.example.com 建立一个连接，也可以将这个连接用于对 images.example.com 的请求。而[未来的协议扩展也允许将其它的主机添加到连接上][20]，即便它们没有被列在最初用于它们的 TLS 证书中。因此，假设连接上的通讯被限制于它初始化时的目的并不适用。

值得注意的是，尽管存在这些变化，HTTP/2 并没有出现明显的互操作性问题或者来自网络的冲突。

#### TLS 1.3

[TLS 1.3][21] 刚刚通过了标准化的最后流程，并且已经被一些实现所支持。

不要被它只增加了版本号的名字所欺骗；它实际上是一个新的 TLS 版本，全新打造的 “握手”机制允许应用程序数据从头开始流动（经常被称为 ‘0RTT’）。新的设计依赖于短暂密钥交换，从而排除了静态密钥。

这引起了一些网络运营商和供应商的担心 —— 尤其是那些需要清晰地知道那些连接内部发生了什么的人。

例如，假设一个对可视性有监管要求的银行数据中心，通过在网络中嗅探通讯包并且使用他们的服务器上的静态密钥解密它，它们可以记录合法通讯和识别有害通讯，无论是来自外部的攻击，还是员工从内部去泄露数据。

TLS 1.3 并不支持那些窃听通讯的特定技术，因为那也是 [一种针对短暂密钥防范的攻击形式][22]。然而，因为他们有使用更现代化的加密协议和监视他们的网络的监管要求，这些使网络运营商处境很尴尬。

关于是否规定要求静态密钥、替代方式是否有效、并且为了相对较少的网络环境而减弱整个互联网的安全是否是一个正确的解决方案有很多的争论。确实，仍然有可能对使用 TLS 1.3 的通讯进行解密，但是，你需要去访问一个短暂密钥才能做到，并且，按照设计，它们不可能长时间存在。

在这一点上，TLS 1.3 看起来不会去改变以适应这些网络，但是，关于去创建另外一种协议有一些传言，这种协议允许第三方去偷窥通讯内容，或者做更多的事情。这件事是否会得到推动还有待观察。

#### QUIC

在 HTTP/2 工作期间，可以很明显地看到 TCP 是很低效率的。因为 TCP 是一个按顺序发送的协议，丢失的包阻止了在缓存中的后面等待的包被发送到应用程序。对于一个多路协议来说，这对性能有很大的影响。

[QUIC][23] 是尝试去解决这种影响而在 UDP 之上重构的 TCP 语义（属于 HTTP/2 的流模型的一部分）像 HTTP/2 一样，它作为 Google 的一项成果被发起，并且现在已经进入了 IETF，它最初是作为一个 HTTP-over-UDP 的使用案例，并且它的目标是在 2018 年成为一个标准。但是，因为 Google 在 Chrome 浏览器和它的网站上中已经部署了 QUIC，它已经占有了互联网通讯超过 7% 的份额。

阅读 [关于 QUIC 的答疑][24]

除了大量的通讯（以及隐含的可能的网络调整）从 TCP 到 UDP 的转变之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求完全加密；这里没有非加密的 QUIC。

iQUIC 使用 TLS 1.3 去为一个会话创建一个密码，然后使用它去加密每个包。然而，因为，它是基于 UDP 的，在 QUIC 中许多会话信息和元数据在加密后的 TCP 包中被公开。

事实上，iQUIC 当前的 [‘短报文头’][25] — 被用于除了握手外的所有包 — 仅公开一个包编号、一个可选的连接标识符、和一个状态字节，像加密密钥转换计划和包字节（它最终也可能被加密）。

其它的所有东西都被加密 — 包括 ACKs，以提高 [通讯分析][26] 攻击的门槛。

然而，这意味着被动估算 RTT 和通过观察连接的丢失包将不再变得可能；因为这里没有足够多的信息了。在一些运营商中，由于缺乏可观测性，导致了大量的担忧，它们认为像这样的被动测量对于他们调试和了解它们的网络是至关重要的。

为满足这一需求，它们有一个提议是 ‘[Spin Bit][27]‘ — 在报文头中的一个 bit，它是一个往返的开关，因此，可能通过观察它来估算 RTT。因为，它从应用程序的状态中解耦的，它的出现并不会泄露关于终端的任何信息，也无法实现对网络位置的粗略估计。

#### DOH

可以肯定的即将发生的变化是 DOH — [DNS over HTTP][28]。[大量的研究表明，对网络实施策略的一个常用手段是通过 DNS 实现的][29]（是否代表网络运营商或者一个更大的权威）。

使用加密去规避这种控制已经 [讨论了一段时间了][30]，但是，它有一个不利条件（至少从某些立场来看）— 它可能从其它的通讯中被区别对待；例如，通过利用它的端口号被阻止访问。

DOH 将 DNS 通讯稍带在已经建立的 HTTP 连接上，因此，消除了任何的鉴别器。一个网络希望去阻止访问，仅需要去阻止 DNS 解析就可以做到阻止对特定网站的访问。

例如，如果 Google 在 <tt style="box-sizing: inherit;">www.google.com</tt> 上部署了它的 [基于 DOH 的公共 DNS 服务][31] 并且一个用户配置了它的浏览器去使用它，一个希望（或被要求的）被停止的网络，它将被 Google 有效的全部阻止（向他们提供的服务致敬！）。

DOH 才刚刚开始，但它已经引起很多人的兴趣和一些部署的声音。通过使用 DNS 来实施策略的网络（和政府机构）如何反应还有待观察。

阅读 [IETF 100, Singapore: DNS over HTTP (DOH!)][1]

#### 骨化和润滑

让我们返回到协议变化的动机，其中一个主题是吞吐量，协议设计者们遇到的越来越多的问题是怎么去假设关于通讯的问题。

例如，TLS 1.3 有一个使用旧版本协议的中间设备的最后结束时间的问题。gQUIC 黑名单控制网络的 UDP 通讯，因为，它们认为那是有害的或者是低优先级的通讯。

当一个协议因为已部署而 “冻结” 它的可扩展点导致不能被进化，我们称它为 _已骨化_ 。TCP 协议自身就是一个严重骨化的例子，因此，很中间设备在 TCP 上做了很多的事情 — 是否阻止有无法识别的 TCP 选项的数据包，或者，优化拥塞控制。

有必要去阻止骨化，去确保协议可以被进化，以满足未来互联网的需要；否则，它将成为一个 ”公共的悲剧“，它只能是满足一些个别的网络行为的地方 — 虽然很好 — 但是将影响整个互联网的健康发展。

这里有很多的方式去阻止骨化；如果被讨论的数据是加密的，它并不能被任何一方所访问，但是持有密钥的人，阻止了干扰。如果扩展点是未加密的，但是在一种可以打破应用程序可见性（例如，HTTP 报头）的方法被常规使用后，它不太可能会受到干扰。

协议设计者不能使用加密的地方和一个不经常使用的扩展点、人为发挥的可利用的扩展点；我们称之为 _润滑_ 它。

例如，QUIC 鼓励终端在 [版本协商][32] 中使用一系列的诱饵值，去避免它永远不变化的假定实现（就像在 TLS 实现中经常遇到的导致重大问题的情况）。

#### 网络和用户

除了避免骨化的愿望外，这些变化也反映出了网络和它们的用户之间的进化。很长时间以来，人们总是假设网络总是很仁慈好善的 — 或者至少是公正的 — 这种情况是不存在的，不仅是 [无孔不入的监视][33]，也有像 [Firesheep][34] 的攻击。

因此，互联网用户的整体需求和那些想去访问流经它们的网络的用户数据的网络之间的关系日益紧张。尤其受影响的是那些希望去对它们的用户实施策略的网络；例如，企业网络。

在一些情况中，他们可以通过在它们的用户机器上安装软件（或一个 CA 证书，或者一个浏览器扩展）来达到他们的目的。然而，在网络不是所有者或者能够访问计算机的情况下，这并不容易；例如，BYOD 已经很常用，并且物联网设备几乎没有合适的控制接口。

因此，在 IETF 中围绕协议开发的许多讨论，是去接触企业和其它的 ”叶子“ 网络之间偶尔的需求竞争，并且这对互联网的整体是有好处的。

#### 参与

为了让互联网在以后工作的更好，它需要为终端用户提供价值、避免骨化、并且允许网络去控制。现在发生的变化需要去满足所有的三个目标，但是，我们需要网络运营商更多的投入。

如果这些变化影响你的网络 — 或者没有影响 — 请在下面留下评论，或者更好用了，通过参加会议、加入邮件列表、或者对草案提供反馈来参与 [IETF][35] 的工作。

感谢 Martin Thomson 和 Brian Trammell 的评论。

 _Mark Nottingham 是互联网架构委员会的成员和 IETF 的 HTTP 和 QUIC 工作组的共同主持人。_

--------------------------------------------------------------------------------

via: https://blog.apnic.net/2017/12/12/internet-protocols-changing/

作者：[Mark Nottingham][a]
译者：[qhwdw](https://github.com/qhwdw)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]:https://blog.apnic.net/author/mark-nottingham/
[1]:https://blog.apnic.net/2017/11/17/ietf-100-singapore-dns-http-doh/
[2]:https://blog.apnic.net/author/mark-nottingham/
[3]:https://blog.apnic.net/category/tech-matters/
[4]:https://blog.apnic.net/tag/dns/
[5]:https://blog.apnic.net/tag/doh/
[6]:https://blog.apnic.net/tag/guest-post/
[7]:https://blog.apnic.net/tag/http/
[8]:https://blog.apnic.net/tag/ietf/
[9]:https://blog.apnic.net/tag/quic/
[10]:https://blog.apnic.net/tag/tls/
[11]:https://blog.apnic.net/tag/protocol/
[12]:https://blog.apnic.net/2017/12/12/internet-protocols-changing/#comments
[13]:https://blog.apnic.net/
[14]:https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/
[15]:https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46197.pdf
[16]:https://http2.github.io/
[17]:http://httpwg.org/specs/rfc7540.html#TLSUsage
[18]:http://httpwg.org/specs/rfc7540.html#BadCipherSuites
[19]:http://httpwg.org/specs/rfc7540.html#reuse
[20]:https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
[21]:https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
[22]:https://en.wikipedia.org/wiki/Forward_secrecy
[23]:https://quicwg.github.io/
[24]:https://blog.apnic.net/2016/08/30/questions-answered-quic/
[25]:https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#short-header
[26]:https://www.mjkranch.com/docs/CODASPY17_Kranch_Reed_IdentifyingHTTPSNetflix.pdf
[27]:https://tools.ietf.org/html/draft-trammell-quic-spin
[28]:https://datatracker.ietf.org/wg/doh/about/
[29]:https://datatracker.ietf.org/meeting/99/materials/slides-99-maprg-fingerprint-based-detection-of-dns-hijacks-using-ripe-atlas/
[30]:https://datatracker.ietf.org/wg/dprive/about/
[31]:https://developers.google.com/speed/public-dns/
[32]:https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.3.7
[33]:https://tools.ietf.org/html/rfc7258
[34]:http://codebutler.com/firesheep
[35]:https://www.ietf.org/