理解しようとしているのですが、Netty SSL モードが奇妙な方法で動作するのはなぜですか? また、問題は次のとおりです.SSLクライアント（httpsブラウザ、sslを使用するJavaクライアント、および任意のsslクライアントアプリケーション）がNettyサーバーに接続すると、使用されているプロトコルを正しく認識できる完全なメッセージを開始しますが、チャネルは接続されたままで、後続のメッセージは奇妙な構造を持ち、非 SSL モードでは同じように発生していません。https ブラウザーがサーバーに接続するときの messageReceived メソッドの例:
PortUnificationServerHandler を使用してプロトコルを切り替えました.. (nettys http ハンドラーを使用せずに、これは単なる例です。自分のプロトコルにも ssl モードを使用しているためです)
- 最初のメッセージは問題ありません。GET または POST で始まる完全なヘッダーが表示されます
- 私は応答を送信するよりも...
- 2 番目のメッセージの長さは 1 バイトのみで、「G」または「P」のみが含まれます。
- 3 番目のメッセージは、ET または OST で始まる残りのメッセージと、残りの http ヘッダーと本文です。
- ここで再び私の応答に従います...
- 4 番目のメッセージも 1 バイトの長さで、1 バイトしか含まれていません。
- 5 番目のメッセージは残りの部分です...そして、この方法でゲームはさらに進みます..
ここでは重要ではありません。どのサブ プロトコルが使用されているかは重要ではありません。http かその他のいずれかです。最初のメッセージの後、最初に 1 バイトを取得し、2 番目のメッセージで残りの要求を取得します。
プロキシの技術を構築し、ssl データを取得して他のリスナーにエンコードせずに送信したかったのですが、完全なデータ要求を待たずに直接実行すると、ターゲット リスナー (例として http サーバー) はそのようなデータを処理できません。ターゲットは最初にのみ 1 バイトを取得し (次のメッセージに残りが含まれている場合でも)、チャネルはすぐに閉じられ、要求は放棄されます..わかりました。それらのメッセージに参加するよりも、応答よりも、それは正常に機能しますが、1バイトが実際には最後のメッセージバイトである場合があるため、正しいアプローチではない場合があり、キャッシュして次のメッセージを誤って待機すると、永遠に待つことができます。 https ブラウザはこの時点でなんらかの応答を期待しており、それ以上データを送信しないためです..
問題は、この問題を SSL で解決できるかどうかです。この動作に影響を与える特別な設定があるのでしょうか? 最初のバイトと残りのバイトではなく、メッセージを一度に完全に結合したい..新しいNettyバージョンでは、PortUnificationServerHandlerを使用して同じ動作をしていることを確認できますか(ただし、netty httpハンドラーなしで、独自のハンドラーを試してください.)この動作はOKなので、私は信じていません..