一文領(lǐng)略HTTP的前世今生

每個(gè)時(shí)代，都不會(huì)虧待會(huì)學(xué)習(xí)的人。

大家好，我是 yes。

HTTP 協(xié)議在當(dāng)今的互聯(lián)網(wǎng)可謂是隨處可見(jiàn)，一直默默的在背后支持著網(wǎng)絡(luò)世界的運(yùn)行，對(duì)于我們程序員來(lái)說(shuō) HTTP 更是熟悉不過(guò)了。

平日里我們都說(shuō)架構(gòu)是演進(jìn)的，需求推動(dòng)著技術(shù)的迭代、更新和進(jìn)步，對(duì)于 HTTP 協(xié)議來(lái)說(shuō)也是如此。

不知你是否有想過(guò) HTTP 協(xié)議是如何誕生的，一開(kāi)始是怎樣的，又是怎么一步一步發(fā)展到今天的 HTTP/3 ?

其中經(jīng)歷了哪些不為人知的秘密？

今天我就想和大家一起來(lái)看一看 HTTP 的演進(jìn)之路，來(lái)看看它是如何從一個(gè)小寶寶成長(zhǎng)為現(xiàn)在統(tǒng)治互聯(lián)網(wǎng)的存在。

不過(guò)在此之前，我們先簡(jiǎn)單的看看互聯(lián)網(wǎng)的始祖-阿帕網(wǎng)的一段小歷史，還是很有趣的。

互聯(lián)網(wǎng)的始祖-阿帕網(wǎng)

在 1950 年代，通信研究者們認(rèn)識(shí)到不同計(jì)算機(jī)用戶和網(wǎng)絡(luò)之間的需要通信，這促使了分布式網(wǎng)絡(luò)、排隊(duì)論和封包交互的研究。

在1958 年2月7日，美國(guó)國(guó)防部長(zhǎng)尼爾 · 麥克爾羅伊發(fā)布了國(guó)防部 5105.15 號(hào)指令，建立了高級(jí)研究計(jì)劃局(ARPA) 。

ARPA 的核心機(jī)構(gòu)之一 IPTO（信息處理處）贊助的一項(xiàng)研究導(dǎo)致了阿帕網(wǎng)的開(kāi)發(fā)。

我們來(lái)看看這段歷史。

在 1962 年，ARPA 的主任聘請(qǐng)約瑟夫·利克萊德?lián)?IPTO 的第一任主任，他是最早預(yù)見(jiàn)到現(xiàn)代交互計(jì)算及其在各種應(yīng)用的人之一。

IPTO 資助了先進(jìn)的計(jì)算機(jī)和網(wǎng)絡(luò)技術(shù)的研究，并委托十三個(gè)研究小組對(duì)人機(jī)交互和分布式系統(tǒng)相關(guān)技術(shù)進(jìn)行研究。每個(gè)小組獲得的預(yù)算是正常研究補(bǔ)助金的三十至四十倍。

這就是財(cái)大氣粗啊，研究人員肯定是干勁十足！

在 1963 年利克萊德資助了一個(gè)名為 MAC 的研究項(xiàng)目，該項(xiàng)目旨在探索在分時(shí)計(jì)算機(jī)上建立社區(qū)的可能性。

這個(gè)項(xiàng)目對(duì) IPTO 和更廣泛的研究界產(chǎn)生了持久的影響，成為廣泛聯(lián)網(wǎng)的原型。

并且利克萊德的全球網(wǎng)絡(luò)愿景極大地影響了他在 IPTO 的繼任者們。

1964 年利克萊德跳槽到了 IBM，第二任主任薩瑟蘭上線，他創(chuàng)建了革命性的 Sketchpad 程序，用于存儲(chǔ)計(jì)算機(jī)顯示器的內(nèi)存，在 1965 年他與麻省理工學(xué)院的勞倫斯 · 羅伯茨簽訂了 IPTO 合同，以進(jìn)一步發(fā)展計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)。

隨后，羅伯茨和托馬斯 · 梅里爾在麻省理工學(xué)院的 TX-2 計(jì)算機(jī)和加利福尼亞的 Q-32 計(jì)算機(jī)之間，通過(guò)撥號(hào)電話連接實(shí)現(xiàn)了第一個(gè)數(shù)據(jù)包交換。

1966 年第三任主任鮑勃 · 泰勒上任，他深受利克萊德的影響，巧的是泰勒和利克萊德一樣也是個(gè)心理聲學(xué)家。

在泰勒的 IPTO 辦公室里有三個(gè)不同的終端連接到三個(gè)不同的研究站點(diǎn)，他意識(shí)到這種架構(gòu)將嚴(yán)重限制他擴(kuò)展訪問(wèn)多個(gè)站點(diǎn)的能力。

于是他想著把一個(gè)終端連接到一個(gè)可以訪問(wèn)多個(gè)站點(diǎn)的網(wǎng)絡(luò)上，并且從他在五角大樓的職位來(lái)說(shuō)，他有這個(gè)能力去實(shí)現(xiàn)這個(gè)愿景。

美國(guó)國(guó)防部高級(jí)研究計(jì)劃局局長(zhǎng)查理 · 赫茨菲爾德向泰勒承諾，如果 IPTO 能夠組織起來(lái)，他將提供 100 萬(wàn)美元用于建立一個(gè)分布式通信網(wǎng)絡(luò)。

泰勒一聽(tīng)舒服了，然后他對(duì)羅伯茨的工作印象很深刻，邀請(qǐng)他加入并領(lǐng)導(dǎo)這項(xiàng)工作，然后羅伯茨卻不樂(lè)意。

泰勒不高興了，于是要求赫茨菲爾德讓林肯實(shí)驗(yàn)室的主任向羅伯茨施壓，要求他重新考慮，這最終促使羅伯茨緩和了態(tài)度，于1966年12月加入 IPTO 擔(dān)任首席科學(xué)家。

在 1968 年6月3日，羅伯茨向泰勒描述了建立阿帕網(wǎng)的計(jì)劃，18 天后，也就是 6 月 21 日，泰勒批準(zhǔn)了這個(gè)計(jì)劃，14 個(gè)月后阿帕網(wǎng)建立。

當(dāng)阿帕網(wǎng)順利發(fā)展時(shí)，泰勒于 1969 年9月將 IPTO 的管理權(quán)移交給羅伯茨。

隨后羅伯茨離開(kāi) ARPA 成為 Telenet 的 CEO ，而利克萊德再次回到 IPTO 擔(dān)任董事，以完成該組織的生命周期。

至此，這段歷史暫告一段落，可以看到阿帕網(wǎng)之父羅伯茨還是被施壓的才接受這項(xiàng)任務(wù)，最終創(chuàng)建了阿帕網(wǎng)，互聯(lián)網(wǎng)的始祖。

也多虧了利克萊德的遠(yuǎn)見(jiàn)和砸錢(qián)促進(jìn)了技術(shù)的發(fā)展，ARPA 不僅成為網(wǎng)絡(luò)誕生地，同樣也是電腦圖形、平行過(guò)程、計(jì)算機(jī)模擬飛行等重要成果的誕生地。

歷史就是這么的巧合和有趣。

互聯(lián)網(wǎng)的歷史

在 1973 年 ARPA 網(wǎng)擴(kuò)展成互聯(lián)網(wǎng)，第一批接入的有英國(guó)和挪威計(jì)算機(jī)，逐漸地成為網(wǎng)絡(luò)連接的骨干。

1974 年 ARPA 的羅伯特·卡恩和斯坦福的文頓·瑟夫提出TCP/IP 協(xié)議。

1986 年，美國(guó)國(guó)家科學(xué)基金會(huì)（National Science Foundation，NSF）建立了大學(xué)之間互聯(lián)的骨干網(wǎng)絡(luò) NSFNET ，這是互聯(lián)網(wǎng)歷史上重要的一步，NSFNET 成為新的骨干，1990 年 ARPANET 退役。

在 1990 年 ，蒂姆·伯納斯-李（下文我就稱李老） 創(chuàng)建了運(yùn)行萬(wàn)維網(wǎng)所需的所有工具：超文本傳輸協(xié)議（HTTP）、超文本標(biāo)記語(yǔ)言（HTML）、第一個(gè)網(wǎng)頁(yè)瀏覽器、第一個(gè)網(wǎng)頁(yè)服務(wù)器和第一個(gè)網(wǎng)站。

至此，互聯(lián)網(wǎng)開(kāi)啟了快速發(fā)展之路，HTTP 也開(kāi)始了它的偉大征途。

還有很多有趣的歷史，比如第一次瀏覽器大戰(zhàn)等等，之后有機(jī)會(huì)再談，今天我們的主角是 HTTP。

接下來(lái)我們就看看 HTTP 各大版本的演進(jìn)，來(lái)看看它是如何成長(zhǎng)到今天這個(gè)樣子的。

HTTP / 0.9 時(shí)代

在 1989 年，李老發(fā)表了一篇論文，文中提出了三項(xiàng)現(xiàn)在看來(lái)很平常的三個(gè)概念。

• URI，統(tǒng)一資源標(biāo)識(shí)符，作為互聯(lián)網(wǎng)上的唯一標(biāo)識(shí)。
• HTML，超文本標(biāo)記語(yǔ)言，描述超文本。
• HTTP ，超文本傳輸協(xié)議，傳輸超文本。

隨后李老就付之于行動(dòng)，把這些都搞出來(lái)了，稱之為萬(wàn)維網(wǎng)（World Wide Web）。

那時(shí)候是互聯(lián)網(wǎng)初期，計(jì)算機(jī)的處理能力包括網(wǎng)速等等都很弱，所以 HTTP 也逃脫不了那個(gè)時(shí)代的約束，因此設(shè)計(jì)的非常簡(jiǎn)單，而且也是純文本格式。

李老當(dāng)時(shí)的想法是文檔存在服務(wù)器里面，我們只需要從服務(wù)器獲取文檔，因此只有 “GET”，也不需要啥請(qǐng)求頭，并且拿完了就結(jié)束了，因此請(qǐng)求響應(yīng)之后連接就斷了。

這就是為什么 HTTP 設(shè)計(jì)為文本協(xié)議，并且一開(kāi)始只有“GET”、響應(yīng)之后連接就斷了的原因了。

在我們現(xiàn)在看來(lái)這協(xié)議太簡(jiǎn)陋了，但是在當(dāng)時(shí)這是互聯(lián)網(wǎng)發(fā)展的一大步！一個(gè)東西從無(wú)到有是最困難的。

這時(shí)候的 HTTP 還沒(méi)有版本號(hào)的，之所以稱之為 HTTP / 0.9 是后人加上去了，為了區(qū)別之后的版本。

HTTP 1.0 時(shí)代

人們的需求是無(wú)止盡的，隨著圖像和音頻的發(fā)展，瀏覽器也在不斷的進(jìn)步予以支持。

在 1995 年又開(kāi)發(fā)出了 Apache，簡(jiǎn)化了 HTTP 服務(wù)器的搭建，越來(lái)越多的人用上了互聯(lián)網(wǎng)，這也促進(jìn)了 HTTP 協(xié)議的修改。

需求促使添加各種特性來(lái)滿足用戶的需求，經(jīng)過(guò)了一系列的草案 HTTP/1.0 于 1996 年正式發(fā)布。

Dave Raggett 在1995年領(lǐng)導(dǎo)了 HTTP 工作組，他希望通過(guò)擴(kuò)展操作、擴(kuò)展協(xié)商、更豐富的元信息以及與安全協(xié)議相關(guān)的安全協(xié)議來(lái)擴(kuò)展協(xié)議，這種安全協(xié)議通過(guò)添加額外的方法和頭字段來(lái)提高效率。

所以在 HTTP/1.0 版本主要增加以下幾點(diǎn)：

• 增加了 HEAD、POST 等新方法。
• 增加了響應(yīng)狀態(tài)碼。
• 引入了頭部，即請(qǐng)求頭和響應(yīng)頭。
• 在請(qǐng)求中加入了 HTTP 版本號(hào)。
• 引入了 Content-Type ，使得傳輸?shù)臄?shù)據(jù)不再限于文本。

可以看到引入了新的方法，填充了操作的語(yǔ)義，像  HEAD 還可以只拿元信息不必傳輸全部?jī)?nèi)容，提高某些場(chǎng)景下的效率。

引入的響應(yīng)狀態(tài)碼讓請(qǐng)求方可以得知服務(wù)端的情況，可以區(qū)分請(qǐng)求出錯(cuò)的原因，不會(huì)一頭霧水。

引入了頭部，使得請(qǐng)求和響應(yīng)更加的靈活，把控制數(shù)據(jù)和業(yè)務(wù)實(shí)體進(jìn)行了拆分，也是一種解耦。

新增了版本號(hào)表明這是一種工程化的象征，說(shuō)明走上了正途，畢竟沒(méi)版本號(hào)無(wú)法管理。

引入了 Content-Type，支持傳輸不同類型的數(shù)據(jù)，豐富了協(xié)議的載體，充實(shí)了用戶的眼球。

但是那時(shí)候 HTTP/1.0 還不是標(biāo)準(zhǔn)，沒(méi)有實(shí)際的約束力，各方勢(shì)力不吃這一套，大白話就是你算老幾。

HTTP 1.1 時(shí)代

HTTP/1.1 版本在 1997 的 RFC 2068 中首次被記錄，從 1995 年至 1999 年間的第一次瀏覽器大戰(zhàn)，極大的推動(dòng)了 Web 的發(fā)展。

隨著發(fā)展 HTTP/1.0 演進(jìn)成了 HTTP/1.1，并且在 1999 年廢棄了之前的 RFC 2068，發(fā)布了 RFC 2616。

從版本號(hào)可以得知這是一個(gè)小版本的更新，更新主要是因?yàn)?HTTP/1.0 很大的性能問(wèn)題，就是每請(qǐng)求一個(gè)資源都得新建一個(gè) TCP 連接，而且只能串行請(qǐng)求。

所以在 HTTP/1.1 版本主要增加以下幾點(diǎn)：

• 新增了連接管理即 keepalive ，允許持久連接。
• 支持 pipeline，無(wú)需等待前面的請(qǐng)求響應(yīng)，即可發(fā)送第二次請(qǐng)求。
• 允許響應(yīng)數(shù)據(jù)分塊（chunked），即響應(yīng)的時(shí)候不標(biāo)明Content-Length，客戶端就無(wú)法斷開(kāi)連接，直到收到服務(wù)端的 EOF ，利于傳輸大文件。
• 新增緩存的控制和管理。
• 加入了 Host 頭，用在你一臺(tái)機(jī)子部署了多個(gè)主機(jī)，然后多個(gè)域名解析又是同一個(gè) IP，此時(shí)加入了 Host 頭就可以判斷你到底是要訪問(wèn)哪個(gè)主機(jī)。

可以看到瀏覽器大戰(zhàn)推進(jìn)了 Web 的發(fā)展，也暴露出 HTTP/1.0 的不足之處，畢竟網(wǎng)絡(luò)帶寬等等都在進(jìn)步，總不能讓協(xié)議限制了硬件的發(fā)展。

因此提出了 HTTP/1.1 ，主要是為了解決性能的問(wèn)題，包括支持持久連接、pipeline、緩存管理等等，也添加了一些特性。

再后來(lái)到 2014 年對(duì) HTTP/1.1 又做了一次修訂，因?yàn)槠涮^(guò)龐大和復(fù)雜，因此進(jìn)行了拆分，弄成了六份小文檔 RFC7230 - RFC7235

這時(shí)候 HTTP/1.1 已經(jīng)成了標(biāo)準(zhǔn)，其實(shí)標(biāo)準(zhǔn)往往是在各大強(qiáng)力競(jìng)爭(zhēng)對(duì)手相對(duì)穩(wěn)定之后建立的，因?yàn)闃?biāo)準(zhǔn)意味著統(tǒng)一，統(tǒng)一就不用費(fèi)勁心思去兼容各種玩意。

只有強(qiáng)大的勢(shì)力才能定標(biāo)準(zhǔn)，當(dāng)你足夠強(qiáng)大的時(shí)候你也可以定標(biāo)準(zhǔn)，去挑戰(zhàn)老標(biāo)準(zhǔn)。

HTTP 2 時(shí)代

隨著 HTTP/1.1 的發(fā)布，互聯(lián)網(wǎng)也開(kāi)始了爆發(fā)式的增長(zhǎng)，這種增長(zhǎng)暴露出 HTTP 的不足，主要還是性能問(wèn)題，而 HTTP/1.1 無(wú)動(dòng)于衷。

這就是人的惰性，也符合平日里我們對(duì)產(chǎn)品的演進(jìn)，當(dāng)你足夠強(qiáng)大又安逸的時(shí)候，任何的改動(dòng)你是不想理會(huì)的。

別用咯。

這時(shí)候 Google 看不下去了，你不搞是吧？我自己搞我的，我自己和我自己玩，我用戶群體大，我有 Chrome，我服務(wù)多了去了。

Google 推出了 SPDY 協(xié)議，憑借著它全球的占有率超過(guò)了 60% 的底氣，2012年7月，開(kāi)發(fā) SPDY 的小組公開(kāi)表示，它正在努力實(shí)現(xiàn)標(biāo)準(zhǔn)化。

HTTP 坐不住了，之后互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織以 SPDY 為基礎(chǔ)開(kāi)始制定新版本的 HTTP 協(xié)議，最終在 2015 年發(fā)布了 HTTP/2。

HTTP/2 版本主要增加以下幾點(diǎn)：

• 是二進(jìn)制協(xié)議，不再是純文本。
• 支持一個(gè) TCP 連接發(fā)起多請(qǐng)求，移除了 pipeline。
• 利用 HPACK 壓縮頭部，減少數(shù)據(jù)傳輸量。
• 允許服務(wù)端主動(dòng)推送數(shù)據(jù)。

從文本到二進(jìn)制其實(shí)簡(jiǎn)化了整齊的復(fù)雜性，解析數(shù)據(jù)的開(kāi)銷(xiāo)更小，數(shù)據(jù)更加緊湊，減少了網(wǎng)絡(luò)的延遲，提升了整體的吞吐量。

支持一個(gè) TCP 連接發(fā)起多請(qǐng)求，即支持多路復(fù)用，像 HTTP/1.1 pipeline 還是有阻塞的情況，需要等前面的一個(gè)響應(yīng)返回了后面的才能返回。

而多路復(fù)用就是完全異步化，這減少了整體的往返時(shí)間（RTT），解決了 HTTP 隊(duì)頭阻塞問(wèn)題，也規(guī)避了 TCP 慢啟動(dòng)帶來(lái)的影響。

HPACK 壓縮頭部，采用了靜態(tài)表、動(dòng)態(tài)表和哈夫曼編碼，在客戶端和服務(wù)器都維護(hù)請(qǐng)求頭的列表，所以只需要增量和壓縮過(guò)的頭部信息，服務(wù)端拿到之后組裝一下就能得到完整的頭部信息。

形象一點(diǎn)就是如下圖所示：

再具體一點(diǎn)就是下圖這樣：

服務(wù)端主動(dòng)推送數(shù)據(jù)，這個(gè)其實(shí)就是減少了請(qǐng)求的次數(shù)，比如客戶端請(qǐng)求 1.html，我把 1.html 需要的 js 和 css 也一塊送過(guò)去，省的之后客戶端再請(qǐng)求我要 js ，我要這個(gè) css。

可以看到 HTTP/2 的整體演進(jìn)都是往性能優(yōu)化的角度發(fā)展，因?yàn)榇藭r(shí)的性能就是痛點(diǎn)，任何東西的演進(jìn)都是哪里痛醫(yī)哪里。

當(dāng)然有一些例外，比如一些意外，或者就是“閑的蛋疼”的那種捯飭。

這次推進(jìn)屬于用戶揭竿而起為之，你再不給我升級(jí)我自己搞了，我有著資本，你自己掂量。

最終結(jié)果是好的，Google 后來(lái)放棄了 SPDY ，擁抱標(biāo)準(zhǔn)，而 HTTP/1.1 這個(gè)歷史包袱太重了，所以 HTTP/2 到現(xiàn)在也只有大致一半的網(wǎng)站使用它。

HTTP 3 時(shí)代

這 HTTP/2 還沒(méi)捂熱， HTTP/3 怎么就來(lái)了？

這次又是 Google，它自己突破自己，主要也是源自于痛點(diǎn)，這次的痛點(diǎn)來(lái)自于 HTTP 依賴的 TCP。

TCP 是面向可靠的、有序的傳輸協(xié)議，因此會(huì)有失敗重傳和按序機(jī)制，而 HTTP/2 是所有流共享一個(gè) TCP 連接，所以會(huì)有 TCP 層面的隊(duì)頭阻塞，當(dāng)發(fā)生重傳時(shí)會(huì)影響多個(gè)請(qǐng)求響應(yīng)。

并且 TCP 是基于四元組（源IP，源端口，目標(biāo)IP，目標(biāo)端口）來(lái)確定連接的，而在移動(dòng)網(wǎng)絡(luò)的情況下 IP 地址會(huì)頻繁的換，這會(huì)導(dǎo)致反復(fù)的建連。

還有 TCP 與 TLS 的疊加握手，增加了延時(shí)。

問(wèn)題就出在 TCP 身上，所以 Google 就把目光瞄向了 UDP。

UDP 我們知道是無(wú)連接的，不管什么順序，也不管你什么丟包，而 TCP 我在之前的文章說(shuō)的很清楚了TCP疑難雜癥解析不了解的同學(xué)可以去看看。

簡(jiǎn)單的說(shuō)就是 TCP 太無(wú)私了，或者說(shuō)太保守了，現(xiàn)在需要一種更激進(jìn)的做法。

那怎么搞? TCP 改不動(dòng)我就換！然后把 TCP 可靠、有序的功能提到應(yīng)用層來(lái)實(shí)現(xiàn)，因此 Google 就研究出了 QUIC 協(xié)議。

QUIC 層來(lái)實(shí)現(xiàn)自己的丟包重傳和擁塞控制，還有出于安全的考慮我們都會(huì)用 HTTPS ，所以需要多次握手。

上面我也已經(jīng)提到了關(guān)于四元組的情況，所以在移動(dòng)互聯(lián)網(wǎng)時(shí)代這握手的消耗就更加放大了，于是 QUIC 引入了個(gè)叫 Connection ID 來(lái)標(biāo)識(shí)一個(gè)鏈接，所以切換網(wǎng)絡(luò)之后可以復(fù)用這個(gè)連接，達(dá)到 0 RTT 就能開(kāi)始傳輸。

注意上圖是在已經(jīng)和服務(wù)端握過(guò)手之后的，由于網(wǎng)絡(luò)切換等原因才有 0 RTT ，也就是 Connection ID 在之前生成過(guò)了。

如果是第一次建連還是需要多次握手的，我們來(lái)看一下簡(jiǎn)化的握手對(duì)比圖。

所以所謂的 0RTT 是在之前已經(jīng)建連的情況下。

當(dāng)然還有 HTTP/2 提到的 HPACK，這個(gè)是依賴 TCP 的可靠、有序傳輸?shù)?，于?QUIC 得搞了個(gè) QPACK，也采用了靜態(tài)表、動(dòng)態(tài)表和哈夫曼編碼。

它豐富了 HTTP/2 的靜態(tài)表，從 61 項(xiàng)加到了 98 項(xiàng)。

上面提到的動(dòng)態(tài)表，是用來(lái)存儲(chǔ)未包含在靜態(tài)表中的頭部項(xiàng)，假設(shè)動(dòng)態(tài)表還未收到，后面來(lái)解頭部的時(shí)候肯定要被阻塞的。

所以 QPACK 就另開(kāi)一條路，在單向的 Stream 里傳輸動(dòng)態(tài)表的編解碼，單向傳輸好了，接受端到才能開(kāi)始解碼，也就是說(shuō)還沒(méi)好你就先別管，防止做一半卡住了。

那還有前面提到的 TCP 隊(duì)頭阻塞， QUIC 是怎么解決的呢？畢竟它也要保證有序和可靠啊。

因?yàn)?TCP 不認(rèn)識(shí)每個(gè)流分別是哪個(gè)請(qǐng)求的，所以它只能全部阻塞住，而 QUIC 知道，因此比如請(qǐng)求 A 丟包了，我就把 A 卡住了就行，請(qǐng)求 B 完全可以全部放行，絲毫不受影響。

可以看到基于 UDP 的 QUIC 還是很強(qiáng)大的，而且人家用戶多，在 2018 年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織 IETF 提議將 HTTP over QUIC 更名為 HTTP/3 并獲得批準(zhǔn)。

可以看到需求又推動(dòng)技術(shù)的進(jìn)步，由于 TCP 自身機(jī)制的限制，我們的目光已經(jīng)往 UDP 上靠了，那 TCP 會(huì)不會(huì)成為歷史呢？

我們拭目以待。

最后

今天我們大致過(guò)了一遍 HTTP 發(fā)展的歷史和它的演進(jìn)之路，可以看到技術(shù)是源于需求，需求推動(dòng)著技術(shù)的發(fā)展。

本質(zhì)上就是人的惰性，只有痛了才會(huì)成長(zhǎng)。

而且標(biāo)準(zhǔn)其實(shí)也是巨頭們?yōu)榱怂麄兊睦嫱苿?dòng)的，不過(guò)標(biāo)準(zhǔn)確實(shí)能減輕對(duì)接的開(kāi)銷(xiāo)，統(tǒng)一而方便。

當(dāng)然就 HTTP 來(lái)說(shuō)還是有很多內(nèi)容的，有很多細(xì)節(jié)，很多算法，比如拿 Connection ID 來(lái)說(shuō)，不同的四元組你如何保證請(qǐng)求一定會(huì)轉(zhuǎn)發(fā)到之前的服務(wù)器上？

所以今天我只是淺顯的談了談大致的演進(jìn)，具體的實(shí)現(xiàn)還是得靠各位自己摸索，或者之后有機(jī)會(huì)我再寫(xiě)一些。

不過(guò)相對(duì)于這些實(shí)現(xiàn)細(xì)節(jié)我更感興趣的是歷史的演進(jìn)，這能讓我從時(shí)代背景等一些約束來(lái)得知，為什么這東西一開(kāi)始是這么設(shè)計(jì)的，從而更深刻的理解這玩意。

而且歷史還是很有趣的，不是么？

最后的最后

個(gè)人能力有限，如有紕漏請(qǐng)趕緊聯(lián)系鞭撻我，如果想進(jìn)群就備注下進(jìn)群，我拉你。

如果覺(jué)得文章不錯(cuò)還望點(diǎn)個(gè)在看支持一下喲。

我是 yes，從一點(diǎn)點(diǎn)到億點(diǎn)點(diǎn)，我們下篇見(jiàn)。

巨人的肩膀

https://www.livinginternet.com/i/ii_ipto.htm

https://jacobianengineering.com/blog/2016/11/1543/

https://w3techs.com/technologies/details/ce-http2

https://www.verizondigitalmedia.com/blog/how-quic-speeds-up-all-web-applications/

https://www.oreilly.com/content/http2-a-new-excerpt/

https://www.darpa.mil/about-us/timeline/dod-establishes-arpa

https://en.wikipedia.org/wiki/ARPANET

https://en.wikipedia.org/wiki/Internet

深入剖析HTTP/3協(xié)議 ,陶輝

透視HTTP協(xié)議 ,羅劍鋒

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！