参考 javascript
http://blog.csdn.net/wdzxl198/article/details/11265475php
http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/css
去百度面试了 没有回答的很好 😔
1.enter the url to the address bar
输入地址
2.a request will be sent to the DNS server based on your network configuration
DNS服务器解析IP
3.DNS will route you to the real IP of the domain name
DNS服务器路由到真实地址
4.a request(with complete Http header) will be sent to the server(with 3's IP to identify)'s 80 port(suppose we don't specify another port)
请求被提交给服务器的80端口
5.server will search the listening ports and forward the request to the app which is listening to 80 port(let's say nginx here) or to another server(then 3's server will be like a load balancer)
服务器查询监听端口,将请求提交给 web服务器 监听80端口 或者 负载均衡服务器(loader balancer)
6.nginx will try to match the url to its configuration and serve as an static page directly, or invoke the corresponding script intepreter(e.g PHP/Python) or other app to get the dynamic content(with DB query, or other logics)
web服务器 将请求的url 直接返回静态页面,或者触发相应的脚本语言好比php python 等 或者其余动态内容 好比数据库等等
7.a html will be sent back to browser with a complete Http response header
一个html 将会携带 返回头信息 返回个 浏览器(客户端)
8.browser will parse the DOM of html using its parser
浏览器将会将html DOM 进行解析
9.external resources(JS/CSS/images/flash/videos..) will be requested in sequence(or not?)
额外资源 JS/CSS/images/flash/video 将会以后在加载
10.for JS, it will be executed by JS engine
js 将会被js引擎执行
11.for CSS, it will be rendered by CSS engine and HTML's display will be adjusted based on the CSS(also in sequence or not?)
css 引擎解析渲染html
12.if there's an iframe in the DOM, then a separate same process will be executed from step 1-12
若是有单独的iframe 将会按照1-12 的顺序 继续下去
DNS 域名解析的流程
浏览器缓存域名->系统缓存域名(host等)->路由缓存域名->DNS缓存域名->DNS服务递归查询(顶级域名[.com/.org]->域名服务器[baidu])
问题:
DNS有一点使人担心,这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好,有几种方法能够消除这个瓶颈:html
大多数DNS服务器使用Anycast来得到高效低延迟的DNS查找。java
直接摘抄过来python
导航的第一步是经过访问的域名找出其IP地址。DNS查找过程以下:mysql
DNS递归查找以下图所示:nginx
DNS有一点使人担心,这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好,有几种方法能够消除这个瓶颈:web
大多数DNS服务器使用Anycast来得到高效低延迟的DNS查找。面试
由于像Facebook主页这样的动态页面,打开后在浏览器缓存中很快甚至立刻就会过时,毫无疑问他们不能从中读取。
因此,浏览器将把一下请求发送到Facebook所在的服务器:
GET 这个请求定义了要读取的URL: “http://facebook.com/”。 浏览器自身定义 (User-Agent 头), 和它但愿接受什么类型的相应 (Acceptand Accept-Encoding 头). Connection头要求服务器为了后边的请求不要关闭TCP链接。
请求中也包含浏览器存储的该域名的cookies。可能你已经知道,在不一样页面请求当中,cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登陆用户名,服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里,每次请求时发送给服务器。
用来看原始HTTP请求及其相应的工具不少。做者比较喜欢使用fiddler,固然也有像FireBug这样其余的工具。这些软件在网站优化时会帮上很大忙。
除了获取请求,还有一种是发送请求,它常在提交表单用到。发送请求经过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=85)。发送请求在请求正文头以后发送其参数。
像“http://facebook.com/”中的斜杠是相当重要的。这种状况下,浏览器能安全的添加斜杠。而像“http: //example.com/folderOrFile”这样的地址,由于浏览器不清楚folderOrFile究竟是文件夹仍是文件,因此不能自动添加 斜杠。这时,浏览器就不加斜杠直接访问地址,服务器会响应一个重定向,结果形成一次没必要要的握手。
图中所示为Facebook服务器发回给浏览器的响应:
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
服务器给浏览器响应一个301永久重定向响应,这样浏览器就会访问“http://www.facebook.com/” 而非“http://facebook.com/”。
为何服务器必定要重定向而不是直接发会用户想看的网页内容呢?这个问题有好多有意思的答案。
其中一个缘由跟搜索引擎排名有 关。你看,若是一个页面有两个地址,就像http://www.igoro.com/ 和http://igoro.com/,搜索引擎会认为它们是两个网站,结果形成每个的搜索连接都减小从而下降排名。而搜索引擎知道301永久重定向是 什么意思,这样就会把访问带www的和不带www的地址归到同一个网站排名下。
还有一个是用不一样的地址会形成缓存友好性变差。当一个页面有好几个名字时,它可能会在缓存里出现好几回。
如今,浏览器知道了“http://www.facebook.com/”才是要访问的正确地址,因此它会发送另外一个获取请求:
GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com
头信息以以前请求中的意义相同。
服务器接收到获取请求,而后处理并返回一个响应。
这表面上看起来是一个顺向的任务,但其实这中间发生了不少有意思的东西- 就像做者博客这样简单的网站,况且像facebook那样访问量大的网站呢!
举 个最简单的例子,需求处理能够以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地 址会映射/httpdocs/folder1/page1.aspx这个文件。web服务器软件能够设置成为地址人工的对应请求处理,这样 page1.aspx的发布地址就能够是http://example.com/folder1/page1。
所 有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据,存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案 有:sharding (基于主键值讲数据表分散到多个数据库中),复制,利用弱语义一致性的简化数据库。
委 托工做给批处理是一个廉价保持数据更新的技术。举例来说,Fackbook得及时更新新闻feed,但数据支持下的“你可能认识的人”功能只须要每晚更新 (做者猜想是这样的,改功能如何完善不得而知)。批处理做业更新会致使一些不过重要的数据陈旧,但能使数据更新耕做更快更简洁。
图中为服务器生成并返回的响应:
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
2b3Tn@[...]
整个响应大小为35kB,其中大部分在整理后以blob类型传输。
内容编码头告诉浏览器整个响应体用gzip算法进行压缩。解压blob块后,你能够看到以下指望的HTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
关于压缩,头信息说明了是否缓存这个页面,若是缓存的话如何去作,有什么cookies要去设置(前面这个响应里没有这点)和隐私信息等等。
请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现,而不是以文件形式下载它。浏览器会根据报头信息决定如何解释该响应,不过同时也会考虑像URL扩展内容等其余因素。
在浏览器没有完整接受所有HTML文档时,它就已经开始显示这个页面了:
在浏览器显示HTML时,它会注意到须要获取其余地址内容的标签。这时,浏览器会发送一个获取请求来从新得到这些文件。
下面是几个咱们访问facebook.com时须要重获取的几个URL:
这些地址都要经历一个和HTML读取相似的过程。因此浏览器会在DNS中查找这些域名,发送请求,重定向等等...
但 不像动态页面那样,静态文件会容许浏览器对其进行缓存。有的文件可能会不须要与服务器通信,而从缓存中直接读取。服务器的响应中包含了静态文件保存的期限 信息,因此浏览器知道要把它们缓存多长时间。还有,每一个响应均可能包含像版本号同样工做的ETag头(被请求变量的实体值),若是浏览器观察到文件的版本 ETag信息已经存在,就立刻中止这个文件的传输。
试着猜猜看“fbcdn.NET”在地址中表明什么?聪明的答案是"Facebook内容分发网络"。Facebook利用内容分发网络(CDN)分发像图片,CSS表和JavaScript文件这些静态文件。因此,这些文件会在全球不少CDN的数据中心中留下备份。
静态内容每每表明站点的带宽大小,也能经过CDN轻松的复制。一般网站会使用第三方的CDN。例如,Facebook的静态文件由最大的CDN提供商Akamai来托管。
举例来说,当你试着ping static.ak.fbcdn.net的时候,可能会从某个akamai.Net服务器上得到响应。有意思的是,当你一样再ping一次的时候,响应的服务器可能就不同,这说明幕后的负载平衡开始起做用了。
在Web 2.0伟大精神的指引下,页面显示完成后客户端仍与服务器端保持着联系。
以 Facebook聊天功能为例,它会持续与服务器保持联系来及时更新你那些亮亮灰灰的好友状态。为了更新这些头像亮着的好友状态,在浏览器中执行的 javascript代码会给服务器发送异步请求。这个异步请求发送给特定的地址,它是一个按照程式构造的获取或发送请求。仍是在Facebook这个例 子中,客户端发送给http://www.facebook.com/ajax/chat/buddy_list.PHP一个发布请求来获取你好友里哪一个 在线的状态信息。
提起这个模式,就必需要讲讲"AJAX"-- “异步JavaScript 和 XML”,虽然服务器为何用XML格式来进行响应也没有个一清二白的缘由。再举个例子吧,对于异步请求,Facebook会返回一些JavaScript的代码片断。
除了其余,fiddler这个工具可以让你看到浏览器发送的异步请求。事实上,你不只能够被动的作为这些请求的看客,还能主动出击修改和从新发送它们。AJAX请求这么容易被蒙,可着实让那些计分的在线游戏开发者们郁闷的了。(固然,可别那样骗人家~)
Facebook聊天功能提供了关于AJAX一个有意思的问题案例:把数据从服务器端推送到客户端。由于HTTP是一个请求-响应协议,因此聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看本身有没有新消息。
这些状况发生时长轮询是个减轻服务器负载挺有趣的技术。若是当被轮询时服务器没有新消息,它就不理这个客户端。而当还没有超时的状况下收到了该客户的新消息,服务器就会找到未完成的请求,把新消息作为响应返回给客户端。
OK,到这里咱们知道了从输入URL开始后,到请求页面返回的详细过程了。你要是可以达到这种程度,我想面试官会向你投去offer的目光!哈哈。
参考资料:
http://stackoverflow.com/questions/2092527/what-happens-when-you-type-in-a-url-in-browser;
http://stackoverflow.com/questions/5165310/what-is-the-complete-process-from-entering-a-url-to-the-browsers-address-bar-to;
3.What really happens when you navigate to a URL http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/;
4. 当你输入一个网址的时候,实际会发生什么? http://www.cnblogs.com/wenanry/archive/2010/02/25/1673368.html;