此前，APNIC 首席科學家杰夫·休斯頓（Geoff Huston）發文，對互聯網發展 25 年的歷史進行回顧，并對互聯網未來發展進行展望?！吨袊逃W絡》雜志將分期刊載文章，本期將對互聯網的網絡層技術和傳輸層技術進行分析回顧。
如果說網絡傳輸系統在過去 25 年發生了巨大的變化，那么 IP 層在同一時期又發生了什么變化呢？
首先，我們需要考慮互聯網層房間里的“大象”。在互聯網協議棧層面，有一個根本性的變化本應在 20 年前就發生，那就是向 IPv6 過渡。25 年前，也就是 1998 年，我們預測到 2025 年左右將用完所有剩余的未分配的 IPv4 地址。這給了我們略多于 25 年的時間，因此我們并沒有緊迫感。我們不需要敲響警鐘或發出任何警報?？傮w目標是以有序的方式推進。
由于我們沒有意識到互聯網向移動設備轉移所帶來的真正影響，事情發生了變化。突然之間，我們面對的是一個擁有數十億用戶、使用數十億移動設備的互聯網，而我們對 IPv4 地址池穩步消耗的舒適預測被拋到九霄云外。從“有的是時間”到“沒時間做任何事”，我們只用了 1 年時間。
從 2005 年到 2010 年的 5 年間，移動服務數量激增，分配的 IP 地址總數從 15 億個地址增加到 31 億個，而 IPv4 地址池的地址總數為 37 億個。網絡規模擴大了一倍，完成過渡所剩下的時間從 20 多年縮短到 1 年多！
此時，所有有序過渡的計劃都被拋諸腦后，許多網絡管理員爭相獲取 IPv4 地址，這進一步耗盡了 IPv4 地址池。2011 年 2 月，由互聯網號碼分配局（Internet Assigned Numbers Authority，IANA）運營的中央 IPv4 地址池耗盡。APNIC（亞太互聯網絡信息中心）于同年 4 月耗盡其 IPv4 地址池，RIPENCC（歐洲網絡協調中心）于 18 個月后耗盡，LACNIC（拉丁美洲和加勒比海地區互聯網絡信息中心）于 2014 年耗盡，ARIN（北美互聯網注冊中心）于 2015 年耗盡。我們原以為這種情況會促使網絡運營商加快 IPv6 部署計劃，但事實并非如此。2011 年，使用 IP6 的互聯網用戶不到 1%。
5 年后，隨著各區域互聯網注冊管理機構（Regional Internet Registry，RIR）將其剩余的 IPv4 地址池用完，整個互聯網的 IPv6 用戶數量僅增加到 5%。到 2023 年，這一進程仍在進行，互聯網用戶中只有約 35% 擁有 IPv6 能力。我不確定是否有人愿意預測，這種在油箱耗盡的情況下運行 IPv4 互聯網的反常情況會持續多久。
在沒有新的 IPv4 地址供應的情況下，互聯網是如何繼續運行甚至發展壯大的？一言以蔽之，答案就是“NAT”。
雖然網絡地址轉換（Network Address Translation，NAT）的概念在首次發布時并沒有引起廣泛關注，但在過去的 25 年里，它得到了大規模的應用，如今 NAT 已無處不在。互聯網的應用架構已經發生了變化，我們現在使用的是客戶端/服務器體系架構。
服務器擁有永久的 IP 地址，而客戶端則“租用”公共的 IPv4 地址來完成交互，并在交互完成后將其歸還給公共地址池。分時共享 IP 地址以及使用 TCP（傳輸控制協議）和 UDP（用戶數據報協議）中的 16 位源端口字段，成功地將“準 IPv4”地址空間擴展了 20 位，使 IPv4+NAT 的地址空間比原來的 32 位 IPv4 地址空間大了 100 萬倍。
在實踐中，情況要更復雜，在使用 NAT 來彌補 IPv4 地址的耗盡方面，一些大型服務提供商的后勤能力已經達到了極限，促使他們過渡到雙棧運行模式。該模式依賴的是雙協議棧主機在可能的情況下更傾向于使用 IPv6 的行為，因此雙棧部署減輕了 IPv4NAT 功能的壓力。
NAT 引發了 IP 層面的重大變化，改變了對 IP 地址語義的默認假設。IP 地址不再是遠程方持久身份的同義詞，而是承擔了短暫會話令牌的角色。IPv6 過渡的緩慢步伐部分歸因于地址角色的改變，因為我們不再要求每個連接的設備都分配一個持久的全球唯一 IP 地址。
IPv6 和 NAT 并不是過去 25 年中互聯網層唯一活躍的領域。我們曾試圖改變互聯網層的許多部分，但幾乎沒有任何提議的變革能在網絡中獲得顯著的效果。協議棧中互聯網層的功能與 25 年前并無不同。移動 IP（IP Mobility）、多播和 IPSec（互聯網安全協議）在很大程度上都是互聯網層的技術，但卻未能在公共互聯網市場上獲得廣泛應用。
服務質量（Quality of Service，QoS）在 1998 年是一個熱門話題，它涉及尋找一種合理的方法，讓某些數據包以某種形式快速通過網絡，而其他數據包則使用無差別的方式通過網絡。我們嘗試了各種形式的信令、數據包分類器、隊列管理算法以及對 IPv4 數據包頭中服務類型（Type of Service）字段的解釋，并詳細探討了集成服務和差異化服務的 QoS 架構。
然而，QoS 一直未能在主流互聯網服務環境中占據一席之地。針對這個情況，互聯網采取了更為簡單的發展方向，對于網絡容量不足的問題，我們只需擴充網絡即可滿足需求。同樣的，這反映了通信系統從稀缺轉向豐富時的心態轉變。我們放棄了在網絡、主機協議棧甚至應用程序中安裝額外的復雜機制來協商如何共享不足的網絡容量。迄今為止，只需為網絡增加更多容量的簡單方法占據了上風，QoS 在很大程度上仍未得到應用。
從電路交換到分組交換的轉變從未獲得普遍認可。我們曾嘗試以各種方式將電路重新納入 IP 數據報的架構，其中最引人注意的是多協議標簽交換（Multi-Protocol Label Switching，MPLS）技術。
MPLS 采用了以前在 X.25、幀中繼（Frame Relay）和 ATM 虛擬電路交換系統中使用的標簽交換方法，并在 IP 網絡中創建了從每個網絡入口到每個網絡出口的虛擬路徑的集合。最初的想法是，在網絡內部，你不需要在每個交換元件中加載完整的路由表，相比于進行目標地址查找，你可以執行一個更小范圍的、更快的標簽查找。
這種方法在性能上的差異并沒有顯現出來，在完全加載的轉發表中使用 32 位目標地址來交換數據包，在硬件層面的成本效率仍與虛擬電路標簽交換基本相同。
然而，事實證明，MPLS 和類似方法對許多網絡運營商來說是無價之寶。通用網絡設施有許多不同的客戶網絡，而單一的分組交換環境不允許網絡運營商控制向每個客戶網絡分配公共網絡資源的方式。此外，它也不太容易支持對訪問域的隔離。MPLS 等虛擬電路覆蓋為控制資源分配和限制跨網絡泄漏提供了機制，對于許多網絡運營商來說，這些都是其網絡平臺采用類 MPLS 路徑的充分理由。
從協議棧的這一層橫向看，我們或許應該看看路由技術的演變。上世紀 90 年代初，路由領域活動頻繁，各種路由協議被迅速開發和部署。到 1998 年，傳統的路由技術選擇是使用 IS-IS 或 OSPF 作為域內路由協議，BGP-4 作為域間路由協議。這種情況一直保持到今天。一方面，看到一項基本技術能夠在多年的擴展過程中保持相當快的增長速度令人欣慰；但另一方面，看到 1998 年我們在路由系統遺留的尚未解決的問題在很大程度上至今仍然存在，就不那么令人欣慰了。
在這些未解決問題中，最大的一個是對互聯網域間路由系統的信任?；ヂ摼W的路由系統沒有整體的協調。每個網絡都會向其相鄰網絡發布可達性信息，并從這些網絡對等點（peers）所提供的可達性信息中選擇其認為“最佳”的信息。每個網絡對所有其他網絡的這種相互信任可以而且已經以各種方式被濫用。
要讓每個路由實體都能區分“正確”或“錯誤”的路由信息，我們提出了大量的倡議，但這些倡議都因為這樣或那樣的原因而失敗了。這一領域的最新成果建立在號碼系統的基礎上，并使用公私鑰來關聯持有者持有的地址和自治域號碼（Autonomous System Number，ASN）。這允許這些持有者能夠簽發關于使用這些路由相關號碼資源的授權，通過將這些授權與路由系統中傳播的信息結合起來，可以檢測到未經授權的使用情況。
經過努力，資源公鑰基礎設施（Resource Public Key Infrastructure，RPKI）已在網絡領域獲得一定程度的認可，到 2023 年，大約三分之一的路由對象都有相關的 RPKI 憑證。這項工作仍在進行中，因為這項工作更具挑戰性的方面是將可驗證的憑證與路由傳播關聯起來，既不給路由系統帶來沉重負擔，又不會使其在運營中過于脆弱。
路由系統長期在不可信任的狀態下運行，促使應用層產生了自己的信任機制。現在很大程度上依賴傳輸層安全性協議（Transport Layer Security，TLS）來確定客戶端是否訪問了預期的服務器。
鑒于我們幾十年來一直無法構建一個安全的路由系統，而在應用層空間，TLS 的使用幾乎無處不在，這在很大程度上解決了該問題。那么問題是，我們是否還像 25 年前那樣需要這樣一個安全的路由系統呢？
互聯網層與協議棧上層之間的這種緊張關系也體現在我們處理位置和身份這一長期問題的方式上。IP 架構一個最初的簡化是將標識、位置和轉發的語義打包到一個 IP 地址中[1]。
雖然這對簡化應用程序和 IP 網絡非常有效，但在考慮移動性、路由選擇、協議過渡和網絡擴展時，卻帶來了一些嚴峻的挑戰。如果互聯網體系結構允許標識與位置的分離，那么互聯網的上述各個方面都將受益匪淺。
在過去 10 年，特別是在 IPv6 中，許多工作圍繞這個問題展開，但到目前為止，我們還沒有找到一種在 IP 環境中真正讓人感覺舒適的方法。在過去 10 年中，我們似乎一直無法解決的問題是，如果創建了一個使用標識作為交會機制的應用框架，并使用需要位置的 IP 層，那么如何以高效和足夠健壯的方式分配標識和位置之間的映射呢？協議棧的傳輸層也研究了同樣的問題，并提出了一些有趣的方法，我們將在下一節中看到。
1998 年，IP 架構的傳輸層由 UDP 和 TCP 組成，網絡使用模式約為 95% 的 TCP 和 5% 的 UDP。經過 25 年的發展，這種情況終于發生了改變。
在此期間，我們開發了一些新的傳輸層協議，如數據擁塞控制協議（Datagram Congestion Control Protocol，DCCP）和流控制傳輸協議（Stream Control Transmission Protocol，SCTP），它們可以被視為對 TCP 的改進。DCCP 將流量控制機制擴展到數據報流；而 SCTP 在多個可靠流上共享流量控制狀態。然而，在感知傳輸層的中間件不斷發展的今天，在公共互聯網上部署這些新協議的能力充其量只能算微不足道。防火墻、NAT 等類似設備無法識別這些最新的傳輸層協議，因此，在公共互聯網大規模部署此類協議的前景并不樂觀。我們似乎還停留在 TCP 和 UDP 的世界里。
多年來的實踐證明，TCP 具有出色的適應能力，但隨著網絡容量的增加，TCP 能否在全球范圍內以更快的數據傳輸速率持續傳輸數據已成為一個重要問題。為修改 TCP 流量控制算法，使 TCP 能與其他并發 TCP 會話公平地共享網絡，同時又能將數據傳輸速率提升至每秒幾個 Gbit，并長時間保持該速率，我們已經做了大量工作。
主流的 TCP 流量控制協議已從傳統的 RENO 型協議轉向 CUBIC 算法。CUBIC 試圖找到一個穩定的發送速率，然后慢慢增加網絡路徑的流量壓力，以檢查網絡是否能支持更高的發送速率。對丟包的反應仍然是速率的急劇下降，但沒有 RENO 的速率減半那么劇烈，盡管如此，它仍然是一個對丟包敏感的 ack 步進式（ack-paced）流量控制協議。
然而，隨著 BBR（Bottleneck Bandwidth and Round-trip Propagation Time，瓶頸帶寬和往返傳播時間）協議的引入，情況發生了變化。驅動網絡形成網絡隊列，并進一步導致隊列溢出和數據包丟失，是一種粗糙的方法。這里的問題在于，數據包丟失代表著反饋的丟失。而在基于反饋的流量控制協議中，反饋的丟失將導致協議不得不降低發送速率以重建信號流。BBR 代表了一種不同的流量控制方式，它試圖根據網絡隊列形成的起始點而不是網絡隊列的崩潰點來導引流量。這樣可以減少流量的延遲，并通過降低對高速內存緩存的要求來降低網絡交換設備的成本。
這并不是改變 TCP 擁塞控制模式的唯一實驗領域。低延遲、低損耗、可擴展吞吐量架構（Low Latency Low Loss Scalable，L4S）正在探索另一種方法，它將網絡信號納入流量控制算法。在這種情況下，網絡中的數據交換機會在隊列形成時將 IP 頭中的顯式擁塞通知（Explicit Congestion Notification，ECN）信號寫入數據包。該信號的接收者會以類似于丟包的方式降低發送速率。這種方法的優點是不會丟失反饋信號，流量會對擁塞狀況的形成而不是隊列崩潰的終點做出反應。不過，ECN 需要部署 ECN 標記設備，與 BBR 等純協議方法相比，同步網絡設備和傳輸協議行為的工作量要大得多。
首先是多路徑 TCP（Multipath TCP）。我們的觀察是，Wi-Fi 和蜂窩無線網絡服務日益普及，并且大多數移動設備同時具有能夠訪問這兩種網絡的能力。一般來說，選擇使用哪個網絡接口是移動平臺為所有活動的應用程序做出的單一決定。當檢測到可用的 Wi-Fi 網絡時，設備會優先選擇使用該連接進行所有新的連接，因為它認為 Wi-Fi 服務對用戶來說更便宜，運行性能也更高。但是，如果性能是問題。那么適應性也是需要考慮的問題，我們能否允許 TCP 會話同時使用所有可用的網絡，并優化使用通往目的地的多個網絡路徑，從而優化總的數據吞吐量？
這就是多路徑 TCP 的目標，即把一個 TCP 會話分成幾個子會話，每個子會話使用不同的本地網絡接口，從而使用不同的網絡路徑。這就允許使用單獨的 TCP 狀態控制通過各個網絡路徑的流量，以優化吞吐量。它還允許流量遷移，允許邏輯 TCP 流量在保持完整性的同時，從一條網絡路徑切換到另一條網絡路徑。類似這種多路徑行為的有趣之處在于，這種行為最初是由應用程序，而不是主機平臺控制的。這是對邊緣網絡日益增長的容量和多樣性的早期應對，也是對如何在傳輸會話層面應對這種情況的早期回應。
第二是引入 QUIC（Quick UDP Internet Connection，快速 UDP 網絡連接）協議，我認為，這是傳輸能力和功能的根本性改變。簡單來說，QUIC 就是將 TCP 和 TLS 包裝成一個 UDP 封裝。不過，我認為這樣的描述遠遠不夠。
QUIC 在許多方面都是一個更加雄心勃勃的傳輸協議，它將傳輸技術提升到了更適合當前應用行為的地步，旨在通過更快的會話建立來改進加密流量的傳輸性能。QUIC 通過支持遠程過程調用（Remote Procedure Call，RPC），使傳輸機制得到進一步發展。
QUIC 還全面支持并發會話多路復用，避免了 TCP 的隊頭阻塞（Head-of-line blocking，HOL Blocking）。QUIC 對有效載荷數據進行加密，但與 TLS 不同的是，QUIC 還對控制數據（相當于 TCP 報頭）進行加密，并通過阻止會話與網絡控制交換的完整性，顯式地避免了網絡中正在顯現的 TCP 協議僵化現象。QUIC 具有地址靈活的特點，因為它可以在一個活躍 QUIC 會話中響應網絡層地址的重新編號，當網絡路徑上存在 NAT 時就會出現這種情況。QUIC 可以在用戶態實現，因此應用程序可以控制自己的傳輸功能，在傳輸服務的實施質量方面不再依賴于底層平臺。有了 QUIC，應用程序可以全面控制與網絡的交互方式。
從 QUIC 的經驗中我們可以汲取一些教訓。首先，任何有用的公共通信媒介都需要保護其傳輸通信的隱私性和完整性。開放協議代表效率、速度和隱私之間可接受的妥協折衷的時代已經一去不復返，如今，公共互聯網上的所有網絡事務都需要得到充分的加密保護。QUIC 將客戶端和服務器之間的數據和控制事務包裝到端到端加密狀態的模型，代表了當今網絡環境的最低功能水平。
其次，QUIC 提供了額外所需的傳輸層功能。TCP 和 UDP 只是更廣范圍的潛在傳輸模型的兩個功能點。UDP 太容易被濫用，所以我們把所有功能都集中在 TCP 上。問題在于，TCP 是作為一個高效的單一流協議而設計的，要在 TCP 中加裝多會話、短事務、RPC（遠程過程調用）、可靠的單數據包事務和共享擁塞狀態等功能，已被證明是不可能實現的。
目前，應用程序在互聯網生態系統中占據主導地位，而平臺和網絡正在被商品化。我們看到，人們對為其托管的應用程序提供通用傳輸服務的底層平臺失去了耐心，而新的模式是應用程序自帶傳輸的服務。
從更廣闊的視角來看，互聯網成功的背景在于將提供服務的責任從網絡轉移到了終端系統。這使我們能夠更有效地利用通用網絡的基底，并將網絡事務分組化的成本轉嫁給終端系統。它將創新的角色從龐大而笨重的電信運營商轉移到了更靈活的軟件世界。
QUIC 在此基礎上更進一步，將創新角色從平臺推向應用，而此時平臺在生態系統中的相對重要性正在下降。從這個角度來看，以應用為中心的傳輸模式的出現是一種不可阻擋的發展趨勢，它能提供更快的服務、更多的傳輸模式和全面的加密。
我們將端到端身份驗證的責任推給了傳輸層以及幾乎無處不在的 TLS。TLS 將自己置于 TCP 層之上（或在 QUIC 中與類似 TCP 的功能合并），客戶端將其打算連接的服務名稱傳遞給遠程服務器。服務器將它的公鑰傳遞給客戶端，客戶端使用自己的信任錨對該密鑰進行驗證。然后，服務器和客戶端協商一個會話密鑰，并進行加密會話。
TLS 幾乎在所有方面都很健壯。它的主要弱點在于高度分布式的信任模式，在這種模式下，有數百個不同的可信憑證運營商（Certification Authority，CA，證書頒發機構）和數千個不同的注冊代理。這些實體被置于高度可信的角色，它們永遠不會說謊。問題是，事實證明它們時常會被破壞。它們通常使用在線服務進行操作，對此類平臺的成功攻擊可能會被濫用，從而允許簽發受信任的公共證書。
我們投入了大量的時間和精力來鞏固這一信任框架，但與此同時，我們也一直在努力使這些公鑰證書成為一種商品，而不是昂貴的奢侈品。免費 CA 的引入成功地讓所有人都能獲得這些證書，但完全自動化的證書頒發流程也容易受到各種形式的濫用。
盡管有這些顧慮，我們還是將服務真實性和會話加密的重任全部交給了 TLS，以至于其他相關工作，如 IPSec、BGP 路由安全和 DNS 中的 DNSSEC，通常被視為可有可無的額外工作，而不是安全工具包中的必需品。
注 釋
[1] IP地址既是一個主機的唯一標識，又是主機的網絡位置，同時也表示訪問這個主機的尋址方法。
