薛開平陳 珂倪 丹張 泓洪佩琳

1(中國科學(xué)技術(shù)大學(xué)電子工程與信息科學(xué)系 合肥 230027)2(中國科學(xué)院無線光電通信重點(diǎn)實(shí)驗(yàn)室(中國科學(xué)技術(shù)大學(xué)) 合肥 230027) (kpxue@ustc.edu.cn)

?

基于MPTCP的多路徑傳輸優(yōu)化技術(shù)綜述

薛開平1,2陳 珂1,2倪 丹1張 泓1洪佩琳1,2

1(中國科學(xué)技術(shù)大學(xué)電子工程與信息科學(xué)系 合肥 230027)2(中國科學(xué)院無線光電通信重點(diǎn)實(shí)驗(yàn)室(中國科學(xué)技術(shù)大學(xué)) 合肥 230027) (kpxue@ustc.edu.cn)

新型網(wǎng)絡(luò)環(huán)境致力于為用戶提供廣覆蓋、高帶寬、包含各種多媒體業(yè)務(wù)的服務(wù)，而多種接入技術(shù)并存的網(wǎng)絡(luò)環(huán)境為無處不在的高質(zhì)量服務(wù)提供了可能.為了適應(yīng)異構(gòu)環(huán)境，用戶終端通常配置多個(gè)接口(比如WIFI和4G)，通信終端之間可能存在多條路徑.多徑TCP協(xié)議(multipath TCP， MPTCP)是IETF MPTCP工作組提出的新型傳輸層多徑協(xié)議,它在兼容TCP協(xié)議的基礎(chǔ)上，同時(shí)利用多條路徑的傳輸能力來進(jìn)行數(shù)據(jù)傳輸，提高帶寬利用率，增強(qiáng)連接的恢復(fù)能力，并且能夠自適應(yīng)地將數(shù)據(jù)從擁塞路徑轉(zhuǎn)移到非擁塞路徑.近年來國內(nèi)外機(jī)構(gòu)先后作出了大量的研究，逐步使得MPTCP由概念走向?qū)嵱?總結(jié)和闡述了MPTCP相關(guān)方面的研究現(xiàn)狀，其中包括仿真實(shí)現(xiàn)與實(shí)際部署、亂序控制、聯(lián)合擁塞控制、能耗管理、安全以及關(guān)于路徑選擇、移動(dòng)性和QoS、數(shù)據(jù)中心中的應(yīng)用等其他方面的研究.最后給出總結(jié)和展望.

多路徑；多徑TCP協(xié)議；調(diào)度算法；擁塞控制；能耗管理；安全

多路徑傳輸技術(shù)旨在研究多宿終端之間如何同時(shí)使用多條路徑進(jìn)行數(shù)據(jù)傳輸，從而實(shí)現(xiàn)帶寬聚合、負(fù)載均衡、動(dòng)態(tài)切換以及自動(dòng)將業(yè)務(wù)從最擁塞、最易中斷的路徑上轉(zhuǎn)移到較好的路徑上的功能.

多路徑傳輸將應(yīng)用層的業(yè)務(wù)數(shù)據(jù)流分發(fā)到多條路徑并行傳輸，而多路徑的傳輸控制功能可以在終端協(xié)議棧的任意層次進(jìn)行實(shí)現(xiàn)，目前已經(jīng)存在很多研究在不同層次考慮多路徑傳輸?shù)膶?shí)現(xiàn)[1-4].為了保證對(duì)應(yīng)用層的透明性，同時(shí)由于在TCPIP協(xié)議棧中傳輸層是最低的端到端層次，可以獲取所用路徑帶寬、延遲、丟包等信息，并且能夠通過擁塞控制算法對(duì)網(wǎng)絡(luò)中的擁塞事件作出快速反應(yīng)，故而傳輸層多路徑方案一直是多徑傳輸技術(shù)研究中的重點(diǎn).

Internet工程任務(wù)組(Internet Engineering Task Force， IETF)于2000年提出一種傳輸層多徑協(xié)議SCTP(stream control transmission protocol)，它是獨(dú)立于TCP和UDP協(xié)議的傳輸層協(xié)議.標(biāo)準(zhǔn)SCTP協(xié)議[5]中定義，一個(gè)SCTP連接可以使用多個(gè)IP地址，但是只有主路徑用于數(shù)據(jù)傳輸，其他路徑作為冗余備份，在主路徑失效時(shí)才啟用.之后的研究又提出了LS-SCTP(load sharing for SCTP)[6]和CMT-SCTP(concurrent multipath transmission for SCTP)[7]，對(duì)標(biāo)準(zhǔn)SCTP協(xié)議進(jìn)行擴(kuò)展以支持多徑并行傳輸.然而，SCTP協(xié)議至今沒有大規(guī)模部署，究其原因是其與現(xiàn)有的應(yīng)用程序不兼容，通信雙方的應(yīng)用都必須調(diào)用SCTP接口才能使用SCTP協(xié)議傳輸.

鑒于當(dāng)前Internet中大部分重要的應(yīng)用程序都基于TCP， Huitema[8]早在1995年就提出基于TCP的多路徑傳輸控制思想，IETF在2009年專門成立了多徑TCP協(xié)議(multipath TCP, MPTCP)工作組[9]，旨在研究在現(xiàn)有TCP會(huì)話基礎(chǔ)上增加多徑傳輸?shù)墓δ?，包括相?yīng)的體系結(jié)構(gòu)、擁塞控制、路由、API、安全等.要求MPTCP與現(xiàn)有的網(wǎng)絡(luò)架構(gòu)和協(xié)議兼容，對(duì)應(yīng)用層提供的仍然是傳統(tǒng)TCP套接字，應(yīng)用程序在不做任何更改的情況下也能使用，從而保證對(duì)應(yīng)用層的透明性，并且在終端不支持MPTCP時(shí)可以回退到TCP.

MPTCP從根本上改變了數(shù)據(jù)的調(diào)度和傳輸方式，通過同時(shí)建立多條傳輸路徑，將數(shù)據(jù)的傳輸方式由傳統(tǒng)的單徑變成了多徑，有效地提升了網(wǎng)絡(luò)的傳輸能力和穩(wěn)定性，具有非常重要的意義.

1 MPTCP協(xié)議技術(shù)細(xì)節(jié)

MPTCP利用多條路徑進(jìn)行端到端傳輸，通信雙方必須同時(shí)支持MPTCP協(xié)議，并且至少一端具有多個(gè)IP地址，實(shí)現(xiàn)多路徑的分離.當(dāng)前IETF MPTCP 工作組制定的標(biāo)準(zhǔn)(RFC)一覽如表 1所示，工作組主要討論的內(nèi)容包括MPTCP的協(xié)議細(xì)節(jié)[10-11]，聯(lián)合擁塞控制[12-14]、安全問題[15-16]、應(yīng)用層接口[17]、MPTCP代理[18]等.

Table 1 The List of IETF MPTCP RFCs

MPTCP的協(xié)議棧如圖1所示，傳輸層的TCP劃分為2部分:MPTCP層和TCP層(也叫子流層).MPTCP層對(duì)于應(yīng)用層是透明的，應(yīng)用層看見的仍然是傳統(tǒng)TCP.MPTCP層實(shí)現(xiàn)路徑管理、數(shù)據(jù)包調(diào)度、擁塞控制等功能，并與子流層有接口，而子流層使用標(biāo)準(zhǔn)TCP協(xié)議.

Fig. 1 MPTCP protocol stack.圖1 MPTCP協(xié)議棧

1.1 MPTCP頭標(biāo)和基本操作

為保證MPTCP與TCP的兼容性，MPTCP利用TCP頭部區(qū)域攜帶MPTCP的選項(xiàng)，如圖2所示.MPTCP選項(xiàng)中的Kind域指明該選項(xiàng)是一個(gè)MPTCP選項(xiàng)，而Subtype域則指明該選項(xiàng)是MPTCP中的何種選項(xiàng)(比如MP_CAPABLE，MP_JOIN，DSS，ADD_ADDR等).

接下來我們給出MPTCP中的基本操作以及相應(yīng)的簡要描述，如表2所示，具體描述請(qǐng)參考RFC 6824[10].

Fig. 2 The position of MPTCP header option in TCP.圖2 MPTCP頭標(biāo)選項(xiàng)在TCP中的位置

Table 2 Basic Operations of MPTCP

1.2 MPTCP功能綜述和設(shè)計(jì)原則

MPTCP層在協(xié)議棧中位于應(yīng)用層之下和TCP層之上，為應(yīng)用層提供標(biāo)準(zhǔn)的TCP接口來隱藏多徑，同時(shí)需要管理多條TCP子流.MPTCP層具備路徑管理、數(shù)據(jù)包調(diào)度、子流接口及擁塞控制的功能，總結(jié)這4點(diǎn)如下：

1) 路徑管理.路徑管理功能負(fù)責(zé)檢測和使用2個(gè)主機(jī)之間的多條路徑.MPTCP的路徑管理機(jī)制要求把本機(jī)可用的地址發(fā)送給對(duì)端主機(jī)，而且可以建立新子流并加進(jìn)已有的MPTCP連接中.

2) 數(shù)據(jù)包調(diào)度.此功能要求把從應(yīng)用程序接收到的字節(jié)流(stream)切割成分段，后續(xù)由子流進(jìn)行傳輸.MPTCP設(shè)計(jì)了序列號(hào)映射機(jī)制，每條子流上發(fā)送的數(shù)據(jù)包都對(duì)應(yīng)有一個(gè)連接級(jí)別的序列號(hào)，從而保證接收端可以正確重組從不同子流上接收到的數(shù)據(jù)包.數(shù)據(jù)包調(diào)度功能依賴于路徑管理功能所提供的可用路徑信息.

3) 子流(采用單獨(dú)路徑TCP)接口.子流功能從數(shù)據(jù)包調(diào)度功能中取得分段，在特定的路徑上確保到主機(jī)可檢測的傳送.MPTCP考慮了網(wǎng)絡(luò)兼容性，在下層使用TCP，確保有序可靠的傳送.TCP在子流層給每個(gè)數(shù)據(jù)包添加子流序列號(hào)，用于實(shí)現(xiàn)子流級(jí)別的檢測和重傳丟包.在接收端，每條TCP子流在按序重組本子流的數(shù)據(jù)包后遞交給數(shù)據(jù)包調(diào)度模塊，繼而進(jìn)行連接級(jí)別的數(shù)據(jù)包按序重組.

4) 擁塞控制.用于在多個(gè)子流之間協(xié)調(diào)窗口，從而實(shí)現(xiàn)擁塞控制功能.MPTCP設(shè)計(jì)了聯(lián)合擁塞控制算法[12]，保證在共享瓶頸處一個(gè)MPTCP連接與傳統(tǒng)單徑TCP相比不會(huì)占用過多的帶寬，從而實(shí)現(xiàn)公平性.

總之，這些功能彼此配合、相互協(xié)作.路徑管理功能獲取兩通信主機(jī)間的可用路徑；數(shù)據(jù)包調(diào)度功能獲取應(yīng)用數(shù)據(jù)流后需要進(jìn)行一定的操作，比如分割數(shù)據(jù)段、添加連接級(jí)別的序列號(hào)，而后將數(shù)據(jù)包分發(fā)至各條TCP子流；子流再添加子流級(jí)別的序列號(hào)和ACK到每個(gè)數(shù)據(jù)包，接收端子流將數(shù)據(jù)包按序交付給數(shù)據(jù)包調(diào)度功能進(jìn)行進(jìn)一步的連接級(jí)別數(shù)據(jù)包的按序重組；擁塞控制功能是數(shù)據(jù)包調(diào)度功能的一部分，它決定了哪些數(shù)據(jù)包以何種速率在哪條子流上進(jìn)行發(fā)送.

MPTCP設(shè)計(jì)原則和優(yōu)化目標(biāo)可歸納為5點(diǎn)：

1) 提升吞吐量.一個(gè)MPTCP連接的總吞吐量不應(yīng)小于其最好路徑上的單條TCP連接的吞吐量.

2) 公平性.與只使用其中的一個(gè)路徑時(shí)相比，MPTCP連接不能占用過多的資源.

3) 均衡擁塞.在滿足前2項(xiàng)的前提下，多徑流應(yīng)該盡可能多地從最擁塞的路徑上轉(zhuǎn)移走一些業(yè)務(wù).

4) 安全性.MPTCP要求其所具有的安全性不差于單個(gè)TCP連接.

5) 恢復(fù)力.在最壞情況下，MPTCP的恢復(fù)力必須不低于常規(guī)的單路徑TCP.

2 仿真實(shí)現(xiàn)與實(shí)際部署

倫敦大學(xué)學(xué)院(University College London， UCL)的網(wǎng)絡(luò)研究組開發(fā)了最早用于MPTCP方案驗(yàn)證和性能仿真的仿真器htsim[19].Google公司負(fù)責(zé)開發(fā)和維護(hù)了目前最有影響力和知名度的NS3(network simulator)仿真環(huán)境下的MPTCP模塊[20]，該模塊基本實(shí)現(xiàn)了在一個(gè)MPTCP連接下多TCP子流并行傳輸?shù)墓δ?雖然代碼并沒有嚴(yán)格按照MPTCP協(xié)議所規(guī)定的進(jìn)行設(shè)計(jì)，但不影響將其作為仿真工具進(jìn)行方案的性能評(píng)估.另一個(gè)用于NS3的MPTCP模塊由Sussex大學(xué)(University of Sussex)的Kheirkhah等人[21-22]提供.

UCL網(wǎng)絡(luò)研究組和以及來自比利時(shí)魯汶天主教大學(xué)(Université catholique de Louvain, UCLouvain)的IP網(wǎng)絡(luò)實(shí)驗(yàn)室分別提供了MPTCP的Linux內(nèi)核開源代碼[19,23]，并在內(nèi)核代碼的基礎(chǔ)上進(jìn)行了MPTCP性能的測試[24-27]，從擁塞窗口調(diào)整、數(shù)據(jù)中心支持、移動(dòng)性支持、能耗考慮等多個(gè)方面對(duì)基本的MPTCP協(xié)議提出一系列機(jī)制改進(jìn).另外一個(gè)重要的開源實(shí)現(xiàn)是以補(bǔ)丁的形式由Apple公司的研究組所提供的[28]，并用于IOS和MacOS當(dāng)中.這3個(gè)研究組以及前面提及的來自Google公司的研究組也是IETF MPTCP工作組的主要參與者.

圖3是內(nèi)核代碼框架示意圖[23].從圖3可以看到，應(yīng)用層調(diào)用的是傳統(tǒng)TCP套接字(socket)，而在建立了MPTCP連接后調(diào)用多徑控制模塊(multipath control block)，該模塊也就是所說的MPTCP層.初始的TCP 套接字為主套接字，之后新建立的TCP 套接字為從TCP 套接字.無論主TCP 套接字上的子流關(guān)閉與否，主TCP套接字一直存在，用于向上層應(yīng)用隱藏MPTCP的存在，從而實(shí)現(xiàn)透明化.在具體實(shí)現(xiàn)[25,29]上，如圖4所示，首先每個(gè)子流的處理都通過一個(gè)tcp_sock來加以實(shí)現(xiàn)，除此之外，該tcp_sock還包含一個(gè)指向mptcp_tcp_sock的指針，用以維護(hù)TCP之外與MPTCP有關(guān)的信息以及處理MPTCP層的相關(guān)功能.MPTCP連接所產(chǎn)生的第1個(gè)子流的tcp_sock記為meta_sock，供應(yīng)用層調(diào)用的為標(biāo)準(zhǔn)的TCP socket api.作為meta_sock的tcp_sock除了包含指向mptcp_tcp_sock的指針之外，還將通過指針連接到一個(gè)新添加的mptcp_cb，該結(jié)構(gòu)體作為MPTCP的控制緩存，其中維護(hù)了到各個(gè)TCP 子流的tcp_sock的指針以及地址列表信息等.各個(gè)子流的mptcp_tcp_sock也需要將相關(guān)標(biāo)識(shí)信息等存儲(chǔ)在mptcp_cb.

Fig. 3 Structure of MPTCP kernel code.圖3 MPTCP內(nèi)核代碼框架

Fig. 4 Relationship and function description of structures in Linux implementation.圖4 Linux內(nèi)核實(shí)現(xiàn)中結(jié)構(gòu)體相互關(guān)系及功能

NS3中MPTCP模塊[20]中類的實(shí)現(xiàn)主要包含4個(gè)部分：

1) MpTcpSocketlmph.MpTcpSocketlmph是類TcpSocketlmpl的子類，它給應(yīng)用層提供MPTCP API(connet，bind等)處理多路連接和包重排序.

2) MpTcpL4Protocol.MpTcpL4Protocol是類TcpL4Protocol的子類，是多路傳輸層和網(wǎng)絡(luò)層之間的接口.

3) MpTcpSubflow.MpTcpSubflow提供MPTCP連接的子路徑.

4) MpTcpHeader.MpTcpHeader是TcpHeader的子類，提供了MPTCP的頭選項(xiàng)等.

目前，除了Linux系統(tǒng)內(nèi)核支持的開發(fā)之外，研究者和開發(fā)者還在Android系統(tǒng)進(jìn)行了大量的嘗試，可以用于Google Nexus，Samsung Galaxy系列等[30].Apple IOS，MacOS以及數(shù)據(jù)中心Amazon EC2[31-32]也應(yīng)用了MPTCP.除此之外，斯威本科技大學(xué)(Swinburne University of Technology， SWIN)先進(jìn)互聯(lián)網(wǎng)架構(gòu)中心(Centre for Advanced Internet Architectures)開發(fā)了用于FreeBSD10.x的MPTCP代碼[33].

目前的趨勢是：隨著MPTCP受到學(xué)術(shù)界和業(yè)界的重視，越來越多的研究者和開發(fā)者投入MPTCP相關(guān)功能的實(shí)現(xiàn)當(dāng)中，日趨呈現(xiàn)百家爭鳴之勢.

3 亂序控制

MPTCP與任何傳統(tǒng)多徑傳輸協(xié)議一樣面臨數(shù)據(jù)包亂序問題的重大挑戰(zhàn).大多數(shù)多徑并行傳輸協(xié)議的初衷是為了聚合各路徑帶寬，提升數(shù)據(jù)傳輸吞吐量.然而多條路徑將引入更為復(fù)雜的參數(shù)維度，亦對(duì)發(fā)送端的多徑控制能力提出更高的要求.

以往的研究[26,34]表明MPTCP吞吐量受到通信雙方間各條端到端路徑的時(shí)延、丟包率、帶寬等參數(shù)差異以及共享接收緩存大小的限制.隨著各路徑差異越大，共享接收緩存越小，MPTCP吞吐量性能急劇惡化，有時(shí)甚至比不上最好路徑上使用傳統(tǒng)TCP協(xié)議進(jìn)行單徑傳輸?shù)耐掏铝?導(dǎo)致這一現(xiàn)象的主要原因是路徑差異導(dǎo)致接收端數(shù)據(jù)包亂序，而在接收緩存過小無法容納大量亂序包時(shí)性能將進(jìn)一步惡化.接收端亂序會(huì)造成2方面的影響：

1) MPTCP多路徑共享一個(gè)接收緩存，接收端亂序?qū)е陆邮站彺孀枞?

2) 限制路徑擁塞窗口滑動(dòng)和增長，路徑傳輸速率偏低.

這2方面因素引起MPTCP各路徑擁塞控制窗口增長相互制約，嚴(yán)重影響吞吐量提升.針對(duì)亂序?qū)е碌念^阻塞問題，為了盡可能保證數(shù)據(jù)按序達(dá)到，現(xiàn)有方案主要包括發(fā)送端調(diào)度策略和MPTCP與網(wǎng)絡(luò)編碼相結(jié)合的方案.

3.1 MPTCP發(fā)送端調(diào)度算法

MPTCP的發(fā)送端調(diào)度算法可以解決路徑不對(duì)稱造成的接收端數(shù)據(jù)包亂序問題，盡力保證數(shù)據(jù)包按序到達(dá)接收端.下面介紹MPTCP相關(guān)研究中提出的調(diào)度機(jī)制[25,27,34-40].

輪詢算法(round-robin， RR)[25]是最簡單的調(diào)度算法.MPTCP連接的各個(gè)子流沒有優(yōu)先級(jí)，發(fā)送端輪詢各個(gè)子流，發(fā)送緩存的數(shù)據(jù)按照輪詢的順序填滿各子流的發(fā)送窗口進(jìn)行發(fā)送.此時(shí)，只是在多子流間簡單地調(diào)配數(shù)據(jù)包，數(shù)據(jù)的按序性無法保證.

最小RTT優(yōu)先輪詢算法(lowest RTT first RR)[27]在輪詢算法的基礎(chǔ)上進(jìn)行了一定的深化.MPTCP連接的各個(gè)子流按照RTT排列優(yōu)先級(jí)，RTT越小優(yōu)先級(jí)越高.發(fā)送端按照優(yōu)先級(jí)高低輪詢各個(gè)子流，依次取發(fā)送緩存的數(shù)據(jù)包填滿各個(gè)子流的發(fā)送窗口.該算法讓路徑質(zhì)量好的子流承載更多的數(shù)據(jù)包，有一定的負(fù)載均衡的效果.無論是輪詢算法還是最小RTT優(yōu)先輪詢算法都沒有考慮數(shù)據(jù)包的按序性，沒有從數(shù)據(jù)包序列號(hào)角度出發(fā).

Fig. 5 Scenario example of the Linux-MPTCP scheduling algorithm.圖5 Linux-MPTCP調(diào)度算法適用的場景示例

Linux-MPTCP調(diào)度算法[25]是Linux-MPTCP內(nèi)核代碼支持的一種預(yù)測調(diào)度算法.以圖5為例說明該算法的思想:一個(gè)MPTCP連接上的數(shù)據(jù)需要調(diào)度到2個(gè)TCP子流(subflowi和subflowj)上發(fā)送.假設(shè)調(diào)度時(shí)刻2條子流的擁塞窗口均為2,2條子流的RTT值存在RTTj=5RTTi的關(guān)系，也就是說，subflowi上發(fā)送5輪數(shù)據(jù)所需的時(shí)間與subflowj上發(fā)送1輪數(shù)據(jù)包所需時(shí)間相同.發(fā)送一輪是指擁塞窗口(cwnd)內(nèi)的第1個(gè)數(shù)據(jù)包從發(fā)送開始直到接收到該數(shù)據(jù)包的ACK，發(fā)送一輪的時(shí)間相當(dāng)于一個(gè)RTT.如果使用RR算法，subflowi取數(shù)據(jù)包1，2，subflowj則取數(shù)據(jù)包3，4，那么，subflowi上數(shù)據(jù)包1，2的ACK回來后，接著取數(shù)據(jù)包5，6，數(shù)據(jù)包5，6將早于數(shù)據(jù)包3，4到達(dá)接收端，亂序的數(shù)據(jù)包需要緩存，且subflowi后續(xù)幾輪的數(shù)據(jù)包仍將早于數(shù)據(jù)包3，4到達(dá)接收端.Linux-MPTCP調(diào)度算法在調(diào)度時(shí)刻subflowj不取數(shù)據(jù)包3，4而是取數(shù)據(jù)包11，12.subflowi上發(fā)送5輪數(shù)據(jù)包，窗口大小為2，一共可以發(fā)送10個(gè)包，subflowj則將發(fā)送緩存中的前10個(gè)包都預(yù)留給subflowi后續(xù)發(fā)送.這樣一來，數(shù)據(jù)包1～12將能基本按序依次到達(dá)接收端.不過該算法過于簡略，沒有考慮擁塞窗口在這5輪發(fā)送過程中會(huì)按照擁塞控制算法變化.

前向預(yù)測調(diào)度(forward prediction scheduling, FPS)[34-35]是Linux-MPTCP調(diào)度算法的改進(jìn)版本，想法來源于Westwood SCTP算法[41]，更精細(xì)地考慮了序列號(hào)的預(yù)測調(diào)度算法.假設(shè)一共有I條子流，對(duì)于pathi而言，其往返時(shí)延為RTTi，數(shù)據(jù)包從離開發(fā)送端到到達(dá)接收端的時(shí)延為FTi(≈RTTi/2)，擁塞窗口大小為si.為了簡化處理，數(shù)據(jù)包大小都設(shè)為TCP最大分段長度MSS(maximum segment size)，故而subflowi上每一個(gè)數(shù)據(jù)包的排隊(duì)時(shí)延εi是確定的：

(1)

在時(shí)刻t，subflowi發(fā)送si個(gè)數(shù)據(jù)包，那么這些數(shù)據(jù)包到達(dá)接收端的時(shí)刻分別為

t+FTi+εi,t+FTi+2εi,…,t+FTi+siεi，

而發(fā)送端接收到這些數(shù)據(jù)包的ACK的時(shí)刻分別為

t+RTTi+εi,t+RTTi+2εi,…,t+RTTi+siεi.

發(fā)送端接收到數(shù)據(jù)包成功接收的確認(rèn)消息后擁塞窗口si會(huì)按照擁塞控制算法增加，新一輪數(shù)據(jù)在時(shí)刻t+RTTi+siεi發(fā)送.

Fig. 6 Transmission sequence diagram of two subflows in FPS.圖6 FPS算法中2條子流數(shù)據(jù)包傳輸時(shí)序圖

以圖6為例說明FPS算法.MPTCP連接的數(shù)據(jù)通過pathi和pathj這2條路徑傳輸，2條路徑往返時(shí)延滿足RTTj>RTTi.在時(shí)刻t，路徑pathj上發(fā)送窗口產(chǎn)生滑動(dòng)，從而準(zhǔn)備發(fā)送新數(shù)據(jù).由于pathi傳輸數(shù)據(jù)快于pathj，pathj上發(fā)送的數(shù)據(jù)包需要經(jīng)過調(diào)度.發(fā)送端首先估計(jì)pathj上數(shù)據(jù)包到達(dá)接收端的時(shí)刻為t′，然后計(jì)算在時(shí)刻t′之前pathi上可以發(fā)送的數(shù)據(jù)包總數(shù).假設(shè)nl是從時(shí)刻tl(tl

(2)

其中，nl必須滿足：

(3)

如果tl+FTi+εi>t′，那么該輪傳輸?shù)乃袛?shù)據(jù)包均在t′之后到達(dá)，此時(shí)nl=0，最后計(jì)算t′之前可以傳輸?shù)臄?shù)據(jù)包總數(shù)為

(4)

其中，N就是在t′之前在pathi上成功發(fā)送的數(shù)據(jù)包總數(shù).那么，發(fā)送端調(diào)度發(fā)送緩存的前N個(gè)包給pathi，pathj跳過發(fā)送緩存前N個(gè)數(shù)據(jù)包從第N+1個(gè)開始取來填滿自己的發(fā)送窗口.pathi上每接收到一個(gè)數(shù)據(jù)包成功接收的確認(rèn)消息，RTTi平滑更新：

(5)

其中,rtti是新測量得到的往返時(shí)延;α是0～1之間的值，指明歷史RTTi和新測量rtti的權(quán)重關(guān)系.單程時(shí)延FTi按式(6)簡單估計(jì)：

(6)

由于在無線鏈路環(huán)境中隨機(jī)丟包事件不可避免，不考慮丟包的前向預(yù)測機(jī)制顯然已經(jīng)不再適用.在FPS[34-35]基礎(chǔ)上，F(xiàn)2P-DPS(fine-grained forward prediction based dynamic packet scheduling)[36]充分考慮了子流的TCP特性以及路徑的丟包率，使用TCP建模的方法，發(fā)送端根據(jù)子流上平滑得到的RTT和統(tǒng)計(jì)得到的丟包率估計(jì)未來一段時(shí)間內(nèi)該子流可能發(fā)送的數(shù)據(jù)量N.所采用的方法是，根據(jù)子流上給出的初始條件，以subflowi為例，初始窗口大小a以及路徑參數(shù)(pi,RTTi)， 對(duì)[t,t′]內(nèi)subflowi上所有可能的數(shù)據(jù)包傳輸事件計(jì)算統(tǒng)計(jì)平均，最終該統(tǒng)計(jì)平均值即為N.

但從根本上講，F(xiàn)PS和F2P-DPS都只是預(yù)測算法，可能與實(shí)際情況有差距.為了防止多輪調(diào)度之后的誤差累計(jì),進(jìn)一步在F2P-DPS的基礎(chǔ)上，一種基于TCP SACK反饋的調(diào)度算法OCPS(offset compensation based packet scheduling)[37]被提出.方案中在子流級(jí)別使用TCP SACK返回當(dāng)前接收端亂序情況,發(fā)送端根據(jù)TCP SACK攜帶的信息來判斷上一輪調(diào)度時(shí)預(yù)留給其他子流的數(shù)據(jù)包是過多還是過少，從而使用修正因子對(duì)下一輪的預(yù)留數(shù)據(jù)包總數(shù)進(jìn)行修正.OCPS在路徑質(zhì)量存在一定擾動(dòng)的情況下有良好的適應(yīng)能力.

借鑒單路徑中引入網(wǎng)絡(luò)編碼帶來的好處，大量研究者嘗試在多路徑TCP中也引入網(wǎng)絡(luò)編碼，一方面可以解決無線場景下由于無線隨機(jī)丟包帶來的問題[42-43]，另一方面可以簡化多路徑TCP各子流之間的調(diào)度問題[44-46].

以圖7和圖8為例進(jìn)行說明，假定所有的丟包都是由于無線隨機(jī)丟包造成的.在圖7中，子流S0與子流S1均非編碼數(shù)據(jù)流，子流0傳輸D3，D4，D6，子流1傳輸D1，D2，D5，傳輸過程中假定子流S0上存在無線隨機(jī)丟包，D3由于無線傳輸錯(cuò)誤而無法正常接收，則將會(huì)出現(xiàn)2個(gè)問題:1)子流S0傳輸?shù)腄4首先到達(dá)接收端，由于小序列號(hào)數(shù)據(jù)段未到達(dá)，則D4只能暫時(shí)緩存在接收緩存中，不可以提交；2)當(dāng)發(fā)生丟包后，接收端需要顯式地發(fā)回反饋消息后發(fā)送端才會(huì)重新發(fā)送分組，這不僅通報(bào)了假的擁塞信息，同時(shí)較長的丟包通報(bào)延時(shí)再一次加重了連接級(jí)別的亂序.如圖7所示，當(dāng)D4到達(dá)時(shí)，接收端反饋D3丟失了，D4不得不被緩存在接收緩存中等待小序列號(hào)數(shù)據(jù)段D1，D2，D3的到達(dá).

Fig. 7 An example of MPTCP transmission.圖7 MPTCP傳輸示例

Fig. 8 An example of MPTCP subflow layer coded transmission.圖8 MPTCP子流級(jí)別編碼傳輸示例

與此不同的是，在圖8中，由于采取了編碼機(jī)制，按照TCP網(wǎng)絡(luò)編碼的原則，接收端并不以完全解碼出原始數(shù)據(jù)段作為成功接收的標(biāo)準(zhǔn)，只要接收端在編碼的分組中可以看到數(shù)據(jù)段，則認(rèn)為已經(jīng)接收到數(shù)據(jù)段，通過這種方式，使得2條子流不需要嚴(yán)格遵循序列號(hào)順序.①發(fā)送端會(huì)發(fā)出冗余的分組，在不需要進(jìn)行顯示反饋的情況下，丟失的分組就可以被恢復(fù)，進(jìn)一步縮短接收緩存被占用的時(shí)間;②無論是編碼子流還是非編碼子流，只要到達(dá)的編碼分組滿足2個(gè)條件，則發(fā)回成功接收的確認(rèn)消息，避免造成擁塞誤判：

1) 編碼分組線性獨(dú)立于其他收到的編碼分組；

2) 最新收到的編碼分組中包含有接收端期望的序列號(hào)信息，或者可以借助新接收的編碼分組從解碼緩存中推導(dǎo)出接收端期望的序列號(hào)信息.

從編碼內(nèi)容上，多路徑TCP網(wǎng)絡(luò)編碼的方式主要可以分為子流級(jí)別編碼[42-43]以及連接級(jí)別編碼[44-46].子流級(jí)別編碼對(duì)多路徑TCP協(xié)議的改進(jìn)較小，兼容性更好.子流級(jí)別編碼和連接級(jí)別編碼的主要不同之處在于：執(zhí)行數(shù)據(jù)在不同子流的分配調(diào)度與執(zhí)行編碼的先后順序.若先執(zhí)行數(shù)據(jù)段調(diào)度，再執(zhí)行編碼，則為子流級(jí)別編碼；否則為連接級(jí)別編碼.

從傳輸形式上看，可以分為編碼子流與非編碼子流[43].在圖8中，子流0是編碼子流，而子流1是非編碼子流.

多路徑TCP網(wǎng)絡(luò)編碼的確認(rèn)機(jī)制尚未統(tǒng)一，可以分為子流級(jí)別確認(rèn)機(jī)制和連接級(jí)別確認(rèn)機(jī)制.子流級(jí)別編碼采用子流級(jí)別的確認(rèn)機(jī)制[42-43]，連接級(jí)別編碼可以采用子流級(jí)別確認(rèn)[44]或者連接級(jí)別的確認(rèn)機(jī)制.子流級(jí)別確認(rèn)機(jī)制與多路徑TCP協(xié)議后向兼容性好，所有的丟包均在子流級(jí)別進(jìn)行分析，以子流級(jí)別序列號(hào)信息作為反饋依據(jù)，反饋信息通報(bào)的丟包和延時(shí)變化均是該路徑上的情況，便于做出擁塞判決.連接級(jí)別反饋僅適用于連接級(jí)別編碼，以連接級(jí)別序列號(hào)信息作為反饋依據(jù)，不需要在連接級(jí)別和子流級(jí)別做映射，但是其不足之處在于，通過序列號(hào)信息可以獲得丟包信息，由于不再與子流信息相關(guān)，無法準(zhǔn)確判定丟包發(fā)生在哪一條路徑上.在圖8中，若反饋的序列號(hào)信息為SSN:PX，則是子流的反饋；若為DSN:DX，則為連接級(jí)別的反饋.

3.3 其他可行的方案

除了以上提到的這2類方案可以用于解決包亂序的問題之外，MPTCP內(nèi)核部署研究[26,34]中還提到了4種簡單的改進(jìn)機(jī)制：

機(jī)制1. 在最快路徑上重傳阻塞數(shù)據(jù)包.當(dāng)發(fā)生接收緩存阻塞時(shí)，將未到達(dá)接收端的序列號(hào)最小的數(shù)據(jù)包在最快路徑上重傳.最快路徑是RTT最小的路徑.

機(jī)制2. 懲罰阻塞接收窗口滑動(dòng)的子流.發(fā)送端判斷阻塞接收緩存的子流，也即未到達(dá)接收端的序列號(hào)最小的數(shù)據(jù)包所在子流，并對(duì)該子流的擁塞窗口減半懲罰操作.不過為了防止總是懲罰某一條子流，在一個(gè)往返時(shí)延內(nèi)同一條子流只能懲罰1次.

機(jī)制3和機(jī)制4. MPTCP的發(fā)送和接收緩存支持自動(dòng)調(diào)整，在需要時(shí)才增大緩存，這樣可以防止直接設(shè)置大緩存造成的空間浪費(fèi).當(dāng)接收緩存中所存儲(chǔ)的亂序數(shù)據(jù)包的數(shù)目超過1個(gè)BDP(BDP的計(jì)算值為Bandwidth×Delay)大小時(shí)，對(duì)擁塞窗口設(shè)置上限.MPTCP中具體的部署方式是：當(dāng)sRTT(smoothed RTT)超過了2倍的基準(zhǔn)RTT時(shí)就為擁塞窗口設(shè)置上限，基準(zhǔn)RTT為所有子流中的最小RTT值.機(jī)制3與機(jī)制4在sRTT的測量方式上有所不同.機(jī)制3使用數(shù)據(jù)包timestamp選項(xiàng)所記錄的發(fā)送與接收時(shí)間來測量sRTT值，而機(jī)制4使用子流接收一個(gè)接收窗口大小的數(shù)據(jù)所需要的實(shí)際時(shí)間來估算sRTT值.

3.4 亂序控制小結(jié)

MPTCP接收端數(shù)據(jù)包亂序現(xiàn)象將直接導(dǎo)致接收端緩存阻塞，并進(jìn)一步阻止發(fā)送端的擁塞窗口向前滑動(dòng).現(xiàn)有處理方案主要集中在3個(gè)方面：1)依據(jù)MPTCP各子流特性為其預(yù)分配數(shù)據(jù)包，使得不同子流所交付的數(shù)據(jù)包保持基本有序；2)使用網(wǎng)絡(luò)編碼的方式掩蓋上層數(shù)據(jù)包丟失狀況，發(fā)送冗余的編碼數(shù)據(jù)包以保證接收端數(shù)據(jù)包有序解碼；3)調(diào)整快速重傳策略以迅速向接收端交付造成緩存阻塞的數(shù)據(jù)包，使得接收端數(shù)據(jù)有序.目前尚無切實(shí)可行的方案可以完全應(yīng)對(duì)亂序問題，以上方案的設(shè)計(jì)也只是處于初步階段，這與MPTCP歸根結(jié)底依然屬于端到端協(xié)議存在一定關(guān)系，網(wǎng)絡(luò)狀態(tài)是實(shí)變的，源端只能根據(jù)反饋信息估計(jì)出當(dāng)前的網(wǎng)絡(luò)狀況，因而具有一定的滯后性，這也就給方案的有效執(zhí)行帶來了難度.所設(shè)計(jì)方案往往很難從根本上解決問題，但力求可以更加準(zhǔn)確地做到這一點(diǎn)，將亂序問題的影響降到最低.

4 聯(lián)合擁塞控制算法

MPTCP的每條TCP子流可以使用標(biāo)準(zhǔn)的TCP擁塞控制算法，而聯(lián)合擁塞控制算法是MPTCP研究的一大熱點(diǎn).沿襲單路徑TCP擁塞控制的思想，多路徑TCP擁塞控制機(jī)制可以分為2類：1)以丟包作為擁塞發(fā)生的標(biāo)志；2)以延時(shí)變化評(píng)估當(dāng)前是否發(fā)生擁塞.

4.1 基于丟包判據(jù)的擁塞控制算法

在MPTCP提出之前，采用的方法是一個(gè)連接的多個(gè)子流共享同一個(gè)擁塞窗口，比如E-TCP[47]，CM[48]，MPAT[49].在這些方案中，窗口調(diào)整都采用了基本的AIMD(additive increasemultiplicative decrease)方式[50]：如果在一個(gè)RTT中沒有發(fā)生丟包，擁塞窗口就增加1；如果共享此擁塞窗口的任一子流發(fā)生了丟包，擁塞窗口就減半.這類方法在減小窗口的算法上過于激進(jìn)，會(huì)對(duì)沒有發(fā)生丟包的子流帶來過多的性能限制，因此在公平性上有很大缺陷.之后多路徑TCP的擁塞控制機(jī)制設(shè)計(jì)為每個(gè)子流擁有自己的擁塞窗口，在AIMD基礎(chǔ)上，不同子流之間采用聯(lián)合擁塞控制的方法.比如EWTCP(equally-weighted TCP)[51]，COUPLED[52-53]，SEMI-COUPLED[54]，LIA[55]，RTT-Compensator[56]，OLIA[57]等.表3給出了這6種方案的窗口調(diào)整方式.

EWTCP方案中，通過“加權(quán)”限制多路徑TCP在瓶頸鏈路上的吞吐量，多路徑TCP子流以高耦合方式增大擁塞窗口，以獨(dú)立的方式減少擁塞窗口.參數(shù)a表示多路徑TCP流與單路徑TCP流吞吐量的關(guān)系，當(dāng)a=1，可以滿足多路徑TCP流與單路徑TCP流吞吐量相當(dāng).EWTCP的不足之處在于，未考慮不同子流RTT的不同.

COUPLED算法可以保證數(shù)據(jù)流遷移至最不擁塞的路徑上，其不足之處在于：1)COUPLED僅考慮RTT相同的假設(shè)條件；2)COUPLED算法在流量遷移過程中會(huì)切斷最擁塞的路徑，當(dāng)該條路徑恢復(fù)非擁塞后，也無法再繼續(xù)使用.

SEMI-COUPLED對(duì)COUPLED的改進(jìn)在于，SEMI-COUPLED偏向于使用擁塞程度輕的路徑，但不會(huì)完全封閉擁塞最為嚴(yán)重的路徑，而是在擁塞的路徑中留一部分少量的數(shù)據(jù)以監(jiān)測擁塞的路徑，當(dāng)發(fā)送端的該路徑擁塞狀態(tài)減輕至低于其他路徑的程度時(shí)，將負(fù)載回遷至該路徑上，減輕其他更為擁塞的路徑壓力.SEMI-COUPLED依舊基于RTT相同的假設(shè).

Table 3 Window Size Change of MPTCP Congestion Control Schemes

LIA從瓶頸公平性的角度出發(fā)，其最大的改進(jìn)之處在于該機(jī)制考慮到各路徑RTT的不同設(shè)計(jì)出a的參考值，用來控制窗口變化的加速度.a的值與各條子流的RTT有密切的關(guān)聯(lián).

RTT-Compensator在LIA算法之上進(jìn)行改進(jìn)，提出每收到一個(gè)ACK，則窗口的增大幅度上限設(shè)定為1wr，其目的是為了保證若一條或者多條多路徑TCP子流經(jīng)過一個(gè)瓶頸鏈路，在相同的擁塞丟包率下以同一瓶頸中TCP流窗口增大值作為上限.RTT-Compensator兼顧了不同路徑RTT的區(qū)別，是最為常用的多路徑TCP擁塞控制機(jī)制，其也被應(yīng)用于多路徑TCP網(wǎng)絡(luò)編碼傳輸機(jī)制中[43].

OLIA延用LIA中控制窗口變化加速度的思想，從公平性以及最優(yōu)資源池角度對(duì)LIA進(jìn)行了改進(jìn).劃分路徑優(yōu)劣集合，為不具有最大擁塞窗口的較好路徑提供更大的窗口變化加速度，并減小較差路徑的窗口變化加速度，從而使得資源利用最大化，并使得擁塞鏈路中的大部分發(fā)送數(shù)據(jù)被轉(zhuǎn)移.目前OLIA已經(jīng)在Linux-MPTCP內(nèi)核代碼中實(shí)現(xiàn).

4.2 基于延時(shí)判據(jù)的擁塞控制算法

在單路徑TCP擁塞控制中，TCP Vegas[58]是典型的基于延時(shí)的擁塞控制算法，其主要思想是基于延時(shí)的變化估計(jì)網(wǎng)絡(luò)中緩存的數(shù)據(jù)包數(shù)量，將其固定在一定的數(shù)量范圍，調(diào)整擁塞窗口的大小.由于延時(shí)對(duì)擁塞表現(xiàn)得更為敏感，因此可以在數(shù)據(jù)流未擁塞至丟包的狀態(tài)時(shí)便觸發(fā)擁塞控制，調(diào)整速率，減少分組的丟失.在此基礎(chǔ)之上，將基于延時(shí)的思想引入至MPTCP中，便提出了基于延時(shí)的多路徑TCP擁塞控制機(jī)制——加權(quán)Vegas(wVegas)算法[59].wVegas算法遵循擁塞均衡準(zhǔn)則，即網(wǎng)絡(luò)資源效用最大化出現(xiàn)在網(wǎng)絡(luò)中每一條路徑上的擁塞程度相同的時(shí)候，實(shí)現(xiàn)擁塞程度相同的方法是流量遷移.wVegas機(jī)制中，欠擁塞的路徑可以獲得更大的權(quán)重，該路徑可以以更為激進(jìn)的方式競爭網(wǎng)絡(luò)帶寬，這使得這條路徑傾向于更為擁塞；反之，過擁塞的路徑獲得的權(quán)重較小，通過反復(fù)變化，最終實(shí)現(xiàn)各條路徑上負(fù)載均衡.

在wVegas算法中，式(7)表示因擁塞路徑中緩存的分組數(shù)量；式(8)中，qr表示該條路徑的擁塞狀況，這里采用基于延時(shí)的擁塞控制方式，使用延時(shí)的增加作為擁塞程度的度量；as,r代替diff表示多路徑TCP流s在路徑r上因擁塞緩存的分組量，且吞吐量可以表示為xs,r=cwnds,r/rtts,r，最終可以用式(9)表示路徑上的吞吐量.經(jīng)過推導(dǎo)，在wVegas算法中，速率的變化可以用式(10)表示，as表示多路徑TCP流在所有子流路徑上緩存的分組數(shù)量，ys表示多路徑TCP流總的吞吐量，多路徑TCP流中發(fā)送速率的增加與該路徑當(dāng)前數(shù)據(jù)流的吞吐量占總吞吐量的比值、多路徑TCP緩存的分組總量以及當(dāng)前路徑的擁塞狀態(tài)qr有關(guān)，其中，權(quán)重表示見式(11).

(7)

(8)

(9)

(10)

(11)

其中，r∈Rs.

4.3 動(dòng)態(tài)窗口耦合機(jī)制

動(dòng)態(tài)窗口耦合(dynamic windows coupling， DWC)[60]機(jī)制強(qiáng)調(diào)了瓶頸的檢測.DWC的核心思想在于，將經(jīng)過同一個(gè)瓶頸的所有子流匯聚成為一條流，同時(shí)確保這一邏輯匯聚流與同一瓶頸上的TCP流之間的公平性，DWC同時(shí)兼顧丟包率與延時(shí)去檢測瓶頸鏈路.DWC機(jī)制保證在某一共享的瓶頸鏈路上子流集合(subflow set)可以與TCP流保證公平性，在不同瓶頸上的子流集合可以獨(dú)立地競爭帶寬，最大化其傳輸效率，DWC同時(shí)需要對(duì)瓶頸的遷移做出及時(shí)的響應(yīng)，經(jīng)過同一個(gè)瓶頸的所有子流被認(rèn)為是一個(gè)子流集合.

DWC機(jī)制主要過程包括：瓶頸檢測、擁塞窗口調(diào)整.初始狀態(tài)下，所有子流處于慢啟動(dòng)狀態(tài)，每一條子流都是一個(gè)獨(dú)立的子流集合.瓶頸檢測過程實(shí)際上是子流集合調(diào)整的過程.瓶頸檢測的觸發(fā)點(diǎn)是某一條子流出現(xiàn)第1個(gè)擁塞丟包，繼而其他子流出現(xiàn)延時(shí)增加、丟包的現(xiàn)象，則將這些子流分配至一個(gè)子流集合內(nèi)，即該集合內(nèi)的所有子流目前經(jīng)過的路徑都包含了某一或者某些瓶頸鏈路.其具體過程如下：假定子流f檢測到一個(gè)擁塞丟包，則將子流f從其原子流集合中取出放入新的活躍集(active set)中，檢測所有其他的子流，統(tǒng)計(jì)其在該時(shí)間點(diǎn)前后的延時(shí)，延時(shí)明顯增加的子流進(jìn)入活躍集中，在任意時(shí)刻，或者沒有活躍集或者有且僅有一個(gè)活躍集，活躍集中的子流通過相同的瓶頸.DWC以丟包為觸發(fā)不斷更新活躍集，并對(duì)活躍集中的子流進(jìn)行擁塞控制.DWC的不足之處在于，先后出現(xiàn)丟包或者延時(shí)增大的子流不一定經(jīng)過同一個(gè)瓶頸，而是有可能分別經(jīng)過不同的瓶頸.

4.4 聯(lián)合擁塞控制算法小結(jié)

聯(lián)合擁塞控制算法致力于達(dá)到最佳公平性，不過公平性的定義很多，包括子流公平性、瓶頸公平性、網(wǎng)絡(luò)公平性等.子流公平性是指瓶頸處每條子流都是獨(dú)立的，分享瓶頸的一部分；瓶頸公平性是指MPTCP的子流在瓶頸處與其他TCP子流公平分享瓶頸帶寬；網(wǎng)絡(luò)公平性是指MPTCP多子流的總吞吐量不應(yīng)該好于最好路徑單TCP吞吐量.側(cè)重點(diǎn)不同時(shí)設(shè)計(jì)的聯(lián)合擁塞控制算法就不同[60].

從更廣泛的角度來說，聯(lián)合擁塞控制算法還需要考慮在友好性(friendliness)、快速性(responsiveness)和窗口震蕩(window oscillation)三個(gè)矛盾因素間取得折中[61].友好性是指對(duì)單TCP的公平性，快速性是指對(duì)于網(wǎng)絡(luò)的擁塞做出快速的反應(yīng)，窗口震蕩是指子流上窗口大小的反復(fù)震動(dòng).比如快速性和窗口震蕩之間的矛盾，如果MPTCP能對(duì)路徑擁塞做出快速反應(yīng)，那么必然意味著某條子流在檢測到擁塞后將快速減小窗口而在發(fā)現(xiàn)路徑質(zhì)量良好時(shí)將及時(shí)增大窗口，從而可能造成窗口大小的反復(fù)震動(dòng).

5 能耗管理

MPTCP需要開啟多個(gè)接口進(jìn)行數(shù)據(jù)傳輸，對(duì)于終端而言會(huì)增加能量消耗，而有時(shí)候開啟多個(gè)接口帶來能量消耗甚至造成得不償失的后果.隨著對(duì)能耗要求的重視，結(jié)合底層技術(shù)的研究進(jìn)展，這方面的研究將會(huì)進(jìn)一步成為熱點(diǎn).目前主要工作包括2個(gè)部分:1)基于MPTCP傳輸過程中的能耗進(jìn)行量化測量；2)將能耗作為因素之一，用于性能優(yōu)化.下面分別從這2方面對(duì)已有的工作進(jìn)行介紹.

5.1 MPTCP能耗測量

基于對(duì)MPTCP能耗問題的關(guān)注，一些MPTCP研究小組采取了多種測量方法對(duì)MPTCP傳輸過程中的能耗進(jìn)行了量化測量，以最小化能耗作為優(yōu)化目標(biāo)之一來改進(jìn)MPTCP設(shè)計(jì)，從而使得其在保證QoS的同時(shí)減少能耗將具有指導(dǎo)性的意義.

文獻(xiàn)[62]提出了通過鄰居節(jié)點(diǎn)共享WIFI，Bluetooth接入從而在現(xiàn)存的3G4G連接之外具有多余的連接，并通過MPTCP組合使用這些不同的接入方式形成多路徑，通過在Galaxy Nexus phone上的實(shí)際測試，采用MPTCP能夠在提升性能的同時(shí)有效節(jié)省能耗.在文獻(xiàn)[10]中也提到了合理使用MPTCP可以有效地降低數(shù)據(jù)的單位傳輸所使用的能耗.

文獻(xiàn)[66]提出MPTCP能耗應(yīng)主要分為CPU能耗和連接能耗2個(gè)部分進(jìn)行考慮.目前針對(duì)MPTCP能耗方面的測量和方案設(shè)計(jì)主要還是考慮連接能耗.文獻(xiàn)[66]通過實(shí)驗(yàn)得出結(jié)論，目前的MPTCP還遠(yuǎn)沒有得到其應(yīng)該具備的性能，除了連接能耗之外，多核CPU的計(jì)算能耗也應(yīng)該考慮能耗和傳輸能力的折中式方案設(shè)計(jì).

此外，通過在MPTCP中引入編碼[44-45,67]、高效的調(diào)度機(jī)制[25]等也可以有效地降低能耗.但從測量的角度，目前還沒有發(fā)現(xiàn)太多這方面的工作.

5.2 MPTCP能耗優(yōu)化方案

能耗大小是路徑選擇和數(shù)據(jù)調(diào)度的標(biāo)準(zhǔn)之一，然而能耗較低的路徑可能擁塞程度較高，如何平衡兩者之間的選擇成為MPTCP相關(guān)研究中的一個(gè)難點(diǎn).文獻(xiàn)[68]證明了該優(yōu)化問題是一個(gè)NP難問題，雖然并未提出有效的近似算法，但從理論論證了MPTCP實(shí)現(xiàn)吞吐量與能耗雙優(yōu)的可能性.

基于內(nèi)核實(shí)現(xiàn)的減小能耗方案[69]，在3GWIFI場景下進(jìn)行討論.由于開啟3G接口的能耗遠(yuǎn)大于WIFI接口，故而方案中延遲3G的開啟時(shí)間.對(duì)于小文件的傳輸，可以在3G開啟前就利用WIFI單接口傳輸完畢；而對(duì)于大文件的傳輸，在一定時(shí)延后同時(shí)啟用3G和WIFI接口，從而提升吞吐量提升，實(shí)現(xiàn)魯棒性以及補(bǔ)償能耗的損失.

文獻(xiàn)[70]基于移動(dòng)設(shè)備使用WIFI傳輸數(shù)據(jù)能耗低于LTE數(shù)據(jù)傳輸能耗的原理，提出了MPTCP能耗優(yōu)化方案eMTCP.建立子流接口狀態(tài)監(jiān)測器，實(shí)時(shí)監(jiān)測WIFILTE的信道狀態(tài)，當(dāng)LTE需要傳輸數(shù)據(jù)且WIFI信道正空閑時(shí)，將數(shù)據(jù)轉(zhuǎn)移到WIFI接口上進(jìn)行傳輸，最大限度地利用低能耗接口，減少能耗.在此基礎(chǔ)上，文獻(xiàn)[71]進(jìn)一步考慮了突發(fā)流量的情況.

文獻(xiàn)[72-73]同時(shí)對(duì)能耗和路徑選擇、擁塞控制等的結(jié)合進(jìn)行了考慮.其中，ecMTCP[72]在聯(lián)合擁塞控制算法LIA的基礎(chǔ)上加入能耗因子，從而設(shè)計(jì)出一種新型的擁塞控制算法.文獻(xiàn)[73]使用了最優(yōu)化理論，通過2個(gè)步驟進(jìn)行路徑選擇和擁塞控制.

然而實(shí)際上，不同接入技術(shù)在不同網(wǎng)絡(luò)場景下都有可能具有不同的能耗表現(xiàn).文獻(xiàn)[74]認(rèn)為，將WIFI能耗優(yōu)于3G能耗作為固有知識(shí)是不科學(xué)的行為，故而提出在MPTCP中使用實(shí)時(shí)探測的方式來決定能耗較優(yōu)路徑.文獻(xiàn)[75]則通過綜合不同無線接口的能耗模型以及不同應(yīng)用的業(yè)務(wù)模型來建立相應(yīng)的預(yù)測模型，從而決定所應(yīng)該選擇的低能耗路徑.由于其中的調(diào)度策略的高計(jì)算代價(jià)，該方案選擇使用云服務(wù)器完成調(diào)度策略的計(jì)算，用戶設(shè)備僅需將相關(guān)測量參數(shù)上傳至云服務(wù)器即可獲得選擇結(jié)果.

5.3 能耗管理小結(jié)

MPTCP協(xié)同使用多個(gè)網(wǎng)絡(luò)接口提升了網(wǎng)絡(luò)傳輸?shù)男阅?，但相較于單接口協(xié)議也帶來更多的能耗.如何平衡能耗與性能的關(guān)系成為MPTCP能耗優(yōu)化方案所考慮的一個(gè)關(guān)鍵問題.根據(jù)不同接入網(wǎng)的傳輸效率以及能耗模型的不同，能耗優(yōu)化方案大多依據(jù)上層應(yīng)用的不同特性動(dòng)態(tài)選擇MPTCP所用接口，如優(yōu)先使用WIFI網(wǎng)絡(luò).但由于不同接入網(wǎng)(如WIFI和3G)覆蓋范圍有所不同，MPTCP能耗優(yōu)化方案也應(yīng)將由地域限制所導(dǎo)致的頻繁接口切換所帶來的能耗納入到考慮范圍內(nèi)，以更好地適應(yīng)實(shí)際網(wǎng)絡(luò)環(huán)境.已有的研究表明，MPTCP路徑的選擇和數(shù)據(jù)分配需要考慮不同接入網(wǎng)絡(luò)的能耗.能耗的研究往往是結(jié)合其他方面的機(jī)制進(jìn)行綜合考慮的.同時(shí)在某些特定條件下，在TCP能滿足傳輸要求時(shí)，MPTCP并不一定具有優(yōu)勢，這完全可以綜合評(píng)價(jià)具有優(yōu)勢的接口采用TCP作為傳輸層協(xié)議.

6 安 全

隨著MPTCP的普及使用，其安全性也受到了越來越多的重視.首先，由于一個(gè)MPTCP連接是由多個(gè)TCP連接組成，因此TCP所面臨的威脅同樣會(huì)給MPTCP帶來風(fēng)險(xiǎn)；其次，MPTCP中使用的新方法會(huì)引入新的威脅.除了第3～5節(jié)所提及的性能目標(biāo)之外，MPTCP要求其所具有的安全性不差于單個(gè)TCP連接.以下將從MPTCP中的安全機(jī)制、面臨的威脅以及對(duì)網(wǎng)絡(luò)安全的影響3個(gè)方面進(jìn)行闡述.

6.1 MPTCP中的安全機(jī)制

從安全的角度，MPTCP在連接初始化過程中要求能夠提供簡單的機(jī)制為后續(xù)子流的建立提供驗(yàn)證信息，同時(shí)也是確保所建立的多條TCP子流同屬于一個(gè)MPTCP連接.在RFC 6824[10]當(dāng)中，提出基于密鑰交換來提供相應(yīng)的功能.在連接初始化過程中，兩端通過3次握手的第2和第3個(gè)消息(SYNACK和ACK)中的MPTCP_CAPABLE選項(xiàng)以明文的形式各自包含發(fā)送方的64 b密鑰，在后續(xù)創(chuàng)建新子流時(shí)則可以基于雙方所發(fā)送的這2個(gè)密鑰生成相應(yīng)的截?cái)嗟?2 b令牌(token)，令牌用于標(biāo)識(shí)一組隸屬于同一個(gè)MPTCP的子流.另外，還產(chǎn)生一個(gè)64 b截?cái)嗟拿荑€Hash用作初始數(shù)據(jù)序列號(hào).密鑰和隨機(jī)的現(xiàn)時(shí)值(nonce)還用于消息認(rèn)證碼(message authentication code， MAC)的計(jì)算，用于認(rèn)證和防重放.

在建立新子流時(shí)， 此前在連接初始化過程中使用MP_CAPABLE握手過程中交換的密鑰為驗(yàn)證終端主機(jī)提供了信息.新子流的建立也和初始化標(biāo)準(zhǔn)TCP連接是類似的，只是在SYN，SYNACK，ACK的數(shù)據(jù)包中攜帶了MP_JOIN選項(xiàng).假設(shè)NodeA在它的一個(gè)地址和NodeB的地址間建立一個(gè)新的子流，如圖9所示.從密鑰中生成的令牌決定此新子流應(yīng)該加入哪一個(gè)MPTCP連接,MAC為驗(yàn)證信息.前2個(gè)消息中還各自包含一個(gè)現(xiàn)時(shí)值，用于MAC值的計(jì)算當(dāng)中，防止重放攻擊.

Fig. 9 Signaling flow of establishing a new subflow in MPTCP.圖9 MPTCP創(chuàng)建新子流的信令流程

6.2 MPTCP面臨的威脅

截止目前，IETF MPTCP工作組當(dāng)中有2個(gè)RFC文檔[15-16]來討論MPTCP可能帶來的安全威脅.在MPTCP從草案變成標(biāo)準(zhǔn)建議[10]之前，RFC 6181[15]給出了使用單連接多地址進(jìn)行數(shù)據(jù)傳輸?shù)陌踩{分析，期望借用SHIM6[76]，SCTP[77]，MIPv6[78]等的經(jīng)驗(yàn)來指導(dǎo)MPTCP設(shè)計(jì).這些可能的威脅在RFC 6824[10]中的解決方案是采用6.1節(jié)中所介紹的基于交換密鑰的安全機(jī)制，雖然該機(jī)制并不能從根本上解決安全威脅，但具有較高的執(zhí)行效率.最近，RFC 7430[16]在RFC 6181[15]的基礎(chǔ)上，對(duì)MPTCP的安全威脅做了進(jìn)一步的補(bǔ)充.

MPTCP對(duì)每個(gè)端點(diǎn)引入多個(gè)地址的支持，與單路徑TCP比較，MPTCP可以在已有的連接上添加新的地址，這將會(huì)導(dǎo)致重定向攻擊的發(fā)生.RFC 6181[15]給出了2種可能的攻擊方式：泛洪攻擊(flooding attack)和劫持攻擊(hijack attack)，這兩者都可以由off-Path的攻擊者來發(fā)起攻擊，而在引入一些安全機(jī)制的情況下，依然可以通過攻擊者初始o(jì)n-path獲取基于明文傳送的安全信息，然后依然發(fā)起off-path的攻擊(這種組合的攻擊方式稱為time-shifted攻擊或者partial-time on-path攻擊).這里的泛洪攻擊指的是攻擊者通過與服務(wù)器建立初始的MPTCP連接，然后欺騙服務(wù)器與攻擊目標(biāo)主機(jī)建立多個(gè)子流，觸發(fā)其發(fā)送大量的數(shù)據(jù)流給攻擊目標(biāo)主機(jī)，從而耗費(fèi)其資源.而在劫持攻擊中，首先由攻擊者劫持合法通信兩端的MPTCP連接，然后添加其地址用于和其中一端建立新的子流，或者作為中間人分別與合法通信的兩端建立子流，而實(shí)際的通信雙方還以為是與合法對(duì)端建立的子流，通過這樣的方式，攻擊者就可以非法獲得通信數(shù)據(jù).RFC 6181[15]總結(jié)出3類可行的解決方案可供使用：1)基于cookie的方法；2)使用明文進(jìn)行秘密交互；3)強(qiáng)加密錨交換.前兩者的缺陷是需要使用明文進(jìn)行初始交換，無法避免on-path攻擊者對(duì)明文交換信息的獲取，但新增加的開銷較小.其中，RFC 6824[10]引入的是第2種方案.第3種方案的安全性較高，目前所提出的方案包括基于公鑰機(jī)制[15,79]和基于Hash chain[80]等.RFC 7430[16]還進(jìn)一步提出了可以采用SSL，CGA，TCPcrypt，DNSSec等強(qiáng)安全機(jī)制，但可能會(huì)引入額外的交互，計(jì)算開銷和系統(tǒng)維護(hù)開銷的增加也不容忽視.

除了以上在RFC 6181[15]中所提及的攻擊之外，RFC 7430[16]還對(duì)這些攻擊和建議解決方案做了進(jìn)一步的細(xì)化(包括初始握手過程的竊聽、SYNJOIN消息的中斷和篡改攻擊、ADD_ADDR攻擊等).此外，還針對(duì)信令交互過程的不合規(guī)操作以及可能產(chǎn)生的安全攻擊做了闡述，同時(shí)也給出了可行的方案.這些攻擊包括基于MP_JOIN的DoS攻擊、SYN Flooding 攻擊放大.其中，基于MP_JOIN的DoS攻擊類似于TCP中的half-open攻擊，但危害性更大，可以實(shí)現(xiàn)分布式的攻擊.如圖9所示的交互過程，當(dāng)需要增加一個(gè)新的TCP子流時(shí)，通過包含MP_JOIN選項(xiàng)的3次握手來完成.在第1個(gè)SYN+MP_JOIN的消息中，包含32 b的token和一個(gè)用于MAC計(jì)算的現(xiàn)時(shí)值，由于需要對(duì)第3個(gè)消息發(fā)送過來的MAC進(jìn)行驗(yàn)證，而不再攜帶token和現(xiàn)時(shí)值，那么主機(jī)B就必須在接收到第1個(gè)消息后維護(hù)相應(yīng)的信息.作為攻擊者就可以假冒主機(jī)A發(fā)送大量包含不同五元組的SYN+MP_JOIN消息，從而可以耗費(fèi)主機(jī)B的資源.針對(duì)TCP的SYN Flooding攻擊指的是攻擊者短時(shí)間內(nèi)發(fā)送大量的SYN請(qǐng)求，而服務(wù)器端需要維護(hù)相應(yīng)的狀態(tài)，大量的請(qǐng)求則會(huì)耗費(fèi)有限的資源；而在MPTCP中，除了需要維護(hù)與TCP相關(guān)的信息之外，還需要維護(hù)初始連接的SYN+MP_CAPABLE中的密鑰信息以及后續(xù)子流建立中SYN+ MP_JOIN有關(guān)的token和現(xiàn)時(shí)信息，這無疑會(huì)使得SYN Flooding的攻擊能力得到放大.針對(duì)這2個(gè)安全威脅，RFC 7430給出的建議方案是使得MPTCP的握手過程從有狀態(tài)變成無狀態(tài)，由消息重復(fù)攜帶必須的信息以及限制half-open的子流的數(shù)量.

6.3 MPTCP對(duì)網(wǎng)絡(luò)安全的影響

MPTCP提供了同時(shí)使用在2個(gè)節(jié)點(diǎn)之間的多個(gè)路徑的能力，這就使得數(shù)據(jù)流不再依附于某個(gè)單獨(dú)的TCP來進(jìn)行傳輸，而是可以分布在構(gòu)成MPTCP連接的多個(gè)子流上，實(shí)現(xiàn)數(shù)據(jù)流的分裂且提供連接的彈性.由于子流可以隨時(shí)添加和刪除，MPTCP的連接與實(shí)際的地址之間是可以實(shí)現(xiàn)解耦的，但由于MPTCP連接的不變性，基于token機(jī)制，新添加的地址和路徑依然可以關(guān)聯(lián)與特定的MPTCP連接,這勢必會(huì)給現(xiàn)有的網(wǎng)絡(luò)安全帶來影響.

文獻(xiàn)[81]總結(jié)了MPTCP在現(xiàn)有網(wǎng)絡(luò)中的安全機(jī)制所帶來的破壞性影響，例如，利用MTCP便于實(shí)施跨路徑的分片攻擊、安全檢測和過濾系統(tǒng)的繞過(bypass)，以及作為移動(dòng)目標(biāo)防御(moving target defense)[82]的實(shí)現(xiàn)手段等.對(duì)于數(shù)據(jù)監(jiān)測也帶來了極大的難度，例如對(duì)于防火墻而言，往往屬于特定的網(wǎng)絡(luò)，這就很難中斷包含經(jīng)過不同網(wǎng)絡(luò)的多個(gè)TCP子流的MPTCP連接.

MPTCP對(duì)于多個(gè)TCP子流的數(shù)據(jù)傳輸往往采用聯(lián)合擁塞控制，這就給實(shí)現(xiàn)跨路徑的推理攻擊(inference attack)引入了一種有效途徑.文獻(xiàn)[83]提出了利用MPTCP可以有效推斷出非監(jiān)測路徑上的吞吐量.此外，該文還初步探討了對(duì)RTT和發(fā)送端的擁塞窗口大小的推斷方法.該文的作者Shafiq 和Liu近期獲得了美國國家科學(xué)基金會(huì)(National Science Foundation， NSF)的資助(2015-2018)[84]，用于研究利用MPTCP實(shí)現(xiàn)旁路攻擊的安全隱患和應(yīng)對(duì)措施，勢必會(huì)取得新的進(jìn)展，對(duì)于MPTCP協(xié)議下一步的制定也會(huì)產(chǎn)生一定的影響.

6.4 安全小結(jié)

MPTCP基于傳統(tǒng)TCP，可能會(huì)受到與TCP相同的安全威脅，此外，MPTCP可動(dòng)態(tài)添加或刪除子流連接，但MPTCP提供基于令牌驗(yàn)證的子流管理機(jī)制用于驗(yàn)證子流有效性，其安全保護(hù)級(jí)別較低，易于導(dǎo)致新的安全威脅.然兒，MPTCP相關(guān)的工作主要還是處于如何發(fā)揮其傳輸性能，已有的針對(duì)MPTCP安全性的考慮并不充分，研究還比較初步，僅包括SYN Flooding等典型攻擊的預(yù)防.然而隨著MPTCP受到越來越多的關(guān)注，其安全性的考量也逐漸被各研究機(jī)構(gòu)作為一個(gè)重要的研究方向.

7 其他方面的研究

7.1 路徑選擇

MPTCP的通信雙方之間可能有多條可供選擇的路徑，選擇最優(yōu)的路徑子集來傳輸數(shù)據(jù)有時(shí)候會(huì)優(yōu)于使用所有路徑，特別是對(duì)于路徑不對(duì)稱，即時(shí)延、丟包、帶寬、能耗等差異較大.

博弈路徑選擇算法[85]利用博弈的思想在各種開銷之間取平衡，比如接口開啟連接開銷和路徑時(shí)延開銷.另外，還有一些基于實(shí)現(xiàn)的方案執(zhí)行路徑選擇策略.MAPS[86]提出在未用于發(fā)送數(shù)據(jù)的路徑上發(fā)送少量探測包探知吞吐量，一旦該路徑吞吐量增大到一定閾值則替換已選用集合吞吐量最小的路徑.

文獻(xiàn)[87]使用跨層信息作為移動(dòng)設(shè)備路徑選擇的基本依據(jù)，數(shù)據(jù)接收端使用MAC層測量所得的路徑信號(hào)強(qiáng)度來估計(jì)路徑質(zhì)量，從而決定是否啟用或中止一條路徑.該方法比基于時(shí)延或丟包率的方法反應(yīng)更加靈敏準(zhǔn)確.

此外，第5節(jié)中與能耗相關(guān)的工作很多也涉及到路徑管理方面的研究，并且該方向日趨成為熱點(diǎn).

7.2 移動(dòng)性和QoS

MPTCP可協(xié)同使用多個(gè)路徑，增加或者刪除若干路徑而不影響上層應(yīng)用的連通性，并且能夠?qū)?shù)據(jù)從擁塞路徑轉(zhuǎn)移到其他路徑上進(jìn)行傳輸.上述特征使得MPTCP 天然集成了移動(dòng)特性.

除了前面的能耗研究之外，文獻(xiàn)[64]還首次使用具有Linux-MPTCP內(nèi)核版本的移動(dòng)設(shè)備在實(shí)際網(wǎng)絡(luò)環(huán)境中進(jìn)行移動(dòng)性測試，同時(shí)使用移動(dòng)終端的WIFI接口和3G接口進(jìn)行數(shù)據(jù)傳輸.當(dāng)WIFI信號(hào)被終止后，MPTCP仍可以使用3G接口繼續(xù)進(jìn)行數(shù)據(jù)傳輸，上層業(yè)務(wù)并沒有發(fā)生中斷，從而完成了不同接口間數(shù)據(jù)傳輸?shù)臒o縫切換，驗(yàn)證了MPTCP的移動(dòng)切換特性.

文獻(xiàn)[63]在此基礎(chǔ)上提出更完善的MPTCP移動(dòng)切換架構(gòu)，即對(duì)于非MPTCP終端，可以使用MPTCP代理作為錨點(diǎn)，與MPTCP終端建立連接，該場景同樣支持移動(dòng)性.

MPTCP與QoS結(jié)合方案[74,88-89]主要針對(duì)視頻業(yè)務(wù)而提出.根據(jù)視頻業(yè)務(wù)對(duì)時(shí)延敏感但是對(duì)丟包不敏感的特性，在MPTCP中增加部分可靠性策略，即接收端設(shè)置時(shí)延閾值(400 ms)，超過該閾值則接收端直接舍棄未接收到的數(shù)據(jù)包，這樣在容忍的丟包率范圍內(nèi)保證小時(shí)延.另外，方案中還將視頻業(yè)務(wù)的I，P，B幀排優(yōu)先級(jí)，對(duì)于優(yōu)先級(jí)高的I幀在吞吐量較高的路徑上發(fā)送，而P幀在次優(yōu)的路徑上發(fā)送.

7.3 數(shù)據(jù)中心中的MPTCP

隨著數(shù)據(jù)中心內(nèi)部數(shù)據(jù)傳輸量的迅速增大，其傳統(tǒng)的分層集中式拓?fù)鋵⒃斐珊诵慕粨Q機(jī)的數(shù)據(jù)傳輸壓力劇增.近年來的研究提出了VL2[90]以及FatTree[91]等新型拓?fù)浣Y(jié)構(gòu)來解決這一問題，這些拓?fù)湓跀?shù)據(jù)中心內(nèi)部任意2臺(tái)主機(jī)間都有多個(gè)核心交換機(jī)以提供全帶寬連接.

文獻(xiàn)[92-93]提出在上述密集并行網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中使用MPTCP替代TCP作為數(shù)據(jù)中心內(nèi)部的傳輸協(xié)議.不僅利用MPTCP多徑傳輸?shù)奶匦蕴嵘诉B接的吞吐量，且由于對(duì)上層應(yīng)用屏蔽部分路徑的失效，也提升了連接的健壯性.另一方面，路徑選擇和擁塞控制功能允許MPTCP將流量轉(zhuǎn)移到可用空間較大的路徑上，平衡了數(shù)據(jù)中心核心交換機(jī)上的流量，相較于TCP具有更好的公平性.

然而MPTCP在數(shù)據(jù)中心也存在TCP incast的問題，即同一路徑上的多個(gè)子流均遭遇擁塞而同步減小窗口，使得有效數(shù)據(jù)量急劇減少的情況.這種情況在一個(gè)終端向多個(gè)服務(wù)器同時(shí)請(qǐng)求數(shù)據(jù)時(shí)較為常見.EW-MPTCP (equally-weighted MPTCP)[94]在每個(gè)MPTCP連接執(zhí)行自身擁塞控制機(jī)制的基礎(chǔ)上，對(duì)同一終端的不同MPTCP連接建立聯(lián)合擁塞控制機(jī)制，為各個(gè)連接“加權(quán)”，使得這些不同MPTCP以高耦合的方式增大擁塞窗口，其連接吞吐量之和相當(dāng)于單條TCP連接，以能夠在瓶頸路徑上與單條TCP流公平競爭鏈路帶寬，而不至于引起路徑擁塞，進(jìn)而避免TCP incast問題.

8 總結(jié)和展望

MPTCP是目前網(wǎng)絡(luò)領(lǐng)域的重要研究方向之一.本文介紹了MPTCP的技術(shù)細(xì)節(jié)以及不同方面的研究進(jìn)展，這些研究促使MPTCP由當(dāng)初的概念逐步走向?qū)嵱?但本文的部分研究進(jìn)展還處于模擬實(shí)驗(yàn)階段，需要進(jìn)一步的實(shí)驗(yàn)，并完善到內(nèi)核代碼當(dāng)中.此外在一些研究方向上，相應(yīng)機(jī)制還需要進(jìn)一步加以研究.要使得MPTCP完全發(fā)揮其潛力，在端到端通信方面比擬于TCP在當(dāng)前的普及程度還有待于進(jìn)一步的研究.

[1]Song Wei, Zhuang Weihua. Performance analysis of probabilistic multipath transmission of video streaming traffic over multi-radio wireless devices[J]. IEEE Trans on Wireless Communications, 2012, 11(4): 1554-1564

[2]Kurant M. Exploiting the path propagation time differences in multipath transmission with FEC[J]. IEEE Journal on Selected Areas in Communications, 2011, 29(5): 1021-1031

[3]Wang Peng, Lan Julong, Chen Shuqiao. Multipath traffic splitting algorithm based on adaptive granularity[J]. Journal on Communications, 2015, 36(1): 211-217 (in Chinese)

(王鵬, 蘭巨龍, 陳庶樵. 粒度自適應(yīng)的多徑流量分割算法[J]. 通信學(xué)報(bào), 2015, 36(1): 211-217)

[4]Wu Chunming, Wang Baojin, Chen Junhua, et al. A traffic splitting algorithm based on nonius in multi-path[J]. Acta Electronic Sinica, 2010, 38(11): 2550-2554 (in Chinese)

(吳春明, 王保進(jìn), 陳均華, 等. 一種基于游標(biāo)的多徑流量分割算法[J]. 電子學(xué)報(bào), 2010, 38(11): 2550-2554)

[5]Stewart R. RFC2960 Stream control transmission protocol[S/OL]. Fremont, CA: IETF, 2000 [2015-06-17]. https://tools.ietf.org/html/rfc2960

[6]Amer P, Becke M, Dreibholz T, et al. draft-tuexen-tsvwg-sctp-multipath-11 load sharing for the stream control transmission protocol (SCTP)[S/OL]. Fremont, CA: IETF, 2013 [2015-12-03]. https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-11

[7]Iyengar J R, Amer P, Stewart R. Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths[J]. IEEE/ACM Trans on Networking, 2006, 14(5): 951-964

[8]Huitema C. draft-huitema-multi-homed-01 multi-homed TCP[S/OL]. Fremont, CA: IETF, 1995 [2015-06-17]. https://tools.ietf.org/html/draft-huitema-multi-homed-01

[9]Eardley P, Nishida Y. IETF MPTCP WG[OL]. [2015-06-17]. http://datatracker.ietf.org/wg/mptcp

[10]Ford A. RFC 6824 TCP extensions for multipath operation with multiple addresses[S/OL]. Fremont, CA: IETF, 2013 [2015-06-17]. https://tools.ietf.org/html/rfc6824

[11]Ford A, Raiciu C, Handley M, et al. RFC 6182 Architectural guidelines for multipath TCP development[S/OL]. Fremont, CA: IETF, 2011 [2015-06-17]. https://tools.ietf.org/html/rfc6182

[12]Raiciu C, Handly M, Wischik D. RFC 6356, Coupled congestion control for multipath transport protocols[S/OL]. Fremont, CA: IETF, 2011 [2015-06-17]. https://tools.ietf.org/html/rfc6356

[13]Walid A, Peng Qiuyu, Hwang J, et al. draft-walid-mptcp-congestion-control-02 balanced linked adaptation congestion control algorithm for MPTCP[S/OL]. Fremont, CA: IETF, 2015 [2015-12-03]. https://tools.ietf.org/html/draft-walid-mptcp-congestion-control-02

[14]Xu Mingwei, Cao Yu, Dong Enhuan. draft-xu-mptcp-congestion-control-02 delay-based congestion control for MPTCP[S/OL]. Fremont, CA: IETF, 2015 [2015-12-03]. https://tools.ietf.org/html/draft-xu-mptcp-congestion-control-02

[15]Bagnulo M. RFC 6181 threat analysis for TCP extensions for multipath operation with multiple addresses[S/OL]. Fremont, CA: IETF, 2011 [2015-06-17]. https://tools.ietf.org/html/rfc6181

[16]Bagnulo M, Paasch C, Gont F, et al. RFC 7430 Analysis of residual threats and possible fixes for multipath TCP (MPTCP)[S/OL]. Fremont, CA: IETF, 2015 [2015-12-03]. https://tools.ietf.org /html/rfc7430

[17]Scharf M, Ford A. RFC 6897 multipath TCP (MPTCP) application interface considerations[S/OL]. Fremont, CA: IETF, 2013 [2015-06-17]. https://tools.ietf.org/html/rfc6897

[18]Wei X, Lopez E. draft-wei-mptcp-proxy-mechanism-02 MPTCP proxy mechanisms[S/OL]. Fremont, CA: IETF, 2015 [2015-06-17]. https://tools.ietf.org/html/draft-wei-mptcp-proxy-mechanism-02

[19]Handley M, Raiciu C. Multipath TCP implementations[OL]. 2015 [2015-06-17]. http://nrg.cs.ucl.ac.uk/mptcp/implementation.html

[20]Google Inc. MPTCP-NS3 project[OL]. 2015 [2015-06-17]. http://code.google.com/p/mptcp-ns3

[21]Kheirkhah M. Morteza Kheirkhah’s homepage on github.com[OL]. 2015 [2015-06-17]. https://github.com/mkheirkhah

[22]Kheirkhah M, Wakeman I, Parisis G. MultiPath-TCP in NS3[OL]. 2014 [2015-06-17]. http://arxiv.org/pdf/1510.07721.pdf

[23]Barré S, Paasch C, Duchêne F, et al. Linux kernel multipath TCP project[OL]. 2015 [2015-06-17]. http://multipath-tcp.org/pmwiki.php/Main/HomePage

[24]Barré S, Paasch C, Bonaventure O. MultiPath TCP: From theory to practice[C] //Proc of IFIP Networking. Berlin: Springer, 2011: 444-457

[25]Barré S. Implementation and assessment of modern host-based multipath solutions[D]. Louvain-la-Neuve: Université catholique de Louvain, 2011

[26]Raiciu C, Paasch C, Barré S, et al. How hard can it be? Designing and implementing a deployable multipath TCP[C] //Proc of the 9th USENIX Symp of Networked Systems Design and Implementation (NSDI’12). Berkeley, CA: USENIX Association, 2012: No.29

[27]Paasch C, Ferlin S, Alay O, et al. Experimental evaluation of multipath TCP schedulers[C] //Proc of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop (CSWS 2014). New York: ACM, 2014: 27-32

[28]Apple Inc. MPTCP patch for Apple IOS and MacOS[OL]. 2015 [2015-06-17]. http://www.opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet

[29]Paasch C. Improving multipath TCP[D]. Louvain-la-Neuve: Université catholique de Louvain, 2014

[30]Detal G, Baerts M, Caninck Q D. Bundles for Android[OL]. 2015 [2015-06-17]. http://multipath-tcp.org/pmwiki.php/Users/Android

[31]Raiciu C, Pluntke C, Barré S, et al. Data center networking with multipath TCP[C] //Proc of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks (HotNets IX workshop). New York: ACM, 2010: No.10

[32]Raiciu C, Barré S, Pluntke C, et al. Improving datacenter performance and robustness with multipath TCP[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 266-277

[33]Armitage G, Williams N, Stewart L, et al. Multipath TCP work in CAIA[OL]. 2015 [2015-06-17]. http://caia.swin.edu.au/urp/newtcp/mptcp

[34]Chen Y C, Lim Y, Gibbens R J, et al. A measurement-based study of multipth TCP performance over wireless networks[C] //Proc of the 2013 Internet Measurement Conf (IMC’13). New York: ACM, 2013: 455-468

[35]Mirani F, Boukhatem N, Tran M A. A data-scheduling mechanism for multi-homed mobile terminals with disparate link latencies[C] //Proc of the 72nd IEEE Vehicular Technology Conf (VTC 2010-Fall). Piscataway, NJ: IEEE, 2010: 1-5

[36]Ni Dan, Xue Kaiping, Hong Peilin, et al. Fine-grained forward prediction based dynamic packet scheduling mechanism for multipath TCP in lossy networks[C] //Proc of the 23rd Int Conf on Computer Communications and Networks (ICCCN 2014). Piscataway, NJ: IEEE, 2014: 1-7

[37]Ni Dan, Xue Kaiping, Hong Peilin, et al. OCPS: Offset compensation based packet scheduling mechanism for multipath TCP[C] //Proc of Int Conf on Communications (ICC 2015). Piscataway, NJ: IEEE, 2015: 6187-6192

[38]Xu Changqiao, Liu Tianjiao, Guan Jianfeng, et al. CMT-QA: Quality-aware adaptive concurrent multipath data transfer in heterogeneous wireless networks[J]. IEEE Trans on Mobile Computing, 2013, 12(11): 2193-2205

[39]Kim H, Oh B, Lee J. Improvement of MPTCP performance in heterogeneous network using packet scheduling mechanism[C] //Proc of the 18th Asia-Pacific Conf on Communications (APCC 2012). Piscataway, NJ: IEEE, 2012: 842-847

[40]Yang Fan, Amer P, Ekiz N. A scheduler for multipath TCP[C] //Proc of the 22nd Int Conf on Computer Communications and Networks (ICCCN 2013). Piscataway, NJ: IEEE, 2013: 1-7

[41]Casetti C, Gaiotto W. Westwood SCTP: Load balancing over multipaths using bandwidth-aware source scheduling[C] //Proc of the 60th IEEE Vehicular Technology Conf (VTC 2004-Fall). Piscataway, NJ: IEEE, 2004: 3025-3029

[42]Cloud J, Calmon F, Zeng Weifei, et al. Multi-path TCP with network coding for mobile devices in heterogeneous networks[C] //Proc of the 78th IEEE Vehicular Technology Conf (VTC 2013-Fall). Piscataway, NJ: IEEE, 2013: 1-5

[43]Li Ming, Lukyanenko A, Cui Yong. Network coding based multipath TCP[C] //Proc of the 2012 IEEE Conf on Computer Communications Workshops (INFOCOM WKSHPS). Piscataway, NJ: IEEE, 2012: 25-30

[44]Cui Yong, Wang Lian, Wang Xin, et al. FMTCP: A fountain code-based multipath transmission control protocol[J]. IEEE/ACM Trans on Networking, 2015, 23(2): 465-478

[45]Sharma V, Troy K, Kar K, et al. MPLOT: A transport protocol exploiting multipath diversity using erasure codes[C] //Proc of the 27th Conf on Computer Communications (INFOCOM 2008). Piscataway, NJ: IEEE, 2008: 592-600

[46]Li Ming, Ludreyanenko A, Tarkoma S, et al. Tolerating path heterogeneity in multipath TCP with bounded receive buffers[J]. Computer Networks, 2014, 64(2014): 1-14

[47]Eggert L, Heidemann J, Touch J. Effects of ensemble-TCP[J]. ACM SIGCOMM Computer Communication Review, 2000, 30(1): 15-29

[48]Balakrishnan H, Rahul H, Seshan S. An integrated congestion management architecture for Internet hosts[J]. ACM SIGCOMM Computer Communication Review, 1999, 29(4): 175-187

[49]Singh M, Pradhan P, Francis P. MPAT: Aggregate TCP congestion management as a building block for Internet QoS[C] //Proc of the 12th IEEE Int Conf on Network Protocols (ICNP 2004). Piscataway, NJ: IEEE, 2004: 129-138

[50]Handley M, Padhye J, Floyd S. RFC2861 TCP congestion window validation[S/OL]. Fremont, CA: IETF, 2000 [2015-06-17]. https://tools.ietf.org/html/rfc2861

[51]Honda M, Nishida Y, Eggert L, et al. Multipath congestion control for shared bottleneck[C] //Proc of the 7th Int Workshop on Protocols for Future, Large-Scale and Diverse Network Transports (PFLDNeT Workshop). New York: ACM, 2009: 19-24

[52]Han H, Shakkottai S, Hollot C, et al. Overlay TCP for multi-path routing and congestion control[C/OL] //Proc of IMA Workshop on Measurements and Modeling of the Internet. Montvale, NJ: IMA, 2004 [2015-06-17]. http://www.ifp.illinois.edu/～sshakkot/multipath_v3.pdf

[53]Kelly F, Voice T. Stability of end-to-end algorithms for joint routing and rate control[J]. ACM SIGCOMM Computer Communication Review, 2005, 35(2): 5-12

[54]Wischik D, Raiciu C, Greenhalgh A, et al. Design, implementation and evaluation of congestion control for multipath TCP[C] //Proc of the 8th USENIX Conf on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2011: No.8

[55]Raiciu C, Handley M, Wischik D. RFC 6356 coupled congestion control for multipath transport protocols[S/OL]. Fremont, CA: IETF, 2000 [2015-06-17]. https://tools.ietf.org/html/rfc6356

[56]Raiciu C, Wischik D, Handley M. Practical congestion control for multipath transport protocols[R/OL]. London, United Kingdom: University College London. 2009 [2015-06-17]. http://nrg.cs.ucl.ac.uk/mptcp/mptcp-techreport.pdf

[57]Khalili R, Gast N, Popovic M, et al. MPTCP is not Pareto-optimal: Performance issues and a possible solution[C] //Proc of the 8th Int Conf on Emerging Networking Experiments and Technologies (CoNEXT 2012). New York: ACM, 2012: 1-12

[58]Brakmo L, O’Malley S W, Peterson L L. TCP vegas: New techniques for congestion detection and avoidance[J]. ACM SIGCOMM Computer Communication Review, 1994, 24(4): 24-35

[59]Cao Yu, Xu Mingwei, Fu Xiaoming. Delay-based congestion control for multipath TCP[C] //Proc of the 20th IEEE Int Conf on Network Protocols (ICNP 2012). Piscataway, NJ: IEEE, 2012: 1-10

[60]Hassayoun S, Iyengar J, Ros D. Dynamic window coupling for multipath congestion control[C] //Proc of the 19th IEEE Int Conf on Network Protocols (ICNP 2011). Piscataway, NJ: IEEE, 2011: 341-352

[61]Peng Qiuyu, Walid A, Low S H. Multipath TCP: Analysis and design[OL]. 2013 [2015-06-17]. http://arxiv.org/pdf/1308.3119.pdf

[62]Nicutar C, Niculescu D, Raiciu C. Using cooperation for low power low latency cellular connectivity[C] //Proc of the 10th ACM Int Conf on Emerging Networking Experiments and Technologies (CoNEXT’14). New York: ACM, 2014: 337-348

[63]Raiciu C, Niculescu D, Bagnulo M, et al. Opportunistic mobility with multipath TCP[C] //Proc of the 6th Int Workshop on MobiArch. New York: ACM, 2011: 7-12

[64]Paasch C, Detal G, Duchene F, et al. Exploring mobile/WiFi handover with multipath TCP[C] //Proc of the 2012 ACM SIGCOMM Workshop on Cellular Networks: Operations, Challenges, and Future Design. New York: ACM, 2012: 31-36

[65]Deng Shuo, Netravali R, Sivaraman A, et al. WiFi, LTE, or both?: Measuring multi-homed wireless Internet performance[C] //Proc of the 2014 Conf on Internet Measurement. New York: ACM, 2014: 181-194

[66]Nika A, Zhu Yibo, Ding Ning, et al. Energy and performance of smartphone radio bundling in outdoor environments[C] //Proc of the 24th Int Conf on World Wide Web. Republic and Canton of Geneva, Switzerland: IW3C2 (International World Wide Web Conferences Steering Committee), 2015: 809-819

[67]Zhang Hong, Xue Kaiping, Hong Peilin, et al. Congestion exposure enabled TCP with network coding for hybrid wired-wireless network[C] //Proc of the 23rd Int Conf on Computer Communication and Networks (ICCCN 2014). Piscataway, NJ: IEEE, 2014: 1-8

[68]Minear L, Zhang E. Impact of energy consumption on multipath TCP enabled mobiles[OL]. 2014 [2015-06-17]. http://arxiv.org/pdf/1412.7912v1.pdf

[69]Lim Y S, Chen Y C, Nahum E M. How green is multipath TCP for mobile devices?[C] //Proc of the 4th Workshop on All Things Cellular: Operations, Applications, & Challenges. New York: ACM, 2014: 3-8

[70]Chen Shengyang, Yuan Zhenhui, Muntean G M. An energy-aware multipath-TCP-based content delivery scheme in heterogeneous wireless networks[C] //Proc of the 2013 IEEE Wireless Communications and Networking Conf (WCNC 2013). Piscataway, NJ: IEEE, 2013: 1291-1296

[71]Chen Shengyang, Yuan Zhenhui, Muntean G M. A traffic burstiness-based offload scheme for energy efficiency deliveries in heterogeneous wireless networks[C] //Proc of the 2013 IEEE Global Communications Conf Workshops (IEEE Globecom Workshops). Piscataway, NJ: IEEE, 2013: 538-543

[72]Le T A, Hong C S. ecMTCP: An energy-aware congestion control algorithm for multipath TCP[J]. IEEE Communications Letters, 2011, 16(2): 275-277

[73]Peng Qiuyu, Chen Minghua, Anwar W, et al. Energy efficient multipath TCP for mobile devices[C] //Proc of the 15th ACM Int Symp on Mobile Ad Hoc Networking and Computing (Mobihoc 2014). New York: ACM, 2014: 257-266

[74]Singh V, Ahsan S, Ott J. MPRTP: Multipath considerations for real-time media[C] //Proc of the 4th ACM Multimedia Systems Conf(MMSys’13). New York: ACM, 2013: 190-210

[75]Pluntke C, Eggert L, Kiukkonen N. Saving mobile device energy with multipath TCP[C] //Proc of the 6th Int Workshop on MobiArch. New York: ACM, 2011: 1-6

[76]Nordmark E, Bagnulo M. RFC5533 Shim6: Level 3 multihoming shim potocol for IPv6[S/OL]. Fremont, CA: IETF, 2009 [2015-06-17]. https://tools.ietf.org/html/rfc5533

[77]Stewart R. RFC4960 stream control transmission protocol[S/OL]. Fremont, CA: IETF, 2007 [2015-06-17]. https://tools.ietf.org/html/rfc4960

[78]Gundavelli S, Leung K, Devarapalli V, et al. Proxy mobile IPv6[S/OL]. Fremont, CA: IETF, 2008 [2015-06-17]. https://tools.ietf.org/html/rfc4960

[79]Bagnulo M. draft-bagnulo-mptcp-secure-00 secure MPTCP[S/OL]. Fremont, CA: IETF, 2014 [2015-06-17]. https://tools.ietf.org/html/draft-bagnulo-mptcp-secure-00

[80]Diez J, Bagnulo M, Valera F, et al. Security for multipath TCP: A constructive approach[J]. International Journal of Internet Protocol Technology, 2011, 6(3): 146-155

[81]Pearce C, Zeadally S. Ancillary impacts of multipath transmission control protocol (MPTCP) on current and future network security[J]. IEEE Internet Computing, 2015, 19(5): 58-65

[82]Jajodia S, Ghosh A K, Swarup V, et al. Moving Target Defense: Creating Asymmetric Uncertainty for Cyber Threats[M]. Berlin: Springer, 2011

[83]Shafiq M Z, Le F, Srivatsa M, et al. Cross-path inference attacks on multipath TCP[C] //Proc of the 12th ACM Workshop on Hot Topics in Networks (Hotnets 2013). New York: ACM, 2013: No.15

[84]Shafiq M Z. Multipath TCP side channel vulnerabilities and defenses[OL]. 2015 [2015-12-03]. http://www.nsf.gov/awardsearch/showAward?AWD_ID=1524329

[85]Nguyen S C, Nguyen T M T, Pujolle G, et al. Strategic evaluation of performance-cost trade-offs in a multipath TCP multihoming context[C] //Proc of the 2012 IEEE Int Conf on Communications (ICC 2012). Piscataway, NJ: IEEE, 2012: 1443-1447

[86]Chen Yu, Wu Xin, Yang Xiaowei. MAPS: Adaptive path selection for multipath transport protocols in the Internet, TR2011-09[R]. Durham, North Carolina: Department of Computer Science, Duke University, 2011

[87]Lim Y, Chen Y, Nahum E, et al. Cross-layer path management in multi-path transport protocol for mobile devices[C] //Proc of the 2014 IEEE Conf on Computer Communications (INFOCOM 2014). Piscataway, NJ: IEEE, 2014: 1815-1823

[88]Diop C, Dugué G, Chassot C, et al. QoS-aware and autonomic-oriented multi-path TCP extensions for mobile and multimedia applications[J]. International Journal of Pervasive Computing and Communications, 2012, 8(4): 306-328

[89]Dugue G, Chassot C, Exposito E. QoS-aware multipath-TCP extensions for mobile and multimedia applications[C] //Proc of the 9th Int Conf on Advances in Mobile Computing and Multimedia(MoMM’11). New York: ACM, 2011: 139-146

[90]Greenberg A, Hamilton J R, Jain N, et al. VL2: A scalable and flexible data center network[J]. ACM SIGCOMM Computer Communication Review, 2009, 39(4): 51-62

[91]Al-Fares M, Loukissas A, Vahdat A. A scalable, commodity data center network architecture[J]. ACM SIGCOMM Computer Communication Review, 2010, 38(4): 63-74

[92]Raiciu C, Pluntke C, Barre S, et al. Data center networking with multipath TCP[C] //Proc of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks. New York: ACM, 2010: No.10

[93]Raiciu C, Barre S, Pluntke C, et al. Improving datacenter performance and robustness with multipath TCP[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 266-277

[94]Li Ming, Lukyanenko A, Tarkoma S, et al. MPTCP incast in data center networks[J]. China Communications, 2014, 11(4): 25-37

Xue Kaiping, born in 1980. PhD, associate professor. Senior member of China Computer Federation and IEEE. His main interests include next generation network architecture, network security.

Chen Ke, born in 1992. Master candidate. Her main research interests include multipath TCP performance improvement and mobility management (chenke13@mail.ustc.edu.cn).

Ni Dan. born in 1991. Received her master degree from University of Science and Technology of China in 2015. Her main research interests include network performance optimization (nidan@mail.ustc.edu.cn).

Zhang Hong. born in 1990. Received her master degree from University of Science and Technology of China in 2015. Her main research interests include network performance optimization (zhh006@mail.ustc.edu.cn).

Hong Peilin. born in 1961. Professor. PhD supervisor. Her main research interests include next-generation network architecture, network virtualization, and information security (plhong@ustc.edu.cn).

Survey of MPTCP-Based Multipath Transmission Optimization

Xue Kaiping1,2, Chen Ke1,2, Ni Dan1, Zhang Hong1, and Hong Peilin1,2

1(DepartmentofElectronicEngineeringandInformationScience,UniversityofScienceandTechnologyofChina,Hefei230027)2(KeyLaboratoryofWireless-OpticalCommunications(UniversityofScienceandTechnologyofChina),ChineseAcademyofSciences,Hefei230027)

The newly developed networks hope to bring some specific features, such as wide coverage, high bandwidth, and provide varieties of media services. Fortunately, multiple access techniques are at there to help. Nowadays，terminals are always equipped with multiple interfaces to adapt to the heterogeneous networks. Thus, there are more than one paths existing between two endpoints. MPTCP (multipath TCP) is proposed by IETF MPTCP working group, in addition to compatible with traditional TCP, which utilizes multiple paths to transmit data. It improves the efficiency of bandwidth usage and the resilience of the connection. What’s more, it can adaptively move data from more congested path to less congested path. In recent years, many researches have been carried out to gradually make MPTCP from concept to practice. This paper introduces the technical details of MPTCP standard, and expounds the present situation of the related aspects, including simulation and actual deployment, out-of-order control, coupled congestion control, energy consumption maintenance, security, and other aspects such as path selection, mobility and QoS, the data center scenario, et al. Finally, this paper gives a summary and expectation.

multiple path; multipath TCP (MPTCP); scheduling algorithms; congestion control; energy consumption management; security

2015-06-17；

2015-12-29

國家自然科學(xué)基金項(xiàng)目(61379129，61390513)；國家“八六三”高技術(shù)研究發(fā)展計(jì)劃基金項(xiàng)目(2014AA01A706)

TP393

This work was supported by the National Natural Science Foundation of China (61379129, 61390513) and the National High Technology Research and Development Program of China (863 Program) (2014AA01A706).