[原创]：致力于稳定高效的web server，中国人自己的web服务器

终于忍受不了windows的独断专行，封闭滞后，用过ubuntu之后将工作学习的重点全部转向了linux，几个月下来感觉还不错。
三年来我一直在致力于建造一个简单高效的web服务器，先后用.net java尝试，结果发现基本的静态文件处理方面都太不如人意，在项目几近封闭的时候放弃了，因为做web已经6－7年了，所以有了一些总结，先是寄希望 于.net的一套合理架构解决我的大部分问题，避免重复劳动，后来发现问题多多，先是想效率不行，然后时常有一些莫名的错误，IIS也经常出错误，所以所 有的上层构建都显得没有意义，也就渐渐是去了信心，后来才下定决心自己作一套web服务器，ruby ror创始人说得好，“可能有一万种方安是和你，但是我们之给你最适合的哪一种”，我计划中的业务模式必须要能满足快速、运行高效、SEO支持度好、分布 式、快速扩展等多种大中型网站的要求，简单来说就是能够快速将Idea变成成熟稳定的web产品，cms就不用说了，只是各种底层之上的玩具，不具有实际 的大规模应用价值，这也是为什么在云云web服务器中还要自己作一套出来的原因。
在后来转向了java，花了大量时间阅读tomcat、resion、jsp等架构于模式，自己构建出来一套简化的能运行java程序（类似于 servlet）web服务器，理念是将所有的业务构建在xml＋xlt之上，对应的不支持的浏览器和搜索引擎采取在服务端执行然后发送的模式，以求达到 速度和SEO的要求，xml由后台控制器产生，可以自定义数据库，采取双备份模式，对于需要认证的页面不产生静态xml，然后还构建了自己的AJAX库， 所有需要SEO支持的页面均采用后台合成，已经有了一定的自动化程度，如果在此基础上继续下去就可以构建类似于cms的应用程序了，这个时候发现整个服务 器的负载是在是不怎么样，那时java还不支持nio的net service,即使支持，介于java本身的复杂度也不可能构建出类似于Nginx的web服务器，那么上面所有的架构旧都是去了意义，那么只能将接近 一年的成果再次搁浅。当然，并不能说浪费了一年的时间，毕竟对于web的内部架构，传统的jsp Asp.net的构够有了深刻的理解，还在中文分词、网络蜘蛛等有了相当的深入，这都得意于java
后来发现了nginx，传奇似的一个web服务器，内存控制相当稳定，运行的也很平稳，速度也很快，超过apache，与lighttpd基本持平，才发 现web服务器是要用c来写的，本来打算借用或者更改模块，但发现阅读别人的代码总是那么困难（可能是本人比较笨），基本的编辑环境都很难构建起来，所以 还是打算从头自己来，一劳永逸，“不要重复造轮子”在这里应该是不适用的，多少年来中国很少有自己的能站的住脚的技术那出来，nginx还是人家俄罗斯 的，ruby也是人家日本的，好的程序不一定都要出自于美国，再说我想要得不是一套专业的商业web服务器，而是一项最适合我业务的定制的web服务器， 正是因为多次尝试更改其他web服务器（tomcat、resoin等实现的异常复杂，每个请求需要10几个类的继承、处理、装发才能到达servlet 执行）的失败与痛苦，才让我更加坚定信心，其实每个web服务器核心只有很少的一块代码，但是他们总是把他层层包装，因为他们需要应对所有的业务模式。
现在我走向了c。
重新拾起c当然是很痛苦的，尤其对于我这种已经习惯了面向对象的语言的人来说，但还是坚持下来了，首先我就很务实，先实现了hashtable、 memory pool,动态array，string等常用功能，一来让自己对c有个熟悉深入的过程，二来有利于将编程习惯多少统一到面相对想的习惯，然后就是web server。
首先我同样是借助于windows的IOCP，同样问题多多，也没有多少业务是构建在其上的，痛苦万分之际遇到了ubuntu，解决了我的基本驱动问题， 让我有能力在全linux环境下工作，也同样让我能够是用epoll进行构架，netbeans c还是不错的编辑器的，虽然相对于visual studio的高度智能远远不及，但是能在linux上有这么个工具已经算是万幸了（6.1才推出c的支持），不过现在最大的问题是对于多线程的调试难了 很多，mem poll等也都是得意于当时在windows下已经用vs调试好了，如果在linux下调试的华就麻烦大了。

现在静态部分已经基本成型，项目源代码不过40个文件，控制200K以内，算是超轻量级的了，局域网环境下测试性能还稍微领先于nginx，大幅领先于apche，ab的结果如下：
100用户并发10000次,环境ubuntu8.04,奔四3.0,1G内存：
我的server（3个读线程3个写线程处理静态请求，本测试在单核机器上没有充分发挥）：
Requests per second: 6906.85 [#/sec] (mean)
Time per request: 14.478 [ms] (mean)
Time per request: 0.145 [ms] (mean, across all concurrent requests)
Transfer rate: 867.50 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 1.3 6 14
Processing: 4 7 1.6 7 22
Waiting: 0 4 1.9 5 21
Total: 11 13 2.0 13 29

Percentage of the requests served within a certain time (ms)
50% 13
66% 14
75% 14
80% 15
90% 16
95% 18
98% 20
99% 20
100% 29 (longest request)


Nging 0.53
Requests per second: 5784.46 [#/sec] (mean)
Time per request: 17.288 [ms] (mean)
Time per request: 0.173 [ms] (mean, across all concurrent requests)
Transfer rate: 1451.32 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 2.6 3 13
Processing: 2 13 4.8 13 34
Waiting: 2 11 4.6 11 33
Total: 8 16 3.8 16 34

Percentage of the requests served within a certain time (ms)
50% 16
66% 17
75% 18
80% 19
90% 22
95% 25
98% 28
99% 29
100% 34 (longest request)
lighttpd/1.4.19
Requests per second: 5948.69 [#/sec] (mean)
Time per request: 16.810 [ms] (mean)
Time per request: 0.168 [ms] (mean, across all concurrent requests)
Transfer rate: 1611.50 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 4 2.7 4 19
Processing: 2 12 5.3 11 43
Waiting: 0 9 4.8 9 37
Total: 6 16 5.6 15 46

Percentage of the requests served within a certain time (ms)
50% 15
66% 17
75% 19
80% 20
90% 23
95% 27
98% 32
99% 36
100% 46 (longest request)
Apache/2.2.8
Requests per second: 3403.92 [#/sec] (mean)
Time per request: 29.378 [ms] (mean)
Time per request: 0.294 [ms] (mean, across all concurrent requests)
Transfer rate: 987.14 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 6.0 4 28
Processing: 4 22 9.9 22 74
Waiting: 2 19 8.7 19 71
Total: 10 28 8.8 27 74

Percentage of the requests served within a certain time (ms)
50% 27
66% 31
75% 34
80% 35
90% 40
95% 45
98% 52
99% 59
100% 74 (longest request)

综合来看，apche是4个中最差的，我的webserver高出他100％还多，nginx和lighttpd都还是不错的，到这一步我仿佛看到了希 望，辛辛苦苦两年多的积累，终于有了一个小的突破，可以让我放心地在此架构上不断完善，使其更加稳定，然后就可以构建上层应用服务

道路还很漫长，随着模块的不断完善只要最终的webserver性能下降不至低于nginx就心满意足了，能够完全掌握起运行状态才是我想要得，以后我会 用更多的文章对于websever的各个部分进行更为严格的测试，包括内存池等基础构建的健壮性都需要时间的考验，但是走过来才发现很多事情做起来比现想象的容易。
这篇文章是我从我baidu博客上转过来的，那里的专业人士比较少，当然这点成绩不足以在这里卖弄。这是几个月前的结果，现在很多部分已经出来了，包括持久连接支持，反向代理等功能，经过进一步优化，现在性能反而有所提升。
做过游戏服务器的人可能觉得http server是很简单的，但是真正作起来了才发现不是这样的，最大的不同在于http的客户端不是固定的，请求是多样的，不受服务器端控制的，网络是及其不稳定的，所以容错性就要高，这恰恰是c的软肋，所以在实现诸如持久连接的过程中就于到了很多麻烦，大家可以在我以后的博客中看到，已经写了大量文章，如有失误之出望多多指教，至于是否开源我觉得不重要，Nginx等大量优秀架构的代码都是开源的，不用心我们照样看不懂，也许等这个服务器出具模型就会开源给大家了，别的优点没有，中文注释还是写得挺全的，有利于国人阅读，附属的一些代码会在下面的博客中先陆续载出来，望大家多多支持。