Google Chrome 中的高性能网络

1、Google Chrome 的历史和指导原则

【译注】这部分再也不详细翻译，只列出核心意思。

驱动 Chrome 继续前进的核心原则包括:

• Speed: 作最快的(fastest)的浏览器。
• Security: 为用户提供最为安全的(most secure)的上网环境。
• Stability: 提供一个健壮且稳定的(resilient and stable)的 Web 应用平台。
• Simplicity: 以简练的用户体验(simple user experience)封装精益求精的技术(sophisticated technology)。

本文关将注于第一点，速度。

1.1 关于性能的方方面面

一个现代浏览器就是一个和操做系统同样的平台。
在 Chrome 以前的浏览器都是单进程的应用，全部页面共享相同的地址空间和资源。
引入多进程架构这是 Chrome 最为著名的改进【译注:省略一些反复谈论的细节】。

一个进程内，Web 应用主要须要执行三个任务：获取资源，页面 排版及渲染，和运行 JavaScript。
渲染和脚本都是在运行中交替以单线程的方式运行的，其缘由是为了保持 DOM 的一致性，而 JavaScript 本 身也是一个单线程的语言。
因此优化渲染和脚本运行不管对于页面开发者仍是浏览器开发者都是极为重要的。

Chrome 的渲染引擎是 WebKit, JavaScript Engine 则使用深刻优论的 V8 (“V8″ JavaScript runtime)。
可是，若是网络不顺畅，不管优化 V8 的 JavaScript 执行，仍是优化 WebKit 的解析和渲染，做用其实颇有限。
巧妇难为无米之炊，数据没来就得等着!

相对于用户体验，做用最为明显的就是如何优化网络资源的加载顺序、优先级及每个资源的延迟时间(latency)。
也许你察觉不到，Chrome 网络模块天天都在进步，逐步下降每一个资源的加载成本：向 DNS lookups 学习，记住页面拓扑结构(topology of the web), 预先链接可能的目标网址，等等，还有不少。
从外面来看就是一个简单的资源加载的机制，但在内部倒是一个精彩的世界。

1.2 关于 Web 应用

开始正题前，仍是先来了解一下如今网页或者 Web 应用在网络上的需求。

HTTP Archive 项目一直在追踪网页构建。
除了页面内容外，它还会分析流行页面使用的资源数量，类型，头信息以及不一样目标地址的元数据(metadata)。
下面是 2013 年 1 月的统计资料，由 300,000 目标页面得出的平均数据:

• 1280 KB
• 包含 88 个资源(Images,JavaScript,CSS …)
• 链接 15 个以上的不一样主机(distinct hosts)

这些数字在过去几年中一直持续增加(steadily increasing)，没有停下的迹象。
这说明咱们正不断地建构一个更加庞大的、野心勃勃的网络应用。
还要注意，平均来看每一个资源不过 12KB, 代表绝大多数的网络传输都是短促(short and bursty)的。
这和 TCP 针对大数据、流式(streaming)下载的方向不一致，正由于如此，而引入了一些并发症。

下面就用一个例子来抽丝剥茧，一窥究竟……

1.3 一个 Resource Request 的一辈子

W3C 的Navigation Timing specification定义了一组 API，能够观察到浏览器的每个请求(request)的时序和性能数据。
下面了解一些细节:

给定一个网页资源地址后，浏览器就会检查本地缓存和应用缓存。
若是以前获取过而且有相应的缓存信息(appropriate cache headers)(如 Expires, Cache-Control, etc.), 就会用缓存数据填充这个请求，毕竟最快的请求就是没有请求(the fastest request is a request not made)。
不然，咱们从新验证资源，若是已经失效(expired)，或者根本就没见过，一个耗费网络的请求就没法避免地发送了。

给定了一个主机名和资源路径后，Chrome 先是检查现有已创建的链接(existing open connections)是否能够复用, 即 sockets 指定了以(scheme、host 和 port)定义的链接池(pool)。
但若是配置了一个代理，或者指定了proxy auto-config(PAC)脚本，Chrome 就会检查与 proxy 的链接。
PAC 脚本基于 URL 提供不一样的代理，或者为此指定了特定的规则。
与每个代理间均可以有本身的 socket pool。
最后，上述状况都不存在，这个请求就会从 DNS 查询(DNS lookup)开始了，以便得到它的 IP 地址。

幸运的话，这个主机名已经被缓存过。
不然，必须先发起一个 DNS Query。
这个过程所需的时间和 ISP，页面的知名度，主机名在中间缓存(intermediate caches)的可能性，以及 authoritative servers 的响应时间这些因素有关。
也就是说这里变量不少，不过通常还不致于到几百毫秒那么夸张。

拿到解析出的 IP 后，Chrome 就会在目标地址间打开一个新 TCP 链接，咱们就要执行一个 3 度握手(“three-way handshake”): SYN > SYN-ACK > ACK。
这个操做每一个新的 TCP 链接都必须完成，没有捷径。
根据远近，路由路径的选择，这个过程可能要耗时几百毫秒，甚至几秒。
而到如今，咱们连一个有效的字节都还没收到。

当 TCP 握手完成了，若是咱们链接的是一个 HTTPS 地址，还有一个 SSL 握手过程，同时又要增长最多两轮的延迟等待。
若是 SSL 会话被缓存了，就只需一次。

最后，Chrome 终于要发送 HTTP 请求了 (如上面图示中的 requestStart)。
服务器收到请求后，就会传送响应数据(response data)回到客户端。
这里包含最少的往返延迟和服务的处理时间。
而后一个请求就完成了。
可是，若是是一个 HTTP 重定向(redirect)的话？
咱们又要从头开始这个过程。
若是你的页面里有些冗余的重定向，最好三思一下！

你得出全部的延迟时间了吗?
咱们假设一个典型的宽带环境：没有本地缓存，相对较快的 DNS lookup(50ms), TCP 握手，SSL 协商，以及一个较快服务器响应时间(100ms)和一次延迟(80ms,在美国国内的平均值):

• 50ms for DNS
• 80ms for TCP handshake (one RTT)
• 160ms for SSL handshake (two RTT’s)
• 40ms （发送请求到服务器）
• 100ms (服务器处理)
• 40ms (服务器回传响应数据)

一个请求花了 470 毫秒, 其中 80% 的时间被网络延迟占去了。
看到了吧，咱们真得有不少事情要作！
事实上，470 毫秒已经很乐观了:

• 若是服务器没有达到到初始 TCP 的拥塞窗口(congestion window)，即 4-15KB，就会引入更多的往返延迟。
• SSL 延迟也可能变得更糟。若是须要获取一个没有的认证(certificate)或者执行online certificate status check(OCSP), 都会让咱们须要一个新的 TCP 链接，又增长了数百至上千毫秒的延迟。

1.4 怎样才算”够快”?

前面能够看到服务器响应时间仅是总延迟时间的 20%，其它都被 DNS，握手等操做占用了。
过去用户体验研究(user experience research)代表用户对延迟时间的不一样反应：

• 0 – 100ms 迅速
• 100 – 300ms 有点慢
• 300 – 1000ms 机器还在运行
• 1s+ 想一想别的事……
• 10s+ 我一会再来看看吧……

上表一样适用于页面的性能表现: 渲染页面，至少要在 250ms 内给个回应来吸引住用户。
这就是简单地针对速度。
从 Google, Amazon, Microsoft 以及其它数千个站点来看，额外的延迟直接影响页面表现：流畅的页面会吸引更多的浏览、以及更强的用户吸引力(engagement) 和页面转换率(conversion rates).

如今咱们知道了理想的延迟时间是 250ms，而前面的示例告诉咱们，DNS Lookup, TCP 和 SSL 握手，以及 request 的准备时间花去了 370ms, 即使不考虑服务器处理时间，咱们也超出了 50%。

对于绝大多数的用户和网页开发者来讲，DNS，TCP，以及 SSL 延迟都是透明，不多有人会想到它。
这也就是为何 Chrome 的网络模块那么的复杂。

咱们已经识别出了问题，下面让咱们深刻一下实现的细节…

2、深刻Chrome的网络模块

2.1 多进程架构

Chrome 的多进程架构为浏览器的网络请求处理带来了重要意义，它目前支持四种不一样的执行模式(four different execution models)。

默认状况下，桌面的 Chrome 浏览器使用 process-per-site 模式, 将不一样的网站页面隔离起来, 相同网站的页面组织在一块儿。
举个简单的例子: 每一个 tab 独立一个进程。
从网络性能的角度上说,并没什么本质上的不一样，只是 process-per-tab 模式更易于理解。

每个 tab 有一个渲染进程(render process)，其中包括了用于解析页面(interpreting)和排版(layout out)的 WebKit 的排版引擎(layout engine), 即上图中的 HTML Render。
还有 V8 引擎和二者之间的 DOM Bindings，若是你对这部分很好奇，能够看这里(great introduction to the plumbing)。

每个这样的渲染进程被运行在一个沙箱环境中，只会对用户的电 脑环境作极有限的访问–包括网络。
而使用这些资源，每个渲染进程必须和浏览内核进程(browser[kernel] process)沟通，以管理每一个渲染进程的安全性和访问策略(access policies)。

2.2 进程间通信(IPC)和多进程资源加载

渲染进程和内核进程之间的通信是经过 IPC 完成的。
在 Linux 和 Mac OS 上，使用了一个提供异步命名管道通信方式的 socketpair()。
每个渲染进程的消息会被序列化地到一个专用的 I/O 线程中，而后再由它发到内核进程。
在接收端，内核进程提供一个过滤接口(filter interface)用于解析资源相关的 IPC 请求(ResourceMessageFilter), 这部分就是网络模块负责的。

这样作其中一个好处是全部的资源请求都由 I/O 进程处理，不管是 UI 产生的活动，或者网络事件触发的交互。
在内核进程(browser/kernel process)的 I/O 线程解析资源请求消息，将转发到一个 ResourceDispatcherHost 的单例(singleton)对象中处理。

这个单例接口容许浏览器控制每一个渲染进程对网络的访问，也能达到有效和一致的资源共享：

• Socket pool 和 connection limits: 浏览器能够限定每个 profile 打开 256 个 sockets, 每一个 proxy 打开 32 个 sockets, 而每一组{scheme, host, port}能够打开 6 个。注意同时针对一组{host,port}最多允计打开 6 个 HTTP 和 6 个 HTTPS 链接。
• Socket reuse: 在 Socket Pool 中提供持久可用的 TCP connections，以供复用。这样能够为新的链接避免额外创建 DNS、TCP 和 SSL (若是须要的话)所花费的时间。
• Socket late-binding(延迟绑定): 网络请求老是当 Scoket 准备好发送数据时才与一个 TCP 链接关连起来，因此首先有机会作到对请求有效分级(prioritization)，好比，在 socket 链接过程当中可能会到达到一个更高优先级的请求。同时也能够有更好的吞吐率(throughput),好比，在链接打开过程当中，去复用一个恰好 可用的 socket, 就可使用到一个彻底可用的 TCP 链接。其实传统的 TCP pre-connect(预链接)及其它大量的优化方法也是这个效果。
• Consistent session state(一致的会话状态): 受权、cookies 及缓存数据会在全部渲染进程间共享。
• Global resource and network optimizations(全局资源和网络优化): 浏览器可以在全部渲染进程和未处理的请求间作更优的决策。好比给当前 tab 对应的请求以更好的优先级。
• Predictive optimizations（预测优化）: 经过监控网络活动，Chrome 会创建并持续改善预测模型来提高性能。
• … 项目还在增长中。

单就一个渲染进程而言, 透过 IPC 发送资源请求很容易，只要告诉浏览器内核进程一个惟一 ID, 后面就交给内核进程处理了。

2.3 跨平台的资源加载

跨平台也是 Chrome 网络模块的一个主要考量，包括 Linux, Windows, OS X, Chrome OS, Android 和 iOS。 为此，网络模块尽可能实现成了单进程模式（只分出了独立的cache和proxy进程）的跨平台函数库, 这样就能够在平台间共用基础组件(infrastructure)并分享相同的性能优化，更有机会作到同时为全部平台进行优化。

相关的代码能够在这里找到the “src/net” subdirectory)。本文不会详细展开每一个组件，不过了解一下代码结构能够帮助咱们理解它的能力结构。 好比:

• net/android 绑定到 Android 运行时(runtime) [译注(Horky)：运行时真是一个很烂的术语，翻和没翻同样。]
• net/base 公共的网络工具函数。好比主机解析， cookies，网络转换侦测(network change detection)，以及 SSL 认证管理
• net/cookies 实现了 Cookie 的存储、管理及获取
• net/disk_cache 磁盘和内存缓存的实现
• net/dns 实现了一个异步的 DNS 解析器(DNS resolver)
• net/http 实现了 HTTP 协议
• net/proxy 代理(SOCKS 和 HTTP)配置、解析(resolution) 、脚本抓取(script fetching), …
• net/socket TCP sockets，SSL streams 和 socket pools 的跨平台实现
• net/spdy 实现了 SPDY 协议
• net/url_request URLRequest, URLRequestContext 和 URLRequestJob 的实现
• net/websockets 实现了 WebSockets 协议

上面每一项都值得好好读读，代码组织的很好，你还会发现大量的单元测试。

2.4 Mobile 平台上的架构和性能

移动浏览器正在大发展，Chrome 团队也视优化移动端的体验为最高优先级。
先要说明的是移动版的 Chrome 的并非其桌面版本的直接移植，由于那样根本不会带来好的用户体验。
移动端的先天特性就决定了它是一个资源严重受限的环境，在运行参数有一些基本的不一样:

• 桌面用户使用鼠标操做，能够有重叠的窗口，大的屏幕，也不用担忧电池。网络也很是稳定，有大量的存储空间和内存。
• 移动端的用户则是触摸和手势操做，屏幕小，电池电量有限，经过只能用龟速且昂贵的网络，存储空间和内存也是至关受限。

再者，不但没有典型的样板移动设备，反而是有一大批各色硬件的设备。
Chrome 要作的，只能是设法兼容这些设备。
好在 Chrome 有不一样的运行模式(execution models)，面对这些问题，游刃有余！

在 Android 版本上，Chrome 一样运用了桌面版本的多进程架构。
一个浏览器内核进程，以及一个或多个渲染进程。
但由于内存的限制，移动版的 Chrome 没法为每个 tabl 运行一个特定的渲染进程，而是根据内存状况等条件决定一个最佳的渲染进程个数，而后就会在多个 tab 间共享这些渲染进程。

若是内存实在不足，或其它缘由致使 Chrome 没法运行多进程，它就会切到单进程、多线程的模式。
好比在 iOS 设备上，由于其沙箱机制的限制，Chrome 只能运行在这种模式下。

关于网络性能，首先 Chrome 在 Android 和 iOS 使用的是 各其它平台相同的网络模块。
这能够作到跨平台的网络优化，这也是 Chrome 明显领先的优点之一。
所不一样的是须要常常根据网络状况和设备能力进行些调整， 包括推测优化(speculative optimization)的优先级、socket 的超时设置和管理逻辑、缓存大小等。

好比，为了延长电池寿命，移动端的 Chrome 会倾向于延迟关闭空闲的 sockets (lazy closing of idle sockets), 一般是为了减小信号(radio)的使用而在打开新的 socket 时关闭旧的。
另外由于预渲染(pre-rendering，稍后会介绍)会使用必定的网络和处理资源，它一般只在 WiFi 才会使用。

关于移动浏览体验会独立一章，也许就在 POSA 系列的下一期。

2.5 Chrome Predictor 的预测功能优化

Chrome会随着使用变得更快。
它这个特性是经过一个单例对象 Predictor 来实现的。
这个对象在浏览器内核进程(Browser Kernel Process)中实例化，它惟一的职责就是观察和学习当前网络活动方式，提早预估用户下一步的操做。

下面是一个示例：

• 用户将鼠标停留在一个连接上，就预示着一个用户的偏好以及下一步的浏览行为。这时 Chrome 就能够提早进行 DNS Lookup 及 TCP 握手。用户的点击操做平均须要将近 200ms，在这个时间就可能处理完 DNS 和 TCP 相关的操做, 也就是省去几百毫秒的延迟时间。
• 当在地址栏(Omnibox/URL bar) 触发高可能性选项时，就一样会触发一个 DNS lookup 和 TCP 预链接(pre-connect)，甚至在一个不可见的页签中进行预渲染(pre-render)!
• 咱们每一个人都一串每天会访问的网站, Chrome 会研究在这些页面上的子资源, 而且尝试进行预解析(pre-resolve), 甚至可能会进行预加载(pre-fetch)以优化浏览体验。

除了上面三项，还有不少..

Chrome 会在你使用过程当中学习 Web 的拓扑结构，而不仅仅是你的浏览模式。
理想的话，它将为你省去数百毫秒的延迟，更接近于即时页面加载的状态。
正是为了这个目标，Chrome 投入了如下的核心优化技术:

• DNS 预解析(pre-resolve)：提早解析主机地址，以减小 DNS 延迟
• TCP 预链接(pre-connect)：提早链接到目标服务器，以减小 TCP 握手延迟
• 资源预加载(prefetching)：提早加载页面的核心资源，以加载页面显示
• 页面预渲染(prerendering)：提早获取整个页面和相关子资源，这样能够作到及时显示

每个决策都包含着一个或多个的优化，用来克服大量的限制因素。
不过毕竟都只是预测性的优化策略，若是效果不理想，就会引入多余的处理和网络传输。
甚至可能会带来一些加载时间上的负体验。

Chrome 如何处理这些问题呢?
Predictor 会尽可能收集各类信息，诸如用户操做，历史浏览数据，以及来自渲染引擎(render)和网络模块自身的信息。

和 Chrome 中负责网络事务调度的 ResourceDispatcherHost 不一样，Predictor 对象会针对用户和网络事务建立一组过滤器(filter):

• IPC channel filter 用来监控来自 render 进程的事务。
• 每一个请求上都会加一个 ConnectInterceptor 对象，这样就能够跟踪网络传输的模式以及每个请求的度量数据。

渲染进程(render process)会在一系列的事件下发送消息到浏览器进程(browser process), 这些事件被定义在一个枚举(ResolutionMotivation)中以便于使用 (url_info.h):

enum ResolutionMotivation {
    MOUSE_OVER_MOTIVATED,     // 鼠标悬停.
    OMNIBOX_MOTIVATED,        // Omni-box建议进行解析.
    STARTUP_LIST_MOTIVATED,   // 这是在前10个启动项中的资源.
    EARLY_LOAD_MOTIVATED,     // 有时须要使用prefetched来提早创建链接.

    // 下面定义了预加载评估的方式，会由一个navigation变量指定.
    // referring_url_也须要同时指定.
    STATIC_REFERAL_MOTIVATED,  // 外部数据库(External Database)建议进行解析。
    LEARNED_REFERAL_MOTIVATED, // 前一次浏览(prior navigation建议进行解析.
    SELF_REFERAL_MOTIVATED,    // 猜想下一个链接是否是须要进行解析.

    // <略> ...
};

经过这些给定的事件，Predictor 的目标就能够评估它成功的可能性, 而后再适时触发操做。
每一项事件都有其成功的机率、优先级以及时间戳，这些能够在内部维护一个用优先级管理的队列，也是优化的一个手段。
最终，对于这个队 列中发出的每个请求的成功率，均可以被 Predictor 追踪到。
基于这些数据，Predictor 就能够进一步优化它的决策。

2.6 Chrome网络架构小结

• Chrome 使用多进程架构，将渲染进程同浏览器进程隔离开来。
• Chrome 维护着一个资源分发器的实例(a single instance of the resource dispatcher), 它运行在浏览器内核进程，并在各个渲染进程间共享。
• 网络层是跨平台的，大部分状况下以单进程库存在。
• 网络层使用非阻塞式(no-blocking)操做来管理全部网络任务。
• 共享的网络层支持有效的资源排序、复用、并为浏览器提供在多进程间进行全局优化的能力。
• 每个渲染进程经过IPC和资源分发器(resource dispatcher)通信。
• 资源分发器(Resource dispatcher)经过自定义的 IPC Filter 解析资源请求。
• Predictor 在解析资源请求和响应网络事务中学习，并对后续的网络请求进行优化。
• Predictor 会根据学习到的网络事务模式预测性的进行 DNS 解析, TCP 握手，甚至是资源请求，为用户实际操做时节省数百毫秒的时间。

了解晦涩的内部细节后，让咱们来看一下用户能够感觉到的优化。
一切从全新的 Chrome 开始。

3、优化冷启动(Cold-Boot)体验

第一次启动浏览器，它固然不可能了解你的使用习惯和喜欢的页面。
但事实上，咱们大多数会在浏览器的冷启动后作些相似的事情，好比到电子邮箱查看邮件，加一些新闻页面、社交页面及内部 页面到个人最爱，诸如此类。
这些页面各有不一样，但它们仍然具备一些类似性，因此 Predictor 仍然能够对这个过程提速。

Chrome 记下了用户在全新启动浏览器时最经常使用的 10 个域名。
当浏览器启动时，Chrome 会提早对这些域名进行 DNS 预解析。
你能够在 Chrome 中使用 chrome://dns 查看到这个列表。
在打开页面的最上面的表格中会列出启动时的备选域名列表。

3.1 经过Omnibox优化与用户的交互

引入 Omnibox 是 Chrome 的一项创新, 并非简单地处理目标的 URL。
除了记录以前访问过的页面 URL，它还与搜索引擎的整合，而且支持在历史记录中进行全文搜索(好比，直接输入页面名称)。

当用户输入时，Omnibox 自动发起一个行为，要么查找浏览记录中的 URL, 要么进行一次搜索。
每一次发起的操做都会被加以评分，以统计它的性能。
你能够在 Chrome 输入 chrome://predictors 来观察这些数据。

Chrome 维护着一个历史记录，内容包括用户输入的前置文字，采用的行为，以命中的资数。在上面的列表，你能够看到，当输入 g 时，有 76% 的机会尝试打开 Gmail. 若是再补充一个 m (就是 gm), 打开 Gmail 的可能性增长到 99.8%。

那么网络模块会作什么呢？
上表中的黄色和绿色对于 ResourceDispatcher 很是重要。
若是有一个通常可能性的页面(黄色), Chrome 就是发起 DNS 预解析。
若是有一个高可能性的页面(绿色)，Chrome 还会在 DNS 解析后发起 TCP 预链接。
若是这两项都完成了，用户仍然继续录入，Chrome 就会在一个隐藏的页签进行预渲染(pre-render)。

相对的，若是输入的前置文字找不到合适的匹配项目，Chrome 会向搜索引擎服务者发起 DNS 预解析和 TCP 预连，以获取类似的搜索结果。

平均而言用户从填写查询内容到评估给出的建议须要花费数百毫秒。此时 Chrome 能够在后台进行预解析，预链接，甚至进行预渲染。
再当用户准备按下回车键时，大量的网络延迟已经被提早处理掉了。

3.2 优化缓存性能

最快的请求就是没有请求。
不管什么时候讨论性能，都不能不谈缓存。
相信你已经为页面上全部资源的都提供了 Expires, ETag, Last-Modified 和 Cache-Control 这些响应头信息(response headers)。
什么? 尚未？那你仍是先处理好再来看吧!

Chrome 有两种不一样的内部缓存的实现：一种备份于本地磁盘(local disk)，另外一种则存储于内存(in-memory)中。
内存模式(in-memory)主要应用于无痕浏览模式(Incognito browsing mode)，并在关闭窗口清除掉。
两种方式使用了相同的内部接口(disk_cache::Backend 和 disk_cache::Entry)，大大简化了系统架构。
若是你想实现一个本身的缓存算法，能够很容易地实现进去。

在内部，磁盘缓存(disk cache)实现了它本身的一组数据结构, 它们被存储在一个单独的缓存目录里。
其中有索引文件(在浏览器启动时加载到内存中)，数据文件(存储着实际数据，以及 HTTP 头以及其它信息)。
比较有趣的是，16KB 如下的文件存储于共同的数据块文件中(data block-files，即小文件集中存储于一个大文件中)，其它较大的文件才会存储到本身专属的文件中。
最后，磁盘缓存的淘汰策略是维护一个 LRU，经过好比访问频率和资源的使用时间(age)的度量进行管理。

在 Chrome 开个页签，输入 chrome://net-internals/#httpCache。
若是你要看到实际的 HTTP 数据和缓存的响应处理，能够打开 chrome://cache， 里面会列出全部缓存中可用的资源。
打开每一项，还能够看到详细的数据头等信息。

3.3 优化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 执行相应的优化决策。

除了内部事件通知外，页面设计者能够在页面中嵌入以下的语句请求浏览器进行预解析：

<link rel="dns-prefetch" href="//host_name_to_prefetch.com">

之因此有这个需求，一个典型的例子是重定向(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 解析器。

这个新技术能够支持如下优化:

• 更好地控制重转的时机，有能力并行执行多个查询操做。 清晰地记录TTLs。
• 更好地处理 IPv4 和 IPv6 的兼容。
• 基于 RTT 和其它事件，针对不一样服务器进行错误处理(failover)

Chrome 仍然进行着持续的优化。经过 chrome://histograms/DNS 能够观察到 DNS 度量数据：

上面的柱状图展现了 DNS 预解析延迟时间的分布：好比将近 50% (最右侧)的查询在 20ms 内完成。
这些数据基于最近的浏览操做(采样 9869 次)，用户能够选择是否报告这些使用数据，而后这些数据会以匿名的形式交由工程团队加以分析，这样就能够了解到功能的性能，以及将来如何进一步调整。
周而复始，不断优化。

3.4 使用预链接优化了 TCP 链接管理

已经预解析到了主机名，也有了由 OmniBox 和 Chrome Predictor 提供信号，预示着用户将来的操做。
为何再进一步链接到目标主机，在用户真正发起请求前完成 TCP 握手呢？
这样就可省掉了另外一个往返的延迟，轻易地就能为用户节省到上百毫秒。
其实，这就是 TCP 预链接的工做。
经过访问 chrome://dns 就能够看到 TCP 预链接的使用状况。

首先，Chrome 检查它的 socket pool 里有没有目标主机能够复用的 socket， 这些 sockets 会在 socket pool 里保留一段时间，以节省 TCP 握手时间及启动延时(slow-start penalty)。
若是没有可用的 socket，就须要发起 TCP 握手，而后放到 socket pool 中。
这样当用户发起请求时，就能够用这个 socket 当即发起 HTTP 请求。

打开 chrome://net-internals#sockets 就能够看到当前的 sockets 的状态:

你能够看到每个 socket 的时间轴：链接和代理的时间，每一个封包到达的时间，以及其它一些信息。
你也能够把这些数据导出，以方便进一步分析或者报告问题。
有好的测试数据是优化的基础, chrome://net-internals 就是 Chrome 网络的信息中心。

使用预加载优化资源加载

Chrome 支持在页面的 HTML 标签中加入的两个线索来优化资源加载:

<link rel="subresource" href="/javascript/myapp.js">
<link rel="prefetch"    href="/images/big.jpeg">

在 rel 中指定的 subresource(子资源)和 prefetch(预加载)很是类似。
不一样的是，若是一个 link 指定 rel(relation) 为 prefetch 后，就是告诉浏览器这个资源是稍后的页面中要用到的。
而指定为 subresource 则表示在本页中就会用到，指望能在使用前加载。
二者不一样的语义让 resource loader 有不一样的行为。
prefetch 的优先级较低，通常只会在页面加载完成后才会开始。
而 subresource 则会在解析出来时就被尝试优先执行。

还要注意，prefetch 是 HTML5 的一部分，Firefox 和 Chrome 均可以支持。
但 subresource 还只能用在 Chrome 中。

3.5 应用 Browser Prefreshing 优化资源加载

不过，并非全部的 Web 开发者会愿意加入上面所述的 subresource relation，就算加了，也要等收到主文档并解析出这些内容才行，这段时间开销依赖于服务器的响应时间和客户端与服务器间的延迟时间，甚至要耗去上千毫秒。

和前面的预解析，预链接同样，这里还有一个 prefreshing::

• 用户初始化一个目标页面的请求。
• Chrome 查询 Predictor 以前针对目标页面的子资源加载，初始化一组 DNS 预解析，TCP 预链接及资源 prefreshing。
• 如是在缓存中发现以前记录的子资源，由从磁盘中加载到内存中。
• 若是没有或者已通过期了，就是发送网络请求。

直到在 2013 年初, prefreshing 仍是处于早期的讨论阶段。
若是经过数据结果分析，这个功能最终上线了，咱们就能够稍晚些时候使用到它了。

3.6 使用预渲染优化页面浏览

前面讨论的每一个优化都用来帮助减小用户发起请求到看到页面内容的延迟时间。
多快才能带来即时呈现的体验呢？
基于用户体验数据，这个时间是 100 毫秒，根本没给网络延迟留什么空间。
而在 100 毫秒内，又怎样渲染页面呢？

你们可能都有这样的体验: 同时开多个页签时会明显快于在一个页签中等待。
浏览器为此提供了一个实现方式:

<link rel="prerender" href="http://example.org/index.html">

这就是 Chrome 的预渲染(prerendering in Chrome)! 相对于只下载一个资源的“prefetch”, “prerender”会让 Chrome 在一个不可见的页签中渲染一个页面,包含了它全部的子资源。
当用户要浏览它时，这个页签被切到前台，作到了即时的体验。

能够浏览 prerender-test.appspot.com 来体验一下效果，再经过 chrome://net-internals/#prerender 查看下历史记录和预链接页面的状态。

由于预渲染会同时消耗 CPU 和网络资源，因些必定要在确信预渲染页面会被使用到状况下才用。
Google Search 就在它的搜索结果里加入 prerender, 由于第一个搜索结果极可能就是下一个页面(也叫做Google Instant Pages)

你可使用预渲染特性，但如下限制项必定要牢记:

• 全部的进程中最多只能有一个预渲染页。
• HTTPS 和带有 HTTP 认证的页面不能够预渲染。
• 若是请求资源须要发起非幂等（non-idempotent,idempotent request 的意义为发起屡次，不会带来服务的负面响应的请求)的请求(只有GET请求)时，预渲染也不可用。
• 全部的资源的优先级都很低。
• 页面渲染进程的使用最低的 CPU 优先级。
• 若是须要超过 100MB 的内存，将没法使用预渲染。
• 不支持 HTML5 多媒体元素。

预渲染只能应用于确信安全的页面。
另外 JavaScript 也最好在运行时使用Page Visibility API来判断一下当前页是否可见(参考 you should be doing anyway) !

最后，总之，Chrome 正逐步优化网络延迟和用户体验，让它随着用户的使用愈来愈快！

---

Ilya Grigorik is a web performance engineer and developer advocate on the Make The Web Fast team at Google, where he spends his days and nights on making the web fast and driving adoption of performance best practices.

Follow @igrigorik

文章来源：UC技术博客