为什么谷歌浏览器比其它浏览器好用？

对于一个网络资源的URL，浏览器首先会检查其本地缓存和应用程序缓存。如果你此前获取过该资源，并且提供了适当的缓存标头（Expires, Cache-Control等），则我们可能被允许使用本地副本来响应原请求——最快的请求就是不请求。或者，如果我们需要重新校验该资源（如果资源已过期），或是我们根本从未获取过该资源，那么就必须发起一个高开销的网络请求。

有了主机名称和资源路径，Chrome首先检查现有的已开启连接中是否有可以重用的——socket按照{scheme, host, port}的格式储存在池中。或者，如果你已经配置了代理，或指定了代理自动配置脚本（PAC），那么Chrome就会通过适当的代理来检查连接。PAC脚本允许基于URL的不同代理或其他指定规则，它们都可以有自己的socket池。最后，如果上述条件都不满足，则请求必须通过将主机名解析为IP地址的方式发起，也称为DNS查询。

如果幸运的话，主机名可能已经在缓存当中了，此时通常只需要一次快速的系统调用就得到响应。如若不然，就必须调度一个DNS查询才能继续下去。DNS查询耗费的时间由网络提供商、站点的热门程度、主机名可能存在过渡缓存中的概率以及该域名的权威服务器的响应时间所决定。换句话说，影响变量有很多，但是耗费数百毫秒来进行一次DNS查询也并非罕见。天啊。

图1.2 三次握手

得到了解析后的IP地址，Chrome现在可以打开一个新的与目标站点的TCP连接，这意味着我们需要进行“三次握手”：SYN > SYN-ACK > ACK。这一交换过程又为每个新的TCP连接增加了一个往返延迟——此处没有捷径可走。根据客户端与服务器的距离和所选定的路由路径不同，这可能产生几十、几百甚至几千毫秒的延迟。这些工作和延迟是甚至还没有一个字节的应用程序数据开始传输之前就发生的。

完成了TCP握手之后，如果我们连接的是安全站点（HTTPS），那么还要进行SSL握手。这又增加了客户端和服务器之间两个往返延迟。如果SSL会话进行了缓存，那么可以“免去”其中一次额外的往返延迟。

最后，Chrome要调度HTTP请求（图1.1中requestStart）。服务器接收到请求之后，会处理该请求，然后通过数据流把响应数据返给客户端。这至少会产生一个往返延迟，还要算上服务器的处理时间。正常情况下这样就结束了，但如果真正的响应是一个HTTP重定向，那么我们可能还需要把整个过程再重走一遍。你的页面上有不必要的重定向吗？那你可能需要重新考虑这个决定了。

你算过这所有的延迟时间了吗？为了便于说明问题，我们假设一个典型的宽带连接的最坏情况：没有本地缓存、相对较快的DNS查询速度（50ms）、TCP握手、SSL协商、相对较快的服务器响应时间（100ms）、80ms的往返延迟（这是美国大陆往返延迟的平均时间）：

DNS需要50ms

TCP握手需要80ms（一次往返延迟）

SSL握手需要160ms（两次往返延迟）

请求传输到服务器需要40ms

服务器处理需要100ms

服务器返回响应需要40ms

这样算下来，单次请求需要470毫秒，与服务器真正处理请求的时间相比，其中80%都是网络延迟开销。实际上，470毫秒都算是一个乐观的估计了：

如果服务器响应不匹配初始的TCP拥塞窗口（4-15KB），还会额外产生一个或多个往返延迟。【注1】

如果我们需要获取缺失证书或者需要执行在线证书状态检查（OCSP），SSL延迟得还会更厉害，因为这两种情况都需要一次全新的TCP连接，这又增加了成百上千毫秒的额外延迟。

“足够快”有多快？

DNS、握手、往返延迟的网络开销是决定前例中总时间的因素——服务器响应时间仅占总延迟的20%。但是，从大局看，这些延迟重要吗？如果你正在阅读本文，你很可能已经知道了答案：不但有影响，而且影响很大。

过去一些用户体验的研究描述了我们作为用户对应用程序（在线或离线）的响应速度作何预期：

表1.1 用户对延迟的感知

表1.1还能够解释网络性能领域中一条不成文的经验法则：如果不能直接呈现页面，至少也要在250毫秒以内提供视觉上的反馈以保持用户不会失去兴趣。其他因素也会影响速度。对Google、Amazon、Microsoft和数千个其他站点的研究显示，额外的延迟会直接影响站点的获利能力：速度快的网站能生成更多的页面请求，用户参与度也更高，从而转化率也更高。

所以，我们知道了，最佳的延迟应该控制在250毫秒，但我们在前例中看到，DNS查询、TCP和SSL握手再加上请求传递的时间总共有370毫秒。我们已经超出50%了，这还是我们没算上服务器处理时间的情况！

对于大多数用户乃至一些网络开发者来说，DNS、TCP和SSL的延迟是完全透明的（无须关心的），它们是在网络层协商的，而我们极少深入到甚至不会去想这个层面的事。但是，这其中的每一步对整体用户体验都是非常关键的，因为每增加额外的网络请求都会增加几十或几百毫秒的延迟。这就是为什么Chrome的网络栈要比一个简单的socket处理器复杂的多得多。

找到了症结所在，我们继续来看一些实现细节。

Chrome的网络栈概览

多进程架构

Chrome的多进程架构对各个网络请求如何在浏览器中进行处理具有重大影响。在底层，Chrome实际上支持四种不同的执行模型用于确定如何进行进程的分配。

默认情况下，桌面上的Chrome浏览器使用“站点对应进程”模型，将不同站点隔离开来，而把同一站点的所有实例分组在同一进程中。不过为了简便起见，我们假设最简单的情况：每个打开的标签页对应一个单独的进程。从网络性能的角度看，这种差别并不重要，但“标签页对应进程”模型要容易理解得多。

图1.3 多进程架构

这个架构为每个标签页配给一个专用的呈现进程。每个呈现进程包含Blink布局引擎和V8 JavaScript引擎，配合上一些胶水代码把这几个部分（再加上其他一些部分）联系起来。【注2】

这些呈现进程的每一个都在一个沙盒环境内执行，这个环境对用户计算机——包括网络，只有有限的访问权限。要获得访问这些资源的权限，每个呈现进程要与主浏览器进程（或称为内核进程）进行通信，由内核进程负责管理每个呈现器的安全和权限策略。

进程间通信和多进程资源加载

Chrome中呈现器和内核进程之间的所有通信都是通过进程间通信（IPC）完成的。在Linux和OS X上使用的是socketpair，这个方法提供一个命名的管道传输进行异步通信。来自呈现器的每条消息经过序列化处理再传给专用的I/O线程，再由它将其派发给主浏览器进程。在接收端，内核进程提供一个过滤接口，允许Chrome拦截应该由网络栈处理的资源IPC请求（参见ResourceMessageFilter），

图1.4 进程间通信