02 | 协议：怎么设计可扩展且向后兼容的协议？

以 Dubbo 为例，消费者发送请求时，使用 AtomicLong 自增，产生一个 消息 ID。由于 Dubbo 底层 IO 操作是异步的，Dubbo 发送请求之后，需要阻塞等待消费者返回信息。消费者会将消息 ID 保存到 Map 结构中,。为了保证请求响应可以一一对应，这就需要提供者返回的响应信息带上请求者消息 ID。 通过响应的消息 ID，通过 上面提到 Map 存储数据，就能找到对应的请求。 感兴趣的同学可以看下 Dubbo 2.6 DefaultFuture 源码。

老师好，您课后问题我有点不能理解。 我们http 请求一个资源不就对应一个返回。是一一对应的关系，为什么会有如何关联响应和请求的问题呢

你好，既然基于TCP优于HTTP，gRPC为什么选择基于HTTP2

调用方需要维护消息ID列表，然后和返回结果中的消息ID做匹配

老师，你好。请求时带上消息id，响应时，响应体里面带上请求消息的id，这样可以进行关联，对吗？

网络通信在传输层就是一堆堆的0/1码，如果没有协议，那谁知道这一堆堆的0/1是啥意思呢？没人能知道，协议的作用就是通信双方约定好，多少个0/1表示什么意思。 1：Bit Offset——标识协议的其实位置 2：魔术位——标识是什么协议 3：整体长度——标识整个协议有多长，减去协议头长度就是协议体长度 4：头长度——标识协议头的长度，因为头是可扩展的，所以具体长度不固定，需要标识一下 5：协议版本——标识当前协议的版本，用于协议兼容性控制 6：消息类型——标识消息的类型，对于文本的需要，这里也需要嘛？协议类型可能是对象？可能是XML文件？可能是JSON码？正常来讲应该都是对象才对，让用于反序列化，猜测是为了扩展预留的 7：序列化方式——用于消息的序列化和反序列化 8：消息ID——用于表示请求和响应的关系 9：协议头扩展字段——用于扩展协议头，是协议具有扩展性，更加的灵活可控 10协议体——协议的内容，一堆堆的二进制数据，双方沟通的东西 协议头——规定信息转换的规则 协议体——信息真正的内容，由于在传输层对人不友好对应用程序也不友好需要转换一下

答案就在题面上，老师的消息协议图里已经设计了消息ID了😃

hhtp现在已经支持长链接了啊

老师，请问一下魔术位是指的什么啊？

你好，一般RPC为了性能，会采用异步通信的方式，请求响应对应关联，就需要一个类似身份证号的ID，我在自己的项目中实现了类似的场景，https://github.com/howardliu-cn/cynomys/tree/master/cynomys-net