linux 内核被污染,linux早期内核的khttpd服务器--策略污染机制

linux内核差一点就走进了windows的为需求而升级的发展道路从而偏离了它原来 的“只提供机制不提供策略”的道路，那就是在2.4内核时期，内核提供了一个叫做khttpd的内核级别的web服务器，当时linux的性能还不是很 好，比如进程调度算法还是O(n)的方式，而且不能有效利用多处理器的优势，线程的实现还是很拙劣，很多方面没有达到posix的高性能指标，因此当时的 开发者可能就钻进了解决性能瓶颈的牛角尖上，鉴于apache服务器很多都运行在linux上，而且web服务是如此的普遍和重要，因此性能瓶颈也就主要 是apache的性能瓶颈，因此面对这个如此“特化”而又如此不能不管的需求，开发者们只好就事论事地将web服务器单独加速，也就是在内核中实现一个 web加速服务，如果按照这条路走下去，linux最终还会在内核实现ftp，甚至任何用户的需求性的策略，还会把图形处理搬到内核，像windows NT做的那样，不过linux到了2.6内核以后重新找到了自己的坐标，因为没有必要再用那种特化需求的方式解决局部的性能瓶颈了，2.6内核的很多机制 都将性能提高到一个新的水平，以web服务器为例，经测试证明2.6下的web服务器完全比内核实现的khttpd加速服务拥有更好的性能，这证明 linux只提供机制是很好的，用户在这种机制上实现的策略性能并不差，这样责任便分来了，如果说用户的程序在用户使了大劲后性能还是不够好，那么就要看 看内核是否可以提供更好的机制。2.6内核的所作所为完全阻止了开发者们再在某一个方面进行优化，2.6内核的进步是整体的，比如新的调度算法，比如 2.6.17中的splice和tee系统调用，这些都使khttpd没有了存在下去的必要。

策略怎么会污染机制呢？想象一下建筑，早先的是混砖式的结构，现在的大厦都成了全框架结构，看看有何不同，住混砖结构房屋的人可能都为装修犯过愁，因为为 了使客厅显得更大，那么就必须打掉一堵墙，可是那堵墙偏偏是承重墙，于是...现在的框架结构就没有这个问题，屋子里除了几个大柱子就没有别的什么了，你 想垒墙就垒墙，想打掉就打掉，这就是机制和策略，框架就是机制，而内部的墙就是策略，如果你把墙垒到了框架里面，势必会影响美观，也会带来不利影响，你将 再次承受承重墙的压力。在操作系统中，尽量不要去通过内核完成一些需求，内核的作用就是为全体进程服务而不是满足用户的个别需求，尽量在用户空间实现需 求，因为这才是需求的实现地，你在内核实现一个你自己进程的需求，如果别的进程不需要这个需求，那人家还是要承受你这个承重墙的压力，只有一个影响全系统 的需求才可以在内核实现，比如杀毒程序，比如防火墙。而khttpd仅仅是一个web加速服务，根本没有资格进入内核独占一地。

在一篇叫做《内核比较：2.4和2.6上的Web服务》的文章中列举了2.6内核的几个新特性：1.超线程支持，多处理支持无论何时都是不错 的；2.NUMA支持；3.线程改进，在内核中增强了posix的线程支持，比如使用NPTL，撤销了管理线程；4.O(1)调度程序，这个就不多说 了；5.I/O的改进，主要是“2.4 中的全局 I/O 请求锁不再使用。在 2.6 中块 I/O 缓冲区(kiobuf)允许 I/O 请求可以比 PAGE_SIZE 大。”；6.异步I/O，这个也不说了；7.这个是比上述6点更高一层次的，就是splice和tee的加入，这俩系统调用可以在用户空间操作内核，其实 就是一个一个内核缓冲的handle。以上7点使khttpd黯然退却，没有必要继续生存。

无论如何，我还是比较欣赏khttpd本身的设计的，很简单，它的代码框架就是：1.启动一些子内核线程在监听80端口(要看内核的khttpd是主 web服务器还是辅web服务器)的套接字上进行accept，并且实时跟踪子内核线程的数量，根据策略进行数量保持，也就是少了创建新的，多了就干 掉；2.子内核线程accept客户浏览器的连接，对于每一个连接进行处理；3.如果内核可以处理，那么直接将结果回写给客户端套接字；4.如果内核处理 不了，那么就呼叫用户端的套接字进行处理，其实就是交给了用户的web服务器。这些流程间涉及到一些技巧，还是看看代码吧：

void NeedSpawn(struct socket *sock)

{