http://oilbeater.com/技术相关/2014/05/09/from-url-to-webpage.html -- 原博文，表示感谢！html
话说这些年来我最喜欢问的面试题是『从输入 URL 到页面加载完的过程当中都发生了什么事情？』，我的以为这道题很是很是难，既考深度又考广度，至今尚未人的回答让我满意，因此我想本身挑战一下，整理出一篇文章，有哪位大牛也想来一块儿挑战么？ @JS小组 @前端交流前端
想到这不就是我这两年来研究的东西么，因而就接受一下挑战。网上已经有不少版本的答案了好比这里和这里。这道题能够从浏览器端，网络传输和服务器端详细展开，每一部分均可以说上好几天，每一个人都能说上几句又不可能说全，因此说的方向和角度就很重要了。其中客户端和服务器端的工做已经有太多的人说了，本文来说一下中间部分的网络传输。但是网络传输部分相对来讲是比较简单的，有成文的规范和协议基本和背课文同样，本文就讲点带花的，讲一下现有针对网络的优化部分，以防止和别人雷同。web
为了简化咱们先从一个HTTP请求开始，简要介绍一下一个HTTP求情的网络传输过程，也就是所谓的“从输入 URL 到页面下载完的过程当中都发生了什么事情”面试
DNS Lookup 先得到URL对应的IP地址chrome
Socket Connect 浏览器和服务器创建TCP链接shell
Send Request 发送HTTP请求数据库
Content Download 服务器发送响应segmentfault
若是下到物理层去讲就有点耍流氓了，若是这些你还承认这几个步骤的话，咱们就来说一下这里面存在的性能问题。浏览器
若是你对DNS的查询还有印象的话如今反思一下，DNS Lookup就是为了获取一串IP地址要和无数个DNS服务器进行通讯，这要消耗多少时间？别忘了你查询完了的时候你还没和那边的服务器通讯呢。缓存
TCP链接要三次握手，若是服务器很远的话这三次握手要花多少时间？别忘了创建链接以后你还没发请求呢。（一般到这里0.5秒就出去了）
发送HTTP请求的时候你要知道一点就是咱们的网络带宽上行和下行一般是不同的，一般上行的带宽会小一些，一个的话还好，可是如今的网页一般都会后续请求不少资源，带宽小的时候上行拥塞怎么办？别忘了已经到第三步了，服务器还没给你发响应呢，如今你的浏览器还什么都画不出来。
终于到了服务器发响应了，不巧你访问的这个服务器比较忙，好几万我的都要这个资源，服务器的上行带宽也是有限的，怎么办？
我以为我出了几道还不错的面试题。顺便提一下，前两步的延迟和网络带宽的影响不大；后两步加带宽是能必定程度缓解，不过你要有钱，并且很贵。虽然说博主作过Webkit本地渲染的优化，可是深知网页加载的主要时间仍是浪费在网络通讯上，因此在这些步骤上的优化会比你在浏览器内核的优化省力且效果明显。
网络方面的主要优化手段，博主总结一下不外乎缓存，预取，压缩，并行。之后若是再有面试问性能优化之类的问题，你们均可以照着这个思路去考虑，下面就分阶段介绍一下现有的优化手段。
对于DNS优化，缓存无疑是最简单粗暴且效果明显的了。说到缓存就必定要提到缓存层级：
浏览器DNS缓存，chrome能够看 chrome://net-internals/#dns
系统DNS缓存
hosts文件，墙里的小伙伴们应该有印象
各个DNS服务器上的缓存
固然DNS缓存失效期一般都比较短，不少状况下都要再去查找，为了下降用户体验到的延迟（注意这里不是网络延时）预取是一个不错的方法。好比说你敲网址的时候尚未敲完，可是浏览器根据你的历史发现你颇有可能去访问哪一个网站就提早给你作dns预取了，好比你打了一个“w”的时候，chrome已经帮你去找weibo.com的ip地址了。chrome用户能够看一下 chrome://predictors/ 你就知道了。
此外浏览器还会记录你过去的历史知道每一个域名下一般还会有哪些其余的连接创建起网站的拓扑结构，当你访问这个域名下的网站他就会预先对其余连接的域名进行DNS解析能够参照 chrome://dns/。
看到前面的DNS的具体优化这么繁杂，知道这简单的一步没那么简单了吧。结果到TCP这一步优化反而简单了，由于刚才dns已经把ip都预先弄到了那么咱们顺着刚才的步骤再创建链接就行了。因此在你敲第一个字母的时候dns解析完了就去创建链接了，这时候你可能网址还没敲完。当你刚访问一个网站的时候浏览器刷刷刷的帮你把到别的服务器的TCP链接给你建好。
写到这里可能有人会想，既然已经把TCP链接创建好了，那我干脆预取更进一步，把全部的连接内容直接预取下来不就行了，这样我网址还没敲完网页就已经加载完成了。这个想法是好的，但现实倒是残酷的。由于要记住咱们的带宽是有限的，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之间加，也就是在路由器上加缓存。小米的路由器和搜狗合做的预取引擎其实就至关因而在路由器上加一层缓存款顺便智能预取一下。博主为何在这里另起一段专门谈小米呢，难不成是小米的水军？才不是呢，是由于博主看到这个消息的时候心都凉了，和博主的毕设撞车了有木有。去年在360刚出随身WiFi的时候博主想到了这么个点子，还想着把这个东西作出来以后用这个创业和360谈合做。结果最近刚作完，论文也投出去了，幻想着开启人生巅峰，颠覆行业结果就发现小米和搜狗出了这么个同样的东西还都商业化了。说好的人生巅峰就这样没有了，早知道去年就先申请个专利了。
另外一个HTTP经常使用的优化就是压缩了，网络传输时间 = 消息大小/网速 既然网速比较贵那么就压缩一下吧，大部分服务器都会对HTTP消息进行gzip压缩。能够在Http Header中看到，具体的就不细说了。
上面的都是传统作法，下面讲一个将来的技术。因为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链接断开的状况仍是比较常见的。不过做为一个将来的技术仍是有必要关注一下。
上面就是博主对”从输入 URL 到页面加载完的过程当中都发生了什么事情“两端之间网络链接这块所知道的事情还有优化措施，欢迎你们来拍砖。对于浏览器端到底作了些什么博主其实也很熟，只是这一块已经有不少成熟的资料了好比这里，这里和这里想写点不同的东西太难了。服务器端的事情博主就不是太清楚了，还请你们多多指教。