构建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