为什么输入url就可以展现对应的页面呢？背后经历了什么？

总体为以下几个过程

• DNS解析： 将域名解析成Ip地址
• tcp连接： tcp三次握手
• 发送http请求
• 服务器处理请求并返回http报文
• 浏览器解析渲染页面
• 断开连接：tcp四次挥手

一、DNS域名解析

在浏览器输入网址（URL）后，首先要经过域名解析，因为浏览器只能通过IP地址找到对应的服务器，输入的是域名，那么就需要解析成IP地址。

DNS协议就是通过域名查找IP地址，或者逆向通过IP地址查找域名的服务。
DNS 是一个网络服务器（域名服务器），我们的域名解析简单来说就是在DNS服务器上记录一条信息记录

二、建立TCP连接（三次握手）

在客户端发送数据之前会发起TCP三次握手用以同步客户端和服务端的序列号的确认号，并交换TCP窗口大小信息。

• 第一次握手，由浏览器发起，告知服务器，我要发送请求了（浏览器发送一个带SYN=1，Seq=x的数据包到服务器）
• 第二次握手，由服务器发起，告知浏览器，我准备接收了，你发送吧（服务器发回一个带SYN=1，ACK= X+1，Seq=Y的响应包以示传达确认信息）
• 第三次握手，由浏览器发起，告知服务器，我马上就要发了，你准备好接收吧（浏览器再传回一个带ACK=Y+1，Seq=Z）

两次就可以建立连接，为什么需要三次握手呢？
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误

考虑这样子的一种情况，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

三、发送HTTP请求

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

四、服务器处理请求并返回HTTP报文

对于不同用户发送的请求，会结合配置文件，把不同请求委托给服务器上处理相应请求的程序进行处理（例如 CGI 脚本，JSP 脚本，servlets，ASP 脚本，服务器端 JavaScript，或者一些其它的服务器端技术等），然后返回后台程序处理产生的结果作为响应信息。

响应信息会以响应报文的形式返回给客户端，最后浏览器通过渲染引擎将网页呈现在用户面前

响应报文由响应行（request line）、响应头部（header）、响应主体三个部分组成

五、浏览器拿到响应的数据（HTML）后，开始处理渲染页面

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

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

六、断开连接

• 第一次挥手：由浏览器发起的，发送给服务器，我请求报文发送完了，你准备关闭吧（发起方向被动方发送报文，Fin、Ack、Seq，表示已经没有数据传输了。并进入 FIN_WAIT_1 状态）
• 第二次挥手：由服务器发起的，告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧（被动方发送报文，Ack、Seq，表示同意关闭请求。此时主机发起方进入 FIN_WAIT_2 状态。）
• 第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧（被动方向发起方发送报文段，Fin、Ack、Seq，请求关闭连接。并进入 LAST_ACK 状态。）
• 第四次挥手：由浏览器发起，告诉服务器，我响应报文接受完了，我准备关闭了，你也准备吧（发起方向被动方发送报文段，Ack、Seq。然后进入等待 TIME_WAIT 状态。被动方收到发起方的报文段以后关闭连接。发起方等待一定时间未收到回复，则正常关闭。）