你知道该怎么做。该请求落在办公室之间运行XYZ应用程序。您可以在LAN上运行它，当然，这一切看起来都很好，但是当您将其放在WAN上时，性能会下降到大约很快Rich Eisen的40码破折号时间。现在，您需要向用户解释问题并提出解决方案。让我为您节省麻烦。这是您的用户应用程序不会在WAN上运行的五个主要原因，以及有关该怎么做的一些建议。
1.并非所有申请都是为WAN提出的。
应用程序开发人员喜欢假设最佳的网络条件，但我们知道，WAN与事实相去甚远。主要问题之一是，某些协议（例如CIF）对自己的利益来说太健谈了。对于他们发送的每次传输，他们等待确认。如果位置之间有足够的距离，这些确认提出的延迟加起来并破坏了应用程序性能。
2. TCP会引起大头痛。
长期以来，已知TCP性能的问题 - 有限的窗口尺寸问题，过多的确认等等。除非您解决了潜在的问题，否则TCP应用程序将继续爬网。这是实时应用程序（例如VoIP和视频会议）使用UDP的原因之一。
3.带宽不是运营商所说的。
抱歉，仅仅因为您的公司在旧金山和亚特兰大之间购买了1 Gbps系列，并不意味着您的应用程序可以传输1 Gbps的数据。应用程序将产生许多连接，但通常仅使用其中一个或两个传输数据。该连接的吞吐量和扩展应用程序受WAN连接的数据包丢失，延迟和带宽的限制。有很多在线WAN吞吐量计算器这可以表明如何将1 Gbps线降低至16.51 Mbps，因为延迟的延迟（在美国的WANS非常短）和.5％的数据包损失。
4.数据包损耗差异很大。
准确阅读数据包损耗率可能非常困难。大多数承运人将在其服务水平协议（SLA）中定位0％的数据包丢失，但这些费率通常仅用于骨干。它们不涵盖本地循环，当他们这样做时，承运人在一段时间内，24小时或一个月内的平均损失率。但是，应用程序性能的启动器，尤其是与实时应用程序性能有关的启动者，不是平均损失，而是随机损失。在给定连接上的随机损失很难找出。通常，例如，MPLS网络上的端到端损失率在.1％至0.5％（非常大致）上。
5.服务提供商有罪！
处理数据包丢失的真正令人沮丧的是，一旦数据包离开了房屋，企业就不会做很多事情。WAN拥塞会导致包装丢失和订购包的损失，而不是企业的承运人手中。您可以解决的来源的症状是开关处的2层错误，由物理植物故障引起的CRC错误（电缆，收发器等）以及非标准框架大小，例如框架太长或太短，通常为不良驱动因素的结果。