0

opensslのSSL_read()呼び出しのマニュアルページには次のように記載されています。

SSL_read() は、SSL/TLS レコードに基づいて機能します。データはレコード単位で受信されます (SSLv3/TLSv1 の最大レコード サイズは 16kB)。レコードが完全に受信された場合にのみ、処理できます (復号化と整合性のチェック)。したがって、SSL_read() の最後の呼び出しで取得されなかったデータは、SSL 層内で引き続きバッファリングでき、SSL_read() への次の呼び出しで取得されます。

とすれば：

  • 単一の送信メッセージの HTTP ヘッダーは、常に一度に送信できます
  • 単一の SSL/TLS レコードは明らかに 16KB のデータを保持できます。これは、すべてのユーザー (または少なくとも非ひねくれた HTTP 要求) にとって十分なはずです。

ブラウザーがヘッダーを複数の SSL レコードに分割する理由はほとんどありませんよね? それとも、レイテンシに関して非常に積極的なブラウザが存在するため、この種の小さなペイロードでさえ複数のレコードに分割しますか?

1 回の成功した呼び出しによって満たされた 1 つの読み取りバッファーから HTTP ヘッダーのセット全体を解析できると便利なので、これを求めていSSL_read()ます。それが奇数のリクエストを拒否することを意味する場合 (たとえば、すべてのリクエストの 0.0000X% のみの場合)、それは私にとって価値があるかもしれません。

編集: Alexei Levenkovは、Cookie が非常に長くなる可能性があるという有効な点を指摘しました。しかし、この特定のサーバーによって Cookie が決して設定されない、または期待されないというシナリオを考えてみましょう。

edit2 : この質問は少し時期尚早でした。その間、私はクライアントの状態ごとに効率的に格納するコードを書き、解析中に任意の数の SSL レコードを受け入れることができ、重大なパフォーマンスの低下を招くことはありませんでした。そうする前に、私は近道をすることができるかどうか疑問に思っていました. 失点。

4

4 に答える 4

1

いいえ、Cookie だけで 16K をはるかに超える可能性があります。

RFC2109およびCookie 制限の IE 実装によると、ドメインあたりの Cookie サイズの推奨最小制限は 80K です。

RFC 2109 セクション「6.3 実装の制限」:

  • Cookie ごとに少なくとも 4096 バイト (Set-Cookie ヘッダーの構文記述で Cookie の非終端記号を構成する文字のサイズによって測定)

  • 一意のホストまたはドメイン名ごとに少なくとも 20 個の Cookie

于 2013-06-08T01:17:45.357 に答える
1

その仮定をすることはできません。同様recv()に、要求されたよりも少ないバイト数を返すことができSSL_read()ます。インバウンド データをバッファリングし、必要なレコード数を読み取ってから、受信する予定のデータをすべて受信し終わったときにのみバッファリングされたデータを処理するのは、ユーザーの責任です。<CRLF><CRLF>ヘッダーの末尾にあるシーケンスを受け取るまで、HTTP ヘッダーを処理しないでください。

于 2013-06-08T01:23:03.783 に答える
1

おそらく、より慎重な声明は、仮定が間違っているということですが、平均的なシナリオでは、ほとんどの場合、希望する動作が得られると予想されます。確かな答えはわかりませんが、調べるために実験を行うことができます。

私はハッカーがルールを無視し、学習、楽しみ、利益のためにプロトコルを悪用することに賛成ですが、それ以外の場合は、単一の SSL レコードの読み取りに制限することに何のメリットもないと思います。詳しく説明していただければ、私は興味があります。

于 2013-06-08T10:07:54.357 に答える