TW洞见〡Ruby Web服务器：这十五年

文章作者来自：ThoughtWorks - 韩翼。

坦率的说，作为一门年轻的计算机语言，Ruby在最近二十年里的发展并不算慢。但如果与坐拥豪门的明星语言们相比，Ruby就颇显平民范儿，表现始终不温不火，批评胜于褒奖，下行多过上扬。但总有一些至少曾经自称过Rubyist的程序员们，愉快地实践了这门语言，他们没有丝毫的歧视习惯，总是努力尝试各家之长，以语言表达思想，用基准评判高下，一不小心就影响了整个技术发展的进程。

本文谨以Ruby Web服务器技术的发展为线索，回顾Ruby截至目前最为人所知的Web领域中，重要性数一数二的服务器技术的发展历程，试图帮助我们了解过去，预见未来。

Ruby Web服务器发展时间轴

1

随波逐流

长久以来，任何Web服务器都具备的两项最重要的功能：一是根据RFC2616解析HTTP/1.1协议，二是接收、处理并响应客户端的HTTP请求。幸运的是Web技术的发展并不算太早，使得Ruby恰好能赶上这趟顺风车，但在前期也基本上受限于整个业界的进展。像Apache HTTP Server、Lighttpd和Nginx这些通用型Web服务器＋合适的Web服务器接口即可完成大部分工作，而当时开发者的重心则是放在接口实现上。

cgi.rb

作为Web服务器接口的早期标准，CGI程序在调用过程中，通过环境变量（GET）或$stdin（POST）传递参数，然后将结果返回至$stdout，从而完成Web服务器和应用程序之间的通信。cgi.rb是Ruby官方的CGI协议标准库，发布于2000年的cgi.rb包含HTTP参数获取、Cookie/Session管理、以及生成HTML内容等基本功能。

Web服务器和CGI

当支持CGI应用的Web服务器接到HTTP请求时，需要先创建一个CGI应用进程，并传入相应的参数，当该请求被返回时再销毁该进程。因此CGI原生是单一进程/请求的，特别是每次请求时产生的进程创建/销毁操作消耗了大量系统资源，根本无法满足较高负载的HTTP请求。此外，CGI进程模型还限制了数据库连接池、内存缓存等资源的复用。

对于标准CGI应用存在的单一进程问题，各大厂商分别提出了兼容CGI协议的解决方案，包括网景的NSAPI、微软的ISAPI和后来的Apache API（ASAPI）。上述服务器API的特点是既支持在服务器进程内运行CGI程序，也支持在独立进程中运行CGI程序，但通常需要在服务器进程中嵌入一个插件以支持该API。

Webrick

作为最古老的Ruby Web服务器而不仅仅是一个接口，诞生于2000年的Webrick从Ruby 1.9.3（2011年10月正式发布）起被正式纳入标准库，成为Ruby的默认Web服务器API。Webrick支持HTTP/HTTPS、代理服务器、虚拟主机服务器，以及HTTP基础认证等RFC2617及以外的其它认证算法。同时，一个Webrick服务器还能由多个Webrick服务器或服务器小程序组合，提供类似虚拟主机或路由等功能：例如处理CGI脚本、ERb页面、Ruby块以及目录服务等。

Webrick曾被用于Rails核心团队的开发和测试中。但是，Webrick内置的HTTP Parser非常古老，文档缺失，性能低下且不易维护，功能单一且默认只支持单进程模式（但支持多线程，不过在Rails中默认关闭了对Webrick的多线程支持），根本无法满足产品环境中的并发和日常维护需求。目前一般只用于Web应用的本地开发和基准测试。

fcgi.rb

fcgi.rb是FastCGI协议的Ruby封装（latest版底层依赖libfcgi）。为了与当时的NSAPI竞争，FastCGI协议最初由Open Market提出和开发、并应用于自家Web服务器，延续了前者采用独立进程处理请求的做法：即维持一个FastCGI服务器。当Web服务器接收到HTTP请求时，请求内容和环境信息被通过Socket（本地）或TCP连接（远程）的方式传递至FastCGI服务器进行处理，再通过相反路径返回响应信息。分离进程的好处是Web服务器进程和FastCGI进程是永远保持的，只有相互之间的连接会被断开，避免了进程管理的开销。

Web服务器和FastCGI/SCGI服务器

进一步，FastCGI还支持同时响应多个请求。为了尽量减少资源浪费，若干请求可以复用同一个与Web服务器之间的连接，且支持扩展至多个FastCGI服务器进程。FastCGI降低了Web服务器和应用程序之间的耦合度，进而为解决安全、性能、管理等各方面问题提供新的思路，相比一些嵌入式方案如mod_perl和mod_php更具灵活性。

由于FastCGI协议的开放性，主流Web服务器产品基本都实现了各自的FastCGI插件，从而导致FastCGI方案被广泛使用。fcgi.rb最早开发于1998年，底层包含C和Ruby两种实现方式，早期曾被广泛应用于Rails应用的产品环境。

mod_ruby

mod_ruby是专门针对Apache HTTP Server的Ruby扩展插件，支持在Web服务器中直接运行Ruby CGI代码。由于mod_ruby在多个Apache进程中只能共享同一个Ruby解释器，意味着当同时运行多个Web应用（如Rails）时会发生冲突，存在安全隐患。因此只在一些简单部署环境下被采用，实际上并没有普及。

LiteSpeed API/RubyRunner

LiteSpeed是由LiteSpeed Tech公司最初于2002年发布的商用Web服务器，特点是与被广泛采用的Apache Web服务器的配置文件兼容，但因为采用了事件驱动架构而具有更好的性能。

LiteSpeed API（LSAPI）是LiteSpeed专有的服务器API，LSAPI具备深度优化的IPC协议以提升通信性能。类似其它Web服务器，LiteSpeed支持运行CGI、FastCGI、以及后来的Mongrel。同时在LSAPI的基础上开发了Ruby接口模块，支持运行基于Ruby的Web应用。此外，LiteSpeed还提供RubyRunner插件，允许采用第三方Ruby解释器运行Ruby应用，但综合性能不如直接基于LSAPI Ruby。

由于LiteSpeed是收费产品，其普及率并不高，一般会考虑采用LiteSpeed作为Web服务器的业务场景包括虚拟主机/VPS提供商、以及相关业务的cPanel产品。同时，LiteSpeed也会被用于一些业务需求比较特殊的场合，例如对Web服务器性能要求高，且应用程序及其部署需要兼容Apache服务器。LiteSpeed于2013年发布了开源的轻量Web服务器——OpenLiteSpeed（GPL v3），移除了商业版本中偏具体业务的功能如cPanel等，更倾向于成为通用Web服务器。

scgi.rb

scgi.rb是对SCGI协议的纯Ruby实现。从原理上来看，SCGI和FastCGI类似，二者的性能并无多大差别。但比起后者复杂的协议内容来说，SCGI移除了许多非必要的功能，看起来十分简洁，且实现复杂度更低。

Web服务器和多FastCGI/SCGI服务器

与FastCGI类似，一个SCGI服务器可以动态创建服务器子进程用于处理更多请求（处理完毕将转入睡眠），直至达到配置的子进程上限。当获得Web服务器请求时，SCGI服务器进程会将其转发至子进程，并由子进程运行CGI程序处理该请求。此外，SCGI还能自动销毁退出和崩溃的子进程，具有良好的稳定性。

2

闻名天下

z2005年，David Heinemeier Hansson（DHH）发布了基于Ruby的开发框架Ruby on Rails（Rails），聚光灯第一次聚焦在Ruby身上。但是业内普遍对Web服务器的方案感到棘手，本地环境Webrick/产品环境FastCGI＋通用Web服务器几乎成了标配，无论是开发、部署或维护都遇到不少困难，一些吃螃蟹的人遂把此视为Rails不如J2EE、PHP方案的证据。