温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

怎么自定义协议

发布时间:2021-10-21 10:15:24 来源:亿速云 阅读:144 作者:iii 栏目:编程语言

本篇内容介绍了“怎么自定义协议”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

为什么要自定义协议

直接使用标准的协议好处是显而易见的,我个人理解的几点优点:

  • 既然是标准协议说明已经成为了标准,这样很多系统就可以直接对接,无缝集成;

  • 协议最重要的一点就是编码解码,标准协议往往有现成的编码解码包,直接拿来使用,减少开发时间;

  • 有很多围绕标准协议的第三方测试工具,可以很方便的进行测试;

既然有这么多优点那我们为什么还要去自定义协议,大致出于以下几点考虑:

  • 既然是标准协议,往往兼顾的东西比较多,导致协议数据相对来说比较大,这样可能在一些追求性能,流量的系统中不能容忍;

  • 标准协议有很多,没有哪一种协议可以适用任何场景中,所以如果在某个场景中还没有既定的标准协议,这时候会有各种私有协议;

  • 自定义协议只要双方约定好数据结构就行,不具有通用性,理论上来说会更加安全一点,当然现在很多标准协议都有安全版本,比如https,sftp等等;

以上只是个人的一点理解,欢迎大家补充;关于如何去自定义协议,其实可以去多参考一些主流的标准协议或者私有协议,其实有很多共同点可以去借鉴;下面先简单看看那些主流的协议;

主流协议

下面分别看看一些主流的标准协议或者私有协议都是如何去定义自己的数据结构的,对我们有非常好的借鉴意义;

http协议

http协议大家最熟悉不过了,全称叫超文本传输协议,整个请求报文可以分为三个部分分别是:请求行,请求报头,请求正文;

  • 请求行

GET /test.html HTTP/1.1 (CRLF换行)
  • 请求报头

Accept-Encoding: gzip, deflateContent-Length: 38 Content-Encoding: gzip...

请求包头有很多,每一个代表了各自的含义,这边就不一一列出,我们这里更加关注整个报文的结构;

  • 请求正文

这个只有在POST请求的时候才有正文,里面存放业务数据,比如常见的json文本串;具体正文的长度可以根据消息头中的Content-Length来决定;

dubbo协议

dubbo协议格式可以直接参考官网提供的如下图片:
怎么自定义协议
看上图其实整个协议数据包也大致分为两个部分:固定部分和可变部分,或者叫消息头和消息体;
固定部分一共是4+8+4=16个字节,具体如下所示:

header{Magic High       = 8bit;  //魔数高位Magic Low        = 8bit;  //魔数低位Req/Res          = 1bit;  //标识是请求或响应2 Way            = 1bit;  //标记是否期望从服务器返回值Event            = 1bit;  //标识是否是事件消息Serialization ID = 5bit;  //标识序列化类型Status           = 8bit;  //标识响应的状态Request ID       = 64bit; //标识唯一请求Data Length      = 32bit; //序列化后的内容长度}

可变部分根据固定部分中的Data Length来确定长度;

redis协议

Redis的客户端与服务端采用叫做 RESP(Redis Serialization Protocol)的网络通信协议交换数据,相对来说还是比较简单的,以下是这个协议的一般形式:

*< 参数数量 > CR LF
$< 参数 1 的字节数量 > CR LF< 参数 1 的数据 > CR LF
...
$< 参数 N 的字节数量 > CR LF< 参数 N 的数据 > CR LF

以上大致介绍了三种比较有代表性的协议,虽然说每种协议都有各自的使用场景,但是如果我们自己去定义协议,还是有一些相通的东西;

如何自定义协议

下面我们重点看看去自定义协议有哪些需要我们关注的点,以下是本人根据自己的理解整理了如下关注点:

  • 完整的数据包

  • 协议号

  • 消息头标识

  • 业务数据

  • 预留字段

下面分别逐一详细介绍:

完整的数据包

我们平时经常讲数据包,但是TCP其实只有流的概念,并没有数据包的概念;那很重要的一点就是我们的程序怎么知道现在的业务数据已经接受全部接收完了,可以作为一个完整的数据包去处理了,如果不去做处理的话就会出现我们常说的半包和粘包问题;主流的的处理方式大致有这么两种:

  • 在消息头部加上数据包长度描述,比如在http协议和dubbo协议中出现的dataLength字段;

  • 用特殊的字符串作为数据包的结尾,这样我们在接受数据的时候接受到预定的特殊字符串就表示数据包完整了;

协议号

可能不同的协议有不同的叫法,我这里把它叫做协议号,个人理解就是根据这个协议号,服务器端知道去执行什么逻辑;比如http协议请求行中的/test.html,dubbo协议中的服务名+版本号,redis中的具体要执行什么key;

消息头标识

这个是否需要还是要看各自的场景,比如redis协议足够简单,无需任何标识,所有的东西都是双端约定好的;但是其他很多协议还是有一些需要的,除了上面说到的可以在消息头中指定dataLength,其实还有很多其他的东西可以指定比如:

  • 业务数据格式:文本格式,json格式,html格式等等;

  • 压缩格式:可能为了追求流量包大小对数据包进行压缩,gzip、deflater、snappy等;

  • 加密算法:可能需要对我的业务数据进行加密处理,保证业务数据的安全性AES、DES等;

业务数据

业务数据往往在整个数据包中是最大的,同时也是大小可变的部分;我们上面所做的这些其实都是在为业务数据服务,业务数据需要在网络传输,最重要的一点就是序列化,一般就以下两种方式:

  • 文本方式:序列化文本文档text,或者json串,xml格式等;

  • 二进制方式:常见的比如protobuf,thrift,kyro等;

预留字段

是否需要预留字段这个得看情况,比如http协议整个消息头是可变的,每一行一个标识,知道读取到空行,表示消息头结束下面就是正文了,可以理解为http使用了两种方式来保证完整包,消息头使用特殊字符结尾,正文使用在消息头中指定dataLength;这种方式其实它的整个扩展性是非常好的;
另外一种像dubbo这样,其实它的头部相当于已经固定好了16个字节,这种情况下是否可以预留几个字节防止后面的变更;

“怎么自定义协议”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站,小编将为大家输出更多高质量的实用文章!

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI