From nakano.hiroaki ＠ nttcom.co.jp Wed Dec 14 17:46:44 2011 From: nakano.hiroaki ＠ nttcom.co.jp (=?ISO-2022-JP?B?GyRCQ2ZMbiEhOShPLxsoQg==?=) Date: Wed, 14 Dec 2011 17:46:44 +0900 Subject: [Ultramonkey-l7-develop 762] Re: =?iso-2022-jp?b?W1VsdHJhbW9ua2V5LWw3LWRldmVsIDQ1NF0gU1NMSUQ=?= =?iso-2022-jp?b?GyRCTGRCaiROJUElMSVDJUhILzlUME1NahsoQg==?= In-Reply-To: <4EBCDAD2.2040106@nttcom.co.jp> References: <4EBCDAD2.2040106@nttcom.co.jp> Message-ID: <4EE86274.302@nttcom.co.jp> 中野＠幕張%別仕事でコードからどんどん離れる・・・です。 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 From tanumak ＠ nttdata.co.jp Wed Dec 14 18:23:11 2011 From: tanumak ＠ nttdata.co.jp (tanumak ＠ nttdata.co.jp) Date: Wed, 14 Dec 2011 18:23:11 +0900 Subject: [Ultramonkey-l7-develop 763] Re: =?iso-2022-jp?b?W1VsdHJhbW9ua2V5LWw3LWRldmVsIDQ2N10gUmU6IFNT?= =?iso-2022-jp?b?TElEGyRCTGRCaiROJUElMSVDJUhILzlUME1NahsoQg==?= In-Reply-To: <4EE86274.302@nttcom.co.jp> References: <4EBCDAD2.2040106@nttcom.co.jp> <4EE86274.302@nttcom.co.jp> Message-ID: <54FE23DF07184B4492BB7F23A660CF3B3AECCEAE9F@MBX-MSG-SV07.msg.nttdata.co.jp> 田沼です。 コードはよくわかりませんが、アルゴリズムに少しつっこみを・・・。 >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: ultramonkey-l7-devel-bounces ＠ lists.sourceforge.jp [mailto:ultramonkey-l7-devel-bounces ＠ lists.sourceforge.jp] On Behalf Of 中野　宏朗 Sent: Wednesday, December 14, 2011 5:47 PM To: ultramonkey-l7-develop ＠ lists.sourceforge.jp; ultramonkey-l7-devel ＠ lists.sourceforge.jp 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 Ultramonkey-l7-devel ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-devel