私はSkypeのようなp2pソフトウェアがそのためにUDPホールパンチングを使用していることを知っています。しかし、クライアントの1つが別のクライアント（UDPではなくTCP接続）からファイルをダウンロードする必要があるWebブラウザーである場合はどうなるでしょうか。そのような場合のテクニックはありますか？
クライアントと結婚できる中間のパブリックサーバーを持つことはできますが、これらのクライアント間のすべてのトラフィックがこのサーバーを通過する余裕はありません。パブリックサーバーは、Skypeのように、クライアント間の接続のみを確立できます。それだけです。また、ダウンロードクライアントをWebブラウザにするには、これはTCP（より正確にはHTTP）を介して機能する必要があります。
両方のクライアントは、ルーターなどに何かをセットアップする必要はありません。
これをC/C ++でコーディングする予定ですが、このアイデアが可能かどうか疑問に思っています。
私は以前、P2Pがどのように大まかに機能するかについて、さまざまなプロトコルと対応するオープンソースライブラリに関するいくつかの議論とともに非常に統合された大まかな答えを書きました。ここで読むことができます。
P2Pの信頼性は、最終的には、クライアントコーディングの観点とサービス構成（つまり、シグナリングサーバーとリレー）の両方からP2Pにどれだけ投資したかによって決まります。ファイアウォールをサポートしていなくても、UDPのNATトラバーサルを簡単に行うことができます。たぶんもう少し努力すれば、TCP接続が得られます。そして、「ずっと」行き、最も通過しにくいファイアウォールの背後にあるクライアント用のHTTPSリスナーを持つリレーを持つことができます。
ファイアウォールについてのあなたの質問の答えについて。ファイアウォールの構成方法によって異なります。多くのファイアウォールは、特定のポートへのトラフィックを制限し、一方的な着信接続をブロックするセキュリティを備えた栄光のNATです。その他は非常に制限があり、プロキシ経由でHTTP/HTTPSトラフィックを許可するだけです。
ビデオ会議アプリは、直接接続できない場合、最終的にPCの構成済みプロキシサーバーを介してリモートリレーサーバーのポート443（または80）へのHTTPS接続をエミュレートするようにフォールバックします。（場合によっては、リモートクライアントはポート80またはポート443でリッスンしようとするため、直接接続できます）。
すべてのクライアントがリレーを通過することは、維持するのに費用がかかると考えるのは絶対に正しいです。クライアントが背後にあるファイアウォールのタイプに関係なく、100％の接続を目標とする場合は、何らかのリレーソリューションが存在する必要があります。リレーソリューションをサポートしていない場合は、直接接続を確実に機能させるために多額の投資を行うことができ、ブロックされるクライアントの割合はごくわずかです。
お役に立てれば。
WebRTCの一部であるPeerConnectionは、最新のブラウザーでこれを解決します。
内部的には、NATホールパンチングのRFCであるICEを使用しています。
古いブラウザの場合、FlashでP2Pサポートを使用することができます。