http1.0 http1.1 http2.0 http3.0 websocket GRPC signalR簡介和了解

HTTP版本介紹

A.Http0.9版本

0.9是鼻祖版本，它的主要特點包括：

• 請求方法支援有限

  隻支援GET請求方式，不支援其他請求方式 是以用戶端向服務端傳輸資訊的量非常有限，也就是現在常用的Post請求無法使用

• 不支援請求頭header

  不能在請求中指定版本号，服務端隻具有傳回HTML字元串的能力

• 響應即關閉

  服務端相響應之後，立即關閉TCP連接配接

B.Http1.0版本

1.0版本主要是對0.9版本的強化，效果也比較明顯，主要特性和缺點包括：

• 豐富請求方法

  請求方式新增了POST，DELETE，PUT，HEADER等方式，提高了用戶端向服務端發送資訊的量級

• 增加請求頭和響應頭

  增添了請求頭和響應頭的概念，可以在通信中指定了HTTP協定版本号，以及其他header資訊，使得C/S互動更加靈活友善

• 豐富資料傳輸内容

  擴充了傳輸内容格式包括：圖檔、音視訊資源、二進制等都可以進行傳輸，相比0.9的隻能傳輸html内容讓http的應用場景更多

• 連結複用性差

  1.0版本中每個TCP連接配接隻能發送一個請求，資料發送完畢連接配接就關閉，如果還要請求其他資源，就必須重建立立連接配接。TCP為了保證正确性和可靠性需要用戶端和伺服器三次握手和四次揮手，是以建立連接配接成本很高，基于擁塞控制開始時發送速率較慢，是以1.0版本的性能并不理想。

• 無狀态無連接配接的弊端

  1.0版本是無狀态且無連接配接的，換句話說就是伺服器不跟蹤不記錄請求過的狀态，用戶端每次請求都需要建立tcp連接配接不能複用，并且1.0規定在前一個請求響應到達之後下一個請求才能發送，如果前一個阻塞後面的請求就會被阻塞。 丢包和亂序問題和高成本的連結過程讓複用和隊頭阻塞産生很多問題，是以無連接配接無狀态是1.0版本的一個弱肋。

C.Http1.1版本

1.1版本在1.0版本釋出後大約1年就推出了，是對1.0版本的優化和完善，1.1版本的主要特點包括：

• 增加長連接配接

  新增Connection字段，可以設定keep-alive值保持連接配接不斷開，即 TCP 連接配接預設不關閉，可以被多個請求複用，這也是1.1版本很重要的優化，但是在S端伺服器隻有處理完一個回應，才會進行下一個回應。要是前面的回應特别慢，後面就會有許多請求排隊等着，仍然存在隊頭阻塞問題。

• 管道化

  在長連接配接的基礎上，管道化可以不等第一個請求響應繼續發送後面的請求，但響應的順序還是按照請求的順序傳回，即在同一個TCP連接配接中，用戶端可以同時發送多個請求，進一步改進了HTTP協定的傳輸效率。

• 更多的請求方法

  增加了 PUT、PATCH、OPTIONS、DELETE 等請求方式。

• host字段

  Host字段用來指定伺服器的域名，這樣就可以将多種請求發往同一台伺服器上的不同網站，提高了機器的複用，這個也是重要的優化

D.Http2.0版本

2.0版本是個裡程碑式的版本，相比1.x版本有了非常多的優化去适應目前的網絡場景，其中幾個重要功能點包括：

• 二進制格式

  1.x是文本協定，然而2.0是以二進制幀為基本機關，可以說是一個二進制協定，将所有傳輸的資訊分割為消息和幀，并采用二進制格式的編碼，一幀中包含資料和辨別符，使得網絡傳輸變得高效而靈活。

• 多路複用

  這是一個非常重要的改進，1.x中建立多個連接配接的消耗以及效率都存在問題，2.0版本的多路複用多個請求共用一個連接配接，多個請求可以同時在一個TCP連接配接上并發，主要借助于二進制幀中的辨別進行區分實作鍊路的複用。

• 頭部壓縮

  2.0版本使用使用HPACK算法對頭部header資料進行壓縮，進而減少請求的大小提高效率，這個非常好了解，之前每次發送都要帶相同的header，顯得很備援，2.0版本對頭部資訊進行增量更新有效減少了頭部資料的傳輸。

• 服務端推送

  這個功能有點意思，之前1.x版本服務端都是收到請求後被動執行，在2.0版本允許伺服器主動向用戶端發送資源，這樣在用戶端可以起到加速的作用。

E.Http3.0版本

HTTP3.0又稱為HTTP Over QUIC，其棄用TCP協定，改為使用基于UDP協定的QUIC協定來實作。QUIC其實是Quick UDP Internet Connections的縮寫，直譯為快速UDP網際網路連接配接。它是 Google 提出來的一個基于 UDP 的傳輸協定。HTTP 3.0 于 2022 年 6 月 6 日正式釋出，IETF 把 HTTP 3.0 标準制定在了 RFC 9114 中。

使用QUIC的優勢

• 使用 UDP 協定，不需要三次連接配接進行握手，而且也會縮短 TLS 建立連接配接的時間。
• 解決了隊頭阻塞問題。
• 實作動态可插拔，在應用層實作了擁塞控制算法，可以随時切換。
• 封包頭和封包體分别進行認證和加密處理，保障安全性。
• 連接配接能夠平滑遷移。

WebSocket

WebSocket 是一個雙向通信協定，它在握手階段采用 HTTP/1.1 協定（暫時不支援 HTTP/2）。先通過HTTP/HTTPS協定發起一條特殊HTTP請求進行握手後建立一個用于交換資料的TCP連接配接，也是支援長連接配接的。WebSocket是由HTTP先發起的，然後在轉為WebSocket。

WebSocket協定的特點

• 建立在 TCP 協定之上，它需要通過握手連接配接之後才能通信，伺服器端的實作比較容易。
• 與 HTTP 協定有着良好的相容性。預設端口也是80或443，并且握手階段采用 HTTP 協定，是以握手時不容易屏蔽，能通過各種 HTTP 代理伺服器。
• 資料格式比較輕量，性能開銷小，通信高效。可以發送文本，也可以發送二進制資料。
• 沒有同源限制，用戶端可以與任意伺服器通信。
• 協定辨別符是ws（如果加密，則為wss），伺服器網址就是URL。（例如：ws://www.example.com/chat）
• 它是一種雙向通信協定，采用異步回調的方式接受消息，當建立通信連接配接，可以做到持久性的連接配接，WebSocket伺服器和Browser都能主動的向對方發送或接收資料，實質的推送方式是伺服器主動推送，隻要有資料就推送到請求方。

握手過程

首先用戶端向服務端發起一個特殊的 HTTP 請求.如果服務端支援該版本的 WebSocket，會傳回 101 響應,握手完成後，接下來的 TCP 資料包就都是 WebSocket 協定的幀了。如圖所示：

HTTP1.1與WebSocket的異同

最後，作為總結，讓我們再來回顧一下HTTP1.1與WebSocket的相同與不同。加深對WebSocket的了解。

協定層面的異同

相同點

• 都是基于TCP的應用層協定。
• 都使用Request/Response模型進行連接配接的建立。
• 在連接配接的建立過程中對錯誤的處理方式相同，在這個階段WebSocket可能傳回和HTTP相同的傳回碼。

不同點

• HTTP協定基于Request/Response，隻能做單向傳輸，是半雙工協定，而WebSocket是全雙工協定，類似于Socket通信，雙方都可以在任何時刻向另一方發送資料。
• WebSocket使用HTTP來建立連接配接，但是定義了一系列新的Header域，這些域在HTTP中并不會使用。換言之，二者的請求頭不同。
• WebSocket的連接配接不能通過中間人來轉發，它必須是一個直接連接配接。如果通過代理轉發，一個代理要承受如此多的WebSocket連接配接不釋放，就類似于一次DDOS攻擊了。
• WebSocket在建立握手連接配接時，資料是通過HTTP協定傳輸的，但在建立連接配接之後，真正的資料傳輸階段是不需要HTTP協定參與的。
• WebSocket傳輸的資料是二進制流，是以幀為機關的，HTTP傳輸的是明文傳輸，是字元串傳輸，WebSocket的資料幀有序

websocket與HTTP的關系可以參考下圖

 WebSockets 最初是為 HTTP/1.1 設計的，但後來改用于 HTTP/2。

 .NET 7 為 Kestrel、SignalR JavaScript 用戶端和帶有 Blazor WebAssembly 的 SignalR 引入了基于 HTTP/2 的 Websockets 支援。

HTTP/2 WebSockets 使用 CONNECT 請求而不是 GET，是以可能需要更新你自己的路由和控制器。

SignalR

ASP.NET Core SignalR 是一個開放源代碼庫，可用于簡化向應用添加實時 Web 功能。 實時 Web 功能使伺服器端代碼能夠将内容推送到用戶端。按照我的了解也是基于Http2.0的消息傳輸架構。

适合 SignalR 的候選項：

• 需要從伺服器進行高頻率更新的應用。 示例包括遊戲、社交網絡、投票、拍賣、地圖和 GPS 應用。
• 儀表闆和監視應用。 示例包括公司儀表闆、即時銷售更新或旅行警報。
• 協作應用。 協作應用的示例包括白闆應用和團隊會議軟體。
• 需要通知的應用。 社交網絡、電子郵件、聊天、遊戲、旅行警報和很多其他應用都需使用通知。

SignalR 提供用于建立伺服器到用戶端遠端過程調用（RPC） 的 API。 RPC 從伺服器端 .NET Core 代碼調用用戶端上的函數。 提供多個受支援的平台，其中每個平台都有各自的用戶端 SDK。 是以，RPC 調用所調用的程式設計語言有所不同。

以下是 ASP.NET Core SignalR 的一些功能：

• 自動處理連接配接管理。
• 同時向所有連接配接的用戶端發送消息。 例如聊天室。
• 向特定用戶端或用戶端組發送消息。
• 對其進行縮放，以處理不斷增加的流量。
• SignalR中心協定

傳輸

SignalR 支援以下用于處理實時通信的技術（按正常回退的順序）：

• WebSockets
• Server-Sent Events
• 長輪詢

SignalR 自動選擇伺服器和用戶端能力範圍内的最佳傳輸方法。

中心

SignalR 使用中心在用戶端和伺服器之間進行通信。

Hub 是一種進階管道，允許用戶端和伺服器互相調用方法。 SignalR 自動處理跨計算機邊界的排程，并允許用戶端調用伺服器上的方法，反之亦然。 可以将強類型參數傳遞給方法，進而支援模型綁定。 SignalR 提供兩個内置中心協定：基于 JSON 的文本協定和基于 MessagePack的二進制協定。相比 JS，MessagePack 通常會建立較小的消息。

中心通過發送包含用戶端方法的名稱和參數的消息來調用用戶端代碼。 作為方法參數發送的對象使用配置的協定進行反序列化。 用戶端嘗試将名稱與用戶端代碼中的方法比對。 當用戶端找到比對項時，它會調用該方法并将反序列化的參數資料傳遞給它。

GRPC

概述

GRPC是一個高性能、通用的開源RPC架構，基于

底層HTTP/2協定标準

和

協定層Protobuf序列化協定

開發，支援衆多的開發語言。

gRPC 也是基于以下理念：定義一個服務，指定其能夠被遠端調用的方法（包含參數和傳回類型）。在服務端實作這個接口，并運作一個 gRPC伺服器來處理用戶端調用。在用戶端擁有一個存根能夠像服務端一樣的方法。

gRPC使用

protocol buffers

作為接口描述語言（IDL）以及底層的資訊交換格式

優點

1. 基于 HTTP/2 之上的二進制協定（Protobuf 序列化機制）；
2. 一個連接配接上可以多路複用，并發處理多個請求和響應；
3. 多種語言的類庫實作；
4. 服務定義檔案和自動代碼生成（.proto 檔案和 Protobuf 編譯工具）。
5. RPC 還提供了很多擴充點，用于對架構進行功能定制和擴充，例如，通過開放負載均衡接口可以無縫的與第三方元件進行內建對接（Zookeeper、域名解析服務、SLB 服務等）

參考文檔：終于搞懂了，HTTP協定發展簡史 - 知乎 (zhihu.com)