TCP 是網(wǎng)絡(luò)協(xié)議集中的核心協(xié)議。它將底層 IP 協(xié)議提供的不可靠數(shù)據(jù)包傳輸服務(wù)變?yōu)橐环N可靠的數(shù)據(jù)流協(xié)議。它無疑是計算機(jī)網(wǎng)絡(luò)進(jìn)化歷程中最偉大的變革。

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

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

TCP 不僅是一中可靠的數(shù)據(jù)傳送流協(xié)議，而且一種采用自適應(yīng)速率控制的協(xié)議。TCP 可以以一種允許協(xié)議將盡可能多的數(shù)據(jù)通過網(wǎng)絡(luò)的模式工作。一個常見的運(yùn)作模式是：一個單獨(dú)的 TCP 會話會不斷探索最高的可傳輸數(shù)據(jù)率，通過分析丟包來降低發(fā)送速率并重復(fù)探索。TCP 的這方面的是一個不斷被研究的領(lǐng)域，在流動控制領(lǐng)域已經(jīng)做了許多的工作，目前有許多不同的 TCP 嘗試來優(yōu)化各種網(wǎng)絡(luò)環(huán)境下的流量。

其他的工作瞄準(zhǔn)在 TCP 的數(shù)據(jù)確認(rèn)上，嘗試在各種各樣的條件下提高算法效率。SACK 允許接收端發(fā)送回更多的信息來響應(yīng)發(fā)送端的丟失。FACK 指示在慢啟動時數(shù)據(jù)丟失的問題。

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

多路徑 TC P有過一個短暫的曝光，據(jù)透露，蘋果 iOS 7為其 Siri 應(yīng)用包含一個多徑TCP的實現(xiàn)，但它有可能在移動互聯(lián)網(wǎng)中發(fā)揮更大的作用。在這篇文章中我將更詳細(xì)地探討這個 TCP 選項，看它是如何工作，看它如何在今天的移動網(wǎng)絡(luò)中發(fā)揮作用。

IP多址

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

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

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

使用 TCP 的應(yīng)用還與初始化 TCP 握手時所采用的 IP 地址“緊密關(guān)聯(lián)”，因此會話不可能在同一接口上的輔助地址間相互轉(zhuǎn)換。

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

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

隨著移動互聯(lián)網(wǎng)的引入，互聯(lián)網(wǎng)已經(jīng)發(fā)生了顯著的變化，多路徑的討論主題也轉(zhuǎn)移成了許多移動相關(guān)的問題。移動設(shè)備上附著著許多 IP 地址。蜂窩無線接口上也有 IP 地址集。這些“智能”設(shè)備中許多也有 WiFi 接口，也有可能有 IPv4 和 IPv6 地址。還可能會有具有 IP 地址的藍(lán)牙接口，興許還有一些 USB 的網(wǎng)絡(luò)接口。當(dāng)啟用時每一個網(wǎng)絡(luò)接口都需要其本地 IP 地址。我們現(xiàn)在所處的互聯(lián)網(wǎng)中設(shè)備具有多個可用 IP 地址是相對較為普遍的。但我們?nèi)绾卫眠@些地址呢?

在大多數(shù)情況下使用多地址是不值當(dāng)?shù)摹３Ｒ姷牧?xí)慣是每一個新的會話是針對特定接口的，給會話的出站地址是通過本地策略決定的。但是，當(dāng)我們開始考慮應(yīng)用綁定的位置和標(biāo)識時是非常多變的，網(wǎng)絡(luò)連接是瞬態(tài)的，連接的成本和容量是不同的，因而現(xiàn)今通常的情況是這樣的，移動蜂窩無線電服務(wù)和 WIFI 漫游服務(wù)會話，擁有一定數(shù)量的敏捷性跨網(wǎng)絡(luò)轉(zhuǎn)換是一個重要的因素。

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

SHIM6

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

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

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

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

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

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

網(wǎng)絡(luò)運(yùn)營商對于把決定權(quán)交給獨(dú)立的主機(jī)的做法表達(dá)了強(qiáng)烈的質(zhì)疑。網(wǎng)絡(luò)運(yùn)營商希望在他們的網(wǎng)絡(luò)中控制連通結(jié)構(gòu)，進(jìn)一步來說，就是像路由系統(tǒng)一樣提供流量的網(wǎng)絡(luò)控制服務(wù)。SHIM6 的目標(biāo)是讓站點(diǎn)從上游獲取 IPv6 地址前綴，避免主機(jī)路由表變得更加臃腫，但同時也降低了站點(diǎn)的“獨(dú)立性”。盡管對于這點(diǎn)表示贊同，運(yùn)營商還是反對把連接的選擇和控制權(quán)交還給獨(dú)立的主機(jī)終端系統(tǒng)。

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

最后我們得出一個很嚴(yán)峻的結(jié)論，目前在網(wǎng)絡(luò)中大多數(shù)使用不同潛在鏈路傳遞流量的地方還只是局限在傳輸層。我們需要進(jìn)一步的推進(jìn) SHIM6 的發(fā)展，重新審視 TCP 的發(fā)展前景。

多通道 TCP

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

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

一個關(guān)于 MPTCP 的關(guān)鍵猜想是從 SHIM6 借鑒而來，主機(jī)上的多重地址有助于實現(xiàn)網(wǎng)絡(luò)中多重鏈路技術(shù)。一條使用多個地址的端對端鏈路，大致上和同時開啟多個 TCP 對話是等效的。

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

圖 1: 標(biāo)準(zhǔn) TCP 和 MPTCP 協(xié)議棧比較

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

#p#

MPTCP運(yùn)行原理

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

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

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

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

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

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

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

MPTCP 和中間設(shè)備

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

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

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

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

MPTCP的一些啟示

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

所有的TCP子流量都會帶上MPTCP 選項，可以共享MPTCP狀態(tài)。子流量沒有主次之分，會話發(fā)起時被創(chuàng)建，會話結(jié)束時被銷毀。子流量是IP協(xié)議無關(guān)的，可以同時存在IPv4和Ipv6協(xié)議連接。在多條網(wǎng)絡(luò)鏈路上使用子流量實現(xiàn)了負(fù)載共享，實現(xiàn)了應(yīng)用程序的主備鏈路控制，帶來了更多的靈活性。

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

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

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

向上堆棧(Stack)

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

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

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

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

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

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