您的位置:首页 > 理论基础 > 计算机网络

从url到页面渲染浏览器经历了什么?

2018-03-18 23:30 429 查看
本文首发http://zhaorubo.top我的个人网站,欢迎访问!

面对这个问题?我想了想,看了看,参考了一下别人的文章,并自己梳理了一下知识,其中有好多东西没有涉及到比如web安全、性能优化、绘话技术、存储技术、负载均衡、集群等,日后有空再慢慢补充,此文也只是简单的记录一下自己对此的理解。以便形成自己前端知识体系,如若有错,欢迎指出!,哈哈哈哈哈,不瞎扯了,看文章了

!

浏览器的组成

用户界面:包括地址栏、后退/前进按钮、书签目录等,也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分

浏览器引擎:用来查询及操作渲染引擎的接口

渲染引擎:用来显示请求的内容,例如,如果请求内容为html,它负责解析html及css,并将解析后的结果显示出来

网络:用来完成网络调用,例如http请求,它具有平台无关的接口,可以在不同平台上工作

UI 后端:用来绘制类似组合选择框及对话框等基本组件,具有不特定于某个平台的通用接口,底层使用操作系统的用户接口

JS解释器-用来解释执行JS代码

数据存储:属于持久层,浏览器需要在硬盘中保存类似cookie的各种数据,HTML5定义了web database技术,这是一种轻量级完整的客户端存储技术





浏览器从请求到渲染经历的过程

DNS域名解析

TCP/IP连接

HTTP 请求即响应

服务器响应

客户端渲染

DNS 查询

DNS(Domain Name System,域名系统),万维网上作为域名和IP地址相互映射的一个分布式数据库

dns解析成IP的大致流程

如果浏览器有缓存直接使用浏览器缓存,否则使用本机缓存,再没有的话就是用host

如果本地没有,就向dns域名服务器查询(当然,中间可能还会经过路由,也有缓存等),查询到对应的IP

注意,域名查询时有可能是经过了CDN调度器的(如果有cdn存储功能的话)。而且,需要知道dns解析是很耗时的,因此如果解析域名过多,会让首屏加载变得过慢,可以考虑
dns-prefetch
优化。


关于DNS缓存

查看Chome浏览器的DNS缓存:在地址栏输入
chrome://dns




清除Chrome浏览器的DNS缓存




清除本机DNS缓存,此截图以win系统为例, cmd输入命令
ipconfig /flushdns




TCP/IP

tcp/ip请求

http的本质就是
tcp/ip
请求。

需要了解3次握手规则建立连接以及断开连接时的四次挥手。

tcp将http长报文划分为短报文,通过三次握手与服务端建立连接,进行可靠传输。

三次握手的步骤(抽象派)

客户端:hello,你是server么?

服务端:hello,我是server,你是client么

客户端:yes,我是client

建立连接成功后,接下来就正式传输数据。

然后,待到断开连接时,需要进行四次挥手(因为是全双工的,所以需要四次挥手)。

四次挥手的步骤(抽象派)

主动方:我已经关闭了向你那边的主动通道了,只能被动接收了

被动方:收到通道关闭的信息

被动方:那我也告诉你,我这边向你的主动通道也关闭了

主动方:最后收到数据,之后双方无法通信

tcp/ip的并发限制

浏览器对同一域名下并发的tcp连接是有限制的(2-10个不等)。

而且在http1.0中往往一个资源下载就需要对应一个tcp/ip请求。

所以针对这个瓶颈,又出现了很多的资源优化方案。

get和post的区别

get和post虽然本质都是tcp/ip,但两者除了在http层面外,在tcp/ip层面也有区别。

get会产生一个tcp数据包,post两个。

具体就是:

get请求时,浏览器会把
headers
data
一起发送出去,服务器响应200(返回数据),

post请求时,浏览器先发送
headers
,服务器响应
100continue
,浏览器再发送
data
,服务器响应200(返回数据)。

再说一点,这里的区别是
specification
(规范)层面,而不是
implementation
(对规范的实现)

五层因特网协议栈

其实这个概念挺难记全的,记不全没关系,但是要有一个整体概念。

其实就是一个概念:从客户端发出http请求到服务器接收,中间会经过一系列的流程。

简括就是:从应用层的发送http请求,到传输层通过三次握手建立tcp/ip连接,再到网络层的ip寻址,再到数据链路层的封装成帧,最后到物理层的利用物理介质传输。

当然,服务端的接收就是反过来的步骤。

五层因特尔协议栈其实就是: 1.应用层(dns,http) DNS解析成IP并发送http请求 2.传输层(tcp,udp) 建立tcp连接(三次握手) 3.网络层(IP,ARP) IP寻址 4.数据链路层(PPP) 封装成帧 5.物理层(利用物理介质传输比特流) 物理传输(然后传输的时候通过双绞线,电磁波等各种介质)

当然,其实也有一个完整的OSI七层框架,与之相比,多了会话层、表示层。

OSI七层框架:
物理层
数据链路层
网络层
传输层
会话层
表示层
应用层


表示层:主要处理两个通信系统中交换信息的表示方式,包括数据格式交换,数据加密与解密,数据压缩与终端类型转换等

会话层:它具体管理不同用户和进程之间的对话,如控制登陆和注销过程



HTTP状态码对照表



http常见的状态码

这里面最常用到的就是状态码,很多时候都是通过状态码来判断,如(列举几个最常见的):

200——表明该请求被成功地完成,所请求的资源发送回客户端

304——自从上次请求后,请求的网页未修改过,请客户端使用本地缓存

400——客户端请求有错(譬如可以是安全模块拦截)

401——请求未经授权

403——禁止访问(譬如可以是未登录时禁止)

404——资源未找到

500——服务器内部错误

503——服务不可用

请求报文结构



渲染引擎基本流程

渲染引擎首先通过
网络
获得所请求文档的内容后进行如下渲染流程

渲染基本流程:

解析html以构建dom树->构建render树->布局render树->绘制render树




具体渲染流程图如下



​ webkit渲染引擎的主流程




​ Mozilla的Geoko 渲染引擎主流程

从图可以看出,尽管webkit和Gecko使用的术语稍有不同,他们的主要流程基本相同。Gecko称可见的格式化元素组成的树为frame树,每个元素都是一个frame,webkit则使用render树这个名词来命名由渲染对象组成的树。Webkit中元素的定位称为布局,而Gecko中称为回流。Webkit称利用dom节点及样式信息去构建render树的过程为attachment,Gecko在html和dom树之间附加了一层,这层称为内容接收器,相当制造dom元素的工厂。下面将讨论流程中的各个阶段。

参考资料:

https://www.kafan.cn/edu/620091.html

http://mp.weixin.qq.com/s/qMsf4DcMhn2cf0fXC-PLVA
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息