Shinya TAKEBAYASHI
omoik****@gmail*****
2011年 8月 6日 (土) 22:50:18 JST
たけばやしです． お久しぶりです・・・． v3 をまともに触っていないので v2 をベースに話をしますが．．． > > 1. キーワードはリクエストのどこを捜査するのか(リクエスト行 > > (PATH, パラメータ) or ヘッダ全体 or (POSTなどの)ボディを含 > > む)。 > > > > マニュアルを見る限りではv2ではヘッダの「リクエスト行」と > > 「Host フィールド」それぞれに専用のオプションが用意されて > > います。 > > > > いただいた図においても、www.YYY.com という文字列で振り分け > > るのであれば、Hostフィールドを見なければなりませんし、図に > > はありませんが、たとえば > > 「http://www.YYY.com/path/to/contents.html」というリクエス > > トの /path 部分で振り分けたいのであればリクエスト行を見な > > ければなりません。 > > ボディ見るのは、厳しいかもね〜。 > HTML解析しないといけないし。 > V2みたいにリクエストとホストで分けるほうがいいかな。利用者も > これまでと同じ設定方法のほうがわかりやすいだろうし。 リクエストと HOST を見るのが良いと思います． ボディを見ないといけない場合って・・・なんでしょう． > > 2. 複数の VirtualService のキーワードにマッチした場合、どの > > Virtual Service にいくのか。(設定ファイルに書かれた上のほ > > うだけに振り分けられる、とか) > > V2だと一番最初にヒットしたやつ(一番上にかかれたやつ)のルールに従う > だったかな。とりあえず、それでいいとおもう。 > 変えるならもっと高度な振り分けルールが設定できるようにしたいな〜。 高度な振り分けルールを実装するとなると，某大きな IP で 使われているような，なんとか rules のようなものを実装することに なるでしょう． 設定する側も作りやすいし，解析する側も構造化されていて 整理しやすいと思います． 実際に作るとなると，かなり難しいものになりますが， 今後を考えると，あって損はないかなぁと思います． ＃ え，今後？ という話はとりあえず・・・ > > 3. 継続的HTTPコネクション(HTTP KeepAlive)における連続したリク > > エストをどう扱うか。 > > > > v2 は HTTP リクエスト単位を意識していないので、HTTP > > KeepAliveが有効な環境では、一度 URL モジュールでリアルサー > > バが決定してしまうと、同一の TCP セッション内のリクエスト > > はすべて同一のサーバに振られていたように記憶しています。こ > > れは望ましい動作ではないと思いますので、v3 ではリクエスト > > ごとに正しい宛先に振るようにすべきだと思います。 > > この3番の状況が、うまくイメージできなかったｗ > KeepAliveが有効だとソケットをcloseしないから、その間おなじ > サーバに振られるってことかな？ > > リアルサーバのApacheがKeepAlive有効だと・・・そか、UltraMonkeyと > リアルサーバの間の接続がクローズされずにつなぎっぱになるのか。 > その場合、UltraMonkeyとクライアントの間は、1リクエスト終わると > すぐクローズするのかな？それともKeepAlive的にクローズしないのかな？ 猿とリアルサーバの間も繋ぎっぱなしです． 一番最初のリアルサーバ未定のときを除いて，どちらかのコネクションが TCP レイヤで切断されない限りは，片方だけ生き残っていることは 無いと認識しています． > URLモジュールに関係なく、その辺の仕様の整理が必要かも。 そうですね． > > あと、これはURLモジュールというよりも本体側の仕様なのですが、 > > モジュールを単体でビルドできるようにしておくと、独自のモジュー > > ルを作りたい人が嬉しいのではないかと思います。 > > さらに、Firefoxの拡張機能のように、動的にロード・アンロードできると > 嬉しいと思いま〜す('∇')ノ > > ・・・まあ、難しいと思いますけどｗ > # 単に動的ロードとアンロードは、dlopen系の関数で出来ますが > # (C++/Boostだとどうやるのかは知んないｗ)、「安全に」「通信中 > # データに影響を与えないように」動的ロード・アンロードできる > # 仕組みを実装するのが大変。 既存のコネクションを救済する必要はないと思います． あっても困ることはないのですが，設変はメンテナンスウィンドウで 実施するもの ＝ サービスを閉塞した状態で実施するものと 割り切ってしまってもいいと思います． > > 具体的にはモジュールのビルドに必要なヘッダファイル、ライブラ > > リをシステムにインストールするように変更することを意図してい > > ます。 > > > > 現状ではヘッダファイルや(スケジューラ/プロトコルモジュール以 > > 外の)ライブラリはインストールされないので、モジュールのビルド > > には展開したソースコード(とビルドしたライブラリ)が必要です。 > > まあ、libuml7proto.soのライブラリとヘッダをセットにした、 > devパッケージはあるといいかもですねぇ。 これは必要ですね． v2 だとプロトコルモジュール／スケジューラモジュールを ビルドするのに必要なヘッダファイルを切り出すくらいなら すぐにできそうですが，v3 だとどうなんでしょう． > > たとえば、UltraMonkey-L7 の RPM をインストールした環境に独自 > > モジュールを追加で使おうとして、インストールされている l7vsd > > と異なるバージョンのソースツリーでモジュールをビルドしてしまっ > > た場合等、障害時の切り分け等でドツボにはまる可能性があります。 > > > > ただ、モジュールのビルドに必要なライブラリの切り出し、ビルド > > 関連ファイルの修正が必要なのでそれなりの手間がかかります > > が・・・ > > まあ、まずは既存機能をまともに動くものにするところから・・・ｗ v3 て動かないんでしたっけ？ ＃ 私の中では v3 は無いことになっているので・・・ ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: omoik****@gmail***** twitter: chi9rin GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 -----------------------------------------------------------
UltraMonkey-L7
Fork