STUN サーバーが同じトランザクション ID を持つ 2 つの異なる STUN エージェントから要求を受信した場合、どのように動作する必要がありますか?
3 に答える
1
これは発生しないはずですが、サーバーが 5 タプル (クライアントの IP アドレスとポート、サーバーの IP アドレスとポート、およびトランスポート プロトコル (現在は UDP、TCP、または TLS のいずれか) の組み合わせ) をチェックする必要がある場合。5 タプルが一致しない場合、サーバーはそれを有効なトランザクションと見なして続行する必要があります。それ以外の場合は、RFC-5766 に従って動作する必要があります。
于 2016-04-18T23:30:54.610 に答える
1
STUN バインディング リクエストからのトランザクション ID は、STUN バインディング レスポンスで単純にエコー バックされます。サーバーは、おそらくロギング以外の目的でこの値を解釈しようとしません。また、重複するリクエストや重複するトランザクション ID を管理または処理しようとすることもありません。2 つの異なるクライアントが同じトランザクション ID を持つバインディング リクエストを送信すると、両方が対応する応答で同じトランザクション ID を取得します。
トランザクション ID は、単にクライアントの利益のためのものです。クライアントがサーバーから、リクエストで使用したものとは異なるトランザクション ID を持つレスポンスを受信した場合、単純にそれを無視する必要があります。そのパケットは、以前の STUN セッションから遅れて到着する可能性があるためです。
重複するトランザクション ID が存在できるのは、クライアントが応答待ちでタイムアウトになり、バインディング要求を再送信するときだけです。RFC 5389 では、セクション 6でこれについて言及しています Resends of the same request reuse the same transaction ID。
于 2016-04-22T07:10:52.780 に答える
0
このような奇妙な状況に対応できるようにソフトウェアを準備する必要はないと思います。トランザクション ID はクライアントによって生成されるランダムな値であり、気絶クライアントでこの種のバグが発生する可能性はほとんどありません。
トランザクション ID は、STUN トランザクションを一意に識別するために使用される 96 ビットの識別子です。要求/応答トランザクションの場合、トランザクション ID は要求に対して STUN クライアントによって選択され、サーバーによって応答でエコーされます。
ランダムでない場合、それは 1 つの偽のクライアント ソフトウェアが原因である可能性が高く、最終的には、開発者がこれを見つけてソフトウェアを修正するまで、そのクライアントに不適切な応答を送信することになります。
于 2016-04-18T14:02:15.510 に答える