去年和今年分別參與了兩個公司的項目，這兩個項目都涉及到了通信方面的程序設(shè)計，或者是以太網(wǎng)絡(luò)通信，或者是串口通信。凡是通信就必須要有通信協(xié)議，個人認(rèn)為協(xié)議的設(shè)計是個非常嚴(yán)肅的工作，需要理解業(yè)務(wù)需求和掌握基本的協(xié)議設(shè)計知識。但是從這兩個項目來看，其協(xié)議的設(shè)計可以說是 糟糕到了極點。下面就其糟糕的設(shè)計之處予以批判。

1 糟糕設(shè)計之一：消息格式“包頭+數(shù)據(jù)+包尾”

與UDP不同，TCP通信屬于流式通信，沒有消息邊界，所以需要應(yīng)用層自行對報文進(jìn)行界定分離。實際項目1中，包頭為{{兩個字節(jié)，包尾為}}兩個字節(jié)，例如{{t=123}}。其格式為：

開始邊界+消息1+結(jié)束邊界+開始邊界+消息2+結(jié)束邊界+開始邊界+消息3+結(jié)束邊界+....

由于TCP是安全的傳輸層協(xié)議，除非特別需要，應(yīng)用層無需再做校驗。消息邊界只需要一個標(biāo)識即可，基本格式為：

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

無論從節(jié)約網(wǎng)絡(luò)帶寬，還是從簡化報文解析代碼，***種設(shè)計都是非常的愚蠢!

無獨有偶，項目2中基于串口的通信應(yīng)用層協(xié)議也采用了這種設(shè)計格式。

當(dāng)問其設(shè)計人員為何如此設(shè)計時，說一直就是這么設(shè)計的，自己也不知道這么設(shè)計的原因，還美滋滋地說一直沒有什么問題，真想揍他一拳。

2 糟糕設(shè)計之二：用結(jié)構(gòu)體代碼而不是文本描述消息結(jié)構(gòu)

項目2中，根本無協(xié)議的描述文本，只有一個包含結(jié)構(gòu)體定義的頭文件供協(xié)議的使用者參考。

通信就會涉及到多個機器，所以通信協(xié)議必須要能跨平臺。而我們知道

struct A
{
char x;
int y;
};

在不同編譯器，不同平臺，不同編譯選項下會有不同的二進(jìn)制布局。況且協(xié)議使用者也可能看不懂C系語言代碼。更搞笑的是，頭文件中竟然沒有強制結(jié)構(gòu)體單字節(jié)對齊。

問到協(xié)議的設(shè)計者設(shè)計思路時，說我們公司一直這樣啊，一直沒問題啊。之所以沒有問題，是因為使用這個協(xié)議的所有機器都是同一CPU型號，同一開發(fā)環(huán)境，同一操作系統(tǒng)。

3 糟糕設(shè)計之三：傳送二進(jìn)制浮點數(shù)

浮點數(shù)的二進(jìn)制格式并不是只有一種，不同平臺采用不同的方式存放。這要比大端小端的整數(shù)差別更加嚴(yán)重。所以跨平臺傳送二進(jìn)制浮點數(shù)是非常不安全的。而在項目2中，消息中大量使用了二進(jìn)制浮點數(shù)。

要傳送浮點數(shù)，通常有兩種解決方式：

文本化。也就是傳送描述浮點數(shù)的字符串，我們知道字符串是完全跨平臺的，尤其是在UTF-8這樣全球統(tǒng)一字符編碼的情況下。

轉(zhuǎn)換為整數(shù)。例如1.2，可以用整數(shù)12代替，只是要規(guī)定單位為0.1即可。

4 糟糕設(shè)計之三：大量備用字段

項目二的消息結(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時會不會吐。如果真的需要這么多備用字段，完全可以重新定義一個消息結(jié)構(gòu)了。

5 糟糕設(shè)計之四：照貓畫虎的握手和校驗

握手和校驗是保證安全完整通信的基本手段，但是其實現(xiàn)卻非常不簡單，看看TCP的實現(xiàn)代碼就知道了，需要考慮各種異常情況。項目二中串口設(shè)備和主機之間照貓畫虎地定義了一個握手協(xié)議。開機后 設(shè)備向主機一直發(fā)送AA，主機收到AA后向設(shè)備發(fā)送AA，設(shè)備收到AA后向主機發(fā)送55，主機收到55后向設(shè)備發(fā)送55。這個簡單的握手存在很多問題，隨便說幾個：

完全沒有必要握手。一般的串口設(shè)備無需知道主機的工作狀態(tài)，主機如果想了解設(shè)備狀態(tài)，發(fā)個詢問報文即可。

如果主機發(fā)送AA后程序退出，那么串口設(shè)備永遠(yuǎn)也等不到來自主機的55。

如果主機中途關(guān)掉，在運行時可能收到來自串口設(shè)備的AA，而此時的AA其實只是消息報文的一個字節(jié)，而不是握手信號。

只要仔細(xì)想想，還有很多類似的情況需要處理。而且實際使用過程中，確實發(fā)生了上面的情況，致使必須重啟串口設(shè)備或主機。

還是項目2中，基于UDP的應(yīng)用層協(xié)議自行設(shè)計了校驗。其實這也無可厚非，比如著名的tftp就是這樣的協(xié)議。只是設(shè)計者考慮不周，各種問題頻出，最終的結(jié)果是這些校驗字段根本就沒有實際使用，白白浪費了網(wǎng)絡(luò)帶寬。需要說明的是，這個協(xié)議的設(shè)計者還是國內(nèi)很大的一家公司，當(dāng)然是國企，你懂的