企业官网建设流程全解析

学做效果图网站有哪些软件,网站建设岗位的任职资格,网页设计培训有前途吗,wordpress的站点地址如何配置网络问题如何排查#xff1f;mtr命令详解mtrmtr命令是一个网络诊断工具#xff0c;用于检测网络的连通性和延迟。MTR是My Traceroute的缩写#xff0c;是traceroute和ping命令的结合体。mtr默认使用ICMP协议#xff0c;在介绍mtr的详细用法前我们先了解下ICMP协议。IMCPICM…网络问题如何排查mtr命令详解mtrmtr命令是一个网络诊断工具用于检测网络的连通性和延迟。MTR是My Traceroute的缩写是traceroute和ping命令的结合体。mtr默认使用ICMP协议在介绍mtr的详细用法前我们先了解下ICMP协议。IMCPICMPInternet Control Message Protocol互联网控制报文协议是一种网络层OSI 第三层协议主要用于在 IP 网络中传递控制信息和错误信息而不是用来传输业务数据。ICMP的作用是1、网络连通性测试最常用的就是ping命令发送的是ICMP Echo Request对方回复ICMP Echo Reply用来判断网络是否可达、是否丢包以及延迟2、网络故障和错误反馈当 IP 包在传输过程中出现问题时ICMP 会返回错误信息例如场景 ICMP 类型目标主机不可达 Destination Unreachable路由中 TTL 用尽 Time Exceeded需要分片但禁止分片 Fragmentation Needed例如路由器发现下一跳不可达时就会被源主机发送一个ICMP不可达报文3、网络路径诊断traceroute和tracert就是通过ICMP实现的mtr的用法Usage:mtr [options] hostname-F, --filename FILE 从文件中读取hostname(s)-4 使用IPv4-6 使用IPv6-f, --first-ttl NUMBER 起跳ttl参数跳过前面的N-1跳只只显示TTLN后的跳不改变真实路由只是不显示-m, --max-ttl NUMBER maximum number of hops-u, --udp 使用UDP 替代 ICMP echo-T, --tcp 使用 TCP 替代ICMP echo-P, --port PORT 使用TCP、SCTP或UDP探测时的目标端口-s, --psize PACKETSIZE 设置探测包的 payload 大小字节-i, --interval SECONDS 设置探测包的 发送间隔-r, --report 报告模式一次性输出不刷新-w, --report-wide 报告模式宽屏对齐输出字段不截断-c, --report-cycles COUNT 发送探测包次数设置20快速判断设置100较为可信-j, --json 以json格式输出-x, --xml 以xml格式输出-C, --csv 以csv格式输出-l, --raw 以原始格式输出-n, --no-dns 不做反向dns解析(只显示ip)-y, --ipinfo NUMBER 输出 IP 归属信息国家 / 运营商在linux上执行mtr时mtr会直接操作网络层构造IP/ICMP报文所以一般需要使用sudo执行示例sudo mtr -r -n -c 100 www.baidu.com输出结果:Start: 2026-01-15T19:00:010800HOST: LTB-MBP.local Loss% Snt Last Avg Best Wrst StDev1.|-- 183.2.172.177 0.0% 100 2.0 1.8 0.4 26.2 3.4字段 含义 解读要点HOST 当前跳主机 * 代表无响应Loss% 丢包率 核心指标Snt 发送包数 统计样本量Last 最近一次延迟 波动参考Avg 平均延迟 主要看Best 最小延迟 理想情况Wrst 最大延迟 是否有抖动StDev 抖动 越小越稳定ICMP限速分析MTR输出时需要关注两个方面丢包率和延迟。如果在某个跳点看到一定程度的丢包这可能说明该路由器有问题。然而一些服务提供商普遍会限制MTR使用的ICMP响应速率。这可能会让人误以为丢包实际上并没有丢包。要判断看到的丢包是真实的还是速率限制引起的可以看看后续跳跃。如果跳跃显示损失为0.0%那么很可能是因为ICMP响应速率限制导致的而非真实的丢包以下面的MTR结果为例:rootlocalhost:~# mtr -r www.google.comHOST: example Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.15. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.96. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.27. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.38. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2第二跳的丢包率虽然是 50%但是其后续跳没有丢包且最终能到到达第8跳所以整个链路实际上通的第二跳的丢包率是因为ICMP限速导致的。可能有的同学会有疑问了难道最后一跳不会出现ICMP限速吗实际上mtr发送数据包后会根据收到的 ICMP 响应类型来判断中间跳返回ICMP Type 11 (Time Exceeded)→ TTL 耗尽我不是目标→ 继续增加 TTL 探测下一跳最后一跳返回ICMP Type 0 (Echo Reply)或 ICMP Type 3 (Destination Unreachable)→ 我就是目标主机→ 停止探测过程可以类比快递配送链路中间转运站路由器可能不会告诉你包裹经过了这里限制或完全不响应ICMP Time Exceeded最终收货点目标主机必须签收并确认收到了响应ICMP Echo Reply即使中间转运站不告诉你进度只要最后收到包裹并有签收确认就说明整条链路是通的。真实的丢包场景以下面的MTR结果为例rootlocalhost:~# mtr -r www.google.comHOST: localhost Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.15. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.96. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.27. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.38. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2在这个示例中第三跳的丢包率高达60%且后续跳均出现了丢包率并且影响了最后的第8跳所以可以判断第三跳是有问题的。由于中间跳ICMP限速和真实丢包会同时发生所以会出现中间跳的丢包率高于最后一跳丢包率。当判断确实出现了丢包时最好使用MTR双向测试下因为数据包可能是发送时遇到了问题也可能是在返回响应时出现了问题。延迟MTR还能测试主机与目标主机之间连接的延迟。由于物理约束延迟总是随着路由跳数的增加而增加。然而增长应保持一致且线性。延迟通常是相对的并且很大程度上取决于主机连接的质量及其物理距离。 在评估可能有问题的连接的 MTR 报告时除了给定区域中其他主机之间的已知连接速度之外还应将早期的功能齐全的报告视为上下文。以下面的MTR结果为例rootlocalhost:~# mtr --report www.google.comHOST: localhost Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com 0.0% 10 388.0 360.4 342.1 396.7 0.25. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.26. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.47. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.18. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2在第3跳和第4跳之间延迟突然增高并且在后续跳中仍然很高这可能表明存在网络延迟问题。但是高延迟并不总是意味着当前路由有问题。 像上面这样的报告意味着尽管第四跳存在某种问题流量仍然到达目标主机并返回源主机。 延迟也可能是由返回路线问题引起的。 返回路线不会在 MTR 报告中看到并且数据包可以采用完全不同的路线往返于特定目的地。在上面的示例中虽然在第3跳和第4跳之间的延迟存在较大跳跃但在任何后续跳中延迟并没有再增高。 由此可以合理地假设第四个路由器存在问题。ICMP限速也会导致延迟增加以下面的MTR报告为例rootlocalhost:~# mtr --report www.google.comHOST: localhost Loss% Snt Last Avg Best Wrst StDev1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.32. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.83. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.74. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.15. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.96. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.27. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.38. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2乍一看第4跳和第5跳之间的延迟突然增高了。然而在第五跳之后延迟急剧下降。这里测得的实际延迟约为40ms且并没有影响最后一条的延迟网络实际上是没有问题的。什么时候需要使用TCP和UDP协议进行检测三种协议的对比协议 默认使用场景 优点 缺点ICMP 默认模式 最常用,大多数设备支持 容易被防火墙过滤UDP 测试 UDP 服务 模拟真实 UDP 流量 可能被过滤,不可靠TCP 测试 Web/API 服务 最接近真实应用流量,不易被过滤 需要指定端口什么时候使用TCP模式场景 1ICMP被防火墙屏蔽或ICMP限速# ICMP 模式失败mtr api.example.com→ 大量 waiting for reply 或 100% 丢包# 改用 TCP 模式测试 443 端口mtr -T -P 443 api.example.com→ 正常显示路由路径场景 2测试特定服务的网络质量# 测试 HTTPS 服务443 端口mtr -T -P 443 api.example.com# 测试 HTTP 服务80 端口mtr -T -P 80 www.example.com# 测试 SSH 服务22 端口mtr -T -P 22 server.example.com# 测试数据库3306 端口mtr -T -P 3306 db.example.commtr使用TCP协议进行网络检测的过程是通过 TCP三次握手的前两步完成的Client → SYN (dst port 443, TTLN)Server → SYN-ACKClient → RST 立刻mtr的TCP模式只完成“三次握手的前两步”并在收到响应后立刻主动 RST不会建立真正的TCP连接更不会形成大量的ESTABLISHED 连接对目标主机性能几乎没有影响。什么时候使用UDP模式场景 1测试 UDP 应用# 测试 DNS 服务53 端口mtr -u -P 53 8.8.8.8# 测试 VoIP/视频会议如 10000-20000 端口范围mtr -u -P 16384 meeting.example.com# 测试游戏服务器mtr -u -P 27015 game.example.com# 测试 VPN如 OpenVPN1194 端口