HTTP 瞭解下

🍃 幾個疑問：

• 瀏覽器輸入 URL 後都發生了什麼？
• 什麼是三次握手，四次揮手？
• 什麼是長鏈接？爲何須要長鏈接？
• HTTP 有什麼缺陷？有什麼解決辦法嗎？
• HTTPS 建立過程是怎樣的？爲何 HTTPS 就是安全的？
• HTTP2 有什麼優點？
• HTTP2 的多路複用爲何能提升性能？

TCP/IP協議族

概念

要了解 HTTP，須要先了解下 TCP/IP協議族。

協議中有各式各樣的內容，好比電纜的規格到 IP 地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序、web頁面顯示須要處理的步驟等，把這些與互聯網相關聯的各種協議集合起來總稱爲TCP/IP協議族。

TCP/IP協議族分層管理

TCP/IP協議族分爲：應用層、傳輸層、網絡層、鏈路層。

• 應用層：決定了向用戶提供應用服務時通訊的活動，HTTP 協議也處於這一層。
• 傳輸層：對上層應用層提供處於網絡鏈接中兩臺計算機間的數據傳輸，TCP（傳輸控制協議）處於這一層。
• 網絡層：處理在網絡上流動的數據包（選擇一條傳輸路線）。
• 鏈路層：處理連接網絡的硬件部分。

TCP/IP協議族通訊數據流

利用TCP/IP協議族進行網絡通訊時，會經過分層順序與對方通訊。
發送端從應用層往下走
接收端往應用層方向上走

🌰 拿 HTTP 通訊舉例來講，客戶端輸入 url 回車後：

客戶端在應用層(HTTP 協議)發出一個 HTTP 請求 ⬇️
在傳輸層(TCP 協議)把從應用層接收到的請求報文分割，打上標記序號及端口號以後發給網絡層 ⬇️
網絡層(IP 協議)增長做爲通訊目的地的 MAC地址後發給鏈路層 ⬇️
這樣，發往網絡的通訊請求準備完畢，接着
接收端的服務器在鏈路層接收到請求數據，按順序往上走，一直走到應用層，纔算是真正的接收到了客戶端發過來的 HTTP 請求。

因而可知，HTTP，TCP，IP，DNS 是 TCP/IP協議族的一個子集，並分別出於本身所在的層級發揮着各自的做用。

HTTP 進化史

🍃 HTTP1.1 版本中的持久鏈接（長鏈接）是怎麼回事？

HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接（短鏈接），這樣無謂的 TCP 鏈接和斷開會增長通訊量的開銷，爲了解決這個問題，HTTP1.1 版本中提出了持久鏈接（HTTP keep-alive），只要任何一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態，這樣能夠創建一次 TCP 鏈接後屢次進行請求和相應的交互。

優勢：減小了 TCP 鏈接的重複創建和斷開所形成了額外開銷，減輕了服務端負載以及提升了 web 頁面的顯示速度。

🍃 HTTP1.1 版本的管線化是怎麼回事？

從前發送請求後須要等待並接收到響應，才能夠發送下一個請求，管線化技術出現後，不用等待響應就能夠直接發送下一個請求，實現了同時並行發送多個請求的功能。

HTTP協議

HTTP協議如何通訊？

HTTP協議：用於客戶端和服務端之間經過請求和響應達成通訊。

在一個 HTTP 請求建立的時候會建立一條 TCP 鏈接，HTTP 的全部請求都是在這個 TCP 鏈接的基礎上發送的。

HTTP通訊的橋樑 - TCP

TCP 位於傳輸層，提供可靠的字節流服務。

爲了方便通訊，將大塊數據分割成報文段（按序號），把每一個報文段可靠的（三次握手策略 (標記：SYN，ACK)）傳遞給對方。

🍃 三次握手策略：

step1. 客戶首先發送一個帶 SYN 標誌的數據包給對方
step2. 服務端接收後，回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息
step3. 客戶端再回傳一個帶 ACK 標誌的數據包，表明握手成功

若握手過程當中某個階段中斷，TCP 協議會再次以相同順序發送相同數據包。

🍃 那，瀏覽器輸入 URL 回車後都發生了什麼？

上圖是客戶端訪問一個頁面的流程圖，HTTP 通訊過程當中，密切相關的幾個協議都起到了哪些做用？

DNS職責：解析域名並返回 IP 地址給客戶端 ⬇️

HTTP協議職責：生成針對 web 目標服務器的 HTTP 請求報文 ⬇️

TCP協議職責：爲了方便通訊，將 HTTP 請求報文按序號分割成報文段，把每一個報文段可靠的（三次握手 (標記：SYN，ACK)）傳遞給對方 ⬇️

IP協議職責：搜索對方地址，一邊中轉一邊傳送 ⬇️

TCP協議職責：將對方那接收到的報文段按原來順序重組請求報文 ⬇️

HTTP協議職責：對 web 服務器請求的內容進行處理，請求的處理結果也一樣利用 TCP/IP通訊協議向用戶回傳

HTTP 狀態碼

HTTP 狀態碼：告知從服務器端返回的請求結果。

🍃 類別

1xx：信息性 - 接收的請求正在處理
2xx：成功 - 請求正常處理完畢
3xx：重定 - 須要進行附加操做已完成請求
4xx：客戶端錯誤 - 服務器沒法處理請求
5xx：服務器錯誤 - 服務器處理請求出錯

🍃 經常使用狀態碼
200：請求處理成功
204：請求處理成功，可是沒有資源能夠返回

301：永久性重定向，請求的資源已經被分配新的 URI，之後應使用如今所指的 URI
302：臨時性重定向，請求的資源已經被分配新的 URI， 但願用戶使用新的 URI 更新
303：請求對應的資源存在另外一個 URI，應使用 get 方法定向獲取請求的資源

400：請求報文中存在語法錯誤
401：請求須要有經過 http 認證的認證信息，若是以前已經進行過一次請求認證則表示用戶認證失敗
403：請求被服務器拒絕
404：服務器上找不到請求的資源

500：服務器執行請求時出錯
503：服務器正在進行停機維護或正在處理超負載，沒法處理請求

HTTP 的缺陷

🍃 可能被竊聽 - 第三方能夠獲知通訊內容 ①

HTTP 沒有加密功能，報文都是以明文的方式發送的，第三方能夠劫持通訊內容形成數據泄露等問題

🍃 可能被冒充 - 第三方能夠冒充他人身份參與通訊 ②

HTTP 通訊不會對通訊方進行確認，任何人均可以假裝成通訊方和你通訊，僞造虛假服務器欺騙用戶，實現釣魚欺詐，然而用戶根本沒法察覺

🍃 可能被篡改 - 第三方能夠修改通訊內容 ③

由於 HTTP 協議沒法證實通訊報文的完整性，也沒辦法確認發出的請求/響應以及接收到的請求/響應是先後相同的，在通訊的過程當中第三方能夠截獲並修改你的內容，然而通訊內容被篡改了也是沒辦法知曉的。

那麼這些弊端怎麼解決呢？
用 HTTPS， HTTPS = HTTP + 加密（①）+ 認證（②） + 完整性保護（③）

HTTP 的缺陷的解決方法 - HTTPS

HTTPS 不是應用層的新協議，是在 HTTP 和 TCP 中間加了一層 SSL，組合成了 HTTPS。

🍃 傳送門：HTTPS 的通訊過程

🍃 爲何 相比較 HTTP 來講 HTTPS 更安全 ？

• 使用 HTTPS 協議可認證用戶和服務端，確保數據發送到正確的客戶端和服務端；
• HTTPS 協議是由 SSL + HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，要比 HTTP 協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。

HTTP2

🍃 在看 HTTP2 以前，來看下 HTTP1.x 有哪些痛點。

1.併發鏈接
雖然 HTTP1.1 的管線化已經實現了併發請求，可是由於同時間同域名下請求個數有限制，超出數量的部分會被阻塞掛起，因此也只能作到部分多路複用。所以咱們在須要屢次請求客戶端的時候，一般要開啓多條 TCP 連接進行通訊，以減小等待時間。

2.HTTP1.x 報頭字段重複冗長切不壓縮就發送
每次互相發送相同的首部形成資源浪費較多，並且首部信息未經壓縮就發送，首部信息越多延遲越大。

3.請求只能從客戶端開始，客戶端不能夠接收除響應之外的指令，服務端不能夠主動推進消息給客戶端。

爲了進行根本性的改善，在協議級別消除 HTTP 所遭遇的瓶頸，SPDY協議 就應運而生了。

🍃 SPDY 是什麼？

SPDY 是一種 HTTP 兼容協議，它沒有徹底改寫 HTTP 協議，而是在 TCP/IP 的應用層與運輸層之間以會話層的形式加入，控制對數據的流動，但仍是採用 HTTP 創建通訊鏈接的，考慮到安全性，SPDY 規定在通訊中使用 SSL。


SPDY 對當前的 HTTP 協議有 4 個改進：

• 多路複用請求
• 對請求劃分優先級
• 壓縮 HTTP 頭
• 服務器推送流（即 Server Push 技術）

而 HTTP2 版本的設計正是基於 SPDY 協議。

HTTP2 相比較 HTTP1.x 來講進一步的下降了網絡延遲，提升了傳輸效率，從而大幅度的提高了web性能。

🌰 借圖說明：同時請求379張圖片

🍃 那麼，HTTP2 相比以前的版本作了哪些改進？

1.多路複用請求（單個域名）

這個設計彌補了HTTP1.1 中管線化只能部分多路複用了問題，作到了真正的併發請求，在 HTTP2 中，全部的通訊都是在一條 TCP 鏈接上完成的，能夠無限制處理多個 HTTP請求，不再用擔憂因爲數量限制而致使請求被阻塞。

2.請求優先級
通訊過程當中不只能夠無限制的併發處理請求並且還給請求逐個分配優先級順序，這樣作解決了因帶寬低而致使響應變慢的問題。

3.服務器推送流
傳統的 HTTP 請求服務端沒辦法主動向客戶端推送內容，HTTP2 中實現了這一功能，服務端能夠主動把一些資源推送給客戶端並緩存起來，當客戶端想要訪問這些資源的時候就能夠直接從緩存中讀取了，這樣能夠避免發送沒必要要的請求。

4.壓縮 HTTP 頭
HTTP1.x 的報頭字段常常重複和冗長，HTTP2 引入了頭信息壓縮機制。
頭信息使用gzip或compress壓縮後發送，這樣通訊產生的數據包數量和發送的字節就更少了。
另外客戶端和服務器同時維護一張頭信息表，全部字段都會存入信息表並生成索引號，之後直接發送索引號而不用再次發送相同字段，這樣能節省帶寬和提高速度。

5.二進制分幀
HTTP2中，在應用層（HTTP2.0）和傳輸層（TCP或者UDP）之間加了二進制分幀層。
在二進制分幀層中， HTTP2 會將全部傳輸的信息分割爲更小的消息和幀（frame），並對它們採用二進制格式的編碼而再也不是文本格式。
這種單鏈接多資源的方式，減小了服務端的壓力，使得內存佔用更少，鏈接吞吐量更大。並且，TCP鏈接數的減小使得網絡擁塞情況得以改善，同時慢啓動時間的減小，使擁塞和丟包恢復速度更快。

---

🍃 後記

由於最近總看到關於 HTTP 的問題，我又對這個概念很模糊，因此學習一下，以上是學習過程的筆記，若是有錯誤還請幫忙指出，感謝~

🍃 資料：

• HTTPS 的通訊過程
• HTTP/2.0 相比1.0有哪些重大改進？
• Java 9和Spring Boot 2.0紛紛宣佈支持的HTTP/2究竟是什麼？
• 《圖解 HTTP》
• HTTP協議原理+實踐視頻 [ 慕課網@jokcy老師 ]