TCP粘包, UDP丢包, nagle算法

一、TCP粘包

1. 什么时候考虑粘包

  1. 如果利用tcp每次发送数据,就与对方建立连接,然后双方发送完一段数据后,就关闭连接,这样就不会出现粘包问题(因为只有一种包结构,类似于http协议,UDP不会出现粘包现象)。关闭连接主要要双方都发送close连接(参考tcp关闭协议)。如:A需要发送一段字符串给B,那么A与B建立连接,然后发送双方都默认好的协议字符如"hello give me sth abour yourself",然后B收到报文后,就将缓冲区数据接收,然后关闭连接,这样粘包问题不用考虑到,因为大家都知道是发送一段字符。
  2. 如果发送数据无结构,如文件传输,这样发送方只管发送,接收方只管接收存储就ok,也不用考虑粘包
  3. 如果双方建立连接,需要在连接后一段时间内发送不同结构数据,如连接后,有好几种结构:
     1)"hello give me sth abour yourself" 
     2)"Don‘t give me sth abour yourself" 
       那这样的话,如果发送方连续发送这个两个包出去,接收方一次接收可能会是"hello give me sth abour yourselfDon‘t give me sth abour yourself" 这样接收方就傻了,到底是要干嘛?不知道,因为协议没有规定这么诡异的字符串,所以要处理把它分包,怎么分也需要双方组织一个比较好的包结构,所以一般可能会在头加一个数据长度之类的包,以确保接收。

2. 粘包出现的原因 :  在流传输中会出现(如TCP),UDP不会出现粘包(数据报传输)

发送端需要等缓冲区满才发送出去,造成粘包  (nalge算法也可能造成粘包现象)
     接收方不及时接收缓冲区的包,造成多个包接收

3. 粘包解决的办法

一是对于发送方引起的粘包现象,用户可通过编程设置来避免,TCP提供了强制数据立即传送的操作指令push,TCP软件收到该操作指令后,就立即将本段数据发送出去,而不必等待发送缓冲区满;

二是对于接收方引起的粘包,则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施,使其及时接收数据,从而尽量避免出现粘包现象;

三是由接收方控制,将一包数据按结构字段,人为控制分多次接收,然后合并,通过这种手段来避免粘包。

还有的笨方法是在两次send函数之间添加 sleep函数, 显然会降低数据传输效率

以上提到的三种措施,都有其不足之处。

第一种编程设置方法虽然可以避免发送方引起的粘包,但它关闭了优化算法,降低了网络发送效率,影响应用程序的性能,一般不建议使用。

第二种方法只能减少出现粘包的可能性,但并不能完全避免粘包,当发送频率较高时,或由于网络突发可能使某个时间段数据包到达接收方较快,接收方还是有可能来不及接收,从而导致粘包。

第三种方法虽然避免了粘包,但应用程序的效率较低,对实时应用的场合不适合。

4.  解决粘包的工程方法:

上面处理TCP粘包的方案: 存在不同程度的硬伤 , 在工程上并不适用,工程项目中,根据数据传输的特点,推荐两种可选择的方案:

1. 添加标志字段,在每次发送数据是添加标记字段:A: =>size 标记数据长度的方式  B:特定标记字段标记数据的结尾(模仿帧的设计方式)=>结束符的方式

2. 定义应用层的数据通讯协议 :=>如果数据按照一定的方式存储或着优加密的需求, 可以通过自己定制 数据通讯协议对数据封装,并实现自己的数据 封包| 拆包函数。

细节:

1. 环形缓冲实现方案是定义两个指针,分别指向有效数据的头和尾.在存放数据和删除数据时只是进行头尾指针的移动.

二、UDP丢包

1.丢包的主要原因

  1. 接收端处理时间过长导致丢包:调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端,将包接收后存入一个缓冲区,然后迅速返回继续recv.
  2. 发送的包较大,超过接受者缓存导致丢包:包超过mtu size数倍,几个大的udp包可能会超过接收者的缓冲,导致丢包
  3. 发送的包频率太快:虽然每个包的大小都小于mtu size 但是频率太快

2. 解决方案

1 模拟tcp三次握手协议,通过使用Timer定时器监视发送请求后接受数据的时间,如果一段时间内没有接受到数据包则判定丢包,并重新发送本次请求

2. 换TCP

三、nagle算法

nagle 算法   糊涂窗口综合症(Silly Windw Syndrome)    TCP_NODELAY 选项  (百度百科)

四、长链接  vs 短链接 

1.长连接

Client方与Server方先建立通讯连接,连接建立后不断开, 然后再进行报文发送和接收。

2.短连接

Client方与Server每进行一次报文收发交易时才进行通讯连接,交易完毕后立即断开连接。此种方式常用于一点对多点

时间: 2024-10-15 13:11:56

TCP粘包, UDP丢包, nagle算法的相关文章

嵌入式开发之UDP 丢包--- UDP 丢包控制方法

0. 发送端可以,发送五次左右,再Sleep 1.调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的包可能丢失.对于这种情况可以修改接收端,将包接收后存入一个缓冲区,然后迅速返回继续recv. 2.发送的包巨大丢包.虽然send方法会帮你做大包切割成小包发送的事情,但包太大也不行.例如超过50K的一个udp包,不切割直接通过send方法发送也会导致这个包丢失.这种情况需要切割成小包再逐个send. 3.发送的包较大,超过mtu si

UDP丢包和无序 问题的解决方法

最近在做一个项目,在这之前,做了个验证程序. 发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象. 纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了. 我用过sleep(10),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失. 你试着用阻塞模式吧... select...我开始的时候好像也遇到过..不过改为阻塞模式后就没这个问题了... 采用回包机制,每个发包必须收到回包后再发下一个 UDP丢包是正常现象,因

[转]UDP丢包原因

原文地址:http://www.cnblogs.com/mengyan/archive/2012/10/04/2711340.html 一.主要丢包原因 1.接收端处理时间过长导致丢包:调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的包可能丢失.对于这种情况可以修改接收端,将包接收后存入一个缓冲区,然后迅速返回继续recv. 2.发送的包巨大丢包:虽然send方法会帮你做大包切割成小包发送的事情,但包太大也不行.例如超过50K的一

linux 系统 UDP 丢包问题分析思路

转自:http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考. 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程. 首先网络报文通过物理网线发送到网卡 网络驱动程序会把网络中的报文读出来放到

java socket编程解决粘包和丢包问题

##socket 丢包粘包解决方式 采用固定头部长度(一般为4个字节),包头保存的是包体的长度 header+body 包头+包体 思路是:先读出一个包头,得到包体的长度,解析出包体 public class SocketServer { public static void main(String args[]) { ServerSocket serverSocket; try { serverSocket = new ServerSocket(); serverSocket.bind(new

linux系统内核UDP丢包原因分析

1.UDP校验和错误 现象:可以用netstat -su 查看到有UDP错包. tcpdump捕包,在wireshark打开捕获的udp报文,开启校验和选项,有错包. 方案:查找链路故障  www.ahlinux.com 2.防火墙开启 现象:特定端口的包收不到 方案:使用service iptables stop关闭. 3.rp_filter开启 现象:tcpdump有包,协议栈收不到.某个地址发送的包一个包都收不到,而另一地只发过来的没问题. 方案:将/etc/sysctl.conf中rp_

浅谈UDP(数据包长度,收包能力,丢包及进程结构选择)

UDP数据包长度 UDP数据包的理论长度 udp数据包的理论长度是多少,合适的udp数据包应该是多少呢?从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大包长度是2^16-1的个字节.由于udp包头占8个字节,而在ip层进行封装后的ip包头占去20字节,所以这个是udp数据包的最大理论长度是2^16-1-8-20=65507. 然而这个只是udp数据包的最大理论长度.首先,我们知道,TCP/IP通常被认为是一个四层协议系统,包括链路层.网络层.运输层.应用层.UDP属于运输

UDP主要丢包原因及具体问题分析

一.主要丢包原因 1.接收端处理时间过长导致丢包:调用recv方法接收端收到数据后,处理数据花了一些时间,处理完后再次调用recv方法,在这二次调用间隔里,发过来的包可能丢失.对于这种情况可以修改接收端,将包接收后存入一个缓冲区,然后迅速返回继续recv. 2.发送的包巨大丢包:虽然send方法会帮你做大包切割成小包发送的事情,但包太大也不行.例如超过50K的一个udp包,不切割直接通过send方法发送也会导致这个包丢失.这种情况需要切割成小包再逐个send. 3.发送的包较大,超过接受者缓存导

记录一个UDP收包丢包的问题

这几天写GB28181平台接入层代码,对收到的PS包进行解包时,总是出现误码,最终导致rtsp点播服务中画面花屏. 分析了码流抓包数据之后,发现网络上没有丢包,遂认为PS流解包代码有bug,于是埋头分析了2个小时的解包函数后,没有发现问题.将抓包RTP负载中的PS包数据导出之后,专门利用PS解包代码写了一个小程序,对导出的数据进行处理,又没有问题——后来事实证明解包代码的确没有问题,而且这部分的代码是在其他项目中用过的.自己有些迷糊了,一时想不明白问题出在哪里. 起身转了几圈冷静后分析一下,认为