An in-depth explanation of PROTOBUF

An in-depth explanation of PROTOBUF

The protobuf of my understanding, summed up as the following points:

1. PB is a coding method.

This is because some people think it is a protocol, it is chivalrous, PB is essentially the same as JSON, XML, is a way of encoding, with PB-encoded streams can be nested in any existing protocol, as part of the content, such as can be placed in the contents of the HTTP area, or the content area of the private protocol, the outer sleeve (length, type, flag,seqno), etc., so that encryption compression can be easily implemented. Some people say that PB does not provide encryption compression, can not use or bad use, in fact, this is precisely its flexibility, he did not limit how you use, you can be flexible combination of various ways. Place this content in HTTP as well, specify MIME type in header or add special keyword.

2. PB is a kind of TLV implementation.

The early TLV was the standard type length value, there is no ID, then have ID, is to resolve the changes in the forward backward compatibility, but this is not the original PB, has been a lot of this use, now TLV T is tag, generally refers to (ID, type), Length is an optional parameter, and length can be omitted at this time, depending on the type, sometimes length is fixed.

PROTOBUF is an implementation of the TLV (tag length value) encoding, the internal is a combination of (ID, type+[length], value), and some type defaults to length, at which time length can be omitted, Indefinite time to need length, in essence, PB is not something very novel, in fact, many of us have done similar TLV code before.

3. The core value of PB is the provision of a set of tools to simplify the complexity of multilingual interaction, making coding and decoding work productive.

Many small and medium teams have also done TLV coding, but perhaps only a language codec, also does not provide tools, but PB provides a set of tools, support a lot of languages, support is relatively good, the general individual or small team can not do this level, there are tools in fact, there is productivity, many developers do not understand this truth, I always think that you give me this need I can solve, but this solution time in the case of tools and no tools is much worse.

4. PB is non self-describing.

PB because only save (ID, type,length, value), so is not self-describing, the corresponding field of only the ID, and the specific details of the ID in the definition file. Proto inside, out of the proto you have to understand this piece of things is somewhat difficult, but also because of the ID, so there is a certain descriptive, not completely unreadable, but the readability of the PB than JSON, XML is a notch. Many people do not understand why to emphasize the readability of self-describing, especially with the C/s + + language developers, always like to emphasize efficiency, in fact, efficiency is not always the most urgent, whether it is codec time or encoded byte size, many times this is not a problem, but readability is a problem, at this time using the high readability of JSON , XML and so on compared to PB advantage is very obvious.

5. PB coding efficiency is very high, but did not exhaust all the margin.

Let's just say two, pb. var type types are stored in the 7-bit encoding, which may make a full encoded 4 bytes into 5byte, the full byte of 8 bytes will be encoded into 10 bytes, then put a previous description length of the byte, Or merge this length into the previous description ID and the byte of type. The other is a float, double storage, it does not take too many effective compression methods, in fact, is also a compressible storage.

Although the storage efficiency is not exhausted, but compared to JSON, XML and other text encoding methods, the PB encoding is still very efficient, this is beyond doubt.

6. PB is still a small audience.

Say PB is a small audience is and JSON, XML is an industrial standard, because JSON is simple enough to have many advocates, especially in the Web environment, JSON is uncrowned king if you want to consider interacting with other systems, compared to JSON, XML is very different from each other and must be carefully considered when used. Because even the JSON, for a typical JSON codec speed can be achieved single-threaded 300,000/sec, most of the time is not a bottleneck, although CPU consumption is slightly higher than PB, Byte will be a little bit more, but readability, multiplatform compatibility is far from PB comparable.

The final sentence concludes that the choice requires wisdom, but only if you know it well enough.