01_Http、Https、Http2.0 的基礎知識總結（持續更新篇）

weir發表於2018-05-05

更新時間	更新記錄
2018.05.01	更新Http的基礎知識部分
2018.05.03	更新Https的相關內容整理
2018.05.05	更新Http2.0的相關內容整理

前言

不得不說現在無論在前端和後端領域的技術迭代十分迅速，比如前段時間SpringBoot2.0的更新採用了Http2.0技術；這些基礎協議的更新往往帶來了實質的更新。一些名詞:"HTTP 管線化"、"會話跟蹤"、"跨站攻擊"等等，那些你耳熟能詳，但是無法細究的東西決定了這個總結誕生，或許文章會很長，但是也請靜下心來閱讀，而這個文章自己打算一段時間來持續更新。

基礎知識

HTTP介紹

基礎概念

HTTP協議（HyperText Transfer Protocol，超文字傳輸協議）是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳送協議。它的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。

版本

最常用的是HTTP1.0/1.1
最新版本是HTTP2.0，與1.0/1.1相比，有了更高的效能、安全性和靈活性以前的版本0.9等

HTTP協議

URL與資源

在TCP/IP模型中，所有的網路連線都要使用方案，方案定義使用什麼協議，比如http、ftp、telnet

一個標準的網路請求包括:

://:@:/;?#

但在實際使用過程中，對於不同協議可以缺少某些資訊，比如

ftp://192.168.169.121
http://www.baidu.com/index.html

URI、URL和URN

URI:統一資源識別符號，包括URL和URN
URL:統一資源識別符號，比如http://www.baidu.com/index.html就是一個URL
URN:統一資源名，它是無關物理位置的資源名定義，例子urn:ieft:rfc:2141

目前URN處於試驗階段，實際應用還很困難，在沒有特別說明時，一般我們說的URI就代表URL

媒體型別

在HTTP中，不管是word檔案、js檔案或者圖片都是資源，通可以通過URL進行請求，但每種不同的檔案都要進行區分，以便服務端和客戶端進行正確處理，比如播放聲音、顯示文字。

因此，HTTP仔細地給每種要通過http請求響應傳輸的物件都打上名為MIME型別的資料格式標籤。

MIME: Multipurpose Internet Mail Extension 多用途因特網郵件擴充套件
複製程式碼

最開始是為了解決電子郵件系統之間的問題，後來用於定義更多型別的多謀體內容。常見的MIME：

html：text/html
Ascii: text/plain
Json:text/json
Jpg:image/jpeg
Gif:image/gif
Ppt: application/vnd.ms-powerpoint
Quicktime:video/quicktime
複製程式碼

協議介紹

協議棧

HTTP在TCP/IP協議棧中的位置

HTTP是基於TCP/IP的應用，因此HTTP無須關心網路定址、資料傳輸和拓撲結構

協議工作流程

在HTTP1.0/1.1中，HTTP採用請求響應模型來處理HTTP事務 HTTP事務有一條請求命令和一個響應結果組成，它們通過HTTP報文進行資料傳輸

注意：請求是從客戶端發往服務端，而響應是從服務端發回客戶端

HTTP的工作過程

（1）客戶端連線到Web伺服器
（2）傳送HTTP請求
（3）伺服器接受請求並返回HTTP響應
（4）釋放連線TCP連線
（5）客戶端瀏覽器解析HTML內容

HTTP報文

報文

HTTP1.0/1.1報文由三部分組成：起始行、首部以及可選、包含資料的主體

其中起始行和首部是由行分隔的ASCII文字

主體是一個可選的資料塊，主體中可以包含文字也可以包含二進位制資料，也可以為空，與首部通過空一行進行區分

請求報文的格式：

<method> <request-url> <version>
<headers>

<entity-body>
複製程式碼

響應報文的格式：

<version> <status> <reason-phrase>
<headers>

<entity-body>
複製程式碼

具體例子：

注：部分文章也將HTTP請求報文分為兩部分請求頭和請求體，請求頭的第一行為請求行。

首部欄位

HTTP首部欄位向請求和響應報文中新增了一些附加資訊，是一系列 key-value的列表,比如Content-Type:image/jpeg 表示型別是jpeg圖片

首部的分類包括

通用首部：在請求和響應中都出現的資訊
請求首部：只在請求報文中出現的資訊
響應首部：只在響應報文中出現的資訊
實體首部：描述主題的長度、內容等的資訊
擴充套件首部：在HTTP規範中沒有定義的其他資訊

實體

HTTP實體是HTTP報文的負荷，是HTTP要傳輸的資料內容。

方法

HTTP基本的方法包括：GET/POST/HEAD/PUT/TRACE/OPTIONS，用來告訴服務端要做什麼操作

GET

GET是最常用的方法，通常用於請求伺服器傳送某個資源

POST

POST是常用的方法之一，用於向服務端提交資料，有主體

HEAD

與GET類似，但在響應中只有首部，不返回具體資料，可以用來檢視資源是否存在

PUT/TRACE/OPTIONS/DELETE

PUT:用於向服務端寫入文件
TRACE:用於跟蹤某個請求
OPTIONS:用於查詢服務端支援的方法
DELETE:用於刪除服務端某個資源

其他擴充套件方法

HTTP在設計之初就被設計成可擴充套件的，這樣就可以適應新的特性。擴充套件方法是在HTTP規範中沒有定義的方法，它們有特別的用處，但需要服務端進行實現：
LOCK：鎖定某個資源
COPY：拷貝某個資源
MOVE：移動某個資源

狀態碼

狀態碼是響應報文中對請求所做事情的處理結果，以方便客戶端處理響應資料

狀態碼分為五大類：

資訊性狀態碼：100~199
成功狀態碼：200~299 重定向狀態碼：300~399
客戶端錯誤狀態碼：400~499
服務端錯誤狀態碼：500~599

常見的狀態碼有如下幾種

 - 200 OK 客戶端請求成功	
 - 301 Moved Permanently 請求永久重定向	
 - 302 Moved Temporarily 請求臨時重定向	
 - 304 Not Modified 檔案未修改，可以直接使用快取的檔案。	
 - 400 Bad Request 由於客戶端請求有語法錯誤，不能被伺服器所理解。	
 - 401 Unauthorized 請求未經授權。這個狀態程式碼必須和WWW-Authenticate報頭域一起使用	
 - 403 Forbidden 伺服器收到請求，但是拒絕提供服務。伺服器通常會在響應正文中給出不提供服務的原因	
 - 404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL	
 - 500 Internal Server Error 伺服器發生不可預期的錯誤，導致無法完成客戶端的請求。	
 - 503 Service Unavailable 伺服器當前不能夠處理客戶端的請求，在一段時間之後，伺服器可能會恢復正常。	
複製程式碼

Https的基礎知識

超文字傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種通過計算機網路進行安全通訊的傳輸協議。HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密資料包。

SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發，SSL 協議位於 TCP/IP 協議與各種應用層協議之間，為資料通訊提供安全支援。

TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）由網景公司開發，1999年從 3.1 開始被 IETF 標準化並改名，發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。SSL3.0和TLS1.0由於存在安全漏洞，已經很少被使用到。TLS 1.3 改動會比較大，目前還在草案階段，目前使用最廣泛的是TLS 1.1、TLS 1.2。

Https

HTTP 傳輸面臨的巨大的安全問題如下：

隱私洩露
頁面劫持
劫持路徑及分類

HTTP 向 HTTPS 演化的過程

第一步：為了防止上述現象的發生，人們想到一個辦法：對傳輸的資訊加密（即使黑客截獲，也無法破解）

如上圖所示，此種方式屬於對稱加密，雙方擁有相同的金鑰，資訊得到安全傳輸，但此種方式的缺點是：

不同的客戶端、伺服器數量龐大，所以雙方都需要維護大量的金鑰，維護成本很高
因每個客戶端、伺服器的安全級別不同，金鑰極易洩露第二步：既然使用對稱加密時，金鑰維護這麼繁瑣，那我們就用非對稱加密試試

如上圖所示，客戶端用公鑰對請求內容加密，伺服器使用私鑰對內容解密，反之亦然，但上述過程也存在缺點：

公鑰是公開的（也就是黑客也會有公鑰），所以第 ④ 步私鑰加密的資訊，如果被黑客截獲，其可以使用公鑰進行解密，獲取其中的內容第三步：非對稱加密既然也有缺陷，那我們就將對稱加密，非對稱加密兩者結合起來，取其精華、去其糟粕，發揮兩者的各自的優勢

如上圖所示
第 ③ 步時，客戶端說：（我們們後續回話採用對稱加密吧，這是對稱加密的演算法和對稱金鑰）這段話用公鑰進行加密，然後傳給伺服器
伺服器收到資訊後，用私鑰解密，提取出對稱加密演算法和對稱金鑰後，伺服器說：（好的）對稱金鑰加密
後續兩者之間資訊的傳輸就可以使用對稱加密的方式了

遇到的問題：

客戶端如何獲得公鑰如何確認伺服器是真實的而不是黑客

第四步：獲取公鑰與確認伺服器身份

獲取公鑰提供一個下載公鑰的地址，回話前讓客戶端去下載。（缺點：下載地址有可能是假的；客戶端每次在回話前都先去下載公鑰也很麻煩）回話開始時，伺服器把公鑰發給客戶端（缺點：黑客冒充伺服器，傳送給客戶端假的公鑰）
那有木有一種方式既可以安全的獲取公鑰，又能防止黑客冒充呢？那就需要用到終極武器了：SSL 證照（申購)

如上圖所示，在第 ② 步時伺服器傳送了一個SSL證照給客戶端，SSL 證照中包含的具體內容有：

證照的釋出機構CA
證照的有效期
公鑰
證照所有者
簽名
………
客戶端在接受到服務端發來的SSL證照時，會對證照的真偽進行校驗，以瀏覽器為例說明如下：
1. 首先瀏覽器讀取證照中的證照所有者、有效期等資訊進行一一校驗
2. 瀏覽器開始查詢作業系統中已內建的受信任的證照釋出機構CA，與伺服器發來的證照中的頒發者CA比對，用於校驗證照是否為合法機構頒發
3. 如果找不到，瀏覽器就會報錯，說明伺服器發來的證照是不可信任的。
4. 如果找到，那麼瀏覽器就會從作業系統中取出頒發者CA 的公鑰，然後對伺服器發來的證照裡面的簽名進行解密
5. 瀏覽器使用相同的hash演算法計算出伺服器發來的證照的hash值，將這個計算的hash值與證照中籤名做對比
6. 對比結果一致，則證明伺服器發來的證照合法，沒有被冒充
7. 此時瀏覽器就可以讀取證照中的公鑰，用於後續加密了
所以通過傳送SSL證照的形式，既解決了公鑰獲取問題，又解決了黑客冒充問題，一箭雙鵰，HTTPS加密過程也就此形成

Htttp2.0

HTTP/2 （原名HTTP/2.0）即超文字傳輸協議 2.0，是下一代HTTP協議。是由網際網路工程任務組（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小組進行開發。是自1999年http1.1釋出後的首個更新。HTTP 2.0在2013年8月進行首次合作共事性測試。在開放網際網路上HTTP 2.0將只用於 https:// 網址，而 http:// 網址將繼續使用HTTP/1，目的是在開放網際網路上增加使用加密技術，以提供強有力的保護去遏制主動攻擊。DANE RFC6698允許域名管理員不通過第三方CA自行發行證照。

Http2.0的優勢；

提升web的效能，在與 HTTP/1.1 完全語義相容的基礎上，進一步減少了網路延遲
HTTP/2: the Future of the Internet 這是 Akamai 公司建立的一個官方的演示，用以說明 HTTP/2 相比於之前的 HTTP/1.1 在效能上的大幅度提升。同時請求 379 張圖片，從Load time 的對比可以看出 HTTP/2 在速度上的優勢。

使用chrome的開發工具的操作時，可以明顯發現Http1.0的延時問題比較。
多路複用 (Multiplexing)

多路複用允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息。

眾所周知，在 HTTP/1.1 協議中「瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量限制。超過限制數目的請求會被阻塞」。
HTTP/2 的多路複用(Multiplexing) 則允許同時通過單一的 HTTP/2 連線發起多重的請求-響應;因此 HTTP/2 可以很容易的去實現多流並行而不用依賴建立多個 TCP 連線，HTTP/2 把 HTTP 協議通訊的基本單位縮小為一個一個的幀，這些幀對應著邏輯流中的訊息。並行地在同一個 TCP 連線上;往往有效的解決了統一域名請求限制阻塞問題。
**二進位制分幀 **
在二進位制分幀層中， HTTP/2 會將所有傳輸的資訊分割為更小的訊息和幀（frame）,並對它們採用二進位制格式的編碼，其中 HTTP1.x 的首部資訊會被封裝到 HEADER frame，而相應的 Request Body 則封裝到 DATA frame 裡面。
++HTTP/2 通訊都在一個連線上完成，這個連線可以承載任意數量的雙向資料流++。在過去， HTTP 效能優化的關鍵並不在於高頻寬，而是低延遲。TCP 連線會隨著時間進行自我「調諧」，起初會限制連線的最大速度，如果資料成功傳輸，會隨著時間的推移提高傳輸的速度。這種調諧則被稱為 TCP 慢啟動。由於這種原因，讓原本就具有突發性和短時性的 HTTP 連線變的十分低效。

總結：
- 單連線多資源的方式，減少服務端的連結壓力,記憶體佔用更少,連線吞吐量更大
- 由於 TCP 連線的減少而使網路擁塞狀況得以改善，同時慢啟動時間的減少,使擁塞和丟包恢復速度更快
首部壓縮（Header Compression） HTTP/1.1並不支援 HTTP 首部壓縮，為此 SPDY 和 HTTP/2 應運而生， SPDY 使用的是通用的DEFLATE 演算法，而 HTTP/2 則使用了專門為首部壓縮而設計的 HPACK 演算法。
服務端推送
服務端推送是一種在客戶端請求之前傳送資料的機制。在 HTTP/2 中，伺服器可以對客戶端的一個請求傳送多個響應。Server Push 讓 HTTP1.x 時代使用內嵌資源的優化手段變得沒有意義；如果一個請求是由你的主頁發起的，伺服器很可能會響應主頁內容、logo 以及樣式表，因為它知道客戶端會用到這些東西。這相當於在一個 HTML 文件內集合了所有的資源，不過與之相比，伺服器推送還有一個很大的優勢：可以快取！也讓在遵循同源的情況下，不同頁面之間可以共享快取資源成為可能。