?

2015 年 HTTP/2 標(biāo)準(zhǔn)發(fā)表后，大多數(shù)主流瀏覽器也于當(dāng)年年底支持該標(biāo)準(zhǔn)。此后，憑借著多路復(fù)用、頭部壓縮、服務(wù)器推送等優(yōu)勢(shì)，HTTP/2 得到了越來(lái)越多開發(fā)者的青睞，不知不覺的 HTTP 已經(jīng)發(fā)展到了第三代。本文基于興趣部落接入 HTTP/3 的實(shí)踐，聊一聊 HTTP/3 的原理以及業(yè)務(wù)接入的方式。

1. HTTP/3 原理

1.1 HTTP 歷史

在介紹 HTTP/3 之前，我們先簡(jiǎn)單看下 HTTP 的歷史，了解下 HTTP/3 出現(xiàn)的背景。

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，1999 年設(shè)計(jì)的 HTTP/1.1 已經(jīng)不能滿足需求，所以 Google 在 2009 年設(shè)計(jì)了基于 TCP 的 SPDY，后來(lái) SPDY 的開發(fā)組推動(dòng) SPDY 成為正式標(biāo)準(zhǔn)，不過(guò)最終沒能通過(guò)。不過(guò) SPDY 的開發(fā)組全程參與了 HTTP/2 的制定過(guò)程，參考了 SPDY 的很多設(shè)計(jì)，所以我們一般認(rèn)為 SPDY 就是 HTTP/2 的前身。無(wú)論 SPDY 還是 HTTP/2，都是基于 TCP 的，TCP 與 UDP 相比效率上存在天然的劣勢(shì)，所以 2013 年 Google 開發(fā)了基于 UDP 的名為 QUIC 的傳輸層協(xié)議，QUIC 全稱 Quick UDP Internet Connections，希望它能替代 TCP，使得網(wǎng)頁(yè)傳輸更加高效。后經(jīng)提議，互聯(lián)網(wǎng)工程任務(wù)組正式將基于 QUIC 協(xié)議的 HTTP （HTTP over QUIC）重命名為 HTTP/3。

1.2 QUIC 協(xié)議概覽

TCP 一直是傳輸層中舉足輕重的協(xié)議，而 UDP 則默默無(wú)聞，在面試中問(wèn)到 TCP 和 UDP 的區(qū)別時(shí)，有關(guān) UDP 的回答常常寥寥幾語(yǔ)，長(zhǎng)期以來(lái) UDP 給人的印象就是一個(gè)很快但不可靠的傳輸層協(xié)議。但有時(shí)候從另一個(gè)角度看，缺點(diǎn)可能也是優(yōu)點(diǎn)。QUIC（Quick UDP Internet Connections，快速 UDP 網(wǎng)絡(luò)連接） 基于 UDP，正是看中了 UDP 的速度與效率。同時(shí) QUIC 也整合了 TCP、TLS 和 HTTP/2 的優(yōu)點(diǎn)，并加以優(yōu)化。用一張圖可以清晰地表示他們之間的關(guān)系。

那 QUIC 和 HTTP/3 什么關(guān)系呢？QUIC 是用來(lái)替代 TCP、SSL/TLS 的傳輸層協(xié)議，在傳輸層之上還有應(yīng)用層，我們熟知的應(yīng)用層協(xié)議有 HTTP、FTP、IMAP 等，這些協(xié)議理論上都可以運(yùn)行在 QUIC 之上，其中運(yùn)行在 QUIC 之上的 HTTP 協(xié)議被稱為 HTTP/3，這就是”HTTP over QUIC 即 HTTP/3“的含義。

因此想要了解 HTTP/3，QUIC 是繞不過(guò)去的，下面主要通過(guò)幾個(gè)重要的特性讓大家對(duì) QUIC 有更深的理解。

1.3 零 RTT 建立連接

用一張圖可以形象地看出 HTTP/2 和 HTTP/3 建立連接的差別。

HTTP/2 的連接需要 3 RTT，如果考慮會(huì)話復(fù)用，即把第一次握手算出來(lái)的對(duì)稱密鑰緩存起來(lái)，那么也需要 2 RTT，更進(jìn)一步的，如果 TLS 升級(jí)到 1.3，那么 HTTP/2 連接需要 2 RTT，考慮會(huì)話復(fù)用則需要 1 RTT。有人會(huì)說(shuō) HTTP/2 不一定需要 HTTPS，握手過(guò)程還可以簡(jiǎn)化。這沒毛病，HTTP/2 的標(biāo)準(zhǔn)的確不需要基于 HTTPS，但實(shí)際上所有瀏覽器的實(shí)現(xiàn)都要求 HTTP/2 必須基于 HTTPS，所以 HTTP/2 的加密連接必不可少。而 HTTP/3 首次連接只需要 1 RTT，后面的連接更是只需 0 RTT，意味著客戶端發(fā)給服務(wù)端的第一個(gè)包就帶有請(qǐng)求數(shù)據(jù)，這一點(diǎn) HTTP/2 難以望其項(xiàng)背。那這背后是什么原理呢？我們具體看下 QUIC 的連接過(guò)程。

Step1：首次連接時(shí)，客戶端發(fā)送 Inchoate Client Hello 給服務(wù)端，用于請(qǐng)求連接；

Step2：服務(wù)端生成 g、p、a，根據(jù) g、p 和 a 算出 A，然后將 g、p、A 放到 Server Config 中再發(fā)送 Rejection 消息給客戶端；

Step3：客戶端接收到 g、p、A 后，自己再生成 b，根據(jù) g、p、b 算出 B，根據(jù) A、p、b 算出初始密鑰 K。B 和 K 算好后，客戶端會(huì)用 K 加密 HTTP 數(shù)據(jù)，連同 B 一起發(fā)送給服務(wù)端；

Step4：服務(wù)端接收到 B 后，根據(jù) a、p、B 生成與客戶端同樣的密鑰，再用這密鑰解密收到的 HTTP 數(shù)據(jù)。為了進(jìn)一步的安全（前向安全性），服務(wù)端會(huì)更新自己的隨機(jī)數(shù) a 和公鑰，再生成新的密鑰 S，然后把公鑰通過(guò) Server Hello 發(fā)送給客戶端。連同 Server Hello 消息，還有 HTTP 返回?cái)?shù)據(jù)；

Step5：客戶端收到 Server Hello 后，生成與服務(wù)端一致的新密鑰 S，后面的傳輸都使用 S 加密。

這樣，QUIC 從請(qǐng)求連接到正式接發(fā) HTTP 數(shù)據(jù)一共花了 1 RTT，這 1 個(gè) RTT 主要是為了獲取 Server Config，后面的連接如果客戶端緩存了 Server Config，那么就可以直接發(fā)送 HTTP 數(shù)據(jù)，實(shí)現(xiàn) 0 RTT 建立連接。

這里使用的是 DH 密鑰交換算法，DH 算法的核心就是服務(wù)端生成 a、g、p 3 個(gè)隨機(jī)數(shù)，a 自己持有，g 和 p 要傳輸給客戶端，而客戶端會(huì)生成 b 這 1 個(gè)隨機(jī)數(shù)，通過(guò) DH 算法客戶端和服務(wù)端可以算出同樣的密鑰。在這過(guò)程中 a 和 b 并不參與網(wǎng)絡(luò)傳輸，安全性大大提高。因?yàn)?p 和 g 是大數(shù)，所以即使在網(wǎng)絡(luò)中傳輸?shù)?p、g、A、B 都被劫持，那么靠現(xiàn)在的計(jì)算機(jī)算力也沒法破解密鑰。

1.4 連接遷移

TCP 連接基于四元組（源 IP、源端口、目的 IP、目的端口），切換網(wǎng)絡(luò)時(shí)至少會(huì)有一個(gè)因素發(fā)生變化，導(dǎo)致連接發(fā)生變化。當(dāng)連接發(fā)生變化時(shí)，如果還使用原來(lái)的 TCP 連接，則會(huì)導(dǎo)致連接失敗，就得等原來(lái)的連接超時(shí)后重新建立連接，所以我們有時(shí)候發(fā)現(xiàn)切換到一個(gè)新網(wǎng)絡(luò)時(shí)，即使新網(wǎng)絡(luò)狀況良好，但內(nèi)容還是需要加載很久。如果實(shí)現(xiàn)得好，當(dāng)檢測(cè)到網(wǎng)絡(luò)變化時(shí)立刻建立新的 TCP 連接，即使這樣，建立新的連接還是需要幾百毫秒的時(shí)間。

QUIC 的連接不受四元組的影響，當(dāng)這四個(gè)元素發(fā)生變化時(shí)，原連接依然維持。那這是怎么做到的呢？道理很簡(jiǎn)單，QUIC 連接不以四元組作為標(biāo)識(shí)，而是使用一個(gè) 64 位的隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)被稱為 Connection ID，即使 IP 或者端口發(fā)生變化，只要 Connection ID 沒有變化，那么連接依然可以維持。

1.5 隊(duì)頭阻塞/多路復(fù)用

HTTP/1.1 和 HTTP/2 都存在隊(duì)頭阻塞問(wèn)題（Head of line blocking），那什么是隊(duì)頭阻塞呢？

TCP 是個(gè)面向連接的協(xié)議，即發(fā)送請(qǐng)求后需要收到 ACK 消息，以確認(rèn)對(duì)方已接收到數(shù)據(jù)。如果每次請(qǐng)求都要在收到上次請(qǐng)求的 ACK 消息后再請(qǐng)求，那么效率無(wú)疑很低。后來(lái) HTTP/1.1 提出了 Pipelining 技術(shù)，允許一個(gè) TCP 連接同時(shí)發(fā)送多個(gè)請(qǐng)求，這樣就大大提升了傳輸效率。

在這個(gè)背景下，下面就來(lái)談 HTTP/1.1 的隊(duì)頭阻塞。下圖中，一個(gè) TCP 連接同時(shí)傳輸 10 個(gè)請(qǐng)求，其中第 1、2、3 個(gè)請(qǐng)求已被客戶端接收，但第 4 個(gè)請(qǐng)求丟失，那么后面第 5 - 10 個(gè)請(qǐng)求都被阻塞，需要等第 4 個(gè)請(qǐng)求處理完畢才能被處理，這樣就浪費(fèi)了帶寬資源。

因此，HTTP 一般又允許每個(gè)主機(jī)建立 6 個(gè) TCP 連接，這樣可以更加充分地利用帶寬資源，但每個(gè)連接中隊(duì)頭阻塞的問(wèn)題還是存在。

HTTP/2 的多路復(fù)用解決了上述的隊(duì)頭阻塞問(wèn)題。不像 HTTP/1.1 中只有上一個(gè)請(qǐng)求的所有數(shù)據(jù)包被傳輸完畢下一個(gè)請(qǐng)求的數(shù)據(jù)包才可以被傳輸，HTTP/2 中每個(gè)請(qǐng)求都被拆分成多個(gè) Frame 通過(guò)一條 TCP 連接同時(shí)被傳輸，這樣即使一個(gè)請(qǐng)求被阻塞，也不會(huì)影響其他的請(qǐng)求。如下圖所示，不同顏色代表不同的請(qǐng)求，相同顏色的色塊代表請(qǐng)求被切分的 Frame。

事情還沒完，HTTP/2 雖然可以解決“請(qǐng)求”這個(gè)粒度的阻塞，但 HTTP/2 的基礎(chǔ) TCP 協(xié)議本身卻也存在著隊(duì)頭阻塞的問(wèn)題。HTTP/2 的每個(gè)請(qǐng)求都會(huì)被拆分成多個(gè) Frame，不同請(qǐng)求的 Frame 組合成 Stream，Stream 是 TCP 上的邏輯傳輸單元，這樣 HTTP/2 就達(dá)到了一條連接同時(shí)發(fā)送多條請(qǐng)求的目標(biāo)，這就是多路復(fù)用的原理。我們看一個(gè)例子，在一條 TCP 連接上同時(shí)發(fā)送 4 個(gè) Stream，其中 Stream1 已正確送達(dá)，Stream2 中的第 3 個(gè) Frame 丟失，TCP 處理數(shù)據(jù)時(shí)有嚴(yán)格的前后順序，先發(fā)送的 Frame 要先被處理，這樣就會(huì)要求發(fā)送方重新發(fā)送第 3 個(gè) Frame，Stream3 和 Stream4 雖然已到達(dá)但卻不能被處理，那么這時(shí)整條連接都被阻塞。

不僅如此，由于 HTTP/2 必須使用 HTTPS，而 HTTPS 使用的 TLS 協(xié)議也存在隊(duì)頭阻塞問(wèn)題。TLS 基于 Record 組織數(shù)據(jù)，將一堆數(shù)據(jù)放在一起（即一個(gè) Record）加密，加密完后又拆分成多個(gè) TCP 包傳輸。一般每個(gè) Record 16K，包含 12 個(gè) TCP 包，這樣如果 12 個(gè) TCP 包中有任何一個(gè)包丟失，那么整個(gè) Record 都無(wú)法解密。

隊(duì)頭阻塞會(huì)導(dǎo)致 HTTP/2 在更容易丟包的弱網(wǎng)絡(luò)環(huán)境下比 HTTP/1.1 更慢！

那 QUIC 是如何解決隊(duì)頭阻塞問(wèn)題的呢？主要有兩點(diǎn)。

• QUIC 的傳輸單元是 Packet，加密單元也是 Packet，整個(gè)加密、傳輸、解密都基于 Packet，這樣就能避免 TLS 的隊(duì)頭阻塞問(wèn)題；

• QUIC 基于 UDP，UDP 的數(shù)據(jù)包在接收端沒有處理順序，即使中間丟失一個(gè)包，也不會(huì)阻塞整條連接，其他的資源會(huì)被正常處理。

1.6 擁塞控制

擁塞控制的目的是避免過(guò)多的數(shù)據(jù)一下子涌入網(wǎng)絡(luò)，導(dǎo)致網(wǎng)絡(luò)超出最大負(fù)荷。QUIC 的擁塞控制與 TCP 類似，并在此基礎(chǔ)上做了改進(jìn)。所以我們先簡(jiǎn)單介紹下 TCP 的擁塞控制。

TCP 擁塞控制由 4 個(gè)核心算法組成：慢啟動(dòng)、擁塞避免、快速重傳和快速恢復(fù)，理解了這 4 個(gè)算法，對(duì) TCP 的擁塞控制也就有了大概了解。

• 慢啟動(dòng)：發(fā)送方向接收方發(fā)送 1 個(gè)單位的數(shù)據(jù)，收到對(duì)方確認(rèn)后會(huì)發(fā)送 2 個(gè)單位的數(shù)據(jù)，然后依次是 4 個(gè)、8 個(gè)……呈指數(shù)級(jí)增長(zhǎng)，這個(gè)過(guò)程就是在不斷試探網(wǎng)絡(luò)的擁塞程度，超出閾值則會(huì)導(dǎo)致網(wǎng)絡(luò)擁塞；

• 擁塞避免：指數(shù)增長(zhǎng)不可能是無(wú)限的，到達(dá)某個(gè)限制（慢啟動(dòng)閾值）之后，指數(shù)增長(zhǎng)變?yōu)榫€性增長(zhǎng)；

• 快速重傳：發(fā)送方每一次發(fā)送時(shí)都會(huì)設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，超時(shí)后即認(rèn)為丟失，需要重發(fā)；

• 快速恢復(fù)：在上面快速重傳的基礎(chǔ)上，發(fā)送方重新發(fā)送數(shù)據(jù)時(shí)，也會(huì)啟動(dòng)一個(gè)超時(shí)定時(shí)器，如果收到確認(rèn)消息則進(jìn)入擁塞避免階段，如果仍然超時(shí)，則回到慢啟動(dòng)階段。

QUIC 重新實(shí)現(xiàn)了 TCP 協(xié)議的 Cubic 算法進(jìn)行擁塞控制，并在此基礎(chǔ)上做了不少改進(jìn)。下面介紹一些 QUIC 改進(jìn)的擁塞控制的特性。

1.6.1 熱插拔

TCP 中如果要修改擁塞控制策略，需要在系統(tǒng)層面進(jìn)行操作。QUIC 修改擁塞控制策略只需要在應(yīng)用層操作，并且 QUIC 會(huì)根據(jù)不同的網(wǎng)絡(luò)環(huán)境、用戶來(lái)動(dòng)態(tài)選擇擁塞控制算法。

1.6.2 前向糾錯(cuò) FEC

QUIC 使用前向糾錯(cuò)(FEC，Forward Error Correction)技術(shù)增加協(xié)議的容錯(cuò)性。一段數(shù)據(jù)被切分為 10 個(gè)包后，依次對(duì)每個(gè)包進(jìn)行異或運(yùn)算，運(yùn)算結(jié)果會(huì)作為 FEC 包與數(shù)據(jù)包一起被傳輸，如果不幸在傳輸過(guò)程中有一個(gè)數(shù)據(jù)包丟失，那么就可以根據(jù)剩余 9 個(gè)包以及 FEC 包推算出丟失的那個(gè)包的數(shù)據(jù)，這樣就大大增加了協(xié)議的容錯(cuò)性。

這是符合現(xiàn)階段網(wǎng)絡(luò)技術(shù)的一種方案，現(xiàn)階段帶寬已經(jīng)不是網(wǎng)絡(luò)傳輸?shù)钠款i，往返時(shí)間才是，所以新的網(wǎng)絡(luò)傳輸協(xié)議可以適當(dāng)增加數(shù)據(jù)冗余，減少重傳操作。

1.6.3 單調(diào)遞增的 Packet Number

TCP 為了保證可靠性，使用 Sequence Number 和 ACK 來(lái)確認(rèn)消息是否有序到達(dá)，但這樣的設(shè)計(jì)存在缺陷。

超時(shí)發(fā)生后客戶端發(fā)起重傳，后來(lái)接收到了 ACK 確認(rèn)消息，但因?yàn)樵颊?qǐng)求和重傳請(qǐng)求接收到的 ACK 消息一樣，所以客戶端就郁悶了，不知道這個(gè) ACK 對(duì)應(yīng)的是原始請(qǐng)求還是重傳請(qǐng)求。如果客戶端認(rèn)為是原始請(qǐng)求的 ACK，但實(shí)際上是左圖的情形，則計(jì)算的采樣 RTT 偏大；如果客戶端認(rèn)為是重傳請(qǐng)求的 ACK，但實(shí)際上是右圖的情形，又會(huì)導(dǎo)致采樣 RTT 偏小。圖中有幾個(gè)術(shù)語(yǔ)，RTO 是指超時(shí)重傳時(shí)間（Retransmission TimeOut），跟我們熟悉的 RTT（Round Trip Time，往返時(shí)間）很長(zhǎng)得很像。采樣 RTT 會(huì)影響 RTO 計(jì)算，超時(shí)時(shí)間的準(zhǔn)確把握很重要，長(zhǎng)了短了都不合適。

QUIC 解決了上面的歧義問(wèn)題。與 Sequence Number 不同的是，Packet Number 嚴(yán)格單調(diào)遞增，如果 Packet N 丟失了，那么重傳時(shí) Packet 的標(biāo)識(shí)不會(huì)是 N，而是比 N 大的數(shù)字，比如 N + M，這樣發(fā)送方接收到確認(rèn)消息時(shí)就能方便地知道 ACK 對(duì)應(yīng)的是原始請(qǐng)求還是重傳請(qǐng)求。

1.6.4 ACK Delay

TCP 計(jì)算 RTT 時(shí)沒有考慮接收方接收到數(shù)據(jù)到發(fā)送確認(rèn)消息之間的延遲，如下圖所示，這段延遲即 ACK Delay。QUIC 考慮了這段延遲，使得 RTT 的計(jì)算更加準(zhǔn)確。

1.6.5 更多的 ACK 塊

一般來(lái)說(shuō)，接收方收到發(fā)送方的消息后都應(yīng)該發(fā)送一個(gè) ACK 回復(fù)，表示收到了數(shù)據(jù)。但每收到一個(gè)數(shù)據(jù)就返回一個(gè) ACK 回復(fù)太麻煩，所以一般不會(huì)立即回復(fù)，而是接收到多個(gè)數(shù)據(jù)后再回復(fù)，TCP SACK 最多提供 3 個(gè) ACK block。但有些場(chǎng)景下，比如下載，只需要服務(wù)器返回?cái)?shù)據(jù)就好，但按照 TCP 的設(shè)計(jì)，每收到 3 個(gè)數(shù)據(jù)包就要“禮貌性”地返回一個(gè) ACK。而 QUIC 最多可以捎帶 256 個(gè) ACK block。在丟包率比較嚴(yán)重的網(wǎng)絡(luò)下，更多的 ACK block 可以減少重傳量，提升網(wǎng)絡(luò)效率。

1.7 流量控制

TCP 會(huì)對(duì)每個(gè) TCP 連接進(jìn)行流量控制，流量控制的意思是讓發(fā)送方不要發(fā)送太快，要讓接收方來(lái)得及接收，不然會(huì)導(dǎo)致數(shù)據(jù)溢出而丟失，TCP 的流量控制主要通過(guò)滑動(dòng)窗口來(lái)實(shí)現(xiàn)的。可以看出，擁塞控制主要是控制發(fā)送方的發(fā)送策略，但沒有考慮到接收方的接收能力，流量控制是對(duì)這部分能力的補(bǔ)齊。

QUIC 只需要建立一條連接，在這條連接上同時(shí)傳輸多條 Stream，好比有一條道路，兩頭分別有一個(gè)倉(cāng)庫(kù)，道路中有很多車輛運(yùn)送物資。QUIC 的流量控制有兩個(gè)級(jí)別：連接級(jí)別（Connection Level）和 Stream 級(jí)別（Stream Level），好比既要控制這條路的總流量，不要一下子很多車輛涌進(jìn)來(lái)，貨物來(lái)不及處理，也不能一個(gè)車輛一下子運(yùn)送很多貨物，這樣貨物也來(lái)不及處理。

那 QUIC 是怎么實(shí)現(xiàn)流量控制的呢？我們先看單條 Stream 的流量控制。Stream 還沒傳輸數(shù)據(jù)時(shí)，接收窗口（flow control receive window）就是最大接收窗口（flow control receive window），隨著接收方接收到數(shù)據(jù)后，接收窗口不斷縮小。在接收到的數(shù)據(jù)中，有的數(shù)據(jù)已被處理，而有的數(shù)據(jù)還沒來(lái)得及被處理。如下圖所示，藍(lán)色塊表示已處理數(shù)據(jù)，黃色塊表示未處理數(shù)據(jù)，這部分?jǐn)?shù)據(jù)的到來(lái)，使得 Stream 的接收窗口縮小。

隨著數(shù)據(jù)不斷被處理，接收方就有能力處理更多數(shù)據(jù)。當(dāng)滿足 (flow control receive offset - consumed bytes) < (max receive window / 2) 時(shí)，接收方會(huì)發(fā)送 WINDOW_UPDATE frame 告訴發(fā)送方你可以再多發(fā)送些數(shù)據(jù)過(guò)來(lái)。這時(shí) flow control receive offset 就會(huì)偏移，接收窗口增大，發(fā)送方可以發(fā)送更多數(shù)據(jù)到接收方。

Stream 級(jí)別對(duì)防止接收端接收過(guò)多數(shù)據(jù)作用有限，更需要借助 Connection 級(jí)別的流量控制。理解了 Stream 流量那么也很好理解 Connection 流控。Stream 中，接收窗口(flow control receive window) = 最大接收窗口(max receive window) - 已接收數(shù)據(jù)(highest received byte offset) ，而對(duì) Connection 來(lái)說(shuō)：接收窗口 = Stream1 接收窗口 + Stream2 接收窗口 + ... + StreamN 接收窗口 。

2. 總結(jié)

QUIC 丟掉了 TCP、TLS 的包袱，基于 UDP，并對(duì) TCP、TLS、HTTP/2 的經(jīng)驗(yàn)加以借鑒、改進(jìn)，實(shí)現(xiàn)了一個(gè)安全高效可靠的 HTTP 通信協(xié)議。憑借著 0 RTT 建立連接、平滑的連接遷移、基本消除了隊(duì)頭阻塞、改進(jìn)的擁塞控制和流量控制等優(yōu)秀的特性，QUIC 在絕大多數(shù)場(chǎng)景下獲得了比 HTTP/2 更好的效果。

一周前，微軟宣布開源自己的內(nèi)部 QUIC 庫(kù) -- MsQuic，將全面推薦 QUIC 協(xié)議替換 TCP/IP 協(xié)議。

HTTP/3 未來(lái)可期。

?

?

---------------------
作者：朱小廝
來(lái)源：CSDN
原文：https://blog.csdn.net/u013256816/article/details/106308906
版權(quán)聲明：本文為作者原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！
內(nèi)容解析By：CSDN,CNBLOG博客文章一鍵轉(zhuǎn)載插件

總結(jié)

以上是生活随笔為你收集整理的[转]HTTP/3 未来可期？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。