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