TCP協議粘包和拆包解析

TCP是一個"流"協議,沒有邊界的一段數據.像打開自來水管同樣,連成一片,沒有邊界.設計

TCP協議並不瞭解上層的業務在作什麼東西,有什麼含義,它會根據本身的緩衝區的實際狀況進行數據包的劃分.圖片

因此,一個完整的數據包可能會被拆分紅多個數據包包進行發送,也有可能將不少個數據包變成一個大的數據包發送.it

這就是TCP的粘包和拆包問題.程序

輸入圖片說明

假設客戶端分別發送兩個數據包D1和D2給服務端.因爲服務端一次讀取到的字節數不肯定,可能存在4種狀況.im

(1)服務端分別接收到 D1 和 D2.沒有拆包和粘包.數據

(2)D1和D2包被一次接收了(粘包)客戶端

(3)D1包被一次接收,D2包被分兩次接受(拆包)協議

(4)D1和D2都被拆開,分兩次讀取完成.img

(5)D1和D2被拆分N個,分N次讀取完成.服務端

查閱資料後找到了爲何會發生以上的緣由:

(1)程序的寫入的字節大於發送數據的緩衝區大小(我只看懂了這個)

(2)進行MSS大小的TCP分段

(3)以太網幀的payload大於MTU進行IP分片

2和3表示看不懂啊.

** 一般的解決方案**

TCP是不知道上層的業務數據的.因此在底層沒法保證不發生粘包拆包,這個問題只能經過上層應用協議棧的設計來解決.

(1)消息定長,固定大小,不夠空格補位(5樓不輔助,你懂的,要學會補位.)

(2)包尾增長回車符,進行分割

(3)將消息分爲消息頭和消息體,消息頭裏來標識消息總長度.

相關文章
相關標籤/搜索