The problem

Ar414 in these two days FFMPEG push stream colleagues reported that the server push video stream to A live broadcast cloud play often lag in A certain period of time

screening

The use of MTR is at the end

  1. The same server pushes the video stream separately toB cloud live,A live broadcast of the cloudCompare the playback smoothness,B live cloudSmooth playback, judgment: the problem is not pushing the stream server
  2. Feedback questions toA live broadcast of the cloud, A live cloud reply: push is not stable
  3. Comparison of the FebruaryPusher serverwithA live broadcast of the cloud,B live cloudNetwork connectivity
  • A live broadcast of the cloudmtr a.ar414.com

  • B live cloudmtr b.ar414.com

  1. The conclusion of the February
  • Pusher serverwithA live broadcast of the cloudThe link is abnormal. The link goes around the foreign country and then returns to China. The packet loss rate and delay rate are high
  • Pusher serverwithB live cloudThe link is normal, and the packet loss rate and delay rate are low

To solve

Feedback the MTR investigation report to A live cloud to adjust the routing link

mtr

Network connectivity judgment tool, which can be combined with ping nslookup tracert to determine the network features, this command is MTR. MTR, which stands for My Traceroute, is a network diagnostic tool that combines ping and Traceroute into one program

The installation

  1. Linux
# Ubuntu
$ apt install mtr
# CentOS
$ yum install mtr
Copy the code
  1. Windows

Free installation package: github.com/oott123/Win…

use

Test according to the actual business, for example, I test the push stream, and need to specify the packet size and TCP protocol

$ mtr ar414.com
Copy the code

Parameter Description:

  • Host: indicates the IP address of a link
  • Loss: indicates the packet Loss rate
  • Snt: indicates the number of sent packets
  • Last: Delay of the Last packet
  • Avg: average delay
  • Best: minimum delay
  • Wrst: indicates the worst delay
  • StDev: stability

Command options

  • -r
    • Use -r: sends 10 ICMP packets to the destination address by default and prints the report directly
    • If -r is not used, ICMP packets are continuously sent to the destination address dynamically
  • -s Specifies the size of each packet to be sent.
  • -c Specifies the number of packets to be sent
  • -i Specifies the interval (in seconds) for sending packets.
  • — TCP Indicates sending TCP packets
  • –udp Indicates sending UDP packets

Results analysis

  1. Link analysis:
  • Self-built housing
  1. Generally, the first few hops are intra-LAN routes. If any exception occurs, check the route or report it to o&M in the equipment room
  2. The intermediate hop number is the intermediate node, if abnormal contactOperator,
  3. The last few hops are the service provider. If any exception occurs, contact the service provider
  • Cloud server
  1. If the preceding link is abnormal, contact the cloud server provider and submit the work order
  2. If the last few hops are abnormal, contact the service provider
  3. Packet loss rate
  • There are also many times when the problem occurs on the way back to the packet, the packet can successfully reach the destination host, but the return process encountered “difficulty”. Therefore, when problems occur, we usually need to collect the MTR report in the opposite direction combined with the positive and negative MRT investigation report for judgment
  1. Network latency
  • Because they are different locations, the latency usually increases as the number of entries increases. Therefore, the delay usually depends on the physical distance between nodes and the line quality.
  • High latency does not necessarily mean there is a problem with the current router. The reason for the large delay can also be caused during the return process. You can’t see the return path from the screenshot of this report. The return path may be a completely different line, so two-way MTR test is generally required