私のオフィスでは問題なく動作するビデオストリーミングアプリケーションを使用していますが、顧客の場所でひどく失敗します。症状は、数秒ごとに、UDPパケットの受信を2秒間停止し、その後ストリームは何も問題がないかのように再開することです。
私は顧客の場所で http://www.pingtest.net/ を実行しましたが、それは素晴らしい結果になりました。ドロップされたパケットがなく、待ち時間が短い。 2つの場所で私が気付いた唯一の違いはping google.ca
彼らの場所でタイムアウトしましたが、私の場所で動作します。
使用しているネットワークが着信UDPパケットをブロックしているかどうかをテストするにはどうすればよいですか?パケットをドロップしているユーザーを特定する方法はありますか?
netcat
を使用してUDP接続の確立を試みることができます。
マシン上[〜#〜] a [〜#〜]コンシューマのネットワーク実行外:
nc -u -l -p 1234 # if using netcat-traditional
nc -u -l 1234 # if using netcat-openbsd (as pointed out by @JamesHaigh)
UDPを使用するようにnetcatに指示する-u
に注意してください。 (また、netcat
にはさまざまなバージョンがあり、-p
パラメータが必要かどうかに注意してください。最も一般的な(?)2つのバリエーションがあり、どちらもDebianに含まれています。)
消費者の場所:nc -u [addr of machine A] 1234
。
いくつかのテキストを送信するか、パイプを使用して両方の場所の間でファイルを送信し、後でdiffを実行してください。
サーバー側で、UPDサーバーを
iperf -s -u
クライアント側で、UDP接続を確認します
iperf -u -c <IP Address of Server>
Mpyの回答のnetcat
コマンドは診断目的で役立ちますが、根本的な問題に対する別のアプローチでその回答を補完しています。
アプリケーションを [〜#〜] sctp [〜#〜] またはTCPにフォールバックすることは価値があるかもしれません。 SCTPやTCPとは異なり、UDPには輻輳制御がなく、ダウンリンクの優先順位付けを非常に困難にするため、ダウンリンクの共有を超えて使用するユーザーからの着信UDPパケットを拒否する方法を探していたため、この質問を実際に見つけましたトラフィック。
SCTPとTCPは輻輳制御があり、QoSとうまく連携しますが、SCTPは、リアルタイムストリーミングアプリケーション用に設計されたTCPよりも優れています。これをTCPとUDPの両方の良い置き換えにします。事実上、SCTPは2つの最も一般的なトランスポートプロトコル。
UDPだけに依存するのではなく、フォールバックがあることは悪い考えではありません。 TCPだけにフォールバックしたとしても、少なくともそれが機能していると言えるでしょう。おそらく最適ではありません。