Commit | Line | Data |
852467e2 |
1 | <HTML> |
2 | <HEAD> |
3 | <TITLE> |
4 | FastCGI |
5 | </TITLE> |
6 | <META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.0z"> |
7 | <STYLE TYPE="text/css"> |
8 | div.c5 {font-family: Arial Narrow; font-size: 80%; text-align: center} |
9 | span.c4 {font-family: Courier} |
10 | tt.c3 {font-family: Courier} |
11 | div.c2 {text-align: center} |
12 | div.c1 {color: #FFFFFF; font-family: Impact; font-size: 120%; text-align: center} |
13 | </STYLE> |
14 | </HEAD> |
15 | <!--Copyright (c) 1996 Open Market, Inc. --> |
af1b4cad |
16 | <!--See the file "LICENSE" for information on usage and redistribution--> |
852467e2 |
17 | <!--of this file, and for a DISCLAIMER OF ALL WARRANTIES. --> |
18 | <!-- $Id: fastcgi.htm,v 1.4 2002/02/25 00:45:06 robs Exp $ --> |
19 | <BODY> |
20 | <P> |
21 | Open Market, Inc. |
22 | </P> |
23 | <P> |
24 | </P> |
25 | <DIV CLASS="c1"> |
26 | Technical White Paper<BR> |
27 | </DIV> |
28 | <H1> |
29 | FastCGI:<BR> |
30 | A High-Performance Web Server Interface |
31 | </H1> |
32 | <P> |
33 | April 1996<!--Please send comments to:--> |
34 | </P> |
35 | <HR> |
36 | <!-- payne@openmarket.com--> |
37 | <H2> |
38 | 1. Introduction |
39 | </H2> |
40 | <P> |
41 | The surge in the use of the Web by business has created a tremendous need for server extension applications |
42 | that create dynamic content. These are the applications that will allow businesses to deliver products, |
43 | services, and messages whose shape and content are in part determined by the interaction with, and knowledge |
44 | of, the customers to which they are delivered. |
45 | </P> |
46 | <P> |
47 | This important movement away from static Web content is pushing the limits and exposing the weaknesses of the |
48 | environment in which these applications are currently bound: CGI (Common Gateway Interface). Most importantly |
49 | it does not offer the performance these applications require. A new communication infrastructure is needed to |
50 | connect Web servers with these new applications. This is what led Open Market to develop FastCGI. |
51 | </P> |
52 | <P> |
53 | FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI, |
54 | without introducing the overhead and complexity of proprietary APIs (Application Programming Interfaces). |
55 | </P> |
56 | <P> |
57 | This paper assumes that the reader has basic familiarity with Web technology and developing Web applications. |
58 | </P> |
59 | <H3> |
60 | Common Gateway Interface |
61 | </H3> |
62 | <P> |
63 | The de facto standard interface for Web server applications is CGI, which was first implemented in the NCSA |
64 | server. CGI has many benefits: |
65 | </P> |
66 | <UL> |
67 | <LI> |
68 | <B>Simplicity.</B> <SPAN>It is easy to understand.</SPAN> |
69 | </LI> |
70 | <LI> |
71 | <B>Language independence.</B> CGI applications can be written in nearly any language. |
72 | </LI> |
73 | <LI> |
74 | <B>Process isolation.</B> Since applications run in separate processes, buggy applications cannot crash the |
75 | Web server or access the server's private internal state. |
76 | </LI> |
77 | <LI> |
78 | <B>Open standard.</B> Some form of CGI has been implemented on every Web server. |
79 | </LI> |
80 | <LI> |
81 | <B>Architecture independence.</B> CGI is not tied to any particular server architecture (single threaded, |
82 | multi-threaded, etc.). |
83 | </LI> |
84 | </UL> |
85 | <P> |
86 | CGI also has some significant drawbacks. The leading problem is performance: Since a new process is created |
87 | for each request and thrown away when the request is done, efficiency is poor. |
88 | </P> |
89 | <P> |
90 | CGI also has limited functionality: It only supports a simple "responder" role, where the |
91 | application generates the response that is returned to the client. CGI programs can't link into other |
92 | stages of Web server request processing, such as authorization and logging. |
93 | </P> |
94 | <H3> |
95 | Server APIs |
96 | </H3> |
97 | <P> |
98 | In response to the performance problems for CGI, several vendors have developed APIs for their servers. The |
99 | two most notable are NSAPI from Netscape and ISAPI from Microsoft. The freely available Apache server also has |
100 | an API. |
101 | </P> |
102 | <P> |
103 | Applications linked into the server API may be significantly faster than CGI programs. The CGI |
104 | startup/initialization problem is improved, because the application runs in the server process and is |
105 | persistent across requests. Web server APIs also offer more functionality than CGI: you can write extensions |
106 | that perform access control, get access to the server's log file, and link in to other stages in the |
107 | server's request processing. |
108 | </P> |
109 | <P> |
110 | However, APIs sacrifice all of CGI's benefits. Vendor APIs have the following problems: |
111 | </P> |
112 | <UL> |
113 | <LI> |
114 | <B>Complexity.</B> Vendor APIs introduce a steep learning curve, with increased implementation and |
115 | maintenance costs. |
116 | </LI> |
117 | <LI> |
118 | <B>Language dependence.</B> Applications have to be written in a language supported by the vendor API |
119 | (usually C/C++). Perl, the most popular language for CGI programs, can't be used with any existing |
120 | vendor API. |
121 | </LI> |
122 | <LI> |
123 | <B>No process isolation.</B> <SPAN>Since the applications run in the server's address space, buggy |
124 | applications can corrupt the core server (or each other). A malicious or buggy application can compromise |
125 | server security, and bugs in the core server can corrupt applications.</SPAN> |
126 | </LI> |
127 | <LI> |
128 | <B>Proprietary.</B> Coding your application to a particular API locks you into a particular vendor's |
129 | server. |
130 | </LI> |
131 | <LI> |
132 | <B>Tie-in to server architecture.</B> API applications have to share the same architecture as the server: |
133 | If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has |
134 | single-threaded processes, multi-threaded applications don't gain any performance advantage. Also, when |
135 | the vendor changes the server's architecture, the API will usually have to change, and applications |
136 | will have to be adapted or rewritten. |
137 | </LI> |
138 | </UL> |
139 | <H3> |
140 | FastCGI |
141 | </H3> |
142 | <P> |
143 | The FastCGI interface combines the best aspects of CGI and vendor APIs. Like CGI, FastCGI applications run in |
144 | separate, isolated processes. FastCGI's advantages include: |
145 | </P> |
146 | <UL> |
147 | <LI> |
148 | <B>Performance.</B> FastCGI processes are persistent-they are reused to handle multiple requests. This |
149 | solves the CGI performance problem of creating new processes for each request. |
150 | </LI> |
151 | <LI> |
152 | <B>Simplicity, with easy migration from CGI.</B> The FastCGI application library (described on page 9) |
153 | simplifies the migration of existing CGI applications. Applications built with the application library can |
154 | also run as CGI programs, for backward compatibility with old Web servers. |
155 | </LI> |
156 | <LI> |
157 | <B>Language independence.</B> Like CGI, FastCGI applications can be written in any language, not just |
158 | languages supported by the vendor API. |
159 | </LI> |
160 | <LI> |
161 | <B>Process isolation.</B> A buggy FastCGI application cannot crash or corrupt the core server or other |
162 | applications. A malicious FastCGI application cannot steal any secrets (such as session keys for |
163 | encryption) from the Web server. |
164 | </LI> |
165 | <LI> |
166 | <B>Non-proprietary.</B> FastCGI is supported in all of Open Market's server products, and support is |
167 | under development for other Web servers, including the freely available Apache and NCSA servers, as well as |
168 | commercial servers from Microsoft and Netscape. |
169 | </LI> |
170 | <LI> |
171 | <B>Architecture independence.</B> The FastCGI interface is not tied to a particular server architecture. |
172 | Any Web server can implement the FastCGI interface. Also, FastCGI does not impose any architecture on the |
173 | application: applications can be single or multi-threaded, regardless of the threading architecture of the |
174 | Web server. |
175 | </LI> |
176 | <LI> |
177 | <B>Support for distributed computing.</B> FastCGI provides the ability to run applications remotely, which |
178 | is useful for distributing load and managing external Web sites. |
179 | </LI> |
180 | </UL> |
181 | <P> |
182 | The following sections describe the FastCGI interface, protocol, application library, and support in Open |
183 | Market's WebServer products. |
184 | </P> |
185 | <H2> |
186 | 2. FastCGI Interface |
187 | </H2> |
188 | <P> |
189 | The functionality provided by the FastCGI interface is very similar to that provided by CGI. To best |
190 | understand the FastCGI protocol, we review the CGI interface here. Basic CGI request processing proceeds as |
191 | follows: |
192 | </P> |
193 | <OL> |
194 | <LI> |
195 | For each request, the server creates a new process and the process initializes itself. |
196 | </LI> |
197 | <LI> |
198 | The Web server passes the request information (such as remote host, username, HTTP headers, etc.) to the |
199 | CGI program in environment variables. |
200 | </LI> |
201 | <LI> |
202 | The Web server sends any client input (such as user-entered field values from an HTML form) to the CGI |
203 | program's standard input. |
204 | </LI> |
205 | <LI> |
206 | The CGI program writes any output to be returned to the client on standard output. Error information |
207 | written to standard error is logged by the Web server. |
208 | </LI> |
209 | <LI> |
210 | When the CGI process exits, the request is complete. |
211 | </LI> |
212 | </OL> |
213 | <P> |
214 | FastCGI is conceptually very similar to CGI, with two major differences: |
215 | </P> |
216 | <UL> |
217 | <LI> |
218 | FastCGI processes are persistent: after finishing a request, they wait for a new request instead of |
219 | exiting. |
220 | </LI> |
221 | <LI> |
222 | Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the |
223 | environment information, standard input, output and error over a single full-duplex connection. This allows |
224 | FastCGI programs to run on remote machines, using TCP connections between the Web server and the FastCGI |
225 | application. |
226 | </LI> |
227 | </UL> |
228 | <P> |
229 | Request processing in a single-threaded FastCGI application proceeds as follows: |
230 | </P> |
231 | <OL> |
232 | <LI> |
233 | The Web server creates FastCGI application processes to handle requests. The processes may be created at |
234 | startup, or created on demand. |
235 | </LI> |
236 | <LI> |
237 | The FastCGI program initializes itself, and waits for a new connection from the Web server. |
238 | </LI> |
239 | <LI> |
240 | When a client request comes in, the Web server opens a connection to the FastCGI process. The server sends |
241 | the CGI environment variable information and standard input over the connection. |
242 | </LI> |
243 | <LI> |
244 | The FastCGI process sends the standard output and error information back to the server over the same |
245 | connection. |
246 | </LI> |
247 | <LI> |
248 | When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for |
249 | another connection from the Web server. |
250 | </LI> |
251 | </OL> |
252 | <P> |
253 | FastCGI applications can run locally (on the same machine as the Web server) or remotely. For local |
254 | applications, the server uses a full-duplex pipe to connect to the FastCGI application process. For remote |
255 | applications, the server uses a TCP connection. |
256 | </P> |
257 | <P> |
258 | FastCGI applications can be single-threaded or multi-threaded. For single threaded applications, the Web |
259 | server maintains a pool of processes (if the application is running locally) to handle client requests. The |
260 | size of the pool is user configurable. Multi-threaded FastCGI applications may accept multiple connections |
261 | from the Web server and handle them simultaneously in a single process. (For example, Java's built-in |
262 | multi-threading, garbage collection, synchronization primitives, and platform independence make it a natural |
263 | implementation language for multi-threaded FastCGI applications.) |
264 | </P> |
265 | <H3> |
266 | Remote FastCGI |
267 | </H3> |
268 | <P> |
269 | FastCGI's ability to run applications remotely (over a TCP connection) provides some major benefits. These |
270 | benefits are described in this section, along with some of the security issues that affect remote FastCGI |
271 | applications. |
272 | </P> |
273 | <H4> |
274 | FastCGI with Firewalls |
275 | </H4> |
276 | <P> |
277 | Applications that run on organizational (external) Web servers and depend on internal databases can be a |
278 | challenge to administer. Figure 1 shows a typical organization, with an external Web server, a firewall |
279 | restricting access to the internal network, and internal databases and applications. |
280 | </P> |
281 | <P> |
282 | </P> |
283 | <DIV CLASS="c2"> |
284 | <IMG ALT="error-file:TidyOut.log" SRC="img00001.gif"><A NAME="_Ref352505891">Figure 1</A> |
285 | </DIV> |
286 | <P> |
287 | With CGI and vendor APIs, the application has to run on the Web server machine. This means the server |
288 | administrator has to replicate the necessary database information onto the system hosting the Web server |
289 | (which may be difficult to do in an automated way without compromising firewall security). Or, the |
290 | administrator may build a "bridge" that allows access through the Web server to internal databases |
291 | and applications (which is effectively re-inventing remote FastCGI). |
292 | </P> |
293 | <P> |
294 | With remote FastCGI, the applications can run on the internal network, simplifying the administrator's |
295 | job. When used with appropriate firewall configuration and auditing, this approach provides a secure, |
296 | high-performance, scalable way to bring internal applications and data to the external network. |
297 | </P> |
298 | <H4> |
299 | Load Distribution |
300 | </H4> |
301 | <P> |
302 | For resource-intensive CGI and API applications, the Web server machine quickly becomes the bottleneck for |
303 | overall throughput. The usual way to solve this performance problem is to buy a bigger, faster Web server |
304 | machine, or to partition the Web site across several Web servers. |
305 | </P> |
306 | <P> |
307 | With remote FastCGI, the resource-intensive applications can be moved off the Web server machine, giving the |
308 | server administrator additional flexibility in configuring the Web server. The administrator can configure |
309 | FastCGI applications "behind the scenes" without having to change any content links or the external |
310 | view of the Web site. The administrator can use several smaller, inexpensive server machines for applications, |
311 | and can tailor each machine to the application it is hosting. |
312 | </P> |
313 | <H4> |
314 | Security Issues with Remote FastCGI |
315 | </H4> |
316 | <P> |
317 | The two security issues with remote FastCGI connections are authentication and privacy. FastCGI applications |
318 | should only accept connections from Web servers that they trust (the application library includes support for |
319 | IP address validation). Future versions of the protocol will include support for applications authenticating |
320 | Web servers, as well as support for running remote connections over secure transport protocols such as SSL or |
321 | PCT.<!--This pargraph needs to be made stronger, going into the issues in a little more detail.--> |
322 | </P> |
323 | <H3> |
324 | The FastCGI Protocol |
325 | </H3> |
326 | <P> |
327 | This section offers a brief introduction to the protocol used on the connection between the Web server and |
328 | FastCGI application. Most application developers will use the FastCGI application library and won't have |
329 | to worry about the protocol details. However, specialized applications are free to implement the FastCGI |
330 | protocol directly. |
331 | </P> |
332 | <P> |
333 | FastCGI uses a simple packet record format on the connection between the application and the Web server. The |
334 | same record format is used in both directions and is outlined in Figure 2. |
335 | </P> |
336 | <P> |
337 | </P> |
338 | <DIV CLASS="c2"> |
339 | <IMG ALT="error-file:TidyOut.log" SRC="img00002.gif"><A NAME="_Ref352404075">Figure 2</A> |
340 | </DIV> |
341 | <P> |
342 | The protocol version field specifies the version of the FastCGI protocol that is in use. The type field |
343 | specifies the type of the record (described in the following section). The request ID identifies this record |
344 | to a particular request, allowing multiple requests to be multiplexed over a single connection. The data |
345 | length field specifies the number of data bytes that follow. |
346 | </P> |
347 | <P> |
348 | The different FastCGI packet types are: |
349 | </P> |
350 | <TABLE> |
351 | <TR> |
352 | <TD WIDTH="186"> |
353 | <TT CLASS="c3">FCGI_PARAMS</TT> |
354 | </TD> |
355 | <TD WIDTH="228"> |
356 | Used for sending name/value pairs (CGI environment variables) from the Web server to the application. |
357 | </TD> |
358 | </TR> |
359 | <TR> |
360 | <TD WIDTH="186"> |
361 | <TT CLASS="c3">FCGI_STDIN</TT> |
362 | </TD> |
363 | <TD WIDTH="228"> |
364 | Used for sending the standard input from the Web server to the application. |
365 | </TD> |
366 | </TR> |
367 | <TR> |
368 | <TD WIDTH="186"> |
369 | <TT CLASS="c3">FCGI_DATA</TT> |
370 | </TD> |
371 | <TD WIDTH="228"> |
372 | Used for sending filter data to the application (for more information, see the filter role described on |
373 | page 7.) |
374 | </TD> |
375 | </TR> |
376 | <TR> |
377 | <TD WIDTH="186"> |
378 | <TT CLASS="c3">FCGI_STDOUT</TT> |
379 | </TD> |
380 | <TD WIDTH="228"> |
381 | Used to send standard output from the application to the Web server. |
382 | </TD> |
383 | </TR> |
384 | <TR> |
385 | <TD WIDTH="186"> |
386 | <TT CLASS="c3">FCGI_STDERR</TT> |
387 | </TD> |
388 | <TD WIDTH="228"> |
389 | Used to send standard error information from the application to the Web server. |
390 | </TD> |
391 | </TR> |
392 | <TR> |
393 | <TD WIDTH="186"> |
394 | <TT CLASS="c3">FCGI_END_REQUEST</TT> |
395 | </TD> |
396 | <TD WIDTH="228"> |
397 | Ends the request (can be sent by either the server or the application). |
398 | </TD> |
399 | </TR> |
400 | </TABLE> |
401 | <P> |
402 | </P> |
403 | <P> |
404 | For complete protocol details, see the <I>FastCGI Protocol Specification</I>, available from the Web site |
405 | listed at the end of this paper. |
406 | </P> |
407 | <H2> |
408 | 3. Application Roles |
409 | </H2> |
410 | <P> |
411 | A major problem with CGI is its limited functionality: CGI programs can only provide simple responses to |
412 | requests. FastCGI provides expanded functionality with support for three different application |
413 | "roles": |
414 | </P> |
415 | <UL> |
416 | <LI> |
417 | <B>Responder.</B> This is the basic FastCGI role, and corresponds to the simple functionality offered by |
418 | CGI today. |
419 | </LI> |
420 | <LI> |
421 | <B>Filter.</B> The FastCGI application filters the requested Web server file before sending it to the |
422 | client. |
423 | </LI> |
424 | <LI> |
425 | <B>Authorizer.</B> The FastCGI program performs an access control decision for the request (such as |
426 | performing a username/password database lookup). |
427 | </LI> |
428 | </UL> |
429 | <P> |
430 | Other roles will be defined in the future. For instance, a "logger" role would be useful, where the |
431 | FastCGI program would receive the server's log entries for real-time processing and analysis. |
432 | </P> |
433 | <P> |
434 | The roles are described in more detail in the following sections. |
435 | </P> |
436 | <H3> |
437 | Responder Role |
438 | </H3> |
439 | <P> |
440 | FastCGI's Responder role is identical to the functionality provided by CGI today. When a request comes |
441 | into the server, the FastCGI program generates the response that's returned to the client (typically an |
442 | HTML page). |
443 | </P> |
444 | <H3> |
445 | <A NAME="_Ref352404524">Filter Role</A> |
446 | </H3> |
447 | <P> |
448 | The Filter role allows a FastCGI application to process a requested file before it is returned to the client. |
449 | </P> |
450 | <P> |
451 | Let's assume that the Web server is configured so that all files with the .<TT CLASS="c3">sgml</TT> |
452 | extension are processed by a SGML-to-HTML FastCGI filter application, and the user accesses the following URL: |
453 | </P> |
454 | <P> |
455 | <TT CLASS="c3">/document.sgml</TT> |
456 | </P> |
457 | <P> |
458 | After the Web server makes an access control decision and maps this URL to a content file, it invokes the |
459 | FastCGI filter application with this file available as input. The FastCGI program's HTML output is sent |
460 | back to the client, just as in the responder role. The process is outlined in Figure 3. |
461 | </P> |
462 | <P> |
463 | </P> |
464 | <DIV CLASS="c2"> |
465 | <IMG ALT="error-file:TidyOut.log" SRC="img00003.gif"><A NAME="_Ref352560526">Figure 3</A> |
466 | </DIV> |
467 | <P> |
468 | Filter applications can significantly improve performance by caching filter results (the server provides the |
469 | modification time in the request information so that applications can flush the cache when the server file has |
470 | been modified). |
471 | </P> |
472 | <P> |
473 | The Filter role is useful for: |
474 | </P> |
475 | <UL> |
476 | <LI> |
477 | On-the-fly format conversions |
478 | </LI> |
479 | <LI> |
480 | Dynamic documents (such as documents with embedded SQL queries, or dynamic advertisement insertion) |
481 | </LI> |
482 | <LI> |
483 | Applying a standard template: headers, footers, and backgrounds |
484 | </LI> |
485 | </UL> |
486 | <H3> |
487 | Authorizer Role |
488 | </H3> |
489 | <P> |
490 | The Authorizer role allows a FastCGI application to make an access control decision for a request. The FastCGI |
491 | application is invoked with all of the request information, just as in the Responder role. If the authorizer |
492 | application generates a "200 OK" HTTP result, the Web server assumes that access is allowed and |
493 | proceeds with the request. (The Web server may process other access checks, including other FastCGI |
494 | authorizers, before access is ultimately allowed.) If the application generates any other response, that |
495 | response is returned to the client and the request is ended. The response can be any valid HTTP response, |
496 | including "Access Denied" or "Redirect". |
497 | </P> |
498 | <P> |
499 | The Authorizer role is useful for: |
500 | </P> |
501 | <UL> |
502 | <LI> |
503 | Access control based on username and password, where the user information is looked up in an external |
504 | database. |
505 | </LI> |
506 | <LI> |
507 | Complex access policies, such as time-of-day based access. |
508 | </LI> |
509 | <LI> |
510 | Smart-card challenge/response authentication. |
511 | </LI> |
512 | <LI> |
513 | Dynamic redirects, where the user is sent to different pages based on the request profile. |
514 | </LI> |
515 | </UL> |
516 | <H2> |
517 | <A NAME="_Ref352251764">4. FastCGI Application Library</A> |
518 | </H2> |
519 | <P> |
520 | Open Market has developed a FastCGI application library that implements the FastCGI protocol (hiding the |
521 | protocol details from the developer). This library makes implementing FastCGI programs as easy as writing CGI |
522 | applications. |
523 | </P> |
524 | <P> |
525 | The application library provides a replacement for the C language standard I/O (stdio) routines, such as <TT |
526 | CLASS="c3">printf()</TT> and <TT CLASS="c3">gets()</TT>. The library converts references to standard input, |
527 | standard output, and standard error to the FastCGI protocol. References to other files "fall |
528 | through" to the underlying operating system standard I/O routines. |
529 | </P> |
530 | <P> |
531 | This approach has several benefits: |
532 | </P> |
533 | <UL> |
534 | <LI> |
535 | Developers don't have to learn a new API to develop FastCGI applications. |
536 | </LI> |
537 | <LI> |
538 | Existing CGI programs can be migrated with minimal source changes (CGI migration is described in more |
539 | detail in the following section). |
540 | </LI> |
541 | <LI> |
542 | FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the |
543 | interpreter source code. |
544 | </LI> |
545 | </UL> |
546 | <P> |
547 | Here's a simple FastCGI application: |
548 | </P> |
549 | <BR> |
550 | <BR> |
551 | <PRE> |
552 | #include <fcgi_stdio.h> |
553 | |
554 | void main(void) |
555 | { |
556 | int count = 0; |
557 | while(FCGI_Accept() >= 0) { |
558 | printf("Content-type: text/html\r\n"); |
559 | printf("\r\n"); |
560 | printf("Hello world!<br>\r\n"); |
561 | printf("Request number %d.", count++); |
562 | } |
563 | exit(0); |
564 | } |
565 | </PRE> |
566 | <P> |
567 | This application returns a "Hello world" HTML response to the client. It also keeps a counter of the |
568 | number of times it has been accessed, displaying the value of the counter at each request. |
569 | </P> |
570 | <P> |
571 | The <TT>fcgi_stdio.h</TT> header file provides the FastCGI replacement routines for the C standard I/O |
572 | library. The <TT>FCGI_Accept()</TT> routine accepts a new request from the Web server. |
573 | </P> |
574 | <H3> |
575 | Migrating Existing CGI Programs |
576 | </H3> |
577 | <P> |
578 | The application library was designed to make migration of existing CGI programs as simple as possible. Many |
579 | applications can be converted by adding a loop around the main request processing code and recompiling with |
580 | the FastCGI application library. FastCGI applications have the following structure, with an initialization |
581 | section and a request processing loop: |
582 | </P> |
583 | <P> |
584 | <I>Initialize application;<BR> |
585 | </I> <TT>while(FCGI_Accept() >= 0) {</TT><BR> |
586 | <I>Process request</I>;<BR> |
587 | <TT>}</TT> |
588 | </P> |
589 | <P> |
590 | To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI |
591 | programs, depending on how they are invoked. The library detects the execution environment and automatically |
592 | selects FastCGI or regular I/O routines, as appropriate. |
593 | </P> |
594 | <P> |
595 | After migration, developers can clean up their FastCGI applications for best performance: |
596 | </P> |
597 | <UL> |
598 | <LI> |
599 | Fix any resource leaks. Many CGI programs do not attempt to manage memory or close files, because they |
600 | assume the world is going to be cleaned up when they exit. (If you don't want to clean up your program, |
601 | you can just have your process assume that it is leaking memory and exit after processing some fixed number |
602 | of requests.) Purify from Pure Software is one of a number of excellent tools for finding leaks and other |
603 | memory use problems. |
604 | </LI> |
605 | <LI> |
606 | Fix any problems with retained application state. The application must ensure that any state that it |
607 | creates in processing one request has no unintended effects on later requests. |
608 | </LI> |
609 | <LI> |
610 | Collapse functionality. A common practice with CGI applications is to implement many small programs, with |
611 | one function per program. CGI encourages this, because smaller programs load faster. With FastCGI, it's |
612 | better to have related functionality in a single executable, so there are fewer processes to manage and |
613 | applications can take advantage of sharing cached information across functions. |
614 | </LI> |
615 | </UL> |
616 | <P> |
617 | Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language |
618 | interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix |
619 | platforms are available from Open Market. The interpreters are backward-compatible: They can run standard Tcl |
620 | and Perl applications. |
621 | </P> |
622 | <H2> |
623 | 5. FastCGI in the Open Market WebServer |
624 | </H2> |
625 | <P> |
626 | This section describes the FastCGI support in the following Open Market server products: |
627 | </P> |
628 | <UL> |
629 | <LI> |
630 | Open Market WebServer V2.0 |
631 | </LI> |
632 | <LI> |
633 | Open Market Secure WebServer V2.0 |
634 | </LI> |
635 | <LI> |
636 | Open Market Secure WebServer (Global) V2.0 |
637 | </LI> |
638 | </UL> |
639 | <P> |
640 | For more information about FastCGI support, see the <I>Open Market WebServer Installation and Configuration |
641 | Guide</I>. |
642 | </P> |
643 | <H3> |
644 | Server Configuration |
645 | </H3> |
646 | <P> |
647 | FastCGI applications are configured with the server's configuration file. Configuration has two parts. |
648 | </P> |
649 | <P> |
650 | First, the server administrator defines an <I>application class</I>. For local applications, the application |
651 | class specifies the details of running the FastCGI application, such as: |
652 | </P> |
653 | <UL> |
654 | <LI> |
655 | The pathname of the application executable. |
656 | </LI> |
657 | <LI> |
658 | Any arguments and environment variables to pass to the process at startup. |
659 | </LI> |
660 | <LI> |
661 | The number of processes to run. |
662 | </LI> |
663 | </UL> |
664 | <P> |
665 | For remote applications, the class configuration information includes the host and TCP port to connect to. The |
666 | Web server assumes that the FastCGI application has been started on the remote host. If a request comes in and |
667 | the server can't connect to the FastCGI TCP port, the server logs an error and returns an error page to |
668 | the client. |
669 | </P> |
670 | <P> |
671 | The second configuration step is mapping the application class to a role: |
672 | </P> |
673 | <UL> |
674 | <LI> |
675 | For responder roles, the administrator configures some part of the URL space to be handled by the FastCGI |
676 | application. For example, all URLs beginning with <SPAN CLASS="c4">/rollcall/</SPAN> might be handled by |
677 | the employee database application. |
678 | </LI> |
679 | <LI> |
680 | For filter roles, the administrator configures a file extension to be handled by a filter application. For |
681 | example, all files with the <SPAN CLASS="c4">.sql</SPAN> extension could be handled by a SQL query lookup |
682 | filter. |
683 | </LI> |
684 | <LI> |
685 | For authorizer roles, the administrator configures an authorizer application in the same manner as other |
686 | access methods (hostname, username/password, etc.) A request must pass <I>all</I> access control checks |
687 | (possibly including multiple FastCGI authorizers) before access is allowed. |
688 | </LI> |
689 | </UL> |
690 | <H3> |
691 | Basic FastCGI |
692 | </H3> |
693 | <P> |
694 | To simplify migration for existing CGI programs, the WebServer provides a simple way to install new FastCGI |
695 | programs without having to reconfigure the server. However, this approach doesn't offer all of the |
696 | performance benefits of FastCGI application classes. |
697 | </P> |
698 | <P> |
699 | The WebServer treats any file with the extension <SPAN CLASS="c4">.fcg</SPAN> as a FastCGI application. When a |
700 | request corresponds to such a file, the WebServer creates a new FastCGI process to handle the request, and |
701 | shuts down the process when the request is complete (just as in CGI). In this mode of operation performance is |
702 | comparable to CGI. Future versions of the WebServer will improve performance by automatically caching |
703 | processes and re-using them for subsequent requests. |
704 | </P> |
705 | <H3> |
706 | Session Affinity |
707 | </H3> |
708 | <P> |
709 | FastCGI programs can improve performance by caching information in the application process. For applications |
710 | that require frequent but expensive operations such as validating a username/password in an external database |
711 | for each request, this technique can significantly improve performance. |
712 | </P> |
713 | <P> |
714 | To improve the effectiveness of this technique, the WebServer implements <I>session affinity</I>. When session |
715 | affinity is enabled, the WebServer arranges for all requests in a user session to be handled by the same |
716 | FastCGI application process. What constitutes a "session" is configurable. The default configuration |
717 | uses the WebServer's built-in session tracking facility to identify user sessions. However, the server |
718 | administrator can use any part of the request information for the session affinity mapping: the URL path, the |
719 | client's hostname, the username, etc. |
720 | <!--Talk about applications that need to hold onto resources for the user (such as open connections to the database).--> |
721 | </P> |
722 | <H2> |
723 | 6. FastCGI Performance Analysis |
724 | </H2> |
725 | <P> |
726 | How fast is FastCGI? The answer depends on the application. This section contains some real FastCGI |
727 | performance measurements, as well as guidelines for estimating the FastCGI speedup. |
728 | </P> |
729 | <H3> |
730 | FastCGI vs CGI |
731 | </H3> |
732 | <P> |
733 | We measured the relative performance of CGI, FastCGI, and static files on the Open Market WebServer, using a |
734 | simple application that generates a fixed number of output bytes. The following table shows the measured |
735 | request processing time for different request types on a typical platform. The times are measured from the |
736 | client perspective and include client, server, and application processing time. |
737 | </P> |
738 | <TABLE BORDERCOLOR="#000000" BORDER="2"> |
739 | <TR> |
740 | <TD WIDTH="72"> |
741 | <DIV CLASS="c5"> |
742 | Static file |
743 | </DIV> |
744 | </TD> |
745 | <TD WIDTH="180"> |
746 | <DIV CLASS="c5"> |
747 | 21ms + 0.19ms per Kbyte |
748 | </DIV> |
749 | </TD> |
750 | </TR> |
751 | <TR> |
752 | <TD WIDTH="72"> |
753 | <DIV CLASS="c5"> |
754 | FastCGI |
755 | </DIV> |
756 | </TD> |
757 | <TD WIDTH="180"> |
758 | <DIV CLASS="c5"> |
759 | 22ms + 0.28ms per Kbyte |
760 | </DIV> |
761 | </TD> |
762 | </TR> |
763 | <TR> |
764 | <TD WIDTH="72"> |
765 | <DIV CLASS="c5"> |
766 | CGI |
767 | </DIV> |
768 | </TD> |
769 | <TD WIDTH="180"> |
770 | <DIV CLASS="c5"> |
771 | 59ms + 0.37ms per Kbyte |
772 | </DIV> |
773 | </TD> |
774 | </TR> |
775 | </TABLE> |
776 | <P> |
777 | FastCGI performance is comparable to serving static files, and significantly better than CGI (clearly showing |
778 | the high overhead for process creation). Real applications have an additional time component: process |
779 | initialization, which should be added to overall request processing time. |
780 | </P> |
781 | <P> |
782 | Let's use this data to estimate the speedup from migrating a typical database CGI application to FastCGI. |
783 | Assume the application takes 50ms to initialize the database connection and generates 5K of output data. |
784 | Request performance can be computed as follows: |
785 | </P> |
786 | <TABLE> |
787 | <TR> |
788 | <TD WIDTH="108"> |
789 | CGI |
790 | </TD> |
791 | <TD WIDTH="331"> |
792 | 59ms + 50ms + (0.37ms)(5) = 111ms |
793 | </TD> |
794 | </TR> |
795 | <TR> |
796 | <TD WIDTH="108"> |
797 | FastCGI |
798 | </TD> |
799 | <TD WIDTH="331"> |
800 | 22ms + (0.28ms)(5) = 23ms |
801 | </TD> |
802 | </TR> |
803 | </TABLE> |
804 | <P> |
805 | In this example, FastCGI has a 5x performance advantage over CGI, mostly due to savings from not having to |
806 | create and initialize new processes for each request.<!--Need to talk about FastCGI vs proprietary APIs.--> |
807 | </P> |
808 | <H2> |
809 | 7. Conclusions |
810 | </H2> |
811 | <P> |
812 | Today's Web business applications need a platform that's fast, open, maintainable, straightforward, |
813 | stable, and secure. FastCGI's design meets these requirements, and provides for a logical extension from |
814 | proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's benefits |
815 | without losing their existing investment in CGI applications.<!--Need to talk about NT.--> |
816 | |
817 | <!--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. --> |
818 | </P> |
819 | <H2> |
820 | 8. For More Information |
821 | </H2> |
822 | <P> |
823 | For more information about Open Market and our products, visit our Web site at:<SPAN CLASS= |
824 | "c4">http://www.openmarket.com/</SPAN> |
825 | </P> |
826 | <P> |
827 | For more information about the FastCGI protocol and the developer's kit, and the latest information about |
828 | FastCGI standardization and support in other Web servers, visit the FastCGI project page at:<SPAN CLASS= |
829 | "c4">http://www.openmarket.com/fastcgi/</SPAN> |
830 | </P> |
831 | </BODY> |
832 | </HTML> |
833 | |