从输入 URL 到页面加载完的过程当中都发生了什么事情

时间 2019-11-18

标签输入 url 页面加载过程当中发生了什么事情栏目 HTTP/TCP 繁體版

原文原文链接

本身总结：html

0.浏览器优化

0.1 智能匹配，DNS预取：输入w时已经把weibo.com的DNS预取了

1. 浏览器查找域名的ip

1.1 查看缓存

浏览器缓存、hosts文件

1.2 DNS服务器递归查询

1.3 负载均衡-将域名导向不一样ip，分给不一样的服务器

2. 创建TCP链接

2.1 三次握手：SYN, SYN+ACK, ACK

2.2 TCP包封装到网络层的 ip包，再被封装到数据链路层的数据帧，再封装成物理层的 比特流发送出去。

2.3 TCP流量控制(滑动窗口)、拥塞控制（慢开始、拥塞避免、快重传、快恢复）

3. 发送HTTP请求

GET HTTP 1.0

4. 接收HTTP响应，检查 HTTP header 里的状态码，并作出不一样的处理方式

http状态码

2xx：成功。这一类型的状态码，表明请求已成功被服务器接收、理解、并接受。

3xx：重定向。这类状态码表明须要客户端采起进一步的操做才能完成请求。一般，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。

4xx：客户端错误。这类的状态码表明了客户端看起来可能发生了错误，妨碍了服务器的处理。

5xx：服务器错误。这类状态码表明了服务器在处理请求的过程当中有错误或者异常状态发生。

5. 浏览器进行解码响应

处理压缩的数据，浏览器渲染

============================================================================================================web

www.itbbu.com/1490.html面试

Cachechrome

一个HTTP请求的过程

为了简化咱们先从一个HTTP请求开始，简要介绍一下一个HTTP求情的网络传输过程，也就是所谓的“从输入 URL 到页面下载完的过程当中都发生了什么事情”数据库

DNS Lookup 先得到URL对应的IP地址浏览器
Socket Connect 浏览器和服务器创建TCP链接缓存
Send Request 发送HTTP请求性能优化
Content Download 服务器发送响应服务器

若是下到物理层去讲就有点耍流氓了，若是这些你还承认这几个步骤的话，咱们就来说一下这里面存在的性能问题。网络

若是你对DNS的查询还有印象的话如今反思一下，DNS Lookup就是为了获取一串IP地址要和无数个DNS服务器进行通讯，这要消耗多少时间？别忘了你查询完了的时候你还没和那边的服务器通讯呢。
TCP链接要三次握手，若是服务器很远的话这三次握手要花多少时间？别忘了创建链接以后你还没发请求呢。（一般到这里0.5秒就出去了）
发送HTTP请求的时候你要知道一点就是咱们的网络带宽上行和下行一般是不同的，一般上行的带宽会小一些，一个的话还好，可是如今的网页一般都会后续请求不少资源，带宽小的时候上行拥塞怎么办？别忘了已经到第三步了，服务器还没给你发响应呢，如今你的浏览器还什么都画不出来。
终于到了服务器发响应了，不巧你访问的这个服务器比较忙，好几万我的都要这个资源，服务器的上行带宽也是有限的，怎么办？

我以为我出了几道还不错的面试题。顺便提一下，前两步的延迟和网络带宽的影响不大；后两步加带宽是能必定程度缓解，不过你要有钱，并且很贵。虽然说博主作过Webkit本地渲染的优化，可是深知网页加载的主要时间仍是浪费在网络通讯上，因此在这些步骤上的优化会比你在浏览器内核的优化省力且效果明显。

网络方面的主要优化手段，博主总结一下不外乎缓存，预取，压缩，并行。之后若是再有面试问性能优化之类的问题，你们均可以照着这个思路去考虑，下面就分阶段介绍一下现有的优化手段。

DNS 优化

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

浏览器DNS缓存，chrome能够看 chrome://net-internals/#dns
系统DNS缓存
hosts文件，墙里的小伙伴们应该有印象

canada erectile dysfunction prednisolone online singapore http://boontaran.com/ypg/cialis-prescription-in-houston/ one day delivery tadalafil doxycycline no presecription
各个DNS服务器上的缓存

固然DNS缓存失效期一般都比较短，不少状况下都要再去查找，为了下降用户体验到的延迟（注意这里不是网络延时）预取是一个不错的方法。好比说你敲网址的时候尚未敲完，可是浏览器根据你的历史发现你颇有可能去访问哪一个网站就提早给你作dns预取了，好比你打了一个“w”的时候，chrome已经帮你去找weibo.com的ip地址了。chrome用户能够看一下 chrome://predictors/ 你就知道了。

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

TCP 优化

看到前面的DNS的具体优化这么繁杂，知道这简单的一步没那么简单了吧。结果到TCP这一步优化反而简单了，由于刚才dns已经把ip都预先弄到了那么咱们顺着刚才的步骤再创建链接就行了。因此在你敲第一个字母的时候dns解析完了就去创建链接了，这时候你可能网址还没敲完。当你刚访问一个网站的时候浏览器刷刷刷的帮你把到别的服务器的TCP链接给你建好。

HTTP传输优化

写到这里可能有人会想，既然已经把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中看到，具体的就不细说了。

将来协议 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链接断开的状况仍是比较常见的。不过做为一个将来的技术仍是有必要关注一下。

============================================================================================================

In an extremely rough and simplified sketch, assuming the simplest possible HTTP request, no proxies and IPv4 (this would work similarly for IPv6-only client, but I have yet to see such workstation):

browser checks cache; if requested object is in cache and is fresh, skip to #9
browser asks OS for server's IP address
OS makes a DNS lookup and replies the IP address to the browser
browser opens a TCP connection to server (this step is much more complex with HTTPS)
browser sends the HTTP request through TCP connection
browser receives HTTP response and may close the TCP connection, or reuse it for another request
browser checks if the response is a redirect (3xx result status codes), authorization request (401), error (4xx and 5xx), etc.; these are handled differently from normal responses (2xx)
if cacheable, response is stored in cache
browser decodes response (e.g. if it's gzipped)
browser determines what to do with response (e.g. is it a HTML page, is it an image, is it a sound clip?)
browser renders response, or offers a download dialog for unrecognized types

Again, discussion of each of these points have filled countless pages; take this as a starting point. Also, there are many other things happening in parallel to this (processing typed-in address, adding page to browser history, displaying progress to user, notifying plugins and extensions, rendering the page while it's downloading, pipelining, connection tracking for keep-alive, etc.).

ref: http://stackoverflow.com/questions/2092527/what-happens-when-you-type-in-a-url-in-browser

============================================================================================================

http://www.cnblogs.com/wenanry/archive/2010/02/25/1673368.html

http://zrj.me/archives/tag/%E4%BB%8E%E7%82%B9%E5%87%BB%E5%88%B0%E5%91%88%E7%8E%B0 写的很详细。

http://zhi.hu/f0Is

http://www.xyduan.net/what-happened-when-you-visit-taobao/

http://www.guokr.com/question/554991/

http://www.w3cfuns.com/blog-5463539-5405103.html