新版网络堵塞分析1.docx
- 文档编号:6039336
- 上传时间:2023-05-09
- 格式:DOCX
- 页数:12
- 大小:19.53KB
新版网络堵塞分析1.docx
《新版网络堵塞分析1.docx》由会员分享,可在线阅读,更多相关《新版网络堵塞分析1.docx(12页珍藏版)》请在冰点文库上搜索。
新版网络堵塞分析1
视频卡顿分析流程
视频卡顿分析流程......................................................................................................................................................1
第一步骤:
明确IPC对外数据流的走向。
...............................................................................................................2
第二步骤:
理清楚排查问题思路..............................................................................................................................4
第三步骤:
抓包数据分析..........................................................................................................................................5
附件:
工具使用分析................................................................................................................................................13
第一步骤:
明确IPC对外数据流的走向。
这个部分是基础首先要明确IPC都有哪些对外的数据流向,出现卡顿到底是出
在哪条数据流上。
第3方CGI接入
CGI协议
IPC
平台软件
3代网络协议
3代
3代网络协议
HTTP协议
网络IPC_WEB
WebServer
RPCServerRPClient
框架
WebApp
2代F6命令实现把
2代协议转3代协议
SDK交互
DSS,PSS平台
数据源
2代
SDK交互
网络NVR
2代网络协议
框架
1)音视频数据源
2)配置文件数据
SDK交互
手机客户端
1)封装数据源
SDK交互
2)对外提供获取数
系统信息
据的接口
手机客户端添
加域名
DDNS服务器
DDNS
1,内存信息
IPC_WEB
2,CPU信息
DDNS域名访问
3,操作系统版本
第3方平台软件
比如:
中星
P2P模块第3方接入模块
微,东方网
SNMP
力,鸿信平台
ONVIF第3方厂家
的存储设备,海
康NVR通过ONVIF
P2P服务器
对接大华IPC
SNMP监控客户
端软件
国标
手机客户端P2PWEB客户端
这个图像是IPC对外数据流的框架图,如果看的不够明白。
下面有个简单框架图。
首先要搞清楚连接IPC都有哪些设备和平台,要明确卡顿是在哪条视频数据流上卡
顿的。
连接IPC的是公司NVR还是第3方的存储设备;连接的平台是公司平台还是
第三方平台。
如果是第3方平台,具体平台名称是什么。
比如:
国标平台,鸿信平
台,上海贝尔,电信平台,中兴力维。
不同连接方式取视频流的方式也是不一样的,
对应端口和发送视频流的协议都不同的。
梳理清楚便于快速找到对应接口人处理问
题。
1)
WEB端浏览视频图像走的是80端口,视频流采用的流媒体协议。
2)
IPC跟第3方NVR对接,基本都是走的ONVIF协议。
视频流采取也是
通过流媒体协议。
3)
IPC跟公司NVR或者EVS对接,则走的是大华私有协议(SDK)。
4)
IPC跟第3方平台对接,则走的是IPC中一个独立的功能模块(接入功
能模块)接入这块功能有专门的开发小组进行维护。
5)
IPC跟公司自己的DSS,SMARTPSS平台对接,则走的也是大华私有协议
(SDK)。
明确了上述流后,确认是哪条环节上视频流出现卡顿。
把对应这条数据流上的
网络拓扑信息图搞清楚。
按照提供的网络拓扑图信息进行分级进行定位。
排查到底
是那级节点出现卡顿。
调试卡顿现象时候一定要把网络拓扑搞清楚。
搞清楚网络拓
扑信息这个步骤,不要进行推诿,也不要找借口,区域要自己想尽一切办法把网络
拓扑信息搞清楚。
不然后续定位卡顿问题,研发拒绝协助和出差排查问题。
第二步骤:
理清楚排查问题思路
1)
IPC设备跟电脑直连都卡顿(排除网线和电脑问题)用VLC和WEB,SDK
测试DEMO都验证过卡顿。
那后续就不用排查其它问题,直接联系研发
进行问题处理。
2)
直连测试正常。
则按照上面讲述的数据流向,把数据流梳理清楚,把网
络拓扑图搞清楚。
按照网络拓扑图逐级进行排查,看到底是那级网络点
出现卡顿。
3)
尝试降低编码参数,比如降低码流。
如果降低码流就不卡顿,初步可以
判定是整个网络带宽不足导致预览视频卡顿。
4)
尝试如果修改WEB端预览视频模式(实时和流畅)调整到流畅模式就不
卡顿,也可以初步判断是网络问题导致。
5)
如果通过降低码流,调整预览视频流畅模式还是卡顿。
则这个时候查看
设备端资源占用情况。
如果设备端CPU占用率特别高,那就可能是设备
端性能不足导致发送视频流有问题,从而引起卡顿。
设备端CPU过高有
可能是开启功能过多,也有可能是编码性能不足。
如果把设备配臵恢复
默认还是设备端占用CPU过高,那就联系研发进行问题排查。
另外一种
情况就有可能是有过多的IP登陆IPC,导致前端IPC资源紧张,从而引
起视频卡顿。
还有一种情况就是设臵编码的FPS为25帧/秒,但实际上
上来的码流只有20帧/秒.这样也会导致视频流卡顿。
6)
如果前端IPC一切正常(CPU资源很空闲,直连也不卡顿),平台端和
NVR端还是卡顿。
这个时候就要着手定位网络问题。
7)
分析编码数据的I帧大小。
使用StreamEye码流分析工具分析录像文件红
色柱状表示I帧数据,对应旁边的数字就表示是对应的I帧数据大小。
一
般在200K以下。
如果是因为I帧过大,一般都可以通过降低码流,或者
调整WEB端预览模式来进行验证。
第三步骤:
抓包数据分析
1)
抓包分析有大量网络重传数据包
2)
UDP方式取视频流卡顿,经过抓包分析有大量的丢包数据。
统计丢包数
据效率的方法如下:
案例总结:
1)
兰州监狱NVR播放录像卡顿
定位为解码库问题,NVR端处理。
2)
杭州--地铁4号线视频卡顿
定位原因:
385光口设备的网络驱动导致网卡适应成10M网卡了。
3)
江苏--南京地铁3号线
问题描述:
HF3200图像卡顿
原因分析:
网络中存在大量的ARP包,导致设备对这些包一直在握手,
导致CPU占用率为100%
解决方案:
没有定位到根本原因,出规避程序去掉IP搜索功能。
4)
新疆米东区平安市区我司IPC在宇视NVR卡顿问题
解决:
宇视NVR上的数据是通过接入协议取视频流,接入组进行解决。
5)
国内-甘肃,我司NVS0104EF接入NVR6000和SVR3016丢帧问题
解决:
修改发送数据缓冲大小。
6)
杭州地铁二号线IPC-HF3301P-F、HDB3301视频卡顿需求
原因:
杭州地铁二号线设备程序缺陷,在现场发现8M视频预览卡顿现
象,经检查发现是接入库问题,由研发谢双提供新的接入库,但程序需
要在地铁二号线的订制需求基础上开发。
7)
虎门公安视频监控项目
现象:
虎门公安视频监控项目用到我司DH-IPC-HF5200和
DH-SD6A82C-HN这两款前端,目前发现通过UDP传输会出现卡顿现象,
TCP传输正常,接入组对UDP进行优化。
8)
洪湖平安城市IPC5200
现象:
只要接入模块启动,WEB端预览图像就会卡顿。
原因:
经过定位是接入模块占用CPU过高,导致数据发送不均匀,从而
引起卡顿。
根本原因是接入回调函数中处理事情过多,导致编码线程数
据发送卡顿。
9)
西科姆IPC项目视频播放卡顿
原因:
确认是网络环境导致,现场网络带宽验证不足导致,客户让网络
集成商
改善网络后解决问题。
10)
杭州电警永翔IPC-HF3300P-P
问题现象:
杭州电警永翔全景相机,接入北京的一家公司的智能分析服
务器,视频出现拖影卡顿。
问题原因:
是第3方解码问题导致。
11)
上海松江--HF3231卡顿问题
问题描述:
上海反馈HF3231现场卡顿问题问题原因:
网络卡顿------优化
内核,开启流控;I帧过大------优化I帧大小
12)
IPC-HX3
(2)XXX华鼎漳州海西高速项目组播拉视频流
问题现象:
第3方平台组播取视频流出现花屏。
问题原因:
区域提需求错误,客户需要的组播裸码流,而区域提需求要
的是TS流,导致客户端解码数据有问题。
13)
关于福亿安防公司定制需求【重要】-网络卡顿问题--区域问题
问题描述:
IPC设备通过客户自己定制的交换机,图像会条秒卡顿现象
定位原因:
交换机问题。
高世达技术给出的解释是:
现场使用的交换机
网口是百兆的,但是现场使用中把网口限制到12M。
带宽不够导致浏览
视频卡顿。
14)
东莞樟木头摄像机卡顿问题
定位原因:
网络带宽问题,网络供应商解决问题。
15)
总结卡顿的原因:
I帧过大;网卡驱动异常;网络环境中网络带宽不足;
设备编码性能不足;解码库不兼容;设备端功能打开过多导致设备CPU
过高影响数据发送;数据发送缓冲设臵过小;网络环境差的条件下没有
对数据做均匀发送处理;交换机问题;网络带宽不足。
附件:
工具使用分析
1)抓包工具的使用设备端抓包工具tcpdump使用。
步骤1)在C盘新建一个share目录,共享权限全开
步骤2)设臵PC机的账号和密码
在控制面板里,用户账户那里,重设密码密码为123456
步骤3)将附件抓包(1.368的arm-v5t-linux,2.安霸的arm-461none-linux)文件
里的client,复制到share文件夹下
telnet至设备执行挂载命令:
mount-tcifs-ousername=Administrator,password=123456//10.34.9.64/share
/home
将10.34.9.64这个IP改成你当前电脑的IP
挂载成功之后,运行client
cd/home
./client&
之后运行抓包文件夹里的tcpdump抓包.exe.将IP改成设备的IP,同时平台选
择相应的比如368.选择arm-v5t-linux,安霸选择arm-461none-linux.点击开始,就
开始抓包,再当前目录下会有一个data.pcap的抓包文件出现
网络带宽分析测试网络带宽工具。
1.在pc上解压rar文件,然后cmd进入该目录,运行jperf.bat,会出来一个程
序界面,选择server,并在右边按钮启动服务
2.iperf_arm_v5t_le需要挂载到ipc上运行(挂载方法可以参考命令12)。
./iperf_arm_v5t_le-c10.34.10.29-i1
命令:
其中10.34.10.29为pc的ip
ipc会出现如下打印:
#./iperf_arm_v5t_le-c10.34.10.29-i1
------------------------------------------------------------
Clientconnectingto10.34.10.29,TCPport5001
TCPwindowsize:
16.0KByte(default)
------------------------------------------------------------
[3]local172.30.1.131port4938connectedwith10.34.10.29port5001
[ID]IntervalTransferBandwidth
[3]0.0-1.0sec3.50MBytes29.4Mbits/sec
[3]1.0-2.0sec3.25MBytes27.3Mbits/sec
[3]2.0-3.0sec3.62MBytes30.4Mbits/sec
[3]3.0-4.0sec3.25MBytes27.3Mbits/sec
[3]4.0-5.0sec2.88MBytes24.1Mbits/sec
[3]5.0-6.0sec2.25MBytes18.9Mbits/sec
[3]6.0-7.0sec3.50MBytes29.4Mbits/sec
[3]7.0-8.0sec3.38MBytes28.3Mbits/sec
[3]8.0-9.0sec3.38MBytes28.3Mbits/sec
[3]9.0-10.0sec3.25MBytes27.3Mbits/sec
[3]0.0-10.1sec32.8MBytes27.1Mbits/sec
测试时候,要注意把服务器端程序(jperf.bat)放到平台中心端的PC电脑上,
进行测试。
另外运行这个程序需要安装JAVAJDK.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 新版 网络 堵塞 分析