嗨~鐵汁兒，肯定不來搞一下HTTP嘛？

不積跬步無以致千里，只有紮實的基礎你纔有可能放眼將來。 本篇文章的圖片借鑑於網絡與圖解HTTP，我的繪圖水平有限（本身畫的太醜了）。正題：總結原則首先知識閉環（即知識的全面性）其次二八原則即重點詳寫（可是好像重點賊拉多） 最後 若有誤，望指教 。感恩！

本篇主要總結的知識點

要開始咯！！！

一：網絡基礎鋪墊篇

​ HTTP協議是構建在TCP/IP協議之上的，它依靠網絡層ip協議實現尋址和路由、依靠傳輸層的tcp協議實現可靠的字節流服務（即提供可靠的數據傳輸）、依靠應用層的DNS協議進行域名解析

​ 故爲了更好了解HTTP，我們纔來回憶一下TCP/IP,DNS這些與HTTP息息相關的東西

​ 注意這裏的TCP/IP不是單指這兩種協議，這裏是指一系列網絡通訊協議的總稱。固然既然是以TCP/IP這樣的命名那麼這兩種協議固然是核心中核心

​ 小黑：爲啥？

​ 我：一個負責對方地址的尋找一個負責數據的傳輸這對於二者通訊而言還不核心？

1.1 來看TCP/IP協議族的四層架構

同OSI七層模型一一對比，能夠看到自己沒什麼區別的。如圖：

​ 主要看一下TCP/IP四層中分別作了什麼

• 應用層：決定了向用戶提供應用服務時通訊的活動，如FTP、DNS、HTTP等
• 傳輸層：嚮應用層提供處於網絡鏈接中的兩臺計算機之間的數據傳輸功能，TCP、UDP
• 網絡層：用於處理在網絡上流動的數據包，這層規定了經過一個什麼樣的路徑把數據交給對方計算機 ，IP
• 鏈路層：這一層用於處理鏈接網絡的硬件部分，包括控制操做系統、硬件設備驅動、NIC以及光纖等物理可見部分。能夠說硬件上的範疇均在鏈路層的做用範圍以內

嗯...其實仍是比較好理解的吧。就是好比使用一個web程序，我想通訊確定先得發一個http請求吧，而後傳輸層的保證數據的傳輸、網絡層的保證我數據能發給對方、鏈路層就後勤保證唄

1.2 通訊數據流

這裏簡單理解，首先客戶端發了一個http請求，這個請求數據會向下走。走到傳輸層（加了啥工這裏無論了）加了一個TCP首部（標記序號、端口號），再往下走，走到網絡層再給加一個IP首部（MAC地址）這時就能夠發出去了。

數據在服務處就能夠從下往上走，過了網絡層去掉IP首部，過了傳輸層去掉TCP首部，到達應用層完成任務

1.3 TCP如何保證可靠傳輸

小黑：三次握手唄，是我的就知道。

NO！！！ 我偏要先說一下TCP說是提供可靠的字節流服務，那麼什麼是字節流服務？

嘿嘿，所謂字節流服務是指，爲方便傳輸將大塊數據分割成以報文段爲單位的數據包進行管理

開始握手吧

爲了保證可靠性，TCP採用三次握手策略。握手過程當中使用了TCP的標誌：SYN和ACK

小黑：標誌？什麼玩意啊，有啥意思啊？

我：來看一下TCP報文中比較重要的字段吧

• 序號：Seq， 用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記

• 確認號： Ack序號，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。

• 標記位： 共6個，即URG、ACK、PSH、RST、SYN、FIN等。具體含義以下：

  • URG：緊急指針（urgent pointer）有效。
  • ACK：確認序號有效。
  • PSH：接收方應該儘快將這個報文交給應用層。
  • RST：重置鏈接。
  • SYN：發起一個新鏈接。
  • FIN：釋放一個鏈接。

  注意：確認方Ack=發送方Seq+1，表示兩端配對。不要把確認號的Ack和標記位的Ack搞混了

  接下來看一下下面的的圖是否是一目瞭然了呢

小黑：那他爲啥要握三次手嘞，誰規定的

我：嗯...，沒人規定。三次是最最最合適的次數。由於要保證可靠，故發送和接收雙方都須要保證本身和對方的收發功能是正常的。

首先，發送方發送完成以後被接收方第一次接收。此時接收方可以獲得結論，發送方的方式功能是正常的，我本身的接收功能是正常的。

而後，第二次握手。此時發送方收到了接收方的回信。它能獲得結論，它本身的發送功能是正常的(不然哪來的回信)，它本身的接收功能是正常的，對方的發送功能是正常的，對方的接收是正常的

最後，第三次握手，信息給到接收方以後，接收方又獲得結論，本身發送功能沒問題，對方接收功能沒問題

既然都沒問題，那就放心的開始數據傳輸了

1.4 DNS域名解析

TCP/IP協議中使用IP地址標識計算機，可是一串數字計算機是比較容易處理，可是對於人類來講卻很差記，因而域名就出現

同時爲了更好的標記不一樣國家和組織，域名又被設計成一個有層次的結構。有.分割，越往右級別越高。例如.com這類的頂級域名

域名解析要作的事情就是將域名解析回IP地址

世界上一個有13組根DNS服務器，咱們確定不能每次訪問一個網站前就是訪問一下這13組根服務器吧。全球那麼用戶就是某一時刻的人數奇數也可怕的很啊，不把它們整爆了

事實上當我好比在地址欄輸入掘金的域名時，會先找咱們的.host文件看看裏面有沒有記錄其對應的IP地址呢。沒有找本地的DNS服務器，仍是沒有找距離本身比較近的DNS（好比按打官司上訪開始找省一級的了）尚未再往上（國家級的）直到最後的根DNS

1.5 URI&URL

仍是URI與URL傻傻分不清嗎？ URI：是統一資源標示符，能夠惟一標識一個資源。 URL：統一資源定位符，能夠提供找到該資源的路徑 關係：URL是URI的一個子集

小黑：別人都這麼說，你能不能別講廢話了。給個例子看看

我： 總之它兩都是對一個資源的標識，我在知乎看到一遍回答給的栗子我以爲蠻形象的 拿現實舉例： URI比如一我的的身份證號，即對於一我的來講咱們能夠用這個身份證號來標識它 URL又是如何標識這我的的呢，它的形式爲 協議：//中國/北京/海淀區/魏公莊/xx大學/xx宿舍/宮小白 這樣區分應該蠻清楚的吧URL不只能夠表示標識這我的還定位到這我的的位置

故一個咱們在地址欄裏輸入的都是URL，由於咱們最終的目的是獲取這個被標識的資源，確定須要夠定位到它的位置吧

二： http初始篇

2.1 什麼是HTTP

HTTP => 超文本傳輸協議。即拆分理解超文本，傳輸，協議。

HTTP首先是一個協議，協議即規則。它使用計算機可以理解的語言確立了一種計算機之間的交流通訊的規範，以及相關的各類控制和錯誤處理方式

再者接着了理解傳輸，傳輸即a->b之間的有關某一種東西的傳送。固然在HTTP中a與b之間的傳輸是雙向的

最後再來看超文本，所謂超文本就是超越了普通文本之上的文本，它是文字、圖片、yinshipin等的混合體且能夠含有超連接，能夠從一個超文本轉到另外一個超文本。固然這裏咱們熟悉的超文本即是HTTML了

總結：HTTP是一個在計算機世界裏專門在兩點之間傳輸 文字圖片等超文本數據的一種約定規範

2.2 HTTP中的報文頭

對於HTTP報文的基本結構咱們應該是很熟悉了。即它有三部分組成：起始行、頭部、實體。（注意頭部和實體之間必須有空行）

起始行的信息相對比較簡單

請求行：

由三部分組成

• 請求方法，如get或post等
• 請求目標，通常是一個URI，如/index.php
• 協議版本號

例子：

GET /index.php HTTP/1.1
複製代碼

響應行：在這裏它其實叫作狀態行

一樣由三部分組成

• 版本號，HTTP的版本
• 狀態碼，如200表示成功
• 緣由，它是狀態碼的補充

例子：

HTTP/1.1 200 ok
複製代碼

接下來主要看報文頭吧

在HTTP中所規範的頭部字段一共有大幾十中，故所有總結是不可能的。。。

報文頭的數據格式爲{key：value}形式

經常使用頭能夠分爲如下四類：

• 通用字段——>便可同時出如今請求頭和響應頭裏面
• 請求字段——>僅能出如今請求頭裏
• 響應字段——>僅能出如今響應頭裏
• 實體字段——>它其實是屬於通用字段，專門用於描述body的額外信息

Date

通用字段，描述了報文發送的時間

Connection

通用字段，可指定本次鏈接的類型。若值爲keep-alive。表示一個請求完成以後本次的tcp鏈接不會關閉，後面能夠繼續使用；若值爲close，則表示一個請求完成以後tcp鏈接關閉，後面每次請求須要從新進行鏈接

如：Connection: keep-alive,Connection:close

HOST

請求字段，且一個請求報文中頭部必須擁有此字段，不然就是一個錯誤的報文。它的做用是指定服務器處理這次請求的主機及其端口號

Referer

請求字段，它的做用是告訴服務器這次請求是從哪一個頁面連接過來的

如從百度頁面搜索某一個東東，從這個字段能夠看出發出請求的那個頁面地址。即https://www.baidu.com/

Accept

請求字段，它的做用是描述了瀏覽器端能夠接受的媒體類型。如 Accept: text/plain

Accept-Charse

請求字段，描述了瀏覽器端所能接受的字符集。如Accept-Charset: utf-8

Accept-Encodong

請求字段，描述了瀏覽器端所能接受的編碼方式，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法。如Accept-Encoding: gzip, deflate

Accept-Language

請求字段，描述了瀏覽端可以接受的語言。如Accept-Language: en-US

User-Agent

請求字段，這次字段描述了客戶端的一些信息，如：客戶端使用的操做系統、瀏覽器的名稱版本等

Access-Control-Allow-Origin

響應字段，指定哪些網站能夠資源共享。這個字段是咱們很常見的，通常咱們會用它處理跨域

Server

響應字段，服務器的名字。如

Content-Type

實體字段，描述了報文體內對象的媒體類型。如表單的Content-Type: application/x-www-form-urlencoded或者html的Content-Type: text/html

Content-Length

實體字段，指定請求體的長度

👉詳細參見此博客

2.3 HTTP中的請求方法

GET

獲取資源，能夠理解爲讀取或者下載數據。同時get方法也能夠用來提交數據

POST

和get方法相似，通常用來傳輸實體主體。get的主要目的是獲取，而post顯然不是

PUT

用來傳輸文件，要求在請求報文的主體中包含文件的內容，而後保存到URI指定的位置。即此方法可直接將報文主體的數據替換到服務器的資源

值得注意的是在HTTP1.1中put方法不存在驗證機制，故任何人都可以上傳文件安全問題得不到保證

它和post方法相似，可是post方法是冪等的，而put不是

小知識 冪等於非冪等

HTTP的冪等性指的是這個HTTP方法無論你調用多少次，其結果都是相同的

如一個get請求的接口，不管你調用多少次它的返回結果都是相同的。（服務器資源不能手動改變）

而一個post的請求，咱們經常使用它作的事情就是數據的增添操做。即這個請求接口的每次調用服務器都會有新的資源產生，而且返回不一樣的結果

再來講這裏的put請求，仍是對接咱們的實際操做。它通常用於更新操做。即調用這個接口一次和屢次，其實際效果均和第一次同樣

HEAD

同get方法相似，只不過其響應報文中沒有主體部分。用於獲取報文首部

DELETE

與put方法相返，put是將URI指定的資源替換掉，而delete則是將它刪除

OPTIONS

用來查詢URI指定的這塊資源支持什麼方法。如支持get咱們能夠用get請求支持post就能夠用post

TRACE

用於追蹤路徑。可能會引起XST攻擊不多用

CONNECT

此方法可在客戶端與一個代理服務器通訊時創建隧道，實現隧道協議進行TCP通訊

2.4 HTTP中的狀態碼

客戶端來信兒了，咱服務器端答不答應它的請求也得表個態吧

大致分類

• 1xx：表示接收的請求正在處理，只是一個臨時的響應
• 2xx：表示成功，這一類的狀態碼錶示請求請求報文已經收到並被正確處理
• 3xx：重定向，表示資源位置發生了變更，須要客戶端從新發送請求
• 4xx：表示客戶端錯誤，即請求報文有錯服務器沒法理解或處理
• 5xx：表示服務器錯誤，即服務器在處理請求時其內部發生了錯誤

比較常見的一些狀態碼

2xx

• 200：服務器已經成功的處理了請求
• 202：服務器接受了請求，但還沒有處理
• 206：服務器成功處理了部分get請求

3xx

• 301：永久移動，表示請求的資源文件已經被永久的移動到一個新的位置，會同時返回一個新的URL，從此的請求就得使用這個新的了
• 302：臨時移動，與301相似，但資源只是被臨時移動之後仍是用老的URL

4xx

• 400：客戶端請求發生語法錯誤，服務器不能理解
• 401：要求用戶進行認證
• 403：服務器能理解客戶端的請求，可是拒絕了它的這次請求
• 404：咱們最熟悉的了，沒有找到資源

5xx

• 500：服務器內部發送錯誤，沒法完成這次請求處理
• 502：充當網關或者代理的服務器時，從遠端服務器接收到了一個無效的請求

2.5 Cookie&Session再加上如今的token

因爲HTTP的無狀態所衍生出來的產物們 Cookie和Seesion估計是每個搞web的人都去了解過的東西，就再簡單複習一下咯

• Cookie：就是一段文本信息，在瀏覽器訪問服務器時由服務器頒給瀏覽器。瀏覽器保存等到下次再訪問此服務器時就會帶着這個Cookie一同訪問，服務器經過cookie中的信息辨認用戶
• Session：cookie是保存在瀏覽器中的不太安全，因而session來了。session也是記錄用戶的一種機制，與cookie不一樣的是session是保存在服務器中的，即瀏覽器訪問服務器若是是第一次訪問，服務器就把這個瀏覽器的一些信息記錄下來。等到它下次訪問時直接去session裏和核對便可

總結：cookie類似於通訊證，session類似於一張本身用戶的明細表

使用session也有很大的肯定，服務器要保存全部人的session Id。像某寶某東這個用戶量上億用戶的網站維持這些信息得是多麼大的開銷

token來了 token：它也是由服務生成的一串字符串，用於當作客戶端瀏覽器的一個令牌。客戶端表單驗證經過第一次訪問時，服務器生成token交予此客戶端。後面它再來訪問的時候拿着token便可

是否是看起來token和cookie蠻像的，東西都是由服務器授予的且再次訪問的時候須要帶着。它們的區別是什麼呢？

token只是一個有服務器通過一些算法以及加密生成的一個字符串，而cookie倒是保存了許多數據。服務器端進行驗證的時候對於token來講僅是至關於一個「對暗號」，對於cookie卻要仔細查看裏面的內容。同時開發時我想碼友有了解了像如今先後端分離，確定存在的就是跨域的問題。還使用cookie是難以處理的，使用token仍然很方便

固然這僅是我理解的一點不一樣，筆記之後進行整理。感受跑題了，這裏不是HTTP專場嗎？

三： http深刻篇

3.1 身份認證

怎麼證實是「你」在訪問服務器呢？

HTTP/1/1中使用的認證方式

• BASIC認證（基本認證）
• DIGEST認證（摘要認證）
• SSL客戶端認證
• FormBase認證（基於表單認證）

BASIC認證

它是從HTTP/1.0就定義的認證方式，是客戶端與服務器之間進行的認證方式

BASIC認證基本流程

如圖所示：要請求的資源須要BASIC認證，服務器響應字段返回狀態碼40一、緣由 Authorization Required ，跟隨返回的還有一個WWW-Authenticate的首部。這個字段包含要認證的方式和 Request-URI 安全域字符串

客戶端接收以後，發現須要進行BASIC認。會將用戶的ID和密碼通過Base64編碼以後放進 Authorization字段中發送至服務器

服務器再對傳過來的認證信息進行驗證，如正確返回一條包含 Request-URI 資源的響應

**值得注意的是：**雖然用戶ID和密碼使用了base64進行了編碼可是可沒有進行加密處理，這串信息使用base64解碼還是原信息。故BASIC認證是一種不安全的認證方式且想要再進行一次BASIC認證，通常的瀏覽器也沒法實現認證註銷。因此BASIC認證不經常使用

DIGEST認證

由於BASIC認證中的信息傳輸是以明文的方式，故在HTTP/1.1中便有了DIGEST認證

DIGEST認證使用質詢/響應的方式。質詢/響應是指：開始一方會先發送認證要求給另外一方，接着使用從另外一方那接收到的質詢碼計算生成響應碼。最後將響應碼返回給對方進行認證的方式

DIGEST認證基本流程

SSL客戶端認證

爲了解決用人獲取了用戶的用戶ID和密碼就能隨意冒充的問題 SSL 客戶端認證是藉由 HTTPS（下面有HTTP與SSL的總結若是不清楚可先跳過） 的客戶端證書完成認證的方式。憑 借客戶端證書認證，服務器可確認訪問是否 來自已登陸的客戶端

基本步驟：

• 接收到須要認證資源的請求，服務器會發送 Certificate Request 報文，要求客戶端提供客戶端證書。
• 客戶端會把客戶端證書信息以 Client Certificate 報文方式發送給服務器
• 服務器進行驗證，驗證經過後方可獲取客戶端的公鑰，而後開始 HTTPS 加密通訊。

FormBase認證

表單認證我想不用再碩了吧。

3.2 長鏈接&短鏈接

HTTP協議是基於請求/響應模式的，故只要服務器端給了響應那麼本次HTTP請求就結束了

值得注意的是：HTTP的長鏈接和短鏈接本質上是指的TCP的長鏈接和短鏈接

爲何要長鏈接：

如今一個頁面會向服務器發出炒雞多的HTTP請求，每個HTTP請求的建立都會經歷一次TCP的三次握手和四次揮手這是十分浪費性能的。故咱們但願經過一個HTTP建立的數據傳輸通道不要在進行了一次數據傳輸以後就關閉，但願它能夠一直開啓以便於咱們後面的數據傳輸

3.3 中介

3.3.1 代理

即如圖所示，代理服務器就是如同中間件同樣被放到客戶端與服務端之間。本來是客戶端直接與服務端進行通訊，因爲代理的存在客戶端的請求會被代理接收，而後再由代理將請求發至源服務器。響應同理

回想node中的中間件或者axios的攔截器，這種"第三人"的出現確定是爲了作某些事情，它能作什麼呢？

• 過濾器，過濾掉某些IP地址的訪問
• 文檔訪問器，對一些文檔資源作限制
• 安全防火牆
• web緩存
• 反向代理
• 負載均衡
• ...

代理最主要的特色是它的「欺上瞞下」，即客戶端覺得它是服務器、服務器覺得它是客戶端。故

3.3.2 網關

網關一樣是一種特殊的服務器，一樣是做爲中間件使用。

網關與代理的工做機制十分相似，可是網關又被稱爲協議轉換器。像上面的代理服務器它兩邊的協議還是HTTP，網關可不是這樣。網關要求其兩邊使用不一樣的協議，如左邊使用HTTP右邊使用FTP。

小黑：那有什麼常見的網關類型不？

答：

• HTTP/*：服務器端Web網關
• HTTP/HTTPS：服務器端安全網關
• HTTPS/HTTP:客戶端安全加速器網關

小黑：什麼玩意客戶端服務器端網關？你在說錘子呢？

答：嗯...，由於web網關兩端所使用的協議不一樣，故通常以這<客戶端協議>/<服務器端協議>這形式表示。像HTTP/這種網關使用HTTP協議與客戶端通訊使用其餘協議和服務器端通訊被稱爲服務器端網關；像/HTTP這種經過其餘協議與客戶端通訊，使用HTTP協議與服務器端通訊的被稱爲客戶端網關

3.4 緩存

主要來看一下客戶端緩存

先來看一下擁有緩存的請求流程

1. 瀏覽器請求一個資源，先去查看緩存裏面看有沒有，沒有則向服務器請求資源
2. 服務器響應，返回資源同時也標記了這個資源的有效期。（即緩存裏的資源是有它的存在時間的）
3. 瀏覽器將資源緩存起來以備下次使用

再來看一下報文中有關緩存的字段

通用字段 Cache-Control

它有如下經常使用值：

• no_store:全部內容均不緩存
• no_cache: 緩存，但瀏覽器每次使用緩存資源前，都會去服務器判斷這個資源是否是最新的
• max-age=x：請求緩存後x秒再也不發起請求(注意：生存時間的計算起點是從響應報文的建立時刻，即包含了在鏈路中傳輸所須要的時間)
• s-maxage=x：代理服務器請求源站緩存後x秒後再也不發起請求，只對CDN緩存有效
• public：資源在客戶端與代理服務器（CDN）均可緩存
• private：只有客戶端才能夠緩存

瞅一眼掘金中的資源吧

值得注意

雖然Cache-Control是一個通用字段，客戶端也可使用。可是瀏覽器使用Cache-Control只能是數據刷新，如頁面中咱們強制刷新時實際是在請求頭裏加上Cache-Control:no-cache即便是普通刷新也會在請求頭裏加上Cache-Control: maxage=0。即它們均表示請求最新的資源

那麼它是怎麼實現使用緩存裏面的數據呢？

HTTP協議中定義了一系列if打頭的字段，專門用來驗證資源是否過時。其中最經常使用的兩個請求字段就是if-Modified-Since和if-None-Match。它們分別於下面的響應字段是一對

從響應字段 Expires提及

表示資源的過時時間，是HTTP1.0的屬性，在與max-age共存的時候優先級要低於它。

即客戶端向服務器請求資源時，服務器給與響應資源時還會帶上一個Expires字段。即和客戶端約定了一個文件資源的過時時間，表示在此時間內你去你緩存裏找不要再來向我要了

可是這樣有一個缺點：即過了這個約定時間其實服務器中的資源仍然沒有變更仍是客戶端瀏覽器緩存裏的那個數據。這樣該怎麼辦呢？

下面的兩對字段就派上了用場

響應字段 Last-Modified與請求字段if-Modified-Since

在文件資源約定過時時間的基礎上，加上了一個資源最新修改時間的對比

即客戶端向服務器請求資源時服務器這時返回的是資源+約定時間+資源最新修改時間（放到Last-Modified字段）

那麼後面就存在了多種狀況

• 約定時間沒有到期直接使用緩存
• 約定時間到期了，客戶端發送請求帶上if-Modified-Since字段（裏面存的是開始服務器響應給的資源最新修改時間）。用if-Modified-Since字段中的數據與此時服務器中的資源最新修改時間作對比，判斷資源文件是否發生了變更。無變更仍然使用緩存，變更了則拿最新資源

小黑：看你下面還有一對字段，這裏是否是也向上面同樣存在不足？

我：你還真聰明嘞，沒錯Last-Modified只能精確到秒。極可能出現這種狀況，開始客戶端請求數據時，服務器返回了資源+約定時間+資源最新修改時間，可是服務器中就在這個響應報文剛發出去，其資源又發生了變更（1s內發生的），那麼就會致使本次修改後的資源客戶端是永遠拿不到的

響應字段 ETag與請求字段if-None-Match

爲了改進上面那對字段的缺點，增長了一個文件標識ETag

ETag：資源的惟一標識，主要用於解決根據修改時間沒法區分文件是否變化的問題。也即資源一發生變更，這個標識符就會跟着變更

這時的客戶端向服務器發起請求，服務器響應回：資源+約定時間（max-age=x或Expires）+最新修改時間+資源標識符

後面仍是存在多種狀況

• 約定時間沒有到，客戶端繼續使用緩存
• 約定時間到了，客戶端發起請求，帶上if-None-Match（放的是開始響應回的ETag）和if-Modified-Since（開始響應回的最新修改時間）。這時服務會先行比較if-None-Match中的標識符與此時服務器裏的資源標識符是否一致（標識符判斷的優先級要高於資源最新修改時間的判斷，其實這裏的if-Modified-Since沒什麼卵用）。一致服務器返302即客戶端繼續使用緩存，不一致服務器返回最新的資源再帶上新的標識符等字段

可是此時還存在一個問題，即在約定時間內資源發生了改變咱們怎麼去獲取呢？

再來了解一下服務器端緩存

服務器端的緩存功能主要是由代理服務器來實現的，其實也是十分相似於客戶端的緩存。代理服務器處於中間層即它可即充當客戶端也可充當服務器端，在它充當客戶端向源服務器請求數據時，請求回來的數據除了轉發給它的下游客戶端也可本身緩存一份。

故這時客戶端再去請求數據，即可直接獲取代理中緩存的了

3.5 內容協商機制

內容協商機制指的是客戶端和服務器端就響應的資源內容進行交涉，而後服務器端響應給客戶端最爲合適的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的基準

說白了就是某一資源，在服務器上有多個版本。而後由客戶端根據本身的喜愛選擇一個最爲合適的

內容協商技術的三種實現方案

• 客戶端驅動：客戶端發起請求，服務器給與一個可選列表，客戶端作出選擇後發送第二次請求
• 服務器驅動：服務器檢查請求報文的首部以判斷髮送哪一個版本的資源
• 透明協商：某個中間設備（一般是緩存代理也即具備緩存功能的代理服務器）表明客戶端進行協商

主要來看一下服務器驅動中的請求報文吧

其實上面也已經總結過了

如 ：

• Accept：告知服務器發送哪一種媒體類型
• Accept-Language：告知服務器發送哪一種語言
• Accept-Charset：告知服務器發送何種字符集
• Accept-Encoding：告知服務器採用哪一種編碼
• ...

再來了解一下q值的使用

q值其實就是一種優先級的表示，它的取值爲[0.0，1.0]，其中1.0表示優先級最高

看這個栗子

Accept-Language: en;q=1.0, fr;q=0.0, nl;q=0.8, tr;q=0.0
複製代碼

表示客戶端接受的語言最好是en，沒有en的話nl也能夠。不接受fr和tr

3.6 斷點續傳與多線程下載

斷點續傳：當咱們下載某一個比較大的資源時由於網絡緣由下載中斷，當網絡從新鏈接時咱們一般可不是將這個資源從頭再次下載一遍，而是從上次中斷的節點繼續下載。那這是怎麼實現的呢？

這裏則是主要關注兩個字段，請求頭裏的Range響應頭裏的Content-Range

• Range:這個請求字段表示我客戶端要某一資源的哪個範圍區間。它的格式是這樣的 Range:(從哪開始，從哪結束]。栗子Range:bytes=0-199 表示我要這個資源從0字節開始到199字節內的這一段資源。其範圍還有如下表示形式如bytes=-1023 表示要最後1k的數據；bytes=500-`表示要的是從500到最後的資源片斷
• Content—Range：在接收到請求以後服務器除了返回其所要片斷的資源，還會在 Content-Range中寫上相應的數據。如客戶端要的是0-199範圍內的資源片斷，則響應報文中 Content-Range會寫上這次響應回的資源片斷範圍也便是0-199，同時還會寫入這個資源的總大小

一個完整的斷點續傳過程

1. 客戶端下載一個1k大小的資源，已經下載了512k了，發生了網絡中斷
2. 網絡從新鏈接，發送續傳請求。其中請求頭中帶上 Range:bytes=512000-
3. 服務器處理請求，從資源的512k處響應資源。並在響應頭中添上 Content-Pange:bytes 512000-/1024000

值得注意由斷點續傳返回的狀態碼不是200而是206

四： HTTPS瞭解篇

4.1 先來看HTTP中存在的不足

• 通訊使用明文，內容存在竊聽風險
• 沒法證實報文的完整性，即報文可能在中途就已經被修改
• 不驗證通訊方身份，所以有可能遭遇假裝

4.2 HTTPS核心內容

HTTPS的出現也就是爲了彌補上面所總結的不足

那麼HTTPS=HTTP+加密+認證+完整性保護=HTTP+TLS

TLS：一種安全通訊協議。注意TLS原來叫作SSL，故可不要把它兩當成兩種協議。

TLS處於應用層的下層，數據傳輸層的上層。

也即HTTP不會再直接與數據傳輸層的TCP進行通訊，而是先與TLS。

HTTP中存在的那些不足就交給TLS來作了

4.2.1 TLS中的對稱加密與非對稱加密

對稱加密

所謂對稱加密就是加密解密都共用一個祕鑰，也即通訊雙方在進行數據交流時由於此時數據已經加密爲使對方能理解本身發出的數據（保證對方能對數據進行解密）還要把這個祕鑰一塊兒發送過去

那麼這裏就有一個很大的漏洞，即只要有人在中間將通訊雙方的傳輸數據竊取下來。由於數據中包含祕鑰，那麼這些信息和明文也沒有多大的區別吧

非對稱加密

爲了解決上面對稱加密存在的問題，非對稱加密使用了兩種祕鑰。一個爲私有祕鑰（只能放在本地計算機中），一個爲公開祕鑰（可隨意給出）

它的工做方式是：發送祕文的一方使用對方傳過來的公開祕鑰進行加密處理，對方收到以後再用本身的私有祕鑰進行解密。也即加密和解密使用兩種不相同的祕鑰，故中間的數據及時被竊取因爲攻擊者沒有私有祕鑰仍然看不懂數據中寫的是啥玩意

混合加密

任何東西都不是完美的，非對稱加密這麼優秀是否在HTTPS中的加密方式就是一直使用的它嗎

要想知道是否是，首先咱們先的瞭解一下對稱與非對稱加密算法

• 對稱加密算法目前經常使用的爲 AES、 ChaCha20
• 非對稱加密算法中最著名的一個爲 RSA,還有後面的 ECC

咱們要知道大部分的密碼學的東西都是使用的一些很複雜的數學計算，那麼在這裏HTTPS傳輸報文時總要通過加密解密這對CPU的計算是有必定的負擔的，計算也要付出時間的成本，在web中時間可就是一切

可是爲了保證報文不在網絡裏進行裸奔，咱們就有必要好好的比較一下這兩種加密了

首先非對稱祕鑰的算法均是基於複雜的數學難題，其運算及其消耗時間，即便ECC也要比AES差上不止一個等級。若是報文傳輸時所有使用非對稱加密，那麼咱們打開一個頁面的時候就先跟屏幕眼瞪眼一會吧

再回想一下對稱加密，對稱加密的缺點在於它的祕鑰不可以保證安全的傳輸個對方。

那麼解決方案不是就來了嗎，咱們可使用非對稱加密的方式將對稱加密中的祕鑰傳過去，後面不就能夠放心的使用對稱加密了嗎

4.2.2 摘要算法

4.2.1中的加密操做僅是保證了報文不是在網絡中裸奔，可是尚未保證數據的完整性。這時攻擊者竊取了數據，雖然它看不懂可是它能夠對其進行修改啊，雖然能夠它也不知道這個玩意最後被解密出來個啥玩意，可是這已經破壞了這次的通訊，咱們也不清楚對方會響應回來個什麼玩意

實現完整性的手段即是摘要算法（散列函數、哈希表）。使用它能夠把數據壓縮成一個固定長度且獨一無二的字符串，也能夠理解爲這段數據的一個指紋或者說這個字符串就是這段數據的惟一標識。（固然會存在像哈希函數那樣通過兩個不一樣的字符串通過轉換獲得的是同一個東西不過這不是咱們如今須要考慮的玩意）

有個這個數據的「指紋」，那麼咱們就能夠在傳輸數據的時候帶上它的數據指紋。由接收方去驗證，若是數據被篡改了，那麼就和它的指紋沒法匹配。由此就保證了數據的完整性

固然這裏的全部數據確定也得是基於祕文傳輸之上的，不然攻擊者在修改了數據以後連指紋也給你從新搞了一個怎麼辦。。。

4.2.3 數字簽名與證書

前兩個問題已經基本解決了，下面開始看第三點了。即你怎麼證實你訪問的是一個正規的站點，可能你本打算訪問某寶了中間被誘導進了一個和某寶長的一毛同樣的站點，這時你在這個站點輸入的全部我的信息可都白瞎了啊。

開始證實數據是目標服務器端發回來的。

映射到現實世界，一個文章證實是你的只須要你在末尾籤一下名或者蓋一下章便可。這裏也是同樣

這時候仍是用到了非對稱中的公鑰和私鑰，值得注意的是私鑰但是本身私有的，故可以使用它來進行「簽名」。而後再由其相對應的公鑰進行「驗籤」

這時解決了驗證的問題了嗎？

小黑：你這麼問確定沒有，快點往下說嘮叨什麼

我：...,嗯此時仍然是沒有解決不了問題。公鑰是能夠隨意轉發的，可是你這個公鑰必需要指明的的來源身份啊。好比我接收方收到了你這個公鑰我就能夠準確的知道你就是某寶

這時就要引入第三方來幫忙咯，CA（證書認證機構）：相似於網絡中的公安局、公正中心具備很高的可信度

這時的流程就變成了這樣:

• 服務器運營人員向數字證書認證結構提出公開祕鑰的申請，數字證書認證機構判明身份以後，對這個已申請的公開祕鑰作數字簽名（至關於蓋上認證結構的章）
• 分配這個已簽名的公開祕鑰
• 服務器就把傳統的公鑰替換爲這個公鑰證書了
• 客戶端驗證真實性

注意客戶端之因此可以對這個認證機構作的公鑰簽名進行驗籤是由於客戶端的操做系統和瀏覽器都事先內置了各大CA的根證書

這時已經基本的實現了認證機制，可是萬事就沒有完美的。所謂道高一尺，魔高一丈

若是CA由於事務或者被欺騙再或者CA和黑客攻陷怎麼辦？

故又出現了下面的補救措施

• CRL 證書吊銷列表
• OCSP：在線證書狀態協議，以便及時廢止有問題的證書

4.2.3 HTTPS/TLS握手

請注意這裏纔是HTTPS的核心

下面來比較詳細的走一下TLS握手的步驟，注意它是發生在TCP鏈接的後面，也就先進行的是TCP的三次握手。在TCP創建了鏈接以後便開始TLS的握手流程了。

仍是看圖解HTTP中的這個圖吧

1. 首先瀏覽器發送一個"ClientHello"的消息。這段消息裏面同時含有客戶端的版本號、支持的密碼套件和一個隨機數random1（用於後面生成對稱加密的祕鑰）
2. 服務端向客戶發送"sever Hello"，同時這段消息也包含了一些信息。好比從客戶端傳遞的密碼套件選擇一份（即決定了後面加密和生成摘要時使用哪一種算法），還有一個隨機數random2（也是用於後面生成對稱加密的祕鑰）
3. 服務端向客戶端發送"Certificate"，這一步是服務端將本身的證書發給客戶端，以便客戶端驗證本身身份。同時咱們前面知道了服務器的公鑰也是存在於證書裏面，故瀏覽器此時也拿到了服務器的公鑰
4. 服務器端發送"Server Hello Done",這一步是通知瀏覽器Server Hello 過程結束
5. 瀏覽器端發送"ClientKeyExchange",這一步客戶端又生成了一個隨機數random3，而後根據服務器傳過來的公鑰生成 PreMaster key而後將它再傳給服務器。服務器拿本身的私鑰解密獲得瀏覽器端的random3 。這個時候不管是瀏覽器端仍是服務器端都有了三個隨機數： random1+random2+random3.而後兩邊就但是使用相同的算法生成對稱加密的密鑰
6. 瀏覽器端發送"changeCipherSpec"，這是一條事件消息，這一步瀏覽器端通知服務器端後面發送的消息就要是以前生成的那個對稱加密密鑰進行加密了
7. 服務器本次工做完成，至關於試探性驗證消息。 客戶端將前面的握手消息生成摘要再用協商好的祕鑰加密，這是客戶端發出的第一條加密消息。服務端接收後會用祕鑰解密，能解出來講明前面協商出來的祕鑰是一致的
8. 服務器一樣發送"changeCipherSpec",一樣是一條事件消息，表示告知瀏覽器後面再發送消息就要加密了
9. 服務器本次工做完成， 至關於試探性驗證消息。服務端也會將握手過程的消息生成摘要再用祕鑰加密，這是服務端發出的第一條加密消息。客戶端接收後會用祕鑰解密，能解出來講明協商的祕鑰是一致的。
10. 均正常，開始正常通訊了

4.3 HTTPS的使用成本

HTTPS這麼優秀爲啥到如今還不是全部的站點都遷移到HTTPS上呢。

主要有如下緣由

• （之前）證書的申請和維護成本過高，小型網站難以承擔。
• 速度問題，不管是多出來的TLS握手仍是後面的不斷加密解密以及包含一些證書的驗證等操做使它要更加的消耗cpu，增長了時延。(如今計算機的性能愈來愈高，再加上有許多對它的優化方案故此時這裏也不是問題了)
• HTTPS涉及的知識點多而雜，有比較高的技術門檻不便於很快的上手

故如今的主要問題就是步驟3，關於HTTPS的技術方面的問題了。

下面的東西就不是咱們如今要了解的了，畢竟咱只是一個弱小而無助的小前端。不能如今就搶了運營大大的活你說是不。。。

五 ： http 2.0、http3.0 展望篇

5.1 先來了解一下webSocket吧

在來看一下HTTP中的不足，HTTP的通訊是基於請求/響應。即你客戶端不請求我服務器端永遠不會將最新的數據給你

可是咱們有許多業務功能就是但願服務器可以將它此時最新的資源數據自動推送給客戶端

基於這種狀況，出現一種解決方案：

輪詢

輪詢又包含兩種

• AJAX輪詢：即沒隔一段時間客戶端向服務器端發送一個請求，看看有無最新資源
• Long Poll：即每次客戶端發起資源的請求，服務器端會先判斷你此次請求的資源和我上次返回的是否是同一個（也即判斷資源是否是最新的）。是同一個即表示此時資源和你上次請求的是同樣的那麼就進行等待，先不進行響應等到資源變更了再將這個最新的資源發送過去。若是一開始判斷就能肯定此時的資源是最新的就直接發給客戶端

Long Poll的缺陷比較顯而易見，即若資源沒有更新那麼此次HTTP請求就不會中斷。要是客戶端請求多個資源呢？這些個資源都沒有更新就存在這麼多的HTTP請求在等待服務端的響應，這消耗服務器端性能不說，對於一些限制HTTP請求條數的服務器來講至關於就被阻塞了，此時任何別的請求服務器均不在受理那該怎麼辦？

小黑：快點介紹WebSocket就你墨跡

我：

好吧下面來看WebSocket

來看一下來自菜鳥教程的介紹筆者感受描述的很nice

WebSocket 是 HTML5 開始提供的一種在單個 TCP 鏈接上進行全雙工通信的協議。

WebSocket 使得客戶端和服務器之間的數據交換變得更加簡單，容許服務端主動向客戶端推送數據。在 WebSocket API 中，瀏覽器和服務器只須要完成一次握手，二者之間就直接能夠建立持久性的鏈接，並進行雙向數據傳輸。

在 WebSocket API 中，瀏覽器和服務器只須要作一個握手的動做，而後，瀏覽器和服務器之間就造成了一條快速通道。二者之間就直接能夠數據互相傳送。

即因爲它是創建在HTTP基礎之上的協議，故發起鏈接的還是客戶端，可是一旦確立了WebSocket通訊鏈接，之後不管是客戶端仍是服務器端均可以主動的發送信息

接下來看一下webSocket中的握手

• 要進行WebSocket通訊，首先客戶端發送請求的報文中頭部須要加上 Upgrade字段。告知服務器通訊協議發生了變化，同時此報文首部還須要加上幾個有關字段： Sec-WebSocket-Key一個一base64編碼的16字節隨機數，用來做爲一個簡單的認證密鑰； Sec-WebSocket-Protocol記錄着使用的一些子協議； Sec-WebSocket-Version版本號
• 服務器響應，狀態碼101 。一樣還有幾個字段。 Sec-WebSocket-Accept，裏面的值由請求中 Sec-WebSocket-Key內的值生成的；一樣含有 Sec-WebSocket-Protocol記錄着使用的一些子協議
• 成功握手後，通訊便使用WebSocket獨立的數據幀

js中有關WebSocket的API

構造函數 WebSocket(url[,protocols])，一參爲地址url，二參可選，指定可接受的子協議

栗子：

const socket=new WebSocket('ws://localhost:8080')
socket.onopen=function(){  socket.send('Hello Server!'); } socket.onmessage=function(e){  console.log('this is from serve',e.data) }  複製代碼

詳細見：

👉MDN WebSocket

5.2 開整 HTTP 2.0

HTTPS解決了HTTP安全方面的問題，但其性能倒是個很大的問題，且其優化方案也只是優化了握手與加密的過程

故在HTTPS逐漸成熟以後就得向着解決它性能問題的方向跨步了

再來看一下此時HTTP存在的缺陷

• 頭部冗餘
• 單路鏈接、請求低效
• 只容許客戶端主動發起請求

此時來看一下HTTP 1.x 、HTTPS、 HTTP 2.0的協議棧，能夠發現HTTP 2.0 也是創建在TLS協議之上的，且對其TLS版本就明確要求。TLS咱們已經知道不了它是爲了保證安全的，那麼TLS與HTTP中新添加的HPack、Stream又是啥玩意呢？（簡單解釋->Hpack用於壓縮首部，同時HTTP2.0使用虛擬的流傳輸消息用於解決隊頭阻塞和實現多路複用，詳細見下）

先來看HTTP 2.0進行的改進

• 頭部壓縮

• 二進制分幀

• 多路複用

頭部壓縮

在HTTP 1.x 版本中雖然報文主體能夠通過gzip壓縮，可是首部倒是沒進行處理。首部所佔的流量也是不容忽視呢，故HTTP 2.0 的改進性能之一就是拿首部問題開刀

首先爲了保證向下兼容，HTTP 2.0 與HTTP 1.x的語義是沒有變化的，故其報文的結構仍是「Header+Body」。可是在請求發送的時候Header必需要用HPACK來壓縮一下

在介紹HPACK的壓縮流程以前，我想有必要了解的東西

HTTP 2.0 爲了方便對首部的管理和壓縮，廢棄了起始行。把它們也放到了首部字段的統籌中，同時爲了與真正的首部字段作區分又給它們起了一個新的名字「僞首部字段」

同時在寫法上爲了區分僞首部字段，與真首部字段，僞首部字段的key值前會加上:",如:method

到如今整個報文的首部就都是key-value的形式了，既然都是key-value的形式那字典這種數據結構顯然就派上了用場

在Hpack中有兩個表用於充當字典的角色，這個字典通訊雙方均擁有

• 靜態表，靜態表比較簡單它記錄了一些已知首部字段，可是其內部又能夠被劃分爲兩種

  • key和value均是肯定的，如 :method:get。這種狀況只需查表看其對應的值便可，即 :method:get之後僅需用一個2表示
  • value 不能肯定，好比 cookie。這種狀況就要用到動態表了
  • 靜態表截圖

• 動態表，它會被添加在靜態表的後面，與靜態表結構相同，且在編碼解碼時會隨時更新。目的仍是讓之後某一個字段能夠僅用一個數字進行表示

接下來Hpack算法的流程就簡單的多了

• 首先通訊雙方共同維護了一個靜態表和一個動態表， 支持基於靜態哈夫曼碼錶的哈夫曼編碼 （用來減少體積）
• 假設此時客戶端剛有cookie，那麼它請求服務器時首先用2/3表示本身的請求方法（其餘省略...）再告知服務器，將 cookie:xxx添加到動態表中，那麼cookie之後也能夠只用一個字符來表示的，相似的服務器也能夠更新對方客戶端的動態表

你可能注意過，使用了頭部壓縮以後首次請求其首部大小可能會減小爲原來的通常，下一次請求可能其首部大小又減小爲剛纔的一半。爲啥兩次壓縮的大小量還不相同呢？

仍是靜態表與動態表的問，靜態表首次就能夠進行使用。像上面的cookie栗子，第一次請求確定須要把這個字段完整的傳到服務器，可是當動態表更新以後下次再來這個cookie字段無論它上次佔了屢次字節我一個字符就搞定，一個字節有8位，即一個字節表示的範圍就是1-2滴8次方（符號沒打出來不打了），徹底夠用

👉想深刻了解，可參考

二進制分幀

HTTP 2.0 把TCP協議的部分特性搞到了應用層，把原來的Header+Body的消息大散爲數個小片的二進制幀，使用HEADERS幀存放首部數據、DATA幀存放實體數據

也可這樣理解：HTTP 2.0 中數據通訊的最小單位再也不是之前的那種報文，而是換成了幀。一個消息由一個或多個幀組成

多路複用

先來了解流是什麼？

流是存在於鏈接中的一個虛擬通道。它能夠承載雙向消息且每個流都有一個惟一的整數ID

它有如下特色

• 可併發，一個HTTP 2.0 的鏈接能夠同時發出多個流傳輸數據即一次鏈接建立可整多個這個虛擬通道。一個HTTP 2.0 中的流對應HTTP 1.x的一次請求-響應，也即一個鏈接併發多條請求（多路複用）
• 流是雙向的，即一個幀能夠由客戶端發送可由服務器端發送
• 不一樣流之間彼此獨立，但一個流內的幀的傳輸順序有着嚴格順序
• 不止客戶端，服務器也可建立流。
• 流可設置優先級，讓服務器優先處理，如先傳輸HTML數據後傳輸圖片
• 0號流特殊，不可關閉不能發送數據幀，只可發送控制幀用於流量控制

那麼到這多路複用咱們就明白了吧

所謂多路複用指的是：全部的請求均是經過一個TCP鏈接併發完成

怎麼解決的隊頭阻塞

經過上面對流的瞭解，咱們知道一次鏈接能夠有多個流，且一個流裏面的數據幀是有着嚴格順序的。注意這是咱們站在流的角度去思考的，此時的數據傳輸像這樣

可是咱們要知道，這些個東西自己可就是在一個鏈接上的。站在鏈接的角度它們就沒有這裏井井有理了，或者說看起來亂七八糟

可是就由於此時多個請求-響應之間沒有了順序關係，故不須要排隊等待，也即不會出現隊頭阻塞的問題

值得注意這裏解決的只用應用層面的隊頭阻塞問題，數據傳輸層仍然存在

HTTP 2.0 的特性還有不少不少，這裏僅是總結了一下最多見的。

詳細見👉透視HTTP協議

5.3 瞭解WebDAV

這玩意是什麼？

先看一下百度百科的解釋：

WebDAV （Web-based Distributed Authoring and Versioning） 一種基於 👉HTTP 1.1協議的通訊協議。它擴展了HTTP 1.1，在👉GET、👉POST、👉HEAD等幾個HTTP標準方法之外添加了一些新的方法，使應用程序可對Web Server直接讀寫，並支持寫文件鎖定(Locking)及解鎖(Unlock)，還能夠支持文件的👉版本控制

拿個比較像的應用來舉栗子：像百度網盤那種，咱們能夠直接對服務器的東西進行增刪改查

WebDAV在這裏我沒有把它當作一個重點知識，故接下來藉助圖解對它的講解簡單進行一下掃盲吧

額發現也沒有什麼可掃的，那就不總結它了吧

好吧。。。

WebDAV除了增刪改的基本功能，還具備文件建立者管理、文件編輯過程當中加鎖即避免多人同時編輯同一文件的問題

而後WebDAV又新增了一些概念，爲方便使用又在HTTP的基礎上新增了一些方法及其對應的狀態碼

5.4 展望QUIC&HTTP 3.0

HTTP 2.0 剛問世不就，HTTP 3.0就已經出來了。HTTP 2.0這麼優秀HTTP 3.0又能改進些什麼東西呢

首先上面說HTTP 2.0 解決隊頭阻塞問題時，我有說過HTTP 2.0僅是在應用層解決了這個問題。可是其在TCP鏈接時由於TCP的可靠鏈接特性在這裏仍是存在阻塞。

而且TCP自己就存在問題，就鏈接來講它由於要保證可靠的傳輸故其須要握手三次。即至少須要兩個RTT

同在數據傳輸層的UDP可沒有這麼麻煩，故HTTP 3.0將傳輸層的協議由TCP換成了UDP

而且由於UDP的不可靠傳輸使在數據傳輸層解決了隊頭阻塞問題，TCP在數據傳輸過程若是丟失了一個數據包那麼它的接收方就會一直等待發送方重傳。UDP就簡單的多了，有數據了直接扔過去，管你有沒有丟包呢

可是又由於UDP不能保證可靠的數據傳輸，則有必要加上一個東西幫它來作這件事情

此時的各協議棧對比

5.4.1 從瞭解QUIC開始

QUIC是基於UDP的傳輸層協議，它提供了像TCP同樣的可靠性。同時它實現了數據傳輸時延0 RTT

同時它還提供了數據傳輸的安全保障、以及像HTTP 2同樣的應用數據二進制分幀、流和多路複用

固然還有其餘重要特性：

• 前向糾錯：QUIC協議傳輸的每一個數據包中除了含有它自己的數據以外還會帶有其餘包的數據，便可實如今有少許丟包的狀況下，可使用其餘包的數據而不用重傳

• 快速重啓會話：普通基於tcp的鏈接，是基於兩端的ip和端口和協議來創建的。以下面場景手機用戶從使用4G切換到了使用wifi，會改變自己的ip，這就致使tcp鏈接必須從新建立。而QUIC協議使用特有的UUID來標記每一次鏈接，在網絡環境發生變化的時候，只要UUID不變，就能不須要握手，繼續傳輸數據。

注意看協議棧的圖：QUIC並非在創建在保障安全的協議TLS之上，能夠說是QUIC內部包含了TLS。且TLS1.3優化了TLS以前的握手

5.4.2 HTTP 3.0

HTTP 3.0 這時候再看就簡單多了。數據傳輸層的QUIC把活都乾的差很少了，應用層的僅需調用下層接口便可（專門的QUIC函數）

剩下的仍是和HTTP 2.0 同樣仍是使用流來發送請求響應，由於HTTP 3.0 流的管理是由QUIC來作個HTTP 3.0裏的幀結構比2.0更爲簡單

寫到最後：發表感言——無敵打工仔谷歌牛皮

參考致謝：

• 圖解HTTP（HTTP必看書籍）
• HTTP權威指南（HTTP字典用書）
• 👉SSL/TLS 握手過程詳解
• 👉風落幾番-大話HTTP協議（偏基礎）
• 👉透視HTTP協議（偏深刻）

本文使用 👉mdnice 排版