[ WEB ] 从地址栏输入 URL 之后发生了啥？

从浏览器到服务器的整体过程感觉是一个前端开发的最基础知识，越是基础越是容易让人忽略，这里也做个思路笔记。

域名判断

在输入地址栏之前，浏览器会对输入的内容进行检查，如果是一个符合格式的正确 url 就会执行 DNS解析，如果不是，比如输入了一些字符串，那么就会执行搜索功能。如图：

DNS 解析

DNS 解析过程

首先，在访问一个网站的时候并不是只靠一个网址就可以找到对应的服务器，而是需要一个 ip地址。网址只是为了方便大家记忆，而并不是一个准确的地址。

比如，我需要打电话给某个人，我知道这个人的名字是没有用的，我必须通过电话本查找到他的电话号码，我才能打给他。而这个对应过来就是

• 人名 就是 网址
• 电话号码 就是 IP
• 查找电话本 就是 DNS 解析

而DNS 的解析又不是像查电话本那样从头查到尾那么简单，而是一层层逐级向上的查找，下面是我画的一张 DNS 解析流程图。

首先，在浏览器输入 www.qq.com 之后 ，输入的 url 符合地址格式执行 DNS解析。而 DNS 解析的解析步骤为：

• 第一步：查找本地域名服务器，查看 www.qq.com 这个域名的 ip是多少。有则返回 IP 地址，无则执行下一步。
• 第二步：查找根域名服务器，查看 www.qq.com 这个域名的 IP 是多少 ，有则返回 IP 地址，无则执行下一步。
• 第三步：查找顶级域名服务器，查看 www.qq.com 这个域名 IP 是多少 ，有则返回 IP 地址 ，无则执行下一步。
• 第四步：由顶级域名服务器得知域名服务器地址，再从查找域名服务器中查找到 IP地址返回。

这里也说明一下，一个 url 是怎么分根域名，和顶级域名的。

例如： 这个域名 ： www.ac.qq.com

他的域名分布是这样的 ： www( 主机 ). ac( 三级域名 ). qq( 二级域名 ) .( 根域名 ) .com( 顶级域名 )

DNS 优化

DNS 缓存和 DNS 重定向是 DNS 优化的重要手段，其核心就是减少请求次数。

DNS 缓存

从上面的流程得知，DNS的解析是层层向上，查找到再返回 ip 地址。那么，在这个过程中也可以将找到的 ip 地址保留下来，下次就可以直接地读取。

DNS 缓存就是把查找到的 IP 地址，临时保存下来，而保存这个 ip 的也有很多的环节。比如，浏览器缓存，客户端系统本身的缓存，路由器缓存，根域名服务器缓存 ，ISP 服务器缓存。

比如，浏览器缓存，二次请求的时候，就不需要层层解析了，浏览器已经记下了这个服务器的 ip 地址，直接访问即可。

DNS 重定向

DNS 重定向就是把请求的距离缩短，可以根据距离用户最近或者是负载量较小的服务器给出相应的 ip 地址，这个也叫 DNS负载均衡。

一直所用到的 CDN 资源，利用的也是这个原理，DNS 服务器会返回一个用户最近的 ip 地址，CDN节点的服务器负责响应提供数据。

确认连接（三次握手）

在经过了 DNS 的解析之后，确认了服务器的位置之后，就开始发起请求，而这个过程我们称为 “三次握手”。

有一次脱口秀上有个叫庞博的工程师，他用最简单的语言解释了什么是三次握手，我到现在还记得，是这样说的，有个人在敲门：

• 叩 叩 叩，请问有人在吗？
• 有人在。
• 好的。

这个就是三次握手。

下面还是简述一下什么是三次握手的过程，如图：

• 第一次请求：客户端发送一个 SYN=1,Seq=X 的数据给到服务器，成为第一次握手
• 第二次请求：服务器返回一个 SYN=1 ，ACK=X+ 1的响应包表示已经接收到了请求，称为第二次握手
• 第三次请求：客户端再发回一个 ACK=Y + 1，Seq= Z 的数据包，表示确认握手结束。

之所以需要三次而不是两次，是因为要防止已经失效的请求报文又传递给了服务器。就比如，客户端发了一个请求 A 给服务器，请求 A 因为延迟等关系还没有到达服务器，

这个时候，客户端又发送了一个 请求 B ，这个时候服务器先接收到了。

收到之后，请求 A 也到了，而服务器会误以为 是一个新的请求，那么就和 A连接上了，并且向客户端发送确认，但此时客户端的请求已经不是之前的那一次，就会产生错误。

发送请求

在进行了三次握手的确认之后，就开始发起 请求报文。HTTP 的请求就是构建请求报文同时通过 tcp

协议发送到指定的服务器端口。

HTTP协议是80/8080，HTTPS的端口是443

请求的报文是由请求行，请求头，请求空行和请求体组成的。

• 请求行：请求行里面有 url 信息和 请求的方法，比如 post get put delete等方法。
• 请求头：包含一些附加的信息例如常用的 Cookie, User-Agent , Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization等参数，
• 请求体：包含一些参数信息，现在请求的数据格式一般为json，就需要设置Content-Type: application/json。

服务器返回数据

响应报文

响应报文由响应行、响应头部、响应主体三个部分组成。

• 响应行：包含了一些状态码协议和版本
• 响应头：包含了一下附加信息，其中包括 Connection 这个会返回一个keep-alive 告诉浏览器连接上了之后不需要断开TCP连接
• 响应体：内容数据的存放仓库，比如一些字符串或者是一些静态资源。

相应的状态码 大致的参数解释就是：

• 1xx 为请求已经成功地接收；
• 2xx 表示请求成功
• 3xx 表示重定向
• 4xx 表示客户端错误
• 5xx 表示服务器错误

前端的同学只要看到 5xx， 那么就是时候去找你的后台好基友了。

浏览器渲染

浏览器是一遍解析一遍渲染的一个过程，浏览器在拿到 html 文本之后 就会进行解析，之后再加载其他的 css 或者 js 等文件。

请求的时候根据浏览器的不同，并发的请求数量也不一样，比如像谷歌浏览器的并发请求是6次。加载回来的资源也不一定是按顺序回来，有一些体积比较小的文件可能就会优先回来。

这里有个小点，就是问什么很一般会把js 文件的加载放在底部，是因为要确保节点生成之后才进行一些节点的操作，否则在节点还没有生成的时候执行绑定操作是会失效的。

渲染过程

页面渲染的过程，大致分为 5个过程：

1. 根据HTML 解析生成 DOM 树；
2. 根据 CSS 解析生产 CSS规则树；
3. 集合 DOM 树和 CSS 规则树 生成 render tree ；
4. 根据 render tree 计算节点信息；
5. 根据已经计算好的节点信息绘制渲染；

整理如图：

这里的 layout 为什么是双线箭头，是因为如果布局节点发生变化就会触发回流计算，之后再执行 paint 。

断开连接

四次挥手

当数据传送完毕，这个时候就需要断开 tcp 协议，也称四次挥手，过程是：

1. 由主动方发起 FIN,ACK,SEQ 报文，表示数据已经传输完毕，第一次挥手。
2. 被动方接收同时发起ACK,SEQ 报文 表示同意关闭，第二次挥手。
3. 被动方请求关闭连接，第三次挥手。
4. 主动方确认关闭的报文之后，关闭连接，第四次挥手。

如下图：

总结

HTTP 协议如果深挖其实还有很多东西，一般也不需要全部吃得透透的，但是大致的流程还是要了解。至少要说得清楚是怎么一回事。

image 的草莓千层雪太甜了。。

欢迎小伙伴在我的后台留言 @GavinUI