TCP數(shù)據(jù)粘包的處理

1. 背鍋俠 TCP

在前面介紹套接字通信的時候說到了 TCP 是傳輸層協(xié)議，它是一個面向連接的、安全的、流式傳輸協(xié)議。因為數(shù)據(jù)的傳輸是基于流的所以發(fā)送端和接收端每次處理的數(shù)據(jù)的量，處理數(shù)據(jù)的頻率可以不是對等的，可以按照自身需求來進(jìn)行決策。

TCP 協(xié)議是優(yōu)勢非常明顯，但是有時也會給我們造成困擾，正所謂：成也蕭何敗蕭何。假設(shè)我們有如下需求：

客戶端和服務(wù)器之間要進(jìn)行基于 TCP 的套接字通信

• 通信過程中客戶端會每次會不定期給服務(wù)器發(fā)送一個不定長度的有特定含義的字符串。
• 通信的服務(wù)器端每次都需要接收到客戶端這個不定長度的字符串，并對其進(jìn)行解析。

根據(jù)上面的描述，服務(wù)器在接收數(shù)據(jù)的時候有如下幾種情況：

• 一次接收到了客戶端發(fā)送過來的一個完整的數(shù)據(jù)包
• 一次接收到了客戶端發(fā)送過來的 N 個數(shù)據(jù)包，由于每個包的長度不定，無法將各個數(shù)據(jù)包拆開
• 一次接收到了一個或者 N 個數(shù)據(jù)包 下一個數(shù)據(jù)包的一部分，還是很悲劇，無法將數(shù)據(jù)包拆開
• 一次收到了半個數(shù)據(jù)包，下一次接收數(shù)據(jù)的時候收到了剩下的一部分 下個數(shù)據(jù)包的一部分，更悲劇，頭大了
• 另外，還有一些不可抗拒的因素：比如客戶端和服務(wù)器端的網(wǎng)速不一樣，發(fā)送和接收的數(shù)據(jù)量也會不一致

對于以上描述的現(xiàn)象很多時候我們將其稱之為 TCP的粘包問題，但是這種叫法不太對的，本身 TCP 就是面向連接的流式傳輸協(xié)議，特性如此，我們卻說是 TCP 這個協(xié)議出了問題，這只能說是使用者的無知。多個數(shù)據(jù)包粘連到一起無法拆分是我們的需求過于復(fù)雜造成的，是程序猿的問題而不是協(xié)議的問題，TCP 協(xié)議表示這鍋它不想背。

現(xiàn)在問題來了，服務(wù)器端如果想保證每次都能接收到客戶端發(fā)送過來的這個不定長度的數(shù)據(jù)包，程序猿應(yīng)該如何解決這個問題呢？下面給大家提供幾種解決方案：

1. 使用標(biāo)準(zhǔn)的應(yīng)用層協(xié)議（比如：http、https）來封裝要傳輸?shù)牟欢ㄩL的數(shù)據(jù)包
2. 在每條數(shù)據(jù)的尾部添加特殊字符，如果遇到特殊字符，代表當(dāng)條數(shù)據(jù)接收完畢了

• 有缺陷：效率低，需要一個字節(jié)一個字節(jié)接收，接收一個字節(jié)判斷一次，判斷是不是那個特殊字符串

3. 在發(fā)送數(shù)據(jù)塊之前，在數(shù)據(jù)塊最前邊添加一個固定大小的數(shù)據(jù)頭，這時候數(shù)據(jù)由兩部分組成：數(shù)據(jù)頭 數(shù)據(jù)塊

• 數(shù)據(jù)頭：存儲當(dāng)前數(shù)據(jù)包的總字節(jié)數(shù)，接收端先接收數(shù)據(jù)頭，然后在根據(jù)數(shù)據(jù)頭接收對應(yīng)大小的字節(jié)
• 數(shù)據(jù)塊：當(dāng)前數(shù)據(jù)包的內(nèi)容

2. 解決方案

如果使用 TCP 進(jìn)行套接字通信，如果發(fā)送的數(shù)據(jù)包粘連到一起導(dǎo)致接收端無法解析，我們通常使用添加包頭的方式輕松地解決掉這個問題。關(guān)于數(shù)據(jù)包的包頭大小可以根據(jù)自己的實際需求進(jìn)行設(shè)定，這里沒有啥特殊需求，因此規(guī)定包頭的固定大小為4個字節(jié)，用于存儲當(dāng)前數(shù)據(jù)塊的總字節(jié)數(shù)。

2.1 發(fā)送端

對于發(fā)送端來說，數(shù)據(jù)的發(fā)送分為 4 步：

1. 根據(jù)待發(fā)送的數(shù)據(jù)長度 N 動態(tài)申請一塊固定大小的內(nèi)存：N 4（4 是包頭占用的字節(jié)數(shù)）
2. 將待發(fā)送數(shù)據(jù)的總長度寫入申請的內(nèi)存的前四個字節(jié)中，此處需要將其轉(zhuǎn)換為網(wǎng)絡(luò)字節(jié)序（大端）
3. 將待發(fā)送的數(shù)據(jù)拷貝到包頭后邊的地址空間中，將完整的數(shù)據(jù)包發(fā)送出去（字符串沒有字節(jié)序問題）
4. 釋放申請的堆內(nèi)存。

由于發(fā)送端每次都需要將這個數(shù)據(jù)包完整的發(fā)送出去，因此可以設(shè)計一個發(fā)送函數(shù)，如果當(dāng)前數(shù)據(jù)包中的數(shù)據(jù)沒有發(fā)送完就讓它一直發(fā)送，處理代碼如下：

/*
函數(shù)描述:?發(fā)送指定的字節(jié)數(shù)
函數(shù)參數(shù):
????-?fd:?通信的文件描述符(套接字)
????-?msg:?待發(fā)送的原始數(shù)據(jù)
????-?size:?待發(fā)送的原始數(shù)據(jù)的總字節(jié)數(shù)
函數(shù)返回值:?函數(shù)調(diào)用成功返回發(fā)送的字節(jié)數(shù),?發(fā)送失敗返回-1
*/
int?writen(int?fd,?const?char*?msg,?int?size)
{
????const?char*?buf?=?msg;
????int?count?=?size;
????while?(count?>?0)
????{
????????int?len?=?send(fd,?buf,?count,?0);
????????if?(len?==?-1)
????????{
????????????close(fd);
????????????return?-1;
????????}
????????else?if?(len?==?0)
????????{
????????????continue;
????????}
????????buf? =?len;
????????count?-=?len;
????}
????return?size;
}
有了這個功能函數(shù)之后就可以發(fā)送帶有包頭的數(shù)據(jù)塊了，具體處理動作如下：

/*
函數(shù)描述:?發(fā)送帶有數(shù)據(jù)頭的數(shù)據(jù)包
函數(shù)參數(shù):
????-?cfd:?通信的文件描述符(套接字)
????-?msg:?待發(fā)送的原始數(shù)據(jù)
????-?len:?待發(fā)送的原始數(shù)據(jù)的總字節(jié)數(shù)
函數(shù)返回值:?函數(shù)調(diào)用成功返回發(fā)送的字節(jié)數(shù),?發(fā)送失敗返回-1
*/
int?sendMsg(int?cfd,?char*?msg,?int?len)
{
???if(msg?==?NULL?||?len?<=?0?||?cfd?<=0)
???{
???????return?-1;
???}
???//?申請內(nèi)存空間:?數(shù)據(jù)長度? ?包頭4字節(jié)(存儲數(shù)據(jù)長度)
???char*?data?=?(char*)malloc(len 4);
???int?bigLen?=?htonl(len);
???memcpy(data,?