NASA空间探测器与吞吐量

在我们更详细地探讨参数是如何影响吞吐量之前，让我们先来考虑一个极端的例子：NASA必须与空间探测器和登陆车进行通信。在太空飞行时，详细的无线命令-响应事件和计算模型可以提供精确的航空器跟踪定位。

但是，只有在我们理解了万有引力、行星轨道和磁场以及其它影响，并且在这些知识的基础上进行预测，我们才能获得这个精确性。我们并不知道航天器在T时刻的所在位置，我们只能推测出T-t时刻它所在的位置以及状态，这个时间是它向我们发出响应的时刻。历史数据，外加一个模型的输出，这就是我们“现在”所谈论的航天器所在的位置。对于火星航天器，t值大约是三分钟：命令-响应信号事件的RTT的一半。而对于木星，t值可能接近一个小时。

这样也就不奇怪NASA登陆车没有使用类似于视频游戏的显示和操纵杆来驾驶了。NASA工程师必须制造一个精确的模型，它使机器人才可以执行他们发送的任何命令，同时他们还必须在同一时间将许多命令集合起来一起发出，这样机器人才可以在我们的期限中准确地完成任务。有一些发往火星的命令在过了6分钟之后可能就“OK”了，但是毫无疑问Titan上的命令返回确认需要2个小时的等待就不可行了。在这个极端的命令-响应延迟环境中的关键是远距离智能（如，导航），以及命令序列缓冲和我们终端上的远距离建模。对这种情况的明智设计意味着我们将仍然必须等待，看机器人是否已经到达岩石X并采取了该岩石的表层样本，但是我们将不必发送更多的命令包脉冲来在一个RTT内获取到结果。

对于地球环境，我们最大的物理性延迟就是地球同步卫星连接——1/4秒RTT。相比之下，一个跨越美国的租用地面连线所发出的命令响应时间可能少于40毫秒。十年前，Bell Lab科学家们深入地研究了人们在电话通话时可以容忍多长时间，结果显示50毫秒的延时是被认为可以接受的。而更长的RTT将影响交谈。对于计算机与计算机交换而言，大的RTT意味着更糟糕。

了解误差概率

通过集合命令和数据、了解远节点如何工作、以及认知如何使用最佳协议（不是TCP/IP）来编码数据以实现成功的外层空间传输，NASA解决了其吞吐量需求的问题。这里我们跳过了错误，但是吞吐量上未发现的和未改正的错误的影响仍然是重大的并且是协议无关的。为了减少错误意外的发生，NASA一直以来都使用纠错代码来保护价值数亿——或数十亿——美元的命令和数据。

我们的最后一个例子，在此包括基本协议和路径属性，如窗口、计时器、RTT、MTU和位/数据传输率，同时还添加了错误概率（误码率（BER））。不管网络路径是否达到1GBps非拥塞的数据传输率，如果10%的发送数据包丢失，那么吞吐量会变差。

在这种情况下，每秒钟实际通过路径的应用数据数是受所选择的传输协议（TCP、UDP、SCP、RTP……）以及配置的参数影响的。如果协议无法恢复丢失（如，UDP、VoIP），那么终端应用必须进行恢复，这通常是非常缓慢或者基本不动。如果传输协议无法区分拥塞数据包丢失（如路由超载）和物理性错误丢失（如CRC错误），那么它将出现错误操作，包括使用错误的恢复算法和大规模减缓吞吐量。