網際網路協議正在發生變化

當上世紀九十年代網際網路開始被廣泛使用的時候，其大部分的通訊只使用幾個協議：IPv4 協議路由這些資料包，TCP 協議轉發這些包到連線上，SSL（及後來的 TLS）協議加密連線，DNS 協議命名那些所要連線的主機，而 HTTP 協議是最常用的應用程式協議。

多年以來，這些核心的網際網路協議的變化幾乎是微乎其微的；HTTP 增加了幾個新的報文頭和請求方式，TLS 緩慢地進行了一點小修改，TCP 調整了擁塞控制，而 DNS 引入了像 DNSSEC 這樣的特性。這些協議看起來很長時間都一成不變（除了已經引起網路運營商們的大量關註的 IPv6）。

因此，希望瞭解（甚至有時控制）網際網路的網路運營商、供應商和決策者對這些協議採用的做法是基於其原有工作方式 —— 無論是打算除錯問題，提高服務質量，或施加政策。

現在，核心網際網路協議的重要改變已經開始了。雖然它們意圖與網際網路大部分相容（因為，如果不相容的話，它們不會被採納），但是它們可能會破壞那些在協議中沒有規定的地方，或者根本就假設那些地方不存在變化。

為什麼我們需要去改變網際網路

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

首先，核心網際網路協議的侷限性越來越明顯，尤其是考慮到效能的時候。由於在應用和傳輸協議方面的結構性問題，網路沒有得到高效使用，導致終端使用者認為效能不能滿足要求（特別是，網路延遲）。

這就意味著人們有強烈的動機來演進或者替換這些協議，因為有 大量的經驗表明，即便是很小的效能改善也會產生影響[1]。

其次，演進網際網路協議的能力 —— 無論在任何層面上 —— 會隨著時間的推移變得更加困難，這主要是因為上面所討論的對網路的非預期使用。例如，嘗試去壓縮響應的 HTTP 代理伺服器使得部署新的壓縮技術更困難；中間裝置中的 TCP 最佳化使得部署對 TCP 的改進越來越困難。

最後，我們正處在一個越來越多地使用加密技術的網際網路變化當中[2]，首次激起這種改變的事件是，2015 年 Edward Snowden 的披露事件（LCTT 譯註：指的是美國中情局僱員斯諾登的事件）。那是一個單獨討論的話題，但是與之相關的是，加密技術是最好的工具之一，我們必須確保協議能夠進化。

讓我們來看一下都發生了什麼，接下來會出現什麼，它對網路有哪些影響，和它對網路協議的設計有哪些影響。

HTTP/2

HTTP/2（基於 Google 的 SPDY） 是第一個重大變化 —— 它在 2015 年被標準化。它將多個請求復用到一個 TCP 連線上，從而避免了客戶端排隊請求，而不會互相阻塞。它現在已經被廣泛部署，並且被所有的主流瀏覽器和 web 伺服器支援。

從網路的角度來看，HTTP/2 帶來了一些顯著變化。首先，這是一個二進位制協議，因此，任何假定它是 HTTP/1.1 的裝置都會出現問題。

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

當它被加密時，HTTP/2 請求也要求使用 TLS/1.2[4]，並且將一些已經被證明是不安全的演演算法套件列入黑名單[5] —— 其效果只允許使用短暫金鑰ephemeral keys。關於潛在的影響可以去看 TLS 1.3 的相關章節。

最終，HTTP/2 允許多個主機的請求被 合併到一個連線上[6]，透過減少頁面載入所使用的連線（從而減少擁塞控制的場景）數量來提升效能。

例如，你可以對 www.example.com 建立一個連線，也可以將這個連線用於對 images.example.com 的請求。而未來的協議擴充套件也允許將其它的主機新增到連線上[7]，即便它們沒有被列在最初用於它們的 TLS 證書中。因此，假設連線上的通訊被限制於它初始化時的目的並不適用。

值得註意的是，儘管存在這些變化，HTTP/2 並沒有出現明顯的互操作性問題或者來自網路的衝突。

TLS 1.3

TLS 1.3[8] 剛剛透過了標準化的最後流程，並且已經被一些實現所支援。

不要被它只增加了版本號的名字所欺騙；它實際上是一個新的 TLS 版本，全新打造的 “握手”機制允許應用程式資料從頭開始流動（經常被稱為 ‘0RTT’）。新的設計依賴於短暫金鑰交換，從而排除了靜態金鑰。

這引起了一些網路運營商和供應商的擔心 —— 尤其是那些需要清晰地知道那些連線內部發生了什麼的人。

例如，假設一個對可視性有監管要求的銀行資料中心，透過在網路中嗅探通訊包並且使用他們的伺服器上的靜態金鑰解密它，它們可以記錄合法通訊和識別有害通訊，無論是來自外部的攻擊，還是員工從內部去洩露資料。

TLS 1.3 並不支援那些竊聽通訊的特定技術，因為那也是 一種針對短暫金鑰防範的攻擊形式[9]。然而，因為他們有使用更現代化的加密協議和監視他們的網路的監管要求，這些使網路運營商處境很尷尬。

關於是否規定要求靜態金鑰、替代方式是否有效、並且為了相對較少的網路環境而減弱整個網際網路的安全是否是一個正確的解決方案有很多的爭論。確實，仍然有可能對使用 TLS 1.3 的通訊進行解密，但是，你需要去訪問一個短暫金鑰才能做到，並且，按照設計，它們不可能長時間存在。

在這一點上，TLS 1.3 看起來不會去改變以適應這些網路，但是，關於去建立另外一種協議有一些傳言，這種協議允許第三方去偷窺通訊內容，或者做更多的事情。這件事是否會得到推動還有待觀察。

QUIC

在 HTTP/2 工作中，可以很明顯地看到 TCP 有相似的低效率。因為 TCP 是一個按順序傳送的協議，一個資料包的丟失可能阻止其後面快取區中的資料包被髮送到應用程式。對於一個多路復用協議來說，這對效能有很大的影響。

QUIC[10] 嘗試去解決這種影響而在 UDP 之上重構了 TCP 語意（以及 HTTP/2 流模型的一部分）。像 HTTP/2 一樣，它始於 Google 的一項成果，並且現在已經被 IETF 接納作為一個 HTTP-over-UDP 的初始用例，其標的是在 2018 年底成為一個標準。然而，因為 Google 已經在 Chrome 瀏覽器及其網站上部署了 QUIC，它已經佔有了超過 7% 的網際網路通訊份額。

除了大量的通訊從 TCP 到 UDP 的轉變（以及隱含的可能的網路調整）之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求全程加密；並沒有非加密的 QUIC。

iQUIC 使用 TLS 1.3 來為會話建立金鑰，然後使用它去加密每個資料包。然而，由於它是基於 UDP 的，許多 TCP 中公開的會話資訊和元資料在 QUIC 中被加密了。

事實上，iQUIC 當前的 ‘短報文頭’[12] 被用於除了握手外的所有包，僅公開一個包編號、一個可選的連線識別符號和一個狀態位元組，像加密金鑰輪換計劃和包位元組（它最終也可能被加密）。

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

然而，這意味著透過觀察連線來被動估算 RTT 和包丟失率將不再變得可行；因為沒有足夠多的資訊。在一些運營商中，由於缺乏可觀測性，導致了大量的擔憂，它們認為像這樣的被動測量對於他們除錯和瞭解它們的網路是至關重要的。

為滿足這一需求，它們有一個提議是 ‘Spin Bit[14]’ — 這是在報文頭中的一個回程翻轉的位，因此，可能透過觀察它來估算 RTT。因為，它從應用程式的狀態中解耦的，它的出現並不會洩露關於終端的任何資訊，也無法實現對網路位置的粗略估計。

DOH

即將發生的變化是 DOH — DNS over HTTP[15]。大量的研究表明，對網路實施政策幹預的一個常用手段是透過 DNS 實現的[16]（無論是代表網路運營商或者一個更大的權力機構）。

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

DOH 將 DNS 通訊搭載在已經建立的 HTTP 連線上，因此，消除了任何的鑒別器。希望阻止訪問該 DNS 解析器的網路只能透過阻止對該網站的訪問來實現。

例如，如果 Google 在 www.google.com 上部署了它的 基於 DOH 的公共 DNS 服務[18]，並且一個使用者配置了它的瀏覽器去使用它，一個希望（或被要求的）被停止訪問該服務的網路，將必須阻止對 Google 的全部訪問（向他們提供的服務致敬！）（LCTT 譯註：他們做到了）。

DOH 才剛剛開始，但它已經引起很多人的興趣，並有了一些部署的傳聞。透過使用 DNS 來實施政策影響的網路（和政府機構）如何反應還有待觀察。

閱讀 IETF 100, Singapore: DNS over HTTP (DOH!)[19]

僵化和潤滑

讓我們傳回到協議變化的動機，有一個主題貫穿了這項工作，協議設計者們遇到的越來越多的問題是網路對流量的使用做了假設。

例如，TLS 1.3 有一些臨門一腳的問題是中間裝置假設它是舊版本的協議。gQUIC 將幾個對 UDP 通訊進行限流的網路列入了黑名單，因為，那些網路認為 UDP 通訊是有害的或者是低優先順序的。

當一個協議因為已有的部署而 “凍結” 它的可擴充套件點，從而導致不能再進化，我們稱它為 已經僵化了 。TCP 協議自身就是一個嚴重僵化的例子，因此，太多的中間裝置在 TCP 協議上做了太多的事情，比如阻止了帶有無法識別的 TCP 選項的資料包，或者，“最佳化”了擁塞控制。

防止僵化是有必要的，確保協議可以進化以滿足未來網際網路的需要；否則，它將成為一個“公共災難”，一些個別網路的行為 —— 雖然在那裡工作的很好 —— 但將影響整個網際網路的健康發展。

有很多的方式去防止僵化；如果被討論的資料是加密的，它並不能被除了持有金鑰的人之外任何一方所訪問，阻止了幹擾。如果擴充套件點是未加密的，但是通常以一種可以明顯中斷應用程式的方法使用（例如，HTTP 報頭），它不太可能受到幹擾。

協議設計者不能使用加密的擴充套件點不經常使用的情況下，人為地利用擴充套件點——我們稱之為 潤滑它。

例如，QUIC 鼓勵終端在 版本協商[20] 中使用一系列的誘餌值，來避免假設它的實現永遠不變化（就像在 TLS 實現中經常遇到的導致重大問題的情況）。

網路和使用者

除了避免僵化的願望外，這些變化也反映出了網路和它們的使用者之間關係的進化。很長時間以來，人們總是假設網路總是很仁慈好善的 —— 或者至少是公正的 —— 但這種情況是不存在的，不僅是 無孔不入的監視[21]，也有像 Firesheep[22] 的攻擊。

因此，當那些網路想去訪問一些流經它們的網路的使用者資料時，網際網路使用者的整體需求和那些網路之間的關係日益緊張。尤其受影響的是那些希望去對它們的使用者實施政策幹預的網路；例如，企業網路。

在一些情況中，他們可以透過在它們的使用者機器上安裝軟體（或一個 CA 證書，或者一個瀏覽器擴充套件）來達到他們的目的。然而，在網路不擁有或無法訪問計算機的情況下，這並不容易；例如，BYOD 已經很常用，並且物聯網裝置幾乎沒有合適的控制介面。

因此，在 IETF 中圍繞協議開發的許多討論，觸及了企業和其它的 “葉子” 網路有時相互競爭的需求，以及網際網路整體的好處。

參與

為了讓網際網路在以後工作的更好，它需要為終端使用者提供價值、避免僵化、讓網路有序執行。現在正在發生的變化需要滿足所有的三個標的，但是，人們需要網路運營商更多的投入。

如果這些變化影響你的網路 —— 或者沒有影響 —— 請在下麵留下評論。更好地可以透過參加會議、加入郵件串列、或者對草案提供反饋來參與 IETF[23] 的工作。

感謝 Martin Thomson 和 Brian Trammell 的評論。

本文作者 Mark Nottingham 是網際網路架構委員會的成員和 IETF 的 HTTP 和 QUIC 工作組的聯席主席。

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

作者：Mark Nottingham[25] 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出