HTTP的歷史?
超文本傳輸協(xié)議（英語：HyperText?Transfer?Protocol，縮寫：HTTP）是萬維網(wǎng)（World Wide Web）的基礎(chǔ)協(xié)議。自蒂姆·伯納斯-李?（Tim BernersLee）博士和他的團(tuán)隊(duì)在 1989-1991 年間創(chuàng)造出它以來，HTTP 已經(jīng)發(fā)生了太多的變化，在保持協(xié)議簡單性的同時(shí)，不斷擴(kuò)展其靈活性。如今，HTTP 已經(jīng)從一個(gè)只在實(shí)驗(yàn)室之間交換文檔的早期協(xié)議進(jìn)化到了可以傳輸圖片，高分辨率視頻和 3D 效果的現(xiàn)代復(fù)雜互聯(lián)網(wǎng)協(xié)議。
HTTP的誕生?
1989 年 3 月歐洲核子研究組織（CERN）的蒂姆·伯納斯-李?（Tim BernersLee）博士提出了一種能讓遠(yuǎn)隔兩地的研究者們共享知識的設(shè)想。 最初設(shè)想的基本理念是：借助多文檔之間相互關(guān)聯(lián)形成的超文本（HyperText），連成可相互參閱的 WWW（World Wide Web，萬維網(wǎng)）。
蒂姆最初的提議。圖片來源：歐洲核子研究中心
到 1990 年 10 月，Tim 編寫了三項(xiàng)基本技術(shù)來實(shí)現(xiàn)設(shè)想，這些技術(shù)仍然是當(dāng)今網(wǎng)絡(luò)的基礎(chǔ)（您可能已經(jīng)在網(wǎng)絡(luò)瀏覽器的某些部分上看到過這些技術(shù)）：
- HTML（HyperText Markup Language）：超文本標(biāo)記語言，作為編寫文檔的語言。
- HTTP（HyperText Transfer Protocol）：超文本傳輸協(xié)議，作為傳遞文檔的協(xié)議。
- URL（Uniform Resource Locator）：統(tǒng)一資源標(biāo)識符，一種唯一的“地址”，用于標(biāo)識文檔在網(wǎng)絡(luò)上的位置。
此外 Tim 還編寫了第一個(gè)網(wǎng)頁編輯器/瀏覽器（“WorldWideWeb.app”）和第一個(gè) Web 服務(wù)器（“httpd”）。至此 Tim 初步完成了他的設(shè)想的所有技術(shù)實(shí)現(xiàn)，且第一批服務(wù)器已經(jīng)在 1991 年初在 CERN 以外的地方運(yùn)行了，1991 年 8 月 16 日，Tim Berners-Lee 在公開的超文本新聞組上發(fā)表的文章被視為是萬維網(wǎng)公共項(xiàng)目的開始。
對于HTTP而言， 在應(yīng)用的早期階段它是非常簡單的，后來它也被稱為 HTTP/0.9，有時(shí)也叫做單行hang（one-line）協(xié)議。
HTTP/0.9——單行協(xié)議(1991)?
最初版本的 HTTP 協(xié)議并沒有版本號，后來它的版本號被定位在 0.9 以區(qū)分后來的版本。HTTP/0.9于 1991 年提出。它是有史以來最簡單的協(xié)議；它的請求由單行指令構(gòu)成（因此也稱為單行協(xié)議），以唯一可用方法?GET?開頭，其后跟目標(biāo)資源的路徑（一旦連接到服務(wù)器，協(xié)議、服務(wù)器、端口號這些都不是必須的）。
GET /index.html
響應(yīng)也極其簡單的：只包含HTML文檔本身。
<HTML>
這是一個(gè)非常簡單的 HTML 頁面
</HTML>
跟后來的版本不同，HTTP/0.9 的響應(yīng)內(nèi)容并不包含 HTTP 頭。這意味著只有 HTML 文件可以傳送，無法傳輸其他類型的文件。也沒有狀態(tài)碼或錯(cuò)誤代碼。一旦出現(xiàn)問題，一個(gè)特殊的包含問題描述信息的 HTML 文件將被發(fā)回，供人們查看。
特性?
- 它是 ASCII 協(xié)議，請求/響應(yīng)都是由ASCII字符組成字符串。
- 它在TCP/IP 鏈路上運(yùn)行。
- 請求以回車符 (CRLF) 終止。
- 響應(yīng)只包含HTML文檔。
- 文檔傳輸完成后，TCP連接將終止。
缺陷?
- 只支持GET請求： ?HTTP/0.9僅支持GET方法，意味著只能用于獲取資源，不能用于其他類型的請求，如POST、PUT、DELETE等。這導(dǎo)致在處理復(fù)雜的應(yīng)用邏輯和實(shí)現(xiàn)數(shù)據(jù)更新等操作時(shí)，HTTP/0.9顯得非常有限。
- 只能傳輸HTML： ?HTTP/0.9的響應(yīng)只能包含HTML文檔，無法處理其他類型的數(shù)據(jù)，如JSON、XML、圖像等。這限制了其在處理現(xiàn)代Web應(yīng)用程序中的數(shù)據(jù)傳輸和交互能力。
- 無法進(jìn)行內(nèi)容協(xié)商： ?HTTP/0.9沒有頭部信息，無法攜帶元數(shù)據(jù)，如Content-Type、Content-Length等，這使得它無法識別并正確解析其他響應(yīng)內(nèi)容。
- 沒有狀態(tài)碼或錯(cuò)誤代碼： ?也是由于HTTP/0.9沒有頭部信息，無法攜帶元數(shù)據(jù)，因此響應(yīng)成功與失敗都是返回HTML文檔，這使得瀏覽器不能知曉請求執(zhí)行成功或失敗，并相應(yīng)調(diào)整行為。
- 不支持持久連接： ?在HTTP/0.9中，每次請求都會建立一個(gè)新的TCP連接，請求完成后立即關(guān)閉連接。這導(dǎo)致在處理大量請求時(shí)，頻繁地建立和關(guān)閉連接會帶來較大的開銷，影響性能。
- 安全性問題： ?HTTP/0.9沒有提供任何加密和安全機(jī)制，所有的數(shù)據(jù)都是明文傳輸。這使得數(shù)據(jù)容易受到竊聽和篡改，缺乏對隱私和數(shù)據(jù)完整性的保護(hù)。
- 只能傳輸英文文本數(shù)據(jù)： ?HTTP/0.9默認(rèn)采用的字符集是ASCII字符集，這意味著HTTP只能傳輸英文文本數(shù)據(jù)，無法支持其他語言的文本數(shù)據(jù)，比如包含非英文字符的文本（如中文、日文、俄文等）。
正如你們所看到的，HTTP/0.9僅適用于簡單的、僅需要獲取HTML文檔的場景。新興 Web 所需功能及其在公共 Web 上的用例不斷增長，很快就強(qiáng)化了 HTTP 0.9 的許多缺陷：我們需要一個(gè)協(xié)議，該協(xié)議不僅可以服務(wù)于超文本文檔，還可以提供有關(guān)請求和響應(yīng)的更豐富的元數(shù)據(jù)。
很快，HTTP 的下一個(gè)版本（即 HTTP/1.0）被推出，它解決了HTTP/0.9的缺陷，并提供更多強(qiáng)大的功能和性能優(yōu)化。
HTTP/1.0——構(gòu)建可擴(kuò)展性(1996)?
1996 年 5 月，HTTP 工作組 (HTTP-WG) 發(fā)布了?RFC 1945，文檔?RFC 1945?定義了 HTTP/1.0，但它是狹義的，并不是官方標(biāo)準(zhǔn)。
HTTP/1.0 通過定義了HTTP請求/響應(yīng)的結(jié)構(gòu)，加入許多頭部信息，現(xiàn)在可以處理其他響應(yīng)格式，即圖像、視頻文件、純文本或任何其他內(nèi)容類型。它添加了更多方法（即 POST 和 HEAD）、添加了狀態(tài)代碼來標(biāo)識響應(yīng)、引入了字符集、類型、授權(quán)、緩存、內(nèi)容編碼等內(nèi)容。
以下為 HTTP/1.0 的請求示例：
GET / HTTP/1.0
Host: cs.fyi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
以下為 HTTP/1.0 的響應(yīng)示例：
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
(response body)
(connection closed)
HTTP/1.0 的請求與響應(yīng)現(xiàn)在看起來也是非常熟悉的，因?yàn)樗状味x了請求/響應(yīng)的格式我們沿用至今，并且由于加入頭信息，使得內(nèi)容協(xié)商變得容易起來，這也極大的豐富了它的擴(kuò)展性，雖然請求和響應(yīng)標(biāo)頭仍保留為 ASCII 編碼，但響應(yīng)正文可以是任何類型，即圖像、視頻、HTML、純文本或任何其他內(nèi)容類型。因此，現(xiàn)在服務(wù)器不僅僅只能向客戶端發(fā)送HTML文檔，還可以發(fā)送其他任何內(nèi)容類型；推出后不久，HTTP 中的“超文本”一詞就變得用詞不當(dāng)。HMTP 或超媒體傳輸協(xié)議可能更有意義，但我想，我們終生都堅(jiān)持這個(gè)名字。
特性?
- 定義了請求/響應(yīng)格式： ?HTTP/1.0將請求/響應(yīng)格式劃分為了三個(gè)部分——起始行、頭部信息、消息體，這個(gè)格式一直沿用至今。
- 加入了狀態(tài)碼和狀態(tài)描述： ?在響應(yīng)的起始行中加入了狀態(tài)代碼和狀態(tài)的描述信息，提供了關(guān)于請求處理結(jié)果的信息，以便客戶端和服務(wù)器能夠進(jìn)行適當(dāng)?shù)奶幚砗蜎Q策。
- 加入了內(nèi)容協(xié)商： ?雖然在HTTP/1.0中起始行與頭部信息都保留為 ASCII 編碼，但它通過加入了Content-Type、Content-Length、Transfer-Encoding等頭部屬性，可以對不同類型的文件在消息體中進(jìn)行不同的編碼。也就是說起始行、頭部信息傳輸仍是ASCII編碼，而消息體則會根據(jù)頭部屬性讓客戶端/服務(wù)器進(jìn)行內(nèi)容協(xié)商，進(jìn)行不同的編碼方式。
- 可以傳輸任何文件： ?由于HTTP/1.0加入了內(nèi)容協(xié)商的機(jī)制，使得只要客戶端/服務(wù)器協(xié)商一致，HTTP/1.0就可以傳輸任何形式的文件。
- 新增POST、HEAD請求： ?POST請求方法允許客戶端向服務(wù)器提交數(shù)據(jù)，而HEAD請求方法允許客戶端獲取資源的元數(shù)據(jù)。這些新增的請求方法豐富了HTTP協(xié)議的能力，使得客戶端和服務(wù)器能夠進(jìn)行更多樣化的交互和處理。
- 不再只是傳輸英文文本數(shù)據(jù)： ?HTTP/1.0引入字符集（Character Set），解決了其他國家語言文本數(shù)據(jù)的字符編碼問題，并確保文本數(shù)據(jù)能夠以正確的方式被處理和顯示。
- 初步引入緩存概念： ?HTTP/1.0引入了頭部字段如Expires和Last-Modified，用于控制緩存的行為，以及頭部字段如If-Modified-Since和If-None-Match，用于條件性請求。
- 初步引入持久鏈接： ?HTTP/1.0引入一個(gè)名為 Connection: keep-alive 的新標(biāo)頭，來保持請求建立起來的TCP連接，以供后續(xù)請求繼續(xù)使用該鏈接完成請求。
- 初步引入代理支持： ?HTTP/1.0引入了Proxy-Connection頭部字段來指示代理服務(wù)器是否應(yīng)保持持久連接，并引入了Via頭部字段，用于標(biāo)識請求經(jīng)過的代理服務(wù)器鏈。
缺陷?
- 持久鏈接未得到廣泛支持，默認(rèn)仍為短連接： ?HTTP/1.0 的嘗試通過引入一個(gè)名為 Connection: keep-alive 的新標(biāo)頭來克服短連接問題，但它仍然沒有得到廣泛的支持，問題仍然存在。
- 請求阻塞： ?在HTTP/1.0中，每個(gè)請求都需要按照順序進(jìn)行，即必須等待前一個(gè)請求的響應(yīng)返回后才能發(fā)送下一個(gè)請求。如果前一個(gè)請求很耗時(shí)，會導(dǎo)致后續(xù)請求被阻塞，影響并發(fā)性能。
- 無狀態(tài)： ?HTTP是一種無狀態(tài)協(xié)議，即服務(wù)器不維護(hù)有關(guān)客戶端的信息，當(dāng)客戶端需要記錄狀態(tài)時(shí)，必須發(fā)送一些記錄狀態(tài)的冗余數(shù)據(jù)，從而導(dǎo)致帶寬使用量增加。
- 缺乏壓縮支持： ?HTTP/1.0沒有內(nèi)置的數(shù)據(jù)壓縮機(jī)制，因此在傳輸大量文本數(shù)據(jù)時(shí)，沒有有效地壓縮數(shù)據(jù)，增加了網(wǎng)絡(luò)傳輸?shù)拈_銷。
- 安全性問題： ?HTTP/1.0沒有提供任何加密和安全機(jī)制，所有的數(shù)據(jù)都是明文傳輸。這使得數(shù)據(jù)容易受到竊聽和篡改，缺乏對隱私和數(shù)據(jù)完整性的保護(hù)。
- 實(shí)現(xiàn)混亂： ?由于HTTP/1.0并不是官方標(biāo)準(zhǔn)，許多瀏覽器廠商并沒有按照HTTP/1.0的指導(dǎo)實(shí)現(xiàn)HTTP，導(dǎo)致在實(shí)際運(yùn)用中混亂不堪。
可以看到對于HTTP/0.9人們詬病的是它的文件類型支持不夠豐富，由于它的文件類型支持不豐富，所有通常只是請求HTML文檔，往往發(fā)送一次請求就能獲取到完整的內(nèi)容。而在HTTP/1.0豐富了文件類型后，一次請求不再能獲取到全部內(nèi)容，并且請求的內(nèi)容也從較小的HTML文檔發(fā)展到了圖片、音頻、視頻等較大的文件，此時(shí)HTTP的性能問題也被暴露出來。
此外，由于各個(gè)瀏覽器相互競爭，各自為戰(zhàn)，并且HTTP/1.0并不是官方標(biāo)準(zhǔn)，只是一些指導(dǎo)意見。這導(dǎo)致各個(gè)廠商對于HTTP都有各自的實(shí)現(xiàn)方式，導(dǎo)致在實(shí)際運(yùn)用中混亂不堪。
由于上述原因，人們迫切需要優(yōu)化HTTP性能，制定一份標(biāo)準(zhǔn)化HTTP協(xié)議！
HTTP/1.1——標(biāo)準(zhǔn)化的協(xié)議(1997)?
HTTP/1.0 多種不同的實(shí)現(xiàn)方式在實(shí)際運(yùn)用中顯得有些混亂。自 1995 年開始，即 HTTP/1.0 文檔發(fā)布的下一年，就開始修訂 HTTP 的第一個(gè)標(biāo)準(zhǔn)化版本。 在 1997 年 1 月HTTP1.1 標(biāo)準(zhǔn)以?RFC 2068?文件發(fā)布，后續(xù) HTTP/1.1 協(xié)議進(jìn)行過兩次修訂，分別是RFC 2616?發(fā)布于 1999 年 6 月，以及?RFC 7230-RFC 7235?發(fā)布于 2014 年 6 月。
HTTP/1.1 標(biāo)準(zhǔn)消除了早期版本中大量歧義內(nèi)容，并引入了許多關(guān)于性能優(yōu)化的措施：持久鏈接、管道化技術(shù)、支持范圍請求和部分響應(yīng)、分塊傳輸機(jī)制、明確緩存控制機(jī)制、增加壓縮技術(shù)、增強(qiáng)內(nèi)容協(xié)商機(jī)制、增加客戶端cookie等。除了改進(jìn)HTTP性能方面HTTP/1.1還新增狀態(tài)碼、引入了基本認(rèn)證和摘要認(rèn)證，提供更強(qiáng)大的用戶認(rèn)證機(jī)制，確保更安全的通信、 引入了 Host 頭字段，該字段允許在同一個(gè)物理服務(wù)器上托管多個(gè)域名。這使得虛擬主機(jī)能夠通過在 Host 頭中指定域名來區(qū)分不同的網(wǎng)站、并且它還新增了許多請求方法，極大豐富了請求類型。
以下為HTTP/1.1的請求示例
GET /zh-CN/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/zh-CN/docs/Glossary/Simple_header
以下為HTTP/1.1的響應(yīng)示例
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
我們可以看到在請求/響應(yīng)格式上HTTP/1.1與HTTP/1.0并無差異，這是因?yàn)镠TTP/1.1沿用了HTTP/1.0的請求/響應(yīng)格式。
特性?
- 持久化連接： ?在HTTP/1.0中持久連接默認(rèn)為關(guān)閉，并沒有得到廣泛應(yīng)用，而在HTTP/1.1中連接默認(rèn)情況下不會關(guān)閉，而是保持打開狀態(tài)，從而允許多個(gè)順序請求。要關(guān)閉連接，請求頭 Connection: close 必須可用?？蛻舳送ǔＴ谧詈笠粋€(gè)請求中發(fā)送此標(biāo)頭以安全地關(guān)閉連接。
- 管道化技術(shù)： ?HTTP/1.1引入了管道化技術(shù)，以解決請求阻塞問題，客戶端可以在同一連接上向服務(wù)器發(fā)送多個(gè)請求，而無需等待服務(wù)器的響應(yīng)，并且服務(wù)器必須按照接收請求的順序發(fā)送響應(yīng)。
- 新增客戶端Cookie： ?由于HTTP是無狀態(tài)協(xié)議，當(dāng)客戶端需要記錄狀態(tài)時(shí)，必須發(fā)送一些記錄狀態(tài)的冗余數(shù)據(jù)，從而導(dǎo)致帶寬使用量增加。HTTP/1.1引入了客戶端cookie以解決該問題，通過在瀏覽器中設(shè)置cookie，服務(wù)器可以跟蹤用戶會話狀態(tài)，實(shí)現(xiàn)用戶身份認(rèn)證，個(gè)性化用戶體驗(yàn)等。
- 新增Gzip、Deflate等壓縮技術(shù)： ?在HTTP/1.1中，服務(wù)器可以使用Gzip、Deflate等壓縮算法來壓縮HTTP響應(yīng)的實(shí)體主體部分（如HTML、CSS、JavaScript等），然后在響應(yīng)頭中使用"Content-Encoding"字段來指示客戶端該響應(yīng)已經(jīng)被壓縮以及壓縮的算法?？蛻舳耸盏綁嚎s的響應(yīng)后，會自動解壓縮以獲取原始內(nèi)容。
- 引入了基本認(rèn)證和摘要認(rèn)證機(jī)制： ?在HTTP/1.1中，可以通過基本認(rèn)證和摘要認(rèn)證機(jī)制，在請求頭中傳遞用戶名和密碼等憑據(jù)進(jìn)行用戶身份驗(yàn)證。
- 引入了范圍請求和部分響應(yīng)機(jī)制： ?HTTP/1.1引入了范圍請求和部分響應(yīng)的功能，通過在HTTP請求頭中使用"Range"字段指定所需的資源范圍，而服務(wù)器在響應(yīng)頭中使用"206 Partial Content"狀態(tài)碼表明返回的是部分響應(yīng)，并通過"Content-Range"字段指示返回內(nèi)容的字節(jié)范圍。這使得客戶端可以請求大文件的特定部分，例如斷點(diǎn)續(xù)傳的情況下，從而避免重新下載整個(gè)文件。此外，范圍請求還能讓客戶端只獲取媒體資源的特定片段，優(yōu)化數(shù)據(jù)傳輸并提升用戶體驗(yàn)。
- 引入了分塊傳輸機(jī)制： ?HTTP/1.1引入了分塊傳輸（Chunked Transfer Encoding）機(jī)制，用于在動態(tài)內(nèi)容傳輸時(shí)，服務(wù)器無法提前確定整個(gè)內(nèi)容的長度的情況下，逐塊發(fā)送內(nèi)容。在分塊傳輸中，服務(wù)器將響應(yīng)拆分為一系列塊，每個(gè)塊都有一個(gè)獨(dú)立的大小，并使用"Transfer-Encoding: chunked"請求頭來通知客戶端有關(guān)分塊傳輸?shù)男畔ⅰ？蛻舳私邮盏皆擃^信息后，知道響應(yīng)將以分塊的形式傳輸，它可以按照指定的塊大小逐塊接收內(nèi)容，直到接收到一個(gè)長度為零的塊，表示傳輸已完成。這種機(jī)制適用于動態(tài)生成內(nèi)容、流式傳輸以及服務(wù)器長時(shí)間運(yùn)行的響應(yīng)等場景，提供了更靈活和高效的數(shù)據(jù)傳輸方式。
- 明確緩存機(jī)制： ?HTTP/1.1在HTTP/1.0的基礎(chǔ)上進(jìn)一步明確了緩存機(jī)制，服務(wù)器可以通過設(shè)置響應(yīng)頭字段來控制緩存行為，例如使用"Cache-Control"頭字段來指定緩存策略，如"max-age"用于設(shè)置資源的最大緩存時(shí)間，"no-cache"用于要求客戶端驗(yàn)證資源的有效性等。同時(shí)，服務(wù)器也可以在響應(yīng)頭中添加"Expires"頭字段，設(shè)置資源的過期時(shí)間，以便客戶端在接收到資源后在過期時(shí)間之前可以直接使用緩存的副本。另外，HTTP/1.1還支持"Last-Modified"和"If-Modified-Since"頭字段，以及"ETag"和"If-None-Match"頭字段，用于在客戶端緩存資源后，再次請求時(shí)驗(yàn)證資源是否已經(jīng)發(fā)生變化，如果未變化，服務(wù)器返回304 Not Modified狀態(tài)碼，讓客戶端使用緩存的資源，從而避免重復(fù)傳輸。通過這些頭字段的靈活組合使用，HTTP/1.1的緩存機(jī)制實(shí)現(xiàn)了更高效、可控的緩存管理，優(yōu)化了Web應(yīng)用程序的性能和用戶體驗(yàn)。
- 增強(qiáng)內(nèi)容協(xié)商機(jī)制： ?HTTP/1.1增加了Accept-Language、Accept-Encoding和Accept-Charset等頭字段，允許客戶端明確指定其首選語言、內(nèi)容編碼方式和字符集，讓服務(wù)器能夠更好地提供適配客戶端需求的內(nèi)容。此外，HTTP/1.1還引入了Vary頭字段，用于標(biāo)明服務(wù)器響應(yīng)可能因客戶端請求頭的不同而變化，這樣確保代理服務(wù)器能夠存儲和提供正確的緩存內(nèi)容。這些改進(jìn)使得HTTP/1.1的內(nèi)容協(xié)商機(jī)制更加強(qiáng)大和智能，提高了資源傳輸?shù)男屎陀脩趔w驗(yàn)。
- 添加了新的 HTTP 方法： ?HTTP/1.1新增了 PUT、PATCH、OPTIONS、DELETE方法。
- 新增了Host 頭字段： ?TTP/1.1 引入了 Host 頭字段，該字段允許在同一個(gè)物理服務(wù)器上托管多個(gè)域名。這使得虛擬主機(jī)能夠通過在 Host 頭中指定域名來區(qū)分不同的網(wǎng)站。
- 新增了狀態(tài)碼
缺陷?
- 線頭阻塞（Head-of-Line Blocking）： ?HTTP/1.1在同一連接上使用持久連接，但由于串行發(fā)送請求和響應(yīng)，如果一個(gè)請求或響應(yīng)的處理時(shí)間較長，那么后續(xù)的請求和響應(yīng)將被阻塞，為此它引入了管道化技術(shù)(pipelining)試圖解決該問題，但它并沒有完全解決這個(gè)問題，因?yàn)榧词乖诳蛻舳苏埱筮x擇某一管道并被異步發(fā)送出去，但在服務(wù)器如果該請求前面存在緩慢或繁重的請求，那么該請求就會被阻塞。這種情況也被稱為線頭阻塞
- 無法處理較多的并發(fā)請求： ?由于頭阻塞問題和單個(gè)連接的限制，HTTP/1.1在處理較多的并發(fā)請求時(shí)表現(xiàn)較差。瀏覽器限制了同時(shí)與同一域名建立的連接數(shù)，從而限制了并發(fā)請求的數(shù)量。
- 未能被充分利用的TCP： ?HTTP 1.1很難榨干TCP協(xié)議所能提供的所有性能。HTTP客戶端和瀏覽器必須要另辟蹊徑的去找到新的解決方案來降低頁面載入時(shí)間。
- 明文傳輸： ?HTTP/1.1默認(rèn)是明文傳輸，數(shù)據(jù)在網(wǎng)絡(luò)上傳輸時(shí)不加密，可能被竊聽或篡改。這會導(dǎo)致安全隱患，尤其是對于敏感信息的傳輸。
- 頭部冗余： ?HTTP/1.1的請求和響應(yīng)頭部會攜帶一些冗余的信息，導(dǎo)致了較大的頭部開銷，特別是對于小的資源請求。
- 沒有對頭字段進(jìn)行壓縮： ?HTTP/1.1沒有對頭字段進(jìn)行壓縮，盡管HTTP響應(yīng)的主體可以使用Gzip等壓縮算法，但頭字段仍然是明文傳輸，可能在一些情況下浪費(fèi)帶寬。
- 請求-響應(yīng)模式： ?HTTP/1.1使用請求-響應(yīng)模式，每個(gè)請求需要等待響應(yīng)后才能繼續(xù)。這種模式對于實(shí)時(shí)性要求較高的應(yīng)用場景，如實(shí)時(shí)通信和流媒體，效率較低。
- 缺乏推送功能： ?HTTP/1.1缺乏服務(wù)器主動向客戶端推送資源的機(jī)制?？蛻舳酥荒芡ㄟ^不斷發(fā)送請求來獲取資源，這導(dǎo)致了一定的延遲和額外的開銷。
超過 25 年的逐步擴(kuò)展?
從HTTP/1.1協(xié)議發(fā)布至今，HTTP/1.1協(xié)議已穩(wěn)定使用超過25年，目前大部分網(wǎng)站仍是基于HTTP/1.1來運(yùn)行的。這期間HTTP/1.1也做了多次擴(kuò)展與修改，并發(fā)展不同的應(yīng)用模式，以彌補(bǔ)之前的缺陷以及滿足日益進(jìn)步的需求。
HTTP 用于安全傳輸?
在1994年，網(wǎng)景通信公司（Netscape Communications Corporation）為了解決當(dāng)時(shí)互聯(lián)網(wǎng)上數(shù)據(jù)傳輸?shù)陌踩珕栴}，發(fā)布了第一個(gè)安全套接字層（Secure Sockets Layer，SSL）協(xié)議。SSL協(xié)議使用了加密技術(shù)，對HTTP的數(shù)據(jù)進(jìn)行加密傳輸，保護(hù)數(shù)據(jù)的安全性。
在SSL協(xié)議的基礎(chǔ)上，網(wǎng)景通信公司將安全傳輸?shù)墓δ苷系紿TTP協(xié)議中，形成了HTTPS協(xié)議。HTTPS使用了SSL/TLS（Transport Layer Security）協(xié)議來加密HTTP傳輸過程中的數(shù)據(jù)，使得網(wǎng)站和用戶之間的通信不再以明文傳輸，變得安全。
HTTP 用于復(fù)雜應(yīng)用?
在 2000 年，一種新的使用 HTTP 的模式被設(shè)計(jì)出來：具象狀態(tài)傳輸（representational state transfer）?(或者說 REST)。由 API 發(fā)起的操作不再通過新的 HTTP 方法傳達(dá)，而只能通過使用基本的 HTTP / 1.1 方法訪問特定的 URI。這允許任何 Web 應(yīng)用程序通過提供 API 以允許查看和修改其數(shù)據(jù)，而無需更新瀏覽器或服務(wù)器。所有需要的內(nèi)容都被嵌入到由網(wǎng)站通過標(biāo)準(zhǔn) HTTP/1.1 提供的文件中。REST 模型的缺點(diǎn)在于每個(gè)網(wǎng)站都定義了自己的非標(biāo)準(zhǔn) RESTful API，并對其進(jìn)行了全面的控制。RESTful API 在 2010 年變得非常流行。
自 2005 年以來，可用于 Web 頁面的 API 大大增加，其中幾個(gè) API 為特定目的擴(kuò)展了 HTTP 協(xié)議，大部分是新的特定 HTTP 頭：
- Server-sent events，服務(wù)器可以偶爾推送消息到瀏覽器。
- WebSocket，一個(gè)新協(xié)議，可以通過升級現(xiàn)有 HTTP 協(xié)議來建立。
SPDY——Google的嘗試(2009)?
這些年來，網(wǎng)頁愈漸變得的復(fù)雜，甚至演變成了獨(dú)有的應(yīng)用，可見媒體的播放量，增進(jìn)交互的腳本大小也增加了許多。 如果仔細(xì)觀察當(dāng)前的一些網(wǎng)站所需要下載的資源的話，會發(fā)現(xiàn)一個(gè)非常明顯的趨勢—— 近年來加載網(wǎng)站首頁需要的下載的數(shù)據(jù)量在逐漸增加，平均每個(gè)頁面為了完成顯示與渲染所需要下載的資源數(shù)已經(jīng)超過了100個(gè)。HTTP/1.1 鏈接需要請求以正確的順序發(fā)送，理論上可以用一些并行的鏈接（尤其是 5 到 8 個(gè)），帶來的成本和復(fù)雜性堪憂。比如，HTTP 管線化（pipelining）就成為了 Web 開發(fā)的負(fù)擔(dān)。HTTP 1.1很難榨干TCP協(xié)議所能提供的所有性能。HTTP客戶端和瀏覽器必須要另辟蹊徑的去找到新的解決方案來降低頁面載入時(shí)間。與此同時(shí)，人們也嘗試去用新的協(xié)議來替代TCP，但結(jié)果證明這也非常困難。無奈之下，我們只能嘗試同時(shí)改進(jìn)TCP協(xié)議本身和基于TCP的上層協(xié)議。
在 2010 年早期，谷歌通過實(shí)踐了一個(gè)實(shí)驗(yàn)性的 SPDY 協(xié)議，想要以此來解決當(dāng)前HTTP存在的問題。SPDY 的功能包括多路復(fù)用、壓縮、優(yōu)先級、安全性等。本節(jié)不打算詳細(xì)介紹 SPDY，因?yàn)槲覀冊谙乱还?jié)中深入了解 HTTP/2 的本質(zhì)時(shí)，您就會明白了，HTTP/2 主要是受到 SPDY 的啟發(fā)。
在2015年，Google決定將SPDY協(xié)議與HTTP合并，并基于SPDY的特點(diǎn)推出了HTTP/2。通過將SPDY融入HTTP/2，Google希望避免存在兩個(gè)競爭的標(biāo)準(zhǔn)，統(tǒng)一標(biāo)準(zhǔn)有利于更好地推動Web協(xié)議的發(fā)展。同時(shí)，Google宣布SPDY協(xié)議被廢棄，不再繼續(xù)作為一個(gè)獨(dú)立的協(xié)議存在，HTTP/2成為了SPDY的繼任者，并繼續(xù)在未來發(fā)展和推廣。
HTTP/2——更優(yōu)異的性能(2015)?
由于HTTP/1.1發(fā)展年限久遠(yuǎn)，用戶數(shù)量龐大，因此對于HTTP/1.1的升級需要制定非常嚴(yán)格的邊界與觀念，這也給小組成員的創(chuàng)新帶來了一些許限制。
升級的邊界與觀念?
- 必須保持早期HTTP的標(biāo)準(zhǔn)范式： ?由于HTTP/1.1使用年限久遠(yuǎn)，用戶數(shù)量龐大，使用該協(xié)議的網(wǎng)站太多了，如果改動過大且費(fèi)力，這肯定會阻礙HTTP/2.0發(fā)展。因此HTTP/2.0必須保留所有現(xiàn)有的接口、內(nèi)容、URI格式和結(jié)構(gòu)， 不需要站點(diǎn)和應(yīng)用做出改變，擁有一個(gè)最新的服務(wù)器和新點(diǎn)的瀏覽器即可升級HTTP/2.0。
- 提供HTTP1到http2服務(wù)器的代理： ?HTTP1的服務(wù)器和客戶端仍然會長期存在，所以我們必須提供HTTP/1到http2服務(wù)器的代理，并且這種代理能夠?qū)ttp2的功能一對一的映射到HTTP 1.1的客戶端。
- 不再使用小版本號： ?服務(wù)器和客戶端都必須確定自己是否完整兼容http2或者徹底不兼容。如果將來該協(xié)議需要被擴(kuò)充或者變更，那么新的協(xié)議將會是http3，而不是http 2.x。
- 降低協(xié)議對延遲的敏感
- 修復(fù)HTTP/1.1中pipelining和head of line blocking的問題
- 防止主機(jī)需求更高的連接數(shù)量
在確認(rèn)好升級邊界與觀念后，HTTP/2協(xié)議規(guī)范（RFC 7540）于2015年5月發(fā)表，HTTP/2解決了HTTP/1中存在的一大堆缺點(diǎn)，其中相當(dāng)一部分對于開發(fā)者來說非常麻煩，在HTTP/2出現(xiàn)前，開發(fā)者要用許多種變通方法來解決。
在HTTP/2.0中HTTP從一個(gè)ASCII協(xié)議變?yōu)橐粋€(gè)二進(jìn)制協(xié)議，其主要特性是多路復(fù)用（multiplexing），它可以通過同一個(gè)TCP連接發(fā)送多個(gè)邏輯數(shù)據(jù)流。復(fù)用使得很多事情變得更快更好，它帶來更好的擁塞控制、更充分的帶寬利用、更長久的TCP連接————這些都比以前更好了，鏈路能更容易實(shí)現(xiàn)全速傳輸，標(biāo)頭壓縮技術(shù)也減少了帶寬的用量。采用HTTP/2后，瀏覽器對每個(gè)主機(jī)一般只需要 一個(gè) TCP連接，而不是以前常見的 六個(gè) 連接。事實(shí)上，HTTP/2使用的連接聚合（connection coalescing）和“去分片”（desharding）技術(shù)還可以進(jìn)一步縮減連接數(shù)。HTTP/2還解決了HTTP的隊(duì)頭擁塞（head of line blocking）問題，客戶端必須等待一個(gè)請求完成才能發(fā)送下一個(gè)請求的日子過去了。
以下為HTTP/2 的請求示例
GET /zh-CN/docs/Glossary/Simple_header HTTP/2
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/zh-CN/docs/Glossary/Simple_header
以下為HTTP/2 的響應(yīng)示例
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
大家可以驚奇的發(fā)現(xiàn)，除了版本號，HTTP/2.0與HTTP/1.1在內(nèi)容與格式上幾乎沒有任何差別！這得益于早期標(biāo)準(zhǔn)制定者對HTTP/1.1升級邊界與觀念的思考，這讓標(biāo)準(zhǔn)制定者幾乎保留了HTTP/1.1內(nèi)容與形式上的所有標(biāo)準(zhǔn)，從修改HTTP底層技術(shù)來解決HTTP/1.1中的缺點(diǎn)。
也正因如此，HTTP/2.0不需 Web 開發(fā)者做什么，不需要站點(diǎn)和應(yīng)用做出改變，隨著陳舊的瀏覽器和服務(wù)器的更新，站點(diǎn)自然就會升級到HTTP/2.0而不會帶來任何問題，并且還能在數(shù)據(jù)傳輸上節(jié)省了可觀的成本和支出，這使得該協(xié)議在互聯(lián)網(wǎng)和萬維網(wǎng)上得到廣泛的實(shí)現(xiàn)和部署，HTTP/2.0取得了巨大的成功。
特性?
- HTTP/2.0是一個(gè)二進(jìn)制協(xié)議： ?在HTTP/2.0中，HTTP不再是ASCII協(xié)議，而是二進(jìn)制協(xié)議。作為一個(gè)二進(jìn)制協(xié)議，它更容易解析，但與 HTTP/1.x 不同的是，它不再被人眼讀取。HTTP/2 的主要構(gòu)建塊是幀和流，每個(gè) HTTP/2 請求和響應(yīng)都被賦予一個(gè)唯一的流 ID，并且它被分成幀。幀不過是二進(jìn)制數(shù)據(jù)，幀的集合稱為流。每個(gè)幀都有一個(gè)流 ID，用于標(biāo)識它所屬的流，并且每個(gè)幀都有一個(gè)公共標(biāo)頭（Type, Length, Flags, Stream Identifie）和幀有效負(fù)載，規(guī)范中一共定義了10種不同的幀，其中最基礎(chǔ)的兩種分別對應(yīng)于HTTP 1.1的DATA和HEADERS。此外，流 ID 是唯一的，客戶端發(fā)起的任何請求流ID都使用奇數(shù)，而來自服務(wù)器的響應(yīng)流ID則都是偶數(shù)。
- 多路復(fù)用： ?由于 HTTP/2 現(xiàn)在是二進(jìn)制協(xié)議，并且正如我上面所說，它使用幀和流來進(jìn)行請求和響應(yīng)，因此一旦打開 TCP 連接，所有流都會通過同一連接異步發(fā)送，而無需打開任何其他連接。反過來，服務(wù)器以相同的異步方式響應(yīng)，即響應(yīng)沒有順序，客戶端使用分配的流 ID 來識別特定數(shù)據(jù)包所屬的流。流的多路復(fù)用解決了 HTTP/1.x 中存在的線頭阻塞問題，即客戶端不必等待正在花費(fèi)時(shí)間的請求，其他請求仍將得到處理。
- 流優(yōu)先級（Stream Prioritization）： ?HTTP/2允許對請求/響應(yīng)進(jìn)行優(yōu)先級排序，每個(gè)流都包含一個(gè)優(yōu)先級（也就是“權(quán)重”），它被用來告訴對客戶端哪個(gè)流更重要。當(dāng)資源有限的時(shí)候，服務(wù)器會根據(jù)優(yōu)先級來選擇應(yīng)該先發(fā)送哪些流。借助于借助于PRIORITY幀，客戶端同樣可以告知服務(wù)器當(dāng)前的流依賴于其他哪個(gè)流，該功能讓客戶端能建立一個(gè)優(yōu)先級“樹”，所有“子流”會依賴于“父流”的傳輸完成情況。優(yōu)先級和依賴關(guān)系可以在傳輸過程中被動態(tài)的改變。這樣當(dāng)用戶滾動一個(gè)全是圖片的頁面的時(shí)候，瀏覽器就能夠指定哪個(gè)圖片擁有更高的優(yōu)先級?；蛘呤窃谀闱袚Q標(biāo)簽頁的時(shí)候，瀏覽器可以提升新切換到頁面所包含流的優(yōu)先級。優(yōu)先級的引入確保重要資源的優(yōu)先加載，提高了頁面加載速度和用戶體驗(yàn)。
- 頭部壓縮： ?HTTP是一種無狀態(tài)的協(xié)議。簡而言之，這意味著每個(gè)請求必須要攜帶服務(wù)器需要的所有細(xì)節(jié)，而不是讓服務(wù)器保存住之前請求的元數(shù)據(jù)，這導(dǎo)致許多請求和響應(yīng)頭部會攜帶一些冗余的一摸一樣的信息，增大了標(biāo)頭大小，致使帶寬使用和延遲增加。為了克服這個(gè)問題，HTTP/2使用HPACK算法對頭部信息進(jìn)行壓縮，減少了頭部大小，從而降低了傳輸?shù)臄?shù)據(jù)量，提高了效率。
- 服務(wù)器推送： ?HTTP/2的服務(wù)器推送功能允許服務(wù)器在客戶端請求前主動推送資源。服務(wù)器可以通過發(fā)送一個(gè)名為PUSH_PROMISE的特殊幀，通知客戶端即將推送的資源。這個(gè)PUSH_PROMISE幀與導(dǎo)致推送發(fā)生的流相關(guān)聯(lián)，并包含服務(wù)器將要推送的資源的流ID。通過服務(wù)器推送，服務(wù)器可以在客戶端請求之前主動將客戶端可能需要的資源發(fā)送到客戶端緩存中，從而避免了客戶端額外的請求，減少了延遲。這種特性在某些情況下可以提高頁面加載速度和性能，尤其是對于一些預(yù)加載資源或常用資源，可以減少客戶端請求的往返次數(shù)，優(yōu)化了Web應(yīng)用的性能和用戶體驗(yàn)。
- 中斷連接不再斷開連接： HTTP/1.1協(xié)議有一個(gè)缺點(diǎn)：當(dāng)一個(gè)含有確切值的Content-Length的HTTP消息被送出之后，你就很難中斷它了。當(dāng)然，通常你可以斷開整個(gè)TCP鏈接（但也不總是可以這樣），但這樣導(dǎo)致的代價(jià)就是需要通過三次握手來重新建立一個(gè)新的TCP連接。在http2里面，我們可以通過發(fā)送RST_STREAM幀來實(shí)現(xiàn)這種需求，它是一種特殊的幀類型，用于中止某些流，即客戶端可以發(fā)送此幀讓服務(wù)器知道我不需要此流了?？蛻舳丝梢允褂?RST_STREAM 并停止接收特定流，同時(shí)連接不會被關(guān)閉其他流仍會正常運(yùn)行。
- 可靠性和安全性： ?HTTP/2支持?jǐn)?shù)據(jù)的流量控制和優(yōu)先級設(shè)置，保障了數(shù)據(jù)的可靠傳輸。此外，HTTP/2要求使用TLS協(xié)議進(jìn)行加密通信，提高了數(shù)據(jù)的安全性。
- 兼容性： ?HTTP/2通過與HTTP/1.1的兼容性保證，使得現(xiàn)有的Web應(yīng)用可以逐漸遷移到HTTP/2，而不需要進(jìn)行大規(guī)模的更改。
HTTP/3——基于 QUIC 的 HTTP(2022)?
HTTP 的下一個(gè)主要版本，HTTP/3 有這與 HTTP 早期版本的相同語義，但在傳輸層部分使用?QUIC (en-US)?而不是?TCP。到2022年10月，26% 的網(wǎng)站正在使用 HTTP/3。
QUIC 旨在為 HTTP 連接設(shè)計(jì)更低的延遲。類似于 HTTP/2，它是一個(gè)多路復(fù)用協(xié)議，但是 HTTP/2 通過單個(gè) TCP 連接運(yùn)行，所以在 TCP 層處理的數(shù)據(jù)包丟失檢測和重傳可以阻止所有流。QUIC 通過?UDP?運(yùn)行多個(gè)流，并為每個(gè)流獨(dú)立實(shí)現(xiàn)數(shù)據(jù)包丟失檢測和重傳，因此如果發(fā)生錯(cuò)誤，只有該數(shù)據(jù)包中包含數(shù)據(jù)的流才會被阻止。
RFC 9114?定義的 HTTP/3 被大多數(shù)主流瀏覽器所支持，包括 Chromium（及其他的變體，例如 Chrome 和 Edge）和 Firefox。
(更多HTTP3的內(nèi)容會隨著發(fā)展逐步更新)
點(diǎn)擊鏈接或微信搜索“汪啊汪”??，關(guān)注我及時(shí)掌握最新動態(tài)
完整手冊可關(guān)注該倉庫，給個(gè)?
該站點(diǎn)也會同步更新
轉(zhuǎn)載需要經(jīng)過本人同意！文章來源：http://www.zghlxwxcb.cn/news/detail-839734.html
本文由mdnice多平臺發(fā)布文章來源地址http://www.zghlxwxcb.cn/news/detail-839734.html
到了這里，關(guān)于【HTTP完全注釋】爆肝萬字！讓你全面了解HTTP發(fā)展史！??！的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
