[轉載]FastCGI: A High-Performance Web Server Interface （1）

本文檔翻譯英文技術原文文檔來自：http://www.fastcgi.com/drupal/node/6?q=node/15 

Technical White Paper（技術白皮書）

FastCGI: A High-Performance Web Server Interface （FastCGI:一種高性能的WEB服務器接口）

April 1996

---

 

 

1. Introduction

The surge in the use of the Web by business has created a tremendous need for server extension applications that create dynamic content. These are the applications that will allow businesses to deliver products, services, and messages whose shape and content are in part determined by the interaction with, and knowledge of, the customers to which they are delivered.

This important movement away from static Web content is pushing the limits and exposing the weaknesses of the environment in which these applications are currently bound: CGI (Common Gateway Interface). Most importantly it does not offer the performance these applications require. A new communication infrastructure is needed to connect Web servers with these new applications. This is what led Open Market to develop FastCGI.  

FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI, without introducing the overhead and complexity of proprietary APIs (Application Programming Interfaces).

FastCGI是一種快速，開放，而且安全的WEB服務器接口用以解決CGI固有的性能問題。 不引用開銷和複雜的專用的APIs(應用程序接口）。

This paper assumes that the reader has basic familiarity with Web technology and developing Web applications.

本文檔假定讀都已經熟悉基本的web技術和web應用程序開發技術。

• Simplicity. It is easy to understand.
• 簡單性。這很容易理解。
• Language independence. CGI applications can be written in nearly any language.
• 獨立於語言。CGI應用能夠用任何語言寫成。
• Process isolation. Since applications run in separate processes, buggy applications cannot crash the Web server or access the server's private internal state.
• 進程隔離。因爲應用程序運行於獨立的進程中，有嚴重BUG的應用程序不能引發web服務器崩潰或者訪問服務器的內部狀態。
• Open standard. Some form of CGI has been implemented on every Web server.
• 標準開放。CGI的某些格式已被實施在每一個web服務器上。
• Architecture independence. CGI is not tied to any particular server architecture (single threaded, multi-threaded, etc.).
• 獨立的架構。CGI不依賴於任何的服務器架構（單獨線程，多線程，等等）。

 CGI also has some significant drawbacks. The leading problem is performance: Since a new process is created for each request and thrown away when the request is done, efficiency is poor.

CGI也有一些明顯的缺憾。首要問題是執行：因爲要爲每一個請求生成一個新進程，處理完成後再終止它。效率不好。

CGI also has limited functionality: It only supports a simple "responder" role, where the application generates the response that is returned to the client. CGI programs can't link into other stages of Web server request processing, such as authorization and logging.

CGI也有功能限制：它僅僅支持一個簡單的「響應者」角色，由應用程序生成響應返回給客戶端。CGI程序不能連接進入到web服務器請求處理的其它階段。例如登陸與驗證。

Server APIs （服務器APIs)

In response to the performance problems for CGI, several vendors have developed APIs for their servers. The two most notable are NSAPI from Netscape and ISAPI from Microsoft. The freely available Apache server also has an API.

在迴應CGI執行效能問題上，某些供應商開發了他們本身的服務器API。兩個最顯著的是API是來自Netcape的NSAPI和來自Microsoft的ISAPI。免費可用的Apache也有一個API。

 Applications linked into the server API may be significantly faster than CGI programs. The CGI startup/initialization problem is improved, because the application runs in the server process and is persistent across requests. Web server APIs also offer more functionality than CGI: you can write extensions that perform access control, get access to the server's log file, and link in to other stages in the server's request processing.

應用程序連接到服務器API也許會效率會比CGI程序更快，CGI的啓動/初始化問題獲得改善。由於應用程序運行在服務器進程中而且在服務器上是持續請求。WEB服務器APIs也比CGI提供的功能要多：你能夠寫擴展，執行訪問控制，得到服務器的訪問日誌文件，還能夠連接到服務器請求處理的其它階段。

However, APIs sacrifice all of CGI's benefits. Vendor APIs have the following problems

然而，APIs犧牲了整個CGI的功效。供應商APIs有如下問題：

• Complexity. Vendor APIs introduce a steep learning curve, with increased implementation and maintenance costs.
• 複雜性。供應商APIs引入陡峭學習曲線，增長了實施和維護成本。
• Language dependence. Applications have to be written in a language supported by the vendor API (usually C/C++). Perl, the most popular language for CGI programs, can't be used with any existing vendor API.
• 語言獨立。應用程序必須由供應商支持的語言編寫（一般爲C、C++）。PERL,最流行的CGI程序語言，不能被任何已存在的供應商API使用。
• No process isolation. Since the applications run in the server's address space, buggy applications can corrupt the core server (or each other). A malicious or buggy application can compromise server security, and bugs in the core server can corrupt applications.
• 非進和隔離。因爲應用程序運行在服務器的地址空間，應用程序的嚴重BUG能引發核心服務器失效（或相互失效）。惡意的或者嚴重的應用程序BUG可使服務器陷於不安全。而且核心服務器的BUG也能讓應用程序中斷。
• Proprietary. Coding your application to a particular API locks you into a particular vendor's server.
• 專有性。編碼你的應用程序到一個專用的API就鎖定你只能使用特定供應商的服務器。
• Tie-in to server architecture. API applications have to share the same architecture as the server: If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has single-threaded processes, multi-threaded applications don't gain any performance advantage. Also, when the vendor changes the server's architecture, the API will usually have to change, and applications will have to be adapted or rewritten.
• 綁定服務器架構。API應用程序必須共享與服務器架構同樣，若是WEB服務器是多線程，應用程序線程必須是安全的。若是WEB服務器是獨立的線程處理，多線程應用程序不會得到任何性能上的優點。一樣，供應商改變服務器架構，API一般不得不改變。並且應用程將必須適應這種改變或重寫。

FastCGI

The FastCGI interface combines the best aspects of CGI and vendor APIs. Like CGI, FastCGI applications run in separate, isolated processes. FastCGI's advantages include:

FastCGI接品是綁定CGI和供商APIs的最佳組合。有點像CGI，FastCGI應用程序運行在單獨，隔離的進程環境中，FastCGI的特色包括：

• Performance. FastCGI processes are persistent-they are reused to handle multiple requests. This solves the CGI performance problem of creating new processes for each request.
• 性能。FastCGI進程是持續的他們處理多個請求能重複的使用。這樣就解決了CGI爲每一個請求建立新進程的執行效率問題。
• Simplicity, with easy migration from CGI. The FastCGI application library (described on page 9) simplifies the migration of existing CGI applications. Applications built with the application library can also run as CGI programs, for backward compatibility with old Web servers.
• 簡單。方便從CGI遷移。FastCGI應用程序庫簡化了已存在CGI應用程序的遷移。跟應用程序構建在一塊兒的應用程序庫也能運行CGI程序，向後兼容舊的WEB服務器。
• Language independence. Like CGI, FastCGI applications can be written in any language, not just languages supported by the vendor API.
• 語言獨立性。如同CGI，FastCGI應用程序可用任何語言編寫，不只僅是被供應商API所支持的語言。
• Process isolation. A buggy FastCGI application cannot crash or corrupt the core server or other applications. A malicious FastCGI application cannot steal any secrets (such as session keys for encryption) from the Web server.
• 進程隔離。一個有bug的FastCGI應用程序不會引起核心服務或者其它應用程序器崩潰或失敗，惡意的FastCGI應用程序不能從WEB服務器上盜取機密（如加密會話密鑰）
• Non-proprietary. FastCGI is supported in all of Open Market's server products, and support is under development for other Web servers, including the freely available Apache and NCSA servers, as well as commercial servers from Microsoft and Netscape.
• 非專用。FastCGI已被Open Market的服務器產品支持。並且還支持在其它WEB服務器下進行開發。包括名費的可用的Apache以及NCSA服務器，以及微軟和網景的商業服務器。
• Architecture independence. The FastCGI interface is not tied to a particular server architecture. Any Web server can implement the FastCGI interface. Also, FastCGI does not impose any architecture on the application: applications can be single or multi-threaded, regardless of the threading architecture of the Web server.
• 架構獨立性。FastCGI接口不綁定專有的服務器架構。任何WEB服務器都能運行實施FCGI接口，一樣，FCGI沒有在應用程序上強迫規定任何架構：應用程序能單進程或多線程，不會管WEB服務器是否是多線架構。
• Support for distributed computing. FastCGI provides the ability to run applications remotely, which is useful for distributing load and managing external Web sites.
• 支持分佈式計算。FCGI提供了遠程運行應用程序的能力，這對分佈負載和管理外部WEB站點頗有用。

The following sections describe the FastCGI interface, protocol, application library, and support in Open Market's WebServer products 

 下面的部份描術了FastCGI接品，協議，應用程序庫，以及Open Market的WEB服務器產品支持。

2. FastCGI Interface

2.FastCGI接口

The functionality provided by the FastCGI interface is very similar to that provided by CGI. To best understand the FastCGI protocol, we review the CGI interface here. Basic CGI request processing proceeds as follows:

因爲FastCGI接口提供的功能很是相似CGI接口。爲了更好地了理解FastCGI協議。咱們在這裏回顧一下CGI接口。基本的CGI請求處理過程以下：

1. For each request, the server creates a new process and the process initializes itself. 對於每一個請求而言，服務器會建立一個新的進程並完成自身初始化。
2. The Web server passes the request information (such as remote host, username, HTTP headers, etc.) to the CGI program in environment variables.WEB服務器傳遞請求給CGI程序的環境變量。（例如：遠程主機，用戶名，HTTP頭，等）。
3. The Web server sends any client input (such as user-entered field values from an HTML form) to the CGI program's standard input. WEB服務器傳送任何客戶端的輸入到CGI程序的標準輸入。（例如：用戶在HTML表單域中輸入的值）。
4. The CGI program writes any output to be returned to the client on standard output. Error information written to standard error is logged by the Web server. CGI程序全部的輸入信息寫入標準輸出並返回到客戶端，錯誤信息寫入標準錯誤日誌並由WEB服務器記錄。
5. When the CGI process exits, the request is complete.完成請求的處理後，CGI程序就退出。

 

FastCGI is conceptually very similar to CGI, with two major differences:

FastCGI的概念與CGI很相似，主要有兩方面的不一樣：

• FastCGI processes are persistent: after finishing a request, they wait for a new request instead of exiting.
• FastCGI處理是持續的：完成一個請求後，他們會等待新請求而不是退出。
• Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the environment information, standard input, output and error over a single full-duplex connection. This allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the FastCGI application.
• 而不是使操做系統環境變量與管道，FastCGI協議複用環境信息。一個單獨的全雙工鏈接上之上的標準輸入，輸出和錯誤。這就容許FastCGI程序運行在遠程機器上，在各個WEB務器和應用程序之間使用TCP鏈接。

 

Request processing in a single-threaded FastCGI application proceeds as follows:

FastCGI應用程序在單獨的線程中持續處理請求以下：

1. The Web server creates FastCGI application processes to handle requests. The processes may be created at startup, or created on demand. Web服務器建立FastCGI應用程序處理請求。進程也許在開始時建立或根據須要建立。
2. The FastCGI program initializes itself, and waits for a new connection from the Web server. FastCGI程序初始化自已從WEB服務器等待新的鏈接請求。
3. When a client request comes in, the Web server opens a connection to the FastCGI process. The server sends the CGI environment variable information and standard input over the connection.當客戶端請求到來時，WEB服務器打開一個鏈接讓FastCGI處理。服務器在鏈接上傳送CGI環境變量信息和標準輸入。
4. The FastCGI process sends the standard output and error information back to the server over the same connection. FastCGI處理髮送來的信息再經過同一個鏈接將信息返回給標準輸出和標準備錯誤。
5. When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for another connection from the Web server. 當FastCGI處理完成請求，關閉鏈接。FastCGI進程等待從web服務器發來的其它鏈接請求。

 

FastCGI applications can run locally (on the same machine as the Web server) or remotely. For local applications, the server uses a full-duplex pipe to connect to the FastCGI application process. For remote applications, the server uses a TCP connection.

FastCGI應用程序能夠運行在本地（同一臺機器上的WEB服務器）也能運行在遠程。對於本地應用程序服務器使用全雙工管道鏈接到FastCGI應用程序，對於遠程應用程序服務器使用TCP鏈接。

FastCGI applications can be single-threaded or multi-threaded. For single threaded applications, the Web server maintains a pool of processes (if the application is running locally) to handle client requests. The size of the pool is user configurable. Multi-threaded FastCGI applications may accept multiple connections from the Web server and handle them simultaneously in a single process. (For example, Java's built-in multi-threading, garbage collection, synchronization primitives, and platform independence make it a natural implementation language for multi-threaded FastCGI applications.)

FastCGI應用程序能夠是單線程或多線程的。對於單線程應用程序，web服務器維護一個進程池處理客戶端請求（若是應用程序是運行在本地），這個進程池的大小可由用戶配置。多線程FastCGI應用程序能夠同時接受來自web服務器的多個鏈接請並在同一個進程中同時處理它們。（例如：JAVA的內建的多線程，垃圾回收，派生同步，以及平臺獨立性使它成爲一門天然的多線程FastCGI應用程序語言）。

Remote FastCGI 遠程FastCGI

FastCGI's ability to run applications remotely (over a TCP connection) provides some major benefits. These benefits are described in this section, along with some of the security issues that affect remote FastCGI applications.

FastCGI的遠程運行應用程序能力提供了某些好處（經過TCP鏈接）。這些好處及某些安全性問題及對FastCGI應用程序產生的影響在本節中描述。

FastCGI with Firewalls FastCGI與防火牆

Applications that run on organizational (external) Web servers and depend on internal databases can be a challenge to administer. Figure 1 shows a typical organization, with an external Web server, a firewall restricting access to the internal network, and internal databases and applications.

應用程序遠程在組織的外部web服務器而且依賴內部的數據庫對系統管理是種挑戰。圖1 顯示了典型的組織架構，外部WEB服務器經過防火牆限制訪問內部網絡和內部數據庫及應用。

With CGI and vendor APIs, the application has to run on the Web server machine. This means the server administrator has to replicate the necessary database information onto the system hosting the Web server (which may be difficult to do in an automated way without compromising firewall security). Or, the administrator may build a "bridge" that allows access through the Web server to internal databases and applications (which is effectively re-inventing remote FastCGI).

因爲CGI和供應商APIs應用程序能在web服務器計算機上運行，這意味着服務器管理員不得不託管系統主機web務器必需的數據庫信息。（要是沒有防火牆安全折中辦法這極可能是種很難作到的一種自動方法）或者，系統管理員也能夠構建「橋樑」容許經過web服務器訪問內部數據庫和應用程序(這其實是從新發明遠程FastCGI)

With remote FastCGI, the applications can run on the internal network, simplifying the administrator's job. When used with appropriate firewall configuration and auditing, this approach provides a secure, high-performance, scalable way to bring internal applications and data to the external network.

 因爲遠程的FastCGI應用程序也能運行在內部網絡，簡化了系統管理員工做。當使用適當的防火牆配置與審計，這種方法提供了一個安全，高性能，可擴展，實現了內部應用程序和數據到外部網絡的辦法。

Load Distribution 分頁負載

For resource-intensive CGI and API applications, the Web server machine quickly becomes the bottleneck for overall throughput. The usual way to solve this performance problem is to buy a bigger, faster Web server machine, or to partition the Web site across several Web servers.

對於資源密集型CGI和API應用程序，WEB服務器很快就變成整整個吞吐量的瓶頸。一般解決這個問題的方法就購買一個更大，更快的計算機。或都將web 站點分在計算機的幾個分區上面。

With remote FastCGI, the resource-intensive applications can be moved off the Web server machine, giving the server administrator additional flexibility in configuring the Web server. The administrator can configure FastCGI applications "behind the scenes" without having to change any content links or the external view of the Web site. The administrator can use several smaller, inexpensive server machines for applications, and can tailor each machine to the application it is hosting.

對於遠程FastCGI,資源密集型的應用程序能夠移出web服務器，給予服務器管理員配置服務器更大的靈活性,管理員能夠在「幕後」配置FastCGI應用程序不用改變任何鏈接內容或web站點的外部視圖。系統管理員能夠爲應用程序使用幾臺小型的，廉價的機器，並能照每臺機器分擔應用承載

Security Issues with Remote FastCGI 遠程FastCGI與安全問題

The two security issues with remote FastCGI connections are authentication and privacy. FastCGI applications should only accept connections from Web servers that they trust (the application library includes support for IP address validation). Future versions of the protocol will include support for applications authenticating Web servers, as well as support for running remote connections over secure transport protocols such as SSL or PCT.

遠程FastCGI鏈接的兩個安全問題是認證和隱私。FastCGI應用程序只能接受信任的Web服務器鏈接(應用程序庫包括了IP地址驗證)。該協議的將來版本將支持包括web服務器驗證，以及遠程運行在如安全傳輸協議層的上支持，例如：SSL或PCT。

The FastCGI Protocol FastCGI協議

This section offers a brief introduction to the protocol used on the connection between the Web server and FastCGI application. Most application developers will use the FastCGI application library and won't have to worry about the protocol details. However, specialized applications are free to implement the FastCGI protocol directly.

本部份提供了一種在web服務器和FastCGI應用程序之間鏈接協議的簡要介紹，大多數應用程序開發員將使用FastCGI應用程序庫而沒必要擔憂協議的詳細細節。然而，專門的應用程序可直接經過FaastCGI協議自由實施。

FastCGI uses a simple packet record format on the connection between the application and the Web server. The same record format is used in both directions and is outlined in Figure 2.

FastCGI使用簡單的包格式在web服務器和應用程序之間進行鏈接。一樣的記錄格式在兩個方向上使用。（圖1及圖2官方網站打不開）

The protocol version field specifies the version of the FastCGI protocol that is in use. The type field specifies the type of the record (described in the following section). The request ID identifies this record to a particular request, allowing multiple requests to be multiplexed over a single connection. The data length field specifies the number of data bytes that follow.

協議版本字段指定FastCGI協議正在使用的版本。類型字段指定了記錄的類型（描述在下面部分）,請求ID標識這個記錄是一個特別的請求，容許在一個單獨鏈接上多路複用請求。數據長度字段在其後面指定數據字節長度號碼

The different FastCGI packet types are:

 不一樣的FastCGI包類型有：

 

FCGI_PARAMS	Used for sending name/value pairs (CGI environment variables) from the Web server to the application. 用來從web服務器發送名字/值對到應用程序（CGI環境變量）
FCGI_STDIN	Used for sending the standard input from the Web server to the application. 用於從web服務器發送標準輸入到應用程序
FCGI_DATA	Used for sending filter data to the application (for more information, see the filter role described on page 7.) 用來發送過濾數據到應用程序
FCGI_STDOUT	Used to send standard output from the application to the Web server. 用來發送從應用程序到web服務器的標準輸出
FCGI_STDERR	Used to send standard error information from the application to the Web server. 用來發送從應用程序到web服務器的標準錯誤。
FCGI_END_REQUEST	Ends the request (can be sent by either the server or the application). 結束請求

 

 

For complete protocol details, see the FastCGI Protocol Specification, available from the Web site listed at the end of this paper.

有關完整的協議細節，請參見FastCGI協議規範，或從本網站末尾列出的文章得到幫助。

Responder Role 響應做用

FastCGI's Responder role is identical to the functionality provided by CGI today. When a request comes into the server, the FastCGI program generates the response that's returned to the client (typically an HTML page).

FastCGI的響應者做用同今天CGI提供的功能相同，當有請求進入服務器，FastCGI應用程序生成響應並返回給客戶端（一般是一個HTML頁）

Filter Role 過濾器做用

The Filter role allows a FastCGI application to process a requested file before it is returned to the client.

過濾器的做用容許FastCGI應用程序在處理請求文件以前返回給客戶端。

Let's assume that the Web server is configured so that all files with the .sgml extension are processed by a SGML-to-HTML FastCGI filter application, and the user accesses the following URL:

咱們假設web服務器被配置成全部文件爲.sgml的擴展名，以便使用FastCGI過濾應用程序SGML到HTML來處理。而且用戶使用下面的URL訪問。

/document.sgml

After the Web server makes an access control decision and maps this URL to a content file, it invokes the FastCGI filter application with this file available as input. The FastCGI program's HTML output is sent back to the client, just as in the responder role. The process is outlined in Figure 3.  

而後WEB服務器爲這個URL使用訪問控制決策和地圖到一個內容文件，FastCGI過濾應用程序調用這個可用的文件做爲輸入，這個FastCGI程序以HTML輸出發送給客戶端，正如應答者角色同樣。這個處理概述在圖3中（圖3沒有）

Filter applications can significantly improve performance by caching filter results (the server provides the modification time in the request information so that applications can flush the cache when the server file has been modified).

過濾應用程序能大幅提升緩存過濾的成果(服務器在請求中提供修改時間，當服務器文件被修改使應用程序能夠修改服務器緩存內容).

 

The Filter role is useful for:

過濾器的做用爲：

• On-the-fly format conversions 快速的格式轉換
• Dynamic documents (such as documents with embedded SQL queries, or dynamic advertisement insertion) 動態文檔內容（例如與文檔一塊兒嵌入SQL查詢，或動態插入廣告）
• Applying a standard template: headers, footers, and backgrounds 應用標準模版：頁眉，頁腳和背景

 

Authorizer Role 受權者角色

The Authorizer role allows a FastCGI application to make an access control decision for a request. The FastCGI application is invoked with all of the request information, just as in the Responder role. If the authorizer application generates a "200 OK" HTTP result, the Web server assumes that access is allowed and proceeds with the request. (The Web server may process other access checks, including other FastCGI authorizers, before access is ultimately allowed.) If the application generates any other response, that response is returned to the client and the request is ended. The response can be any valid HTTP response, including "Access Denied" or "Redirect". 

受權者角色容許爲FastCGi應用程序爲制定請求訪問控制。FastCGI應用程序的調用和全部請求信息，有點像響應者角色。若是受權器應用程序生成"200 OK"的HTTP結果。WEB服務器容許請求繼續訪問。(WEB服務器能夠處理其它訪問檢查，包括其它FastCGI認證，最終容許訪問)。若是應用程序生成其它響應，那麼響應會返回給客戶端而且請求結束。響應也能夠是任何有效的HTTP響應，包括"Access Denied"或"Redeirect".

The Authorizer role is useful for:受權者角色的好處爲:

• Access control based on username and password, where the user information is looked up in an external database.基於用戶名和密碼的訪問控制，用戶信息放在外部數據庫進行查詢.
• Complex access policies, such as time-of-day based access.複雜的訪問規則，例如:基於時刻的訪問控制)
• Smart-card challenge/response authentication.響應認證/智能卡挑戰
• Dynamic redirects, where the user is sent to different pages based on the request profile.動態重定向，基於請求屬性向用戶發送不一樣的頁面。

 

4. FastCGI Application Library. FastCGI應用程序庫

Open Market has developed a FastCGI application library that implements the FastCGI protocol (hiding the protocol details from the developer). This library makes implementing FastCGI programs as easy as writing CGI applications. 

Open Market 已經開發了一個FastCGI應用程序庫來實現FastCGi協議(爲開發者隱藏協議細節).這個庫具備編寫CGI應用程序同樣開發FastCGi程序.

The application library provides a replacement for the C language standard I/O (stdio) routines, such as printf() and gets(). The library converts references to standard input, standard output, and standard error to the FastCGI protocol. References to other files "fall through" to the underlying operating system standard I/O routines. 

    應用程序庫提供了替換C語言標準I/O(stdin)的子例程，例如printf()和gets(),這個庫會轉換引用標準輸入，標準輸出，和標準錯誤到FastCGI協議.引用操做系統底層I/O子例程其它文件會「失效"

This approach has several benefits: 

這種方法有幾個好處：

• Developers don't have to learn a new API to develop FastCGI applications.開發者無須再學習新的API開發FastCGI應用程序。
• Existing CGI programs can be migrated with minimal source changes (CGI migration is described in more detail in the following section).已存在的CGI程序很小改變能夠移植(CGI移植描述的更多細節在下面的部分中)
• FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the interpreter source code.FastCGI解析程序爲perl,TCL和其它解析語言不用修改解析器源代碼來構建應用程序

 

Here's a simple FastCGI application:這裏是一個簡單的FastCGI應用程序：

#include  <fcgi_stdio.h>

void main(void)

{int count = 0;

 while(FCGI_Accept() >= 0) 

{

        printf("Content-type: text/html ");

            printf(" ");

        printf("Hello world!");

       printf("Request number %d.", count++);

}

      exit(0);

}

This application returns a "Hello world" HTML response to the client. It also keeps a counter of the number of times it has been accessed, displaying the value of the counter at each request. 

這個應用程序將向客戶端 返回"Hello World" HTML應答。它保存一個每次訪問的計數器計數器，用於顯示每次請求的次數的值。

The fcgi_stdio.h header file provides the FastCGI replacement routines for the C standard I/O library. The FCGI_Accept() routine accepts a new request from the Web server. 

fcgi_stdio.h頭文件提供FastCGi替換標準C I/O庫的子例程。 FCGI_Accept（）子例程從web服務器接受一個新的請求。

Migrating Existing CGI Programs 移植已存在的CGI程序.

The application library was designed to make migration of existing CGI programs as simple as possible. Many applications can be converted by adding a loop around the main request processing code and recompiling with the FastCGI application library. FastCGI applications have the following structure, with an initialization section and a request processing loop: 

應用程序庫被設計成將已存在的CGI程序移植儘量的簡單，大多數應用程序能夠被轉換爲主要的請求在一個循環中處理並與FastCGI庫從新編譯.FastCGI應用程序有下列結構，初始化部分與循環請求處理部份:

 

Initialize application;

初始化應用程序

while(FCGI_Accept() >= 0) {

Process request;請求處理

}

To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the execution environment and automatically selects FastCGI or regular I/O routines, as appropriate. 

更容易移植到FastCGI.可執行文件構建的應用程序庫能運行CGI或者FastCGI程序.取決於怎麼調用他們。程序庫檢查執行環境而且適時自動選擇FastCGI或是標準I/O例程庫.

After migration, developers can clean up their FastCGI applications for best performance:

移植後，開發人員能夠清理他們的FastCGI應用程序以得到最好的性能：

• Fix any resource leaks. Many CGI programs do not attempt to manage memory or close files, because they assume the world is going to be cleaned up when they exit. (If you don't want to clean up your program, you can just have your process assume that it is leaking memory and exit after processing some fixed number of requests.) Purify from Pure Software is one of a number of excellent tools for finding leaks and other memory use problems.修復全部的源代碼漏洞，大多數CGI程序不嘗試管理內存和關閉文件，由於它們假定當他們退出後世界已經被清理。某些優秀的工具能找出內存溢出和其它內存使用問題。
• Fix any problems with retained application state. The application must ensure that any state that it creates in processing one request has no unintended effects on later requests.保留應用程序狀態修復全部問題。應用程序必須確保處理一個請求任何狀態不能有意地影響之後請求.
• Collapse functionality. A common practice with CGI applications is to implement many small programs, with one function per program. CGI encourages this, because smaller programs load faster. With FastCGI, it's better to have related functionality in a single executable, so there are fewer processes to manage and applications can take advantage of sharing cached information across functions.崩潰功能。一般的做法是CGI應用程序由多數小型程序構成，每一個程序一個功能。CGI鼓勵這樣作，由於小型程序載入更快，因爲FastCGI在一個單獨可執行的環境中提供更好的相關功能。所以有較少的管理處理而且應用程序能夠並行利用共享緩存信息.

 

Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix platforms are available from Open Market. The interpreters are backward-compatible: They can run standard Tcl and Perl applications.  

在perl,TCL或其它腳本語言中編寫的應用程序能使用語言解析器構建能遷移的應用程序庫。Open Market 爲多數流行的Unix平臺在FastCGI集成了可用的Tcl和perl解析器.解析器是向後兼容的。它們能運行標準的Tcl和perl應用程序。

5. FastCGI in the Open Market WebServer Open Market web服務器中的FastCGI

This section describes the FastCGI support in the following Open Market server products:

本節描述了Open Market服務器產品對FastCGI的支持以下：

• Open Market WebServer V2.0
• Open Market Secure WebServer V2.0
• Open Market Secure WebServer (Global) V2.0

 

For more information about FastCGI support, see the Open Market WebServer Installation and Configuration Guide.

如要得到關於FastCGI支持的更多信息，請參見Open Market Web服務器安裝和配置指南。

Server Configuration 服務器配置

FastCGI applications are configured with the server's configuration file. Configuration has two parts.

FastCGI應用程序經過服務器配置文件配置的.配置有兩個部分。

First, the server administrator defines an application class. For local applications, the application class specifies the details of running the FastCGI application, such as:

首先，服務器管理員定義一個應用程序類。對於本地的應用程序，應用程序類指定了運行FastCGI應用程序的細節，例如：

• The pathname of the application executable.可執的應用程序路徑名。
• Any arguments and environment variables to pass to the process at startup. 在啓動時傳遞給進程的參數和環境變量
• The number of processes to run.運行進程的號碼

 

For remote applications, the class configuration information includes the host and TCP port to connect to. The Web server assumes that the FastCGI application has been started on the remote host. If a request comes in and the server can't connect to the FastCGI TCP port, the server logs an error and returns an error page to the client.

對於遠程應用程序，類配置信息包括鏈接的主機和TCP端口，web服務器假定FastCGI應用程序已在遠程主機上啓動。若是一個請求到來而且服務不能鏈接到FastCGI TCP端口，服務器記錄錯誤並返回一個錯誤頁面給客戶端。

The second configuration step is mapping the application class to a role:

第二個配置步驟是應用程序映像到一個角色：

• For responder roles, the administrator configures some part of the URL space to be handled by the FastCGI application. For example, all URLs beginning with /rollcall/ might be handled by the employee database application. 響應者角色，管理員配置URL空間的某部分由FastCGI應用程序處理。例如，全部URL以 /rollcall/開始的能夠被職員數據庫應用程序處理。
• For filter roles, the administrator configures a file extension to be handled by a filter application. For example, all files with the .sql extension could be handled by a SQL query lookup filter. 過濾器角色,管理員配置過濾應用程序處理文件擴展名。例如.全部文件爲.sql的擴展名能被SQL查詢過濾器處理.
• For authorizer roles, the administrator configures an authorizer application in the same manner as other access methods (hostname, username/password, etc.) A request must pass all access control checks (possibly including multiple FastCGI authorizers) before access is allowed. 受權者角色。管理員配置一個受權者應用程序同其它訪問是同樣的.(主機名，用戶名，密碼等等）.請求以前必須傳遞全部的訪問控制檢查，該訪問才被容許(可能包括多個受權者)

 

Basic FastCGI FastCGI基本配置

To simplify migration for existing CGI programs, the WebServer provides a simple way to install new FastCGI programs without having to reconfigure the server. However, this approach doesn't offer all of the performance benefits of FastCGI application classes. 爲了簡化已存在的CGI程序遷移，web服務器提供一種簡單方法來安裝新的FastCGI應用程序而不用從新配置服務器。然而，這種方式不提供FastCGI應用程序類的全部性能優點。

The WebServer treats any file with the extension .fcg as a FastCGI application. When a request corresponds to such a file, the WebServer creates a new FastCGI process to handle the request, and shuts down the process when the request is complete (just as in CGI). In this mode of operation performance is comparable to CGI. Future versions of the WebServer will improve performance by automatically caching processes and re-using them for subsequent requests.

web服務器把文件擴展名爲.fcg做爲FastCGI應用程序處理。當一個請求對應於這樣一個文件，web服務器建立一個新的FastCGI進程處理請求，當請求完成後就關閉進程(如同CGI同樣).這種模式的操做性能與CGI至關。將來版本的web服務器將改善自動緩存進程和爲再次請求從新使用它們以提升性能。

Session Affinity 會話的密切關係

FastCGI programs can improve performance by caching information in the application process. For applications that require frequent but expensive operations such as validating a username/password in an external database for each request, this technique can significantly improve performance.

FastCGI程序能在應用程序中處理緩存信息以改善性能。爲了應用程序頻繁須要,可是這種操做很費時間，例如爲每一個請求在外部數據確認用戶名/密碼，這種技術能大大改善性能

To improve the effectiveness of this technique, the WebServer implements session affinity. When session affinity is enabled, the WebServer arranges for all requests in a user session to be handled by the same FastCGI application process. What constitutes a "session" is configurable. The default configuration uses the WebServer's built-in session tracking facility to identify user sessions. However, the server administrator can use any part of the request information for the session affinity mapping: the URL path, the client's hostname, the username, etc. <!--Talk about applications that need to hold onto resources for the user (such as open connections to the database).-->

爲改進這種技術有效性。web服務器實現了會話的密切關係.當會話的密切關係是啓用的.web服務器爲全部的請求安排同一個FastCGI應用程序處理用戶會話.一個"session「配置由什麼構成,默認配置使用web服務器內置會話追蹤設備設備用戶會話。然而,服務器管理員也能爲會話的密切關係映射任何的請求部分信息：URL路徑，客戶端的主機名，用戶名等.

6. FastCGI Performance Analysis FastCGI性能分析

How fast is FastCGI? The answer depends on the application. This section contains some real FastCGI performance measurements, as well as guidelines for estimating the FastCGI speedup.

FastCGI有多快？答案依賴於應用程序，本節包含了一些真實的FastCGI性能測試。即爲指導又爲FastCGI加速做估算.

FastCGI vs CGI

We measured the relative performance of CGI, FastCGI, and static files on the Open Market WebServer, using a simple application that generates a fixed number of output bytes. The following table shows the measured request processing time for different request types on a typical platform. The times are measured from the client perspective and include client, server, and application processing time.

咱們測算CGI,FastCGI的相關性能，並在靜態文件的Open Market web服務器上使用一個簡單的應用程序生成固定的輸出字節數,下表顯示了在一個典型平臺上爲不一樣類型的請求測算請求處理時間。時間從客戶端角度測算而且包括客戶端，服務器端，以及應用程序處理時間.

 

 

Static file	21ms + 0.19ms per Kbyte
FastCGI	22ms + 0.28ms per Kbyte
CGI	59ms + 0.37ms per Kbyte

 

FastCGI performance is comparable to serving static files, and significantly better than CGI (clearly showing the high overhead for process creation). Real applications have an additional time component: process initialization, which should be added to overall request processing time.

FastCGI性能與服務的靜態文件至關.顯著的比CGI好(清楚地顯示爲建立進程的高開銷).實際應用有一些額外的時間成份：進程初始化，都應該增請求處理時間。

Let's use this data to estimate the speedup from migrating a typical database CGI application to FastCGI. Assume the application takes 50ms to initialize the database connection and generates 5K of output data. Request performance can be computed as follows:

讓咱們遷移一個類型的數據庫CGI程序到FastCGI程序來估算這個數據的加速比。假設應用程序要50ms初始化數據庫鏈接及生成5K的輸出數據。請求性能計算以下：

 

CGI	59ms + 50ms + (0.37ms)=111ms
FastCGI	22ms + (0.28ms)(5) = 23ms

 

In this example, FastCGI has a 5x performance advantage over CGI, mostly due to savings from not having to create and initialize new processes for each request.<!--Need to talk about FastCGI vs proprietary APIs.-->

在這個例子中，FastCGI超過CGI5倍的性能優點。主要歸因於節省了爲每一個請求建立和初始化進程.

7. Conclusions 結論

Today's Web business applications need a platform that's fast, open, maintainable, straightforward, stable, and secure. FastCGI's design meets these requirements, and provides for a logical extension from proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's benefits without losing their existing investment in CGI applications.<!--Need to talk about NT.--> <!--Need to give "more punch" to this conclusion: include info about uses for FastCGI (accessing legacy data in databases, access control, distributed applications, apps that have to run in multiple OS environments. -->

今天的商業web應用程序須要一個快速，快速廣，可維護，簡單，穩定，安全的平臺。FastCGI的設計知足這些要求，而且爲本地擴展提供了普遍部屬CGI的技術.這樣容許開發人員不失去現有的CGI應用程序投資利用FastCGI的好處.

8. For More Information

For more information about Open Market and our products, visit our Web site at:http://www.openmarket.com/

For more information about the FastCGI protocol and the developer's kit, and the latest information about FastCGI standardization and support in other Web servers, visit the FastCGI project page at: http://www.fastcgi.com

This file is Copyright © 1996 Open Market, Inc.

 

from:http://fuzhong1983.blog.163.com/blog/static/1684705201002052599/