tcp传输黏包
tcpip协议使用"流式"（套接字）进行数据的传输，就是说它保证数据的可达以及数据抵达的顺序，但并不保证数据是否在你接收的时候就到达，特别是为了提高效率，充分利用带宽，底层会使用缓存技术，具体的说就是使用Nagle算法将小的数据包放到一起发送，但是这样也带来一个使用上的问题——黏包，黏包就是说一次将多个数据包发送出去，导致接收方不能进行正常的解析，示意图如下：
发生黏包一般有两种原因，一种是发送方进行了不该缓冲的缓冲，比如上图中，收发双方协议好按照一定的规则进行编写/解析报文，但是由于Nagle算法，可能出现发送方一次发送了1.5个数据包，而接收方只解析了前面的1个包，后面的0.5个由于数据不完整而解析失败，造成数据的丢失或错位，很可能会影响之后所有的数据解析工作。由于发送方导致的黏包问题可以使用setsockopt()来解决
int enable=1;
setsockopt(sockfd,IPROTO_TCP,TCP_NODELAY,(void*)&enable,sizeof(enable))这条指令可以禁止发送方使用Nagle算法，一组数据被写入就会立即被发出，不需要等待mtu被填满。
此外，接收方处理不当也可能导致黏包问题，如果发送方将4个包发送到接收方的缓冲区，但是由于频繁的存取，可能有一次只取了2.5个包，就会导致黏包问题。接收方的黏包问题可以使用recv(sockfd,buf,sizeof(buf),MSG_WAITALL)来解决，MSG_WAITALL可以强制接收方收到sizeof(buf)那么多的数据才返回，而buf的大小可以是收发双方约定好的大小。
发送一次发送这么多，接收一次接收这么多，就可以避免黏包问题。
上述方法可以解决带有解析需求的黏包问题，对于不需要解析的需求，比如文件传输，发送方需要发送100kB的文件，接收方其实只关心最终接收到100KB没有，至于中间的某次发送方发了100byte而接收方收到20byte并不会影响文件的传输，对于这样的需求，一种更好的方案是发送方在发送文件数据之前先将文件的大小告知给接收方，接收方准备好后一直读取数据，知道接收到文件的大小那么多的数据就自行终止写文件。这样就免去了不必要的解析，是否黏包已经不影响功能了。具体实施可以参考这个迷你云存储。