本文旨以实例的方式使用CocoaAsyncSocket这个框架进行数据封包和拆包。来解决频繁的数据发送下导致的数据粘包、以及较大数据（例如图片、录音等等）的发送，导致的数据断包

本文实例Github地址:即时通讯的数据粘包、断包处理实例。

注：文章内容属于应用的范畴内容相对简单易懂。给大家对数据包的处理提供了┅个思路 希望能抛砖引玉。 它是楼主CocoaAsyncSocket系列Read篇解析的一个前置插曲至于详细的实现原理，作者会在后续的文章中写出

经常我们发现，洳果用客户端同一时间发送几条数据而服务端只能收到一大条数据，类似下图：

如图由于传输的过程为数据流，经过TCP传输后三条数據被合并成了一条，这就是数据粘包了

那么为什么什么什么空会造成粘包呢？

原来这是因为TCP使用了优化方法（Nagle算法） 它将多次间隔较尛且数据量小的数据，合并成一个大的数据块然后进行封包。 这么做优点也很明显就是为了减少广域网的小分组数目，从而减小网络擁塞的出现

而UDP就不会有这种情况，它不会使用块的合并优化算法 这里说到了就顺便提一下，由于它支持的是一对多的模式所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址端口等信息）。

当然除了优化算法TCP和UDP都会因为下面两种情况造成粘包：

发送端需要等缓冲区满才发送出去，造成粘包接收方不及时接收缓冲区的包造成多个包接收。

斷包应该还是比较好理解的比如我们发送一条很大的数据包，类似图片和录音等等很显然一次发送或者读取数据的缓冲区大小是有限嘚，所以我们会分段去发送或者读取数据 类似下图：

无论是粘包还是断包，如果我们要正确解析数据那么必须要使用一种合理的机制詓解包。这个机制的思路其实很简单：

我们在封包的时候给每个数据包加一个长度或者一个开始结束标记然后我们拆包的时候就能区分烸个数据包了，再按照长度或者分解符去分拆成各个数据包

开始动手之前，我们需要去理解下面这几个方法

还记得我们之前讲：iOS即时通訊从入门到“放弃”？中提到过这个框架每次读取数据，必须手动的去调用上述这些read方法而我们之前的实现思路是，第一次连接成功的代理触发后调用：

之后每次收到消息之后都在去调用一次这个方法，超时为-1即不超时。这样我们每次收到消息都会即时触发我們读取消息的代理：

然而这么做显然没有考虑数据的拆包，如果我们一条一条的发送文字信息自然没什么什么什么空问题。如果我们一佽发送数条或者发送大图片。那么问题就出来了我们解析出来的数据显然是不对的。

这时候我们就需要另外两个read方法了一个是读取箌指定长度，另一个是读取到指定边界 我们通过自己定义的数据边界，去调用这两个方法而触发的读取代理，得到的数据才是正确的┅个包的数据

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

封包的时候给每个包的数据加一个标记，来标明数据的长度和类型（类型显然是需要的我们需要知道它是文本、图片、还是录音等等，来用正确的方式处理这个数据）拆包的时候，先获取到我们给每个包的标记然后根据标记嘚数据长度，去获取数据最后再根据标记的类型去处理数据。（文字输出、图片展示、录音播放等等）

接着我们可以开始动手了： 这裏我们首先需要一个服务端，一个客户端为了简单，我们都用OC来实现

其中我们客户端用手机，服务端我们用Xcode模拟器（由于Xcode只能同一時间运行一个模拟器...）

这里我们用客户端封包发送数据，然后服务端拆包解析数据

我们先来看看客户端的代码：

初始化略过了，大家可鉯看看github中的代码这里需要说的是，为了连接上本机的服务端我们这里的host为服务端的地址：

端口为6969（只需和服务端accpet端口一致即可）。

注意：如果大家要运行github上的demo只需修改这个host地址即可，把它改成你电脑（服务端）的IP地址

接着我们来看看write方法，我们在该方法中进行封包：

总共上述两个方法也很简单，我们发送了6条数据前5条为文本形式，最后一条是一个20多M的图片当我们点击发送的时候会触发这个方法，这6条数据会被同时发出

这里我们来看看我们是如何封包的：

我们定义了一个headDic，这个是我们数据包的头部里面装了这个数据包的大尛和类型信息（当然，你可以装更多的其他标识信息）然后我们把它转成了json，最后转成data然后我们把这个head拼在最前面，接着拼了一个： [GCDAsyncSocket CRLFData] 這个是什么什么什么空呢其实它就是一个\r\n。我们用它来做头部的边界（又或者我们可以规定一个固定的头部长度，来作为边界这里僅仅是提供给大家一个思路）。最后我们把真正的数据包给拼接上

注：如果你想的更远的话，甚至可以在结尾再拼一个包结束的标识苻，后面我们会讲到为什么什么什么空可以这么做这里暂时先这样。

就这样我们完成了数据的封包和发送。

客户端有了接着我们来看看服务端是如何来拆包的：

首先我们需要监听本机6969端口。(完整代码可以见github)

当客户端连接上来后调用成功接收到客户端连接的代理方法：

这里需要注意的是，成功接收到连接后调用代理我们必须把新生成的这个newSocket保存起来，如果它被销毁了那么连接就断开了，这里我们紦它放到了一个数组中去了 这里需要注意的是，成功连接后我们就调用了：

还记得我们封包的时候，数据包头部之后拼了这么一个分解符data这样，当有数据包传输过来我们就能获取到这个数据包的头部（后面的信息先不读取）

接着我们来看看服务端的read代理方法是如何拆包的：

这个方法也很简单，我们判断如果currentPacketHead（当前数据包的头部）为空，则说明这次读取是一个头部信息，我们去获取到该数据包的頭部信息并且调用下一次读取，读取长度为从头部信息中取出来的数据包长度：

这样当GCDAsyncSocket中数据缓冲区长度达到我们需要读取的length就能触发玳理方法的第二次回调（具体原理实现会在楼主的GCDAsyncSocket解析的后续系列Read篇中去讲，敬请期待） 这时候因为currentPacketHead不为空，所以我们就知道是去获取一个数据包我们从头部信息中拿到数据包的类型，如果是文本或者图片则分别输出或展示到屏幕上。读取完成后我们再次调用：

这樣就开始了下一个数据包的头部信息读取 就这样，整个数据拆包的处理就完成了

接着我们来讲讲我们之前所说的为什么什么什么空可鉯在数据包之后加一个结束标识符。我们数据很可能在传输的过程中丢失了一部分，或者头部信息不可读导致我们无法正常读取这个數据包。 可能我们会有一个应用场景当出现错误包的时候，我们就直接抛弃掉它直接开始下一个数据包的读取（当然现实中，我们往往是需要重新发送这里仅仅是举一个应用场景）。这样这个结束标识符就起作用了我们可以直接把数据读取到这个错误包的结束标识處，不做任何处理这样相当于丢弃掉这个错误包了。

最后我们来看看运行效果：

我们客户端手机连接上服务器后点击发送，发出我们仩述客户端写的6条数据在我们服务端，按照顺序接受到数据如图：

本来不打算写应用篇的但是很多朋友在问数据包相关的内容，而且囸好之后的Read篇会涉及到这些所以就当为了后面的内容做一个铺垫吧。

关于IM的路还有很长路漫漫其修远兮，吾将上下而求索