阻塞 IO: 等到系统内核层面完成所有操作之后，调用随之结束

非阻塞 IO: 调用之后立即返回（不携带处理完成的数据，因为尚未生成），之后还得通过文件描述符再次读取数据

非阻塞 IO 返回之后，CPU 时间片可以用于处理其它事务，但为了获取完整数据需要轮询，以判断操作是否完成

轮询满足了非阻塞 IO 确保获取完整数据的需求，但是对于应用程序而言，它仍然是一种同步，因为应用程序仍然需要等待 IO 完全返回

Node 的单线程仅仅是指 JavaScript 执行在单线程中，内部另有线程池完成 IO 任务

Node 经典的调用方式: 从 JavaScript 调用 Node 的核心模块；核心模块调用 C++ 内建模块；内建模块通过 libuv 进行系统调用（其中 libuv 作为封装层，有两个平台的实现）

Node 的异步:

第一部分：JavaScript 调用立即返回；接着在进行系统调用过程中，创建了一个请求对象，该对象包含了从JavaScript 层传入的参数和当前方法，以及回调函数；接着将该对象推入系统的线程池中等待执行，而不用在乎该操作是否阻塞 IO

第二部分：线程池中的 IO 操作调用完毕之后，将 IO 结果通知并归还线程；此时在每次 Tick 的执行中，会调用特定方法检查线程池中是否有执行完的请求；若存在则将请求对象加入到 IO 观察者的队列中，然后将其当做事件处理

setTimeout 与 setInterval 的定时并不精确，相比 process.nextTick 更为浪费性能

process.nextTick 在每轮循环中将数组中的回调函数全部执行完毕，而 setImmediate 则在每轮循环中执行链表中的一个回调函数

解除引用：delete 操作和重新赋值具有相同的效果，在 V8 中通过 delete 删除对象的属性有可能干扰V8的优化，所以建议使用赋值方式。

无法立即回收的内存有闭包和全局变量引用这两种情况。由于V8的内存限制，要十分小心此类变量是否无限制地增加，因为它会导致老生代中的对象增多。

堆中的内存总是小于进程的内存，这意味着 Node 中的内存使用并非都是通过 V8 进行分配的。那些不是通过 V8 分配的内存称为堆外内存。例如 Buffe r对象，它不经过V8的内存分配机制，所以也不会有堆内存的大小限制。

由于模块的缓存机制，模块是常驻老生代的。在设计模块时，要十分小心内存泄漏的出现。在下面的代码，每次调用 leak() 方法时，都导致局部变量 leakArray 不停增加内存的占用，且不被释放：

1
2
3
4

var leakArray = [];
exports.leak = function () {
  leakArray.push("leak" + Math.random());
};

如果模块不可避免地需要这么设计，那么请添加清空队列的相应接口，以供调用者释放内存。

深度的解决方案应该是监控队列的长度，一旦堆积，应当通过监控系统产生报警并通知相关人员。

另一个解决方案是任意异步调用都应该包含超时机制，一旦在限定的时间内未完成响应，通过回调函数传递超时异常，使得任意异步调用的回调都具备可控的响应时间，给消费速度一个下限值。

由于V8的内存限制，我们无法通过fs.readFile()和fs.writeFile()直接进行大文件的操作，而改用fs.createReadStream()和fs.createWriteStream()方法通过流的方式实现对大文件的操作。

如果需要超过 8 KB 的 Buffer 对象，将会直接分配一个 SlowBuffer 对象作为 slab 单元，这个 slab 单元将会被这个大 Buffer 对象独占。

上面提到的 Buffer 对象都是 JavaScript 层面的，能够被 V8 的垃圾回收标记回收。但是其内部的 parent 属性指向的 SlowBuffer 对象却来自于 Node 中 C++ 层面上的 Buffe r对象，所用内存不在 V8 的堆中。

当进行小而频繁的 Buffer 操作时，采用 slab 的机制进行预先申请和事后分配，使得 JavaScript 到操作系统之间不必有过多的内存申请方面的系统调用。对于大块的 Buffer 而言，则直接使用 C++ 层面提供的内存，而无需细腻的分配操作。

buffer += chunk; 这句代码里隐藏了 toString() 操作，它等价于如下的代码：

1

buffer = buffer.toString() + chunk.toString();

通过预先转换静态内容为 Buffer 对象，可以有效地减少 CPU 的重复使用，节省服务器资源。在 Node 构建的 Web 应用中，可以选择将页面中的动态内容和静态内容分离，静态内容部分可以通过预先转换为 Buffer 的方式，使性能得到提升。由于文件自身是二进制数据，所以在不需要改变内容的场景下，尽量只读取 Buffer，然后直接传输，不做额外的转换，避免损耗。

TCP 针对网络中的小数据包有一定的优化策略：Nagle算法。Nagle算法要求缓冲区的数据达到一定数量或者一定时间后才将其发出，所以小数据包将会被Nagle算法合并，以此来优化网络。这种优化虽然使网络带宽被有效地使用，但是数据有可能被延迟发送。

在 Node 中，TCP 默认启用了 Nagle 算法，调用 socket.setNoDelay(true) 关闭 Nagle 算法，使得write() 可以立即发送数据到网络中。
另一个需要注意的是，尽管在网络的一端调用 write() 会触发另一端的 data 事件，但是并不意味着每次 write() 都会触发一次 data 事件，在关闭掉 Nagle 算法后，另一端可能会将接收到的多个小数据包合并，然后只触发一次 data 事件。

UDP 与 TCP 同属于网络传输层。TCP 中连接一旦建立，所有的会话都基于连接完成，客户端如果要与另一个 TCP 服务通信，需要另创建一个套接字来完成连接。但在 UDP 中，一个套接字可以与多个 UDP 服务通信，常常应用在那种偶尔丢一两个数据包也不会产生重大影响的场景，比如音频、视频等。UDP 目前应用很广泛，DNS 服务即是基于它实现的。

报文体部分则抽象为一个只读流对象，如果业务逻辑需要读取报文体中的数据，则要在这个数据流结束后才能进行操作，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12

function (req, res) {
  // console.log(req.headers);
    var buffers = [];
    req.on('data', function (trunk) {
    buffers.push(trunk);
  }).on('end', function () {
    var buffer = Buffer.concat(buffers);
    // TODO
    res.end('Hello world');
  });
}

HTTP响应对象：它封装了对底层连接的写操作，可以将其看成一个可写的流对象。它影响响应报文头部信息的 API 为 res.setHeader() 和 res.writeHead()。在上述示例中：
res.writeHead(200, {‘Content-Type’: ‘text/plain’});

其分为 setHeader() 和 writeHead() 两个步骤。它在 http 模块的封装下，实际生成如下报文：

< HTTP/1.1 200 OK
< Content-Type: text/plain

我们可以调用 setHeader 进行多次设置，但只有调用 writeHead 后，报头才会写入到连接中。除此之外，http模块会自动帮你设置一些头信息，如下所示：

< Date: Sat, 06 Apr 2013 08:01:44 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
​

报文体部分则是调用 res.write() 和 res.end() 方法实现，差别在于 res.end() 会先调用 write() 发送数据，然后发送信号告知服务器这次响应结束。

响应结束后，HTTP 服务器可能会将当前的连接用于下一个请求，或者关闭连接。值得注意的是，报头是在报文体发送前发送的，一旦开始了数据的发送，writeHead() 和 setHeader() 将不再生效。
另外，无论服务器端在处理业务逻辑时是否发生异常，务必在结束时调用res.end()结束请求，否则客户端将一直处于等待的状态。

同时 http 模块提供了一个底层 API：http.request(options, connect)，用于构造 HTTP 客户端。

为了重用 TCP 连接，http 模块包含一个默认的客户端代理对象 http.globalAgent。它对每个服务器端（host + port）创建的连接进行了管理，默认情况下，通过 ClientRequest 对象对同一个服务器端发起的 HTTP 请求最多可以创建 5 个连接。

除此之外，WebSocket 与传统 HTTP 有如下好处：