去年和今年分別參與了兩個公司的項目，這兩個項目都涉及到了通信方面的程序設計，或者是以太網絡通信，或者是串口通信。凡是通信就必須要有通信協議，個人認為協議的設計是個非常嚴肅的工作，需要理解業務需求和掌握基本的協議設計知識。但是從這兩個項目來看，其協議的設計可以說是 糟糕到了極點。下面就其糟糕的設計之處予以批判。
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就是這樣的協議。只是設計者考慮不周，各種問題頻出，最終的結果是這些校驗字段根本就沒有實際使用，白白浪費了網絡帶寬。需要說明的是，這個協議的設計者還是國內很大的一家公司，當然是國企，你懂的
京公網安備 11010502049343號