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

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

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

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

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

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

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

IP多址

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

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

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

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

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

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

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

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

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

SHIM6

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

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

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

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

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

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

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

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

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

多通道 TCP

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

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

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

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

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

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

#p#

MPTCP運(yùn)行原理

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

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

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

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

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

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

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

MPTCP 和中間設(shè)備

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

對(duì)于MPTCP 來(lái)說(shuō)，一個(gè)重要的問(wèn)題就是一些中間設(shè)備會(huì)修改 TCP 報(bào)文的字段值。

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

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

MPTCP的一些啟示

MPTCP使用額外的連接選項(xiàng)帶來(lái)了 靈活性。

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

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

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

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

向上堆棧(Stack)

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

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

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

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

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

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