FastCGI

FastCGIとは、Webサーバ上でユーザプログラムを動作させるためのインタフェース仕様の一つである。CGIの問題を解決するためにOpen Market（英語: Open Market）社によって1990年代中頃に開発された^[1]もので、仕様は公開されている。

概要(従来のCGIの問題点)

CGIは、外部アプリケーションをWebサーバに接続するためのプロトコルである。CGIアプリケーションは個別のプロセスで実行され、各リクエストの開始時に作成され、終了時に破棄される。この﹁リクエスト毎に1つの新しいプロセス﹂モデルにより、CGIプログラムの実装が非常に簡単になるが、効率とスケーラビリティが制限される。高負荷では、プロセスの作成と破棄のためのオペレーティングシステムのオーバーヘッドが大きくなる。また、CGIプロセスモデルは、データベース接続の再利用、インメモリキャッシング等のリソース再利用方法を制限する。

歴史

CGIのスケーラビリティの欠点に対処するために、Open Market はFastCGI を開発し、1990年代中頃に最初にWebサーバ製品に導入した。Open Market は当初、Webアプリケーションを開発するためのNetscape独自のインプロセスAPI(Netscapeサーバアプリケーションプログラミングインターフェイス︵英語版︶(NSAPI))に対する競争力のある対応としてFastCGIを開発した。最初はOpen Market によって開発されたが、FastCGI は他のいくつかのWebサーバメーカーによって実装された。ただし、そのアプローチは、サーバとサブプログラム間の通信を高速化および簡素化する他の方法と競合した。mod_perl︵英語版︶やmod_php︵英語版︶等のApache HTTP Serverモジュールがほぼ同時期に登場し、急速に普及した。2019年現在、CGIを含むこれら様々な方法は引き続き使用されている。

詳細

リクエスト毎に新しいプロセスを作成する代わりに、FastCGI は永続的なプロセスを使用して一連のリクエストを処理する。これらのプロセスは、WebサーバではなくFastCGI サーバが所有している^[2]。受信リクエストを処理するために、Webサーバは環境変数情報とページリクエストを、UNIXドメインソケット、名前付きパイプ、または伝送制御プロトコル(TCP)接続のいずれかを介してFastCGI プロセスに送信する。応答は同じ接続を介してプロセスからWebサーバに返され、Webサーバはその応答をエンドユーザに配信する。応答の最後に接続が閉じられる可能性があるが、WebサーバとFastCGI サービスプロセスの両方が存続する^[3]。個々のFastCGI プロセスは、その存続期間中に多くの要求を処理できるため、要求毎のプロセスの作成と終了のオーバーヘッドを回避できる。複数の要求を同時に処理するには、いくつかの方法がある。1つの接続を内部多重化(つまり、1つの接続で複数の要求)を使用して行う、複数の接続を使用する、またはこれらの方法の組み合わせによる方法がある。複数のFastCGI サーバを構成できるため、安定性とスケーラビリティが向上する。 Webサイトの管理者とプログラマは、FastCGI でWebサーバからWebアプリケーションを分離すると、組み込みインタプリタ(mod_perl︵英語版︶やmod_php︵英語版︶等)に比べて多くの利点がある。この分離により、サーバプロセスとアプリケーションプロセスを個別に再起動できる。これは、多忙なWebサイトにとって重要な考慮事項である。また、ISPやWebホスティング会社にとって重要な要件である、アプリケーションごとのホスティングサービスセキュリティポリシーの実装も可能になる^[4]。様々なタイプの着信要求を、それらのタイプの要求を効率的に処理するように装備されている特定のFastCGI サーバに配布できる。

FastCGI を実装するWebサーバ

参考: Webサーバソフトウェアの比較＃機能︵英語版︶注: 特に明記しない限り、FastCGI 実装の完全性は不明 ●Apache HTTP Server(部分的) ●mod_fcgid^[5]によって実装されている。このモジュールは以前はサードパーティだったが、Chris Darroch によって統括された2009年にApache ServerのサブプロジェクトとしてApacheソフトウェア財団(ASF)に寄贈された^[5]。UNIXドメインソケットのみをサポートし、TCP ソケットはサポートしない^[6]。 ●サードパーティのモジュールmod_fastcgiも使用される。しばらくの間、このモジュールはApache 2.4.xで適切にコンパイルされなかった^[7]。その問題は元のプロジェクトのフォークで解決された^[8]。 ●1つの接続を介したリクエストの多重化は、Apache 1.x 設計によって禁止されているため^[9]、これはサポートされていない ●Apache 2.4では、mod_proxy_fcgi^[1^0]が追加され、TCP FastCGI サーバをサポートしている。 ●Caddy^[11] ●Cherokee︵英語版︶^[12] ●Hiawatha︵英語版︶^[13] ●ロードバランシングFastCGI サポート ●chroot されたFastCGI サーバをサポート ●Jetty^[14] ●Kerio WebSTAR︵英語版︶ ●Lighttpd^[15] ●LiteSpeed Web Server︵英語版︶ ●Microsoft IIS^[16] ●nginx ●NaviServer︵英語版︶ ●Oracle iPlanet Web Server ●OpenBSDのhttpd(8)^[17] ●Open Market︵英語版︶Webサーバ ●Resin︵英語版︶WebサーバおよびWebアプリケーション ●Roxen︵英語版︶Webサーバ ●ShimmerCat︵英語版︶Webサーバ ●Zeus Web Server︵英語版︶

API言語バインディング

FastCGI は、ネットワークソケットをサポートする任意の言語で実装できる。﹁FastCGI はプロトコルであり、実装ではない﹂ため、1つの言語に強く拘束されていない。アプリケーションプログラミングインターフェイス(API)は、次のものに対して存在する^[1^8]: ●Ada^[19] ●Delphi, Lazarus, Free Pascal^[20^] ●C言語、C++ ●Chicken (Scheme) ●Common Lisp^[21] ●D言語 ●Eiffel^[22] ●Erlang ●GnuCOBOL ●Go ●Guile Scheme ●Haskell ●HP BASIC for OpenVMS︵英語版︶ ●Java^[23]^[14] ●Lua ●node.js^[24] ●OCaml ●Perl^[25] ●PHP(php-fpm経由^[26]、HipHop for PHP︵英語版︶^[27]) ●Python ●Ruby ●Rust^[28] ●SmartEiffel︵英語版︶ ●Smalltalk: FasTalk およびDolphin Smalltalk︵英語版︶ ●Tcl ●WebDNA︵英語版︶ ●Vala(C言語バインディング) ●Xojo(以前はRealbasic, REAL Studio)^[29] Ruby on Rails, Catalyst, Django, Kepler︵英語版︶、Plack︵英語版︶等の最近のフレームワークでは、組み込みインタープリタ(mod_ruby︵英語版︶, mod_perl︵英語版︶, mod_python, mod_lua︵英語版︶等)、またはFastCGI を使用できる。 FastCGI が適用できない言語の一つはシェルスクリプトである。一部のシェルの実装では POSIX では規定されてない拡張機能として最低限のネットワークソケットをサポートしてはいるが、言語上の制限が大きく実装が困難なため API 言語バインディングが存在しない。また FastCGI は新しいプロセスを作成しないことで要求毎のオーバーヘッドを回避するのが目的であるが、シェルスクリプトでは多数の外部コマンドを呼び出すことで処理を行うプロセスを多数作成するプログラミングスタイルとなるため、たとえ FastCGI が使えたとしても要求毎のプロセス生成をたかだか1つ減らせる程度となり FastCGI のオーバーヘッドの回避の効果は限りなくゼロに近い。

脚注

[脚注の使い方]

出典

外部リンク

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[1

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[1

[19]

[20

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

概要(従来のCGIの問題点)

歴史

詳細

FastCGI を実装するWebサーバ

API言語バインディング

脚注

出典

関連項目

外部リンク