In message <_A79@delegate-ja.ML_> on 11/30/07(03:41:31)
you "Takemitsu Suzuki" <pj4aabrv6-iafv4ftyganw.ml@delegate.org> wrote:
 |こんばんは。日立ソフトウェアエンジニアリングの鈴木と申します。
 |
 |現在Webシステムの構成について検討しており、Delegate + Windows Server 2003
 |のキャッシュサーバを構築しようと考えています。検証を実施しているのですが、
 |Delegateの仕様について確認したいことがございます。
 
Delegate ではなく、DeleGateなんですが。。。

 |このような問い合わせにDelegate御意見箱を利用できないようであれば、ご指摘
 |ください。

適切な利用だと思います。(deja vu?)

 |複数台のWebサーバを負荷分散装置で負荷分散しているWebシステムに、
 |Delegateを採用したキャッシュサーバをプロキシサーバとして指定したPC
 |から接続するような環境を構築しました。この環境で、以下のような事象が生じ
 |ています。
 |
 |・事象
 |あるWebアプリケーションを実行した際、PCからの2つのHTTPリクエトが発生する。
 |このときのパケットをキャプチャして確認してみると、2つのHTTPリクエストは
 |それぞれ異なる2つのTCPセッションに分かれている。このとき、Delegateから負
 |荷分散装置へも2つのHTTPリクエストが発生するが、パケットをキャプチャして
 |確認してみると、2つのHTTPリクエストが1つのTCPセッションに纏まっていること
 |がある。
 |
 |実は負荷分散装置でCookieを利用したセッション維持を行っているのですが、
 |Cookieの割り当てが正常に行われていない現象が発生しており、上記事象が影響
 |している可能性を調査しているところです。
 |
 |一般的にこのような動作が問題なのかどうかは把握できておりませんが、
 |Delegateの設定により、2つのHTTPリクエストをそれぞれ異なる2つのTCPセッショ
 |ンに強制的に分かれさせるようなことは可能でしょうか？基本的には、PCからの
 |HTTPリクエストのTCPセッションと同じように分かれさせられれば良いと考えて
 |います。

まず、HTTPはコネクションレス&セッションレスなプロトコルなので、とある２つの
リクエストは、それらが物理的に同じクライアントホストからのものであるか否か、
同じTCPコネクション上からのものであるか否かに、意味が依存しない（させては
いけない）ものだと思います。
論理的なセッションを表現するためのCookieについても、それを物理的なコネク
ションと関連させるように使用するのは、いかがなものか？と思います。

それはそうと、実際、DeleGateではサーバへのコネクションをKeep-Aliveしており、
複数の（異なるTCPコネクションでの）クライアントからのリクエストの中継に
共有しています。これは主に、多段プロキシやリバースプロキシ等、あるいは
接続先のサーバが限定される際に、中継の際のサーバ向けコネクションの作成を
減少させて高速化するためのものです。
実装の当初は、HTTP/1.1の（keep-aliveする）サーバとHTTP/1.0の（keep-aliveし
ない）クライアント間の中継で、同様な効果をねらったものだったと思います。

DeleGateのこの機能は、HTTP/1.1サーバとの暗黙的なkeep-aliveを抑制する

  HTTPCONF=svver:1.0

あるいは、keep-alive機能を抑制する

  HTTPCONF=bugs:no-keepalive

などで抑制することができます。ただ、これにより、HTTP/1.1のその他の機能
(chunkedやgzipなど)も抑制してしまったり、クライアント側とのkeep-aliveも
抑制してしまうため、性能的に問題があると思います。

ところで、DeleGateでは、クライアントからのリクエストにCookieがある場合、
サーバがそれに依存した応答を返すような実装の場合のセキュリティ上の問題から、
応答のキャッシュを自動的に無効にしています。
同様に、Cookieがある場合に物理的なコネクションをセッションと関連付ける
ようなサーバの実装に対応するために、別々のクライアント側からのコネクション
に対してはサーバへのコネクションを再利用させない、ということが考えられます。
こうすれば、Cookieが無い場合には従来どおりコネクションを再利用できるので
性能の低下も多少は防げるかも知れません。もっとも、最近のサーバはほとんどの
場合、何らかのCookieを使っていると思いますが。

とりあえず、これを実現するための変更は、同封のパッチのようになります。

別々のコネクションでも、同じアドレスのクライアントからの要求の場合には
サーバの再利用を許可するとか、Proxy-Authorizationが同じ場合には再利用する
とかも考えられますが、クライアントがプロキシの場合には効果がありません。
Cookie（のMD5とか）を残しておいて、同一のCookieの場合には再利用を許可する
とかというのも考えられます。
考えてみれば、同一のコネクションからでも、Cookieが異なる場合には、サーバの
再利用を行わないようにする、というのが、一番確実ではありますね。

　　　　　　　 　　　        9 9　　
┌─┐┬┌──┬┐ ／／\^^ ( e ); {Do the more with the less -- B. Fuller}
├─┤│└─┐│ ／　877m\_<   >_ <URL:http://www.delegate.org/delegate/>
┴　└┴──┘┴──────────────────────────────
佐藤豊＠情報技術研究部門.産業技術総合研究所(独立行政法人)

*** /Users/yutaka/dist/src/delegate9.8.2-pre3/src/http.c	Thu Nov 29 00:58:53 2007
--- src/http.c	Fri Nov 30 15:36:12 2007
***************
*** 10150,10151 ****
--- 10150,10152 ----
  	int nka;
+ 	int ateCookie = 0;
  	int timeout,timeout1,timeout2,rtimeout,ptimeout,nready,till;
***************
*** 10389,10390 ****
--- 10390,10394 ----
  		service_http2(Conn,ftc);
+ 		if( ServKeepAlive && findFieldValue(REQ_FIELDS,"Cookie") ){
+ 			ateCookie++;
+ 		}
  		if( isWindows() )
***************
*** 10496,10497 ****
--- 10500,10504 ----
  	setFTOCL(FTOCL);
+ 	if( ateCookie && clearServ(Conn) ){
+ 		sv1log("---- cleaerServ() with Cookie*%d\n",ateCookie);
+ 	}
  }