从服务质量角度来看，假设不考虑其它因素，那么家庭网络服务非常大程度上取决于带宽。尽管带宽对于web内容用户来说非常重要，可是它并非仅有的重要指标。众所周知，市面上所卖的高带宽连接并非真正意义上的传输速度，它们只是是最大网速，仅仅是一个卖点而已。直接说就是：不要期望能达到广告中的速度。
让我们来看一个东西...TCP或者叫传输控制协议，是你的浏览器连接一个站点时所使用的网络协议，并且是数据怎样通过＂管道＂传输的基础。TCP网络是基于包的，这就意味着使用TCP网络须要将数据分块来发送。
当中每一个数据包都有一定量的协议开销。这样的开销影响到带宽的实际有效负载(用户内容)而不是协议本身。并且，普通情况下这样的开销大约在15%左右，所以不论你有什么服务这15%的开销都无法避免。
然而除了带宽这个因素外还有什么会影响到网络链接的质量和速度，而且不会被带宽提供商所提及呢？
-
对称性 上传和下载速度是否同样
-
延迟 众所周知的“往返时间”(RTT)
-
可靠性 也就是我们所说的“包丢失”
像非常多商业级网络这种高质量网络是对称的、尽可能低的延迟以及零丢包率。而家庭网络服务绝不是对称的--其上传速度仅仅是下载速度的一小部分、高延迟以及偶尔会出现某种程度上的包丢失。
对称性
首先，为什对称性非常重要？还记得前边提到过的TCP协议开销吗？TCP是基于包的传输协议，并且是双向通信的。为了保证数据包流能可靠的传输，连接的两方必须连续不断保持会话。所以，上传须要占用一定的上行带宽。同一时候，有趣的是，假设上传通道不论不论什么原因被限制，那么下载速度也将受影响。上传和下载速度越不平衡，这样的现象也越明显。尽管低成本的家庭网络的上传速度非常慢，可是对于随意浏览器网页、电子邮件以及很多典型的在线活动，这样的速度是能够满足要求的。但当你上传大的文件或者是种子提供者时，你的上传操作可能会大幅影响下载速度。
延迟
延迟是指数据包从你连接的server到达你机器所用的时间。在一定程度上，这和你与server的距离有关。互联网的骨干网络是由光纤组成，因此数据包基本上是以光速传输的（186,000英里每秒）。也就是说数据包从美国路易斯维尔到欧洲比到芝加哥所花的时间更长，所以说在一定程度上这就是简单的物理问题。可是，这里边还有几个潜在的问题。
在网上，每当数据包通过一个机械设备(交换机和路由器)时速度都会减慢。而一个典型的网络连接可能须要10 - 12“跳”，每一“跳”代表一个路由器，因此，“跳”数越少，延迟也就越低。也就是说，你真正须要的是在经可能少的“跳”数下到达互联网骨干网络。好的点对点网络安排能够祈祷作用；同一时候，一个好的商业级网络也能起到非常大帮助作用。这里我对我的家庭网络和工作网络做一个高速比較：
-
AT&T公司的Uverse网络到google.com的“跳”数：13
-
TWTelecom商业级网络到google.com的“跳”数：7
那是相当有冲击力的。另外，webproject师也会告诉你，当你在5M以上的网络环境下訪问web内容时延迟因素的限制比带宽更大。并且你不能通过添加带宽来降低延迟；这必须通过提高你昂贵的基础设施以及更合理的安排对等网络来实现--这些代价都很昂贵。让我们来看看以上两个网络环境的延迟情况：
-
AT&T公司的Uverse网络到google.com的往返时间(RTT)：38毫秒
-
TWTelecom商业级网络到google.com的往返时间(RTT)：9.5毫秒
重新相当有冲击力。手机网络又是还有一码事，4G的网络延迟超过100毫秒，3G的网络延迟超过300毫秒。
另外一个比較复杂的问题是当路由器阻塞也就是超负荷执行时，工作量对路由器过大会这网速下降，这是网络延迟添加的还有一个原因，也是低成本家庭网络中常常出现的情况。
可靠性
最后，我们来说说可靠性，通常通过“包丢失”来衡量。当一个路由器超负荷情况下压力越来越大，它的处理速度也越来越慢，那么在某一时刻当它不能再处理很多其它数据时，它将随机丢弃一些数据包。这些被丢弃的数据包也就基本上从传输流中消失，这也必需要重传。这样的情况很不好，我们能够通过ping命令来測试丢包情况。即使很少的数量的包丢失也能导致很严重的连接速度下降，另外，包丢失在低成本的设备上发生的可能性更大。
以上这些概念并非主要针对一般消费者，大部分消费者并不须要了解这些细节，这主要是针对webproject师和其它互联网业务专家来精通这些概念。或许你的客户往往请你帮助为什么“我的互联网不工作”或“我的站点非常慢”，假设你可以通过描写叙述几方面来分析这些问题或者带着你的客户解决这些问题，那么你将为你的客户提供一个非常好的服务以及让你的顾客知道你的专业是非常有价值的。
1. 本文由程序猿学架构翻译
2. 本文译自Ping Me! It Isn’t Just About Bandwidth
3. 转载请务必注明本文出自：程序猿学架构(微信号：archleaner )
4. 很多其它文章请扫码：
