fastcgi入门

FastCGI
一种高性能的Web服务器接口
这是技术白皮书。
对GitHub的看法
公开市场，公司，1996年4月

1.导言
业务对Web的使用激增，对创建动态内容的服务器扩展应用程序产生了极大的需求。这些应用程序将允许企业交付产品、服务和消息，这些产品、服务和消息的形状和内容部分取决于与客户的交互和客户的知识。

这种远离静态Web内容的重要动向正在推动这些应用程序当前绑定的环境的局限性和弱点：CGI(公共网关接口)。最重要的是，它没有提供这些应用程序所需的性能。需要一个新的通信基础结构来将Web服务器与这些新应用程序连接起来。这就是开放市场发展FastCGI的原因。

FastCGI是一个快速、开放和安全的Web服务器接口，它解决了CGI固有的性能问题，而不引入专有API(应用程序编程接口)的开销和复杂性。

本文假设读者基本熟悉Web技术和开发Web应用程序。

公共网关接口
Web服务器应用程序的实际标准接口是CGI，它最初是在NCSA服务器中实现的。CGI有许多好处：

简单。这很容易理解。
语言独立。CGI应用程序几乎可以用任何语言编写。
进程隔离。由于应用程序在单独的进程中运行，bug的应用程序不能使Web服务器崩溃或访问服务器的私有内部状态。
开放标准。在每个Web服务器上都实现了某种形式的CGI。
建筑独立性。CGI不与任何特定的服务器体系结构(单线程、多线程等)绑定。
CGI也有一些明显的缺点。首要的问题是性能：由于为每个请求创建了一个新流程，并在完成请求时丢弃，效率很低。

CGI的功能也很有限：它只支持一个简单的“响应者”角色，其中应用程序生成返回给客户端的响应。CGI程序不能链接到Web服务器请求处理的其他阶段，如授权和日志记录。

服务器API
针对CGI的性能问题，一些供应商为其服务器开发了API。最引人注目的两个是Netscape的NSAPI和Microsoft的ISAPI。免费使用的Apache服务器也有一个API。

链接到服务器API的应用程序可能比CGI程序快得多。CGI启动/初始化问题得到了改进，因为应用程序在服务器进程中运行，并且在请求之间持久化。Web服务器API还提供了比CGI更多的功能：您可以编写执行访问控制的扩展，访问服务器的日志文件，并链接到服务器请求处理的其他阶段。

然而，API牺牲了CGI的所有好处。供应商API存在以下问题：

复杂。供应商API引入了一个陡峭的学习曲线，增加了实现和维护成本。
语言依赖性应用程序必须用供应商API支持的语言编写(通常是C/C++)。Perl是CGI程序最流行的语言，不能与任何现有的供应商API一起使用。
没有进程隔离。由于应用程序在服务器的地址空间中运行，bug的应用程序可能会损坏核心服务器(或彼此)。恶意或错误的应用程序可能会危及服务器安全，而核心服务器中的错误可能会损坏应用程序。
专有的。将应用程序编码到特定API将您锁定在特定供应商的服务器上。
连接到服务器架构。API应用程序必须与服务器共享相同的体系结构：如果Web服务器是多线程的，则应用程序必须是线程安全的。如果Web服务器具有单线程进程，则多线程应用程序不会获得任何性能优势。另外，当供应商更改服务器架构时，API通常需要更改，应用程序必须进行调整或重写。
FastCGI
FastCGI接口结合了CGI和供应商API的最佳方面。与CGI一样，FastCGI应用程序在单独的孤立进程中运行。FastCGI的优势包括：

表演。FastCGI进程是持久化的-它们被重用来处理多个请求。这解决了为每个请求创建新进程的CGI性能问题。
简单，易于从CGI迁移。FastCGI应用程序库(在第9页中描述)简化了现有CGI应用程序的迁移。使用应用程序库构建的应用程序也可以作为CGI程序运行，以便与旧Web服务器向后兼容。
语言独立。和CGI一样，FastCGI应用程序可以用任何语言编写，而不仅仅是供应商API支持的语言。
进程隔离。错误的FastCGI应用程序不能使核心服务器或其他应用程序崩溃或损坏。恶意的FastCGI应用程序不能从Web服务器窃取任何秘密(例如用于加密的会话密钥)。
非专利的。开放市场的所有服务器产品都支持FastCGI，目前正在为其他Web服务器开发支持，包括免费提供的Apache和NCSA服务器，以及Microsoft和Netscape的商业服务器。
建筑独立性。FastCGI接口不绑定到特定的服务器体系结构。任何Web服务器都可以实现FastCGI接口。此外，FastCGI不将任何体系结构强加于应用程序：应用程序可以是单线程的，也可以是多线程的，而不管Web服务器的线程结构如何。
支持分布式计算。FastCGI提供了远程运行应用程序的能力，这对于分发负载和管理外部网站非常有用。
以下部分描述了开放市场的WebServer产品中的FastCGI接口、协议、应用程序库和支持。

2.快速CGI接口
FastCGI接口提供的功能非常类似于CGI提供的功能。为了更好地理解FastCGI协议，我们在这里回顾一下CGI接口。基本CGI请求处理过程如下：

对于每个请求，服务器创建一个新进程，进程初始化自己。
Web服务器传递请求信息(例如远程主机、用户名、HTTP头等)。环境变量中的CGI程序。
Web服务器将任何客户端输入(例如从HTML表单输入的字段值)发送到CGI程序的标准输入。
CGI程序将任何输出写入标准输出时返回给客户端。写入标准错误的错误信息由Web服务器记录。
当CGI进程退出时，请求就完成了。
FastCGI在概念上与CGI非常相似，有两个主要区别：

FastCGI进程是持久化的：在完成请求之后，它们等待一个新请求而不是退出。
FastCGI协议不使用操作系统环境变量和管道，而是在一个全双工连接上复用环境信息、标准输入、输出和错误。这允许使用Web服务器和FastCGI应用程序之间的TCP连接在远程计算机上运行FastCGI程序。
单线程FastCGI应用程序中的请求处理过程如下：

Web服务器创建用于处理请求的FastCGI应用程序进程。进程可以在启动时创建，也可以按需创建。
FastCGI程序初始化自己，并等待来自Web服务器的新连接。
当客户端请求传入时，Web服务器将打开到FastCGI进程的连接。服务器通过连接发送CGI环境变量信息和标准输入。
FastCGI进程通过相同的连接将标准输出和错误信息发送回服务器。
当FastCGI进程关闭连接时，请求就完成了。然后，FastCGI进程等待来自Web服务器的另一个连接。
FastCGI应用程序可以在本地(与Web服务器在同一台机器上)或远程运行。对于本地应用程序，服务器使用全双工管道连接到FastCGI应用程序进程。对于远程应用程序，服务器使用TCP连接。

快速CGI应用程序可以是单线程的，也可以是多线程的.对于单线程应用程序，Web服务器维护一个进程池(如果应用程序在本地运行)来处理客户端请求。池的大小是用户可配置的。多线程FastCGI应用程序可以接受来自Web服务器的多个连接，并在单个进程中同时处理它们。(例如，Java的内置多线程、垃圾收集、同步原语和平台无关使它成为多线程FastCGI应用程序的自然实现语言。)

远程FastCGI
FastCGI(通过TCP连接)远程运行应用程序的能力提供了一些主要好处。本节将介绍这些好处，以及影响远程FastCGI应用程序的一些安全问题。

防火墙FastCGI
在组织(外部)Web服务器上运行并依赖内部数据库的应用程序可能是管理方面的一个挑战。图1显示了一个典型的组织，包括一个外部Web服务器、一个限制对内部网络的访问的防火墙以及内部数据库和应用程序。

error-file:TidyOut.log图1

使用CGI和供应商API，应用程序必须在Web服务器机器上运行。这意味着服务器管理员必须将必要的数据库信息复制到承载Web服务器的系统上(这可能很难在不损害防火墙安全的情况下以自动化方式完成)。或者，管理员可以构建一个“桥”，允许通过Web服务器访问内部数据库和应用程序(这实际上是重新发明了远程FastCGI)。

使用远程FastCGI，应用程序可以在内部网络上运行，从而简化管理员的工作。当与适当的防火墙配置和审核一起使用时，这种方法提供了一种安全、高性能、可伸缩的方法，可以将内部应用程序和数据带入外部网络。

负荷分配
对于资源密集型的CGI和API应用程序，Web服务器机器很快成为总体吞吐量的瓶颈。解决此性能问题的通常方法是购买一台更大、更快的Web服务器机器，或者在多个Web服务器之间对Web站点进行分区。

使用远程FastCGI，资源密集型应用程序可以从Web服务器机器上移出，从而使服务器管理员在配置Web服务器时具有更大的灵活性。管理员可以“幕后”配置FastCGI应用程序，而不必更改任何内容链接或网站的外部视图。管理员可以为应用程序使用几台更小、更便宜的服务器机器，并且可以根据其承载的应用程序定制每台机器。

远程FastCGI的安全问题
远程FastCGI连接的两个安全问题是身份验证和隐私。FastCGI应用程序应该只接受来自它们信任的Web服务器的连接(应用程序库包括对IP地址验证的支持)。该协议的未来版本将包括对验证Web服务器的应用程序的支持，以及对在安全传输协议(如SSL或PCT)上运行远程连接的支持。
FastCGI协议
本节简要介绍Web服务器和FastCGI应用程序之间的连接所使用的协议。大多数应用程序开发人员将使用FastCGI应用程序库，而不必担心协议细节。但是，专门的应用程序可以直接实现FastCGI协议。

FastCGI在应用程序和Web服务器之间的连接上使用简单的数据包记录格式。在两个方向上都使用相同的记录格式，如图2所示。

error-file:TidyOut.log图2

协议版本字段指定正在使用的FastCGI协议的版本。Type字段指定记录的类型(在下一节中描述)。请求ID将此记录标识为特定请求，允许在单个连接上复用多个请求。“数据长度”字段指定后面的数据字节数。

不同的FastCGI数据包类型如下：

分组类型 描述
FCGI参数 用于从Web服务器向应用程序发送名称/值对(CGI环境变量)。
FCGI_STDIN 用于将标准输入从Web服务器发送到应用程序。
FCGI数据 用于向应用程序发送筛选器数据(有关更多信息，请参见第7页中描述的筛选器角色)。
FCGI_STDOUT 用于将标准输出从应用程序发送到Web服务器。
FCGI_STDERR 用于从应用程序向Web服务器发送标准错误信息。
FCGI_End请求 结束请求(可以由服务器或应用程序发送)。
有关完整协议详细信息，请参阅FastCGI协议规范，可从本文末尾列出的网站上查阅。

3.应用作用
CGI的一个主要问题是功能有限：CGI程序只能提供对请求的简单响应。FastCGI提供扩展功能，支持三个不同的应用程序“角色”：

回应者。这是基本的FastCGI角色，与CGI今天提供的简单功能相对应。
过滤器。FastCGI应用程序在将请求的Web服务器文件发送到客户端之前对其进行筛选。
授权人。FastCGI程序对请求执行访问控制决定(例如执行用户名/密码数据库查找)。
今后还将确定其他角色。例如，“记录器”角色很有用，FastCGI程序将接收服务器的日志条目，以便进行实时处理和分析。

下面的部分将更详细地描述这些角色。

应答者角色
FastCGI的Responder角色与今天CGI提供的功能相同。当请求进入服务器时，FastCGI程序生成返回给客户端的响应(通常是HTML页面)。

过滤角色
Filter角色允许FastCGI应用程序在将所请求的文件返回给客户端之前处理它。

假设Web服务器被配置为所有文件。SGML扩展由SGML到HTML FastCGI筛选应用程序处理，用户访问以下URL：

/document.sgml

在Web服务器做出访问控制决策并将此URL映射到内容文件后，它将调用FastCGI过滤器应用程序，该文件可用作输入。FastCGI程序的HTML输出被发送回客户端，就像在Responder角色中一样。图3概述了这个过程。

error-file:TidyOut.log图3

过滤器应用程序可以通过缓存筛选结果显著提高性能(服务器在请求信息中提供修改时间，以便应用程序可以在修改服务器文件时刷新缓存)。

筛选器角色对于以下方面非常有用：

即时格式转换
动态文档(例如带有嵌入式SQL查询的文档，或动态广告插入)
应用标准模板：标头、页脚和背景
授权人角色
Authorizer角色允许FastCGI应用程序为请求做出访问控制决策。使用所有请求信息调用FastCGI应用程序，就像Responder角色中的那样。如果授权程序生成“200 OK”HTTP结果，则Web服务器假设允许访问并继续执行请求。(Web服务器可能在最终允许访问之前处理其他访问检查，包括其他FastCGI授权程序。)如果应用程序生成任何其他响应，则该响应将返回给客户端并结束请求。响应可以是任何有效的HTTP响应，包括“拒绝访问”或“重定向”。

Authorizer角色在以下方面非常有用：

基于用户名和密码的访问控制，其中在外部数据库中查找用户信息。
复杂的访问策略，例如基于时间的访问。
智能卡挑战/响应认证。
动态重定向，其中根据请求配置文件将用户发送到不同的页面。
4.FastCGI应用程序库
OpenMarket开发了一个FastCGI应用程序库，它实现了FastCGI协议(向开发人员隐藏协议细节)。这个库使FastCGI程序的实现与编写CGI应用程序一样容易。

应用程序库提供了C语言标准I/O(Stdio)例程的替代品，例如Printf()和获取()。库将对标准输入、标准输出和标准错误的引用转换为FastCGI协议。对其他文件的引用“通过”底层操作系统标准I/O例程。

这种方法有几个好处：

开发人员不必学习新的API来开发FastCGI应用程序。
现有的CGI程序可以通过最小的源更改进行迁移(下面一节将更详细地描述CGI迁移)。
可以在不修改解释器源代码的情况下构建用于Perl、TCL和其他解释语言的FastCGI解释器。
下面是一个简单的FastCGI应用程序：

#include <fcgi_stdio.h>

void main(void)
{
int count = 0;
while(FCGI_Accept() >= 0) {
printf(“Content-type: text/html\r\n”);
printf("\r\n");
printf(“Hello world!
\r\n”);
printf(“Request number %d.”, count++);
}
exit(0);
}
此应用程序向客户端返回一个“HelloWorld”HTML响应。它还保存被访问次数的计数器，在每次请求时显示计数器的值。

这个Fcgi_stdio.h头文件为C标准I/O库提供FastCGI替换例程。这个FCGI_Accept()例程接受来自Web服务器的新请求。

迁移现有CGI程序
应用程序库旨在使现有CGI程序的迁移尽可能简单。可以通过在主请求处理代码周围添加一个循环并使用FastCGI应用程序库重新编译来转换许多应用程序。FastCGI应用程序具有以下结构，具有初始化部分和请求处理循环：

Initialize application;
while(FCGI_Accept() >= 0) {
Process request;
}
为了简化对FastCGI的迁移，使用应用程序库构建的可执行文件可以作为CGI或FastCGI程序运行，这取决于它们的调用方式。库检测执行环境，并根据情况自动选择FastCGI或常规I/O例程。

迁移之后，开发人员可以清理他们的FastCGI应用程序以获得最佳性能：

修复任何资源泄漏。许多CGI程序并不试图管理内存或关闭文件，因为它们认为当它们退出时，这个世界将被清理。(如果您不想清理您的程序，您可以让您的进程假设它正在泄漏内存，并在处理一些固定数量的请求后退出。)Purify From PureSoftware是许多发现泄漏和其他内存使用问题的优秀工具之一。
修复保留的应用程序状态的任何问题。应用程序必须确保它在处理一个请求时创建的任何状态都不会对以后的请求产生意外影响。
折叠功能。CGI应用程序的一个常见做法是实现许多小程序，每个程序只有一个功能。CGI鼓励这一点，因为较小的程序加载速度更快。使用FastCGI，最好在单个可执行文件中具有相关的功能，因此需要管理的进程较少，应用程序可以利用跨功能共享缓存的信息。
使用Perl、TCL和其他脚本语言编写的应用程序可以通过使用应用程序库构建的语言解释器进行迁移。FastCGI-用于流行Unix平台的集成TCL和Perl解释器可从开放市场获得。解释器是向后兼容的：它们可以运行标准的TCL和Perl应用程序。

5.开放市场WebServer中的FastCGI
本节介绍下列公开市场服务器产品中的FastCGI支持：

开放市场WebServerV2.0
开放市场安全WebServerV2.0
开放市场安全WebServer(全球)V2.0
有关FastCGI支持的更多信息，请参见开放市场WebServer安装和配置指南.

服务器配置
FastCGI应用程序使用服务器的配置文件进行配置。配置有两部分。

首先，服务器管理员定义了应用类。对于本地应用程序，应用程序类指定运行FastCGI应用程序的详细信息，如：

应用程序可执行文件的路径名。
在启动时传递给进程的任何参数和环境变量。
要运行的进程数。
对于远程应用程序，类配置信息包括要连接的主机和TCP端口。Web服务器假定FastCGI应用程序已在远程主机上启动。如果请求传入，而服务器无法连接到FastCGITCP端口，则服务器记录错误并将错误页返回给客户端。

第二个配置步骤是将应用程序类映射到一个角色：

对于响应者角色，管理员配置由FastCGI应用程序处理的URL空间的某些部分。例如，以/ROLCALL/开头的所有URL都可能由Employee数据库应用程序处理。
对于筛选器角色，管理员配置要由筛选器应用程序处理的文件扩展名。例如，具有.sql扩展名的所有文件都可以由SQL查询查找筛选器处理。
对于授权者角色，管理员以与其他访问方法(主机名、用户名/密码等)相同的方式配置授权器应用程序。请求必须通过全在允许访问之前进行访问控制检查(可能包括多个FastCGI授权程序)。
基本FastCGI
为了简化现有CGI程序的迁移，WebServer提供了一种简单的方法来安装新的FastCGI程序，而不必重新配置服务器。但是，这种方法并没有提供FastCGI应用程序类的所有性能优势。

WebServer将扩展名为.fcg的任何文件视为FastCGI应用程序。当请求对应于这样的文件时，WebServer将创建一个新的FastCGI进程来处理该请求，并在请求完成时关闭该进程(与CGI中的情况一样)。在这种运行模式下，性能与CGI相当。WebServer的未来版本将通过自动缓存进程并在后续请求中重用它们来提高性能。

会话亲和力
FastCGI程序可以通过在应用程序进程中缓存信息来提高性能。对于需要频繁但昂贵的操作(如在外部数据库中验证每个请求的用户名/密码)的应用程序，这种技术可以显著提高性能。

为了提高该技术的有效性，WebServer实现了会话亲和力。启用会话关联时，WebServer将安排由同一个FastCGI应用程序进程处理用户会话中的所有请求。什么是“会话”是可配置的。默认配置使用WebServer的内置会话跟踪工具来标识用户会话。但是，服务器管理员可以将请求信息的任何部分用于会话关联映射：URL路径、客户端主机名、用户名等。
6.FastCGI性能分析
FastCGI有多快？答案取决于应用程序。本节包含一些真实的FastCGI性能度量，以及估算FastCGI加速比的指南。

FastCGI对CGI
我们使用一个生成固定数量输出字节的简单应用程序来测量OpenMarketWebServer上CGI、FastCGI和静态文件的相对性能。下表显示了典型平台上不同请求类型的测量请求处理时间。时间是从客户端的角度来衡量的，包括客户机、服务器和应用程序处理时间。

类型 每KByte处理时间
静态文件 21毫秒+每千字节0.19毫秒
FastCGI 22毫秒+每千字节0.28毫秒
CGI 59毫秒+每千字节0.37毫秒
FastCGI性能可与提供静态文件相媲美，而且明显优于CGI(清楚地显示了创建进程的高开销)。实际应用程序有一个额外的时间组件：进程初始化，它应该添加到整个请求处理时间中。

让我们使用这些数据来估计将典型的数据库CGI应用程序迁移到FastCGI的加速速度。假设应用程序需要50 ms来初始化数据库连接并生成5K的输出数据。请求性能可计算如下：

类型 处理时间
CGI 59 ms+50 ms+(0.37 ms)(5)=111 ms
FastCGI 22 ms+(0.28 ms)(5)=23 ms
在本例中，FastCGI比CGI具有5倍的性能优势，主要是因为无需为每个请求创建和初始化新进程而节省了费用。
7.结论
今天的Web业务应用程序需要一个快速、开放、可维护、简单、稳定和安全的平台。FastCGI的设计满足了这些要求，并提供了经过验证和广泛部署的CGI技术的逻辑扩展。这使开发人员能够在不损失现有CGI应用程序投资的情况下，利用FastCGI的好处。
8.欲了解更多信息
有关FastCGI协议和开发人员工具包的更多信息，以及有关其他Web服务器中FastCGI标准化和支持的最新信息，请访问FastCGI项目页面：Fastcgi-archives.github.io

本文件为1996年开放市场公司版权所有。

FastCGI Gizub档案馆由米卡诺.