去年和今年分別參與了兩個(gè)公司的項(xiàng)目，這兩個(gè)項(xiàng)目都涉及到了通信方面的程序設(shè)計(jì)，或者是以太網(wǎng)絡(luò)通信，或者是串口通信。凡是通信就必須要有通信協(xié)議，個(gè)人認(rèn)為協(xié)議的設(shè)計(jì)是個(gè)非常嚴(yán)肅的工作，需要理解業(yè)務(wù)需求和掌握基本的協(xié)議設(shè)計(jì)知識(shí)。但是從這兩個(gè)項(xiàng)目來(lái)看，其協(xié)議的設(shè)計(jì)可以說(shuō)是 糟糕到了極點(diǎn) 。下面就其糟糕的設(shè)計(jì)之處予以批判。
1 糟糕設(shè)計(jì)之一：消息格式“包頭+數(shù)據(jù)+包尾”
與UDP不同，TCP通信屬于流式通信，沒(méi)有消息邊界，所以需要應(yīng)用層自行對(duì)報(bào)文進(jìn)行界定分離。實(shí)際項(xiàng)目1中，包頭為{{兩個(gè)字節(jié)，包尾為}}兩個(gè)字節(jié)，例如{{t=123}}。其格式為：
開始邊界+消息1+結(jié)束邊界+開始邊界+消息2+結(jié)束邊界+開始邊界+消息3+結(jié)束邊界+....
由于TCP是安全的傳輸層協(xié)議，除非特別需要，應(yīng)用層無(wú)需再做校驗(yàn)。消息邊界只需要一個(gè)標(biāo)識(shí)即可，基本格式為：
消息1+邊界+消息2+邊界+消息3+邊界+...
無(wú)論從節(jié)約網(wǎng)絡(luò)帶寬，還是從簡(jiǎn)化報(bào)文解析代碼，第一種設(shè)計(jì)都是非常的愚蠢!
無(wú)獨(dú)有偶，項(xiàng)目2中基于串口的通信應(yīng)用層協(xié)議也采用了這種設(shè)計(jì)格式。
當(dāng)問(wèn)其設(shè)計(jì)人員為何如此設(shè)計(jì)時(shí)，說(shuō)一直就是這么設(shè)計(jì)的，自己也不知道這么設(shè)計(jì)的原因，還美滋滋地說(shuō)一直沒(méi)有什么問(wèn)題，真想揍他一拳。
2 糟糕設(shè)計(jì)之二：用結(jié)構(gòu)體代碼而不是文本描述消息結(jié)構(gòu)
項(xiàng)目2中，根本無(wú)協(xié)議的描述文本，只有一個(gè)包含結(jié)構(gòu)體定義的頭文件供協(xié)議的使用者參考。
通信就會(huì)涉及到多個(gè)機(jī)器，所以通信協(xié)議必須要能跨平臺(tái)。而我們知道
struct A
{
char x;
int y;
};
在不同編譯器，不同平臺(tái)，不同編譯選項(xiàng)下會(huì)有不同的二進(jìn)制布局。況且協(xié)議使用者也可能看不懂C系語(yǔ)言代碼。更搞笑的是，頭文件中竟然沒(méi)有強(qiáng)制結(jié)構(gòu)體單字節(jié)對(duì)齊。
問(wèn)到協(xié)議的設(shè)計(jì)者設(shè)計(jì)思路時(shí)，說(shuō)我們公司一直這樣啊，一直沒(méi)問(wèn)題啊。之所以沒(méi)有問(wèn)題，是因?yàn)槭褂眠@個(gè)協(xié)議的所有機(jī)器都是同一CPU型號(hào)，同一開發(fā)環(huán)境，同一操作系統(tǒng)。
3 糟糕設(shè)計(jì)之三：傳送二進(jìn)制浮點(diǎn)數(shù)
浮點(diǎn)數(shù)的二進(jìn)制格式并不是只有一種，不同平臺(tái)采用不同的方式存放。這要比大端小端的整數(shù)差別更加嚴(yán)重。所以跨平臺(tái)傳送二進(jìn)制浮點(diǎn)數(shù)是非常不安全的。而在項(xiàng)目2中，消息中大量使用了二進(jìn)制浮點(diǎn)數(shù)。
要傳送浮點(diǎn)數(shù)，通常有兩種解決方式：
文本化。也就是傳送描述浮點(diǎn)數(shù)的字符串，我們知道字符串是完全跨平臺(tái)的，尤其是在UTF-8這樣全球統(tǒng)一字符編碼的情況下。
轉(zhuǎn)換為整數(shù)。例如1.2，可以用整數(shù)12代替，只是要規(guī)定單位為0.1即可。
4 糟糕設(shè)計(jì)之三：大量備用字段
項(xiàng)目二的消息結(jié)構(gòu)體類似如下：
struct A
{
char name[16];
int age;
int spare1;
short spare2;
short spare3;
int spare4;
};
大量的備用字段充斥在結(jié)構(gòu)體中。少量的備用字段可以理解，如此大量的后備力量，真是深遠(yuǎn)謀慮啊。真不知道協(xié)議使用者在看到spare時(shí)會(huì)不會(huì)吐。如果真的需要這么多備用字段，完全可以重新定義一個(gè)消息結(jié)構(gòu)了。
5 糟糕設(shè)計(jì)之四：照貓畫虎的握手和校驗(yàn)
握手和校驗(yàn)是保證安全完整通信的基本手段，但是其實(shí)現(xiàn)卻非常不簡(jiǎn)單，看看TCP的實(shí)現(xiàn)代碼就知道了，需要考慮各種異常情況。項(xiàng)目二中串口設(shè)備和主機(jī)之間照貓畫虎地定義了一個(gè)握手協(xié)議。開機(jī)后 設(shè)備向主機(jī)一直發(fā)送AA，主機(jī)收到AA后向設(shè)備發(fā)送AA，設(shè)備收到AA后向主機(jī)發(fā)送55，主機(jī)收到55后向設(shè)備發(fā)送55。這個(gè)簡(jiǎn)單的握手存在很多問(wèn)題，隨便說(shuō)幾個(gè)：
完全沒(méi)有必要握手。一般的串口設(shè)備無(wú)需知道主機(jī)的工作狀態(tài)，主機(jī)如果想了解設(shè)備狀態(tài)，發(fā)個(gè)詢問(wèn)報(bào)文即可。
如果主機(jī)發(fā)送AA后程序退出，那么串口設(shè)備永遠(yuǎn)也等不到來(lái)自主機(jī)的55。
如果主機(jī)中途關(guān)掉，在運(yùn)行時(shí)可能收到來(lái)自串口設(shè)備的AA，而此時(shí)的AA其實(shí)只是消息報(bào)文的一個(gè)字節(jié)，而不是握手信號(hào)。
只要仔細(xì)想想，還有很多類似的情況需要處理。而且實(shí)際使用過(guò)程中，確實(shí)發(fā)生了上面的情況，致使必須重啟串口設(shè)備或主機(jī)。