优化DNS预连接 前面已经多次提到了DNS预解析，在深入实现之前，先汇总一下DNS预解析的场景和理由: 运行在渲染进程中的WebKit文档解析器(document parser), 会为当前页面上所有的链接提供一个主机名(hostname)列表，Chrome可以选择是否提前解析。 当用户要打开页面时，渲染进程先会触发一个鼠标悬停(hover)或按键(button down)事件。 Omnibox可能会针对一个高可能性的建议页面发起解析请求。 Chrome Predictor会基于过往浏览记录和资源请求数据发起主机解析请求。(下面会详细解释。) 页面本身会显式地要求Chrome对某些主机名称进行预解析。 上述各项对于Chrome都只是一个线索。 Chrome 并不保证预解析一定会被执行，所有的线索会由Predictor进行评估，以决定后续的操作。最坏的情况下，可能无法及时解析主机名，用户就必须等待一个 DNS解析时间，然后是TCP连接时间，最后是资源加载时间。Predictor会记下这个场景，在未来决策时相应地加以参考。总之，一定是越用越快。 之前提过到Chrome可以 记住每个页面的拓扑(topology),并可以基于这个信息进行加速。还记得吧，平均每个页面带有88个资源，分别来自于30多个独立的主机。每打开这 个页面，Chrome会记下资源中比较常用的主机名，在后续的浏览过程中，Chrome就会发起针对某些主机或者全部主机的DNS解析，甚至是TCP预连接!
使用chrome://dns 就可以观察到上面的数据(Google+页面), 其中有6个子资源对应的主机名，并记录了DNS预解析发生的次数，TCP预连接发生的次数，以及到每个主机的请求次数。这些数据就可以让Chrome Predictor执行相应的优化决策。 除了内部事件通知外，页面设计者可以在页面中嵌入如下的语句请求浏览器进行预解析： 之所以有这个需求，一个典型的例子是重定向(redirects). Chrome本身没办法判断出这种模式，通过这种方式则可以让浏览器提前进行解析。 具体的实现也是因版本而有所差异，总体而言，Chrome中的DNS处理有两个主要的实现：1.基于历史数据(historically), 通过调用平台无关的getaddrinfo()系统函数实现。2.代理操作系统的DNS处理方法，这种方法正在被Chrome自行实现的一套异步DNS解 析机制(asynchronous DNS resolver)所取代。 依赖于系统的实现，代码少而 且简单，但是getaddrInfo()是一个阻塞式的系统调用，无法有效地并行多个查询操作。经验数据还显示，并行请求过多甚至会超出路由器的负额。 Chrome为此设计了一个复杂的机制。对于其中带有worker-pool的预解析, Chrome只是简单的发送getaddrinfo() 调用, 同时阻塞worker thread直到收到响应数据。因为系统有DNS缓存的原因，针对解析过的主机，解析操作会立即返回。 这个过程简单，有效。 但还不够！ getaddrinfo()隐藏了太多有用的信息，比如Time-to-live(TTL)时间戳, DNS缓存的状态等。于是Chrome决定自己实现一套跨平台的异步DNS解析器。
这个新技术可以支持以下优化:
基于RTT和其它事件，针对不同服务器进行错误处理(failover) Chrome仍然进行着持续的优化. 通过chrome://histograms/DNS可以观察到DNS度量数据：
上面的柱状图展示了 DNS预解析延迟时间的分布：比如将近50%(最右侧)的查询在20ms内完成。这些数据基于最近的浏览操作(采样9869次)，用户可以选择是否报告这 些使用数据，然后这些数据会以匿名的形式交由工程团队加以分析，这样就可以了解到功能的性能，以及未来如何进一步调整。周而复始，不断优化。 |
