在继续讨论不同的技术之前，那些是下一代企业广域网(NEW)架构以及其他的——地址丢包以及如何丢包，我认为有必要深入探讨一下为什么丢包对广域网上的应用程序性能有如此巨大的影响。
虽然这不是一个能让科学家、工程师和网络开发者满意的深刻的技术解释，但它将在本系列的典型专栏中，我们将提供更多的技术细节。
我们花了两个列在在WAN上影响应用程序性能的因素他指出，丢包是其中之一广域网上的应用程序性能的祸害．事实上,包丢失根据设计，对WAN上大多数应用程序的性能有最大的影响。
为什么丢包是一个杀手?原因有很多，大多数都与“如何”的本质有关传输控制协议工作，特别是TCP如何进行拥塞控制/拥塞避免。关键问题是如何处理有限带宽的争用。
TCP被设计为使用所有可用带宽，并且平均“公平”地跨流使用它。要做到这一点,考虑到每个端站和TCP流不知道有多少带宽可用——无论是如果单流是唯一一个使用端到端带宽,也在更加典型的情况下,当给定的多个流,可用数量变化时刻。因此，TCP数据的发送方需要一种方法来知道什么时候“够了”。丢包是最基本的信号。
虽然这可能违反直觉，但TCP和路由器一起被设计为导致并以特定的方式对其作出反应，以避免网络的过度利用和潜在的拥塞崩溃。因为如果在网络被高度利用到过度利用的程度时，提供给网络的数据没有减少，那么有用的工作，也就是。“goodput”,将停止。想想你在高速公路上看到的交通堵塞，最常见的是在入口和出口，但偶尔也会横穿高速公路。TCP设计的目标是最小化高速公路停止的时间(避免拥堵)，并适当地做出反应，在它停止的时候减少交通流量(拥堵控制)。
接收站接收到的TCP报文被确认回发送站。TCP是一个基于窗口的协议，这意味着它可以在发送站和接收站之间有一定数量的流量。它被设计成在观察到丢包时后退并大幅减少所提供的带宽(减半)。此外，在收到丢失的数据包并被接收者确认之前，只会提供数量有限的额外数据包。即使对于那些使用多个TCP流的应用程序，同样的原则也适用于只有那么多的新流打开/包发送，直到另一端收到丢失的包并确认其收到。
检测丢包的方法有两种。对于仅丢失一两个包的较长的传输，当接收方确认随后的包时，发送方会注意到丢失的包，并对丢失的包作出反应，而不是丢失的包。另外，对于新的或较短的TCP流，更典型的是，包丢失是通过出现“超时”来检测的:没有收到对包的确认。直到“超时”被认为发生的时间通常在几百毫秒到3秒之间。
TCP是40多年前设计的一种优雅的协议，当时用于保持状态的CPU和内存非常昂贵，而路由器中间件的设计目标是使它们是无状态的。这种方法在高带宽、低带宽的情况下非常有效，并将继续有效延迟局域网和低带宽、高延迟广域网上。但是，TCP的设计并不是为了在中高带宽、高延迟的环境中工作，而这种环境是当今大多数广域网使用的特点。TCP也不是为在非常长距离的广域网上运行交互应用程序(web浏览，远程桌面)而设计的。
特别是TCP，它的设计使每个端站都可以完全独立地做出决策。这种保守的方法有助于网络的稳定性和拥塞的最小化。
由于提供给网络的数据量减少了一半——并且只在成功接收到的包被确认后缓慢增加——当发送站检测到单个包丢失时，广域网包丢失会对大型传输性能产生巨大影响。
对于前几个包中的一个丢失的短流，单个丢失的包可能导致严重的应用程序延迟，因为需要等待超时发生。
现在，如果网络是所以拥塞使许多数据包正在丢失，这可能是正确的行为，以确保网络条件不会变得更糟。但对于因单次失败而“不幸”的广域网流来说，这种惩罚往往过于严厉。
TCP所采用的保守方法仍然是解决局域网中网络带宽争用的最佳方法。然而，这些年来，智能广域网设备和技术在中间，它们的CPU处理能力和可用内存比TCP刚引入时高出许多数量级多更大的CPU和内存能力相对于广域网带宽，甚至可以做出更好的决定，提供更稳定的网络，更高的效率，更好的网络利用率和更好的应用程序性能。
下一次，我们将开始研究各种WAN技术和技术解决丢包对应用程序性能影响的方法。
安迪是一位有着25年数据网络经验的老手Talari网络，是广域网虚拟化技术的先驱，并担任其第一任首席执行官，目前领导着广域网的产品管理Aryaka网络．安迪是一本即将出版的关于下一代企业广域网的书的作者。