用于诊断和修复networking问题的前N个工具/方法是什么？
例如，给定一个局域网，用户可以一直ping外部服务器，但任何数据密集型连接都是片状的; 你将如何开始解决networking问题？
我想象拥塞，带宽限制，吞吐量限制等问题都是因素，但我不知道如何诊断这些问题。
我特别感兴趣的是局域网环境（而不是广域网）
这是一个非常广泛的主题，但作为一个开始，networking\数据包嗅探器是一个宝贵的工具。 有很多可用的。 我倾向于使用多种工具，具体取决于它是什么types的networking问题。 我使用Wireshark主要解决两个特定设备（客户端到服务器，服务器到服务器等）之间的问题，并使用Colasoft Capsa解决拥塞和使用问题。 Wireshark非常善于展示networking对话的细节，但在试图“可视化”一般的拥塞或使用问题时，可能有些压倒性的。 Colasoft Capsa更好地获得“可视化”的问题。
如果您的networking通信性能较差（由于拥塞和/或利用率），您需要查找以下内容：
大量networking广播（在networking层或物理层）和/或大量的TCP重传和慢确认。
大量的广播可能是NIC，主机，交换机，软件，驱动程序等configuration错误或错误的指示，也可能是networking某处恶意软件感染的指示。 由于每个主机都必须监听广播stream量，以确定stream量是否适合自己，广播可能导致拥塞，进而导致networking链路（交换机端口）的高利用率。
TCP重传和慢确认也是networking拥塞的一个指示。 拥塞导致分组发送和接收缓慢，并且导致ACK“迟到”，迫使发送主机重发正在等待ACK的分组。 如果你拥挤，这是重传和慢速的原因，那么你可以放心，这是造成性能问题。
我已经使用mtr（基于linux屏幕的跟踪路由），每分钟慢速ping（1到2）来监视对端点的响应。 如果一个或多个交换机堵塞，则会显示ping丢失或响应缓慢。 这可能是双工问题的结果。
在某些情况下，我看到Cisco路由器似乎在硬编码为全双工的链路上运行半双工。 可以通过双向传输大文件来testing双面打印问题。 一个方向比另一个方向慢得多。 这使得通过networking的软件包安装变得不可能。
在所有的接口（主机和路由器）上转储错误计数器可能会有帮助。 错误计数器应该是0或者低值，并且不会以明显的速度增加。
不知道如果你的Windows的房子，但下面的博客将有所帮助也从MS研究它的非常酷的tcp分析器。
如果您遇到数据密集型TCP传输速度变慢的问题，您可能会受到“全局同步”的困扰，线路上的所有TCP通话器的TCP窗口大小大致同步增长（之前允许的未完成字节数ACK被接收）。
TCP传输窗口越大，A和B之间的数据传输速度越快。当多个主机通过单个链路发送TCP（同一方向）时，此链路上使用的带宽将根据窗口大小所有主机。 当链路不拥塞时，TCP窗口大小将增加，直到数据包开始丢弃（通常对于所有TCP会话同时），并将TCP窗口大小设置为可能的最小大小，使链路不受影响。 然后，在没有拥塞的情况下，所有的发送者将同步增加窗口大小。
如果你看一个短时间间隔的利用率曲线图，一旦使用完整的链路容量，这应该从“锯齿形”斜坡上升并急剧下降。 你可能会想要比每五分钟更频繁地轮询你的广域网链路使用情况，我想说每分钟的统计数据可能就够了，但你可能不得不下降到每5-10秒。
我知道消除这种情况的最好方法是使加权随机早期丢弃，在WAN链路拥塞之前基本上丢弃数据包，从而使LAN上所有主机的TCP窗口彼此解耦。