Node 基于 V8 引擎构建，采用单线程模型，所有的 JavaScript 将会运行在单个进程的单个线程上，它带来的好处是：没有多线程中常见的锁以及线程同步的问题，操作系统在调度时也能减少上下文切换，提高 CPU 使用率。但是如今 CPU 基本均是多核的，真正的服务器往往还有多个 CPU，一个 Node 进程只能利用一个核，这带来硬件资源的浪费。另外，Node 运行在单线程之上，一个单线程抛出异常而没有被捕获，将会导致进程的崩溃。
严格来说，Node 并非真正的单线程，Node 自身中还有 I/O 线程存在，这些 I/O 线程由底层 libuv 处理，这部分线程对于 JavaScript 而言是透明的，只有 C++ 扩展时才会关注到，JavaScript 代码运行在 V8 上，是单线程的。
more >>WebSocket 与 Node 之间的配合可以说是天作之合：WebSocket 客户端基于事件的编程模型与 Node 中自定义事件相差无几；WebSocket 实现了客户端与服务器之间的长连接，而 Node 在与大量客户端之间保持高并发连接方面非常擅长。
WebSocket 有以下好处：
Node 中提供了 net，dgram，http，https 四个模块，分别用来处理 TCP，UDP，HTTP，HTTPS，适用于客户端和服务器。
TCP 传输控制协议，在 OSI 模型中属于传输层，许多应用层的协议基于 TCP 构建，比如 HTTP，SMTP，IMAP 等。回顾一下 OSI 模型。
Buffer 是一个像 Array 的对象，主要用来操作字节。Buffer 是一个典型的 JavaScript 与 C++ 结合的模块，它将性能相关的部分用 C++ 实现，将非性能相关的部分用 JavaScript 实现。
Buffer 所占用的内存不是通过 V8 分配的，而是堆外内存。由于 V8 垃圾回收性能的影响，将 Buffer 对象用更高效的专有内存分配回收策略来管理。
Buffer 在 Node 进程启动的时候已经载入了，并将其放在全局对象 global 上，因此无需 require() 就能使用。
Buffer 的元素为 16 进制的两位数，即 0 到 255 的数值。
1 | var str = '深入浅出node.js' |
不同编码的字符串占用的元素个数各不相同，中文在 UTF-8 编码下占用 3 个元素，字母和半角标点占用 1 个元素。
Buffer 可以通过 length 属性得到长度，也可以通过下标访问元素。
more >>本章学习 V8 的垃圾回收机制以及如何高效使用内存，内存泄漏以及如何排查内存泄漏。
关于 JavaScript 中常用的垃圾回收机制，可以参考这篇文章 JavaScript 垃圾回收。
一般后端开发语言中，在基本的内存使用上都没有什么限制，而 Node 中将 JavaScript 的使用内存做出如下限制：64 位操作系统约为 1.4G，32 位操作系统约为 0.7G。在这样的限制下，Node 无法直接操作大内存对象，比如将一个 2GB 文件读取到内存中进行字符串分析，即使物理内存有 32 GB。
在 V8 中，所有的 JavaScript 对象都是通过堆来进行内存分配的，Node 中可以通过 process.memoryUsage() 查看内存使用情况。
1 | $ node |
异步的概念首先在 Web2.0 中火起来，是因为浏览器中 JavaScript 在单线程上执行，而且它还与 UI 渲染共用一个线程。这意味着 JavaScript 在执行的时候 UI 渲染和响应是处于停滞状态的。前端通过异步的方式来消除 UI 阻塞的现象。假如业务场景中有一组互不相关的任务需要完成，可以采用下面两种方式。
如果创建多线程的开销小于并行执行，那么多线程的方式是首选的。多线程的代价在于创建线程和执行期间线程上下文切换的开销较大。另外，在复杂业务中，多线程编程经常面临锁、状态同步等问题。但是多线程能有效利用 CPU。
单线程顺序执行比较符合编程人员按照顺序思考的思维方式，也是最主流的编程方式。缺点在于执行性能，任何一个略慢的任务都会导致后续执行代码被阻塞。
Node 在两者之间给出了它的方案：利用单线程，远离多线程死锁，状态同步问题；利用异步 I/O，让单线程远离阻塞，更好地利用 CPU。
异步 I/O 就是 I/O 的调用不再阻塞后续计算，将原有等待 I/O 完成这段时间分配给其它需要的业务去执行。
more >>不知不觉 Node 已经更新到第十个版本了，本人使用 Node 也有两年多时间，之前学习的东西一直零零散散，没有形成系统的知识体系，于是最近又抽时间回顾这本经典的 《深入浅出Node.js》，阅读的过程中，难免有些东西不易理解或者容易忘记，因此选择博客的形式记录。
作者书写这本书的时候，Node 的稳定版本为 v0.10.13，当前最高版本为 v10.1.0，不过整个 Node 的核心体系在当时已经形成，因此对更高版本的理解问题不大。
Node 诞生于 2009 年 3 月，作者为 Ryan Dahl。作者选择 JavaScript 作为 Node 的实现语言主要因为：JavaScript 高性能（V8），符合事件驱动，没有后端历史包袱。
除了 HTML、WebKit 和显卡这些与 UI 相关技术没有支持外，整个 Node 的结构与 Chrome 非常相似，它们都是基于事件驱动的异步架构，浏览器通过事件驱动来服务界面上的交互，Node 通过事件驱动来服务 I/O。
more >>前面几天学习 DNS 缓存的时候，了解到了 DNS 劫持和 HTTP 劫持，关于 DNS 劫持和 HTTP 劫持的区别，知乎上一位同学给出了有趣的比喻DNS劫持和HTTP劫持有什么区别？:
DNS 劫持：你输入的网址是 http://www.google.com，出来的是百度的页面。
HTTP 劫持：你打开的是知乎的页面，右下角弹出唐老师的不孕不育广告（2018年更：右下角弹出：偶系渣渣辉）。
应对 HTTP 劫持最有效的方法就是 HTTPS。本文学习 HTTPS 相关的知识。在学习之前首先抛出三个问题：
白屏时间是指浏览器从响应用户输入网址地址，到浏览器开始显示内容的时间。
首屏时间是指浏览器从响应用户输入网络地址，到首屏内容渲染完成的时间。
白屏时间 = 地址栏输入网址后回车 - 浏览器出现第一个元素
首屏时间 = 地址栏输入网址后回车 - 浏览器第一屏渲染完成
影响白屏时间的因素：网络，服务端性能，前端页面结构设计。
影响首屏时间的因素：白屏时间，资源下载执行时间。
以百度为例，将 chrome 网速调为 Fast 3G，然后打开 Performance 工具，点击 “Start profiling and reload page” 按钮，查看 Screenshots 如下图：
more >>HTTP 缓存通常要配合客户端（浏览器）使用才能发挥效果，所以又被称之为浏览器缓存，是 Web 性能优化的一大利器。
浏览器缓存分为强缓存和协商缓存。
(1) 强缓存：浏览器在加载资源的时候，根据资源的 HTTP Header 判断它是否命中强缓存，如果命中，浏览器直接从自己的缓存中读取资源，不会发请求到服务器。
(2) 协商缓存：当强缓存没有命中的时候，浏览器向服务器发送请求，服务器端依据资源的另外一些 HTTP Header 验证这个资源是否命中协商缓存，如果协商缓存命中，服务器会将这个请求返回 304，浏览器从缓存中加载这个资源；若未命中请求，服务端返回 200 并将资源返回客户端，浏览器更新本地缓存数据。
more >>缓存技术几乎存在于网络技术发展的各个角落，从数据库到服务器，从服务器到网络，再从网络到客户端，缓存随处可见。跟前端有关的缓存技术主要有：DNS 缓存，HTTP 缓存，浏览器缓存，HTML5 缓存（localhost/manifest）和 service worker 中的 cache api。
当用户在浏览器中输入网址的地址后，浏览器要做的第一件事就是解析 DNS：
(1) 浏览器检查缓存中是否有域名对应的 IP，如果有就结束 DNS 解析过程。浏览器中的 DNS 缓存有时间和大小双重限制，时间一般为几分钟到几个小时不等。DNS 缓存时间过长会导致如果 IP 地址发生变化，无法解析到正确的 IP 地址；时间过短会导致浏览器重复解析域名。
(2) 如果浏览器缓存中没有对应的 IP 地址，浏览器会继续查找操作系统缓存中是否有域名对应的 DNS 解析结果。我们可以通过在操作系统中设置 hosts 文件来设置 IP 与域名的关系。
more >>上一篇文章学习了重绘和回流对页面性能的影响，是从比较宏观的角度去优化 Web 性能，本篇文章从每一帧的微观角度进行分析，来学习 CSS3 硬件加速的知识。
CSS3 硬件加速又叫做 GPU 加速，是利用 GPU 进行渲染，减少 CPU 操作的一种优化方案。由于 GPU 中的 transform 等 CSS 属性不会触发 repaint，所以能大大提高网页的性能。
我做了一个页面，左边元素的动画通过 left/top 操作位置实现，右边元素的动画通过 transform: translate 实现，你可以打开 chrome 的 “Paint flashing” 查看，绿色部分是正在 repaint 的内容。
从 demo 中可以看到左边的图形在运动时外层有一圈绿色的边框，表示元素不停地 repaint，并且可以看到其运动过程中有丢帧现象，具体表现为运动不连贯，有轻微闪动。
more >>tag:
