有关TCP和UDP 粘包 消息保护边界

http://www.cnblogs.com/lancidie/archive/2013/10/28/3392428.html

在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的。因此TCP的socket编程,收发两端(客户端和服务器端)都要有一一成对的 socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一 个大的数据块,然后进行封包。这样,接收端,就难于分辨出来了,必须提供科学的拆包机制。 对于UDP,不会使用块的合并优化算法,这样,实际上目前认为,是由于UDP支持的是一对多的模式,所以接收端的skbuff(套接字缓冲区)采用了链式 结构来记录每一个到达的UDP包,在每个UDP包中就有了消息头(消息来源地址,端口等信息),这样,对于接收端来说,就容易进行区分处理了

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

保护消息边界,就是指传输协议把数据当作一条独立的消息在网上传输,接收端只能接收独立的消息.也就是说存在保护消息边界,接收  端一次只能接收发送端发出的一个数据包.   而面向流则是指无保护消息保护边界的,如果发送端连续发送数据,  接收端有可能在一次接收动作中,会接收两个或者更多的数据包. 我们举个例子来说,例如,我们连续发送三个数据包,大小分别是2k,  4k , 8k,这三个数据包,都已经到达了接收端的网络堆栈中,如果使  用UDP协议,不管我们使用多大的接收缓冲区去接收数据,我们必须有  三次接收动作,才能够把所有的数据包接收完.而使用TCP协议,我们  只要把接收的缓冲区大小设置在14k以上,我们就能够一次把所有的  数据包接收下来.只需要有一次接收动作.  这就是因为UDP协议的保护消息边界使得每一个消息都是独立的.而  流传输,却把数据当作一串数据流,他不认为数据是一个一个的消息. 所以有很多人在使用tcp协议通讯的时候,并不清楚tcp是基于流的  传输,当连续发送数据的时候,他们时常会认识tcp会丢包.其实不然,  因为当他们使用的缓冲区足够大时,他们有可能会一次接收到两个甚  至更多的数据包,而很多人往往会忽视这一点,只解析检查了第一个  数据包,而已经接收的其他数据包却被忽略了.所以大家如果要作这  类的网络编程的时候,必须要注意这一点.  结论:  根据以上所说,可以这样理解,TCP为了保证可靠传输,尽量减少额外 开销(每次发包都要验证),因此采用了流式传输,面向流的传输, 相对于面向消息的传输,可以减少发送包的数量。从而减少了额外开
销。但是,对于数据传输频繁的程序来讲,使用TCP可能会容易粘包
当然,对接收端的程序来讲,如果机器负荷很重,也会在接收缓冲里 粘包。这样,就需要接收端额外拆包,增加了工作量因此,这个特
别适合的是数据要求可靠传输,但是不需要太频繁传输的场合
(  两次操作间隔100ms,具体是由TCP等待发送间隔决定的,取决于内核
中的socket的写法)   而UDP,由于面向的是消息传输,它把所有接收到的消息都挂接到缓冲
区的接受队列中,因此,它对于数据的提取分离就更加方便,但是, 它没有粘包机制,因此,当发送数据量较小的时候,就会发生数据包
有效载荷较小的情况,也会增加多次发送的系统发送开销(系统调用, 写硬件等)和接收开销。因此,应该最好设置一个比较合适的数据包
的包长,来进行UDP数据的发送。(UDP最大载荷为1472,因此最好能 每次传输接近这个数的数据量,这特别适合于视频,音频等大块数据
的发送,同时,通过减少握手来保证流媒体的实时性

时间: 2024-08-11 01:21:50

有关TCP和UDP 粘包 消息保护边界的相关文章

【转】关于TCP和UDP协议消息保护边界的介绍

在 socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因此TCP的socket编程,收发两端(客户端和服务器端)都要有一一成对的 socket,因此,发送端为了将多个发往接收端的包,更有效的发到对方,使用了优化方法(Nagle算法),将多次间隔较小且数据量小的数据,合并成一个大的数据块,然后进行封包.这样,接收端,就难于分辨出来了,必须提供科学的拆包机制.对于UDP,不会使用块的合并优化算法,这样,实际上目前认为,是由于UDP支持的是一对多的模式,所以接收端的skbuff(套接

tcp协议下粘包问题的产生及解决方案

1.粘包产生原因: (1)TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一个TCP段.若连续几次需要send的数据都很少,通常TCP会根据优化算法(Nagle)把这些数据合成一个TCP段后一次发送出去,这样接收方就收到了粘包数据: (2)接收方不知道消息之间的界限,不知道一次性提取多少字节的数据:接收时有字节的限制,如果超过这个限制没有接收完的会留在 操作系统缓存,下次再执行命令获取结果时,优先收取上次命令结果残留的信息: 注:UDP是无连接的,面向消息的,提供高效率服务.不会使用

TCP网络传输“粘包”问题,经典解决(附代码)

一.前言 关于TCP网络传输粘包,网上很多人写了原理.总结起来就一句话:这里拿Server和Client长连接,Server和Client之间通过信令传输做说明: Server发送的时候按照一条条信令发送,到达操作系统网络层,首先进入缓冲池,然后TCP协议层从池子中获取数据,传输给Client.我们知道TCP的传输有几个方案,比如,滑动窗口.1比特方案.所以Client收到的数据已经不可能是一个个完整的信令的. 个人理解TCP粘包的概念:它描述了一个场景:"信令是一个个紧挨着的,好像是被粘在一起

Netty系列(四)TCP拆包和粘包

Netty系列(四)TCP拆包和粘包 一.拆包和粘包问题 (1) 一个小的Socket Buffer问题 在基于流的传输里比如 TCP/IP,接收到的数据会先被存储到一个 socket 接收缓冲里.不幸的是,基于流的传输并不是一个数据包队列,而是一个字节队列.即使你发送了 2 个独立的数据包,操作系统也不会作为 2 个消息处理而仅仅是作为一连串的字节而言.因此这是不能保证你远程写入的数据就会准确地读取.举个例子,让我们假设操作系统的 TCP/TP 协议栈已经接收了 3 个数据包: 由于基于流传输

TCP 拆、粘包

Netty(三) 什么是 TCP 拆.粘包?如何解决? 前言 记得前段时间我们生产上的一个网关出现了故障. 这个网关逻辑非常简单,就是接收客户端的请求然后解析报文最后发送短信. 但这个请求并不是常见的 HTTP ,而是利用 Netty 自定义的协议. 有个前提是:网关是需要读取一段完整的报文才能进行后面的逻辑. 问题是有天突然发现网关解析报文出错,查看了客户端的发送日志也没发现问题,最后通过日志发现收到了许多不完整的报文,有些还多了. 于是想会不会是 TCP 拆.粘包带来的问题,最后利用 Net

TCP和UDP数据包大小限制

1.概述 首先要看TCP/IP协议,涉及到四层:链路层,网络层,传输层,应用层. 其中以太网(Ethernet)的数据帧在链路层 IP包在网络层 TCP或UDP包在传输层 TCP或UDP中的数据(Data)在应用层 它们的关系是 数据帧{IP包{TCP或UDP包{Data}}}     不同的协议层对数据包有不同的称谓,在传输层叫做段(segment),在网络层叫做数据报(datagram),在链路层叫做帧(frame).数据封装成帧后发到传输介质上,到达目的主机后每层协议再剥掉相应的首部,最后

关于TCP封包、粘包、半包

关于Tcp封包 很多朋友已经对此作了不少研究,也花费不少心血编写了实现代码和blog文档.当然也充斥着一些各式的评论,自己看了一下,总结一些心得. 首先我们学习一下这些朋友的心得,他们是: http://blog.csdn.net/stamhe/article/details/4569530 http://www.cppblog.com/tx7do/archive/2011/05/04/145699.html //……………… 当然还有太多,很多东西粘来粘区也不知道到底是谁的原作,J 看这些朋友

python学习_day30_基于tcp协议的粘包现象

1.基于远程执行命令的程序 需用到subprocess模块 服务端: #1.执行客户端发送的指令 import socket import subprocess phone=socket.socket(socket.AF_INET,socket.SOCK_STREAM) phone.bind(('127.0.0.1',8090)) phone.listen(5) while True: conn,addr=phone.accept() print('IP:%s PORT:%s' %(addr[0

基于tcp协议下粘包现象和解决方案

一.缓冲区 每个 socket 被创建后,都会分配两个缓冲区,输入缓冲区和输出缓冲区.write()/send() 并不立即向网络中传输数据,而是先将数据写入缓冲区中,再由TCP协议将数据从缓冲区发送到目标机器.一旦将数据写入到缓冲区,函数就可以成功返回,不管它们有没有到达目标机器,也不管它们何时被发送到网络,这些都是TCP协议负责的事情.TCP协议独立于 write()/send() 函数,数据有可能刚被写入缓冲区就发送到网络,也可能在缓冲区中不断积压,多次写入的数据被一次性发送到网络,这取决