去年和今年分別參與了兩個(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)目來看，其協(xié)議的設(shè)計(jì)可以說是 糟糕到了極點(diǎn)。下面就其糟糕的設(shè)計(jì)之處予以批判。

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

與UDP不同，TCP通信屬于流式通信，沒有消息邊界，所以需要應(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)用層無需再做校驗(yàn)。消息邊界只需要一個(gè)標(biāo)識(shí)即可，基本格式為：

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

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

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

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

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

項(xiàng)目2中，根本無協(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系語言代碼。更搞笑的是，頭文件中竟然沒有強(qiáng)制結(jié)構(gòu)體單字節(jié)對(duì)齊。

問到協(xié)議的設(shè)計(jì)者設(shè)計(jì)思路時(shí)，說我們公司一直這樣啊，一直沒問題啊。之所以沒有問題，是因?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)卻非常不簡單，看看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è)簡單的握手存在很多問題，隨便說幾個(gè)：

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

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

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

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

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