面試官問了一下三次握手，我甩出這張腦圖，他服了！
前言失業期間閑來無事，看了本《網絡是怎樣連接的》與兩本HTTP相關的專欄。
一方面補充專業知識，另一方面也是為了跳槽面試做準備。
避免看了即忘，就畫了一張XMind圖：
值得深入的問題太多了，今兒就先來講講：Web中的幾種“握手”。
1. 不止一種握手
在早期的網絡傳輸中，也就存在TCP協議需要“握手”的過程，但早期的協議有一個缺陷：通信只能由客戶端發起，做不到服務器主動向客戶端推送信息。
于是WebSocket 協議在 2008 年誕生，2011 年成為國際標準。所有瀏覽器都已經支持了。
而隨著SSL/TLS的完善，存在已久的安全版網絡協議：HTTPS也是迸發式發展。
最后前端領域的協議握手便成了三分天下：
- TCP三次握手，歸HTTP。
- TLS握手，歸HTTPS
- WebSocket握手，基于TCP協議，都能用。
2. TCP三次握手的終極意義
在我之前的文章也詳細的講述過TCP三次握手，但那時我未明確意識到其深刻含義。
就和大家一樣，只在面試前會記得，過后即忘。
直到我看到《網絡是怎樣連接的》中的一段話：
| 在實際的通信中，序號并不是從 1 開始的，而是需要用隨機數計算出一個初始值，這是因為 如果序號都從 1 開始，通信過程就會非常容易預測，有人會利用這一點來發動攻擊。
但是如果初始值是隨機的，那么對方就搞不清楚序號到底是從 多少開始計算的，因此需要在開始收發數據之前將初始值告知通信對象。 |
你品，你細品。三次握手不就是相互試探暗號，來確定是不是對的人嗎?
(1) 知識補充：一個網絡包的最大長度
計算每個網絡包能容納的數據長度，協議棧會根據一個叫作 MTU的參數來進行判斷。
MTU表示一個網絡包的最大長度，在以太網中一般是1500字節
MTU是包含頭部的總長度，因此需要從MTU減去頭部的長度，然后得到的長度就是一個網絡包中所能容納的最大數據長度，這一長度叫作MSS。
由上兩圖可知，MSS值是1460(1500-40)字節，其中：
- TCP固定頭部20字節。
- IP固定頭部20字節。
- TCP頭部最長可以達到60字節。
3. TLS握手：HTTPS的核心
|
HTTPS 其實是一個“非常簡單”的協議，RFC 文檔很小，只有短短的 7 頁，里面規定了新的協議名“https”，默認端口號 443，至于其他的什么請求 - 應答模式、報文結構、請求方法、URI、頭字段、連接管理等等都完全沿用 HTTP，沒有任何新的東西。 ---- 《透視HTTP協議》 |
感興趣的可以到這里看看：鏈接：https://tools.ietf.org/html/rfc2818
(1) TLS/SSL究竟是啥?
很多人看到TLS/SSL這對詞就開始蒙圈了。實際上，這兩個東西是一個玩意兒：
1999 年改名：SSL 3 === TLS 1.0
目前運用最廣泛的是TLS 1.2:
| TLS 由記錄協議、握手協議、警告協議、變更密碼規范協議、擴展協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術。 |
由于TLS/SSL 協議位于應用層和傳輸層 TCP 協議之間。TLS粗略的劃分又可以分為 2 層：
- 靠近應用層的握手協議 TLS Handshaking Protocols
- 靠近 TCP 的記錄層協議 TLS Record Protocol
這個篇幅展開來寫就太多了，我們先關心下TLS握手吧。
(2) TLS握手詳解
TLS 握手何時發生?：
- 每當用戶通過HTTPS導航到網站并且瀏覽器首先開始查詢網站的原始服務器時，就會進行TLS握手。
- 每當其他任何通信使用HTTPS(包括API調用和HTTPS查詢上的 DNS)時，也會發生TLS握手。
- 通過 TCP 握手打開 TCP 連接后，會發生TLS 握手。
TLS 握手期間會發生什么?
在TLS握手過程中，客戶端和服務器將共同執行以下操作：
- 指定將使用的 TLS 版本(TLS 1.0、1.2、1.3 等)
- 確定將使用哪些加密套件。
- 通過服務器的公鑰和 SSL 證書頒發機構的數字簽名來驗證服務器的身份
- 握手完成后，生成會話密鑰以使用對稱加密
在TLS中有兩種主要的握手類型：一種基于RSA，一種基于Diffie-Hellman。這兩種握手類型的主要區別在于主秘鑰交換和認證上。
主流的握手類型，基本都是基于RSA，所以以下講解都基于RSA版握手。
整個流程如下圖所示：
具體流程描述：
a. 客戶端hello：客戶端通過向服務器發送“問候”消息來發起握手。該消息將包括客戶端支持的 TLS 版本，支持的加密套件以及稱為“客戶端隨機”的隨機字節字符串。
b. 服務器hello：為回復客戶端hello消息，服務器發送一條消息，其中包含服務器的SSL證書，服務器選擇的加密套件和“服務器隨機數”，即服務器生成的另一個隨機字節串。
c. 客戶端發送公鑰加密的預主密鑰。
d. 服務器用自己的私鑰解密加密的預主密鑰。
- 客戶端finished：客戶端發送“完成”消息，該消息已用會話密鑰加密。
- 服務器finished：服務器發送一條用會話密鑰加密的“完成”消息。
e. 握手完成，后續通過主密鑰加解密。
只有加密套件，講解的話需要有抓包基礎。改天，改天我一定講。。。
4. WebSocket握手
WebSocket協議實現起來相對簡單。它使用HTTP協議進行初始握手。成功握手之后，就建立了連接，WebSocket基本上使用原始 TCP 讀取/寫入數據。
《圖解HTTP》一書中的圖講的比較清楚：
具體步驟表現是：
客戶端請求：
- 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
服務端響應：
- HTTP/1.1 101
- Switching Protocols
- Upgrade: websocket
- Connection: Upgrade
- Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
- Sec-WebSocket-Protocol: chat
(1) Websocket全雙工通信
Websocket協議解決了服務器與客戶端全雙工通信的問題。
那什么是單工、半雙工、全雙工通信?
(2) Websocket和Socket區別
可以把WebSocket想象成HTTP應用層)，HTTP和Socket什么關系，WebSocket和Socket就是什么關系。
a. WebSocket與HTTP的關系
相同點：
- 都是一樣基于TCP的，都是可靠性傳輸協議。
- 都是應用層協議。
不同點：
- WebSocket是雙向通信協議，模擬Socket協議，可以雙向發送或接受信息。HTTP是單向的。
- WebSocket是需要握手進行建立連接的。
b. Socket是什么?
Socket是應用層與TCP/IP協議族通信的中間軟件抽象層，它是一組接口。
在設計模式中，Socket其實就是一個門面模式，它把復雜的TCP/IP協議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數據，以符合指定的協議。
(3) 擴展知識：Socket.IO的七層降級
在Golang、Java Spring等框架中，websocket都有一套實現API。
Socket.IO 由兩部分組成：
- 一個服務端用于集成 (或掛載) 到 Node.JS HTTP 服務器：socket.io
- 一個加載到瀏覽器中的客戶端：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 核心區別在于兩點：
- 把 HTTP 下層的傳輸協議由 TCP/IP 換成了 SSL/TLS
- 收發報文不再使用 Socket API，而是調用專門的安全接口。
具體區別：
- HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。
- HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS 則是具有安全性的 ssl 加密傳輸協議。
- HTTP和https使用的是完全不同的連接方式，用的端口也不一樣,前者是80,后者是443。
- HTTP的連接很簡單,是無狀態的。HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。
