CGI（Common Gateway Interface）
かつてサーバサイド技術といえば、すなわちCGIと同義でもありました。そもそもCGIとは、Webサーバ上から外部プログラムを起動させ、その標準出力をクライアントに応答するインターフェイスの総称であり、そこで使用されるプログラミング言語を問いません。
CGIで起動される外部プログラムの開発には、テキスト処理に強く、柔軟な記述が可能なPerl（Practical Extension and Report Language）や特定OSに依存しない言語仕様を持つC言語が採用されることが比較的一般的ではありますが、文献や資料・対応するモジュール（ライブラリ）の多寡を除いては、どのような言語を採用するのもユーザーの自由です。CGIといってもなんらWebに特化したしくみではなく、要は外部プログラムに対してデータを入出力するだけのしくみですから、できることも使用する言語がサポートする範囲内で「完全に無制限」といえます。
以下では、Perl＋CGIによる最も簡単なサンプルを挙げておくことにしましょう。
#!/usr/local/bin/perl print "Content-Type:text/html\n\n"; print "<html>"; print "<head>"; print "<title>Hello, World!!</title>"; print "<body>"; print "Hello, World!!"; print "</body>"; print "</html>";
開発性の観点から
結論からいうならば、CGIによる開発性は決して高いとはいえません。というのも、CGIとはあくまでアクセスカウンタや掲示板、ゲストブックのような、サーバサイド技術をページ上の「付随的」な機能として利用していた世界の産物であり、そもそもの構造上、アプリケーションの骨子を形成するビジネスロジックを構築することを意識したものではないからです。
（1）言語を選ばない
開発するうえでCGIが言語を選ばないというのは大きなメリットです。それは、CGI開発に当たって開発者が「自分が最も得意な言語を選択できる」ことを意味するからです。これは、後述するASPが「COM（Component Object Model）技術に対応する」すべての「スクリプト言語」を使用可能とするのとはまったく異なる次元の柔軟性を保証するもので、また、使用言語がJavaに限定されるJSP＆サーブレットとはまったく対照的な性質といえましょう。
しかし、半面で、開発性が言語仕様に直接依存することも忘れてはなりません。例えば、PerlなどはCGI用の言語として古くから採用されてきたもので、ライブラリの豊富なラインアップから高い開発性を保証します。しかし、これらライブラリはあくまで「PerlがCGIの開発用に用意したもの」で、CGIとして標準的に用意されているものではありません。言語によっては一から該当する機能を構築する必要があります。
（2）HTTPプロトコルを直接操作しなければならない
CGIが使用する言語をまったく選ばない、という利点は、CGIがHTTP（HyperText Transfer Protocol）プロトコルを隠ぺいするためのしくみをなんら持たないという事実の裏返しでもあります。つまり、JSP＆サーブレットをはじめASPやPHPといったポストCGI（CGIの後継）技術が、プロトコルレベルの操作をAPI（関数・クラス・COM）によって隠ぺいしているのとは裏腹に、CGI開発ではプロトコルレベルの操作を自ら記述する必要があります。APIはおのずと使用する言語を制約しますが、その制約に見合うだけの利点をユーザーに提供しているのです。
上のサンプルでもコード冒頭においてHTTPヘッダを自らその都度出力していますが、そのほかにもHTTP応答ステータスを意識する必要があったり、自らリクエストデータを処理しなければならないなど、純粋なビジネスロジックとは異なるレベルでの処理を、CGIはユーザーに強要します。
パフォーマンスの観点から
ビジネスアプリケーションを構築する場合、CGIでは、大きく前述の開発性とパフォーマンスがネックとなることが少なくありません。
一般的に、CGIはユーザー数の増加に極めて脆弱であり、パフォーマンスの劣化に直結する危険性を含んでいます。
（1）処理パフォーマンスは言語に依存
繰り返し述べているように、CGIは使用する言語を選びません。例えば、コンパイル（一括翻訳）言語であるC言語を選択した場合には言語処理的には比較的高いパフォーマンスを望むことができますし、インタプリタ（逐次翻訳）言語であるPerlを選択した場合には、C言語に比べれば相対的に処理パフォーマンスは劣化します。
ただし（2）で後述するように、言語処理レベルでのパフォーマンス以上に、CGIには構造上、パフォーマンスの足を引っ張る致命的な欠陥が含まれています。
（2）プロセスを常に起動する
CGIといっても、要はなんの変哲もない、Webサーバの外部プログラムにほかなりません。つまり、リクエストの都度、CGIは新たな実行プロセスを起動しなければならないのです。これは極めてシステムリソースを浪費する大きな要因でもあり、ユーザー数が少ないうちならばいざしらず、ユーザー数が増加してくると急激にレスポンスの鈍化を招きます。
対するJSP＆サーブレットをはじめASPやPHPなどのポストCGIが、あくまでWeb上で動作するコンテナ（実行エンジン）の1プロセス上で、スレッドと呼ばれるより軽量な実行単位で処理されるのとは対照的で、これは極めて非効率的な処理方法です。
可搬性の観点から
これもまた採用する言語によって、大きく左右されるところでもあります。例えば、Perl言語であれば、UNIX系OSでもWindows系OSでも実行エンジンが用意されていますので、OS機能に依存するような命令がコード中に含まれていなければ、実行パスを変更するだけで基本的には移植が可能です。
一方、C言語を採用している場合、実行形式がOSに強く依存しますので、そのままの移植は原則できないと考えるべきでしょう。
One Point
CGIはWebサーバから外部プログラムを呼び出し、標準出力を受け取るための汎用的なしくみです。制約事項が少ない反面、開発保守性・パフォーマンスともに難点も少なくありません。
Copyright © ITmedia, Inc. All Rights Reserved.