1。 Internet互聯
萬物互聯已經實實在在的組建在我們生活之中。我們作為網路中的一個節點，不管是否從事IT行業，瞭解HTTP協議對我們使用瀏覽器或其他APP都有一定的幫助，這些不限於
我們是如何能瀏覽網頁的？
我們是如何能使用APP交水電煤的？
我們是如何使用電腦或APP買火車票的？
我們是如何透過電子網站購物的？
我們是如何登入一個系統就可以一直使用這個賬號的？
…
HTTP協議是應用層廣泛使用的一個協議，瞭解它我們需要從
協議的定義、協議的用法、跨服務呼叫（專業稱為跨域請求）、資料快取、長連線和它的版本演進
為大家撥雲開霧的一探究竟。
2。 HTTP協議定義
HTTP
是
H
yperText
T
ransfer
P
rotocol的縮寫，中文翻譯就是超文字傳輸協議。顧名思義：
超文字表示資料型別不在侷限於文字。在網際網路早期的時候只是簡單的字元文字，但現在「文字」的涵義已經可以擴充套件為圖片、影片、壓縮包等；
傳輸表示能雙向溝通；
協議表示一個約定的規範。
即
HTTP是一個應用層協議，無狀態，由請求和響應構成，是一個標準的客戶端伺服器模型。在計算機世界裡一個專門在「兩點」之間「傳輸」文字、圖片、音訊、影片等「超文字」資料的「約定和規範」。
3。 一個具體的HTTP請求分析
舉個栗子，當我們開啟頭條的Web頁面，透過F12開啟控制檯，我們挑選一個請求來分析下HTTP的結構。
這是一個 http 請求以及響應，這裡的 General 可以理解成為 http請求和響應的起始行的一個公共部分，
說明：
Genaral headers： 同時適用於請求和響應訊息，但與最終訊息傳輸的資料無關的訊息頭。
Request Headers： 包含更多有關要獲取的資源或客戶端本身資訊的訊息頭。
Response Headers：包含有關響應的補充資訊，如其位置或伺服器本身（名稱和版本等）的訊息頭。
Entity Headers［其他］：包含有關實體主體的更多資訊，比如主體長（Content-Length）度或其MIME型別。
客戶端傳送一個HTTP請求到伺服器的請求訊息包括以下格式：
請求行
（request line）、
請求頭部
（header）、
空行
和
請求資料
四個部分組成；
3。1 General Headers
通用頭即可以包含在HTTP請求中，也可以包含在HTTP響應中。通用頭的作用是描述HTTP協議本身。比如描述HTTP是否持久連線的Connection頭，HTTP傳送日期的Date頭，描述HTTP所在TCP連線時間的Keep-Alive頭，用於快取控制的Cache-Control頭等
Request URL：請求地址
Request Method：請求方法
Status Code：請求狀態
Remote Address：Remote Address 來自 TCP 連線，表示與服務端建立 TCP 連線的裝置 IP
Referrer-Policy：控制請求頭中
referrer
的內容
HTTP的請求方法
方法
描述
1
GET
（查詢）傳送請求來獲得伺服器上的資源，請求體中不會包含請求資料，請求資料放在協議頭中。
2
POST
（新增）向伺服器提交資源（例如提交表單或上傳檔案）。資料被包含在請求體中提交給伺服器。
3
PUT
（修改）向伺服器提交資源，並使用提交的新資源，替換掉伺服器對應的舊資源。。
4
DELETE
（刪除）請求伺服器刪除指定的資源。
5
HEAD
HEAD 方法請求一個與 GET 請求的響應相同的響應，但沒有響應體。
6
OPTIONS
獲取http伺服器支援的http請求方法，允許客戶端檢視伺服器的效能，比如ajax跨域時的預檢等。
7
CONNECT
建立一個到由目標資源標識的伺服器的隧道。
8
TRACE
沿著到目標資源的路徑執行一個訊息環回測試，主要用於測試或診斷。
9
PATCH
是對 PUT 方法的補充，用來對已知資源進行區域性更新。
3。1。1 GET 和 POST 比較？
根據 RFC 規範
GET 的語義是從伺服器獲取指定的資源
，這個資源可以是靜態的文字、頁面、圖片影片等。GET 請求的引數位置一般是寫在 URL 中，URL 規定只能支援 ASCII，所以 GET 請求的引數只允許 ASCII 字元 ，而且瀏覽器會對 URL 的長度有限制（HTTP協議本身對 URL長度並沒有做任何規定）。
POST 的語義是根據請求負荷（報文body）對指定的資源做出處理
，具體的處理方式視資源型別而不同。POST 請求攜帶資料的位置一般是寫在報文 body 中， body 中的資料可以是任意格式的資料，只要客戶端與服務端協商好即可，而且瀏覽器不會對 body 大小做限制。
3。1。2 GET 和 POST 的安全和冪等性
安全：指請求方法不會「破壞」伺服器上的資源。
冪等：多次執行相同的操作，結果都是「相同」的。
如果從 RFC 規範定義的語義來看：
GET 方法就是安全且冪等的
，因為它是「只讀」操作，無論操作多少次，伺服器上的資料都是安全的，且每次的結果都是相同的。所以，
可以對 GET 請求的資料做快取，這個快取可以做到瀏覽器本身上（徹底避免瀏覽器發請求），也可以做到代理上（如nginx），而且在瀏覽器中 GET 請求可以儲存為書籤
。
POST
因為是「新增或提交資料」的操作，會修改伺服器上的資源，所以是
不安全
的，且多次提交資料就會建立多個資源，所以
不是冪等
的。所以，
瀏覽器一般不會快取 POST 請求，也不能把 POST 請求儲存為書籤
。
3。2 Rquest Headers
實體頭是那些描述HTTP資訊的頭。既可以出現在HTTP POST方法的請求中，也可以出現在HTTP響應中。比如Content-Type和Content-length等描述實體的型別和大小的頭。其它還有用於描述實體的Content-Language、Content-MD5、Content-Encoding以及控制實體快取的Expires、Last-Modifies頭等。
請求頭是那些由客戶端發往服務端以便幫助服務端更好的滿足客戶端請求的頭。請求頭只能出現在HTTP請求中。比如告訴伺服器只接收某種響應內容的Accept頭，傳送Cookies的Cookie頭，顯示請求主機域的HOST頭，用於快取的If-Match、If-Match-Since、If-None-Match頭，用於只取HTTP響應資訊中部分資訊的Range頭，用於附屬HTML相關請求引用的Referer頭等。
引數說明：瀏覽器側的能力
Accept：可以接受的媒體型別，例如： Accept： text/html 代表瀏覽器可以接受伺服器回發的型別為 text/html
Accept-Encoding：申明自己接收的編碼方法，通常指定壓縮方法，是否支援壓縮，支援什麼壓縮方法（gzip，deflate），注意：這不是指字元編碼
Accept-Language：申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等，例如： Accept-Language： en-us
Connection：keep-alive 當一個網頁開啟完成後，客戶端和伺服器之間保持一個長連線。
Referer：當瀏覽器向web伺服器傳送請求的時候，一般會帶上Referer，告訴伺服器我是從哪個頁面連結過來的，伺服器籍此可以獲得一些資訊用於處理。
User-Agent：客戶端使用的作業系統和瀏覽器的名稱和版本。
Cache-Control：Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器快取取資料還是重新發請求到伺服器取資料。
Cookie：Cookie是用來儲存一些使用者資訊以便讓伺服器辨別使用者身份的（大多數需要登入的網站上面會比較常見），比如cookie會儲存一些使用者的使用者名稱和密碼，當用戶登入後就會在客戶端產生一個cookie來儲存相關資訊，這樣瀏覽器透過讀取cookie的資訊去伺服器上驗證並通過後會判定你是合法使用者，從而允許檢視相應網頁。當然cookie裡面的資料不僅僅是上述範圍，還有很多資訊可以儲存在cookie裡面，比如sessionid等。
If-Modified-Since：把瀏覽器端快取頁面的最後修改時間傳送到伺服器去，伺服器會把這個時間與伺服器上實際檔案的最後修改時間進行對比。如果時間一致，那麼返回304，客戶端就直接使用本地快取檔案。如果時間不一致，就會返回200和新的檔案內容。客戶端接到之後，會丟棄舊檔案，把新檔案快取起來，並顯示在瀏覽器中T。
If-None-Match：If-None-Match和ETag一起工作，工作原理是在HTTP Response中新增ETag資訊。 當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match資訊（ETag的值）。如果伺服器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地快取檔案。否則將返回200狀態和新的資源和Etag。
3。3 Response Headers
HTTP響應頭是那些描述HTTP響應本身的頭，這裡面並不包含描述HTTP響應中第三部分也就是HTTP資訊的頭（這部分由實體頭負責）。比如說定時重新整理的Refresh頭，當遇到503錯誤時自動重試的Retry-After頭，顯示伺服器資訊的Server頭，設定COOKIE的Set-Cookie頭，告訴客戶端可以部分請求的Accept-Ranges頭等。
引數說明：
Access-Control-Allow-Credentials：跨域Ajax請求時是否帶Cookie的設定；表示是否允許傳送cookies。預設情況下，Cookies不包括在CORS請求中；設為true表示cookies可以包含在請求中一起發給伺服器，如果不需要傳送cookies給伺服器，需刪除欄位。需要注意的是：除了設定Access-Control-Allow-Credential：true外，在ajax請求中也必須開啟withCredentials
Access-Control-Allow-Methods：必要欄位 ，表示伺服器支援的所有跨域請求方法，只要瀏覽器使用的請求方法包含在內即可透過
Access-Control-Allow-Origin：必要欄位 ，該站點可以被哪些網站進行跨域資源共享
Access-Control-Expose-Headers：必要欄位 ，表明伺服器支援的所有頭資訊欄位，也是為了避免多次預檢請求
Access-Control-Allow-Max-Age ：可選欄位， 單位是s，用來指定本次預檢的有效期，即在給定時間內允許該條快取迴應，不會發出一條預檢請求。
Cache-Control：控制快取的行為 淺談http中的Cache-Control
Connection：“Connection：Keep-Alive”或 “Connection：close”，這裡具體的含義是有關http 請求的是否保持長連線，即連結是否複用，每次請求是複用已建立好的請求，還是重新建立一個新的請求。
Content-Length：在Http 1。0及之前版本中，content-length欄位可有可無；在http1。1及之後版本。如果是keep alive，則content-length和chunk必然是二選一。若是非keep alive，則和http1。0一樣。content-length可有可無。
Content-Encoding：Accept-Encoding 和Content-Encoding是HTTP中用來對採用哪種編碼格式傳輸正文進行協定的一對頭部欄位。
（Content-Encoding 中的 gzip 和 deflate：
gzip，一種由檔案壓縮程式「Gzip，GUN zip」產生的編碼格式，描述於 RFC 1952。這種編碼格式是一種具有 32 位 CRC 的 Lempel-Ziv 編碼（LZ77）；
deflate，由定義於 RFC 1950 的「ZLIB」編碼格式與 RFC 1951 中描述的「DEFLATE」壓縮機制組合而成的產物；）
Content-Type：代表傳送端傳送的實體資料的資料型別（post請求肯定要傳送資料包；因此對資料包的Type有專門的限定：Content-Type只能是application/x-www-form-urlencoded，application/json，multipart/form-data或 text/plain中的一種。）
Keep-Alive：在http早期，每個http請求都要求開啟一個tpc socket連線，並且使用一次之後就斷開這個tcp連線。使用keep-alive可以改善這種狀態，即在一次TCP連線中可以持續傳送多份資料而不會斷開連線。透過使用keep-alive機制，可以減少tcp連線建立次數，也意味著可以減少TIME_WAIT狀態連線，以此提高效能和提高httpd伺服器的吞吐率（更少的tcp連線意味著更少的系統核心呼叫，socket的accept（）和close（）呼叫）。但是，keep-alive並不是免費的午餐，長時間的tcp連線容易導致系統資源無效佔用。配置不當的keep-alive，有時比重複利用連線帶來的損失還更大。所以，正確地設定keep-alive timeout時間非常重要。
HTTP響應訊息由
狀態行
、
響應頭部
、
空行
和
響應體
4個部分組成，如下圖所示：
3。2 HTTP 常見的狀態碼
場景的Status Code說明：
1XX
100（continue） 表明到目前為止都很正常，客戶端可以繼續傳送請求或者忽略這個響應。
2XX
200（OK） 表示從客戶端發來的請求在伺服器端被正常處理了。
204（No Content） 該狀態碼代表伺服器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。
206（Partial Content） 該狀態碼錶示客戶端進行了範圍請求，而伺服器成功執行了這部分的 GET 請求。響應報文中包含由 Content-Range 指定範圍的實體內容。
3XX
301（Moved Permanently） 永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，以後應使用資源現在所指的 URI。
302（Found） 臨時性重定向。比如在沒有登入情況下訪問網站“個人中心”，會重定向到登入頁，但是你登入後，訪問個人中心時，它又不會重定向到其他地方了。
303（See Other） 和 302 有著相同的功能，但是 303 明確要求客戶端應該採用 GET 方法獲取資源。
304（Not Modified） 如果請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則伺服器會返回 304 狀態碼。
4XX
400（Bad Request） 該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次傳送請求。
401 Unauthorized 該狀態碼錶示傳送的請求需要有認證資訊。返回含有 401 的響應必須包含一個適用於被請求資源的 WWW-Authenticate 首部用以詢問使用者資訊。當瀏覽器初次接收到 401 響應，會彈出認證用的對話視窗。第二次接收到，則不彈出，直接表示認證失敗。
403（Forbidden） 對請求資源的訪問被伺服器拒絕了，一般是未獲得檔案系統的訪問授權，問許可權出現某些問題。
404（Not Found） 瀏覽器地址錯誤。伺服器找不到對應資源。
5XX
500（Internal Server Error） 伺服器在執行時報錯。
503（Service Unavailable） 伺服器暫時處於超負載或正在進行停機維護，無響應。一般需要重啟伺服器即可。
4。 HTTP 快取技術
對於一些具有重複性的 HTTP 請求，或者靜態資料檔案，比如css/js/html等，可以把這對「請求-響應」的資料都
快取在本地
，下次就直接讀取本地的資料，進而提高訪問效能。
HTTP 快取的2種實現方式：
強制快取和協商快取
。
強制快取
強制快取：不判斷直接使用瀏覽器的本地快取。強快取是透過下面這兩個 HTTP 響應頭部（Response Header）欄位實現的，它們都用來表示資源在客戶端快取的有效期：
Cache-Control：相對時間；
Expires：絕對時間；
如果 HTTP 響應頭部同時有上面2個欄位的話，
Cache-Control的優先順序高於 Expires
。Cache-Control 配置比較多，建議使用 Cache-Control 來實現強快取進行精細化控制。具體流程如下：
客戶端第一次請求服務資源，伺服器會在返回這個資源的同時，在 Response 頭部加上 Cache-Control，並設定了過期時間大小；
客戶端再次請求請求伺服器中的該資源時，會先
透過請求資源的時間與 Cache-Control 中設定的過期時間大小，來計算出該資源是否過期
，如果沒有，則使用該快取，否則重新請求伺服器；
伺服器再次收到請求後，會更新 Response 頭部的 Cache-Control。
協商快取
當請求的響應碼是 304時，伺服器告訴瀏覽器可以使用本地快取的資源，通常這種方式被稱為協商快取。
協商快取就是與服務端協商之後，透過協商結果來判斷是否使用本地快取
。
協商快取透過配置頭部有2種實現：
第一種：請求頭部 If-Modified-Since 欄位與響應頭部中的 Last-Modified 欄位
Last-Modified：標示這個響應資源的最後修改時間；
If-Modified-Since：當資源過期了，發現響應頭中具有 Last-Modified 宣告，則再次發起請求的時候帶上 Last-Modified 的時間，伺服器收到請求後發現有 If-Modified-Since 則與被請求資源的最後修改時間進行對比（Last-Modified），如果最後修改時間較新，說明資源又被改過，則返回最新資源，HTTP 200 OK；如果最後修改時間較舊，說明資源無新修改，響應 HTTP 304 走快取。
第二種：請求頭部 If-None-Match 欄位與響應頭部中的 ETag 欄位
響應頭部中 Etag：唯一標識響應資源；
請求頭部中的 If-None-Match：當資源過期時，瀏覽器發現響應頭裡有 Etag，則再次向伺服器發起請求資源時，會將請求頭If-None-Match 值設定為 Etag 的值。伺服器收到請求後進行比對，如果沒有變化返回 304，如果變化了返回 200。
第一種方式是基於時間實現的，第二種方式是基於一個唯一標識實現的。對比2種方式，第二種可以更加準確地判斷檔案內容是否被修改，避免由於時間篡改導致的不可靠問題。
如果在第一次請求資源的時候，服務端返回的 HTTP 響應頭部同時有 Etag 和 Last-Modified 欄位，那麼客戶端再下一次請求的時候，如果帶上了 ETag 和 Last-Modified 欄位資訊給服務端，
這時 Etag 的優先順序更高
，也就是服務端先會判斷 Etag 是否變化了，如果 Etag 沒有變化，然後再看 Last-Modified，否則不做其他檢查。
**為什麼 ETag 的優先順序更高？**這是因為 ETag 主要能解決 Last-Modified 存在的問題：
在沒有修改檔案內容情況下檔案的最後修改時間可能也會改變，這會導致客戶端認為這檔案被改動了，從而重新請求；
可能有些檔案是在秒級以內修改的，If-Modified-Since 能檢查到的粒度是秒級的，使用 Etag就能夠保證這種需求下客戶端在 1 秒內能重新整理多次；
有些伺服器不能精確獲取檔案的最後修改時間。
協商快取這兩個欄位都需要配合強制快取中 Cache-control 欄位來使用，只有在未能命中強制快取的時候，才能發起帶有協商快取欄位的請求
。
強制快取和協商快取的工作流程如下：
使用 ETag 欄位實現的協商快取的過程：
當瀏覽器第一次請求訪問伺服器資源時，伺服器會在返回這個資源的同時，在 Response 頭部加上 ETag 唯一標識，它根據當前請求的資源生成；
當瀏覽器再次請求訪問伺服器中的該資源時，會先檢查強制快取是否過期：如果沒有過期，則直接使用本地快取；如果過期了，則會在 Request 頭部加上 If-None-Match 欄位，該欄位的值就是 ETag 唯一標識；
伺服器再次收到請求後，會根據請求中的 If-None-Match 值與當前請求的資源生成的唯一標識進行比較：如果相等，則返回 304；如果不相等，則返回 200 狀態碼和返回資源，並在 Response 頭部加上新的 ETag 唯一標識；
如果瀏覽器收到 304 的請求響應狀態碼，則會從本地快取中載入資源，否則更新資源。
5。 HTTP 特性
HTTP 當前常見到版本有 HTTP/1。1，HTTP/2。0，HTTP/3。0，特性不相容。
5。 1 HTTP/1。1 的優點
HTTP /1。1的優點：
簡單：HTTP 基本的報文格式就是 header + body，頭部資訊也是 key-value 簡單文字的形式，
易於理解
，降低了學習和使用的門檻。
靈活和易於擴充套件：HTTP 協議裡的各類請求方法、URI/URL、狀態碼、頭欄位等每個組成要求都沒有被固定死，都允許開發人員自定義和擴充。
應用廣泛和跨平臺：網際網路發展至今，HTTP 的應用範圍非常的廣泛，從桌上型電腦的瀏覽器到手機上的各種 APP，從看新聞、刷貼吧到購物、理財、吃雞，HTTP 的應用遍地開花，同時天然具有
跨平臺
的優越性。
HTTP/1。1 的缺點：
HTTP 協議裡有優缺點一體的
雙刃劍
，分別是「無狀態、明文傳輸」，同時還有一大缺點「不安全」。
HTTP/1。1 的效能：
HTTP 協議是基於
TCP/IP
，使用了「
請求 - 應答
」的通訊模式。
長連線
HTTP/1。0 效能比較差，原因是每發起一個請求，都要新建一次 TCP 連線（三次握手），而且是序列請求，增加了通訊開銷。
為了解決上述 TCP 連線問題，HTTP/1。1 提出了
長連線
的通訊方式。這種方式的好處在於減少了 TCP 連線的重複建立和斷開所造成的額外開銷，減輕了伺服器端的負載。
持久連線的特點是，只要任意一端沒有明確提出斷開連線，則保持 TCP 連線狀態。如果某個 HTTP 長連線超過一定時間沒有任何資料互動，服務端就會主動斷開這個連線。
管道網路傳輸
HTTP/1。1 採用了長連線的方式，則可以選擇管道（pipeline）傳輸。即可在同一個 TCP 連線裡面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以
減少整體的響應時間。因為管道傳輸是序列的，所以會有一個問題。
如果服務端在處理 A 請求時耗時比較長，那麼後續的請求的處理都會被阻塞住，這稱為「隊頭堵塞」。
所以，
HTTP/1.1 管道解決了請求的隊頭阻塞，但是沒有解決響應的隊頭阻塞
。
實際上 HTTP/1。1 管道化技術不是預設開啟，而且瀏覽器基本都沒有支援，所以
後面所有文章討論HTTP/1.1 都是建立在沒有使用管道化的前提
。大家知道有這個功能，但是沒有被使用就行了。
HTTP/1。1 的效能一般般，後續的 HTTP/2 和 HTTP/3 就是在最佳化 HTTP 的效能。
5。2 HTTP/1。1、HTTP/2、HTTP/3 演變
HTTP/1。1 相比 HTTP/1。0 效能上的改進：
長連線改善了 HTTP/1。0 短連線造成的效能開銷。
支援管道（pipeline）網路傳輸，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的響應時間。
但 HTTP/1。1 還是有效能瓶頸：
請求 / 響應頭部（Header）未經壓縮就傳送，首部資訊越多延遲越大。只能壓縮 Body 的部分；
傳送冗長的首部；
伺服器是按請求的順序響應的，容易隊頭阻塞；
沒有請求優先順序控制；
請求只能從客戶端開始，伺服器只能被動響應。
5。3 HTTP/2 最佳化
HTTP/2 協議是基於 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
那 HTTP/2 相比 HTTP/1。1 效能上的改進：
頭部壓縮
二進位制格式
併發傳輸
伺服器主動推送資源
HTTP/2 缺點
HTTP/2 透過 Stream 的併發能力，解決了 HTTP/1 隊頭阻塞的問題，看似很好，但是 HTTP/2 還是存在“隊頭阻塞”的問題，只不過問題不是在 HTTP 這一層面，而是在 TCP 這一層。
HTTP/3 做了哪些最佳化？
前面我們知道了 HTTP/1。1 和 HTTP/2 都有隊頭阻塞的問題：
HTTP/1。1 中的管道（ pipeline）雖然優化了請求的隊頭阻塞，但是
沒有解決響應的隊頭阻塞
，這屬於 HTTP 層隊頭阻塞。
HTTP/2 雖然透過多個請求複用一個 TCP 連線解決了 HTTP 的隊頭阻塞 ，基於流水線的傳輸模式，
一旦發生丟包，就會阻塞住所有的 HTTP 請求
，這屬於 TCP 層隊頭阻塞。
HTTP/2 隊頭阻塞的問題是因為 TCP，所因此
HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！
UDP 並不是一個可靠傳輸，傳送是不管順序，也不管丟包的，所以不會出現像 HTTP/2 隊頭阻塞的問題。不可靠的 UDP 進過改造後的
QUIC 協議
可以實現類似 TCP 的可靠性傳輸。
QUIC 有以下 3 個特點。
無隊頭阻塞
連線建立更平滑
連線遷移更穩定
HTTP/3 現在普及的進度非常的緩慢，不知道未來 UDP 是否能夠逆襲 TCP。
參考資料：
阮一峰。HTTP 協議入門。阮一峰的網路日誌。
小林coding圖解http
