構建字節協議的技巧

Question

我在設備之間傳遞數據，我必須將協議編程爲字節數組。

在低級別構建協議時有什麼提示？ ..例如：

• 使用一個2字節的頭，在數據字節之前發送消息的長度。
• 使用CRC /數據驗證方案。 （我該怎麼做？任何簡單校驗和？）

Answer 1

1. 在設置結構之前明智地考慮所有情況。
2. 使頭部稍大一點，即使發送零字節。
3. 將標題拆分爲幾個部分。這當然取決於您的要求，例如控制字節，消息長度字節，格式字節等。

關於校驗和，取決於基礎協議。但是你可以自己實現一個。加密，哈希，緊縮，翻轉，2s補充消息並將結果存儲在一個校驗字節中

Answer 2

它取決於底層傳輸層的QoS（服務質量）特性。

如果底層通道是可靠的，那麼CRC可能是矯枉過正的（假設某種形式的完整性檢查在較低的協議層完成）。

如果你問如何到描出您的有效載荷從一個字節流，那麼有幾種可能其中一個可能只是爲Base64編碼/解碼的流。再次，根據您的要求，BASE64可能會轉化爲過多的開銷。

當然，您總是可以在有效載荷中使用HEADER（唯一序列+有效載荷長度+ CRC），發生概率較低，但您需要在有效載荷上應用擾頻器以最大限度地減少重複HEADER的可能性等。

---

如果您正在尋找建立一個協議不可靠的面向字節流的網絡協議，那麼爲什麼另起爐竈？爲什麼不使用像PPP這樣的東西？

Answer 3

仔細想想你是否可以有一個人類可讀的協議
然後考慮是否可以使用壓縮，而不是原始bianry

Answer 4

重要部分取決於設置在下層什麼。這裏有一些例子來解釋我爲什麼重要：

• 我曾經參與過ITU H.223協議的實現。數據流最糟糕的地方可能是基於字節或比特流，而低層只能在原始數據旁邊提供。協議有幾個可能的層次，取決於上層的傳輸可靠性和功能要求。

• 另一個例子是基於TCP的ITU H.225協議，其中傳輸是可靠的，但它是字節流。所以它必須是很好的消息定界邏輯。

• 那麼，基於UDP的SIP。數據報。很有用。但很多麻煩都與消息傳遞的可靠性有關。因此，排序和請求/響應跟蹤（交易，支付......）非常重要。

• 好的，由於某些原因，我們使用RPC協議。好，如果你懶惰。一些與應用程序邏輯有關的限制，但我建議看看這個，甚至只是爲了學習。

• NASA IPC是我不久前看過的東西。好，很簡單，與上層相關。但它是集中的限制。

另一個關鍵點是：您應該設計方案看第一您的需求（分析上層要求）。如果您真的需要這樣做，例如，CRC-32是保護分析過程中數據完整性的最佳方法？

那麼，我認爲這些提到可能會幫助你思考稍有不同的觀點。