CIO的困惑：基础网络与关键应用矛盾

编者按：路宽了，为何越来越堵？网络链路宽了，为何关键业务的网络访问速度却瓶颈不断？网络时代的CIO将如何面对这个困惑？

CIO的困惑：到底是网络问题，还是系统应用问题？

如今，网络基础链路越来越好，例如万兆交换、千兆路由的普及，另一边，是企业关键应用的不断多功能化、复杂化，然而，当我们的关键应用运行在网络上时，却或多或少地出现了关键应用访问速度慢等很多问题，这给企业用户带来了不少麻烦。

这就如同北京的三环、四环主路一样，不可否认，北京的公路系统，在全国范围内是建得最好之一的了，公路建得宽，建得好；另一方面，北京市民的用车也越来越好，例如富康变现代。然而，这么宽的路，为何却越来越堵？大家的上班行路时间也一再变久。

很明显，堵车的最直接原因是车多了，因此减少上路车辆是最直接的解决办法，然而，如果简单地减少上路车辆，这将会引出很多社会问题。因此，我们需要采取有效的管理措施，使公路的通行效率更高，让更多的人上班赶路的时间更短。解决的办法例如有设立公交专用道等有力的措施。

同样，在企业网络应用中，我们会有同样的感受，我们的物理网络基础链路越来越宽，但关键业务的网络访问速度却开始不断出现访问速度瓶颈，我们应该如何应对？

对此，F5 产品管理总监 Ameet Dhillon 解释到：“企业的物理网络基础网络是由企业的网络管理员来负责的，然而，对于关键业务系统的维护，却是由系统管理员承担的，很多企业都有两班人马去承担。然而，当关键业务系统出现访问瓶颈时（例如远程访问网络版用友NC ERP系统时，出现不能访问的现象），大家都会去找维护应用系统的系统管理员。然而，这个问题又跟基础网络设施相关，从而导致系统管理员无法解决问题，同样，这是应用系统问题，网络管理员似乎也无能为力。”

于是，CIO困惑了！

基于这样的问题，思科、华为等传统设备厂商不太好提出相应的解决方案，而SAP、ORACLE、用友等应用系统供应商，也难有解决办法。在这种情况下，需要新的厂商提出全新的解决办法。

寻找网络拥堵的真因

面对关键应用网络访问性能低下的问题，你可能最容易想到的是：网络带宽难道不够？在这种情况下，电信公司也往往会建议你增加带宽。

的确，带宽不够是造成网络访问性能低下的原因之一，增加带宽能够在一定程度上解决问题。但是，当带宽增加到一定程度后，网络访问性能低下的问题将依然存在。

其实，应用性能受到许多因素的影响，必须同时满足网络和应用逻辑要求才能得到满意的应用性能结果。在网络层，应用性能受到长时间延迟（空间距离的影响）、不稳定性（jitter）、数据包丢失和拥塞的限制。在应用层，性能进一步被应用协议的正常行为（尤其是在面临网络层的长时间延迟、不稳定性、数据包丢失和拥塞时），过多参与网络链路间握手的应用协议、以及应用本身的连续性所限制。

另外，F5 产品管理总监 Ameet Dhillon指出：“应用性能和吞吐率受多种因素影响。延迟和数据包丢失对应用性能也会产生深远影响。利特尔定律（Littles Law）开创性地描述了队列理论和模拟空间距离（延迟）与数据包丢失等式，说明了这两个因素对应用性能的影响。随着每个请求的往返时间（RTT）的增加，拥塞窗口必然会增加，或者说 TCP 吞吐率将会下降。不幸的是，TCP 不能有效地管理大型窗口。因此，甚至是少量的延迟和数据包丢失也会迅速将给定应用的网络性能降低到 1 MB/秒以下。即使带宽容量提高到 100 Mbps，应用消耗的容量也永远不会超过总容量的 1%。在这些条件下，选择增加网络容量的经理们也只是在增加毫无用武之地的资源，白白浪费资金而已。”

F5 产品管理总监 Ameet Dhillon

在广域网中，导致往返时间（即延迟）较长的原因包括空间距离远、网络路由模式效率低、以及网络拥塞等 —— 这些因素会大量出现在广域网（WAN）中。目前，许多 TCP 协议堆栈管理重传能力的效率都非常低。实际上，如果丢失了一个数据包，那么一些堆栈可能必须重传整个拥塞窗口。在面临网络拥塞时，它们也会呈指数级后退（即减少拥塞窗口的数量并增加重传定时器）。

此时，TCP 会检测到此类行为并将其归类为数据包丢失。虽然在帧中继网络中丢失现象通常不是很严重（平均水平低于 0.01%），但是在通过 IP VPN 网络进出某些市场（如中国）的过程中却非常明显，丢失率总是超过 5%。在后一种情况下，高丢失率会对应用性能造成灾难性的打击。当数据包丢失和延迟现象同时出现时，性能下降更快。