CDN和DNS
DNS
DNS 提供了互联网中的主机名到 IP 地址转换的目录服务，在互联网中起着十分重要的作用。
严格来说 DNS 具有两层含义：
由分层的 DNS 服务器实现的分布式数据库
查询分布式数据库的应用层协议，运输层协议使用 UDP，端口号 53
提供的服务
除了主机名到 IP 地址转换，DNS 提供了其他服务：
主机别名： 主机可以拥有多个主机名(一个规范主机名，多个别名)，DNS 服务可以获取别名对应的 IP 和规范主机名
邮件服务器别名： 和主机别名相同，邮件服务器也可以拥有别名便于记忆
负载分配： 一个规范主机名可以对应多台服务器（多个 IP），DNS 可以在这些 IP 地址集合中循环分配负载
工作原理
分布式、层次数据库
DNS 使用了大量的 DNS 服务器，它们以层次方式组织并分布在全世界范围。
DNS 服务器存储着主机到 IP 的映射，这些映射分布在所有的 DNS 服务器上，每一台都仅存储一部分的映射。
DNS 服务器在层次上分为三种：
根 DNS 服务器：根服务器遍及全球，根服务器提供的是 TLD 服务器的 IP
顶级域服务器（TLD）：每个顶级域都有对 ...
UDP和TCP的多路复用和分解
运输层的作用
运输层将网络层在两个端系统之间的交付扩展到了运行在两个端系统上的应用进程之间的交付。
或者说运输层的协议为运行在不同主机上的应用进程提供了逻辑通信的能力。
因特网中的运输层协议有两种：UDP（用户数据报协议） 和 TCP（传输控制协议）
应用进程和运输层之间不会直接打交道，而是通过套接字来进行数据的传输，所以当运输层收到另一个端系统的某个应用进程发来的数据时，会将该数据交给上层对应的套接字，而非应用进程。
多路复用和分解
一台主机上会运行很多的应用进程，每个应用进程又可能会有一个或多个套接字，所以套接字需要有唯一的标识符来让运输层可以实现准确的交付。
多路分解： 运输层将报文段中的数据交付到正确的套接字的工作
多路复用： 运输层从上层不同的套接字收集数据并生成报文段，接着将报文段传递到网络层
实现多路分解和复用的要求：
套接字有唯一的标识符
每个报文字段有特殊字段（目的端口号、源端口号）来指示该报文字段所要交付的套接字
端口
端口号是一个 16 bit 的数，大小在 0 ~ 65535 之间。
0 ~ 1023 号端口被称为周知端口号，也就是说它们是给特定应用层 ...
NodeJS多进程
多进程
通过 child_process 模块即可创建多进程，被创建的进程称之为子进程，创建进程的进程称之为父进程。
多进程的意义在于可以充分利用计算机的 CPU 资源，早期的 Node 没有提供创建线程的方式，只有通过创建多个子进程来充分利用多核 CPU。
相比于多线程，虽然线程更加轻量，但是一个进程崩溃并不会影响另一个，而一个线程崩溃则整个进程都会崩溃，这对于服务器来说是不可接受的，所以一般都会使用 pm2 等工具部署，因为提供了守护进程用于守护 Node 进程。
如果使用子进程，尽量使用 commonjs 模块而不是 ES 模块，具体的看 issue
创建子进程
child_process 提供了同步和异步两种方式创建子进程，一般都是使用异步的方式创建：
exec：创建一个子进程（shell）执行命令，通过回调（子进程退出时调用）可以获取 shell 的输出
spawn：创建一个子进程（shell）执行命令，但是没有回调去获取输出
execFile：创建一个子进程执行可执行文件，如果是 js 文件则文件开头必须有 #!/user/bin/env node
fork：创建一个 ...
NodeJS中的流
流的意义
流的意义是我们可以不用将资源全部读入内存而是读一点消费一点，具有非常多的优点和用处。
Node 的 stream 模块提供了用于构建流接口的对象，但不提供某种流的具体实现。
stream api 的目的是为了限制数据的缓冲到可接受的程度，也就是读写速度不一致的源头与目的地不会压垮内存，而具体数据的处理（生产和消费）则需要自己实现。
也就是流在数据的生产和消费做了一层缓存，当读取流的时候读取的太慢则告知我们生成数据的速度就要降低，当将流从内存中写出时写的太快就要我们降低写的速度。
流的类型
Node 中共有四种类型的流：
可读流：对应的是 stream.Readable 类型
可写流：对应的是 stream.Writable 类型
双工流：对应的是 stream.Duplex 类型
转换流：对应的是 stream.Transform 类型
其中最重要的就是可读流和可写流；双工流存无非就是一个流既可读也可写，存在的原因是 JavaScript 中没有多继承；转换流本质就是一个双工流只不过在可读流和可写流进行数据转移时进行了数据的转换。
缓冲
既然流的目的是为了解决数据的 ...
HTTP/2特性
HTTP/1.1 的缺点
网站的变化
HTTP/1.1 发明以来：
一个页面请求的消息大小从几 KB 到几 MB
每个页面从小于 10 个资源，到多于 100 个资源
网站内容从文本为主到富媒体为主
对页面内容实时性高要求的应用越来越多
出现的问题
HTTP/1.0 一个请求和响应只能跑在一个 TCP 连接上，即每发起一个请求都要新建一次 TCP 连接，而且请求是串行的，通信开销非常的大。
HTTP/1.1 默认长连接（也叫持久连接），只要客户端或服务端没有提出断开连接，则保持 TCP 连接状态，减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
Connection 头部用于管理持久连接：
HTTP/1.1 默认长连接，当服务器想断开连接时只需要指定 Connection: close
HTTP/1.1 之前的版本默认短连接，如果想在旧版本也使用就需要指定 Connection: Keep-alive，服务器会返回 Connection: keep-alive 和 Keep-alive: xxxx 首部
随着带宽的提高以及网站资源数量的提升， ...
