ゼロ構成HTTPリレーサーバー
データベースのリモート管理に使用できるWebサーバー（ServiceStack）が組み込まれたデスクトップ製品（C＃）を開発しています。これを内部サーバーと呼びます。多くのユーザーはネットワークの外部で内部サーバーにアクセスしたいと考えていますが、ファイアウォールとポート転送を構成するための私の側のサポート負担は高すぎます。また、動的IPアドレスも問題になる可能性があります。
私は、ユーザーが内部サービスで何も構成しなくても内部サーバーに要求を中継できる外部サーバーIホストに接続できるゼロ構成サービスを作成する方法を考え出そうとしています。ユーザーの観点からは「正しく機能する」はずです。
これは、ユーザーがファイアウォールを構成しなくても、ログインしてコンピュータに「接続」できるTeamViewer/AnyDesk/etcの動作に似ています。
以下のシーケンス図に基づいて、概念実証を作成しました。動作しますが、直接接続に対するパフォーマンスは非常に遅くなります。
これをよりよく達成するにはどうすればよいでしょうか。また、この問題をすぐに解決できる解決策はありますか？
次の図に示されている主な課題は、パブリックリレーサーバーが内部サーバーへの直接接続を開始してはならないことです。
改善のための考えられる考え：
- 可能であれば、リレーと内部サーバーの間でHTTP/2を使用します（理想的にはどこでも）。これにより、内部サーバーからのハングしたリクエストをポーリングしたり、新しい外部リクエストを待機したりする代わりに、HTTP/2サーバープッシュ機能を利用できるようになります。また、その他の潜在的なパフォーマンスの向上も多数提供されます。
- クライアントシステムとリレー/内部サーバー間の通信を非同期にします。そのため、クライアントは定期的なリクエストをリレー/内部サーバーに送信し、受け入れられたという応答を受け取り、サーバーからの2次応答を待ちます（HTTP/2サーバープッシュ機能またはその他のプッシュ通知メカニズムを介して） 。これにより、リクエストが実際に処理されていることをユーザーにフィードバックすることができます。これにより、実際にパフォーマンスが向上しなくても、処理が速くなります。
- 内部サーバーに要求について通知するときに、リレーから内部サーバーに要求をプリエンプティブに送信します。これにより、リレーと内部サーバー間の完全なラウンドトリップが排除され、処理速度が大幅に向上します。
- 上記の点を実装する場合は、リレーと内部サーバーの間で前述したのと同じ非同期通信モデルを使用します。
- [〜＃〜] ice [〜＃〜] （または同様のもの）を使用して、可能な限りクライアントと内部サーバー間の直接接続を設定する可能性を検討してください。ここでの最大のパフォーマンスのボトルネックは、実際にはリレーサーバー自体です。接続のセットアップ中以外に、一部（またはすべて）のユーザーがリレーサーバーと通信する必要がないように設定できる場合は、パフォーマンスが大幅に向上するはずです。 。