本文是我最近對Node.js學習過程中產生的一個想法,提出來和大家一起探討。
Node.js的HTTP服務器
使用Node.js可以非常容易的實現一個http服務,最簡的例子如官方網站的示例:
1.基于Node.js單線程特性的原因,其健壯性的保證對開發人員要求比較高。
2.服務器上可能已有其他http服務已占用80端口,而非80端口的web服務對用戶顯然不夠友好。
3.Node.js對文件IO處理并沒太大優勢,如作為常規網站可能需同時響應圖片等文件資源。
4.分布式負載場景也是一個挑戰。
所以,使用Node.js作為web服務更多可能是作為游戲服務器接口等類似場景,大多是處理不需用戶直接訪問且僅作數據交換的服務。
基于Nginx作為前端機的Node.js web服務
基于上述原因,如果是使用Node.js搭建的網站形的產品,常規的使用方式是在Node.js的web服務前端放置另一個成熟的http服務器,如最常使用的是Nginx。
然后使用Nginx作為反向代理訪問基于Node.js的web服務。如:
location / {
proxy_pass http://127.0.0.1:1337;
}
location ~ /.(gif|jpg|png|swf|ico|css|js)$ {
root /home/andy/wwwroot/yekai/static;
}
}
這樣就比較好的解決了上面提出的幾個問題。
使用FastCGI協議通訊
不過,上述代理的方式也有一些不是很好的地方。
一個是有可能的場景是需要控制后面的Node.js的web服務的直接http訪問。不過,要解決的話也可以使用自身的服務或者依靠防火墻阻擋。
另外一個是因為代理的方式畢竟是網絡應用層上的方案,也不是很方便直接獲取和處理與客戶端http交互的數據,比如對keep-alive、trunk甚至cookie等的處理。當然這也與代理服務器自身的能力和功能完善程度相關。
所以,我在想嘗試另外一種處理方式,首先想到的就是現在在php web應用上普遍使用的FastCGI的方式。
什么是FastCGI
快速通用網關接口(Fast Common Gateway Interface/FastCGI)是一種讓交互程序與Web服務器通信的協議。
FastCGI產生的背景是用來作為cgi web應用的替代方案,一個最明顯的特點是一個FastCGI服務進程可以用來處理一連串的請求,web服務器會把環境變量和這個頁面請求通過一個socket比如FastCGI進程與web服務器連接起來,連接可用Unix Domain Socket或是一個TCP/IP連接。關于更多的背景知識可以參考Wikipedia的詞條。
Node.js的FastCGI實現
那么理論上我們只需要使用Node.js創建一個FastCGI進程,再指定Nginx的監聽請求發送到這個進程就行了。由于Nginx和Node.js都是基于事件驅動的服務模型,“理論”上應該是天作地合的解決方案。下面我們就親自實現一下。
在Node.js中net模塊剛好可用來建立一個socket服務,為了方便我們就選用unix socket的方式。
在Nginx端的配置稍微修改下:
var server = net.createServer();
server.listen('/tmp/node_fcgi.sock');
server.on('connection', function(sock){
console.log('connection');
sock.on('data', function(data){
console.log(data);
});
});
然后運行(因為權限的原因,請保證Nginx和node腳本使用同一用戶或有相互權限的帳號運行,不然讀寫sock文件會遇到權限問題):
node node_fcgi.js
在瀏覽器訪問,我們看到運行node腳本的終端正常的接收到了數據內容,比如這樣:
這就證明我們的理論基礎已經實現了第一步,接下來只需要搞清楚這個buffer的內容如何解析就行了。
FastCGI協議基礎
FastCGI記錄由一個定長前綴后跟可變數量的內容和填充字節組成。記錄結構如下:
version :FastCGI協議版本,現在默認就用1就好
type :記錄類型,其實可以當做是不同狀態,后面具體說
requestId :請求id,返回時需對應,如果不是多路復用并發的情況,這里直接用1就好
contentLength :內容長度,這里最大長度是65535
paddingLength :填充長度,作用就是長數據填充為滿8字節的整數倍,主要是用來更有效地處理保持對齊的數據,主要是性能考慮
reserved :保留字節,為了后續擴展
contentData :真正的內容數據,一會具體說
paddingData :填充數據,反正都是0,直接忽略就好。
具體的結構和說明請參考官網文檔(http://www.fastcgi.com/devkit/doc/fcgi-spec.html#S3.3)。
請求部分
似乎好像很簡單,就是這樣解析一次拿到數據就行了。不過,這里有一個坑,那就是這里定義的是數據單元(記錄)的結構,并不是整個buffer的結構,整個buffer由一個記錄一個記錄這樣的組成。一開始可能對于我們習慣了前端開發的同學不大好理解,但是這是理解FastCGI協議的基礎,后面還會看到更多例子。
所以,我們需要將一個記錄一個記錄單獨解析出來,根據前面拿到的type來區分記錄。這里是一個簡單的獲取所有記錄的函數:
var body = contentLength ? data.slice(end, contentLength) : null;
rcds.push([type, body, requestId]);
return arguments.callee();
}
}
//使用
sock.on('data', function(data){
getRcds(data, function(rcds){
})();
}
注意這里只是簡單處理,如果有上傳文件等復雜情況這個函數不適應,為了最簡演示就先簡便處理了。同時,也忽略了requestId參數,如果是多路復用的情況下不能忽略,并且處理會需要復雜得多。
接下來就可以根據type來對不同的記錄進行處理了。type的定義如下:
接下來就可以根據記錄的type來解析拿到真正的數據,下面我只拿最常用的FCGI_PARAMS、FCGI_GET_VALUES、FCGI_GET_VALUES_RESULT來說明,好在他們的解析方式是一致的。其他type記錄的解析有自己不同的規則,可以參考規范的定義實現,我這里就不細說了。
FCGI_PARAMS、FCGI_GET_VALUES、FCGI_GET_VALUES_RESULT都是“編碼名-值”類型數據,標準格式為:以名字長度,后跟值的長度,后跟名字,后跟值的形式傳送,其中127字節或更少的長度能在一字節中編碼,而更長的長度總是在四字節中編碼。長度的第一字節的高位指示長度的編碼方式。高位為0意味著一個字節的編碼方式,1意味著四字節的編碼方式??磦€綜合的例子,比如長名短值的情況:
對應的實現js方法示例:
if(body[j] >> 7 == 1){
valueLength = ((body[j++] & 0x7f) << 24) + (body[j++] << 16) + (body[j++] << 8) + body[j++];
} else {
valueLength = body[j++];
}
var ret = body.asciiSlice(j, j + nameLength + valueLength);
name = ret.substring(0, nameLength);
value = ret.substring(nameLength);
params[name] = value;
j += (nameLength + valueLength);
}
return params;
}
這樣就實現了一個簡單可獲取各種參數和環境變量的方法。完善前面的代碼,演示我們如何獲取客戶端ip:
到現在我們已經了解了FastCGI請求部分的基礎,下面接著將響應部分的實現,并最終完成一個簡單的echo應答服務。
響應部分
響應部分相對比較簡單,最簡單的情況只需要發送兩個記錄就行了,那就是FCGI_STDOUT和FCGI_END_REQUEST。
具體記錄實體的內容就不冗述了,直接看代碼吧:
function buffer0(len){
return new Buffer((new Array(len + 1)).join('/u0000'));
};
function writeStdout(data){
var rcdStdoutHd = new Buffer(8),
contendLength = data.length,
paddingLength = 8 - contendLength % 8;
rcdStdoutHd[0] = 1;
rcdStdoutHd[1] = TYPES.FCGI_STDOUT;
rcdStdoutHd[2] = 0;
rcdStdoutHd[3] = 1;
rcdStdoutHd[4] = contendLength >> 8;
rcdStdoutHd[5] = contendLength;
rcdStdoutHd[6] = paddingLength;
rcdStdoutHd[7] = 0;
return Buffer.concat([rcdStdoutHd, data, buffer0(paddingLength)]);
};
function writeHttpHead(){
return writeStdout(new Buffer("HTTP/1.1 200 OK/r/nContent-Type:text/html; charset=utf-8/r/nConnection: close/r/n/r/n"));
}
function writeHttpBody(bodyStr){
var bodyBuffer = [],
body = new Buffer(bodyStr);
for(var i = 0, l = body.length; i < l; i += MaxLength + 1){
bodyBuffer.push(writeStdout(body.slice(i, i + MaxLength)));
}
return Buffer.concat(bodyBuffer);
}
function writeEnd(){
var rcdEndHd = new Buffer(8);
rcdEndHd[0] = 1;
rcdEndHd[1] = TYPES.FCGI_END_REQUEST;
rcdEndHd[2] = 0;
rcdEndHd[3] = 1;
rcdEndHd[4] = 0;
rcdEndHd[5] = 8;
rcdEndHd[6] = 0;
rcdEndHd[7] = 0;
return Buffer.concat([rcdEndHd, buffer0(8)]);
}
return function(data){
return Buffer.concat([writeHttpHead(), writeHttpBody(data), writeEnd()]);
};
})();
在最簡單的情況下,這樣就可以發送一個完整的響應了。把我們最終的代碼修改一下:
對比測試
最后,我們需要考慮的問題是這個方案具體是否具有可行性?可能已經有同學看出了問題,我先把簡單的壓測結果放上來:
500 clients, running 20 sec.
Speed=22131 pages/min, 63359 bytes/sec.
Requests: 6523 susceed, 854 failed.
//proxy方式:
500 clients, running 10 sec.
Speed=28752 pages/min, 73191 bytes/sec.
Requests: 3724 susceed, 1068 failed.
500 clients, running 20 sec.
Speed=26508 pages/min, 66267 bytes/sec.
Requests: 6716 susceed, 2120 failed.
//直接訪問Node.js服務方式:
500 clients, running 10 sec.
Speed=101154 pages/min, 264247 bytes/sec.
Requests: 15729 susceed, 1130 failed.
500 clients, running 20 sec.
Speed=43791 pages/min, 115962 bytes/sec.
Requests: 13898 susceed, 699 failed.
后記
如果有興趣繼續玩的同學可以查看我本文實現的例子源碼,這兩天研究下了協議規范,其實不難。
同時,回頭準備再玩玩uWSGI,不過官方說v8已經在準備直接支持了。
玩得很淺,如有錯誤歡迎指正交流。
新聞熱點
疑難解答