后面准备抽时间对大作High Performance Browsing Networking进行翻译，主要是自己看的慢，所以就边看边翻译，权当学习。
水平有限，欢迎围观、指正、批评~~
------------------------------------------------------------------------------------------------------------------------------------
第一部分 网络
第一章 延迟和带宽入门
速度是一个功能（Speed Is a Feature）
过去几年，WTO（web performance optimization）行业的出现和快速发展释放了一个明显的信号，速度越来越重要，用户要求更快的用户体验。在我们不断加速和连接的世界中，这不是简单的对速度需求的强迫症，而是由对很多在线业务最低性能需求测量而得的实证结果驱动的需求。
- 更快的网站带来更好的用户参与度
- 更快的网站带来更好的用户保留率
- 更快的网站带来更高的用户转换率
简言之，速度是一个功能。为了实现这个功能，我们需要理解与之相关的各种因素和基本的限制。本章，我们将把重点放在决定网络流通性能的两个关键因素：延迟和带宽（图1）。
延迟
从源端发出包到目标端收到包的时间间隔
带宽
一个逻辑或物理通信链路的最大吞吐量
对延迟和带宽如何协同作用有了更好的理解之后，我们就有信心深挖TCP， UDP，和所有基于这两个协议的应用层协议的内部结构和性能特征。
通过Hibernia Express降低横跨大西洋的延迟
延迟是金融市场上很多高频交易算法的一个重要标准，一个几毫秒的微弱差别可能导致数百万的损失，也可能带来数百万的利润。
2011年初，华为和Hibernia Atlantic（美国宽带服务商）开始部署一条新的横跨大西洋的3000英里光纤，以连接伦敦和纽约。新光纤的唯一目标是节约5毫秒的交易延迟。
部署好之后，这条电缆将只给金融机构使用。整个工程花费 4亿美元，换句话说是，节约一毫秒需要花费8000万美元！延迟是相当昂贵的 -- 名副其实。
延迟的构成（The Many Components of Latency）
延迟是一个消息，或一个数据包从发送端到达接收端所花费的时间。这是一个简单而且有用的定义，但也隐藏了很多有用的信息 -- 每一个系统都包含多个源，或组件，它们会影响到消息发送的整体时间，理解有哪些组件和它们的性能的决定因素是很重要的。
让我们进一步看看，互联网上，用于中继消息的典型的路由器，一般有哪些的部分影响到延迟。
传播延迟
一个消息从发送端传输到接收端所需要的时间，与传播距离正相关。
传输延迟
把所有数据包的bits推送进链路所需要的时间，与数据包长度和链路的数据传输率有关。
处理延迟
处理包头，检查位错误，决定包的目的地总共需要的时间
排队延迟
能够被处理前，在队列中等待的时间
客户端与服务器之间的延迟是如上所列所有延迟的总和。传播延迟由信号传输的介质和距离决定 -- 我们将会看到，传播速度通常是比光速小一些。另一方面，传输延迟由传输链路的可用数据传输率决定，与客户端和服务器之间的距离无关。举个例子，假设我们要通过两条链路：一条1Mbps，一条100Mbps, 传输一个10Mb的文件。把整个文件放入1Mbps的链路，需要10秒，而放入100Mbps的链路只需要0.1秒。
下一步，当数据包到达路由器时，路由器必须检查包头来决定输出路由，而且还要对数据做其它的检查 -- 这也花时间。许多这类逻辑现在常常由硬件完成，所以延迟会很小，但确实存在。最后，如果数据包到达的速度比路由器处理的快，它们就要在输入缓冲中排队等待。数据在缓冲中等待的时间，毫无疑问，就是所谓的排队延迟。
每一个在网络上传输的包，都会遇到许多这些延迟的实例。客户端与服务器之间的距离越远，花在传播上的时间就越长。沿途遇到的中间路由器越多，每个包的处理和传输延迟就越大。最后，传输路径上的负载越高，包被阻塞在输入缓冲中的概率就越大。
你的本地路由器中的缓冲膨胀（Bufferbloat）
Bufferbloat是一个由Jim Gettys在2010年杜撰并普及的术语，它是一个说明排队延迟对网络整体性能影响的很好的例子。
潜在的问题是，在应该不惜代价避免丢包的假设下，如今的路由器都配备了很大的输入缓冲。但这破坏了TCP的拥塞避免机制，给网络引入了高且可变的延迟。
好消息是，为了解决这一个问题，已经提出了一个新的CoDel主动式队列管理算法，而且目前已经在Linux 3.5内核中实现。更详细了解，请参考 "Controlling
Queue Delay"。
光速和传播延迟
爱因斯坦在他的相对论中强调，光速是万事万物所能达到的最大速度。这给任何网络包的传播时间设置了一个硬性限制。
好消息是，光速是很高的：299,792,458米/秒（3.0x10^8米/秒）。然而，有个附加条件，这是光在真空中传播的速度。我们的数据包不是通过真空，而是通过铜线和光纤传输，这将使信号变慢（表 1-1）。
光速与数据包在某种介质中的传输速度之比就是众所周知的该物质的折射率。这个值越大，光在这种物质中传输得就越慢。
光纤的折射率一般是1.4到1.6 -- 很慢，但可以肯定的是，我们正在不断改进传输介质的质量，折射率将会变得更低。出于简单考虑，经验法则是假设光纤中的光速是200,000,000米每秒，相应的折射率系数就是1.5。这里值得注意的部分是，我们已经离最大速度相差不远了！这本身就是一个了不起的工程成就。
光速是很快的，尽管如此，从纽约到悉尼的RTT仍然需要花费160ms。事实上，表一的数据是比较乐观的，它们是在假定数据包沿着两个城市之间的最优路径（球面上两点之间的最短距离）传输的基础上估计的。实际上，不存在这样的线路，数据包将会经过一个比纽约和悉尼之间的距离长的多的路径。路径上的每一跳都会引入额外的路由、处理、排队、和传输延迟。结果，在当前线路上，纽约与悉尼之间的RTT，实际上是200-300毫秒之间。考虑了各方面的事情，看起来还是很快，是这样吗？
我们不太习惯用毫秒来衡量我们的日常生活，但研究显示，如果给系统引入100-200毫秒的延迟，我们大多数人就会感觉到有延迟。一旦延迟超过了300毫秒，我们就会觉得交互不及时，如果大于1秒，许多用户在等待响应时就会心不在焉了。
结论很简单：为了给当前任务所涉及的用户带来最好的用户体验，我们的应用程序需要在几百毫秒内作出反应。这留给我们，特别是网络的错误空间已经不多了。为了达到目标，必须小心的管理网络延迟，在开发的所有阶段都要把它作为一个设计考量准则。
内容分发网络（Content delivery network）提供很多好处，最主要的是能够简单观察分布在全球各地的内容，从一个离客户端比较近的位置提供内容服务，这将大大降低所有数据包的传播延迟。
虽然我们不能使数据包传输的更快，但可以通过策略定位我们的服务器接近用户来缩短距离。利用CDN来服务你的数据可以获得明显的性能优势。
![]()
最后一英里延迟
讽刺的是，主要的延迟，通常是在最后几英里，而不是横跨海洋或大陆时，引入的：声名狼藉的最后一英里问题。为了把你的住所或办公室连接到互联网，你当地的运营商需要在附近部署电缆，聚集信号，并把它们传递到当地的一个路由点。实际中，取决于连接类型、路由方法、部署技术，可能要花费数十毫秒进行几次跳跃才到达ISP的主路由器！根据由Federal
Communications Commission于2013年初实施的报告“美国带宽测量”（Measuring Broadband America），在使用高峰：
光纤用户，在高峰时平均有18ms的延迟，是性能最好的，同轴电缆用户是26ms，DSL是44ms。
也就是说，在数据包路由到目的之前，仅到ISP核心网络的最近测量点会有18-44ms的延迟。FCC报告关注的是美国，但是最后一英里问题是所有英特网提供商所面临的挑战，不分地域。如果对此感兴趣，一个简单的traceroute就能够告诉你很多关于你的英特网提供商的拓扑逻辑和性能的知识。
在前面的例子中，数据包起始于Sunnyvale，跳跃到Santa Clara，然后是Oakland，再回到San Jose，被路由到“529 Bryant”数据中心，在这里被路由到Google，在11跳时到达了它的目的地。整个过程，平均每跳花费18ms。看起来还不坏，但在同样的时间，数据包几乎可以穿越整个美国大陆了。
最后一英里延迟可能变化很大，这取决于你的ISP、部署技术、网络逻辑、时段。作为一个终端用户，如果你希望改进你的网页浏览速度，在挑选你的本地ISP时，低延迟是值得考虑的一个因素。
对大多数网站而言，性能瓶颈是延迟，而不是带宽。要理解其中缘由，我们需要理解TCP和HTTP协议的机制 -- 这是我们随后章节将要讨论的问题。然而，如果你很好奇，你可以随时翻到“More Bandwidth Doesn't Matter(Much）"。
使用Traceroute测量延迟
Traceroute是一个简单的网络诊断工具，用于确定数据包的路由路径和IP网络中每一跳的延迟。为了识别每一跳，它以不断增加的"hop limit"发送一系列达到目标主机的数据包。达到跳限制时，中继者返回ICMP超时消息，从而允许工具测量每一个网络跳的延迟。
在Unix平台，这一工具可以通过在命令行输入 tranceroute来启动，在Windows上，是众所周知的tracert。
核心网络中的带宽
光纤作为简单的“导光管”，比人的头发丝粗一点，被设计用来在电缆的两端传递光信号。金属线也会被用到，但有更高的信号损失率，容易受电磁干扰，维护成本也更高。可能，这两种类型的电缆，你的数据包都会经过，但在做长距离跳跃时，它们将通过光纤进行传输。
在带宽上，光纤有明显的优势，因为每一根光纤都能够通过，被称之为波分多路复用（WDM）的过程来携带不同波长的光。因此，一条光纤链路的总带宽是单通道数据速率的多倍，具体而言就是多路复用的通道数乘以单通道数据速率。
2012年初，研究人员就能够在单个通道上覆用400种波长了，达到峰值流量171Gbit/s，也就是说单个光纤链路的总带宽超过了70Tbit/s！我们需要几千条铜轴电缆才能匹配这个吞吐量。毫不奇怪，大部分的长距离跳跃，例如大陆之间的海底数据传输，现在都是通过光纤链路完成。每条光缆携带多条光纤（一般是四条），这样每条光缆的带宽容量达到了几百terabits/秒。
网络边缘带宽
主干网，或光纤链路，组成了因特网的核心数据路径，它们能够每秒传输数百terabits。然而，网络边缘的可用容量要少的多的多，而且基于不同的部署技术：拨号上网、DSL、电缆、无线主机技术、光纤到户、甚至是当地路由器的性能，差异巨大。用户的可用带宽是由客户端与目标服务器之间的最低容量的链路决定的（图1-1）。
阿卡迈科技（Akamai Technologies）使用位于全球各地的服务器，经营全球CDN，在Akamai’s
website 提供免费的平均宽带速度季度报告，这些数据是通过他们的服务器观测到的。表-2显示了2013年1季度的宏观带宽趋势：
上述数据不包括来自移动运营商的流量，有关移动网络我们后面再做进一步讨论。现在，一言以蔽之，移动速度通常变化很大而且很慢。然而，即便如此，2013年初全球平均带宽也仅仅是3.1Mbps!韩国以14.2Mbps的平均吞吐量居世界首位。
给个参考，根据分辨率和编码/解码器的不同，流媒体高清视频需要2-10Mbps的带宽。因此，一个拥有平均带宽的用户能够在线观看一个低分辨率的视频，这已经消耗了他们链路带宽的大部分 -- 对于有多个用户的家庭而言，这不是他们爱听的故事。
搞清楚给定用户的带宽瓶颈是件平凡但重要的工作。再一次，如果你感兴趣，有很多在线服务，比如由Ookla运营的speedtest.net（图1-2），提供到某些本地服务器的上行带宽和下行带宽测试
-- 在我们讨论TCP时，我们将会明白为什么挑选一个本地服务器是重要的。通过这些服务来测试你的网络，是一个检测你的实际速度是否与本地运营商声称的速度相符的好方法。
然而，一条到你的ISP的高带宽链路是可取的，但它也不能保证稳定的端到端性能。由于突发需求量、硬件故障、集中网络攻击、主机故障等原因，网络中的任何中间结点都可能在某些时间点发生阻塞。吞吐量和延迟性能的高波动性，是我们的数据网络的天性--预测、管理、适应不断变化的“网络天气”是件复杂的任务。
提供更好的带宽和更低的延迟
我们对更高带宽的需求正在快速增长，很大程度上是由于视频流的日益普及，如今已经占到了整个互联网流量的一半。好消息是，尽管可能不便宜，但我们有多种可用策略用于增加可用带宽：增加更多光纤到光纤链路中，在拥塞路由上部署更多链路，或者改进WDM技术以通过现有链路传输更多数据。
TeleGeography，一个电信市场研究和咨询公司，估计截止2010年，我们只使用了已部署的海底光纤容量的20%。甚至更重要的是，2007至2010年间，跨太平洋光缆所增加容量的一半是由于WDM改进：同样的光纤链路，链路两端更好的数据复用技术。当然，我们不能期望这种进步能够无限发展下去，因为每一种媒介都会达到收益递减点。尽管如此，只要企业经济条件允许，没有理由带宽不随着时间的推移而增加
-- 如果真的不能再增加了，我们也还有最后的法宝，增加更多的光纤链路。
另一方面，改进延迟，是个非常不同的故事。能够通过改进光纤链路的质量以使我们再稍微接近光速：使用更低折射率的材料和更快的路由器。然而，鉴于我们目前拥有的速度，使用该策略最多只能达到30%的改进。不幸的是，面对物理定律，我们根本无能为力：光速限制了我们能达到的最低延迟。
还有另外一个办法，虽然我们不能使光跑得更快，但我们能够缩短距离 -- 球面上两点间的最短距离定义为：the great-circle path。然而，由于物理地形、社会与政治原因、当然还有相关成本这些限制，部署新的光缆也不总是可行的。
所以，为了改善我们应用程序的性能，在构建和优化我们的协议、网络代码时，要牢记可用带宽和光速的限制: 我们需要降低往返次数，把数据移到更靠近用户的地方，构建能够通过缓存隐藏延迟的应用，使用pre-fetching技术和后面章节将会介绍到的各种类似的技术。