当应用程序被专门托管在公司数据中心时，远程站点的带宽要低得多，并且每个站点都需要自己的WAN优化设备。雷竞技电脑网站按照传统观点，如果我们增加带宽，性能就会提高。然而，如果不降低延迟，应用程序的性能将继续恶化——无论我们在网络上投入多少带宽。
导致延迟的主要原因有四:
- 传播延迟
- 序列化延迟
- 排队延迟
- 处理延迟
传播延迟
这是两个端点之间的延迟。例如，传播延迟是基于每1000公里5毫秒的光速测量的。位于纽约的数据中心和位于圣何塞的分支机构之间的单向传播延迟至少为24毫秒。雷竞技电脑网站这假设有一个直接的光纤路径和没有路由器跳，在这种情况下传播延迟将会显著地更高。对于大型运营商，单向延迟平均在35-45毫秒之间。
序列化延迟
序列化延迟是将一个帧从网络接口计时到传输介质上所需的时间。它直接与链路速度挂钩，也会受到使用不同数据链路协议的网络的影响。
序列化延迟的计算方法是用以比特为单位的数据包大小除以以兆位/秒(Mbps)为单位的链路速度，并包括所有数据包、第2层和第3层开销。为了简单起见，在此讨论中我们将忽略层2的开销。T1和100Mbps的链路很可能是不同的，而且它足够小，可以忽略不计。
表1:不同数据包大小和传输速率的序列化延迟
值得注意的是，虽然有效下载速率可能与实际链接速度不同，甚至可能低于实际链接速度，但序列化延迟仍然仅取决于实际链接速度。
排队延迟
这是来自端点之间等待服务的中间路由器队列中的数据包的延迟。这是唯一一个高度可变的延迟部分。与依赖于光的速度和时钟速率的传播和序列化延迟不同，排队延迟依赖于当前的通信量。如果链路或中间路由器出现拥塞，排队延迟可能从几乎为零增加到几百毫秒。排队延迟的波动取决于所服务的流量类别和服务路由器的配置。
网络设计人员经常试图通过过度配置带宽来避免拥塞，这需要很好地理解网络上的平均和最大负载。但是，DDoS攻击或链接失败等事件仍可能导致拥塞，这些事件将流量转移到通常使用较少的路径。
无论网络的整体负载状况如何，一个精心设计和实现的QoS策略以及适当标记的流量将有助于避免拥塞，至少对于高优先级的流量是这样的。在极端情况下，这可能不成立。
处理延迟
这是在数据包通过路由器时处理它们所需要的时间。处理包括转发路由查找、访问列表处理、cflowd流数据生成和识别、加密。处理延迟在基于软件的路由器中可能略有变化，但在基于硬件的设备中通常是静态的。例如，如果一个基于硬件的转发引擎被设计成每秒处理400万包，那么处理延迟自然必须是1 /4M (250ns)才能让转发引擎跟上。
要了解端点之间的延迟，同时考虑到之前讨论的所有组件，美国的国家运营商是一个很好的参考点。这两个美国电话电报公司(AT&T)和冲刺在线发布他们的延迟数据，通常将纽约和圣何塞之间的延迟设置为~70ms。
因此，San Jose与San Diego之间的延迟约为13ms。实际上，这可能会根据运营商网络的布局而有所不同。例如，圣何塞和圣迭戈之间的连接可能会经过菲尼克斯，这将导致圣何塞和西雅图之间的延迟超过13毫秒。
区域绩效中心
评估不同站点之间的延迟数据是企业决定是否根据用户密度部署区域性能集线器的好方法。使用性能集线器的远程站点将连接到区域广域网优化设备。
例如，如果将性能中心放置在圣何塞的托管设施中，那么西海岸城市(如西雅图、波特兰、洛杉矶和凤凰城)的大多数分支将在20毫秒内延迟。类似地，在全国几个城市的托管设施上部署性能集线器将为企业提供一个最佳的网络和很少需要管理的设备。与5,000台WAN优化设备不同，企业可以根据其性能集散中心的经验总共部署20台或至多50台，从而降低延迟并实现最佳的应用程序性能。