从URL到页面加载完成发生了什么——营养吸收

(1)http请求的网络传输过程

●DNS Lookup 先获得URL对应的IP地址（DNS服务器就像一个电话号码薄，根据你说的人名找到对应的号码）

●Socket Connect 浏览器和服务器建立TCP连接

●Send Request 发送HTTP请求

●Content Download 服务器发送响应

(2)优化

网页加载的主要时间还是浪费在网络通信上，所以在这些步骤上的优化会比在浏览器内核的优化(Webkit渲染)省力且效果明显。

DNS 优化

对于DNS优化，缓存无疑是最简单粗暴且效果明显的了。说到缓存就一定要提到缓存层级：

●浏览器DNS缓存，chrome可以看 chrome://net-internals/#dns

●系统DNS缓存

●hosts文件，墙里的小伙伴们应该有印象

●各个DNS服务器上的缓存

DNS缓存期通常都比较短，很多情况下都要再去查找，为了降低用户体验到的延迟，预取是一个不错的方法。

比如:网址没有敲完，但是浏览器根据你的历史发现你很有可能去访问哪个网站就提前给你做dns预取了，比如你打了一个“w”的时候，chrome直接baidu.com的ip地址了。chrome用户可以看一下 chrome://predictors/

此外浏览器还会记录你过去的历史知道每个域名下通常还会有哪些其他的链接建立起网站的拓扑结构，当你访问这个域名下的网站他就会预先对其他链接的域名进行DNS解析可以参照 chrome://dns/。

TCP 优化

刚才dns已经把ip都预先弄到了，那么我们顺着刚才的步骤再建立连接就好了。

所以在你敲第一个字母的时候dns解析完了就去建立连接了，这时候你可能网址还没敲完。当你刚访问一个网站的时候浏览器帮你把到别的服务器的TCP连接给你建好。

HTTP传输优化

我们的带宽是有限的，DNS和TCP连接量级都比较轻，对网络带宽不会占据太多，但是HTTP传输就不一样了如果你所有链接都去预取的话你的带宽很快就被占满了，这样你正常的请求无法得到满足，性能反而会严重下降。

缓存就又出现了，缓存层次结构：。

●PageCache（网页缓存） ，直接在内存中缓存现有网页的dom结构和渲染结果，这就是你为什么在点前进后退的时候会这么快。

●HTTP Cache 文件级别的Cache存在本地的文件系统上按照RFC2616实现。

●代理Cache 如果是通过代理服务器上网的话，代理服务器通常也会按照缓存标准

●CDN 一个地理上离你很近的内容服务器，比如说你在北京请求杭州淘宝的一个图片，结果在北京的一个CDN上有这个图片，那么就不用去杭州了。

●DMOC（distributed memory object caching system）CDN主要存放的是静态数据，但是网页中通常有很多动态的数据需要查数据库，流量多了压力就会很大，通常服务器外围还会有一层内存缓存服务器，专门缓存这些数据库中的对象，据《淘宝技术这10年》称可以减少99.5%的数据库访问。

●Server 其实真正落在服务器上的请求已经不多了。

可以在2和3之间加，也就是在路由器上加缓存。小米的路由器和搜狗合作的预取引擎其实就相当于是在路由器上加一层缓存款顺便智能预取一下。

另一个HTTP常用的优化就是压缩了，网络传输时间 = 消息大小/网速 既然网速比较贵那么就压缩一下吧，大部分服务器都会对HTTP消息进行gzip压缩。可以在Http Header中看到，具体的就不细说了。

未来协议 SPDY

由于HTTP协议是上个世纪制定的协议了，已经不能很好的适应现在Web的发展，所以Google提出了SPDY协议目前是指定中的HTTP2.0标准的一个底版。SPDY主要有下面的特点：

●一个TCP连接上并行多个HTTP连接，减少连接的建立时间

●请求优先级（目前还没看到具体实现）

●HTTP头部压缩，上文提到的HTTP压缩是对HTTP body的压缩，并没有对头部压缩。对于小的HTTP消息，头部的比重还是很大的，而现在的web中存在大量小消息。

●Server push/hint 服务器主动推送对象（可以想象成服务器帮客户端预取）

业界目前对SPDY是有赞有弹。主要在1和4上，4其实和之前提到的HTTP直接预取的矛盾点一样，万一推送的不需要又占据了带宽怎么办，hint到底该如何实现都有困难。第一条潜在的风险就是TCP连接中途断开，那么所有的连接就全部停掉了，PC互联网这种情况可能会少一些，但是移动互联网中TCP连接断开的情况还是比较常见的。不过作为一个未来的技术还是有必要关注一下。