构建web应用会遇到的问题
请求方法的判断
URL路径的解析
URL中查询字符串的解析
Cookie的解析
表单数据得解析
任意格式文件的上传处理
会话的需求
请求方法
web请求方法存在于报文的第一行的第一个单词，通常大写
curl -v url
HTTP_Parser在解析请求报文的时候，将报文抽取出来，设置为req.method。存在的相应有POST、DELETE、PUT、GET。
PUT代表新建一个资源，POST表示要更新一个资源，GET表示查看一个资源，而DELETE表示删除一个资源
路径解析
客户端代理（浏览器）会将这个地址解析成报文，将路径和查询的部分放在报文的第一行。最常见的根据路径进行业务的应用是静态文件服务器，它会根据路径去查找磁盘中的文件，然后将其相应给客户端
http://user:pass@host.com:8080/p/a/t/h?query=string
查询字符串
查询字符串位于路径之后，在地址栏中路径后的？foo=bar&baz=val字符串就是查询字符串
这个字符串会跟随在路径之后，形成请求报文首行第二部分，为业务逻辑所用
Node提供了queryString 模块用于处理这部分数据
var url = require('url');
var querystring = require('querystring');
var query = querystring.parse(url.parse(req.url).query);
它会将查询字符串解析成一个JSON对象
{
foo:'bar',
baz:'val'
}
Cookie & Session
HTTP是一个无状态协议，业务逻辑需要一定得状态来区分用户身份。
Cookie的处理分为以下几步：
服务器像客户端发送Cookie
浏览器将cookie保存
之后每次浏览器都会讲Cookie发向服务器
cookie值得格式为 key = value；key=value形式
服务器告知客户端设置cookie的值，在Set-Cookie字段中
Set-Cookie字段的格式为
Set-Cookie：name=value；Path=/; Expires=Sun, 23-Apr-23 09:01:35 GMT; Domain=.domain.com;
其中name=value是必须包含的部分，其余部分皆是可选参数。参数的意义：
path：表示这个Cookie影响的路径，当前访问的路径不满足改匹配时，浏览器不发送这个Cookie
Expires和Max-Age 告知浏览器这个Cookie何时过期，如果不设置该选项，在关闭浏览器时会丢失掉这个Cookie
HttpOnly 告知浏览器不允许通过脚本document.cookie来更改Cookie值。
Secure 当secure设置为true，在HTTP请求中这个Cookie是无效的，HTTPS中才有效
Cookie的性能影响：
由于Cookie的实现机制，一旦服务器向客户端发送了设置Cookie的意图，除非Cookie过期，否则客户端每次请求都会发送这个写Cookie到服务器端，一旦设置Cookie过多，会导致报文较大。
针对该问题做一下几点优化
减小Cookie的大小 ： 限定Cookie域
为静态组件使用不同的域名： 换域名减少无效Cookie的传输，引入的问题域名转换为IP需要DNS查询，多一个域名多一次DNS查询
减少DNS查询： 冲突规则，现在浏览器都会进行DNS缓存
Cookie除了服务器可以设置，客户端也可以通过Document.cookie进行修改，修改后，在后续的网络请求中就会携带上修改后的值
Session
Cookie的缺点，1.会存在体积过大 2 前后端都可进行修改，数据容易被篡改和伪造
Session 的数据只保留在服务器端，客户端无法进行修改，数据也无须在协议中每次都被传递
利用Session如何将每个客户端与服务器对应起来，常见有以下方式
1.基于Cookie来实现用户和数据得映射
cookie中只存放口令，服务器接受到Cookie口令去找对应的Session。
这是目前大多数web应用的方案，如果客户端禁止使用Cookie，瞎
2.通过查询字符串来实现浏览器和服务器端数据的对应。风险比较大
Session 与内存
session引入的问题
1.Session 存放在内存中，用户量增多，内存量的数据会加大，会引起垃圾回收的频繁扫描，影响性能。极端会耗尽内存
2.利用多核CPU开启多个进程启动服务，用户的连接请求会被随意分配到各个进程中，Node的进程与进程之间不能直接共享内存，用户的Session可能会引起混乱，这种问题通过Session集中化，将Session存在缓存中，目前redis，memcached等
数据上传
Node的http模块只对HTTP报文的头部进行解析，然后触发request事件，如果请求中还带有内容部分，内容部分需要用户自行接受和解析。可以通过Transfer-Encoding或Content-Length即可判断请求中是否带有内容
表单数据
最为常见的数据提交是网页表单提交数据到服务器端
默认的表单提交，请求头中的Content-Type字段值为applicant/x-www-form-urlencoded
由于它的内容跟查询字符串相同
req.body = query string.parase(req.rawBody);
后续的业务直接访问req.body就可以
其他格式
除了表单数据外，常见的提交还有JSON/XML文件等，判断和解析的原理都是依据content-type中的值决定。
其中JSON类型的值为application/json ,XML 的值为 application/xml
附件上传
附件的上传表单中含有file类型控件，以及需要制定表单属性encpty为multipart/form-data
浏览器在遇到multipart/form-data表单提交时，构造的请求报文与普通表单完全不同，其中报头
content-type：multipart/form-data; boundary=AaBo3x
content-length:18321;
它代表本次提交内容是由多部分构成，其中boundary代表每部分的分界符，随机产生。
流式解析报文，这里提到的模块为formidable。将接受到的文件写入到系统临时文件夹中，并返回对应的路径。
数据上传内存问题
内存限制：数据上传请求并发量大如果文件存放在内存中，服务器内存很快耗尽。
解决方案：1.限制上传内容的大小。2.采用流式解析，将数据流导向磁盘汇总，Node只保留文件路径等小数据
路由解析
文件路径型
1.静态文件
请求路径对应服务器文件，比较简单
2.动态文件
web服务器根据URL路径找到对应的文件，WEB服务器根据文件名后缀去寻找脚本的解析器，并传入HTTP请求的上下文。
MVC
用户的请求的URL路径可以跟具体的脚本所以得路径没有任何关系。
use('/user/setting', exports.setting);
MVC模型叫业务逻辑按职责分离
工作模式如下：
路由解析，根据URL寻找到对应的控制器和行为。
行为调用相关的模型，进行数据操作
数据操作结束后，调用视图和相关数据进行页面渲染，输出到客户端。
URL 做路由映射，有两种方式1.手工关联映射。2.自然关联映射。
优缺点：手动映射，如果项目较大，路由映射的数量也会很多，从路径到具体的控制器，需要查看代码才能知道。 自然关联映射，如果URL变动，文件也需要变动，手工映射只需要更改路由映射即可
RESTful
representational state transfer 表现层转态转化
设计哲学主要将服务端提供的内容实体看做一个资源，并表现在URL上
例如：
/uses/jacksontian
这个地址代表一个资源，对这个资源的操作，主要体现在HTTP请求方法上，不体现在URL上。
过去对用户的增删改设计的URL为
POST /user/add?username=jack
GET /user/remove?username=jack
POST /user/update?username=jack
GET /user/get?username=jack
在RESTful设计中如下：
POST /user/jack
DELETE /user/jack
PUT /user/jack
GET /user/jack
将DEL PUT 请求方法引入到设计中，参与资源的操作和更改资源状态
RESTful是对MVC更好的改进，相比较，只是将HTTP请求的方法加入了路由的过程，以及在url路径上体现的更资源化
中间件 自看
NODE 学习参考
1.Node.js 开发指南
2.深入浅出 node.js
3 Node.js实战
https://github.com/yantao608/myblog
