第一个需要讨论的大概就是粘包问题了。因为这个是TCP的个性问题，UDP通信时不存在这个问题的。首先看一下什么叫粘包：
客户端采取与服务器的长连接方式建立通信（Open-Write/Read-Write/Read-……-Write/Read-Close）。即建立连接之后进行多次读写操作，最后才关闭。而且不是文件传输，而是数据结构的传输（文件传输发生粘包与没发生粘包都不会影响结果，反正都是字节流的按顺序写入本地文件）。举个例子来说明一下吧：
两种数据结构：{give me something} {don't give me anything}则粘包是则是接受到{give me something don't give me anything} 这个算是让服务器傻眼了，没见过这么诡异的数据结构，不知道怎么处理了。 |
上面的例子是转的网上的
来分析一下之所以发生粘包的原因吧，其实也就是为什么TCP会发生，但是UDP却不会发生的原因：TCP是面向连接流式无边界的传输方式。当传输通道建立之后，则数据流就像水一样流过来，其中没有数据边界的概念，包随便多大，因而会出现多个包最后粘成一个大包。当然这个是TCP的原因，还有就是缓冲区机制的问题，发送端在默认状况下是需要等到发送去满才发送出去，故而适当使用push刷缓冲区也可减少粘包的现象，还有就是接受缓冲区处理不及时，没有做到来一个包立马处理完这个包。
所以解决的思路大约如下：
- 对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满。此种方法关闭了优化算法，降低了网络发送效率，影响应用程序的性能。而且并不能保证100%不发生粘包现象。
- 对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象。该种思路对于接收方的程序算法结构要求较高，而且可靠性不高，因为网络通信中的并发等现象大量存在，很难真的能完全即使处理接受缓冲区而不发生粘包。
- 由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。该思路的问题就更大了，应用程序效率被降低太多。而且我实在不认为这个真能不发生粘包，虽然包变小了，但是并发情况的存在并不能保证接收方有足够的间隙去处理包。
- 预定义数据结构，单线程。字节流前面先加上包头标志位，包头中包含该包的数据长度，这样在读取的时候可按字节读取。这样可有效控制粘包问题。并可以成功避免残包的问题，且不会发生连锁反应，一个坏包的出现不会影响下一个包的正常读取。如{##Length##DataStram}。该中解决方案的优点是可以保证通信的100%准确，缺点是影响程序性能，因为按字节读取包，必定会影响程序的效率。
- 改进：预定义数据结构，单线程。但是不是按字节。查看头标志位，读取包长度，查看缓冲区内包长度，两者相等，则直接读取。如果缓冲区内可读字节数大于标志位描述的包长度，则按照标志位描述的包长度读取数据，如果缓冲区内刻度字节数小于标志位描述的包长度，则线程睡眠，等下一个数据包的到来。
- 预定义数据结构，多线程。服务器端与客户端都是多线程工作，客户端为三个主要线程：发送线程、读取线程与解析线程。服务器端为四个主要线程：监听主线程、接收、读取、解析。按照第五种的思路，拿到数据包之后直接扔给解析线程，解析线程负责数据解析以及最终结果的回调。此处比第五种多的思路就是一个多线程，从而可以很大幅度提升程序的性能。
标志位
长度
数据
预定义数据结构示意图：
