我在两个星期内写在一个博客上我是WAN加速溶解．考虑到我们目前的带宽大小，它只是没有产生我所期望的不可思议的差异。然而，在博客的最后，我提到了一种情况，我认为WAN加速将是谨慎的:
尽管有这些负面影响，我确实觉得广域网加速有一个很好的作用(至少在我们的网络中)。这是在站点有足够的广域网带宽。目前，在没有广域网加速的情况下，由于广域网延迟，大带宽链路站点的用户无法使用它们。例如，从阿姆斯特丹到加利福尼亚的单个TCP会话最大可以达到约5.4 Mbps。但是，我们有近90mbps的广域网带宽在阿姆斯特丹进入我们的MPLS云。所以，我们有带宽，但没有能力利用它。但是现在引入广域网加速。然后我们就有能力(大带宽)利用WAN加速(WARM和COLD传输)的所有好处。如果天气暖和，那就太好了。但是，如果它是冷的，仍然需要通过广域网传输，我们有带宽来做它。 Then you get all the other benefits of WAN acceleration, particularly TCP acceleration which can enhance application response time. Instead of 5.4 Mbps per TCP session, WAN Acceleration takes that COLD TCP session to maybe 20 Mbps. That's a big difference that users will notice.
为了我们自己的内在目的，我开始描绘这种情况，并觉得它很有意义。回顾一下，让我们假设今天的情况，一个小的广域网管道:四年前，这是一个很好的带宽分配，因为我们没有任何VoIP或IP视频和应用程序使用较少的每个会话:但是，快进到今天。现在我们有网络电话，视频，以及关键的应用。哦，每个“其他公司应用程序”在每个会话中占用更多带宽:这就没有给其他任何东西留下空间。随之而来的下一个会话将导致QoS启动并随之删除。然后用户会感到沮丧，因为很多工作是在“其他公司应用程序”队列中完成的。
所以，我们的想法是引入广域网加速，这会带来很大的不同。但是，在我们的情况下，并不是所有的传输都是WARM传输，这使得COLD传输占用了更大的带宽:这导致QoS更快地启动，惹恼了更多的人。
好吧，很明显我们需要更多的带宽，所以让我们添加它，跳过广域网加速硬件的投资。太糟糕了，这也是个问题。在这种情况下，您需要为更多的带宽付出代价，但考虑到TCP上的延迟的影响，无法利用全部带宽。此外，单个用户会话仍然和以前一样，所以他们不会注意到太多的差异(除了QoS消失之外):这是在浪费钱。
所以，真正的解决方案是两者兼而有之(我现在可以听到首席财务官在尖叫)。如果您真的想要获得WAN加速的好处，您需要将它与更多的带宽结合起来。然后你就有能力(广域网加速)+机会(大带宽)来改变用户的性能和生产力:
更多来自Field博客的>:
去思科子网浏览更多思科新闻、博客、论坛、安全警报、图书赠品等。