输入url到页面展示的过程

Posted 2023-05-15

参考技术A

1、 域名解析
2、 根据IP建立TCP连接（三次握手）
3、 发送HTTP请求
4、 服务器处理请求并返回HTTP报文
5、 浏览器解析并渲染页面
6、 连接结束，关闭TCP连接（四次挥手）

当输入一个域名的时候，我们首先要做的就是 将域名转化成IP地址 。前端的静态资源等，都是存储在服务器上。在计算机网络中，我们不能通过域名直接访问，只能通过IP地址访问到具体的主机。

1、首先 浏览器会查询自身的缓存 中，有没有此条域名的解析，如果有的话，就返回这个解析后的地址。

2、如果浏览器自身的缓存中，没有找到与此条域名对应的IP地址，那么就会去 操作系统中的缓存 中查找是否有这条域名的解析。

3、如果在操作系统中也没有找到的话，那么就需要通过 DNS(域名系统) 帮助我们解析。

4、DNS域名解析过程（详细看参考链接）

浏览器与远程web服务器通过TCP三次握手协商来建立一个TCP/IP连接。该握手首先由客户端尝试建立起通信，而后服务器应答并接受客户端的请求，最后由客户端发出该请求已经被接受的报文。

一旦TCP/IP连接建立，浏览器会通过该连接向远程服务器发送HTTP请求。

当浏览器再次访问某个url时，会先获取资源的header信息， 判断是否命中强缓存 ：
1、如命中，直接从缓存获取资源，包括响应的header信息（ 请求不会和服务器通信 ），也就是强缓存
2、如未命中强缓存，浏览器发送请求到服务器，该请求会携带第一次请求返回的有关缓存的header信息，由服务器根据请求种的相关header信息来 对比结果是否协商缓存命中
1）若命中，服务器 返回新的响应header信息，更新缓存中对应的header信息，但并不返回资源内容 ，它会告诉浏览器可以直接从缓存获取
2）否则，返回最新的资源内容

Expires ：Expires 的值是一个 绝对时间的GMT格式的时间字符串（如Thu, 02 Sep 2021 11:03:45 GMT） ，在浏览器发起请求的时候，会根据系统时间和 Expires 的值进行比较，如果发送请求的时间在expires之前，那么本地缓存始终有效，否则就会发送请求到服务端来获取资源。

注：这个字段会导致一个问题，要是系统时间与服务器时间不一致的时候，就可能出现假性失效，或者出现缓存已经失效了，但是并未去请求最新资源

Cache-control ：HTTP/1.1 中新增的属性，属性值具有以下几个：

pragma ：不使用强缓存，需要验证缓存是否新鲜。（HTTP/1.1 之前版本的历史遗留字段，仅作为与 HTTP/1.0 的向后兼容而定义）

协商缓存都是由浏览器和服务器协商，来确定是否缓存，主要通过两组header字段，两组字段都是 成对出现 的，即第一次请求的响应头上带某个字段（Last-Modified 或 Etag），则后续请求会带上对应的请求字段（if-modified-since或者if-none-match），若响应头没有，则请求头也不会有对应的字段

①、解析 html，生成 DOM 树（浏览器不能直接理解和使用HTML，需要将HTML转换为浏览器能够理解的结构）
②、解析 CSS，生成 CSS 规则树
③、合并 CSS 和 DOM 树，生成render树
④、计算渲染树的布局（Layout/reflow），即各元素尺寸、位置的计算
⑤、绘制 render 树（paint），绘制页面像素信息
⑥、浏览器将各层信息发送给GPU,GPU将各层合成，显示在屏幕

注 ：
1 、render树的节点并不等同的dom树的节点，因为有些节点的display为none，那么在生成render树的时候，就不会将其加入到render树中
2 、 当我们浏览器获得HTML文件后，会自上而下的加载，并在加载过程中进行解析和渲染。
3 、 如果在加载过程中遇到外部CSS文件和图片，浏览器会另外发送一个请求，去获取CSS文件和相应的图片，这个请求是异步的，并不会影响HTML文件的加载。 不会阻塞DOM树的解析，会阻塞DOM树的渲染和后面js语句的执行 ，当计算样式的时候需要等待css文件的资源进行层叠样式，资源阻塞了，会进行等待，直到网络超时，network报出错误，渲染进程继续层叠样式计算。为了避免让用户看到长时间的白屏时间，应该提高css的加载速度：

4 、如果遇到javascript文件，HTML文件会挂起渲染的进程，等待JavaScript文件加载完毕后，再继续进行渲染。因为JavaScript可能会修改DOM，导致后续HTML资源白白加载，所以HTML必须等待JavaScript文件加载完毕后，再继续渲染，这也就是为什么JavaScript文件在写在底部body标签前的原因
5 、 每个页面至少需要一次回流，就是在页面第一次加载的时候。

1.第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2.第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

3.第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4.第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1， Server进入CLOSED状态，完成四次挥手。

参考： 前端进阶必看——详细版输入URL到界面展示的过程
简述浏览器渲染机制

HTTP面试-在浏览器输入url到页面展示

前言

上次说到 HTTP基础 概念相关的问题，这次非常简单的讲解一道超高频率的面试题。

在浏览器输入 url 到页面展示的过程 ,我主要从网络相关的层面去讲一下。

当你输入了 https://www.baidu.com 到页面显示出来一共发生了什么？

解析url

首先这个过程肯定是需要涉及到 「 客户端跟服务端的数据传输 」 的，数据传输的前提就是 「 双方建立连接 」 ，那么这个建立连接的过程是如何建立的呢？

1. 检查浏览器缓存中是否缓存过该域名对应的IP地址
2. 查看host文件有没有跟域名对应的规则（本地主机host文件中一般会存储经常访问的url到host文件中）。
3. 查看路由器里面有没有缓存。
4. 最后才发出DNS请求到本地DNS(域名分布系统)服务器 。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。

建立tcp连接

为什么要建立tcp连接呢？主要就是为了保证两端能够进行 「 可靠的传输 」 ，可靠的传输的基本，就是两端对数据的发送和接收的功能。

ssl / tls 证书

ssl / tls 是什么？大白话来说一下，在我们中国，身份证就是我们个人的专属身份的标志，同理，在网络中，为了确定连接那头的人是不是你要找的人，就会有一个大型的网上认证系统，ssl / tls 其实就是每个人自己服务器的 身份证， 确认了建立连接对面的人是你要的那个人，就是通过 ssl / tls 这个证书来确认的。

所以由于http的 「 明文传输 」 ，导致了一次普通的没有 身份证 的http的调用其实是不不够安全的，有可能会被恶意修改数据或者是截取信息，这个时候https来了，它主要就是通过 ssl / tls 提供验证服务端的身份，加密处理数据等等，只要服务端提前在ca机构注册好自己的 身份证， 就可以做到保证两端身份的确定性，就进行可靠安全的传输了。这里的话不细讲具体是如何加密的，简单说一下流程。

1. 客户端向服务端请求连接，请求头里面包含了客户端支持的加密解密类型等等。
2. 服务端根据客户端可接受的加密类型中，选择最合适自己的那一个，加密自己的私钥，并且存在证书里面，连同 「 证书 」 一起发给客户端。
3. 客户端收到证书之后，首先向权威 「 ca机构 」 验证证书的有效性，确认了服务端的身份后，将自己用来对称加密的公钥用证书返回的公钥加密，发送给服务端。

总的来说，就是确定了双方同时持有对称加密使用的公钥，就可以安全的进行传输了。

这里补充一下，假如服务端申请了客户端未信任的证书机构的话（也有可能自己制作ssl证书），客户端需要信任（或者直接拒绝访问了），而且自制的ssl证书容易被伪造的，不咋安全（毕竟没收到国际认证和电子签发许可），所以这也是一种可能被钓鱼的情况之一。

三次握手

三次握手的主要目的，就是确定 「 双方同时具备正常的收和发功能 」 的功能，需要站在客户端和服务端的角度来看这个为什么需要三次握手的问题，接下来说一下流程：

1. 客户端发送连接请求 「 你好服务器兄弟听得到吗 」 给服务端，服务端收到。

「 服务端的角度 」

服务端的角度：我服务端收到了客户端的消息，所以服务端是知道客户端的发是正常的，服务端自己的收也是正常的。

	客户端	服务端
收	X	正常
发	正常	X

「 客户端的角度 」

客户端的角度：不清楚自己发出去的服务端收到没，也不清楚自己能不能收到服务端的消息。

	客户端	服务端
收	X	X
发	X	X

---

2. 服务端发送 「 听得到啊，客户端兄弟听得到吗 」 给客户端，客户端收到了。

「 服务端的角度 」

服务端的角度:是只能确认自己的收是正常的，但是不确定客户端有没有收到自己发出去的东西。

	客户端	服务端
收	X	正常
发	正常	X

「 客户端的角度 」

客户端的角度:客户端是已经可以确认，客户端的收发的功能都是正常的，服务端的收发功能也是正常的。（此时客户端的角度已经确认好了）。

	客户端	服务端
收	正常	正常
发	正常	正常

---

3. 客户端发送 「 我也听得到 」 给服务端。

这个时候服务端才知道，客户端收到了，所以就确认了自己可以发数据给客户端。（此时服务端的角度也确认好了）。总的来说，照着 「 确定双方同时具备收和发的功能 」 这个思路说下去，三次握手就很好理解了。

「 服务端的角度 」

	客户端	服务端
收	正常	正常
发	正常	正常

「 客户端的角度 」

	客户端	服务端
收	正常	正常
发	正常	正常

---

数据传输。

连接建立后自然就是发送数据了，这时候客户端也就可以发送请求给服务端了，服务端收到对应的请求，（可能有代理）找到自己的对应的服务对应的端口去做相应的处理，并反回数据给客户端（tcp的拥塞机制）。

三次握手

四次挥手

四次挥手 「 连接终止协议 」 ，这个很好理解，主要就是确认双方都没有数据发送了。

为什么要四次挥手? 主要就是因为上面说到的三次握手，建立的连接是去确定双方同时具备收和发的功能来建立的一个通道，那么关闭这个通道肯定也是要双方去确认的，所以我们可以按照这个思路往下去整理。

1. 当客户端发起所有需要的请求后，决定关闭连接了，他向服务器发送了一个 「 我已经没啥要的了 」 。
2. 服务器收到后，要给客户端返回一个 「 收到 」。

其实这样的话是存在服务器数据还没发完数据的情况的，所以上面的两次挥手的主要作用只是断开了客户端的发，但服务器还是可以继续传输没传输完的数据。

3. 当服务器发送完所有之后，决定关闭连接了，他向客户端发送了一个 「 我也把东西都发完给你了 」。
4. 完了客户端也要回复一个 「 收到 」。

到此四次挥手就结束了，这里补充一张四次挥手的图给大家参悟一下。

四次挥手

最后

关于https相关流程可以看看 。

PS

都结合网上资料加上自己的一些理解，如果有影响到人的地方，可以联系我：[e-mail]