视频流批量点播问题排查

relax_peng
393 阅读5分钟

一.背景

我最近在做一个视频的批量点播的一个性能压测,测试人员反馈,在批量点播视频的时候,发现一直无法点播成功,当时自己还有其他需求要做,就先让测试去排查下,结果过了两天,问题还是说没找到,只能我来去排查,将将自己排查的思路整理如下

二.问题简要描述

有个服务端部署一个视频接入平台, 平台叫做WVP是java写的, 客户端是自己用netty模拟的客户端, wvp和netty-client是使用udp做一些信令的通信,通信后, wvp启动zlm流媒体服务, netty-client也会开启一个本地的c++编写的流媒体服务, 后面客户端流媒体会通过tcp/udp来连接服务端的zlm流媒体服务,进行视频流的推送,流程如下

image.png

并且在页面上进行点播点播的时候,是好的,用脚本批量点播时候,就会失败

在得知情况后,我开始进行排查

三.排查思路

服务端使用tcpdump 进行抓包分析,命令是:

tcpdump -ni any -w play.pcap,是抓取服务所有的网卡数据,并保存到本地文件 play.pcap文件中

把这个文件下载下来,用wireshar分析后如图

image.png 从wireshark分析可以看到,客户端在用 5000端口连接服务器的20042端口时候,服务器返回RST,从而连接失败. 在TCP三次握手过程中，如果客户端发送了一个SYN数据包以发起连接，但服务器响应了一个RST（复位）数据包而不是预期的SYN-ACK，这通常意味着以下几种情况之一：

  1. 端口未监听： 服务器上没有进程在指定的端口上监听。这意味着没有服务或应用程序正在等待来自客户端的连接请求。

  2. 防火墙或网络设备拦截： 中间的防火墙、路由器或网络安全设备可能阻止了连接请求，或者基于某些规则决定拒绝连接，并发送RST响应。

  3. 服务未启动或崩溃： 即使端口配置为可监听，但预期运行在该端口上的服务可能未启动，或者在尝试接收连接时发生了故障。

  4. 资源限制： 服务器可能已达到其最大并发连接数或资源使用限制，因此拒绝新的连接尝试。

  5. 连接速率过高： 如果客户端发送SYN请求的速度过快，服务器可能认为这是SYN洪水攻击的一部分，从而自动发送RST响应来拒绝连接。

  6. SYN数据包格式错误： 客户端发送的SYN数据包可能包含无效或不合规的字段，导致服务器将其视为非法请求并发送RST。

  7. 序列号问题： 如果客户端发送的SYN数据包中的序列号与服务器期望的序列号不匹配，服务器可能发送RST以拒绝连接。

  8. 安全策略： 服务器的安全策略可能配置为只接受来自特定IP地址或范围的连接，如果客户端不在允许的范围内，服务器会发送RST。

  9. 临时问题： 服务器可能暂时不可用，可能是因为维护、更新或是其他暂时的网络问题。

其实最主要也就三个原因,分别是流媒体服务未开启,防火墙拦截,端口未监听 我分别去服务器查看流媒体的进程,iptabables的规则,发现都没有问题,想着基本就是端口问题了, 使用netstat截图如下

image.png

通过对比发现,页面上手动点击播放时候,同一个端口会监听TCP和UDP,但是批量播放时候,只会监听UDP协议,TCP协议的端口没有监听,从而导致当使用tcp协议传输的时候,客户端是无法连接服务端的,从而导致无法传输流;

四.通过代码验证

4.1 服务端的zlm流媒体开通端口的那种协议是程序调用的

从netstat查看端口监听的协议有问题,那肯定就是程序调用时候的参数的问题,经过排查后原因如下:

image.png

4.2 参数调用反查

tcp_mode这个参数是用设备表中的流传输协议字段获取的,在页面上可以选择UDP/TCP被动/TCP主动;

设备第一次注册时候,默认写入数据库的协议是UDP,而我们这次测试的协议是TCP被动, 页面上有1000台模拟的设备,所以开发人员为了省事,就批量修改数据库中这个字段,但是程序在执行时候,会现充redis缓存中获取设备信息,缓存中并没有修改协议,还是老的数据UDP,从而导致点播时候参数有问题

五,总结

其实这个问题整体分析下来并不难,自己也就花了不到一个小时就找到原因并且处理好了,最主要的是处理问题的思路,尤其像这种触发之后,对方没有任务反应,而且日志也没有记录的情况下,分析的思路

1.服务器抓包并分析

2.使用netstat查看端口是否开启

3.反推代码中的问题,查找愿原因,进行验证

avatar
文章
阅读
粉丝