从输入URL到页面渲染完成

原文-英文
译文

推荐阅读《图解HTTP》

各类协议与HTTP协议的关系(参照该图理解下文)

1. 输入URL地址

2. 浏览器根据域名查询IP地址

从要访问的域名中获取IP地址，DNS查询的步骤以下：

1. 从浏览器缓存中查询。浏览器会存储必定时间的DNS记录，操做系统不会告诉浏览器每一个DNS记录的保存时限，不一样浏览器设置保存时限为一个固定值（不一样浏览器状况不一样，通常在2-30分钟）。
2. 从操做系统缓存中查询。若是浏览器中没有包含想要的缓存记录，那浏览器就会发起操做系统请求，继续查询操做系统缓存
3. 从路由器中查询DNS缓存。请求持续发送到你的路由，它一般会有本身的DNS缓存。
4. 从ISP中查询DNS缓存。下一个被查询地方是ISP缓存DNS的服务器。
5. 域名服务器递归查询。首先从root域名服务器中查询如.com域名服务器，而后逐步向前查询，.com顶级域名服务器到Facebook的域名服务器。通常来讲，.com级别的都已经在缓存中了，因此通常不会进行对root域名服务器的查询。下面给出一张递归查询的图。

扩展

什么是DNS？

DNS（Domain Name System，域名系统），因特网上做为域名和IP地址相互映射的一个分布式数据库，可以使用户更方便的访问互联网，而不用去记住可以被机器直接读取的IP数串。经过主机名，最终获得该主机名对应的IP地址的过程叫作域名解析（或主机名解析）。

DNS查询的两种方式：递归查询和迭代查询

一、递归解析

当局部DNS服务器本身不能回答客户机的DNS查询时，它就须要向其余DNS服务器进行查询。
此时有两种方式，如图所示的是递归方式。
局部DNS服务器本身负责向其余DNS服务器进行查询，通常是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。
最后获得的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。

二、迭代解析

当局部DNS服务器本身不能回答客户机的DNS查询时，也能够经过迭代查询的方式进行解析，如图所示。
局部DNS服务器不是本身向其余DNS服务器进行查询，而是把能解析该域名的其余DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到获得查询结果为止。
也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。
好比说：baidu.com的服务器ip地址在192.168.4.5这里，你本身去查吧，本人比较忙，只能帮你到这里了。

DNS域名称空间的组织方式

咱们在前面有说到根DNS服务器，域DNS服务器，这些都是DNS域名称空间的组织方式。
按其功能命名空间中用来描述 DNS 域名称的五个类别的介绍详见下表中，以及与每一个名称类型的示例:

3. 浏览器发送HTTP请求到web服务器

向 http://facebook.com/ 发出GET请求

HTTP请求报文

在请求中，HTTP报文首部由方法、URI、HTTP版本、HTTP首部字段等构成。

确保可靠性的TCP协议

扩展

TCP三次握手

• 第一次握手：
  客户端A将标志位SYN置为1,随机产生一个值为seq=J（J的取值范围为=1234567）的数据包到服务器，客户端A进入SYN_SENT状态，等待服务端B确认；
• 第二次握手：
  服务端B收到数据包后由标志位SYN=1知道客户端A请求创建链接，服务端B将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端A以确认链接请求，服务端B进入SYN_RCVD状态。
• 第三次握手：
  客户端A收到确认后，检查ack是否为J+1，ACK是否为1，若是正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务端B，服务端B检查ack是否为K+1，ACK是否为1，若是正确则链接创建成功，客户端A和服务端B进入ESTABLISHED状态，完成三次握手，随后客户端A与服务端B之间能够开始传输数据了。

为什须要三次握手？

《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的链接请求报文段忽然又传送到了服务端，于是产生错误”

书中的例子是这样的，“已失效的链接请求报文段”的产生在这样一种状况下：client发出的第一个链接请求报文段并无丢失，而是在某个网络结点长时间的滞留了，以至延误到链接释放之后的某个时间才到达server。
原本这是一个早已失效的报文段。但server收到此失效的链接请求报文段后，就误认为是client再次发出的一个新的链接请求。因而就向client发出确认报文段，赞成创建链接。

假设不采用“三次握手”，那么只要server发出确认，新的链接就创建了。因为如今client并无发出创建链接的请求，所以不会理睬server的确认，也不会向server发送数据。但server却觉得新的运输链接已经创建，并一直等待client发来数据。这样，server的不少资源就白白浪费掉了。采用“三次握手”的办法能够防止上述现象发生。

例如刚才那种状况，client不会向server的确认发出确认。server因为收不到确认，就知道client并无要求创建链接。”。主要目的防止server端一直等待，浪费资源。

TCP四次挥手

• 第一次挥手：
  Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
• 第二次挥手：
  Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
• 第三次挥手：
  Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
• 第四次挥手：
  Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

为何创建链接是三次握手，而关闭链接倒是四次挥手呢？

这是由于服务端在LISTEN状态下，收到创建链接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

而关闭链接时，当收到对方的FIN报文时，仅仅表示对方再也不发送数据了可是还能接收数据，己方也未必所有数据都发送给对方了，因此己方能够当即close，也能够发送一些数据给对方后，再发送FIN报文给对方来表示赞成如今关闭链接，所以，己方ACK和FIN通常都会分开发送。

什么是反向代理？

客户端原本能够直接经过HTTP协议访问某网站应用服务器，网站管理员能够在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，而后将结果返回给客户端，此时Nginx就是反向代理服务器。

负责传输的IP协议

• IP间的通讯依赖MAC地址
• ARP协议：(Address Resolution Protocol)用以解析地址的协议，根据通讯方的IP地址就能够反查出对应的MAC地址

4. Facebook服务器返回一个永久重定向响应

服务器会发送一个301永久重定向响应来告诉浏览器访问 http://www.facebook.com/ 而不是 http://facebook.com/。

为何服务器坚持重定向而不是直接给予浏览器用户须要的结果，这有不少有意思缘由:

• 一个缘由是搜索引擎排名，若是有两个URLs指向同一个页面，好比 http://www.igoro.com/ 和 http://igoro.com/ ,搜索引擎会认为这是两个不一样的网站，结果他们两个每一个都有一部分访问量，可是也只能拥有更低的搜索引擎排名。若是使用了301定位，搜索引擎将会识别重定向，进而将同一来源的多个连接算做一个。
• 另外一个缘由是，一样的内容多个URLs还不利于缓存，一样的内容拥有多个名字，潜在形成缓存浪费。

扩展

301和302的区别：

301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址能够从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另外一个地址B）——这是它们的共同点。

他们的不一样在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址换为重定向以后的网址；

302表示旧地址A的资源还在（仍然能够访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。 SEO 302好于301

重定向缘由：

• 网站调整（如改变网页目录结构）；
• 网页被移到一个新地址；
• 网页扩展名改变(如应用须要把.php改为.Html或.shtml)。
  这种状况下，若是不作重定向，则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户获得一个404页面错误信息，访问流量白白丧失；再者某些注册了多个域名的网站，也须要经过重定向让访问这些域名的用户自动跳转到主站点等。

何时进行301或者302跳转呢？

当一个网站或者网页24—48小时内临时移动到一个新的位置，这时候就要进行302跳转，而使用301跳转的场景就是以前的网站由于某种缘由须要移除掉，而后要到新的地址访问，是永久性的。

清晰明确而言：使用301跳转的大概场景以下：

一、 域名到期不想续费（或者发现了更适合网站的域名），想换个域名。
二、 在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候能够用301重定向来告诉搜索引擎咱们目标的域名是哪个。
三、 空间服务器不稳定，换空间的时候。

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

浏览器知道了 http://www.facebook.com/ 是真正应该访问的URL，因此就发送了另一个GET请求。

6. 服务器处理请求

服务器会接收这个GET请求，而且返回一个响应结果

怎么存储数据是每一个动态网站都会面临的有趣难题

小网站会常常有一个SQL数据库来存储他们的数据，可是网站存储数据量过大或者流量过大后就必须将数据库分布在多台机器，解决的方法有不少种

包括sharding(在主键基础上划分表到多个数据库中)，复制和使用简化的弱语义一致性数据库

推迟一些任务到批处理做业是廉价保持数据更新的的一种技术。

例如，Facebook必须尽快更新新闻供应，但数据支持的“你可能认识的人”功能可能只须要每晚进行更新（做者猜想是这样）。批处理做业的更新致使存在一些旧的相对不重要的数据，可是使数据更新更快更简单。

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
...

整个完整的响应是36KB，其中大部分处理后由blob类型传送
内容编码头部告诉浏览器响应体使用了gzip压缩算法。在解析blob后，你就会看到你指望的HTML了。

8. 浏览器开始渲染HTML

在浏览器接收完整HTML文件前，浏览器就开始渲染页面了。

9. 浏览器发送嵌入在HTML中的对象的请求

随着浏览器渲染HTML，浏览器会注意到有些标签须要请求其余URLs的资源，浏览器将会发送一个GET请求来从新获取每一个文件 。

10. 浏览器发送异步请求

在web2.0时代，即便在页面渲染后客户端仍是持续与服务器端通讯。

例如，当你的朋友上线或下线时，Facebook聊天功能将会持续更新你已经登陆的朋友列表。为了更新这个列表，你浏览器上运行的JS将会发送异步请求到服务器，异步请求是发送给特殊URL的GET或POST请求。在Facebook的例子中，客户端会发送一个POST请求到 http://www.facebook.com/ajax/chat/buddy_list.php ，获取你在线的朋友列表

这个模式被称为AJAX，是“Asynchronous JavaScript And XML”,的缩写，虽然不太清楚为何服务器必须将响应格式化为xml。

相关阅读：

当你访问淘宝的时候，发生了什么？