我们都曾抱怨过“网络”在某个时候“很慢”：可能局限于一个房间（交换机）或一台计算机，可能只是互联网（DNS？浏览器问题？），可能只是一个应用程序（长时间运行的 SQL 查询？AV 扫描正在运行？）。
排除明显的系统和/或应用程序问题后，如何测试网络是否缓慢或行为不稳定？您是否会逐步向上检查 OSI 层？如果是，如何检查每一层？在未知环境下，如何确保物理网络正常？广播过多或广播风暴怎么办？第 3 层及以上？跟踪路由？还有其他提示、方法或想法吗？各种规模的网络都必须具备的功能和工具（端口镜像、SNMP、监控等）？
答案1
tcpdump 和 wireshark 是你的朋友。
我发现，观察“慢速”网络与“良好”网络上的数据包通常可以查明问题所在。
“慢”有很多种类型。
您可以使用 SmokePing 等工具跟踪本地和互联网网站的延迟。（可以配置 SmokePing 来跟踪 ICMP 延迟以及 TCP 服务的服务延迟）
您的交换机应该跟踪广播数据包与单播数据包。绘制该比率的图表。
我还喜欢监控跟踪路由（检查我自己的“重要”站点之间的 ISP 跳转的域名）。
我希望这些评论能有所帮助。
答案2
很难给出具体的答案，因为这项工作 90% 是经验，它告诉你在哪里寻找哪种问题，而另外 90% 是知道在 Google 上查找哪里可以获得从哪里开始的提示。
我通常会尝试纸袋法，比如让客户演示问题（主要是为了排除手指问题以及客户在描述问题时可能遇到的任何问题），然后尝试在另一台计算机上复制该问题。这样做通常可以让你了解应该从哪里查找。
不要忘记重新启动的纠正问题，尤其是对于 Windows 系统，即使在今天也是如此。以前这种情况经常发生，以至于我会问人们“你重新启动过吗？那就试试吧，如果问题仍然存在，请告诉我”——这解决了我被问到的大部分问题。
DNS 解析问题和基本连接（路由器上的 ACL、网络中的气隙、到远程站点的 ping/traceroute/mtr 等）也经常存在容易解决的问题。
对于您直接控制的服务，运行 nagios 或其他程序以确保服务确实在运行，通常可以促使您在客户告知您问题之前解决问题。您可能还希望运行统计信息收集，无论是直接通过 munin 或其他程序，还是通过 SNMP 收集到 Cacti 之类的程序。
我通常会尝试让 Cacti 至少针对我所有的核心交换机和防火墙运行；如果可能，我会针对所有可能的情况运行 Cacti。在这些情况下，我通常会寻找诸如端口错误计数或过量流量之类的东西。某些设备的防火墙图表可以显示 CPU 使用率和并发会话；您将了解防火墙设备在什么阈值下开始出现问题。
您的防火墙可能能够将日志记录到 syslog 设备；如果是这样，请记录所有可以记录的内容，然后查看其中的提示。如果您运行 syslog-ng、rsyslog 或 splunk 之类的程序，可以稍微划分日志，而不是处理单个文件，那么这会更容易。
我还尝试至少在防火墙内部以及尽可能在互联网提供商的上行链路上运行 nfsen。这样您就可以回溯查看会话，看看谁在做什么；有时这可以捕捉到有趣的行为。
答案3
以下是一些可用于解决延迟和其他网络问题的有用工具：
- 这OSI 模式l - 从底层开始，然后逐步向上
- ping - 检查你的 RTT（即延迟）
- HTTP ping- 如果你的防火墙阻止了正常的 ICMP，这很有用
- ping -r 9 - 有助于识别不对称路由情况
- traceroute - 我的数据包如何到达那里以及沿途的路由器如何响应？请注意，路由器通常以低优先级处理这些数据包，因此实际性能可能更好。
- Wireshark- 需要一些专业知识，但你不能达到更低的水平
- SpeedGuide.net TCP/IP 分析器- 检查你的电脑的 TCP 设置
- SG TCP 优化器- （仅限 Windows）建议优化 NIC 设置的方法
- IP鸡- 你的源（非 NAT） IP 地址是什么？
- http://downforeveryoneorjustme.com/- 或许这是你...
- 带宽速度测试- 检查您的下载/上传速度
- 网络工具- 从网络外部运行工具/测试
- 检查网络端口是否存在错误/CRC/等等。-
- 检查网络是否过度利用（带宽监视器）和广播风暴
- 检查单播泛滥 - 使用 wireshark 并监控未发往您的工作站的单播流量。
- 验证生成树根桥是否放置正确
答案4
我总是从使用以下方式监控第 2 层内容开始仙人掌。这将为您提供大量数据，您可以使用这些数据来寻找模式，并且可以比较一切运行良好时和用户看到速度缓慢时的 Cacti 图表。
它可能无法找到确切的问题，但它会给你一个良好的起点来帮助缩小问题范围。