这里讨论的缓存是指 web 缓存：一个 web 资源（如 html 页面、图片、文件等）在服务器和客户端（浏览器）之间的副本。缓存会根据进来的请求保存请求输出的内容的副本；然后，如果下一个请求是相同的 URL，且网页在这段时间内没有更新，浏览器就不会再次下载网页，而是直接使用本地缓存的网页副本。

缓存的作用主要有：

• 节约带宽。
• 减少延迟。
• 降低服务器压力。

所有的缓存都有一套规则来帮助它们决定什么情况下使用缓存中的副本，什么情况下向源服务器再次发送请求。这些规则有的在协议（如 HTTP 协议 1.0 和 1.1）中有定义，有的则是由缓存的管理员（如 DBA、浏览器的用户、代理服务器管理员或者应用开发者）设置。

由于 doT.js 模板引擎的整体性能较优，OnceIO 采用 doT.js 作为默认模板引擎。在使用任何一种除了 doT.js 之外的模板引擎之前都需要先用 cmd 在项目文件夹安装这种模板引擎。以使用 Git Bash 安装 EJS 为例，使用的命令是：

$ npm install ejs  

before函数提供了一种机制，可以在文件接收之前根据req.headers对文件进行验证(如大小、类型)，return true 表示验证通并开始接收文件。在这里 before 中的回调函数会根据 req.headers 中的 content-length 判断上传的文件是否超出了尺寸限制（开发人员可以通过修改 if 语句中的常数改变文件上传尺寸上限，content-length 单位为 byte，1024 * 1024 即代表 1 MB），如果超出了，文件不会被上传，服务器返回错误信息；如果没有超出，函数返回值为 true，服务器继续执行 app.file 中的回调函数，将文件从临时地址转移到指定存储地址，文件上传到这里就完成了。  

在互联网上, QueryString是地址的一部分, 其中包含着需要传给后台的数据，通常以?开始，以&号分割。在表单提交时，会默认以QueryString的形式向后台发送数据，OnceIO会将其存储在res.query对象上。

OnceIO 是一个自身功能极简，完全由路由、中间件和Handler构成的 web 开发框架：一个 OnceIO 应用本质上就是在调用各种中间件和Handler。  

中间件是一个函数，它可以访问请求对象（request object (req)）, 响应对象（response object (res)），并将应用的请求-响应循环传向下一个中间件。

一个应用的请求-响应循环如下图所示，由请求对象、响应对象、中间件和 handler 构成。

OnceIO 的模块路由和模板注入机制是与其它Web框架最主要的区别之一。软件系统时常需要针对不同的客户定制不同的功能。OnceIO的模块路由可以通过一个扩展包，对系统原有模板(Template)和填充数据(Model)进行重定向或复写。可以在不更改系统源代码的情况下，以非侵入的方式对系统进行深度定制和扩展。

HTTP 是一种无状态的协议，服务器单从网络连接上无从知道客户身份，这给交互式 Web 应用程序的实现带来了阻碍。Cookie 就是用来绕开 HTTP 的无状态性的手段之一。Cookie 实际上是一小段的文本信息。客户端（浏览器）向服务器发送请求，如果 服务器需要记录该用户状态，就会将 Cookie 放在响应头中向客户端浏览器发送。如果浏览器启用了 Cookie，就会把 Cookie 保存起来，并且在再次请求该网站时把请求的网址连同 Cookie 一同提交给服务器。服务器通过读取 Cookie 来辨认用户状态。服务器还可以根据需要修改 Cookie 的内容。

我们的企业网盘OnceDoc和管理软件采用内存数据库Redis。Redis 是一个使用 C 语言编写的键值对存储数据库，体积小巧，性能优异，实施简单。很多大并发网站如Twitter、GitHub Weibo、Snapchat、Flickr、阿里等都将其用作SESSION存储及缓存的管理。出于性能的考虑 Redis 自带的命令一般不支持按值查找。但是企业软件又需要数据库有搜索、复杂条件查询以及聚合分析的能力。为了实现这些功能我们修改了Redis的源码。并创建了一个新的开源分支 OnceDB

Github在去年7月刚刚完成了一轮2.5亿美元的融资。然而据TechCrunch报道，Github正在寻求第二轮融，或是为了投资者或员工的清算做准备。

此传言有两点，此轮融资可能低于之前的20亿美元的估值。消息来源方透露此轮估值可能在15亿美元左右，目前还不能透露具体数额。然而另外也有传闻称此轮融资或为普通股。所以这一轮的估值可能可能比较模糊，或者不是传统意义上的下一轮融资。

单线程的 Node.js 为了充分利用 CPU 的多核特性，采用了 cluster 模块，利用主从模式，生成与 CPU 核心数量相当的子进程，主进程捕获请求随机分配给子进程处理，并负责子进程的崩溃重启。进程与进程之间是不能共享数据的，如果把 Session 存储在内存里，存储在不同进程的内存中的 Session 将无法共享，Session 认证机制会出现问题。例如，用户 A 认证的过程是由进程 1 处理的，那么维持会话的 Session 将保存在进程 1 的内存数据中；用户 A 接下来的请求被分配给进程 2 处理，因为进程 2 没有处理过用户 A 的认证，没有维持这个会话的 Session，所以进程 2 会判断用户 A 并没有授权。这样用户 A 需要多次重复认证访问才能继续下去。