ejabberd的网络数据粘包处理
对ejabberd的源代码分析,ejabberd是如何处理网络数据的粘包情况。
什么是粘包
因为UDP的协议特性,粘包现象并不会出现在UDP当中。因此粘包一般都出现在TCP当中,不 过并不是使用TCP进行数据传输就会产生粘包。
TCP长链接
客户端和服务器建立起一个TCP连接后,进行多次数据交换而不断开,必要的时候会插入和 数据无关的心跳包来保持TCP连接不被中间路由强制断开。
TCP短链接
客户端与服务器没进行一次数据交换就建立一次连接,完成数据交换后立刻断开连接。
TCP粘包的产生
从上面可以看出,只有是TCP长连接存在的时候,才会发生粘包,因为TCP是流式传输的。在 应用层面上虽然可以划分出一个个数据包,但是TCP传输层会将数据包整合一起发送或缓存 着被应用一次性取出。简单的说就是:
- 发送方需要等到缓存区被填充满了之后,再发送,因此造成了粘包现象。
- 接收方不能快速的处理缓存区中的包,造成多个包堆积在缓存区中,因此造成了粘包现 象。
如何解决TCP粘包
最常见的方式就是,在每次发送数据包之前,先定义一个数据包长度。在接收数据包的时候 先读取数据包长度,再读取整个数据包。进一步去完成业务操作。
ejabberd是如何处理粘包问题
作为即时通讯,ejabberd在和普通的客户端进行通讯的时候底层技术也使用的是TCP长连接 (Web做客户端还有websocket和BOSH这两个技术)。因此ejabberd也会出现粘包这一现象, 这里就介绍下ejabberd是如何处理粘包的。
ejabberd_receiver模块
ejabberd_receiver可以说是eJabberd的XML输入流最主要的部分,它负责管理了socket,输 入流的流控和XML的解析器。在每次收到数据后,ejabberd_receiver都会更新流量控制器, 防止一个客户端过快的发送数据,而给ejabberd_c2s造成过大的负担。
在ejabberd_receiver进程被创建之后,会立刻初始化一个exml_stream的解析器。因为XMPP 是基于TCP长连接的XML流,而XMPP又规定了XML流上传输的数据是通过XML节这种结构化格式 封装的,所以这里XML的节就相当于数据包前方的长度字段了。简单的说:读取了一个完整 的XML节,就是一个数据包,剩下的数据就是后续的数据包。
exml项目
exml_event
exml_event是一个对libexpat进行封装的NIF,可以进行高效率的XML解析。exml_event会将 xml数据解析成xml_element_start,xml_element_end和xml_cdata这三个标签。如果传入的 数据没有被完全被解析,会保存在libexpat的parser的上下文当中。
exml_stream
exml_stream会将数据交给exml_event进行解析,会对解析出来的events(上面提到的 xml_element_start,xml_element_end和xml_cdata)进行转换。将它们转化成 xmlstreamstart,xmlstreamend和xmlel的Erlang的record。在exml_stream的上下文当中, 会将没有闭合的xml节保存起来,直到整个XML节闭合后才会交还给ejabberd_receiver。
总结
ejabberd使用XML节闭合的特性,作为数据包的边界来解决粘包问题。同时使用libexpat的 parser来缓存没有解析完的原始数据,使用exml项目中的exml_stream来缓存解析成功,但 是没有闭合的XML节。从而保证了XMPP流中的XMPP节的完整性,以此来解决粘包问题。