郵件標題/前綴應該多長時間？

Question

我已經使用了幾個協議，並自己寫了。我已經寫了一些只有1個字符的消息格式來標識消息，有些消息格式只有4個字符。我並不覺得自己有足夠的經驗去分辨哪個更好，所以我正在尋找一個答案來描述在哪種情況下可能比另一個好。

爲了提高性能，您可以想象，發送2個字節（A%1i）比發送5個字節（ABCD%1i）要快。但是，我注意到，在使用1字節前綴編寫協議時，如果您有一個導致代碼不能從套接字讀取足夠數據的錯誤，那麼您可能會將垃圾數據存入您的系統。

那麼4字節前綴的目的是爲了保證你的消息是乾淨的嗎？對於你的表演來說，它值得嗎？你是否真的對任何表演感到厭惡？也許最好有2或3字節的前綴？

我不確定這個問題應該是特定於TCP還是它適用於所有傳輸協議。對此的建議很有意思。

更新：爲了引起關注，我會提到Synergy使用4字節的消息前綴，因此對於鼠標移動增量，頭部與實際數據大小相同。有些人建議只有1或2字節的前綴來提高效率。我不知道這會有什麼缺點？

更新：此外，我不知道是否只有握手真的很重要，如果你擔心垃圾數據。 Synergy有很長的握手時間（幾個字節），所以需要4字節的消息前綴？我最近制定了一個只有1字節握手的協議，結果這是一個糟糕的主意，因爲不兼容的協議會向系統發送垃圾數​​據（這可能導致數據不準確，我可能會建議至少長時間握手） 。

Answer 1

標題的目的是爲了更容易地解決frame synchronization problem（byte aligning in serial communication）。 爲了同步，接收器在數據流中查找任何「看起來像」消息頭部開頭的東西。 如果你有很多不同類型的有效開始消息頭，並且它們都是1個字節長，那麼你將不可避免地得到很多「錯誤的幀同步」 - 從「看起來像「一個開始的消息頭，但不是。 最好選擇一些其他頭文件，使其「不太可能」使串行數據流中的任何內容「看起來」成爲一個有效的消息開始頭。

無論您如何使用design the packet header，您都將無法避免垃圾數據進入系統。 無論你用什麼來處理這些其他問題（例如在消息中間偶爾出現的位錯誤），也應該足以處理偶然的​​「假幀同步」垃圾。 在某些系統中，任何錯誤的數據都會被新的新數據快速覆蓋，如果您眨眼，則可能永遠不會看到錯誤的數據。 其他系統至少需要某種error detection in the footer來拒絕不良數據。其他系統不僅需要檢測這些錯誤，而且還要不斷重新發送該消息 - 直到雙方都確信該消息的無錯版本已被成功接收。

As Oleksi暗示，在some systems中latency在發送單個二進制位（100ms）和發送10個字節（102.4ms）之間沒有顯着差異。 因此，與使用更詳細的標題的優點相比，使用小標題的優勢（延遲減少2.4％）可能不值得（更容易的調試;更易於向後兼容和向前兼容;更容易測試「獨立」的微小變化的影響，而不將雙方同步升級到與舊協議完全不相容的新協議）。 （a）在很少使用的消息上保留冗長，易於調試的頭文件，以致小頭文件的效果太小而無法測量（我懷疑是幾乎所有的消息），和（b）爲任何類型的消息引入「小標題」格式，其中小標題的效果「明顯更好」或至少可以測量。 看起來Synergy協議足夠靈活，可以以一種與其他類型的郵件標題輕鬆區分的方式添加這樣的「小標題」格式。

我在筆記本電腦和幾臺臺式機之間使用Synergy。我很高興有人試圖讓它變得更好。

Answer 2

性能將取決於您發送的消息內容。如果你的內容是幾千字節，那你的標題有多少字節並不重要。現在，我會選擇最容易處理的方案，因爲與發送的實際數據相比，發送一個字節或四個字節之間的性能差異可以忽略不計。