HTTP史記-從HTTP/1到HTTP/3
誕生
說起http必然先了解 《萬維網(wǎng)（World Wide Web）》簡稱WWW。
WWW是基于客戶機 <=> 服務(wù)器方式 '利用鏈接跳轉(zhuǎn)站點' 和 '傳輸超文本標記語言(HTML)' 的技術(shù)綜合。
1989年仲夏之夜，蒂姆·伯納斯·李成功開發(fā)出世界上第一個Web服務(wù)器和第一個Web客戶機，這個時候能做的還只是一本電子版的電話號碼簿。
而HTTP (HyperText Transfer Protocol) 是萬維網(wǎng)的基礎(chǔ)協(xié)議，制定了瀏覽器與服務(wù)器之間的通訊規(guī)則。
通常使用的網(wǎng)絡(luò)(包括互聯(lián)網(wǎng))是在TCP/IP協(xié)議族的基礎(chǔ)上動作的。而HTTP屬于它的內(nèi)部的一個子集。
http不斷的實現(xiàn)更多功能，到目前從HTTP 0.9已經(jīng)演化到了HTTP 3.0。
HTTP/0.9
HTTP問世之初并沒有作為標準建立，被正式制定為標準是在1996年公布的HTTP/1.0協(xié)議。因此，在這之前的協(xié)議被稱為HTTP/0.9。
request只有一行且只有一個GET命令，命令后面跟著的是資源路徑。
GET /index.$html$
reponse僅包含文件內(nèi)容本身。
<html>
<body>HELLO WORLD!</body>
</html>
HTTP/0.9沒有header的概念，也沒有content-type的概念，僅能傳遞html文件。同樣由于沒有status code，當發(fā)生錯誤的時候是通過傳遞回一個包含錯誤描述的html文件來處理的。
HTTP/1.0
隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，HTTP協(xié)議被使用的越來越廣泛，協(xié)議本身的局限性已經(jīng)不能滿足互聯(lián)網(wǎng)功能的多樣性。因此，1996年5月HTTP/1.0誕生，其內(nèi)容和功能都大大增加了。對比與HTTP/0.9，新的版本包含了以下功能：
- 在每個request的GET一行后面添加版本號
- 在response第一行中添加狀態(tài)行
- 在request和response中添加header的概念
- 在header中添加content-type以此可以傳輸html之外類型的文件
- 在header中添加content-encoding來支持不同編碼格式文件的傳輸
- 引入了POST和HEAD命令
- 支持長連接（默認短連接）
GET /index.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html；charset=utf-8 // 類型，編碼。
<HTML>
A page with an image
<IMG src="/image.gif">
<HTML>
content
簡單的文字頁面自然無法滿足用戶的需求，于是1.0加入了更多的文件類型：
常見Content-Type | ||
text/plan | text/html | text/css |
image/jpeg | image/png | image/svg + xml |
application/javascript | application/zip | application/pdf |
也同樣可以用在html中。
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Content-encoding
由于支持任意數(shù)據(jù)格式的發(fā)送，因此可以先把數(shù)據(jù)進行壓縮再發(fā)送。HTTP/1.0進入了Content-Encoding來表示數(shù)據(jù)的壓縮方式。
- Content-Encoding: gzip?！颈硎静捎?Lempel-Ziv coding (LZ77) 壓縮算法，以及32位CRC校驗的編碼方式】。
- Content-Encoding: compress?！静捎?Lempel-Ziv-Welch (LZW) 壓縮算法】。
- Content-Encoding: deflate?！静捎?zlib 】。
客戶端發(fā)送請求帶有表明我可以接受gzip、deflate兩種壓縮方式。
Accept-Encoding: gzip, deflate
服務(wù)器在 Content-Encoding 響應(yīng)首部提供了實際采用的壓縮模式。
Content-Encoding: gzip
HTTP/1.0 缺點
- 隊頭阻塞（Head-of-Line Blocking? ，每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接。
- 默認是短連接，即每個HTTP請求都要使用TCP協(xié)議通過三次握手和四次揮手實現(xiàn)。
- 僅定義了16種狀態(tài)碼。
HTTP/1.1
僅僅在HTTP/1.0公布后的幾個月，HTTP/1.1發(fā)布了，到目前為止HTTP1.1協(xié)議都是作為主流的版本，以至于隨后的近10年時間里都沒有新的HTTP協(xié)議版本發(fā)布。
對比之前的版本，其主要更新如下：
- 可以重復(fù)使用連接（keep-alive），從而節(jié)省時間，不再需要多次打開才能顯示嵌入在單個原始文檔中的資源。
- 添加了Pipeline，這允許在第一個請求的答案完全傳輸之前發(fā)送第二個請求這降低了通信的延遲。
- chunked機制，分塊響應(yīng)。
- 引入了額外的緩存控制機制。
- 引入了內(nèi)容協(xié)商，包括語言、編碼和類型，客戶端和服務(wù)器現(xiàn)在可以就交換哪些內(nèi)容達成一致。
- 由于Host標頭，從同一 IP 地址托管不同域的能力允許服務(wù)器搭配。
keep-alive
由于建立一個連接的過程需要DNS解析過程以及TCP的三次握手，但在同服務(wù)器獲取資源不斷的建立和斷開鏈接需要消耗的資源和時間是巨大的，為了提升連接的效率 HTTP/1.1的及時出現(xiàn)將長連接加入了標準并作為默認實現(xiàn)，服務(wù)器端也按照協(xié)議保持客戶端的長連接狀態(tài)，一個服務(wù)端上的多個資源都可以通過這一條連接多個request來獲取。
可以在request header中引入如下信息來告知服務(wù)器完成一次request請求后不要關(guān)閉連接。
Connection: keep-alive
服務(wù)器端也會答復(fù)一個相同的信息表示連接仍然有效，但是在當時這只是屬于程序員的自定義行為，在1.0中沒有被納入標準。這其中的提升對于通訊之間的效率提升幾乎是倍增的，
這也為管線化方式（pipelining）打下基礎(chǔ)。
Pipeline （管線化）
HTTP/1.1嘗試通過HTTP管線化技術(shù)來解決性能瓶頸，誕生了pipeline機制，如圖從每次response返回結(jié)果才能進行下一次request，變?yōu)橐淮芜B接上多個http request不需要等待response就可以連續(xù)發(fā)送的技術(shù)。
不幸的是因為HTTP是一個無狀態(tài)的協(xié)議，一個體積很大的或慢response仍然會阻塞后面所有的請求，每條request無法知道哪條response是返回給他的，服務(wù)端只能根據(jù)順序來返回response，這就是隊頭阻塞，這導(dǎo)致主流瀏覽器上默認下該功能都是關(guān)閉狀態(tài)，在http2.0中會解決這個問題。
host頭域
在 HTTP1.0 中認為每臺服務(wù)器都綁定一個唯一的 IP 地址，因此，請求消息中的 URL 并沒有傳遞主機名（hostname）,1.1中新增的host用來處理一個 IP 地址上面多個虛擬主機的情況。
在請求頭域中新增了Host字段，其用來指定服務(wù)器的域名。有了Host字段，在同一臺服務(wù)器上就可以搭建不同的網(wǎng)站了，這也為后來虛擬化的發(fā)展建好啦地基。
Host: www.alibaba-inc.com
cache機制
Cache不僅可以提高用戶的訪問速率，在移動端設(shè)備上還可以為用戶極大節(jié)省流量。因此，在HTTP/1.1中新增了很多與Cache相關(guān)的頭域并圍繞這些頭域設(shè)計了更靈活、更豐富的Cache機制。
Cache機制需要解決的問題包括：
- 判斷哪些資源可以被Cache及訪問訪問策略。
- 在本地判斷Cache資源是否已經(jīng)過期。
- 向服務(wù)端發(fā)起問詢，查看已過期的Cache資源是否在服務(wù)端發(fā)生了變化。
chunked機制
建立好鏈接之后客戶端可以使用該鏈接發(fā)送多個請求，用戶通常會通過response header中返回的Content-Length來判斷服務(wù)端返回數(shù)據(jù)的大小。但隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，越來越多的動態(tài)資源被引入進來，這時候服務(wù)端就無法在傳輸之前知道待傳遞資源的大小，也就無法通過Content-Length來告知用戶資源大小。服務(wù)器可以一邊動態(tài)產(chǎn)生資源，一邊傳遞給用戶，這種機制稱為“分塊傳輸編碼”（Chunkded Transfer Encoding），允許服務(wù)端發(fā)送給客戶端的數(shù)據(jù)分為多個部分，此時服務(wù)器端需要在header中添加“Transfer-Encoding: chunked”頭域來替代傳統(tǒng)的“Content-Length。
Transfer-Encoding: chunked
HTTP 緩存機制
相比 HTTP 1.0，HTTP 1.1 新增了若干項緩存機制：
強緩存
強緩存，是瀏覽器優(yōu)先命中的緩存，速度最快。當我們在狀態(tài)碼后面看到 (from memory disk) 時，就表示瀏覽器從內(nèi)存中讀取了緩存，當進程結(jié)束后，也就是 tab 關(guān)閉以后，內(nèi)存里的數(shù)據(jù)也將不復(fù)存在。只有當強緩存不被命中的時候，才會進行協(xié)商緩存的查找。
Pragma
Pragma頭域是HTTP/1.0的產(chǎn)物。目前僅作為與HTTP/1.0的向后兼容而定義。它現(xiàn)在僅在請求首部中出現(xiàn)，表示要求所有中間服務(wù)器不返回緩存的資源，與Cache-Control: no-cache的意義相同。
Pragma: no-cache
Expires
Expires僅在響應(yīng)頭域中出現(xiàn)，表示資源的時效性當發(fā)生請求時，瀏覽器將會把 Expires 的值與本地時間進行對比，如果本地時間小于設(shè)置的時間，則讀取緩存。
Expires 的值為標準的 GMT 格式：
Expires: Wed, 21 Oct 2015 07:28:00 GMT
這里需要注意的是：當header中同時存在Cache-Control: max-age=xx和Expires的時候，以Cache-Control: max-age的時間為準。
Cache-Control
由于 Expires 的局限性， Cache-Control 登場了， 下面說明幾個常用的字段：
- no-store：緩存不應(yīng)存儲有關(guān)客戶端請求或服務(wù)器響應(yīng)的任何內(nèi)容。
- no-cache：在發(fā)布緩存副本之前，強制要求緩存把請求提交給原始服務(wù)器進行驗證。
- max-age：相對過期時間，單位為秒(s)，告知服務(wù)器資源在多少以內(nèi)是有效的，無需向服務(wù)器請求。
協(xié)商緩存
當瀏覽器沒有命中強緩存后，便會命中協(xié)商緩存，協(xié)商緩存由以下幾個 HTTP 字段控制。
Last-Modified
服務(wù)端將資源傳送給客戶端的時候，會將資源最后的修改時間以 Last-Modified: GMT 的形式加在實體首部上返回。
Last-Modified: Fri, 22 Jul 2019 01:47:00 GMT
客戶端接收到后會為此資源信息做上標記，等下次重新請求該資源的時候?qū)蠒r間信息給服務(wù)器做檢查，若傳遞的值與服務(wù)器上的值一致，則返回 304 ，表示文件沒有被修改過，若時間不一致，則重新進行資源請求并返回 200。
優(yōu)先級
強緩存 --> 協(xié)商緩存Cache-Control -> Expires -> ETag -> Last-Modified。
新增了五種請求方法
OPTIONS：瀏覽器為確定跨域請求資源的安全做的預(yù)請求。
PUT：從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
DELETE ：請求服務(wù)器刪除指定的頁面。
TRACE：回顯服務(wù)器收到的請求，主要用于測試或診斷。
CONNECT：HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
新增一系列的狀態(tài)碼
可以參考狀態(tài)碼大全
Http1.1缺陷
- 高延遲，帶來頁面加載速度的降低，（網(wǎng)絡(luò)延遲問題只要由于隊頭阻塞，導(dǎo)致寬帶無法被充分利用）。
- 無狀態(tài)特性，帶來巨大的Http頭部。
- 明文傳輸，不安全。
- 不支持服務(wù)器推送消息。
HTTP/2.0
根據(jù)時代的發(fā)展網(wǎng)頁變得更加復(fù)雜。其中一些甚至本身就是應(yīng)用程序。顯示了更多的視覺媒體，增加了交互性的腳本的數(shù)量和大小也增加了。更多的數(shù)據(jù)通過更多的 HTTP 請求傳輸，這為 HTTP/1.1 連接帶來了更多的復(fù)雜性和開銷。為此，谷歌在 2010 年代初實施了一個實驗性協(xié)議 SPDY。鑒于SPDY的成功，HTTP/2也采用了SPDY作為整個方案的藍圖進行開發(fā)。HTTP/2 于 2015 年 5 月正式標準化。
HTTP/2 與 HTTP/1.1 區(qū)別：
- 二進制幀層。
- 多路復(fù)用協(xié)議。可以通過同一連接發(fā)出并行請求，從而消除 HTTP/1.x 協(xié)議的約束。
- 頭部壓縮算法HPACK。由于一些請求在一組請求中通常是相似的，因此這消除了傳輸數(shù)據(jù)的重復(fù)和開銷。
- 它允許服務(wù)器通過稱為服務(wù)器推送的機制在客戶端緩存中填充數(shù)據(jù)一張圖來理解HTTP/2 和 HTTP/1.1。
Header壓縮
HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，為 HTTP/2 的專門量身打造的 HPACK 便是類似這樣的思路延伸。它使用一份索引表來定義常用的 HTTP Header，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮 ?/p>
看上去協(xié)議的格式和HTTP1.x完全不同了，實際上HTTP2并沒有改變HTTP1.x的語義，只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已。
多路復(fù)用
為了解決HTTP/1.x中存在的隊頭阻塞問題，HTTP/2提出了多路復(fù)用的概念。即將一個request/response作為一個stream，并將一個stream根據(jù)負載分為多種類型的frame（例如 header frame，data frame等），在同一條connection之上可以混合發(fā)送分屬于不同stream的frame，這樣就實現(xiàn)了同時發(fā)送多個request的功能，多路復(fù)用意味著線頭阻塞將不再是一個問題。
HTTP/2 雖然通過多路復(fù)用解決了 HTTP 層的隊頭阻塞，但仍然存在 TCP 層的隊頭阻塞。
服務(wù)端推送 server push
服務(wù)可以主動向客戶端發(fā)送消息。在瀏覽器剛請求 HTML 的時候，服務(wù)端會把某些資源存在一定的關(guān)聯(lián)性 JS、CSS 等文件等靜態(tài)資源主動發(fā)給客戶端，這樣客戶端可以直接從本地加載這些資源，不用再通過網(wǎng)絡(luò)再次請求，以此來達到節(jié)省瀏覽器發(fā)送request請求的過程。
使用服務(wù)器推送
Link: </css/styles.css>; rel=preload; as=style，
</img/example.png>; rel=preload; as=image
可以看到服務(wù)器initiator中的push狀態(tài)表示這是服務(wù)端進行主動推送。
對于主動推送的文件勢必會帶來多余或已經(jīng)瀏覽器已有一份的文件
客戶端使用一個簡潔的 Cache Digest 來告訴服務(wù)器，哪些東西已經(jīng)在緩存，因此服務(wù)器也就會知道哪些是客戶端所需要的。
流
服務(wù)器和客戶端在HTTP/2連接內(nèi)用于交換幀數(shù)據(jù)的獨立雙向序列，HTTP/2 在單個 TCP 連接上虛擬出多個 Stream, 多個 Stream 實現(xiàn)對一個 TCP 連接的多路復(fù)用, 為了合理地利用傳輸鏈路, 實現(xiàn)在有限資源內(nèi)達到傳輸性能的最優(yōu)化。
所有的通信都建立在一個TCP連接上，可以傳遞大量的雙向流通的流。
每個流都有獨一無二的標志和優(yōu)先級。
每個消息都是邏輯上的請求和相應(yīng)消息。由一個或者多個幀組成。
來自不同流的幀可以通過幀頭的標志來關(guān)聯(lián)和組裝起來。
流的概念提出是為了實現(xiàn)多路復(fù)用，在單個連接上實現(xiàn)同時進行多個業(yè)務(wù)單元數(shù)據(jù)的傳輸。
二進制幀層
在HTTP/1.x中,用戶為了提高性能建立多個TCP連接.會導(dǎo)致隊頭阻塞和重要TCP連接不能穩(wěn)定獲得。HTTP/2中的二進制幀層允許請求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進制編碼(http1.0基于文本格式)。多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流（比如每個流都有自己的id）表示可以重新組裝。
顯然這對二進制的計算機是非常友好，無需再將收到明文的報文轉(zhuǎn)成二進制，而是直接解析二進制報文，進一步提高數(shù)據(jù)傳輸?shù)男省?/p>
每一個幀可看做是一個學(xué)生，流是小組（流標識符為幀的屬性值），一個班級（一個連接）內(nèi)學(xué)生被分為若干個小組，每一個小組分配不同的具體任務(wù)，多個小組任務(wù)可同時并行在班級內(nèi)執(zhí)行。一旦某個小組任務(wù)耗時嚴重，但不會影響到其它小組任務(wù)正常執(zhí)行。
最后我們來看一看理想狀態(tài)下http2帶來的提升。
缺點
- TCP以及TCP+TLS建立連接的延遲（握手延遲）。
- http2.0中TCP的隊頭阻塞依然沒有徹底解決，連接雙方的有任一個數(shù)據(jù)包丟失，或任一方的網(wǎng)絡(luò)中斷，整個TCP連接就會暫停，丟失的數(shù)據(jù)包需要被重新傳輸，從而阻塞該TCP連接中的所有請求，反而在網(wǎng)絡(luò)較差或不穩(wěn)定情況下，使用多個連接表現(xiàn)更好。
HTTP/3.0 (HTTP-over-QUIC)
在限定條件下，TCP下解決隊頭阻塞的問題相當困難，但是隨著互聯(lián)網(wǎng)的爆炸式發(fā)展，更高的穩(wěn)定性和安全性需要得到滿足，谷歌在2016年11月國際互聯(lián)網(wǎng)工程任務(wù)組(IETF)召開了第一次QUIC（Quick UDP Internet Connections）工作組會議，制定的一種基于UDP的低時延的互聯(lián)網(wǎng)傳輸層協(xié)議，HTTP-over-QUIC于2018年11月更名為HTTP/3。
0-RTT 握手
tcp中客戶端發(fā)送syn包(syn seq=x)到服務(wù)器, 服務(wù)器接收并且需要發(fā)送(SYN seq =y; ACK x+1)包給客戶端，客戶端向服務(wù)器發(fā)送確認包ACK(seq = x+1; ack=y+1)，至此客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次握手。
1-RTT
- 客服端生成一個隨機數(shù) a 然后選擇一個公開的加密數(shù) X ，通過計算得出 a*X = A, 將X 和 A發(fā)送給服務(wù)端。
- 客服端生成一個隨機數(shù) b，通過計算得出 b*X = B, 將B發(fā)送給服務(wù)端。
- 客戶端使用ECDH生成通訊密鑰 key = aB = a(b*X)。
- 服務(wù)器使用ECDH生成通訊密鑰 key = bA = b(a*X)。
sequenceDiagram
客服端->>服務(wù)端: clinet Hello
服務(wù)端-->>客服端: Server Hello
所以，這里的關(guān)鍵就是 ECDH 算法，a 和 b 是客戶端和服務(wù)器的私鑰，是不公開的,即使知道 A、X，通過 A = a*X 公式也是無法推導(dǎo)出 a 的，保證了私鑰的安全性。
0-RTT
0-RTT則是客戶端緩存了 ServerConfig（B=b*X），下次建連直接使用緩存數(shù)據(jù)計算通信密鑰：
sequenceDiagram
客服端->>服務(wù)端: clinet Hello + 應(yīng)用數(shù)據(jù)
服務(wù)端-->>客服端: ACK
- 客戶端：生成隨機數(shù) c，選擇公開的大數(shù) X，計算 A=cX，將 A 和 X 發(fā)送給服務(wù)器，也就是 Client Hello 消息后，客戶端直接使用緩存的 B 計算通信密鑰 KEY = cB = cbX，加密發(fā)送應(yīng)用數(shù)據(jù)。
- 服務(wù)器：根據(jù) Client Hello 消息計算通信密鑰 key = bA = b(c*X)。
客戶端不需要經(jīng)過握手直接通過緩存的B生成key就可以發(fā)送應(yīng)用數(shù)據(jù)。
再來思考一個問題：假設(shè)攻擊者記錄下所有的通信數(shù)據(jù)和公開參數(shù)A1，A2，一旦服務(wù)器的隨機數(shù) b（私鑰）泄漏了，那之前通信的所有數(shù)據(jù)就都可以破解了。
為了解決這個問題，需要為每次會話都創(chuàng)建一個新的通信密鑰，來保證前向安全性。
有序交付
QUIC 是基于 UDP 協(xié)議的，而 UDP 是不可靠傳輸協(xié)議，QUIC 在每個數(shù)據(jù)包都設(shè)有一個 offset 字段（偏移量），接收端根據(jù) offset 字段就可以對異步到達的數(shù)據(jù)包進行排序了，保證了有序性。
sequenceDiagram
客服端->>服務(wù)端: PKN=1；offset=0
客服端->>服務(wù)端: PKN=2；offset=1
客服端->>服務(wù)端: PKN=3；offset=2
服務(wù)端-->>客服端: SACK = 1，3
客服端->>服務(wù)端: 重傳：PKN=4；offset=1
隊頭堵塞
HTTP/2 之所以存在 TCP 層的隊頭阻塞，是因為所有請求流都共享一個滑動窗口，而QUIC中給每個請求流都分配一個獨立的滑動窗口。
A 請求流上的丟包不會影響 B 請求流上的數(shù)據(jù)發(fā)送。但是，對于每個請求流而言，也是存在隊頭阻塞問題的，也就是說，雖然 QUIC 解決了 TCP 層的隊頭阻塞，但仍然存在單條流上的隊頭阻塞。這就是 QUIC 聲明的無隊頭阻塞的多路復(fù)用。
連接遷移
連接遷移：當客戶端切換網(wǎng)絡(luò)時，和服務(wù)器的連接并不會斷開，仍然可以正常通信，對于 TCP 協(xié)議而言，這是不可能做到的。因為 TCP 的連接基于 4 元組：源 IP、源端口、目的 IP、目的端口，只要其中 1 個發(fā)生變化，就需要重新建立連接。但 QUIC 的連接是基于 64 位的 Connection ID，網(wǎng)絡(luò)切換并不會影響 Connection ID 的變化，連接在邏輯上仍然是通的。
假設(shè)客戶端先使用 IP1 發(fā)送了 1 和 2 數(shù)據(jù)包，之后切換網(wǎng)絡(luò)，IP 變更為 IP2，發(fā)送了 3 和 4 數(shù)據(jù)包，服務(wù)器根據(jù)數(shù)據(jù)包頭部的 Connection ID 字段可以判斷這 4 個包是來自于同一個客戶端。QUIC 能實現(xiàn)連接遷移的根本原因是底層使用 UDP 協(xié)議就是面向無連接的。
最后我們一張圖來看一下http的升級。
