从开发 & 运维角度方面来看,总体来说分为以下几个过程:
- DNS 解析: 将域名解析成 IP 地址
- TCP 连贯:TCP 三次握手
- 发送 HTTP 申请
- 服务器解决申请并返回 HTTP 报文
- 浏览器解析渲染页面
- 断开连接:TCP 四次挥手
一、什么是 URL?
URL(Uniform Resource Locator),对立资源定位符,用于定位互联网上资源,俗称网址。
scheme: // host.domain:port / path / filename ? abc = 123 # 456789
scheme - 定义因特网服务的类型。常见的协定有 http、https、ftp、file,其中最常见的类型是 http,而 https 则是进行加密的网络传输。host - 定义域主机(http 的默认主机是 www)domain - 定义因特网域名,比方 baidu.com
port - 定义主机上的端口号(http 的默认端口号是 80)path - 定义服务器上的门路(如果省略,则文档必须位于网站的根目录中)。filename - 定义文档 / 资源的名称
query - 即查问参数
fragment - 即 # 后的 hash 值,个别用来定位到某个地位
二、DNS 域名解析
在浏览器输出网址后,首先要通过域名解析,因为浏览器并不能间接通过域名找到对应的服务器,而是要通过 IP 地址。
- IP 地址
IP 地址是指互联网协议地址,是 IP Address 的缩写。IP 地址是 IP 协定提供的一种对立的地址格局,它为互联网上的每一个网络和每一台主机调配一个逻辑地址,以此来屏蔽物理地址的差别。
- 什么是域名解析
DNS 协定提供通过域名查找 IP 地址,或逆向从 IP 地址反查域名的服务。DNS 是一个网络服务器,咱们的域名解析简略来说就是在 DNS 上记录一条信息记录。
- 浏览器如何通过域名去查问 URL 对应的 IP 呢?
DNS 域名解析分为递归查问和迭代查问两种形式,现个别为迭代查问。
DNS 的优化与利用
- DNS 缓存
DNS 存在着多级缓存,从离浏览器的间隔排序的话,有以下几种: 浏览器缓存,零碎缓存,路由器缓存,IPS 服务器缓存,根域名服务器缓存,顶级域名服务器缓存,主域名服务器缓存。
- DNS 负载平衡
(DNS 重定向) DNS 负载平衡技术的实现原理是在 DNS 服务器中为同一个主机名配置多个 IP 地址,在应答 DNS 查问时,DNS 服务器对每个查问将以 DNS 文件中主机记录的 IP 地址按程序返回不同的解析后果,将客户端的拜访 疏导到不同的机器下来,使得不同的客户端拜访不同的服务器,从而达到负载平衡的目标。
- 大家耳熟能详的 CDN(Content Delivery Network) 就是利用 DNS 的重定向技术,DNS 服务器会返回一个跟
用户最靠近的点的 IP 地址给用户,CDN 节点的服务器负责响应用户的申请,提供所需的内容。 - dns-prefetch
DNS Prefetch 是一种 DNS 预解析技术。当你浏览网页时,浏览器会在加载网页时对网页中的域名进行解析缓存,这样在你单击以后网页中的连贯时就无需进行 DNS 的解析,缩小用户等待时间,进步用户体验。
OSI 参考模型与 TCP/IP 四层模型
三、TCP 三次握手
- 客户端发送一个带 SYN=1,Seq=X 的数据包到服务器端口
(第一次握手,由浏览器发动,通知服务器我要发送申请了)
- 服务器发回一个带 SYN=1,ACK=X+1,Seq=Y 的响应包以示传播确认信息
(第二次握手,由服务器发动,通知浏览器我筹备承受了,你连忙发送吧)
- 客户端再回传一个带 ACK=Y+1,Seq=Z 的数据包,代表“握手完结”
(第三次握手,由浏览器发送,通知服务器,我马上就发了,筹备承受吧)
四、发送 HTTP 申请
TCP 三次握手完结后,开始发送 HTTP 申请报文。
为防止篇幅过长,http 协定、缓存等相干内容请参阅:
从 HTTP 到 WEB 缓存
五、服务器解决申请并返回 HTTP 报文
每台服务器上都会装置解决申请的利用——Web server。常见的 web server 产品有 apache、nginx、IIS、Lighttpd 等。
伪装我是一个传统的 MVC 模型,RD 同学请忽视
六、浏览器解析渲染页面
浏览器的次要形成
用户界面 (User Interface) - 包含地址栏、后退 / 后退按钮、书签目录等,也就是你所看到的除了用来显示你所申请页面的主窗口之外的其余局部
浏览器引擎 (Browser Engine) - 用来查问及操作渲染引擎的接口
渲染引擎 (Rendering Engine) - 用来显示申请的内容,例如,如果申请内容为 html,它负责解析 html 及 css,并将解析后的结果显示进去
网络 (Networking) - 用来实现网络调用,例如 http 申请,它具备平台无关的接口,能够在不同平台上工作
JS 解释器 (JS Interpreter) - 用来解释执行 JS 代码
UI 后端 (UI Backend) - 用来绘制相似组合抉择框及对话框等根本组件,具备不特定于某个平台的通用接口,底层应用操作系统的用户接口
数据存储 (DB Persistence) - 属于长久层,浏览器须要在硬盘中保留相似 cookie 的各种数据,HTML5 定义了 web database 技术,这是一种轻量级残缺的客户端存储技术
1. 多过程的浏览器
浏览器是多过程的,有一个主控过程,以及每一个 tab 页面都会新开一个过程(某些状况下多个 tab 会合并过程), 参考:前端进阶面试题具体解答
过程可能包含主控过程,插件过程,GPU,tab 页(浏览器内核)等等
- Browser 过程:浏览器的主过程(负责协调、主控),只有一个
- 第三方插件过程:每种类型的插件对应一个过程,仅当应用该插件时才创立
- GPU 过程:最多一个,用于 3D 绘制
- 浏览器渲染过程(内核):默认每个 Tab 页面一个过程,互不影响,管制页面渲染,脚本执行,事件处理等(有时候会优化,如多个空白 tab 会合并成一个过程)
2. 多线程的浏览器内核
每一个 tab 页面能够看作是浏览器内核过程,而后这个过程是多线程的,它有几大类子线程:
- GUI 线程
- JS 引擎线程
- 事件触发线程
- 定时器线程
- 网络申请线程
浏览器内核拿到内容后,渲染步骤大抵能够分为以下几步:
1. 解析 HTML,构建 DOM 树
2. 解析 CSS,生成 CSS 规定树
3. 合并 DOM 树和 CSS 规定,生成 render 树
4. 布局 render 树(Layout/reflow),负责各元素尺寸、地位的计算
5. 绘制 render 树(paint),绘制页面像素信息
以 webkit 内核为例
1. HTML 解析,构建 DOM
简略的了解,这一步的流程是这样的:浏览器解析 HTML,构建 DOM 树。
解析 HTML 到构建出 DOM 当然过程能够简述如下:
Bytes → characters → tokens → nodes → DOM
其中比拟要害的几个步骤
1. Conversion 转换:浏览器将取得的 HTML 内容(Bytes)基于他的编码转换为单个字符
2. Tokenizing 分词:浏览器依照 HTML 标准规范将这些字符转换为不同的标记 token。每个 token 都有本人独特的含意以及规定集
3. Lexing 词法剖析:分词的后果是失去一堆的 token,此时把他们转换为对象,这些对象别离定义他们的属性和规定
4. DOM 构建:因为 HTML 标记定义的就是不同标签之间的关系,这个关系就像是一个树形构造一样
例如:body 对象的父节点就是 HTML 对象,而后段略 p 对象的父节点就是 body 对象
2. 解析 CSS,生成 CSS 规定树
同理,CSS 规定树的生成也是相似。
Bytes → characters → tokens → nodes → CSSOM
3. 合并 DOM 树和 CSS 规定,生成 render 树
当 DOM 树和 CSSOM 都有了后,就要开始构建渲染树了
一般来说,渲染树和 DOM 树绝对应的,但不是严格意义上的一一对应, 因为有一些不可见的 DOM 元素不会插入到渲染树中,如 head 这种不可见的标签或者 display: none 等
4. 布局 render 树(Layout/Reflow),负责各元素尺寸、地位的计算
布局:通过渲染树中渲染对象的信息,计算出每一个渲染对象的地位和尺寸。
5. 绘制 render 树(Paint),绘制页面像素信息
绘制阶段,零碎会遍历出现树,并调用出现器的“paint”办法,将出现器的内容显示在屏幕上。
这张图片中重要的四个步骤
1. 计算 CSS 款式
2. 构建渲染树
3. 布局,次要定位坐标和大小,是否换行,各种 position overflow z-index 属性
4. 绘制,将图像绘制进去
- Layout,也称为 Reflow,即回流。个别意味着元素的内容、构造、地位或尺寸产生了变动,须要从新计算款式和渲染树
- Repaint,即重绘。意味着元素产生的扭转只是影响了元素的一些外观之类的时候(例如,背景色,边框色彩,文字色彩等),此时只须要利用新款式绘制这个元素就能够了
七、断开连接
当数据传送结束,须要断开 tcp 连贯,此时发动 tcp 四次挥手。
- 发动方向被动方发送报文,Fin、Ack、Seq,示意曾经没有数据传输了。并进入 FIN_WAIT_1 状态。
(第一次挥手:由浏览器发动的,发送给服务器,我申请报文发送完了,你筹备敞开吧)
- 被动方发送报文,Ack、Seq,表示同意敞开申请。此时主机发起方进入 FIN_WAIT_2 状态。
(第二次挥手:由服务器发动的,通知浏览器,我申请报文承受完了,我筹备敞开了,你也筹备吧)
- 被动方向发起方发送报文段,Fin、Ack、Seq,申请敞开连贯。并进入 LAST_ACK 状态。
(第三次挥手:由服务器发动,通知浏览器,我响应报文发送完了,你筹备敞开吧)
- 发动方向被动方发送报文段,Ack、Seq。而后进入期待 TIME_WAIT 状态。被动方收到发起方的报文段当前敞开连贯。发起方期待肯定工夫未收到回复,则失常敞开。
(第四次挥手:由浏览器发动,通知服务器,我响应报文承受完了,我筹备敞开了,你也筹备吧)