前端須要關注的幾種「握手」

前言

失業期間閒來無事，看了本《網絡是怎樣鏈接的》與兩本HTTP相關的專欄。

一方面補充專業知識，另外一方面也是爲了跳槽面試作準備。

避免看了即忘，就畫了一張XMind圖：

值得深刻的問題太多了，今兒就先來說講： Web中的幾種「握手」

1. 不止一種握手

在早期的網絡傳輸中，也就存在TCP協議須要「握手」的過程，但早期的協議有一個缺陷：通訊只能由客戶端發起，作不到服務器主動向客戶端推送信息。

因而WebSocket 協議在2008年誕生，2011年成爲國際標準。全部瀏覽器都已經支持了。

而隨着SSL/TLS的完善，存在已久的安全版網絡協議：HTTPS也是迸發式發展。

最後前端領域的協議握手便成了三分天下：

1. TCP三次握手，歸HTTP。
2. TLS握手，歸HTTPS
3. WebSocket握手，基於TCP協議，都能用。

2. TCP三次握手的終極意義

在我以前的文章：[《「真香警告」重學 TCP/IP 協議 與三次握手
》](https://juejin.im/post/5ca95e...

也詳細的講述過TCP三次握手，但那時我未明確意識到其深入含義。

就和你們同樣，只在面試前會記得，事後即忘。

直到我看到《網絡是怎樣鏈接的》中的一段話：

**在實際的通訊中，序號並非從 1 開始的，而是須要用隨機數計算出一個初始值，這是由於
若是序號都從 1 開始，通訊過程就會很是容易預測，有人會利用這一點來發動攻擊。 <br/><br/>可是若是初始值是隨機的，那麼對方就搞不清楚序號究竟是從
多少開始計算的，所以須要在開始收發數據以前將初始值告知通訊對象。**

你品，你細品。三次握手不就是相互試探暗號，來肯定是否是對的人嗎？

2.1 知識補充：一個網絡包的最大長度

計算每一個網絡包能容納的數據長度，協議棧會根據一個叫做 MTU的參數來進行判斷。

MTU表示一個網絡包的最大長度，在以太網中通常是1500字節

MTU是包含頭部的總長度，所以須要從MTU減去頭部的長度，而後獲得的長度就是一個網絡包中所能容納的最大數據長度，這一長度叫做MSS。

由上兩圖可知，MSS值是1460（1500-40）字節，其中：

1. TCP固定頭部20字節。
2. IP固定頭部20字節。
3. TCP頭部最長能夠達到60字節。

3. TLS握手：HTTPS的核心

HTTPS 實際上是一個「很是簡單」的協議， RFC 文檔很小，只有短短的 7 頁，裏面規定了新的協議名「 https」，默認端口號 443，至於其餘的什麼請求 - 應答模式、報文結構、請求方法、 URI、頭字段、鏈接管理等等都徹底沿用 HTTP，沒有任何新的東西。---- 《透視 HTTP協議》

感興趣的能夠到這裏看看：連接：https://tools.ietf.org/html/r...

3.1 TLS/SSL到底是啥？

不少人看到TLS/SSL這對詞就開始蒙圈了。實際上，這兩個東西是一個玩意兒：

1999 年更名：SSL 3 === TLS 1.0

目前運用最普遍的是TLS 1.2:

TLS 由記錄協議、握手協議、警告協議、變動密碼規範協議、擴展協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術。

因爲TLS/SSL 協議位於應用層和傳輸層 TCP 協議之間。TLS 粗略的劃分又能夠分爲 2 層：

1. 靠近應用層的握手協議 TLS Handshaking Protocols
2. 靠近 TCP 的記錄層協議 TLS Record Protocol

這個篇幅展開來寫就太多了，咱們先關心下TLS握手吧。

3.2 TLS握手詳解

TLS握手什麼時候發生？：

1. 每當用戶經過HTTPS導航到網站而且瀏覽器首先開始查詢網站的原始服務器時，就會進行TLS握手。
2. 每當其餘任何通訊使用HTTPS（包括API調用和HTTPS查詢上的DNS）時，也會發生TLS握手。
3. 經過TCP握手打開TCP鏈接後，會發生TLS 握手。

TLS握手期間會發生什麼？

在TLS握手過程當中，客戶端和服務器將共同執行如下操做：

• 指定將使用的TLS版本（TLS 1.0、1.二、1.3等）
• 肯定將使用哪些加密套件。
• 經過服務器的公鑰和SSL證書頒發機構的數字簽名來驗證服務器的身份
• 握手完成後，生成會話密鑰以使用對稱加密

加密套件決定握手方式：：

摘自：《HTTPS篇之SSL握手過程詳解》
在 TLS中有兩種主要的握手類型：一種基於 RSA，一種基於 Diffie-Hellman。 這兩種握手類型的主要區別在於主祕鑰交換和認證上。

	祕鑰交換	身份驗證
RSA握手	RSA	RSA
DH握手	DH	RSA/DSA

主流的握手類型，基本都是基於RSA，因此如下講解都基於 RSA版握手。

整個流程以下圖所示：

具體流程描述：

1. 客戶端hello：客戶端經過向服務器發送「問候」消息來發起握手。該消息將包括客戶端支持的TLS版本，支持的加密套件以及稱爲「客戶端隨機」的隨機字節字符串。
2. 服務器hello：爲回覆客戶端hello消息，服務器發送一條消息，其中包含服務器的SSL證書，服務器選擇的加密套件和「服務器隨機數」，即服務器生成的另外一個隨機字節串。
3. 客戶端發送公鑰加密的預主密鑰。

4. 服務器用本身的私鑰解密加密的預主密鑰。

   • 客戶端finished：客戶端發送「完成」消息，該消息已用會話密鑰加密。
   • 服務器finished：服務器發送一條用會話密鑰加密的「完成」消息。
5. 握手完成，後續經過主密鑰加解密。

只有加密套件，講解的話須要有抓包基礎。改天，改天我必定講。。。

4. WebSocket握手

WebSocket協議實現起來相對簡單。它使用HTTP協議進行初始握手。成功握手以後，就創建了鏈接，WebSocket基本上使用原始TCP讀取/寫入數據。

《圖解HTTP》一書中的圖講的比較清楚：

具體步驟表現是：

1. 客戶端請求：

GET /chat HTTP/1.1     
Host: server.example.com     
Upgrade: websocket     
Connection: Upgrade     
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==     
Sec-WebSocket-Protocol: chat, superchat     
Sec-WebSocket-Version: 13     
Origin: http://example.com

1. 服務端響應：

HTTP/1.1 101 
Switching Protocols     
Upgrade: websocket     
Connection: Upgrade     
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=     
Sec-WebSocket-Protocol: chat

4.1 Websocket全雙工通訊

Websocket協議解決了服務器與客戶端全雙工通訊的問題。

那什麼是單工、半雙工、全雙工通訊？

類型	能力
單工	信息單向傳送
半雙工	信息能雙向傳送，但不能同時雙向傳送
全雙工	信息可以同時雙向傳送

4.2 Websocket和Socket區別

能夠把WebSocket想象成HTTP應用層)，HTTP和Socket什麼關係，WebSocket和Socket就是什麼關係。

1. WebSocket與HTTP的關係

相同點

1. 都是同樣基於TCP的，都是可靠性傳輸協議。
2. 都是應用層協議。

不一樣點

1. WebSocket是雙向通訊協議，模擬Socket協議，能夠雙向發送或接受信息。HTTP是單向的。
2. WebSocket是須要握手進行創建鏈接的。

2. Socket是什麼？

Socket是應用層與TCP/IP協議族通訊的中間軟件抽象層，它是一組接口。

在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議。

4.1 擴展知識：Socket.IO的七層降級

在Golang、Java Spring等框架中，websocket都有一套實現API。

Socket.IO 由兩部分組成：

1. 一個服務端用於集成 (或掛載) 到 Node.JS HTTP 服務器： socket.io
2. 一個加載到瀏覽器中的客戶端： socket.io-client

不少人覺得Socket.IO只是WebSocket和XHR長輪詢。

實際上，Socket.io有不少傳輸機制:

1. WebSockets 
2. FlashSocket 
3. XHR長輪詢
4. XHR部分流：multipart/form-data
5. XHR輪詢
6. JSONP輪詢
7. iframe

得益於這麼多種傳輸機制，Socket.io兼容性徹底不用擔憂。

5. 擴展：HTTPS 與HTTP 核心區別

上面講到 Socket是什麼？，有一點我忘了講：

HTTPS 與HTTP 核心區別在於兩點：

1. 把 HTTP 下層的傳輸協議由 TCP/IP 換成了 SSL/TLS
2. 收發報文再也不使用 Socket API，而是調用專門的安全接口。

具體區別：

1. HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
2. HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS 則是具備安全性的ssl加密傳輸協議。
3. HTTP和https使用的是徹底不一樣的鏈接方式，用的端口也不同,前者是80,後者是443。
4. HTTP的鏈接很簡單,是無狀態的。HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。

後記及引用

本篇引用了大量資料和專欄：

1.《HTTPS篇之SSL握手過程詳解》
<br/>
2.[《網絡是怎樣鏈接的》--戶根勤]()
<br/>
3.[《圖解HTTP》--上野宣 ]()
<br/>
4.[《透視HTTP協議》--羅劍峯]()
<br/>
5.《What Happens in a TLS Handshake?》
<br/>

1. 《How to Use Websockets in Golang: Best Tools and Step-by-Step Guide》

在個人腦圖中，總結歸納了8種HTTP核心問題。

做爲一個轉行的前端，理解這些HTTP的過程既痛苦又有趣。想要腦圖的能夠掃碼加我，或公衆號回覆：HTTP

❤️ 看完三件事

若是你以爲這篇內容對你挺有啓發，我想邀請你幫我三個小忙：

1. 點贊，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓 -_-）
2. 關注「前端勸退師」，不按期分享原創知識。
3. 也看看其它文章

勸退師我的微信：huab119

也能夠來個人GitHub博客裏拿全部文章的源文件：

前端勸退指南：https://github.com/roger-hiro...一塊兒玩耍呀。~