一. protocol buffers 是什么?

Protocol buffers 是一種語言中立，平臺無關(guān)，可擴展的序列化數(shù)據(jù)的格式，可用于通信協(xié)議，數(shù)據(jù)存儲等。

Protocol buffers 在序列化數(shù)據(jù)方面，它是靈活的，高效的。相比于 XML 來說，Protocol buffers 更加小巧，更加快速，更加簡單。一旦定義了要處理的數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)之后，就可以利用 Protocol buffers 的代碼生成工具生成相關(guān)的代碼。甚至可以在無需重新部署程序的情況下更新數(shù)據(jù)結(jié)構(gòu)。只需使用 Protobuf 對數(shù)據(jù)結(jié)構(gòu)進(jìn)行一次描述，即可利用各種不同語言或從各種不同數(shù)據(jù)流中對你的結(jié)構(gòu)化數(shù)據(jù)輕松讀寫。

Protocol buffers 很適合做數(shù)據(jù)存儲或 RPC 數(shù)據(jù)交換格式?？捎糜谕ㄓ崊f(xié)議、數(shù)據(jù)存儲等領(lǐng)域的語言無關(guān)、平臺無關(guān)、可擴展的序列化結(jié)構(gòu)數(shù)據(jù)格式 。

二. 為什么要發(fā)明 protocol buffers ?

 

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

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

 

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

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

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

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

• 可以很容易地引入新的字段，并且不需要檢查數(shù)據(jù)的中間服務(wù)器可以簡單地解析并傳遞數(shù)據(jù)，而無需了解所有字段。
• 數(shù)據(jù)格式更加具有自我描述性，可以用各種語言來處理(C++, Java 等各種語言)
• 這個版本的 protocol buffers 仍需要自己手寫解析的代碼。
• 不過隨著系統(tǒng)慢慢發(fā)展，演進(jìn)，protocol buffers 目前具有了更多的特性：
• 自動生成的序列化和反序列化代碼避免了手動解析的需要。(官方提供自動生成代碼工具，各個語言平臺的基本都有)
• 除了用于 RPC(遠(yuǎn)程過程調(diào)用)請求之外，人們開始將 protocol buffers 用作持久存儲數(shù)據(jù)的便捷自描述格式(例如，在Bigtable中)。
• 服務(wù)器的 RPC 接口可以先聲明為協(xié)議的一部分，然后用 protocol compiler 生成基類，用戶可以使用服務(wù)器接口的實際實現(xiàn)來覆蓋它們。

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

小結(jié)：

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

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 編譯器為我們生成類之前。當(dāng)時，有一個名為 ProtocolBuffer 的類，它實際上充當(dāng)了單個方法的緩沖區(qū)。用戶可以通過調(diào)用像 AddValue(tag,value) 這樣的方法分別將標(biāo)簽/值對添加到此緩沖區(qū)。原始字節(jié)存儲在一個緩沖區(qū)中，一旦構(gòu)建消息就可以將其寫出。

從那時起，名為“緩沖”的部分已經(jīng)失去了意義，但它仍然是我們使用的名稱。今天，人們通常使用術(shù)語“protocol message”來指代抽象意義上的消息，“protocol buffer”指的是消息的序列化副本，而“protocol message object”指的是代表內(nèi)存中對象解析的消息。

三. proto3 定義 message

 

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

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

在 proto 中，所有結(jié)構(gòu)化的數(shù)據(jù)都被稱為 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";，則默認(rèn)使用 proto2 進(jìn)行解析。

1. 分配字段編號

每個消息定義中的每個字段都有 唯一的編號 。這些字段編號用于標(biāo)識消息二進(jìn)制格式中的字段，并且在使用消息類型后不應(yīng)更改。請注意，范圍 1 到 15 中的字段編號需要一個字節(jié)進(jìn)行編碼，包括字段編號和字段類型(具體原因見 Protocol Buffer 編碼原理 這一章節(jié))。范圍 16 至 2047 中的字段編號需要兩個字節(jié)。所以你應(yīng)該保留數(shù)字 1 到 15 作為非常頻繁出現(xiàn)的消息元素。請記住為將來可能添加的頻繁出現(xiàn)的元素留出一些空間。

可以指定的最小字段編號為1，***字段編號為2^29^-1 或 536,870,911。也不能使用數(shù)字 19000 到 19999(FieldDescriptor :: kFirstReservedNumber 到 FieldDescriptor :: kLastReservedNumber)，因為它們是為 Protocol Buffers實現(xiàn)保留的。

如果在 .proto 中使用這些保留數(shù)字中的一個，Protocol Buffers 編譯的時候會報錯。

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

2. 保留字段

如果您通過完全刪除某個字段或?qū)⑵渥⑨尩魜砀孪㈩愋停敲次磥淼挠脩艨梢栽趯υ擃愋瓦M(jìn)行自己的更新時重新使用該字段號。如果稍后加載到了的舊版本 .proto 文件，則會導(dǎo)致服務(wù)器出現(xiàn)嚴(yán)重問題，例如數(shù)據(jù)混亂，隱私錯誤等等。確保這種情況不會發(fā)生的一種方法是指定刪除字段的字段編號(或名稱，這也可能會導(dǎo)致 JSON 序列化問題)為 reserved。如果將來的任何用戶試圖使用這些字段標(biāo)識符，Protocol Buffers 編譯器將會報錯。

 

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

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

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

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

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

4. 各個語言標(biāo)量類型對應(yīng)關(guān)系

 

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 的是作為零值，當(dāng)不賦值的時候，就會是零值。

為了和 proto2 兼容。在 proto2 中，零值必須是***個值。

另外在反序列化的過程中，無法被識別的枚舉值，將會被保留在 messaage 中。因為消息反序列化時如何表示是依賴于語言的。在支持指定符號范圍之外的值的開放枚舉類型的語言中，例如 C++ 和 Go，未知的枚舉值只是存儲為其基礎(chǔ)整數(shù)表示。在諸如 Java 之類的封閉枚舉類型的語言中，枚舉值會被用來標(biāo)識未識別的值，并且特殊的訪問器可以訪問到底層整數(shù)。

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

5. 枚舉中的保留值

如果您通過完全刪除枚舉條目或?qū)⑵渥⑨尩魜砀旅杜e類型，未來的用戶可以在對該類型進(jìn)行自己的更新時重新使用數(shù)值。如果稍后加載到了的舊版本 .proto 文件，則會導(dǎo)致服務(wù)器出現(xiàn)嚴(yán)重問題，例如數(shù)據(jù)混亂，隱私錯誤等等。確保這種情況不會發(fā)生的一種方法是指定已刪除條目的數(shù)字值(或名稱，這也可能會導(dǎo)致JSON序列化問題)為 reserved。如果將來的任何用戶試圖使用這些字段標(biāo)識符，Protocol Buffers 編譯器將會報錯。您可以使用 max 關(guān)鍵字指定您的保留數(shù)值范圍上升到***可能值。

 

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

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

6. 允許嵌套

Protocol Buffers 定義 message 允許嵌套組合成更加復(fù)雜的消息。

 

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. 枚舉不兼容性

可以導(dǎo)入 proto2 消息類型并在 proto3 消息中使用它們，反之亦然。然而，proto2 枚舉不能直接用在 proto3 語法中(但是如果導(dǎo)入的proto2消息使用它們，這是可以的)。

8. 更新 message

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

1. 不要改動原有字段的數(shù)據(jù)結(jié)構(gòu)。
2. 如果您添加新字段，則任何由代碼使用“舊”消息格式序列化的消息仍然可以通過新生成的代碼進(jìn)行分析。您應(yīng)該記住這些元素的默認(rèn)值，以便新代碼可以正確地與舊代碼生成的消息進(jìn)行交互。同樣，由新代碼創(chuàng)建的消息可以由舊代碼解析：舊的二進(jìn)制文件在解析時會簡單地忽略新字段。(具體原因見 未知字段 這一章節(jié))
3. 只要字段號在更新的消息類型中不再使用，字段可以被刪除。您可能需要重命名該字段，可能會添加前綴“OBSOLETE_”，或者標(biāo)記成保留字段號 reserved，以便將來的 .proto 用戶不會意外重復(fù)使用該號碼。
4. int32，uint32，int64，uint64 和 bool 全都兼容。這意味著您可以將字段從這些類型之一更改為另一個字段而不破壞向前或向后兼容性。如果一個數(shù)字從不適合相應(yīng)類型的線路中解析出來，則會得到與在 C++ 中將該數(shù)字轉(zhuǎn)換為該類型相同的效果(例如，如果將 64 位數(shù)字讀為 int32，它將被截斷為 32 位)。
5. sint32 和 sint64 相互兼容，但與其他整數(shù)類型不兼容。
6. 只要字節(jié)是有效的UTF-8，string 和 bytes 是兼容的。
7. 嵌入式 message 與 bytes 兼容，如果 bytes 包含 message 的 encoded version。
8. fixed32與sfixed32兼容，而fixed64與sfixed64兼容。
9. enum 就數(shù)組而言，是可以與 int32，uint32，int64 和 uint64 兼容(請注意，如果它們不適合，值將被截斷)。但是請注意，當(dāng)消息反序列化時，客戶端代碼可能會以不同的方式對待它們：例如，未識別的 proto3 枚舉類型將保留在消息中，但消息反序列化時如何表示是與語言相關(guān)的。(這點和語言相關(guān)，上面提到過了)Int 域始終只保留它們的值。
10. 將單個 值 更改為新的成員是安全和二進(jìn)制兼容的。如果您確定一次沒有代碼設(shè)置多個 字段 ，則將多個字段移至新的字段可能是安全的。將任何 字段 移到現(xiàn)有字段中都是不安全的。(注意字段和值的區(qū)別，字段是 field，值是 value)

9. 未知字段

未知數(shù)字段是 protocol buffers 序列化的數(shù)據(jù)，表示解析器無法識別的字段。例如，當(dāng)一個舊的二進(jìn)制文件解析由新的二進(jìn)制文件發(fā)送的新數(shù)據(jù)的數(shù)據(jù)時，這些新的字段將成為舊的二進(jìn)制文件中的未知字段。

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

10. Map 類型

repeated 類型可以用來表示數(shù)組，Map 類型則可以用來表示字典。

 

map  
map_field = N;  
map  
projects = 3; 

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

枚舉值也不能作為 key 。

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

需要特別注意的是 ：

• map 是不能用 repeated 修飾的。
• 線性數(shù)組和 map 迭代順序的是不確定的，所以你不能依靠你的 map 是在一個特定的順序。
• 為 .proto 生成文本格式時，map 按 key 排序。數(shù)字的 key 按數(shù)字排序。
• 從數(shù)組中解析或合并時，如果有重復(fù)的 key，則使用所看到的***一個 key(覆蓋原則)。從文本格式解析映射時，如果有重復(fù)的 key，解析可能會失敗。

Protocol Buffer 雖然不支持 map 類型的數(shù)組，但是可以轉(zhuǎn)換一下，用以下思路實現(xiàn) maps 數(shù)組：

 

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

上述寫法和 map 數(shù)組是完全等價的，所以用 repeated 巧妙的實現(xiàn)了 maps 數(shù)組的需求。

11. JSON Mapping

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

如果 JSON 編碼數(shù)據(jù)中缺少值或其值為空，則在解析為 protocol buffer 時，它將被解釋為適當(dāng)?shù)哪J(rèn)值。如果一個字段在協(xié)議緩沖區(qū)中具有默認(rèn)值，默認(rèn)情況下它將在 JSON 編碼數(shù)據(jù)中省略以節(jié)省空間。具體 Mapping 的實現(xiàn)可以提供選項決定是否在 JSON 編碼的輸出中發(fā)送具有默認(rèn)值的字段。

 

proto3 的 JSON 實現(xiàn)中提供了以下 4 中 options:

• 使用默認(rèn)值發(fā)送字段：在默認(rèn)情況下，默認(rèn)值的字段在 proto3 JSON 輸出中被忽略。一個實現(xiàn)可以提供一個選項來覆蓋這個行為，并使用它們的默認(rèn)值輸出字段。
• 忽略未知字段：默認(rèn)情況下，Proto3 JSON 解析器應(yīng)拒絕未知字段，但可能提供一個選項來忽略解析中的未知字段。
• 使用 proto 字段名稱而不是 lowerCamelCase 名稱：默認(rèn)情況下，proto3 JSON 的 printer 將字段名稱轉(zhuǎn)換為 lowerCamelCase 并將其用作 JSON 名稱。實現(xiàn)可能會提供一個選項，將原始字段名稱用作 JSON 名稱。 Proto3 JSON 解析器需要接受轉(zhuǎn)換后的 lowerCamelCase 名稱和原始字段名稱。
• 發(fā)送枚舉形式的枚舉值而不是字符串：在 JSON 輸出中默認(rèn)使用枚舉值的名稱。可以提供一個選項來使用枚舉值的數(shù)值。

四. proto3 定義 Services

如果要使用 RPC(遠(yuǎn)程過程調(diào)用)系統(tǒng)的消息類型，可以在 .proto 文件中定義 RPC 服務(wù)接口，protocol buffer 編譯器將使用所選語言生成服務(wù)接口代碼和 stubs。所以，例如，如果你定義一個 RPC 服務(wù)，入?yún)⑹?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 相關(guān)的代碼。

如果你不想使用 gRPC，也可以在你自己的 RPC 實現(xiàn)中使用 protocol buffers。您可以在 Proto2 語言指南中找到更多關(guān)于這些相關(guān)的信息。

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

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

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

 

message SongServerRequest { required string song_name = 1; 
} 

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

 

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

每個枚舉值用分號結(jié)束，不是逗號 。

服務(wù)名和方法名都采用駝峰命名法。并且首字母都大寫開頭。

 

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

六. Protocol Buffer 編碼原理

在討論 Protocol Buffer 編碼原理之前，必須先談?wù)?Varints 編碼。

Base 128 Varints 編碼

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

Varint 中的每個字節(jié)(***一個字節(jié)除外)都設(shè)置了***有效位(msb)，這一位表示還會有更多字節(jié)出現(xiàn)。每個字節(jié)的低 7 位用于以 7 位組的形式存儲數(shù)字的二進(jìn)制補碼表示，***有效組首位。

如果用不到 1 個字節(jié)，那么***有效位設(shè)為 0 ，如下面這個例子，1 用一個字節(jié)就可以表示，所以 msb 為 0.

如果需要多個字節(jié)表示，msb 就應(yīng)該設(shè)置為 1 。例如 300，如果用 Varint 表示的話：

如果按照正常的二進(jìn)制計算的話，這個表示的是 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  
(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  
(ptr);  
}  
300 = 100101100 

由于 300 超過了 7 位(Varint 一個字節(jié)只有 7 位能用來表示數(shù)字，***位 msb 用來表示后面是否有更多字節(jié))，所以 300 需要用 2 個字節(jié)來表示。

Varint 的編碼，以 300 舉例：

100101100 | 10000000 = 1 1010 1100 2. 110101100 >> 7 = 1010 1100 3. 100101100 >> 7 = 10 = 0000 0010 4. 1010 1100 0000 0010 (最終 Varint 結(jié)果) 

Varint 的解碼算法應(yīng)該是這樣的：(實際就是編碼的逆過程)

如果是多個字節(jié)，先去掉每個字節(jié)的 msb(通過邏輯或運算)，每個字節(jié)只留下 7 位。

逆序整個結(jié)果，最多是 5 個字節(jié)，排序是 1-2-3-4-5，逆序之后就是 5-4-3-2-1，字節(jié)內(nèi)部的二進(jìn)制位的順序不變，變的是字節(jié)的相對位置。

解碼過程調(diào)用 GetVarint32Ptr 函數(shù)，如果是大于一個字節(jié)的情況，會調(diào)用 GetVarint32PtrFallback 來處理。

 

inline const char* GetVarint32Ptr(const char* p, const char* limit, uint32_t* value) { if (p < limit) { uint32_t result = *(reinterpret_cast  
(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 
(p));  
p++; if (byte & 128) { // More bytes are present result |= ((byte & 127) << shift);  
} else {  
result |= (byte << shift);  
*value = result; return reinterpret_cast  
(p);  
}  
} return NULL;  
} 

至此，Varint 處理過程讀者應(yīng)該都熟悉了。上面列舉出了 Varint 32 的算法，64 位的同理，只不過不再用 10 個分支來寫代碼了，太丑了。(32位 是 5 個 字節(jié)，64位 是 10 個字節(jié))

64 位 Varint 編碼實現(xiàn)：

 

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

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

64 位 Varint 解碼實現(xiàn)：

 

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  
  (p));       
    p++; if (byte & 128) { // More bytes are present result |= ((byte & 127) << shift); 
    } else { 
      result |= (byte << shift); 
      *value = result; return reinterpret_cast 
   (p); 
    }       
  } return NULL;     
} 

讀到這里可能有讀者會問了，Varint 不是為了緊湊 int 的么?那 300 本來可以用一個字節(jié)表示，現(xiàn)在變成 2 個字節(jié)了，哪里緊湊了，花費的空間反而變多了?!

Varint 確實是一種緊湊的表示數(shù)字的方法。它用一個或多個字節(jié)來表示一個數(shù)字，值越小的數(shù)字使用越少的字節(jié)數(shù)。這能減少用來表示數(shù)字的字節(jié)數(shù)。比如對于 int32 類型的數(shù)字，一般需要 4 個 byte 來表示。但是采用 Varint，對于很小的 int32 類型的數(shù)字，則可以用 1 個 byte 來表示。當(dāng)然凡事都有好的也有不好的一面，采用 Varint 表示法，大的數(shù)字則需要 5 個 byte 來表示。從統(tǒng)計的角度來說，一般不會所有的消息中的數(shù)字都是大數(shù)，因此大多數(shù)情況下，采用 Varint 后，可以用更少的字節(jié)數(shù)來表示數(shù)字信息。

300 如果用 int32 表示，需要 4 個字節(jié)，現(xiàn)在用 Varint 表示，只需要 2 個字節(jié)了。縮小了一半!

1. Message Structure 編碼

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

 

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

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

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

 

注意上圖中，3 和 4 已經(jīng)被廢棄了，所以 wire_type 取值目前只有 0、1、2、5 。

key 的計算方法是 (field_number<<3) | wire_type，換句話說，key 的*** 3 位表示的就是 wire_type。

舉例，一般 message 的字段號都是 1 開始的，所以對應(yīng)的 tag 可能是這樣的：

末尾 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 代表的數(shù)據(jù)就是 150 。

 

message Test1 { required int32 a = 1; 
} 

如果存在上面這樣的一個 message 的結(jié)構(gòu)，如果存入 150，在 Protocol Buffer 中顯示的二進(jìn)制應(yīng)該為 08 96 01 。

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

2. Signed Integers 編碼

從上面的表格里面可以看到 wire_type = 0 中包含了無符號的 varints，但是如果是一個無符號數(shù)呢?

一個負(fù)數(shù)一般會被表示為一個很大的整數(shù)，因為計算機定義負(fù)數(shù)的符號位為數(shù)字的***位。如果采用 Varint 表示一個負(fù)數(shù)，那么一定需要 10 個 byte 長度。為此 Google Protocol Buffer 定義了 sint32 這種類型，采用 zigzag 編碼。 將所有整數(shù)映射成無符號整數(shù)，然后再采用 varint 編碼方式編碼 ，這樣，絕對值小的整數(shù)，編碼后也會有一個較小的 varint 編碼值。

Zigzag 映射函數(shù)為：

 

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

按照這種方法，-1 將會被編碼成 1，1 將會被編碼成 2，-2 會被編碼成 3，如下表所示：

 

需要注意的是，第二個轉(zhuǎn)換 (n >> 31) 部分，是一個算術(shù)轉(zhuǎn)換。所以，換句話說，移位的結(jié)果要么是一個全為0(如果n是正數(shù))，要么是全部1(如果n是負(fù)數(shù))。

當(dāng) sint32 或 sint64 被解析時，它的值被解碼回原始的帶符號的版本。

3. Non-varint Numbers

Non-varint 數(shù)字比較簡單，double 、fixed64 的 wire_type 為 1，在解析時告訴解析器，該類型的數(shù)據(jù)需要一個 64 位大小的數(shù)據(jù)塊即可。同理，float 和 fixed32 的 wire_type 為5，給其 32 位數(shù)據(jù)塊即可。兩種情況下，都是高位在后，低位在前。

說 Protocol Buffer 壓縮數(shù)據(jù)沒有到極限，原因就在這里，因為并沒有壓縮 float、double 這些浮點類型 。

4. 字符串

 

wire_type 類型為 2 的數(shù)據(jù)，是一種指定長度的編碼方式：key + length + content，key 的編碼方式是統(tǒng)一的，length 采用 varints 編碼方式，content 就是由 length 指定長度的 Bytes。

舉例，假設(shè)定義如下的 message 格式：

 

message Test2 { optional string b = 2; 
} 

設(shè)置該值為"testing"，二進(jìn)制格式查看：

12 07 74 65 73 74 69 6e 67 

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

此處，key 是16進(jìn)制表示的，所以展開是：

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

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

所以 wire_type 類型為 2 的數(shù)據(jù)，編碼的時候會默認(rèn)轉(zhuǎn)換為 T-L-V (Tag - Length - Value)的形式 。

5. 嵌入式 message

假設(shè)，定義如下嵌套消息：

 

message Test3 { 
  optional Test1 c = 3; 
} 

設(shè)置字段為整數(shù)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 。

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

6. Optional 和 Repeated 的編碼

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

對于 proto3 中的任何非重復(fù)字段或 proto2 中的可選字段，編碼的 message 可能有也可能沒有包含該字段號的鍵值對。

通常，編碼后的 message，其 required 字段和 optional 字段最多只有一個實例。但是解析器卻需要處理多對一的情況。對于數(shù)字類型和 string 類型，如果同一值出現(xiàn)多次，解析器接受***一個它收到的值。對于內(nèi)嵌字段，解析器合并(merge)它接收到的同一字段的多個實例。就如 MergeFrom 方法一樣，所有單數(shù)的字段，后來的會替換先前的，所有單數(shù)的內(nèi)嵌 message 都會被合并(merge)，所有的 repeated 字段，都會串聯(lián)起來。這樣的規(guī)則的結(jié)果是， 解析兩個串聯(lián)的編碼后的 message，與分別解析兩個 message 然后 merge，結(jié)果是一樣的 。例如：

 

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

等價于

 

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

這種方法有時是非常有用的。比如，即使不知道 message 的類型，也能夠?qū)⑵浜喜ⅰ?/p>

7. Packed Repeated Fields

在 2.1.0 版本以后，protocol buffers 引入了該種類型，其與 repeated 字段一樣，只是在末尾聲明了 [packed=true]。類似 repeated 字段卻又不同。在 proto3 中 Repeated 字段默認(rèn)就是以這種方式處理。對于 packed repeated 字段，如果 message 中沒有賦值，則不會出現(xiàn)在編碼后的數(shù)據(jù)中。否則的話，該字段所有的元素會被打包到單一一個 key-value 對中，且它的 wire_type=2，長度確定。每個元素正常編碼，只不過其前沒有標(biāo)簽 tag。例如有如下 message 類型：

 

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

構(gòu)造一個 Test4 字段，并且設(shè)置 repeated 字段 d 3個值：3，270和86942，編碼后：

22 // tag 0010 0010(field number 010 0 = 4, wire type 010 = 2) 06 // payload size (設(shè)置的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 …… 對 。

只有原始數(shù)字類型(使用varint，32位或64位)的重復(fù)字段才可以聲明為“packed”。

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

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

8. Field Order

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

如果消息具有未知字段，則當(dāng)前的 Java 和 C++ 實現(xiàn)在按順序排序的已知字段之后以任意順序?qū)懭胨鼈?。?dāng)前的 Python 實現(xiàn)不會跟蹤未知字段。

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

 

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

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

舉個例子：

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

 

John Doe  
jdoe@example.com 

相同需求，如果換成 protocol buffers 來實現(xiàn)，定義文件如下：

 

# 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 通過編碼以后，以二進(jìn)制的方式進(jìn)行數(shù)據(jù)傳輸，最多只需要 28 bytes 空間和 100-200 ns 的反序列化時間。但是 XML 則至少需要 69 bytes 空間(經(jīng)過壓縮以后，去掉所有空格)和 5000-10000 的反序列化時間。

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

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

 

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

而 XML 讀取數(shù)據(jù)會麻煩一些：

 

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

Protobuf 語義更清晰，無需類似 XML 解析器的東西(因為 Protobuf 編譯器會將 .proto 文件編譯生成對應(yīng)的數(shù)據(jù)訪問類以對 Protobuf 數(shù)據(jù)進(jìn)行序列化、反序列化操作)。

使用 Protobuf 無需學(xué)習(xí)復(fù)雜的文檔對象模型，Protobuf 的編程模式比較友好，簡單易學(xué)，同時它擁有良好的文檔和示例，對于喜歡簡單事物的人們而言，Protobuf 比其他的技術(shù)更加有吸引力。

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

當(dāng)然 protocol buffers 也并不是***的，在使用上存在一些局限性。

由于文本并不適合用來描述數(shù)據(jù)結(jié)構(gòu)，所以 Protobuf 也不適合用來對基于文本的標(biāo)記文檔(如 HTML)建模。另外，由于 XML 具有某種程度上的自解釋性，它可以被人直接讀取編輯，在這一點上 Protobuf 不行，它以二進(jìn)制的方式存儲，除非你有 .proto 定義，否則你沒法直接讀出 Protobuf 的任何內(nèi)容。

八. ***

讀完本篇 Protocol Buffer 編碼原理以后，讀者應(yīng)該能明白以下幾點：

• Protocol Buffer 利用 varint 原理壓縮數(shù)據(jù)以后，二進(jìn)制數(shù)據(jù)非常緊湊，option 也算是壓縮體積的一個舉措。所以 pb 體積更小，如果選用它作為網(wǎng)絡(luò)數(shù)據(jù)傳輸，勢必相同數(shù)據(jù)，消耗的網(wǎng)絡(luò)流量更少。但是并沒有壓縮到極限，float、double 浮點型都沒有壓縮。
• Protocol Buffer 比 JSON 和 XML 少了 {、}、: 這些符號，體積也減少一些。再加上 varint 壓縮，gzip 壓縮以后體積更小!
• Protocol Buffer 是 Tag - Value (Tag - Length - Value)的編碼方式的實現(xiàn)，減少了分隔符的使用，數(shù)據(jù)存儲更加緊湊。
• Protocol Buffer 另外一個核心價值在于提供了一套工具，一個編譯工具，自動化生成 get/set 代碼。簡化了多語言交互的復(fù)雜度，使得編碼解碼工作有了生產(chǎn)力。
• Protocol Buffer 不是自我描述的，離開了數(shù)據(jù)描述 .proto 文件，就無法理解二進(jìn)制數(shù)據(jù)流。這點即是優(yōu)點，使數(shù)據(jù)具有一定的“加密性”，也是缺點，數(shù)據(jù)可讀性極差。所以 Protocol Buffer 非常適合內(nèi)部服務(wù)之間 RPC 調(diào)用和傳遞數(shù)據(jù)。
• Protocol Buffer 具有向后兼容的特性，更新數(shù)據(jù)結(jié)構(gòu)以后，老版本依舊可以兼容，這也是 Protocol Buffer 誕生之初被寄予解決的問題。因為編譯器對不識別的新增字段會跳過不處理。
• Protocol Buffer 編碼原理篇到此結(jié)束，下篇來講講 Protocol Buffer 反序列化解包性能快的原因。

Reference：