https://www.toutiao.com/article/7174788591591113250/?log_from=09aebc0b506cc_1676437908324

   (由請(qǐng)求和響應(yīng)構(gòu)成打開(kāi)頭條的Web頁(yè)面通過(guò)F12打開(kāi)控制臺(tái)我們挑選一個(gè)請(qǐng)求來(lái)分析下HTTP的結(jié)構(gòu))

1. Internet互聯(lián)

https://www.toutiao.com/article/7174788591591113250/?log_from=09aebc0b506cc_1676437908324

萬(wàn)物互聯(lián)已經(jīng)實(shí)實(shí)在在的組建在我們生活之中,。我們作為網(wǎng)絡(luò)中的一個(gè)節(jié)點(diǎn)，不管是否從事IT行業(yè),，了解HTTP協(xié)議對(duì)我們使用瀏覽器或其他APP都有一定的幫助,，這些不限于

• 我們是如何能瀏覽網(wǎng)頁(yè)的？

• 我們是如何能使用APP交水電煤的,？

• 我們是如何使用電腦或APP買(mǎi)火車(chē)票的,？

• 我們是如何通過(guò)電子網(wǎng)站購(gòu)物的？

• 我們是如何登錄一個(gè)系統(tǒng)就可以一直使用這個(gè)賬號(hào)的,？

• …

HTTP協(xié)議是應(yīng)用層廣泛使用的一個(gè)協(xié)議,，了解它我們需要從協(xié)議的定義、協(xié)議的用法,、跨服務(wù)調(diào)用（專業(yè)稱為跨域請(qǐng)求）,、數(shù)據(jù)緩存、長(zhǎng)連接和它的版本演進(jìn)為大家撥云開(kāi)霧的一探究竟,。

2. HTTP協(xié)議定義

HTTP 是HyperText Transfer Protocol的縮寫(xiě),，中文翻譯就是超文本傳輸協(xié)議。顧名思義:

• 超文本表示數(shù)據(jù)類型不在局限于文本,。在互聯(lián)網(wǎng)早期的時(shí)候只是簡(jiǎn)單的字符文字,，但現(xiàn)在「文本」的涵義已經(jīng)可以擴(kuò)展為圖片,、視頻、壓縮包等,；

• 傳輸表示能雙向溝通,；

• 協(xié)議表示一個(gè)約定的規(guī)范。

即HTTP是一個(gè)應(yīng)用層協(xié)議,，無(wú)狀態(tài),，由請(qǐng)求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型,。在計(jì)算機(jī)世界里一個(gè)專門(mén)在「兩點(diǎn)」之間「?jìng)鬏敗刮淖?、圖片、音頻,、視頻等「超文本」數(shù)據(jù)的「約定和規(guī)范」,。

3. 一個(gè)具體的HTTP請(qǐng)求分析

舉個(gè)栗子，當(dāng)我們打開(kāi)頭條的Web頁(yè)面,，通過(guò)F12打開(kāi)控制臺(tái),，我們挑選一個(gè)請(qǐng)求來(lái)分析下HTTP的結(jié)構(gòu)。

這是一個(gè) http 請(qǐng)求以及響應(yīng),，這里的 General 可以理解成為 http請(qǐng)求和響應(yīng)的起始行的一個(gè)公共部分，說(shuō)明：

1. Genaral headers: 同時(shí)適用于請(qǐng)求和響應(yīng)消息,，但與最終消息傳輸?shù)臄?shù)據(jù)無(wú)關(guān)的消息頭,。

2. Request Headers: 包含更多有關(guān)要獲取的資源或客戶端本身信息的消息頭。

3. Response Headers：包含有關(guān)響應(yīng)的補(bǔ)充信息,，如其位置或服務(wù)器本身（名稱和版本等）的消息頭,。

4. Entity Headers[其他]：包含有關(guān)實(shí)體主體的更多信息，比如主體長(zhǎng)(Content-Length)度或其MIME類型,。

客戶端發(fā)送一個(gè)HTTP請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下格式：請(qǐng)求行（request line）,、請(qǐng)求頭部（header）、空行和請(qǐng)求數(shù)據(jù)四個(gè)部分組成,；

3.1 General Headers

通用頭即可以包含在HTTP請(qǐng)求中,，也可以包含在HTTP響應(yīng)中。通用頭的作用是描述HTTP協(xié)議本身,。比如描述HTTP是否持久連接的Connection頭,，HTTP發(fā)送日期的Date頭，描述HTTP所在TCP連接時(shí)間的Keep-Alive頭,，用于緩存控制的Cache-Control頭等

• Request URL：請(qǐng)求地址

• Request Method:請(qǐng)求方法

• Status Code：請(qǐng)求狀態(tài)

• Remote Address:Remote Address 來(lái)自 TCP 連接,，表示與服務(wù)端建立 TCP 連接的設(shè)備 IP

• Referrer-Policy：控制請(qǐng)求頭中referrer的內(nèi)容

HTTP的請(qǐng)求方法

3.1.1 GET 和 POST 比較？

根據(jù) RFC 規(guī)范

• GET 的語(yǔ)義是從服務(wù)器獲取指定的資源,，這個(gè)資源可以是靜態(tài)的文本,、頁(yè)面、圖片視頻等,。GET 請(qǐng)求的參數(shù)位置一般是寫(xiě)在 URL 中,，URL 規(guī)定只能支持 ASCII，所以 GET 請(qǐng)求的參數(shù)只允許 ASCII 字符 ,，而且瀏覽器會(huì)對(duì) URL 的長(zhǎng)度有限制（HTTP協(xié)議本身對(duì) URL長(zhǎng)度并沒(méi)有做任何規(guī)定）,。

• POST 的語(yǔ)義是根據(jù)請(qǐng)求負(fù)荷（報(bào)文body）對(duì)指定的資源做出處理，具體的處理方式視資源類型而不同,。POST 請(qǐng)求攜帶數(shù)據(jù)的位置一般是寫(xiě)在報(bào)文 body 中,， body 中的數(shù)據(jù)可以是任意格式的數(shù)據(jù)，只要客戶端與服務(wù)端協(xié)商好即可,，而且瀏覽器不會(huì)對(duì) body 大小做限制,。

3.1.2 GET 和 POST 的安全和冪等性

• 安全：指請(qǐng)求方法不會(huì)「破壞」服務(wù)器上的資源。

• 冪等：多次執(zhí)行相同的操作,，結(jié)果都是「相同」的,。

如果從 RFC 規(guī)范定義的語(yǔ)義來(lái)看：

• GET 方法就是安全且冪等的，因?yàn)樗恰钢蛔x」操作,，無(wú)論操作多少次,，服務(wù)器上的數(shù)據(jù)都是安全的，且每次的結(jié)果都是相同的,。所以,，可以對(duì) GET 請(qǐng)求的數(shù)據(jù)做緩存,，這個(gè)緩存可以做到瀏覽器本身上（徹底避免瀏覽器發(fā)請(qǐng)求），也可以做到代理上（如nginx）,，而且在瀏覽器中 GET 請(qǐng)求可以保存為書(shū)簽,。

• POST 因?yàn)槭恰感略龌蛱峤粩?shù)據(jù)」的操作，會(huì)修改服務(wù)器上的資源,，所以是不安全的,，且多次提交數(shù)據(jù)就會(huì)創(chuàng)建多個(gè)資源，所以不是冪等的,。所以,，瀏覽器一般不會(huì)緩存 POST 請(qǐng)求，也不能把 POST 請(qǐng)求保存為書(shū)簽,。

3.2 Rquest Headers

實(shí)體頭是那些描述HTTP信息的頭,。既可以出現(xiàn)在HTTP POST方法的請(qǐng)求中，也可以出現(xiàn)在HTTP響應(yīng)中,。比如Content-Type和Content-length等描述實(shí)體的類型和大小的頭,。其它還有用于描述實(shí)體的Content-Language、Content-MD5,、Content-Encoding以及控制實(shí)體緩存的Expires,、Last-Modifies頭等。

請(qǐng)求頭是那些由客戶端發(fā)往服務(wù)端以便幫助服務(wù)端更好的滿足客戶端請(qǐng)求的頭,。請(qǐng)求頭只能出現(xiàn)在HTTP請(qǐng)求中,。比如告訴服務(wù)器只接收某種響應(yīng)內(nèi)容的Accept頭，發(fā)送Cookies的Cookie頭,，顯示請(qǐng)求主機(jī)域的HOST頭,，用于緩存的If-Match,、If-Match-Since,、If-None-Match頭，用于只取HTTP響應(yīng)信息中部分信息的Range頭,，用于附屬HTML相關(guān)請(qǐng)求引用的Referer頭等,。

參數(shù)說(shuō)明：瀏覽器側(cè)的能力

• Accept：可以接受的媒體類型,例如： Accept: text/html 代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html

• Accept-Encoding：申明自己接收的編碼方法，通常指定壓縮方法,，是否支持壓縮,，支持什么壓縮方法（gzip，deflate）,，注意：這不是指字符編碼

• Accept-Language：申明自己接收的語(yǔ)言,。語(yǔ)言跟字符集的區(qū)別：中文是語(yǔ)言，中文有多種字符集,，比如big5,，gb2312,，gbk等等，例如： Accept-Language: en-us

• Connection：keep-alive 當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后,，客戶端和服務(wù)器之間保持一個(gè)長(zhǎng)連接,。

• Referer：當(dāng)瀏覽器向web服務(wù)器發(fā)送請(qǐng)求的時(shí)候，一般會(huì)帶上Referer,，告訴服務(wù)器我是從哪個(gè)頁(yè)面鏈接過(guò)來(lái)的,，服務(wù)器籍此可以獲得一些信息用于處理。

• User-Agent：客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本,。

• Cache-Control：Cache-Control與Expires的作用一致,，都是指明當(dāng)前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數(shù)據(jù)還是重新發(fā)請(qǐng)求到服務(wù)器取數(shù)據(jù),。

• Cookie：Cookie是用來(lái)存儲(chǔ)一些用戶信息以便讓服務(wù)器辨別用戶身份的（大多數(shù)需要登錄的網(wǎng)站上面會(huì)比較常見(jiàn)）,，比如cookie會(huì)存儲(chǔ)一些用戶的用戶名和密碼，當(dāng)用戶登錄后就會(huì)在客戶端產(chǎn)生一個(gè)cookie來(lái)存儲(chǔ)相關(guān)信息,，這樣瀏覽器通過(guò)讀取cookie的信息去服務(wù)器上驗(yàn)證并通過(guò)后會(huì)判定你是合法用戶,，從而允許查看相應(yīng)網(wǎng)頁(yè)。當(dāng)然cookie里面的數(shù)據(jù)不僅僅是上述范圍,，還有很多信息可以存儲(chǔ)在cookie里面,，比如sessionid等。

• If-Modified-Since：把瀏覽器端緩存頁(yè)面的最后修改時(shí)間發(fā)送到服務(wù)器去,，服務(wù)器會(huì)把這個(gè)時(shí)間與服務(wù)器上實(shí)際文件的最后修改時(shí)間進(jìn)行對(duì)比,。如果時(shí)間一致，那么返回304,，客戶端就直接使用本地緩存文件,。如果時(shí)間不一致，就會(huì)返回200和新的文件內(nèi)容,?？蛻舳私拥街螅瑫?huì)丟棄舊文件,，把新文件緩存起來(lái),，并顯示在瀏覽器中T。

• If-None-Match：If-None-Match和ETag一起工作,，工作原理是在HTTP Response中添加ETag信息,。 當(dāng)用戶再次請(qǐng)求該資源時(shí)，將在HTTP Request 中加入If-None-Match信息(ETag的值),。如果服務(wù)器驗(yàn)證資源的ETag沒(méi)有改變（該資源沒(méi)有更新）,，將返回一個(gè)304狀態(tài)告訴客戶端使用本地緩存文件。否則將返回200狀態(tài)和新的資源和Etag.

3.3 Response Headers

HTTP響應(yīng)頭是那些描述HTTP響應(yīng)本身的頭，這里面并不包含描述HTTP響應(yīng)中第三部分也就是HTTP信息的頭（這部分由實(shí)體頭負(fù)責(zé)）,。比如說(shuō)定時(shí)刷新的Refresh頭,，當(dāng)遇到503錯(cuò)誤時(shí)自動(dòng)重試的Retry-After頭，顯示服務(wù)器信息的Server頭,，設(shè)置COOKIE的Set-Cookie頭,，告訴客戶端可以部分請(qǐng)求的Accept-Ranges頭等。

參數(shù)說(shuō)明：

• Access-Control-Allow-Credentials：跨域Ajax請(qǐng)求時(shí)是否帶Cookie的設(shè)置,；表示是否允許發(fā)送cookies,。默認(rèn)情況下，Cookies不包括在CORS請(qǐng)求中,；設(shè)為true表示cookies可以包含在請(qǐng)求中一起發(fā)給服務(wù)器,，如果不需要發(fā)送cookies給服務(wù)器，需刪除字段,。需要注意的是：除了設(shè)置Access-Control-Allow-Credential：true外,，在ajax請(qǐng)求中也必須打開(kāi)withCredentials

• Access-Control-Allow-Methods：必要字段 ，表示服務(wù)器支持的所有跨域請(qǐng)求方法,，只要瀏覽器使用的請(qǐng)求方法包含在內(nèi)即可通過(guò)

• Access-Control-Allow-Origin：必要字段 ,，該站點(diǎn)可以被哪些網(wǎng)站進(jìn)行跨域資源共享

• Access-Control-Expose-Headers：必要字段 ，表明服務(wù)器支持的所有頭信息字段,，也是為了避免多次預(yù)檢請(qǐng)求

• Access-Control-Allow-Max-Age ：可選字段,， 單位是s，用來(lái)指定本次預(yù)檢的有效期,，即在給定時(shí)間內(nèi)允許該條緩存回應(yīng),，不會(huì)發(fā)出一條預(yù)檢請(qǐng)求。

• Cache-Control：控制緩存的行為 淺談http中的Cache-Control

• Connection：“Connection:Keep-Alive”或 “Connection:close”,，這里具體的含義是有關(guān)http 請(qǐng)求的是否保持長(zhǎng)連接,，即鏈接是否復(fù)用，每次請(qǐng)求是復(fù)用已建立好的請(qǐng)求,，還是重新建立一個(gè)新的請(qǐng)求,。

• Content-Length：在Http 1.0及之前版本中，content-length字段可有可無(wú),；在http1.1及之后版本,。如果是keep alive,，則content-length和chunk必然是二選一,。若是非keep alive，則和http1.0一樣,。content-length可有可無(wú),。

• Content-Encoding：Accept-Encoding 和Content-Encoding是HTTP中用來(lái)對(duì)采用哪種編碼格式傳輸正文進(jìn)行協(xié)定的一對(duì)頭部字段。

• （Content-Encoding 中的 gzip 和 deflate：

• gzip,，一種由文件壓縮程序「Gzip,，GUN zip」產(chǎn)生的編碼格式,，描述于 RFC 1952。這種編碼格式是一種具有 32 位 CRC 的 Lempel-Ziv 編碼（LZ77）,；

• deflate,，由定義于 RFC 1950 的「ZLIB」編碼格式與 RFC 1951 中描述的「DEFLATE」壓縮機(jī)制組合而成的產(chǎn)物；）

• Content-Type：代表發(fā)送端發(fā)送的實(shí)體數(shù)據(jù)的數(shù)據(jù)類型（post請(qǐng)求肯定要發(fā)送數(shù)據(jù)包;因此對(duì)數(shù)據(jù)包的Type有專門(mén)的限定:Content-Type只能是application/x-www-form-urlencoded,application/json,，multipart/form-data或 text/plain中的一種,。）

• Keep-Alive：在http早期，每個(gè)http請(qǐng)求都要求打開(kāi)一個(gè)tpc socket連接,，并且使用一次之后就斷開(kāi)這個(gè)tcp連接,。使用keep-alive可以改善這種狀態(tài)，即在一次TCP連接中可以持續(xù)發(fā)送多份數(shù)據(jù)而不會(huì)斷開(kāi)連接,。通過(guò)使用keep-alive機(jī)制,，可以減少tcp連接建立次數(shù)，也意味著可以減少TIME_WAIT狀態(tài)連接,，以此提高性能和提高h(yuǎn)ttpd服務(wù)器的吞吐率(更少的tcp連接意味著更少的系統(tǒng)內(nèi)核調(diào)用,socket的accept()和close()調(diào)用),。但是，keep-alive并不是免費(fèi)的午餐,長(zhǎng)時(shí)間的tcp連接容易導(dǎo)致系統(tǒng)資源無(wú)效占用,。配置不當(dāng)?shù)膋eep-alive,，有時(shí)比重復(fù)利用連接帶來(lái)的損失還更大。所以,，正確地設(shè)置keep-alive timeout時(shí)間非常重要,。

HTTP響應(yīng)消息由狀態(tài)行、響應(yīng)頭部,、空行 和 響應(yīng)體 4個(gè)部分組成,，如下圖所示：

3.2 HTTP 常見(jiàn)的狀態(tài)碼

場(chǎng)景的Status Code說(shuō)明：

1XX

• 100(continue) 表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng),。

2XX

• 200(OK) 表示從客戶端發(fā)來(lái)的請(qǐng)求在服務(wù)器端被正常處理了,。

• 204(No Content) 該狀態(tài)碼代表服務(wù)器接收的請(qǐng)求已成功處理，但在返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分,。

• 206(Partial Content) 該狀態(tài)碼表示客戶端進(jìn)行了范圍請(qǐng)求,，而服務(wù)器成功執(zhí)行了這部分的 GET 請(qǐng)求。響應(yīng)報(bào)文中包含由 Content-Range 指定范圍的實(shí)體內(nèi)容,。

3XX

• 301(Moved Permanently) 永久性重定向,。該狀態(tài)碼表示請(qǐng)求的資源已被分配了新的 URI，以后應(yīng)使用資源現(xiàn)在所指的 URI,。

• 302(Found) 臨時(shí)性重定向,。比如在沒(méi)有登錄情況下訪問(wèn)網(wǎng)站"個(gè)人中心"，會(huì)重定向到登錄頁(yè)，但是你登錄后,，訪問(wèn)個(gè)人中心時(shí),，它又不會(huì)重定向到其他地方了。

• 303(See Other) 和 302 有著相同的功能,，但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源,。

• 304(Not Modified) 如果請(qǐng)求報(bào)文首部包含一些條件，例如：If-Match,，If-Modified-Since,，If-None-Match，If-Range,，If-Unmodified-Since,，如果不滿足條件，則服務(wù)器會(huì)返回 304 狀態(tài)碼,。

4XX

• 400(Bad Request) 該狀態(tài)碼表示請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤,。當(dāng)錯(cuò)誤發(fā)生時(shí)，需修改請(qǐng)求的內(nèi)容后再次發(fā)送請(qǐng)求,。

• 401 Unauthorized 該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息,。返回含有 401 的響應(yīng)必須包含一個(gè)適用于被請(qǐng)求資源的 WWW-Authenticate 首部用以詢問(wèn)用戶信息。當(dāng)瀏覽器初次接收到 401 響應(yīng),，會(huì)彈出認(rèn)證用的對(duì)話窗口,。第二次接收到，則不彈出,，直接表示認(rèn)證失敗,。

• 403(Forbidden) 對(duì)請(qǐng)求資源的訪問(wèn)被服務(wù)器拒絕了，一般是未獲得文件系統(tǒng)的訪問(wèn)授權(quán),，問(wèn)權(quán)限出現(xiàn)某些問(wèn)題,。

• 404(Not Found) 瀏覽器地址錯(cuò)誤。服務(wù)器找不到對(duì)應(yīng)資源,。

5XX

• 500(Internal Server Error) 服務(wù)器在執(zhí)行時(shí)報(bào)錯(cuò),。

• 503(Service Unavailable) 服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，無(wú)響應(yīng),。一般需要重啟服務(wù)器即可,。

4. HTTP 緩存技術(shù)

對(duì)于一些具有重復(fù)性的 HTTP 請(qǐng)求，或者靜態(tài)數(shù)據(jù)文件,，比如css/js/html等,，可以把這對(duì)「請(qǐng)求-響應(yīng)」的數(shù)據(jù)都緩存在本地，下次就直接讀取本地的數(shù)據(jù),，進(jìn)而提高訪問(wèn)性能,。

HTTP 緩存的2種實(shí)現(xiàn)方式：強(qiáng)制緩存和協(xié)商緩存。

強(qiáng)制緩存

強(qiáng)制緩存：不判斷直接使用瀏覽器的本地緩存,。強(qiáng)緩存是通過(guò)下面這兩個(gè) HTTP 響應(yīng)頭部（Response Header）字段實(shí)現(xiàn)的,，它們都用來(lái)表示資源在客戶端緩存的有效期：

• Cache-Control：相對(duì)時(shí)間；

• Expires：絕對(duì)時(shí)間,；

如果 HTTP 響應(yīng)頭部同時(shí)有上面2個(gè)字段的話,，Cache-Control的優(yōu)先級(jí)高于 Expires 。Cache-Control 配置比較多,，建議使用 Cache-Control 來(lái)實(shí)現(xiàn)強(qiáng)緩存進(jìn)行精細(xì)化控制,。具體流程如下：

• 客戶端第一次請(qǐng)求服務(wù)資源，服務(wù)器會(huì)在返回這個(gè)資源的同時(shí),，在 Response 頭部加上 Cache-Control,，并設(shè)置了過(guò)期時(shí)間大小,；

• 客戶端再次請(qǐng)求請(qǐng)求服務(wù)器中的該資源時(shí),，會(huì)先通過(guò)請(qǐng)求資源的時(shí)間與 Cache-Control 中設(shè)置的過(guò)期時(shí)間大小，來(lái)計(jì)算出該資源是否過(guò)期,，如果沒(méi)有,，則使用該緩存，否則重新請(qǐng)求服務(wù)器,；

• 服務(wù)器再次收到請(qǐng)求后,，會(huì)更新 Response 頭部的 Cache-Control。

協(xié)商緩存

當(dāng)請(qǐng)求的響應(yīng)碼是 304時(shí),，服務(wù)器告訴瀏覽器可以使用本地緩存的資源,，通常這種方式被稱為協(xié)商緩存。

協(xié)商緩存就是與服務(wù)端協(xié)商之后,，通過(guò)協(xié)商結(jié)果來(lái)判斷是否使用本地緩存,。

協(xié)商緩存通過(guò)配置頭部有2種實(shí)現(xiàn)：

第一種：請(qǐng)求頭部 If-Modified-Since 字段與響應(yīng)頭部中的 Last-Modified 字段

• Last-Modified：標(biāo)示這個(gè)響應(yīng)資源的最后修改時(shí)間；

• If-Modified-Since：當(dāng)資源過(guò)期了,，發(fā)現(xiàn)響應(yīng)頭中具有 Last-Modified 聲明,，則再次發(fā)起請(qǐng)求的時(shí)候帶上 Last-Modified 的時(shí)間，服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有 If-Modified-Since 則與被請(qǐng)求資源的最后修改時(shí)間進(jìn)行對(duì)比（Last-Modified）,，如果最后修改時(shí)間較新,，說(shuō)明資源又被改過(guò)，則返回最新資源,，HTTP 200 OK,；如果最后修改時(shí)間較舊，說(shuō)明資源無(wú)新修改,，響應(yīng) HTTP 304 走緩存,。

第二種：請(qǐng)求頭部 If-None-Match 字段與響應(yīng)頭部中的 ETag 字段

• 響應(yīng)頭部中 Etag：唯一標(biāo)識(shí)響應(yīng)資源,；

• 請(qǐng)求頭部中的 If-None-Match：當(dāng)資源過(guò)期時(shí)，瀏覽器發(fā)現(xiàn)響應(yīng)頭里有 Etag,，則再次向服務(wù)器發(fā)起請(qǐng)求資源時(shí),，會(huì)將請(qǐng)求頭If-None-Match 值設(shè)置為 Etag 的值。服務(wù)器收到請(qǐng)求后進(jìn)行比對(duì),，如果沒(méi)有變化返回 304,，如果變化了返回 200。

第一種方式是基于時(shí)間實(shí)現(xiàn)的,，第二種方式是基于一個(gè)唯一標(biāo)識(shí)實(shí)現(xiàn)的,。對(duì)比2種方式，第二種可以更加準(zhǔn)確地判斷文件內(nèi)容是否被修改,，避免由于時(shí)間篡改導(dǎo)致的不可靠問(wèn)題,。

如果在第一次請(qǐng)求資源的時(shí)候，服務(wù)端返回的 HTTP 響應(yīng)頭部同時(shí)有 Etag 和 Last-Modified 字段,，那么客戶端再下一次請(qǐng)求的時(shí)候,，如果帶上了 ETag 和 Last-Modified 字段信息給服務(wù)端，這時(shí) Etag 的優(yōu)先級(jí)更高,，也就是服務(wù)端先會(huì)判斷 Etag 是否變化了,，如果 Etag 沒(méi)有變化，然后再看 Last-Modified,，否則不做其他檢查,。

**為什么 ETag 的優(yōu)先級(jí)更高？**這是因?yàn)?ETag 主要能解決 Last-Modified 存在的問(wèn)題：

1. 在沒(méi)有修改文件內(nèi)容情況下文件的最后修改時(shí)間可能也會(huì)改變,，這會(huì)導(dǎo)致客戶端認(rèn)為這文件被改動(dòng)了,，從而重新請(qǐng)求；

2. 可能有些文件是在秒級(jí)以內(nèi)修改的,，If-Modified-Since 能檢查到的粒度是秒級(jí)的,，使用 Etag就能夠保證這種需求下客戶端在 1 秒內(nèi)能刷新多次；

3. 有些服務(wù)器不能精確獲取文件的最后修改時(shí)間,。

協(xié)商緩存這兩個(gè)字段都需要配合強(qiáng)制緩存中 Cache-control 字段來(lái)使用,，只有在未能命中強(qiáng)制緩存的時(shí)候，才能發(fā)起帶有協(xié)商緩存字段的請(qǐng)求,。

強(qiáng)制緩存和協(xié)商緩存的工作流程如下：

使用 ETag 字段實(shí)現(xiàn)的協(xié)商緩存的過(guò)程：

• 當(dāng)瀏覽器第一次請(qǐng)求訪問(wèn)服務(wù)器資源時(shí),，服務(wù)器會(huì)在返回這個(gè)資源的同時(shí)，在 Response 頭部加上 ETag 唯一標(biāo)識(shí),，它根據(jù)當(dāng)前請(qǐng)求的資源生成,；

• 當(dāng)瀏覽器再次請(qǐng)求訪問(wèn)服務(wù)器中的該資源時(shí)，會(huì)先檢查強(qiáng)制緩存是否過(guò)期：如果沒(méi)有過(guò)期,，則直接使用本地緩存,；如果過(guò)期了,，則會(huì)在 Request 頭部加上 If-None-Match 字段，該字段的值就是 ETag 唯一標(biāo)識(shí),；

• 服務(wù)器再次收到請(qǐng)求后,，會(huì)根據(jù)請(qǐng)求中的 If-None-Match 值與當(dāng)前請(qǐng)求的資源生成的唯一標(biāo)識(shí)進(jìn)行比較：如果相等，則返回 304,；如果不相等,，則返回 200 狀態(tài)碼和返回資源,，并在 Response 頭部加上新的 ETag 唯一標(biāo)識(shí),；

• 如果瀏覽器收到 304 的請(qǐng)求響應(yīng)狀態(tài)碼，則會(huì)從本地緩存中加載資源,，否則更新資源,。

5. HTTP 特性

HTTP 當(dāng)前常見(jiàn)到版本有 HTTP/1.1，HTTP/2.0,，HTTP/3.0,，特性不兼容。

5. 1 HTTP/1.1 的優(yōu)點(diǎn)

HTTP /1.1的優(yōu)點(diǎn)：

• 簡(jiǎn)單：HTTP 基本的報(bào)文格式就是 header + body,，頭部信息也是 key-value 簡(jiǎn)單文本的形式,，易于理解，降低了學(xué)習(xí)和使用的門(mén)檻,。

• 靈活和易于擴(kuò)展：HTTP 協(xié)議里的各類請(qǐng)求方法,、URI/URL、狀態(tài)碼,、頭字段等每個(gè)組成要求都沒(méi)有被固定死,，都允許開(kāi)發(fā)人員自定義和擴(kuò)充。

• 應(yīng)用廣泛和跨平臺(tái)：互聯(lián)網(wǎng)發(fā)展至今,，HTTP 的應(yīng)用范圍非常的廣泛,，從臺(tái)式機(jī)的瀏覽器到手機(jī)上的各種 APP，從看新聞,、刷貼吧到購(gòu)物,、理財(cái)、吃雞,，HTTP 的應(yīng)用遍地開(kāi)花,，同時(shí)天然具有跨平臺(tái)的優(yōu)越性。

HTTP/1.1 的缺點(diǎn)：

HTTP 協(xié)議里有優(yōu)缺點(diǎn)一體的雙刃劍,，分別是「無(wú)狀態(tài),、明文傳輸」，同時(shí)還有一大缺點(diǎn)「不安全」,。

HTTP/1.1 的性能：

HTTP 協(xié)議是基于 TCP/IP,，使用了「請(qǐng)求 - 應(yīng)答」的通信模式,。

長(zhǎng)連接

HTTP/1.0 性能比較差，原因是每發(fā)起一個(gè)請(qǐng)求,，都要新建一次 TCP 連接（三次握手）,，而且是串行請(qǐng)求，增加了通信開(kāi)銷,。

為了解決上述 TCP 連接問(wèn)題,，HTTP/1.1 提出了長(zhǎng)連接的通信方式。這種方式的好處在于減少了 TCP 連接的重復(fù)建立和斷開(kāi)所造成的額外開(kāi)銷,，減輕了服務(wù)器端的負(fù)載,。

持久連接的特點(diǎn)是，只要任意一端沒(méi)有明確提出斷開(kāi)連接,，則保持 TCP 連接狀態(tài),。如果某個(gè) HTTP 長(zhǎng)連接超過(guò)一定時(shí)間沒(méi)有任何數(shù)據(jù)交互，服務(wù)端就會(huì)主動(dòng)斷開(kāi)這個(gè)連接,。

管道網(wǎng)絡(luò)傳輸

HTTP/1.1 采用了長(zhǎng)連接的方式,，則可以選擇管道（pipeline）傳輸。即可在同一個(gè) TCP 連接里面,，客戶端可以發(fā)起多個(gè)請(qǐng)求,，只要第一個(gè)請(qǐng)求發(fā)出去了，不必等其回來(lái),，就可以發(fā)第二個(gè)請(qǐng)求出去,，可以減少整體的響應(yīng)時(shí)間。因?yàn)楣艿纻鬏斒谴械?，所以?huì)有一個(gè)問(wèn)題,。如果服務(wù)端在處理 A 請(qǐng)求時(shí)耗時(shí)比較長(zhǎng)，那么后續(xù)的請(qǐng)求的處理都會(huì)被阻塞住,，這稱為「隊(duì)頭堵塞」,。

所以，HTTP/1.1 管道解決了請(qǐng)求的隊(duì)頭阻塞,，但是沒(méi)有解決響應(yīng)的隊(duì)頭阻塞,。實(shí)際上 HTTP/1.1 管道化技術(shù)不是默認(rèn)開(kāi)啟，而且瀏覽器基本都沒(méi)有支持,，所以后面所有文章討論HTTP/1.1 都是建立在沒(méi)有使用管道化的前提,。大家知道有這個(gè)功能，但是沒(méi)有被使用就行了,。

HTTP/1.1 的性能一般般,，后續(xù)的 HTTP/2 和 HTTP/3 就是在優(yōu)化 HTTP 的性能。

5.2 HTTP/1.1,、HTTP/2,、HTTP/3 演變

HTTP/1.1 相比 HTTP/1.0 性能上的改進(jìn)：

• 長(zhǎng)連接改善了 HTTP/1.0 短連接造成的性能開(kāi)銷,。

• 支持管道（pipeline）網(wǎng)絡(luò)傳輸，只要第一個(gè)請(qǐng)求發(fā)出去了,，不必等其回來(lái),，就可以發(fā)第二個(gè)請(qǐng)求出去，可以減少整體的響應(yīng)時(shí)間,。

但 HTTP/1.1 還是有性能瓶頸：

• 請(qǐng)求 / 響應(yīng)頭部（Header）未經(jīng)壓縮就發(fā)送,，首部信息越多延遲越大。只能壓縮 Body 的部分,；

• 發(fā)送冗長(zhǎng)的首部,；

• 服務(wù)器是按請(qǐng)求的順序響應(yīng)的，容易隊(duì)頭阻塞,；

• 沒(méi)有請(qǐng)求優(yōu)先級(jí)控制,；

• 請(qǐng)求只能從客戶端開(kāi)始,，服務(wù)器只能被動(dòng)響應(yīng),。

5.3 HTTP/2 優(yōu)化

HTTP/2 協(xié)議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的,。

那 HTTP/2 相比 HTTP/1.1 性能上的改進(jìn)：

• 頭部壓縮

• 二進(jìn)制格式

• 并發(fā)傳輸

• 服務(wù)器主動(dòng)推送資源

HTTP/2 缺點(diǎn)

HTTP/2 通過(guò) Stream 的并發(fā)能力,，解決了 HTTP/1 隊(duì)頭阻塞的問(wèn)題，看似很好,，但是 HTTP/2 還是存在“隊(duì)頭阻塞”的問(wèn)題,，只不過(guò)問(wèn)題不是在 HTTP 這一層面，而是在 TCP 這一層,。

HTTP/3 做了哪些優(yōu)化,？

前面我們知道了 HTTP/1.1 和 HTTP/2 都有隊(duì)頭阻塞的問(wèn)題：

• HTTP/1.1 中的管道（ pipeline）雖然優(yōu)化了請(qǐng)求的隊(duì)頭阻塞，但是沒(méi)有解決響應(yīng)的隊(duì)頭阻塞,，這屬于 HTTP 層隊(duì)頭阻塞,。

• HTTP/2 雖然通過(guò)多個(gè)請(qǐng)求復(fù)用一個(gè) TCP 連接解決了 HTTP 的隊(duì)頭阻塞 ，基于流水線的傳輸模式,，一旦發(fā)生丟包,，就會(huì)阻塞住所有的 HTTP 請(qǐng)求，這屬于 TCP 層隊(duì)頭阻塞,。

HTTP/2 隊(duì)頭阻塞的問(wèn)題是因?yàn)?TCP,，所因此HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP！

UDP 并不是一個(gè)可靠傳輸,，發(fā)送是不管順序,，也不管丟包的，所以不會(huì)出現(xiàn)像 HTTP/2 隊(duì)頭阻塞的問(wèn)題,。不可靠的 UDP 進(jìn)過(guò)改造后的QUIC 協(xié)議 可以實(shí)現(xiàn)類似 TCP 的可靠性傳輸,。

QUIC 有以下 3 個(gè)特點(diǎn),。

• 無(wú)隊(duì)頭阻塞

• 連接建立更平滑

• 連接遷移更穩(wěn)定

HTTP/3 現(xiàn)在普及的進(jìn)度非常的緩慢，不知道未來(lái) UDP 是否能夠逆襲 TCP,。

參考資料：

• 阮一峰.HTTP 協(xié)議入門(mén).阮一峰的網(wǎng)絡(luò)日志.

• 小林coding圖解http