日常生活中，我们经常会遇到一种体验：Wi-Fi 信号明明显示满格，但视频一直转圈缓冲、网页迟迟打不开，打游戏延迟还特别高。问题通常不在于“有没有信号”，而在于这条网络通道当前能承载多少有效流量、传输是否及时且稳定。
带宽、吞吐量、延迟与丢包
要理解网络性能，先要分清几个核心指标：
- 带宽（Bandwidth）：指网络链路理论上的最大承载速率。运营商宣传的“千兆宽带”，单位通常是
1000 Mbps，也就是每秒 1000 兆比特。由于1 Byte = 8 bits，1000 Mbps换算成下载速度，理论上限约为125 MB/s。 - 吞吐量（Throughput）：指单位时间内在网络中实际成功传输的有效业务数据量。由于 Wi-Fi 干扰、协议开销、服务器带宽限制、网络拥塞等因素，实际吞吐量往往明显低于理论带宽。
- 延迟（Latency / RTT）：指一个数据包从发送端发出、到达接收端并返回确认所需的往返时间（Round-Trip Time）。网络游戏、视频会议等实时应用对延迟非常敏感，RTT 超过约
100ms时，通常就会感到明显卡顿。 - 抖动（Jitter）与丢包率（Packet Loss）：抖动指每次往返延迟的波动程度；丢包率指数据包在传输过程中丢失的百分比。丢包会让 TCP 触发重传和降速，网络体验会迅速变差。
一个简单判断方法
如果测速下载很快，但游戏卡顿，往往更可能是延迟、抖动或丢包问题；如果视频频繁缓冲，则更可能是实际吞吐量不足、链路拥塞或服务器侧带宽受限。
ping：测试连通性与往返时延
ping 是网络排错中最常用的诊断工具。它基于网络层的 ICMP（Internet Control Message Protocol，互联网控制消息协议） 发送 Echo Request（回显请求），并等待目标返回 Echo Reply（回显应答）。
在 Linux 终端运行：
crow@laptop:~$ ping -c 4 192.168.12.129
PING 192.168.12.129 (192.168.12.129) 56(84) bytes of data.
64 bytes from 192.168.12.129: icmp_seq=1 ttl=64 time=2.00 ms
64 bytes from 192.168.12.129: icmp_seq=2 ttl=64 time=3.00 ms
64 bytes from 192.168.12.129: icmp_seq=3 ttl=64 time=2.00 ms
64 bytes from 192.168.12.129: icmp_seq=4 ttl=64 time=5.00 ms
--- 192.168.12.129 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 2.000/3.000/5.000/1.225 ms
关键信息怎么看
- 0% packet loss：表示 4 个测试包全部收到回复，说明 ICMP 可达，链路相对稳定。
- time=2.00 ms：表示单次往返延迟约为 2 毫秒。
- ttl=64：表示目标返回报文时剩余的 TTL 值。不同系统默认初始 TTL 不同，Linux 常见为 64。
注意：ping 不通并不一定代表服务器死机。许多生产环境服务器和防火墙为了防御 ICMP 洪水攻击、网络扫描或拒绝服务攻击，会默认丢弃 ICMP 请求。此时 Web 的 80 端口、443 端口仍可能正常提供服务。
traceroute：追踪数据包经过的路由
Linux 下的 traceroute，在 Windows 下对应 tracert，可以列出从本机到目标主机沿途经过的每一台路由器，也就是每一“跳”。
它的实现原理很巧妙：
- 第一轮向目标发送 TTL=1 的探测包。第一台直连路由器收到后，将 TTL 减为 0，丢弃该包，并返回一个 ICMP Time Exceeded（时间超时） 报文。这样，我们就能看到第 1 跳路由器的 IP 和往返延迟。
- 第二轮发送 TTL=2 的探测包。第 1 跳路由器将 TTL 减为 1 后继续转发，第 2 跳路由器将 TTL 减为 0，丢弃并返回 ICMP Time Exceeded，从而暴露第 2 跳。
- 依次将 TTL 设置为 3、4、5……直到探测包最终抵达目标服务器，或者达到最大跳数。
如果输出中出现若干 * * * Request timed out，通常是因为沿途某些骨干路由器或防火墙策略不回应 ICMP 差错报文。只要后续跳数仍然能够继续推进，就说明数据转发本身没有中断。
一次完整访问：从敲回车到网页显示
现在，把一次浏览器访问网站的完整过程串起来理解：
- 网络接入与地址获取：设备通过 Wi-Fi 或有线接入网络，并通过 DHCP 自动获取本机 IP、子网掩码、默认网关和 DNS 服务器。DHCP 的交互过程通常可以概括为 Discover、Offer、Request、Acknowledge。
- 域名解析：浏览器或系统发起 DNS 查询，将用户输入的域名转换为可用的公网或内网 IP 地址。
- 路由判断与二层寻址：操作系统根据本机 IP 和子网掩码判断目标地址是否属于同一子网。如果目标在外网或不在同一子网，则根据路由表将数据包交给默认网关；如果本地尚未记录网关的 MAC 地址，就会通过 ARP 查询获得网关接口的 MAC。
- 建立传输连接：与目标服务器通过 TCP 三次握手 建立连接：
SYN → SYN-ACK → ACK。 - 加密与应用层请求：如果访问 HTTPS 网站，则在 TCP 之上完成 TLS 握手，随后发送 HTTP GET 请求。
- 沿途转发与状态检查：数据包从本地网卡出发，每经过一台路由器都会 逐跳减 TTL，并在每一段链路上更新二层帧的源 MAC 和目的 MAC。流经家庭或企业网关时，还可能经历 NAT 地址与端口转换，并接受防火墙状态规则检查。
- 响应返回与页面渲染：远程 Web 服务器根据端口号将请求交给对应进程处理，生成 HTML、CSS、JS 等响应数据，沿原路返回，最终由浏览器渲染成网页。
最后，用一组网络诊断参数来检验对上述模型的理解：
发送方网卡配置：10.24.6.90/27
发送方网卡 MAC：02:00:00:00:06:90
主机本地路由表：
10.24.6.64/27 直接从本地网卡链路发送（直连网段）
0.0.0.0/0 下一跳网关经 10.24.6.65 转发
当前 ARP 缓存表：
10.24.6.65 → 02:00:00:00:06:65
本次应用程序要访问的目标端点：10.24.6.110，TCP 8080 端口