Google Chrome中的高性能网络 (三)

使用预连接优化了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 中。

应用Browser Prefreshing优化资源加载

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

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

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

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

使用预渲染优化页面浏览

前面讨论的每个优化都用来帮助减少用户发起请求到看到页面内容的延迟时间。多快才能带来即时呈现的体验呢？基于用户体验数据，这个时间是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

[译注]终于翻完了，在这个过程还是学习到不少东西，也期待着对大家有所启发。效果最好，当然还是看原文。以后也争取和作者原文一起更新。

转载请注明出处:http://blog.csdn.net/horkychen

这个系列的索引:

Google Chrome中的高性能网络(一)

Google Chrome中的高性能网络(二)

Google Chrome中的高性能网络(三)

完整的PDF档下载
原文地址: http://www.igvita.com/posa/high-performance-networking-in-google-chrome/

from:http://blog.csdn.net/horkychen/article/details/10878489