From tateishi.katsuyuki ＠ oss.ntt.co.jp Mon Aug 8 12:00:35 2011 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Mon, 08 Aug 2011 12:00:35 +0900 (JST) Subject: [Ultramonkey-l7-develop 715] Re: =?iso-2022-jp?b?dWx0cmFtb25rZXktbDcgVjMgGyRCJE4/NzUsJWIbKEI=?= =?iso-2022-jp?b?GyRCJTglZSE8JWszK0gvJEskRCQkJEYbKEI=?= In-Reply-To: References: <20110804.174425.568956462776812355.tateishi.katsuyuki@oss.ntt.co.jp> <4E3BA793.1080609@nttcom.co.jp> Message-ID: <20110808.120035.2113337934188172344.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 Shinya TAKEBAYASHI -san wrote: >> > 1. キーワードはリクエストのどこを捜査するのか(リクエスト行 >> > (PATH, パラメータ) or ヘッダ全体 or (POSTなどの)ボディを含 >> > む)。 >> > >> > マニュアルを見る限りではv2ではヘッダの「リクエスト行」と >> > 「Host フィールド」それぞれに専用のオプションが用意されて >> > います。 >> > >> > いただいた図においても、www.YYY.com という文字列で振り分け >> > るのであれば、Hostフィールドを見なければなりませんし、図に >> > はありませんが、たとえば >> > 「http://www.YYY.com/path/to/contents.html」というリクエス >> > トの /path 部分で振り分けたいのであればリクエスト行を見な >> > ければなりません。 >> >> ボディ見るのは、厳しいかもね〜。 >> HTML解析しないといけないし。 ボディを見るとして、の話ですが、HTML解析は不要だと思います。 >> V2みたいにリクエストとホストで分けるほうがいいかな。利用者も >> これまでと同じ設定方法のほうがわかりやすいだろうし。 > > リクエストと HOST を見るのが良いと思います． > ボディを見ないといけない場合って・・・なんでしょう． 私も強く必要だと思っているわけではありませんが、以下のような 場合が考えられないでしょうか: 1. あるフォームでGETにパラメータを渡すページがあり、そのパラ メータを URL モジュールでマッチさせて振り分けていた 2. そのフォームで大きなデータを送ることになり(ファイルアップ ロード等)、GET から POST に変更する必要が生じた 3. しかし URL モジュールはリクエストボディを見て振り分けでき ない。困った。 > > >> > 2. 複数の VirtualService のキーワードにマッチした場合、どの >> > Virtual Service にいくのか。(設定ファイルに書かれた上のほ >> > うだけに振り分けられる、とか) >> >> V2だと一番最初にヒットしたやつ(一番上にかかれたやつ)のルールに従う >> だったかな。とりあえず、それでいいとおもう。 l7directord.cf に書いた順番がよさそうですね。 あと URL モジュールを使った Virtual Service しか存在せず、か つどの Virtula Service にもマッチしなかった場合はどうします か？ >> > 3. 継続的HTTPコネクション(HTTP KeepAlive)における連続したリク >> > エストをどう扱うか。 >> > >> > v2 は HTTP リクエスト単位を意識していないので、HTTP >> > KeepAliveが有効な環境では、一度 URL モジュールでリアルサー >> > バが決定してしまうと、同一の TCP セッション内のリクエスト >> > はすべて同一のサーバに振られていたように記憶しています。こ >> > れは望ましい動作ではないと思いますので、v3 ではリクエスト >> > ごとに正しい宛先に振るようにすべきだと思います。 >> >> この3番の状況が、うまくイメージできなかったｗ >> KeepAliveが有効だとソケットをcloseしないから、その間おなじ >> サーバに振られるってことかな？ そうです。 >> >> リアルサーバのApacheがKeepAlive有効だと・・・そか、UltraMonkeyと >> リアルサーバの間の接続がクローズされずにつなぎっぱになるのか。 >> その場合、UltraMonkeyとクライアントの間は、1リクエスト終わると >> すぐクローズするのかな？それともKeepAlive的にクローズしないのかな？ > > 猿とリアルサーバの間も繋ぎっぱなしです． > 一番最初のリアルサーバ未定のときを除いて，どちらかのコネクションが > TCP レイヤで切断されない限りは，片方だけ生き残っていることは > 無いと認識しています． 竹林さんと同じ認識です。 UltraMonkey-L7 はリアルサーバあるいはクライアントからのクロー ズをそのまま他方に伝えるだけで、コネクションプーリングしたり はできないはず。 > > >> URLモジュールに関係なく、その辺の仕様の整理が必要かも。 > > そうですね． クライアント:リアルサーバの接続が1:nになるような状況では、い くつか考えないといけないことがありそうです。 ・あるリアルサーバからのコネクションクローズ時に、別のリアル サーバとのコネクションが生きている場合がある ・通常ではなさそうなレスポンスをサーバが返すことになる。 たとえば、サーバはレスポンスヘッダの Keep-Alive フィールド にあと何回リクエストを受け付けられるかを入れて返してきます が(max=100 など)、これがリクエストのたびに変わる可能性があ ります。これがプロトコル仕様上問題があるかどうかはわかりま せん＝対応しなくていいかも とか。 もちろん、UltraMonkey-L7 が ・クライアント-UML7間におけるHTTPサーバとしての動作 ・UML7-リアルサーバ間におけるHTTPクライアントとしての動作 についてそれぞれ正しいHTTPを喋るというのが、あるべき姿だと思 います。 > > >> > あと、これはURLモジュールというよりも本体側の仕様なのですが、 >> > モジュールを単体でビルドできるようにしておくと、独自のモジュー >> > ルを作りたい人が嬉しいのではないかと思います。 >> >> さらに、Firefoxの拡張機能のように、動的にロード・アンロードできると >> 嬉しいと思いま〜す('∇')ノ >> >> ・・・まあ、難しいと思いますけどｗ >> # 単に動的ロードとアンロードは、dlopen系の関数で出来ますが >> # (C++/Boostだとどうやるのかは知んないｗ)、「安全に」「通信中 >> # データに影響を与えないように」動的ロード・アンロードできる >> # 仕組みを実装するのが大変。 > > 既存のコネクションを救済する必要はないと思います． > あっても困ることはないのですが，設変はメンテナンスウィンドウで > 実施するもの ＝ サービスを閉塞した状態で実施するものと > 割り切ってしまってもいいと思います． 竹林さんと同じ意見です。 サーバプログラムという用途を考えると、コスト効果は低いかなと 思います。ないと困る or あると大変便利な機能かといわれるとそ うでもない気がしますし。 > > >> > 具体的にはモジュールのビルドに必要なヘッダファイル、ライブラ >> > リをシステムにインストールするように変更することを意図してい >> > ます。 >> > >> > 現状ではヘッダファイルや(スケジューラ/プロトコルモジュール以 >> > 外の)ライブラリはインストールされないので、モジュールのビルド >> > には展開したソースコード(とビルドしたライブラリ)が必要です。 >> >> まあ、libuml7proto.soのライブラリとヘッダをセットにした、 >> devパッケージはあるといいかもですねぇ。 > > これは必要ですね． > v2 だとプロトコルモジュール／スケジューラモジュールを > ビルドするのに必要なヘッダファイルを切り出すくらいなら > すぐにできそうですが，v3 だとどうなんでしょう． これは共有ライブラリ化 && ヘッダといっしょにインストールとい う方向でよさそうですね。 -- TATEISHI Katsuyuki