高效的數據壓縮編碼方式 Protobuf

時間 2019-11-16

原文原文鏈接

一. protocol buffers 是什麼？

Protocol buffers 是一種語言中立，平臺無關，可擴展的序列化數據的格式，可用於通訊協議，數據存儲等。git

Protocol buffers 在序列化數據方面，它是靈活的，高效的。相比於 XML 來講，Protocol buffers 更加小巧，更加快速，更加簡單。一旦定義了要處理的數據的數據結構以後，就能夠利用 Protocol buffers 的代碼生成工具生成相關的代碼。甚至能夠在無需從新部署程序的狀況下更新數據結構。只需使用 Protobuf 對數據結構進行一次描述，便可利用各類不一樣語言或從各類不一樣數據流中對你的結構化數據輕鬆讀寫。github

Protocol buffers 很適合作數據存儲或 RPC 數據交換格式。可用於通信協議、數據存儲等領域的語言無關、平臺無關、可擴展的序列化結構數據格式。算法

二. 爲何要發明 protocol buffers ？

你們可能會以爲 Google 發明 protocol buffers 是爲了解決序列化速度的，其實真實的緣由並非這樣的。編程

protocol buffers 最早開始是 google 用來解決索引服務器 request/response 協議的。沒有 protocol buffers 以前，google 已經存在了一種 request/response 格式，用於手動處理 request/response 的編組和反編組。它也能支持多版本協議，不過代碼比較醜陋：數組

if (version == 3) {
   ...
 } else if (version > 4) {
   if (version == 5) {
     ...
   }
   ...
 }
複製代碼

若是很是明確的格式化協議，會使新協議變得很是複雜。由於開發人員必須確保請求發起者與處理請求的實際服務器之間的全部服務器都能理解新協議，而後才能切換開關以開始使用新協議。安全

這也就是每一個服務器開發人員都遇到過的低版本兼容、新舊協議兼容相關的問題。bash

protocol buffers 爲了解決這些問題，因而就誕生了。protocol buffers 被寄予一下 2 個特色：服務器

能夠很容易地引入新的字段，而且不須要檢查數據的中間服務器能夠簡單地解析並傳遞數據，而無需瞭解全部字段。
數據格式更加具備自我描述性，能夠用各類語言來處理(C++, Java 等各類語言)

這個版本的 protocol buffers 仍須要本身手寫解析的代碼。網絡

不過隨着系統慢慢發展，演進，protocol buffers 目前具備了更多的特性：數據結構

自動生成的序列化和反序列化代碼避免了手動解析的須要。（官方提供自動生成代碼工具，各個語言平臺的基本都有）
除了用於 RPC（遠程過程調用）請求以外，人們開始將 protocol buffers 用做持久存儲數據的便捷自描述格式（例如，在Bigtable中）。
服務器的 RPC 接口能夠先聲明爲協議的一部分，而後用 protocol compiler 生成基類，用戶可使用服務器接口的實際實現來覆蓋它們。

protocol buffers 如今是 Google 用於數據的通用語言。在撰寫本文時，谷歌代碼樹中定義了 48162 種不一樣的消息類型，包括 12183 個 .proto 文件。它們既用於 RPC 系統，也用於在各類存儲系統中持久存儲數據。

小結：

protocol buffers 誕生之初是爲了解決服務器端新舊協議(高低版本)兼容性問題，名字也很體貼，「協議緩衝區」。只不事後期慢慢發展成用於傳輸數據。

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 的類，它實際上充當了單個方法的緩衝區。用戶能夠經過調用像 AddValue(tag,value) 這樣的方法分別將標籤/值對添加到此緩衝區。原始字節存儲在一個緩衝區中，一旦構建消息就能夠將其寫出。

從那時起，名爲「緩衝」的部分已經失去了意義，但它仍然是咱們使用的名稱。今天，人們一般使用術語「protocol message」來指代抽象意義上的消息，「protocol buffer」指的是消息的序列化副本，而「protocol message object」指的是表明內存中對象解析的消息。

三. proto3 定義 message

目前 protocol buffers 最新版本是 proto3，與老的版本 proto2 仍是有些區別的。這兩個版本的 API 不徹底兼容。

proto2 和 proto3 的名字看起來有點撲朔迷離，那是由於當咱們最初開源的 protocol buffers 時，它其實是 Google 的第二個版本了，因此被稱爲 proto2，這也是咱們的開源版本號從 v2 開始的緣由。初始版名爲 proto1，從 2001 年初開始在谷歌開發的。

在 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 中的字段編號須要一個字節進行編碼，包括字段編號和字段類型（具體緣由見 Protocol Buffer 編碼原理這一章節）。範圍 16 至 2047 中的字段編號須要兩個字節。因此你應該保留數字 1 到 15 做爲很是頻繁出現的消息元素。請記住爲未來可能添加的頻繁出現的元素留出一些空間。

能夠指定的最小字段編號爲1，最大字段編號爲2^29^-1 或 536,870,911。也不能使用數字 19000 到 19999（FieldDescriptor :: kFirstReservedNumber 到 FieldDescriptor :: kLastReservedNumber），由於它們是爲 Protocol Buffers實現保留的。

若是在 .proto 中使用這些保留數字中的一個，Protocol Buffers 編譯的時候會報錯。

一樣，您不能使用任何之前 Protocol Buffers 保留的一些字段號碼。保留字段是什麼，下一節詳細說明。

2. 保留字段

若是您經過徹底刪除某個字段或將其註釋掉來更新消息類型，那麼將來的用戶能夠在對該類型進行本身的更新時從新使用該字段號。若是稍後加載到了的舊版本 .proto 文件，則會致使服務器出現嚴重問題，例如數據混亂，隱私錯誤等等。確保這種狀況不會發生的一種方法是指定刪除字段的字段編號（或名稱，這也可能會致使 JSON 序列化問題）爲 reserved。若是未來的任何用戶試圖使用這些字段標識符，Protocol Buffers 編譯器將會報錯。

message Foo {
  reserved 2, 15, 9 to 11;
  reserved "foo", "bar";
}
複製代碼

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

3. 默認字段規則

字段名不能重複，必須惟一。
repeated 字段：能夠在一個 message 中重複任何數字屢次(包括 0 )，不過這些重複值的順序被保留。

在 proto3 中，純數字類型的 repeated 字段編碼時候默認採用 packed 編碼（具體緣由見 Protocol Buffer 編碼原理這一章節）

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

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 文件，則會致使服務器出現嚴重問題，例如數據混亂，隱私錯誤等等。確保這種狀況不會發生的一種方法是指定已刪除條目的數字值（或名稱，這也可能會致使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

若是後面發現以前定義 message 須要增長字段了，這個時候就體現出 Protocol Buffer 的優點了，不須要改動以前的代碼。不過須要知足如下 10 條規則：

不要改動原有字段的數據結構。
若是您添加新字段，則任何由代碼使用「舊」消息格式序列化的消息仍然能夠經過新生成的代碼進行分析。您應該記住這些元素的默認值，以便新代碼能夠正確地與舊代碼生成的消息進行交互。一樣，由新代碼建立的消息能夠由舊代碼解析：舊的二進制文件在解析時會簡單地忽略新字段。（具體緣由見未知字段這一章節）
只要字段號在更新的消息類型中再也不使用，字段能夠被刪除。您可能須要重命名該字段，可能會添加前綴「OBSOLETE_」，或者標記成保留字段號 reserved，以便未來的 .proto 用戶不會意外重複使用該號碼。
int32，uint32，int64，uint64 和 bool 全都兼容。這意味着您能夠將字段從這些類型之一更改成另外一個字段而不破壞向前或向後兼容性。若是一個數字從不適合相應類型的線路中解析出來，則會獲得與在 C++ 中將該數字轉換爲該類型相同的效果（例如，若是將 64 位數字讀爲 int32，它將被截斷爲 32 位）。
sint32 和 sint64 相互兼容，但與其餘整數類型不兼容。
只要字節是有效的UTF-8，string 和 bytes 是兼容的。
嵌入式 message 與 bytes 兼容，若是 bytes 包含 message 的 encoded version。
fixed32與sfixed32兼容，而fixed64與sfixed64兼容。
enum 就數組而言，是能夠與 int32，uint32，int64 和 uint64 兼容（請注意，若是它們不適合，值將被截斷）。可是請注意，當消息反序列化時，客戶端代碼可能會以不一樣的方式對待它們：例如，未識別的 proto3 枚舉類型將保留在消息中，但消息反序列化時如何表示是與語言相關的。（這點和語言相關，上面提到過了）Int 域始終只保留它們的值。
將單個值更改成新的成員是安全和二進制兼容的。若是您肯定一次沒有代碼設置多個字段，則將多個字段移至新的字段多是安全的。將任何字段移到現有字段中都是不安全的。（注意字段和值的區別，字段是 field，值是 value）

9. 未知字段

未知數字段是 protocol buffers 序列化的數據，表示解析器沒法識別的字段。例如，當一箇舊的二進制文件解析由新的二進制文件發送的新數據的數據時，這些新的字段將成爲舊的二進制文件中的未知字段。

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 中的規範編碼，使系統之間共享數據變得更加容易。編碼在下表中按類型逐個描述。

若是 JSON 編碼數據中缺乏值或其值爲空，則在解析爲 protocol buffer 時，它將被解釋爲適當的默認值。若是一個字段在協議緩衝區中具備默認值，默認狀況下它將在 JSON 編碼數據中省略以節省空間。具體 Mapping 的實現能夠提供選項決定是否在 JSON 編碼的輸出中發送具備默認值的字段。

proto3 的 JSON 實現中提供瞭如下 4 中 options:

使用默認值發送字段：在默認狀況下，默認值的字段在 proto3 JSON 輸出中被忽略。一個實現能夠提供一個選項來覆蓋這個行爲，並使用它們的默認值輸出字段。
忽略未知字段：默認狀況下，Proto3 JSON 解析器應拒絕未知字段，但可能提供一個選項來忽略解析中的未知字段。
使用 proto 字段名稱而不是 lowerCamelCase 名稱：默認狀況下，proto3 JSON 的 printer 將字段名稱轉換爲 lowerCamelCase 並將其用做 JSON 名稱。實現可能會提供一個選項，將原始字段名稱用做 JSON 名稱。 Proto3 JSON 解析器須要接受轉換後的 lowerCamelCase 名稱和原始字段名稱。
發送枚舉形式的枚舉值而不是字符串：在 JSON 輸出中默認使用枚舉值的名稱。能夠提供一個選項來使用枚舉值的數值。

四. proto3 定義 Services

若是要使用 RPC（遠程過程調用）系統的消息類型，能夠在 .proto 文件中定義 RPC 服務接口，protocol buffer 編譯器將使用所選語言生成服務接口代碼和 stubs。因此，例如，若是你定義一個 RPC 服務，入參是 SearchRequest 返回值是 SearchResponse，你能夠在你的 .proto 文件中定義它，以下所示：

service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}
複製代碼

與 protocol buffer 一塊兒使用的最直接的 RPC 系統是 gRPC：在谷歌開發的語言和平臺中立的開源 RPC 系統。gRPC 在 protocol buffer 中工做得很是好，而且容許你經過使用特殊的 protocol buffer 編譯插件，直接從 .proto 文件中生成 RPC 相關的代碼。

若是你不想使用 gRPC，也能夠在你本身的 RPC 實現中使用 protocol buffers。您能夠在 Proto2 語言指南中找到更多關於這些相關的信息。

還有一些正在進行的第三方項目爲 Protocol Buffers 開發 RPC 實現。

五. Protocol Buffer 命名規範

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 是一種緊湊的表示數字的方法。它用一個或多個字節來表示一個數字，值越小的數字使用越少的字節數。這能減小用來表示數字的字節數。

Varint 中的每一個字節（最後一個字節除外）都設置了最高有效位（msb），這一位表示還會有更多字節出現。每一個字節的低 7 位用於以 7 位組的形式存儲數字的二進制補碼錶示，最低有效組首位。

若是用不到 1 個字節，那麼最高有效位設爲 0 ，以下面這個例子，1 用一個字節就能夠表示，因此 msb 爲 0.

0000 0001
複製代碼

若是須要多個字節表示，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 一個字節只有 7 位能用來表示數字，最高位 msb 用來表示後面是否有更多字節），因此 300 須要用 2 個字節來表示。

Varint 的編碼，以 300 舉例：

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

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

若是是多個字節，先去掉每一個字節的 msb（經過邏輯或運算），每一個字節只留下 7 位。
逆序整個結果，最可能是 5 個字節，排序是 1-2-3-4-5，逆序以後就是 5-4-3-2-1，字節內部的二進制位的順序不變，變的是字節的相對位置。

解碼過程調用 GetVarint32Ptr 函數，若是是大於一個字節的狀況，會調用 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 個字節，64位是 10 個字節）

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);
}
複製代碼

原理不變，只不過用循環來解決了。

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 個字節表示，如今仍是 2 個字節了，哪裏緊湊了，花費的空間沒有變啊？！

Varint 確實是一種緊湊的表示數字的方法。它用一個或多個字節來表示一個數字，值越小的數字使用越少的字節數。這能減小用來表示數字的字節數。好比對於 int32 類型的數字，通常須要 4 個 byte 來表示。可是採用 Varint，對於很小的 int32 類型的數字，則能夠用 1 個 byte 來表示。固然凡事都有好的也有很差的一面，採用 Varint 表示法，大的數字則須要 5 個 byte 來表示。從統計的角度來講，通常不會全部的消息中的數字都是大數，所以大多數狀況下，採用 Varint 後，能夠用更少的字節數來表示數字信息。

300 若是用 int32 表示，須要 4 個字節，如今用 Varint 表示，只須要 2 個字節了。縮小了一半！

1. Message Structure 編碼

protocol buffer 中 message 是一系列鍵值對。message 的二進制版本只是使用字段號(field's number 和 wire_type)做爲 key。每一個字段的名稱和聲明類型只能在解碼端經過引用消息類型的定義（即 .proto 文件）來肯定。這一點也是人們經常說的 protocol buffer 比 JSON，XML 安全一點的緣由，若是沒有數據結構描述 .proto 文件，拿到數據之後是沒法解釋成正常的數據的。

因爲採用了 tag-value 的形式，因此 option 的 field 若是有，就存在在這個 message buffer 中，若是沒有，就不會在這裏，這一點也算是壓縮了 message 的大小了。

當消息編碼時，鍵和值被鏈接成一個字節流。當消息被解碼時，解析器須要可以跳過它沒法識別的字段。這樣，能夠將新字段添加到消息中，而不會破壞不知道它們的舊程序。這就是所謂的「向後」兼容性。

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

注意上圖中，3 和 4 已經被廢棄了，因此 wire_type 取值目前只有 0、一、二、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 字符串這一章節）

2. Signed Integers 編碼

從上面的表格裏面能夠看到 wire_type = 0 中包含了無符號的 varints，可是若是是一個無符號數呢？

一個負數通常會被表示爲一個很大的整數，由於計算機定義負數的符號位爲數字的最高位。若是採用 Varint 表示一個負數，那麼必定須要 10 個 byte 長度。爲此 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，以下表所示：

須要注意的是，第二個轉換 （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. 字符串

wire_type 類型爲 2 的數據，是一種指定長度的編碼方式：key + length + content，key 的編碼方式是統一的，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，編碼後的字節爲：

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 個字節，即 08 96 01 。

須要轉變爲 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 不須要連續的出現；他們可能與其餘的字段間隔的出現。儘管他們是無序的，可是在解析時，他們是須要有序的。在 proto3 中 repeated 字段默認採用 packed 編碼（具體緣由見 Packed Repeated Fields 這一章節）

對於 proto3 中的任何非重複字段或 proto2 中的可選字段，編碼的 message 可能有也可能沒有包含該字段號的鍵值對。

一般，編碼後的 message，其 required 字段和 optional 字段最多隻有一個實例。可是解析器卻須要處理多對一的狀況。對於數字類型和 string 類型，若是同一值出現屢次，解析器接受最後一個它收到的值。對於內嵌字段，解析器合併(merge)它接收到的同一字段的多個實例。就如 MergeFrom 方法同樣，全部單數的字段，後來的會替換先前的，全部單數的內嵌 message 都會被合併(merge)，全部的 repeated 字段，都會串聯起來。這樣的規則的結果是，解析兩個串聯的編碼後的 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 必須是串聯的，每一個 pair 必須包含完整的元素。

Protocol Buffer 解析器必須可以解析被從新編譯爲 packed 的字段，就像它們未被 packed 同樣，反之亦然。這容許以正向和反向兼容的方式將[packed = true]添加到現有字段。

8. Field Order

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

若是消息具備未知字段，則當前的 Java 和 C++ 實如今按順序排序的已知字段以後以任意順序寫入它們。當前的 Python 實現不會跟蹤未知字段。

七. protocol buffers 的優缺點

protocol buffers 在序列化方面，與 XML 相比，有諸多優勢：

更加簡單
數據體積小 3- 10 倍
更快的反序列化速度，提升 20 - 100 倍
能夠自動化生成更易於編碼方式使用的數據訪問類

舉個例子：

若是要編碼一個用戶的名字和 email 信息，用 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 的反序列化時間。

上面說的是性能方面的優點。接下來講說編碼方面的優點。

protocol buffers 自帶代碼生成工具，能夠生成友好的數據訪問存儲接口。從而開發人員使用它來編碼更加方便。例如上面的例子，若是用 C++ 的方式去讀取用戶的名字和 email，直接調用對應的 get 方法便可（全部屬性的 get 和 set 方法的代碼都自動生成好了，只須要調用便可）

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

而 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 最後一個很是棒的特性是，即「向後」兼容性好，人們沒必要破壞已部署的、依靠「老」數據格式的程序就能夠對數據結構進行升級。這樣您的程序就能夠沒必要擔憂由於消息結構的改變而形成的大規模的代碼重構或者遷移的問題。由於添加新的消息中的 field 並不會引發已經發布的程序的任何改變(由於存儲方式原本就是無序的，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 文件，就沒法理解二進制數據流。這點便是優勢，使數據具備必定的「加密性」，也是缺點，數據可讀性極差。因此 Protocol Buffer 很是適合內部服務之間 RPC 調用和傳遞數據。
Protocol Buffer 具備向後兼容的特性，更新數據結構之後，老版本依舊能夠兼容，這也是 Protocol Buffer 誕生之初被寄予解決的問題。由於編譯器對不識別的新增字段會跳過不處理。

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

Reference：

google 官方文檔
 thrift-protobuf-compare - Benchmarking.wiki
jvm-serializers