タグ付けされた質問 「udp」

UDPはUser Datagram Protocolの略です。UDPアプリケーションを使用すると、特別な伝送チャネルまたはデータパスを設定するための事前の通信を必要とせずに、ネットワーク上の他のホストにメッセージ(データグラム)を送信できます。

1
ベンダーのホワイトペーパーによると、5Mppsは問題ありません。私はすでに120kppsで壁にぶつかっています。ボトルネックはどこですか?
HPのQLogic(fka Broadcom)NetXtreme IIアダプターに関するホワイトペーパーには、テスト中の特定のNICが含まれており、最大256バイト/パケットまでのパケットの小さなパケットパフォーマンスは5,000,000パケット/秒を超えると述べています(7ページ)。 単なるUDP受信部分を除くすべての処理を無効にしたアプリでのテストでは、120,000パケット/秒までしか行えません。パケットは12のマルチキャストグループに均等に分散されます。 UDPの送信速度を上げると負荷が徐々に増加し、最大120,000で最大になるコアが1つ(2つのソケットにそれぞれ12コア中)あることに気付きました。しかし、私はそのコアが何をしているのか、そしてその理由を知りません。私のアプリではシングルスレッドのボトルネックではありません。すべてのマルチキャストグループに対してアプリの単一のインスタンスを実行するか、それぞれ1つのマルチキャストグループを処理する12のインスタンスを実行するかは関係ないからです。そのため、ボトルネックは私のレシーバーアプリではありません。 MSIが有効になり(デバイスマネージャーの[種類ごとのリソース]ビューで確認)、NIC設定でRSSも8つのキューで有効になります。では、その1つのコアにしがみついているのは何ですか?すべてのNICオフロード機能は現在オンになっていますが、オフにすることは役に立ちませんでした。 では、ボトルネックはどこにあるのでしょうか? システムの詳細: ProLiant BL460c Gen9 Intel Xeon E5-2670 v3(2 x 12コア) HP FlexFabric 10Gb 2ポート536FLB NIC Windows 2012 R2

6
ネットワーク監視のためにSNMPトラップ(またはNetflow、汎用UDPなど)をルーティング/プロキシするソリューションですか?
非常に大規模なネットワーク(約5000台のネットワークデバイス)にネットワーク監視ソリューションを実装しています。ネットワーク上のすべてのデバイスが単一のボックスにSNMPトラップを送信し(技術的にはこれはおそらくHAペアのボックスになります)、そのボックスにSNMPトラップを実際の処理ボックスに渡すようにします。これにより、トラップを処理する複数のバックエンドボックスを使用し、それらのバックエンドボックス間で負荷を分散できます。 必要な重要な機能の1つは、トラップのソースアドレスに応じて特定のボックスにトラップを転送する機能です。これを処理する最良の方法に関する提案はありますか? 私たちが検討したものの中には: snmptrapdを使用してトラップを受け入れ、カスタム記述されたperlハンドラスクリプトに渡して、トラップを書き換えて適切な処理ボックスに送信します。 Linuxボックスで実行されている何らかの負荷分散ソフトウェアを使用してこれを処理します(UDPを処理する多くの負荷分散プログラムを見つけるのは多少困難です) 負荷分散アプライアンスの使用(F5など) LinuxボックスでIPTablesを使用して、NATでSNMPトラップをルーティングする 現在、トラップを受信するようにIPTablesが設定されたLinuxボックスを使用して最後のソリューションを実装し、テストしています。次に、トラップの送信元アドレスに応じて、パケットが送信されるように宛先nat(DNAT)で書き換えます適切なサーバー。例えば: # Range: 10.0.0.0/19 Site: abc01 Destination: foo01 iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.0.0/19 -j DNAT --to-destination 10.1.2.3 # Range: 10.0.33.0/21 Site: abc01 Destination: foo01 iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.33.0/21 -j DNAT …

3
udp portコマンドラインに接続する方法は?
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け付けていません。 これは私が試したものですが、動作していないようです: [root@ ~]# netstat -a|grep 48772 udp 0 0 *:48772 *:* [root@ ~]# telnet localhost 48772 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host: Connection refused
14 udp 

2
UDPポート上のサーバーへの接続を確認する
HP-UXマシンがUDPを使用して特定のポートでリモートマシン(私は制御できません)と通信できるかどうかを知りたいです。 telnetを試しましたが、UDPをサポートしているようには見えません。netcatを使用しますが、バンドルが見つかりませんでした。このマシンは生産中ですので、コンパイルやインストールに煩わされたくありません...(nmap、netcat from source ...) これを行う簡単な方法はありますか?
14 telnet  udp  hp-ux 

4
tcpdumpはudpのパフォーマンスを向上させます
一連の負荷テストを実行して、次のセットアップのパフォーマンスを判断しています。 Node.js test suite (client) --> StatsD (server) --> Graphite (server) つまり、node.jsテストスイートは、x秒ごとに一定量のメトリックを別のサーバーにあるStatsDインスタンスに送信します。次に、StatsDは、メトリックを毎秒同じサーバーにあるGraphiteインスタンスにフラッシュします。次に、テストスイートによって実際に送信されたメトリックの数と、グラファイトによって受信されたメトリックの数を調べて、テストスイートとグラファイトの間のパケット損失を判断します。 しかし、20〜50%の範囲の非常に大きなパケットドロップ率(UDPプロトコルで送信されていることに注意してください)が得られることがあることに気付きました。そのため、これらのパケットがドロップされる場所を調べ始めたのは、StatsDのパフォーマンスの問題の可能性があるからです。そこで、このドロップが発生した場所を追跡するために、システムのすべての部分でメトリックの記録を開始しました。そして、これは物事が奇妙になる場所です。 私が使用していtcpdumpのを、私は、テストの実行が行われた後、検査キャプチャファイルを作成します。しかし、tcpdumpを実行してテストを実行すると、パケット損失はほとんどありません。tcpdumpがテストのパフォーマンスを何らかの形で向上させているように見えますが、これがなぜ、どのように行われるのかわかりません。次のコマンドを実行して、サーバーとクライアントの両方でtcpdumpメッセージを記録しています。 tcpdump -i any -n port 8125 -w test.cap 特定のテストケースでは、40000メトリック/秒を送信しています。tcpdumpの実行中のテストでは約4%のパケット損失がありますが、テストなしでは約20%のパケット損失があります。 両方のシステムは、次のセットアップでXen VMとして実行されています。 Intel Xeon E5-2630 v2 @ 2.60GHz 2GB RAM Ubuntu 14.04 x86_64 潜在的な原因についてすでに確認したこと: UDPバッファーの受信/送信サイズを増やします。 テストに影響するCPU負荷。(クライアント側とサーバー側の両方で最大負荷40〜50%) 「any」の代わりに特定のインターフェイスでtcpdumpを実行します。 「-p」を指定してtcpdumpを実行し、混合モードを無効にします。 サーバーでのみtcpdumpを実行します。これにより、20%のパケット損失が発生し、テストには影響がないようです。 クライアントでのみtcpdumpを実行します。これにより、パフォーマンスが向上しました。 netdev_max_backlogおよびnetdev_budgetを2 ^ 32-1に増やします。これは違いはありませんでした。 すべてのNICで無差別モードの可能な設定をすべて試しました(サーバーのオンとクライアントのオフ、サーバーのオフとクライアントのオン、両方のオン、両方のオフ)。これは違いはありませんでした。

2
ファイアウォールルールを半分に削減-tcpおよびudpに1つのiptablesルール
私のファイアウォールには、次のようなiptablesルールがいくつかあります。 iptables -A zone_lan_forward -p tcp -d 1.2.3.0/24 -j ACCEPT iptables -A zone_lan_forward -p udp -d 1.2.3.0/24 -j ACCEPT すべてのアドレスに対して、tcp用とudp用の2つのルールを設定するためのショートカットはありますか?私はこのようなことをすることができます: iptables -A zone_lan_forward -p tcp,udp -d 1.2.3.0/24 -j ACCEPT
12 iptables  firewall  tcp  udp 

2
300Mbit(14%)での極端なUDPパケット損失、ただし再送信なしのTCP> 800Mbit
iperf3クライアントとして使用するLinuxボックスがあり、2台の同じ装備のWindows 2012 R2サーバーボックスとBroadcom BCM5721、1Gbアダプターをテストしています(2つのポート、ただしテストに使用したのは1つだけです)。すべてのマシンは、単一の1Gbスイッチを介して接続されます。 300MbitなどでのUDPのテスト iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192 送信されたすべてのパケットの14%が失われます(まったく同じハードウェアを備えた他のサーバーボックスの場合、古いNICドライバーの場合、損失は約2%です)が、それほど深刻ではありませんが、50Mbitでも損失が発生します。同等の設定を使用したTCPパフォーマンス: iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192 報告された再送信なしで800Mbitの北の伝送速度をもたらします。 サーバーは常に次のオプションを使用して起動されます。 iperf3 -sB192.168.30.161 誰のせいですか? Linuxクライアントボックス(ハードウェア?ドライバー?設定?)? 編集: Windowsサーバーボックス間でテストを実行したところ、300MbitのUDPパケット損失はさらに大きく、22%でした Windowsサーバーボックス(ハードウェア?ドライバー?設定?)? すべてのテストマシンを接続する(単一の)スイッチですか? ケーブル? 編集: 今、私は別の方向を試してみました:Windows-> Linux。結果:パケット損失は常に0ですが、スループットは約で最大になります 840Mbit -l8192、つまりフラグメント化されたIPパケット 250Mbit for -l1472、断片化されていないIPパケット フロー制御はスループットを制限し、パケット損失を防ぐと思います。特に後者の、断片化されていない数値はTCPスループットに近いところにありません(断片化されていないTCPは断片化されたTCPと同様の数値をもたらします)が、パケット損失の点でLinux-> Windowsをはるかに上回る改善です。 そして、どうやって見つけるのですか? サーバーのドライバー設定に関する通常のアドバイスに従ってパフォーマンスを最大化し、有効化/無効化/最大化/最小化/変更を試みました 割り込みモデレーション フロー制御 受信バッファー RSS ウェイクオンLAN すべてのオフロード機能が有効になっています。 編集私も有効/無効にしようとしました イーサネット@ワイヤスピード …

2
moshのようなポート転送
これはLinux上にあり、Linuxサーバーに接続します。 私はmoshが大好きですが、ポートフォワーディングをサポートしていません。また、もう1年が経ち、まだ実現していないので、しばらくはサポートしないでしょう。 sshを介したポートフォワーディングは優れていますが、私のラップトップは1日に数回ネットワーク間を移動するため、sshセッションは停止し、ポート転送も同様に停止します。 ハングしたsshを検出して再接続するためにスクリプト/ハックしてポートを戻すことができますが、これを行う前に、ソースIPが1日に数回変更されたときに長期にわたるポート転送を行う別の方法があります(異なるネットワークに行くため) )? UDPを介したsshでうまくいくと考えていますが、もちろんsshはTCPを介しています。
11 port  forwarding  udp 

3
TCPおよびUDPの送信元ポートは1024を超えてランダムである必要があるというドキュメントはどこにありますか?
ソースポートがランダムで、1024〜65535の範囲にあることが文書化されている場所を見つけるのに苦労しています。 これはどのRFCで文書化されていますか? 編集: 特権ポートの最初のリファレンスはRFC2623 にあります。これはTCP / IPの実装により依存しており、事実上の標準であるようです。 IANAはポート番号を割り当てています(RFC1700)
11 tcpip  udp  rfc 

6
UDPのMTUは65535ですが、イーサネットでは1500バイトを超えるフレームサイズは許可されていません
私は100 Mbpsの高速イーサネットを使用しています。そのフレームサイズは1500バイト未満です(私の教科書によると、ペイロード用に1472バイトです)。その中で、メッセージサイズ65507バイトのUDPパケットを送受信できました。つまり、パケットサイズは65507 + 20(IPヘッダー)+ 8(UDPヘッダー)= 65535でした。 フレームのペイロードサイズ自体が最大1472バイト(私の教科書によると)である場合、IPのパケットサイズを65535のサイズよりも大きくするにはどうすればよいですか。 私は送信者コードを次のように使用しました char buffer[100000]; for (int i = 1; i < 100000; i++) { int len = send (socket_id, buffer, i); printf("%d\n", len); } 受信者コードとして while (len = recv (socket_id, buffer, 100000)) { printf("%d\n". len); } 私はそれを観察しsend returns -1にi > 65507し、recv印刷物やのパケットを受信しますmaximum of length 65507。

3
Windows Server 2012-RDP over UDPが機能しない
Windows Server 2012(R2ではない)マシンがあり、RDセッションホストとRDゲートウェイがインストールされたHyper-V仮想化内でホストされています。デスクトップGISアプリケーションを実行するために使用されます。 WAN経由のパフォーマンスは非常に低くなっています。パフォーマンスを向上させるためにUDPポートをNATに追加しましたが、UDP接続はまだ使用されていません。 LANテスト環境(NAT /ファイアウォールの設定ミスを避けるため)で、Win10マシンから接続しています。接続情報バーには「優れた品質」が表示されますが、UDPについては何も触れられていません。逆接続の場合(Windows Server => Windows 10)、接続情報バーにはUDPが有効になっていると表示されます。 WindowsサーバーにインストールされているWindowsファイアウォールを完全にオフにしました。UDPトランスポートがRDゲートウェイで有効になっていることを再確認しました。ゲートウェイ(443 + 3391)または直接(3389 + 3389)を使用して接続しても違いはありません。マシン全体を2回再起動し、最初の3つのgoogle結果ページのすべてのリンクをスクロールしました。 何がいけないのか考えていますか?

3
DNSサーバーの負荷分散:UDP / TCP
データセンターで負荷分散インフラストラクチャを再構築するように依頼されました。 元の要求は、FTPサーバーの負荷を分散することでした。現在のロードバランサー(Piranha / LVS)を使用してそれを実行しようとしましたが、起動して実行できませんでした。このソフトウェアのドキュメントがほとんどないからというだけではありません。以来Piranha非推奨とみなされ、私はに渡ったHAProxy上で費やした時間の割合で仕事をしたしようとして数日後Piranha。 そのため、FTP負荷分散(パッシブモード)を用意しています。次に、データセンターのピラニアロードバランサー全体を交換するように依頼されました。現在のピラニア構成では、いくつかのWebサーバー、IISサーバー.... aaaおよびDNSがあります。 いいえ HAProxy、これは問題ではありませんUDP load balancing。一般的に使用されているLBのようですが、処理できません。HAProxy動作が好きなので、これは残念です。それで、私はたくさんググって、いくつかのものに出くわしました。ほとんどの人はLVSDNS(TCP / UDP)のLBとして使用しているようです。一部の用途dlbDNS、一部の用途lbnamed、一部の用途netfilter / iptables。 HAProxyFTP、HTTP、IISサーバーを使い続けたいので、と並べて使用することに混乱しましたLVS。 要件: フェイルオーバーのある 2 つのLBインスタンスフェイルオーバーのある2つのDNSサーバー(すでに存在) 複数のバックエンドサーバー(http、アプリケーションなど) 質問: これは可能ですか?DNSサーバーでのUDP負荷分散は必要ですか?それを始める方法を教えてくれるリソースはありますか?または、TCP / HTTPだけでなくUDP負荷分散も処理できるLBソリューションはありますか? PS: LBソリューションは、ハードウェアではなく、オープンソース/ GPLライセンス/無料である必要があります。 助けやそれぞれのリソースにつながることは大歓迎です!

4
データセンター内の通信でドロップされたパケットはどのくらい一般的ですか?
同じデータセンターに2台のマシンがあるとしますが、必ずしも同じラックにあるとは限りません。 これらの2つのマシン間でUDPを使用して送信された場合、パケットのドロップはどのくらい一般的ですか? 私は、マシン間にせいぜい数個のスイッチしかないので、パケットがまったくドロップされないという仮定の下で質問しています。 同じデータセンター内でのパケットの到着の乱れはどのくらい一般的ですか?私の仮定では、99.9%の時間しかルートがないため、これは起こり得ません。 しかし、絶対的なことを考えているときはいつでも、何かを見逃しているに違いないことを知っています。 パケットのドロップが予想されるタイミング、およびそれらがドロップされて同じデータセンター内のマシンの順序が狂ってしまう頻度をよりよく理解するには、どのような背景情報が必要ですか? 最終的に、同じデータセンターにある異なるLinode VPSインスタンス間で通信するときに、マルチキャストUDPまたはPGMのどちらを使用するかを決定しようとしています。情報が到着し、順番に並んでいる必要があります。もちろん、UDPはそれほど素晴らしい音ではありません! ただし、同じデータセンターでほぼ完全な、または完全な配信が期待できる場合は、問題ありません。しかし、私はその仮定をテストしています。 ありがとう。

5
UDPソケットへのすべてのリクエストをリストする方法は?
udpを使用して多数のクライアントと通信するサーバーデーモンをいくつか運用しています。サーバーデーモンに接続されているアクティブなクライアントの数を推定するために、サーバーと通信しているすべてのアクティブなudp "接続"を見つけて一覧表示するにはどうすればよいですか?tsharkまたはtcpdumpでパケットをスニッフィングしてサーバーデーモンに送信されるudpパケットのソースIPを確認する以外に、これを行う簡単な方法は考えられませんでした。もちろん、UDPはコネクションレスでステートレスなプロトコルです。

2
対称NATおよびUDPホールパンチング
私はこの質問を読みましたが、対称NATの説明は十分に詳しくありませんでした。 誰かが以下の段落を理解するのを手伝ってくれませんか? 私は対称NATについてこれを読みました: 同じ内部IPアドレスとポートから特定の宛先IPアドレスとポートへの各要求は、同じ内部ホストが同じ送信元アドレスとポートを使用していても異なるパケットにパケットを送信する場合、一意の外部送信元IPアドレスとポートにマップされます。宛先では、異なるマッピングが使用されます。内部ホストからパケットを受信する外部ホストだけがパケットを送り返すことができます。 http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT そしてこれはUDPホールパンチングについてです: UDPホールパンチングは、大規模な企業ネットワークでよく見られる対称NATデバイス(双方向NATとも呼ばれます)では機能しません。対称NATでは、既知のSTUNサーバーへの接続に関連付けられているNATのマッピングは、既知のサーバーからのデータの受信に制限されているため、既知のサーバーが参照するNATマッピングは、エンドポイントにとって有用な情報ではありません。 http://en.wikipedia.org/wiki/UDP_hole_punching しかし、私はそれを本当に吸収していません。(クライアントが通信を開始するクライアント/サーバーアプリケーションでは)サーバーがNATデバイスによって明示的に許可されていない限り、他の方法でサーバーに通信できなかったと感じています。なぜそれが言っているのか理解できません。可能であれば、この説明を少し簡単にしていただけませんか。 私たちの環境では、同じように有名なソフトウェアベンダーが有名なリモートサポートツールを使用してサポートを提供できないという問題があります。クライアントはプロキシに対応していますが、一部の理由から、クライアントを使用せずに、ポート1153でUDPを介してまったく異なることを行うのが良い考えであると考えています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.