基于Node.js的文件下载服务器

首先表示，并不是我客户端玩腻歪了要玩跨界；另外，代码不是我写的，而是我找的。

        直接上代码地址，不想看唠叨的就直接下载代码就ok了。

        https://github.com/andygrn/Node.js-File-Server

        下载代码后，直接把server.js拖到node.exe图标上就可以运行了，在浏览器中访问http://127.0.0.1:80/可以直接连接下载服务器了。

       

        发现个有趣的问题。两年前在第二家公司里面，也有做下载更新的东西。当时是要求用公司的自己写的下载器。后面我就用网上的简易web服务器搭建了一个测试服务器，发现下载失败，而我自己写的下载器是可以正常下载的。所以就认为公司的有bug。因为没有代码，所以就拜托另外一个组的同事帮忙调试，发现是因为无法获取到文件的大小，而且用Apache搭建的服务器是没有问题的。既然是因为我使用的服务器有问题，我就没有深究。 今天这个问题终于让我弄明白了，多亏了Node.js的服务器有代码，所以很多问题可以深究其理。

       原因很简单，很多web服务器，包含我使用的这个Node.js的服务器，在处理Http请求时只处理'GET'或者'POST'，而libcurl在请求文件大小时使用的是'HEAD'。因为请求的操作服务器不认，就直接返回403 Forbidden了。 而很多时候我们没有获取到真正的错误信息，只能看到文件大小获取为-1。今天跟着调了一下，看到了实际获取的Header内容才明白原因。

      新发现之二：断点续传。之前下载东西时偶尔会看到提示说该服务器不支持断点续传，现在终于明白是怎么回事了。要支持断点续传其实很简单，w3c的一个协议"Range"和"Conteng-Range"，客户端请求时通过"Range"来告诉服务器我要下载那个区间的文件内容，而服务器解析客户端的请求，返回指定的数据流，并通过"Content-Range"来通知客户端。 也就是说，断点续传必须要服务器支持"Range"才行。具体可以参考这篇文章http://www.infoq.com/cn/news/2011/11/tyq-nodejs-static-file-server

        1、为什么要关注下载服务器（文件服务器）？

             因为我要写个多线程断点续传的下载库，当然要有一个服务器进行测试。用Apache搭建的太过困难，乱七八糟的一大堆东西要配置，之前都是使用网上下的简易web服务器。这个倒是能满足需求，不过总会有一些缺点，比如只支持有限的扩展名格式的文件，连接限制等。而恰好我想到前一段时间关注的Node.js，就想干脆自己实现一个，代码都在自己手上，很多东西也好解决。而且后面还会有服务器相关的需求，研究一下也有好处。

       2、为什么要关注Node.js？

            原本我以为服务器就应该要用c++来写，之前公司也说测试过c#的服务器性能不行。但是随着手游的兴起，越来越多的实例表明，服务器可以有很多解决方案，只要自己喜欢用着顺手就是正确的解决方案。很多千万用户量的手游服务器竟然是PHP写的，Java、Go、Erlang也有很多成功的例子。我们可以看到，在某种程度上说，代码级的效率远远比不上设计和结构上的效率提升，更何况很多写c++的人不一定能写出安全高效的代码。

            Node.js就是一个Javascript的解决方案。网易也有推出一个基于Node.js的开源分布式游戏服务器引擎Pomelo。且不论具体代码如何，结构设计上还是非常漂亮的，而且因为Node.js的特性，天生就为解决高并发而来。Node.js是基于Google V8的脱离于浏览器的解析Javascript的应用程序，有非常多的第三方模块。Node.js的设计初衷就是为了解决高并发网络服务器的问题。从这点也可以看到，如果能够从语言或者框架的角度来解决大用户连接的问题的话，那么其实没有必要使用c++来写出一坨蹩脚的代码而且只能支撑800人连接。

        3、使用是否方便？

             如果熟悉了异步编程的习惯，其他的还是很简洁的。毕竟如果一个脚本语言都需要钻研才能写出合格的代码的话，那就是去了脚本语言的本意。

             整个服务器功能比较完善，而代码量只有两百行左右。