雲端是一棟建築物
到目前為止，這道階梯把網路當成公共網際網路：一張由許多獨立網路組成的龐雜網狀結構，靠 IP 與路由協定黏合起來，由一條條為了共享鏈路上的空間而彼此競爭的 TCP 連線所穿越。那幅景象是真的，但你接觸到的大部分位元組從來不走那條路。當你打開一個應用程式，真正吃重的工作發生在一座資料中心裡——一座倉庫，塞滿了數萬甚至數十萬台伺服器，全部屬於同一個營運者，全部由一張他們從頭到尾自己設計的網路接在一起。雲端不是天上的某個地方。它是一棟建築物，而一種非常特別的網路就住在裡面。
那位唯一的擁有者改變了一切。在網際網路上，沒有人控制整條路徑，所以設計必須謹慎、去中心化，並且要容忍陌生人行為不端。在資料中心內，一個營運者擁有每一台交換器、每一條纜線、每一台伺服器，並能把整個系統當成一台機器來調校。他們可以挑選拓樸、選定定址方式、跑自己的協定，明年還能整個重建。所以你為狂野的網際網路學到的規則仍然成立，只是這位營運者得以彎折它們。本段位談的，就是他們用這份自由做了什麼。
現在流量是橫著走的
最大的意外是流量的方向。舊的網頁景象是南北向：一個請求從外部的使用者進來，單一一台伺服器回答，回覆再送出去。但一個現代的雲端服務不是一台伺服器——它是一群。為了組出一個網頁，前端伺服器會扇出（fan out）到數十個後端：這裡一個搜尋索引、那裡一個推薦模型、三個資料庫分片、一個快取、一個認證服務。它們每一個又可能呼叫別的。給使用者的回覆很小；伺服器之間為了產出它而進行的對話卻很龐大。這種從不離開建築物的伺服器對伺服器流量叫做東西向流量，在真實的資料中心裡它遠遠蓋過南北向流量，常常是十倍以上。
從物理上想像這個差別。南北向是顧客走過一道前門到櫃檯。東西向則是全體員工在幕後不停地在各個工作桌之間奔走、傳紙條，廚房對著吧台喊、再對著倉庫喊、再喊回來，每一筆顧客點單都要來回數百次。如果你只蓋了一道氣派的前門，卻忘了工作桌之間的走廊，這地方就會卡死。資料中心網路是「走廊優先」設計的：第一要務是讓任何一台伺服器都能快速地跟任何另一台伺服器對話，因為幾乎所有的流量其實就是這個。
兩個伺服器對伺服器的特質最要緊。一個是對分頻寬（bisection bandwidth）：想像把資料中心切成相等的兩半，問一次最多能有多少流量越過這道切口。高對分頻寬意味著無論誰在對話，任意對任意的通訊都不會塞住。另一個是低延遲——這裡要誠實：更多的頻寬並不能替你買到低延遲。它們是不同的東西。頻寬是管子有多寬；延遲是一則訊息花多久抵達；吞吐量是實際通過了多少。你打不過光速，但在一棟建築物裡距離極小，所以剩下的延遲大多是排隊與交換——而那恰好是營運者能用工程手段消去的部分。
把它接起來：從超額認購的樹到 Clos 架構
把建築物接起來的經典方法是三層式的樹。伺服器在最底層插進接取交換器（access switch）；接取交換器往上連到少數幾台匯聚交換器（aggregation switch）；匯聚再往上連到頂端一兩台強壯的核心路由器。位於不同接取交換器下的兩台伺服器之間的流量，必須爬上這棵樹再爬下來。麻煩就在這個攀爬。每往上一層，鏈路就更少、更繁忙，所以這棵樹是超額認購的：它的建造假設了不是所有人會同時對話。4 比 1 的超額認購意味著底層四個單位的需求共用上層一個單位的容量。對南北向的網頁流量這個賭注沒問題，但東西向流量會打破它——當每一台伺服器真的都在對話，上層的鏈路就塞死了。
現代的答案把設計翻轉過來：不要在頂端用少數幾條粗鏈路，而是用一大堆便宜、一模一樣的交換器組成網狀，讓往上的頻寬等於底層的頻寬。這就是 Clos／胖樹（fat-tree）的想法，它實際的形態就是葉脊架構。每台伺服器連到一台葉（leaf）交換器；每台葉連到每一台脊（spine）交換器；脊除了葉之外什麼都不連。於是任何一台伺服器抵達任何另一台都恰好是兩跳——上到一台脊、再下到目的地的葉——而且沒有塞住的頂端，因為有許多台脊平均分攤負載。要加容量，就加脊。完整的運作機制，以及胖樹為什麼能提供完整對分頻寬的數學，正是下一篇的全部內容。
網狀結構帶來一個令人開心的新問題：任兩台伺服器之間現在有許多條一樣好的路徑，每一台脊一條。你要怎麼把它們全用上？訣竅是ECMP（等價多路徑）：當一台交換器看到好幾個成本相等的下一跳時，它對每一條流（flow）的標頭欄位（來源與目的 IP、連接埠）做雜湊，挑出一條路徑，並把那條流釘在那條路上。不同的流雜湊到不同的脊，於是負載散布到整張架構上，同時單一條流的每一個封包都走同一條路、保持順序。它就像一位接待員，面對五座一模一樣的電梯，用一條規則把每位訪客送進某一座電梯——既讓任一位訪客的行李保持在一起，又讓五座電梯都忙著。
一張裡的兩張網：覆疊與虛擬交換器
還有第二個轉折。你在雲端租的伺服器通常不是整台機器，而是共用實體主機的虛擬機或容器，而且數千個彼此獨立的客戶（租戶）住在同一套硬體上。每個租戶都想要自己私有的網路——自己的 IP 範圍、自己的廣播網域——而且絕不能看到別的租戶的流量。但底下的實體架構是營運者只接過一次的、唯一的共享物。所以雲端同時跑著兩張網：真實的實體網路，也就是底層（underlay），以及在它之上為每個租戶畫出來的一張軟體定義的邏輯網路，也就是覆疊。
覆疊靠隧道（tunnel）運作，常用的工具是 VXLAN。當一個租戶的虛擬機送出一個封包，主機上的一段軟體——虛擬交換器，也就是那台實體機器眾多訪客的接待員——會把整個租戶封包包進一個全新的、定址在實體主機之間的外層封包裡，並貼上一個標籤說明它屬於哪個租戶。底層架構自始至終只看到、也只路由那個外層封包，主機對主機；它對租戶一無所知。在對面那台主機，虛擬交換器把它拆開，把原始封包交給正確的虛擬機。這其實就是封裝——一層套一層的信封——被拿來讓一張實體網路假裝成數千張私有網路。覆疊、虛擬交換器，以及替它們編程的控制器，就是第三篇的內容。
坐在建築物前門的，還有一個雲端的主力：負載平衡器。一個服務不是一台伺服器，而是一群一模一樣的伺服器，所以必須有個東西把進來的請求分散到它們之間、把故障的成員藏起來，並對外呈現一個穩定的位址。簡單的負載平衡器在傳輸層運作，引導整條 TCP 連線；更聰明的第七層負載平衡器會讀 HTTP 請求，按 URL 或 cookie 來路由。無論哪一種，它都是門口的領班，把每一組抵達的客人安排到任何一張空著的、一模一樣的桌子——這也正是雲端只靠加更多桌子就能把一個服務擴大的方式。
為微秒重寫的傳輸
現在來到你爬過的那個傳輸層段位被彎折得最厲害的部分。TCP 是為網際網路調校的，那裡的來回時間是數十毫秒、緩衝區很深。在資料中心內，來回時間是數十微秒——短了一千倍——而交換器的緩衝區很小。兩件在網際網路上無害的事，在這裡變得兇狠。第一個是incast（入射壅塞）：還記得那個一台前端查詢許多後端的扇出嗎？當所有那些後端幾乎在同一瞬間回答，它們的回覆同時湧向一個交換器連接埠、塞爆它小小的緩衝區，於是一連串封包被一起丟掉。傳統 TCP 對這個遺失的反應是退讓並等一個逾時——但一個逾時是數毫秒，在這裡是永恆。一場同步的回答風暴就能讓整個請求卡住。
第二個是微突發（microburst）。資料中心的流量是尖峰式的：一條鏈路可以幾乎閒置，卻在幾微秒內收到一陣突發封包，短暫地壓垮一個緩衝區。以一秒為單位平均，這條鏈路看起來是空的，所以容量圖表發誓什麼問題都沒有，然而封包正以短到看不見的突發被丟掉。兩個麻煩的解方都是一個更聰明的壅塞訊號。DCTCP 倚賴 ECN：交換器在它的佇列才剛開始堆積、遠在溢出之前就標記封包，而發送方按它看到多少標記成比例地反應——一個溫和、提早、分級的剎車，而不是盲目地等一次災難性的丟包。那位謹慎的駕駛現在儀表板上有了一盞預警燈。incast、微突發與 DCTCP 全部是第四篇的內容。
有些工作負載需要更快——分散式訓練、儲存、記憶體內資料庫想要一台機器在幾微秒內讀取另一台的記憶體，而即使是精簡的 TCP 堆疊，也花太多時間在作業系統裡複製資料與處理中斷。出路是 RDMA，遠端直接記憶體存取：一張網路卡直接寫進遠端伺服器的記憶體，主機 CPU 幾乎不插手，就像一間辦公室直接伸手進另一間的檔案櫃，而不是寄一份請求再等回覆。在普通的乙太網路架構上跑 RDMA 叫做 RoCE，它需要一張近乎無損的網路，這也是為什麼它倚賴 DCTCP 引入的同一套壅塞機制。奔向微秒的競賽，是第五篇、也是最後一篇。
前方的地圖
用一個畫面把它收攏。資料中心是一棟建築物，裡面的員工彼此交談遠多於跟顧客交談，所以它被接成一張扁平、有許多等價路徑的網狀結構，上面塗滿了數千張私有的覆疊網路，並跑在一個被重建成能在數微秒內剎車的傳輸堆疊上。它的一切特別之處都源自兩個事實：一個擁有者控制全部，以及流量大多是橫著走的。以下是本段位其餘的部分。
- 胖樹與葉脊：Clos 的想法如何用便宜、一模一樣的交換器堆出完整的對分頻寬、為什麼任意對任意都只需固定的跳數，以及一張架構能長多大的算術。
- 覆疊與虛擬交換器：在底層之上的 VXLAN 隧道、每台主機上的虛擬交換器，以及把數千張私有租戶網路編程到一張共享架構上的控制器。
- TCP Incast 與資料中心壅塞控制：為什麼扇出回覆與微突發會毀掉小小的緩衝區，以及 DCTCP 如何用提早的 ECN 標記做出溫和、成比例的剎車。
- RDMA 與奔向微秒的競賽：繞過作業系統、直接寫進遠端記憶體，乙太網路上的 RoCE，以及它所需要的近乎無損網路。