HTTP1.0
HTTP/1.0是無狀態(tài)、無連接的應(yīng)用層協(xié)議。
無連接
? 無連接：每次請求都要建立連接，需要使用 keep-alive 參數(shù)建立長連接、HTTP1.1默認(rèn)長連接keep-alive
? 無法復(fù)用連接，每次發(fā)送請求都要進(jìn)行TCP連接，TCP的連接釋放都比較費(fèi)事，會(huì)導(dǎo)致網(wǎng)絡(luò)利用率低
隊(duì)頭阻塞
? 隊(duì)頭阻塞(head of line blocking)，由于HTTP1.0規(guī)定下一個(gè)請求必須在前一個(gè)請求響應(yīng)到達(dá)之前才能發(fā)送，假設(shè)前一個(gè)請求響應(yīng)一直不到達(dá)，那么下一個(gè)請求就不發(fā)送，后面的請求就阻塞了。
緩存
在HTTP1.0中主要使用header里的協(xié)商緩存 last-modified\if-modified-since，強(qiáng)緩存 Expires來做為緩存判斷的標(biāo)準(zhǔn)
If-Modified-Since
Expires是RFC 2616（HTTP/1.0）協(xié)議中和網(wǎng)頁緩存相關(guān)字段。用來控制緩存的失效日期。
Expires 字段聲明了一個(gè)網(wǎng)頁或 URL 地址不再被瀏覽器緩存的時(shí)間，一旦超過了這個(gè)時(shí)間，瀏覽器都應(yīng)該聯(lián)系原始服務(wù)器。RFC告訴我們：“由于推斷的失效時(shí)間也許會(huì)降低語義透明度，應(yīng)該被謹(jǐn)慎使用，同時(shí)我們鼓勵(lì)原始服務(wù)器盡可能提供確切的失效時(shí)間?！?/p>
其他問題
? HOST域：認(rèn)為每個(gè)服務(wù)器綁定唯一一個(gè)IP地址，因此在請求消息的URL中沒有主機(jī)名，HTTP1.0沒有host域。而現(xiàn)在在一臺(tái)服務(wù)器上可以存在多個(gè)虛擬主機(jī)，并且它們共享一個(gè)IP地址。
? HTTP1.0不支持?jǐn)帱c(diǎn)續(xù)傳功能，每次都會(huì)傳送全部的頁面和數(shù)據(jù)。如果只需要部分?jǐn)?shù)據(jù)就會(huì)浪費(fèi)多余帶寬
?
?
?
HTTP/1.1
特點(diǎn)
-
簡單
HTTP 基本的報(bào)文格式就是 header + body，頭部信息也是 key-value 簡單文本的形式，易于理解 -
靈活、易擴(kuò)展
各類請求方法、URL、狀態(tài)碼，等每個(gè)組成都沒有固定死，開發(fā)者可以自定義與擴(kuò)充
HTTP在應(yīng)用層其下層可以靈活變化（https就是HTTP與TCP之間增加SSL/TSL安全傳輸協(xié)議） -
應(yīng)用廣泛、支持跨平臺(tái)
優(yōu)缺點(diǎn)
- 無狀態(tài)
好處：服務(wù)器不用額外資源記錄，減輕服務(wù)器負(fù)擔(dān)，提高CPU內(nèi)存利用效率
壞處：每次都要確認(rèn)驗(yàn)證信息；一般通過Cookie解決（Cookie 通過在請求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。） - 明文傳輸： 傳輸過程中信息可以抓包直接獲取，信息暴露、安全性差
- 不安全：
通信使用明文傳輸、信息泄露
不驗(yàn)證通信雙方身份、有可能進(jìn)入偽裝網(wǎng)站
無法證明報(bào)文完整性都導(dǎo)致不安全的問題
解決方式：可以用 HTTPS 的方式解決，也就是通過引入 SSL/TLS 層，使得更安全。
長連接
為了解決早期HTTP/1.0每次都要建立連接導(dǎo)致通信效率低的性能問題，因?yàn)镠TTP基于TCP/IP協(xié)議
為了解決上述 TCP 連接問題，HTTP/1.1 提出了長連接的通信方式，也叫持久連接。這種方式的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負(fù)載。
持久連接的特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。如果某個(gè) HTTP 長連接超過一定時(shí)間沒有任何數(shù)據(jù)交互，服務(wù)端就會(huì)主動(dòng)斷開這個(gè)連接。
短連接和長連接對比
管道傳輸
因?yàn)镠TTP/1.1 采用了長連接的方式，這使得管道（pipeline）網(wǎng)絡(luò)傳輸成為了可能。
即可在同一個(gè) TCP 連接里面，客戶端可以發(fā)起多個(gè)請求，只要第一個(gè)請求發(fā)出去了，不必等其回來，就可以發(fā)第二個(gè)請求出去，可以減少整體的響應(yīng)時(shí)間。
但是服務(wù)器必須按照接收請求的順序發(fā)送對這些管道化請求的響應(yīng)。
如果服務(wù)端在處理 A 請求時(shí)耗時(shí)比較長，那么后續(xù)的請求的處理都會(huì)被阻塞住，這稱為「隊(duì)頭堵塞」。
所以，HTTP/1.1 管道解決了請求的隊(duì)頭阻塞，但是沒有解決響應(yīng)的隊(duì)頭阻塞。
注意：實(shí)際上 HTTP/1.1 管道化技術(shù)不是默認(rèn)開啟，而且瀏覽器基本都沒有支持，所以后面討論HTTP/1.1 都是建立在沒有使用管道化的前提。
HTTP/1.0 比較 HTTP/1.1
HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
- 使用長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。
- 支持管道（pipeline）網(wǎng)絡(luò)傳輸，只要第一個(gè)請求發(fā)出去了，不必等其回來，就可以發(fā)第二個(gè)請求出去，可以減少整體的響應(yīng)時(shí)間
?
?
HTTP協(xié)議層次結(jié)構(gòu)圖
現(xiàn)在主流瀏覽器大部分使用的都是HTTP/1.1協(xié)議，也有部分支持HTTP/2.0；絕大部分網(wǎng)站都升級為HTTPS更保證安全性
HTTP/2.0
詳見該文章：深入理解HTTP/2.0
HTTP/2.0協(xié)議是基于HTTPS的，更加安全
相比與HTTP/1.1，HTTP/2.0增加如下幾點(diǎn)的重大優(yōu)化
頭部壓縮
HTTP2.0會(huì)壓縮（Header）部分；如果同時(shí)多個(gè)請求其頭部一樣或相似，那么協(xié)議會(huì)消除重復(fù)部分。
利用HPAK算法：在客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，就不用重復(fù)發(fā)送同樣字段了，只發(fā)送索引號(hào)，減少數(shù)據(jù)量提高速度
二進(jìn)制格式
HTTP/1.0和HTTP/1.1中，報(bào)文都是純文本的格式簡單易讀；而在2.0中采用了二進(jìn)制的格式
報(bào)頭和數(shù)據(jù)體稱為：幀（frame）-》頭信息幀（Headers Frame）和數(shù)據(jù)幀（Data Frame）
文本形式信息保存為一個(gè)一個(gè)字符，占用空間多，每個(gè)字符對應(yīng)比特位多，接受方還需要將報(bào)文轉(zhuǎn)換為二進(jìn)制，而直接用二進(jìn)制減少了傳輸數(shù)據(jù)量，提高數(shù)據(jù)傳輸效率
1.0：
2.0：
數(shù)據(jù)以數(shù)據(jù)流（stream）的形式以字節(jié)單位發(fā)送，數(shù)據(jù)包可以不按順序發(fā)送
在 HTTP/2 中每個(gè)請求或響應(yīng)的所有數(shù)據(jù)包，稱為一個(gè)數(shù)據(jù)流（Stream）。每個(gè)數(shù)據(jù)流都標(biāo)記著一個(gè)獨(dú)一無二的編號(hào)（Stream ID）；
所有HTTP2.0通信都在一個(gè)TCP鏈接上完成，這個(gè)鏈接可以承載任意流量的雙向數(shù)據(jù)流。每個(gè)數(shù)據(jù)流以消息的形式發(fā)送，而消息由一或多個(gè)幀組成。不同 Stream 的幀是可以亂序發(fā)送的（因此可以并發(fā)不同的 Stream ），因?yàn)槊總€(gè)幀的頭部會(huì)攜帶 Stream ID 信息，所以接收端可以通過 Stream ID 有序組裝成 HTTP 消息
客戶端還可以指定數(shù)據(jù)流的優(yōu)先級。優(yōu)先級高的請求，服務(wù)器就先響應(yīng)該請求
多路復(fù)用
HTTP2.0實(shí)現(xiàn)了真正的并行傳輸，它能夠在一個(gè)TCP上進(jìn)行任意數(shù)量的HTTP請求，由于其二進(jìn)制分幀特性
HTTP/2 是可以在一個(gè)連接中并發(fā)多個(gè)請求或回應(yīng)，而不用按照順序一一對應(yīng)。
移除了 HTTP/1.1 中的串行請求，不需要排隊(duì)等待，徹底解決「隊(duì)頭阻塞」問題，降低了延遲，大幅度提高了連接的利用率。
服務(wù)端推送
HTTP/2 還在一定程度上改善了傳統(tǒng)的「請求 - 應(yīng)答」工作模式，服務(wù)端不再是被動(dòng)地響應(yīng)，可以主動(dòng)向客戶端發(fā)送消息、推送額外的資源。
例如：
TCP導(dǎo)致隊(duì)頭阻塞
因?yàn)門CP面向字節(jié)流傳輸，而且保證傳輸可靠性和數(shù)據(jù)的完整性
只有TCP拿到完整連續(xù)的數(shù)據(jù)時(shí)，內(nèi)核才會(huì)將數(shù)據(jù)從緩沖區(qū)交給HTTP應(yīng)用，而只要前一個(gè)字節(jié)沒有收到，HTTP就無法從內(nèi)核緩沖區(qū)中得到數(shù)據(jù)，直到其到達(dá)，所以在此過程仍然會(huì)導(dǎo)致隊(duì)頭阻塞
圖中發(fā)送方發(fā)送了很多個(gè) packet，每個(gè) packet 都有自己的序號(hào)，你可以認(rèn)為是 TCP 的序列號(hào)，其中 packet 3 在網(wǎng)絡(luò)中丟失了，即使 packet 4-6 被接收方收到后，由于內(nèi)核中的 TCP 數(shù)據(jù)不是連續(xù)的，于是接收方的應(yīng)用層就無法從內(nèi)核中讀取到，只有等到 packet 3 重傳后，接收方的應(yīng)用層才可以從內(nèi)核中讀取到數(shù)據(jù)，這就是 HTTP/2 的隊(duì)頭阻塞問題，是在 TCP 層面發(fā)生的。
因此如果出現(xiàn)丟包就會(huì)觸發(fā)TCP的超時(shí)重傳，這樣后續(xù)緩沖隊(duì)列中所有數(shù)據(jù)都得等丟了的重傳
HTTP/3.0
（仍在學(xué)習(xí)中…后續(xù)完善）
基于Google的QUIC，HTTP3 背后的主要思想是放棄 TCP，轉(zhuǎn)而使用基于 UDP 的 QUIC 協(xié)議。
為了解決HTTP/2.0中TCP造成的隊(duì)頭阻塞問題，HTTP/3.0直接放棄使用TCP，將傳輸層協(xié)議改成UDP；但是因?yàn)閁DP是不可靠傳輸，所以這就需要QUIC實(shí)現(xiàn)可靠機(jī)制
QUIC 也是需要三次握手來建立連接的，主要目的是為了確定連接 ID。
可以學(xué)一下這篇文章：QUIC詳解（用UDP實(shí)現(xiàn)可靠協(xié)議）
在 UDP 報(bào)文頭部與 HTTP 消息之間，共有 3 層頭部：
QUIC特點(diǎn)：
無隊(duì)頭阻塞
QUIC 協(xié)議也有類似 HTTP/2 Stream 與多路復(fù)用的概念，也是可以在同一條連接上并發(fā)傳輸多個(gè) Stream，Stream 可以認(rèn)為就是一條 HTTP 請求。
QUIC 有自己的一套機(jī)制可以保證傳輸?shù)目煽啃缘?。?dāng)某個(gè)流發(fā)生丟包時(shí)，只會(huì)阻塞這個(gè)流，其他流不會(huì)受到影響，因此不存在隊(duì)頭阻塞問題。這與 HTTP/2 不同，HTTP/2 只要某個(gè)流中的數(shù)據(jù)包丟失了，其他流也會(huì)因此受影響。
所以，QUIC 連接上的多個(gè) Stream 之間并沒有依賴，都是獨(dú)立的，某個(gè)流發(fā)生丟包了，只會(huì)影響該流，其他流不受影響。
連接建立
HTTP/3 在傳輸數(shù)據(jù)前雖然需要 QUIC 協(xié)議握手，這個(gè)握手過程只需要 1 RTT，握手的目的是為確認(rèn)雙方的「連接 ID」，連接遷移就是基于連接 ID 實(shí)現(xiàn)的。
連接遷移
基于 TCP 傳輸協(xié)議的 HTTP 協(xié)議，由于是通過四元組（源 IP、源端口、目的 IP、目的端口）確定一條 TCP 連接，例如設(shè)備要連接wifi（IP地址改變）就必須要重新建立連接，而建立連接包含TCP三次握手和TSL四次握手，以及TCP慢啟動(dòng)所以會(huì)造成使用者卡頓的感覺
而QUIC通過連接ID標(biāo)記自己，客戶端和服務(wù)器可以各自選擇一組 ID 來標(biāo)記自己，因此即使移動(dòng)設(shè)備的網(wǎng)絡(luò)變化后，導(dǎo)致 IP 地址變化了，只要有上下文信息（比如連接 ID、TLS 密鑰等），就可以“無縫”地復(fù)用原連接，消除重連的成本，沒有絲毫卡頓感，達(dá)到了連接遷移的功能。
其實(shí)， QUIC 是一個(gè)在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路復(fù)用的協(xié)議。
?
?
?
?
?
?文章來源：http://www.zghlxwxcb.cn/news/detail-787873.html
部分圖片來源《圖解HTTP》、《圖解網(wǎng)絡(luò)——小林coding》文章來源地址http://www.zghlxwxcb.cn/news/detail-787873.html
到了這里，關(guān)于詳解HTTP協(xié)議版本（HTTP/1.0、1.1、2.0、3.0區(qū)別）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
