为何不直接依靠浏览器的自动机制呢？有些时候，你可能希望解析一个页面中任何地方都没有提到过的主机名。重定向就是一个典型的例子：链接可能指向一个主机——就如同一项分析追踪服务一样——这个主机再把用户重定向至真正的目标站点。Chrome依靠自身是无法推断出这种模式的，但你可以手动提供一条提示帮助它，让浏览器提前解析真实目标站点的主机名。
这一切在后台是如何实现的呢？和我们讨论过的其他优化手段一样，这个问题的答案也取决于Chrome的版本，因为开发团队一直试验新的、更好的方式来提升性能。但是，不严格地说，Chrome内部的DNS基础设施有两个主要的实现方式。过去，Chrome依靠操作平台无关的系统调用getaddrinfo，并把DNS查询的实际职责交由操作系统完成。但是，这种方式正逐步被Chrome自己实现的异步DNS解析器所替代。
依靠操作系统的原有方式具有其优点：代码少而简单，并能够利用操作系统的DNS缓存。但是，getaddrinfo也是一个阻塞型的系统调用，这意味着Chrome必须创建并维护一个专用的worker线程池，才能够实现多条并行查询。这个未连接池最多只能容纳六个线程，这个上限是基于硬件的最小公分母得出的经验数字——这样并行请求的数量超出的话，有些用户的路由器就会过载。
对于使用worker池的预解析，Chrome就只是调度getaddrinfo调用，这会一直阻塞worker线程，直至响应就绪后马上丢弃所返回的结果，并开始处理下一条预获取请求。结果由操作系统的DNS缓存来存储，未来实际进行getaddrinfo查询时，它会立即返回响应。这种方式简单有效，实践中的表现也不错。
但这还不够好。getaddrinfo调用有很多有用信息不向Chrome公开，比如每条记录的生存时间（TTL）时间戳，以及DNS缓存本身的状态。为了提升性能，Chrome团队决定自己来实现跨平台的异步DNS解析器。
图1.7 启用异步DNS解析器
通过把DNS解析放到Chrome内部来处理，新的异步解析器可以实现一些新的优化手段：
更好控制重传计时器，能够并行执行多条查询
记录生存时间的可见性，使得Chrome能提前刷新热点记录
更好的双栈实现（IPv4和IPv6）行为
基于RTT或其他信号的，对不同服务器的故障切换
以上所有以及其他很多想法都是在Chrome内持续试验并优化的。这就必然涉及一个问题：我们如何了解并衡量这些想法的效果呢？很简单，Chrome会为每个profile分别记录详细的网络性能统计数据和直方图。要查看所收集到的DNS统计数据，可以打开新标签页，访问chrome://histograms/DNS（见图1.8）。
图1.8 DNS预获取的直方图
上面的直方图显示出了DNS预获取请求延迟的分布情况：大约50%的（最右侧列）预获取查询在20毫秒内完成（最左侧列）。注意，这是基于最近的浏览会话（9869个样本）的统计得到的，并属于用户的隐私数据。如果该用户选择报告Chrome的使用统计数据，则这些数据的摘要会被匿名处理，定期反馈给开发团队，他们就可以看到试验的效果并进行相应的调整。
使用预连接优化TCP连接管理
我们已经预解析了主机名，按照Omnibox或Chrome预测器的估计，我们很有可能即将进行浏览行为。为什么不更进一步，也推测性地预连接到目标主机，在用户发出请求之前完成TCP握手的步骤呢？这样一来，我们又能消除掉一个往返延迟，轻松省去用户数百毫秒的时间。没错，TCP预连接正是这样做的。
打开新标签页访问chrome://dns可以查看已经触发TCP预连接的主机。
图1.9 展示已经触发TCP预连接的主机
首先，Chrome会检查socket池，看看是否有该主机名的可用socket可供重用——存活socket会在池中留存一段时间，以避免TCP握手和慢热启动的惩罚时间。如果没有socket可用，则由其发起TCP握手并放入池中。然后，当用户进行浏览时，HTTP请求就可以立刻调度。
Chrome在chrome://net-internals#sockets中提供了一个工具可以查看Chrome中所有已开启socket的状态。图1.10是相关的截图。
图1.10 已开启的socket
你还可以详细查看每个socket，检查时间线：连接和代理时间，每个包的到达时间等等。最后要说的很重要的一点是：你也可以导出这些数据进行后续分析或报告bug。具有良好的信息统计机制对任何优化都是很关键的，chrome://net-internals就是Chrome中所有功能相互作用的集中展示——如果你还没探索过这个功能，你应该试试！
使用预获取提示优化资源加载
有时，页面的作者能够提供基于其站点结构或布局附加的导航或页面上下文，帮助浏览器优化用户体验。Chrome支持两种这样的提示，可以嵌入页面标记中使用：
子资源和预获取看起来非常类似，但是语义完全不同。当链接资源指定其关系为“预获取”时，它是告诉浏览器，这项资源在以后的浏览中可能用到。换言之，这实际上是一个跨页面提示。而当资源指定其关系为“子资源”时，它是提前告诉浏览器该资源会在当前页面中被用到，在该文档后面的部分遇到它之前可以先发起请求。
可以想见，两者的不同语义会导致资源加载器的行为大相径庭。标记预获取的资源会被看做优先级较低，并在当前页面加载完成后由浏览器进行一次下载。标记为子资源的内容一旦遇到就会作为高优先级资源来获取，并与当前页面上的其余资源相互竞争。
这两种提示如果使用得当可以极大地帮助优化你站点的用户体验。最后，还要注意，预获取是HTML5规范的一部分，目前Firefox和Chrome都支持，而子资源目前只限于Chrome。
使用浏览器预刷新优化资源加载
不巧的是，不是所有站点所有者都能够或愿意在标记中为浏览器提供子资源提示。而且，即使他们这样做，我们还是要等待HTML文档从服务器传送过来之后才能解析这些提示，开始获取这些必要的子资源——根据服务器响应时间和客户端与服务器间的延迟，这可能需要耗费数百乃至数千毫秒。
但是，我们前面看到，Chrome已经通过学习常用资源的主机名来执行DNS预获取了。那么，为什么不如法炮制，更进一步：执行DNS查询，使用TCP预连接然后也推测性地预获取资源呢？没错，这就是预刷新的作用：
用户发起对目标URL的请求
Chrome询问预测器其所学习到的与目标URL相关的子资源，并发起DNS预获取、TCP预连接和资源预刷新等一连串行为
如果所学到的子资源在缓存中，则将其从磁盘加载到内存中
如果所学到的子资源缺失，或者已过期，则进行一次网络请求
资源预刷新是展示Chrome中每个试验性优化手段的工作流的绝佳例子——理论上讲，一项优化应该使性能得到提升，但是也涉及很多因素的此消彼长。只有一种方式能够可靠地确定一项优化是不是有效，是不是适合于Chrome：先实现它，并在一些预先发布的渠道（真正的网络、真实浏览模式、真人用户）上进行A/B试验。
在2013年初，Chrome团队还处于讨论这种实现的早期阶段。如果根据所收集的结果它能奏效，我们我们可能会在年内晚些时候在Chrome中看到预刷新。Chrome的网络性能优化从未止步——开发团队一直在试验新的方法、创意和技术。
相关文章
网友评论（共有 0 条评论）
