在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

QUIC通信協議到底講了什么?

jf_uPRfTJDa ? 來源:5G通信 ? 作者:陸營川 ? 2022-12-14 10:24 ? 次閱讀

Labs 導讀

QUIC(Quick UDP Internet Connection)是谷歌制定的一種基于UDP的低時延的互聯網傳輸層協議,很好地解決了當今傳輸層和應用層面臨的各種需求,包括處理更多的連接,低延遲以及安全性保障等,目前QUIC開始了它的標準化過程,已經成為新一代傳輸層協議。

作者:陸營川

單位:中國移動智慧家庭運營中心

Part 01什么是QUIC

QUIC(Quick UDP Internet Connection)是Google提出的一個基于UDP的傳輸協議,因其高效的傳輸效率和多路并發的能力,已經成為下一代互聯網協議HTTP/3的底層傳輸協議,2021年5月IETF公布RFC9000,QUIC規范推出了標準化版本。除了應用于Web領域,它的優勢同樣適用于一些通用的需要低延遲、高吞吐特性的傳輸場景。

從協議棧可以看出:QUIC = HTTP/2 + TLS + UDP

9157dc10-7acf-11ed-8abf-dac502259ad0.png

Part 02為什么要有QUIC

HTTP從最初的HTTP/0.9,經歷了HTTP/1.x,HTTP/2到最新的HTTP/3這幾個大的迭代。在HTTP/3版本之前,HTTP底層都是用TCP傳輸數據,而伴隨著移動互聯網的發展,網絡交互場景越來越豐富并要求及時性,傳統TCP固有的性能瓶頸越來越不能滿足需求,原因有以下幾點:

- 建立連接的握手延遲大

HTTPS包含兩個握手:1)TCP三次握手,1個RTT;2)TLS握手,2個RTT。完整握手總共需要3個RTT,對于直播等需要首幀秒開場景,握手延遲太大。

- 多路復用的隊首阻塞

以HTTP/2多路復用為例,多個數據請求作為不同的流,共用一條TCP連接發送,所有的流應用層都必須按序處理。若某個流的數據丟失,后面其他流的數據都會被阻塞,直到丟失的流數據重傳完成其他流才能被繼續傳輸。即使接收端已經收到之后流的數據包,HTTP協議也不會通知應用層去處理。

- TCP協議的更新滯后

TCP協議實現在操作系統內核內,但是用戶端的操作系統版本升級非常困難,很多老舊的系統還有大量用戶使用,因此TCP協議的一些更新很難被快速推廣。

正是考慮到以上的這些問題,QUIC在應用層之上基于UDP實現丟包恢復,擁塞控制,加解密,多路復用等功能,既能優化握手延遲,同時又完全解決內核協議更新滯后問題。

Part 03QUIC建立連接的過程

QUIC建立連接步驟比較簡單,流程如下:

91759a2a-7acf-11ed-8abf-dac502259ad0.png

1)客戶端發起Inchoate client hello;

2)服務器返回Rejection,包括密鑰交換算法的公鑰信息,算法信息,證書信息等被放到server config中傳給客戶端;

3)客戶端發起client hello,包括客戶端公鑰信息。

此時,雙方各自計算出了對稱密鑰。QUIC的1次RTT建連過程結束,平均只耗時100ms以內。后續發起連接的過程中,一旦客戶端緩存或持久化了server config,就可以復用并結合本地生成的私鑰進行加密數據傳輸,不需要再次握手,從而實現0次RTT建立連接。

Part 04QUIC的優缺點

4.1 QUIC的優勢體現在如下方面:

(1)可擴展性強。更改TCP并不容易,因為其中的中間件抗拒更新,而且TCP 40字節的可選位幾乎全部填滿。TCP沒有任何版本協商(version negotiation)擴展位,相比之下,QUIC有32位,所以它有很多空間部署新版本,廠商也可以利用這些空間定義自己的專屬版本。

(2)用戶空間實現容易。QUIC能夠在應用層實現,與在操作系統內核中實現的TCP相比,它可以更快地進行更新。這進一步提高了QUIC的可擴展性,使得服務可以非常快速地演進,從而新的特性每天都能得到部署。同時它還能在上下文切換時通過調用較少的開銷而實現更高的響應能力。

(3)建立連接更加快速。Web瀏覽特別需要快速建立連接,因為用戶通常會開啟多個、短暫的連接。當使用HTTPS時,TCP在建立連接前,需要“三次握手”以及后續的TLS協議設置。QUIC(基于UDP)不需要三次握手,加上它會在初次握手時交換安全密鑰,從而使它在建立加密連接時速度提升了一倍。

(4)丟包敏感度較低。使用TCP時,如果丟失一個數據包,接下來所有的數據包都會停止傳輸,直到丟失的那個數據包被發送,這種現象被稱為“隊頭阻塞”,它會導致延遲明顯增加。相比之下,QUIC使用的是類似HTTP/2的多路復用模式,可以同時支持多個數據流。如果一個數據流發送錯誤,導致丟包,那么其他數據流會繼續發送數據包,而不會阻塞傳輸。

(5)切換網絡時的性能提升較高。切換網絡時,QUIC可以實現平穩過渡。比如,當你使用家里的Wi-Fi觀看手機上的視頻,然后你走出家門,家里的Wi-Fi便切換到LTE;或者當你一直忙于觀看視頻,在不同的移動基站間移動時;在以上這些場景中,TCP將切斷連接,并通過新的網絡創建新的連接,進而影響到你的觀看體驗,而QUIC則能夠實現無縫連接。

(6)安全性和隱私保護較高。QUIC在傳輸層中內置了加密功能,從而驗證整個負載(包括header)。TCP在header中不包含加密,使它非常容易受到攻擊。QUIC默認支持安全的TLS,意味著端到端完全安全。

4.2 QUIC的劣勢體現在如下方面:

TCP發明時,網絡都是有線連接,而且相當可靠,QUIC對非可靠、無法預測的無線連接進行了改進,但并沒有改變互聯網傳輸的本質,它的局限性導致它只能改變某些特定使用場景。下面列舉了一些額外的QUIC局限性:

(1)遷移app面臨巨大挑戰。將app從HTTP/2遷移到HTTP/3(或者從TCP遷移到UDP)要費很大力氣。整個過程需要將應用層實現和傳輸層實現轉移到UDP,并在服務端和客戶端構建全新的解決方案。這對于流媒體領域中資源相對有限的小廠商而言無疑挑戰重重,同時也解釋了谷歌和微軟這樣的科技巨頭可以率先采用QUIC協議的原因。

(2)采用受限。QUIC的最大問題就是它的采用依然受限。幾乎每個瀏覽器都接受使用QUIC進行簡單的網頁瀏覽,但是除了chromium,沒有瀏覽器將它設置為默認選項。除此之外,在流媒體領域,除了谷歌和Facebook之外,少有公司使用QUIC。只有少數CDN提供商支持QUIC,而其中的一些也只是驗證了QUIC的實現,并沒有為大規模部署準備好。這就帶來了問題:如果你推出了使用multi-CDN并基于QUIC的新服務,那么將只有20%的訪問使用QUIC,因為你無法向用戶證明它對用戶體驗的顯著影響。

(3)QUIC包含TCP回退。QUIC之所以被構建在UDP之上,部分原因是極少有中間件和網絡設備攔截UDP。但確實存在被攔截的風險,所以基于QUIC的app必須設計成能夠回退到TCP,以防萬一。這意味著app(基于QUIC)的開發者要同時開發和維護兩個不同的版本(由于TCP回退和受到限制的采用率),導致他們的負擔很重。好消息是,隨著最新的DEVOPS結構與HTTP的Alt-Svc標簽的使用,支持兩種協議要比以前簡單得多。

(4)無法檢查數據包。網絡防火墻無法解密QUIC流量來檢查數據包,所以潛在的惡意流量非常有可能沒有被標準安全功能檢測出來而進入網絡。因此,思科和Palo Alto Networks等安全廠商通常會在端口80(Web服務器)和443(TSL)攔截QUIC數據包(認為它們包含惡意軟件),迫使客戶端回退使用HTTP/2和TCP協議。但上述操作并不會顯著影響內容用戶體驗,因為正確實現的流媒體服務會默認回退到TCP+TLS,但這種操作可能會阻止率先部署QUIC的想法。只有解決這一挑戰,QUIC才能被各大企業廣泛接受。

Part 05QUIC在實際場景中的使用

5.1QUIC在MQTT通信場景中的應用前景

MQTT是基于TCP的物聯網通信協議,緊湊的報文結構能夠在嚴重受限的硬件設備和低帶寬、高延遲的網絡上實現穩定傳輸;心跳機制、遺囑消息、QoS質量等級等諸多特性能夠應對各種物聯網場景。盡管如此,由于底層TCP傳輸協議限制,某些復雜網絡環境下 MQTT 協議存在固有的弊端:

網絡切換導致經常性連接中斷;

斷網后重新建立連接困難:斷網后操作系統釋放資源較慢,且應用層無法及時感知斷開狀態,重連時Server/Client開銷較大;

弱網環境下數據傳輸受限于擁塞、丟包偵測和重傳機制。

例如車聯網用戶通常會面對類似的問題:車輛可能會運行在山區、礦場、隧道等地方,當進入到信號死角或被動切換基站時會導致連接中斷,頻繁連接中斷與較慢的連接恢復速度會導致用戶體驗變差。在一些對數據傳輸實時性和穩定性要求較高的業務,如L4級別的無人駕駛中,客戶需要花費大量的成本來緩解這一問題。

在上述這類場景中,QUIC低連接開銷和多路徑支持的特性就顯示出了其優勢,基于QUIC 0 RTT/1 RTT重連/新建能力,能夠在弱網與不固定的網絡通路中有效提升用戶體驗。

5.2 QUIC協議在CDN加速方面的應用

傳統CDN會有多級結構,每一級結構會有不同熱度數據。在CDN節點之間有大量的通訊數據,這些數據進行分布式存儲時的路徑對最終CDN服務質量有著非常重要的影響。通常來說影響通訊質量的因素通常會受到緩存業務內容的性質、節點間的網絡連接和Client-server側的傳輸架構和機制的影響。這些層級間的數據拉取性能會直接影響到整體CDN的下發響應速度。通常可以通過TCP優化手段(數據連接池、TCP優化)、緩存數據分塊、高層級向低層次的數據推送、緩存數據預拉取、數據壓縮等手段實現超遠節點之間的進一步傳輸。

在這種情況下,QUIC的優勢就展現出來了。CDN QUIC服務針對業務場景進行了全面優化,包括4個方面:

連接優化0-RTT連接復用率,降低連接的延遲。

加解密優化明文傳輸,可以減少加解密造成的一些影響。

傳輸優化亂序報文緩存,針對特殊數據優先級需求進行調整。

針對線上的不同業務場景調整參數,利用擁塞算法,提升在不同業務場景下的效果。

Part 06總結

本文主要對QUIC協議概念背景以及該協議的優缺點進行了簡要的概述,同時舉例了該協議的應用場景,方便大家對該協議有一個初步的了解。目前該協議大型互聯網公司都有在不同的業務場景中使用,得到了不錯的性能提升。中國移動也在積極探索新技術,用技術改變生活。

審核編輯:湯梓紅

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 通信協議
    +關注

    關注

    28

    文章

    915

    瀏覽量

    40440
  • UDP
    UDP
    +關注

    關注

    0

    文章

    327

    瀏覽量

    34045
  • Quic
    +關注

    關注

    0

    文章

    25

    瀏覽量

    7320

原文標題:QUIC通信協議到底講了什么?

文章出處:【微信號:5G通信,微信公眾號:5G通信】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    關于通信協議的應用問題

    大家好,我想問下有關通信協議的問題;協議,在具體設計或者應用的時候,我們該如何利用協議指導我們的設計呢?比如硬件中的電路如何體現協議的作用?軟件中的程序如何體現
    發表于 01-27 18:25

    CAN通信協議

    CAN通信協議,需要的看看。
    發表于 04-19 17:11

    TCP通信協議-Labview上位機

    現在用單片機進行信息采集,通過GPRS模塊上傳到PC,用Labview做上位機,TCP通信協議,想請教一下,TCP通信協議和Modbus TCP通信協議有什么不同?
    發表于 12-10 08:58

    如何應用mavlink通信協議

    如何應用mavlink通信協議
    發表于 12-20 06:30

    如何實現基礎通信協議的設計?

    常見的通信協議格式是什么?如何實現基礎通信協議的設計?
    發表于 02-14 07:35

    串口通信協議的相關資料分享

    目錄一、串口通信協議1、UART簡介2、 UART通信協議(1)起始位(2)數據幀(3)奇偶校驗位(4)停止位(5)下個起始位(6)波特率二、STM32的USART串口通信(中斷)3、要求2、工程
    發表于 02-22 07:16

    ModBus通信協議.pdf

    ModBus通信協議.pdf
    發表于 04-09 22:24 ?90次下載

    Modbus通信協議教程

    Modbus通信協議教程Modbus通信協議教程Modbus通信協議教程
    發表于 12-08 14:14 ?75次下載

    SCPI通信協議

    SCPI通信協議
    發表于 05-04 17:54 ?180次下載

    ModBus通信協議及編程

    ModBus通信協議及編程。
    發表于 05-11 16:40 ?22次下載

    通信協議的概念

    通信協議是指在通信過程中,為了使得不同設備之間進行有效的數據交換,所約定的一整套規則和標準。通信協議中定義了通信雙方的接口、數據格式、傳輸速率、傳輸控制和數據處理等細節,從而確保了
    發表于 05-06 14:32 ?2216次閱讀

    通信協議的特點

    通信協議的種類和特點目前常見的通信協議主要有:NetBEUI、IPX/SPX、NWLink、TCP/IP,在這幾種協議中用得最多、最為復雜的當然還是TCP/IP協議,最為簡單的是Net
    發表于 05-06 14:57 ?1554次閱讀

    一文讀懂QUIC協議:更快、更穩、更高效的網絡通信

    HTTP/3 是第三個主要版本的 HTTP 協議。與其前任 HTTP/1.1 和 HTTP/2 不同,在 HTTP/3 中,棄用 TCP 協議,改為使用基于 UDP 協議QUIC
    的頭像 發表于 08-24 15:43 ?1810次閱讀
    一文讀懂<b class='flag-5'>QUIC</b><b class='flag-5'>協議</b>:更快、更穩、更高效的網絡<b class='flag-5'>通信</b>

    PROFINET通信協議是什么

    PROFINET通信協議是一種專為工業自動化領域設計的基于以太網的實時通信協議。以下是對PROFINET通信協議的詳細解析,包括其定義、特點、體系結構、工作原理、通信方式、應用領域以及
    的頭像 發表于 09-25 18:13 ?2540次閱讀

    總線通信協議解析及應用

    在現代計算機系統中,總線通信協議扮演著至關重要的角色。它們定義了數據如何在處理器、內存、輸入/輸出設備等組件之間傳輸。 總線通信協議的基本概念 總線通信協議是一組規則,它規定了數據在系統總線上的傳輸
    的頭像 發表于 12-31 10:07 ?216次閱讀
    主站蜘蛛池模板: 亚洲黄网址 | 第九色| zsvdy午夜片 爱爱456高清国语在线456 | 天堂视频在线 | 狠狠婷婷 | 黑人边吃奶边扎下面激情视频 | 五月丁香六月综合缴清无码 | 色优久久 | 亚洲天堂一区二区三区 | 天堂bt在线种子网 | 欧美一级视频精品观看 | 午夜神马福利影院 | 天天综合网天天综合色 | 狠狠操天天操夜夜操 | 2022国产情侣真实露脸在线 | 夜夜爽影院 | 亚洲欧美日韩国产一区二区三区精品 | 午夜影音| 美女 免费 视频 黄的 | 日本一线a视频免费观看 | 亚洲国产一区二区在线 | 在线观看黄日本高清视频 | 免费看黄在线 | 午夜视频观看 | 天堂种子 | 天天做天天添天天谢 | 天天躁狠狠躁狠狠躁夜夜躁 | 色婷婷六月丁香在线观看 | 亚洲影院手机版777点击进入影院 | 日韩午夜 | 天天天综合 | 国产亚洲综合视频 | 深爱五月综合网 | 嫩草网 | 国产精品免费看久久久 | 在线播放免费 | www.夜| 人人狠狠综合88综合久久 | 日鲁夜鲁鲁狠狠综合视频 | free性欧美video69 | 亚洲免费视频网址 |