中文字符在网络传输中粘包问题研究.docVIP

中文字符在网络传输中“粘包”问题研究 　　摘要：TCP提供了一种面向连接的、可靠的字节流服务。但字节流式传输将导致应用层的数据到达接收端后产生半包、粘包等现象。针对如何还原发送端数据，给出了一个基于正则表达式的解决方案，并用C#语言进行了实现。测试结果表明，该方案能很好地解决中文传输的粘包问题，并已经应用到实际项目中。 　　关键词：网络传输；粘包；半包；正则表达式 　　中图分类号：TP301文献标识码：A文章编号2013）004004403 　　0引言 　　TCP协议在传输报文段时会产生半包、粘包问题，主要有以下3个方面的原因： 　　（1）协议自身无消息边界。两个应用程序通过TCP连接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。 　　（2）应用程序数据被分段或合并。当程序的一个数据包比较大时，会被放到若干个TCP报文段中传输；数据包比较小时，一个TCP报文段会携带几个数据包；TCP报文段也可能是其它形式数据包的组合。 　　（3）缓冲区工作机制。为了提高效率，发送方要等到发送缓冲区满，才会把TCP报文段发送出去。接收方同样也会等到缓冲区满才读取数据。 　　举例：如果一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发送方每次发送了多少个字节。接收方可以分4次接收这80个字节，每次20个字节。这样一来，前一次发的数据就会和后发的数据粘合在一起；也可能接收方在读数据时只能读取发送数据的一部分。 　　解决TCP消息无边界，通常有3种办法：①发送固定长度的消息，此方法简单但缺少灵活性；②使用特殊标记分隔消息，此方法需要处理消息的内容；③将消息长度与消息一起发送，此方法灵活但增加开销。 　　1问题产生分析 　　英文字符在网络传输时采用ASCII编码，而中文在网络传输时不能采用ASCII编码的方式，ASCII编码使用固定字节的编码方式，无论发送方和接收方都比较容易处理。 　　ACII编码不能对中文字符编码，在网络传输时可直接采用UTF8编码，这样在发送方不会产生太多问题。但是由于UTF8编码对中文采用不固定字节长度的编码方式，在接收方如果接收的不是完整包，就很容易产生各种问题。比如：若接收方只收到某个中文字符的部分字节，而该中文字符的其余字节还没有收到。在应用层采用基于正文的处理方式，进行读取该数据包的有效长度时会先把字节转换成字符，再进行匹配，取有效长度。收到字节数组在向中文字符转换时，由于不是完整的正文字节数，就会产生乱码，计算转换后的字符串字节长度就会导致与收到的字节长度不一致，可能会产生本来没有收到完整的包但计算的结果是字符已经接收完毕。本文提出一种基于正则表达式解决方案，将消息长度与消息一起发送。 　　2解决方案 　　本文将在消息长度与消息一起发送的方法基础上进行改进，提出一种基于正则表达式的方法解决上述问题。 　　2.1协议设计 　　数据报分首部和数据两部分组成，如图1所示。 　　首部字符串格式为：＼[length=？＼]，其中问号为数据部分长度，单位为字节（不是字体数）。注：若数据部分有与首部同格式字符，则进行变换，此处不再进行叙述。 　　2.2正则表达式设计 　　针对协议首部格式，正则表达式设计为：？d1，收到的是多包，取出第一段有效消息，转到（3），处理剩余部分。 　　（5）得到完整数据的字节数组，对字节数组转换到中文字符串，转到（6）。 　　（6）程序结束。 　　2.4流程 　　总的程序流程如图2所示，流程图1为主调函数部分，实现依次处理每个完整的报文段，流程图2实现取单个完整数据包部分，流程图3为半包、单包和多包分别处理。 　　2.5实现 　　定义一个类StickPackag，类有数据成员temp和函数成员GetAllActualString和GetActualString。temp用来缓存不完整的包，GetAllActualString通过调用GetActualString函数返回所有完整包，GetActualString通过每次取出一个完整包。代码用C#语言实现，如下： 　　public class StickPackage 　　{ 　　byte[]temp； 　　public string[]GetAllActualString（byte[]inputbyte） 　　{ 　　byte[][]dbyte=GetActualString（inputbyte， null）； 　　Listlist=new List（）； 　　foreach （byte[]bs in dbyte） 　　{ 　　list.Add（Encoding.UTF8.GetString（bs））； 　　} 　　return list.ToArray（）； 　　} 　　priva