前言
本文旨以例項的方式，使用CocoaAsyncSocket這個框架進行資料封包和拆包。來解決頻繁的資料傳送下，導致的資料粘包、以及較大資料（例如圖片、錄音等等）的傳送，導致的資料斷包。
本文例項Github地址:即時通訊的資料粘包、斷包處理例項。
注：文章內容屬於應用的範疇，內容相對簡單易懂。給大家對資料包的處理提供了一個思路， 希望能拋磚引玉。
它是樓主CocoaAsyncSocket系列Read篇解析的一個前置插曲，至於詳細的實現原理，作者會在後續的文章中寫出。
正文
一、什麼是粘包？
經常我們發現，如果用客戶端同一時間傳送幾條資料，而服務端只能收到一大條資料，類似下圖：
如圖，由於傳輸的過程為資料流，經過TCP傳輸後，三條資料被合併成了一條，這就是資料粘包了。
那麼為什麼會造成粘包呢？
原來這是因為TCP使用了優化方法（Nagle演算法）。
它將多次間隔較小且資料量小的資料，合併成一個大的資料塊，然後進行封包。
這麼做優點也很明顯，就是為了減少廣域網的小分組數目，從而減小網路擁塞的出現。
具體的內容感興趣的可以看看這兩篇文章：
TCP之Nagle演算法&&延遲ACK
TCP NAGLE演算法和實現
而UDP就不會有這種情況，它不會使用塊的合併優化演算法。
這裡說到了就順便提一下，由於它支援的是一對多的模式，所以接收端的skbuff(套接字緩衝區）採用了鏈式結構來記錄每一個到達的UDP包，在每個UDP包中就有了訊息頭（訊息來源地址，埠等資訊）。
當然除了優化演算法，TCP和UDP都會因為下面兩種情況造成粘包：
- 傳送端需要等緩衝區滿才傳送出去，造成粘包
- 接收方不及時接收緩衝區的包，造成多個包接收。
二、什麼是斷包？
斷包應該還是比較好理解的，比如我們傳送一條很大的資料包，類似圖片和錄音等等，很顯然一次傳送或者讀取資料的緩衝區大小是有限的，所以我們會分段去傳送或者讀取資料。
類似下圖：
無論是粘包還是斷包，如果我們要正確解析資料，那麼必須要使用一種合理的機制去解包。這個機制的思路其實很簡單：
- 我們在封包的時候給每個資料包加一個長度或者一個開始結束標記。
- 然後我們拆包的時候就能區分每個資料包了，再按照長度或者分解符去分拆成各個資料包。
Talk is cheap. Show me the code
三、例項：基於CocoaAsyncSocket的封包，拆包處理。
開始動手之前，我們需要去理解下面這幾個方法
|
1 2 3 4 5 6 |
//讀取資料，有資料就會觸發代理 - (void)readDataWithTimeout:(NSTimeInterval)timeout tag:(long)tag; //直到讀到這個長度的資料，才會觸發代理 - (void)readDataToLength:(NSUInteger)length withTimeout:(NSTimeInterval)timeout tag:(long)tag; //直到讀到data這個邊界，才會觸發代理 - (void)readDataToData:(NSData *)data withTimeout:(NSTimeInterval)timeout tag:(long)tag; |
還記得我們之前講：iOS即時通訊，從入門到“放棄”？中提到過，這個框架每次讀取資料，必須手動的去呼叫上述這些read方法，而我們之前的實現思路是，第一次連線成功的代理觸發後呼叫：
|
1 |
- (void)readDataWithTimeout:(NSTimeInterval)timeout tag:(long)tag; |
之後每次收到訊息之後，都在去呼叫一次這個方法，超時為-1，即不超時。這樣我們每次收到訊息，都會即時觸發我們讀取訊息的代理：
|
1 |
- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag |
然而這麼做顯然沒有考慮資料的拆包，如果我們一條一條的傳送文字資訊，自然沒什麼問題。如果我們一次傳送數條，或者傳送大圖片。那麼問題就出來了，我們解析出來的資料顯然是不對的。
這時候我們就需要另外兩個read方法了，一個是讀取到指定長度，另一個是讀取到指定邊界。
我們通過自己定義的資料邊界，去呼叫這兩個方法，而觸發的讀取代理，得到的資料才是正確的一個包的資料。
所以我們的核心思路有了：
- 封包的時候給每個包的資料加一個標記，來標明資料的長度和型別（型別顯然是需要的，我們需要知道它是文字、圖片、還是錄音等等，來用正確的方式處理這個資料）。
- 拆包的時候，先獲取到我們給每個包的標記，然後根據標記的資料長度，去獲取資料。最後再根據標記的型別去處理資料。（文字輸出、圖片展示、錄音播放等等）。
接著我們可以開始動手了：
這裡我們首先需要一個服務端，一個客戶端。為了簡單，我們都用OC來實現。
其中我們客戶端用手機，服務端我們用Xcode模擬器。（由於Xcode只能同一時間執行一個模擬器…）
這裡我們用客戶端封包傳送資料，然後服務端拆包解析資料。
我們先來看看客戶端的程式碼：
|
1 2 3 4 5 6 7 |
static NSString * Khost = @"10.10.100.48"; static const uint16_t Kport = 6969; //建立連線 - (BOOL)connect { return [gcdSocket connectToHost:Khost onPort:Kport error:nil]; } |
初始化略過了，大家可以看看github中的程式碼，這裡需要說的是，為了連線上本機的服務端，我們這裡的host為服務端的IP地址：
埠為6969（只需和服務端accpet埠一致即可）。
注意：如果大家要執行github上的demo，只需修改這個host地址即可，把它改成你電腦（服務端）的IP地址。
接著我們來看看write方法，我們在該方法中進行封包：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
//傳送訊息 - (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]; //第二個引數，請求超時時間 [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]; } |
總共上述兩個方法，也很簡單，我們傳送了6條資料，前5條為文字形式，最後一條是一個20多M的圖片。當我們點選傳送的時候會觸發這個方法，這6條資料會被同時發出。
這裡我們來看看我們是如何封包的：
- 我們定義了一個
headDic，這個是我們資料包的頭部，裡面裝了這個資料包的大小和型別資訊（當然，你可以裝更多的其他標識資訊。）然後我們把它轉成了json，最後轉成data。 - 然後我們把這個
head拼在最前面，接著拼了一個：
1[GCDAsyncSocket CRLFData]
這個是什麼呢？其實它就是一個\r\n。我們用它來做頭部的邊界。（又或者我們可以規定一個固定的頭部長度，來作為邊界，這裡僅僅是提供給大家一個思路）。 - 最後我們把真正的資料包給拼接上。
注：如果你想的更遠的話，甚至可以在結尾，再拼一個包結束的識別符號，後面我們會講到為什麼可以這麼做。這裡暫時先這樣。
就這樣，我們完成了資料的封包和傳送。
客戶端有了，接著我們來看看服務端是如何來拆包的：
首先我們需要監聽本機6969埠。(完整程式碼可以見github)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
static const uint16_t Kport = 6969; //等待連線 - (BOOL)accept { NSError *error = nil; BOOL isSuccess = [gcdSocket acceptOnPort:Kport error:&error]; if (isSuccess) { NSLog(@"監聽成功6969埠成功，等待連線"); return YES; }else{ NSLog(@"監聽失敗，原因：%@",error); return NO; } } |
當客戶端連線上來後，呼叫成功接收到客戶端連線的代理方法：
|
1 2 3 4 5 6 7 |
- (void)socket:(GCDAsyncSocket *)sock didAcceptNewSocket:(GCDAsyncSocket *)newSocket { NSLog(@"接受到socket連線"); [_sockets addObject:newSocket]; [newSocket readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110]; } |
這裡需要注意的是，成功接收到連線後，呼叫代理我們必須把新生成的這個newSocket儲存起來，如果它被銷燬了，那麼連線就斷開了，這裡我們把它放到了一個陣列中去了。
這裡需要注意的是，成功連線後，我們就呼叫了：
|
1 |
[newSocket readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110]; |
還記得我們封包的時候，資料包頭部之後拼了這麼一個分解符data。這樣，當有資料包傳輸過來我們就能獲取到這個資料包的頭部（後面的資訊先不讀取）。
接著我們來看看服務端的read代理方法是如何拆包的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag { //先讀取到當前資料包頭部資訊 if (!currentPacketHead) { currentPacketHead = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:nil]; NSUInteger packetLength = [currentPacketHead[@"size"] integerValue]; //讀到資料包的大小 [sock readDataToLength:packetLength withTimeout:-1 tag:110]; return; } if (!currentPacketHead) { NSLog(@"error：當前資料包的頭為空"); //斷開連線 [self disConnect]; return; } //正式的包處理 NSUInteger packetLength = [currentPacketHead[@"size"] integerValue]; //說明資料有問題 if (packetLength <= 0 || data.length != packetLength) { NSLog(@"error：當前資料包資料大小不正確"); [self disConnect]; return; } NSString *type = currentPacketHead[@"type"]; if ([type isEqualToString:@"img"]) { NSLog(@"圖片設定成功"); 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]; } |
這個方法也很簡單，我們判斷，如果currentPacketHead（當前資料包的頭部）為空，則說明這次讀取，是一個頭部資訊，我們去獲取到該資料包的頭部資訊。並且呼叫下一次讀取，讀取長度為從頭部資訊中取出來的資料包長度：
|
1 |
[sock readDataToLength:packetLength withTimeout:-1 tag:110]; |
這樣當GCDAsyncSocket中資料緩衝區長度達到我們需要讀取的length就能觸發代理方法的第二次回撥。（具體原理實現會在樓主的GCDAsyncSocket解析的後續系列Read篇中去講，敬請期待）。
這時候因為currentPacketHead不為空，所以我們就知道是去獲取一個資料包，我們從頭部資訊中拿到資料包的型別，如果是文字或者圖片，則分別輸出或展示到螢幕上。讀取完成後我們再次呼叫：
|
1 |
[sock readDataToData:[GCDAsyncSocket CRLFData] withTimeout:-1 tag:110]; |
這樣就開始了下一個資料包的頭部資訊讀取。
就這樣，整個資料拆包的處理就完成了。
接著我們來講講我們之前所說的為什麼可以在資料包之後加一個結束識別符號。我們資料很可能在傳輸的過程中，丟失了一部分，或者頭部資訊不可讀，導致我們無法正常讀取這個資料包。
可能我們會有一個應用場景，當出現錯誤包的時候，我們就直接拋棄掉它，直接開始下一個資料包的讀取（當然現實中，我們往往是需要重新傳送，這裡僅僅是舉一個應用場景）。這樣這個結束識別符號就起作用了，我們可以直接把資料讀取到這個錯誤包的結束標識處，不做任何處理，這樣相當於丟棄掉這個錯誤包了。
最後我們來看看執行效果：
我們客戶端手機連線上伺服器後，點選傳送，發出我們上述客戶端寫的6條資料，在我們服務端，按照順序接受到資料如圖：
寫在結尾：
本來不打算寫應用篇的，但是很多朋友在問資料包相關的內容，而且正好之後的Read篇會涉及到這些，所以就當為了後面的內容做一個鋪墊吧。
關於IM的路還有很長，路漫漫其修遠兮，吾將上下而求索。