网速慢？这可不仅仅是带宽问题！

从服务质量角度来看，如果不考虑其他因素，那么家庭网络服务很大程度上取决于带宽。虽然带宽对于web内容用户来说非常重要，但是它并不是仅有的重要指标。众所周知，市面上所卖的高带宽连接并不是真正意义上的传输速度，它们不过是最大网速，只是一个卖点而已。直接说就是：不要期望能达到广告中的速度。

让我们来看一个东西...TCP或者叫传输控制协议，是你的浏览器连接一个网站时所使用的网络协议，而且是数据如何通过＂管道＂传输的基础。TCP网络是基于包的，这就意味着使用TCP网络需要将数据分块来发送。

其中每个数据包都有一定量的协议开销。这种开销影响到带宽的实际有效负载(用户内容)而不是协议本身。而且，一般情况下这种开销大约在15%左右，所以不论你有什么服务这15%的开销都无法避免。

然而除了带宽这个因素外还有什么会影响到网络链接的质量和速度，并且不会被带宽提供商所提及呢？

• 对称性 上传和下载速度是否相同

• 延迟 众所周知的“往返时间”(RTT)

• 可靠性 也就是我们所说的“包丢失”

像很多商业级网络这样的高质量网络是对称的、尽可能低的延迟以及零丢包率。而家庭网络服务绝不是对称的--其上传速度只是下载速度的一小部分、高延迟以及偶尔会出现某种程度上的包丢失。

对称性

首先，为什对称性非常重要？还记得前边提到过的TCP协议开销吗？TCP是基于包的传输协议，而且是双向通信的。为了保证数据包流能可靠的传输，连接的双方必须连续不断保持会话。所以，上传需要占用一定的上行带宽。同时，有趣的是，如果上传通道不论任何原因被限制，那么下载速度也将受影响。上传和下载速度越不平衡，这种现象也越明显。虽然低成本的家庭网络的上传速度很慢，但是对于任意浏览器网页、电子邮件以及许多典型的在线活动，这种速度是可以满足要求的。但当你上传大的文件或者是种子提供者时，你的上传操作可能会大幅影响下载速度。

延迟

延迟是指数据包从你连接的服务器到达你机器所用的时间。在一定程度上，这和你与服务器的距离有关。互联网的骨干网络是由光纤组成，因此数据包基本上是以光速传输的（186,000英里每秒）。也就是说数据包从美国路易斯维尔到欧洲比到芝加哥所花的时间更长，所以说在一定程度上这就是简单的物理问题。但是，这里边还有几个潜在的问题。

在网上，每当数据包通过一个机械设备(交换机和路由器)时速度都会减慢。而一个典型的网络连接可能需要10 - 12“跳”，每一“跳”代表一个路由器，因此，“跳”数越少，延迟也就越低。也就是说，你真正需要的是在经可能少的“跳”数下到达互联网骨干网络。好的点对点网络安排可以祈祷作用；同时，一个好的商业级网络也能起到很大帮助作用。这里我对我的家庭网络和工作网络做一个快速比较：

• AT&T公司的Uverse网络到google.com的“跳”数：13

• TWTelecom商业级网络到google.com的“跳”数：7

那是相当有冲击力的。另外，web工程师也会告诉你，当你在5M以上的网络环境下访问web内容时延迟因素的限制比带宽更大。而且你不能通过增加带宽来减少延迟；这必须通过提高你昂贵的基础设施以及更合理的安排对等网络来实现--这些代价都非常昂贵。让我们来看看以上两个网络环境的延迟情况：

• AT&T公司的Uverse网络到google.com的往返时间(RTT)：38毫秒

• TWTelecom商业级网络到google.com的往返时间(RTT)：9.5毫秒

又一次相当有冲击力。手机网络又是另一码事，4G的网络延迟超过100毫秒，3G的网络延迟超过300毫秒。

另外一个比较复杂的问题是当路由器堵塞也就是超负荷运行时，工作量对路由器过大会这网速下降，这是网络延迟增加的另一个原因，也是低成本家庭网络中经常出现的情况。

可靠性

最后，我们来说说可靠性，通常通过“包丢失”来衡量。当一个路由器超负荷情况下压力越来越大，它的处理速度也越来越慢，那么在某一时刻当它不能再处理更多数据时，它将随机丢弃一些数据包。这些被丢弃的数据包也就基本上从传输流中消失，这也必须要重传。这种情况非常不好，我们可以通过ping命令来测试丢包情况。即使非常少的数量的包丢失也能导致非常严重的连接速度下降，另外，包丢失在低成本的设备上发生的可能性更大。

以上这些概念并不是主要针对一般消费者，大部分消费者并不需要了解这些细节，这主要是针对web工程师和其他互联网业务专家来精通这些概念。也许你的客户往往请你帮助为什么“我的互联网不工作”或“我的网站很慢”，如果你能够通过描述几方面来分析这些问题或者带着你的客户解决这些问题，那么你将为你的客户提供一个很好的服务以及让你的顾客知道你的专业是很有价值的。

 

 

1. 本文由程序员学架构翻译

2. 本文译自Ping Me! It Isn’t Just About Bandwidth

3. 转载请务必注明本文出自：程序员学架构(微信号：archleaner )

4. 更多文章请扫码：