?云原生計(jì)算基金會(huì)（Cloud Native Computing Foundation，CNCF）是一個(gè)非盈利的開源組織，專注于推動(dòng)云原生計(jì)算的發(fā)展和標(biāo)準(zhǔn)化。
而gRPC（Google Remote Procedure Call）是由Google發(fā)起并開源的高性能、跨語(yǔ)言RPC框架。
2017年，Google將gRPC項(xiàng)目捐贈(zèng)給了CNCF，使其成為云原生生態(tài)的核心組件之一。
gRPC與Kubernetes（容器編排）、Prometheus（監(jiān)控）、Istio（服務(wù)網(wǎng)格）等CNCF項(xiàng)目深度集成，廣泛應(yīng)用于微服務(wù)架構(gòu)和云原生應(yīng)用中，其重要性隨著云原生理念的普及而日益凸顯。
gRPC巧妙地結(jié)合了ProtoBuf、HTTP/2等成熟技術(shù)，為上述RPC三大問(wèn)題提供了全面且標(biāo)準(zhǔn)化的解決方案。
數(shù)據(jù)表示：默認(rèn)采用 ProtoBuf作為其IDL和高效的二進(jìn)制序列化方案。
數(shù)據(jù)傳遞：建立在 HTTP/2 協(xié)議之上，利用其多路復(fù)用、流控、頭部壓縮等特性實(shí)現(xiàn)高效網(wǎng)絡(luò)通信。
方法約定：通過(guò) ProtoBuf IDL (.proto 文件) 定義服務(wù)接口和消息結(jié)構(gòu)。
HTTP/2協(xié)議
HTTP/2是HTTP/1.1的重大升級(jí)版，其設(shè)計(jì)源于Google的SPDY協(xié)議，并于2015年正式成為標(biāo)準(zhǔn)（RFC 7540）。
HTTP/1.1雖應(yīng)用廣泛，但其固有的性能瓶頸——如隊(duì)頭阻塞（Head-of-Line Blocking）、較高的連接建立延遲、低效的文本頭部傳輸——已難以滿足現(xiàn)代Web應(yīng)用對(duì)高性能、低延遲的需求。
HTTP/2旨在克服這些問(wèn)題，顯著提升傳輸效率和用戶體驗(yàn)。
與HTTP/1.1的純文本傳輸不同，HTTP/2引入了二進(jìn)制分幀層 (Binary Framing Layer)，所有HTTP消息（請(qǐng)求/響應(yīng)）都被封裝成一個(gè)個(gè)二進(jìn)制編碼的幀 (Frame) 進(jìn)行傳輸。
這種設(shè)計(jì)不僅提高了處理效率和健壯性（解析二進(jìn)制比文本更快更不容易出錯(cuò)），還為多路復(fù)用（Multiplexing）、頭部壓縮（Header Compression）和服務(wù)器推送（Server Push）等高級(jí)特性奠定了基礎(chǔ)。
HTTP/2的核心架構(gòu)包含以下幾個(gè)關(guān)鍵概念：
Connection（連接）：一個(gè)TCP連接支持多個(gè)并發(fā)Stream，減少了HTTP/1.1中多個(gè)TCP連接的開銷和延遲。
Stream（流）：獨(dú)立的雙向通信通道，用于傳輸一條或多條Message，避免了隊(duì)頭阻塞。
Message（消息）：對(duì)應(yīng)HTTP/1.1的請(qǐng)求或響應(yīng)，由一個(gè)或多個(gè)Frame組成，使數(shù)據(jù)傳輸更靈活。
Frame（幀）：最小的通信單位，采用二進(jìn)制格式，包含元數(shù)據(jù)和有效載荷，用于客戶端與服務(wù)器間的信息傳遞。
幀結(jié)構(gòu)：
幀是一種長(zhǎng)度前綴消息（Length-Prefixed-Message）。幀以固定的9字節(jié)作為幀頭，后面跟著變長(zhǎng)的幀載荷（Frame Payload），幀頭包括如下公共字段：Type、Length、Flags， Stream Identifier。
+-----------------------------------------------+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
HTTP/2協(xié)議定義了10種不同類型的幀（Frame），其中通用格式包含以下幾個(gè)關(guān)鍵類型，這些類型共同定義了幀的行為和內(nèi)容。
Length（長(zhǎng)度）：表示幀載荷（Frame Payload）的長(zhǎng)度，以字節(jié)為單位。其最大長(zhǎng)度為2^14（即16384字節(jié)），不包括幀頭的9個(gè)字節(jié)。
Type（類型）：用于標(biāo)識(shí)幀的類型。其中，DATA幀和HEADERS幀，分別對(duì)應(yīng)于HTTP/1.1中的數(shù)據(jù)和頭部信息。其他幀類型還包括SETTINGS、PRIORITY、RST_STREAM等，用于實(shí)現(xiàn)協(xié)議的各種高級(jí)特性。
Flags（標(biāo)志）：該字段包含一組標(biāo)志位，用于傳遞幀的附加控制信息。常用的標(biāo)志位包括： END_HEADERS：表示當(dāng)前幀是頭數(shù)據(jù)（Headers）的最后一幀，相當(dāng)于HTTP/1.1中頭信息結(jié)束后的空行（“\r\n”）；END_STREAM：表示當(dāng)前幀是流（Stream）中最后一個(gè)幀，標(biāo)志著單方向數(shù)據(jù)傳輸?shù)慕Y(jié)束（End of Stream, EOS），相當(dāng)于HTTP/1.1中分塊傳輸編碼（Chunked Encoding）的結(jié)束標(biāo)志（“0\r\n\r\n”）；PRIORITY：用于指示流的優(yōu)先級(jí)，幫助服務(wù)器和客戶端優(yōu)化資源分配。
R（保留字段）：該字段為保留位，目前未使用，必須設(shè)置為0。
Stream Identifier（流標(biāo)識(shí)符）：用于標(biāo)識(shí)幀所屬的流（Stream）。每個(gè)流都有一個(gè)唯一的標(biāo)識(shí)符，用于在同一個(gè)TCP連接中區(qū)分不同的并發(fā)流。流標(biāo)識(shí)符的長(zhǎng)度為31位，其中客戶端發(fā)起的流使用奇數(shù)標(biāo)識(shí)符，服務(wù)器發(fā)起的流使用偶數(shù)標(biāo)識(shí)符。
消息的語(yǔ)義兼容性：
HTTP/2 協(xié)議與 HTTP/1盡可能保持兼容。從應(yīng)用程序的角度來(lái)看，協(xié)議的功能基本沒(méi)有變化。
為了實(shí)現(xiàn)這一點(diǎn)，HTTP/1的所有請(qǐng)求和響應(yīng)語(yǔ)義被保留，雖然傳達(dá)那些語(yǔ)義的語(yǔ)法已經(jīng)改變。
HTTP/1使用消息起始行（start-line）來(lái)傳達(dá)目標(biāo) URI，請(qǐng)求方法和響應(yīng)的狀態(tài)代碼，而HTTP/2為此使用以“:”字符開頭的特殊字段（pseudo-header）來(lái)達(dá)到相同的目的。
可以看到在第一個(gè)請(qǐng)求中，前兩個(gè)頭通常類似與HTTP/1：
GET /resoure HTTP/1.1
Host: https://example.com
...
現(xiàn)在被拆分為一個(gè)標(biāo)題框。
:method: GET
:scheme: https
:host: example.com
:path: /resource
...
而其余的頭則大致相同，都是lower-case字符。
HTTP/2嘗試盡可能地最小化有效載荷大小。它將壓縮與前一個(gè)請(qǐng)求中相同的頭。在HTTP/1中，一個(gè)連續(xù)的請(qǐng)求看起來(lái)像是針對(duì)不同資源的初始請(qǐng)求。
GET /otherResource HTTP/1.1
Host: https://example.org
...
而在HTTP/2中，對(duì)同一服務(wù)器的連續(xù)請(qǐng)求只需要:path頭部信息。
:path: /otherResource
因?yàn)樗衅渌^部信息都被標(biāo)記并壓縮緩存，并且可以通過(guò)“索引”進(jìn)行還原。
參考文章：原文鏈接
該文章在 2025/8/28 17:06:05 編輯過(guò)
400 186 1886
