DASH over QUIC的研究與設計
發(fā)布時間:2021-04-09 07:08
QUIC協(xié)議的出現(xiàn)為僵化的傳輸層協(xié)議帶來了新生,QUIC減少了握手時間,改進了擁塞控制機制,避免了隊頭阻塞,支持連接遷移。較TCP,QUIC擁有更優(yōu)的傳輸效果。DASH是基于HTTP的自適應傳輸協(xié)議,位于應用層,在TCP上傳輸,是目前廣為應用的流媒體技術,最大的特點是支持碼率自適應。QUIC具有上述眾多優(yōu)秀的特性,QUIC能否為DASH提供較TCP更優(yōu)異的性能表現(xiàn)是本論文的研究重點。因此本論文將通過搭建DASH over QUIC性能測試系統(tǒng)對比DASH運行在QUIC及TCP上的效果。DASH over QUIC性能測試系統(tǒng)由支持QUIC/TCP切換的服務器、支持QUIC/TCP連接協(xié)商的DASH客戶端和網絡可控的無線接入點組成。實驗中通過網絡可控無線接入點的設置保證客戶端連接網絡環(huán)境一致,設置固定帶寬和可變帶寬分別測試DASH在TCP與QUIC上的關鍵性能指標。測試結果顯示DASH在QUIC上運行效果差于在TCP上運行效果。本論文首先介紹了選題背景及意義,總結了QUIC協(xié)議的研究現(xiàn)狀。然后對本論文涉及的相關技術進行介紹,包括QUIC協(xié)議和DASH協(xié)議的相關技術。然后本論文給出了基于D...
【文章來源】:北京郵電大學北京市 211工程院校 教育部直屬院校
【文章頁數(shù)】:89 頁
【學位級別】:碩士
【部分圖文】:
一ITCP+TLS+HTTP尼和QUIC十Hl…TP/2的協(xié)議體系
QUIC是Google開發(fā)的基于UDP的多路復用且安全的傳輸協(xié)議。??QUIC在OSI中處于網絡層之上,跨傳輸層、會話層、表示層和應用層,如??圖2-1所示。??⑷?(b)??Applicaiton?Layer?HTTP/2?HTTP/2?over?QUIC??????QUIC??Piesentation?Layei?|?Multistreaming?丨?丨?Multistreaming?|??Session?Layer??TLS?1.2?TLS?1.3?key?negotiation??Congestion?Control?Congestion?Control??Transport?Layer??Loss?recovery???Lossrecoveiy???TCP?UDP??Network?Layer?ip?jp??圖?2-1?TCP?+?TLS?+?HTTP/2?和?QUIC?+?HTTP/2?的協(xié)議體系??(a)?TCP?+?TLS?+?HTTP/2??(b)?QUIC?+?HTTP/2??自下而上來看,QUIC協(xié)議底層通過UDP協(xié)議替代了?TCP,并實現(xiàn)TCP具??有的擁塞控制以及丟包恢復功能。QUIC協(xié)議內置TLS棧,實現(xiàn)其自帶加密協(xié)??議,無需使用現(xiàn)有的TLS?1.2,同時QUIC協(xié)議實現(xiàn)了?HTTP/2中的多路復用和??連接管理功能,QUIC協(xié)議之上的應用層的HTTP/2只需要完成HTTP協(xié)議解析??即可。??QUIC與現(xiàn)有TCP?+?TLS?+?HTTP/2方案相比,QUIC協(xié)議基于UDP實現(xiàn)??可完全運行于用戶空間而非系統(tǒng)內核
次僅能請求一個資源的問題。盡管從邏輯上來說HTTP/2實現(xiàn)了不同流之間的相??互獨立,但在實際傳輸上,數(shù)據(jù)仍需一幀一幀地傳送,一旦某個流發(fā)生丟包,將??會阻塞在他之后的幀的傳輸,即隊頭阻塞問題。如圖2-4所示,即便流間的數(shù)據(jù)??是相互獨立的,但所有在一個TCP連接上傳輸?shù)臄?shù)據(jù)仍然是按序交付給應用層。??因此一個流的數(shù)據(jù)包丟失將導致其他流上的數(shù)據(jù)由于隊頭阻塞而無法成功接收??數(shù)據(jù)。????廣—Requests????HTTP??\?^——?廣?HTTP??Client?卜_〔?Internet」^)]?Server??TCP?Connection??圖2-4基于TCP的多路復用??QUIC是基于UDP的傳輸層協(xié)議,由于UDP不需要保證包的時序,一個??QUIC數(shù)據(jù)包可以攜帶同一個流或者不同流的多個幀,如圖2-5所示。同一個流??的幀按序交付,但一個流的幀丟失不會阻塞其他流的幀傳輸。因此QUIC解決了??隊頭阻塞的問題,實現(xiàn)了不同流之間真正的獨立傳輸。??f、?Requests??7?\Am?ra?.?ra,、'?_??QUIC?Internet? ̄H ̄P?Server??Client?yTiT?a?al?:??^^?UDP?Connection??圖2-5基于QUIC的多路復用??8??
本文編號:3127167
【文章來源】:北京郵電大學北京市 211工程院校 教育部直屬院校
【文章頁數(shù)】:89 頁
【學位級別】:碩士
【部分圖文】:
一ITCP+TLS+HTTP尼和QUIC十Hl…TP/2的協(xié)議體系
QUIC是Google開發(fā)的基于UDP的多路復用且安全的傳輸協(xié)議。??QUIC在OSI中處于網絡層之上,跨傳輸層、會話層、表示層和應用層,如??圖2-1所示。??⑷?(b)??Applicaiton?Layer?HTTP/2?HTTP/2?over?QUIC??????QUIC??Piesentation?Layei?|?Multistreaming?丨?丨?Multistreaming?|??Session?Layer??TLS?1.2?TLS?1.3?key?negotiation??Congestion?Control?Congestion?Control??Transport?Layer??Loss?recovery???Lossrecoveiy???TCP?UDP??Network?Layer?ip?jp??圖?2-1?TCP?+?TLS?+?HTTP/2?和?QUIC?+?HTTP/2?的協(xié)議體系??(a)?TCP?+?TLS?+?HTTP/2??(b)?QUIC?+?HTTP/2??自下而上來看,QUIC協(xié)議底層通過UDP協(xié)議替代了?TCP,并實現(xiàn)TCP具??有的擁塞控制以及丟包恢復功能。QUIC協(xié)議內置TLS棧,實現(xiàn)其自帶加密協(xié)??議,無需使用現(xiàn)有的TLS?1.2,同時QUIC協(xié)議實現(xiàn)了?HTTP/2中的多路復用和??連接管理功能,QUIC協(xié)議之上的應用層的HTTP/2只需要完成HTTP協(xié)議解析??即可。??QUIC與現(xiàn)有TCP?+?TLS?+?HTTP/2方案相比,QUIC協(xié)議基于UDP實現(xiàn)??可完全運行于用戶空間而非系統(tǒng)內核
次僅能請求一個資源的問題。盡管從邏輯上來說HTTP/2實現(xiàn)了不同流之間的相??互獨立,但在實際傳輸上,數(shù)據(jù)仍需一幀一幀地傳送,一旦某個流發(fā)生丟包,將??會阻塞在他之后的幀的傳輸,即隊頭阻塞問題。如圖2-4所示,即便流間的數(shù)據(jù)??是相互獨立的,但所有在一個TCP連接上傳輸?shù)臄?shù)據(jù)仍然是按序交付給應用層。??因此一個流的數(shù)據(jù)包丟失將導致其他流上的數(shù)據(jù)由于隊頭阻塞而無法成功接收??數(shù)據(jù)。????廣—Requests????HTTP??\?^——?廣?HTTP??Client?卜_〔?Internet」^)]?Server??TCP?Connection??圖2-4基于TCP的多路復用??QUIC是基于UDP的傳輸層協(xié)議,由于UDP不需要保證包的時序,一個??QUIC數(shù)據(jù)包可以攜帶同一個流或者不同流的多個幀,如圖2-5所示。同一個流??的幀按序交付,但一個流的幀丟失不會阻塞其他流的幀傳輸。因此QUIC解決了??隊頭阻塞的問題,實現(xiàn)了不同流之間真正的獨立傳輸。??f、?Requests??7?\Am?ra?.?ra,、'?_??QUIC?Internet? ̄H ̄P?Server??Client?yTiT?a?al?:??^^?UDP?Connection??圖2-5基于QUIC的多路復用??8??
本文編號:3127167
本文鏈接:http://sikaile.net/kejilunwen/ruanjiangongchenglunwen/3127167.html
最近更新
教材專著