《浏览器工作原理与实践》笔记之HTTP2

HTTP/2 的多路复用 前面我们分析了 HTTP/1.1 所存在的一些主要问题:慢启动和 TCP 连接之间相互竞争带宽是由于 TCP 本身的机制导致的,而队头阻塞是由于 HTTP/1.1 的机制导致的。那么该如何去解决这些问题呢? 虽然 TCP 有问题,但是我们依然没有换掉 TCP 的能力,所以我们就要想办法去规避 TCP 的慢启动和 TCP 连接之间的竞争问题。 基于此,HTTP/2 的思路就是一个域名只使用一个 TCP 长连接来传输数据,这样整个页面资源的下载过程只需要一次慢启动,同时也避免了多个 TCP 连接竞争带宽所带来的问题。 另外,就是队头阻塞的问题,等待请求完成后才能去请求下一个资源,这种方式无疑是最慢的,所以 HTTP/2 需要实现资源的并行请求,也就是任何时候都可以将请求发送给服务器,而并不需要等待其他请求的完成,然后服务器也可以随时返回处理好的请求资源给浏览器。 所以,HTTP/2 的解决方案可以总结为:一个域名只使用一个 TCP 长连接和消除队头阻塞问题。可以参考下图: 该图就是 HTTP/2 最核心、最重要且最具颠覆性的多路复用机制。从图中你会发现每个请求都有一个对应的 ID,如 stream1 表示 index.html 的请求,stream2 表示 foo.css 的请求。这样在浏览器端,就可以随时将请求发送给服务器了。 服务器端接收到这些请求后,会根据自己的喜好来决定优先返回哪些内容,比如服务器可能早就缓存好了 index.html 和 bar.js 的响应头信息,那么当接收到请求的时候就可以立即把 index.html Read more…

《浏览器工作原理与实践》笔记之HTTP诞生到HTTP 1.1

HTTP 0.9 HTTP协议最早的版本是0.9版本,于1991年提出,其需求很简单——用来在网络之间传递 HTML 超文本的内容。 完整的请求流程如下: 因为 HTTP 都是基于 TCP 协议的,所以客户端先要根据 IP 地址、端口和服务器建立 TCP 连接,而建立连接的过程就是 TCP 协议三次握手的过程。 建立好连接之后,会发送一个 GET 请求行的信息,如GET /index.html用来获取 index.html。 服务器接收请求信息之后,读取对应的 HTML 文件,并将数据以 ASCII 字符流返回给客户端。 HTML 文档传输完成后,断开连接。 0.9版本有以下三个特点。 第一个是只有一个请求行,并没有 HTTP 请求头和请求体,因为只需要一个请求行就可以完整表达客户端的需求了。 第二个是服务器也没有返回头信息,这是因为服务器端并不需要告诉客户端太多信息,只需要返回数据就可以了。 第三个是返回的文件内容是以 ASCII 字符流来传输的,因为都是 HTML 格式的文件,所以使用 ASCII 字节码来传输是最合适的。 HTTP 1.0 随着新兴网络都带来了新的需求。首先在浏览器中展示的不单是 HTML 文件了,还包括了 JavaScript、CSS、图片、音频、视频等不同类型的文件。因此支持多种类型的文件下载是 HTTP/1.0 的一个核心诉求,而且文件格式不仅仅局限于 ASCII Read more…

CKEditor系列(一)CKEditor4项目怎么跑起来的

我们先看CKEditor的入口ckeditor.js,它里面有一部分是压缩版,压缩版部分对应的源码地址为src/core/ckeditor_base.js // src/core/ckeditor_base.js if ( !window.CKEDITOR ) { window.CKEDITOR = ( function() { var basePathSrcPattern = /(^|.*[\\\/])ckeditor\.js(?:\?.*|;.*)?$/i; var CKEDITOR = { _: { pending: [], basePathSrcPattern: basePathSrcPattern }, status: 'unloaded', basePath: ( function() {})(), // Find out the editor directory path, based on its <script> tag. var path = window.CKEDITOR_BASEPATH Read more…

《浏览器工作原理与实践》笔记之事件循环队列

为了能让你更加深刻地理解事件循环机制,我们就从最简单的场景来分析,然后带你一步步了解浏览器页面主线程是如何运作的。 使用单线程处理安排好的任务 我们先从最简单的场景讲起,比如有如下一系列的任务: 任务 1:1+2 任务 2:20/5 任务 3:7*8 任务 4:打印出任务 1、任务 2、任务 3 的运算结果 现在要在一个线程中去执行这些任务,通常我们会这样编写代码: void MainThread(){ int num1 = 1+2; //任务1 int num2 = 20/5; //任务2 int num3 = 7*8; //任务3 print("最终计算的值为:%d,%d,%d",num1,num2,num3); //任务4 } 在上面的执行代码中,我们把所有任务代码按照顺序写进主线程里,等线程执行时,这些任务会按照顺序在线程中依次被执行;等所有任务执行完成之后,线程会自动退出。 可以参考下图来直观地理解下其执行过程: 在线程运行过程中处理新任务 但并不是所有的任务都是在执行之前统一安排好的,大部分情况下,新的任务是在线程运行过程中产生的。为了能接收并执行新的任务,就需要采用事件循环机制。我们可以通过一个 for 循环语句来监听是否有新的任务。 如下面的示例代码: //GetInput //等待用户从键盘输入一个数字,并返回该输入的数字 int GetInput(){ int input_number = Read more…

《浏览器工作原理与实践》笔记之垃圾回收

先了解下垃圾回收领域的重要术语——代际假说和分代收集。 代际假说 第一个是大部分对象在内存中存在的时间很短,简单来说,就是很多对象一经分配内存,很快就变得不可访问; 第二个是不死的对象,会活得更久。 分代收集 在 V8 中会把堆分为新生代和老生代两个区域,新生代中存放的是生存时间短的对象,老生代中存放的生存时间久的对象。 新生区通常只支持 1~8M 的容量,由副垃圾回收器负责回收 老生区支持的容量就大很多了,由主垃圾回收器负责回收。 垃圾回收器的工作流程 现在你知道了 V8 把堆分成两个区域——新生代和老生代,并分别使用两个不同的垃圾回收器。其实不论什么类型的垃圾回收器,它们都有一套共同的执行流程。 第一步是标记空间中活动对象和非活动对象。所谓活动对象就是还在使用的对象,非活动对象就是可以进行垃圾回收的对象。 第二步是回收非活动对象所占据的内存。其实就是在所有的标记完成之后,统一清理内存中所有被标记为可回收的对象。 第三步是做内存整理。一般来说,频繁回收对象后,内存中就会存在大量不连续空间,我们把这些不连续的内存空间称为内存碎片。当内存中出现了大量的内存碎片之后,如果需要分配较大连续内存的时候,就有可能出现内存不足的情况。最后一步需要整理这些内存碎片,但这步其实是可选的,因为有的垃圾回收器不会产生内存碎片,比如接下来我们要介绍的副垃圾回收器。 副垃圾回收器(新生代) 副垃圾回收器主要负责新生区的垃圾回收。而通常情况下,大多数小的对象都会被分配到新生区,所以说这个区域虽然不大,但是垃圾回收还是比较频繁的。 新生代中用 Scavenge 算法来处理。所谓 Scavenge 算法,是把新生代空间对半划分为两个区域,一半是对象区域,一半是空闲区域,如下图所示: 新加入的对象都会存放到对象区域,当对象区域快被写满时,就需要执行一次垃圾清理操作。 在垃圾回收过程中,首先要对对象区域中的垃圾做标记;标记完成之后,就进入垃圾清理阶段,副垃圾回收器会把这些存活的对象复制到空闲区域中,同时它还会把这些对象有序地排列起来,所以这个复制过程,也就相当于完成了内存整理操作,复制后空闲区域就没有内存碎片了。 完成复制后,对象区域与空闲区域进行角色翻转,也就是原来的对象区域变成空闲区域,原来的空闲区域变成了对象区域。这样就完成了垃圾对象的回收操作,同时这种角色翻转的操作还能让新生代中的这两块区域无限重复使用下去。 由于新生代中采用的 Scavenge 算法,所以每次执行清理操作时,都需要将存活的对象从对象区域复制到空闲区域。但复制操作需要时间成本,如果新生区空间设置得太大了,那么每次清理的时间就会过久,所以为了执行效率,一般新生区的空间会被设置得比较小。 也正是因为新生区的空间不大,所以很容易被存活的对象装满整个区域。为了解决这个问题,JavaScript 引擎采用了对象晋升策略,也就是经过两次垃圾回收依然还存活的对象,会被移动到老生区中。 主垃圾回收器(老生代) 主垃圾回收器主要负责老生区中的垃圾回收。除了新生区中晋升的对象,一些大的对象会直接被分配到老生区。因此老生区中的对象有两个特点,一个是对象占用空间大,另一个是对象存活时间长。 由于老生区的对象比较大,若要在老生区中使用 Scavenge 算法进行垃圾回收,复制这些大的对象将会花费比较多的时间,从而导致回收执行效率不高,同时还会浪费一半的空间。因而,主垃圾回收器是采用标记 – 清除(Mark-Sweep)的算法进行垃圾回收的。下面我们来看看该算法是如何工作的。 首先是标记过程阶段。标记阶段就是从一组根元素开始,递归遍历这组根元素,在这个遍历过程中,能到达的元素称为活动对象,没有到达的元素就可以判断为垃圾数据。 比如最开始的那段代码,当 showName 函数执行退出之后,这段代码的调用栈和堆空间如下 上面的标记过程和清除过程就是标记 – 清除算法,不过对一块内存多次执行标记 – 清除算法后,会产生大量不连续的内存碎片。而碎片过多会导致大对象无法分配到足够的连续内存,于是又产生了另外一种算法——标记 Read more…

《浏览器工作原理与实践》笔记之闭包问题解答

Q: function fn() { var a = 10 function f1() { console.log(a) }; function f2() { console.log('f2') }; f2(); }; fn(); 我在函数f2里打断点,当执行到函数f2时,chrome里显示Closure:{a:10},如果把这个原因解释为在fn函数里会预扫描f1函数,那我现在把fn2函数和调用都注释了,现在执行fn函数时不产生Closure,为什么就不预扫描f1函数了?这是为什么? A: 你把f2注释了,当执行fn函数时,照样会预扫描f1,照样会产生闭包,只不过当fn执行结束之后,闭包的内容没有外部引用,那么下次垃圾回收直接把比闭包的内容回收掉 Q: 从内存模型角度分析执行代码的执行流程第二步看,在堆空间创建closure(foo)对象,它是存储在foo函数的执行上下文中的。 那么closure(foo)创建开始时是空对象,执行第三步的时候,才会逐渐把变量添加到其中。 当foo函数执行结束后,foo的执行上下文是不是销毁了?如果销毁了,产生一下两个疑问: 如果foo函数执行上下文销毁了,closure(foo)并没有销毁,那foo函数执行上下文是怎么销毁的呢?就比如销毁一个盒子,盒子毁里,里面的东西应该也是毁掉的 既然closure(foo)既然没有销毁,那它存储在堆中的什么地方呢?毕竟它所依赖的foo执行上下文已经不存在了 A: 关于foo函数执行上下文销毁过程:foo函数执行结束之后,当前执行状态的指针下移到栈中的全局执行上下文的位置,foo函数的执行上下文的那块数据就挪出来,这也就是foo函数执行上下文的销毁过程,这个文中有提到,你可以参考“调用栈中切换执行上下文状态“图。 第二个问题:innerBar返回后,含有setName和getName对象,这两个对象里面包含了堆中的closure(foo)的引用。虽然foo执行上下文销毁了,foo函数中的对closure(foo)的引用也断开了,但是setName和getName里面又重新建立起来了对closure(foo)引用。 你可以: 打开“开发者工具” 在控制台执行上述代码 然后选择“Memory”标签,点击"take snapshot" 获取V8的堆内存快照。 然后“command+f"(mac) 或者 "ctrl+f"(win),搜索“setName”,然后你就会发现setName对象下面包含了 raw_outer_scope_info_or_feedback_metadata,对闭包的引用数据就在这里面。 Q: Function 函数类型也是继承于Object,声明函数后是不是也是存在堆空间中的,那么浏览器编译函数时是不是会同时创建执行上下文和向堆空间中压入一个值 function a(){ var b Read more…

《浏览器工作原理与实践》笔记之从堆栈空间看闭包过程

基础 我们先看下面的代码 function foo(){ var a = "极客时间" var b = a var c = {name:"极客时间"} var d = c } foo() 执行第 4 行代码,由于 JavaScript 引擎判断右边的值是一个引用类型,这时候处理的情况就不一样了,JavaScript 引擎并不是直接将该对象存放到变量环境中,而是将它分配到堆空间里面,分配后该对象会有一个在“堆”中的地址,然后再将该数据的地址写进 c 的变量值,最终分配好内存的示意图如下所示: 我们知道原始类型的数据值都是直接保存在“栈”中的,引用类型的值是存放在“堆”中的。 不过你也许会好奇,为什么一定要分“堆”和“栈”两个存储空间呢?所有数据直接存放在“栈”中不就可以了吗? 这是因为 JavaScript 引擎需要用栈来维护程序执行期间上下文的状态,如果栈空间大了话,所有的数据都存放在栈空间里面,那么会影响到上下文切换的效率,进而又影响到整个程序的执行效率。比如文中的 foo 函数执行结束了,JavaScript 引擎需要离开当前的执行上下文,只需要将指针下移到上个执行上下文的地址就可以了,foo 函数执行上下文栈区空间全部回收,具体过程你可以参考下图: 进阶 有了上面基础,我们再来看下闭包 先看下面的代码 function foo() { var myName = "极客时间" let Read more…

《浏览器工作原理与实践》笔记之JavaScript是如何支持块级作用域的

你已经知道 JavaScript 引擎是通过变量环境实现函数级作用域的,那么 ES6 又是如何在函数级作用域的基础之上,实现对块级作用域的支持呢? function foo(){ var a = 1 let b = 2 { let b = 3 var c = 4 let d = 5 console.log(a) console.log(b) } console.log(b) console.log(c) console.log(d) } foo() 执行流程如下 编译并创建执行上下文 1.函数内部通过 var 声明的变量,在编译阶段全都被存放到变量环境里面了。 2.通过 let 声明的变量,在编译阶段会被存放到词法环境(Lexical Environment)中。 3.在函数的作用域块内部,通过 let 声明的变量并没有被存放到词法环境中。 续执行代码 从图中看出,当进入函数的作用域块时,作用域块中通过 Read more…

《浏览器工作原理与实践》笔记之CSS、JS阻塞DOM合成场景分析

当从服务器接收HTML页面的第一批数据时,DOM解析器就开始工作了。 我们先看第一种情况在解析过程中,如果遇到了JS脚本,如下所示: <html> <body> 极客时间 <script> document.write("–foo") </script> </body> </html> 那么DOM解析器会先执行JavaScript脚本,执行完成之后,再继续往下解析。 第二种情况复杂点了,上述解析过程中内联的JS脚本替换成JS外部文件,如下所示: <html> <body> 极客时间 <script type="text/javascript" src="foo.js"></script> </body> </html> 这种情况下,当解析到JavaScript的时候,会先暂停DOM解析,并下载foo.js文件,下载完成之后执行该段JS文件,然后再继续往下解析DOM。这就是JavaScript文件为什么会阻塞DOM渲染。 再看第三种情况,还是看下面代码: <html> <head> <style type="text/css" src = "theme.css" /> </head> <body> <p>极客时间</p> <script> let e = document.getElementsByTagName('p')[0] e.style.color = 'blue' </script> </body> </html> 当我在JavaScript中访问了某个元素的样式,那么这时候就需要等待这个样式被下载完成才能继续往下执行,所以在这种情况下,CSS也会阻塞DOM的解析。 所以JS和CSS都有可能会阻塞DOM解析。 本文截取自《浏览器工作原理与实践》05 | 渲染流程(上):HTML、CSS和JavaScript,是如何变成页面的?

《浏览器工作原理与实践》笔记之渲染流程

由于渲染机制过于复杂,所以渲染模块在执行过程中会被划分为很多子阶段,输入的 HTML 经过这些子阶段,最后输出像素。我们把这样的一个处理流程叫做渲染流水线,其大致流程如下图所示: 按照渲染的时间顺序,流水线可分为如下几个子阶段:构建 DOM 树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。 构建DOM树 为什么要构建 DOM 树呢?这是因为浏览器无法直接理解和使用 HTML,所以需要将 HTML 转换为浏览器能够理解的结构——DOM 树。 平时用的document就是DOM树,它和 HTML 内容几乎是一样的,但是和 HTML 不同的是,DOM 是保存在内存中树状结构,可以通过 JavaScript 来查询或修改其内容。 样式计算 把 CSS 转换为浏览器能够理解的结构 当渲染引擎接收到 CSS 文本时,会执行一个转换操作,将 CSS 文本转换为浏览器可以理解的结构——styleSheets。 转换样式表中的属性值,使其标准化 2em、blue、bold,这些类型数值不容易被渲染引擎理解,所以需要将所有值转换为渲染引擎容易理解的、标准化的计算值,这个过程就是属性值标准化。 计算出 DOM 树中每个节点的具体样式 样式计算阶段的目的是为了计算出 DOM 节点中每个元素的具体样式,在计算过程中需要遵守 CSS 的继承和层叠两个规则。这个阶段最终输出的内容是每个 DOM 节点的样式,并被保存在 ComputedStyle 的结构内。 布局阶段 计算出 DOM 树中可见元素的几何位置,我们把这个计算过程叫做布局。 创建布局树 Read more…