输入url到页面渲染前半段

前言

当我们输入url到页面渲染的时候,电脑其实做了很多操作,其中就包括了后半段,生成dom树,cssom树,render树,回流,重绘,这个我们已经聊完了,附上链接:输入url到页面渲染后半段:回流,重绘,优化【一次性带你搞明白】 - 掘金 (juejin.cn)

本期就来把前半段给细细聊明白,这也是老八股了,面试官很喜欢问这个东西,年年如此,经久不衰......

输入url到页面渲染

url解析

首先就是判断用户输入的url是否合法,一个合法的url的样子如下

https://juejin.cn/user

  • 协议号

    https://是协议号,多了个s指的是TLS,相比较httphttps进行了加密

  • ip

    ip因为很难记住,因此人们用域名来进行代替

  • 端口

    默认端口号是80。协议号,ip,端口是同源策略三要素

  • 路径

    比如user页,home

dns解析

DNS(Domain names Systems)就是将域名对应的ip地址找到来

dns解析也有好几个步骤,这些步骤目的都是去找到对应的ip来,比如我访问baidu.com

  1. 去操作系统的本地缓存中查找ip

    这就相当于第一次访问一个新的地址,浏览器会帮你把地址域名对应的ip映射关系存入本地中,这样日后再次访问就不需要查找了

  2. 去系统配置的dns服务器(或缓存)中查询

  3. 去根服务器中查询

  4. com顶级域名服务器中查找

  5. 去到baidu.com这个域名服务器中查找

tcp三次握手

此时已经拿到了对方的ip,接下来就是通过tcp的三次握手来建立网络连接

其实如果没有tcp照样可以进行网络通讯,这里先插入udp

udp

udp(User Datagram Protocal)用户数据报协议

以前面试官很喜欢问tcpudp二者的区别,现在好像问这个比较少了

udp特征如下:

  1. 无连接:不需要再正式传数据之前建立双方的连接

    如果网络通讯依靠tcp得话,tcp相比udp就更礼貌了,还需要先寒暄几下

  2. 只是数据报文的搬运工,不会对数据报文进行拆分和拼接

    从这里就可以看出,udp传输的时候可以很高效,但是不安全

总结下特点

  • 不可靠性

    因为面向无连接,不会去备份数据,没有拥塞控制

    这个拥塞控制我来举个情景:udp传输的时候不会去管网络好坏,都是一个劲的去传输,就像是一个莽夫在路上开车,路况你无从控制的,万一碰到了窄路就会发生拥堵

    拥塞控制就是可以控制网不好的时候传少点,网好的时候传多点

  • 高效

  • 传输方式:一对一(单播),一对多(多播),多对一,多对多(广播)

虽然行为很莽夫,但是因为传输高效以及方式导致这个udp还是有很多应用场景的

比如直播,在线游戏,视频通话,只要是实时通讯的,就要用上udp协议

tcp

tcp(Transmission Control Protocal)传输控制协议

tcp特征如下

  1. 需要握手来建立连接和断开连接

  2. 通过某种算法保障了数据的可靠性

    既然是网络协议,那么传输一定是会受网络影响的,tcp在传输之前会先把数据先进行备份,并且可以通过网络的好坏来进行拥塞控制,网不好就慢慢发

tcp有些字段也比较重要:

  • Sequence Number

    序列号:给每个数据报文都打上序列号,保证了接收顺序

  • Acknowledgement Number

    确认号:接收端期望接收到的下一个字节的编码是多少。比如你接收了第一包,确认号就是第二个包

  • 标识符

    URG = 1表示数据包的优先级,1表示最高,加急的效果

    ACK = 1表示该数据包有效,比如超时重传后,先前很慢过来的数据包就成了无效的

    SYN = 1; ACK = 0 表示连接请求报文

    SYN = 1; ACK = 1 表示应答连接报文

就是因为有这么多字段,才可以使得tcp可靠传输

第一次握手

客户端向服务端发送建立连接请求,客户端进入SYN-SEND状态,syn就是报文,send就是发送

第二次握手

服务端接收到建立连接请求后,向客户端发送一个应答,服务端进入SYN-RECEIVED状态,received就是接收到了

第三次握手

客户端接收到应答后,发送确认接收到应答,客户端进入ESTABLISHED状态,established就是建立了

面试官:能否仅两次握手?

不行。两次连接网络请求通讯完毕后,双方都会进入closed状态,假设之前有个包因为某些原因丢失了,等下次回来的时候双方都是closed状态(tcp有超时重传机制,若丢失会再次发送),服务端接收到时,进入SYN-RECEIVED状态,但是客户端因为是closed状态没有去理服务端的应答,于是服务端一直都是SYN-RECEIVED造成资源浪费,服务端在这个状态得不到应答不会自动关闭,但是三次握手,之前的包回来的时候,服务端接收到进入SYN-RECEIVED状态,得不到应答会自动关闭,就不会造成资源浪费

三次握手的目的就是用来建立连接,接下来数据通讯就是归http负责

其实tcp也可以做数据传输

http发请求

服务端响应请求返回数据

浏览器渲染页面

这里面的详细过程已经在那期文章讲得很详细了

  • 解析html代码,生成一个dom树

  • 解析css代码,生成CSSOM树

  • 将dom树和CSSOM树结合,去除不可见的元素,生成Render Tree

  • 计算布局,(回流 | 重排)根据Render Tree进行布局计算,得到每一个节点的几何信息

  • 绘制页面,(重绘)GPU根据布局信息绘制

tcp四次挥手断开连接

第一次挥手

客户端向服务端发送断开请求连接

第二次挥手

服务端接收到断开连接请求后,告诉应用层去释放tcp连接,此时服务端仍然可以给客户端发送数据包

应用层指的是OSI七层协议

路由器一般是网络层,交换机是物理层,应用层就是为终端或者应用提供网络服务

第三次挥手

服务端向客户端发送最后一个数据包FINBIT后,服务端进入Last-ACK状态

第四次挥手

客户端接收到服务端的释放连接请求后,向服务端确认应答,最终双方均进入closed状态

面试官:能否仅三次挥手

第四次就是客户端确认收到了释放连接的请求,也就是确认可以关闭,如果没有这一步,客户端就一直都是开放的状态,浪费性能

最后

输入url后第一步就是url解析,判断url是否合法,然后就是dns解析,这个过程就是解析出域名对应的ip,一层一层的找,然后就是tcp三次握手建立连接,建立好连接就是http数据通讯服务端响应请求返回数据,浏览器通过生成html树,cssom树,合并成render树,回流重绘渲染好页面,最终tcp四次挥手断开连接

如果你对春招感兴趣,可以加我的个人微信:Dolphin_Fung,我和我的小伙伴们有个面试群,可以进群讨论你面试过程中遇到的问题,我们一起解决

另外有不懂之处欢迎在评论区留言,如果觉得文章对你学习有所帮助,还请"点赞+评论+收藏"一键三连,感谢支持!

相关推荐
Zheng11311 分钟前
【可视化大屏】将柱状图引入到html页面中
javascript·ajax·html
程序猿小D17 分钟前
第二百六十七节 JPA教程 - JPA查询AND条件示例
java·开发语言·前端·数据库·windows·python·jpa
john_hjy35 分钟前
【无标题】
javascript
奔跑吧邓邓子1 小时前
npm包管理深度探索:从基础到进阶全面教程!
前端·npm·node.js
软件开发技术深度爱好者1 小时前
用HTML5+CSS+JavaScript庆祝国庆
javascript·css·html5
前端李易安1 小时前
ajax的原理,使用场景以及如何实现
前端·ajax·okhttp
杰哥在此2 小时前
Python知识点:如何使用Multiprocessing进行并行任务管理
linux·开发语言·python·面试·编程
汪子熙2 小时前
Angular 服务器端应用 ng-state tag 的作用介绍
前端·javascript·angular.js
Envyᥫᩣ2 小时前
《ASP.NET Web Forms 实现视频点赞功能的完整示例》
前端·asp.net·音视频·视频点赞
Мартин.6 小时前
[Meachines] [Easy] Sea WonderCMS-XSS-RCE+System Monitor 命令注入
前端·xss