精华内容
下载资源
问答
  • 大家有没有发现无线网络中多播的丢包率很高
    千次阅读
    2020-12-20 15:20:28

    在linux下用vlc在若干笔记本组成的无线网络中做视频传输实验

    如果用单播(unicast)的udp,效果很好,很流畅

    但如过用多播(Multicast)的udp,效果就很差,接收的图像上有很多方块,根本看不清图像

    换成rtp也没有好转

    谁知道为什么这种广播传输,丢包率就这么高?

    怎么解决呢?怎么能让广播包和单播包“一视同仁”阿?

    3x!bow//

    应当确定哪个环节丢包显著增加。

    如果是接收端以太网芯片收到了但是丢弃了一部分,那么查看下它的控制工作方式,应该不难搞定的。

    和组播包的重传有关?

    udp应该没有重传吧?偶弱。。。。

    组播协议要考虑重传吧

    只看过相关paper,没看过相关协议代码,瞎猜的

    能不能说详细一点儿,比如说路由协议是啥?网络拓扑如何?

    ad hoc网络?通过802.11互联?

    没什么路由协议,就是两台thinkpad,其中一个笔记本用webcam采集视频,然后传给另一台显示。

    可以说是ad-hoc吧,因为两个本连在一个ap上,在同一个子网里,一跳就可以传到。

    是用802.11b协议

    不清楚利用Multicast的UDP是咋实现的,是不是用了MAC层的广播包

    如果是,有一个可能的理由

    实验的链路质量较差,或者有其它局域网干扰,MAC层有一定的误帧率。这时,广播包在MAC层没有ACK,而单播包在MAC层有ACK,可以重传几次,直至超时。传输层用UDP是没有反馈的,但是考虑到底下的MAC层,还是有的。

    .66

    802.11中的多播/广播数据在MAC层上是没有重传的,单播有ACK。所以组播的数据包丢失

    会比较严重。本身IP组播和UDP单播都没有重传,应该和IP层、传输层没有关系。

    还有一种可能性就是,现在的无线路由器应该都用类似IGMP snooping的机制在2层上做

    组播,IGMP snooping给处理器带来比较大的压力,尤其是组播的视频码率比较高的原因

    我们以前在netgear的无线路由器上弄组播的时候(高码率),经常AP就无反映了。

    要是这样的话,这个问题岂不是无解了?

    那现有无线视频广播都是怎么搞定的呢?

    ms有可能是第一种情况,因为当两个机器同时接收的广播包时,往往会丢失同样的包

    对了,一般丢包会有多严重,我的有百分之十几甚至二十的丢包率 :(

    在应用层看来的丢包可能是链路误码或者是丢包。可以先用一些网络测量工具,如iper

    f测一下udp传输下的丢包率看看有多大?

    如果想测误码率就比较难了。用madwifi驱动可以,要让驱动不过滤那些crc校验错误的

    数据包,然后根据mac地址来分析。

    20%的丢包率很高了把。一般没有那么夸张啊。

    你说的那个可能性应该是不存在的

    如果这个ap起了多个ssid,不开启igmp snooping的话,会是马赛克的,其实2个ssid就这

    样了

    而开启igmp snooping之后,播放会很流畅

    多播的mac层应该是用广播包,这个是没有ARQ的吧。

    跟踪这个系列有一阵子了,越看越胡涂。lz原来说若干笔记本,这样组播还说得过去。

    现在怎么样变成两台了,两台笔记本为啥要组播?另外没弄懂到底是ad-hoc还是infras

    tructure。如果是前者,AP就没啥用了。如果是后者,即便是同一子网,也得两跳(经

    AP接力)。接下来几位指出的问题多是协议参数,但是这些参数应该跟拓扑很有关系的

    ,所以偶一直想搞清楚拓扑...

    事情是这样子滴

    我用的笔记本可能是因为驱动问题,不能设成ad-hoc模式,所以几台笔记本都连到一个无线路由器上,但因为都处在一个网段,比如都处在192.168.1.0这个网段上,那么两台笔记本是可以直接连接的,比如IP为192.168.1.5的本本就可以一跳到达IP为192.168.1.6的本本。

    实验设计的是1台本本发送,n(n>=1)台接收,中间没有任何中继,就是简单的1对多无线组播。不过为了简单起见,在调试的时候我就只用一台来接收了

    可是按说我这种传输是在子网内一跳就能完成的,不会经过无线路由器转发阿

    11e中才定义了direct link吧

    我觉得现在能用到的多数网卡还是需要两跳的,sta1-ap-sta2,即使sta1和sta2在一个

    网段

    我现在不确定的是,AP向各STA发送组播报文时,STA还回应ACK么

    我也不知道哦。。。不过看前面的大大的回复,似乎广播情况下mac层是不回复ACK的。

    有什么工具可以检测ACK 吗?

    兄台有所不懂,一个是重传最多7次,一个根本不重传,

    怎么能是“一视同仁” 呢?

    更多相关内容
  • 说到网络技术,我个人比较关注IP,其次是链路设备,然后才是TCP,这可能跟我第一次接触网络技术时所遇到的公司有关,它们是华为3Com以及Cisco,而不是Google,Yahoo或者BAT。 然而能接触到的大多数的人可能更关注的...
    还像往常一样,本文的内容没有收敛,依然是随笔式的备忘,而不是文档。人在外地,本不该来的,也挺沮丧,不过每周总结总是必不可少。
    说到网络技术,我个人比较关注IP,其次是链路设备,然后才是TCP,这可能跟我第一次接触网络技术时所遇到的公司有关,它们是华为3Com以及Cisco,而不是Google,Yahoo或者BAT。
            然而能接触到的大多数的人可能更关注的是TCP,因为这是他们唯一能接触到的网络技术,虽然在侠义上,TCP并不属于网络,它是典型的一个端到端系统,网络只是它经由的一个路径。
            以公共交通系统为例,TCP比较类似票务和调度系统,它关注是否可以卖票,可以卖多少票,始发站是否可以发车,间隔多久发一班等等这种事情。至于车在途径道路上发生了什么,甚至途径哪些道路,票务系统并不关心,偶尔,小概率的,坐在公交总站的阿姨会接到电话,路上司机打来的,汇报一些突发情况,车坏了,车翻了,自己被捅了一刀...然后阿姨唯一能做的就是再派一辆车过去,她既无力修车,也无力修路,更无力(事实上也无权)惩罚歹徒...
    ...
            令人悲哀的痛点在于,一个承诺质量的端到端系统跑在一个根本无法保证质量的统计复用的分组交换网络里面!请注意,公路也是统计复用的分组交换网路。
             整个网络是拥塞的,而且随时都可能拥塞,如果我们想设计一个好的TCP,我们就必须能动态适应网络的当前状况,我们必须能够探知网络的当前状况,因此我们需要一个工具。
            在给出这个工具之前,我们先从Wireshark说起。

    1.如何看Wireshark里TCP trace图

    用Wireshark打开一个保存TCP流的pcap文件,点击“统计”-“TCP流图形”-“时间序列(tcptrace)”,我们可以看到一张图表,通过该图表可以探知关于网络状况的大部分细节:




    然而,促使我写自己工具的动机在于,TCP trace这个图受到TCP本身的拥塞控制算法的控制,因此它并不客观!诚然,如果发生了拥塞,拥塞窗口要下降,但是具体下降到多少合适,这个就是拥塞控制算法说了算了,而它是个黑盒子!另外,如果线路有噪声产生了误码,按照比较垃圾的拥塞控制算法,也会降低窗口,从图表上看,你会误以为发生了拥塞...
            因此,我需要一个比较客观的工具,也就是说它对网络状态是无知的,也不奢望获知网络状态,它只是按照自己的参数固定速率发送数据,然后我们通过回应来探测网络到底发生了什么。

    2.基于数据包守恒的ping -f

    在写工具之前,首先看看现成的ping -f是否好用。
            这个工具自己试一下便知,不多谈。事实上,它是基于数据包守恒的,即收到了n个Reply,发出去n个Request,因此它会根据网络的状态自动调速,但是它计算的是一种保守状态的丢包率,
    比如下面的序列:
    1).发出100个Request,收到100个Reply。
    2).发出100个Request,收到80个Reply,假设此时真的发生了拥塞丢包。
    3).发出80个Request,收到80个Reply,假设拥塞马上缓解了。
    4).请问怎么可以快速获知拥塞缓解了??

    因此我更希望的是,固定数量发出数据包,然后看回应:
    1).发出100个Request,收到100个Reply。
    2).发出100个Request,收到80个Reply,假设此时真的发生了拥塞丢包。
    3).发出100个Request,收到100个Reply,拥塞缓解马上被探知。

    3.我的Python工具概述

    在上面的篇幅,我给出了不用Wireshark和ping -f的理由:

    不用Wireshark的理由:

    它完全是TCP实现的行为勾画,在实现的很垃圾的TCP中,根本无法勾勒网络的状态,即便是在完美的TCP实现中,它表示的也是TCP如何反应网络状况变化的,这个信息丝毫没有指导意义,我们也很难知道网络到底发生了什么。总之,不同的TCP实现针对相同的网络质量会给出不同的数据,画出不同的图,而且,它太复杂了!

    不用ping -f的理由:

    很直接的说,ping -f跟tcptrace没有什么根本的不同,只是它的“拥塞控制”机制更加简单,完全就是根据数据包守恒来的。不多说了。
            我写这个工具完全是为了自用,而且确实也还可以,这个工具可以完成以下的功能:

    1).探测丢包率

    这种丢包率是客观的丢包率,包括噪声和排队造成的丢包。我基于ping -f修改了,把根据Reply的调速反馈机制去掉了,因为这样可以探测出更加详细的队形情况以及拥塞对丢包的影响。不然的话,如果使用ping -f,你不得不通过斜率来观测这种影响,而且当拥塞恢复,探测端无法及时感知。
            我在这里就不贴图了,基本就跟ping -f是一样的。

    2).探测RTT波动

    该工具最终会生成一个文件,该文件的截图如下:




    基于这个图画出一个图,类似tcptrace那样的:




    注意,我是用gnuplot画的,而不是Python,因为我在Windows上装Python画图库失败了,在Linux上没有X环境...所以本着UNIX组合小玩意的原则,我用Python生产并解析数据,然后用gnuplot来展现,我的画图脚本很简单:



    3).探测队列的队形

    和ping -f不同,我的工具可以生成点星文件("."表示收到了回应,"*"表示发送了数据),从点和星的分布,我们可以更加深入的探测队列细节。如下只是一个例子:



    动态的图跟ping -f 几乎一样:




    如果使用ping -f,你不得不时刻盯着点号的打印和消除...然后有个突增,随后有个突减,这意味着发生了排队且队列被突发清空...然而却没有留下数据事后分析。我的工具可以输出三种数据,首先,详细数据是可以无条件输出的,其次,你可以选择是看动态数据还是看静态的点星数据,事实上,通过详细的输出,完全可以生成后面两类数据,之所以在程序中直接支持,完全是为了方便。
            以RED队列为例,丢包往往是缓速随机的,然后如果拥塞不缓解,丢包就会趋于连续,表现为星号越来越连续且增多,点号的连续性则相反,趋于离散化...我的工具不重传,只观测,所以完全可以通过点星的分布来解析队列的细节,并且很有可能你能把路径上是否有UDP流氓找出来!即便你无法控制你的路径从而绕开,不也是可以反制一下么?你可以通过点星分布的变化情况得知拥塞是否由于发送端主动降速而缓解。

    4.如何使用这个工具

    首先,你不能盲目的去探测,你首先要有一个大概的拓扑。比如,还是baidu,我们想知道到达baidu的路径中的情况,利用上古神奇traceroute,我们可以得到很多信息:




    为什么用Windows的tracert?因为我的虚拟机是NAT模式,特殊原因不能用Bridge,所以我用Windows...

    得到了路径细节,我们可以逐步探测各个节点了,如下这样:
    ./ic.py 183.56.64.62 1 1000 1
    ./ic.py 14.29.121.206 1 1000 1
    ...

    由于我程序的时间精度不够,很难探知更详细的信息,但是这个问题是可以10秒内解决的...为什么不解决,是因为我觉得这已经够了。

    5.说到最后,代码呢?

    前面扯了那么多,代码呢?代码在 github
            但是这里也贴一份吧:
    #!/usr/local/bin/python
    
    import sys
    import time
    from time import sleep,ctime
    
    import signal
    import threading
    from scapy.all import *
    
    # 指定目标IP地址
    target = sys.argv[1]
    # 指定执行次数
    tot = int(sys.argv[2])
    # 指定每次发送的包量
    tot_per = int(sys.argv[3])
    # 指定是否回显
    vl = int(sys.argv[4])
    flt = "host " + target + " and icmp"
    
    handle = open("/dev/null", 'w')
    
    out_list = []
    in_list = []
    
    def output():
    	all = out_list + in_list
    	all.sort(lambda x,y:cmp(x[3],y[3]))
    	for item in all:
    		print item[0], item[1], item[2], item[3]*10
    	sys.stdout.flush()
            os._exit(0)
    
    def signal_handler(signal, frame):
    	output()
    
    class ThreadWraper(threading.Thread):
    	def __init__(self,func,args,name=''):
    		threading.Thread.__init__(self)
    		self.name=name
    		self.func=func
    		self.args=args
    
    	def run(self):
    		apply(self.func,self.args)
    		
    # 将结果输出到list
    def printrecv(pktdata):
    	if ICMP in pktdata and pktdata[ICMP]:
    		seq = str(pktdata[ICMP].seq)
    		if seq == tot_per + 2:
    			return
    		if str(pktdata[IP].dst) == target:
        			handle.write('*')
        			handle.flush()
    			out_list.append(('+', 1, seq, time.clock()))
    		else:
    			if vl == 2:
        				handle.write('.')
    			else:
        				handle.write('\b \b')
        			handle.flush()
    			in_list.append(('-', 0, seq, time.clock()))
    
    # 收到seq+2的包就停止抓包并终止程序
    def checkstop(pktdata):
    	if ICMP in pktdata and pktdata[ICMP]:
    		seq = str(pktdata[ICMP].seq)
    		if int(seq) == tot_per + 2 and str(pktdata[IP].src) == target:
        			handle.write("\nExit:" + ctime() + '\n')
    			output()
    			return True
    	return False
    
    # 发送线程
    def send_packet():
    	times = 0
    	while times < tot:
    		times += 1
        		send(IP(dst = target)/ICMP(seq = (0, tot_per))/"test", verbose = 0, loop = 1, count = 1)
        	send(IP(dst = target)/ICMP(seq = tot_per+2)/"bye", verbose = 0)
    
    # 接收线程
    def recv_packet():
    	sniff(prn = printrecv, store = 1, filter = flt, stop_filter = checkstop)
    
    def startup():
        	handle.write("Start:" + ctime() + '\n')
    
    	send_thread = ThreadWraper(send_packet,(),send_packet.__name__)
    	send_thread.setDaemon(True)  
    	send_thread.start()
    
    	recv_thread = ThreadWraper(recv_packet,(),recv_packet.__name__)
    	recv_thread.setDaemon(True)  
    	recv_thread.start()
    
    	signal.pause()
    
    if __name__ == '__main__':
    	if vl != 0:
    		handle.close()
    		handle = sys.stderr
    	signal.signal(signal.SIGINT, signal_handler)
    	startup()

    这个代码写的不好,因为我真的不怎么会编程。
            这个代码使用了令人陶醉的scapy!这个我5年前就接触过的东西直到今天才用起来。关于scapy的文档,我觉得比较好的是 这个

    本文最后,再举一个例子来聊一下TCP

    蝙蝠是个瞎子,TCP也是个瞎子。蝙蝠虽瞎但不会撞墙,依靠的是声波定位,而TCP虽瞎也能保持平滑发送,依靠的是ACK时钟流。而这个引发了另一个思路,其效果就是,我们可以采取一些措施撞死蝙蝠。
            TCP和蝙蝠不同的是,蝙蝠发出的声波无法被缓存,它永远直来直去,而TCP发出的数据包却可以被中间的网络设备缓存很久,因此,TCP测出的RTT除以2并不一定是数据包到达接收端的时间!如果你不理解我的意思,请考虑以下场景:
    0).发送端到接收端的路径,路径传输用时为10秒,因此不考虑缓存,来回为20秒;
    1).时间点A,数据包P发出;
    2).到达接收端前,经过了5秒,数据包P在路径正中间被一个设备缓存了10秒;
    3).在时间点A的15秒后数据包P继续前行,又过了5秒,到达接收端;
    4).接收端对数据包P的ACK未缓存经过了10秒返回到发送端。

    经过计算得到时间点A发送的数据包P的RTT为5+10+5+10=30秒,除以2就是15秒,请问15秒是发送端到达接收端的时间吗?显然不是!如果TCP不是瞎子,那么它肯定知道上述的过程,然而TCP是个瞎子,所以它不知道上面的具体过程。如果数据包P没有被缓存,显然只需要10秒就能到达接收端,然而现在却算出来是15秒,这多出来的5秒发生了什么?TCP不知道,因此传统上,TCP会认为发生了拥塞排队。
            但是对于拥塞排队的细节,TCP真的很容易判断清楚吗?
            TCP会把RTT的陡增视为发生了拥塞,但是:
    A.如果排队发生在数据包P到达接收端的过程中,数据包到达接收端的总时间为20秒,RTT/2=15秒,此时TCP少算了5秒;
    B.如果排队发生在ACK返回到发送端的过程中,数据包到达接收端的总时间为10秒,RTT/2=15秒,此时TCP多算了5秒。
    B-1.如果ACK发生了拥塞排队或者丢弃,后面的ACK会连带着代替该ACK去确认已经发送的数据,TCP对待数据包P和ACK是不同的!

    因此,RTT陡增(并且持续保持高值)可以比较容易定性拥塞的发生,却很难从RTT抖动情况去辨析拥塞发生的细节,就更别说去区分偶然的噪声丢包还是拥塞丢包了...
    于是回声定位技术给了我一些思路,这个思路其实也想了蛮久了。我们可以从如何发现中间网络设备的流量整形说起...

    写在最后

    虽然我是一个典型的IP粉,但我丝毫没有贬低TCP的意思,事实上我也不常接触到中间网络的设备,我之所以总是对TCP表现的不屑一顾是因为我总是发现很多所谓的“精通网络编程”的人事实上只是“精通编程”而根本不懂网络,对此的另一个极端,是我在2013到2014年的时候碰到的一些CCIE,他们真的十分精通网络,但是却丝毫不懂socket编程,也不懂协议栈的实现,而我在多年的时间内试图调和两者。说实话,我鄙视过那些玩弄网络设备而不懂编程的人,也鄙视过那些在端主机编程但是不懂网络的人,但其实我更鄙视的是我自己。

            tcpdump/Wireshark/tshark抓包工具是利器,但是绝对不是唯一的,碰到问题仅仅依赖分析数据包的人事实上很大的可能是他曾经从事过很长一段时间协议分析和逆向的工作,在这段时间形成了自己的工作方式,如果是一个从事路由器交换机工作的人,他可能就会依赖另外一种工具了。这就是网络的复杂性之体现。

            如果我碰到那些CCIE曾经看不惯他们天天的HSRP,BGP,PolicyRouting,SpanningTree,Teaming等等之来之去的,同时又对程序员天天socket,TCP,通告窗口,抓包等等之来之去的有意见,那只能说明一个问题,我是贱人,我是傻逼。
    展开全文
  • 吞吐量/TPS、 QPS 、并发数、响应时间/RT概念1. 响应时间(RT)2. 吞吐量(Throughput)3. 并发用户数4. QPS每秒查询(Query Per Second) 1. 响应时间(RT) 响应时间是指系统对请求作出...实际上,不同系统的平均响应时间随

    1. 响应时间(RT)

    响应时间是指系统对请求作出响应的时间。

    2. 流量/bps:

    是个含糊的词,它不是设备的指标术语,在这里既然是跟吞吐量做对比,我们把它理解为每秒钟流经某台设备的数据量(单位为bps)

    bps 比特率,是指单位时间内传送的比特(bit)数,单位为bps(bit per second)
    

    2.1 CPS 秒新建连接数

    每秒新建连接数-Connection Per Second (CPS)
    每秒新建连接数定义了新建连接的速率。当新建连接的速率超过规格定义的每秒新建连接数时,新建连接请求将被丢弃。

    3. 吞吐量(Throughput)

    形象的说就是即有吞进来了又有吐出去的行为,网络术语就是全双工的实际传输数据量。

    设备单位时间内能够处理(接受并转发出去)的最大数据速率(单位也为bps)
    

    如:千兆全双工意思是1000bps(上下都是1000bps),但是吞吐量肯定不是1000bps。

    1. 理解:
    吞吐量的英文单词为throughput,中英文两个词起的都很贴切,through是穿过,通过的意思,
    从一头进去,另一头出去叫做通过,吞吐顾名思义:吞进去并吐出来。当我们把概念吃够之后就容易分析了。
    
    2. 吞吐量测试: 端到端的实际数据传输速率 
    串联在网络中的设备 
    拓扑: 测试仪01——测试设备——测试仪02 
    
    3. 例子:
    	防火墙吞吐量是指在没有帧丢失的情况下,设备能够接收并转发的最大数据速率。
    

    4. 并发用户数

    并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。

    4.1 高并发连接

    高并发连接指的是连接的数量。

    对服务端来说,一个套接字对就是一个连接,连接和本地 文件描述符无关,不受本地文件描述符限制,只跟内存有关,假设一个套接字占用服务器8k内存,那么1G内存=1024*1024/8 = 131072。因此连接数跟内存有关。

    1G = 10万左右连接,当然这是理论,实际要去除内核占用,其他进程占用,和本进程其他占用。

    假哪一个机器32G内存,那个撑个100万个连接是没有问题的。

    如果是单个进程100万连,那就更牛B了,但一般都不会这么做,因为如果此进程宕了,那么,所有业务都影响了。所以一般都会分布到不同进程,不同机器,一个进程出问题了,不会影响其他进程的处理。

    5. PV : 每天的总访问量pave view,

    PV = QPS * (24*0.2) * 3600 (二八原则)

    6. QPS每秒查询率(Query Per Second)

    1. 每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准.
      在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

    2. 例子说明:
      每秒请求量。假如每秒请求量10万,假如机器为16核,那么启16个线程同时工作, 那么每个线程同时的请求量= 10万/ 16核 = 6250QPS。

      按照二八原则,一天24小时,忙时=24*0.2 = 4.8小时。

      则平均一天总请求量=4.8 * 3600 *10万QPS = 172亿8千万。

      那么每秒请求10万并发量,每天就能达到172亿的PV。

    7. 丢包率

    如果客端端发10万请求,服务端只处理了8万,那么就丢了2万。丢包率=2/10 = 20%。丢包率是越小越好,最好是没有。去除,网络丢包,那么就要考虑内核里的丢包 问题,因此要考虑网卡的吞吐量,同一时间发大多请求过来,内核会不会处理不过来, 导致丢包。

    8. 挂载

    7.1 背景:

    前面讲过,Linux 系统中“一切皆文件”,所有文件都放置在以根目录为树根的树形目录结构中。在 Linux 看来,任何硬件设备也都是文件,它们各有自己的一套文件系统(文件目录结构)。

    7.2 挂载的产生

    因此产生的问题是,当在 Linux 系统中使用这些硬件设备时,只有将Linux本身的文件目录与硬件设备的文件目录合二为一,硬件设备才能为我们所用。合二为一的过程称为“挂载”。

    7.3 挂载定义

    挂载,指的就是将设备文件中的顶级目录连接到 Linux 根目录下的某一目录(最好是空目录),访问此目录就等同于访问设备文件。

    如果不挂载,通过Linux系统中的图形界面系统可以查看找到硬件设备,但命令行方式无法找到。

    http://c.biancheng.net/view/2859.html
    参考:
    https://www.cnblogs.com/data2value/p/6220859.html

    展开全文
  • 编写一转发模块,虽然没有要求一转多时达到多少路(不采用组播的情况下,单纯的一路转成多路),但是本着物尽其用的原则,尽可能测试一下极限。网络环境:1000M,直连,多网卡系统:Linux version 3.19.0接收模式...

    编写一个转发模块,虽然没有要求一转多时要达到多少路(不采用组播的情况下,单纯的一路转成多路),但是本着物尽其用的原则,尽可能测试一下极限。

    网络环境:1000M,直连,多网卡

    系统:Linux version 3.19.0

    接收模式:udp模式的raw socket(优化的话,可以直接通过网卡处理)

    发送模式:udp模式的raw socket(优化的话,可以直接通过网卡处理),单线程/多线程

    2M               1转N

    设备A   ---------------->   转发设备  ---------------->  设备B

    但N大到一定程度时,发现发送丢包。

    注意,是转发设备发送丢包,不是设备B接收丢包。

    设备B接收丢包是可以理解的,毕竟2M码率本身的突发性相当高,1转N时,这个突发率更加扩大。

    但是发送丢包是一个什么情况,sendto的返回值都进行了判断,如果异常是会出现打印信息的,但是没有异常出现。

    上网查资料。其中最靠谱的是

    1.发送频率过高导致丢包

    很多人会不理解发送速度过快为什么会产生丢包,原因就是UDP的SendTo不会造成线程阻塞,也就是说,UDP的SentTo不会像TCP中的SendTo那样,直到数据完全发送才会return回调用函数,它不保证当执行下一条语句时数据是否被发送。(SendTo方法是异步的)这样,如果要发送的数据过多或者过大,那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释,作者这样说:“A few packets a second are not an issue; hundreds or thousands may be an issue.”(一秒钟几个数据包不算什么,但是一秒钟成百上千的数据包就不好办了)。

    发送方丢包:内部缓冲区(internal buffers)已满,并且发送速度过快(即发送两个报文之间的间隔过短);

    但是更让人郁闷的事情出现了。无论是网上资料,还是询问同事,与tcp不同,发送这一块没有缓存区啊。

    问题的,已经设置SO_SNDBUF为64M,修改系统值为128M,设置后获取到的SO_SNDBUF为128M。

    现在就是在此种情况下发送丢包,128M是什么概念啊,所以基本可以排除这一块的问题。

    通过命令watch netstat -s,可以明确的看出 Ip 项下的 outgoing packets dropped 持续增长,也就意味着确实是发送丢包。

    然后就通过outgoing packets dropped ,sendto频率过快等等关键词开始查资料,结果让人蓝瘦香菇啊

    阴差阳错的情况下,查到了 IOCTLS

    SIOCGIFTXQLEN , SIOCSIFTXQLEN

    使用 ifr_qlen 读取 或 设置 设备的 传输队列长度. 设置 传输队列长度 是 特权操作.

    于是通过

    struct ifreq ifr;

    memset(&ifr, 0, sizeof(ifr));

    strncpy(ifr.ifr_name, "eth0", sizeof(ifr.ifr_name));

    if (-1 == ioctl(sock_, SIOCGIFTXQLEN, &ifr))

    PLOG(ERROR) << "failed to get dev eth0 queue length";

    LOG(KEY) << "Dev eth0 queue length " << ifr.ifr_qlen;

    获取到eth0上的队列长度为1000,设置成10000试试

    struct ifreq ifr;

    memset(&ifr, 0, sizeof(ifr));

    strncpy(ifr.ifr_name, "eth0", sizeof(ifr.ifr_name));

    ifr.ifr_qlen = 10000;

    if (-1 == ioctl(sock_, SIOCSIFTXQLEN, &ifr))

    PLOG(ERROR) << "failed to set dev eth0 queue length";

    if (-1 == ioctl(sock_, SIOCGIFTXQLEN, &ifr))

    PLOG(ERROR) << "failed to get dev eth0 queue length";

    LOG(KEY) << "Dev eth0 queue length " << ifr.ifr_qlen;

    果然,发现好了,没有发送丢包了

    去掉SO_SNDBUF的设置,获取下SO_SNDBUF,才多少K,再测试,仍然没有发送丢包。

    结论:

    sendto过快导致发送丢包,是因为发送队列满了,如果说缓存区,估计大部分人都将误解。

    至于接收方因为突发率导致接收丢包的问题,那么就要在发送方进行发送平滑进行解决。

    udp丢包 处理

    转自: 自己在做UDP传输时遇到的问题,接收端没设置缓存,结果总是丢包. 看到这篇文章设置了一下接收缓存就好 *;//设置为32K setsockopt(s,SOL_SOCKET,SO_RCVBUF, ...

    UDP丢包原因总结

    丢包检查方法 给每个UDP包编号,对比收发端的接收到的包.对于UDP协议层上的包,例如RTP包,可以从RTP包中读出包的序列号进行判断. 抓包.发送端和接收端分别抓包.linux下可以使用tcpdum ...

    浅谈UDP&lpar;数据包长度,收包能力,丢包及进程结构选择&rpar;

    UDP数据包长度 UDP数据包的理论长度 udp数据包的理论长度是多少,合适的udp数据包应该是多少呢?从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大包长度是2^16-1的个 ...

    Linux服务器丢包故障的解决思路及引申的TCP&sol;IP协议栈理论

    我们使用Linux作为服务器操作系统时,为了达到高并发处理能力,充分利用机器性能,经常会进行一些内核参数的调整优化,但不合理的调整常常也会引起意想不到的其他问题,本文就一次Linux服务器丢包故障的处 ...

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

    转自:http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug?hmsr=toutiao.io&utm_medium=toutiao.i ...

    【VS开发】浅谈UDP&lpar;数据包长度,收包能力,丢包及进程结构选择&rpar;

    UDP数据包长度 UDP数据包的理论长度 udp数据包的理论长度是多少,合适的udp数据包应该是多少呢?从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大包长度是2^16-1的个 ...

    &lbrack;转载&rsqb;Linux服务器丢包故障的解决思路及引申的TCP&sol;IP协议栈理论

    Linux服务器丢包故障的解决思路及引申的TCP/IP协议栈理论 转载至:https://www.sdnlab.com/17530.html 我们使用Linux作为服务器操作系统时,为了达到高并发处理 ...

    java中DatagramSocket连续发送多个数据报包时产生丢包现象解决方案

    try { //向指定的ip和端口发送数据~! //先说明一下数据是谁发送过来的! byte[] ip = InetAddress.getLocalHost().getHostAddress().ge ...

    【疑】checkpoint防火墙双链路切换导致丢包问题

    拓扑: 外线联通.电信各200M,通过边界交换机(纯二层,用于分线),分别接到主.备防火墙. 具体配置如下: 故障现象: 由于电信光缆中断导致电信链路不可用.大量员工反映频繁出现断网现象,通过公网注册 ...

    随机推荐

    带你使用h5开发移动端小游戏

    带你使用h5开发移动端小游戏 在JY1.x版本中,你要做一个pc端的小游戏,会非常的简单,包括说,你要在低版本的浏览器IE8中,也不会出现明显的卡顿现象,你只需要关心游戏的逻辑就行了,比较适合逻辑较为 ...

    MySQL更新优化

    通常情况下,当访问某张表的时候,读取者首先必须获取该表的锁,如果有写入操作到达,那么写入者一直等待读取者完成操作(查询开始之后就不能中断,因此允许读取者完成操作).当读取者完成对表的操作的时候,锁就会 ...

    大家注意:升级 win8&period;1 火狐浏览器 谷歌浏览器 搜狗五笔输入法 都不能用啦

    大家注意:升级 win8.1 火狐浏览器 谷歌浏览器 搜狗五笔输入法 都不能用啦 我的电脑64位 win8 thinkpad e531,8G内存 刚在线升级完8.1,发现这些问题,大家注意,有知道问题 ...

    04---XML编程整理

    一.XML概述       XML(eXtensible Markup Language),可扩展标记语言,       被设计的宗旨是传输数据,而非显示数据       W3C发布的,目前遵循1.0 ...

    解决NSAttributedString与UILabel高度自适应计算问题

    两个类扩展方法: /** *  修改富文本的颜色 * *  @param str   要改变的string *  @param color 设置颜色 *  @param range 设置颜色的文字范围 ...

    Android 蓝牙&lpar; Bluetooth&rpar;耳机连接分析及实现

    Android 实现了对Headset 和Handsfree 两种profile 的支持.其实现核心是BluetoothHeadsetService,在PhoneApp 创建的时候会启动它. if ( ...

    CSS position 笔记&plus;实验

    目录: 1.static 2.relative 3.absolute 4.fixed 5.实验:static, relative, absolute中,父元素-子元素高度关系 6.z-index 7. ...

    导入Spreadsheet到sharepoint2013报错

    当导入Spreadsheet到sharepoint2013会报下面的错: an unexpected error has occurred -2147467259 The specified file ...

    jquery遍历集合&amp&semi;数组&amp&semi;标签

    jquery遍历集合&数组的两种方式 CreateTime--2017年4月24日08:31:49Author:Marydon 方法一: $(function(){ $("inp ...

    【C】常用的字符串函数

    1. strcpy 函数名:strcpy 用法:char *strcpy(char *destin, char *cource) 功能:将一个字符串从一个拷贝到另外一个 程序示例: #include ...

    展开全文
  • 为了延长无线传感器...最后与无线传感器网络传统的种节能路由协议基于信息协商的传感器网络协议和直接扩散协议在同等条件下针对节点能量使用、延迟、丢包率和吞吐量等四性能评价指标进行了对比。结果表明,ERARP
  • 本文分享了iptable防火墙状态异常导致丢包的排查记录,这排查过程非常曲折,最后使用了在现在的作者看来非常落伍的工具:systemtap,才得以排查成功。其实依作者现有的经验,此问题现在仅需一条命令即可找到原因,...
  • 本实例利用OPNET创建了简单的网络拓扑结构仿真模型,练习使用OPNET进行场景创建、节点配置与仿真数据统计操作。 分析难点为:问题3.2、问题4。需明确什么是以太网MTU,以太网协议及MAC帧格式,IP协议及IP数据包格式...
  • 深度好文:云网络丢包故障定位,看这一篇就够...本期分享一个比较常见的⽹络问题—丢包。例如我们去 Ping ⼀⽹站,如果能 Ping 通,且⽹站返回信息全⾯,则说明与⽹站服务器的通信是畅通的,如果 Ping 不通,或者⽹..
  • 作者简介:冯荣,腾讯云网络高级工程师,腾讯云网络核心开发人员。 万字长文 建议收藏 引言本期分享一个比较常见的⽹络问题--丢包。例如...
  • 网络端口采用了1000M速率时候出现网络通信丢包+IDC机房托管服务器之间通信不畅 网络故障: 交换机端口1000M,网卡也是1000M,网卡配置正常。ping时候间隔丢包。 表现为网络通信丢包,并且排除了其他网络设置故障。 ...
  • 找不到原文地址了,看到另一博主转的,再发一遍吧。 1.问题:为什么大IP数据包需要分片? 因为有MTU(最大传输单元)限制,一般以太网是1500B,超过这...不同设备之间传输数据前,需要先确定一 IP 数据包的大小上
  • HDFS中,存储的文件将会被分成若干的大小一致的block分布式地存储在不同的机器上,需要NameNode节点来对这些数据进行管理,存储这些block的结点称为DataNode,NameNode是用来管理这些元数据的。 NameNode保证元数据...
  • 现在市场上工业现场总线产生了...但它采用总线式拓扑结构和载波监听多路访问/冲突检测(CSMA/CD)方式,在实时性要求较高的场合下,数据的传输过程会产生延滞,具有“不确定性”.工业以太网通过增加信道带宽、采用...
  • : 吞吐量是评价网络平台性能的重要指标,是网络用户关注的焦点,对于不同帧长的以太网数据包,网络平台的处理能力存在较大差异,主要体现在处理64B和128B小包数据时,吞吐量有明显的降低。针对这一问题,以...
  • 因特网发展的三阶段3. 因特网的标准化工作4. 因特网的组成二. 三种交换方式1. 电路交换(Circuit Switching)2. 分组交换(Packet Switching)3. 报文交换(Message Switching)4. 电路交换,报文交换,分组交换三者区别...
  • “网络丢包现象是常见的网络故障,但引起丢包的原因却多种多样、千奇百怪。因此对于此类故障的解决,要求处理人员洞悉网络基础理论、了解不同厂家产品特性,有耐心、深入地进行分析定位。”---《网络丢包现象分析...
  • 浅析网络丢包原因

    2013-01-03 10:59:00
    导致网络丢包,可分为以下几方面: 一、网络本身问题; 二、网络设备故障或瓶颈; 三、物理线路故障; 四、网络攻击; 五、流量占用较大; 六、网络环路; 七、广播风暴; 一、网络本身问题 网络本身问题可以这样...
  • 计算机网络之概述篇

    2021-04-28 21:06:36
    概述篇 计算机网络在信息时代的作用 计算机网络已由一种通讯基础设施发展成为...多网络还可以通过路由器互连起来,这样就构成了一覆盖范围更大的网络,即互连网(互联网)。 因此互联网是“网络的网络(Network o
  • ::116::经过陈123同学的提醒,补充两个知识点:组成原理的微指令的设计以及操作系统的文件管理的混合索引方式。个人认为第二个更加重要。::99::之前看到有不少同学说不知道408的大题怎么下手,也因为快要到考试了,...
  • 在Flex24上将Flex24的24端口镜像到19端口(关闭原先的镜像配置,启用新的镜像配置),pc再向202.98.0.68发300ping报文,pc最终显示发送了300包,接收224报文,丢了76报文,丢包率25%。 xiong2127 51cto...
  • 想解决网络质量,首先知道影响网络质量的几因素:它包括了丢包率、延迟时间、抖动、乱序。如果网络丢包率低、延迟时间小、不抖动、不乱序,这就是非常优质的网络啦。但如果丢包率很高,那么网络质量一定会很...
  • 通过端到端时延、抖动率、丢包率和控制包开销四评价指标对比不同协议在同一场景下的表现效果.此外,针对AODV协议,分析了车辆速度、车辆密度、最大联机数和单位时间内发送封包数等环境因子对协议通信效果的影响....
  • 实验名称:两个移动节点网络连接及协议性能分析 实验日期:2015年3月9日~2015年3月14日 实验报告日期:2015年3月15日 一、实验环境(网络平台,操作系统,网络拓扑图) 运行平台:虚拟机VMwareWorkstation11.0...
  • 网络拥塞导致的公平性问题有线网络中TCP拥塞控制端到端的拥塞控制网络辅助的拥塞控制TCP拥塞控制发展演进TCP拥塞控制改进研究点有线、无线、manet有线网络对比无线网络及manet**网络拥塞判断****资源管理划分**manet...
  • 超硬核!数据结构学霸笔记,考试面试吹牛就靠它

    万次阅读 多人点赞 2021-03-26 11:11:21
    如何衡量一个算法好坏 很显然,最重要的两个指标:需要多久可以解决问题、解决问题耗费了多少资源 那我们首先说第一个问题,多长时间来解决某个问题。那我们可以在电脑上真实的测试一下嘛,多种方法比一比,用时...
  • 最近由于公司业务关系,需要一在公网上能实时互动超清视频的架构和技术方案。众所周知,视频直播用 CDN + RTMP 就可以满足绝大部分视频直播业务,我们也接触了和测试了几家 CDN 提供的方案,单人直播没有问题,...
  • 曾经有一教训是某单板只有特定长度的包极易丢包,最后的原因是长度域的值是0xFF,当这数据出现在总线上时,干扰了相邻的WE信号,导致写不进RAM。其它数据也会对WE产生干扰,但干扰在可接受的范围内,可是当8位...
  • (1)充分利用网络资源以手机为例,手机包含种上网方式,蜂窝移动数据网络(2G,3G,4G)和WIFI网络。我们希望在有WIFI的时候尽量使用WIFI,这样可以节省成本,没有WIFI的时候自动切换到蜂窝移动网络,避免断连。同样...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,240
精华内容 1,696
关键字:

要对比两个不同拓扑丢包率

友情链接: Javakcsjaljbydm.rar