去年的這個時候，國內(nèi)的 web 網(wǎng)絡環(huán)境開始普及和部署 HTTP/2. 時隔一年，HTTP/2 的普及程度有了顯著提升，而各大

可以近似的認為 QUIC over UDP 將成為下一代(或替代)TLS over TCP. 也就是說， QUIC 將能應用于任何應用層協(xié)議中，只是當前階段將優(yōu)先在 HTTP 中進行應用和驗證。

統(tǒng)一使用 TLS 1.3 作為安全協(xié)議

2018年，有幾個重要的WEB標準終于塵埃落定，其中一個便是 RFC 8446 TLS 1.3. 這個標準對于降低延遲，改善用戶體驗，尤其是移動端的體驗有非常重要的意義。在雖然 TLS 1.3和 QUIC 都能做到 0-RTT，從而降低延遲，但是 QUIC 卻自顧自地實現(xiàn)了一套安全協(xié)議。主要是因為當時 TLS 1.3 標準還沒有發(fā)布，而 QUIC 又需要一套安全協(xié)議：

The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.

如今，TLS 1.3 標準已經(jīng)發(fā)布，而 HTTP/3 也納入 IETF，因此 QUIC 也就順理成章的使用 TLS 1.3 作為其安全協(xié)議。Google 在這些方面倒是從來都不雞賊和墨跡，點贊。

使用 QHPACK 頭部壓縮代替 HPACK

其實，QPACK與HPACK的設計非常類似，單獨提出QPACK主要是更好的適配QUIC，同時也是 Google 將 QUIC 從與 HTTP/2 的耦合中抽離出來，與 IETF 標準完成統(tǒng)一的必要一步。

HTTP/3 問題與挑戰(zhàn)

UDP 連通性問題

幾乎所有的電信運營商都會“歧視” UDP 數(shù)據(jù)包，原因也很容易理解，畢竟歷史上幾次臭名昭著的 DDoS 攻擊都是基于 UDP 的。國內(nèi)某城寬帶在某些區(qū)域更是直接禁止了非53端口的UDP數(shù)據(jù)包，而其他運營商及IDC即使沒有封禁UDP，也是對UDP進行嚴格限流的。這點上不太樂觀，但是我們相信隨著標準的普及和推廣落地，運營商會逐步改變對UDP流量的歧視策略。國外的情況會稍好一些，根據(jù)Google的數(shù)據(jù)，他們部署的QUIC降級的比例不到10%。

QUIC 不支持明文傳輸

對于用戶來說，這是一個優(yōu)勢，并不是問題。對于國內(nèi)內(nèi)容審查環(huán)境來說是個不可忽視的坎。但QUIC以后畢竟也是基于TLS協(xié)議的，國內(nèi)HTTPS都能普及下來，QUIC的普及也許會更樂觀一些。

UDP 消耗資源多

當前階段，UDP消耗的CPU資源多，且處理速度慢。這是不爭的事實，但是我相信隨著UDP應用的增多，內(nèi)核和硬件的優(yōu)化一定會跟上，直至達到或超過TCP的性能。而 QUIC 因為實在應用層實現(xiàn)，因此迭代速度更快，部署和更新難度和代價更小，能夠一定程度緩解如TCP那樣的協(xié)議僵化問題。

分享文章：HTTP2還沒上手，HTTP3就要來了
網(wǎng)頁網(wǎng)址：http://jinyejixie.com/news36/98186.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、品牌網(wǎng)站制作、搜索引擎優(yōu)化、全網(wǎng)營銷推廣、網(wǎng)頁設計公司、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)