作者 | 王磊

來源 | Java中文社群（ID：javacn666）

大家好，我是躍哥。躍哥之前使用過Socket，同時(shí)在前面的Java學(xué)習(xí)之路上，也提到過Socket通信可以很好的作為練手項(xiàng)目進(jìn)行Java 學(xué)習(xí)。但是，Socket 學(xué)起來簡單，用起來的時(shí)候，不免會(huì)遇到各種各樣的問題。

粘包就是一個(gè)很煩躁的問題，是吧？簡短的數(shù)據(jù)傳輸可能沒什么問題，但是遇到冗長的數(shù)據(jù)傳輸，你在使用的時(shí)候會(huì)有疑問：咦？我的數(shù)據(jù)怎么不全呀？怎么這么奇怪？那我們就來探索下，王哥給我們的方案，來搞懂粘包問題吧。

在 ?Java 語言中，傳統(tǒng)的 Socket 編程分為兩種實(shí)現(xiàn)方式，這兩種實(shí)現(xiàn)方式也對應(yīng)著兩種不同的傳輸層協(xié)議：TCP 協(xié)議和 UDP 協(xié)議，但作為互聯(lián)網(wǎng)中最常用的傳輸層協(xié)議 TCP，在使用時(shí)卻會(huì)導(dǎo)致粘包和半包問題，于是為了徹底的解決此問題，便誕生了此篇文章。

什么是 TCP 協(xié)議？

TCP 全稱是 Transmission Control Protocol（傳輸控制協(xié)議），它由 IETF 的 RFC 793 定義，是一種面向連接的點(diǎn)對點(diǎn)的傳輸層通信協(xié)議。

TCP 通過使用序列號(hào)和確認(rèn)消息，從發(fā)送節(jié)點(diǎn)提供有關(guān)傳輸?shù)侥繕?biāo)節(jié)點(diǎn)的數(shù)據(jù)包的傳遞的信息。TCP 確保數(shù)據(jù)的可靠性，端到端傳遞，重新排序和重傳，直到達(dá)到超時(shí)條件或接收到數(shù)據(jù)包的確認(rèn)為止。

TCP 是 Internet 上最常用的協(xié)議，它也是實(shí)現(xiàn) HTTP（HTTP 1.0/HTTP 2.0）通訊的基礎(chǔ)，當(dāng)我們在瀏覽器中請求網(wǎng)頁時(shí)，計(jì)算機(jī)會(huì)將 TCP 數(shù)據(jù)包發(fā)送到 Web 服務(wù)器的地址，要求它將網(wǎng)頁返還給我們，Web 服務(wù)器通過發(fā)送 TCP 數(shù)據(jù)包流進(jìn)行響應(yīng)，然后瀏覽器將這些數(shù)據(jù)包縫合在一起以形成網(wǎng)頁。

TCP 的全部意義在于它的可靠性，它通過對數(shù)據(jù)包編號(hào)來對其進(jìn)行排序，而且它會(huì)通過讓服務(wù)器將響應(yīng)發(fā)送回瀏覽器說“已收到”來進(jìn)行錯(cuò)誤檢查，因此在傳輸過程中不會(huì)丟失或破壞任何數(shù)據(jù)。

目前市場上主流的 HTTP 協(xié)議使用的版本是 HTTP/1.1，如下圖所示：

什么是粘包和半包問題？

粘包問題是指當(dāng)發(fā)送兩條消息時(shí)，比如發(fā)送了 ABC 和 DEF，但另一端接收到的卻是 ABCD，像這種一次性讀取了兩條數(shù)據(jù)的情況就叫做粘包（正常情況應(yīng)該是一條一條讀取的）。

半包問題是指，當(dāng)發(fā)送的消息是 ABC 時(shí)，另一端卻接收到的是 AB 和 C 兩條信息，像這種情況就叫做半包。

為什么會(huì)有粘包和半包問題？

這是因?yàn)?TCP 是面向連接的傳輸協(xié)議，TCP 傳輸?shù)臄?shù)據(jù)是以流的形式，而流數(shù)據(jù)是沒有明確的開始結(jié)尾邊界，所以 TCP 也沒辦法判斷哪一段流屬于一個(gè)消息。

粘包的主要原因：

發(fā)送方每次寫入數(shù)據(jù) < 套接字（Socket）緩沖區(qū)大小；
接收方讀取套接字（Socket）緩沖區(qū)數(shù)據(jù)不夠及時(shí)。

半包的主要原因：

發(fā)送方每次寫入數(shù)據(jù) > 套接字（Socket）緩沖區(qū)大??；
發(fā)送的數(shù)據(jù)大于協(xié)議的 MTU (Maximum Transmission Unit，最大傳輸單元)，因此必須拆包。

小知識(shí)點(diǎn)：什么是緩沖區(qū)？

緩沖區(qū)又稱為緩存，它是內(nèi)存空間的一部分。也就是說，在內(nèi)存空間中預(yù)留了一定的存儲(chǔ)空間，這些存儲(chǔ)空間用來緩沖輸入或輸出的數(shù)據(jù)，這部分預(yù)留的空間就叫做緩沖區(qū)。

緩沖區(qū)的優(yōu)勢以文件流的寫入為例，如果我們不使用緩沖區(qū)，那么每次寫操作 CPU 都會(huì)和低速存儲(chǔ)設(shè)備也就是磁盤進(jìn)行交互，那么整個(gè)寫入文件的速度就會(huì)受制于低速的存儲(chǔ)設(shè)備（磁盤）。但如果使用緩沖區(qū)的話，每次寫操作會(huì)先將數(shù)據(jù)保存在高速緩沖區(qū)內(nèi)存上，當(dāng)緩沖區(qū)的數(shù)據(jù)到達(dá)某個(gè)閾值之后，再將文件一次性寫入到磁盤上。因?yàn)閮?nèi)存的寫入速度遠(yuǎn)遠(yuǎn)大于磁盤的寫入速度，所以當(dāng)有了緩沖區(qū)之后，文件的寫入速度就被大大提升了。

粘包和半包問題演示

接下來我們用代碼來演示一下粘包和半包問題，為了演示的直觀性，我會(huì)設(shè)置兩個(gè)角色：

服務(wù)器端用來接收消息；
客戶端用來發(fā)送一段固定的消息。

然后通過打印服務(wù)器端接收到的信息來觀察粘包和半包問題。

服務(wù)器端代碼如下：

/**
?*?服務(wù)器端（只負(fù)責(zé)接收消息）
?*/
class?ServSocket?{
????//?字節(jié)數(shù)組的長度
????private?static?final?int?BYTE_LENGTH?=?20;??
????public?static?void?main(String[]?args)?throws?IOException?{
????????//?創(chuàng)建?Socket?服務(wù)器
????????ServerSocket?serverSocket?=?new?ServerSocket(9999);
????????//?獲取客戶端連接
????????Socket?clientSocket?=?serverSocket.accept();
????????//?得到客戶端發(fā)送的流對象
????????try?(InputStream?inputStream?=?clientSocket.getInputStream())?{
????????????while?(true)?{
????????????????//?循環(huán)獲取客戶端發(fā)送的信息
????????????????byte[]?bytes?=?new?byte[BYTE_LENGTH];
????????????????//?讀取客戶端發(fā)送的信息
????????????????int?count?=?inputStream.read(bytes,?0,?BYTE_LENGTH);
????????????????if?(count?>?0)?{
????????????????????//?成功接收到有效消息并打印
????????????????????System.out.println("接收到客戶端的信息是:"?+?new?String(bytes));
????????????????}
????????????????count?=?0;
????????????}
????????}
????}
}

客戶端代碼如下：

/**
?*?客戶端（只負(fù)責(zé)發(fā)送消息）
?*/
static?class?ClientSocket?{
????public?static?void?main(String[]?args)?throws?IOException?{
????????//?創(chuàng)建?Socket?客戶端并嘗試連接服務(wù)器端
????????Socket?socket?=?new?Socket("127.0.0.1",?9999);
????????//?發(fā)送的消息內(nèi)容
????????final?String?message?=?"Hi,Java.";?
????????//?使用輸出流發(fā)送消息
????????try?(OutputStream?outputStream?=?socket.getOutputStream())?{
????????????//?給服務(wù)器端發(fā)送?10?次消息
????????????for?(int?i?=?0;?i?10;?i++)?{
????????????????//?發(fā)送消息
????????????????outputStream.write(message.getBytes());
????????????}
????????}
????}
}

以上程序的通訊結(jié)果如下圖所示：

通過上述結(jié)果我們可以看出，服務(wù)器端發(fā)生了粘包和半包的問題，因?yàn)榭蛻舳税l(fā)送了 10 次固定的“Hi,Java.”的消息，正常的結(jié)果應(yīng)該是服務(wù)器端也接收到了 10 次固定的消息才對，但現(xiàn)實(shí)的結(jié)果并非如此。

粘包和半包的解決方案

粘包和半包的解決方案有以下 3 種：

發(fā)送方和接收方規(guī)定固定大小的緩沖區(qū)，也就是發(fā)送和接收都使用固定大小的 byte[] 數(shù)組長度，當(dāng)字符長度不夠時(shí)使用空字符彌補(bǔ)；
在 TCP 協(xié)議的基礎(chǔ)上封裝一層數(shù)據(jù)請求協(xié)議，既將數(shù)據(jù)包封裝成數(shù)據(jù)頭（存儲(chǔ)數(shù)據(jù)正文大?。? 數(shù)據(jù)正文的形式，這樣在服務(wù)端就可以知道每個(gè)數(shù)據(jù)包的具體長度了，知道了發(fā)送數(shù)據(jù)的具體邊界之后，就可以解決半包和粘包的問題了；
以特殊的字符結(jié)尾，比如以“\n”結(jié)尾，這樣我們就知道結(jié)束字符，從而避免了半包和粘包問題（推薦解決方案）。

那么接下來我們就來演示一下，以上解決方案的具體代碼實(shí)現(xiàn)。

解決方案1：固定緩沖區(qū)大小

固定緩沖區(qū)大小的實(shí)現(xiàn)方案，只需要控制服務(wù)器端和客戶端發(fā)送和接收字節(jié)的（數(shù)組）長度相同即可。

服務(wù)器端實(shí)現(xiàn)代碼如下：

/**
?*?服務(wù)器端，改進(jìn)版本一（只負(fù)責(zé)接收消息）
?*/
static?class?ServSocketV1?{
????private?static?final?int?BYTE_LENGTH?=?1024;??//?字節(jié)數(shù)組長度（收消息用）
????public?static?void?main(String[]?args)?throws?IOException?{
????????ServerSocket?serverSocket?=?new?ServerSocket(9091);
????????//?獲取到連接
????????Socket?clientSocket?=?serverSocket.accept();
????????try?(InputStream?inputStream?=?clientSocket.getInputStream())?{
????????????while?(true)?{
????????????????byte[]?bytes?=?new?byte[BYTE_LENGTH];
????????????????//?讀取客戶端發(fā)送的信息
????????????????int?count?=?inputStream.read(bytes,?0,?BYTE_LENGTH);
????????????????if?(count?>?0)?{
????????????????????//?接收到消息打印
????????????????????System.out.println("接收到客戶端的信息是:"?+?new?String(bytes).trim());
????????????????}
????????????????count?=?0;
????????????}
????????}
????}
}

客戶端實(shí)現(xiàn)代碼如下：

/**
?*?客戶端，改進(jìn)版一（只負(fù)責(zé)接收消息）
?*/
static?class?ClientSocketV1?{
????private?static?final?int?BYTE_LENGTH?=?1024;??//?字節(jié)長度
????public?static?void?main(String[]?args)?throws?IOException?{
????????Socket?socket?=?new?Socket("127.0.0.1",?9091);
????????final?String?message?=?"Hi,Java.";?//?發(fā)送消息
????????try?(OutputStream?outputStream?=?socket.getOutputStream())?{
????????????//?將數(shù)據(jù)組裝成定長字節(jié)數(shù)組
????????????byte[]?bytes?=?new?byte[BYTE_LENGTH];
????????????int?idx?=?0;
????????????for?(byte?b?:?message.getBytes())?{
????????????????bytes[idx]?=?b;
????????????????idx++;
????????????}
????????????//?給服務(wù)器端發(fā)送?10?次消息
????????????for?(int?i?=?0;?i?10;?i++)?{
????????????????outputStream.write(bytes,?0,?BYTE_LENGTH);
????????????}
????????}
????}
}

以上代碼的執(zhí)行結(jié)果如下圖所示：

優(yōu)缺點(diǎn)分析

從以上代碼可以看出，雖然這種方式可以解決粘包和半包的問題，但這種固定緩沖區(qū)大小的方式增加了不必要的數(shù)據(jù)傳輸，因?yàn)檫@種方式當(dāng)發(fā)送的數(shù)據(jù)比較小時(shí)會(huì)使用空字符來彌補(bǔ)，所以這種方式就大大的增加了網(wǎng)絡(luò)傳輸?shù)呢?fù)擔(dān)，所以它也不是最佳的解決方案。

解決方案二：封裝請求協(xié)議

這種解決方案的實(shí)現(xiàn)思路是將請求的數(shù)據(jù)封裝為兩部分：數(shù)據(jù)頭+數(shù)據(jù)正文，在數(shù)據(jù)頭中存儲(chǔ)數(shù)據(jù)正文的大小，當(dāng)讀取的數(shù)據(jù)小于數(shù)據(jù)頭中的大小時(shí)，繼續(xù)讀取數(shù)據(jù)，直到讀取的數(shù)據(jù)長度等于數(shù)據(jù)頭中的長度時(shí)才停止。

因?yàn)檫@種方式可以拿到數(shù)據(jù)的邊界，所以也不會(huì)導(dǎo)致粘包和半包的問題，但這種實(shí)現(xiàn)方式的編碼成本較大也不夠優(yōu)雅，因此不是最佳的實(shí)現(xiàn)方案，因此我們這里就略過，直接來看最終的解決方案吧。

解決方案三：特殊字符結(jié)尾，按行讀取

以特殊字符結(jié)尾就可以知道流的邊界了，因此也可以用來解決粘包和半包的問題，此實(shí)現(xiàn)方案是我們推薦最終解決方案。

這種解決方案的核心是，使用 Java 中自帶的 BufferedReader?和 BufferedWriter，也就是帶緩沖區(qū)的輸入字符流和輸出字符流，通過寫入的時(shí)候加上 \n?來結(jié)尾，讀取的時(shí)候使用 readLine 按行來讀取數(shù)據(jù)，這樣就知道流的邊界了，從而解決了粘包和半包的問題。

服務(wù)器端實(shí)現(xiàn)代碼如下：

/**
?*?服務(wù)器端，改進(jìn)版三(只負(fù)責(zé)收消息)
?*/
static?class?ServSocketV3?{
????public?static?void?main(String[]?args)?throws?IOException?{
????????//?創(chuàng)建?Socket?服務(wù)器端
????????ServerSocket?serverSocket?=?new?ServerSocket(9092);
????????//?獲取客戶端連接
????????Socket?clientSocket?=?serverSocket.accept();
????????//?使用線程池處理更多的客戶端
????????ThreadPoolExecutor?threadPool?=?new?ThreadPoolExecutor(100,?150,?100,
????????????????TimeUnit.SECONDS,?new?LinkedBlockingQueue<>(1000));
????????threadPool.submit(()?->?{
????????????//?消息處理
????????????processMessage(clientSocket);
????????});
????}
????/**
?????*?消息處理
?????*?@param?clientSocket
?????*/
????private?static?void?processMessage(Socket?clientSocket)?{
????????//?獲取客戶端發(fā)送的消息流對象
????????try?(BufferedReader?bufferedReader?=?new?BufferedReader(
????????????????new?InputStreamReader(clientSocket.getInputStream())))?{
????????????while?(true)?{
????????????????//?按行讀取客戶端發(fā)送的消息
????????????????String?msg?=?bufferedReader.readLine();
????????????????if?(msg?!=?null)?{
????????????????????//?成功接收到客戶端的消息并打印
????????????????????System.out.println("接收到客戶端的信息:"?+?msg);
????????????????}
????????????}
????????}?catch?(IOException?ioException)?{
????????????ioException.printStackTrace();
????????}
????}
}

PS：上述代碼使用了線程池來解決多個(gè)客戶端同時(shí)訪問服務(wù)器端的問題，從而實(shí)現(xiàn)了一對多的服務(wù)器響應(yīng)。

客戶端的實(shí)現(xiàn)代碼如下：

/**
?*?客戶端，改進(jìn)版三(只負(fù)責(zé)發(fā)送消息)
?*/
static?class?ClientSocketV3?{
????public?static?void?main(String[]?args)?throws?IOException?{
????????//?啟動(dòng)?Socket?并嘗試連接服務(wù)器
????????Socket?socket?=?new?Socket("127.0.0.1",?9092);
????????final?String?message?=?"Hi,Java.";?//?發(fā)送消息
????????try?(BufferedWriter?bufferedWriter?=?new?BufferedWriter(
????????????????new?OutputStreamWriter(socket.getOutputStream())))?{
????????????//?給服務(wù)器端發(fā)送?10?次消息
????????????for?(int?i?=?0;?i?10;?i++)?{
????????????????//?注意:結(jié)尾的?\n?不能省略,它表示按行寫入
????????????????bufferedWriter.write(message?+?"\n");
????????????????//?刷新緩沖區(qū)(此步驟不能省略)
????????????????bufferedWriter.flush();
????????????}
????????}
????}
}

以上代碼的執(zhí)行結(jié)果如下圖所示：

總結(jié)

本文我們講了 TCP 粘包和半包問題，粘包是指讀取到了兩條信息，正常情況下消息應(yīng)該是一條一條讀取的，而半包問題是指讀取了一半信息。導(dǎo)致粘包和半包的原因是 TCP 的傳輸是以流的形式進(jìn)行的，而流數(shù)據(jù)是沒有明確的開始和結(jié)尾標(biāo)識(shí)的，因此就導(dǎo)致了此問題。

本文我們提供了 3 種粘包和半包的解決方案，其中最推薦的是使用 BufferedReader 和 BufferedWriter 按行來讀、寫和區(qū)分消息，也就是本文的第三種解決方案。

參考 & 鳴謝

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

https://www.jianshu.com/p/6a4ec6095f2c

0、重磅！兩萬字長文總結(jié)，梳理 Java 入門進(jìn)階哪些事（推薦收藏）
1、程序員小躍 2020 原創(chuàng)匯總來襲，全年干貨一網(wǎng)打盡

3種Socket通信粘包問題的解決方案，最后一種真棒！

什么是 TCP 協(xié)議？

什么是粘包和半包問題？

為什么會(huì)有粘包和半包問題？