UDP（user datagram protocol，用戶數據報協議）是無連接的，面向消息的，提供高效率服務。不會使用塊的合并優化算，, 由于UDP支持的是一對多的模式，所以接收端的skbuff(套接字緩沖區）采用了鏈式結構來記錄每一個到達的UDP包，在每個UDP包中就有了消息頭（消息來源地址，端口等信息），這樣，對于接收端來說，就容易進行區分處理了。 即面向消息的通信是有消息保護邊界的。

TCP（transport control protocol，傳輸控制協議）是面向連接的，面向流的，提供高可靠性服務。收發兩端（客戶端和服務器端）都要有一一成對的socket，因此，發送端為了將多個發往接收端的包，更有效的發到對方，使用了優化方法（Nagle算法），將多次間隔較小且數據量小的數據，合并成一個大的數據塊，然后進行封包。這樣，接收端，就難于分辨出來了，必須提供科學的拆包機制。即面向流的通信是無消息保護邊界的。

1 TCP粘包、拆包圖解

假設客戶端分別發送了兩個數據包D1和D2給服務端，由于服務端一次讀取到字節數是不確定的，故可能存在以下四種情況：

• 服務端分兩次讀取到了兩個獨立的數據包，分別是D1和D2，沒有粘包和拆包
• 服務端一次接受到了兩個數據包，D1和D2粘合在一起，稱之為TCP粘包
• 服務端分兩次讀取到了數據包，第一次讀取到了完整的D1包和D2包的部分內容，第二次讀取到了D2包的剩余內容，這稱之為TCP拆包
• 服務端分兩次讀取到了數據包，第一次讀取到了D1包的部分內容D1_1，第二次讀取到了D1包的剩余部分內容D1_2和完整的D2包。

特別要注意的是，如果TCP的接受滑窗非常小，而數據包D1和D2比較大，很有可能會發生第五種情況，即服務端分多次才能將D1和D2包完全接受，期間發生多次拆包。

2 發生原因

• socket緩沖區與滑動窗口
• MSS/MTU限制
• Nagle算法

具體請看粘包、拆包產生原因：

https://zhuanlan.zhihu.com/p/103616849

3 解決方案：定義通信協議

通過定義應用的協議(protocol)來解決。協議的作用就定義傳輸數據的格式。這樣在接受到的數據的時候，如果粘包了，就可以根據這個格式來區分不同的包，如果拆包了，就等待數據可以構成一個完整的消息來處理。目前業界主流的協議(protocol)方案可以歸納如下：

1 定長協議：假設我們規定每3個字節，表示一個有效報文，如果我們分4次總共發送以下9個字節：

 +---+----+------+----+
 | A | BC | DEFG | HI |
 +---+----+------+----+

那么根據協議，我們可以判斷出來，這里包含了3個有效的請求報文

 +-----+-----+-----+
 | ABC | DEF | GHI |
 +-----+-----+-----+

2 特殊字符分隔符協議：在包尾部增加回車或者空格符等特殊字符進行分割 。

例如，按行解析，遇到字符n、rn的時候，就認為是一個完整的數據包。對于以下二進制字節流：

 +--------------+
 | ABCnDEFrn |
 +--------------+

那么根據協議，我們可以判斷出來，這里包含了2個有效的請求報文

 +-----+-----+
 | ABC | DEF |
 +-----+-----+

3 長度編碼：將消息分為消息頭和消息體，消息頭中用一個int型數據(4字節)，表示消息體長度的字段。在解析時，先讀取內容長度Length，其值為實際消息體內容(Content)占用的字節數，之后必須讀取到這么多字節的內容，才認為是一個完整的數據報文。

 header    body
+--------+----------+
| Length | Content |
+--------+----------+

總的來說，通信協議就是通信雙方約定好的數據格式，發送方按照這個數據格式來發送，接受方按照這個格式來解析。因此發送方和接收方要完成的工作不同，發送方要將發送的數據轉換成協議規定的格式，稱之為編碼(encode)；接收方需要根據協議的格式，對二進制數據進行解析，稱之為解碼(decode)。