wen 聊聊dubbo协议
搜索关注微信公众号”捉虫大师”，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。
协议
协议通俗易懂地解释就是通信双方需要遵循的约定。
我们了解的常见的网络传输协议有tcp、udp、http等。再到我们常用的基础组件，一般来说client端与server端也有相应的协议，如redis、mysql、zookeeper等都是各自约定的私有协议，同样今天标题中的dubbo协议也是一种私有协议，他们都是应用层协议，基于tcp或udp设计。
通常应用层协议都是基于tcp和udp，可靠传输通常使用tcp，如大多数的基础组件，如redis、mysql。只有能容忍丢失且需要很高的性能时使用udp协议，比如metric上报等场景。
这里介绍几种基于tcp的应用协议。
redis协议
redis协议足够简单，所以先介绍一下。redis协议基于tcp设计，客户端和服务器发送的命令一律使用
*<参数数量> CRLF
$<参数1 字节数量> CRLF
<参数1的数据> CRLF
...
$<参数n 字节数量> CRLF
<参数n的数据> CRLF
举个例子，client向server端发送命令 set mykey myvalue
*3 CRLF
$3 CRLF
SET CRLF
$5 CRLF
mykey CRLF
$7 CRLF
myvalue CRLF
也就是 *3
$3
SET
$5
mykey
$7
myvalue
关于redis协议更详细信息可以看这个链接：
http://redisdoc.com/topic/protocol.html
http协议
http协议是我们最常见的协议，它的请求报文格式是由三部分组成：
- 请求行：包括method、url、version，由空格分隔，
结尾 - 请求头：多行，每行是key:value的格式，以
结尾 - 请求体：请求头与请求体直接由一个空白行分隔，请求体的长度在请求头中由
content-length给出
redis和http协议的处理方式截然不同。他们都是基于tcp，而tcp协议传输的数据是流式的，通俗地说就是它就像水流，不断地发送字节，tcp保证不重复，不丢包。而接收端要拿到想要的数据必须得从流式的数据中“判断出数据包的边界”，这就是tcp的粘包问题，解决它通常有三种方法：
- 发送固定长度的消息
- 使用特殊标记区分消息间隔
- 将消息的尺寸和消息一起发送
redis协议使用了第2种，http和接下来要介绍的dubbo协议使用了第3种，固定长度的消息比较理想，在实际中很少遇到。
dubbo协议
由于dubbo支持的协议很多，本文提到的dubbo协议特指dubbo框架的默认协议，也就是dubbo的私有协议。它的格式如下：
- 0-15: 魔数，判断是否是dubbo协议
- 16: 判断是请求还是返回
- 17: 判断是否期望返回
- 18: 判断是否为事件消息，如心跳事件
- 19-23: 序列化标志
- 24-31: 标志响应状态（类似http status）
- 32-63: 请求id
- 64-95: 内容长度（字节）
- 96-?: 序列化后的内容（换行符分隔）
常用的attachments在dubbo协议的哪里？
dubbo的attachments，我们通常将他类比为http协议的header，可以携带一些隐式的参数信息（不用编码到请求对象中），如压测标志等。从他的类型
private Map<String, String> attachments;
基本可以推断出attachments存在于dubbo协议的96字节之后的内容中，因为前面头的根本放不下这个map。
从dubbo的实现中可以看出，dubbo的一个请求被封装为一个DecodeableRpcInvocation对象，里面包含了methodName、parameterTypes、arguments、attachments等，将该对象序列化后填入dubbo协议的96字节后的内容中发送出去。
使用时，consumer端：
RpcContext.getContext().setAttachment("hello", "from_consumer");
provider端：
RpcContext.getContext().getAttachment("hello");
这里能看出dubbo协议相比较http协议来说设计的还是有所欠缺的，想要拿到一些隐式参数，或者想要知道请求发往哪里，必须得把请求体解析出来才可以，这也是dubbo协议往mesh方向发展的一个绊脚石。
dubbo协议支持在返回值中带回attachments吗？
consumer端向provider端发送请求可以在头部携带隐式参数，那么返回时也可以从provider端带回到consumer端吗？
比如provider回传给consumer它自身的处理耗时，consumer计算出请求的响应时间，两者相减即可得到网络耗时，此时provider端最好是将耗时放在attachments中隐式地传回。
dubbo的协议是请求和回复都是相同格式，理论上consumer可以带隐式参数到provider端，则provider端肯定也可以回传。
从dubbo的返回对象DecodeableRpcResult中可以看到是存在attachments的，但从实际的测试来看，2.7.x版本是不支持的，但2.6.x（>=2.6.3）版本是支持的。
provider端设置：
RpcContext.getServerContext().setAttachment("hello", "from_provider");
consumer端获取：
RpcContext.getServerContext().getAttachment("hello")
github上相关的issue链接如下：
https://github.com/apache/dubbo/pull/1843
协议和序列化有什么区别？
我们可能会经常听到这样的说法，dubbo除了dubbo协议外还支持rest、thrift、grpc等协议，也支持hessian、json序列化。协议与序列化是什么关系？
通过刚刚介绍的dubbo协议格式或许就能明白，dubbo协议是如上的格式包含了头和内容，其中96字节之后的内容是序列化后的内容，默认使用hessian2序列化，也可以修改为fastjson、gson、jdk等。只需要配置即可修改协议
<dubbo:protocol name="dubbo" serialization="fastjson"/>
如果非要做个类比的话，就是你不仅可以通过http协议传输json格式的数据，也可以传输xml格式的数据。http就是协议，json和xml就是序列化。
最后
dubbo协议的设计虽然有所欠缺，但依然不能阻止它成为dubbo使用最广泛的协议。
搜索关注微信公众号”捉虫大师”，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。
