程序很简单，局域网通信

C#服务端

IPEndPoint end_point = new IPEndPoint(IPAddress.Any, 6000);

TcpListener listener = new TcpListener(end_point);

listener.Start();

TcpClient client = listener.AcceptTcpClient();

NetworkStream streamToClient = client.GetStream();

byte[] buffer = new byte[1024];

streamToClient.Read(buffer, 0, 1024);

while (true)

{//收数据

int bytesRead = streamToClient.Read(buffer, 0, 1024);

if (bytesRead == 0)

break;

Console.WriteLine(BitConverter.ToSingle(buffer, 0));

}

手机上的Java客户端(单独线程)

public void run()

{

try {

client_socket = new Socket("192.168.0.100", 6000);

output = client_socket.getOutputStream();

} catch (IOException e) {}

while(true) {

try {//发数据

output.write(floatToBytes(idx += 1.0f));

try {

Thread.sleep(100);//延时100ms

} catch (InterruptedException e) {}

} catch (IOException e) {}

}

} 服务端理想的输出是

1 2 3 4 5 6 7 8 9 10 11 ......

但是输出是

2 4 6 8 10 12 ......

如果把客户端的延时改成

Thread.sleep(200); 可以得到正确输出

好像要隔200ms才能收到数据

在200ms毫秒内传输的数据都丢了

如果改成udp通信，同样的发数字，即使不延时都不会丢数据。

这是啥问题？

问题

这两天ffmpeg推流的同事反应服务器推送视频流到A直播云的直播播放某个时间段经常卡顿

排查

mtr的使用在末尾

1. 同一台服务器将视频流分别推送到B云直播、A直播云对比播放流畅度，B直播云播放流畅，判断：问题不在推流服务器
2. 将问题反馈给A直播云，A直播云答复：推送不稳定
3. 排查对比推流服务器与A直播云、B直播云的网络联通性
4. A直播云 mtr a.ar414.com

1. B直播云mtr b.ar414.com

1. 排查结论
2. 推流服务器与A直播云的链路异常，链路绕到国外才回国，丢包率与延迟率较高
3. 推流服务器与B直播云的链路正常，丢包率与延迟率总体较低

解决

将mtr排查报告反馈至A直播云让其调整路由链路

mtr

网络联通性判断工具，它可以结合 ping nslookup tracert 来判断网络的相关特性，这个命令就是 mtr。mtr 全称 my traceroute，是一个把 ping 和 traceroute 合并到一个程序的网络诊断工具 ### 安装 1. Linux

# Ubuntu
$ apt install mtr
# CentOS
$ yum install mtr

1. Windows 免安装包：https://github.com/oott123/WinMTR/releases

使用

根据实际业务进行测试 比如我这边测的是推流则需要指定包大小及tcp协议

$ mtr ar414.com

参数说明： Host：链路IP地址 Loss：丢包率 Snt：已发送数据包数 Last：最后一个包的延时 Avg：平均延时 Best：最低延时 Wrst：最差延时 StDev：稳定性

命令选项

• -r
• 使用-r：默认向目标地址发送10个ICMP包 然后直接打印报告
• 不使用-r：动态运行不断向目标地址发送ICMP包
• -s 指定发送每个数据包大小（bytes）
• -c 指定发送包数量
• -i 指定发送数据包的间隔（秒）
• --tcp 指定发送tcp包
• --udp 指定发送udp包

结果分析

1. 链路分析：
2. 自建机房
3. 一般情况下前几跳都是局域网内路由，如果异常则自行排查或上报机房运维
4. 中间跳数则是中间节点，如果异常则联系运营商
5. 后几跳则是服务提供商，如果异常联系服务提供商
6. 云服务器
7. 前中的链路异常则联系云服务器商，一般提交工单
8. 后几跳异常则联系服务提供商
9. 丢包率
10. 还有很多时候问题是在数据包返回途中发生的，数据包可以成功的到达目的主机，但是返回过程中遇到 “困难” 了。所以，当问题发生后，我们通常需要收集反方向的 MTR 报告 结合正反向MRT排查报告进行判断
11. 网络延迟
12. 因为是不同的位置，延迟通常会随着条数的增加而增加。所以，延迟通常取决于节点之间的物理距离和线路质量。
13. 高延迟并不一定意味着当前路由器有问题。延迟很大的原因也有可能是在返回过程中引发的。从这份报告的截图看不到返回的路径，返回的路径可能是完全不同的线路，所以一般需要进行双向 MTR 测试

一、网络自身问题 您想要连接的目标网站所在的服务器带宽不足或负载过大。一台服务器，如果带宽超过峰值的时间，外来客户再PING这个服务器IP的时间，掉包是很正常的。也就是说你的服务器需要加带宽了。 二、访问者PC问题 这个问题有多种触发性，防火墙的安装或设置，客户电话线路等等，在这里不多加阐述，我博客里已经注明。 三、网络中存在回路导致网速变慢 当网络涉及的节点数不是很多、结构不是很复杂时，这种现象一般很少发生。但在一些比较复杂的网络中，经常有多余的备用线路，如无意间连上时会构成回路。比如网线从网络中心接到计算机一室，再从计算机一室接到计算机二室。同时从网络中心又有一条备用线路直接连到计算机二室，若这几条线同时接通，则构成回路，数据包会不断发送和校验数据，从而影响整体网速。这种情况查找比较困难。为避免这种情况发生，要求我们在铺设网线时一定养成良好的习惯：网线打上明显的标签，有备用线路的地方要做好记载。当怀疑有此类故障发生时，一般采用分区分段逐步排除的方法。 这个是摘抄的，没有实践经过。亮出来供大家参考。 四、网络设备硬件故障引起的广播风暴而导致网速变慢 作为发现未知设备的主要手段，广播在网络中起着非常重要的作用。然而，随着网络中计算机数量的增多，广播包的数量会急剧增加。当广播包的数量达到30%时，网络的传输效率将会明显下降。当网卡或网络设备损坏后，会不停地发送广播包，从而导致广播风暴，使网络通信陷于瘫痪。因此，当网络设备硬件有故障时也会引起网速变慢。当怀疑有此类故障时，首先可采用置换法替换集线器或交换机来排除集线设备故障。如果这些设备没有故障，关掉集线器或交换机的电源后， DOS下用“Ping”命令对所涉及计算机逐一测试，找到有故障网卡的计算机，更换新的网卡即可恢复网速正常。网卡、集线器以及交换机是最容易出现故障引起网速变慢的设备。 五、网络中某个端口形成了瓶颈导致网速变慢 实际上，路由器广域网端口和局域网端口、交换机端口、集线器端口和服务器网卡等都可能成为网络瓶颈。当网速变慢时，我们可在网络使用高峰时段，利用网管软件查看路由器、交换机、服务器端口的数据流量；也可用Netstat命令统计各个端口的数据流量。据此确认网络数据流通瓶颈的位置，设法增加其带宽。具体方法很多，如更换服务器网卡为100M或1000M、安装多个网卡、划分多个VLAN、改变路由器配置来增加带宽等，都可以有效地缓解网络瓶颈，可以最大限度地提高数据传输速度。 六、蠕虫病毒的影响导致网速变慢通过E-mail散发的蠕虫病毒对网络速度的影响越来越严重，危害性极大。这种病毒导致被感染的用户只要一上网就不停地往外发邮件，病毒选择用户个人电脑中的随机文档附加在用户机子的通讯簿的随机地址上进行邮件发送。成百上千的这种垃圾邮件有的排着队往外发送，有的又成批成批地被退回来堆在服务器上。造成个别骨干互联网出现明显拥塞，网速明显变慢，使局域网近于瘫痪。因此，我们必须及时升级所用杀毒软件；计算机也要及时升级、安装系统补丁程序，同时卸载不必要的服务、关闭不必要的端口，以提高系统的安全性和可靠性。 七、防火墙的过多使用 防火墙的过多使用也可导致网速变慢，处理办法不必多说，卸载下不必要的防火墙只保留一个功能强大的足以。 八、经过路邮的数量和质量对网速有一定的影响。 我们的机柜都是千兆接入, 防火墙有全局防护策略的, 一般攻击不会透过来,

取消

评论