TCP通信中的粘包问题

TCP通信中的粘包问题
尹德位 2015 西安

关键词 ： TCP 网络通信 粘包 Linux C/S
一 粘包问题概述
二 粘包回避设计

第一章 粘包问题概述

1.1 描述背景
采用TCP协议进行网络数据传送的软件设计中，普遍存在粘包问题。这主要是由于现代操作系统的网络传输机制所产生的。我们知道，网络通信采用的套接字(socket)技术，其实现实际是由系统内核提供一片连续缓存(流缓冲)来实现应用层程序与网卡接口之间的中转功能。多个数据包被连续存储于连续的缓存中，在对数据包进行读取时由于无法确定发生方的发送边界，而采用某一估测值大小来进行数据读出，若双方的size不一致时就会使数据包的边界发生错位，导致读出错误的数据分包，进而曲解原始数据含义。

1.2 粘包的概念
粘包问题的本质就是数据读取边界错误所致，通过下图可以形象地理解其现象。



如图1所示，当前的socket缓存中已经有6个数据分组到达，其大小如图中数字。而应用程序在对数据进行收取时(如图2)，采用了300字节的要求去读取，则会误将pkg1和pkg2一起收走当做一个包来处理。而实际上，很可能pkg1是一个文本文件的内容，而pkg2则可能是一个音频内容，这风马牛不相及的两个数据包却被揉进一个包进行处理，显然有失妥当。严重时可能因为丢了pkg2而导致软件陷入异常分支产生乌龙事件。
因此，粘包问题必须引起所有软件设计者（项目经理）的高度重视！
那么，或许会有读者发问，为何不让接收程序按照100字节来读取呢？我想如果您了解一些TCP编程的话就不会有这样的问题。网络通信程序中，数据包通常是不能确定大小的，尤其在软件设计阶段无法真的做到确定为一个固定值。比如聊天软件客户端若采用TCP传输一个用户名和密码到服务端进行验证登陆，我想这个数据包不过是几十字节，至多几百字节即可发送完毕，而有时候要传输一个很大的视频文件，即使分包发送也应该一个包在几千字节吧。（据说，某国电信平台的MW中见到过一次发送1.5万字节的电话数据）这种情况下，发送数据的分包大小无法固定，接收端也就无法固定。所以一般采用一个较为合理的预估值进行轮询接收。（网卡的MTU都是1500字节，因此这个预估值一般为MTU的1~3倍）。
相信读者对粘包问题应该有了初步认识了。

第二章 粘包回避设计

2.0 闲扯
作者在此提出三种可解之法，这都是从软件设计的角度去考虑的，当然代码实现也是可以验证没问题的。下面一一为读者解开其谜底。
读者在别的文献中还能看到一种叫做【短连接】的方法，根据经验不建议采用此法，开销太大得不偿失。故而本文对该方案不做解释。

2.1 设计方案一：定长发送
在进行数据发送时采用固定长度的设计，也就是无论多大数据发送都分包为固定长度（为便于描述，此处定长为记为LEN），也就是发送端在发送数据时都以LEN为长度进行分包。这样接收方都以固定的LEN进行接收，如此一来发送和接收就能一一对应了。分包的时候不一定能完整的恰好分成多个完整的LEN的包，最后一个包一般都会小于LEN，这时候最后一个包可以在不足的部分填充空白字节。
当然，这种方法会有缺陷。1.最后一个包的不足长度被填充为空白部分，也即无效字节序。那么接收方可能难以辨别这无效的部分，它本身就是为了补位的，并无实际含义。这就为接收端处理其含义带来了麻烦。当然也有解决办法，可以通过增添标志位的方法来弥补，即在每一个数据包的最前面增加一个定长的报头，然后将该数据包的末尾标记一并发送。接收方根据这个标记确认无效字节序列，从而实现数据的完整接收。2.在发送包长度随机分布的情况下，会造成带宽浪费。比如发送长度可能为 1,100,1000,4000字节等等，则都需要按照定长最大值即4000来发送，数据包小于4000字节的其他包也会被填充至4000，造成网络负载的无效浪费。
综上，此方案适在发送数据包长度较为稳定(趋于某一固定值)的情况下有较好的效果。

2.2 设计方案二：尾部标记序列
在每个要发送的数据包的尾部设置一个特殊的字节序列，此序列带有特殊含义，跟字符串的结束符标识”\0”一样的含义，用来标示这个数据包的末尾，接收方可对接收的数据进行分析，通过尾部序列确认数据包的边界。
这种方法的缺陷较为明显：1.接收方需要对数据进行分析，甄别尾部序列。2.尾部序列的确定本身是一个问题。什么样的序列可以向”\0”一样来做一个结束符呢？这个序列必须是不具备通常任何人类或者程序可识别的带含义的数据序列，就像“\0”是一个无效字符串内容，因而可以作为字符串的结束标记。那普通的网络通信中，这个序列是什么呢？我想一时间很难找到恰当的答案。

2.3 设计方案三：头部标记分步接收
这个方法是作者有限学识里最好的办法了。它既不损失效率，还完美解决了任何大小的数据包的边界问题。
这个方法的实现是这样的，定义一个用户报头，在报头中注明每次发送的数据包大小。接收方每次接收时先以报头的size进行数据读取，这必然只能读到一个报头的数据，从报头中得到该数据包的数据大小，然后再按照此大小进行再次读取，就能读到数据的内容了。这样一来，每个数据包发送时都封装一个报头，然后接收方分两次接收一个包，第一次接收报头，根据报头大小第二次才接收数据内容。（此处的data[0]的本质是一个指针，指向数据的正文部分，也可以是一篇连续数据区的起始位置。因此可以设计成data[user_size]，这样的话。）
下面通过一个图来展现设计思想。



由图看出，数据发送多了封装报头的动作；接收方将每个包的接收拆分成了两次。
这方案看似精妙，实则也有缺陷：1.报头虽小，但每个包都需要多封装sizeof(_data_head)的数据，积累效应也不可完全忽略。2.接收方的接收动作分成了两次，也就是进行数据读取的操作被增加了一倍，而数据读取操作的recv或者read都是系统调用，这对内核而言的开销是一个不能完全忽略的影响，对程序而言性能影响可忽略（系统调用的速度非常快）。
优点：避免了程序设计的复杂性，其有效性便于验证，对软件设计的稳定性要求来说更容易达标。综上，方案三乃上上策！

致 热爱技术和努力的人们 ！ 2015/11/29 凌晨
<<END>>