簡(jiǎn)介

很多小伙伴可能還沉浸在HTTP1.1的世界無(wú)法自拔，但是時(shí)代的洪流已經(jīng)帶領(lǐng)我們來(lái)到了HTTP3的世界了。是的，你在橋上看風(fēng)景，而橋邊的房子上有人正在看你。

為了不被時(shí)代所拋棄，今天給大家講解一下HTTP3的新特性。

HTTP成長(zhǎng)介紹

HTTP的全名叫做超文本傳輸​​協(xié)議，是萬(wàn)維網(wǎng)所基于的應(yīng)用層傳輸協(xié)議。最初的版本是HTTP 0.9，是在80年的后期產(chǎn)生的，后面在1996年升級(jí)到了1.0.

但是HTTP1.0滿足不了日益增長(zhǎng)的物質(zhì)文化需求和對(duì)美好世界的向往。所以在1997年出現(xiàn)了HTTP1.1，隨后到2014年，HTTP1.1都一直都在更新。

然后到了2015年，為了適應(yīng)快速發(fā)送的web應(yīng)用和現(xiàn)代瀏覽器的需求，在Google的SPDY項(xiàng)目基礎(chǔ)上發(fā)展出了新的HTTP2協(xié)議。

又過(guò)了4年，在2019年，Google又開(kāi)發(fā)出了一個(gè)新的協(xié)議標(biāo)準(zhǔn)QUIC協(xié)議，它就是HTTP3的基石，其目的是為了提高用戶(hù)與網(wǎng)站和API交互的速度和安全性。

不同HTTP協(xié)議解決的問(wèn)題

不同HTTP協(xié)議解決的問(wèn)題也是不同的，HTTP1.1有什么問(wèn)題呢？

1.因?yàn)镠TTP1.1一個(gè)連接中數(shù)據(jù)是順序傳輸?shù)?，所以?huì)有Head-of-line Blocking的問(wèn)題，如果前面是一個(gè)大的數(shù)據(jù)包，則會(huì)導(dǎo)致后續(xù)數(shù)據(jù)包的阻塞。

2.HTTP1.1無(wú)法對(duì)請(qǐng)求頭和cookie進(jìn)行壓縮，所以傳輸效率會(huì)比較低。

3.為了保證緩沖區(qū)不會(huì)溢出，HTTP1.1有一個(gè)TCP慢啟動(dòng)的功能，作為擁塞控制措施，協(xié)議反復(fù)探測(cè)網(wǎng)絡(luò)以計(jì)算可用容量，但是這樣就會(huì)導(dǎo)致多次數(shù)據(jù)的傳輸，從而導(dǎo)致消息的延時(shí)。

對(duì)于HTTP2來(lái)說(shuō)，它使用二進(jìn)制進(jìn)行消息傳輸，并且將消息拆分成一個(gè)個(gè)的stream，在stream中又包含了多個(gè)frame，允許資源通過(guò)多路復(fù)用使用同一個(gè)連接發(fā)送，解決了行頭阻塞的問(wèn)題，并且還支持?jǐn)?shù)據(jù)包的優(yōu)先級(jí)和服務(wù)器推送。

但是HTTP2的服務(wù)器推送會(huì)導(dǎo)致應(yīng)用程序變得復(fù)雜，TCP級(jí)別的頭阻塞的問(wèn)題在數(shù)據(jù)包丟失并且必須重新以正確的順序重新發(fā)送時(shí)，仍然可能發(fā)生。

要注意，HTTP/2是HTTP/1.1的擴(kuò)展，而不是它的替代品。 應(yīng)用程序語(yǔ)義保持不變，具有相同的HTTP方法、狀態(tài)代碼、URI和標(biāo)頭字段。 所以HTTP/2可以被用在任何使用HTTP/1.1的地方。

HTTP/2在客戶(hù)端和服務(wù)器之間使用單個(gè)TCP連接，該連接在交互期間保持打開(kāi)狀態(tài)。

雖然HTTP/2支持并發(fā)，但是過(guò)多的并發(fā)會(huì)導(dǎo)致HTTP/2服務(wù)器接收到大批量的請(qǐng)求，從而導(dǎo)致請(qǐng)求超時(shí)。

HTTP3和QUIC

HTTP/3的目標(biāo)是通過(guò)解決HTTP/2的傳輸相關(guān)問(wèn)題，在所有形式的設(shè)備上提供快速、可靠和安全的Web連接。為此，它使用了一種不同的傳輸層網(wǎng)絡(luò)協(xié)議，稱(chēng)為QUIC，該協(xié)議最初由Google開(kāi)發(fā)的。

感慨一下，雖然最近中國(guó)在系統(tǒng)的應(yīng)用方面有了一定的進(jìn)步，但是看看這些底層的協(xié)議，還都是外國(guó)人搞出來(lái)的。

HTTP/2和HTTP/3的根本區(qū)別在于，HTTP/2底層使用的是TCP協(xié)議，而HTTP/3使用的是QUIC，而QUIC的底層使用的是UDP協(xié)議。

我們看一下HTTP/2和HTTP/3的協(xié)議棧對(duì)比：

TCP協(xié)議主要保證服務(wù)的可靠性和有序交付，但是TCP需要同握手來(lái)建立連接，這樣做是為了確?？蛻?hù)端和服務(wù)器都存在并且他們?cè)敢獠⑶夷軌蚪粨Q數(shù)據(jù)。但是，它也需要一個(gè)完整的網(wǎng)絡(luò)往返才能完成，然后才能在連接上完成任何其他操作。 如果客戶(hù)端和服務(wù)器端相距比較遠(yuǎn)，那么就需要花費(fèi)較多的時(shí)間來(lái)進(jìn)行連接。

我們知道UDP是無(wú)連接的，所以它要比TCP簡(jiǎn)單很多。它不需要TCP這種建立多次連接的步驟，只需要發(fā)送數(shù)據(jù)包出去就夠了。

所以使用QUIC的優(yōu)點(diǎn)就在于減少了系統(tǒng)的延時(shí)，適用于可以容忍一些數(shù)據(jù)丟包的情況，比如在線游戲、廣告競(jìng)價(jià)、在線視頻、實(shí)時(shí)流等地方。

另外因?yàn)閁DP支持廣播，所以HTTP3還適用于廣播應(yīng)用中，如精確時(shí)間協(xié)議和路由信息協(xié)議等。

另外HTTP3還可以用在物聯(lián)網(wǎng)、大數(shù)據(jù)和VR等方面。

既然HTTP3使用的是QUIC協(xié)議，那么QUIC到底是什么呢？

通常來(lái)說(shuō)QUIC是一種通用傳輸協(xié)議，與TCP非常相似。為什么要打造一套新的協(xié)議呢？這是因?yàn)楝F(xiàn)有的TCP協(xié)議擴(kuò)展起來(lái)非常困難，因?yàn)橐呀?jīng)有太多太多的設(shè)備使用了各種不同的TCP協(xié)議的版本，如果想直接在現(xiàn)有的TCP協(xié)議上進(jìn)行擴(kuò)展非常困難，因?yàn)樾枰o這么多臺(tái)設(shè)備進(jìn)行升級(jí)幾乎是不可能完成的任務(wù)。

所以QUIC在選擇在UDP協(xié)議之上進(jìn)行構(gòu)建。QUIC使用UDP，主要是因?yàn)橄Ｍ茏孒TTP/3更容易部署，因?yàn)樗呀?jīng)被互聯(lián)網(wǎng)上的所有設(shè)備所知并已實(shí)現(xiàn).

QUIC實(shí)際上就是在UDP基礎(chǔ)上重寫(xiě)了TCP的功能，但是又比TCP更加智能，更高效的實(shí)現(xiàn)了TCP的核心功能。

接下來(lái)我們看下QUIC具體有哪些特征。

TLS1.3

TLS主要用來(lái)保證客戶(hù)端和服務(wù)器端在數(shù)據(jù)傳輸過(guò)程的數(shù)據(jù)安全性，可以對(duì)明文數(shù)據(jù)進(jìn)行加密傳輸。TLS1.3是TLS協(xié)議的最新版本，在舊的版本如TLS1.2中，客戶(hù)端和服務(wù)器端的握手至少需要兩次網(wǎng)絡(luò)往返，但是在TLS1.3中，將其減少到只有一次往返。

雖然在HTTP/2中是支持無(wú)加密傳輸模式，但是默認(rèn)情況下所有的現(xiàn)代瀏覽器都不支持這種模式，所以HTTP/2必須配合HTTPS一起使用。長(zhǎng)遠(yuǎn)看來(lái)HTTPS肯定是未來(lái)的趨勢(shì)，所以在QUIC中，直接就使用了TLS 1.3協(xié)議。QUIC本身就封裝了TLS1.3。

這樣做的好處就是QUIC沒(méi)辦法運(yùn)行明文，所以更加的安全。并且QUIC內(nèi)置了加密協(xié)議，將傳輸和加密握手合二為一，節(jié)省了往返。

因?yàn)镼UIC是全程加密的，所以對(duì)于某些ISP和中間網(wǎng)絡(luò)來(lái)說(shuō)，無(wú)法再對(duì)網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行分析和統(tǒng)計(jì)，所以可能會(huì)限制它的使用。并且因?yàn)镼UIC是單獨(dú)對(duì)每個(gè)數(shù)據(jù)包進(jìn)行加密的，在高并發(fā)的情況下，可能會(huì)造成性能問(wèn)題。

解決HoL阻塞

傳統(tǒng)的HTTP1.1和HTTP2底層協(xié)議是TCP，雖然HTTP2在應(yīng)用層可以將不同文件的數(shù)據(jù)拆分成一個(gè)個(gè)的stream放在同一個(gè)連接中進(jìn)行傳輸。但是對(duì)于TCP本身來(lái)說(shuō)，它并不知道這些stream屬于不同的文件，它會(huì)將其當(dāng)成同一個(gè)文件。所以如果發(fā)送數(shù)據(jù)丟包的情況，TCP會(huì)重新發(fā)送所有的文件包。從而導(dǎo)致HOL阻塞的問(wèn)題。

而QUIC更加細(xì)粒度一點(diǎn)，它可以在每個(gè)流的基礎(chǔ)上執(zhí)行丟包檢測(cè)和恢復(fù)邏輯。從而只會(huì)重發(fā)失敗的流，而不是整個(gè)文件。

連接的遷移

在TCP中，如果我想要建立客戶(hù)端和服務(wù)器端的連接，需要知道這4個(gè)元素：客戶(hù)端IP地址 + 客戶(hù)端端口 + 服務(wù)器IP地址 + 服務(wù)器端口。

如果這4個(gè)元素中有一個(gè)發(fā)送了變化，則需要重新建立TCP連接。并且需要根據(jù)應(yīng)用程序級(jí)協(xié)議，重新啟動(dòng)進(jìn)程中的操作。

比如你正在下載一個(gè)大的文件，但是網(wǎng)絡(luò)地址突然發(fā)生了變化，則可能需要重新請(qǐng)求該文件。

為了解決這個(gè)問(wèn)題，QUIC引入了一個(gè)名為連接標(biāo)識(shí)符(CID)的概念 。 每個(gè)連接都在上述4個(gè)元素中額外分配一個(gè)編號(hào)，用于標(biāo)記客戶(hù)端和服務(wù)器端的唯一連接。

因?yàn)檫@個(gè)CID是由QUIC定義的，所以不會(huì)隨著網(wǎng)絡(luò)遷移的變化而變化。從而不需要新的握手，這種情況被稱(chēng)為連接遷移 。

總結(jié)

好了，今天的HTTP/3和QUIC就介紹到這里，雖然我們沒(méi)有涉及到底層的更多細(xì)節(jié)，但是相信大家應(yīng)該都聽(tīng)得明白了，再總結(jié)一下，QUIC實(shí)際上行就是在UDP協(xié)議之上，再造了一個(gè)更加高級(jí)有效的TCP協(xié)議。

到此這篇關(guān)于淺析HTTP3的文章就介紹到這了,更多相關(guān)HTTP3內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！