[轉載]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/

轉載于:https://www.cnblogs.com/junhwong/p/3487557.html