TCP和UDP的“保护消息边界”(粘包、半包)

TCP是面向连接,面向流的(有可能会出项粘包情况),提供高可靠服务性。因此TCP,使用了优化方法,将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包。这样,接收端收到的包可能会被切开或者合并的,必须提供科学的拆包机制。

UDP是面向非连接,会保证消息的保护边界,不会使用块的合并优化算法,这样,实际上目前认为,是由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了


保护消息边界和流 那么什么是保护消息边界和流呢?

保护消息边界,就是指传输协议把数据当作一条独立的消息在网上 传输,接收端只能接收独立的消息.也就是说存在保护消息边界,接收
端一次只能接收发送端发出的一个数据包.
而面向流则是指无保护消息保护边界的,如果发送端连续发送数据, 接收端有可能在一次接收动作中,会接收两个或者更多的数据包.

我们举个例子来说,例如,我们连续发送三个数据包,大小分别是2k, 4k , 8k,这三个数据包,都已经到达了接收端的网络堆栈中,如果使
用UDP协议,不管我们使用多大的接收缓冲区去接收数据,我们必须有 三次接收动作,才能够把所有的数据包接收完.而使用TCP协议,我们
只要把接收的缓冲区大小设置在14k以上,我们就能够一次把所有的 数据包接收下来.只需要有一次接收动作.

这就是因为UDP协议的保护消息边界使得每一个消息都是独立的.而 流传输,却把数据当作一串数据流,他不认为数据是一个一个的消息.


所以有很多人在使用tcp协议通讯的时候,并不清楚tcp是基于流的 传输,当连续发送数据的时候,他们时常会认识tcp会丢包.其实不然,
因为当他们使用的缓冲区足够大时,他们有可能会一次接收到两个甚 至更多的数据包,而很多人往往会忽视这一点,只解析检查了第一个
数据包,而已经接收的其他数据包却被忽略了.所以大家如果要作这 类的网络编程的时候,必须要注意这一点.



结论:
根据以上所说,可以这样理解,TCP为了保证可靠传输,尽量减少额外 开销(每次发包都要验证),因此采用了流式传输,面向流的传输, 相对于面向消息的传输,可以减少发送包的数量。从而减少了额外开 销。但是,对于数据传输频繁的程序来讲,使用TCP可能会容易粘包。
当然,对接收端的程序来讲,如果机器负荷很重,也会在接收缓冲里 粘包。这样,就需要接收端额外拆包,增加了工作量。因此,这个特
别适合的是数据要求可靠传输,但是不需要太频繁传输的场合( 两次操作间隔100ms,具体是由TCP等待发送间隔决定的,取决于内核
中的socket的写法)

而UDP,由于面向的是消息传输,它把所有接收到的消息都挂接到缓冲 区的接受队列中,因此,它对于数据的提取分离就更加方便,但是,
它没有粘包机制,因此,当发送数据量较小的时候,就会发生数据包 有效载荷较小的情况,也会增加多次发送的系统发送开销(系统调用,
写硬件等)和接收开销。因此,应该最好设置一个比较合适的数据包 的包长,来进行UDP数据的发送。(UDP最大载荷为1472,因此最好能
每次传输接近这个数的数据量,这特别适合于视频,音频等大块数据 的发送,同时,通过减少握手来保证流媒体的实时性)

来自: http://hi.baidu.com/chongerfeia/blog/item/b1e572f631dd7e28bd310965.html

TCP无保护消息边界的解决
针对这个问题,一般有3种解决方案:

  (1)发送固定长度的消息

  (2)把消息的尺寸与消息一块发送

  (3)使用特殊标记来区分消息间隔

下面我们主要分析下前两种方法:

1、发送固定长度的消息
这种方法的好处是他非常容易,而且只要指定好消息的长度,没有遗漏未未发的数据,我们重写了一个SendMessage方法。代码如下:

 private static int SendMessage(Socket s, byte[] msg)

        { 
            int offset = 0; 
            int size = msg.Length; 
            int dataleft = size;

            while (dataleft > 0) 
            {

                int sent = s.Send(msg, offset, SocketFlags.None); 
                offset += sent; 
                dataleft -= sent;

            }

            return offset; 
        }

简要分析一下这个函数:形参s是进行通信的套接字,msg即待发送的字节数组。该方法使用while循环检查是否还有数据未发送,尤其当发送一个很庞大的数据包,在不能一次性发完的情况下作用比较明显。特别的,用sent来记录实际发送的数据量,和recv是异曲同工的作用,最后返回发送的实际数据总数。

有sentMessage函数后,还要根据指定的消息长度来设计一个新的Recive方法。代码如下:

private byte[] ReciveMessage(Socket s, int size) 
        {

            int offset = 0; 
            int recv; 
            int dataleft = size; 
            byte[] msg = new byte[size];


            while (dataleft > 0)

            {

                //接收消息 
                recv = s.Receive(msg, offset, dataleft, 0); 
                if (recv == 0)

                {

                    break;

                } 
                offset += recv; 
                dataleft -= recv;

            }

            return msg;

        }

以上这种做法比较适合于消息长度不是很长的情况。

2、消息长度与消息一同发送

我们可以这样做:通过使用消息的整形数值来表示消息的实际大小,所以要把整形数转换为字节类型。下面是发送变长消息的SendMessage方法。具体代码如下:

 private static int SendMessage(Socket s, byte[] msg) 
        {

            int offset = 0; 
            int sent; 
            int size = msg.Length; 
            int dataleft = size; 
            byte[] msgsize = new byte[2];

            //将消息尺寸从整形转换成可以发送的字节型 
            msgsize = BitConverter.GetBytes(size);


            //发送消息的长度信息 
            sent = s.Send(size);

            while (dataleft > 0)

            {

                sent = s.Send(msg, offset, dataleft, SocketFlags.None);

                //设置偏移量

                offset += sent; 
                dataleft -= sent;

            }

            return offset;

        }

下面是接收变长消息的ReciveVarMessage方法。代码如下:

private byte[] ReciveVarMessage(Socket s) 
        {


            int offset = 0; 
            int recv; 
            byte[] msgsize = new byte[2];


            //将字节数组的消息长度信息转换为整形 
            int size = BitConverter.ToInt16(msgsize); 
            int dataleft = size; 
            byte[] msg = new byte[size];


            //接收2个字节大小的长度信息 
            recv = s.Receive(msgsize, 0, 2, 0); 
            while (dataleft > 0) 
            {

                //接收数据 
                recv = s.Receive(msg, offset, dataleft, 0); 
                if (recv == 0) 
                { 
                    break; 
                } 
                offset += recv; 
                dataleft -= recv;

            }

            return msg;

        }

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/xinshi9608/archive/2010/12/31/6109511.aspx

  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
TCPUDP在传输过程中都可能会出现分包和粘包的问题,但是处理方式有所不同。 对于TCP协议,如果定义的TCP包没有超过范围,即在IP层不需要分包,传输过程中就可以避免IP层组包发生的错误。但是如果超过范围,即IP数据报大于1500字节,发送方IP层就需要将数据包分成若干片,而接收方IP层则需要进行数据报的重组。TCP协议保证了可靠传输,如果发生组包错误,该包会被重传,确保数据的可靠性。\[1\] 对于UDP协议,由于UDP发送时没有经过Negal算法优化,不会将多个小包合并一次发送出去,因此不存在粘包问题。在UDP协议的接收端,采用了链式结构来记录每一个到达的UDP包,这样接收端应用程序一次recv只能从socket接收缓冲区中读出一个数据包。也就是说,发送端send了几次,接收端必须recv几次(无论recv时指定了多大的缓冲区)。因此,UDP协议不会出现粘包问题。\[2\] 总结来说,TCP协议在IP层可能会发生分包和组包的情况,但会保证可靠传输;而UDP协议不存在粘包问题,每个UDP包都是独立的。 #### 引用[.reference_title] - *1* *2* *3* [tcpudp、分包粘包](https://blog.csdn.net/liao_hb/article/details/106382297)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^control_2,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值