私はsslまたはplain httpのいずれかにバインドされるWebサービスを持っています。 Javaクライアントは、サーバーのホストとポートを認識するように構成されています。クライアントが接続すると、私はhttp://host:port/serviceのようなサーバのエンドポイントを構築します。クライアントは、サーバがssl-serverを使用しているかどうかを知っていないので、常に1つのポートにバインドされているので、安全であるかどうかはわかりません。さて、問題は、別のパラメータを導入せずにクライアントにこれを発見させる方法です。プレーンなhttp要求に挑戦して、ある例外でssl（またはその逆）にフォールバックすることはできますか？あるいは、私は明示的に新しい接続パラメータをクライアントに導入する必要がありますか？SSLを正常に検出する方法
サーバー側では、Grizzly's port unificationのような実装を使用できます。これは、同じポート上でHTTPとHTTPSを処理するために使用できます。これは、どちらの場合も、クライアントが最初に話し、HTTP要求またはSSL/TLSクライアントのHelloメッセージを送信するという事実に依存しています。これはサーバー側では非常に便利です（ただし、私は一般的に同じポートで2つのプロトコルを実行することをお勧めします）。 （あなたが尋ねているものである）クライアントの観点からは
、の結果は次のとおりです。
ポート統一を除いて（これはまれなケースです）、過去の試行の結果をキャッシュすることができます。もっと根本的
、セキュリティの観点から、使用すべきプロトコル知ることは、脆弱性を紹介しません：お使いのシステムは、（blindly relying on automatic redirectsと同じように、同様の方法で）攻撃をダウングレードして公開されます。あなたのユーザエージェントがHSTSをサポートしているなら、それを調べる価値があります（ただし、HTTPSで使用するサイトをユーザエージェントが記憶する必要があります）。
いずれにしても、セキュリティが懸念される場合、はで、クライアントはhttps://をいつ使用するかを設定する必要があります。
これは私が後になっているようです。セキュリティは懸念事項です。そうでなければ、まずはSSLがありません。しかし、この特定のケースでは、トラフィックを暗号化するだけで済み、認証は問題ではないので大したことではありません。実際、この場合のクライアントは、実際には同じ種類の別のノードを呼び出すサーバーノードです（クラスター内で何らかの話があります）。新しいパラメータを導入するのを避けるためにちょうどよいショートカットが必要でした。これを行う方法は信頼できるものではないように思えますが、私はポートの統一物で遊んでいきます。興味深いことに、ありがとう！ – Dima
サーバの認証（暗号化前）は、トラフィックをまったく変更できない受動的な攻撃者（盗聴者）を最大限に抱えていることが分かっていない限り、常に問題になります。 – Bruno
そうだね、盗聴者は私の場合は脅威ではない – Dima