3

ということで、NATトラバーサルをしている最中でした。

シナリオは次のとおりです。私は 2 台の Android 携帯を持っており、HTTP サーバーを使用してそれら (ソケット) を接続したいと考えています (両方のデバイスが NAT の背後にあります)。

これまでのところ、両方のクライアントが HTTP サーバーに接続し、HTTP サーバーが IP アドレスとポートを記録し、

ただし、Java HttpDefaultClient() を使用しているため、クライアントからサーバーにリクエストを送信するたびにポートが変更されるため、少し問題があります。単純な問題のように思えますが、Socket() を使用して、サーバーへの有効な TCP 接続を実際に維持してみましょう。

public Socket(InetAddress アドレス、int ポート、InetAddress localAddr、int localPort) が IOException をスローする

このクラスを使用して、localPort をランダムに配置します。これを覚えておきます。今度はすべてをやり直しますが、今回はポートが変更されないようです。

対戦相手の IP とポート (彼も NAT の背後にいる) を取得した後、理論的には、SERVER 接続をドロップして、実際に clientServer をホストするために既に使用したものと同じ localPort を使用できますか?

1) HTTP サーバーソケットをドロップすると、NAT はそれを理解し、ポートマッピングを削除しますか? (それは悪いことです) 2) 対称コーン nat を実際に渡す方法は? 3) STUN ライブラリは何らかの方法で動作しますか?

4

3 に答える 3

0

NAT がすべて同じように機能するわけではありませんが、いくつかのことを当てにすることができます: 1) クライアントがポート X にあると認識した場合、NAT はそれを別のポートに変換します。発信パケット。

STUN は、サーバーの助けを借りて、実際の送信ポートが何であるかを推測し、アドレスとポートを他のクライアントに渡します。それはひどく信頼できるものではありません。TURN は、すべてをサーバー経由でルーティングするだけです。その方が信頼性が高くなりますが、サーバーの CPU と帯域幅のコストが発生します。

既存のコードを使用して NAT トラバーサルを行うことができれば、多くの手間を省くことができます。それ以外の場合は、ソケットを介して TURN などを実行するか、Urban Airship などを使用します。バイナリ SMS も使用しましたが、それは特殊な場合のためのものでした。

于 2012-05-01T17:10:13.140 に答える
0

Nats に関していくつかの問題が発生していると思います。私は実際にこれをしばらく前に機能させました（サードパーティサーバー（私のもの）とパブリックSTUNサーバーを利用してピアツーピアアンドロイド接続を作成しました.

RFC5389 - Nat traversal It's complexを読むことを強くお勧めします。また、 JStun ライブラリのようなものを使用するか、私が行ったように独自のものを実装することをお勧めします。

このクラスを使用して、localPort をランダムに配置します。これを覚えておきます。今度はすべてをやり直しますが、今回はポートが変更されないようです。

私の推測では、nat の背後にあるため、要求した内部ポートが別の外部ポートにマップされました。

対戦相手の IP とポート (彼も NAT の背後にいる) を取得した後、理論的には、SERVER 接続をドロップして、実際に clientServer をホストするために既に使用していたものと同じ localPort を使用できますか?

まだ、ほとんどの nat は、クライアントが接続したポート 2 だけでなく、接続先の IP アドレスも記録するため、他の IP からのトラフィックをブロックします。たとえば、Phone1 は IP-a 上にあり、ポート b 上の ip-a からサーバーに接続します。nat はポート b をポート c に変換します。サーバーの観点からは、電話機はポート c の IP-a にあります。この情報を phone2 に中継します。nat は、phone1 がポート b から phone2 にデータを送信するまで、phone2 からのすべての通信をブロックします。

1) HTTP サーバー ソケットをドロップすると、NAT はそれを理解し、ポート マッピングを削除しますか? (それは悪いことです) 2)

私が経験から学んだことは、ポートがマップされることを除いて、nats ポート マッピングの動作から何も期待しないことです。これには多くの更新が必要です。しかし、一般的にいいえ。

于 2012-06-18T15:27:10.290 に答える
0

最近のほとんどの(すべてではない) NATでは、一定の一貫性と予測可能なポート マッピング動作を想定できます。(つまり、異なるサーバー接続に同じローカル ポートを使用すると、NAT 上の同じローカル ポートにマップされます)。しかし、UDP よりも難しい問題である TCP 経由で NAT トラバーサルを実行したいようです。

根本的な問題は、ほとんどの NAT がファイアウォールとしても機能していることです。リモート ip:port からのインバウンド接続は許可されません。トリックは、両側で同時接続を行うことだと思います。

TCP ホール パンチングの詳細については、http: //en.wikipedia.org/wiki/TCP_hole_punchingを参照してください。

于 2012-05-08T02:29:32.980 に答える