简介AZ-104是微软Azure管理员认证考试此PDF文档为围绕该考试整理的题库资料主要面向备战MCP认证、计划通过AZ-104的IT从业者。内容聚焦Azure资源管理和Azure AD条件访问等核心考点例如通过为虚拟机分配标签实现部门关联以及正确配置条件访问策略而非仅修改用户多因素认证设置等典型题目。每道题均附有正确答案、参考文档及社区投票分布便于判断各选项的接受程度。资源为单个PDF文件容量45.55MB仅含一份完整题库文档方便离线刷题和反复练习。目前已累计120人学习适合在备考阶段进行自测和查漏补缺。题库呈现了多个场景化问题与解决方案并支持自定义视图考生可对照专家验证过的答案快速掌握解题思路有效提升通过考试的把握。1. 办公室网络慢到想砸电脑先从这次公网延时排查说起先别急着买新路由器或者给运营商打电话你在家里或者小办公室里遇到的“网页转圈、视频卡顿、游戏跳ping”很多时候跟带宽大小没关系真正的问题是公网链路的质量。去年我帮朋友排查一个“百兆光纤看视频还缓冲”的案例折腾了一下午最后定位到路由器丢包率高达 12%而这一切的起点只是一条最简单的ping命令。这就是本篇要讲的公网延时测试方案一条命令看链路通不通、延迟高不高、丢包严不严重再配合几个进阶工具把玄学网络问题变成可以量化的数据。这篇实战笔记适合刚入门的网管、运维新手以及所有被“网速慢”折磨却不知从何下手的普通用户——跟着一步步做你也能自己定位问题避免被售后忽悠。2. 从 ping 开始一条命令背后的延时原理与工具选型2.1 延时和 RTT 是什么Ping 命令为什么能测网络质量用ping测网络测出来的核心指标叫 RTTRound-Trip Time往返时间也就是你的数据包从本机出发到达目标服务器再返回本机所花费的总时间。这个时间包含了传播延迟光/电信号在介质里跑的时间、处理延迟沿途路由器转发数据包的时间以及排队延迟数据包在路由器缓存里排队等转发的时间。所以 RTT 不是单纯的距离问题你 ping 一个隔壁城市的服务器RTT 可能只要 10ms但 ping 一个同一城市的拥堵服务器RTT 可能飙到 80ms这就是因为对方处理不过来数据包排队了。理解 RTT 的构成你才能正确解读 ping 的输出。做测试时还有一个容易忽略的细节ping默认发的 ICMP Echo 请求报文很小通常只有 32 字节或 56 字节它占用的链路资源微乎其微。这意味着即使链路已经比较拥堵小包的 ping 测试也可能看起来一切正常等真正下载大文件时大流量一上来就把链路打满网络就崩了。2.2 为什么不能只 Ping 一次丢包、抖动与标准差只 ping 一次拿到一个 RTT 值就像只测了一次体温就说人健康没有意义。网络是动态的路由器缓存会起伏运营商线路会波动所以必须连续发多个包观察三个关键指标平均 RTT、丢包率、抖动Jitter即 RTT 的离散程度。丢包率是最直观的——只要不是 0链路就有问题。哪怕丢包只有 1%在 TCP 传输里都会触发重传导致下载速度骤降因为 TCP 对每个丢失的包都要额外等待一个超时周期。抖动则是很多人忽视的点。比如你连续 ping 10 次RTT 分别是 20ms、21ms、19ms、45ms、22ms、18ms、50ms平均值看着是 27.8ms不算高但这个网络实际不堪大用。这 45ms 和 50ms 的尖峰就是抖动。对于网页浏览这种短连接场景抖动的影响不明显但对于视频会议、在线游戏、实时音视频通讯抖动直接导致画面卡顿、声音断续。所以专业一点的测试工具都会同时报告丢包率和 RTT 的标准差。标准差越大说明网络的稳定性越差。下文会用工具展示怎么看这个参数。提示做延时测试必须选一个稳定的、固定 IP 的目标比如223.5.5.5阿里公共 DNS或114.114.114.114114 DNS。选定了就别换来换去否则数据没法对比。2.3 选对工具Windows 的 ping 与 Linux 的 ping 有什么不同Windows 和 Linux 虽然都有ping命令但默认行为和可用参数差异很大。Windows 的ping默认只发 4 个包每个包 32 字节且不会自动显示丢包统计只显示“Lost 0 (0% loss)”。要连续测试得手动加-t参数要改包大小得用-l参数。而 Linux 的ping如果不加-c参数会一直运行直到你按 CtrlC且在运行时能实时看到每个包的 RTT包大小默认通常也是 32 字节。另外Windows 的 ping 输出格式比较冗长不利于脚本处理Linux 的 ping 可以用-c指定次数用-i指定间隔输出也很干净适合直接丢给可视化工具或脚本解析。在做跨平台网络测试时我的习惯是Windows 上直接用 PowerShell 的Test-Connection或者原生 pingLinux 上则直接用 ping或者装fping做批量主机探测。实战中很多网络问题只在特定的包大小下才会暴露。比如 MTU 设置不当大包会分片或丢包小包却毫发无损。所以测试链路时不仅要默认 32 字节的包还要测 1400 字节甚至 1472 字节的大包。Windows 用ping -l 1400 -f禁止分片探测 MTULinux 用ping -M do -s 1400。如果大包不通而小包通十有八九是 MTU 问题。3. 在本地复现一次完整测试这四步抓出问题链路3.1 第一步基础连通性测试给你的路由器把脉打开命令行工具先 ping 路由器地址。Windows 下是ipconfig看网关Linux 下是ip route看 default拿到网关 IP 后直接开测。目标地址是你的局域网网关比如192.168.1.1。# Windows 用户请在 CMD 里执行这条命令会连续发送 20 个 64 字节的包 ping 192.168.1.1 -n 20 -l 64# Linux 用户请在你的终端里执行每秒发送一个包共发 20 个 ping -c 20 -i 1 -s 64 192.168.1.1输出的重点看两部分一是 RTT 的 min/avg/max二是丢包统计Windows 看 LostLinux 看 packet loss。在局域网里RTT 应该在 1ms 以下任何大于 5ms 的数值都说明无线干扰严重、网线接触不良或交换机端口异常。丢包率必须为零只要局域网里丢了一个包外网测试都不用做先把内网清干净。如果这一步正常说明你的问题出在互联网链路上继续往下测。3.2 第二步外网延时测试确认丢包位置在运营商还是机房换一个固定 IP 的公网地址来测建议同时测 4 个目标223.5.5.5阿里、114.114.114.114114 DNS、8.8.8.8谷歌如果你能直连的话和一个你最常访问的网站域名比如baidu.com或某个游戏服务器的 IP。多个目标是为了区分是全网性掉包还是只有某个特定线路出现问题。# 以 admin 身份在 CMD 里执行测外网 DNS 的连续丢包与延迟 ping 223.5.5.5 -n 100 -l 64 # 对比测试同时开一个窗口测 114 DNS。两个窗口同时跑对比哪条线路不稳 ping 114.114.114.114 -n 100 -l 64这里把包数设成 100 个是为了拿到足够的样本量。如果 100 个包里有超过 2 个丢包这条链路的质量就有问题。查看 RTT 的 max 值如果平均延迟 30ms但 max 是 300ms说明链路里存在严重的拥塞或路由绕路。一旦发现大量丢包或延迟剧烈波动就可以基本断定外网链路质量差。如果这里正常而你体验仍然卡顿那问题往往出在服务端或应用层比如 CPU 性能不行、网页资源太大链路本身背不了锅。3.3 第三步大包压力测试揪出 MTU 和无线干扰小包测试正常不代表万事大吉不少网络故障是间歇性的。把包大小从 64 字节增大到 1400 字节左右加大单个报文的传输时间这样做有两个目的一是验证 MTU 设置是否合理二是让无线链路的噪声更明显地体现出来因为大包在无线介质上传送时更容易受干扰而损坏。# Windows 下禁止分片并发送 1400 字节的包如果返回 Packet needs to be fragmented 说明 MTU 有问题 ping 223.5.5.5 -n 30 -l 1400 -f # Linux 下使用 dont fragment 选项测试同样的包大小 ping -c 30 -M do -s 1400 223.5.5.5我在项目里实际测过无数条链路碰到的典型现象是64 字节小包通畅但 1400 字节大包丢包率突然升到 20% 以上。这种情况通常出在使用了 PPPoE 拨号的光猫上因为 PPPoE 的 MTU 默认是 1492如果你的路由器没有正确设置 MTU大包就会被分片或直接丢弃。另一种常见原因是老旧网线或水晶头接触不良大包在高频信号下误码率迅速上升。注意-f或-M do参数非常有用它不仅测延迟还能直接告诉你路径上的 MTU 值。如果你收到的回显是 “Packet needs to be fragmented but DF set”就把包大小递减重测能测算出当前链路的实际最大传输单元。3.4 第四步同屏对比追踪路由看数据包到底绕了多远延时高还有一种隐蔽原因路由绕路。你连上海的服务器数据却先跑到北京再折返回来物理距离变成三倍延迟自然高。这时要用tracertWindows或tracerouteLinux查看数据包经过的每一跳路由节点。# Windows 下追踪到阿里 DNS 的路由路径非管理员也能跑 tracert -d 223.5.5.5 # Linux 下使用 traceroute 命令-n 表示不做反向 DNS 解析速度更快 traceroute -n 223.5.5.5输出的每一行代表一个路由器。看两个关键点一是每一跳的 RTT二是总共经过多少跳。正常情况下到国内主流 DNS 服务器的跳数在 10 跳以内超过 15 跳就要注意。如果中间某一跳突然出现* * *或 RTT 飙升到 200ms 以上问题就出在这一跳上。这里的经验是遇到* * *先别急着下结论因为很多运营商路由器出于安全原因禁用了 ICMP 响应不回应不代表不通。只有当连续多跳出现超时或 RTT 异常时才能判断是链路问题。tracert和traceroute一次结果不足以定位问题得跑三次以上对比每一跳 RTT 的变化趋势。4. 进阶排障工具与参数解析WinMTR 和 PingPlotter 的取舍4.1 为什么单点测试不够持续监测更靠谱一次性测试只能拍到网络质量的瞬间快照而网络问题是间歇性的有时候白天一切正常晚上高峰期才出现丢包和抖动。所以排障时尤其是对付“时好时坏”的故障我会先把持续监测的工具跑起来让数据积累一段时间再做判断。这个操作也叫“留观”跟医院里让你住院观察一个道理。持续监测的收益很明显你可以拿到时间维度上的丢包率分布图看出问题是全天候的还是特定时段出现的。如果丢包集中在晚上 8 点到 11 点基本可以断定是运营商网络在高峰期带宽资源不足你就算把路由器重启十次也没用。如果丢包在整点出现比如每小时的第 45 分钟开始丢包则有可能是运营商做了 QoS 限速或你的路由器在做定时任务。4.2 用 WinMTR 同时看丢包与路由一次测试替代三个命令WinMTR 是 Windows 平台上的神器它把 ping 和 traceroute 合并到一个界面里同时对每一个跃点做持续数据采集并且按照“Host”“Loss%”“Sent”“Recv”“Best”“Avrg”“Worst”“Last”列展示。它解决的核心痛点就是普通 ping 只能告诉你丢包了但告诉你丢在哪里WinMTR 可以定位到具体是哪一跳出了问题。打开 WinMTR 后在 Host 框输入目标 IP按 Start 就开始测试。建议让它跑 10 分钟以上再截图分析因为样本量太少时丢包率统计没有意义。看结果时注意判断标准本地路由器第一跳丢包说明是路由器到光猫之间的问题运营商接入层前两三跳丢包说明是“最后一公里”线路质量问题骨干网节点丢包涉及到运营商之间的互联问题你这边除了换运营商基本没什么办法。这个工具的缺点是没有命令行版本不适合在服务器上跑也拿不到输出报表而且在目标 IP 不响应 ICMP 时会显得很“慌”。但用来做日常小型网络的健康检查已经足够。4.3 Linux 下的持续测试与日志记录自定义脚本的灵活度Linux 环境下没有 WinMTR 的官方替代品不过用系统自带的工具加一个循环脚本就能实现而且能直接用文本格式输出数据配合 Grafana 做趋势图。原理很简单用 ping 命令定时跑测试把输出重定向到文件或者用 awk/sed 提取关键字段拼接成 CSV记录。这个方法的灵活性比 WinMTR 高得多。#!/bin/bash # 这个脚本会每 10 秒 ping 一次目标并输出时间戳和丢包率 while true; do # 单次 ping 发 10 个包每个包间隔 0.5 秒超时 2 秒 ping -c 10 -i 0.5 -W 2 223.5.5.5 /tmp/ping_result.txt 21 # 提取丢包率和平均 RTT loss$(grep -oP \d(?% packet loss) /tmp/ping_result.txt | tail -n 1) avg$(grep -oP (? )[0-9.](?/) /tmp/ping_result.txt | tail -n 1) echo $(date %s) $loss $avg /var/log/net_quality.log sleep 10 done上面脚本的-W 2参数指定了单个包的超时是 2 秒避免在链路完全不通时命令长时间卡住grep -oP用来从输出里提取丢包百分率和平均 RTT 数值。保存为netmon.sh用chmod x赋予执行权限然后在后台运行。这个方案能帮你区分“完全断网”和“间歇性劣化”并且有日志可回溯比人肉盯着屏幕强太多。4.4 用 PingPlotter 做免费可视化看趋势比看数字直观如果你需要把结果呈现给客户或老板看或者只是想让自己一眼看懂PingPlotter 是更好的选择。免费版允许同时监测几个目标显示的图表会清晰展示丢包率和 RTT 随时间变化的关系。它比文本日志直观太多了时间轴是横坐标RTT 或丢包率是纵坐标一目了然。PingPlotter 还有一个 WinMTR 没有的优点它可以把“丢包”和“延迟尖峰”分开看。很多时候丢包率是 0但 RTT 波形每隔几分钟就出现一次插花尖峰这种状况下视频会议依然会出问题。在日志里你会错过这些短期尖峰但在 PingPlotter 的图形上它们非常扎眼。提示如果对企业网络做定期健康检查建议每周固定一天跑一次 WinMTR 和 PingPlotter 组合测试。健康基线建立之后再次出现问题就有了对比数据比临时起意测试结果更容易定位异常。5. 常见网络测试的坑与误判这条命令让我背了三个锅5.1 背锅事件一DNS 解析失败却骂路由器现象用域名 pingwww.baidu.com提示ping: unknown host。第一反应是网络断了检查路由器检查光猫重启了一轮结果问题依旧。原因路由器或电脑配置的 DNS 服务器失效了但链路的连通性完全正常。用nslookup www.baidu.com验证时才发现DNS 解析环节挂了。解决临时指定一个公共 DNS 再测比如在测试命令里直接把目标换成223.5.5.5的 IP 或先nslookup www.baidu.com 223.5.5.5强制用阿里 DNS 解析。之后可以去路由器后台把 DNS 改成自动获取或者直接写两个公共 DNS。判断链路质量一律建议用 IP 地址做目标不要在初次排查时用域名省得把 DNS 和延时两件事搅在一起。5.2 背锅事件二禁 ping 的服务器不回应被误判为断网现象ping 8.8.8.8全部超时同事说“我们连不上谷歌了”查了一下本地网络没问题于是开始怀疑防火墙和运营商。原因很多服务器尤其是机房和云厂商的负载均衡节点为了安全会禁用 ICMP 协议你 ping 不到它不代表它的 TCP 服务不通。解决用telnet IP 443或者Test-NetConnection来测试端口连通性比如Test-NetConnection 8.8.8.8 -Port 443。这一步能确认 TCP 层是否握手成功。如果端口也连不上那才是真正断网了。记住结论ICMP 通代表链路通但 ICMP 不通不代表链路不通这个逻辑要刻进脑子。5.3 背锅事件三只测一次就下结论调度到深夜才反应过来现象白天 ping 一切正常用户晚上 9 点投诉网络卡顿测试发现延时 50ms 丢包 5%但白天测的时候是 20ms 丢包 0%。于是认为是光猫老化换了一个新光猫结果问题依旧。原因大部分家庭网络的晚高峰拥堵完全是由运营商汇聚层和骨干网带宽饱和导致的这不是你设备的问题。晚上 9 点的数据不代表白天数据你只测一次测到的是当前时刻的一个切片。解决持续测试至少 24 小时覆盖晚高峰和空闲时段。最好用上面提到的后台日志脚本或者 PingPlotter 记录全天数据。看到傍晚 6 点到 11 点的丢包率明显高于凌晨 2 点基本可以断定是运营商问题直接报修或联系换宽带方案不用自己在家折腾。5.4 平均延迟正常但视频会议疯狂卡顿的真相现象报告里显示平均 RTT 只有 40ms符合预期但用户开视频会议时声音断断续续、画面经常冻结收到的投诉络绎不绝。原因平均 RTT 掩盖了抖动。测试过程中 RTT 从 20ms 到 200ms 来回摇摆平均值看起来还行但对实时音视频来说一次 200ms 的尖峰就会导致音频缓冲打乱卡顿就在一次尖峰里产生了。解决别只看平均值要看抖动值和最大延迟。在测试报告里同时输出 max RTT 和标准差排除不稳定锯齿波。把 max RTT 超过 100ms 的记录标红能单独标记出触发性尖峰问题。这类问题通常是某个应用在上传大文件占满了上行带宽找到那个应用限速就好了。6. 把延时测试做成习惯三张表建好你自己的网络基线测试做完了不是把结果截图扔一边就完了。最终目的是把“感觉慢”变成“看得见的数字”再拿这些数字去和运营商或网管沟通。我给自己定了一套流程做完以后可以给任何一条网络线路出具体检报告。第一步记录基线。在第一次测试时记录下网络正常时的 RTT、丢包率、抖动范围这就是这条线路的“黄金标准”。后续任何时间发现异常都和这份标准对比。第二步测三种场景空闲状态测一次、满载状态下载大文件测一次、夜高峰测一次三组数据维度就全面了。第三步每台测试设备固定设置好目标 IP不要今天 ping 阿里明天 ping 百度目标不固定数据之间就没有可比性。以下是我每次测试都会记录的最小信息表建议你按照这个格式维护一个日志文件。日期时间段目标地址平均 RTT (ms)抖动/最大 RTT (ms)丢包率备注2024-01-1010:00223.5.5.5185/450%空闲2024-01-1021:00223.5.5.55230/1802%晚高峰2024-01-1210:00223.5.5.5194/400%下载中观察在做基线测试时我的个人习惯是给宽带排障留下“后悔药”——测试日志记录不够详细时遇到偶发问题往往要重新测一轮尤其对那种两天没出现一次故障的链路没有日志基本等于瞎猜。所以每次发现问题我都会顺手把瞬时现象记录到手机备忘录里再用 PingPlotter 的免费版挂机抓一个 12 小时的曲线拿数据说话永远是最高效的沟通方式。这套流程我已经沿用了好几年为了让它真正融入日常我给自己定了一条规矩每次网络调整后当天必须做一次完整的四步测试。延迟测试不是技术的边角料它是一切网络应用质量判断的起点。把这个习惯保持下来你手里永远握着当下链路的体检单任何网络抖动都能直言问题所在希望帮到你。本文还有配套的精品资源点击获取