消灭网络拥塞

文章来源：泛普软件

一些常见问题
在开始找出故障之前，你需要就你的网络回答一些问题。即使是你对答案成竹在胸，你也应当使用工具来验证这些答案。让我们从下面的问题开始：

你的网络是什么样子的？你有图表来描述它么？
网络链路的容量有多大？
网络上运行着什么类型的应用程序？
这些应用程序都有什么样的特点？对延迟是否敏感？
这些程序产生了多少流量？这些流量具备什么样的模式？
网络拥塞是在什么时候开始的？是突然出现的还是慢慢产生的？
拥塞会持续很长时间还是来得也快去得也快？它是在某一天或某星期或某个月的一个固定时间产生么？
网络最近是否有一些可能引发拥塞的改变（比如新的应用程序，硬件变更，安装补丁等）？

验证答案

考虑一下你对这些问题的答案，你或许认为你已经知道了造成拥塞的原因。不要忙，你需要使用一些工具来验证你的推断。例如，你如何确定拥塞得链路的确是你所认为的那条？在Cisco路由器上，这可能只需要简单的使用 show interface命令，例如：

看到了吧，接收负载对于这条512K的回路来说太高，5分钟内的输入速率对链路来说也太快了。这样的结果表明这条链路的确出现了拥塞。你还可以使用Paessler的PRTG来验证你的结论，这是一种更为方便的检测链路使用情况的图形化工具。不过，尽管这些工具能助你确定自己在朝着正确方向努力，但无论是PRTG还是show interface都无法告诉你这些流量来自何方，他们到底到底是什么。

确定流量的构成

要更好的了解链路上的流量，你需要一个包捕获器，或是类似Packeteer、Network General Sniffer以及Network Instruments Observer这样的工具。这些工具能在远程硬件上捕获数据包包，然后把包送回到解包工作站（就是你的桌面计算机了），还可以对这些包的内容进行解释（Packeteer还能引发阻塞）。

如果你是在拥塞网络的本地站点，要判断有问题的网络流量就太简单了，只需要对交换机连接路由器的端口进行映像，然后使用Ethereal这样的工具在PC上察看流量就可以了。有很多方法可以分析出网络流量的构成，因此你只需要选择自己最熟悉的方法就可以了。

决定如何应对这些流量

一旦判定出了流量的构成，通常你会有两种选择：一是阻断一些流量，二是继续放行。如果可以通过阻断流量解决拥塞问题，你真是太幸运了。你可以通过访问控制列表来阻断流量，或是直接将其封堵在源端。
如果你不得不选择将流量继续放行，你可以使用下面一些方法。当然，这些方法各有利弊。

增加网络带宽；

对流量进行服务质量（QoS）控制；

压缩流量。

权衡与选择

增加更多带宽意味着你每个月要多花钱了（至少对WAN来说）。然而，有时这是你唯一的选择。
举个例子，你有25个使用Citrix的用户，只有一条56K的专用帧中继链路路由器，没有QoS或压缩方案能解决问题。你只能选择增加带宽。

另一方面，如果相对于你的Citrix和VoIP业务流量，带宽已经够大了，但有时用户还是抱怨网络太慢。这种情况发生在用户在256K的WAN链路上打印10MB的PDF文件。在这种情况下，你需要使用QoS。
这样的解决方案需要确定网络上的应用程序的需求（就本例而言，是延迟的敏感度问题）。对延迟不敏感的打印任务会把延迟敏感任务的速度托慢，因此延迟敏感流量需要更高的优先级。绝大部分用户都不会注意到自己的打印任务慢了一拍，但都会对电话音质变糟或Citrix会话变慢十分敏感。

你可以借助压缩来代替扩充带宽。然而，压缩这种方法有几点需要你注意。
一个大问题就是这种方法并不会总是奏效。压缩只能针对特定类型的流量，并可以会对其他类型的流量造成延迟。此外，压缩还会非常麻烦，因为如果有多个站点，你需要对每一个站点部署一个压缩单元。
尽管Cisco的路由器可以对流量进行压缩，但这会带来延时，并且极大的消耗CPU计算。Cisco路由器还可以执行 QoS，但无论是配置过程，还是察看配置是否生效都会比较麻烦。

尽管部署类似于Packeteer这样的专用QoS设备要花上一笔钱，但我认为，这远胜过尝试在Cisco路由器内部配置 QoS。尽管我对Cisco路由器喜爱有加，并且尽一切可能去使用它，但有时你还是需要考虑“术业有专攻”的解决方案。(zdnet)

发布：2007-04-22 09:59 编辑：泛普软件 · xiaona [打印此页] [关闭]

消灭网络拥塞

泛普南昌OA信息化其他应用