这道题目没有所谓的完全的正确答案，这个题目可以让你在任意的一个点深入下去， 只要你对这个点是熟悉的。以下是一个大概流程：
- 浏览器向DNS服务器查找输入URL对应的IP地址。
- DNS服务器返回网站的IP地址。
- 浏览器根据IP地址与目标web服务器在80端口上建立TCP连接
- 浏览器获取请求页面的html代码。
- 浏览器在显示窗口内渲染HTML。
- 窗口关闭时，浏览器终止与服务器的连接。
这其中最有趣的是第1步和第2步(域名解析)。我们输入的网址(域名)是IP地址的一个别名， 在一个DNS内，一个域名对应一个IP地址。域名系统(DNS) 的工作就是将域名与它的IP地址对应起来。DNS是分布式的，同时也是具有层级关系的。
一个域名服务器虽然只记录一个小的子网内的主机名和IP地址， 但所有的域名服务器联合起来工作，就能将全网内的域名与它们的IP地址对应起来。 这也就意味着，如果一个域名服务器无法找到某个请求域名所对应的IP地址， 它就会向其它的域名服务器发出请求进行寻找。
web前端性能：
即是web用户在访问一个页面时所要花费的时间总和。即一个完全意义上的用户响应时间，相对于服务器的响应时间而言还会包括更多的内容和影响因素。那么一个web页面的完整请求包括了哪些部分的时间总和就是web前段性能分析和优化所需要了解的基础知识，先了解一下用户从浏览器访问一个url后到页面完全展示所有内容的整个过程吧。
页面的请求过程：
1、浏览器的url请求2、递归寻找DNS服务器
3、连接目标IP并建立TCP连接
4、向目标服务器发送http请求
5、web服务器接收请求后处理
6、web服务器返回相应的结果【无效、重定向、正确页面等】
7、浏览器接收返回的http内容
================================前端解析分割线===========================================
8、开始解析html文件，当然是自上而下，先是头部，后是body9、当解析到头部css外部链接时，同步去下载，如果遇到外部js链接也是下载【不过js链接不建议放在头部，因为耽误页面第一展现时间】
10、接着解析body部分，边解析边开始生成对应的DOM树，同时等待css文件下载
11、一旦css文件下载完毕，那么就同步去用已经生成的DOM节点+CSS去生成渲染树
12、渲染树一旦有结构模型了，接着就会同步去计算渲染树节点的布局位置
13、一旦计算出来渲染的坐标后，又同步去开始渲染
14、10-13步进行过程中如果遇到图片则跳过去渲染下面内容，等待图片下载成功后会返回来在渲染原来图片的位置
15、同14步，如果渲染过程中出现js代码调整DOM树机构的情况，也会再次重新来过，从修改DOM那步开始
16、最终所有节点和资源都会渲染完成
=========================================分析结束分割线==============================================
17、渲染完成后开始page的onload事件18、整个页面load完成
整个过程中会有很多的分别请求，所以TCP连接会很多，并且每一个用完都会自己关了，除非是keep-live类型的可以请求多次才关闭。
第二章 WEB前台的优化规则
一、尽量减少 HTTP 请求
有几种常见的方法能切实减少 HTTP 请求：
1、 合并脚本跟样式文件，如可以把多个 CSS 文件合成一个，把多个 JS 文件合成一个。
2、 CSS Sprites 利用 CSS background 相关元素进行背景图绝对定位,把多个图片合成一个图片。
二、使用浏览器缓存
在用户浏览网站的不同页面时，很多内容是重复的，比如相同的JS、CSS、图片等。如果我们能够建议甚至强制浏览器在本地缓存这些文件，将大大降低页面产生的流量，从而降低页面载入时间。
根据服务器端的响应header，一个文件对浏览器而言，有几级不同的缓存状态。
1、服务器端告诉浏览器不要缓存此文件，每次都到服务器上更新文件。
2、服务器端没有给浏览器任何指示。
3、在上次传输中，服务器给浏览器发送了Last-Modified或Etag数据，再次浏览时浏览器将提交这些数据到服务器，验证本地版本是否最新的，如果为最新的则服务器返回304代码，告诉浏览器直接使用本地版本，否则下载新版本。一般来说，有且只有静态文件，服务器端才会给出这些数据。
4、服务器强制要求浏览器缓存文件，并设置了过期时间。在缓存未到期之前，浏览器将直接使用本地缓存文件，不会与服务器端产生任何通信。
我们要做的是尽量强制浏览器到第四种状态，特别是对于JS、CSS、图片等变动较少的文件。
三、使用压缩组件
IE和Firefox浏览器都支持客户端GZIP，传输之前，先使用GZIP压缩再传输给客户端，客户端接收之后由浏览器解压，这样虽然稍微占用了一些服务器和客户端的CPU，但是换来的是更高的带宽利用率。对于纯文本来讲，压缩率是相当可观的。如果每个用户节约50%的带宽，那么租用来的那点带宽就可以服务多一倍的客户，并且缩短了数据的传输时间。
四、图片、JS的预载入
预载入图像最简单的方法是在 JavaScript 中实例化一个新 Image() 对象，然后将需要载入的图像的 URL 作为参数传入。
function preLoadImg(url) {
var img = new Image();
img.src = url;
}
可以在登录页面预载入JS和图片
五、将脚本放在底部
脚本放在顶部带来的问题，
1、 使用脚本时，对于位于脚本以下的内容，逐步呈现将被阻塞
2、 在下载脚本时会阻塞并行下载
放在底部可能会出现JS错误问题，当脚本没加载进来，用户就触发脚本事件。
要综合考虑情况。
六、将样式文件放在页面顶部
如果样式表任在加载，构建呈现树就是一种浪费，样式文件放在页面底部可能会出现两种情况：
1、 白屏
2、 无样式内容的闪烁
七、使用外部的JS和CSS
将内联的JS和CSS做成外部的JS、CSS。减少重复下载内联的JS和CSS。
八、切分组件到多个域
主要的目的是提高页面组件并行下载能力。但不要跨太多域名，建议采用2个子域名。
九、精简JS
可以做到两个级别
1、精简：从代码中移除不必要的字符以减少其大小，
2、混淆：在精简的同时，还会改写代码，函数、变量名被转换成更短的字符串
可以使用ShrinkSafe来精简JS http://shrinksafe.dojotoolkit.org/
十、精简CSS
从代码中移除不必要的字符以减少其大小，
可以使用CSS Compressor http://www.cssdrive.com/index.php/main/csscompressor /
十一、 精简图片、Flash
对大图片、Flash，要在效果和大小之间做出平衡。
第三章 程序的优化
第四章 数据库的优化
附录A 页面请求分析
从输入URL到页面呈现需要下面5个步骤
1． 输入URL地址或者点击URL的一个链接
2． 浏览器根据URL地址，结合DNS，解析出URL对应的IP地址
3． 发送HTTP请求
4． 开始连接请求的服务器并且请求相关的内容
5． 浏览器解析从服务器端返回的内容，并且把页面显现出来
上面基本上就是一个页面从请求到实现的基本过程，下面我们将剖析这个过程。
当输入URL之后，浏览器就要知道这个URL对应的IP是什么，只有知道了IP地址，浏览器才能准备的把请求发送到指定的服务器的具体IP和端口号上面。浏览器的DNS解析器负责把URL解析为正确的IP地址。这个解析的工作是要花时间的，而且这个解析的时间段内，浏览器不是能从服务器那里下载到任何的东西的。浏览器和操纵系统提供了DNS解析缓存支持。
当获得了IP地址之后，那么浏览器就向服务器发送HTTP的请求，过程如下：
1．浏览器通过发送一个TCP的包，要求服务器打开连接
2．服务器也通过发送一个包来应答客户端的浏览器，告诉浏览器连接开了。
3．浏览器发送一个HTTP的GET请求，这个请求包含了很多的东西了，例如我们常见的cookie和其他的head头信息。
这样，一个请求就算是发过去了。
请求发送去之后，之后就是服务器的事情了，服务器端的程序把最后的结果发送到客户端。
其实首先到达浏览器的就是html的那些文档，所谓的html的文档，就是纯粹的html代码，不包含什么图片，脚本，CSS等的。也就是页面的html结构。因为此时返回的只是页面的html结构。这个html文档的发送到浏览器的时间是很短的，一般是占整个响应时间的10%左右。
这样之后，那么页面的基本的骨架就在浏览器中了，下一步就是浏览器解析页面的过程，也就是一步步从上到下的解析html的骨架了。
如果此时在html文档中，遇到了img标签，那么浏览器就会发送HTTP请求到这个img响应的URL地址去获取图片，然后呈现出来。如果在html文档中有很多的图片，flash，那么浏览器就会一个个的请求，然后呈现，如果每个图片都要请求，那么就要进行之前说的那些步骤：解析url，打开tcp连接等等。打开连接也是要消耗资源的，就像我们在进行数据库访问一样，我们也是尽可能的少开数据库连接，多用连接池中的连接。道理一样，tcp连接也是可以重用的。http1.1提出了持久连接（persistent connection）的概念，也就是说同一条 HTTP 连接，可以同时处理多个请求，减少tcp连接。
当页面的html骨架载入了之后,浏览器就开始解析页面中标签,从上到下开始解析。
首先是head标签的解析，如果发现在head中有要引用的JS脚本，那么浏览器此时就开始请求脚本，此时整个页面的解析过程就停了下来，一直到JS请求完毕。之后页面接着向下解析，如解析body标签，如果在body中有img标签，那么浏览器就会请求img的src对应的资源，如果有多个img标签，那么浏览器就一个个的解析，解析不会像JS那样等待的，会并发的下载。
综上所述：
一个页面的请求等于一个或多个url的请求，因此一个页面里包含的外部请求数会影响页面的整体性能
【每请求一次就要多占用一次cpu使用、多一次tcp连接】
每个url的请求又包括寻址、连接、请求传输、返回传输、断连的过程；因此每个阶段的外部环境也会影响整体性能
【DNS服务器的寻址时间，请求和返回内容时的网络环境】
除了URL请求数量外，每个请求的内容大小也是影响性能的主要因素
【文件越大消耗在传输过程中的时间就越长】
请求同样多的资源，并行请求和串行请求速率是不一样的，所以请求的资源要尽量支持同步请求
【同步请求不同资源，即请求被发送到不同的资源服务器即可】
依据浏览器的加载、渲染机制，选择合适的HTML内容排版方式
【减少反复创建对象实例的次数、充分利用缓存机制】
优先加载用户关注的内容
【css加载优于js内容，首屏内容优于非首屏内容】
关注完http请求的过程后，再来关注整个请求过程中关注的几个时间点，通过确定时间点就可以确定影响性能的时间段，就是确定影响性能的因素。根据上面的介绍主要的几个时间点又可以分页面的整体时间点、以及单个url请求过程中的时间点。【基于httpanalyzer工具的指标】
1、Cache Read：缓存读取时间，或304错误的处理时间
2、Block：请求等待时间，取决于缓存检查，网络连接等待
3、DNS Lookup：DNS服务器查找时间，取决于dns服务的数量，dns注册的域
4、Connect：tcp连接的总时间，取决于连接类型，ssh，keepalive都会比http长
5、Send first to last：发送请求内容的时间，取决于请求内容大小，及上行的传输速度
6、Wait：等待响应的时间，取决于网络环境的响应，web服务器的处理时间
7、Receive first to last：接收响应内容的时间，取决于响应内容，下行的传输速度，也要考虑服务器的带宽
8、Time to first byte：从请求一直到接收到第一个字符的总时间，等于1+2+3+4+5+6
9、Network：网络消耗时间，等于3+4
10、Begin to end：整个请求的总时间，等于1+2+3+4+5+6+7
单个页面的主要时间点：
1、DOM Ready Time: DOM完成的时间，从接收html到完全转换成dom树所需的时间
2、DOM Ready to Page Load: 页面元素的加载和渲染完成时间，包括html，css，img及其它内容
3、Page Load Time: page页onload事件的时间，其实际时间等于总时间 - （DOM ready + 元素渲染时间）
4、URL Requests Begin to End:url请求所消耗的所有时间，从发送请求发起到接收最后一个字节断开
5、Network Time:消耗在网络上的时间，即tcp的连接时间
6、Begin to End:所有消耗的时间，包括请求结束后的渲染时间
1.浏览器获得url对应的请求，向操作系统请求该url对应的iP地址
2.操作系统查询DNS （首先查询本地host文件，没有则查询网络）获得对应ip地址
3.浏览器发送tcp连接请求向 ip地址对应的服务器（带SYN标志数据包）。
4.服务器收到tcp连接请求后，回复可以链接请求（有SYN/ACK标志的数据包）。
5.浏览器收到回传的数据，确认ok后，还会向服务端发送数据（带ACK标志的数据包）包表示三次握手结束。
6.三次握手成功后，浏览器和服务端开始tcp连接形式传输数据包。
7.服务器传给浏览所需要的资源数据。
8.浏览器获得数据，渲染网页然后呈现给用户。
作为一个软件开发者，你一定会对网络应用如何工作有一个完整的层次化的认知，同样这里也包括这些应用所用到的技术：像浏览器，HTTP，HTML，网络服务器，需求处理等等。
本文将更深入的研究当你输入一个网址的时候，后台到底发生了一件件什么样的事～
1. 首先嘛，你得在浏览器里输入要网址:
2. 浏览器查找域名的IP地址
导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下：
- 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。
- 系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。
- 路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。
- ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。
- 递归搜索 – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。
DNS递归查找如下图所示：
DNS有一点令人担忧，这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：
大多数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 andAccept-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到底是文件夹还是文件，所以不能自动添加 斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重定向，结果造成一次不必要的握手。
4. facebook服务的永久重定向响应
图中所示为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的地址归到同一个网站排名下。
还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。
5. 浏览器跟踪重定向地址
现在，浏览器知道了“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
头信息以之前请求中的意义相同。
6. 服务器“处理”请求
服务器接收到获取请求，然后处理并返回一个响应。
这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西- 就像作者博客这样简单的网站，何况像facebook那样访问量大的网站呢！
- Web 服务器软件
web服务器软件（像IIS和阿帕奇）接收到HTTP请求，然后确定执行什么请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应的程序（像ASP.NET,PHP,RUBY...）。举 个最简单的例子，需求处理可以以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地 址会映射/httpdocs/folder1/page1.aspx这个文件。web服务器软件可以设置成为地址人工的对应请求处理，这样 page1.aspx的发布地址就可以是http://example.com/folder1/page1。
- 请求处理
请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据，并讲数据存储在服务器上。然后，需求处理会生成一个HTML响应。
所 有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据，存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案 有：sharding （基于主键值讲数据表分散到多个数据库中），复制，利用弱语义一致性的简化数据库。
委 托工作给批处理是一个廉价保持数据更新的技术。举例来讲，Fackbook得及时更新新闻feed，但数据支持下的“你可能认识的人”功能只需要每晚更新 （作者猜测是这样的，改功能如何完善不得而知）。批处理作业更新会导致一些不太重要的数据陈旧，但能使数据更新耕作更快更简洁。
7. 服务器发回一个HTML响应
图中为服务器生成并返回的响应：
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扩展内容等其他因素。
8. 浏览器开始显示HTML
在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了：
9. 浏览器发送获取嵌入在HTML中的对象
在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。
下面是几个我们访问facebook.com时需要重获取的几个URL：
- 图片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
… - CSS 式样表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
… - JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
这些地址都要经历一个和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一次的时候，响应的服务器可能就不一样，这说明幕后的负载平衡开始起作用了。
10. 浏览器发送异步（AJAX）请求
在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是一个请求-响应协议，所以聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。
这些情况发生时长轮询是个减轻服务器负载挺有趣的技术。如果当被轮询时服务器没有新消息，它就不理这个客户端。而当尚未超时的情况下收到了该客户的新消息，服务器就会找到未完成的请求，把新消息做为响应返回给客户端。
总结一下
希望看了本文，你能明白不同的网络模块是如何协同工作的
在浏览器里输入网址或者点击链接，网页打开了……这是我们上网时再普通不过的一幕，但是如此简单的表象背后，却隐藏着无比复杂的技术流程。想涨涨知识吗？往下看吧。
一个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缓存
● 系统DNS缓存
● Hosts文件
● 各个DNS服务器上的缓存
当然DNS缓存失效期通常都比较短，很多情况下都要再去查找。为了降低用户体验到的延迟（注意这里不是网络延时），预取是一个不错的方法。
比如说你敲网址的时候还没有敲完，但是浏览器根据你的历史发现你很有可能去访问哪个网站，就提前给你做DNS预取了，比如你打了一个“w”的时候，chrome已经帮你去找weibo.com的IP地址了。chrome用户看一下chrome://predictors 你就知道了。
此外浏览器还会记录你过去的历史，知道每个域名下通常还会有哪些其他的链接，以便建立起网站的拓扑结构。当你访问这个域名下的网站，它就会预先对其他链接的域名进行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刚出随身Wi-Fi的时候博主想到了这么个点子，还想着把这个东西做出来之后用这个创业和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连接断开的情况还是比较常见的。
不过作为一个未来的技术，还是有必要关注一下。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
