.NET中的消息構造方法優點和缺點

Question

我正在研究我知道的兩種不同的TCP消息構架方法的優缺點。

1. 分界符：TCP流通過使用分隔符字節分解爲非固定長度的消息。發送數據時，例程必須檢查分隔符的消息數據並將其轉義以確保消息幀的安全傳輸。當接收數據時，例程必須通過流來讀取分隔符字節以將幀分解爲消息。

EG：用戶[用戶名] \ n密碼[密碼] \ n上

1. 長度前綴：該TCP流被分成預定大小的消息通過使用一個前綴說4個字節爲狀態消息的長度。例程在接收數據時將首先讀取前綴以確定消息幀的長度。發送數據時，例程必須在發送之前將長度前綴添加到消息中。

EG：[MessageLength]用戶[用戶名] [MessageLength]密碼[密碼]

這些方法都允許將被解釋，可以在尺寸上變化，並且包含一個字節流的消息幀的傳輸。較高級別的消息結構或協議不相關。

---

因此，我將注意力集中在可伸縮性和性能效率上。我發現自己需要運行基準測試，以查看哪種方法可以在不涉及任何消息處理的情況下獲得最高的效率吞吐量。

---

我目前的想法，我不是專家的任何手段。

定界消息幀在接收例程期間效率較低，因爲流中的每個字節都需要檢查消息幀定界符。長度爲前綴的消息幀將始終讀取前綴字節，並且消息幀流的其餘部分將直接進入緩衝區而不進行處理，直到接收到整個消息幀爲止。

作爲長度 - 前綴消息幀在發送例程期間作爲消息前綴將在消息本身之前傳輸的效率較低。

---

我能想到的可能包括其他因素：

• 許多小消息幀將導致一個長度爲前綴的結構正在發送更多的數據包。
• 由於沒有讀取每個字節以檢查分隔符，因此使用長度前綴結構可以更有效地處理大量較大的消息幀。

---

過這個話題的任何光線將是真棒。我發現很難找到有關TCP消息幀結構之間差異的良好資源。

Answer 1

從我的經驗來看，長度前綴是首選，消息的解析代碼往往更容易編寫。

此外，使用消息分隔符，如果消息有效載荷可能包含分隔符，則需要找出轉義方案。

我遇到了第三個方案，不是有效載荷不可知的。它定義了已知格式的不同消息類型，消息的不同部分可以是固定長度或可變長度。 （固定爲簡單的類型和變量是數組和字符串）。預先在客戶端和服務器之間共享結構。發送消息時，消息的前綴爲消息類型編號。接收部分從消息類型編號中可以推導出如何解析消息。
這是LysKOM消息系統的protocol的一個示例。
該協議有一個可用於生成解析器代碼的正式規範。