Web RTCを使用してUDPパケットを送信するにはどうすればよいですか?
3 に答える
WebRTCを使用してUDPパケットを直接送信することはできません。これは、ブラウザに必要な基本的なセキュリティ制約に違反します。
SRTPをICE対応ホストに送信できます。それはおそらくあなたが探しているものではありません。
ブラウザが任意のUDPパケットの送信を許可した場合、悪意のあるアプリケーションが任意のホストにパケットを送信する可能性があります。
これはそれほど悪くないように聞こえるかもしれませんが、結局のところ、インターネット上のホストはその権利に対処できる必要がありますか?問題は、一部のブラウザがネットワークへのアクセスが制限されている保護された環境にあることです。これらのネットワーク内では、一部のホストは、パブリックインターネット上のホストよりもはるかに保護されていません。ネットワークへのアクセスが制御されているので、これは問題ありません。
ブラウザが任意のパケットを送信できる場合、その環境のブラウザのユーザーは、これらの保護が不十分なホストの1つに特別に細工されたパケットを送信するように確信できます。おそらく、その結果、ネットワークオペレーターはブラウザーを禁止することになります。これは、ブラウザーメーカーが非常に避けたいことです。
WebRTCは、特定の条件下でのみ特定のタイプのUDPパケットを送信します。話したいホストがICEを理解していて、 SRTPまたはSCTP over DTLSを使用してRTPを使用できる場合(メチンクではない可能性があります)。次に、ブラウザに何かを送信させることができます。
sipml5を確認する必要があります。http ://code.google.com/p/sipml5/コードを取得し、次のフォルダを調べてください:sipml5 / src / tinySIP / src /transports
@MartinThomsonは問題を非常によく説明しています。彼の投稿からモチベーションを引き出すことで、この投稿は一部のオタクや初心者にガイダンスを提供する可能性があります。
WebRtcはReal-time
、2つ以上のピア間の通信でBi-directional
あると言われています。「セキュアSecure
」という言葉にもっと焦点を当てます。
エンタープライズネットワークのセキュリティポリシーでは、通常、着信する一方的なトラフィックのフィルタリング、特定のプロトコルのブロック、およびアプリケーションレベルのフィルタリングとスキャンの実行が必要です。spam
malware
intellectual property
ここで、2つの新しい質問が思い浮かびます。
- TCPトラバーサルが問題にならないのはなぜですか?
- UDPトラバーサルに問題があるのはなぜですか?
TCPトラバーサルが問題にならないのはなぜですか?
TCPは2つのことを明確に示しています。
- 流れの始まり
(SYN)
と、 - フローの終わり
(FIN or RST)
。
これは、ファイアウォールopen
とclose
ピンホールによって使用されます。例外的に、長期間トラフィックを受信していないTCP接続でも、ピンホールが閉じられます(ネットワークトポロジの変更または両方のTCPピアの障害に対応するため)。ファイアウォールは、プロトコル検証も実行して、次の問題をクリーンアップします。
- ウィンドウ外のTCPセグメントと、
- 重複するTCPセグメント
これにより、ファイアウォールはネットワークを保護し、いくつかの攻撃ベクトル(リプレイ攻撃、ホストIPアドレスプロービング、DDOS攻撃など)からホストを保護できます。
UDPトラバーサルに問題があるのはなぜですか?
UDPフローの場合、5タプルの最初の発信パケットは、ファイアウォールによってstart-of-session
インジケーターとして使用されます。ただし、UDPにはend-of-session
インジケーターがないため、ファイアウォールはtwo ways
ピンホールを閉じるだけで済みます。
interior host
が数秒間トラフィックを送信しなかった後、またはピンホールをタイムアウトする- 内部ホストは致命的なを生成し
ICMP error
ます。
セッションが停止していることを確実に判断する方法がないため、ファイアウォールの役割ははるかに困難です。アプリケーションレベルゲートウェイ(ALG)
を実装し、UDPに加えて上位レベルのコードによって課せられるセマンティクスを認識できます。
また、一連の有名なアプリケーションサーバーに依存して、セッションの開始時と終了時にセッションを通知することもできますが、アプリケーションサーバーは、使用されているネットワークとは独立してホストされるため、多くの課題があります。
を使用する
ALG
と、ファイアウォールはコールがいつ終了するかを判断し、メディアセッション用に作成された動的マッピングを閉じることができます。ただし、問題は、ブラウザで実行されているWebRTCアプリケーションとTLSを使用している可能性のあるWebサーバー間のセッションシグナリングです。この場合、ALGはシグナリングにアクセスできなくなります。
結論:
したがって、アプリケーションレベルゲートウェイでは、Webrtcはとの組み合わせを利用しSDP
ますICE
。WebRtcは基本的に次UDP
のようにラップします
- オーディオ、ビデオチャネルの場合、WebRtcは、、overの組み合わせを使用
RTP
します。RTCP
SRTP
DTLS
- データチャネルの場合、webrtcはRFC2960
(SCTP)
で定義されているStreamControlTransmissionProtocolを使用します。
TCP
SCTPは、またはの代替として意図されたトランスポート層プロトコルですUDP
。WebRtcの場合、DTLS接続を介して実行されるアプリケーション層プロトコルとして使用します。
STUN
これらのプロトコルには、、などの新しいプロトコルも付属していますTURN
。WebRtcの基本的な実装については、以下に従ってください。
この説明が一部のオタクに役立つことを願っています。ありがとう