Apache
Apache HTTP服务器是 Robert McCool 在1995年写成，并在1999年开始在Apache软件基金会的 框架下进行开发。由于Apache HTTP服务器是基金会最开始的一个项目也是最为有名的一个项目， 所以通常大家提到Apache这个词都是说的Apache HTTP Server。
Apache web服务器从1996年开始就是互联网上最为流行的HTTP服务器。Apache之所以这么流行 很大程度上是由于相比其他的软件项目，在Apache基金会的精心维护下他的文档十分的详尽还有 集成的支持服务。
Apache由于其可变性、高性能和广泛的支持，经常是系统管理员的首选。他可以通过一系列 的语言相关的扩展模块支持很多解释型语言的后端，而不需要连接一个独立的后端程序。
Apache软件基金会也是利用开源软件盈利的一个范本。时至今日，Apache软件基金会 已经枝繁叶茂，在基金会名下的开源项目我们耳熟能详的有：
- Apache HTTP Server
- Ant（Java的编译工具）
- ActiveMQ（MQ集群）
- Cassandra（强一致的分布式KV数据库）
- CloudStack（OpenStack的劲敌）
- CouchDB（KV数据库）
- Flume（日志收集工具）
- Hadoop、Hbase、Hive
- Kafka（流式计算）
- Lucene（开源搜索引擎）
- Maven（Java编译&依赖管理工具）
- Mesos（分布式协调）
- OpenNLP（开源自然语言处理库）
- OpenOffice（开源的类Office工具）
- Perl（Perl语言）
- Spark（分布式计算集群）
- Storm（流式计算）
- Structs（Java SSH框架的第二个S）
- Subversion（SVN，你懂的）
- Tcl（Tcl语言）
- Thrift（Java网络框架）
- Tomcat（大名鼎鼎的Java容器）
- ZooKeeper（分布式协调集群）
完整的Apache基金会的项目列表参见：Welcome to The Apache Software Foundation!
Nginx
2002年，一个叫Igor Sysoev的俄罗斯哥们儿（貌似俄罗斯叫Igor的人挺多的） 写出了一个叫Nginx（和Engine X谐音，取引擎之义）。 那时候有一个时代背景，当时C10K（Concurrency 10K，1万并发）问题还是困扰绝大多数 web服务器的一个难题。Nginx利用异步事件驱动的架构写成，是C10K问题的一个很好的答卷。 Nginx的第一个公开发行版是在2004年发布的，之前都是作为俄罗斯访问量第二的网站Rambler 的内部使用。
Nginx的主要优势在于“轻、快、活”：
轻
很低的资源占用，甚至能在很多嵌入式设备上运行。
快
响应速度超快，几乎不会由于高并发影响响应速度。
活
配置灵活，广泛的模块支持。
网上关于Apache和Nginx性能比较的文章非常多，基本上有如下的定论：
- Nginx在并发性能上比Apache强很多，如果是纯静态资源（图片、JS、CSS）那么Nginx是不二之选。
- Apache有mod_php、在PHP类的应用场景下比Nginx部署起来简单很多。一些老的PHP项目用Apache 来配置运行非常的简单，例如Wordpress。
- 对于初学者来说Apache配置起来非常复杂冗长的类XML语法，甚至支持在子目录放置.htaccess 文件来配置子目录的属性。Nginx的配置文件相对简单一点。
- Nginx的模块比较容易写，可以通过写C的mod实现接口性质的服务，并且拥有惊人的性能。 分支OpenResty，可以配合lua来实现很多自定义功能，兼顾扩展性和性能。
这里我们要着重讨论的是为什么Nginx在并发性能上比Apache要好很多。
想要了解这个问题，不得不先做一些铺垫，讲讲并发网络编程的一些历史：
壹 最原始
最原始的网络编程的伪代码大致是这样：
|
1
2
3
4
5
6
|
listen(port) # 监听在接收服务的端口上
while True: # 一直循环
conn = accept() # 接收连接
read_content = read(conn) # 读取连接发送过来的请求
response = process(conn) # 执行业务逻辑，并得到给客户端回应的内容
conn.write(response) # 将回应写回给连接
|
我们需要了解，最原始的Linux中accept、read、write调用都是 阻塞的（现在，阻塞也是这些调用的默认行为）。这就导致了以上代码只能同时 处理一个连接，所以就有了下面的方法：
贰 每个连接开一个进程
后来，大家想到了办法：
|
1
2
3
4
5
6
7
8
|
listen(port) # 监听在接收服务的端口上
while True: # 一直循环
conn = accept() # 接收连接
if fork() == 0:
# 子进程
read_content = read(conn) # 读取连接发送过来的请求
response = process(conn) # 执行业务逻辑，并得到给客户端回应的内容
conn.write(response) # 将回应写回给连接
|
用子进程来处理连接，父进程继续等待连接进来。但这种方式有如下两个明显的缺陷：
- fork()调用比较费时，需要对进程进行内存拷贝。即使现在的Linux普遍 引入了COW（Copy On Write）技术（fork的时候不做内存拷贝，只有其中一个 副本发生了write的时候才进行copy）加速了fork的效率，但fork依旧是个 比较“重”的系统调用。
- 较多的内存占用，也是由于上述的内存复制造成的。
叁 引入线程
得益于之前提过的Linux对于线程的引入，上面例子的开进程，被换成了开线程， 这样，上一小节说的两个缺陷都大大的被缓解了。
肆 进程/线程池
计算机领域有很多算法或者是方法都会用到一种智慧：“空间换时间”。 即用使用更多内存的方式换取更快的运行速度：事先创建出很多进程/线程 ，就像一个池子，这样虽然会浪费一部分的内存，但连接过来的时候就省去了 开启进程/线程的时间。
但这种方式会有一个比较显著的缺陷：当并发数大于进程/线程池的大小的时候 性能就会发生很大的下滑，退化成“贰”的情况。
伍 非阻塞&事件驱动
那么，是不是想要达到高性能就一定要付出高系统资源占用呢？ 答案是否定的，如果我们注意观察生活中的一个细节，肯德基和麦当劳的不同 服务方式：
- 肯德基
- 服务员在前台问：“先生/小姐，有什么可以帮你？”
- 顾客，思考一下点什么比较好：“我要，xxxxx”
- 服务员去后台配餐、取餐，3分钟过去了：“您的餐齐了，下一位”
- 麦当劳
- 服务员在前台问：“先生/小姐，有什么可以帮你？”
- 顾客：“我要，xxxxx”。如果顾客思考超过5秒：“后面的顾客请先点”； 点完餐，前台服务员继续为下一位顾客点餐。后台有别的服务员完成配餐。
可以思考一下，这两种运作方式那种比较好：
- 在肯德基，如果遇到需要纠结半天吃什么的客户。服务员和后面的顾客 都会陷入较长时间的等候。原因就是如果最前面的客户先让后面的顾客点餐 ，他想好了还需要较长时间的等候。相比之下，麦当劳就更胜一筹。
- 在麦当劳，后面配餐的服务员如果发现有两个订单都要了可乐。他可以 智能地把两个订单的可乐一次性灌好，这样会大大的提高效率。各个岗位上 的服务员可以灵活的采用各种方式优化自己的工作效率。
这里，肯德基的服务方式就是古老的进程/线程池；麦当劳的服务方式 就是一个简单的非阻塞&事件驱动。
那么，非阻塞&事件驱动这么好，为什么大家没有一开始就采用这种方式呢？ 原因有二：
- 非阻塞&事件驱动需要系统的支持，提供non-blocking版的整套 系统调用。
- 非阻塞&事件驱动编程难度较大，需要很高的抽象思维能力， 把整个任务拆解；采用有限状态机编程才能实现。
更多精彩，请见 Reboot教育 – 高效你的学习