使用预连接优化了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标签中加入的两个线索来优化资源加载: 在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还是处于早期的讨论阶段。如果通过数据结果分析，这个功能最终上线了，我们就可以稍晚些时候使用到它了。 |
