mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
178 lines
15 KiB
Markdown
178 lines
15 KiB
Markdown
互联网协议正在发生变化
|
||
============================================================
|
||
|
||
|
||
|
||
当上世纪九十年代互联网开始被广泛使用的时候，其大部分的通讯只使用几个协议：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 的，许多 TCP 中公开的会话信息和元数据在 QUIC 中被加密了。
|
||
|
||
事实上，iQUIC 当前的 [‘短报文头’][25] 被用于除了握手外的所有包，仅公开一个包编号、一个可选的连接标识符和一个状态字节，像加密密钥轮换计划和包字节（它最终也可能被加密）。
|
||
|
||
其它的所有东西都被加密 —— 包括 ACK，以提高 [通讯分析][26] 攻击的门槛。
|
||
|
||
然而，这意味着通过观察连接来被动估算 RTT 和包丢失率将不再变得可行；因为没有足够多的信息。在一些运营商中，由于缺乏可观测性，导致了大量的担忧，它们认为像这样的被动测量对于他们调试和了解它们的网络是至关重要的。
|
||
|
||
为满足这一需求，它们有一个提议是 ‘[Spin Bit][27]’ — 这是在报文头中的一个回程翻转的位，因此，可能通过观察它来估算 RTT。因为，它从应用程序的状态中解耦的，它的出现并不会泄露关于终端的任何信息，也无法实现对网络位置的粗略估计。
|
||
|
||
### DOH
|
||
|
||
即将发生的变化是 DOH — [DNS over HTTP][28]。[大量的研究表明，对网络实施政策干预的一个常用手段是通过 DNS 实现的][29]（无论是代表网络运营商或者一个更大的权力机构）。
|
||
|
||
使用加密去规避这种控制已经 [讨论了一段时间了][30]，但是，它有一个不利条件（至少从某些立场来看）— 它可能与其它通讯区别对待；例如，通过它的端口号被阻止访问。
|
||
|
||
DOH 将 DNS 通讯搭载在已经建立的 HTTP 连接上，因此，消除了任何的鉴别器。希望阻止访问该 DNS 解析器的网络只能通过阻止对该网站的访问来实现。
|
||
|
||
例如，如果 Google 在 www.google.com 上部署了它的 [基于 DOH 的公共 DNS 服务][31]，并且一个用户配置了它的浏览器去使用它，一个希望（或被要求的）被停止访问该服务的网络，将必须阻止对 Google 的全部访问（向他们提供的服务致敬！）（LCTT 译注：他们做到了）。
|
||
|
||
DOH 才刚刚开始，但它已经引起很多人的兴趣，并有了一些部署的传闻。通过使用 DNS 来实施政策影响的网络（和政府机构）如何反应还有待观察。
|
||
|
||
阅读 [IETF 100, Singapore: DNS over HTTP (DOH!)][1]
|
||
|
||
### 僵化和润滑
|
||
|
||
让我们返回到协议变化的动机，有一个主题贯穿了这项工作，协议设计者们遇到的越来越多的问题是网络对流量的使用做了假设。
|
||
|
||
例如，TLS 1.3 有一些临门一脚的问题是中间设备假设它是旧版本的协议。gQUIC 将几个对 UDP 通讯进行限流的网络列入了黑名单，因为，那些网络认为 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)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [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/
|
||
|
||
|