esb和雲平台區别?衆所周知，QUIC（Quick UDP Internet Connection）是谷歌制定的一種互聯網傳輸層協議，它基于UDP傳輸層協議，同時兼具TCP、TLS、HTTP/2等協議的可靠性與安全性，可以有效減少連接與傳輸延遲，更好地應對當前傳輸層與應用層的挑戰目前阿裡雲CDN線上提供GQUIC版本服務，已經有Tbps級别的流量承載，并對客戶來帶了顯著的延遲收益本文将由低向上分層讨論QUIC協議的特點，今天小編就來聊一聊關于esb和雲平台區别?接下來我們就一起去研究一下吧!

esb和雲平台區别

衆所周知，QUIC（Quick UDP Internet Connection）是谷歌制定的一種互聯網傳輸層協議，它基于UDP傳輸層協議，同時兼具TCP、TLS、HTTP/2等協議的可靠性與安全性，可以有效減少連接與傳輸延遲，更好地應對當前傳輸層與應用層的挑戰。目前阿裡雲CDN線上提供GQUIC版本服務，已經有Tbps級别的流量承載，并對客戶來帶了顯著的延遲收益。本文将由低向上分層讨論QUIC協議的特點。

QUIC協議是一系列協議的集合，主要包括：

• 傳輸協議（Transport）
• 丢包檢測與擁塞控制（Recovery)
• 安全傳輸協議（TLS)
• HTTP3協議
• HTTP頭部壓縮協議（QPACK)
• 負載均衡協議（Load Balance)

本文針對QUIC的系列協議進行科普性簡單介紹，細節讀者仍然需要通讀協議原文。本文基于quic的讨論均基于quic-34系列版本。

QUIC協議類似快遞公司，在收到用戶數據後，将數據打包，傳輸到對端，再進行拆包，将用戶數據交給了最終目标用戶。QUIC是基于UDP協議，實現了類似TCP的可靠傳輸，并在此基礎上，結合HTTP3/QPACK，更好地服務互聯網上海量的HTTP Request/Response需求。如其名發音，QUIC(quick)，其目标就是希望比基于TCP的HTTP交互有更好的體驗。

QUIC/HTTP3的特點：

• 有序傳輸：用Stream的概念，确保數據有序。不同的stream或者packet，不保證有序到達。
• 報文壓縮，提高荷載比率：比如QUIC引入了variable-length integer encoding。又比如引入QPACK進行頭部壓縮
• 可靠傳輸：支持丢包檢測和重傳
• 安全傳輸：TLS 1.3安全協議

QUIC是在UDP的基礎上，構建類似TCP的可靠傳輸協議。HTTP3則在QUIC基礎上完成HTTP事務。網絡總是分層讨論的，在此我們由低向上分層讨論quic協議

• UDP層: 在UDP層傳輸的是UDP報文，此處關注的是UDP報文荷載内容是什麼，以及如何高效發送UDP報文
• Connection層: Connection通過CID來确認唯一連接，connection對packet進行可靠傳輸和安全傳輸
• Stream層: Stream在相應的Connection中，通過StreamID進行唯一流确認，stream對stream frame進行傳輸管理
• HTTP3層：HTTP3建立在QUIC Stream的基礎上，相對于HTTP1.1和HTTP2.0，HTTP3提供更有效率的HTTP事務傳輸。HTTP3中通過QPACK協議進行頭部壓縮

UDP層

本章節讨論QUIC發包的UDP部分的相關問題。

UDP荷載大小

荷載大小受限于3個對象：QUIC協議規定；路徑MTU；終端接受能力1、QUIC不能運行在不支持1200字節的單個UDP傳輸網絡路徑上 QUIC有規定initial包大小不得小于1200，如果數據本身不足1200（比如initial ack)，那麼需要用padding方式至少填充到1200字節

2、QUIC不希望出現IP層分片現象本要求意味着udp交給ip層的數據不會大于1個MTU，假設mtu為1500，ipv4場景下，udp的荷載上限為1472字節（1500-20-8），ipv6下，udp荷載上限為1452（1500-40-8)。QUIC建議使用PMTUD以及DPLPMTUD進行mtu探測。在實戰中，我們建議設置IPv6的MTU為1280，大于這個值，某些網絡會存在丢包現象。

3、終端能接受 transport paraments的max_udp_payload_size(0x03)的是終端接受單個udp包大小的能力，發送端應當遵從這一約定。

UDP荷載内容

UDP荷載内容即為quic協議中的packet。協議規定，如果不超過荷載大小的限制，那麼多個packet可以組成一個udp報文發出去。在quic實現中，如果每個udp報文隻包含一個quic packet，會更容易出現亂序問題。

高效發UDP包

和tcp不同，quic需要在應用層就完成udp數據組裝，且每個udp報文不大于1個mtu，如果不加以優化，比如每個包直接用sendto/sendmsg發送，勢必會造成大量的系統調用，影響吞吐

1、通過sendmmsg接口進行優化，sendmmsg可以将用戶态的多個udp quic包通過一次系統調用發到内核态。内核态對于每個udp quic包獨立作為udp包發出去

2、在1.）解決了系統調用次數問題，開啟GSO可以進步一分包延遲到發給網卡驅動前一刻，可以進一步提高吞吐，降低CPU消耗

3、在2.）的基礎上，現在主流網卡已經支持硬件GSO offload方案，可以進一步提高吞吐，降低cpu消耗

上面介紹的發送方式，事實上可以理解為udp burst發送方式，這帶來了一個問題，擁塞控制需要pacing能力！

Connection層

在我們讨論時，可知1個udp報文裡傳輸的其實是一個或多個quic協議定義的packet。那麼在Connection這一層面，其實是以packet為單位進行管理的。一個packet到來，終端需要解析出目标ConnectionID(DCID)字段，并将該packet交給找到對應的quic connection。一個packet是由header加payload兩部分組成。

connection id

不同于tcp的4元組唯一确認一條連接的方式，QUIC定義了一個和網絡路由無關的ConnectionID來确認唯一連接的。這帶來一個好處，可以在四元組發生變化時（比如nat rebinding或者終端網絡切換wifi->4G)，依然保持連接。當然，雖然連接狀态依然保持，但由于路徑發生變化，擁塞控制也需要能夠及時調整。

packet頭部

IETF的quic header分為兩種類型，long header, short header。其中long header有分為 initial, 0rtt, handshake, retry四種類型。類型的定義可以直接參考rfc文檔，此處不再贅述。

quic規定packet number始終為自增的，就算某個packet的内容為重傳的frame數據，其packet number也必須自增，這相對于TCP來說，帶來一個優點，能夠更加精确的采集到路徑的RTT屬性。

packet number編解碼: packet number是一個0~262 -1的取值範圍，quic為了節約空間，在計算packet number時，引入了unacked的概念，通過截斷（隻保留有效bit位）的方式，隻用了1-4個字節，即可以encode/decode出正确的packet number。rfc文檔中有附錄詳細講解了enc/dec的過程。

packet頭在安全傳輸中是被保護對象，這也意味着在沒有ssl信息的情況下，無法使用wireshake對packet進行時序分析。中間網絡設備也無法向TCP那樣獲得packet number進行亂序重組。

packet荷載

在對packet進行解密，且去除掉packet header後，packet的荷載裡就都是frame了（至少包括1個）。

如果packet的荷載裡，不包括ACK, PADDING, and CONNECTION_CLOSE這種三種類型的幀，那麼這個packet則被定義為ack-eliciting，意味着對端必須對這種packet生成相應的ack通知發送方，以确保數據沒有丢失。

packet的荷載裡frames的類型在多達30種類型，每種類型都有自己的應用場景，如ACK Frame用于可靠傳輸（Recovery)，Crypto用于安全傳輸（TLS握手），Stream Frame用于業務數據傳遞，MAX_DATA/DATA_BLOCKED用于流控，PING Frame可以用于mtu探測，具體描述參考rfc文檔。

安全傳輸

QUIC的安全傳輸依賴TLS1.3，而boringssl是衆多quic實現的依賴庫。協議對Packet的頭部以及荷載均進行了保護（包括packet number）。TLS1.3 0RTT的能力，在提供數據保護的同時，能在第一時間（服務端收到第一個請求報文時）就将Response Header發給客戶端。大大降低了HTTP業務中的首包時間。為了支持0RTT，客戶端需要保存PSK信息，以及部分transport parament信息。

安全傳輸也經常會涉及到性能問題，在目前主流的服務端，AESG由于cpu提供了硬件加速，所以性能表現最好。CHACHA20則需要更多的CPU資源。在短視頻業務上，出于對首幀的要求，通常直接使用明文傳輸。

Transport Paramenter（TP)協商是在安全傳輸的握手階段完成，除了協議規定的TP外，用戶也可以擴展私有TP内容，這一特性帶來了很大的便利，比如：客戶端可以利用tp告知服務端進行明文傳輸。

可靠傳輸

QUIC協議是需要像TCP能夠進行可靠傳輸，所以QUIC單獨有一個rfc描述了丢包檢測和擁塞控制的話題，

丢包檢測：協議利用兩種方式來判斷丢包是否發生：一種是基于ack的檢測，通過time threshold和packet threshold根據已經到達的packet，推斷在此包之前發出去的包是否丢失。第二種，在失去了參考包的情況下，那麼隻能通過PTO的方式來推斷包是否丢失。一般來說，大量被觸發的應該是ACK的檢測方式。如果PTO被大量觸發，會影響發包效率。

擁塞控制：QUIC針對TCP協議中的一些缺陷，專門做了優化。比如始終遞增的packet number，豐富的ack range，host delay計算等。同時tcp的擁塞控制需要内核态實現，而QUIC在用戶态實現，這大大降低了研究高效率的可靠傳輸協議的門檻。Recovery協議中，描述了newReno的實現方式。在GOOGLE chrome中，實現了cubic, bbr, bbrv2，而mvfst項目則更為豐富，包括了ccp, copa協議。

Stream層

stream是一個抽象的概念，它表達了一個有序傳輸的字節流，而這些字節其實就是由Stream Frame排在一起構成。在一個quic connection上，可以同時傳輸多條流。

Stream頭部

在Quic協議裡，stream分為單向流或雙向流，又分為客戶端發起或服務端發起。stream的不同類型定義在HTTP3中得到了充分的利用。

Stream荷載

Stream的荷載即為一系列Stream Frame，通過Stream Frame頭部的Stream ID來确認單個流。在TCP裡，如果一個segment傳遞丢失，那麼後續segment亂序到達，也不會被應用層使用，隻到丢失的segment重傳成功為止，因此TCP實現的HTTP2的多路複用能力受到制約。在QUIC協議中，有序的概念僅維護在單個stream中，stream之間和packet都不要求有序，假設某個packet丢失，隻會影響包含在這個包裡的stream，其他stream仍然可以從後續亂序到達的packet中提取到自己所需要的數據交給應用層。

HTTP3層

stream分類

在引入HTTP3後，stream的單向流類型被擴展成：控制流，Push流和其他保留類型。其中HTTP3的setting則是在控制流中傳輸，而HTTP數據傳輸是在客戶端發起的雙向流中，所以讀者會發現，HTTP數據傳輸的stream id都是模4等于0的。

在引入QPACK後，單向流被進一步擴展了兩個類型，encoder流，decoder流，QPACK中動态表的更新則依賴這兩個流。

QPACK

QPACK的作用是頭部壓縮。類似HPACK，QPACK定義了靜态表，動态表用于頭部索引。靜态表是針對常見的頭部，協議預先定義的。動态表則是在該QUIC Connection服務HTTP過程中，逐漸建立的。QPACK所建立的Encoder/Decoder流是伴随用于HTTP事務的QUIC Connection生命周期。動态表不是HTTP3能夠運行的必須項，所以在某些QUIC開源項目中，并沒有實現複雜的動态表功能。

在QPACK的動态表業務中，數據流，編碼流，解碼流3種對象共同參與，編碼流和解碼流負責維護動态表變化，數據流則解析出頭部的索引号，去動态表中查詢，得到最終的頭部定義。

其他

Flow Control 流控

QUIC協議引入了flow control的概念，用于表達接收端的接受能力。流控分兩級，Connection級别，和Stream級别。發送端發送的數據偏移量不能超過流控的限制，如果達到限制，那麼發送端應該通過 DATA_BLOCKED/STREAM_DATA_BLOCKED來通知接收端。如果為了傳輸性能，接收端應該盡量保持限制足夠大，比如達到max_data的一半時，就及時更新max_data傳給發送端。如果接收端不希望太快接受數據，也可以利用流控對發送端進行約束。

QUIC版本

QUIC一開始由google主導設計開發，在chromium項目中，可以看到google quic(GQUIC)版本号被定義為Q039,Q043,Q046,Q050等。

随着IETF版本的QUIC推出，ietf quic(IQUIC)也有很多版本，如29,30,34(最新版)等，不同版本可能是無法互通的，比如不同版本安全傳輸的salt變量規定不一樣。所以IQUIC引入了版本協商的功能，用于不同的客戶端和服務端協商出可以互通的版本。

在實踐中，還會遇到一個需求，要求一個服務能夠同時服務GQUIC的不同版本，又能服務IQUIC的不同版本。這就要求服務在收取到packet後，需要對packet作出判斷，分析出它屬于iquic的，還是gquic的，然後進行邏輯分流。

目前阿裡雲CDN線上提供GQUIC版本服務，适用的産品包含靜态内容分發（圖片小文件、大文件下載、視音頻點播）和動态内容分發（全站加速）。用戶隻需在CDN、全站加速控制台對域名開啟【QUIC協議開關】功能，支持QUIC協議的客戶端即可通過QUIC協議與阿裡雲CDN節點通信。

QUIC應用場景

圖片小文件：明顯降低文件下載總耗時，提升效率視頻點播：提升首屏秒開率，降低卡頓率，提升用戶觀看體驗動态請求：适用于動态請求，提升訪問速度，如網頁登錄、交易等交互體驗提升弱網環境：在丢包和網絡延遲嚴重的情況下仍可提供可用的服務，并優化卡頓率、請求失敗率、秒開率、提高連接成功率等傳輸指标大并發連接：連接可靠性強，支持頁面資源數較多、并發連接數較多情況下的訪問速率提升加密連接：具備安全、可靠的傳輸性能

關于QUIC協議，目前阿裡雲CDN線上的QUIC已經有了Tbps級别的大流量驗證，并為客戶來帶了顯著的延遲收益。随着IETF标準的QUIC協議完善，阿裡雲也會盡快推出ietf quic服務，我們相信QUIC未來會成為互聯網流量的主力成員。

作者：黎叔

本文為阿裡雲原創内容，未經允許不得轉載。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!