从URL输入到前端页面显示到底发生了什么?

**总的来说可以分为以下几个过程**

• DNS解析：将域名解析为 IP 地址
• TCP连接：TCP 三次握手
• 发送HTTP请求
• 服务器响应并返回HTTP报文
• 浏览器解析报文渲染页面
• 断开链接：TCP 四次挥手

一、URL是什么

URL（Uniform Resource Locator）,统一资源占位符，用于定位网络上的资源，俗称网址。
例如：https://www.csdn.net；遵循以下的语法规则：

scheme://host.domain:port/path/filename，各个部分解释如下

• scheme：因特网服务类型，常见的协议有 http、https、ftp、file，其中最常见的是http，而https则是加密的网络传输；
• host：域主机（http默认的是www）；
• domain：因特网域名，如csdn.net；
• port：主机端口号（http默认的端口号是80）；
• path：服务器上的路径（如果省略，则文档必须位于网站的根目录中）；
• filename：文档/资源的名称。

二、域名解析

在浏览器输入网址后，首先要进过域名解析，因为浏览器不能通过域名直接找到对应的服务器地址，而是要通过IP地址。那怎么把域名解析为IP地址的呢？DNS协议可以通过域名查找IP地址，DNS是一个网络服务器，我们的域名解析简单的来说就是在DNS的一条信息记录。

例如：csdn.net 47.95.164.112（服务器外网地址） 80（服务器端口号）

那浏览器如何通过域名去查询 URL 对应的 IP 呢

• 浏览器缓存：浏览器会按照频率去缓存 DNS 记录；
• 操作系统缓存：如果浏览器缓存中找不到 DNS 记录，那就会去操作系统中找；
• 路由缓存：路由器也有 DNS 的缓存；
• ISP的DNS服务器：ISP 是互联网服务器提供商（Internet Service Provider）的简称，ISP 有专门的DNS 服务器对应 DNS 查询请求；
• 根服务器：ISP 的 DNS 服务器还找不到的话，它就会向根服务器发送请求，进行递归查询。
  

浏览器先向 DNS 服务器发送域名，DNS 服务器查询到域名对应的 IP 地址，然后返回给浏览器， 浏览器将IP地址打在协议上，同时请求参数也在协议中搭载，然后一并发送给对应的服务器。接下来就是向服务器发送 HTTP 请求阶段，这个阶段分为三部分，TCP 三次握手，HTTP 请求响应信息，TCP 四次挥手。

三、TCP三次握手

1.TCP三次握手过程如下：

• 客户端发送一个带 SYN=1，Seq=X 的数据包到服务器端口（第一次握手，由浏览器发起，告诉服务器我要发送请求了）
• 服务器发回一个带 SYN=1，ACK=X+1，Seq=Y 的响应包表示传达确认信息（第二次握手，由服务器发起，告诉浏览器我准备接受了，你可以发送了）
• 客户端再回传一个 ACK=Y+1,Seq=Z 的数据包，代表“握手结束”（第三次握手，由浏览器发送，告诉服务器，我马上就发了，你准备接受吧）。

2.为啥需求三次握手呢？

谢希仁著的《计算机网络》中将“三次握手”的目的是为**防止已失效的连接请求报文段突然又传送到了服务器，因而
产生错误。

四、发送 HTTP 请求

TCP 三次握手结束后，开始发送 HTTP 请求报文，请求报文由请求行（request line）、请求头（header）、请求体三个部分组成。

1.请求行包含请求方法、URL、协议版本

• 请求方法包含8种：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
• URL即请求地址，由 <协议>：//<主机>：<端口>/<路径>?<参数> 组成
• 协议版本即http协议号，现在常用的协议号是Http 1.1版本

2.请求头包含请求的附加信息，由关键字/值对组成，每行一对

请求头部通知服务器有关于客户端的请求信息。它包含许多有关客户端环境和请求正文的有用信息。其中比如 Host，表示主机名，虚拟主机；Connection,当值为 keepalive,即持久连接。

3.请求体，可以承载多个请求参数的数据，并不是所有请求都具有请求数据
如：username=cxs&password=sxc,这就表示有两个请求参数

五、服务器处理并返回HTTP报文

HTTP响应报文由响应行（response line）、响应头、响应主体三个部分组成。如下：

1.响应行包含：协议版本、状态码、状态码描述

状态码规则如下：1XX：指示信息–表示请求已接受，继续处理；2XX：成功–表示请求已被成功接收；
3XX：重定向–要完成请求必须进行进一步操作；4XX：客户端错误–请求有语法错误或请求无法实现；
5XX：服务器端错误–服务器未能实现合法的请求。

2.响应头部包含响应报文的附加信息，由名/值 对组成

3.响应体包含回车符、换行符和响应数据，并不是所有的响应报文都有响应数据

六、浏览器解析渲染页面

浏览器拿到响应文本HTML后，接下来就接收浏览器渲染机制

浏览器解析渲染页面分为下面五个步骤：

• 根据 HTML 解析出 DOM 树
• 根据 CSS 解析生成 CSS 规则树
• 结合 DOM 树和 CSS 规则树生成渲染树
• 根据渲染树计算每一个节点的信息
• 根据计算好的信息渲染页面

1.根据 HTML 解析 DOM 树

• 根据 HTML 的内容，将所有标签解析成 DOM 树，DOM 树解析的过程是一个深度优先遍历，即构建当前节点的所有字节点，再构建下一个兄弟节点。
• 在读取 HTML 文档，构建 DOM 树的过程中，如遇到 script 标签，则 DOM 树的构建会暂停，直到脚本执行完毕。

2.根据 CSS 解析生成 CSS 规则树

• 解析 CSS 规则树 JS 执行将暂停，直至 CSS 规则树就绪。
• 浏览器在 CSS 规则树生成之前不会进行渲染。

3.结合 DOM 树和 CSS 规则树，生成渲染树

• DOM 树和 CSS 规则树全部准备好了以后，浏览器才会开始构建渲染树。
• 精简 CSS 可以加快 CSS 规则树的构建，从而加快页面的响应速度。

4.根据渲染树计算每一个节点的信息（布局）

• 布局：通过渲染树中渲染对象信息，计算出每一个渲染对象的尺寸
• 回流：在布局完成后发现某个部分发生了变化影响了布局，那就需要倒回去重新渲染。

5.根据渲染好的信息绘制页面

• 绘制阶段，系统会遍历呈现树，并调用呈现器 “paint” 方法，将呈现器的内容显示在屏幕上。
• 重绘：某个元素的背景颜色，文字颜色等，不影响元素周围或内部布局的属性，将只会触发浏览器的重绘。
• 回流：某个元素的尺寸发生了变化，则重新计算渲染树，重新渲染。

七、断开连接（TCP 四次挥手）

1.四次挥手详述

假设 Client 端发起中断连接请求，也就是发送 FIN 报文。Server 端接到 FIN 报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭 Socket，可以继续发送数据。所以你先发送 ACK，“告诉 Client 端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候 Client 端就进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。当 Server 端确定数据已发送完成，则向Client端发送FIN报文，“告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果 Server 端没有收到ACK则可以重传。“，Server 端收到 ACK 后，“就知道可以断开连接了”。Client 端等待了2MSL后依然没有收到回复，则证明 Server 端已正常关闭，那好，我 Client 端也可以关闭连接了。TCP 连接就这样关闭了！

数据传输结束后，通信的双方都可释放连接，A和B都处于ESTABLISHED状态。（A、B连接建立状态ESTABLISHED——A终止等待1状态FIN-WAIT-1——B关闭等待状态CLOSE-WAIT——A终止等待2状态FIN-WAIT-2——B最后确认状态LAST-ACK——A时间等待状态TIME-WAIT——B、A关闭状态CLOSED）

• A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
• B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
• A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
• B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
• A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

2.总结四次挥手过程：

起初A和B处于 ESTABLISHED 状态——A发出连接释放报文段并处于FIN-WAIT-1状态——B发出确认报文段且进入CLOSE-WAIT状态——A收到确认后，进入FIN-WAIT-2状态，等待B的连接释放报文段——B没有要向A发出的数据，B发出连接释放报文段且进入LAST-ACK状态——A发出确认报文段且进入TIME-WAIT状态——B收到确认报文段后进入 CLOSED 状态——A经过等待计时器时间2MSL后，进入CLOSED状态。

3.为什么 A 在TIME-WAIT状态必须等待 2MSL的时间？

MSL最长报文段寿命 Maximum Segment Lifetime，MSL=2

• 保证A发送的最后一个ACK报文段能够到达B。
• 防止“已失效的连接请求报文段”出现在本连接中。
• 这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的 FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。
• A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

4.为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

5.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

注：本文大部分转载 公众号 前端技术优选
其中TCP四次挥手转载 https://www.cnblogs.com/Andya/p/7272462.html