再谈光速太慢!

开篇：润墨网以专业的文秘视角，为您筛选了一篇再谈光速太慢!范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

光速是世界上最快的速度。就连《无极》，都在追寻时空速度。那么，网络呢？现实中的速度远没有想象中那么畅快淋漓。是距离？还是介质？抑或数据处理的方式？

1998年，我曾经写过一篇论述光速太慢的文章。但我们发现，如果没有我们的设备，用户会因因特网协议本身的缺陷，感到网络运行性能很差。但有些人认为“增加带宽会解决这个问题”，于是很快就把这个问题忘记了。

现在，8年过去了，我们仍然没能提高“光”的速度。目前的广域网(WAN)带宽比过去增加了许多倍，而我们那些远离数据的员工要想获得信息仍需要等待，可能情况比原来还要糟糕。

现在越来越多的用户在远离企业数据的地方工作。Nemertes Research最近的一次调查表明，“在公司总部工作的员工平均不到10%。”而同时，IT 部门通过进行服务器整合，来减轻管理负担并遵守备份规则的要求。比如惠普公司就曾宣布把全球的85 个数据中心减少到了6个。

过去的8年中，将应用传送到用户的方法也发生了变化；基于网络的应用成为主流标准(往往采用SSL进行加密)；用于培训的媒体数据流以及丰富的内容经常在企业内部进行传播，Web的应用比传统的C/S(Client/Server)应用所消耗的带宽至少要多10倍。

增加带宽不等于加快吞吐量

增加带宽有助于数据传送到某一个点，并且对于更多的位于远程办公室的用户来说，增加的带宽越多，其带来的好处就越多――这些都是毋庸置疑的。

举一个简单的例子：一条65英里长的高速公路限速65英里，一辆空驶汽车在道路上走完全程需要一个小时，如果道路发展计划显示该高速公路将在今后的8年中增加一倍的车辆。于是增加行使车道一倍，为新的交通状况提供足够的宽度。但是，每个坐在自己车里的人会怎么样呢？他们能够更快地到达终点吗？要知道限速仍然是65英里。因此，尽管我们增加了一倍的车辆，每单辆车走完全程仍然需要同样的时间，即一个小时。

再拿这个例子打个比方：如果开车的人在8年前要搬家，他需要在这条公路上往返两次搬运他的东西，那么搬家的总体时间就是4个小时(两个往返)。假如今天他又搬家了，而且需要搬运的物品增加了10倍。现在除非他雇用一辆卡车，否则的话，他就需要往返20次，或者说总共需要40个小时的时间。而在公路上行使车道的数量是多少则和他没有任何关系。

应用的劲敌――距离

如果应用的劲敌不是带宽的话，那是什么呢？答案是距离。讲得再确切一点，就是往返的时间。往返时间是由下面的因素决定的：

光的速度

数据需要传输的实际距离(电缆可不是从数据源头直接到达目的地的)

路由器、防火墙和网络的延迟

服务器或者PC机自身的延迟

一次能够传输的数据量，一般是由协议决定的

我们的协议在广域网(WAN)上效率不高

现在我们要谈到数学(不要害怕，不会太学术的)。

TCP/IP 的最初设计目标是创造一个几乎所有网络都可以使用的协议。发送者发送一个小型的信息包(不超过64K)之后，就要等待接收一个从接收者发送的ACK(数据确认Acknowledgements of Data)，然后才可以继续发送其它文件。这就如同汽车在高速路上载运一件物品，走完65英里的路程，然后再空驶回来取另外一件物品。

更糟糕的是，其它协议规定的最大值更小(比如Microsoft Exchange 采用的MAPI，其最大量为32K)。那么，一个5MB 的文件就需要至少78次往返 (如果采用MAPI的话，则需要156次)。

即使这样也是假设TCP采用的是最大的窗口尺寸。但是，窗口尺寸是可以根据设备的反应时间进行协调和调整的。TCP在长时间的延迟链接中从未得到一个64KB 的窗口。

光速难道还不快吗？

好，我承认，光速在真空里是非常快的――299,792公里/秒，或者186,282 英里/秒。但是，光速在纤维和铜里的速度只是真空速度的70%，大致210,000公里/秒。

再让我们回到那个5MB 的文件需要至少 78 次往返的例子上。我们如果假设服务器在马萨诸塞的波士顿，而用户在伦敦，他们之间的距离有5279公里。单次往返的距离就是10558公里，那么78次往返的距离就是78×10558 ，即823524公里。用这个距离除以210000，我们得到的是至少需要4秒钟才能获得这个文件。

但是这还只是纯理论的分析，而且是在假设用户和服务器是直接连接的情况下(不存在路由器延迟、网络堵塞问题)，而且当时是最佳的TCP窗口尺寸。

你自己可以计算――比你想象的要慢两倍！

大多数的PC机都具备一个叫做PING的功能，你可以通过这个功能看到实际的设备穿越WAN连接和因特网的往返时间。开始之前一定要确保你测试的端点就是你想测试的端点，网上也有很多途径可以告诉你服务器的位置。

理论上，我们从波士顿到伦敦的往返时间可以缩短到50毫秒(即10,558除以 210,000)，但是当你测试以后你会发现这个时间至少增加了一倍。我曾经在伦敦附近写东西，就测试过传送到三个在波士顿附近的网站的往返时间(当时大多数美国人正在睡觉，因此堵塞较少)，而收到文件的平均往返时间是129 毫秒。现在一个5MB的文件就需要10秒钟才能收到，而且这还是在假设没有服务器或者防火墙延迟、没有网络堵塞、没有启动慢、没有附加信息包请求获得服务器对内容和传输的批准、且具有最大窗口大小的情况下计算的。

我们要注意，波士顿和伦敦之间的往返距离只有10,558 公里，而绕地球一周的长度是这个距离的8倍。而且距离越远，情况就越糟糕。这里还有几个在其它距离的情况下传输5MB文件需要的往返时间的例子：

旧金山――伦敦 16 秒

旧金山――悉尼 23秒

达拉斯――北京 21 秒

巴黎――新德里 12.5秒

(不要试图想用卫星来替代――卫星距离地球的距离就有35000 公里，这样会造成更大的延迟)。

找到真正的问题，有时候就只剩一种选择了。在总部工作的人需要坐飞机到另外一个远程办公室办公一周，

只因他需要访问所有存放在总部的数据！

该怎么办

简单来说，我们需要减少数据从服务器到用户之间的往返时间。回到我们那个搬家的例子，我们可以做的事情有：

1. 舍弃一些不必要的物品――从而减少往返次数。

2. 优化我们的运送机制；不用自家轿车，雇用一辆卡车，从而每次可以多载一些物品。

3. 首先运送最重要的物品。比如，冰箱或卷发器哪个更重要？

对于数据来说，达到快速传输的目的还有许多其它的方法可以同时使用。

一、对象或者文件缓存

把对象的一个副本保存在远程办公室，就采用对象缓存的方法。当用户对一个已经被另外一个用户请求过的对象发出请求时，那么这个对象就可以从本地缓存中获得(在检查服务器缓存的副本是最新的之后)。这样就减少了WAN的带宽使用，而延迟也几乎为零。

二、字节缓存

当一个对象不是全部缓存，可以先确定数据中重复的样本，然后用令牌的形式代替重复数据来发送。这样就可以只发送少量的字节，不用传输大量的数据。于是就提高了带宽的使用效率，降低了传输内容的时间。

三、协议优化

要想避免协议的缺陷，可以在等待确认之前就发送大量的数据块，快速启动那些传输比较慢的协议，甚至预测用户对数据的请求(如果用户请求打开一个文件，这些设备应该能够预测到用户对其它文件也将提出请求)。

四、压缩

采用站点之间的压缩技术，减少带宽消耗和往返次数。

五、带宽管理

为保证系统最有效地使用可用带宽，按照用户组、服务器或者应用程序等对带宽进行优先排序。

六、消除不适当的流量

我们不要忘记业务流量经常与非业务流量相竞争。部署可以实施策略的设备，对不适当的流量进行拦截。

结论：延迟是应用的杀手

带宽不是最主要的，距离才是真正的杀手。尽管具有无限带宽，数据仍然缓缓地从服务器到用户之间进行往返，直到全部数据传输成功，这样我们还是需要等待。企业应对这种情况进行实际调查，然后解决这个问题。否则，远程办公几乎不可能。