因特网协议正在发生变化
============================================================
在上世纪九十年代，当因特网开始被广泛使用的时候，大部分的通讯只使用几个协议：IPv4 路由包，TCP 转发这些包到连接上，SSL（后来的 TLS）加密连接，DNS 命名连接上的主机，HTTP 是最常用的应用程序协议。
多年以来，这些核心的因特网协议的变化几乎是可以忽略的；HTTP 增加了几个新的报文头和方法，TLS 缓慢地进行了一点小修改，TCP 调整了拥塞控制，而 DNS 引入了像 DNSSEC 这样的特性。这些协议本身在很长一段时间以来都面向相同的 “线上(on the wire)” 环境（除了 IPv6，它已经引起网络运营商们的大量关注）。
因此，网络运营商、供应商、和政策制定者们，他们想去了解（并且有时是想去管理），因特网基于上面的这些协议的“影响（footpring）”已经采纳了的大量的实践 — 是否打算去调试问题、改善服务质量、或者强制实施策略。
现在，核心因特网协议的重要改变已经开始了。虽然它们的目的是与因特网兼容（因为，如果不兼容的话，它们不会被采纳），但是它们可以破坏那些在协议方面进行非法使用的人的自由，或者假设那些事件不会改变。
#### 为什么我们需要去改变因特网
那里有大量的因素推动这些变化。
首先，核心因特网协议的限制越来越明显，尤其是考虑到性能的时候。由于在应用程序和传输协议方面的结构上的问题，网络不能被高效地使用，导致终端用户感受到性能问题（特别是，延迟）。
这就转化成进化或者替换这些协议的强烈的动机，因为有 [大量的经验表明，即便是很小的性能改善也会产生影响][14]。
第二，有能力去进化因特网协议 — 在任何层面上 — 随着时间的推移会变得更加困难，很大程度上要感谢上面所讨论的网络带来的意想不到的使用。例如，尝试去压缩响应的 HTTP 代理，使的部署一个新的压缩技术更困难；中间设备中的 TCP 优化使得部署一个对 TCP 的改善越来越困难。
最后，[我们正处在一个更多地使用加密技术的因特网变化中][15]，首次激起这种改变的事件是，2015 的 Edward Snowden 披露的信息（译者注：指的是美国中情局雇员斯诺登的事件）。那是一个单独讨论的话题，但是它的意义是，我们为确保协议可以进化，加密是其中一个很好的工具。
让我们来看一下都发生了什么，接下来会出现什么，它对网络有哪些影响，和它对网络协议的设计有哪些影响。
#### HTTP/2
[HTTP/2][16]（基于 Google 的 SPDY） 是第一个发生重大变化的 — 在 2015 年被标准化，它多路传输多个请求到一个 TCP 连接中，因此可以在客户端上不阻塞任何一个其它请求的情况下避免了请求队列。它现在已经被广泛部署，并且被所有的主流浏览器和 web 服务器支持。
从一个网络的角度来看，HTTP/2 的一些显著变化。首先，适合一个二进制协议，因此，任何假定它是 HTTP/1.1 的设备都会被中断。
中断是在 HTTP/2 中另一个大的变化的主要原因；它有效地请求加密。这种改变的好处是避免了来自伪装的 HTTP/1.1 的中间人攻击，或者一些更狡滑的比如 “脱衣攻击” 或者阻止新的协议扩展 — 协议上的这两种情况都在工程师的工作中出现过，给他们带来了很明显的支持问题。
[当它被加密时，HTTP/2 也请求使用 TLS/1.2][17]，并且 [黑名单][18] 密码组合已经被证明不安全 — 它只对暂时的密钥有效果。关于潜在的影响可以去看 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 在 www.google.com 上部署了它的 [基于 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/