移動互聯(lián)網(wǎng)：原理、技術與應用 第3版 課件 第6、7章 移動傳輸機制、移動云計算

移動互聯(lián)網(wǎng)傳輸機制1課程大綱傳統(tǒng)傳輸技術

新興傳輸層協(xié)議QUIC其他傳輸機制22課程大綱傳統(tǒng)傳輸技術

新興傳輸層協(xié)議QUIC其他傳輸機制33TCP/IP概述IP數(shù)據(jù)包可能亂序傳輸數(shù)據(jù)包可能丟失數(shù)據(jù)包可能重復

44NitinH.Vaidya@Infocom’06TCP/IP概述TCP面向連接的可靠傳輸如果必要通過重傳來實現(xiàn)擁塞避免和控制端到端語義TCP接收方發(fā)送確認給發(fā)送方來證實數(shù)據(jù)的送達對數(shù)據(jù)對確認在數(shù)據(jù)到達接受方后才發(fā)送556樣例中假設確認不會被延遲TCP/IP概述基于窗口的流控擁塞窗口大?。╓）限定了每個往返時間（RTT）內(nèi)可以發(fā)送的最大數(shù)據(jù)量吞吐率<=W/RTT擁塞避免和控制慢啟動擁塞避免慢啟動閾值ssthreshTCP如何檢測丟包重傳超時(RTO)TCP發(fā)送端為一個數(shù)據(jù)包設定超時計時器如果被計時數(shù)據(jù)包在計時器到時間前還被確認，則該數(shù)據(jù)包就被認為丟失了RTO是動態(tài)計算的重復確認TCP發(fā)送端在連續(xù)收到三次重復確認時就認為發(fā)生了丟包77TCP/IP概述8ssthresh=8ssthresh=10cwnd=20超時后擁塞控制快速重傳在多個（>=3）重復確認到達時發(fā)生快速重傳快速恢復跟著快速重傳快速恢復慢啟動閾值（ssthresh）

min(cwnd,接收方通告窗口)/2 (最小2MSS)重傳丟失的分片（快速重傳）cwnd

ssthresh

+重復確認數(shù)新確認到達時cwnd

ssthresh進入擁塞避免9擁塞控制10在快速重傳和快速恢復后窗口減半接收端的通告窗口大小快速恢復后TCP在無線網(wǎng)絡中的問題1111TCP基本假設丟包是由于擁塞需要降低傳輸速率

但是在無線網(wǎng)絡中丟包可能是由于:高誤比特率（BER）,無線信道的BER為10-3-10-5,而有線信道的BER為10-8-10-10

甚至更低不穩(wěn)定的信道用戶移動/節(jié)點電池耗盡需要快速重傳傳輸錯誤的影響隨機錯誤可能引起快速重傳重傳丟失的包擁塞窗口減小突發(fā)錯誤可能引起超時超時引起慢啟動

慢啟動減小擁塞窗口到一個MSS從而降低吞吐率隨機錯誤也可能引起超時一個窗口內(nèi)丟失多個包在使用TCP-Reno時可以造成超時（在使用SACK時影響程度小一些）12傳輸錯誤的影響TCP無法分辨丟包是由于擁塞還是傳輸錯誤因為傳輸錯誤減小擁塞窗口是不必要的擁塞窗口減小降低吞吐率：吞吐率<=W/RTT理想情況：

W=延時*帶寬丟包率為p時：W(<=延時*帶寬)吞吐率受到損害13隨機錯誤的影響14指數(shù)誤差模型2Mbps無線全雙工鏈路無擁塞損失吞吐量與錯誤率成反比NitinH.Vaidya@ASSET’99隱藏和暴露終端問題隱藏終端問題15暴露終端問題ACBABCD不穩(wěn)定問題有些場景即使只有一個TCP連接，吞吐率可能降到零使得連接不穩(wěn)定如果站點1正發(fā)送給終端5，吞吐率可能由于下面原因而降到零：隱藏和暴露終端問題可能阻止終端2接收RTS或者發(fā)送CTS到終端1隨機退避時間TCP使用大窗口不穩(wěn)定問題的解決方案降低TCP層的最大窗口大小讓干擾范圍和通信范圍相同16不兼容問題兩個同時的TCP流不能在網(wǎng)絡中共存一旦一個會話發(fā)展，另一個停工在任何時間可以隨機顛倒主要原因隱藏終端問題暴露終端問題

MAC層的指數(shù)退避方案解決方案通過懲罰傳輸太多數(shù)據(jù)的終端來改變退避政策，使得其他終端也能使用上媒體

調(diào)整干擾和感知范圍

17單跳不公平問題如果有兩個同時運行的TCP連接，一個單跳一個多跳，即使多跳連接先開始單跳連接也會激活原因是隱藏/暴露終端問題、指數(shù)退避策略

解決方案基于退避策略的活躍鄰居估計(ANE)：替換指數(shù)退避策略接收波束形成(RBF)天線：

使用定向天線來避免來自競爭終端的干擾18單跳無線TCP解決方案19單跳無線TCP傳輸機制丟包恢復連接管理丟包原因的通知機制分離鏈路機制端對端連接機制鏈路層丟包恢復機制鏈路層解決方案目標：讓鏈路層改正所有錯誤方案

FEC(前向糾錯)：在信息中加入冗余用來改正少量錯誤FEC在沒有錯誤時也會引入更多開銷ARQ(自動重傳請求)：在鏈路層重傳在超出FEC能力范圍時使用僅當錯誤發(fā)生時彩引入重傳開銷HARQ:FEC+ARQ2020鏈路層解決方案21物理層鏈路層網(wǎng)絡層傳輸層應用層rxmtTCP連接鏈路層狀態(tài)FHMHBS無線鏈路固定主機基站移動主機物理層鏈路層網(wǎng)絡層傳輸層應用層物理層鏈路層網(wǎng)絡層傳輸層應用層鏈路層重傳：問題鏈路層應該嘗試重傳多少次才放棄？有限邊界–半可靠的鏈路層沒有邊界–可靠的鏈路層什么觸發(fā)鏈路層重傳？鏈路層超時策略鏈路層確認（否定確認，重復確認……）其他方案(比如后面將要介紹的Snoop)鏈路層重傳需要多長時間？端到端TCPRTT的小部分端到端TCPRTT的大部分或幾倍22鏈路層重傳：問題鏈路層應該在數(shù)據(jù)包到達時就傳輸，還是應該按序傳輸？要按序傳輸?shù)脑挘溌穼尤绻匾赡苄枰彺鏀?shù)據(jù)以及重新排序重傳可能導致隊頭阻塞盡管到接收端1的鏈路可能很差，到接收端2的鏈路可能狀態(tài)良好到接收端1的重傳失敗也會阻塞發(fā)送到接收端2的數(shù)據(jù)包23接收端1接收端2基站鏈路層重傳：問題重傳可能導致?lián)砣麃G包嘗試重傳隊列頭部的一個包，顯著降低可用帶寬，可能使得基站的隊列長度更長隊列滿之后數(shù)據(jù)包會丟失，對發(fā)送端表明擁塞這是應該的嗎？24基站接收端1接收端2鏈路層重傳：初期研究

發(fā)送端的RTO是測量得到的RTT的函數(shù)鏈路層重傳會提升RTT，從而提升RTO如果錯誤不頻繁的話，RTO并不能解釋由于鏈路層重傳引起的RTT變化發(fā)生錯誤時，發(fā)送端可能在鏈路層重傳成功前發(fā)生超時重傳發(fā)送端和鏈路層都進行重傳重復重傳（干擾）會浪費無線帶寬超時會造成擁塞窗口減少缺點：不能準確建模實際的TCP棧25A.DeSimone@Globecom’93鏈路層重傳：更準確的了解頻繁的差錯在比較慢的無線鏈路上會顯著提高RTO鏈路層和TCP重傳間干擾的可能性更小但是擁塞響應會因為更大的RTO而受到延遲無線丟包引起超時時會浪費很多時間大TCP重傳超時間隔有助于減少和鏈路層重傳間的干擾不利于擁塞丟包的恢復需要一個對兩種丟包都正確響應的超時策略（開放型問題）26H.Balakrishnan@Sigcomm’96鏈路層重傳：按序傳輸為了避免不必要的快速重傳，使用重傳的鏈路層應該嘗試盡量按序傳輸按序傳輸并不是所有連接都能從重傳或者按序傳輸中獲得好處（比如音頻視頻就不一定）需要能夠在每個包的基礎上指定要求某個包應該重傳嗎？多少次？強制按序傳輸？需要一個標準的方案來指定要求開放型(IETFPILC工作組)27R.Ludwig@Sigmetrics’98鏈路層方案：總結(jié)可靠的鏈路層什么時候?qū)CP性能有益？如果能夠提供幾乎按序的傳輸以及

TCP重傳超時大到能夠容忍由于鏈路層重傳引起的額外時延28鏈路層方案：特性對TCP發(fā)送端隱藏無線丟包在無線鏈路兩端都要進行鏈路層修改TCP不需要修改29SnoopTCP在BS（外地代理）中的“透明的”TCP擴展緩存發(fā)送給移動端的數(shù)據(jù)包無線鏈路上（雙向?。┑膩G包會立刻由移動端或者基站（外地代理）重傳BS因此“snoops（窺探）”數(shù)據(jù)包流并且識別雙向確認只修改BS中的TCP30“有線”互聯(lián)網(wǎng)緩存數(shù)據(jù)端到端TCP連接本地重傳對端節(jié)點CN外地代理（基站）移動節(jié)點窺探ACKH.Balakrishnan@ACM95SnoopTCP31FHMHBS無線rxmt每個TCP連接狀態(tài)TCP連接數(shù)據(jù)傳輸?shù)揭苿佣薋A緩存數(shù)據(jù)到接收到MH的ACK，F(xiàn)A通過重復確認或者超時檢測丟包可能快速重傳，對固定網(wǎng)絡透明數(shù)據(jù)來自移動端FA通過序列號檢測無線丟包，F(xiàn)A直接回復NACK給MHMH現(xiàn)在可以以很小到時延重傳數(shù)據(jù)物理層鏈路層網(wǎng)絡層傳輸層應用層物理層鏈路層網(wǎng)絡層傳輸層應用層物理層鏈路層網(wǎng)絡層傳輸層應用層SnoopTCP

保留了分離鏈路方案的本地恢復和鏈路層重傳策略集成了MAC層MAC層通常含有和TCP類似的方案MAC已經(jīng)能夠檢測到由于重傳而重復的數(shù)據(jù)包并丟棄改進了分離鏈路保留了端到端語義在基站使用軟狀態(tài)而不是硬狀態(tài)對發(fā)送端隱藏無線丟包只需要對BS進行修改（以網(wǎng)絡為中心的方案）32SnoopTCP332Mbps無線鏈路Snoop相對基準TC片的吞吐率增長SnoopTCP：什么時候有用？Snoop阻止快速重傳除非發(fā)生傳輸錯誤，在無線鏈路進行亂序傳輸亂序傳輸當且僅當引起了至少3個重復確認時才快速重傳在無線鏈路層帶寬時延乘積少于四個數(shù)據(jù)包時，一個簡單的（TCP不感知的）鏈路層重傳策略就足夠了由于帶寬時延乘積很小，重傳策略可以在不引起3次重傳確認的情況小傳輸丟失的包34SnoopTCP：優(yōu)點可以達到高吞吐率使用選擇確認時性能可以進一步提高本地回復無線丟包發(fā)送端不會觸發(fā)快速重傳除非時亂序鏈路層傳輸保留了端到端語義基站中是軟狀態(tài)軟狀態(tài)丟失影響性能但不影響正確性35SnoopTCP：缺點基站但鏈路層需要是TCP感知的隔離無線鏈路不如I－TCP好在TCP頭加密時無用(IPsec)在TCP數(shù)據(jù)和確認走不同路徑時無用（兩個都不經(jīng)過基站）36非TCP感知的鏈路層目標仿真snoopTCP的性能不需要BS的鏈路層感知在BS鏈路層重傳是用來進行本地恢復在snoop-TCP中重傳由TCP重復確認觸發(fā)，但在非TCP感知的鏈路層重傳由鏈路層確認觸發(fā)3737非TCP感知的鏈路層MN減少了TCP和鏈路層重傳間的干擾對最開始兩個數(shù)據(jù)包，立刻發(fā)送副本對后續(xù)連續(xù)包，副本延遲時間d3838傳統(tǒng)TCP中的干擾3939151410131011129DS新ACK16151410121311DSACK1716151410131012DSACK1010101817161510101413DS新ACKACKACK101010重復ACK10非TCP感知的鏈路層4040151410131011129DS新ACK16151410121311DSACK1716151410131012DSACK101018171615101413DS新ACKACKACK1010重復ACK被延遲了重復ACK被延遲了非TCP感知的鏈路層優(yōu)點鏈路層不需要感知TCP在無線鏈路上小RTT的情況工作良好缺點DUPACK延時的最優(yōu)值獨立于無線鏈路4141丟包原因通知機制EBSN基站發(fā)現(xiàn)無線鏈路的通信質(zhì)量不好時，馬上向發(fā)送點發(fā)送消息，調(diào)整數(shù)據(jù)包大小并更新超時時間，避免不必要的超時。50%性能提升加重基站負擔42分離鏈路方案考慮有線部分比無線部分更可靠無線鏈路可能成為瓶頸因此分開控制

一個單獨的TCP連接拆分成兩個TCP連接FH-MH=FH-BS+BS-MH4343分離鏈路方案FHMHBS無線鏈路physicallinknetworktransportapplicationphysicallinknetworktransportapplicationphysicallinknetworktransportapplicationrxmt每條TCP連接狀態(tài)TCP連接TCP連接固定終端基站移動終端44ITCP(Indirect-TCP)考慮

把TCP連接分割成兩個不同的連接一個移動終端（MN）到基站（BS）間的連接

一個基站（BS）到

對端節(jié)點（CN）45A.Bakre@ICDCS’95移動節(jié)點（主機）接入點（外地代理）“有線”互聯(lián)網(wǎng)“無線”TCP標準TCP固定主機ITCP移動終端發(fā)送一個特殊的I-TCP請求到當前的AP來建立連接固定主機完全不知道這種間接連接46移動節(jié)點（主機）接入點（外地代理）“有線”互聯(lián)網(wǎng)“無線”TCP標準TCP固定主機ITCP套接字和狀態(tài)遷移47移動主機老的AP互聯(lián)網(wǎng)新的AP套接字遷移和狀態(tài)轉(zhuǎn)移當MN轉(zhuǎn)移到一個新的AP老的AP扮演外地代理來緩存和轉(zhuǎn)發(fā)數(shù)據(jù)包到新的APITCP優(yōu)勢固定網(wǎng)絡不需要改變，主機（TCP協(xié)議）不需要改變，所有當前對TCP的優(yōu)化仍然有效無線鏈路上的傳輸錯誤不會傳播到固定網(wǎng)絡容易控制，無線TCP僅僅在外地代理和移動終端間單跳中使用可以對數(shù)據(jù)包進行快速重傳48ITCP缺點破壞了端到端語義切換延時更高，由于需要在外地代理中緩存數(shù)據(jù)然后轉(zhuǎn)發(fā)到一個新的外地代理49MTCP(Mobile-TCP)問題

移動性——MN和BS之間的連接丟失一小段時間，者會導致：發(fā)送端超時，慢啟動AP可能緩存太多數(shù)據(jù)MTCP借助于監(jiān)控主機(SH)來解決這個問題5050保留一個到FH的ACKZ.Haas@ICC’97MTCP監(jiān)控主機SH在有線網(wǎng)絡中控制一些AP的節(jié)點沒有緩存，沒有重傳保留一個ACK給FH監(jiān)測所有數(shù)據(jù)包，如果檢測到斷連將發(fā)送端窗口置為0發(fā)送端自動進入保持模式（發(fā)送端的一個模式，不管接收端斷連多久都不會改變）舊的或者新的SH重新打開窗口51MTCP優(yōu)點保持了端到端語義（盡管TCP連接在SH處分割了）支持斷連沒有緩存轉(zhuǎn)發(fā)避免發(fā)送端慢啟動缺點無線鏈路的丟包傳播到固定網(wǎng)絡無線鏈路上的自適應TCP5252分離鏈路方案：特點對發(fā)送端隱藏傳輸錯誤基站負主要責任如果無線鏈路使用特殊傳輸協(xié)議，那個移動終端也需要進行修改53分離鏈路方案：優(yōu)點可以獨立于FH-BS連接對BS-MH連接進行優(yōu)化兩個連接上進行不同的流控和差錯控制錯誤恢復因為無線連接RTT變短而恢復更快使用合適的BS-MH協(xié)議可以獲得良好的性能標準TCP在BS-MH表現(xiàn)很差，當一個窗口中出現(xiàn)多個丟包時（這種情況下選擇確認可以改善性能）54分離鏈路方案：缺點違背了端到端語義ACK可能在數(shù)據(jù)傳輸?shù)浇邮斩酥鞍l(fā)送給發(fā)送端對不依賴TCP維持端到端語義的應用而言可能并不是個問題55FHMHBS403937383640BS處于困難模式 BS故障可以導致數(shù)據(jù)丟失（不可靠）如果BS故障，數(shù)據(jù)包40將會丟失因為數(shù)據(jù)包40已經(jīng)對發(fā)送端確認，發(fā)送端不再緩存56FHMHBS403937383640分離鏈路方案：缺點分離鏈路方案：缺點BS處于困難模式

切換延時因為狀態(tài)轉(zhuǎn)移而上升被確認給發(fā)送端了的數(shù)據(jù)必須移動到新的基站57FHMHBS403937383640MH新基站切換4039分離鏈路方案：缺點在BS上每個TCP連接都需要緩存空間在無線鏈路比固定連接更慢時，BS緩存會漸漸填滿（對每個分割的連接，在有線連接上一個窗口大小的數(shù)據(jù)要能夠存儲在基站中）BS-MH連接的窗口會因為誤碼而減小對帶寬延時乘積很小的無線鏈路問題不大58分離鏈路方案：缺點BS中額外的數(shù)據(jù)復制從FH-BS套接字緩存到BS-MH套接字緩存提高端到端延時在數(shù)據(jù)和確認通過不同路徑事可能無效（雙方不通過基站）例子：數(shù)據(jù)走衛(wèi)星無線鏈路，確認走一個撥號通道59FHMHBS數(shù)據(jù)ack端到端解決方案只有端點參與流控接收端提供網(wǎng)絡狀況反饋發(fā)送端決定擁塞控制60TCPSACK(選擇確認)問題ACKn確認正確且按序接收到的直到序列號n的包如果單個丟包很頻繁，空缺處開始的一整個數(shù)據(jù)包序列都得重傳（回退N），浪費帶寬解決方案TCP選擇確認

允許單個包確認允許發(fā)送端只重傳丟失得包6161M.Mathis@RFC2018SACKSACK指出接收端接受到到一個數(shù)據(jù)塊發(fā)送端可以直到丟失包的準確編號優(yōu)點效率更高缺點接收端需要更多緩存發(fā)送端和接收端都需要修改SACK塊編碼在TCP選項域，限制了每個ACK能攜帶的SACK塊數(shù)目擁塞避免能力有限6262Freeze-TCP（冷凍TCP）M-TCP需要基站的幫助基站扣留一字節(jié)的確認基站在一個移動端移動到另一個小區(qū)時，使用這個確認來發(fā)送一個零窗口廣告Freeze-TCP要求接收端發(fā)送零窗口廣告（ZWA）63FHMHBS移動TCP接收端Freeze-TCPTCP接收端確定切換是否即將發(fā)生確定可以基于信號強度理想情況下，接收端應該在切換前一個RTT嘗試發(fā)送ZWA在路由重建時，接收端發(fā)送3個重復確認不需要來自基站的幫助端到端的增強方案64TCP-Veno移動節(jié)點監(jiān)測網(wǎng)絡擁塞的級別，根據(jù)檢測到的網(wǎng)絡擁塞級別來調(diào)整慢啟動算法的閾值，并判斷丟包的原因是擁塞還是鏈路錯誤。有效地提高了無線移動互聯(lián)網(wǎng)的網(wǎng)絡利用率在斷路和切換頻繁時性能較差。65JTCP使用抖動率區(qū)分擁塞和斷路抖動率是一定時間間隔內(nèi)由于抖動產(chǎn)生的丟包數(shù)量通過連續(xù)的應答消息到達時間的差異計算抖動率，然后區(qū)分因擁塞造成的丟包和其他原因引起的丟包。66多跳無線TCP解決方案路由失敗fix降低路由失敗損失降低信道競爭67TCP-F該機制禁用TCP擁塞控制機制以防網(wǎng)絡引起的非擁塞相關的丟包以及路由失敗導致的超時事件。68ELFN定期探查鏈路恢復TCP-RC：恢復后參數(shù)重新計算CIIA：跨層信息通知缺陷：TCP更加激進69AdhocTCP在網(wǎng)絡層和傳輸層間增加名為ATCP的中間層，以確保在高傳輸錯誤時甚至路由失敗時采取正確的行為。70TCP-BuS一旦發(fā)生路由失敗，中間節(jié)點就對信息包進行緩存而不是加以丟棄，目的是為了不重新發(fā)送所有這些信息包。明確路由斷開通知(ERDN)明確路由成功通知(ERSN)71ENIC:增強的中間層通信和控制機制ELFN+TCPSACK第一個考慮路徑重建后路由性質(zhì)的潛在變化的方案。vsTCP-BuS中間節(jié)點協(xié)助更少72TCPDOOR利用數(shù)據(jù)包和/或異常傳遞的ACK來表示路由變更而不用明確的反饋。當異常包被收到時，發(fā)送節(jié)點可以暫時禁用TCP擁塞控制機制以保持它的狀態(tài)變量為常數(shù)。此外，它可能回滾到之前的某個狀態(tài)。73降低路由失敗的損失PreemptiveRouting：利用信號強度來預測路由失敗BackupPathRouting：維護多條路徑AtraFramework：預測+快速通知74降低競爭，增強公平性COPAS：動態(tài)競爭平衡LinkRED：控制重傳的平均次數(shù)N-RED：基于鄰居隊列的平均長度計算75課程大綱傳統(tǒng)傳輸技術

新興傳輸層協(xié)議QUIC其他傳輸機制767677QUIC概述QUIC協(xié)議棧結(jié)構(gòu)工作在用戶態(tài)，而非內(nèi)核QUIC概述需求驅(qū)動用戶對于網(wǎng)絡安全、低延遲傳輸?shù)膹娏倚枨髲幕ヂ?lián)網(wǎng)到物聯(lián)網(wǎng)，網(wǎng)絡連接數(shù)量不斷增多TCP丟包重傳機制影響了傳輸速度，其協(xié)議棧復雜難以修改快速建鏈QUIC將加密和傳輸握手結(jié)合在一起QUIC再次建立連接的時候通常只需要0-RTT擁塞控制

可嵌套的擁塞控制，便于部署不同的擁塞控制算法流量控制使用流級別和連接級別的流量控制7879QUIC概述多路復用HTTP/2的多路復用仍基于TCPQUIC使用多流機制減緩隊頭阻塞連接遷移

用64bit的ID來標識一個連接IP發(fā)生改變后，QUIC連接仍可存活安全性

QUIC的包頭參與加密，防止中間人攻擊QUIC連接

第一次連接建立QUIC改進了連接建立的過程，將TLS1.3的握手與傳輸層握手結(jié)合QUIC的握手數(shù)據(jù)包中攜帶了TLS秘鑰、證書協(xié)商信息以及相關的初始化參數(shù)80QUIC連接

再次建立連接0-RTT建鏈QUIC利用緩存信息避免了傳輸握手和秘鑰協(xié)商的過程，讓客戶端可以直接發(fā)送加密消息給與其通信過的服務器81QUIC連接

連接遷移TCP連接由源地址、源端口、目標地址和目標端口的4元組標識QUIC連接由一個64-bit連接ID標識。在IP地址改變和NAT重綁定時，QUIC連接可以繼續(xù)存活，因為連接ID在這些遷移過程中保持不變。移動設備在WIFI和4G移動網(wǎng)絡切換時，客戶端的IP肯定會發(fā)生變化。QUIC的連接能繼續(xù)存活，而TCP需要重新建立和服務端的連接。82多路復用多路復用使得多個數(shù)據(jù)流在一個傳輸連接上發(fā)送83多路復用HTTP/1.1只能一次請求一個資源客戶端與服務器之間經(jīng)常建立多個很短的TCP連接HTTP/2將多個數(shù)據(jù)流復用在同一個TCP連接上每個流的有效載荷數(shù)據(jù)是獨立的，但同一個TCP連接上的數(shù)據(jù)需要按序傳輸給上層應用當一個流的數(shù)據(jù)發(fā)生丟失時，其他流的數(shù)據(jù)都需要等待，從而造成線頭阻塞QUIC重新設計了多路復用QUIC保證每個流的數(shù)據(jù)都是按序傳輸?shù)模粋€流發(fā)生的數(shù)據(jù)丟失不會對同一連接上的其他流造成影響，避免了線頭阻塞問題84多路復用分層流控QUIC實現(xiàn)了流級別和連接級別的兩種流量控制基于連接的流控，讓接收端可以根據(jù)實際網(wǎng)絡情況調(diào)整為自身連接上所有數(shù)據(jù)流分配的聚合緩沖區(qū)大小基于數(shù)據(jù)流的流控，讓接收端可以調(diào)整每個流上自身能接收數(shù)據(jù)的空間85擁控機制擁塞控制QUIC具有可嵌套的擁塞控制接口，可以對不同的擁塞控制算法進行試驗和部署對TCP協(xié)議保持友好性，（計劃）將NewReno、CUBIC作為默認擁塞控制算法丟包恢復單調(diào)遞增的數(shù)據(jù)報文編號，可以區(qū)分出重傳的數(shù)據(jù)包，從而避免重傳二義性ACK中包含收包到發(fā)送ACK之間的延遲信息，利于估算RTTQUIC的SACK支持最多256個ACK塊，丟包恢復能力更強8687挑戰(zhàn)及未來方向特殊網(wǎng)絡場景下的擁塞控制無線網(wǎng)絡場景，丟包多由傳輸錯誤造成數(shù)據(jù)中心、虛擬現(xiàn)實等對低延遲的要求很高前向糾錯FEC利用冗余信息恢復丟失的數(shù)據(jù)報文，減少重傳前向糾錯的編解碼造成了額外的時間開銷，消耗帶寬2016年Google在QUIC的實現(xiàn)中已暫時放棄支持FEC基于應用的優(yōu)化HTTP/2與QUIC相結(jié)合如何更好地承載更多的應用88挑戰(zhàn)及未來方向優(yōu)先級網(wǎng)頁通常包含多個內(nèi)容，QUIC可針對依賴關系定制不同數(shù)據(jù)流的優(yōu)先級。安全與隱私針對0-RTT機制的重放攻擊、握手報文篡改未加密信息（如連接標識符）可能會造成檢測攻擊威脅連接遷移造成的可關聯(lián)性問題等等課程大綱傳統(tǒng)傳輸技術

新興傳輸層協(xié)議QUIC其他傳輸機制8989新的無線傳輸協(xié)議EXACT：顯式流控制協(xié)議，依據(jù)速率調(diào)節(jié)傳輸流量。它依靠網(wǎng)絡組件（比如路由器）來測量網(wǎng)絡擁塞狀態(tài)并且用顯式控制信息通知傳輸終端ATP：使用具有嚴格標準的擁塞控制機制以區(qū)分擁塞與斷路，只需要來自接收節(jié)點的很有限的反饋WXCP：WirelessXCP90總結(jié)傳統(tǒng)TCP在無線場景下新的問題和解決方案QUIC新興傳輸協(xié)議：純UDP其他非TCP技術91移動云計算9292課程大綱移動云計算概述移動云計算關鍵技術計算遷移技術基于移動云的位置服務移動節(jié)能終端技術數(shù)據(jù)中心網(wǎng)絡

數(shù)據(jù)中心概述數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)路性能優(yōu)化發(fā)展趨勢與展望9393課程大綱移動云計算概述移動云計算關鍵技術計算遷移技術基于移動云的位置服務移動節(jié)能終端技術數(shù)據(jù)中心網(wǎng)絡

數(shù)據(jù)中心概述數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)路性能優(yōu)化發(fā)展趨勢與展望9494移動云計算概述95移動云計算移動互聯(lián)網(wǎng)

+云計算催生新的服務和應用模式移動云計算體系架構(gòu)面向移動用戶通過無線網(wǎng)絡解決移動終端資源受限移動云計算體系架構(gòu)移動云計算概述96移動云計算優(yōu)勢動態(tài)部署資源可擴展多用戶共享移動云計算問題安全性網(wǎng)絡延遲課程大綱移動云計算概述移動云計算關鍵技術計算遷移技術基于移動云的位置服務移動節(jié)能終端技術數(shù)據(jù)中心網(wǎng)絡

數(shù)據(jù)中心概述數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)路性能優(yōu)化發(fā)展趨勢與展望9797計算遷移技術計算遷移將移動終端的計算、存儲等任務遷移到附近資源豐富的服務器執(zhí)行，減少移動終端計算、存儲和能量等資源的需求總體目標擴展CPU處理能力節(jié)約移動終端能耗減少服務延遲節(jié)約成本98計算遷移技術計算遷移過程代理發(fā)現(xiàn)環(huán)境感知任務劃分任務調(diào)度執(zhí)行控制99計算遷移步驟圖計算遷移技術計算遷移方案基于進程、功能函數(shù)的細粒度遷移基于程序、VM的粗粒度遷移100移動云計算中的計算遷移方案細粒度計算遷移細粒度計算遷移對程序預先劃分標注遷移計算密集型代碼盡可能減少數(shù)據(jù)傳輸遷移方案靜態(tài)劃分動態(tài)劃分101靜態(tài)劃分方案基于能耗（包括通信能量和計算能量）預測基于多種資源的利用情況基于集群式服務，支持將數(shù)據(jù)分發(fā)到網(wǎng)絡上多個節(jié)點并行處理應用數(shù)據(jù)，以進一步提高計算遷移的執(zhí)行效率，例如Misco。

102[1]ZLi,CWang,RXu.ComputationOffloadingtoSaveEnergyonHandheldDevices:aPartitionScheme[C].CASES,2001[2]KYang,SOu,HChen.OnEffectiveOffloadingServicesforResource-constrainedMobileDevicesRunningHeavierMobileInternetApplications.IEEECommunicationsMagazine,2001[3]ADou,VKalogeraki,DGunopulos,TMielikainen,VTuulos.Misco:aMapreduceFrameworkforMobileSystems[C].PETRA,2010動態(tài)劃分方案為了克服靜態(tài)劃分方案無法適應環(huán)境動態(tài)變化的不足，動態(tài)劃分方案可以根據(jù)連接狀態(tài)的變化調(diào)整遷移劃分區(qū)域103示例：動態(tài)遷移決策圖a，b，c為程序輸入，r為應用程序輸出，應用程序運行過程中會經(jīng)歷X1，X2，X3和X4四個計算節(jié)點。默認X1和X2在移動終端執(zhí)行，X3和X4在云端執(zhí)行。根據(jù)策略設置，在網(wǎng)絡帶寬比較好的時候，系統(tǒng)可以把X2動態(tài)遷移至云端執(zhí)行。細粒度計算遷移靜態(tài)劃分根據(jù)預先標注策略遷移需要預測、統(tǒng)計通信開銷和計算時間動態(tài)劃分根據(jù)系統(tǒng)負載、網(wǎng)絡狀態(tài)變化調(diào)整劃分導致額外的劃分決策消耗注意事項細粒度遷移導致額外的劃分決策的消耗，劃分算法的優(yōu)劣直接影響了遷移效率，而且并不總是能獲得最優(yōu)解。104粗粒度計算遷移粗粒度計算遷移整個程序封裝在VM中發(fā)送到云端減少細粒度遷移的劃分、決策開銷時間開銷、資源開銷較大105粗粒度計算遷移微云（Cloudlet）把微云定義為一種可信任的、資源豐富的計算設備或一群計算設備向附近的移動終端提供計算資源進一步細分為移動微云模式和固定微云模式106[1]SatyanarayananM,BahlP,CaceresR,etal.TheCaseforVm-basedCloudletsinMobileComputing[J].IEEEPervasiveComputing,2009Cloudlet架構(gòu)計算遷移方案對比107系統(tǒng)框架操作平臺決策目標粒度劃分遷移支持管理模式Misco移動云節(jié)點代理延遲方法級靜態(tài)程序級集中式MAU

云服務器代理/移動終端能耗方法級動態(tài)程序級集中式Thinkair

云服務器移動端延遲/能耗線程級動態(tài)系統(tǒng)級集中式Comet云服務器×延遲多線程動態(tài)系統(tǒng)級集中式Cogniserve云服務器×性能/能耗應用程序×程序級集中式Cyberforaging本地分布式代理延遲應用程序×系統(tǒng)級集中式Cloudle本地服務器×延遲應用程序×系統(tǒng)級分布式Cloneclou云服務器×性能/能耗VM動態(tài)系統(tǒng)級集中式VirtualizedExecutionEnvironment

云服務器××應用程序×系統(tǒng)級集中式基于移動云的位置服務基于GPS等傳統(tǒng)定位技術穿透力弱、定位能耗大無法滿足精確室內(nèi)定位、用戶動作識別需求移動云計算為解決以上問題提供重要技術支撐108基于移動云的位置服務移動云技術定位服務應用室內(nèi)軌跡追蹤與導航通過手機新越好強度，與加速、慣性等傳感器數(shù)據(jù)融合，最終用戶行動軌跡，回執(zhí)建筑物內(nèi)部平面圖室內(nèi)精確定位與動作識別利用三個WiFi訪問點，執(zhí)行三角測量算法進行跟蹤定位海量位置信息管理位置服務系統(tǒng)依賴云平臺進行用戶位置軌跡數(shù)據(jù)存儲、計算、索引等管理，從而減輕移動端的存儲和計算負載109移動終端節(jié)能技術移動端電池容量成為用戶體驗瓶頸移動端能耗管理研究數(shù)據(jù)傳輸節(jié)能Cellular網(wǎng)絡傳輸節(jié)能Wi-Fi網(wǎng)絡傳輸節(jié)能Cellular與Wi-Fi切換節(jié)能定位服務節(jié)能基于移動端能耗優(yōu)化基于云能耗優(yōu)化110數(shù)據(jù)傳輸節(jié)能Cellular網(wǎng)絡傳輸節(jié)能無線資源控制協(xié)議（RRC）完成數(shù)據(jù)傳輸后，移動端從高能耗狀態(tài)轉(zhuǎn)到中間能耗狀態(tài)，即尾能耗狀態(tài)（功率約為高能耗的50%）尾能耗狀態(tài)結(jié)束后進入低能耗狀態(tài)（功率約為該能耗狀態(tài)的1%）數(shù)據(jù)傳輸工程中，過多尾能耗狀態(tài)降低移動端能耗利用率針對尾能耗節(jié)能改變尾能耗時間閾值，減少跳至尾能耗狀態(tài)次數(shù)通過傳輸調(diào)度，減少尾能耗111數(shù)據(jù)傳輸節(jié)能Wi-Fi網(wǎng)絡傳輸節(jié)能Wi-Fi網(wǎng)絡能耗源于CSMA中空閑監(jiān)聽狀態(tài)下的能耗目前能耗優(yōu)化通過睡眠調(diào)度算法減少空閑監(jiān)聽狀態(tài)時間以達到節(jié)能目的Cellular與Wi-Fi切換節(jié)能Wi-Fi網(wǎng)絡的有效傳輸速率大于Cellular網(wǎng)絡切換節(jié)能目標是將負載從Cellular網(wǎng)絡遷移至Wi-Fi網(wǎng)絡112定位服務節(jié)能移動終端能耗優(yōu)化方案基于時間和距離的追蹤EnTracked動態(tài)預測方案EnTracked2軌跡追蹤113EnTracked2策略圖[1]LeonhardiA,RothermelK.AComparisonofProtocolsforUpdatingLocationInformation.SpringerClusterComputing,2001[2]Kj?rgaardM,LangdalJ,GodskT,Toftkj?rT.Entracked:Energy-efficientRobustPositionTrackingforMobileDevices.Mobisys,2009[3]Kj?rgaardM,BhattacharyaS,BlunckH,NurmiP.Energy-efficientTrajectoryTrackingforMobileDevices.Mobisys,2011定位服務節(jié)能基于云的節(jié)能優(yōu)化基于歷史軌跡信息的定位節(jié)能用戶位置和軌跡信息通常被收集并存儲在云端。通過適當?shù)乩迷贫说男畔?，用戶可以以比較節(jié)能的方式獲取位置信息基于計算遷移的定位節(jié)能將定位服務的信號解碼和計算處理遷移至云端服務器基于共享信息的定位節(jié)能通過共享其他設備的位置信息來減少自身的定位開銷114課程大綱移動云計算概述移動云計算關鍵技術計算遷移技術基于移動云的位置服務移動節(jié)能終端技術數(shù)據(jù)中心網(wǎng)絡

數(shù)據(jù)中心概述數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)路性能優(yōu)化發(fā)展趨勢與展望115115數(shù)據(jù)中心概述云計算與移動云計算的基礎設施服務器，數(shù)據(jù)中心網(wǎng)絡數(shù)量和大小呈幾何級數(shù)增長計算資源、存儲資源、網(wǎng)絡資源應用案例科學應用、醫(yī)療保健、電子商務、智能電網(wǎng)、…116數(shù)據(jù)中心概述數(shù)據(jù)中心網(wǎng)絡數(shù)據(jù)中心的通信骨干可擴展性、容錯能力、能源效率以及橫截面帶寬117數(shù)據(jù)中心網(wǎng)絡數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)絡架構(gòu)無線數(shù)據(jù)中心網(wǎng)絡性能優(yōu)化以交換機為核心以服務器為核心混合數(shù)據(jù)中心網(wǎng)絡無線數(shù)據(jù)中心網(wǎng)絡無線信道分配無線鏈路調(diào)度多播傳輸優(yōu)化數(shù)據(jù)冗余消除數(shù)據(jù)中心網(wǎng)絡研究分類交換機為核心的拓撲方案Fat-tree是典型的基于樹狀拓撲的解決方案每臺交換機配備4個端口接入交換機和匯聚交換機被劃分為不同的網(wǎng)絡基本單元塊118Fat-tree拓撲結(jié)構(gòu)[1]Al-Fares,Mohammad,AlexanderLoukissas,AminVahdat.AScalable,CommodityDataCenterNetworkArchitecture.SIGCOMM,

2008交換機為核心的拓撲方案Helios是兩層的多根樹結(jié)構(gòu)所有服務器劃分為集群每個集群中的服務器連

接到接入交換機119[1]Farrington,N,Porter,G,Radhakrishnan,S,Bazzaz,HH,Subramanya,V,Fainman,Y,Papen,G,Vahdat,A.Helios:aHybridElectrical/OpticalSwitchArchitectureforModularDataCenters.SIGCOMM,2010

Helios拓撲結(jié)構(gòu)服務器為核心的拓撲方案DCell

是基于遞歸思想構(gòu)建的拓撲由一個交換機連接若干

個服務器構(gòu)成基礎單元利用多個下層單元按照

完全圖的方式進行連接120[1]Guo,C,Wu,H,Tan,K,Shi,L,Zhang,Y,Lu,S.Dcell:aScalableandFault-tolerantNetworkStructureforDataCenters.SIGCOMM,2008DCell

拓撲結(jié)構(gòu)服務器為核心的拓撲方案BCube是另一種基于遞歸思想構(gòu)建的拓撲結(jié)構(gòu)以一個交換機與若干服務器連接構(gòu)成基礎單元通過額外的交換機匯聚多個低級單元的服務器121BCube拓撲結(jié)構(gòu)[1]Guo,C,Lu,G,Li,D,Wu,H,Zhang,X,Shi,Y,Tian,C,Zhang,Y,Lu,S.BCube:aHighPerformance,Server-centricNetworkArchitectureforModularDataCenters.SIGCOMM,2009無線數(shù)據(jù)中心網(wǎng)絡架構(gòu)新型無線技術為數(shù)據(jù)中心發(fā)展提供了新的機會合理地將每個機架考慮