PRF:20171212 Internet protocols are changing.md

部分校对

translated/tech/20171212 Internet protocols are changing.md

@@ -59,23 +59,23 @@ TLS 1.3 并不支持那些窃听通讯的特定技术，因为那也是 [一种
 
 #### QUIC
 
-在 HTTP/2 工作期间，可以很明显地看到 TCP 是很低效率的。因为 TCP 是一个按顺序发送的协议，丢失的包阻止了在缓存中的后面等待的包被发送到应用程序。对于一个多路协议来说，这对性能有很大的影响。
+在 HTTP/2 工作中，可以很明显地看到 TCP 有相似的低效率。因为 TCP 是一个按顺序发送的协议，一个数据包的丢失可能阻止其后面缓存区中的数据包被发送到应用程序。对于一个多路复用协议来说，这对性能有很大的影响。
 
-[QUIC][23] 是尝试去解决这种影响而在 UDP 之上重构的 TCP 语义（属于 HTTP/2 的流模型的一部分）像 HTTP/2 一样，它作为 Google 的一项成果被发起，并且现在已经进入了 IETF，它最初是作为一个 HTTP-over-UDP 的使用案例，并且它的目标是在 2018 年成为一个标准。但是，因为 Google 在 Chrome 浏览器和它的网站上中已经部署了 QUIC，它已经占有了互联网通讯超过 7% 的份额。
+[QUIC][23] 尝试去解决这种影响而在 UDP 之上重构了 TCP 语义（以及 HTTP/2 流模型的一部分）。像 HTTP/2 一样，它始于 Google 的一项成果，并且现在已经被 IETF 接纳作为一个 HTTP-over-UDP 的初始用例，其目标是在 2018 年底成为一个标准。然而，因为 Google 已经在 Chrome 浏览器及其网站上部署了 QUIC，它已经占有了超过 7% 的互联网通讯份额。
 
-阅读 [关于 QUIC 的答疑][24]
+- 阅读 [关于 QUIC 的答疑][24]
 
-除了大量的通讯（以及隐含的可能的网络调整）从 TCP 到 UDP 的转变之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求完全加密；这里没有非加密的 QUIC。
+除了大量的通讯从 TCP 到 UDP 的转变（以及隐含的可能的网络调整）之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求全程加密；并没有非加密的 QUIC。
 
-iQUIC 使用 TLS 1.3 去为一个会话创建一个密码，然后使用它去加密每个包。然而，因为，它是基于 UDP 的，在 QUIC 中许多会话信息和元数据在加密后的 TCP 包中被公开。
+iQUIC 使用 TLS 1.3 来为会话建立密钥，然后使用它去加密每个数据包。然而，由于它是基于 UDP 的，许多 TCP 中公开的会话信息和元数据在 QUIC 中被加密了。
 
-事实上，iQUIC 当前的 [‘短报文头’][25] — 被用于除了握手外的所有包 — 仅公开一个包编号、一个可选的连接标识符、和一个状态字节，像加密密钥转换计划和包字节（它最终也可能被加密）。
+事实上，iQUIC 当前的 [‘短报文头’][25] 被用于除了握手外的所有包，仅公开一个包编号、一个可选的连接标识符和一个状态字节，像加密密钥轮换计划和包字节（它最终也可能被加密）。
 
-其它的所有东西都被加密 — 包括 ACKs，以提高 [通讯分析][26] 攻击的门槛。
+其它的所有东西都被加密 —— 包括 ACK，以提高 [通讯分析][26] 攻击的门槛。
 
-然而，这意味着被动估算 RTT 和通过观察连接的丢失包将不再变得可能；因为这里没有足够多的信息了。在一些运营商中，由于缺乏可观测性，导致了大量的担忧，它们认为像这样的被动测量对于他们调试和了解它们的网络是至关重要的。
+然而，这意味着通过观察连接来被动估算 RTT 和包丢失率将不再变得可行；因为没有足够多的信息。在一些运营商中，由于缺乏可观测性，导致了大量的担忧，它们认为像这样的被动测量对于他们调试和了解它们的网络是至关重要的。
 
-为满足这一需求，它们有一个提议是 ‘[Spin Bit][27]‘ — 在报文头中的一个 bit，它是一个往返的开关，因此，可能通过观察它来估算 RTT。因为，它从应用程序的状态中解耦的，它的出现并不会泄露关于终端的任何信息，也无法实现对网络位置的粗略估计。
+为满足这一需求，它们有一个提议是 ‘[Spin Bit][27]’ — 这是在报文头中的一个回程翻转的位，因此，可能通过观察它来估算 RTT。因为，它从应用程序的状态中解耦的，它的出现并不会泄露关于终端的任何信息，也无法实现对网络位置的粗略估计。
 
 #### DOH