自上世紀(jì)九十年代互聯(lián)網(wǎng)開始得到廣泛使用時，大多數(shù)流量還僅使用少數(shù)幾種協(xié)議：IPv4 對數(shù)據(jù)包進(jìn)行路由、TCP 負(fù)責(zé)將這些數(shù)據(jù)包轉(zhuǎn)化為連接，SSL(以及之后的 TLS)進(jìn)行連接加密，DNS 命名所接入主機(jī)，再加上核心應(yīng)用協(xié)議 HTTP。
多年以來，這些核心互聯(lián)網(wǎng)協(xié)議的變化可謂微乎其微。HTTP 增加了一些新的標(biāo)頭與方法，TLS 緩慢完成小幅修改，TCP 終于能夠?qū)崿F(xiàn)擁塞控制，DNS 也引入了 DNSSEC 等功能。但更準(zhǔn)確地講，這些協(xié)議本身在相當(dāng)長的歷史周期內(nèi)幾乎沒有發(fā)生什么顯著變化(除了 IPv6，其已經(jīng)在網(wǎng)絡(luò)運(yùn)營商層面得到高度關(guān)注)。
也正因為如此，希望了解甚至控制互聯(lián)網(wǎng)的網(wǎng)絡(luò)運(yùn)營商、供應(yīng)商以及立法者們廣泛采取眾多基于上述協(xié)議的實踐手段，旨在借此實現(xiàn)問題調(diào)試、服務(wù)質(zhì)量改善以及政策執(zhí)行等等。
如今，核心互聯(lián)網(wǎng)協(xié)議正在發(fā)生重大變化。盡管將繼續(xù)與整體互聯(lián)網(wǎng)保持兼容(否則這些新協(xié)議將根本不會被采用)，但其仍有可能對并不熟悉網(wǎng)絡(luò)協(xié)議或者認(rèn)為網(wǎng)絡(luò)協(xié)議不會變化的用戶產(chǎn)生嚴(yán)重影響。
我們?yōu)楹涡枰七M(jìn)互聯(lián)網(wǎng)演變?
驅(qū)動互聯(lián)網(wǎng)演變的因素可謂多種多樣。
首先，核心互聯(lián)網(wǎng)協(xié)議存在的諸多局限已經(jīng)非常明顯，特別是在性能方面造成了重大問題。由于應(yīng)用與傳輸協(xié)議的自身結(jié)構(gòu)存在不足，網(wǎng)絡(luò)資源無法得到有效利用，而這又導(dǎo)致最終用戶面對糟糕的性能感受(特別是在延遲方面)。
正因為如此，業(yè)界開始抱有強(qiáng)烈的動機(jī)以演變或替換這些現(xiàn)有協(xié)議——因為大量事實證明，即使是極小的性能收益也會對用戶體驗產(chǎn)生巨大影響。
其次，隨著時間的推移，互聯(lián)網(wǎng)協(xié)議的演進(jìn)工作變得越來越困難，而其原因主要源自對網(wǎng)絡(luò)資源的各種非預(yù)期性使用方式。舉例來說，試圖對響應(yīng)進(jìn)行壓縮的 HTTP 代理使得我們很難部署新的壓縮技術(shù) ; 中間件中的 TCP 優(yōu)化機(jī)制亦使我們很難對現(xiàn)有 TCP 作出改進(jìn)。
最后，考慮到 2015 年曝出的愛德華 - 斯諾登事件，如今我們開始越來越多地在互聯(lián)網(wǎng)之上使用加密技術(shù)。這實際上可以算是另一個話題，但與之密切相關(guān)的是，加密技術(shù)已經(jīng)成為我們能夠用于確保協(xié)議持續(xù)發(fā)展的最佳工具之一。
在今天的文章中，我們將立足上述歷史背景，觀察網(wǎng)絡(luò)協(xié)議已經(jīng)發(fā)生了哪些變化、未來還將迎來哪些演進(jìn)，這會給網(wǎng)絡(luò)帶來怎樣的影響，以及網(wǎng)絡(luò)又會如何左右協(xié)議的設(shè)計思路。
HTTP/2
HTTP/2 (基于谷歌的 SPDY) 堪稱這場浪潮中的最大變化——其于 2015 年實現(xiàn)標(biāo)準(zhǔn)化，核心特征在于能夠?qū)⒍鄺l請求復(fù)用至同一 TCP 連接之上，這意味著能夠在不造成擁塞的前提下立足客戶端消除請求隊列需求。HTTP/2 如今已經(jīng)得到廣泛部署，且受到各大主流瀏覽器與 Web 服務(wù)器的通力支持。
從網(wǎng)絡(luò)的角度來看，HTTP/2 作出了一系列顯著的變化。首先，這是一項二進(jìn)制協(xié)議，因此任何使用 HTTP/1.1 的設(shè)備都無法與之兼容。
這種不兼容特性又給 HTTP/2 帶來了另一項重量級功能——即在客觀上要求全程加密。由于無法支持 HTTP/1.1，HTTP/2 能夠有效避免由前者帶來的中間人干擾，或者去標(biāo)頭乃至屏蔽新協(xié)議擴(kuò)展等可能給支持工作帶來巨大麻煩的問題。
HTTP/2 還要求配合 TLS/1.2 以完成加密操作，同時會將被判定為不安全類別的密碼套件列入黑名單(即僅允許其使用臨時性密鑰)。具體請參閱本文中的 TLS 1.3 部分以了解更多相關(guān)信息。
最后，HTTP/2 還允許將多臺主機(jī)的請求合并至同一連接當(dāng)中，這將有效減少用于頁面加載的連接數(shù)量，進(jìn)而降低控制情境擁塞以提高性能水平。
舉例來說，我們可以為 www.example.com 建立連接，但也可以利用其處理指向 images.example.com 的請求。未來的各類協(xié)議擴(kuò)展可能還將允許向連接當(dāng)中添加更多其它主機(jī)，無論這些主機(jī)是否在其原始 TLS 證書當(dāng)中列出。因此，屆時連接上的流量很可能將僅限于其初始目的——而無法被作為它用。盡管存在上述變化，但值得注意的是，HTTP/2 似乎并不存在嚴(yán)重的互操作性問題，亦未受到來自網(wǎng)絡(luò)的干擾。
TLS 1.3
TLS 1.3 正在經(jīng)歷最后的標(biāo)準(zhǔn)化流程，且已經(jīng)得到了一定程度的實際性支持。
但千萬別被 1.3 這樣的表述所迷惑——TLS 1.3 實際上已經(jīng)屬于全新版本，其中經(jīng)過徹底修改的握手機(jī)制使得應(yīng)用程序數(shù)據(jù)自起始階段即開始流通(通常被稱為‘0RTT’)。新的設(shè)計采用臨時性密鑰交換，旨在替代原有靜態(tài)密鑰機(jī)制。
這樣的調(diào)整已經(jīng)引起部分網(wǎng)絡(luò)運(yùn)營商與服務(wù)供應(yīng)商的關(guān)注——特別是那些需要了解連接內(nèi)部實現(xiàn)機(jī)制的相關(guān)方。
舉例來說，銀行的數(shù)據(jù)中心需要滿足可見性監(jiān)管要求。通過嗅探網(wǎng)絡(luò)中的流量并利用服務(wù)器靜態(tài)密鑰進(jìn)行流量解密，銀行數(shù)據(jù)中心能夠記錄合法流量并識別惡意流量——包括來自外部攻擊者的流量乃至源自內(nèi)部員工的數(shù)據(jù)竊取行為。
TLS 1.3 并不支持對流量進(jìn)行攔截的特定技術(shù)，其臨時性密鑰甚至?xí)⒋俗鳛橐活愄囟ü粜袨榧右苑雷o(hù)。這意味著對于既需要利用現(xiàn)代加密協(xié)議、又需要監(jiān)控自有網(wǎng)絡(luò)的網(wǎng)絡(luò)運(yùn)營商而言，目前的狀況使其陷入了兩難的尷尬境地。
目前就此已經(jīng)出現(xiàn)了諸多爭議，包括是否應(yīng)當(dāng)遵循監(jiān)管要求中提出的靜態(tài)密鑰使用指導(dǎo)、是否可利用其它替代性方案獲得相同的效果，以及是否應(yīng)當(dāng)削弱整體互聯(lián)網(wǎng)安全性以換取相對少數(shù)網(wǎng)絡(luò)的合規(guī)能力等等。事實上，目前我們?nèi)匀挥心芰?TLS 1.3 中的流量進(jìn)行解密，但這要求相關(guān)方訪問臨時密鑰——這顯然與臨時密鑰的設(shè)計目標(biāo)有所沖突。
就目前而言，TLS 1.3 似乎不會進(jìn)一步改變以適應(yīng)此類網(wǎng)絡(luò) ; 但已經(jīng)出現(xiàn)了一些建立新的協(xié)議以滿足上述需求的傳聞。據(jù)稱這一新協(xié)議將允許第三方觀察用例細(xì)節(jié)信息，甚至開放更多功能。但這種主張能否得到市場肯定，尚有待進(jìn)一步觀察。
QUIC
在對 HTTP/2 的研究當(dāng)中，有證據(jù)表明 TCP 已經(jīng)成為阻礙傳輸效率的一大弊端。由于 TCP 屬于一項有序傳輸協(xié)議，因此單一數(shù)據(jù)包的丟失即有可能阻止后續(xù)緩沖區(qū)內(nèi)的數(shù)據(jù)被順利交付至應(yīng)用程序。對于多路復(fù)用協(xié)議而言，這樣的情況很有可能給最終性能造成嚴(yán)重影響。
QUIC 試圖在 UDP 之上有效重建 TCP 語義(以及部分 HTTP/2 流模式)。與 HTTP/2 類似，QUIC 最初源自谷歌公司的內(nèi)部項目，而目前此項目已經(jīng)由 IETF 接手——其初始用例為 HTTP-over-UDP，下階段發(fā)展目標(biāo)為截至 2018 年年底前成為行業(yè)標(biāo)準(zhǔn)。由于谷歌已經(jīng)將其引入 Chrome 瀏覽器以及自家官方網(wǎng)站，因此 QUIC 目前已經(jīng)占據(jù)互聯(lián)網(wǎng)整體流量中的 7% 以上。
除了由 TCP 轉(zhuǎn)向 UDP 以實現(xiàn)流量大小調(diào)節(jié)能力(以及其它潛在的網(wǎng)絡(luò)調(diào)節(jié)指標(biāo))之外，谷歌 QUIC(簡稱 gQUIC)與 IETF QUIC(簡稱 iQUIC)皆要求對執(zhí)行流程進(jìn)行加密 ; 目前不存在任何非加密形式的 QUIC。
iQUIC 采用 TLS 1.3 為會話建立密鑰，而后利用這些密鑰加密每個數(shù)據(jù)包。但由于其基于 UDP，因此原本在 TCP 中得到公開的大量會話信息與元數(shù)據(jù)將在 QUIC 中接受加密。
事實上，iQIUC 目前的“短標(biāo)頭”——用于除握手?jǐn)?shù)據(jù)包之外的全部數(shù)據(jù)包——僅公開數(shù)據(jù)包編號、可選連接標(biāo)識符以及一個用于描述加密密鑰輪換計劃與數(shù)據(jù)包類型等狀態(tài)的字節(jié)(此字節(jié)最終也可能被加密)。
其它的全部信息都將進(jìn)行加密——具體包括 ACK，這將大大增加流量分析攻擊活動的實施難度。然而，這同時意味著我們無法通過觀察連接本身被動估計 RTT 與丟包情況——因為其中包含的信息不足以支持這種判斷。觀察能力的缺失引起了運(yùn)營商們的高度關(guān)注，他們認(rèn)為這種被動的測量能力對于理解并調(diào)試自身網(wǎng)絡(luò)服務(wù)至關(guān)重要。
為了滿足這類需求，運(yùn)營商們建議設(shè)置所謂“Spin Bit”——即存在于標(biāo)頭當(dāng)中、并在每次流量往返時進(jìn)行一次翻轉(zhuǎn)的 bit，觀察者將能夠借此估算 RTT。由于其與應(yīng)用程序自身的狀態(tài)不再關(guān)聯(lián)，因此除了能夠用于粗略估算網(wǎng)絡(luò)位置之外，該 bit 似乎不會泄漏關(guān)于端點的任何其它信息。
DOH
DOH 堪稱互聯(lián)網(wǎng)協(xié)議領(lǐng)域的最新變化成果——即 DNS over HTTP。目前已經(jīng)有大量研究表明，網(wǎng)絡(luò)通常利用 DNS 作為實施管理政策的手段(包括網(wǎng)絡(luò)運(yùn)營商以及其它規(guī)模更大的權(quán)威機(jī)構(gòu))。
我們之前已經(jīng)討論了利用加密以限制這種控制能力，但其在某種程度上講仍然存在缺陷——其能夠被與其它流量區(qū)分開來 ; 例如利用其端口編號以阻斷訪問。
DOH 能夠很好地解決這個問題。其會將 DNS 流量搭載至現(xiàn)有 HTTP 連接之上，這意味著不再需要任何鑒碼機(jī)制。要阻斷指向該 DNS 解析器的訪問，網(wǎng)絡(luò)只能直接屏蔽全部指向該網(wǎng)站的全部訪問。
舉例來說，如果谷歌公司在 www.google.com 上通過 DOH 部署其公開 DNS 服務(wù)，而某位用戶通過配置瀏覽器的方式對其加以使用，則希望阻止這種使用行為的網(wǎng)絡(luò)必須徹底屏蔽全部谷歌訪問請求(這主要由谷歌自身的服務(wù)托管方式所決定)。
DOH 目前才剛剛興起，但已經(jīng)在行業(yè)之內(nèi)引起了高度關(guān)注并得到一定支持。我們?nèi)栽诶^續(xù)觀察各類網(wǎng)絡(luò)與政府機(jī)構(gòu)如何利用 DNS 機(jī)制實施自身管理政策。
“僵化”與“潤滑”
下面回到動機(jī)層面的討論，其中的一大重點在于協(xié)議設(shè)計者們?nèi)绾谓鉀Q由網(wǎng)絡(luò)流量處理假設(shè)所帶來的問題。
舉例來說，中間件由于默認(rèn)將 TLS 1.3 當(dāng)作較早版本而引發(fā)不少新的問題 ; gQUIC 則將多個對 UDP 流量進(jìn)行限流的網(wǎng)絡(luò)(理由是其可能屬于有害或者低優(yōu)先級流量)納入黑名單。
當(dāng)一項協(xié)議由于擴(kuò)展點“凍結(jié)”而無法繼續(xù)演進(jìn)時，我們將其狀態(tài)描述為“僵化”。TCP 本身就是一種僵化實例 ; 因為大量中間件需要在 TCP 上執(zhí)行大量處理任務(wù)——包括對未能識別的 TCP 選項進(jìn)行阻斷，或者“優(yōu)化”擁塞控制機(jī)制。
只有阻止此類“僵化”問題，才能確保各類網(wǎng)絡(luò)協(xié)議通過持續(xù)演變以滿足未來互聯(lián)網(wǎng)的發(fā)展需求 ; 否則，悲劇將再度重演——即盡管意圖良好，但某些個別網(wǎng)絡(luò)行為仍會對互聯(lián)網(wǎng)的整體健康造成負(fù)面影響。我們可以通過多種方式防止此類僵化問題 ; 如果相關(guān)數(shù)據(jù)已經(jīng)被加密，則只有使用密鑰才能對其進(jìn)行訪問，這將有效防止額外干擾。而如果某一擴(kuò)展點未經(jīng)加密，但具體使用方式?jīng)Q定其可見性不高(例如 HTTP 標(biāo)頭)，則同樣不太可能受到干擾。
在協(xié)議設(shè)計者無法使用加密機(jī)制且擴(kuò)展點使用頻度不高的情況下，人為使用擴(kuò)展點將有助于解決此類問題——我們將這種方式稱為“潤滑”。
舉例來說，QUIC 鼓勵端點在其版本協(xié)商當(dāng)中利用一系列假值以避免其被假設(shè)為永遠(yuǎn)不會發(fā)生變化(這類情況在 TLS 實現(xiàn)場景中經(jīng)常出現(xiàn)，并往往帶來顯著問題)。
網(wǎng)絡(luò)與用戶
除了避免僵化問題之外，上述變化也反映出網(wǎng)絡(luò)與用戶之間不斷變化的互動關(guān)系。長久以來，人們一直將網(wǎng)絡(luò)視為正面——或者至少是中立性質(zhì)的環(huán)境。但情況如今已經(jīng)開始變化，特別是在政府監(jiān)督日益升級與 Firesheep 等攻擊活動的雙重沖擊之下。
如此一來，互聯(lián)網(wǎng)用戶的整體需求與獲取網(wǎng)絡(luò)內(nèi)一定程度數(shù)據(jù)流量的監(jiān)管要求就構(gòu)成了日益升級的緊張關(guān)系。其中受影響最為明顯的當(dāng)數(shù)企業(yè)網(wǎng)絡(luò)這類希望對用戶施加管理政策的網(wǎng)絡(luò)體系。
在某些情況下，企業(yè)網(wǎng)絡(luò)可通過在用戶設(shè)備上安裝軟件(或者 CA 證書，或瀏覽器擴(kuò)展)的方式達(dá)成目標(biāo)。然而，當(dāng)無法接入網(wǎng)絡(luò)或者無法訪問客戶計算機(jī)的情況下，問題就變得很難解決?？紤]到 BYOD 已經(jīng)變得非常普遍，而物聯(lián)網(wǎng)設(shè)備更是極少提供適當(dāng)?shù)目刂平涌?，情況已經(jīng)非常非常復(fù)雜。
因此，IETF 內(nèi)部圍繞協(xié)議發(fā)展議題出現(xiàn)了大量討論，旨在尋求能夠諧調(diào)企業(yè)及其它“分支”網(wǎng)絡(luò)相互競爭的問題，進(jìn)而為整體互聯(lián)網(wǎng)帶來助益。
- 更多相關(guān)內(nèi)容
- 互聯(lián)網(wǎng)協(xié)議的演變之路
數(shù)字化要一盤棋更要各自為戰(zhàn)
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。