前端必備的 HTTP 知識
HTTP 起源
HTTP 是由蒂姆·伯納斯-李（TimBerners—Lee）於1989年在歐洲核子研究組織（CERN）所發起
其中最著名的是 1999 年 6 月公布的 RFC 2616，定義了 HTTP 協議中現今廣泛使用的一個版本——HTTP 1.1
HTTP 是什麼
全稱：超文本傳輸協議（HyperText Transfer Protocol）
概念：HTTP 是一種能夠獲取像 HTML、圖片等網絡資源的通訊協議（protocol）。它是在 web 上進行數據交換的基礎，是一種 client-server 協議
HTTP——互聯網的多媒體信使 ——《HTTP權威指南》。
HTTP 在互聯網的角色：充當一個信使的角色，乾的就是一個跑腿的活，在客戶端和服務端之間傳遞信息，但我們又不能缺少它。HTTP 協議是應用層的協議，是與前端開發最息息相關的協議。平時我們遇到的 HTTP 請求、 HTTP 緩存、Cookies、跨域等其實都跟 HTTP 息息相關
HTTP 的基礎特性
-
可拓展協議。
HTTP 1.0出現的HTTP headers讓協議拓展變得更加的容易。只要服務端和客戶端就headers達成語義一致，新功能就可以被輕鬆的加入進來 -
HTTP是無狀態的、有會話的。在同一個連接中，兩個執行成功的HTTP請求之間是沒有關係的。這就帶來了一個問題，用戶沒有辦法在同一個網站中進行連續的交互，比如在一個電商網站里，用戶把某個商品加入到購物車，切換一個頁面後再次添加了商品，這兩次添加商品的請求之間沒有關聯，瀏覽器無法知道用戶最終選擇了哪些商品。而使用HTTP的頭部擴展，HTTP Cookies就可以解決這個問題。把Cookies添加到頭部中，創建一個會話讓每次請求都能共享相同的上下文信息，達成相同的狀態。 -
HTTP與連接。通過TCP，或者TLS——加密的TCP連接來發送，理論上任何可靠的傳輸協議都可以使用。連接是傳輸層控制的，這從根本上來講不是HTTP的範疇。
也就是說，HTTP 依賴於面向連接的 TCP 進行消息傳遞，但連接並不是必須的。只需要它是可靠的，或不丟失消息的（至少返回錯誤）。
HTTP/1.0 默認為每一對 HTTP 請求/響應都打開一個單獨的 TCP 連接。當需要連續發起多個請求時，這種模式比多個請求共享同一個 TCP 鏈接更低效。為此，HTTP 1.1 持久連接的概念，底層 TCP 連接可以通過 connection 頭部實現。但 HTTP 1.1 在連接上也是不完美的，後面我們會提到。
基於 HTTP 的組件系統
HTTP 的組件系統包括客戶端、web 服務器和代理
客戶端：user-agent
瀏覽器，特殊比如是工程師使用的程序，以及 Web 開發人員調試應用程序
Web服務端
由 Web Server 來服務並提供客戶端所請求的文檔。每一個發送到服務器的請求，都會被服務器處理並返回一個消息，也就是 response
代理（Proxies）
在瀏覽器和服務器之間，有很多計算機和其他設備轉發了 HTTP 消息。它們可能出現在傳輸層、網絡層和物理層上，對於 HTTP 應用層而言就是透明的
有如下的一些作用
- 緩存
- 過濾（像防病毒掃描、家長控制）
- 負載均衡
- 認證（對不同的資源進行權限控制）
- 日誌管理
HTTP 報文組成
HTTP 有兩種類型的消息：
- 請求——由客戶端發送用來觸發一個服務器上的動作
- 響應——來自服務器端的應答
HTTP 消息由採用 ASCII 編碼的多行文本構成的。在 HTTP/1.1 以及更早的版本中，這些消息通過連接公開的發送。在 HTTP2.0 中，消息被分到了多個 HTTP 幀中。通過配置文件（用於代理服務器或者服務器），API（用於瀏覽器）或者其他接口提供 HTTP 消息
典型的 HTTP 會話
-
建立連接
在客戶端-服務器協議中，連接是由客戶端發起建立的。在HTTP中打開連接意味着在底層傳輸層啟動連接，通常是TCP。使用TCP時，HTTP服務器的默認端口號是80，另外還有8000和8080也很常用 -
發送客戶端請求
-
服務器響應請求
HTTP 請求和響應
HTTP 請求和響應都包括起始行（start line）、請求頭（HTTP Headers）、空行（empty line）以及 body 部分，如下圖所示：
- 起始行。
請求的起始行：請求方法、請求Path和HTTP版本號
響應的起始行：HTTP版本號、響應狀態碼以及狀態文本描述
下面詳細說下請求 Path，請求路徑（Path）有以下幾種：
1）一個絕對路徑，末尾跟上一個 ‘ ? ‘ 和查詢字符串。這是最常見的形式，稱為 原始形式 (origin form)，被 GET，POST，HEAD 和 OPTIONS 方法所使用
POST / HTTP/1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
2）一個完整的 URL。主要在使用 GET 方法連接到代理的時候使用
GET //developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
3）由域名和可選端口（以’:’為前綴）組成的 URL 的 authority component，稱為 authority form。僅在使用 CONNECT 建立 HTTP 隧道時才使用
CONNECT developer.mozilla.org:80 HTTP/1.1
4）星號形式 (asterisk form)，一個簡單的星號(‘*’)，配合 OPTIONS 方法使用，代表整個服務器。
OPTIONS * HTTP/1.1
-
Headers請求頭或者響應頭。詳見下面的首部。
不區分大小寫的字符串，緊跟着的冒號 (‘😂 和一個結構取決於header的值 -
空行。很多人容易忽略
-
Body
請求 Body 部分：
有些請求將數據發送到服務器以便更新數據：常見的的情況是 POST 請求（包含 HTML 表單數據）。請求報文的 Body 一般為兩類。一類是通過 Content-Type 和 Content-Length 定義的單文件 body。另外一類是由多 Body 組成，通常是和 HTML Form 聯繫在一起的。兩者的不同表現在於 Content-Type的值。
1）Content-Type —— application/x-www-form-urlencoded
對於 application/x-www-form-urlencoded 格式的表單內容，有以下特點:
I.其中的數據會被編碼成以&分隔的鍵值對
II.字符以URL編碼方式編碼。
// 轉換過程: {a: 1, b: 2} -> a=1&b=2 -> 如下(最終形式)
"a%3D1%26b%3D2"
2)Content-Type —— multipart/form-data
請求頭中的 Content-Type 字段會包含 boundary，且 boundary 的值有瀏覽器默認指定。例: Content-Type: multipart/form-data;boundary=----WebkitFormBoundaryRRJKeWfHPGrS4LKe。
數據會分為多個部分，每兩個部分之間通過分隔符來分隔，每部分表述均有 HTTP 頭部描述子包體，如Content-Type，在最後的分隔符會加上–表示結束。
Content-Disposition: form-data;name="data1";
Content-Type: text/plain
data1
----WebkitFormBoundaryRRJKeWfHPGrS4LKe
Content-Disposition: form-data;name="data2";
Content-Type: text/plain
data2
----WebkitFormBoundaryRRJKeWfHPGrS4LKe--
響應 Body 部分：
1）由已知長度的單個文件組成。該類型 body 由兩個 header 定義：Content-Type 和 Content-Length
2）由未知長度的單個文件組成，通過將 Transfer-Encoding 設置為 chunked 來使用 chunks 編碼。
關於 Content-Length 在下面 HTTP 1.0 中會提到，這個是 HTTP 1.0 中新增的非常重要的頭部。
方法
安全方法：HTTP 定義了一組被稱為安全方法的方法。GET 方法和 HEAD 方法都被認為是安全的，這意味着 GET 方法和 HEAD 方法都不會產生什麼動作 —— HTTP 請求不會再服務端產生什麼結果，但這並不意味着什麼動作都沒發生，其實這更多的是 web 開發者決定的
GET：請求服務器發送某個資源HEAD：跟GET方法類似，但服務器在響應中只返回了首部。不會返回實體的主體部分。PUT：向服務器中寫入文檔。語義：用請求的主體部分來創建一個由所請求的URL命名的新文檔POST：用來向服務器中輸入數據的。通常我們提交表單數據給服務器。【POST用於向服務器發送數據，PUT方法用於向服務器上的資源（例如文件）中存儲數據】TRACE：主要用於診斷。實現沿通向目標資源的路徑的消息環回（loop-back）測試 ，提供了一種實用的debug機制。OPTIONS：請求WEB服務器告知其支持的各種功能。可以詢問服務器支持哪些方法。或者針對某些特殊資源支持哪些方法。DELETE：請求服務器刪除請求URL中指定的的資源
GET 和 POST 的區別
首先要了解下副作用和冪等的概念，副作用指的是對服務器端資源做修改。冪等指發送 M 和 N 次請求（兩者不相同且都大於 1），服務器上資源的狀態一致。應用場景上，get是無副作用的，冪等的。post 主要是有副作用的，不冪等的情況
技術上有以下的區分：
- 緩存：
Get請求能緩存，Post請求不能 - 安全：
Get請求沒有Post請求那麼安全，因為請求都在URL中。且會被瀏覽器保存歷史紀錄。POST放在請求體中，更加安全 - 限制：
URL有長度限制，會幹預Get請求，這個是瀏覽器決定的 - 編碼：
GET請求只能進行URL編碼，只能接收ASCII字符，而POST沒有限制。POST支持更多的編碼類型，而且不對數據類型做限制 - 從
TCP的角度，GET請求會把請求報文一次性發出去，而POST會分為兩個TCP數據包，首先發header部分，如果服務器響應100(continue)， 然後發body部分。(火狐瀏覽器除外，它的POST請求只發一個TCP包)
狀態碼
-
100~199——信息性狀態碼
101 Switching Protocols。在HTTP升級為WebSocket的時候，如果服務器同意變更，就會發送狀態碼 101。
-
200~299——成功狀態碼
200 OK，表示從客戶端發來的請求在服務器端被正確處理
204 No content，表示請求成功，但響應報文不含實體的主體部分
205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，但是與 204 響應不同在於要求請求方重置內容
206 Partial Content，進行範圍請求
-
300~399——重定向狀態碼
301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL
303 see other，表示資源存在着另一個 URL，應使用 GET 方法獲取資源
304 not modified，表示服務器允許訪問資源，但因發生請求未滿足條件的情況
307 temporary redirect，臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求
-
400~499——客戶端錯誤狀態碼
400 bad request，請求報文存在語法錯誤
401 unauthorized，表示發送的請求需要有通過 HTTP 認證的認證信息
403 forbidden，表示對請求資源的訪問被服務器拒絕
404 not found，表示在服務器上沒有找到請求的資源
-
500~599——服務器錯誤狀態碼
500 internal sever error，表示服務器端在執行請求時發生了錯誤
501 Not Implemented，表示服務器不支持當前請求所需要的某個功能
503 service unavailable，表明服務器暫時處於超負載或正在停機維護，無法處理請求
首部
HTTP Headers
1.通用首部（General headers）同時適用於請求和響應消息，但與最終消息主體中傳輸的數據無關的消息頭。如 Date
2.請求首部（Request headers）包含更多有關要獲取的資源或客戶端本身信息的消息頭。如 User-Agent
3.響應首部（Response headers）包含有關響應的補充信息
4.實體首部（Entity headers）含有關實體主體的更多信息，比如主體長(Content-Length)度或其 MIME 類型。如 Accept-Ranges
詳細的 Header 見 HTTP Headers 集合
HTTP 的前世今生
HTTP（HyperText Transfer Protocol）是萬維網（World Wide Web）的基礎協議。Tim Berners-Lee 博士和他的團隊在1989-1991年間創造出它。【HTTP、網絡瀏覽器、服務器】
在 1991 年發佈了 HTTP 0.9 版，在 1996 年發佈 1.0 版，1997 年是 1.1 版，1.1 版也是到今天為止傳輸最廣泛的版本。2015 年發佈了 2.0 版，其極大的優化了 HTTP/1.1 的性能和安全性，而 2018 年發佈的 3.0 版，繼續優化 HTTP/2，激進地使用 UDP 取代 TCP 協議，目前，HTTP/3 在 2019 年 9 月 26 日 被 Chrome，Firefox，和 Cloudflare 支持
HTTP 0.9
單行協議，請求由單行指令構成。以唯一可用的方法 GET 開頭。後面跟的是目標資源的路徑
GET /mypage.html
響應：只包括響應文檔本身
<HTML>
這是一個非常簡單的HTML頁面
</HTML>
- 沒有響應頭，只傳輸
HTML文件 - 沒有狀態碼
HTTP 1.0
RFC 1945 提出了 HTTP1.0，構建更好可拓展性
- 協議版本信息會隨着每個請求發送
- 響應狀態碼
- 引入了
HTTP頭的概念，無論是請求還是拓展，允許傳輸元數據。使協議變得靈活，更加具有拓展性 Content-Type請求頭，具備了傳輸除純文本HTML文件以外其他類型文檔的能力
在響應中，Content-Type標頭告訴客戶端實際返回的內容的內容類型
媒體類型是一種標準。用來表示文檔、文件或者位元組流的性質和格式。瀏覽器通常使用 MIME （Multipurpose Internet Mail Extensions ）類型來確定如何處理 URL，因此 Web 服務器在響應頭中配置正確的 MIME 類型會非常的重要。如果配置不正確，可能會導致網站無法正常的工作。MIME 的組成結構非常簡單；由類型與子類型兩個字符串中間用’/’分隔而組成。
HTTP 從 MIME type 取了一部分來標記報文 body 部分的數據類型，這些類型體現在Content-Type 這個字段，當然這是針對於發送端而言，接收端想要收到特定類型的數據，也可以用 Accept 字段。
這兩個字段的取值可以分為下面幾類:
- text： text/html, text/plain, text/css 等
- image: image/gif, image/jpeg, image/png 等
- audio/video: audio/mpeg, video/mp4 等
- application: application/json, application/javascript, application/pdf, application/octet-stream
同時為了約定請求的數據和響應數據的壓縮方式、支持語言、字符集等，還提出了以下的 Header
1.壓縮方式:發送端：Content-Encoding（服務端告知客戶端，服務器對實體的主體部分的編碼方式） 和 接收端：Accept-Encoding（用戶代理支持的編碼方式），值有 gzip: 當今最流行的壓縮格式；deflate: 另外一種著名的壓縮格式；br: 一種專門為 HTTP 發明的壓縮算法
2.支持語言：Content-Language 和 Accept-Language（用戶代理支持的自然語言集）
3.字符集：發送端：Content-Type 中，以 charset 屬性指定。接收端： Accept-Charset（用戶代理支持的字符集）。
// 發送端
Content-Encoding: gzip
Content-Language: zh-CN, zh, en
Content-Type: text/html; charset=utf-8
// 接收端
Accept-Encoding: gzip
Accept-Language: zh-CN, zh, en
Accept-Charset: charset=utf-8
雖然 HTTP1.0 在 HTTP 0.9 的基礎上改進了很多，但還是存在這不少的缺點
HTTP/1.0 版的主要缺點是，每個 TCP 連接只能發送一個請求。發送數據完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。
TCP 連接的新建成本很高，因為需要客戶端和服務器三次握手，並且開始時發送速率較慢（slow start）。
HTTP 最早期的模型，也是 HTTP/1.0 的默認模型，是短連接。每一個 HTTP 請求都由它自己獨立的連接完成；這意味着發起每一個 HTTP 請求之前都會有一次 TCP 握手，而且是連續不斷的。
HTTP 1.1
HTTP/1.1 在1997年1月以 RFC 2068 文件發佈。
HTTP 1.1 消除了大量歧義內容並引入了多項技術
-
連接可以復用。長連接：
connection: keep-alive。HTTP 1.1支持長連接（PersistentConnection），在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。 -
增加了管道化技術（
HTTP Pipelinling），允許在第一個應答被完全發送完成之前就發送第二個請求，以降低通信延遲。復用同一個TCP連接期間，即便是通過管道同時發送了多個請求，服務端也是按請求的順序依次給出響應的；而客戶端在未收到之前所發出所有請求的響應之前，將會阻塞後面的請求(排隊等待)，這稱為”隊頭堵塞”（Head-of-line blocking）。 -
支持響應分塊，分塊編碼傳輸：
Transfer-Encoding: chunked
Content-length聲明本次響應的數據長度。keep-alive連接可以先後傳送多個響應，因此用Content-length來區分數據包是屬於哪一個響應。
使用Content-Length字段的前提條件是，服務器發送響應之前，必須知道響應的數據長度。 對於一些很耗時的動態操作來說，這意味着，服務器要等到所有操作完成，才能發送數據，顯然這樣的效率不高。更好的處理方法是，產生一塊數據，就發送一塊，採用”流模式”（Stream）取代”緩存模式”（Buffer）。因此，HTTP 1.1規定可以不使用Content-Length字段，而使用”分塊傳輸編碼”（Chunked Transfer Encoding）。只要請求或響應的頭信息有Transfer-Encoding: chunked字段，就表明body將可能由數量未定的多個數據塊組成。
每個數據塊之前會有一行包含一個 16 進制數值，表示這個塊的長度；最後一個大小為 0 的塊，就表示本次響應的數據發送完了。 -
引入額外的緩存控制機制。在
HTTP1.0中主要使用header里的If-Modified-Since,Expires等來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag,If-None-Match，Cache-Control等更多可供選擇的緩存頭來控制緩存策略。 -
Host頭。不同的域名配置同一個IP地址的服務器。Host是HTTP 1.1協議中新增的一個請求頭，主要用來實現虛擬主機技術。
虛擬主機（virtual hosting）即共享主機（shared web hosting），可以利用虛擬技術把一台完整的服務器分成若干個主機，因此可以在單一主機上運行多個網站或服務。
舉個栗子，有一台 ip 地址為 61.135.169.125 的服務器，在這台服務器上部署着谷歌、百度、淘寶的網站。為什麼我們訪問 //www.google.com 時，看到的是 Google 的首頁而不是百度或者淘寶的首頁？原因就是 Host 請求頭決定着訪問哪個虛擬主機。
HTTP 2.0
2015年，HTTP2.0 面世。rfc7540
HTTP/2是二進制協議而不是文本協議。先來看幾個概念：- 幀：客戶端與服務器通過交換幀來通信，幀是基於這個新協議通信的最小單位。
- 消息：是指邏輯上的 HTTP 消息，比如請求、響應等，由一或多個幀組成。
- 流：流是連接中的一個虛擬信道，可以承載雙向的消息；每個流都有一個唯一的整數標識符
HTTP 2.0 中的幀將 HTTP/1.x 消息分成幀並嵌入到流 (stream) 中。數據幀和報頭幀分離，這將允許報頭壓縮。將多個流組合，這是一個被稱為多路復用 (multiplexing) 的過程，它允許更有效的底層 TCP 連接。
也就是說，流用來承載消息，消息又是有一個或多個幀組成。二進制傳輸的方式更加提升了傳輸性能。
每個數據流都以消息的形式發送，而消息又由一個或多個幀組成。 幀是流中的數據單位。
HTTP 幀現在對 Web 開發人員是透明的。在 HTTP/2 中，這是一個在 HTTP/1.1 和底層傳輸協議之間附加的步驟。Web 開發人員不需要在其使用的 API 中做任何更改來利用 HTTP 幀；當瀏覽器和服務器都可用時，HTTP/2 將被打開並使用。
- 這是一個復用協議。並行的請求能在同一個連接中處理，移除了
HTTP/1.x中順序和阻塞的約束。多路復用允許同時通過單一的HTTP/2連接發起多重的請求-響應消息
之前我們提到，雖然 HTTP 1.1 有了長連接和管道化的技術，但是還是會存在 隊頭阻塞。而 HTTP 2.0 就解決了這個問題
HTTP/2 中新的二進制分幀層突破了這些限制，實現了完整的請求和響應復用：客戶端和服務器可以將 HTTP 消息分解為互不依賴的幀，然後交錯發送，最後再在另一端把它們重新組裝起來。
如上圖所示，快照捕捉了同一個連接內並行的多個數據流。 客戶端正在向服務器傳輸一個 DATA 幀（數據流 5），與此同時，服務器正向客戶端交錯發送數據流 1 和數據流 3 的一系列幀。因此，一個連接上同時有三個並行數據流。
將 HTTP 消息分解為獨立的幀，交錯發送，然後在另一端重新組裝是 HTTP 2 最重要的一項增強。事實上，這個機制會在整個網絡技術棧中引發一系列連鎖反應，從而帶來巨大的性能提升，讓我們可以：
1.並行交錯地發送多個請求，請求之間互不影響。
2.並行交錯地發送多個響應，響應之間互不干擾。
3.使用一個連接並行發送多個請求和響應。
4.消除不必要的延遲和提高現有網絡容量的利用率，從而減少頁面加載時間。
5.不必再為繞過 HTTP/1.x 限制而做很多工作(比如精靈圖)
…
連接共享，即每一個 request 都是是用作連接共享機制的。一個 request 對應一個 id，這樣一個連接上可以有多個 request，每個連接的 request 可以隨機的混雜在一起，接收方可以根據 request 的 id 將 request 再歸屬到各自不同的服務端請求裏面。
HTTP 1.1 和 HTTP 2.0 的對比，可以參考這個 網站 demo 演示
HTTP 1.1 演示如下：
HTTP2.0 演示如下：
- 壓縮了
headers。HTTP1.x的header帶有大量信息，而且每次都要重複發送，就造成了性能的損耗。 為了減少此開銷和提升性能，HTTP/2使用HPACK壓縮格式壓縮請求和響應標頭元數據，這種格式採用兩種簡單但是強大的技術：
這種格式支持通過靜態霍夫曼代碼對傳輸的標頭字段進行編碼，從而減小了各個傳輸的大小。
這種格式要求客戶端和服務器同時維護和更新一個包含之前見過的標頭字段的索引列表（換句話說，它可以建立一個共享的壓縮上下文），此列表隨後會用作參考，對之前傳輸的值進行有效編碼。
- 服務端推送。其允許服務器在客戶端緩存中填充數據，通過一個叫服務器推送的機制來提前請求。服務器向客戶端推送資源無需客戶端明確地請求，服務端可以提前給客戶端推送必要的資源，這樣可以減少請求延遲時間，例如服務端可以主動把
JS和CSS文件推送給客戶端，而不是等到HTML解析到資源時發送請求，這樣可以減少延遲時間大致過程如下圖所示：
如何升級你的 HTTP 版本
使用 HTTP/1.1 和 HTTP/2 對於站點和應用來說是透明的。擁有一個最新的服務器和新點的瀏覽器進行交互就足夠了。只有一小部分群體需要做出改變，而且隨着陳舊的瀏覽器和服務器的更新，而不需 Web 開發者做什麼，用的人自然就增加了
HTTPS
HTTPS 也是通過 HTTP 協議進行傳輸信息，但是採用了 TLS 協議進行了加密
對稱加密和非對稱加密
對稱加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。但是因為傳輸數據都是走的網絡，如果將秘鑰通過網絡的方式傳遞的話，一旦秘鑰被截獲就沒有加密的意義的
非對稱加密
公鑰大家都知道，可以用公鑰加密數據。但解密數據必須使用私鑰，私鑰掌握在頒發公鑰的一方。首先服務端將公鑰發佈出去，那麼客戶端是知道公鑰的。然後客戶端創建一個秘鑰，並使用公鑰加密，發送給服務端。服務端接收到密文以後通過私鑰解密出正確的秘鑰
TLS 握手過程
TLS 握手的過程採用的是非對稱加密
Client Hello: 客戶端發送一個隨機值(Random1)以及需要的協議和加密方式。Server Hello以及Certificate: 服務端收到客戶端的隨機值，自己也產生一個隨機值(Random2)，並根據客戶端需求的協議和加密方式來使用對應的方式，並且發送自己的證書（如果需要驗證客戶端證書需要說明）Certificate Verify: 客戶端收到服務端的證書並驗證是否有效，驗證通過會再生成一個隨機值(Random3)，通過服務端證書的公鑰去加密這個隨機值並發送給服務端，如果服務端需要驗證客戶端證書的話會附帶證書Server 生成 secret: 服務端收到加密過的隨機值並使用私鑰解密獲得第三個隨機值(Random3)，這時候兩端都擁有了三個隨機值，可以通過這三個隨機值按照之前約定的加密方式生成密鑰，接下來的通信就可以通過該密鑰來加密解密
HTTP 緩存
強緩存
強緩存主要是由 Cache-control 和 Expires 兩個 Header 決定的
Expires 的值和頭裏面的 Date 屬性的值來判斷是否緩存還有效。Expires 是 Web 服務器響應消息頭字段，在響應 http 請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據，而無需再次請求。Expires 的一個缺點就是，返回的到期時間是服務器端的時間，這是一個絕對的時間，這樣存在一個問題，如果客戶端的時間與服務器的時間相差很大（比如時鐘不同步，或者跨時區），那麼誤差就很大。
Cache-Control 指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。但是其設置的是一個相對時間。
指定過期時間：max-age 是距離請求發起的時間的秒數，比如下面指的是距離發起請求 31536000S 內都可以命中強緩存
Cache-Control: max-age=31536000
表示沒有緩存
Cache-Control: no-store
有緩存但要重新驗證
Cache-Control: no-cache
私有和公共緩存
public 表示響應可以被任何中間人（比如中間代理、CDN 等緩存）
而 private 則表示該響應是專用於某單個用戶的，中間人不能緩存此響應，該響應只能應用於瀏覽器私有緩存中。
Cache-Control: private
Cache-Control: public
驗證方式：以下表示一旦資源過期（比如已經超過 max-age），在成功向原始服務器驗證之前，緩存不能用該資源響應後續請求
Cache-Control: must-revalidate
Cache-control 優先級比 Expires 優先級高
以下是一個 Cache-Control 強緩存的過程：
- 首次請求，直接從 server 中獲取。其中會設置
max-age=100 - 第二次請求，
age=10，小於 100，則命中Cache，直接返回 - 第三次請求，
age=110，大於 110。強緩存失效，就需要再次請求Server
協商緩存
If-Modified-Since——Last-Modified
Last-Modified 表示本地文件最後修改日期，瀏覽器會在 request header 加上 If-Modified-Since（上次返回的 Last-Modified 的值），詢問服務器在該日期後資源是否有更新，有更新的話就會將新的資源發送回來
但是如果在本地打開緩存文件，就會造成 Last-Modified 被修改，所以在 HTTP / 1.1 出現了 ETag
If-none-match——ETags
Etag 就像一個指紋，資源變化都會導致 ETag 變化，跟最後修改時間沒有關係，ETag 可以保證每一個資源是唯一的。If-None-Match 的 header 會將上次返回的 Etag 發送給服務器，詢問該資源的 Etag 是否有更新，有變動就會發送新的資源回來
If-none-match、ETags 優先級高於 If-Modified-Since、Last-Modified
第一次請求：
第二次請求相同網頁：
協商緩存，假如沒有改動的話，返回 304 ，改動了返回 200 資源
- 200：強緩存
Expires/Cache-Control失效時，返回新的資源文件 - 200
(from cache): 強緩Expires/Cache-Control兩者都存在，未過期，Cache-Control優先Expires時，瀏覽器從本地獲取資源成功 - 304
(Not Modified)：協商緩存Last-modified/Etag沒有過期時，服務端返回狀態碼304
現在的200(from cache)已經變成了 disk cache(磁盤緩存)和 memory cache(內存緩存)兩種
revving 技術
上面提到 HTTP 緩存相關，但是很多有時候，我們希望上線之後需要更新線上資源。
web 開發者發明了一種被 Steve Souders 稱之為 revving 的技術。不頻繁更新的文件會使用特定的命名方式：在 URL 後面（通常是文件名後面）會加上版本號。
弊端：更新了版本號，所有引用這些的資源的地方的版本號都要改變
web 開發者們通常會採用自動化構建工具在實際工作中完成這些瑣碎的工作。當低頻更新的資源（js/css）變動了，只用在高頻變動的資源文件（html）里做入口的改動。
Cookies
HTTP Cookie（也叫 Web Cookie 或瀏覽器 Cookie）是服務器發送到用戶瀏覽器並保存在本地的一小塊數據，它會在瀏覽器下次向同一服務器再發起請求時被攜帶並發送到服務器上。
創建 cookie
Set-Cookie 響應頭部和 Cookie 請求頭部
Set-Cookie: <cookie名>=<cookie值>
會話期Cookie
會話期Cookie是最簡單的 Cookie：瀏覽器關閉之後它會被自動刪除，也就是說它僅在會話期內有效。會話期 Cookie 不需要指定過期時間（Expires）或者有效期（Max-Age）。需要注意的是，有些瀏覽器提供了會話恢復功能，這種情況下即使關閉了瀏覽器，會話期 Cookie 也會被保留下來，就好像瀏覽器從來沒有關閉一樣
持久性Cookie
和關閉瀏覽器便失效的會話期 Cookie 不同，持久性 Cookie 可以指定一個特定的過期時間（Expires）或有效期（Max-Age）。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Cookie的Secure和HttpOnly 標記
標記為 Secure 的 Cookie 只應通過被 HTTPS 協議加密過的請求發送給服務端。
標記為 Secure 的 Cookie 只應通過被 HTTPS 協議加密過的請求發送給服務端。但即便設置了 Secure 標記，敏感信息也不應該通過 Cookie 傳輸，因為 Cookie 有其固有的不安全性，Secure 標記也無法提供確實的安全保障
通過 JavaScript 的 Document.cookie API 是無法訪問帶有 HttpOnly 標記的 cookie。這麼做是為了避免跨域腳本攻擊（XSS）
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Cookie的作用域
Domain 和 Path 標識定義了 Cookie 的作用域：即 Cookie 應該發送給哪些 URL。
Domain 標識指定了哪些主機可以接受 Cookie。如果不指定，默認為當前的主機（不包含子域名）。如果指定了 Domain，則一般包含子域名。
例如，如果設置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如developer.mozilla.org）。
Path 標識指定了主機下的哪些路徑可以接受 Cookie（該 URL 路徑必須存在於請求 URL 中）。以字符 %x2F (“/”) 作為路徑分隔符，子路徑也會被匹配。
例如，設置 Path=/docs，則以下地址都會匹配：
/docs
/docs/Web/
/docs/Web/HTTP
SameSite Cookies
SameSite Cookie 允許服務器要求某個 cookie 在跨站請求時不會被發送，從而可以阻止跨站請求偽造攻擊
None瀏覽器會在同站請求、跨站請求下繼續發送cookies，不區分大小寫。【舊版本chrome默認Chrome 80版本之前】Strict瀏覽器將只在訪問相同站點時發送cookie。Lax將會為一些跨站子請求保留，如圖片加載或者frames的調用，但只有當用戶從外部站點導航到URL時才會發送。如link鏈接
Set-Cookie: key=value; SameSite=Strict
None Strict Lax
在新版本的瀏覽器（Chrome 80 之後）中，SameSite 的默認屬性是 SameSite=Lax。換句話說，當 Cookie 沒有設置 SameSite 屬性時，將會視作 SameSite 屬性被設置為 Lax —— 這意味着 Cookies 將不會在當前用戶使用時被自動發送。如果想要指定 Cookies 在同站、跨站請求都被發送，那麼需要明確指定SameSite 為 None。因為這一點，我們需要好好排查舊系統是否明確指定 SameSite，以及推薦新系統明確指定 SameSite，以兼容新舊版本 Chrome
更多 cookie 相關，可以查看我之前總結的一篇關於 cookie 的文章 前端須知的 Cookie 知識小結
HTTP訪問控制（CORS）
跨域資源共享（CORS）是一種機制，它使用額外的 HTTP 頭告訴瀏覽器，讓運行在一個 origin (domain) 上的 web 應用被准許訪問來自不同源服務器上的指定的資源
跨域資源共享標準新增了一組 HTTP 首部字段，允許服務器聲明哪些源站通過瀏覽器有權限訪問哪些資源。
簡單請求
簡單請求（不會觸發 CORS 的預檢請求）需要同時滿足以下三點：
-
方法是
GET/HEAD/POST之一 -
Content-Type的值僅限text/plain、multipart/form-data、application/x-www-form-urlencoded三者之一 -
HTTP頭部不能超過以下字段：Accept、Accept-Language、Content-Language
Content-Type（需要注意額外的限制）DPR、Downlink、Save-Data、Viewport-Width、Width
以下為一個簡單請求的請求報文以及響應報文
簡化以下：
請求首部字段 Origin 表明該請求來源於 //foo.example
本例中，服務端返回的 Access-Control-Allow-Origin: * 表明，該資源可以被任意外域訪問。如果服務端僅允許來自 //foo.example 的訪問，該首部字段的內容如下：
Access-Control-Allow-Origin: //foo.example
Access-Control-Allow-Origin 應當為 * 或者包含由 Origin 首部字段所指明的域名。
預檢請求
規範要求，對那些可能對服務器數據產生副作用的 HTTP 請求方法。瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否允許該跨域請求。
服務器確認允許之後，才發起實際的 HTTP 請求。在預檢請求的返回中，服務器端也可以通知客戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關數據）
預檢請求中同時攜帶了下面兩個首部字段：
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
首部字段 Access-Control-Request-Method 告知服務器，實際請求將使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服務器，實際請求將攜帶兩個自定義請求首部字段：X-PINGOTHER 與 Content-Type。服務器據此決定，該實際請求是否被允許。
預檢請求的響應中，包括了以下幾個字段
Access-Control-Allow-Origin: //foo.example
// 表明服務器允許客戶端使用 POST, GET 和 OPTIONS 方法發起請求
Access-Control-Allow-Methods: POST, GET, OPTIONS
// 表明服務器允許請求中攜帶字段 X-PINGOTHER 與 Content-Type
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
// 表明該響應的有效時間為 86400 秒，也就是 24 小時。在有效時間內，瀏覽器無須為同一請求再次發起預檢請求。
Access-Control-Max-Age: 86400
一般而言，對於跨域 XMLHttpRequest 或 Fetch 請求，瀏覽器不會發送身份憑證信息。如果要發送憑證信息，需要設置 XMLHttpRequest 的某個特殊標誌位。比如說 XMLHttpRequest 的 withCredentials 標誌設置為 true，則可以發送 cookie 到服務端。
對於附帶身份憑證的請求，服務器不得設置 Access-Control-Allow-Origin 的值為「*」。
這是因為請求的首部中攜帶了 Cookie 信息，如果 Access-Control-Allow-Origin 的值為「*」，請求將會失敗。而將 Access-Control-Allow-Origin 的值設置為 //foo.example，則請求將成功執行。
CORS 涉及到的請求和響應頭如下：
HTTP 響應首部字段
Access-Control-Allow-Origin允許訪問該資源的外域URI。對於不需要攜帶身份憑證的請求，服務器可以指定該字段的值為通配符，表示允許來自所有域的請求。Access-Control-Expose-Headers頭讓服務器把允許瀏覽器訪問的頭放入白名單Access-Control-Max-Age頭指定了preflight請求的結果能夠被緩存多久Access-Control-Allow-Credentials頭指定了當瀏覽器的credentials設置為true時是否允許瀏覽器讀取response的內容。Access-Control-Allow-Methods首部字段用於預檢請求的響應。其指明了實際請求所允許使用的HTTP方法。Access-Control-Allow-Headers首部字段用於預檢請求的響應。其指明了實際請求中允許攜帶的首部字段。
HTTP 請求首部字段
Origin首部字段表明預檢請求或實際請求的源站Access-Control-Request-Method首部字段用於預檢請求。其作用是，將實際請求所使用的 HTTP 方法告訴服務器。Access-Control-Request-Headers首部字段用於預檢請求。其作用是，將實際請求所攜帶的首部字段告訴服務器。
