tanum****@nttda*****
tanum****@nttda*****
2011年 12月 14日 (水) 18:23:11 JST
田沼です。 コードはよくわかりませんが、アルゴリズムに少しつっこみを・・・。 >5. 4でゲットできなければ、session_endpoint_mapにSSLIDとendpointを登録して、3にいく。 ↑ 登録する endpoint がこの時点で決まっていないと思います。 >5. 4でゲットできなければ、3にいく。 でいいのではないでしょうか。 そもそも、ClientHello の時は map を参照するだけで更新の必要はないという 認識です。自信ないですが・・・。 >9. ぶっこ抜いたSSLIDが、upthreadで捕まえたClientHelloのSSLIDを同じかチェックする。 >10. 同じならば、12にいく。 >11. 違ったら、session_endpoint_mapの該当endpointのセッションIDのほうを更新する。 > あ、単に追加するだけでもいいか。できれば、古いのを消す。 ↑ これでもいいし、比較すらせずに map 更新でもいいかも。 どっちが早いかはよくわかりません。 11の古いのって ClientHello 内の SSLID のことですよね。 downthread でも ClientHello の SSLID ってわかるんでしたっけ？ >12. クライアントにぶんなげる。 あとはSSLの再ネゴシエーションが同じリアルサーバで うまくいくのかが心配なのですが、 一度 endpoint が確定してしまえば途中で別の endpoint に 変わることは無いので大丈夫、と思っていいですよね？ -----Original Message----- From: ultra****@lists***** [mailto:ultra****@lists*****] On Behalf Of 中野 宏朗 Sent: Wednesday, December 14, 2011 5:47 PM To: ultra****@lists*****; ultra****@lists***** Subject: [Ultramonkey-l7-devel 467] Re: SSLID問題のチケット発行依頼 中野＠幕張%別仕事でコードからどんどん離れる・・・です。 sslidのパーシステント部分をごっそり無効にしたコードで 検証しようとしていて、よくわからないコード見つけました。 protocol_module_sslid.cpp protocol_module_sslid::handle_realserver_select( の 1517 if (realserver_selected(threaddata->selected_realserver)) { の中身。 4143 boost::asio::ip::tcp::endpoint temp_endpoint; 4144 if (temp_endpoint == rs_endpoint) { ・・・これ、なにを比較しようとしたいの？temp_endpointの存在意義って・・・ threaddata->selected_realserverって、どこで入るんだろう・・・ あと、 1543 (get_ssl_session_id(threaddata->data_buffer.data() + threaddata->data_begain_offset, 1544 threaddata->data_size, session_id) == -1)) { の中身って、リターンコードは0と1と-1返してるけど、-1しか使ってないよね。 まあ、 1572 if (session_id.empty()) { で見てるんだろうけど。でもC++なら暗黙に初期化されるとはいえ、session_id初期化してないし。 コード見て何がしたいのかわかんなかったので、外部設計書とか確認したけど、 アルゴリズムがRFCベースとは違ってる感じ。 UltraMonkey使わないときのSSL IDのプロトコルをまずはベースにして、 そこにUM-L7入れたときにどういう手順にするかしないと。 もともとのSSL IDは、RFC2246の7.3節あたり。 http://www5b.biglobe.ne.jp/~type-aya/rfc/rfc2246j.txt そこにUM-L7を噛ませた場合のアルゴリズムを、もう一度考えてみました。 ====== 1. ClientHelloのパケットをupthreadで捕まえる。 2. SSLIDが付与されているかどうか、見る。 3. 付与されていなければ、スケジュールモジュールによりendpointを決めて、6にいく。 4. 付与されていれば、session_endpoint_mapに問い合わせて、endpointをゲットし、6にいく。 5. 4でゲットできなければ、session_endpoint_mapにSSLIDとendpointを登録して、3にいく。 6. リアルサーバにぶんなげる。 7. ServerHelloのパケットをdownスレッドで捕まえる。 8. 捕まえたパケットのSSLIDをぶっこ抜く。 9. ぶっこ抜いたSSLIDが、upthreadで捕まえたClientHelloのSSLIDを同じかチェックする。 10. 同じならば、12にいく。 11. 違ったら、session_endpoint_mapの該当endpointのセッションIDのほうを更新する。 あ、単に追加するだけでもいいか。できれば、古いのを消す。 12. クライアントにぶんなげる。 ====== 要は、SSL IDが入っていたら、まずはsession_endpoint_mapを見なければ始まらないはず。 realserver_selectedって何者なんだ。sslidやmap見る前に格納されるデータに見えないんだけど。 あと、RFC2246によると、SSLIDがリアルサーバ側でヒットしなければ、Server Helloで 異なるIDを付与して送ってくるはず。 そしたら、downthreadでmapを更新しなければいけないはず。その処理ないよね？ まずは上記アルゴリズム案で直してみようと思いますが、どうでしょう。 速度が出るかどうかは未保障ｗ つか、session_endpoint_mapをスレッドまたがりのデータとして持って、 mutex lock掛けながらスレッドが参照しなきゃいけないから、かなり 遅くなると思う。セッションレスより遅くなるんじゃないかな。 session_endpoint_mapをスレッド固有データとして持てるデータ構造というか 仕組みを考案できたら、速くなるだろうけど。 あと問題は、自分がコードいじれるまとまった時間がないってこと・・・ (2011/11/11 17:20), 中野 宏朗 wrote: > 中野@幕張です。 > > SSLIDモジュールで通信した時、性能が極端に悪いという事象について、 > どなたかチケットを発行してもらえないでしょうか。 > # 自分でやってもいいですが(出来るのかな？)、自分は上記以上の経緯は > # 知らないので・・・ > > で、自分がとりあえず担当しますので、hiroakinakanoにアサイン > してもらえればと思います。 > > ちなみに、まだ糸口はつかめていませんorz > > # sslidのhandler系にrdtsc仕掛けてみたんですが、時間かかっているところは > # 見つからなかったので、ハンドラ内で時間かかっているわけではなさそう。 > # となると、ハンドラを起動するのに時間かかっている？それだと他の > # プロトコルでも再現しそうなきもするし・・・ > > # 他に固有なところといえば、ssl_protocol_module_base？といっても、 > # 特定のオフセットのデータをみてるだけだよな〜・・・ > # ひょっとして、protocolモジュールをVirtualServiceからロードし、 > # sessionスレッドで呼び出すから、パケットデータであるthreaddataの > # 参照で、CPU間でメインメモリ介したコピーが走ってる？でもそんなに > # 影響するかなぁ・・・ > ## 脳みそ沸騰中 > -- 中野 宏朗 (NAKANO Hiroaki) NTTコムウェア 品質生産性技術本部 技術SE部 基盤ソフトSE・OSS部門 OSS適用推進担当 Tel: 043-211-2452 (Ext: 特番+26-8341), Fax: 043-211-5086 Zip/Address: 261-0023 千葉県千葉市美浜区中瀬1-6 NTT幕張ビル21F-En _______________________________________________ Ultramonkey-l7-devel mailing list Ultra****@lists***** http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-devel
UltraMonkey-L7
Fork