原文地址https://zhuanlan.zhihu.com/p/600306778

1、解析URL：首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

2、缓存判断：浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。

3、DNS解析： 首先需要获取的是输入的 URL 中的域名对应的 IP 地址，会先判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户。用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。(具体可以参考昨天文章)

4、获取MAC地址： 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，值得注意的是，此时目的主机的 MAC 地址应该为网关的地址。

5、TCP三次握手： 首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号seq，服务端接收到请求后向客户端发送SYN,ACK报文段，确认连接请求，并且也向客户端发送一个同步报文段(SYN和随机序号seq)。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。(这里有个有意思的点，其实TCP连接只是一次握手，广为流行的三次握手意思是在一次握手的过程中交换了三个报文，而非进行了三次握手，如同握一次手，热情地摇晃了三次，怪不得三次握手英译过来的handshake不是复数[哈哈]。计算机网络第7版5.9.1节对此有解释)

6、HTTPS握手： 如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。 (对称加密+非对称加密一起上菜)

7、返回数据： 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。

8、页面渲染： 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。

9、TCP四次挥手： 最后一步是 TCP 断开连接的四次挥手过程。若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大报文段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

大抵上述内容已经回答差不多了。

下面从浏览器视角上(进程)看，更加页面化出来上面的一些内容，看完再去阅读以上的总结，会发现自己能补充进去的东西也可以挺多！

我们就一起来探索下这个流程，下图是“从输入URL到页面展示完整流程示意图”：

从图中可以看出，整个过程需要各个进程之间的配合，所以在开始正式流程之前，我们还是先来快速回顾下浏览器进程、渲染进程和网络进程的主要职责。

• 浏览器进程主要负责用户交互、子进程管理和文件储存等功能。

• 网络进程是面向渲染进程和浏览器进程等提供网络下载功能。

• 渲染进程的主要职责是把从网络下载的HTML、JavaScript、CSS、图片等资源解析为可以显示和交互的页面。因为渲染进程所有的内容都是通过网络获取的，会存在一些恶意代码利用浏览器漏洞对系统进行攻击，所以运行在渲染进程里面的代码是不被信任的。这也是为什么Chrome会让渲染进程运行在安全沙箱里，就是为了保证系统的安全。

回顾了浏览器的进程架构后，我们再结合上图来看下这个完整的流程，可以看出，整个流程包含了许多步骤，这个过程可以大致描述为如下：

• 首先，用户从浏览器进程里输入请求信息；

• 然后，网络进程发起URL请求；

• 服务器响应URL请求之后，浏览器进程就又要开始准备渲染进程了；

• 渲染进程准备好之后，需要先向渲染进程提交页面数据，我们称之为提交文档阶段；

• 渲染进程接收完文档信息之后，便开始解析页面和加载子资源，完成页面的渲染。

这其中，用户发出URL请求到页面开始解析的这个过程，就叫做导航。下面我们来详细分析下这些步骤，同时也就解答了标题。

1.用户输入

当用户在地址栏中输入一个查询关键字时，地址栏会判断输入的关键字是搜索内容，还是请求的URL。

• 如果是搜索内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的URL。

• 如果判断输入内容符合URL规则，比如输入的是http://github.com，那么地址栏会根据规则，把这段内容加上协议，合成为完整的URL，如 https://github.com。

当用户输入关键字并键入回车之后，浏览器便进入下图的状态：

从上图可以看出，当浏览器开始加载一个地址之后，标签页上的图标便进入了加载状态。但此时图中页面显示的依然是之前打开的页面内容，并没立即替换为github的页面。因为需要等待提交文档阶段，页面内容才会被替换。

2.URL请求过程

接下来，便进入页面资源请求过程，此时浏览器会通过进程间通信（IPC）把URL请求发送至网络进程，由网络进程去发起真正的URL请求流程，那么，下面涉及的一些步骤（HTTP请求，老朋友了）：准备IP地址和端口（DNS解析），建立TCP连接（提前先看是否需要进入等待TCP队列），HTTP请求，服务器响应（发给客户端的网络进程）。具体地，可以看下Day04文章。

2.1 重定向

在接收到服务器返回的响应头（这里将响应行+响应头一起称呼为响应头，后面同）后，网络进程开始解析响应头，如果发现返回的状态码是301或者302，那么说明服务器需要浏览器重定向到其他URL。这时网络进程会从响应头的Location字段里面读取重定向的地址，然后再发起新的HTTP或者HTTPS请求，一切又重头开始了。

2.2 响应数据类型处理

在处理了跳转信息之后，我们继续导航流程的分析。我们知道，响应数据类型由Content-Type标识，这是HTTP头中一个非常重要的字段， 它告诉浏览器服务器返回的响应体数据是什么类型，然后浏览器会根据Content-Type的值来决定如何显示响应体的内容。

这里我们以极客时间为例，看看极客时间官网返回的Content-Type值是什么。在终端输入以下命令：

curl -I https://time.geekbang.org/

响应头中的Content-type字段的值是text/html，这就是告诉浏览器，服务器返回的数据是HTML格式。

接下来我们再来利用curl来请求极客时间安装包的地址，如下所示：

curl -I https://res001.geekbang.org/apps/geektime/android/2.3.1/official/geektime_2.3.1_20190527-2136_offical.apk

从返回的响应头信息来看，其Content-Type的值是application/octet-stream，显示数据是字节流类型的，通常情况下，浏览器会按照下载类型来处理该请求。

由此，我们学习两个不同的响应数据类型，可以较为清楚感受到，不同Content-Type的后续处理流程也截然不同。如果Content-Type字段的值被浏览器判断为下载类型，那么这个请求会被提交给浏览器的下载管理器，同时该URL请求的导航流程就此结束。但如果是HTML，那么浏览器则会继续进行导航流程。由于Chrome的页面渲染是运行在渲染进程中的，所以接下来就需要准备渲染进程了。

3.准备渲染进程

默认情况下，Chrome为每个标签页分配一个渲染进程，即每打开一个新页面，就会配套创建一个新的渲染进程，但是，如果不同标签页属于同个站点，则会运行在同一个渲染进程中（新页面可能复用父页面的渲染进程，这个默认策略官方叫process-per-site-instance）。

同个站点：根域名（例如，http://geekbang.org）加上协议（例如，https:// 或者http://），还包含了该根域名下的所有子域名和不同的端口，比如下面这三个：

https://time.geekbang.org
https://www.geekbang.org
https://www.geekbang.org:8080

它们都是属于同一站点，因为它们的协议都是HTTPS，而且根域名也都是http://geekbang.org。

因此，打开一个新页面采用的渲染进程策略就是：

• 通常情况下，打开新的页面都会使用单独的渲染进程；

• 如果从A页面打开B页面，且A和B都属于同一站点的话，那么B页面复用A页面的渲染进程；如果是其他情况，浏览器进程则会为B创建一个新的渲染进程。

渲染进程准备好之后，还不能立即进入文档解析状态，因为此时的文档数据还在网络进程中，并没有提交给渲染进程，所以下一步就进入了提交文档阶段。

4.提交文档

提交文档，这个“文档”指的是网络进程请求后得到的响应体数据。

• “提交文档”的消息是由浏览器进程发出的，渲染进程接收到“提交文档”的消息后，会和网络进程建立传输数据的“管道”。

• 等文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程。

• 浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态、地址栏的URL、前进后退的历史状态，并更新Web页面。

更新内容如下图所示：

到这里，一个完整的导航流程就“走”完了，这之后就要进入渲染阶段了。

5.渲染阶段

一旦文档被提交，渲染进程便开始页面解析和子资源加载了，关于这个阶段的过程，我们明天再来学习下。

这里可以先了解的就是一旦页面生成完成，渲染进程会发送一个消息给浏览器进程，浏览器收到消息后，会停止标签图标上的加载动画。

参考

极客时间《浏览器工作原理与实践》学习笔记 Day 05

计算机网络（第7版）-谢希仁