HTTP史記-從HTTP/1到HTTP/3

作者：權(quán)明揚(yáng) 2022-06-21 10:10:14

網(wǎng)絡(luò) 通信技術(shù)

HTTP問(wèn)世之初并沒(méi)有作為標(biāo)準(zhǔn)建立，被正式制定為標(biāo)準(zhǔn)是在1996年公布的HTTP/1.0協(xié)議。因此，在這之前的協(xié)議被稱為HTTP/0.9。

誕生

說(shuō)起http必然先了解《萬(wàn)維網(wǎng)（World Wide Web）》簡(jiǎn)稱WWW。

WWW是基于客戶機(jī) <=> 服務(wù)器方式 '利用鏈接跳轉(zhuǎn)站點(diǎn)' 和 '傳輸超文本標(biāo)記語(yǔ)言(HTML)' 的技術(shù)綜合。

1989年仲夏之夜，蒂姆·伯納斯·李成功開(kāi)發(fā)出世界上第一個(gè)Web服務(wù)器和第一個(gè)Web客戶機(jī)，這個(gè)時(shí)候能做的還只是一本電子版的電話號(hào)碼簿。

而HTTP (HyperText Transfer Protocol) 是萬(wàn)維網(wǎng)的基礎(chǔ)協(xié)議，制定了瀏覽器與服務(wù)器之間的通訊規(guī)則。

通常使用的網(wǎng)絡(luò)(包括互聯(lián)網(wǎng))是在TCP/IP協(xié)議族的基礎(chǔ)上動(dòng)作的。而HTTP屬于它的內(nèi)部的一個(gè)子集。

http不斷的實(shí)現(xiàn)更多功能，到目前從HTTP 0.9已經(jīng)演化到了HTTP 3.0。

HTTP/0.9

request只有一行且只有一個(gè)GET命令，命令后面跟著的是資源路徑。

GET /index.$html$

reponse僅包含文件內(nèi)容本身。

<html>
  <body>HELLO WORLD!</body>
</html>

HTTP/0.9沒(méi)有header的概念，也沒(méi)有content-type的概念，僅能傳遞html文件。同樣由于沒(méi)有status code，當(dāng)發(fā)生錯(cuò)誤的時(shí)候是通過(guò)傳遞回一個(gè)包含錯(cuò)誤描述的html文件來(lái)處理的。

HTTP/1.0

隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，HTTP協(xié)議被使用的越來(lái)越廣泛，協(xié)議本身的局限性已經(jīng)不能滿足互聯(lián)網(wǎng)功能的多樣性。因此，1996年5月HTTP/1.0誕生，其內(nèi)容和功能都大大增加了。對(duì)比與HTTP/0.9，新的版本包含了以下功能：

在每個(gè)request的GET一行后面添加版本號(hào)
在response第一行中添加狀態(tài)行
在request和response中添加header的概念
在header中添加content-type以此可以傳輸html之外類(lèi)型的文件
在header中添加content-encoding來(lái)支持不同編碼格式文件的傳輸
引入了POST和HEAD命令
支持長(zhǎng)連接（默認(rèn)短連接）

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 // 類(lèi)型，編碼。
<HTML>
A page with an image
  <IMG src="/image.gif">
<HTML>

content

簡(jiǎn)單的文字頁(yè)面自然無(wú)法滿足用戶的需求，于是1.0加入了更多的文件類(lèi)型：

常見(jiàn)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ù)進(jìn)行壓縮再發(fā)送。HTTP/1.0進(jìn)入了Content-Encoding來(lái)表示數(shù)據(jù)的壓縮方式。

Content-Encoding: gzip。【表示采用 Lempel-Ziv coding (LZ77) 壓縮算法，以及32位CRC校驗(yàn)的編碼方式】。
Content-Encoding: compress。【采用 Lempel-Ziv-Welch (LZW) 壓縮算法】。
Content-Encoding: deflate。【采用 zlib 】。

客戶端發(fā)送請(qǐng)求帶有表明我可以接受gzip、deflate兩種壓縮方式。

Accept-Encoding: gzip, deflate

服務(wù)器在 Content-Encoding 響應(yīng)首部提供了實(shí)際采用的壓縮模式。

Content-Encoding: gzip

HTTP/1.0 缺點(diǎn)

隊(duì)頭阻塞（Head-of-Line Blocking? ，每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請(qǐng)求其他資源，就必須再新建一個(gè)連接。
默認(rèn)是短連接，即每個(gè)HTTP請(qǐng)求都要使用TCP協(xié)議通過(guò)三次握手和四次揮手實(shí)現(xiàn)。
僅定義了16種狀態(tài)碼。

HTTP/1.1

僅僅在HTTP/1.0公布后的幾個(gè)月，HTTP/1.1發(fā)布了，到目前為止HTTP1.1協(xié)議都是作為主流的版本，以至于隨后的近10年時(shí)間里都沒(méi)有新的HTTP協(xié)議版本發(fā)布。

對(duì)比之前的版本，其主要更新如下：

可以重復(fù)使用連接（keep-alive），從而節(jié)省時(shí)間，不再需要多次打開(kāi)才能顯示嵌入在單個(gè)原始文檔中的資源。
添加了Pipeline，這允許在第一個(gè)請(qǐng)求的答案完全傳輸之前發(fā)送第二個(gè)請(qǐng)求這降低了通信的延遲。
chunked機(jī)制，分塊響應(yīng)。
引入了額外的緩存控制機(jī)制。
引入了內(nèi)容協(xié)商，包括語(yǔ)言、編碼和類(lèi)型，客戶端和服務(wù)器現(xiàn)在可以就交換哪些內(nèi)容達(dá)成一致。
由于Host標(biāo)頭，從同一 IP 地址托管不同域的能力允許服務(wù)器搭配。

keep-alive

由于建立一個(gè)連接的過(guò)程需要DNS解析過(guò)程以及TCP的三次握手，但在同服務(wù)器獲取資源不斷的建立和斷開(kāi)鏈接需要消耗的資源和時(shí)間是巨大的，為了提升連接的效率 HTTP/1.1的及時(shí)出現(xiàn)將長(zhǎng)連接加入了標(biāo)準(zhǔn)并作為默認(rèn)實(shí)現(xiàn)，服務(wù)器端也按照協(xié)議保持客戶端的長(zhǎng)連接狀態(tài)，一個(gè)服務(wù)端上的多個(gè)資源都可以通過(guò)這一條連接多個(gè)request來(lái)獲取。

可以在request header中引入如下信息來(lái)告知服務(wù)器完成一次request請(qǐng)求后不要關(guān)閉連接。

Connection: keep-alive

服務(wù)器端也會(huì)答復(fù)一個(gè)相同的信息表示連接仍然有效，但是在當(dāng)時(shí)這只是屬于程序員的自定義行為，在1.0中沒(méi)有被納入標(biāo)準(zhǔn)。這其中的提升對(duì)于通訊之間的效率提升幾乎是倍增的，

這也為管線化方式（pipelining）打下基礎(chǔ)。

Pipeline （管線化）

HTTP/1.1嘗試通過(guò)HTTP管線化技術(shù)來(lái)解決性能瓶頸，誕生了pipeline機(jī)制，如圖從每次response返回結(jié)果才能進(jìn)行下一次request，變?yōu)橐淮芜B接上多個(gè)http request不需要等待response就可以連續(xù)發(fā)送的技術(shù)。

不幸的是因?yàn)镠TTP是一個(gè)無(wú)狀態(tài)的協(xié)議，一個(gè)體積很大的或慢response仍然會(huì)阻塞后面所有的請(qǐng)求，每條request無(wú)法知道哪條response是返回給他的，服務(wù)端只能根據(jù)順序來(lái)返回response，這就是隊(duì)頭阻塞，這導(dǎo)致主流瀏覽器上默認(rèn)下該功能都是關(guān)閉狀態(tài)，在http2.0中會(huì)解決這個(gè)問(wèn)題。

host頭域

在 HTTP1.0 中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的 IP 地址，因此，請(qǐng)求消息中的 URL 并沒(méi)有傳遞主機(jī)名（hostname）,1.1中新增的host用來(lái)處理一個(gè) IP 地址上面多個(gè)虛擬主機(jī)的情況。

在請(qǐng)求頭域中新增了Host字段，其用來(lái)指定服務(wù)器的域名。有了Host字段，在同一臺(tái)服務(wù)器上就可以搭建不同的網(wǎng)站了，這也為后來(lái)虛擬化的發(fā)展建好啦地基。

Host: www.alibaba-inc.com

cache機(jī)制

Cache不僅可以提高用戶的訪問(wèn)速率，在移動(dòng)端設(shè)備上還可以為用戶極大節(jié)省流量。因此，在HTTP/1.1中新增了很多與Cache相關(guān)的頭域并圍繞這些頭域設(shè)計(jì)了更靈活、更豐富的Cache機(jī)制。

Cache機(jī)制需要解決的問(wèn)題包括：

判斷哪些資源可以被Cache及訪問(wèn)訪問(wèn)策略。
在本地判斷Cache資源是否已經(jīng)過(guò)期。
向服務(wù)端發(fā)起問(wèn)詢，查看已過(guò)期的Cache資源是否在服務(wù)端發(fā)生了變化。

chunked機(jī)制

建立好鏈接之后客戶端可以使用該鏈接發(fā)送多個(gè)請(qǐng)求，用戶通常會(huì)通過(guò)response header中返回的Content-Length來(lái)判斷服務(wù)端返回?cái)?shù)據(jù)的大小。但隨著網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，越來(lái)越多的動(dòng)態(tài)資源被引入進(jìn)來(lái)，這時(shí)候服務(wù)端就無(wú)法在傳輸之前知道待傳遞資源的大小，也就無(wú)法通過(guò)Content-Length來(lái)告知用戶資源大小。服務(wù)器可以一邊動(dòng)態(tài)產(chǎn)生資源，一邊傳遞給用戶，這種機(jī)制稱為“分塊傳輸編碼”（Chunkded Transfer Encoding），允許服務(wù)端發(fā)送給客戶端的數(shù)據(jù)分為多個(gè)部分，此時(shí)服務(wù)器端需要在header中添加“Transfer-Encoding: chunked”頭域來(lái)替代傳統(tǒng)的“Content-Length。

Transfer-Encoding: chunked

HTTP 緩存機(jī)制

相比 HTTP 1.0，HTTP 1.1 新增了若干項(xiàng)緩存機(jī)制：

強(qiáng)緩存

強(qiáng)緩存，是瀏覽器優(yōu)先命中的緩存，速度最快。當(dāng)我們?cè)跔顟B(tài)碼后面看到 (from memory disk) 時(shí)，就表示瀏覽器從內(nèi)存中讀取了緩存，當(dāng)進(jìn)程結(jié)束后，也就是 tab 關(guān)閉以后，內(nèi)存里的數(shù)據(jù)也將不復(fù)存在。只有當(dāng)強(qiáng)緩存不被命中的時(shí)候，才會(huì)進(jìn)行協(xié)商緩存的查找。

Pragma

Pragma頭域是HTTP/1.0的產(chǎn)物。目前僅作為與HTTP/1.0的向后兼容而定義。它現(xiàn)在僅在請(qǐng)求首部中出現(xiàn)，表示要求所有中間服務(wù)器不返回緩存的資源，與Cache-Control: no-cache的意義相同。

Pragma: no-cache

Expires

Expires僅在響應(yīng)頭域中出現(xiàn)，表示資源的時(shí)效性當(dāng)發(fā)生請(qǐng)求時(shí)，瀏覽器將會(huì)把 Expires 的值與本地時(shí)間進(jìn)行對(duì)比，如果本地時(shí)間小于設(shè)置的時(shí)間，則讀取緩存。

Expires 的值為標(biāo)準(zhǔn)的 GMT 格式：

Expires: Wed, 21 Oct 2015 07:28:00 GMT

這里需要注意的是：當(dāng)header中同時(shí)存在Cache-Control: max-age=xx和Expires的時(shí)候，以Cache-Control: max-age的時(shí)間為準(zhǔn)。

Cache-Control

由于 Expires 的局限性， Cache-Control 登場(chǎng)了，下面說(shuō)明幾個(gè)常用的字段：

no-store：緩存不應(yīng)存儲(chǔ)有關(guān)客戶端請(qǐng)求或服務(wù)器響應(yīng)的任何內(nèi)容。
no-cache：在發(fā)布緩存副本之前，強(qiáng)制要求緩存把請(qǐng)求提交給原始服務(wù)器進(jìn)行驗(yàn)證。
max-age：相對(duì)過(guò)期時(shí)間，單位為秒(s)，告知服務(wù)器資源在多少以內(nèi)是有效的，無(wú)需向服務(wù)器請(qǐng)求。

協(xié)商緩存

當(dāng)瀏覽器沒(méi)有命中強(qiáng)緩存后，便會(huì)命中協(xié)商緩存，協(xié)商緩存由以下幾個(gè) HTTP 字段控制。

Last-Modified

服務(wù)端將資源傳送給客戶端的時(shí)候，會(huì)將資源最后的修改時(shí)間以 Last-Modified: GMT 的形式加在實(shí)體首部上返回。

Last-Modified: Fri, 22 Jul 2019 01:47:00 GMT

客戶端接收到后會(huì)為此資源信息做上標(biāo)記，等下次重新請(qǐng)求該資源的時(shí)候?qū)?huì)帶上時(shí)間信息給服務(wù)器做檢查，若傳遞的值與服務(wù)器上的值一致，則返回 304 ，表示文件沒(méi)有被修改過(guò)，若時(shí)間不一致，則重新進(jìn)行資源請(qǐng)求并返回 200。

優(yōu)先級(jí)

強(qiáng)緩存 --> 協(xié)商緩存Cache-Control -> Expires -> ETag -> Last-Modified。

新增了五種請(qǐng)求方法

OPTIONS：瀏覽器為確定跨域請(qǐng)求資源的安全做的預(yù)請(qǐng)求。

PUT：從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。

DELETE ：請(qǐng)求服務(wù)器刪除指定的頁(yè)面。

TRACE：回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。

CONNECT：HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

新增一系列的狀態(tài)碼

可以參考狀態(tài)碼大全

Http1.1缺陷

高延遲，帶來(lái)頁(yè)面加載速度的降低，（網(wǎng)絡(luò)延遲問(wèn)題只要由于隊(duì)頭阻塞，導(dǎo)致寬帶無(wú)法被充分利用）。
無(wú)狀態(tài)特性，帶來(lái)巨大的Http頭部。
明文傳輸，不安全。
不支持服務(wù)器推送消息。

HTTP/2.0

根據(jù)時(shí)代的發(fā)展網(wǎng)頁(yè)變得更加復(fù)雜。其中一些甚至本身就是應(yīng)用程序。顯示了更多的視覺(jué)媒體，增加了交互性的腳本的數(shù)量和大小也增加了。更多的數(shù)據(jù)通過(guò)更多的 HTTP 請(qǐng)求傳輸，這為 HTTP/1.1 連接帶來(lái)了更多的復(fù)雜性和開(kāi)銷(xiāo)。為此，谷歌在 2010 年代初實(shí)施了一個(gè)實(shí)驗(yàn)性協(xié)議 SPDY。鑒于SPDY的成功，HTTP/2也采用了SPDY作為整個(gè)方案的藍(lán)圖進(jìn)行開(kāi)發(fā)。HTTP/2 于 2015 年 5 月正式標(biāo)準(zhǔn)化。

HTTP/2 與 HTTP/1.1 區(qū)別：

二進(jìn)制幀層。
多路復(fù)用協(xié)議。可以通過(guò)同一連接發(fā)出并行請(qǐng)求，從而消除 HTTP/1.x 協(xié)議的約束。
頭部壓縮算法HPACK。由于一些請(qǐng)求在一組請(qǐng)求中通常是相似的，因此這消除了傳輸數(shù)據(jù)的重復(fù)和開(kāi)銷(xiāo)。
它允許服務(wù)器通過(guò)稱為服務(wù)器推送的機(jī)制在客戶端緩存中填充數(shù)據(jù)一張圖來(lái)理解HTTP/2 和 HTTP/1.1。

Header壓縮

HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送，為 HTTP/2 的專(zhuān)門(mén)量身打造的 HPACK 便是類(lèi)似這樣的思路延伸。它使用一份索引表來(lái)定義常用的 HTTP Header，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

看上去協(xié)議的格式和HTTP1.x完全不同了，實(shí)際上HTTP2并沒(méi)有改變HTTP1.x的語(yǔ)義，只是把原來(lái)HTTP1.x的header和body部分用frame重新封裝了一層而已。

多路復(fù)用

為了解決HTTP/1.x中存在的隊(duì)頭阻塞問(wèn)題，HTTP/2提出了多路復(fù)用的概念。即將一個(gè)request/response作為一個(gè)stream，并將一個(gè)stream根據(jù)負(fù)載分為多種類(lèi)型的frame（例如 header frame，data frame等），在同一條connection之上可以混合發(fā)送分屬于不同stream的frame，這樣就實(shí)現(xiàn)了同時(shí)發(fā)送多個(gè)request的功能，多路復(fù)用意味著線頭阻塞將不再是一個(gè)問(wèn)題。

HTTP/2 雖然通過(guò)多路復(fù)用解決了 HTTP 層的隊(duì)頭阻塞，但仍然存在 TCP 層的隊(duì)頭阻塞。

服務(wù)端推送 server push

服務(wù)可以主動(dòng)向客戶端發(fā)送消息。在瀏覽器剛請(qǐng)求 HTML 的時(shí)候，服務(wù)端會(huì)把某些資源存在一定的關(guān)聯(lián)性 JS、CSS 等文件等靜態(tài)資源主動(dòng)發(fā)給客戶端，這樣客戶端可以直接從本地加載這些資源，不用再通過(guò)網(wǎng)絡(luò)再次請(qǐng)求，以此來(lái)達(dá)到節(jié)省瀏覽器發(fā)送request請(qǐng)求的過(guò)程。

使用服務(wù)器推送

Link: </css/styles.css>; rel=preload; as=style，
</img/example.png>; rel=preload; as=image

可以看到服務(wù)器initiator中的push狀態(tài)表示這是服務(wù)端進(jìn)行主動(dòng)推送。

對(duì)于主動(dòng)推送的文件勢(shì)必會(huì)帶來(lái)多余或已經(jīng)瀏覽器已有一份的文件

客戶端使用一個(gè)簡(jiǎn)潔的 Cache Digest 來(lái)告訴服務(wù)器，哪些東西已經(jīng)在緩存，因此服務(wù)器也就會(huì)知道哪些是客戶端所需要的。

流

服務(wù)器和客戶端在HTTP/2連接內(nèi)用于交換幀數(shù)據(jù)的獨(dú)立雙向序列，HTTP/2 在單個(gè) TCP 連接上虛擬出多個(gè) Stream, 多個(gè) Stream 實(shí)現(xiàn)對(duì)一個(gè) TCP 連接的多路復(fù)用, 為了合理地利用傳輸鏈路, 實(shí)現(xiàn)在有限資源內(nèi)達(dá)到傳輸性能的最優(yōu)化。

所有的通信都建立在一個(gè)TCP連接上，可以傳遞大量的雙向流通的流。

每個(gè)流都有獨(dú)一無(wú)二的標(biāo)志和優(yōu)先級(jí)。

每個(gè)消息都是邏輯上的請(qǐng)求和相應(yīng)消息。由一個(gè)或者多個(gè)幀組成。

來(lái)自不同流的幀可以通過(guò)幀頭的標(biāo)志來(lái)關(guān)聯(lián)和組裝起來(lái)。

流的概念提出是為了實(shí)現(xiàn)多路復(fù)用，在單個(gè)連接上實(shí)現(xiàn)同時(shí)進(jìn)行多個(gè)業(yè)務(wù)單元數(shù)據(jù)的傳輸。

二進(jìn)制幀層

在HTTP/1.x中,用戶為了提高性能建立多個(gè)TCP連接.會(huì)導(dǎo)致隊(duì)頭阻塞和重要TCP連接不能穩(wěn)定獲得。HTTP/2中的二進(jìn)制幀層允許請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進(jìn)制編碼(http1.0基于文本格式)。多個(gè)幀之間可以亂序發(fā)送，根據(jù)幀首部的流（比如每個(gè)流都有自己的id）表示可以重新組裝。

顯然這對(duì)二進(jìn)制的計(jì)算機(jī)是非常友好，無(wú)需再將收到明文的報(bào)文轉(zhuǎn)成二進(jìn)制，而是直接解析二進(jìn)制報(bào)文，進(jìn)一步提高數(shù)據(jù)傳輸?shù)男省?/p>

每一個(gè)幀可看做是一個(gè)學(xué)生，流是小組（流標(biāo)識(shí)符為幀的屬性值），一個(gè)班級(jí)（一個(gè)連接）內(nèi)學(xué)生被分為若干個(gè)小組，每一個(gè)小組分配不同的具體任務(wù)，多個(gè)小組任務(wù)可同時(shí)并行在班級(jí)內(nèi)執(zhí)行。一旦某個(gè)小組任務(wù)耗時(shí)嚴(yán)重，但不會(huì)影響到其它小組任務(wù)正常執(zhí)行。

最后我們來(lái)看一看理想狀態(tài)下http2帶來(lái)的提升。

缺點(diǎn)

TCP以及TCP+TLS建立連接的延遲（握手延遲）。
http2.0中TCP的隊(duì)頭阻塞依然沒(méi)有徹底解決，連接雙方的有任一個(gè)數(shù)據(jù)包丟失，或任一方的網(wǎng)絡(luò)中斷，整個(gè)TCP連接就會(huì)暫停，丟失的數(shù)據(jù)包需要被重新傳輸，從而阻塞該TCP連接中的所有請(qǐng)求，反而在網(wǎng)絡(luò)較差或不穩(wěn)定情況下，使用多個(gè)連接表現(xiàn)更好。

HTTP/3.0 (HTTP-over-QUIC)

在限定條件下，TCP下解決隊(duì)頭阻塞的問(wèn)題相當(dāng)困難，但是隨著互聯(lián)網(wǎng)的爆炸式發(fā)展，更高的穩(wěn)定性和安全性需要得到滿足，谷歌在2016年11月國(guó)際互聯(lián)網(wǎng)工程任務(wù)組(IETF)召開(kāi)了第一次QUIC（Quick UDP Internet Connections）工作組會(huì)議，制定的一種基于UDP的低時(shí)延的互聯(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ā)送確認(rèn)包ACK(seq = x+1; ack=y+1)，至此客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。

1-RTT

客服端生成一個(gè)隨機(jī)數(shù) a 然后選擇一個(gè)公開(kāi)的加密數(shù) X ，通過(guò)計(jì)算得出 a*X = A, 將X 和 A發(fā)送給服務(wù)端。
客服端生成一個(gè)隨機(jī)數(shù) b，通過(guò)計(jì)算得出 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ù)器的私鑰，是不公開(kāi)的,即使知道 A、X，通過(guò) A = a*X 公式也是無(wú)法推導(dǎo)出 a 的，保證了私鑰的安全性。

0-RTT

0-RTT則是客戶端緩存了 ServerConfig（B=b*X），下次建連直接使用緩存數(shù)據(jù)計(jì)算通信密鑰：

sequenceDiagram
客服端->>服務(wù)端: clinet Hello + 應(yīng)用數(shù)據(jù)
服務(wù)端-->>客服端: ACK

客戶端：生成隨機(jī)數(shù) c，選擇公開(kāi)的大數(shù) X，計(jì)算 A=cX，將 A 和 X 發(fā)送給服務(wù)器，也就是 Client Hello 消息后，客戶端直接使用緩存的 B 計(jì)算通信密鑰 KEY = cB = cbX，加密發(fā)送應(yīng)用數(shù)據(jù)。
服務(wù)器：根據(jù) Client Hello 消息計(jì)算通信密鑰 key = bA = b(c*X)。

客戶端不需要經(jīng)過(guò)握手直接通過(guò)緩存的B生成key就可以發(fā)送應(yīng)用數(shù)據(jù)。

再來(lái)思考一個(gè)問(wèn)題：假設(shè)攻擊者記錄下所有的通信數(shù)據(jù)和公開(kāi)參數(shù)A1，A2，一旦服務(wù)器的隨機(jī)數(shù) b（私鑰）泄漏了，那之前通信的所有數(shù)據(jù)就都可以破解了。

為了解決這個(gè)問(wèn)題，需要為每次會(huì)話都創(chuàng)建一個(gè)新的通信密鑰，來(lái)保證前向安全性。

有序交付

QUIC 是基于 UDP 協(xié)議的，而 UDP 是不可靠傳輸協(xié)議，QUIC 在每個(gè)數(shù)據(jù)包都設(shè)有一個(gè) offset 字段（偏移量），接收端根據(jù) offset 字段就可以對(duì)異步到達(dá)的數(shù)據(jù)包進(jìn)行排序了，保證了有序性。

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

隊(duì)頭堵塞

HTTP/2 之所以存在 TCP 層的隊(duì)頭阻塞，是因?yàn)樗姓?qǐng)求流都共享一個(gè)滑動(dòng)窗口，而QUIC中給每個(gè)請(qǐng)求流都分配一個(gè)獨(dú)立的滑動(dòng)窗口。

A 請(qǐng)求流上的丟包不會(huì)影響 B 請(qǐng)求流上的數(shù)據(jù)發(fā)送。但是，對(duì)于每個(gè)請(qǐng)求流而言，也是存在隊(duì)頭阻塞問(wèn)題的，也就是說(shuō)，雖然 QUIC 解決了 TCP 層的隊(duì)頭阻塞，但仍然存在單條流上的隊(duì)頭阻塞。這就是 QUIC 聲明的無(wú)隊(duì)頭阻塞的多路復(fù)用。

連接遷移

連接遷移：當(dāng)客戶端切換網(wǎng)絡(luò)時(shí)，和服務(wù)器的連接并不會(huì)斷開(kāi)，仍然可以正常通信，對(duì)于 TCP 協(xié)議而言，這是不可能做到的。因?yàn)?TCP 的連接基于 4 元組：源 IP、源端口、目的 IP、目的端口，只要其中 1 個(gè)發(fā)生變化，就需要重新建立連接。但 QUIC 的連接是基于 64 位的 Connection ID，網(wǎng)絡(luò)切換并不會(huì)影響 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 個(gè)包是來(lái)自于同一個(gè)客戶端。QUIC 能實(shí)現(xiàn)連接遷移的根本原因是底層使用 UDP 協(xié)議就是面向無(wú)連接的。

最后我們一張圖來(lái)看一下http的升級(jí)。