我有一个视频流应用程序,在我的办公室运行良好,但在客户那里却失败了。症状是每隔几秒钟,我就会停止接收 UDP 数据包 2 秒钟,然后流会恢复,好像什么都没有发生一样。
我跑了http://www.pingtest.net/在客户位置,结果非常好。没有丢包,延迟低。我注意到我们两个位置之间的唯一区别是,ping google.ca
在他们的位置超时,但在我的位置可以正常工作。
如何测试我所在的网络是否阻止传入的 UDP 数据包?有没有什么办法可以帮助我找出丢失数据包的人?
答案1
您可以尝试与 建立 UDP 连接netcat
。
在机器上A在消费者网络之外运行:
nc -u -l -p 1234 # if using netcat-traditional
nc -u -l 1234 # if using netcat-openbsd (as pointed out by @JamesHaigh)
请注意-u
,指示 netcat 使用 UDP。(还请注意,有不同版本的netcat
,需要-p
或不需要参数;给出了两个最常见版本的变体,均包含在 Debian 中。)
在消费者位置上:nc -u [addr of machine A] 1234
。
尝试发送一些文本,或者更好的是使用管道在两个位置之间发送文件,然后进行差异比较。
答案2
在服务器端,建立一个UPD服务器
iperf -s -u
在客户端,检查 UDP 连接
iperf -u -c <IP Address of Server>
答案3
在服务器端使用
iperf -u -p <port> -s
在客户端使用
iperf -u -p <port> -c <domain or ip>
确保防火墙允许端口。测试后,这将向您提供如下报告
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 1] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 3.722 ms 1/ 893 (0.11%)
答案4
netcat
mpy 答案中的命令对于诊断目的很有用,但我用另一种方法补充该答案来解决您的潜在问题。
让你的应用程序回到连续传输协议,甚至是 TCP。我之所以发现这个问题,其实是因为我正在寻找如何在下行链路拥塞时拒绝使用超过其份额的用户的传入 UDP 数据包,因为与 SCTP 和 TCP 不同,UDP 没有拥塞控制,因此很难对下行链路流量进行优先级排序。
SCTP 和 TCP 都具有拥塞控制功能,并且与 QoS 配合良好,但 SCTP 比 TCP 具有额外的优势,即它是为实时流媒体应用而设计的,因此可以很好地替代 TCP和UDP。实际上,SCTP 是两种最常见的传输协议中最好的。
与其只依赖 UDP,不如设置一个后备方案。即使你只使用 TCP,至少可以说它能正常工作,只是可能不是最佳状态。