本文将深入理解当你输入一个网址的时候，后台到底发生了什么事。。。→_→

原文传送门：What really happens when you navigate to a URL

1. 首先，在浏览器中输入网址:

   

2. 浏览器查找域名的IP地址

   

   DNS查找过程如下：

   • 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。

• 系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。

• 路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。

• ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。

• 递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。

  DNS递归查找如下图所示：

  

  DNS有一点令人担忧，这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：

  负载平衡器 是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。 一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。

  地理 DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。

  Anycast 是一个IP地址映射多个物理主机的路由技术。 美中不足，Anycast与TCP协议适应的不是很好，所以很少应用在那些方案中。

  大多数DNS服务器使用Anycast来获得高效低延迟的DNS查找。

3. 浏览器给web服务器发送一个HTTP请求

   

   因为像Facebook主页这样的动态页面，打开后在浏览器缓存中很快甚至马上就会过期，毫无疑问他们不能从缓存中读取。

   所以，浏览器将把请求发送到Facebook所在的服务器：

   GET http://facebook.com/ HTTP/1.1
    Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
    User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive
    Host: facebook.com
    Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

   • GET 这个请求定义了要读取的URL：“http://facebook.com/“

   • 浏览器自身定义 (User-Agent 头)，和它希望接受什么类型的相应 (Accept and Accept-Encoding 头)。

   • Connection 头要求服务器为了后边的请求不要关闭TCP连接

   • 请求中也包含浏览器存储的该域名的cookies 。在不同页面请求当中，cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登录用户名，服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里，每次请求时发送给服务器。

4. 服务器的永久重定向响应
   

   为什么服务器一定要重定向而不是直接发会用户想看的网页内容呢？

   • 搜索引擎排名有关。如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是两个网站,结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是 什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下

   • 用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。

5. 浏览器跟踪重定向地址

   

   现在，浏览器知道了“http://www.facebook.com/”才是要访问的正确地址，所以它会发送另一个获取请求：

6. 服务器“处理”请求

   

   服务器接收到获取请求，然后处理并返回一个响应。

   请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据，并讲数据存储在服务器上。然后，需求处理会生成一个HTML响应。

7. 服务器发回一个HTML响应

   

8. 浏览器开始显示HTML

   在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了

   

9. 浏览器发送获取嵌入在HTML中的对象

   

   在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。这些都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等…

   但不像动态页面那样，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取。服务器的响应中包含了静态文件保存的期限信息，所以浏览器知道要把它们缓存多长时间。还有，每个响应都可能包含像版本号一样工作的ETag头（被请求变量的实体值），如果浏览器观察到文件的版本 ETag信息已经存在，就马上停止这个文件的传输。

10. 浏览器发送异步（AJAX）请求

    

    在Web 2.0伟大精神的指引下，页面显示完成后客户端仍与服务器端保持着联系。

    “AJAX”–“异步JavaScript 和 XML”，把数据从服务器端推送到客户端。因为HTTP是一个请求-响应协议，所以服务器不能把新消息发给客户，取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。如果当被轮询时服务器没有新消息，它就不理这个客户端。而当尚未超时的情况下收到了该客户的新消息，服务器就会找到未完成的请求，把新消息做为响应返回给客户端。

这篇总结真的很好，学习了。。。