MPTCP协议学习
對(duì)MPTCP協(xié)議理論部分的學(xué)習(xí)進(jìn)行了整理，文中數(shù)據(jù)包結(jié)構(gòu)的圖來自于RFC6824。詳見http://www.rfcreader.com/#rfc6824
MPTCP協(xié)議學(xué)習(xí)
MPTCP目的：隨著技術(shù)的發(fā)展許多設(shè)備具有了多個(gè)網(wǎng)絡(luò)接口，而TCP依然是一個(gè)單線路的協(xié)議，在TCP的通信過程中發(fā)端和收端都不能隨意變換地址。我們可以利用多個(gè)網(wǎng)絡(luò)接口的這一特性來改善性能和有效冗余。
例如：手中的?iPhone 同時(shí)開啟了?4G 和?WiFi 連接（大多數(shù)情況也是這樣），這個(gè)時(shí)候我通過?App Store 更新一個(gè)?100M 的軟件。按照以往的情況，App Store 的軟件更新是會(huì)優(yōu)先通過?WiFi 進(jìn)行的，44G 在此刻是閑置狀態(tài)。但是在?Multipath TCP 的支援下，盡管只通過?App Store 更新一個(gè)軟件，建立起了一個(gè)網(wǎng)絡(luò)連接，但是它卻可以同時(shí)利用?3G 和?WiFi 建立?Mutlpath 連接，通過多點(diǎn)優(yōu)化網(wǎng)絡(luò)下載，且互為備份。假如這個(gè)時(shí)候?WiFi 斷了，以前的情況是，App Store 更新中斷，需要人工干預(yù)恢復(fù)或重新下載。而在?Mutlipath TCP 的優(yōu)化下，只要?3G 沒斷，App Store 就能繼續(xù)更新下載。除非?3G 也斷了，才宣告此次連接失敗。
而Multipath TCP可以在一條TCP鏈接中包含多條路徑，避免上述問題出現(xiàn)。
簡(jiǎn)單來說：MPTCP允許在一條TCP鏈路中建立多個(gè)子通道。當(dāng)一條通道按照三次握手的方式建立起來后，可以按照三次握手的方式建立其他的子通道，這些通道以三次握手建立連接和四次握手解除連接。這些通道都會(huì)綁定于MPTCP session，發(fā)送端的數(shù)據(jù)可以選擇其中一條通道進(jìn)行傳輸。
MPTCP的設(shè)計(jì)遵守以下兩個(gè)原則：1.?應(yīng)用程序的兼容性，應(yīng)用程序只要可以運(yùn)行在TCP環(huán)境下，就可以在沒有任何修改的情況下，運(yùn)行于MPTCP環(huán)境。2.?網(wǎng)絡(luò)的兼容性，MPTCP兼容其他協(xié)議。協(xié)議棧中的位置：同TCP一樣處于傳輸層。
頭部選項(xiàng)在TCP頭部和數(shù)據(jù)包內(nèi)容之間，一個(gè)TCP包可能沒有頭部選項(xiàng)，也可能同時(shí)有好幾個(gè)頭部選項(xiàng)。TCP頭部選項(xiàng)的格式如下，通過kind字段區(qū)分不同的頭部選項(xiàng)。
?
?
TCP數(shù)據(jù)包格式：
| 源端口（16） | 目的端口（16） | ||
| TCP序號(hào)（32） | |||
| 捎帶的確認(rèn)（32） | |||
| 首部長(zhǎng)度（4） | 保留（6） | FLAG（6） | 窗口尺寸（16） |
| TCP校驗(yàn)和（16） | 緊急指針（16） | ||
| 選項(xiàng)和填充 | |||
| 數(shù)據(jù) | |||
TCP選項(xiàng)格式：
在做包解析的時(shí)候，根據(jù)TCP頭部選項(xiàng)的kind值就可以判斷該包是否為MPTCP包了。
MPTCP選項(xiàng)的典型結(jié)構(gòu)為
?
其中，kind字段表示該頭部選項(xiàng)為MPTCP頭部選項(xiàng)，kind=30。Length字段表示該頭部選項(xiàng)的長(zhǎng)度，subtype選項(xiàng)表示該MPTCP選項(xiàng)的子類型，剩下的字節(jié)則為該子類選項(xiàng)的具體數(shù)據(jù)。根據(jù)subtype值的不同，MPTCP選項(xiàng)的子類型有以下幾種：
?
?
MPTCP建立連接過程：如圖，MPTCP的第一個(gè)子通道的建立遵守TCP的三次握手，唯一的區(qū)別是每次發(fā)送的報(bào)文段需要添加MP_CAPABLE的的TCP選項(xiàng)和一個(gè)安全用途的key。而子通道的建立依需要四次握手，而TCP選項(xiàng)換成了MP_JOIN。而token是基于key的一個(gè)hash值，rand為一個(gè)隨機(jī)數(shù)，而HMAC是基于rand的一個(gè)has
數(shù)據(jù)的發(fā)送和接收：MPTCP可以選擇多條子通道中任意一條來發(fā)送數(shù)據(jù)。MPTCP在發(fā)送數(shù)據(jù)方面和TCP的區(qū)別是可以從多條路徑中選擇一條路徑來發(fā)送數(shù)據(jù)，MPTCP在接收數(shù)據(jù)方面與TCP的區(qū)別是子路徑對(duì)無序包進(jìn)行重排后。
由于所有的數(shù)據(jù)會(huì)通過不同的子路徑發(fā)送，在接收端MPTCP需要對(duì)數(shù)據(jù)進(jìn)行重新排序。因此我們需要數(shù)據(jù)序號(hào)映射。數(shù)據(jù)序號(hào)映射定義從子路徑序列空間到數(shù)據(jù)序列空間的映射。子路徑的序列空間是子路徑自身的序列號(hào)，而數(shù)據(jù)序列空間維護(hù)著所有需發(fā)送的數(shù)據(jù)。如下圖
?
紅色子路徑上的子路徑序號(hào)分別是1、2，其數(shù)據(jù)序號(hào)是1000、1002。而下面的藍(lán)色的子路徑上的子路徑序號(hào)和數(shù)據(jù)序號(hào)分別是200，1001。這說明從下面的藍(lán)色子路徑已經(jīng)發(fā)送了199個(gè)報(bào)文，而上面的紅色子路徑才開始發(fā)送。在MPTCP協(xié)議定義如下：
?
MPTCP的接收包過程分為兩個(gè)階段：第一、每個(gè)子通道依據(jù)自身序號(hào)來重組報(bào)文段；第二、MPTCP的控制模塊依據(jù)DSN對(duì)所有子通道的報(bào)文段進(jìn)行重組。
?
擁塞控制：
?
MPTCP的擁塞控制對(duì)TCP的擁塞控制的線性增加階段進(jìn)行了修改，而慢啟動(dòng)，快速重傳、快速恢復(fù)都沒有改變。每條子路徑擁有自己的cwnd，MPTCP的擁塞算法主要關(guān)心cwnd的改變。
?
擁塞算法設(shè)計(jì)原則：?
MPTCP的Throughput 要達(dá)到MPTCP中所有子路徑中最好的一條路徑
MPTCP應(yīng)該和普通TCP一樣從共享資源中獲得相同資源
MPTCP中的流量將從擁塞的子路徑轉(zhuǎn)移到不擁塞的路徑
?
關(guān)于傳統(tǒng)TCP協(xié)議中的擁塞控制：
幾種擁塞控制的方法：慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復(fù)( fast recovery )、選擇性應(yīng)答(?selective?acknowledgement,SACK)算法。
慢開始算法：當(dāng)主機(jī)開始發(fā)送數(shù)據(jù)時(shí)，如果立即所大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò)，那么就有可能引起網(wǎng)絡(luò)擁塞，因?yàn)楝F(xiàn)在并不清楚網(wǎng)絡(luò)的負(fù)荷情況。因此，較好的方法是先探測(cè)一下，即由小到大逐漸增大發(fā)送窗口，也就是說，由小到大逐漸增大擁塞窗口數(shù)值。
為了防止擁塞窗口cwnd增長(zhǎng)過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個(gè)慢開始門限ssthresh狀態(tài)變量（如何設(shè)置ssthresh）。慢開始門限ssthresh的用法如下：
當(dāng) cwnd < ssthresh 時(shí)，使用上述的慢開始算法。
當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法。
當(dāng) cwnd = ssthresh 時(shí)，既可使用慢開始算法，也可使用擁塞控制避免算法。
擁塞避免算法：讓擁塞窗口cwnd緩慢地增大，即每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長(zhǎng)，比慢開始算法的擁塞窗口增長(zhǎng)速率緩慢得多。
快重傳算法：快重傳算法首先要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對(duì)方）而不要等到自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn)。
快重傳算法還規(guī)定，發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段M3，而不必繼續(xù)等待M3設(shè)置的重傳計(jì)時(shí)器到期。
與快重傳配合使用的還有快恢復(fù)算法，其過程有以下兩個(gè)要點(diǎn)：
<1>. 當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)，就執(zhí)行“乘法減小”算法，把慢開始門限ssthresh減半。這是為了預(yù)防網(wǎng)絡(luò)發(fā)生擁塞。請(qǐng)注意：接下去不執(zhí)行慢開始算法。
<2>. 由于發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)很可能沒有發(fā)生擁塞，因此與慢開始不同之處是現(xiàn)在不執(zhí)行慢開始算法（即擁塞窗口cwnd現(xiàn)在不設(shè)置為1），而是把cwnd值設(shè)置為慢開始門限ssthresh減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。
選擇性應(yīng)答：改變TCP的確認(rèn)機(jī)制，最初的TCP只確認(rèn)當(dāng)前已連續(xù)收到的數(shù)據(jù)，SACK則把亂序等信息會(huì)全部告訴對(duì)方，從而減少數(shù)據(jù)發(fā)送方重傳的盲目性。比如說序號(hào)1，2，3，5，7的數(shù)據(jù)收到了，那么普通的ACK只會(huì)確認(rèn)序列號(hào)4，而SACK會(huì)把當(dāng)前的5，7已經(jīng)收到的信息在SACK選項(xiàng)里面告知對(duì)端，從而提高性能，當(dāng)使用SACK的時(shí)候，NewReno算法可以不使用，因?yàn)?/span>SACK本身攜帶的信息就可以使得發(fā)送方有足夠的信息來知道需要重傳哪些包，而不需要重傳哪些包。
另外還有Limited?transmit(RFC3042)。這個(gè)算法是在擁塞窗口比較小的時(shí)候如果在一個(gè)傳輸窗口內(nèi)有多個(gè)包丟失時(shí)比較有效率的恢復(fù)算法。之前已經(jīng)講過，TCP有一個(gè)快速恢復(fù)的機(jī)制，而快速恢復(fù)的前提是收到3個(gè)重復(fù)ACK。然而，接收方發(fā)送重復(fù)ACK卻又需要亂序包的到達(dá)才可以觸發(fā)，TCP在每收到一個(gè)亂序包就會(huì)立即發(fā)送一個(gè)重復(fù)的ACK給發(fā)送端。如果擁塞窗口比較小的時(shí)候會(huì)發(fā)生情況呢？發(fā)送方和接收方進(jìn)入一段互相等待的狀況，接收方等待再收到一個(gè)包于是發(fā)生重復(fù)ACK，而發(fā)送方卻等待第3個(gè)重復(fù)ACK，如果窗口較小，例如為3，如果此時(shí)第一個(gè)包丟失了，接收方對(duì)第二個(gè)和第三個(gè)包分別發(fā)送了重復(fù)ACK，總共兩個(gè)重復(fù)ACK，此時(shí)發(fā)送端由于窗口的關(guān)系不能再發(fā)送數(shù)據(jù)，此時(shí)雙方進(jìn)入互等，直到發(fā)送方的重傳超時(shí)計(jì)時(shí)器到，才能打破該僵局，顯然如果是這樣的話效率就明顯降低，因?yàn)橹貍鞒瑫r(shí)的時(shí)間設(shè)置為RTT+4×RTTVar，一般該值都比較大。
Limited?Transmit就是為了解決這種情況的，它的方法很簡(jiǎn)單，那就是當(dāng)收到兩個(gè)重復(fù)ACK時(shí)，檢測(cè)兩個(gè)條件：
1）接收方的通告窗口rwnd是否允許傳輸新的數(shù)據(jù)包，即是否滿足rwnd>cwnd？
2）停留在網(wǎng)絡(luò)中的數(shù)據(jù)包個(gè)數(shù)是否小于或等于cwnd+2？
如果這兩個(gè)條件都滿足的話，那么TCP再發(fā)送新的數(shù)據(jù)包，其實(shí)第二個(gè)條件換個(gè)意思理解就是說在這種情況下可以超出擁塞窗口最多再發(fā)送兩個(gè)數(shù)據(jù)包。假設(shè)新的數(shù)據(jù)包和相應(yīng)的ACK不被丟失的話，那么有了這兩個(gè)新的數(shù)據(jù)包，從而雙方可以立即從僵局中恢復(fù)出來，發(fā)送方接著進(jìn)入標(biāo)準(zhǔn)的快速恢復(fù)。注意的是盡管可以發(fā)送兩個(gè)新的數(shù)據(jù)包，但是cwnd的值要保持不變，而不能把它增加2。顯然Limited?Transmit算法比利用超時(shí)重傳在包亂序時(shí)具有更好的魯棒性
?
?
協(xié)議學(xué)習(xí)過程中遇到的一些名詞：
head-of-line blocking:
輸入排隊(duì)最主要的缺點(diǎn)是存在對(duì)頭阻塞（HOL Blocking）現(xiàn)象。這是比較容易理解的。在一條入線上輸入隊(duì)列中緩存的輸入信元，其目的出現(xiàn)通常情況下各不相同。如果對(duì)頭的信元因?yàn)楦?jìng)爭(zhēng)失敗而暫時(shí)無法得到服務(wù)，那么對(duì)頭信元的等待將使整個(gè)隊(duì)列中所有信元被迫等待。例如，假定某入線I1的對(duì)頭信元的目的出線為O1，恰巧另一條入線I2的對(duì)頭信元的目的出線也是O1。仲裁邏輯判定入線I2首先獲得服務(wù)，入線I1上的信元?jiǎng)t必須等待。這將導(dǎo)致整個(gè)入線I1的輸入隊(duì)列中的后續(xù)信元進(jìn)入等待。即使I1隊(duì)列中的后續(xù)的第2個(gè)信元的目的是另外某個(gè)出線Ox，且Ox當(dāng)時(shí)正處于空閑狀態(tài)，該信元也不能被服務(wù)，因?yàn)樵撔旁獱款^的對(duì)頭信元阻擋著它的傳送
?
DoS/DDoS：
DoS：最常見的DoS攻擊有對(duì)計(jì)算機(jī)網(wǎng)絡(luò)的帶寬攻擊和連通性攻擊。帶寬攻擊指以極大的通信量沖擊網(wǎng)絡(luò)，使得所有可用網(wǎng)絡(luò)資源都被消耗殆盡，最后導(dǎo)致合法的用戶請(qǐng)求無法通過。連通性攻擊指用大量的連接請(qǐng)求沖擊計(jì)算機(jī)，使得所有可用的操作系統(tǒng)資源都被消耗殆盡，最終計(jì)算機(jī)無法再處理合法用戶的請(qǐng)求
DDoS：傳統(tǒng)上，攻擊者所面臨的主要問題是網(wǎng)絡(luò)帶寬，由于較小的網(wǎng)絡(luò)規(guī)模和較慢的網(wǎng)絡(luò)速度的限制，攻擊者無法發(fā)出過多的請(qǐng)求。雖然類似“the ping of death”的攻擊類型只需要較少量的包就可以摧毀一個(gè)沒有打過補(bǔ)丁的UNIX系統(tǒng)，但大多數(shù)的DoS攻擊還是需要相當(dāng)大的帶寬的，而以個(gè)人為單位的黑客們很難使用高帶寬的資源。為了克服這個(gè)缺點(diǎn)，DoS攻擊者開發(fā)了分布式的攻擊。攻擊者簡(jiǎn)單利用工具集合許多的網(wǎng)絡(luò)帶寬來同時(shí)對(duì)同一個(gè)目標(biāo)發(fā)動(dòng)大量的攻擊請(qǐng)求，這就是DDoS(Distributed Denial of Service)攻擊。
?
SYN attack：
SYN Flood是一種廣為人知的DoS（拒絕服務(wù)攻擊）是DDoS（分布式拒絕服務(wù)攻擊）的方式之一，這是一種利用TCP協(xié)議缺陷，發(fā)送大量偽造的TCP連接請(qǐng)求，從而使得被攻擊方資源耗盡（CPU滿負(fù)荷或內(nèi)存不足）的攻擊方式
?
half-open：
TCP的半開連接(half-open)是指TCP連接的一端崩潰，或者在未通知對(duì)端的情況下移除socket，不可以正常收發(fā)數(shù)據(jù)，否則會(huì)產(chǎn)生RST。
TCP的半關(guān)閉是指TCP連接的一端調(diào)用shutdown操作使數(shù)據(jù)只能往一個(gè)方向流動(dòng)，只有一方發(fā)送了FIN，仍然可以正常收（或發(fā)）數(shù)據(jù)
?
轉(zhuǎn)載于:https://www.cnblogs.com/DesperateCupid/p/7898795.html
總結(jié)
- 上一篇： apache 目录网站显示indexs
- 下一篇： STM8S103 PB4和PB5