前言

本文旨以實(shí)例的方式，使用CocoaAsyncSocket這個(gè)框架進(jìn)行數(shù)據(jù)封包和拆包。來解決頻繁的數(shù)據(jù)發(fā)送下，導(dǎo)致的數(shù)據(jù)粘包、以及較大數(shù)據(jù)（例如圖片、錄音等等）的發(fā)送，導(dǎo)致的數(shù)據(jù)斷包。

本文實(shí)例Github地址:即時(shí)通訊的數(shù)據(jù)粘包、斷包處理實(shí)例。

注：文章內(nèi)容屬于應(yīng)用的范疇，內(nèi)容相對簡單易懂。給大家對數(shù)據(jù)包的處理提供了一個(gè)思路， 希望能拋磚引玉。
它是樓主CocoaAsyncSocket系列Read篇解析的一個(gè)前置插曲，至于詳細(xì)的實(shí)現(xiàn)原理，作者會在后續(xù)的文章中寫出。

正文

一、什么是粘包？

經(jīng)常我們發(fā)現(xiàn)，如果用客戶端同一時(shí)間發(fā)送幾條數(shù)據(jù)，而服務(wù)端只能收到一大條數(shù)據(jù)，類似下圖：

如圖，由于傳輸?shù)倪^程為數(shù)據(jù)流，經(jīng)過TCP傳輸后，三條數(shù)據(jù)被合并成了一條，這就是數(shù)據(jù)粘包了。

那么為什么會造成粘包呢？

原來這是因?yàn)門CP使用了優(yōu)化方法（Nagle算法）。
它將多次間隔較小且數(shù)據(jù)量小的數(shù)據(jù)，合并成一個(gè)大的數(shù)據(jù)塊，然后進(jìn)行封包。
這么做優(yōu)點(diǎn)也很明顯，就是為了減少廣域網(wǎng)的小分組數(shù)目，從而減小網(wǎng)絡(luò)擁塞的出現(xiàn)。

具體的內(nèi)容感興趣的可以看看這兩篇文章：
TCP之Nagle算法&&延遲ACK
TCP NAGLE算法和實(shí)現(xiàn)

而UDP就不會有這種情況，它不會使用塊的合并優(yōu)化算法。
這里說到了就順便提一下，由于它支持的是一對多的模式，所以接收端的skbuff(套接字緩沖區(qū)）采用了鏈?zhǔn)浇Y(jié)構(gòu)來記錄每一個(gè)到達(dá)的UDP包，在每個(gè)UDP包中就有了消息頭（消息來源地址，端口等信息）。

當(dāng)然除了優(yōu)化算法，TCP和UDP都會因?yàn)橄旅鎯煞N情況造成粘包：

• 發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去，造成粘包
• 接收方不及時(shí)接收緩沖區(qū)的包，造成多個(gè)包接收。

二、什么是斷包？

斷包應(yīng)該還是比較好理解的，比如我們發(fā)送一條很大的數(shù)據(jù)包，類似圖片和錄音等等，很顯然一次發(fā)送或者讀取數(shù)據(jù)的緩沖區(qū)大小是有限的，所以我們會分段去發(fā)送或者讀取數(shù)據(jù)。
類似下圖：

無論是粘包還是斷包，如果我們要正確解析數(shù)據(jù)，那么必須要使用一種合理的機(jī)制去解包。這個(gè)機(jī)制的思路其實(shí)很簡單：

• 我們在封包的時(shí)候給每個(gè)數(shù)據(jù)包加一個(gè)長度或者一個(gè)開始結(jié)束標(biāo)記。
• 然后我們拆包的時(shí)候就能區(qū)分每個(gè)數(shù)據(jù)包了，再按照長度或者分解符去分拆成各個(gè)數(shù)據(jù)包。

Talk is cheap. Show me the code

三、實(shí)例：基于CocoaAsyncSocket的封包，拆包處理。

開始動手之前，我們需要去理解下面這幾個(gè)方法

//讀取數(shù)據(jù)，有數(shù)據(jù)就會觸發(fā)代理
- (void)readDataWithTimeout:(NSTimeInterval)timeout tag:(long)tag;
//直到讀到這個(gè)長度的數(shù)據(jù)，才會觸發(fā)代理
- (void)readDataToLength:(NSUInteger)length withTimeout:(NSTimeInterval)timeout tag:(long)tag;
//直到讀到data這個(gè)邊界，才會觸發(fā)代理
- (void)readDataToData:(NSData *)data withTimeout:(NSTimeInterval)timeout tag:(long)tag;

還記得我們之前講：iOS即時(shí)通訊，從入門到“放棄”？中提到過，這個(gè)框架每次讀取數(shù)據(jù)，必須手動的去調(diào)用上述這些read方法，而我們之前的實(shí)現(xiàn)思路是，第一次連接成功的代理觸發(fā)后調(diào)用：

- (void)readDataWithTimeout:(NSTimeInterval)timeout tag:(long)tag;

之后每次收到消息之后，都在去調(diào)用一次這個(gè)方法，超時(shí)為-1，即不超時(shí)。這樣我們每次收到消息，都會即時(shí)觸發(fā)我們讀取消息的代理：

- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag

然而這么做顯然沒有考慮數(shù)據(jù)的拆包，如果我們一條一條的發(fā)送文字信息，自然沒什么問題。如果我們一次發(fā)送數(shù)條，或者發(fā)送大圖片。那么問題就出來了，我們解析出來的數(shù)據(jù)顯然是不對的。

這時(shí)候我們就需要另外兩個(gè)read方法了，一個(gè)是讀取到指定長度，另一個(gè)是讀取到指定邊界。
我們通過自己定義的數(shù)據(jù)邊界，去調(diào)用這兩個(gè)方法，而觸發(fā)的讀取代理，得到的數(shù)據(jù)才是正確的一個(gè)包的數(shù)據(jù)。

所以我們的核心思路有了：

1. 封包的時(shí)候給每個(gè)包的數(shù)據(jù)加一個(gè)標(biāo)記，來標(biāo)明數(shù)據(jù)的長度和類型（類型顯然是需要的，我們需要知道它是文本、圖片、還是錄音等等，來用正確的方式處理這個(gè)數(shù)據(jù)）。
2. 拆包的時(shí)候，先獲取到我們給每個(gè)包的標(biāo)記，然后根據(jù)標(biāo)記的數(shù)據(jù)長度，去獲取數(shù)據(jù)。最后再根據(jù)標(biāo)記的類型去處理數(shù)據(jù)。（文字輸出、圖片展示、錄音播放等等）。

接著我們可以開始動手了：
這里我們首先需要一個(gè)服務(wù)端，一個(gè)客戶端。為了簡單，我們都用OC來實(shí)現(xiàn)。

其中我們客戶端用手機(jī)，服務(wù)端我們用Xcode模擬器。（由于Xcode只能同一時(shí)間運(yùn)行一個(gè)模擬器...）

這里我們用客戶端封包發(fā)送數(shù)據(jù)，然后服務(wù)端拆包解析數(shù)據(jù)。

我們先來看看客戶端的代碼：

static  NSString * Khost = @"10.10.100.48";
static const uint16_t Kport = 6969;
//建立連接
- (BOOL)connect
{
    return  [gcdSocket connectToHost:Khost onPort:Kport error:nil];
}

初始化略過了，大家可以看看github中的代碼，這里需要說的是，為了連接上本機(jī)的服務(wù)端，我們這里的host為服務(wù)端的IP地址：

端口為6969（只需和服務(wù)端accpet端口一致即可）。

注意：如果大家要運(yùn)行github上的demo，只需修改這個(gè)host地址即可，把它改成你電腦（服務(wù)端）的IP地址。

接著我們來看看write方法，我們在該方法中進(jìn)行封包：

//發(fā)送消息
- (void)sendMsg
{
    NSData *data  = [@"你好" dataUsingEncoding:NSUTF8StringEncoding];
    NSData *data1  = [@"豬頭" dataUsingEncoding:NSUTF8StringEncoding];
    NSData *data2  = [@"先生" dataUsingEncoding:NSUTF8StringEncoding];
    
    
    NSData *data3  = [@"今天天氣好" dataUsingEncoding:NSUTF8StringEncoding];
    NSData *data4  = [@"吃飯了嗎" dataUsingEncoding:NSUTF8StringEncoding];

    [self sendData:data :@"txt"];
    [self sendData:data1 :@"txt"];
    [self sendData:data2 :@"txt"];
    [self sendData:data3 :@"txt"];
    [self sendData:data4 :@"txt"];
    
    NSString *filePath = [[NSBundle mainBundle]pathForResource:@"test1" ofType:@"jpg"];
    
    NSData *data5 = [NSData dataWithContentsOfFile:filePath];
    
    [self sendData:data5 :@"img"];
}

- (void)sendData:(NSData *)data :(NSString *)type
{
    NSUInteger size = data.length;
    
    NSMutableDictionary *headDic = [NSMutableDictionary dictionary];
    [headDic setObject:type forKey:@"type"];
    [headDic setObject:[NSString stringWithFormat:@"%ld",size] forKey:@"size"];
    NSString *jsonStr = [self dictionaryToJson:headDic];

    
    NSData *lengthData = [jsonStr dataUsingEncoding:NSUTF8StringEncoding];
    
    
    NSMutableData *mData = [NSMutableData dataWithData:lengthData];
    //分界
    [mData appendData:[GCDAsyncSocket CRLFData]];
    
    [mData appendData:data];
    
    
    //第二個(gè)參數(shù)，請求超時(shí)時(shí)間
    [gcdSocket writeData:mData withTimeout:-1 tag:110];

}
- (NSString *)dictionaryToJson:(NSDictionary *)dic
{
    NSError *error = nil;
    NSData *jsonData = [NSJSONSerialization dataWithJSONObject:dic options:NSJSONWritingPrettyPrinted error:&error];
    return [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding];
}

總共上述兩個(gè)方法，也很簡單，我們發(fā)送了6條數(shù)據(jù)，前5條為文本形式，最后一條是一個(gè)20多M的圖片。當(dāng)我們點(diǎn)擊發(fā)送的時(shí)候會觸發(fā)這個(gè)方法，這6條數(shù)據(jù)會被同時(shí)發(fā)出。

這里我們來看看我們是如何封包的：

• 我們定義了一個(gè)headDic，這個(gè)是我們數(shù)據(jù)包的頭部，里面裝了這個(gè)數(shù)據(jù)包的大小和類型信息（當(dāng)然，你可以裝更多的其他標(biāo)識信息。）然后我們把它轉(zhuǎn)成了json，最后轉(zhuǎn)成data。
• 然后我們把這個(gè)head拼在最前面，接著拼了一個(gè)：

[GCDAsyncSocket CRLFData]

這個(gè)是什么呢？其實(shí)它就是一個(gè)\r\n。我們用它來做頭部的邊界。（又或者我們可以規(guī)定一個(gè)固定的頭部長度，來作為邊界，這里僅僅是提供給大家一個(gè)思路）。

• 最后我們把真正的數(shù)據(jù)包給拼接上。

注：如果你想的更遠(yuǎn)的話，甚至可以在結(jié)尾，再拼一個(gè)包結(jié)束的標(biāo)識符，后面我們會講到為什么可以這么做。這里暫時(shí)先這樣。

就這樣，我們完成了數(shù)據(jù)的封包和發(fā)送。

客戶端有了，接著我們來看看服務(wù)端是如何來拆包的：

首先我們需要監(jiān)聽本機(jī)6969端口。(完整代碼可以見github)

static const uint16_t Kport = 6969;

//等待連接
- (BOOL)accept
{
    NSError *error = nil;
    
    BOOL isSuccess =   [gcdSocket acceptOnPort:Kport error:&error];
    if (isSuccess) {
        NSLog(@"監(jiān)聽成功6969端口成功，等待連接");
        return YES;
    }else{
        NSLog(@"監(jiān)聽失敗，原因：%@",error);
        return NO;
    }
}

當(dāng)客戶端連接上來后，調(diào)用成功接收到客戶端連接的代理方法：

- (void)socket:(GCDAsyncSocket *)sock didAcceptNewSocket:(GCDAsyncSocket *)newSocket
{
    NSLog(@"接受到socket連接");
 
    [_sockets addObject:newSocket];
    [newSocket readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110];
}

這里需要注意的是，成功接收到連接后，調(diào)用代理我們必須把新生成的這個(gè)newSocket保存起來，如果它被銷毀了，那么連接就斷開了，這里我們把它放到了一個(gè)數(shù)組中去了。
這里需要注意的是，成功連接后，我們就調(diào)用了：

[newSocket readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110];

還記得我們封包的時(shí)候，數(shù)據(jù)包頭部之后拼了這么一個(gè)分解符data。這樣，當(dāng)有數(shù)據(jù)包傳輸過來我們就能獲取到這個(gè)數(shù)據(jù)包的頭部（后面的信息先不讀取）。

接著我們來看看服務(wù)端的read代理方法是如何拆包的：

- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag
{
    //先讀取到當(dāng)前數(shù)據(jù)包頭部信息
    if (!currentPacketHead) {
        currentPacketHead = [NSJSONSerialization
                             JSONObjectWithData:data
                             options:NSJSONReadingMutableContainers
                             error:nil];
        if (!currentPacketHead) {
            NSLog(@"error：當(dāng)前數(shù)據(jù)包的頭為空");
            
            //斷開這個(gè)socket連接或者丟棄這個(gè)包的數(shù)據(jù)進(jìn)行下一個(gè)包的讀取
            
            //....
            return;
        }        

        NSUInteger packetLength = [currentPacketHead[@"size"] integerValue];
        
        //讀到數(shù)據(jù)包的大小
        [sock readDataToLength:packetLength withTimeout:-1 tag:110];

        return;
    }

    
    //正式的包處理
    NSUInteger packetLength = [currentPacketHead[@"size"] integerValue];
    //說明數(shù)據(jù)有問題
    if (packetLength <= 0 || data.length != packetLength) {
        NSLog(@"error：當(dāng)前數(shù)據(jù)包數(shù)據(jù)大小不正確");
        return;
    }
    
    NSString *type = currentPacketHead[@"type"];
    
    if ([type isEqualToString:@"img"]) {
        NSLog(@"圖片設(shè)置成功");
        self.recvImg.image = [UIImage imageWithData:data];
    }else{
        
        NSString *msg = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
        NSLog(@"收到消息:%@",msg);
    }
    
    currentPacketHead = nil;
    
    [sock readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110];
}

這個(gè)方法也很簡單，我們判斷，如果currentPacketHead（當(dāng)前數(shù)據(jù)包的頭部）為空，則說明這次讀取，是一個(gè)頭部信息，我們?nèi)カ@取到該數(shù)據(jù)包的頭部信息。并且調(diào)用下一次讀取，讀取長度為從頭部信息中取出來的數(shù)據(jù)包長度：

[sock readDataToLength:packetLength withTimeout:-1 tag:110];

這樣當(dāng)GCDAsyncSocket中數(shù)據(jù)緩沖區(qū)長度達(dá)到我們需要讀取的length就能觸發(fā)代理方法的第二次回調(diào)。（具體原理實(shí)現(xiàn)會在樓主的GCDAsyncSocket解析的后續(xù)系列Read篇中去講，敬請期待）。
這時(shí)候因?yàn)?code>currentPacketHead不為空，所以我們就知道是去獲取一個(gè)數(shù)據(jù)包，我們從頭部信息中拿到數(shù)據(jù)包的類型，如果是文本或者圖片，則分別輸出或展示到屏幕上。讀取完成后我們再次調(diào)用：

[sock readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110];

這樣就開始了下一個(gè)數(shù)據(jù)包的頭部信息讀取。
就這樣，整個(gè)數(shù)據(jù)拆包的處理就完成了。

接著我們來講講我們之前所說的為什么可以在數(shù)據(jù)包之后加一個(gè)結(jié)束標(biāo)識符。我們數(shù)據(jù)很可能在傳輸?shù)倪^程中，丟失了一部分，或者頭部信息不可讀，導(dǎo)致我們無法正常讀取這個(gè)數(shù)據(jù)包。
可能我們會有一個(gè)應(yīng)用場景，當(dāng)出現(xiàn)錯(cuò)誤包的時(shí)候，我們就直接拋棄掉它，直接開始下一個(gè)數(shù)據(jù)包的讀取（當(dāng)然現(xiàn)實(shí)中，我們往往是需要重新發(fā)送，這里僅僅是舉一個(gè)應(yīng)用場景）。這樣這個(gè)結(jié)束標(biāo)識符就起作用了，我們可以直接把數(shù)據(jù)讀取到這個(gè)錯(cuò)誤包的結(jié)束標(biāo)識處，不做任何處理，這樣相當(dāng)于丟棄掉這個(gè)錯(cuò)誤包了。

最后我們來看看運(yùn)行效果：

我們客戶端手機(jī)連接上服務(wù)器后，點(diǎn)擊發(fā)送，發(fā)出我們上述客戶端寫的6條數(shù)據(jù)，在我們服務(wù)端，按照順序接受到數(shù)據(jù)如圖：

寫在結(jié)尾：

本來不打算寫應(yīng)用篇的，但是很多朋友在問數(shù)據(jù)包相關(guān)的內(nèi)容，而且正好之后的Read篇會涉及到這些，所以就當(dāng)為了后面的內(nèi)容做一個(gè)鋪墊吧。

關(guān)于IM的路還有很長，路漫漫其修遠(yuǎn)兮，吾將上下而求索。