从输入URL到浏览器完成页面渲染发生了什么？

最新推荐文章于 2024-07-22 06:48:36 发布

钧桐

最新推荐文章于 2024-07-22 06:48:36 发布

阅读量348

点赞数 5

分类专栏：面试之我的大厂梦文章标签： http node.js tcp/ip

本文链接：https://blog.csdn.net/qq_42136832/article/details/120308041

版权

面试之我的大厂梦专栏收录该内容

30 篇文章 9 订阅

订阅专栏

从输入URL到浏览器完成页面渲染发生了什么？

写在前面
让我们走进输入url到浏览器完成页面渲染的过程

写在前面

计算机网络无论找什么工作都要问的，标题这个问题比较基础，但是又比较能够有一种整体的感觉。

让我们走进输入url到浏览器完成页面渲染的过程

1.DNS解析：将域名解析成IP地址
2.TCP连接：TCP三次握手
3.发送HTTP请求
4.服务器处理请求并返回HTTP报文
5.浏览器解析渲染页面
6.断开连接：TCP四次握手

输入url后，首先需要找到这个url域名的服务器ip，为了寻找这个ip，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查询记录为：浏览器缓存—系统缓存—路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录，如果没有则查询DNS服务器

得到服务器的ip地址后，浏览器根据这个ip以及相应的端口号，构造一个http请求，这个请求报文会包括这次请求的信息，主要是请求方法，请求说明和请求附带的数据，并将这个http请求封装再一个tcp包中，这个tcp包会依次经过传输层，网络层，数据链路层，物理层到达服务器，服务器解析这个请求来作出响应，返回相应的html给浏览器

浏览器拿到HTML后，遇见HTML和CSS之后渲染引擎会立即解析，如果遇到CSS连接会发起请求连接并继续解析剩下代码，等下载完后，则解析下载的，等遇到js代码则会停下来用JS解析器解析js代码，当遇到JS连接则会停下来下载JS等下载完后才继续解析，

因为html是一个树形结构，浏览器根据这个html来构建DOM树，在dom树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM树来执行和下载相应的代码，这会造成阻塞，这就是为什么推荐JS代码应该放在html代码的后面，之后根据外部样式，内部样式，内联样式构建一个CSS对象模型树CSSOM树，构建完成后和DOM树合并为渲染树，这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点，之后进行布局，布局主要是确定各个元素的位置和尺寸，之后是渲染页面，因为html文件中会含有图片，视频，音频等资源，在解析DOM的过程中，遇到这些都会进行并行下载，浏览器对每个域的并行下载数量有一定的限制，一般是9-6个，当然在这些所有的请求中我们还需要关注的就是缓存，缓存一般通过Cache-Contorl，Last-Modify，Expires等首部字段控制。Cache-Control和Expires的区别在于Cache-Control使用相对时间，Expires使用的是基于服务器端的绝对时间，因为存在时差问题，一般采用Cache-Control，在请求这些有设置了缓存的数据是，会先查看是否过期，如果没有过期则直接使用本地缓存，过期则请求并在服务器校验文件是否修改，如果上一次响应设置了ETag值会在这次请求的时候作为If-None-Match的值交给服务器校验，如果一致，继续校验Last-Modified，没有设置ETag则直接验证Last-Modified，再决定是否返回304

DNS解析

域名为什么要解析成ip？因为相对于带有字母和数字的字符串，计算机更擅长处理数字，DNS服务应运而生

三次握手

1.第一次：发送端首先发送一个带SYN标志的数据包给对方
2.第二次：接收端收到后，回传一个带有SYN/ASK标志的数据包以示传达确认信息
3.第三次：发送端再回传一个带ASK标志的数据包，代表“握手”结束。若在握手过程中某个阶段莫名终端，TCP协议会再次以相同的顺序发送相同的数据包

在这里插入图片描述

为什么握手是三次，而不是两次或者四次？

两次不安全，四次没必要
tcp通信需要确保双方都具有数据收发的能力，得到ACK响应则认为对象具有数据收发的能力，因此双方都要发送SYN确保对面具有通信的能力。第一次握手是客户端发送SYN，服务端接收，服务端得出客户端的发送能力和服务端的接收能力都正常；第二次握手时服务端发送SYN+ACK，客户端得出客户端发送接收能力正常，服务端发送接收能力也都正常，但是此时服务器并不能确认客户端的接收能力是否正常；第三次握手客户端发送ACK，服务器接收，服务端才能得出客户端发送接收能力正常，服务端自己发送接收能力也都正常。

三次握手可以携带数据吗？

第一次，第二次握手不可以携带数据，而第三次握手时可以携带数据的。假设第一次可以携带数据，如果有人恶意攻击服务器，每次都在第一次握手中的SYN报文放入大量数据，重复发送大量SYN报文，此时雾浮起会花费大量内存空间来缓冲这些报文，服务器就更容易被攻击了

tcp三次握手失败，服务端会如何处理？

握手失败的原因有两种：

第一种是服务端没有收到SYN，则什么都不做；
第二种是服务端回复了SYN+ACK后，尝试后没有收到ACK响应，则超时后就会发送RST重置连接报文，释放资源

ISN代表什么？意义何在？ISN是固定不变的吗？ISN为何要动态随机？

ISN全程是 Initial Sequence Number，是TCP发送方的字节数据编号的原点，告诉对方我要开始发送数据的初始化序列号，ISN如果是固定的，攻击者很容易猜出后序的确认号，为了安全起见，避免被第三方猜到从而发送伪造的RST报文，因此ISN是动态生成的

什么是半连接队列？

服务器第一次收到客户端的SYN之后，就会处于SYN_RECD状态，此时双方还没有完全建立连接。服务器会把这种状态下的请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起来的连接就会放在全连接队列中，如果队列满了救有可能出现丢包现象。

四次挥手

1.第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的时候，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接收数据
2.第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)
3.第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了
4.第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此完成四次挥手

为什么握手是三次，而挥手时需要四次呢？

其实在TCP握手的时候，接收端将SYN包和ACK确认包合并到一个包中发送的，所以减少了一次包的发送。对于四次挥手，由于TCP时全双工通信，主动关闭方发送FIN请求不代表完全断开连接，只能表示主动关闭方不再发送数据了。而接收方可能还要发送数据，就不能立即关闭服务器端到客户端的数据通道，所以就不能将服务端的FIN包和客户端的ACK包合并发送，只能先确认ACK，等服务器无需发送数据时在发送FIN包，所以四次挥手时需要四次数据包的交互

TIME_WAIT状态有什么作用，为什么主动关闭方没有直接进入CLOSED状态释放资源？

如果主动关闭方进入CLOSED状态后，被动关闭方发送FIN包后没有得到ACK确认，超时后会重传一个FIN包。如果客户端没有TIME_WAIT状态而直接进入CLOSED状态释放资源，下次启动新的客户端就可能使用了与之前客户端相同的地址信息，有两个危害，第一种是这个刚启动的新的客户端绑定地址成功时，就会收到一个重传的FIN包，它对新连接就会造成影响。第二种时如果该新客户端向相同的服务端发送SYN连接请求，但是此时服务端处于LAST_ACK状态，要求收到的是ACK而不是SYN，因此就会发送RST重新建立请求

为什么TIME_WAIT状态需要经过2MSL才能进入CLOSED状态？

MSL指的是报文在网络中最大生存时间。在客户端发送对服务端的FIN确认包ACK后，这个ACK包有肯能到达不了，服务器端如果接收不到ACK包就会重新发送FIN包。所以客户端发送ACK后需要留出2MSL时间(ACK到达服务器+服务器发送FIN重传包，一来一回)
等待确认服务器端缺失收到ACK包，也就是说客户端如果等待2MSL时间也没有收到服务器端重传的FIN包，则就可以确认服务器已经收到客户端发送的ACK包