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