应用层协议设计的反面教材

2016/09/13 16:52
阅读数 444

1 糟糕设计之一:消息格式“包头+数据+包尾”

  与UDP不同,TCP通信属于流式通信,没有消息边界,所以需要应用层自行对报文进行界定分离。实际项目1中,包头为{{两个字节,包尾为}}两个字节,例如{{t=123}}。其格式为:

  开始边界+消息1+结束边界+开始边界+消息2+结束边界+开始边界+消息3+结束边界+....

  由于TCP是安全的传输层协议,除非特别需要,应用层无需再做校验。消息边界只需要一个标识即可,基本格式为:

  消息1+边界+消息2+边界+消息3+边界+...

  无论从节约网络带宽,还是从简化报文解析代码,第一种设计都是非常的愚蠢!

  无独有偶,项目2中基于串口的通信应用层协议也采用了这种设计格式。

  当问其设计人员为何如此设计时,说一直就是这么设计的,自己也不知道这么设计的原因,还美滋滋地说一直没有什么问题,真想揍他一拳。

  2 糟糕设计之二:用结构体代码而不是文本描述消息结构

  项目2中,根本无协议的描述文本,只有一个包含结构体定义的头文件供协议的使用者参考。

  通信就会涉及到多个机器,所以通信协议必须要能跨平台。而我们知道

  struct A

  {

  char x;

  int y;

  };

  在不同编译器,不同平台,不同编译选项下会有不同的二进制布局。况且协议使用者也可能看不懂C系语言代码。更搞笑的是,头文件中竟然没有强制结构体单字节对齐。

  问到协议的设计者设计思路时,说我们公司一直这样啊,一直没问题啊。之所以没有问题,是因为使用这个协议的所有机器都是同一CPU型号,同一开发环境,同一操作系统。

  3 糟糕设计之三:传送二进制浮点数

  浮点数的二进制格式并不是只有一种,不同平台采用不同的方式存放。这要比大端小端的整数差别更加严重。所以跨平台传送二进制浮点数是非常不安全的。而在项目2中,消息中大量使用了二进制浮点数。

  要传送浮点数,通常有两种解决方式:

  文本化。也就是传送描述浮点数的字符串,我们知道字符串是完全跨平台的,尤其是在UTF-8这样全球统一字符编码的情况下。

  转换为整数。例如1.2,可以用整数12代替,只是要规定单位为0.1即可。

  4 糟糕设计之三:大量备用字段

  项目二的消息结构体类似如下:

  struct A

  {

  char name[16];

  int age;

  int spare1;

  short spare2;

  short spare3;

  int spare4;

  };

  大量的备用字段充斥在结构体中。少量的备用字段可以理解,如此大量的后备力量,真是深远谋虑啊。真不知道协议使用者在看到spare时会不会吐。如果真的需要这么多备用字段,完全可以重新定义一个消息结构了。

  5 糟糕设计之四:照猫画虎的握手和校验

  握手和校验是保证安全完整通信的基本手段,但是其实现却非常不简单,看看TCP的实现代码就知道了,需要考虑各种异常情况。项目二中串口设备和主机之间照猫画虎地定义了一个握手协议。开机后 设备向主机一直发送AA,主机收到AA后向设备发送AA,设备收到AA后向主机发送55,主机收到55后向设备发送55。这个简单的握手存在很多问题,随便说几个:

  完全没有必要握手。一般的串口设备无需知道主机的工作状态,主机如果想了解设备状态,发个询问报文即可。

  如果主机发送AA后程序退出,那么串口设备永远也等不到来自主机的55。

  如果主机中途关掉,在运行时可能收到来自串口设备的AA,而此时的AA其实只是消息报文的一个字节,而不是握手信号。

  只要仔细想想,还有很多类似的情况需要处理。而且实际使用过程中,确实发生了上面的情况,致使必须重启串口设备或主机。

  还是项目2中,基于UDP的应用层协议自行设计了校验。其实这也无可厚非,比如著名的tftp就是这样的协议。只是设计者考虑不周,各种问题频出,最终的结果是这些校验字段根本就没有实际使用,白白浪费了网络带宽。需要说明的是,这个协议的设计者还是国内很大的一家公司,当然是国企,你懂的。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部