去年和今年分别参与了两个公司的项目，这两个项目都涉及到了通信方面的程序设计，或者是以太网络通信，或者是串口通信。凡是通信就必须要有通信协议，个人认为协议的设计是个非常严肃的工作，需要理解业务需求和掌握基本的协议设计知识。但是从这两个项目来看，其协议的设计可以说是 糟糕到了极点 。下面就其糟糕的设计之处予以批判。
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其实只是消息报文的一个字节，而不是握手信号。
只要仔细想想，还有很多类似的情况需要处理。而且实际使用过程中，确实发生了上面的情况，致使必须重启串口设备或主机。