2020-06-17 - 簡書

一. protocol buffers 是什么色乾？

Protocol buffers 是一種語言中立姑食，平臺無關，可擴展的序列化數據的格式芭梯，可用于通信協(xié)議险耀，數據存儲等。

Protocol buffers 在序列化數據方面玖喘，它是靈活的甩牺，高效的。相比于 XML 來說累奈，Protocol buffers 更加小巧贬派，更加快速，更加簡單澎媒。一旦定義了要處理的數據的數據結構之后搞乏，就可以利用 Protocol buffers 的代碼生成工具生成相關的代碼。甚至可以在無需重新部署程序的情況下更新數據結構旱幼。只需使用 Protobuf 對數據結構進行一次描述查描，即可利用各種不同語言或從各種不同數據流中對你的結構化數據輕松讀寫突委。

Protocol buffers 很適合做數據存儲或 RPC 數據交換格式柏卤。可用于通訊協(xié)議匀油、數據存儲等領域的語言無關缘缚、平臺無關、可擴展的序列化結構數據格式敌蚜。

二. 為什么要發(fā)明 protocol buffers 桥滨？

image

大家可能會覺得 Google 發(fā)明 protocol buffers 是為了解決序列化速度的，其實真實的原因并不是這樣的。

protocol buffers 最先開始是 google 用來解決索引服務器 request/response 協(xié)議的齐媒。沒有 protocol buffers 之前蒲每，google 已經存在了一種 request/response 格式，用于手動處理 request/response 的編組和反編組喻括。它也能支持多版本協(xié)議邀杏，不過代碼比較丑陋：

 if (version == 3) {
   ...
 } else if (version > 4) {
   if (version == 5) {
     ...
   }
   ...
 }

如果非常明確的格式化協(xié)議，會使新協(xié)議變得非常復雜唬血。因為開發(fā)人員必須確保請求發(fā)起者與處理請求的實際服務器之間的所有服務器都能理解新協(xié)議望蜡，然后才能切換開關以開始使用新協(xié)議。

這也就是每個服務器開發(fā)人員都遇到過的低版本兼容拷恨、新舊協(xié)議兼容相關的問題脖律。

protocol buffers 為了解決這些問題，于是就誕生了腕侄。protocol buffers 被寄予一下 2 個特點：

可以很容易地引入新的字段小泉，并且不需要檢查數據的中間服務器可以簡單地解析并傳遞數據，而無需了解所有字段冕杠。
數據格式更加具有自我描述性膏孟，可以用各種語言來處理(C++, Java 等各種語言)

這個版本的 protocol buffers 仍需要自己手寫解析的代碼。

不過隨著系統(tǒng)慢慢發(fā)展拌汇，演進柒桑，protocol buffers 目前具有了更多的特性：

自動生成的序列化和反序列化代碼避免了手動解析的需要。（官方提供自動生成代碼工具噪舀，各個語言平臺的基本都有）
除了用于 RPC（遠程過程調用）請求之外魁淳，人們開始將 protocol buffers 用作持久存儲數據的便捷自描述格式（例如，在Bigtable中）与倡。
服務器的 RPC 接口可以先聲明為協(xié)議的一部分界逛，然后用 protocol compiler 生成基類，用戶可以使用服務器接口的實際實現來覆蓋它們纺座。

protocol buffers 現在是 Google 用于數據的通用語言息拜。在撰寫本文時，谷歌代碼樹中定義了 48162 種不同的消息類型净响，包括 12183 個 .proto 文件少欺。它們既用于 RPC 系統(tǒng)，也用于在各種存儲系統(tǒng)中持久存儲數據馋贤。

小結：

protocol buffers 誕生之初是為了解決服務器端新舊協(xié)議(高低版本)兼容性問題赞别，名字也很體貼，“協(xié)議緩沖區(qū)”配乓。只不過后期慢慢發(fā)展成用于傳輸數據仿滔。

Protocol Buffers 命名由來：

Why the name "Protocol Buffers"?
The name originates from the early days of the format, before we had the protocol buffer compiler to generate classes for us. At the time, there was a class called ProtocolBuffer which actually acted as a buffer for an individual method. Users would add tag/value pairs to this buffer individually by calling methods like AddValue(tag, value). The raw bytes were stored in a buffer which could then be written out once the message had been constructed.

Since that time, the "buffers" part of the name has lost its meaning, but it is still the name we use. Today, people usually use the term "protocol message" to refer to a message in an abstract sense, "protocol buffer" to refer to a serialized copy of a message, and "protocol message object" to refer to an in-memory object representing the parsed message.

這個名字起源于 format 早期惠毁，在我們有 protocol buffer 編譯器為我們生成類之前。當時崎页，有一個名為 ProtocolBuffer 的類鞠绰，它實際上充當了單個方法的緩沖區(qū)。用戶可以通過調用像 AddValue(tag,value) 這樣的方法分別將標簽/值對添加到此緩沖區(qū)飒焦。原始字節(jié)存儲在一個緩沖區(qū)中洞豁，一旦構建消息就可以將其寫出。

從那時起荒给，名為“緩沖”的部分已經失去了意義丈挟，但它仍然是我們使用的名稱。今天志电，人們通常使用術語“protocol message”來指代抽象意義上的消息曙咽，“protocol buffer”指的是消息的序列化副本，而“protocol message object”指的是代表內存中對象解析的消息挑辆。

三. proto3 定義 message

image

目前 protocol buffers 最新版本是 proto3例朱，與老的版本 proto2 還是有些區(qū)別的。這兩個版本的 API 不完全兼容鱼蝉。

proto2 和 proto3 的名字看起來有點撲朔迷離洒嗤，那是因為當我們最初開源的 protocol buffers 時，它實際上是 Google 的第二個版本了魁亦，所以被稱為 proto2渔隶，這也是我們的開源版本號從 v2 開始的原因。初始版名為 proto1洁奈，從 2001 年初開始在谷歌開發(fā)的间唉。

在 proto 中，所有結構化的數據都被稱為 message利术。

message helloworld 
{ 
   required int32     id = 1;  // ID 
   required string    str = 2;  // str 
   optional int32     opt = 3;  //optional field 
}

上面這幾行語句呈野，定義了一個消息 helloworld，該消息有三個成員印叁，類型為 int32 的 id被冒，另一個為類型為 string 的成員 str。opt 是一個可選的成員轮蜕，即消息中可以不包含該成員昨悼。

接下來說明一些 proto3 中需要注意的地方。

syntax = "proto3";

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

如果開頭第一行不聲明 syntax = "proto3";肠虽，則默認使用 proto2 進行解析幔戏。

1. 分配字段編號

每個消息定義中的每個字段都有唯一的編號。這些字段編號用于標識消息二進制格式中的字段税课，并且在使用消息類型后不應更改闲延。請注意，范圍 1 到 15 中的字段編號需要一個字節(jié)進行編碼韩玩，包括字段編號和字段類型（具體原因見 Protocol Buffer 編碼原理這一章節(jié)）垒玲。范圍 16 至 2047 中的字段編號需要兩個字節(jié)。所以你應該保留數字 1 到 15 作為非常頻繁出現的消息元素找颓。請記住為將來可能添加的頻繁出現的元素留出一些空間合愈。

可以指定的最小字段編號為1，最大字段編號為2²⁹-1 或 536,870,911击狮。也不能使用數字 19000 到 19999（FieldDescriptor :: kFirstReservedNumber 到 FieldDescriptor :: kLastReservedNumber）佛析，因為它們是為 Protocol Buffers實現保留的。

如果在 .proto 中使用這些保留數字中的一個彪蓬，Protocol Buffers 編譯的時候會報錯寸莫。

同樣，您不能使用任何以前 Protocol Buffers 保留的一些字段號碼档冬。保留字段是什么膘茎，下一節(jié)詳細說明。

2. 保留字段

如果您通過完全刪除某個字段或將其注釋掉來更新消息類型酷誓，那么未來的用戶可以在對該類型進行自己的更新時重新使用該字段號披坏。如果稍后加載到了的舊版本 .proto 文件，則會導致服務器出現嚴重問題盐数，例如數據混亂棒拂，隱私錯誤等等。確保這種情況不會發(fā)生的一種方法是指定刪除字段的字段編號（或名稱玫氢，這也可能會導致 JSON 序列化問題）為 reserved着茸。如果將來的任何用戶試圖使用這些字段標識符，Protocol Buffers 編譯器將會報錯琐旁。

message Foo {
  reserved 2, 15, 9 to 11;
  reserved "foo", "bar";
}

注意涮阔，不能在同一個 reserved 語句中混合字段名稱和字段編號。如有需要需要像上面這個例子這樣寫灰殴。

3. 默認字段規(guī)則

字段名不能重復敬特，必須唯一。
repeated 字段：可以在一個 message 中重復任何數字多次(包括 0 )牺陶，不過這些重復值的順序被保留伟阔。

在 proto3 中，純數字類型的 repeated 字段編碼時候默認采用 packed 編碼（具體原因見 Protocol Buffer 編碼原理這一章節(jié)）

4. 各個語言標量類型對應關系

image

標注：

[1] 在 Java 中掰伸，無符號的 32 位和 64 位整數使用對應帶符號的表示方法皱炉，最高位存儲符號位。
[2] 在所有情況下狮鸭，給一個字段設置一個值的時候都會執(zhí)行類型檢查以確保其有效合搅。
[3] 64 位或無符號 32 位整數在解碼時始終表示為 long多搀，但是如果在設置字段的時候設置了 int，則可以為 int灾部。在所有情況下康铭，該值都必須符合設置時表示的類型。參見[2]赌髓。
[4] Python 字符串在解碼時表示為 unicode从藤，但如果給出了 ASCII 字符串，則可以為 str（此字符串可能會發(fā)生變化）锁蠕。
[5] 在 64 位計算機上使用 Integer夷野，在 32 位計算機上使用 string。

5. 枚舉

在 message 中可以嵌入枚舉類型荣倾。

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
  enum Corpus {
    UNIVERSAL = 0;
    WEB = 1;
    IMAGES = 2;
    LOCAL = 3;
    NEWS = 4;
    PRODUCTS = 5;
    VIDEO = 6;
  }
  Corpus corpus = 4;
}

枚舉類型需要注意的是悯搔，一定要有 0 值。

枚舉為 0 的是作為零值逃呼，當不賦值的時候鳖孤，就會是零值。
為了和 proto2 兼容抡笼。在 proto2 中苏揣，零值必須是第一個值。

另外在反序列化的過程中推姻，無法被識別的枚舉值平匈，將會被保留在 messaage 中。因為消息反序列化時如何表示是依賴于語言的藏古。在支持指定符號范圍之外的值的開放枚舉類型的語言中增炭，例如 C++ 和 Go，未知的枚舉值只是存儲為其基礎整數表示拧晕。在諸如 Java 之類的封閉枚舉類型的語言中隙姿，枚舉值會被用來標識未識別的值，并且特殊的訪問器可以訪問到底層整數厂捞。

在其他情況下输玷，如果消息被序列化，則無法識別的值仍將與消息一起序列化靡馁。

5. 枚舉中的保留值

如果您通過完全刪除枚舉條目或將其注釋掉來更新枚舉類型欲鹏，未來的用戶可以在對該類型進行自己的更新時重新使用數值。如果稍后加載到了的舊版本 .proto 文件臭墨，則會導致服務器出現嚴重問題赔嚎，例如數據混亂，隱私錯誤等等。確保這種情況不會發(fā)生的一種方法是指定已刪除條目的數字值（或名稱尤误，這也可能會導致JSON序列化問題）為 reserved侠畔。如果將來的任何用戶試圖使用這些字段標識符，Protocol Buffers 編譯器將會報錯袄膏。您可以使用 max 關鍵字指定您的保留數值范圍上升到最大可能值践图。

enum Foo {
  reserved 2, 15, 9 to 11, 40 to max;
  reserved "FOO", "BAR";
}

注意掺冠，不能在同一個 reserved 語句中混合字段名稱和字段編號沉馆。如有需要需要像上面這個例子這樣寫。

6. 允許嵌套

Protocol Buffers 定義 message 允許嵌套組合成更加復雜的消息德崭。

message SearchResponse {
  repeated Result results = 1;
}

message Result {
  string url = 1;
  string title = 2;
  repeated string snippets = 3;
}

上面的例子中斥黑，SearchResponse 中嵌套使用了 Result 。

更多的例子：

message SearchResponse {
  message Result {
    string url = 1;
    string title = 2;
    repeated string snippets = 3;
  }
  repeated Result results = 1;
}

message SomeOtherMessage {
  SearchResponse.Result result = 1;
}

message Outer {                  // Level 0
  message MiddleAA {  // Level 1
    message Inner {   // Level 2
      int64 ival = 1;
      bool  booly = 2;
    }
  }
  message MiddleBB {  // Level 1
    message Inner {   // Level 2
      int32 ival = 1;
      bool  booly = 2;
    }
  }
}

7. 枚舉不兼容性

可以導入 proto2 消息類型并在 proto3 消息中使用它們眉厨，反之亦然锌奴。然而，proto2 枚舉不能直接用在 proto3 語法中（但是如果導入的proto2消息使用它們憾股，這是可以的）鹿蜀。

8. 更新 message

如果后面發(fā)現之前定義 message 需要增加字段了，這個時候就體現出 Protocol Buffer 的優(yōu)勢了服球，不需要改動之前的代碼茴恰。不過需要滿足以下 10 條規(guī)則：

不要改動原有字段的數據結構。
如果您添加新字段斩熊，則任何由代碼使用“舊”消息格式序列化的消息仍然可以通過新生成的代碼進行分析往枣。您應該記住這些元素的默認值，以便新代碼可以正確地與舊代碼生成的消息進行交互粉渠。同樣分冈，由新代碼創(chuàng)建的消息可以由舊代碼解析：舊的二進制文件在解析時會簡單地忽略新字段。（具體原因見未知字段這一章節(jié)）
只要字段號在更新的消息類型中不再使用霸株，字段可以被刪除雕沉。您可能需要重命名該字段，可能會添加前綴“OBSOLETE_”去件，或者標記成保留字段號 reserved坡椒，以便將來的 .proto 用戶不會意外重復使用該號碼。
int32箫攀，uint32肠牲，int64，uint64 和 bool 全都兼容靴跛。這意味著您可以將字段從這些類型之一更改為另一個字段而不破壞向前或向后兼容性缀雳。如果一個數字從不適合相應類型的線路中解析出來，則會得到與在 C++ 中將該數字轉換為該類型相同的效果（例如梢睛，如果將 64 位數字讀為 int32肥印，它將被截斷為 32 位）识椰。
sint32 和 sint64 相互兼容，但與其他整數類型不兼容深碱。
只要字節(jié)是有效的UTF-8腹鹉，string 和 bytes 是兼容的。
嵌入式 message 與 bytes 兼容敷硅，如果 bytes 包含 message 的 encoded version功咒。
fixed32與sfixed32兼容，而fixed64與sfixed64兼容绞蹦。
enum 就數組而言力奋，是可以與 int32，uint32幽七，int64 和 uint64 兼容（請注意景殷，如果它們不適合，值將被截斷）澡屡。但是請注意猿挚，當消息反序列化時，客戶端代碼可能會以不同的方式對待它們：例如驶鹉，未識別的 proto3 枚舉類型將保留在消息中绩蜻，但消息反序列化時如何表示是與語言相關的。（這點和語言相關梁厉，上面提到過了）Int 域始終只保留它們的值辜羊。
將單個值更改為新的成員是安全和二進制兼容的。如果您確定一次沒有代碼設置多個字段词顾，則將多個字段移至新的字段可能是安全的八秃。將任何字段移到現有字段中都是不安全的。（注意字段和值的區(qū)別肉盹，字段是 field昔驱，值是 value）

9. 未知字段

未知數字段是 protocol buffers 序列化的數據，表示解析器無法識別的字段上忍。例如骤肛，當一個舊的二進制文件解析由新的二進制文件發(fā)送的新數據的數據時，這些新的字段將成為舊的二進制文件中的未知字段窍蓝。

Proto3 實現可以成功解析未知字段的消息腋颠，但是，實現可能會或可能不會支持保留這些未知字段吓笙。你不應該依賴保存或刪除未知域淑玫。對于大多數 Google protocol buffers 實現，未知字段在 proto3 中無法通過相應的 proto 運行時訪問，并且在反序列化時被丟棄和遺忘絮蒿。這是與 proto2 的不同行為尊搬，其中未知字段總是與消息一起保存并序列化。

10. Map 類型

repeated 類型可以用來表示數組土涝，Map 類型則可以用來表示字典佛寿。

map<key_type, value_type> map_field = N;

map<string, Project> projects = 3;

key_type 可以是任何 int 或者 string 類型(任何的標量類型，具體可以見上面標量類型對應表格但壮，但是要除去 float冀泻、double 和 bytes)

枚舉值也不能作為 key。

key_type 可以是除去 map 以外的任何類型茵肃。

需要特別注意的是：

map 是不能用 repeated 修飾的腔长。
線性數組和 map 迭代順序的是不確定的袭祟，所以你不能依靠你的 map 是在一個特定的順序验残。
為 .proto 生成文本格式時，map 按 key 排序巾乳。數字的 key 按數字排序您没。
從數組中解析或合并時，如果有重復的 key胆绊，則使用所看到的最后一個 key（覆蓋原則）氨鹏。從文本格式解析映射時，如果有重復的 key压状，解析可能會失敗仆抵。

Protocol Buffer 雖然不支持 map 類型的數組，但是可以轉換一下种冬，用以下思路實現 maps 數組：

message MapFieldEntry {
  key_type key = 1;
  value_type value = 2;
}

repeated MapFieldEntry map_field = N;

上述寫法和 map 數組是完全等價的镣丑，所以用 repeated 巧妙的實現了 maps 數組的需求。

11. JSON Mapping

Proto3 支持 JSON 中的規(guī)范編碼娱两，使系統(tǒng)之間共享數據變得更加容易莺匠。編碼在下表中按類型逐個描述。

如果 JSON 編碼數據中缺少值或其值為空十兢，則在解析為 protocol buffer 時趣竣，它將被解釋為適當的默認值。如果一個字段在協(xié)議緩沖區(qū)中具有默認值旱物，默認情況下它將在 JSON 編碼數據中省略以節(jié)省空間遥缕。具體 Mapping 的實現可以提供選項決定是否在 JSON 編碼的輸出中發(fā)送具有默認值的字段。

image

proto3 的 JSON 實現中提供了以下 4 中 options:

使用默認值發(fā)送字段：在默認情況下宵呛，默認值的字段在 proto3 JSON 輸出中被忽略单匣。一個實現可以提供一個選項來覆蓋這個行為，并使用它們的默認值輸出字段。
忽略未知字段：默認情況下封孙，Proto3 JSON 解析器應拒絕未知字段迹冤，但可能提供一個選項來忽略解析中的未知字段。
使用 proto 字段名稱而不是 lowerCamelCase 名稱：默認情況下虎忌，proto3 JSON 的 printer 將字段名稱轉換為 lowerCamelCase 并將其用作 JSON 名稱泡徙。實現可能會提供一個選項，將原始字段名稱用作 JSON 名稱膜蠢。 Proto3 JSON 解析器需要接受轉換后的 lowerCamelCase 名稱和原始字段名稱堪藐。
發(fā)送枚舉形式的枚舉值而不是字符串：在 JSON 輸出中默認使用枚舉值的名稱√粑В可以提供一個選項來使用枚舉值的數值礁竞。

四. proto3 定義 Services

如果要使用 RPC（遠程過程調用）系統(tǒng)的消息類型，可以在 .proto 文件中定義 RPC 服務接口杉辙，protocol buffer 編譯器將使用所選語言生成服務接口代碼和 stubs模捂。所以，例如蜘矢，如果你定義一個 RPC 服務狂男，入參是 SearchRequest 返回值是 SearchResponse，你可以在你的 .proto 文件中定義它品腹，如下所示：

service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}

與 protocol buffer 一起使用的最直接的 RPC 系統(tǒng)是 gRPC：在谷歌開發(fā)的語言和平臺中立的開源 RPC 系統(tǒng)岖食。gRPC 在 protocol buffer 中工作得非常好，并且允許你通過使用特殊的 protocol buffer 編譯插件舞吭，直接從 .proto 文件中生成 RPC 相關的代碼泡垃。

如果你不想使用 gRPC，也可以在你自己的 RPC 實現中使用 protocol buffers羡鸥。您可以在 Proto2 語言指南中找到更多關于這些相關的信息蔑穴。

還有一些正在進行的第三方項目為 Protocol Buffers 開發(fā) RPC 實現。

五. Protocol Buffer 命名規(guī)范

message 采用駝峰命名法兄春。message 首字母大寫開頭澎剥。字段名采用下劃線分隔法命名。

message SongServerRequest {
  required string song_name = 1;
}

枚舉類型采用駝峰命名法赶舆。枚舉類型首字母大寫開頭虏劲。每個枚舉值全部大寫镜雨，并且采用下劃線分隔法命名。

enum Foo {
  FIRST_VALUE = 0;
  SECOND_VALUE = 1;
}

每個枚舉值用分號結束，不是逗號悍缠。

服務名和方法名都采用駝峰命名法佛纫。并且首字母都大寫開頭囤官。

service FooService {
  rpc GetSomething(FooRequest) returns (FooResponse);
}

六. Protocol Buffer 編碼原理

在討論 Protocol Buffer 編碼原理之前癣亚，必須先談談 Varints 編碼寺鸥。

Base 128 Varints 編碼

Varint 是一種緊湊的表示數字的方法。它用一個或多個字節(jié)來表示一個數字品山，值越小的數字使用越少的字節(jié)數胆建。這能減少用來表示數字的字節(jié)數。

Varint 中的每個字節(jié)（最后一個字節(jié)除外）都設置了最高有效位（msb）肘交，這一位表示還會有更多字節(jié)出現笆载。每個字節(jié)的低 7 位用于以 7 位組的形式存儲數字的二進制補碼表示，最低有效組首位涯呻。

如果用不到 1 個字節(jié)凉驻，那么最高有效位設為 0 ，如下面這個例子复罐，1 用一個字節(jié)就可以表示涝登，所以 msb 為 0.

0000 0001

如果需要多個字節(jié)表示，msb 就應該設置為 1 效诅。例如 300胀滚，如果用 Varint 表示的話：

1010 1100 0000 0010

如果按照正常的二進制計算的話，這個表示的是 88068(65536 + 16384 + 4096 + 2048 + 4)填帽。

那 Varint 是怎么編碼的呢蛛淋？

下面代碼是 Varint int 32 的編碼計算方法。

char* EncodeVarint32(char* dst, uint32_t v) {
  // Operate on characters as unsigneds
  unsigned char* ptr = reinterpret_cast<unsigned char*>(dst);
  static const int B = 128;
  if (v < (1<<7)) {
    *(ptr++) = v;
  } else if (v < (1<<14)) {
    *(ptr++) = v | B;
    *(ptr++) = v>>7;
  } else if (v < (1<<21)) {
    *(ptr++) = v | B;
    *(ptr++) = (v>>7) | B;
    *(ptr++) = v>>14;
  } else if (v < (1<<28)) {
    *(ptr++) = v | B;
    *(ptr++) = (v>>7) | B;
    *(ptr++) = (v>>14) | B;
    *(ptr++) = v>>21;
  } else {
    *(ptr++) = v | B;
    *(ptr++) = (v>>7) | B;
    *(ptr++) = (v>>14) | B;
    *(ptr++) = (v>>21) | B;
    *(ptr++) = v>>28;
  }
  return reinterpret_cast<char*>(ptr);
}

300 = 100101100

由于 300 超過了 7 位（Varint 一個字節(jié)只有 7 位能用來表示數字篡腌，最高位 msb 用來表示后面是否有更多字節(jié)），所以 300 需要用 2 個字節(jié)來表示勾效。

Varint 的編碼嘹悼，以 300 舉例：

if (v < (1<<14)) {
    *(ptr++) = v | B;
    *(ptr++) = v>>7;
}

1. 100101100 | 10000000 = 1 1010 1100
2. 110101100 取出末尾 7 位 = 010 1100
3. 100101100 >> 7 = 10 = 0000 0010
4. 1010 1100 0000 0010 (最終 Varint 結果)

Varint 的解碼算法應該是這樣的：（實際就是編碼的逆過程）

如果是多個字節(jié)，先去掉每個字節(jié)的 msb（通過邏輯或運算）层宫，每個字節(jié)只留下 7 位杨伙。
逆序整個結果，最多是 5 個字節(jié)萌腿，排序是 1-2-3-4-5限匣，逆序之后就是 5-4-3-2-1，字節(jié)內部的二進制位的順序不變毁菱，變的是字節(jié)的相對位置米死。

解碼過程調用 GetVarint32Ptr 函數，如果是大于一個字節(jié)的情況贮庞，會調用 GetVarint32PtrFallback 來處理峦筒。

inline const char* GetVarint32Ptr(const char* p,
                                  const char* limit,
                                  uint32_t* value) {
  if (p < limit) {
    uint32_t result = *(reinterpret_cast<const unsigned char*>(p));
    if ((result & 128) == 0) {
      *value = result;
      return p + 1;
    }
  }
  return GetVarint32PtrFallback(p, limit, value);
}

const char* GetVarint32PtrFallback(const char* p,
                                   const char* limit,
                                   uint32_t* value) {
  uint32_t result = 0;
  for (uint32_t shift = 0; shift <= 28 && p < limit; shift += 7) {
    uint32_t byte = *(reinterpret_cast<const unsigned char*>(p));
    p++;
    if (byte & 128) {
      // More bytes are present
      result |= ((byte & 127) << shift);
    } else {
      result |= (byte << shift);
      *value = result;
      return reinterpret_cast<const char*>(p);
    }
  }
  return NULL;
}

至此，Varint 處理過程讀者應該都熟悉了窗慎。上面列舉出了 Varint 32 的算法物喷，64 位的同理卤材，只不過不再用 10 個分支來寫代碼了，太丑了峦失。（32位是 5 個字節(jié)扇丛，64位是 10 個字節(jié)）

64 位 Varint 編碼實現：

char* EncodeVarint64(char* dst, uint64_t v) {
  static const int B = 128;
  unsigned char* ptr = reinterpret_cast<unsigned char*>(dst);
  while (v >= B) {
    *(ptr++) = (v & (B-1)) | B;
    v >>= 7;
  }
  *(ptr++) = static_cast<unsigned char>(v);
  return reinterpret_cast<char*>(ptr);
}

原理不變，只不過用循環(huán)來解決了尉辑。

64 位 Varint 解碼實現：

const char* GetVarint64Ptr(const char* p, const char* limit, uint64_t* value) {
  uint64_t result = 0;
  for (uint32_t shift = 0; shift <= 63 && p < limit; shift += 7) {
    uint64_t byte = *(reinterpret_cast<const unsigned char*>(p));
    p++;
    if (byte & 128) {
      // More bytes are present
      result |= ((byte & 127) << shift);
    } else {
      result |= (byte << shift);
      *value = result;
      return reinterpret_cast<const char*>(p);
    }
  }
  return NULL;
}

讀到這里可能有讀者會問了晕拆，Varint 不是為了緊湊 int 的么？那 300 本來可以用 2 個字節(jié)表示材蹬，現在還是 2 個字節(jié)了实幕，哪里緊湊了，花費的空間沒有變暗唐鳌昆庇？！

Varint 確實是一種緊湊的表示數字的方法闸溃。它用一個或多個字節(jié)來表示一個數字整吆，值越小的數字使用越少的字節(jié)數。這能減少用來表示數字的字節(jié)數辉川。比如對于 int32 類型的數字表蝙，一般需要 4 個 byte 來表示。但是采用 Varint乓旗，對于很小的 int32 類型的數字府蛇，則可以用 1 個 byte 來表示。當然凡事都有好的也有不好的一面屿愚，采用 Varint 表示法汇跨，大的數字則需要 5 個 byte 來表示。從統(tǒng)計的角度來說妆距，一般不會所有的消息中的數字都是大數穷遂，因此大多數情況下，采用 Varint 后娱据，可以用更少的字節(jié)數來表示數字信息蚪黑。

300 如果用 int32 表示，需要 4 個字節(jié)中剩，現在用 Varint 表示忌穿，只需要 2 個字節(jié)了⊙拾玻縮小了一半伴网！

1. Message Structure 編碼

protocol buffer 中 message 是一系列鍵值對。message 的二進制版本只是使用字段號(field's number 和 wire_type)作為 key妆棒。每個字段的名稱和聲明類型只能在解碼端通過引用消息類型的定義（即 .proto 文件）來確定澡腾。這一點也是人們常常說的 protocol buffer 比 JSON沸伏，XML 安全一點的原因，如果沒有數據結構描述 .proto 文件动分，拿到數據以后是無法解釋成正常的數據的毅糟。

image

由于采用了 tag-value 的形式，所以 option 的 field 如果有澜公，就存在在這個 message buffer 中姆另，如果沒有，就不會在這里坟乾，這一點也算是壓縮了 message 的大小了迹辐。

當消息編碼時，鍵和值被連接成一個字節(jié)流甚侣。當消息被解碼時明吩，解析器需要能夠跳過它無法識別的字段。這樣殷费，可以將新字段添加到消息中印荔，而不會破壞不知道它們的舊程序。這就是所謂的 “向后”兼容性详羡。

為此仍律，線性的格式消息中每對的“key”實際上是兩個值，其中一個是來自.proto文件的字段編號实柠，加上提供正好足夠的信息來查找下一個值的長度水泉。在大多數語言實現中，這個 key 被稱為 tag主到。

image

注意上圖中茶行，3 和 4 已經被廢棄了，所以 wire_type 取值目前只有 0登钥、1、2娶靡、5牧牢。

key 的計算方法是 (field_number << 3) | wire_type，換句話說姿锭，key 的最后 3 位表示的就是 wire_type塔鳍。

舉例，一般 message 的字段號都是 1 開始的呻此，所以對應的 tag 可能是這樣的：

000 1000

末尾 3 位表示的是 value 的類型轮纫，這里是 000，即 0 焚鲜，代表的是 varint 值掌唾。右移 3 位放前，即 0001，這代表的就是字段號(field number)糯彬。tag 的例子就舉這么多凭语，接下來舉一個 value 的例子，還是用 varint 來舉例：

96 01 = 1001 0110  0000 0001
       → 000 0001  ++  001 0110 (drop the msb and reverse the groups of 7 bits)
       → 10010110
       → 128 + 16 + 4 + 2 = 150

可以 96 01 代表的數據就是 150 撩扒。

message Test1 {
  required int32 a = 1;
}

如果存在上面這樣的一個 message 的結構似扔，如果存入 150，在 Protocol Buffer 中顯示的二進制應該為 08 96 01 搓谆。

額外說一句炒辉，type 需要注意的是 type = 2 的情況，tag 里面除了包含 field number 和 wire_type 泉手，還需要再包含一個 length黔寇，決定 value 從那一段取出來。（具體原因見 Protocol Buffer 字符串這一章節(jié)）

2. Signed Integers 編碼

從上面的表格里面可以看到 wire_type = 0 中包含了無符號的 varints螃诅，但是如果是一個無符號數呢啡氢？

一個負數一般會被表示為一個很大的整數，因為計算機定義負數的符號位為數字的最高位术裸。如果采用 Varint 表示一個負數倘是，那么一定需要 10 個 byte 長度。

為何 32 位和 64 位的負數都需要 10 個 byte 長度呢袭艺？

C
inline void CodedOutputStream::WriteVarint32SignExtended(int32 value) {
 WriteVarint64(static_cast<uint64>(value));
}
因為源碼里面是這么規(guī)定的搀崭。32 位的有符號數都會轉換成 64 位無符號來處理。至于源碼為什么要這么規(guī)定呢猾编，猜想可能是怕 32 位的負數轉換會有溢出的可能瘤睹。(只是猜想)

為此 Google Protocol Buffer 定義了 sint32 這種類型，采用 zigzag 編碼答倡。將所有整數映射成無符號整數轰传，然后再采用 varint 編碼方式編碼，這樣瘪撇，絕對值小的整數获茬，編碼后也會有一個較小的 varint 編碼值。

Zigzag 映射函數為：

Zigzag(n) = (n << 1) ^ (n >> 31), n 為 sint32 時

Zigzag(n) = (n << 1) ^ (n >> 63), n 為 sint64 時

按照這種方法倔既，-1 將會被編碼成 1恕曲，1 將會被編碼成 2，-2 會被編碼成 3渤涌，如下表所示：

image

需要注意的是佩谣，第二個轉換 （n >> 31） 部分，是一個算術轉換实蓬。所以茸俭，換句話說吊履，移位的結果要么是一個全為0（如果n是正數），要么是全部1（如果n是負數）瓣履。

當 sint32 或 sint64 被解析時率翅，它的值被解碼回原始的帶符號的版本。

3. Non-varint Numbers

Non-varint 數字比較簡單袖迎，double 冕臭、fixed64 的 wire_type 為 1，在解析時告訴解析器燕锥，該類型的數據需要一個 64 位大小的數據塊即可辜贵。同理，float 和 fixed32 的 wire_type 為5归形，給其 32 位數據塊即可托慨。兩種情況下，都是高位在后暇榴，低位在前厚棵。

說 Protocol Buffer 壓縮數據沒有到極限，原因就在這里蔼紧，因為并沒有壓縮 float婆硬、double 這些浮點類型。

4. 字符串

image

wire_type 類型為 2 的數據奸例，是一種指定長度的編碼方式：key + length + content彬犯，key 的編碼方式是統(tǒng)一的，length 采用 varints 編碼方式查吊，content 就是由 length 指定長度的 Bytes谐区。

舉例，假設定義如下的 message 格式：

message Test2 {
  optional string b = 2;
}

設置該值為"testing"逻卖，二進制格式查看：

12 07 74 65 73 74 69 6e 67

74 65 73 74 69 6e 67 是“testing”的 UTF8 代碼宋列。

此處，key 是16進制表示的评也，所以展開是：

12 -> 0001 0010虚茶，后三位 010 為 wire type = 2，0001 0010 右移三位為 0000 0010仇参，即 tag = 2。

length 此處為 7婆殿，后邊跟著 7 個bytes诈乒，即我們的字符串"testing"。

所以 wire_type 類型為 2 的數據婆芦，編碼的時候會默認轉換為 T-L-V (Tag - Length - Value)的形式怕磨。

5. 嵌入式 message

假設喂饥，定義如下嵌套消息：

message Test3 {
  optional Test1 c = 3;
}

設置字段為整數150，編碼后的字節(jié)為：

1a 03 08 96 01

08 96 01 這三個代表的是 150肠鲫，上面講解過员帮，這里就不再贅述了。

1a -> 0001 1010导饲，后三位 010 為 wire type = 2捞高，0001 1010 右移三位為 0000 0011，即 tag = 3渣锦。

length 為 3硝岗，代表后面有 3 個字節(jié)，即 08 96 01 袋毙。

需要轉變?yōu)?T - L - V 形式的還有 string, bytes, embedded messages, packed repeated fields （即 wire_type 為 2 的形式都會轉變成 T - L - V 形式）

6. Optional 和 Repeated 的編碼

在 proto2 中定義成 repeated 的字段型檀，（沒有加上 [packed=true] option ），編碼后的 message 有一個或者多個包含相同 tag 數字的 key-value 對听盖。這些重復的 value 不需要連續(xù)的出現胀溺；他們可能與其他的字段間隔的出現。盡管他們是無序的皆看，但是在解析時仓坞，他們是需要有序的。在 proto3 中 repeated 字段默認采用 packed 編碼（具體原因見 Packed Repeated Fields 這一章節(jié)）

對于 proto3 中的任何非重復字段或 proto2 中的可選字段悬蔽，編碼的 message 可能有也可能沒有包含該字段號的鍵值對扯躺。

通常，編碼后的 message蝎困，其 required 字段和 optional 字段最多只有一個實例录语。但是解析器卻需要處理多對一的情況。對于數字類型和 string 類型禾乘，如果同一值出現多次澎埠，解析器接受最后一個它收到的值。對于內嵌字段始藕，解析器合并(merge)它接收到的同一字段的多個實例蒲稳。就如 MergeFrom 方法一樣，所有單數的字段伍派，后來的會替換先前的江耀，所有單數的內嵌 message 都會被合并(merge)，所有的 repeated 字段诉植，都會串聯(lián)起來祥国。這樣的規(guī)則的結果是，解析兩個串聯(lián)的編碼后的 message，與分別解析兩個 message 然后 merge舌稀，結果是一樣的啊犬。例如：

MyMessage message;
message.ParseFromString(str1 + str2);

等價于

MyMessage message, message2;
message.ParseFromString(str1);
message2.ParseFromString(str2);
message.MergeFrom(message2);

這種方法有時是非常有用的。比如壁查，即使不知道 message 的類型觉至，也能夠將其合并。

7. Packed Repeated Fields

在 2.1.0 版本以后睡腿，protocol buffers 引入了該種類型语御，其與 repeated 字段一樣，只是在末尾聲明了 [packed=true]嫉到。類似 repeated 字段卻又不同沃暗。在 proto3 中 Repeated 字段默認就是以這種方式處理。對于 packed repeated 字段何恶，如果 message 中沒有賦值孽锥，則不會出現在編碼后的數據中。否則的話细层，該字段所有的元素會被打包到單一一個 key-value 對中惜辑，且它的 wire_type=2，長度確定疫赎。每個元素正常編碼盛撑，只不過其前沒有標簽 tag。例如有如下 message 類型：

message Test4 {
  repeated int32 d = 4 [packed=true];
}

構造一個 Test4 字段捧搞，并且設置 repeated 字段 d 3個值：3抵卫，270和86942，編碼后：

22 // tag 0010 0010(field number 010 0 = 4, wire type 010 = 2)

06 // payload size (設置的length = 6 bytes)

03 // first element (varint 3)

8E 02 // second element (varint 270)

9E A7 05 // third element (varint 86942)

形成了 Tag - Length - Value - Value - Value …… 對胎撇。

只有原始數字類型（使用varint介粘，32位或64位）的重復字段才可以聲明為“packed”。

有一點需要注意晚树，對于 packed 的 repeated 字段姻采，盡管通常沒有理由將其編碼為多個 key-value 對，編碼器必須有接收多個 key-pair 對的準備爵憎。這種情況下慨亲，payload 必須是串聯(lián)的，每個 pair 必須包含完整的元素宝鼓。

Protocol Buffer 解析器必須能夠解析被重新編譯為 packed 的字段刑棵，就像它們未被 packed 一樣，反之亦然愚铡。這允許以正向和反向兼容的方式將[packed = true]添加到現有字段铐望。

8. Field Order

編碼/解碼與字段順序無關，這一點由 key-value 機制保證。

如果消息具有未知字段正蛙，則當前的 Java 和 C++ 實現在按順序排序的已知字段之后以任意順序寫入它們。當前的 Python 實現不會跟蹤未知字段营曼。

七. protocol buffers 的優(yōu)缺點

image

protocol buffers 在序列化方面乒验，與 XML 相比，有諸多優(yōu)點：

更加簡單
數據體積小 3- 10 倍
更快的反序列化速度蒂阱，提高 20 - 100 倍
可以自動化生成更易于編碼方式使用的數據訪問類

舉個例子：

如果要編碼一個用戶的名字和 email 信息锻全，用 XML 的方式如下：

Xml

  <person>
    <name>John Doe</name>
    <email>jdoe@example.com</email>
  </person>

相同需求，如果換成 protocol buffers 來實現录煤，定義文件如下：

# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
  name: "John Doe"
  email: "jdoe@example.com"
}

protocol buffers 通過編碼以后鳄厌，以二進制的方式進行數據傳輸，最多只需要 28 bytes 空間和 100-200 ns 的反序列化時間妈踊。但是 XML 則至少需要 69 bytes 空間（經過壓縮以后了嚎，去掉所有空格）和 5000-10000 的反序列化時間。

上面說的是性能方面的優(yōu)勢廊营。接下來說說編碼方面的優(yōu)勢歪泳。

protocol buffers 自帶代碼生成工具，可以生成友好的數據訪問存儲接口露筒。從而開發(fā)人員使用它來編碼更加方便呐伞。例如上面的例子，如果用 C++ 的方式去讀取用戶的名字和 email慎式，直接調用對應的 get 方法即可（所有屬性的 get 和 set 方法的代碼都自動生成好了伶氢，只需要調用即可）

  cout << "Name: " << person.name() << endl;
  cout << "E-mail: " << person.email() << endl;

而 XML 讀取數據會麻煩一些：

Xml

  cout << "Name: "
       << person.getElementsByTagName("name")->item(0)->innerText()
       << endl;
  cout << "E-mail: "
       << person.getElementsByTagName("email")->item(0)->innerText()
       << endl;

Protobuf 語義更清晰，無需類似 XML 解析器的東西（因為 Protobuf 編譯器會將 .proto 文件編譯生成對應的數據訪問類以對 Protobuf 數據進行序列化瘪吏、反序列化操作）癣防。

使用 Protobuf 無需學習復雜的文檔對象模型，Protobuf 的編程模式比較友好肪虎，簡單易學劣砍，同時它擁有良好的文檔和示例，對于喜歡簡單事物的人們而言扇救，Protobuf 比其他的技術更加有吸引力刑枝。

protocol buffers 最后一個非常棒的特性是，即“向后”兼容性好迅腔，人們不必破壞已部署的装畅、依靠“老”數據格式的程序就可以對數據結構進行升級。這樣您的程序就可以不必擔心因為消息結構的改變而造成的大規(guī)模的代碼重構或者遷移的問題沧烈。因為添加新的消息中的 field 并不會引起已經發(fā)布的程序的任何改變(因為存儲方式本來就是無序的掠兄，k-v 形式)。

當然 protocol buffers 也并不是完美的，在使用上存在一些局限性蚂夕。

由于文本并不適合用來描述數據結構迅诬，所以 Protobuf 也不適合用來對基于文本的標記文檔（如 HTML）建模。另外婿牍，由于 XML 具有某種程度上的自解釋性侈贷，它可以被人直接讀取編輯，在這一點上 Protobuf 不行等脂，它以二進制的方式存儲俏蛮，除非你有 .proto 定義，否則你沒法直接讀出 Protobuf 的任何內容上遥。

八. 最后

讀完本篇 Protocol Buffer 編碼原理以后搏屑，讀者應該能明白以下幾點：

Protocol Buffer 利用 varint 原理壓縮數據以后，二進制數據非常緊湊粉楚，option 也算是壓縮體積的一個舉措辣恋。所以 pb 體積更小，如果選用它作為網絡數據傳輸解幼，勢必相同數據抑党，消耗的網絡流量更少。但是并沒有壓縮到極限撵摆，float底靠、double 浮點型都沒有壓縮。
Protocol Buffer 比 JSON 和 XML 少了 {特铝、}暑中、: 這些符號，體積也減少一些鲫剿。再加上 varint 壓縮鳄逾，gzip 壓縮以后體積更小灵莲！
Protocol Buffer 是 Tag - Value (Tag - Length - Value)的編碼方式的實現雕凹，減少了分隔符的使用，數據存儲更加緊湊政冻。
Protocol Buffer 另外一個核心價值在于提供了一套工具枚抵，一個編譯工具，自動化生成 get/set 代碼明场。簡化了多語言交互的復雜度汽摹，使得編碼解碼工作有了生產力。
Protocol Buffer 不是自我描述的苦锨，離開了數據描述 .proto 文件逼泣，就無法理解二進制數據流趴泌。這點即是優(yōu)點，使數據具有一定的“加密性”拉庶，也是缺點嗜憔，數據可讀性極差。所以 Protocol Buffer 非常適合內部服務之間 RPC 調用和傳遞數據砍的。
Protocol Buffer 具有向后兼容的特性痹筛，更新數據結構以后，老版本依舊可以兼容廓鞠，這也是 Protocol Buffer 誕生之初被寄予解決的問題。因為編譯器對不識別的新增字段會跳過不處理谣旁。

Protocol Buffer 編碼原理篇到此結束床佳，下篇來講講 Protocol Buffer 反序列化解包性能快的原因。

正文我出身青樓缭贡，卻偏偏與公主長得像，于是被迫代替她去往敵國和親破衔。傳聞我的和親對象是個殘疾皇子羡榴，可洞房花燭夜當晚...