构建动态服务器基础
发布于 3年前 作者 JacksonTian 6687 次浏览

有同学肯定觉得只看了静态文件服务器是不过瘾的。必须来点动态服务器才行，甚至MVC框架之类的才能摆上台面。但是冰冻三尺，非一日之寒；千寻之塔，也是起于砂石啊。所以这一章的目的是用来构建一个动态服务器的基础，下一章会在这个基础上，构建一个MVC框架。

一门后端动态语言要达到Web的可用水平需要满足那些条件呢。让我们来想想，通常的PHP或是ASP/ASP.NET，甚至是JSP。一些基本的东东是什么呢。


  • Get/Post 数据获取，这个是最基本的

  • Cookie你都不支持，你让Session如何混。

  • Session，对于无状态的HTTP协议，Session的实现帮助后端太多了。


以上这些支持几乎是必须的。缺少一部分，这个服务器都会缺胳膊少腿的。那么有了这些需求之后，我们就来实现吧。

Anyway，架子搭起来先。我们的动态服务器并不是在静态服务器的基础上再增强的，所以需要一个全新的架子。 
var http = require(“http”);



var server = http.createServer(function (request, response){

    response.setHeader("Content-Type", “text/plain”);

    response.writeHead(200, “Ok”);

    // TODO

    // response.write(“”);

    response.end();

});



server.listen(8000);

嗯，还是很简单很朴素的感觉。

Get/Post支持


HTTP请求协议主要包含以下几种请求类型：

  • GET

  • POST

  • HEAD

  • PUT

  • DELETE

  • OPTIONS

  • TRACE


其中最常见的就是GET和POST了。其次，PUT和DELETE在RESTful请求中也是十分常见的。在这里，我们只讨论GET和POST方法。客户端向服务端传递数据也是主要通过这两种方法。那么我们来进一步剖析GET和POST方法吧。

GET方法最为常见，其形式大致如下： 
http://localhost:8000/?foo=bar

用CURL工具来查看下协议的细节吧: 
curl  -v http://localhost:8000/?foo=bar

看看请求头是什么样子： 
GET /?foo=bar HTTP/1.1



User-Agent: curl/7.20.1 (i686-pc-cygwin) libcurl/7.20.1 OpenSSL/0.9.8r zlib/1.

Host: localhost:8000

Accept: /

Get支持只需要分析问号后面的foo=bar部分就ok的。在写出我们Node的代码之前，可以少许的看看PHP和ASP.NET是如何调用的。

PHP： 
$_GET[“name”]

ASP.NET： 
Request.QueryString(“name”)

嗯，接口不错，那我们为Node也写一个接口吧，保持简单，request.get(name)就可以了。Node在处理这个问题上，提供了URL模块和QueryString模块，用于解析URL和QueryString部分（参见：http://nodejs.org/docs/v0.6.1/api/http.html#request.url）。

引入url和querystring模块吧。 
var url = require(“url”);

var qs = require(“querystring”);

对于URL的解析，由于每一个请求进来，并不是每个程序员都需要获取query上的值的。这种场景下，我们没必要为其浪费解析URL的CPU时间，所以延迟解析吧。 
var _urlMap;



request.get = function (key) {

    if (!_urlMap) {

        urlMap = url.parse(request.url, true);

    }

    return urlMap.query[key];

};

只有后续有代码调用到了get方法，才会解析一次。如果没有用到，这里就不占用空间和CPU时间了。

接下来搞定Post方法，接口依然保持一致，那就是request.post(name)。POST请求与GET请求略有不同在于GET请求是不用向服务端发送body部分的报文的。这里有点类似条件请求的响应，如果是304，只有头信息，没有body信息；如果是200，才会将body和头信息一起发回给客户端。这里反之，get请求不用发送body信息，只有post才会发送body信息。所以这里对于前端来说，如果不发送数据到服务端，用get方法可以节省一些带宽的。对于小数据量的发送，通过URL请求发送时携带就足够了。（URL的最大长度在IE下是2k，超过此额度，请用post吧）。

具体参见YSlow的这条Rule：http://developer.yahoo.com/performance/rules.html#ajax_get。

一般而言，POST请求都是通过表单发送出来的。浏览器会自动的将数据编码为foo=bar&baz=xxx这样的格式。而且与get方法不同的是，在接受数据的时候，需要通过监听data事件接受所有数据，因为客户端可能是通过chunk方式逐步发送过来的。 
if (request.method === “POST”) {

    var _postData = "",

        _postMap = "";



    request.on('data’, function (chunk) {

        _postData += chunk;

    })

    .on("end", function () {

        request.postData = _postData;

        request.post = function (key) {

            if (!_postMap) {

                _postMap = qs.parse(_postData);

            }

            return _postMap[key];

        };

    });

}

之所以有request.postData = _postData这样一句，因为客户端上传的并不一定是key=value&key=value的方式，或者是一个json对象，或者是一个xml文档。这个时候这个数据留给程序员自己去再解析。

相同的，一切为了性能，所以延迟解析，并且只在请求方法为POST的时候才有这些方法。

最终的代码大致如下： 
var server = http.createServer(function (request, response) {

    var handle = function () {

        response.setHeader("Content-Type", “text/plain”);

        response.writeHead(200, “Ok”);

        response.write(request.get(“foo”));

        response.write(request.post(“foo”));

        response.end();

    };



    var _urlMap;

    request.get = function (key) {

        if (!_urlMap) {

            urlMap = url.parse(request.url, true);

        }

        return urlMap.query[key];

    };



    if (request.method === “POST”) {

        var _postData = "",

            _postMap = "";



        request.on('data’, function (chunk) {

            _postData += chunk;

        })

        .on("end", function () {

            request.postData = _postData;

            request.post = function (key) {

                if (!_postMap) {

                    _postMap = qs.parse(_postData);

                }

                return _postMap[key];

            };

            handle();

        });

    } else {

        handle();

    }

});

我们通过curl来模拟一次同时带有post数据和get数据的请求吧： 
curl --data “foo=postdata” http://localhost:8000/?foo=getdata

看看响应： 
getdata

postdata

嗯，完全满足需求。（注意：处理文件上传的请求会更复杂，再次不做讨论，如需深入，请移步http://cnodejs.org/blog/?p=2207）

Cookie支持


尽管身为前端工程师，对Cookie有着相当多的怨言。比如不方便调用；每次都会附带在请求中，占用带宽。一个经典的面试题目是，假如客户端禁用了Cookie，Session是否有效？如何有效？

不知各位是否有答案。关于Cookie与Session之间的关系，我们下一节再来详述。先来解释下Cookie是如何工作的吧，在协议里是怎么传递的。

  1. 请求传递Cookie
    如果当前域名下存在Cookie，浏览器在每次发起HTTP请求的时候，都会在请求头中带上这样一项：
    Cookie: UserCookie=AgiTOOpJet; RegisteredUserCookie=PXLgvDECVD; JSESSIONID=BF0844821;
    注意，是每次。

  2. 响应传递Cookie


如果服务端设置了Cookie，则会在相应头里发出这样一项：

Set-Cookie:JSESSIONID=D211F624077921CEACD202C1ACDD30C6; Path=/
注意，这里只是单次的，有需求才发送。浏览器端在接受到这个header之后，会将这项存在客户端，下次发送请求时会带在请求头中。

那么我们要在Node中取得客户端发送过来的cookie就很简单了，从header中读取cookie就ok。

var cookieStr = request.headers.cookie || "";

再次看看别的语言中是如何做cookie获取和调用的:

  • PHP: 
    $_COOKIE[“user”];


  • ASP: 
    Request.Cookies(“firstname”)



中和一下，那么我们要的API就是：request.cookie(key)。 
var _cookieMap;



request.cookie = function (key) {

    if (!_cookieMap) {

        _cookieMap = cookie.parse(request.headers.cookie || “”);

    }

    return _cookieMap[key];

};

嗯，还是延迟解析的老把戏。等等，cookie.parse从哪里来的？ 
var cookie = require(“./cookie”);

嗯，没有枪，没有炮，我们自己造。在写这个具体的parse函数之前，有必要研究一下cookie的格式。老规矩，还是按标准协议（http://www.w3.org/Protocols/rfc2109/rfc2109）来： 
av-pairs        =       av-pair *(“;” av-pair)

av-pair         =       attr [“=” value]        ; optional value

attr            =       token

value           =       word

word            =       token | quoted-string

如果你看不懂以上这段描述的话，我来简单介绍吧。

  1. 通过;分割多个属性/值对。

  2. 属性值对由属性，等号，和值构成。等号和值是可选的，也就是说可能只有属性，没有值。


嗯，仅此而已。那么实现吧。 
exports.parse = function (cookie) {

    var map = {};

    var pairs = cookie.split(“;”);

    pairs.forEach(function (pair) {

        var kv = pair.split(“=”);

        map[kv[0]] = kv[1] || “";

    });



    return map;

};

由于Node使用的是V8，所以可以放心大胆的用这些来自ES5的方法。

在之前的代码中加入响应Cookie： 
response.write(request.cookie(“foo”) + “\n\r”);

然后通过curl伪装cookie测试一下吧： 
curl -i --cookie “foo=cookiedata” --data “foo=postdata” http://localhost:8000/?foo=getdata

响应： 
HTTP/1.1 200 Ok

Content-Type: text/plain

Connection: keep-alive

Transfer-Encoding: chunked



getdata

postdata

cookiedata

嗯，just so so。

再来看看响应cookie吧。同样先对比下API吧：

  • ASP.NET 
    Response.Cookies(“firstname”)="Alex”


  • PHP 
    setcookie(name, value, expire, path, domain);



对比了一下，取个中间的而且符合JavaScript的接口吧：response.setCookie(name, value, expire, path, domain)。

然后再看看响应的cookie头在协议标准里是怎样定义的呢。 
set-cookie      =       “Set-Cookie:” cookies

   cookies         =       1#cookie

   cookie          =       NAME “=” VALUE (“;” cookie-av)

   NAME            =       attr

   VALUE           =       value

   cookie-av       =       “Comment” “=” value

                   |       “Domain” “=” value

                   |       “Max-Age” “=” value

                   |       “Path” “=” value

                   |       “Secure”

                   |       “Version” “=” 1DIGIT

继续用我们能够看懂的语言解释吧：

  1. 响应头是Set-Cookie做key的，值由多个cookie组成。

  2. 每个cookie的必须包含的部分是name和value。

  3. 每个cookie还有一部分选项对，选项对之间通过;来分割。这些选项包含：

    1. Comment，注释【可选】

    2. Domain，域【可选】

    3. Max-Age，标明这个cookie在客户端的最大存活时间，单位时间是秒。如果是0，则直接被禁掉【可选】

    4. Path，标明在域下的那些路径下有效【可选，默认为当前路径】

    5. Secure，这个比较特殊的选项标明的是否是https。【可选】

    6. Version，版本号。【必选】




看到这么多可选项，看起来假定的接口要去适配这么多可选参数，是有点麻烦了（JavaScript没有那么方便的重载函数呀）。那么JSON搞起吧。 
response.setCookie(cookie);

这个cookie对象必选值是name和value。那么我们为这个cookie生成需要的字符串写一个stringify函数吧。

最后要申明一下的是现行的Cookie格式，貌似几乎不包含Comment，Version之类的了。我参考了一些实现后，最后给出的实现是如下这样的。 
exports.stringify = function (cookie) {

    var buffer = [cookie.key, “=", cookie.value];

    if (cookie.expires) {

        buffer.push(" expires=", (new Date(cookie.expires)).toUTCString(), “;”);

    }



    if (cookie.path) {

        buffer.push(" path=", cookie.path, “;”);

    }



    if (cookie.domain) {

        buffer.push(" domain=", cookie.domain, “;”);

    }



    if (cookie.secure) {

        buffer.push(" secure", “;”);

    }



    if (cookie.httpOnly) {

        buffer.push(" httponly”);

    }



    return buffer.join(“”);

};

包装了工具方法之后，对于response.setCookie方法就比较简单了： 
response.setCookie = function (cookieObj) {

    response.setHeader("Set-Cookie", cookie.stringify(cookieObj));

};

由于一次请求可能会设置多个cookie，那个这个代码需要增强一下： 
var _setCookieMap = {};



response.setCookie = function (cookieObj) {

    _setCookieMap[cookieObj.key] = cookie.stringify(cookieObj);

    var returnVal = [];

    for(var key in _setCookieMap) {

         returnVal.push(_setCookieMap[key]);

    }

    response.setHeader("Set-Cookie", returnVal.join(", "));

};

Have a try： 
response.setCookie({key: "username", value: "Jackson"});

response.setCookie({key: "password", value: “xxxxxx"});

用浏览器的网络工具或者curl看看响应头： 
Set-Cookie: username=Jackson, password=xxxxxx

再刷新浏览器检查是否将这两个cookie存储了（存储之后，下次请求会在request头中包含）。

至此，Cookie的底层实现和包装都完成了。

注意：由于Cookie的协议较多，有RFC2109，RFC2965，Netscape标准等，这里主要参考RFC2109标准，然后再根据现有浏览器和服务器的做法再中和实现的，在Chrome下测试通过。

Session支持


上一节提到的如果Cookie被禁用了，那么Session是否可用这个问题。不知各位是否有答案。之所以有这样的一个面试题，其主要的原因是因为大多数的Session的实现，都是依赖Cookie的。而Cookie的作用，很大部分的功劳可以解决HTTP协议是种无状态协议，无法追踪和保持与用户的会话功能。这也是我们要先实现Cookie的一个原因。

下面我们来看一眼截取自某网站的一段响应头： 
Set-Cookie: sid=qwSsRlaZcQqFWC11ojBKW7Jc.vCqINHUqTnWEsH7VB4throHfZnNONt%2FKXwFx5xObRkA; path=/; expires=Tue, 15 Nov 2011 14:21:36 GMT; httpOnly

实际上这段响应头被人拿到手里，甚至是可以构成帐号攻击的，具体细节不解释。

还是继续老规矩吧，看看别的语言中Session的调用接口吧：

  • PHP 
    $_SESSION[‘views’]

    unset($_SESSION[‘views’]);

    session_destroy();


  • ASP 
    Session(“date”)="2001/05/05”

    Session.Contents.Remove(“test2”)

    Contents.RemoveAll()

    Session.Abandon



那么我们的调用API也是很简单的：session.get(name)/session.set(name, value)/session.remove(name)/session.removeAll()/session.abandon()。所以在session.js文件中创建如下内容吧。 
exports.Session = function () {

    this._map = {};

};



Session.prototype.set = function (name, value) {

    this._map[name] = value;

};



Session.prototype.get = function (name) {

    return this._map[name];

};



Session.prototype.remove = function (key) {

    delete this._map[key];

};



Session.prototype.removeAll = function () {

    delete this._map;

    this._map = {};

};

再回顾一下Session的一些特性：

  1. 服务器与每一个用户之间保持一个Session。

  2. 两个用户之间的Session不会被共享。

  3. Session有过期时间。如果在过期时间之前没有更新会话时间，则会超时。


所以我们需要一个Session的管理器来维护客户端与服务端的联系，以及处理超时。像大多数服务器一样，我们的timeout也是可配置的。 
exports.Timeout = 20 * 60 * 1000;

SessionManager因为需要管理全局的Session，所以算是服务器级别的。而Session存在于请求级别中，可以供程序员后续调用。

 


Session Manager干的事情，其实就是检查session，如果不存在或者已经过期了，就重新创建一个新的session，给后续调用。以下是这个流程图的代码实现： 
var sessionId = request.cookie(session.SESSIONID_KEY);

var curSession;



if (sessionId && (curSession = sessionManager.get(sessionId))) {

    if (curSession.isTimeout()) {

        sessionManager.remove(sessionId);

        curSession = sessionManager.renew(response);

    } else {

        curSession.updateTime();

    }

} else {

    curSession = sessionManager.renew(response);

}

至于获取session，判断session是否timeout，以及重新创建一个session的方法实现，直接看代码吧： 
var SessionManager = function (timeout) {

    this.timeout = timeout;

    this._sessions = {};

};



SessionManager.prototype.renew = function (response) {

    var that = this;

    var sessionId = [new Date().getTime(), Math.round(Math.random() * 1000)].join(“”);

    var session = new Session(sessionId);

    session.updateTime();

    this._sessions[sessionId] = session;

    var clientTimeout = 30 * 24 * 60 * 60 * 1000;

    var cookie = {key: SESSIONID_KEY, value: sessionId, path: "/", expires: new Date().getTime() + clientTimeout};

    response.setCookie(cookie);

    return session;

};



SessionManager.prototype.get = function (sessionId) {

    return this._sessions[sessionId];

};



SessionManager.prototype.remove = function (sessionId) {

    delete this._sessions[sessionId];

};



SessionManager.prototype.isTimeout = function (session) {

    return (session._updateTime + this.timeout) < new Date().getTime();

};

业务逻辑代码上起来，常常session的味道吧： 
var handle = function (session) {

    response.setHeader("Content-Type", “text/plain”);

    response.writeHead(200, “Ok”);

    if (!session.get(“username”)) {

        session.set("username", request.get(“username”));

    }

    response.write("Hi, " + session.get(“username”) + “\n\r”);

    response.end();

};

我们首先访问http://localhost:8080/，看看有什么响应： 
Hi, undefined

继续访问http://localhost:8080/?username=jacksontian ： 
Hi, jacksontian

再继续访问http://localhost:8080/，看看是否成功： 
Hi, jacksontian

其实如果你用Chrome来测试这一段的话，也许是不成功的。因为浏览器会同时发送2个请求到服务端，你不知道的那一个是/favicon.ico。为了不影响你的测试，首先干掉这个调皮鬼吧： 
if (request.url == “/favicon.ico”) {

    response.writeHead(404, “Not Found”);

    response.end();

    return;

}

至此，session部分打造完毕。

最后值得注意的是，由于Cookie不能被不同的浏览器共享，所以服务端每次给不同的客户端分配的Session ID是不同的，导致多个浏览器之间不能共享会话。也因为服务端与同一个客户端只根据一个Session ID来做判断，所以通常一个站点不能支持多帐号在一个客户端中同时登陆。

动态服务器与静态服务器对比


一般而言，一个服务器是能够Handle所有的动态静态请求的，比如Apache（添加了PHP模块支持的）。但是我们还是可以简单的分析一下动静态服务器之间的需求差别的。

静态文件服务器:

  • 不需要Cookie，Session之类来保证状态

  • 不需处理GET，POST方法上传的数据

  • 通常具可备缓存性

  • 版本有效性


动态服务器：

  • 需要追踪状态，验证身份

  • 需要处理请求上传的数据，来动态响应

  • 响应不具备可缓存性

  • 永远只有现在一个版本


所以对于Cookie，Session一类的检测和判断，完全不必要放到静态文件服务器上。而动态服务器也是不需要304之类的条件请求和Expires之类的头的。为了提高各自的性能，所以彼此之间不必交叉满足所有需求。

下一章节将会在这部分Get/Post处理，cookie处理，session处理的基础上介绍如何搭建一个MVC框架。

本文代码可于https://github.com/JacksonTian/ping/zipball/dynamic_server 下载

项目地址：https://github.com/JacksonTian/ping 项目改名字为ping了。

9 回复

写的很详细啊，细节很多都考虑到拉~有一块地方建议改写一下，可以提升一点点点点效率：
http.IncomingMessage.prototype.post = function ([arguments]) {
//do something
};
这样省的每次有用户请求，都要去内存创建一个post方法~。
期待你的下一篇文章啊!

请问下 session还有个特点是在用户从进入页面到关闭浏览器的这段时间存在，如果按照这样不是不能判断用户关闭浏览器的吗？

判断浏览器关闭很难的。你可以测试一下大多数的服务器，一般登录后，浏览器关掉再打开，session还会存在的。session通常是客户端与服务器段一定时间没有交互，则会造成过期。

既然session是依赖cookie, 那么有效期当然也是依赖cookie的…

一口气看了静态的和动态的，写的非常好~ 学了好多东西，期待下一篇！什么时候出来呢？

下一篇MVC的，呵呵~~

这么长的文章，没有一点厌烦的看下来了！呵呵，文章真不错！

动态服务器的关键其实是数据库访问，而对于企业应用开发来说，能够访问想 oracle , db2 这样扎实的数据库才是关键。

oracle 访问可以参考 : https://github.com/kaven276/psp.web

或者参考 https://github.com/kaven276/node-oracle-plsql-page

每一步都是关键。

回到顶部