TCP 是網絡協議集中的核心協議。它將底層 IP 協議提供的不可靠數據包傳輸服務變為一種可靠的數據流協議。它無疑是計算機網絡進化歷程中最偉大的變革。

TCP 出現之前，計算機網絡協議期望計算機可以通過網絡得到一種無損可靠的服務，并一直致力于對它的研究。DECnet 的 DDCMP 就是一種無損的數據連接控制協議。X.25 是 telsaur world 為連接到的電腦所提供的一種可靠的流式協議。我還記得在 Ethernet 問世之初因它缺乏可靠的確認機制而受人指責。是 TCP 的出現改變了這一切。TCP 將所有提供可靠數據傳輸的功能從底層網絡轉移到 TCP 會話兩端的電腦的共享狀態中。TCP 體現了網絡架構的端到端原則，即將可以由會話終端提供的功能放在底層網絡中并沒什么好處。TCP 需要的是一種更加簡單的網絡服務，在這種網絡上數據包可以無序傳輸或丟棄，但 TCP 協議能夠檢測到并修復這些問題，以保證傳送到終端程序的比特流與傳入 TCP socket 的原始數據完全相同。TCP 協議到現在已經有

40年歷史了，但這并不意味著它將在近些年被凍結。

TCP 不僅是一中可靠的數據傳送流協議，而且一種采用自適應速率控制的協議。TCP 可以以一種允許協議將盡可能多的數據通過網絡的模式工作。一個常見的運作模式是：一個單獨的 TCP 會話會不斷探索最高的可傳輸數據率，通過分析丟包來降低發送速率并重復探索。TCP 的這方面的是一個不斷被研究的領域，在流動控制領域已經做了許多的工作，目前有許多不同的 TCP 嘗試來優化各種網絡環境下的流量。

其他的工作瞄準在 TCP 的數據確認上，嘗試在各種各樣的條件下提高算法效率。SACK 允許接收端發送回更多的信息來響應發送端的丟失。FACK 指示在慢啟動時數據丟失的問題。

提高數據傳輸路徑也是一種嘗試方法，相比同時打開多個 TCP 會話，這種方式將數據分成多個部分，然后每個會話發送其中的部分。有效開放多個并行的 TCP 會話。一個 TCP 的變體，MulTCP，在一個 TCP 會話模擬多個并行的 TCP 會話的行為。這些行為為并行的 TCP 會話假設相同的端點幾相同的端到端網絡路徑。一個使用多個并行會話的 TCP 進化，但試圖通過網絡以多種路徑傳輸這些會話，這就是多路徑 TCP。

多路徑 TC P有過一個短暫的曝光，據透露，蘋果 iOS 7為其 Siri 應用包含一個多徑TCP的實現，但它有可能在移動互聯網中發揮更大的作用。在這篇文章中我將更詳細地探討這個 TCP 選項，看它是如何工作，看它如何在今天的移動網絡中發揮作用。

IP多址

首先我們要回到一個基本的網絡概念，即尋址和地址。IP 協議里的地址與 1970 年和 1980 年通常使用的其他計算機通信協議有細微的不同。當時許多其他協議將其所使用的通信協議層地址作為主機地址，IP 協議小心的選擇聯想到了連接到網絡接口的 IP 地址。這是在大多數情況下這是一個相對不重要的區別，當時的計算機通常只有一個單一的網絡接口。但當計算機有兩個或兩個以上的接口連接到兩個或兩個以上的網絡時，這卻是一個重要的區別。一臺 IP 主機有兩個網絡接口有兩個 IP 協議地址，一個接口一個。在 IP 協議里它是設備間的接口，在網絡里它是通信的地址端點。IP 主機會接受網絡接口中接收到數據包中與自己 IP 地址匹配的包，而發送數據包時，發送數據包的源地址是其用于把數據包從主機發送到網絡接口的IP地址。

這個模型的網絡尋址盡可能的簡單，但也存在一些操作上的問題。這種尋址的一個含義是：當一個主機有多個接口，使用 TCP 協議的應用層會話有一定“粘性”。比如，當一個網絡接口已經開啟一個 TCP 會話時，主機網絡棧不能立馬地遷移到另一個接口，因為這個會話正保持活動狀態。試圖通過“結束”的一個 TCP 會話而更改會話對端為另一個IP地址通常不會在原會話對端被承認。因此多接口和多個地址不會增加 TCP 連接的額外彈性。

只是簡單地給每個網絡接口配置唯一的 IP 地址并不滿足所有應用場景的需求，而且沒過多久就有了“輔助地址”了。給一臺主機賦予多個地址的一種方法就是給一個網絡接口配置多個 IP 地址。傳輸層可以給流出的數據包指定源 IP 地址，這樣就不會采取默認的動作，即源 IP 地址為流出數據包所在接口的主地址。輔助地址有自己適用的場合，特別是你試圖在單一平臺上實現多個應用時尤其如此，不過，在 IPV4 環境下，輔助地址是針對特定需求而提出的特定解決方案，而不是通用方案。

使用 TCP 的應用還與初始化 TCP 握手時所采用的 IP 地址“緊密關聯”，因此會話不可能在同一接口上的輔助地址間相互轉換。

IPv6的尋址方式稍有不同。IPv6協議從誕生那一刻起就允許對單個接口指定多個IPv6單播地址，而且沒有主次之分。IPv6協議還引入了“地址適用范圍”這一理念，這樣可以確保一個地址要么在本地連接網絡中是唯一的，要么是一個全局地址。基于隱私方面的考慮還引入了永久地址和臨時地址，為了支持移動性還引入了“最終地址”和“轉發地址”。

IPv6從某種程度來說只是對原來IPv4地址模型作了表面上的修改。如果一個IPv6主機有多個接口，那么每個接口都擁有一組IPv6地址。而且如果TCP會話在一對地址上啟動后，那么在這個TCP會話期間，TCP就無法轉換到另一對地址上。在一個網絡接口上啟動的TCP會話與這一網絡接口緊密相關，不管這個接口配置的IPv4地址還是IPv6地址都是如此。

隨著移動互聯網的引入，互聯網已經發生了顯著的變化，多路徑的討論主題也轉移成了許多移動相關的問題。移動設備上附著著許多 IP 地址。蜂窩無線接口上也有 IP 地址集。這些“智能”設備中許多也有 WiFi 接口，也有可能有 IPv4 和 IPv6 地址。還可能會有具有 IP 地址的藍牙接口，興許還有一些 USB 的網絡接口。當啟用時每一個網絡接口都需要其本地 IP 地址。我們現在所處的互聯網中設備具有多個可用 IP 地址是相對較為普遍的。但我們如何利用這些地址呢?

在大多數情況下使用多地址是不值當的。常見的習慣是每一個新的會話是針對特定接口的，給會話的出站地址是通過本地策略決定的。但是，當我們開始考慮應用綁定的位置和標識時是非常多變的，網絡連接是瞬態的，連接的成本和容量是不同的，因而現今通常的情況是這樣的，移動蜂窩無線電服務和 WIFI 漫游服務會話，擁有一定數量的敏捷性跨網絡轉換是一個重要的因素。

如果一個端到端的會話能使用多地址，而且以此推理也能使用到多接口。那么應用就可以在移動數據鏈路和WiFi之間進行無縫數據傳輸，或者可以同時利用兩鏈路進行傳輸。假如接口的 IPv4 地址和 IPv6 地址是等同地位的，那么在兩種協議之間進行無縫地數據傳輸也是可實現的。至于在某個時刻使用哪種傳輸服務不再由移動運營商或者 WiFi 運營者，或者設備，或者運行的操作系統決定。如果應用能夠使用到多地址，多協議和多接口，那么應用自身就可以根據各個連接是關閉還是可用狀態來決定怎樣選擇連接才能最好的滿足自身需求。同時，由于已分配到頻譜的傳統的移動運營商和未分配到頻譜的WiFi運營商之間就獲取未分配頻譜的爭論將會不斷升溫，自然“WiFi 傳輸“到底是由設備還是應用來實現就會隨著事態的發展而變化。最終會改變傳輸功能的控制者。多地址 TCP 和多路徑 TCP 是對這種爭論的一種備受關注的響應：讓應用自身來決定多連接環境下該如何選擇。

SHIM6

在IP上利用多地址的第一次嘗試就是在IPv6上進行的SHIM6。

在這種情況下，目的就是在多外部連接的端站點的彈性，而且約束是避免對端站點使用獨立路由的IPv6地址前綴。因此這就是在沒有路由碎片的情況下支持站點多宿主所做的努力。為了理解SHIM6模式，我們需要從不能獨自提供獨立IPv6地址前綴的端站點開始，但是要連接到兩個或以上，上游的運輸提供者，它們每個都能對端站點提供地址。在IPv4中，經常看到與網絡地址解析器(NATs)相連的場景。IPv4中，站點是內部地址所使用的專用地址前綴，而且接口到每一個能提供NAT的上游提供者。出站的包為了使用地址要重寫源地址，這是作為轉換NAT提供者前綴的一部分。提供者提供用于朝向各的NAT內部路由策略的情況。雖然在IPv6中使用IPv6ULA作為外部地址以及NAT IPv6對IPv6設備到每一個上游的服務提供商的配置可能相似，一個隱藏在IPv6和大量增長的地址空間背后的概念就是消除NATs。如何才能使IPv6端站點成為多個上游服務提供商的宿主，而不需要在域間路由表或避免任何形式的網絡地址轉換中通知使用更具體的路由條目?

傳統意義上的 IPv6 架構是指，單個站點接收到每個上游服務提供商分發的站點前綴，再由接口路由廣播到站點內部。站點內部的主機接收到路由廣播，對每個站點前綴完成 UPv6 地址的接口配置。多宿主配置給站點提供了更多的靈活性。假如站點與一個服務提供商的連接失效了，如果站點在每一層都以獨立組件的方式實現了多宿主配置，便可以重新建立其他可用的連接。實施了這種路由系統方案之后，如果一個上游服務提供商無法提供解析到一個特定地址的服務，便可以不中斷的連接到另外一個可以提供實時端對端會話的上游服務提供商。

SHIM6 嘗試以基于主機的方式，使用額外的本地 IPv6 地址建立到達目的地址的潛在鏈路。如果與遠端主機的通訊失效了(接收不到遠端主機發送的報文)，一個解決方案就是本機上的 ip 層 shim 切換使用另外一個(源/目的地址) 地址對。在一個或多個實時會話中，本地 SHIM 模塊包含了一個網絡地址轉換函數，防止地址的變化影響到上層傳輸協議層。當電纜上傳輸的地址對發生變化之后，shim通過網絡地址轉換函數對上層傳輸協議層隱藏了地址對的變化，所以對上層傳輸協議層來說地址對一直是固定的。

這個解決方案本質上就是把 NAT 函數應用到主機的 ip 協議棧上。從設計的角度來說，它避免了對 TCP 和 UDP 的修改，保證了傳輸會話中使用的 ip 地址保持不變。也就是說，如果需要更換路由鏈路，又要保證傳輸層的 ip 地址保持不變，就必定會用到地址轉換技術。IPv4 使用基于網絡的 NATs 技術發送響應，不同的是，IPv6 在每臺主機上都應用了 NAT 技術，通過這種方式 SHIM6 試圖把 NAT 技術進一步推向“幕后”。

然而 SHIM6 并不是一個能讓所有人都滿意的解決方案。

網絡運營商對于把決定權交給獨立的主機的做法表達了強烈的質疑。網絡運營商希望在他們的網絡中控制連通結構，進一步來說，就是像路由系統一樣提供流量的網絡控制服務。SHIM6 的目標是讓站點從上游獲取 IPv6 地址前綴，避免主機路由表變得更加臃腫，但同時也降低了站點的“獨立性”。盡管對于這點表示贊同，運營商還是反對把連接的選擇和控制權交還給獨立的主機終端系統。

除此之外，SHIM6 還遇到了另外一個多宿主的問題。備用鏈路不僅在當主鏈路不可用的時候可以起到作用，更為重要的是，可以通過共享配置來使用備用鏈路。但是，在這里 SHIM6 遇到了問題。SHIM6 部署在在 IP 層，它不能直接區分數據包的先后順序。在一個會話中，一端的 SHIM 單元可以把一組數據包通過不同的鏈路發送出去，在遠端對應的 SHIM 單元會把數據包按照抵達的順序，而不是原始的數據包順序，傳遞給上層的傳輸層。如果 SHIM 使用了多條鏈路，這種亂序分發會對 TCP 造成嚴重的問題。最好的解決方法是為每個會話提供一個主備鏈路方案，每個會話總是使用主鏈路來傳遞數據。

最后我們得出一個很嚴峻的結論，目前在網絡中大多數使用不同潛在鏈路傳遞流量的地方還只是局限在傳輸層。我們需要進一步的推進 SHIM6 的發展，重新審視 TCP 的發展前景。

多通道 TCP

與 SHIM6 相比，在傳輸層合并多個 ip 地址的解決方案在協議棧方面更深入了一層，這是一個端對端的機制，由2個終端主機一起維護共享多樣的狀態。

Multipath TCP (MTCP) 的基本原理和 SHIM6 類似，初始雙方會交換信息來確保雙方都支持這個機制，允許雙方使用額外的鏈路或者通道。不同的是，SHIM6 會在主鏈路不可用的情況下才會使用備用鏈路，而 MPTCP 在應用允許的前提下，可以立刻使用這些鏈路來完成通信。

一個關于 MPTCP 的關鍵猜想是從 SHIM6 借鑒而來，主機上的多重地址有助于實現網絡中多重鏈路技術。一條使用多個地址的端對端鏈路，大致上和同時開啟多個 TCP 對話是等效的。

Multipath TCP 的基本思路是把發送的流量切分為更多的子流量，每個子流量建立一個單獨的端對端會話，然后在遠端把接收的子流量重新整合成單個流量。如圖1所示。

圖 1: 標準 TCP 和 MPTCP 協議棧比較

這實質上是在 TCP 模塊中插入了一塊“木條”。MPTCP 可以像 TCP 一樣的模式工作，生成多個子流量，然后把數據分配給單獨的子流量，這種機制對于上層應用程序來說是不透明的。應用程序可以通過 API 在鏈路池中添加和刪除地址，但不能直接管理和操作 MPTCP。MPTCP 保證了低層級的 TCP 組件不會受到影響，即 MPCTP 子流量是傳統的 TCP 流量。從數據發送者的角度來說，MPTCP 把來自應用程序的數據流切分成了一個個數據塊，再把單個數據塊封裝到了單個子流量中。從數據接收者的角度來說，MPTCP 收集了 TCP 子流量里的數據塊，并且重新組裝成原始數據流，并傳遞給本地應用程序。

#p#

MPTCP運行原理

在 TCP 頭部有一個大小為40字節的選項表示數據偏移量。如果數據偏移量的值大于5，就會使用 TCP 頭部的最后32位字符(校驗和指針)和數據的前8位之間的空間。MPTCP 會使用這個選項，并且所有的MPTCP 信號都會包含在這個選項字段里。

當打開一個會話的時候，主機會向遠端主機會發送一個 TCP SYN 消息，在 MPTCP 選項字段里包含了一個MP_CAPABLE 信號。如果遠端主機也支持 MPTCP，遠端主機會返回一個 SYN+ACK 響應，同樣在MPTCP 選項字段里包含了一個 MP_CAPABLE 信號。會話使用了 ACK 和 MP_CAPABLE 信號完成 TCP 和 MTCP 握手過程，確保兩端都得到了對方的 MPTCP 會話數據。在整個會話過程中，兩端交換了 64 位字節的會話密鑰，同時各自生成一個 32位的哈希共享密鑰。兩個主機之間隨后使用子鏈路的時候會用到這個共享密鑰。

進一步來說，在 MPTCP 會話里，可以通過附帶 MPTCP 字段的 TCP SYN 交換來生成 TCP 子流量，MPTCP 字段包含了一個 MP_JOIN 值。MP_JOIN 包含了接收端的哈希共享密鑰和原始會話的 token 值，這樣兩端就能將新生成的 TCP 會話就能和原始會話關聯起來了。另外 MP_JOIN 還包含一個隨機數，用來防止重放攻擊。MP_JOIN 字段包含了發送端的地址，即使地址值被 NAT 轉換了，兩端還是能獲得對方的原始地址。會話兩端能在任意端口生成 MP_JOIN 值，也就是說，使用服務器的 80 端口開始會話后，便可以在任意端口對上建立子流量，而服務器無需監聽新端口。新的子流量包含 5 個元素(協議，源地址和端口號，目的地址和端口號)。兩端可以通過發送 ADD_ADDR 消息告知對方新的地址，同樣可以通過發送 REMOVE_ADDR 刪除地址。

TCP 子流量除了使用傳統的 TCP 信號，MPTCP 增加了一個數據序列信號(DSS)，標示了 MPTCP 會話中子流量的數據流狀態。發送端的序列號包括一個總的序列號，以及標示單個子流量的序列號。DSS ACK序列號是接收端接收到的有序數據的集合。另外，子流量會用到 SACK。

為了防止出現子流量數據丟失后造成阻塞的情況，發送端必須再使用另外一個子流量重發數據。子流量使用的是常規的 TCP 排序算法，一個不穩定的連接可能會造成子流量失效。這時，MPTCP 可以選擇另外一條子流量重新發送數據。如果子流量依然失效，MPTCP 可以使用 TCP RST 重置該子流量。

單個子流量是被傳統的 FIN 消息 TCP 交換或通過 TCP RST 消息停止的。 在 MPTCP 選項空間，作為數據順序信號的數據 FIN 消息決定 MP-TCP 會話的關閉。

擁擠控制看起來仍然是 MPTCP 的一個未解決問題。一種實驗性的方法是結合每個子流量的擁擠時間窗，以及根據 RTT 間隔以線性的速率增加總時間窗的總量，和對最大的時間窗的子流量采用最大的增量。采用這樣的方式，總的流量也不比在最佳可用路徑上的單個 TCP 會話差，并且單個子流量都占用的路徑是相同份額的。其他可能減少各子流量耦合的方法也會被考慮。

MPTCP 和中間設備

如今的互聯網充斥著各種各樣的中間設備，比如 NAT 設備，負載均衡器，代理，過濾器，防火墻等。這就意味著使用不同的 IP 策略，不同的中間設備就會遇到各種各樣的問題。

對于MPTCP 來說，一個重要的問題就是一些中間設備會修改 TCP 報文的字段值。

這個問題主要存在于 ADD_ADDR 消息和 NAT。如果想在一個 NAT 連接上傳遞 ip 地址，結果總是會失敗，MPTCP也不例外。MPTCP 沒有內置 NAT 識別函數，所有沒辦法探測到是否存在 NAT 設備。本地主機向遠端主機發送報文的時候會帶上自己的 ip 地址，但是 NAT 設備會對 ip 地址做轉換，遠端無法獲取真實的ip地址，除非不經過 NAT 設備直接從本地主機發起 TCP 連接。

當存在NAT設備時，一個簡單有效的方法讓主動發起會話的主機創建子流量連接。這就意味著在一個Client/Server模式中，最好由客戶端發起子流量連接。當然，沒有NAT設備的時候就沒有這些限制了，兩端都可以發起子流量連接，發送ADD_ADDR消息將新的鏈路告知對方。這個方法對于MPTCP本身來說是無關緊要的，但是對于一個用到 MPTCP的應用程序來說是意義重大的。

MPTCP的一些啟示

MPTCP使用額外的連接選項帶來了 靈活性。

所有的TCP子流量都會帶上MPTCP 選項，可以共享MPTCP狀態。子流量沒有主次之分，會話發起時被創建，會話結束時被銷毀。子流量是IP協議無關的，可以同時存在IPv4和Ipv6協議連接。在多條網絡鏈路上使用子流量實現了負載共享，實現了應用程序的主備鏈路控制，帶來了更多的靈活性。

當應用到移動設備上時，又出現了一些意想不到的情況。我總是說我的移動設備不能做到“實時切換”。在蜂窩網絡上發起的連接只能存在于蜂窩網絡上，同樣的在 WIFI 網絡上發起的連接只能存在于WIFI網絡上。實時會話不能跨網絡連接。我發現當我的手機連上 WiFi 時，會優先使用 WIFI 而不是 4G，來建立新連接。這也符合實際情況，使用 4G 連接的邊際成本比 WIFI 連接高1到1000倍。當 MPTCP 代替 TCP 時會出現什么情況?應用程序會使用所有可用的連接來建立子流量，會產生更多的流量。

但是，像往常一樣，它總是會變得更加復雜。如果 WiFi 網絡是一個企業服務，伴有 NAT，水平分割 VPN 和各種安全服務器有該怎么樣?如果我的設備開始在這樣的背景下進行 MPTCP，那么到什么程度是我的 WiFi 連接的屬性在蜂窩數據連接保留?我曾這樣公開新漏洞。如何一個虛擬接口，如 VPN，告知 MPTCP 感知應用程序，而其他接口不在同一安全域的 VPN 接口中?

然而，MPTCP 似乎在無縫切換的 WIFI 中發揮作用。在 MPTCP 下，一個移動手機進入 WiFi 服務地區以及 WIFI 無線子流到現有的數據傳輸，而不停止和重新啟動的數據流的情況是有可能的。應用程序可能會在 WIFI 子流處于激活時關閉蜂窩子流。這項功能是在使用 MPTCP 的應用程序的控制之下，而不是在載體主機操作系統的控制之下。

向上堆棧(Stack)

顯然不能停止在傳輸層使用 MPTCP。自定義的應用他們自己會做這件事。

舉例來說，“mosh”應用是一串靈活的地址，會話狀態是被加密分享的，服務將會接收一個來自任何客戶端 IP 地址的重連接，只要客戶端可以證明它知道被加密的分享。

在應用層上配置負載均衡，擴展 TCP 數據傳輸模型支持多個活動的 TCP 會話也是可能的，這在形式上與 MPTCP 沒什么差異。

當然還可以更進一步，而不是使用多路徑 TCP 會話，同樣的兩個末端點，你可以跨越多個末端點來代替共享的相同服務器上的數據，并且在多個服務器上也可以使用多路徑 TCP 會話。這個時候，這東西看起來就非常像分布式點對點架構。

另一種方法是將數據流格式化到消息，同時在兩個交換系統中允許多個消息通過不同的路徑發送。這個方法，SCTP 和 MPTCP 雖類似，但SCTP高明在多地址對多路徑的支持。它把 UDP 消息事務的特性和 TCP 可靠的隊列傳送服務很好的結合在一起。如今網絡中的問題，不在于 TCP 或 UDP，而是許多中間件，包括 NATs，經常”敵視“ SCTP 時不時丟失 SCTP 的數據包。成為當今網絡中的一個中間件增長的主要成本。當今網絡協議模型的革新受制于網絡中間件相對狹窄的規則，相似地 thumb 規則(譯者注：一個簡單的解釋thumb規則的鏈接)在如今的網絡中成為了 TCP，UDP 和中間件的”飼料“。

(我)已經很多次注意到網絡協議棧的抽象是有些任意的，并且在參考棧的不同層級上都有可能實現相同的需求。在因特網多路徑支持的方案中，我們看到過很多的方法，有在數據鏈路層，IP層，在路由層，在傳輸層，在應用層上探索并行數據流傳輸方案。每種方案都各有優劣。但是使我擔心的是你是否會碰到同時采用了所有方案的情形?這會是超高效呢，或者是令人崩潰的復雜性呢?