1. 输入URL：
2. 浏览器查询域名指向的IP：
DNS查询过程如下（依次查询，直到得到指向记录）：
浏览器缓存 —— 各浏览器不同，大约都在 2-30 分钟之间。另外，缓存只存在于
进程中，浏览器关闭或重启后失效。
操作系统缓存
路由器缓存
ISP DNS 缓存
递归搜索 —— 该搜索由你所属的ISP 的DNS服务器发起，首先找到互联网根服务
器， 从根服务器获取到.com 域名服务器，从.com 域名服务器获取到Facebook的
域名服务器（一般小公司没有自己的域名服务器）。 由于根服务器及.com 域名服务
器都比较固定，通常ISP 的DNS服务器已经缓存了.com 域名服务器，即，可以省略
对根服务器的查询。
题外话：像facebook、wikipedia这种规模的网站，如果它的域名只是指向一个IP，那么
可能很容易就挂掉了。通常人们采用以下几种技术解决这个瓶颈：
Round-robin DNS：一个域名指向多个IP，DNS服务器返回多个IP。
Load-balancer：采用高性能负载均衡设备，将请求重定向到其它IP。
Geographic DNS：一个域名指向多个IP，根据客户端所处的物理位置返回最近的IP。
适合不常更新的静态内容例如js、css及图片等。可能CDN采用这种方式。
Anycast：一个IP 映射到多台物理服务器。由于不能很好的兼容TCP协议，应用场
景很少。但大多数DNS服务器使用这种方式。
3. 浏览器向web服务器发送HTTP请求。
像facebook这种网站的首页是不会缓存到浏览器端的。
此次请求如下：
GET：获取http://facebook.com的内容。
User-Agent：浏览器的标识。
Accept：浏览器能接受的响应类型。
Accept-Encoding：浏览器能接受的数据编码类型。
Connection：浏览器将在对一个server的多次访问中重用一个连接。
Cookie：该浏览器中存储的此域名下的所有cookie值。每次请求都会发送所有cookie。
可以使用fiddler 查看请求和响应的原始http信息。
Post请求与Get请求的区别：Get请求的参数在URL中，Post请求的参数在请求体中。
4. 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/）。
对于为什么使用客户端的重定向而非直接将内容响应出来有以下两个原因：
为了SEO。对于搜索引擎来说，www.facebook.com 和facebook.com 两个不同的URL
会各自分一批流量，不利于排名。而搜索引擎能够识别301重定向，会将两个URL
的流量合并。
为了优化缓存。对于缓存来说，两个URL将保存两份缓存。使用了重定向后，缓存
依据的仅仅是www.facebook.com，只产生一份缓存。
5. 浏览器转向。
现在浏览器知道www.facebook.com才是正确的URL，于是发起另一此Get请求：
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
6. 服务器开始处理请求。
Web服务器。
IIS 或apache 等接收到http 请求后，为请求选择一个处理程序。请求处理程序
（ASP.NET、PHP、Ruby等）负责读取请求信息，生成HTML响应。
请求处理程序。
请求处理程序读取请求信息、URL、参数、cookie 等。然后读取或更新存储在
器段的数据。最后生成一段HTML文本。
7. 服务器向浏览器返回响应信息。
以下是响应内容：
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
最后一行是一大堆乱码，这里省略掉了。
可以看到Content-Encoding的值是gzip，表示响应体的内容是使用gzip压缩过的，所以
看上去是一堆乱码。浏览器会将它解压。解压后内容如下：
<!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" />
...
响应头还告诉浏览器是否可以缓存页面、怎样缓存页面、需要设置的cookie（此例中没
有）以及隐私信息等。Content-Type的值是text/html表示，浏览器应该把响应内容作为
html来呈现，而不是下载这个文件。实际上浏览器还会考虑其它因素，例如URL的后缀
名以决定以什么方式呈现或下载。
8. 浏览器开始呈现HTML。
在完全接收整个HTML文档之前就已开始呈现。
9. 浏览器请求获取HTML文档中内嵌的对象。
在呈现过程中，浏览器会分析HTML中的需要下载内容的标签。浏览器发起GET请求获
取这些文件。这些文件可能包括图片、CSS样式表、js 文件等等。
请求这些文件的过程与请求HTML文档类似，包括在DNS服务器中查询域名指向、向
URL发送请求、重定向等等。
然而，静态文件是可以允许浏览器缓存的。一些文件可以直接从浏览器缓存获取，而不
必重新向服务器请求。浏览器知道应该缓存多久——服务器返回的响应头中写着呢。作
为浏览器缓存过期时间的补充，响应头中可能还会包含一个”ETag”，标识文件的版本—
—当浏览器接收一个响应时发现该响应的Etag版本在缓存中已经存在了，则会停止下载
文件。
题外话：像facebook这种规模的网站都会使用CDN（content delivery network，内容分
发网络）——可以将静态内容例如图片、样式表、js 文件等部署在CDN上——这些文件
会被copy到很多服务器上。
10. 浏览器发送ajax请求。
Web 2.0的技术精神就是即使页面已经呈现完毕了，客户端仍然能够异步的与服务端进
行交互。