浏览器导航

[su-Pro]

整体流程

1. 用户从浏览器进程里输入请求信息；
2. 网络进程发起 URL 请求；
3. 服务器响应 URL 请求之后，浏览器进程就又要开始准备渲染进程；
4. 渲染进程准备好之后，需要先向渲染进程提交页面数据，我们称之为提交文档阶段；
5. 渲染进程接收完文档信息之后，便开始解析页面和加载子资源，从而完成页面的渲染。

输入请求信息

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

• 如果是搜索内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的 URL。
• 如果判断输入内容符合 URL 规则，那么地址栏会根据规则，把这段内容加上协议，合成为完整的 URL.

浏览器刚开始加载一个地址之后,标签页上的图标便进入了加载状态。但此时图中页面显示的依然是之前打开的页面内容,并没立即替换页面

到提交文档阶段,页面内容才会被替换

URL 请求过程（重点HTTP阶段）

浏览器通过进程间通信（IPC）把 URL 请求发送至网络进程，网络进程接收到 URL 请求后，会在这里发起真正的 URL 请求流程。


浏览器端发起HTTP请求流程

1. 査找本地缓存

网络进程会查找本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；如果在缓存中没有查找到资源，那么直接进入网络请求流程。

这样做的好处:缓解服务器压力，提升性能;实现快速资源加载的重要组成部分

2. 准备IP地址和端口

浏览器会请求DNS返回域名对应的IP,当然浏览器还提供了DNS数据缓存服务,如果某个域名已经解析过了,那么浏览器会缓存解析的结果,以供下次查询时直接使用,这样也会减少一次网络请求。如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

如果DNS解析失败会将错误页面进行渲染，具体自己尝试一下就知道了

3. 构建HTTP报文

构建HTTP请求头、请求体等信息，并把和该域名相关的 Cookie 等数据附加到请求头中。

4. 等待TCP队列

Chrome有个机制,同一个域名同时最多只能建立6个TCP连接

解释了为什么一个大型项目需要配置很多DNS静态资源服务器

5. 建立TCP连接

委托操作系统与服务器建立TCP连接，向服务器发送构建的请求信息。

细节部分会在网络部分进行总结

6. 发送HTTP请求

服务器端处理HTTP请求流程

1. 返回请求
2. 断开连接

正常情况下，服务器返回数据后就要关闭TCP连接

connection：Keep-alive可以保持TCP的持久连接，再下次通信时免去建立连接的过程

浏览器收到数据后

其中重要的三个环节：

1. 判断是否需要重定向

在接收到服务器返回的响应后,网络进程开始解析响应头,如果发现返回的状态码是301或者302,那么说明服务器需要浏览器重定向到其他URL。

2. 检查异常

如果状态码是400系 、500系那么会抛出异常页面

3. 判断Content-Type 类型

Content-Type是HTTP头中一个非常重要的字段,它告诉浏览器服务器返回的响应体数据是什么类型,然后浏览器会根据 Content-Type的值来決定如何进行下一步工作（显示响应体的内容）

如果 Content-Type 字段的值被浏览器判断为下载类型，那么该请求会被提交给浏览器的下载管理器，同时该 URL 请求的导航流程就此结束**。但如果是text/html，那么浏览器则会继续进行导航流程,也就是渲染流水线。

准备渲染进程

Chrome的默认策略是,每个标签对应一个渲染进程。但如果从一个页面打开了另一个新页面,而新页面和当前页面属于同一站点的话,那么新页面会复用父页面的渲染进程。官方把这个默认策略叫 proces-per-site- instance。

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

• 通常情况下，打开新的页面都会使用单独的渲染进程；
• 如果从 A 页面打开 B 页面，且 A 和 B 都属于同一站点的话，那么 B 页面复用 A 页面的渲染进程；

根域名 和 协议同时相同 （可以端口不同）

提交文档

这里的“文档”是指 URL 请求的响应体数据。

• “提交文档”的消息是由浏览器进程发出的，渲染进程接收到“提交文档”的消息后，会和网络进程建立传输数据的“pipe”。
• 文档数据传输开始后，渲染进程会返回“确认提交”的消息给浏览器进程。
• 浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括安全状态、地址栏的 URL、前进后退的历史状态，并刷新页面内容。

渲染阶段

一旦文档被提交，渲染进程便开始页面解析和子资源加载。