grpc比http性能高的原因
二进制消息格式：gRPC使用Protobuf（一种有效的二进制消息格式）进行序列化，这种格式在服务器和客户端上的序列化速度非常快，且序列化后的消息体积小，适合带宽有限的场景。
HTTP/2协议：gRPC是为HTTP/2设计的，HTTP/2协议在发送和接收方面都是紧凑且高效的，支持多路复用，即在单个TCP连接上可以复用多个HTTP/2调用，消除了应用程序层的队头阻塞问题。
流控制和双向通信：gRPC支持双向流控制机制，允许客户端和服务器之间进行实时的双向通信，这对于需要实时数据交互的应用非常有利。
为什么protobuf比较高效
概括：
即：序列化后数据体积小（压缩率高）、序列化和反序列化速度快。
与XML、JSON这类文本协议相比，ProtoBuf通过T-L-V（TAG-LENGTH-VALUE）方式编码，不需要", {, }, :等分隔符来结构化信息。同时在编码层面使用varint压缩，所以描述同样的信息，protobuf序列化后的体积要小很多，在网络中传输消耗的网络流量更少。
详细：
（1）压缩率高
protobuf基于接口描述语言IDL(Interface Description Language)实现消息结构的定义，传输数据的两端都需要定义该消息结构，并保存在.proto文件中，这样就不需要在消息数据中定义结构信息，自然就把空间压榨到极限了。例如：
package my;
message helloworld
{
required int32 id = 1;
required string str = 2;
optional int32 wow = 3;
}
除此之外，每个消息项前面有对应的tag，才能解析对应的数据类型，类似于计算机网络中传输IP数据包也需要分隔符来标识一样。对于protobuf，tag的大小是一个字节，即八位，tag的计算方式: tag = (field_number << 3) | wire_type，其中，上面定义的1，2，3可以类比json中的key。field_number是.proto文件用于定义某个字段，比如对于上述消息结构，id是1，str是2，wow是3，wire_type是google官方定义的，它是消息结构类型的一种再次分类，每个wire_type都可以对应多种数据类型，每种数据类型都有对应的wire_type：可以观察到，protobuf支持的wire_type 范围是0~5，对应二进制也就是000~101，正好是三位，那么按照tag计算公式，field_number左移三位之后，再或上wire_type就组成了tag。这样就总共是六位，放在一个字节中，表示tag，就可以标识该字段的结构信息。因此在判断wire_type类型的时候，只需要取后三位。
（2）解析快
（a）Varint编码：
在说varint之前，我们回顾一下，传输int需要四字节，但如果这个数用不到四字节，那么会导致浪费，例如对于整数267，二进制表示是00000000 00000000 00000001 00001011，前两个字节就是浪费的。
varint是一种特殊的编码，例如下图是两个字节(这两个字节其实对于varint编码来说，表示267，why？我们后面就见分晓)：
第一个字节最高是1，表示下一个字节也是其想表述的数据的组成部分。反之，0则表示下一个字节与当前字节没有关系。
这样的话，其实上面16位里，只有14位是有实际数据意义的，从左到右先放高位，那么就是0000010 0001011，连一起就是00000100001011,正好就是前面我们的例子267的二进制表示
那么，varint编码有什么问题吗？
如果想表示-1，二进制是11111111 11111111 11111111 11111111 ，用varint编码效率很低。
（b）Zigzag编码：
Zigzag编码规则如下：
如果数据是负数，那么套用2*|x|-1来编码表示
如果数据是正数，那么套用2*|x| 来编码表示
那么对于-1，就编成1，再二进制表示，就是00000001
上面的编码都是基于数字编码，那么如果传输字符串，就显得不太方便。
（c）TLV（Tag-Length-Value）：
这不是一种编码格式，而是一种传输规则，对于传输字符串，Tag还是起到分隔符的作用，Length表示字符串的长度，Value表示字符的具体值，不进行编码。
