Hatena::ブログ(Diary)

kazuhoのメモ置き場

2009-09-07

FastCGI プロトコルってなんのためにあるのかわからない

どういう場合に便利なんだっけ。てか HTTP プロトコルでいいじゃんみたいな。

たとえば httpd とアプリケーションサーバを分割するような環境なら、apache + fastcgi external server みたいな構成よりも、apache (mod_proxy + mod_proxy_balancer) + apache (mod_perl) とかのほうが柔軟だし。

あるいは、apache + fastcgi external server みたいなのを組むよりも、apache (mod_proxy + mod_proxy_balancer) + HTTP::Server::Simple (Net::Server::Prefork) でいいんじゃないかみたいな。

unix socket を動的に作成して通信、みたいたことをする場合でも、独自プロトコルな必要ってないんじゃないのかなー。みたいなことを改めて思っている秋。

どっかのおっさんどっかのおっさん 2009/09/08 08:37 fastcgiのプロトコルはhttpとはまったく別物。
mod_proxyともまったく性質が違う。

どちらも同じ土俵で比べるもんじゃないのでは。

もうちょっというと、fastcgiプロトコルというのは、httpdがどう外部プロセスとIPCするのかを決めるのであって、httpのように、外部クライアントとの間のグローバルなプロトコルではない。利点のひとつとしては、phpのようなインセキュアなものをプレフォークモデルのwebサーバプロセス実行権限から切り離して固有の権限で動かせること。ホスティング業者等で、マルチユーザ環境において、どのユーザのphpプロセスもwebサーバユーザで動かしていると、様々なセキュリティの問題があって、php(特に依存ライブラリ)がリエントラントではない場合が多いのでマルチスレッドじゃなく古典的なプレフォーク/webサーバユーザモデルでやる場合が多いけど、そういうときにfastcgiが重宝する。

kazuhookukazuhooku 2009/09/08 10:27 コメントありがとうございます。

「どっかのおっさん」さん、コメントありがとうございます。私の説明が不足していたかもしれませんが、「外部クライアントとの間のグローバルなプロトコル」について議論しているのではなく、「httpdがどう外部プロセスとIPCするか」という点について、わざわざ HTTP と異なる FastCGI プロトコルを使うメリットはないのではないかと、リバースプロキシとhttpベースのアプリケーションサーバを組み合わせる構成を例に挙げながら指摘しています。

べき論としては、(HTTPD⇔ウェブサーバ間のプロトコルとして) 特に設計上の優位性が FastCGI プロトコルにあるとは言えない以上、両プロトコルのいずれかを選択可能な場合は HTTP プロトコルを選択すべきだと考えます。

普及度から言っても HTTP プロトコル > FastCGI プロトコル、なので、かなりの場合で FastCGI プロトコルを使わずに済むのかな、と思います。

どっかのおっさん2どっかのおっさん2 2009/10/30 17:05 なにをいってんだか。。めんどくさいので誰も説明したがらないようなので、説明しとく。どっかのおっさんが言っているように、FastCGIというのは、httpと同列に論じるものじゃなくて、そもそも、httpというのはIPCのプロトコルじゃない。FastCGIはhttpと競合するものでもなければ打ち消しあうものでもない。相互に相乗効果をもたらすものだ。FastCGIは単体で機能するものではなくて、DSOと同等の性能を得るために常駐させておく外部プロセス部分(php、perlなどのCGIプロセス)と、それらを管理(プロセス数や再起動までの最大リクエスト数などの閾値の設定が可能)するPM(プロセスマネージャ)の部分とにわかれていて、perlはperlのphpはphp用に、FCGIのサーバとして機能するためのパッチが用意されていて、PMと「FastCGIプロトコル」でやり取りするようになっている。httpとその(あんたが言及した)モジュールで実現可能な運用手法と同列で見るものじゃない。わかる?

kazuhookukazuhooku 2009/10/31 09:08 問題は、FastCGIが提供している(提供しうる)機能のうち、FastCGIプロトコルが提供していてHTTPプロトコルベースではできない機能として何があり、その結果、どのようなメリットが生まれているのか。FastCGIプロトコルに優位性があると主張したいなら、その点を明確にしないとダメじゃないですか?

たとえば、プロセスマネージャの機能が密結合されていることがメリットなら、それがアプリケーションプロトコルのどの機能によって実現されていて、その機能が、シグナルや他のIPC手段によって代替できない(だからHTTPプロトコルを使用すべきでない)ということを示すべきだと思います。

> FastCGIというのは、httpと同列に論じるものじゃなくて、そもそも、httpというのはIPCのプロトコルじゃない

Unixドメインソケットを使うか、ネットワークソケットにするかによって、プロトコルが異なるべき必然性ってなんですか? UnixドメインソケットでもTCP上でも使用されるプロトコルって、多種存在しますよね (FastCGIプロトコルにしたって、TCP上で運用されることもある)。

ついでに言うと、PerlのFCGI対応はパッチじゃないです。普通のモジュール。

TETSUTETSU 2011/05/02 15:41 スケーラブルなWebサービスを提供したい時に、最近はどっちも選ぶことが出来るようになってきていて、自分もHTTPプロトコルを選ぶ方がメリットが大きいと思うようになりました。(どっかのおっさんはプロトコル比較の話なのでこの場合意味が無い)
HTTPプロトコルなら慣れているし、デバックも楽だし(個別のサーバで単体テストも簡単)リバースプロキシでキャッシュさせる時も設定が簡単だし
あと最近だと、負荷分散の方法もいろいろ選べますからね。リバースプロキシ側で分散させることが出来るのはあたりまえですが、LVSを使ってバックエンドの方で負荷分散させることも簡単ですからね。
あとバックエンドのサーバが同じデータセンターにあるとは限らないことも、HTTPでアクセスできるところにあれば、別にどこでもよいわけですし、最近は回線も早くなっているので・・メインはDC、一部のサービスは自宅サーバとかも簡単に実現できます(^^) もちろんやるかどうかは別問題ですが

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証