TCP是個“流”協議，所謂流，就是沒有界限的一串數據。大家可以想象河里的流水，他們是連成一片的，其間并沒有分界線。TCP底層并不了解上層業務數據的具體含義，他會根據TCP緩沖區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆分成多個包進行發送，也有可能把多個小的包封裝成一個大的數據包發送。這就是TCP所謂的拆包和粘包的問題。

一、TCP粘包/拆包問題說明

我們可以通過圖解對TCP粘包和拆包問題進行說明，粘包問題如圖。

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

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

如果此時服務端TCP接收滑窗非常小，而數據包D1和D2比較大，很有可能會發生第五種可能，即服務端分多次才能將D1和D2包接收完全，期間發生多次拆包。

二、TCP粘包/拆包發生的原因

問題產生的原因有三個，分別如下。

應用程序write寫入的字節大小大于套接口發送緩沖區大小。
進行MSS大小的TCP分段。
以太網幀的payload大于MTU進行IP分片。

三、粘包問題的解決策略

由于底層的TCP無法理解上層的業務數據，所以在底層是無法保證數據包不被拆分和重組的，這個問題只能通過上層的應用協議棧設計來解決，根據業界的主流協議的解決方案，可以歸納如下。

消息定長，例如每個報文的大小為固定長度200字節，如果不夠，空位補空格
在包尾增加回車換行符進行分割，例如FTP協議
將消息分為消息頭和消息體，消息頭中包含表示消息總長度(或者消息體長度)的字段，通常涉及思路為消息頭的第一個字段使用int32來表示消息的總長度
更復雜的應用層協議。

總結

以上是生活随笔為你收集整理的Java网络编程基础之TCP粘包拆包的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。