之前也聊了不少網(wǎng)絡(luò)協(xié)議這塊內(nèi)容，現(xiàn)在我們將深入探討關(guān)鍵的網(wǎng)絡(luò)協(xié)議及其在不同應(yīng)用中的作用。重點在于理解這些協(xié)議如何塑造我們在互聯(lián)網(wǎng)上的通信和互動方式。我們將深入研究以下領(lǐng)域：

WebSocket

在之前的討論中，我們研究了HTTP及其在客戶端和服務(wù)器之間的典型請求-響應(yīng)交互中的作用。HTTP在大多數(shù)情況下表現(xiàn)良好，特別是當(dāng)響應(yīng)是即時的時候。然而，在服務(wù)器需要主動向客戶端推送更新的情況下，尤其是這些更新依賴于客戶端無法預(yù)測的事件（比如其他用戶的操作），HTTP可能不是最有效的方法。這是因為HTTP基本上是一種拉?。╬ull-based）協(xié)議，客戶端必須發(fā)起所有請求。那么，在不需要客戶端預(yù)測和請求每個更新的情況下，如何讓服務(wù)器向客戶端推送數(shù)據(jù)呢？通常有四種處理這種推送型通信的方法，如下圖所示。

1. 短輪詢（Short polling）

這是最基本的方法。在這種方法中，客戶端，通常是運行在我們的瀏覽器中的Web應(yīng)用程序，會不斷向服務(wù)器發(fā)送HTTP請求。想象這樣的場景：我們登錄到一個Web應(yīng)用程序，并被要求用智能手機(jī)掃描一個二維碼。這個二維碼通常用于某個特定的操作，比如認(rèn)證或啟動某個過程。Web應(yīng)用程序不知道我們何時會掃描二維碼。因此，它會每1-2秒向服務(wù)器發(fā)送一次請求，以檢查二維碼的狀態(tài)。一旦我們用智能手機(jī)掃描了二維碼，服務(wù)器會識別掃描，然后在Web應(yīng)用程序的下一個檢查請求中，將更新后的狀態(tài)發(fā)送回來。這樣，我們在掃描二維碼后將在接下來的1-2秒內(nèi)得到響應(yīng)。由于這種頻繁的檢查，我們將這種方法稱為“短輪詢”。

這種方法有兩個問題：

?它發(fā)送大量的HTTP請求，占用帶寬并增加服務(wù)器負(fù)載。?在最壞的情況下，我們可能要等待長達(dá)2秒才能收到響應(yīng)，導(dǎo)致明顯的延遲。

2. 長輪詢（Long polling）

長輪詢通過設(shè)置較長的HTTP請求超時時間來解決短輪詢的問題。可以這樣理解：我們將超時時間調(diào)整為30秒。如果我們在這個時間段內(nèi)掃描了二維碼，服務(wù)器將立即發(fā)送響應(yīng)。這種方法顯著減少了HTTP請求的數(shù)量。

然而，長輪詢并非沒有挑戰(zhàn)。即使長輪詢減少了請求的數(shù)量，但每個開放的請求仍然需要與服務(wù)器保持連接。如果有許多客戶端，這可能對服務(wù)器資源造成壓力。

3. WebSocket

短輪詢和長輪詢適用于簡單的任務(wù)，比如掃描二維碼。但對于復(fù)雜、數(shù)據(jù)量大且需要實時交互的任務(wù)，比如在線游戲，需要一種更高效的解決方案 - 這就是WebSocket。

TCP本質(zhì)上允許雙向數(shù)據(jù)流，使客戶端和服務(wù)器能夠同時相互發(fā)送數(shù)據(jù)。然而，基于TCP的HTTP/1.1并未充分利用這種能力。在HTTP/1.1中，數(shù)據(jù)傳輸通常是按順序進(jìn)行的 - 一方發(fā)送數(shù)據(jù)，然后另一方回應(yīng)。這種設(shè)計對于網(wǎng)頁交互足夠，但對于需要實時交互的在線游戲等應(yīng)用而言顯得不足。WebSocket是另一種基于TCP的協(xié)議，在單個連接上允許全雙工通信，填補(bǔ)了這個空白。稍后我們將詳細(xì)介紹。

4. SSE (Server-Sent Events)

SSE，即服務(wù)器推送事件，適用于特定的用例。當(dāng)客戶端建立SSE連接時，服務(wù)器保持此連接開放以持續(xù)發(fā)送更新。這種設(shè)置非常適用于服務(wù)器需要定期向客戶端推送數(shù)據(jù)的情況，而客戶端只需接收數(shù)據(jù)，無需向服務(wù)器發(fā)送信息。典型的例子是實時股票市場數(shù)據(jù)更新。使用SSE，服務(wù)器可以在每次有更新時向客戶端推送實時數(shù)據(jù)，而無需每次更新都發(fā)送請求。值得注意的是，與WebSocket不同，SSE不支持雙向通信，因此在需要雙向交互的用例中不太適用。

如何建立WebSocket連接

要建立WebSocket連接，我們需要在HTTP頭部包含特定字段，這些字段告訴瀏覽器切換到WebSocket協(xié)議。一個隨機(jī)生成的Base64編碼密鑰（Sec-WebSocket-Key）被發(fā)送到服務(wù)器。

請求頭：

服務(wù)器響應(yīng)頭：

狀態(tài)碼101表示協(xié)議正在切換。經(jīng)過這個額外的握手后，WebSocket連接建立完成，如下圖所示：

WebSocket消息

一旦HTTP升級為WebSocket，客戶端和服務(wù)器將在幀中交換數(shù)據(jù)。我們來看一下數(shù)據(jù)是什么樣子的：

操作碼（Opcode）是一個4位字段，表示幀數(shù)據(jù)的類型。

?“1”表示文本幀。?“2”表示二進(jìn)制幀。?“8”表示關(guān)閉連接的信號。

有效負(fù)載長度可以是一個7位字段，也可以擴(kuò)展為包含擴(kuò)展的有效負(fù)載長度。如果這兩個長度字段都被充分利用，有效負(fù)載長度可以表示幾個TB的數(shù)據(jù)。

WebSocket適用于在線游戲、聊天室和協(xié)作編輯應(yīng)用等需要客戶端和服務(wù)器頻繁交互的場景。

RPC

RPC允許在不同服務(wù)上執(zhí)行函數(shù)。從調(diào)用程序的角度來看，它似乎是在本地執(zhí)行函數(shù)。下圖展示了本地過程調(diào)用和遠(yuǎn)程過程調(diào)用之間的區(qū)別。我們可以將訂單管理和支付等模塊部署在同一進(jìn)程或不同服務(wù)器上。當(dāng)部署在同一進(jìn)程時，這是本地函數(shù)調(diào)用。當(dāng)部署在不同服務(wù)器上時，這是遠(yuǎn)程過程調(diào)用。

為什么我們需要RPC？難道我們不能使用HTTP在服務(wù)之間進(jìn)行通信嗎？讓我們在下表中比較RPC和HTTP。

RPC相對于HTTP的主要優(yōu)勢在于它輕量級的消息格式和卓越的性能。例如，gRPC就是一個例子，它在HTTP/2上運行，由于這一點，它具有更好的性能。

接下來，我們將探討另一個重要的應(yīng)用層協(xié)議 - RPC（遠(yuǎn)程過程調(diào)用）。

讓我們逐步了解gRPC的運作流程：

第一步：客戶端發(fā)起一個REST調(diào)用。請求體通常以JSON格式表示。

第二至四步：訂單服務(wù)（充當(dāng)gRPC客戶端）接收到REST調(diào)用后，將其轉(zhuǎn)換成適當(dāng)?shù)母袷?，并且發(fā)起一個RPC調(diào)用給支付服務(wù)。gRPC將客戶端存根編碼成二進(jìn)制格式，并將其發(fā)送到底層傳輸層。

第五步：gRPC通過HTTP2將數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)。二進(jìn)制編碼和網(wǎng)絡(luò)優(yōu)化使得gRPC比JSON快上多達(dá)五倍。

第六至八步：支付服務(wù)（充當(dāng)gRPC服務(wù)器）接收到數(shù)據(jù)包后，對其進(jìn)行解碼，并調(diào)用服務(wù)器應(yīng)用程序。

第九至十一步：服務(wù)器應(yīng)用程序返回的結(jié)果被編碼并發(fā)送回傳輸層。

第十二至十四步：訂單服務(wù)接收到數(shù)據(jù)包后，對其進(jìn)行解碼，并將結(jié)果發(fā)送給客戶端應(yīng)用程序。