网络编程(一)丨网络编程的演进——从Apache到Nginx

nginx-apache

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性能比较的文章非常多,基本上有如下的定论:

  1. Nginx在并发性能上比Apache强很多,如果是纯静态资源(图片、JS、CSS)那么Nginx是不二之选。
  2. Apache有mod_php、在PHP类的应用场景下比Nginx部署起来简单很多。一些老的PHP项目用Apache 来配置运行非常的简单,例如Wordpress。
  3. 对于初学者来说Apache配置起来非常复杂冗长的类XML语法,甚至支持在子目录放置.htaccess 文件来配置子目录的属性。Nginx的配置文件相对简单一点。
  4. Nginx的模块比较容易写,可以通过写C的mod实现接口性质的服务,并且拥有惊人的性能。 分支OpenResty,可以配合lua来实现很多自定义功能,兼顾扩展性和性能。

这里我们要着重讨论的是为什么Nginx在并发性能上比Apache要好很多。

想要了解这个问题,不得不先做一些铺垫,讲讲并发网络编程的一些历史:

壹 最原始

最原始的网络编程的伪代码大致是这样:

我们需要了解,最原始的Linux中accept、read、write调用都是 阻塞的(现在,阻塞也是这些调用的默认行为)。这就导致了以上代码只能同时 处理一个连接,所以就有了下面的方法:

贰 每个连接开一个进程

后来,大家想到了办法:

 

用子进程来处理连接,父进程继续等待连接进来。但这种方式有如下两个明显的缺陷:

  1. fork()调用比较费时,需要对进程进行内存拷贝。即使现在的Linux普遍 引入了COW(Copy On Write)技术(fork的时候不做内存拷贝,只有其中一个 副本发生了write的时候才进行copy)加速了fork的效率,但fork依旧是个 比较“重”的系统调用。
  2. 较多的内存占用,也是由于上述的内存复制造成的。

叁 引入线程

得益于之前提过的Linux对于线程的引入,上面例子的开进程,被换成了开线程, 这样,上一小节说的两个缺陷都大大的被缓解了。

肆 进程/线程池

计算机领域有很多算法或者是方法都会用到一种智慧:“空间换时间”。 即用使用更多内存的方式换取更快的运行速度:事先创建出很多进程/线程 ,就像一个池子,这样虽然会浪费一部分的内存,但连接过来的时候就省去了 开启进程/线程的时间。

但这种方式会有一个比较显著的缺陷:当并发数大于进程/线程池的大小的时候 性能就会发生很大的下滑,退化成“贰”的情况。

伍 非阻塞&事件驱动

那么,是不是想要达到高性能就一定要付出高系统资源占用呢? 答案是否定的,如果我们注意观察生活中的一个细节,肯德基和麦当劳的不同 服务方式:

  • 肯德基
    1. 服务员在前台问:“先生/小姐,有什么可以帮你?”
    2. 顾客,思考一下点什么比较好:“我要,xxxxx”
    3. 服务员去后台配餐、取餐,3分钟过去了:“您的餐齐了,下一位”
  • 麦当劳
    1. 服务员在前台问:“先生/小姐,有什么可以帮你?”
    2. 顾客:“我要,xxxxx”。如果顾客思考超过5秒:“后面的顾客请先点”; 点完餐,前台服务员继续为下一位顾客点餐。后台有别的服务员完成配餐。

可以思考一下,这两种运作方式那种比较好:

  1. 在肯德基,如果遇到需要纠结半天吃什么的客户。服务员和后面的顾客 都会陷入较长时间的等候。原因就是如果最前面的客户先让后面的顾客点餐 ,他想好了还需要较长时间的等候。相比之下,麦当劳就更胜一筹。
  2. 在麦当劳,后面配餐的服务员如果发现有两个订单都要了可乐。他可以 智能地把两个订单的可乐一次性灌好,这样会大大的提高效率。各个岗位上 的服务员可以灵活的采用各种方式优化自己的工作效率。

这里,肯德基的服务方式就是古老的进程/线程池;麦当劳的服务方式 就是一个简单的非阻塞&事件驱动。

那么,非阻塞&事件驱动这么好,为什么大家没有一开始就采用这种方式呢? 原因有二:

  1. 非阻塞&事件驱动需要系统的支持,提供non-blocking版的整套 系统调用。
  2. 非阻塞&事件驱动编程难度较大,需要很高的抽象思维能力, 把整个任务拆解;采用有限状态机编程才能实现。

更多精彩,请见 Reboot教育 – 高效你的学习

文章分类 后端

发表评论

电子邮件地址不会被公开。

在线交流

数百位业内高手和同行在等你交流
Reboot运维开发分享