Onelong

分享知识,与你一起进步......
RSS icon Home icon
  • 自定义网络协议

    post by onelong / 2016-8-31 20:48 Wednesday [工作]

    2012年的时候,来到深圳做局域网无线控制,最开始参考别人协议做的控制,别人用的是http,http是无状态的,一个请求完成会断开,下一个控制要重新连接,做实时控制比较麻烦。所以我们我用的socket长连接,在最初的时候,因为没人有经验,直接tcp,只管发送,不管发送是否成功,默认它是成功的,假如丢包了,tcp本身就有重发功能,也就是这样,在断网或切换网络的时候,客户端并不能马上检测出来是否断开了。于是加了心跳和超时,心跳也是单向发包的,需要服务器端确认,如果超时了就认为是断开了,则重连。经过一系列的修改,客户端通讯变得稳定了,但是还是有问题,控制数据包有时候也会丢掉,导致控制无反应。于是还是加了响应包,解决了问题。后来数据包多了,发现有些丢包是因为粘包了,后来继续定了一个规则进行把粘的数据包分开。最初的分包规则很简单,和http差不多用\r\n分开,也就是每个数据固定用\r\n结束。我最初接触到网络封装协议就是这么粗暴的,我知道很多人大学的时候都搞过了,我们当时的老大却没有给我任何建议,就这样弄成了一个产品,后来这个产品装机量也到达30w,还得了很多客户的好评。
    每次说到网络协议,我们总觉得这个东西特别高深的样子,因为概念有点抽象,一说到自定义协议,很多人就吓住了。其实协议有简单的也有复杂的,主要是看需求 ,上面我们定义的协议就非常简单了,如发送的消息包:touch\nx,y\r\n,x,y是两个参数。然后服务端收到这个消息包之后,发送一个回应包如:touch\nok\r\n。是不是很简单呢!这样也是一个协议。定义协议呢,主要要处理好两样东西:1、粘包,2、响应。任何一个请求消息都应该有一个响应包,告诉对方“你发送的东西,我收到了”,这是最基本的。在处理通讯的时候,由于各种网络环境的原因,数据包粘包是必然存在的,所以定义的协议的时候,应该给出分包的解决方案。当前自定义协议比较常见分包方案有两个:1、如上面,用行分隔,这样做法常用于文本类的协议。 2、长度分包,例如一个消息包含两部分header+body,header里面第一个字段是整个消息的长度,header可能还包含如消息类型,版本等字段,具体情况按需求定。body是就是消息的主体,消息主体可以放各种对象,String,json,protobuf等。说到这里,我想你对自定义网络协议感到很无语了,这么简单么?的确基础的东西就是这么简单。
         我在2013年写过嵌入式的java服务器,当时是给ipad上传文件的,还有给电视盒上传文件。从http到webdav走了一遍,以前在东莞的时候做过邮件相关的软件,熟悉了smtp,pop3,imap等,协议定义确实是不太复杂,协议复杂的原因,很多时候是因为复杂的业务需求。好了下面简单看一看xmpp的协议的几个应答,其实大部分协议都差不多,只是格式不同而已。
    获取联系人列表请求内容如下:

    <iq type=‘get’ from=‘romeo@montague.lit/pda’>

    <query xmlns=‘jabber:iq:roster’/>

    </iq>
    意思是用户
    romeo@montague.lit/pda发送了一个get类型的请求,请求域是jabber:iq:roster,具体是什么意思呢?具体看协议规定。
     在看看响应内容如下:

    <iq type=‘result’ to=‘romeo@montague.lit/pda’>

    <query xmlns=‘jabber:iq:roster’>

    <item jid=‘juliet@capulet.lit’/>
    <item jid=‘mercutio@shakespeare.lit’/>

    <item jid=‘benvolio@shakespeare.lit’/>

    </query>

    </iq> 
    接收人:romeo@montague.lit/pda,域:jabber:iq:roster,联系人列表就说了,每个item都是的。
    看了这么简单的一个协议,是否会让你想到一些东西呢?我当时看的时候,就在想为什么浪费那么多流量呢,用了xml,还有用户名为什么那么复杂呢?后来看了一个分布式服务器逻辑 ,发现用户名 
    romeo@montague.lit/pda是用意义的,这个名字包含了路由的信息如uerid@serverid,方便消息做正确的路由。

    引用地址:
     

    我要评论