當(dāng)上世紀(jì)九十年代互聯(lián)網(wǎng)開始被廣泛使用的時候，其大部分的通訊只使用幾個協(xié)議：IPv4 協(xié)議路由這些數(shù)據(jù)包，TCP 協(xié)議轉(zhuǎn)發(fā)這些包到連接上，SSL（及后來的 TLS）協(xié)議加密連接，DNS 協(xié)議命名那些所要連接的主機，而 HTTP 協(xié)議是最常用的應(yīng)用程序協(xié)議。

多年以來，這些核心的互聯(lián)網(wǎng)協(xié)議的變化幾乎是微乎其微的；HTTP 增加了幾個新的報文頭和請求方式，TLS 緩慢地進行了一點小修改，TCP 調(diào)整了擁塞控制，而 DNS 引入了像 DNSSEC 這樣的特性。這些協(xié)議看起來很長時間都一成不變（除了已經(jīng)引起網(wǎng)絡(luò)運營商們的大量關(guān)注的 IPv6）。

因此，希望了解（甚至有時控制）互聯(lián)網(wǎng)的網(wǎng)絡(luò)運營商、供應(yīng)商和決策者對這些協(xié)議采用的做法是基于其原有工作方式 —— 無論是打算調(diào)試問題，提高服務(wù)質(zhì)量，或施加政策。

現(xiàn)在，核心互聯(lián)網(wǎng)協(xié)議的重要改變已經(jīng)開始了。雖然它們意圖與互聯(lián)網(wǎng)大部分兼容（因為，如果不兼容的話，它們不會被采納），但是它們可能會破壞那些在協(xié)議中沒有規(guī)定的地方，或者根本就假設(shè)那些地方不存在變化。

為什么我們需要去改變互聯(lián)網(wǎng)

有大量的因素推動這些變化。

首先，核心互聯(lián)網(wǎng)協(xié)議的局限性越來越明顯，尤其是考慮到性能的時候。由于在應(yīng)用和傳輸協(xié)議方面的結(jié)構(gòu)性問題，網(wǎng)絡(luò)沒有得到高效使用，導(dǎo)致終端用戶認(rèn)為性能不能滿足要求（特別是，網(wǎng)絡(luò)延遲）。

這就意味著人們有強烈的動機來演進或者替換這些協(xié)議，因為有 大量的經(jīng)驗表明，即便是很小的性能改善也會產(chǎn)生影響。

其次，演進互聯(lián)網(wǎng)協(xié)議的能力 —— 無論在任何層面上 —— 會隨著時間的推移變得更加困難，這主要是因為上面所討論的對網(wǎng)絡(luò)的非預(yù)期使用。例如，嘗試去壓縮響應(yīng)的 HTTP 代理服務(wù)器使得部署新的壓縮技術(shù)更困難；中間設(shè)備中的 TCP 優(yōu)化使得部署對 TCP 的改進越來越困難。

最后，我們正處在一個越來越多地使用加密技術(shù)的互聯(lián)網(wǎng)變化當(dāng)中，首次激起這種改變的事件是，2015 年 Edward Snowden 的披露事件（LCTT 譯注：指的是美國中情局雇員斯諾登的事件）。那是一個單獨討論的話題，但是與之相關(guān)的是，加密技術(shù)是最好的工具之一，我們必須確保協(xié)議能夠進化。

讓我們來看一下都發(fā)生了什么，接下來會出現(xiàn)什么，它對網(wǎng)絡(luò)有哪些影響，和它對網(wǎng)絡(luò)協(xié)議的設(shè)計有哪些影響。

HTTP/2

HTTP/2（基于 Google 的 SPDY） 是第一個重大變化 —— 它在 2015 年被標(biāo)準(zhǔn)化。它將多個請求復(fù)用到一個 TCP 連接上，從而避免了客戶端排隊請求，而不會互相阻塞。它現(xiàn)在已經(jīng)被廣泛部署，并且被所有的主流瀏覽器和 web 服務(wù)器支持。

從網(wǎng)絡(luò)的角度來看，HTTP/2 帶來了一些顯著變化。首先，這是一個二進制協(xié)議，因此，任何假定它是 HTTP/1.1 的設(shè)備都會出現(xiàn)問題。

這種破壞性問題是導(dǎo)致 HTTP/2 中另一個重大變化的主要原因之一：它實際上需要加密。這種改變的好處是避免了來自偽裝的 HTTP/1.1 的中間人攻擊，或者一些更細(xì)微的事情，比如 strip headers 或者阻止新的協(xié)議擴展 —— 這兩種情況都在工程師對協(xié)議的開發(fā)中出現(xiàn)過，導(dǎo)致了很明顯的支持問題。

當(dāng)它被加密時，HTTP/2 請求也要求使用 TLS/1.2，并且將一些已經(jīng)被證明是不安全的算法套件列入黑名單—— 其效果只允許使用短暫密鑰ephemeral keys。關(guān)于潛在的影響可以去看 TLS 1.3 的相關(guān)章節(jié)。

最終，HTTP/2 允許多個主機的請求被 合并到一個連接上，通過減少頁面加載所使用的連接（從而減少擁塞控制的場景）數(shù)量來提升性能。

例如，你可以對 www.example.com 建立一個連接，也可以將這個連接用于對 images.example.com 的請求。而未來的協(xié)議擴展也允許將其它的主機添加到連接上，即便它們沒有被列在最初用于它們的 TLS 證書中。因此，假設(shè)連接上的通訊被限制于它初始化時的目的并不適用。

值得注意的是，盡管存在這些變化，HTTP/2 并沒有出現(xiàn)明顯的互操作性問題或者來自網(wǎng)絡(luò)的沖突。

TLS 1.3

TLS 1.3 剛剛通過了標(biāo)準(zhǔn)化的最后流程，并且已經(jīng)被一些實現(xiàn)所支持。

不要被它只增加了版本號的名字所欺騙；它實際上是一個新的 TLS 版本，全新打造的 “握手”機制允許應(yīng)用程序數(shù)據(jù)從頭開始流動（經(jīng)常被稱為 ‘0RTT’）。新的設(shè)計依賴于短暫密鑰交換，從而排除了靜態(tài)密鑰。

這引起了一些網(wǎng)絡(luò)運營商和供應(yīng)商的擔(dān)心 —— 尤其是那些需要清晰地知道那些連接內(nèi)部發(fā)生了什么的人。

例如，假設(shè)一個對可視性有監(jiān)管要求的銀行數(shù)據(jù)中心，通過在網(wǎng)絡(luò)中嗅探通訊包并且使用他們的服務(wù)器上的靜態(tài)密鑰解密它，它們可以記錄合法通訊和識別有害通訊，無論是來自外部的攻擊，還是員工從內(nèi)部去泄露數(shù)據(jù)。

TLS 1.3 并不支持那些竊聽通訊的特定技術(shù)，因為那也是 一種針對短暫密鑰防范的攻擊形式。然而，因為他們有使用更現(xiàn)代化的加密協(xié)議和監(jiān)視他們的網(wǎng)絡(luò)的監(jiān)管要求，這些使網(wǎng)絡(luò)運營商處境很尷尬。

關(guān)于是否規(guī)定要求靜態(tài)密鑰、替代方式是否有效、并且為了相對較少的網(wǎng)絡(luò)環(huán)境而減弱整個互聯(lián)網(wǎng)的安全是否是一個正確的解決方案有很多的爭論。確實，仍然有可能對使用 TLS 1.3 的通訊進行解密，但是，你需要去訪問一個短暫密鑰才能做到，并且，按照設(shè)計，它們不可能長時間存在。

在這一點上，TLS 1.3 看起來不會去改變以適應(yīng)這些網(wǎng)絡(luò)，但是，關(guān)于去創(chuàng)建另外一種協(xié)議有一些傳言，這種協(xié)議允許第三方去偷窺通訊內(nèi)容，或者做更多的事情。這件事是否會得到推動還有待觀察。

QUIC

在 HTTP/2 工作中，可以很明顯地看到 TCP 有相似的低效率。因為 TCP 是一個按順序發(fā)送的協(xié)議，一個數(shù)據(jù)包的丟失可能阻止其后面緩存區(qū)中的數(shù)據(jù)包被發(fā)送到應(yīng)用程序。對于一個多路復(fù)用協(xié)議來說，這對性能有很大的影響。

QUIC 嘗試去解決這種影響而在 UDP 之上重構(gòu)了 TCP 語義（以及 HTTP/2 流模型的一部分）。像 HTTP/2 一樣，它始于 Google 的一項成果，并且現(xiàn)在已經(jīng)被 IETF 接納作為一個 HTTP-over-UDP 的初始用例，其目標(biāo)是在 2018 年底成為一個標(biāo)準(zhǔn)。然而，因為 Google 已經(jīng)在 Chrome 瀏覽器及其網(wǎng)站上部署了 QUIC，它已經(jīng)占有了超過 7% 的互聯(lián)網(wǎng)通訊份額。

閱讀 關(guān)于 QUIC 的答疑

除了大量的通訊從 TCP 到 UDP 的轉(zhuǎn)變（以及隱含的可能的網(wǎng)絡(luò)調(diào)整）之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求全程加密；并沒有非加密的 QUIC。

iQUIC 使用 TLS 1.3 來為會話建立密鑰，然后使用它去加密每個數(shù)據(jù)包。然而，由于它是基于 UDP 的，許多 TCP 中公開的會話信息和元數(shù)據(jù)在 QUIC 中被加密了。

事實上，iQUIC 當(dāng)前的 ‘短報文頭’ 被用于除了握手外的所有包，僅公開一個包編號、一個可選的連接標(biāo)識符和一個狀態(tài)字節(jié)，像加密密鑰輪換計劃和包字節(jié)（它最終也可能被加密）。

其它的所有東西都被加密 —— 包括 ACK，以提高 通訊分析 攻擊的門檻。

然而，這意味著通過觀察連接來被動估算 RTT 和包丟失率將不再變得可行；因為沒有足夠多的信息。在一些運營商中，由于缺乏可觀測性，導(dǎo)致了大量的擔(dān)憂，它們認(rèn)為像這樣的被動測量對于他們調(diào)試和了解它們的網(wǎng)絡(luò)是至關(guān)重要的。

為滿足這一需求，它們有一個提議是 ‘Spin Bit’ — 這是在報文頭中的一個回程翻轉(zhuǎn)的位，因此，可能通過觀察它來估算 RTT。因為，它從應(yīng)用程序的狀態(tài)中解耦的，它的出現(xiàn)并不會泄露關(guān)于終端的任何信息，也無法實現(xiàn)對網(wǎng)絡(luò)位置的粗略估計。

DOH

即將發(fā)生的變化是 DOH — DNS over HTTP。大量的研究表明，對網(wǎng)絡(luò)實施政策干預(yù)的一個常用手段是通過 DNS 實現(xiàn)的（無論是代表網(wǎng)絡(luò)運營商或者一個更大的權(quán)力機構(gòu)）。

使用加密去規(guī)避這種控制已經(jīng) 討論了一段時間了，但是，它有一個不利條件（至少從某些立場來看）— 它可能與其它通訊區(qū)別對待；例如，通過它的端口號被阻止訪問。

DOH 將 DNS 通訊搭載在已經(jīng)建立的 HTTP 連接上，因此，消除了任何的鑒別器。希望阻止訪問該 DNS 解析器的網(wǎng)絡(luò)只能通過阻止對該網(wǎng)站的訪問來實現(xiàn)。

例如，如果 Google 在 www.google.com 上部署了它的 基于 DOH 的公共 DNS 服務(wù)，并且一個用戶配置了它的瀏覽器去使用它，一個希望（或被要求的）被停止訪問該服務(wù)的網(wǎng)絡(luò)，將必須阻止對 Google 的全部訪問（向他們提供的服務(wù)致敬?。↙CTT 譯注：他們做到了）。

DOH 才剛剛開始，但它已經(jīng)引起很多人的興趣，并有了一些部署的傳聞。通過使用 DNS 來實施政策影響的網(wǎng)絡(luò)（和政府機構(gòu)）如何反應(yīng)還有待觀察。

閱讀 IETF 100， Singapore： DNS over HTTP （DOH?。?/p>

僵化和潤滑

讓我們返回到協(xié)議變化的動機，有一個主題貫穿了這項工作，協(xié)議設(shè)計者們遇到的越來越多的問題是網(wǎng)絡(luò)對流量的使用做了假設(shè)。

例如，TLS 1.3 有一些臨門一腳的問題是中間設(shè)備假設(shè)它是舊版本的協(xié)議。gQUIC 將幾個對 UDP 通訊進行限流的網(wǎng)絡(luò)列入了黑名單，因為，那些網(wǎng)絡(luò)認(rèn)為 UDP 通訊是有害的或者是低優(yōu)先級的。

當(dāng)一個協(xié)議因為已有的部署而 “凍結(jié)” 它的可擴展點，從而導(dǎo)致不能再進化，我們稱它為 已經(jīng)僵化了 。TCP 協(xié)議自身就是一個嚴(yán)重僵化的例子，因此，太多的中間設(shè)備在 TCP 協(xié)議上做了太多的事情，比如阻止了帶有無法識別的 TCP 選項的數(shù)據(jù)包，或者，“優(yōu)化”了擁塞控制。

防止僵化是有必要的，確保協(xié)議可以進化以滿足未來互聯(lián)網(wǎng)的需要；否則，它將成為一個“公共災(zāi)難”，一些個別網(wǎng)絡(luò)的行為 —— 雖然在那里工作的很好 —— 但將影響整個互聯(lián)網(wǎng)的健康發(fā)展。

有很多的方式去防止僵化；如果被討論的數(shù)據(jù)是加密的，它并不能被除了持有密鑰的人之外任何一方所訪問，阻止了干擾。如果擴展點是未加密的，但是通常以一種可以明顯中斷應(yīng)用程序的方法使用（例如，HTTP 報頭），它不太可能受到干擾。

協(xié)議設(shè)計者不能使用加密的擴展點不經(jīng)常使用的情況下，人為地利用擴展點——我們稱之為 潤滑 它。

例如，QUIC 鼓勵終端在 版本協(xié)商 中使用一系列的誘餌值，來避免假設(shè)它的實現(xiàn)永遠不變化（就像在 TLS 實現(xiàn)中經(jīng)常遇到的導(dǎo)致重大問題的情況）。

網(wǎng)絡(luò)和用戶

除了避免僵化的愿望外，這些變化也反映出了網(wǎng)絡(luò)和它們的用戶之間關(guān)系的進化。很長時間以來，人們總是假設(shè)網(wǎng)絡(luò)總是很仁慈好善的 —— 或者至少是公正的 —— 但這種情況是不存在的，不僅是 無孔不入的監(jiān)視，也有像 Firesheep 的攻擊。

因此，當(dāng)那些網(wǎng)絡(luò)想去訪問一些流經(jīng)它們的網(wǎng)絡(luò)的用戶數(shù)據(jù)時，互聯(lián)網(wǎng)用戶的整體需求和那些網(wǎng)絡(luò)之間的關(guān)系日益緊張。尤其受影響的是那些希望去對它們的用戶實施政策干預(yù)的網(wǎng)絡(luò)；例如，企業(yè)網(wǎng)絡(luò)。

在一些情況中，他們可以通過在它們的用戶機器上安裝軟件（或一個 CA 證書，或者一個瀏覽器擴展）來達到他們的目的。然而，在網(wǎng)絡(luò)不擁有或無法訪問計算機的情況下，這并不容易；例如，BYOD 已經(jīng)很常用，并且物聯(lián)網(wǎng)設(shè)備幾乎沒有合適的控制接口。

因此，在 IETF 中圍繞協(xié)議開發(fā)的許多討論，觸及了企業(yè)和其它的 “葉子” 網(wǎng)絡(luò)有時相互競爭的需求，以及互聯(lián)網(wǎng)整體的好處。

參與

為了讓互聯(lián)網(wǎng)在以后工作的更好，它需要為終端用戶提供價值、避免僵化、讓網(wǎng)絡(luò)有序運行?，F(xiàn)在正在發(fā)生的變化需要滿足所有的三個目標(biāo)，但是，人們需要網(wǎng)絡(luò)運營商更多的投入。

如果這些變化影響你的網(wǎng)絡(luò) —— 或者沒有影響 —— 請在下面留下評論。更好地可以通過參加會議、加入郵件列表、或者對草案提供反饋來參與 IETF 的工作。