據(jù)據(jù)中國(guó)臺(tái)灣地區(qū)消息報(bào)道，國(guó)際互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force, IETF）將于近日商討下一代HTTP底層協(xié)議，可能不再使用已經(jīng)沿用多年的TCP協(xié)議，而有望改用以UDP協(xié)議發(fā)展出的QUIC技術(shù)，同時(shí)新一代HTTP將命名為HTTP/3。

目前，人們使用的HTTP (1.0、1.1及2)都是以TCP (Transmission Control Protocol)協(xié)議為基礎(chǔ)實(shí)作出來(lái)。TCP作為一種傳輸控制協(xié)議，優(yōu)點(diǎn)是安全、流量穩(wěn)定、講求封包的傳輸順序，但缺點(diǎn)是效率低、連接耗時(shí)。為了提升數(shù)據(jù)在IP網(wǎng)絡(luò)上的傳輸，Google提出了實(shí)驗(yàn)性網(wǎng)絡(luò)層協(xié)議，稱為QUIC。

QUIC并不使用TCP，而改用UDP (User Datagram Protocol)為底層，UDP雖然較不安全、可能有掉封包或封包后發(fā)先至的問(wèn)題，但較簡(jiǎn)單、傳輸效率更高，能大幅減低延遲性。Google為QUIC提升安全性、并加入緩沖機(jī)制避免阻斷服務(wù)攻擊（DoS）。

雖然Google有意將QUIC提交到IETF，以便成為下一代網(wǎng)際網(wǎng)絡(luò)規(guī)范，但I(xiàn)ETF也提出了一個(gè)和Google QUIC分庭抗禮的QUIC。社區(qū)中稱Google提出的QUIC為gQUIC，而IETF的為iQUIC。

另一方面，當(dāng)IETF的QUIC工作小組將QUIC標(biāo)準(zhǔn)化時(shí)，它衍生出共兩個(gè)協(xié)議，一個(gè)是網(wǎng)絡(luò)傳輸協(xié)議，一個(gè)是HTTP層協(xié)議。網(wǎng)絡(luò)傳輸層協(xié)議也可用于傳輸其他數(shù)據(jù)，不只為HTTP設(shè)定，但兩者名稱都使用了QUIC；而在iQUIC上傳輸?shù)腍TTP協(xié)議，長(zhǎng)期以來(lái)就被稱為HTTP-over-QUIC，或HTTP/QUIC。

為了解決種種混淆，讓彼此之間更容易分別，IETF決定加以正名。HTTP工作小組暨QUIC工作小組主席Mark Nottingham倡議將HTTP-over-QUIC（HTTP/QUIC）重新命名為HTTP/3，并在上周舉行的IETF HTTPBIS會(huì)議中提議，并且也廣為接受。

Mozilla開發(fā)人員Daniel Stenberg日志列出了NotTIgham在會(huì)中的簡(jiǎn)報(bào)，簡(jiǎn)報(bào)重申HTTP/3和之前協(xié)議之間的差異。HTTP/QUIC（HTTP/3）并非HTTP/1.1或HTTP/2的后代，也不是QUIC上的HTTP/2協(xié)議，因?yàn)樗窃赒UIC協(xié)議上新開發(fā)出的HTTP。下一代HTTP將是以QUIC為核心及網(wǎng)絡(luò)傳輸協(xié)議的新協(xié)議。

Litespeed的工程師也宣布該公司和臉書已經(jīng)完成HTTP/3實(shí)作的相容性測(cè)試。