浏览器中地址框输入url地址会进行什么操作？

一、 http请求流程

http（超文本传输协议）是基于TCP协议之上的应用层协议。

1.1 url域名解析成ip地址（dns解析）

因为一般浏览器找到并访问服务器是通过ip地址，而不是通过域名。所以需要设法寻找到对应的ip地址，以此能够进行服务器的访问。

那么是怎么找到ip地址的呢?

是通过以下顺序一层层分别查找，若其中一层找到ip地址的话，则直接进入下一部分的TCP连接。

浏览器缓存→系统缓存→路由器→互联网服务提供商→递归查询

接下来，详细地叙述以下查找步骤

1. (浏览器缓存部分)查找浏览器缓存是否有输入该域名对应的ip地址（此缓存是否未过期），有则结束解析，反之则进入第2步。
2. (系统缓存)查找系统缓存是否有对应的DNS缓存（此缓存是否未过期），有则结束解析，反之则进入第3步。
3. (路由器)向局域网所归属路由器发送请求，请求有ip地址则结束解析，反之则进入第4步。
4. (互联网服务提供商)向局域网所归属路由器发送请求，请求有ip地址则结束解析，反之则进入第5步。
5. (递归查询)使用递归查询，以从根域名服务器到顶级域名服务器，从顶级域名服务器到所查询的服务器的形式，直至查到有ip地址则结束解析。

1.2 建立三次握手TCP连接

因为TCP是类似于面向连接的，是服务端与客户端之间安全的传输。只要建立起TCP连接，就证明双方能够正常地发出或接收数据。

正常互联网传输的报文格式会如下所示：

而确认双方地发出或接收数据，就是使用三次发送包地传输来确认的，俗称TCP的三次握手。

TCP的三次握手流程图如下所示：

根据上图的流程可以分为下面三步：

1. 客户端发送SYN/Seq的报文给服务端（SYN=1,Seq=X），此时服务端判断客户端的发送正常。
2. 服务端接收到第1步报文，并给客户端发送SYN/ACK/Seq报文（SYN=1,ACK=1,ack=X+1,Seq=Y），此时客户端判断服务端的发送与接收正常。
3. 客户端接收到第2步报文，并给服务端发送ACK/Seq报文（ACK=1,ack=Y+1,Seq=X+1），此时客户端判断服务端的发送与接收正常，服务端判断客户端的发送与接收正常。

1.2.1 报文中SYN,Seq,ack,ACK

在TCP三次握手会使用到的有：
① SYN（synchronous）：当为1时，表示确定自己需要建立连接请求。
② Seq（Sequence number 顺序号码）：表示自己所发送的数据。
③ ack（Acknowledge number 确认号码）：表示对方所发送的数据。
④ ACK（acknowledgement 确认）：当为1时，表示确定接收到请求。

1.2.2 为什么需要使用三次握手？

是为了确保服务端与客户端的之间连接正常，防止互相发送错误的报文连接出错。

反正要是以下一次、两次握手会有以下情况发生：

• 一次握手：服务端值只判断到客户端的发送正常。
• 两次握手：服务端值只判断到客户端的发送正常，客户端只判断到服务端的发送与接收正常。

所以需要三次握手，用平时俗一点的交流就是：
客：服务端你在不？我要连接。
服：我在，我会和你建立连接。
客：好的，我收到你的答复了，可以开始连接了。

1.3 发送http请求

浏览器中地址框输入url地址时，一般执行的都是get请求，打开网页仅仅是从服务器后端获取页面数据进行解析。在服务端与客户端都建立了TCP连接之后，就会进行发送相应的HTTP请求。
既然讲到http请求，我们就这方面进行更深入地叙述一下接口请求地原理。
请求方式一般会分为：get,post,put,delete,options,head等，一般项目都会使用get,post请求。
项目的请求地址是使用 <协议（http或者https）>：//<主机>：<端口>/<路径（前端设置页面的路径名称）>?<参数（前端存放get请求时所使用的参数）> 组成。

例如当我们输入百度时，观察控制台，可以查看到获取百度首页对应的请求地址以及请求方式，如下图所示：

1.3.1 http请求中的get请求与post请求区别

get：
1.一般用于获取数据库的数据，请求数据是静态资源时会有缓存。
2.前端请求的参数是放在url上，用户实际上是能够看到请求的参数内容，所以安全性不太好。
3.请求数据使用长度限制的，一般是在1k以内。
4.可以收藏为浏览器书签，因为请求地址与参数都在url上，可以保存进浏览器浏览历史上。
5.浏览器后退与刷新操作，对数据无影响。
6.编码格式为application/x-www-form-urlencoded。
7.请求的参数只允许ASCII字符传输的。
8.发送请求时，会把http header与data一并发送出去。（一个TCP数据包）

post:
1.一般是用于增加，修改，删除等数据的操作。
2.前端请求的参数是放在http消息主体上发送的，而不是书写在body上，所以安全性较为安全。
3.请求数据没有长度限制（数据长度是根据浏览器与服务器决定的）
4.不可以收藏为浏览书签，因为请求参数不是书写在请求地址上，既是访问也会页面报错。
5.浏览器后退与刷新操作，会再次向后端发送请求，既是再次修改数据库中的数据。
6.编码格式不仅有application/x-www-form-urlencoded，还有multipart/form-data编码形式。
7.请求的参数没有限制。
8.发送请求时，先会把http header发出去，当后端返回状态码100表示可以继续时，再把data发送过去。（两个TCP数据包）

1.4 服务器处理请求，并进行相应的响应请求

一般执行数据请求后，要是不存在跨域、请求接口不存在与请求接口超时的话，都会从后端返回一个状态码，msg操作提示以及返回data。
状态码基本如下：

• 1XX：（指示信息）代表请求已经接收到了，会进行进一步的处理。
• 2XX：（成功）代表请求成功，并已返回相应的数据。
• 3XX：（重定向）要继续请求，需要进行进一步的操作。
• 4XX：（客户端错误）请求接口有书写错误，或者是参数错误（值，类型或者格式）无法进行请求操作。
• 5XX：（服务端错误）服务器未能实现合法请求。

例如当我们输入百度时，观察控制台，可以查看到获取百度首页的请求状态码，如下图所示：

个人经验分享：
一般前端对接接口返回状态码不是2XX的时候，要以下进行逐步分析，进行排查。
1.先观察后端返回结果有没有提示php哪几行报错，有即与后端爸爸沟通
2.接口请求地址书写错误
3.请求方式是为get类型还是post类型
4.参数放置位置是否正确，是放在http消息主体上还是url后面拼接
5.要是为get请求，传输的数据格式是否转换为ASCII码形式
6.对应的编码格式是否正确
7.传送的参数，数值，类型，格式是否与后端书写的接口文档保持一致
8.要是以上所有都排查没问题，就与后端爸爸沟通以下，是不是数据业务处理有问题等。

1.5 浏览器进行数据解析并进行页面渲染

先大致了解以下具体流程，具体流程图如下所示：

具体的解析流程会分成以下个部分：

1. 根据HTML数据解析，生成对应的DOM树。
2. 根据CSS数据解析，生成对应的CSSOM树。
3. 遍历每一层DOM树的NODE节点，并且计算出该节点下的所有样式，生成一个每个节点含有最终样式的DOM树。（DOM树与CSSOM树相应结合）
4. 对于含有样式的DOM树，根据它所在的页面计算坐标位置以及页面前后位置进行分层，生成对应的Layout树。
5. 最后对页面进行生成绘制指令，页面区域进行分块，对所处的分块光栅化(GPU加速确认每个像素点的rgb信息)，最后进行对页面的绘制操作。

数据解析到渲染页面底层的操作流程可能繁琐，之后会找天重点去详细叙述数据此步骤。

1.6 四次挥手断开TCP连接

在断开TCP连接时，是进行四次挥手操作。TCP四次挥手流程图如下所示：

根据上图流程图可以分为以下四步：

1. 客户端发送FIN/seq的报文给服务端（FIN=1，seq=x），此时为客户端向服务端表明需要断开连接，而服务端已经知道客户端需要断开连接。
2. 服务端接收到第1步的报文，向服务端发送ACK/ack/seq报文（ACK=1，seq=y,ack=x+1），此时客户端知道服务端已经接到请求断开连接的操作，并等待服务端最后一段数据传输完成。
3. 一段时间后，服务端继续向客户端发送ACK/FIN/ack/seq报文（ACK=1,FIN=1,seq=z,ack=x+1）,此时客户端已经知道服务端把最后一段数据传输完成了，而服务端在等待客户端最后一段数据传输完成的确认。
4. 客户端接收第3步的报文之后，向服务端发送报文ACK/ack/seq报文（ACK=1，ack=z+1,seq=x+1）,此时客户端发送完即等待一段时间并转换成关闭状态，而服务端在接收到客户端传输完成的确认（第4步的报文）就会转换成关闭状态。

1.6.1 报文中FIN

在TCP四次挥手会使用到的有SYN，Seq，ack，ACK，FIN（SYN，Seq，ack，ACK在三次握手1.2.1有叙述，这里只分析FIN）：
① FIN：当1的时候，表示自己需要确定断开连接。

1.6.2 为什么需要使用四次挥手？

防止数据传输不完整资源浪费，或者客户端，服务端是否能正常关闭。

反正要是以下一次、两次，三次挥手会有以下情况发生：

• 一次挥手：客户端无法确认服务端是否收到断开连接请求，以及服务端所有数据是否传输完成。
• 二次挥手：客户端虽然确认收到服务端的第一次挥手，但此时不能直接关闭，因为服务端所有数据还没有传输完成。
• 三次挥手：客户端虽然知道服务端知道断开连接请求，客户端也拿到服务器传过来的所有数据，但没有告诉服务器自己已经接收到最后一批数据。

所以需要四次挥手，用平时俗一点的交流就是：
客：在不？我需要断开连接了。
服：我知道你需要断开连接，这次的数据是XXX。
服：这次的数据是YYY，我已经把所有数据传给你了，你可以准备断开连接了。
客：好的，我这边已经接收到最后数据YYY，我会等待一段时间等你回应，以防你听不到我这段话。如果都没问题我就关闭连接了，服务端你那边也可以自己关闭服务端了，不用等我回应。

1.6.3 为什么服务端接收到第一次挥手时状态会进入CLOSE-WAIT？

因为此时服务端不确定客户端与服务端的数据是否完全传输完毕，所以不会马上发出有关FIN=1的报文，马上执行关闭连接流程，而是进入CLOSE-WAIT状态。

1.6.4 为什么客户端发出第四次挥手时状态会进入IME-WAIT，而不是马上关闭?

因为客户端此时防止发送第四次挥手的报文丢失，而服务端重新发送第三次挥手的ACK/FIN/ack/seq报文。
若是客户端直接关闭了，就接收不到服务端报文，而服务端一直在等待客户端的第四次挥手。服务端传输状态没有关闭，就会造成资源浪费。