遅いサーバーでストリーミングされるアプリケーションの動作を研究したいと思います。ネットワーク待ち時間の導入を活用しようとしていますtc-netem。
より複雑なシナリオを設定する前に、遅いサーバーをシミュレートする必要がある仮想マシンでこれを行うことにしました。仮想マシンを介してアクセスしているので、ssh仮想イーサネットを作成することにしました。これにより、実際のイーサネットデバイスを使用して管理しようとしましたが、レイテンシが発生しました。
まず、偽のインターフェイスを作成し、ip link add link eth0 type macvtapここにIPアドレスを割り当てました。
その後、40ミリ秒の遅延を追加しましたtc qdisc add dev macvtap0 root netem delay 40000。これにより、実際にスループットが低下しました（〜250MiB /秒から〜6MiB /秒）。
この時点で設定を少し調整してみましたが、遅延がデバイスにのみ影響するのではなく、私が接続されているデバイスにも影響することに気づき始めましたmacvtap0。eth0つまり、sshセッションが遅れ始めました。
netem delay実際のネットワークカードに影響を与えるようです。私は仮想マシンで作業しているからですか？それとも別の日焼けを使うべきですかmacvtap？それとも、変更をに適用したためですかroot qdisc？
編集する- 一見、巨大に見えるトラフィック差別化の世界に初めて入りました。たぶんもっと良い方法がありますか？たとえば、選択したプロセスの速度を遅くするようにキューを設定できますか？私は実際の目的を反映するためにこの質問の名前を変更することにしました。
答え1
まず、説明：待ち時間を増やすことは帯域幅を制限するのと同じではありません。考える静止軌道衛星インターネットリンク：一方向の流れは（光の速度のために）約1/4秒の必須遅延があるため、ルート全体が衛星を介して送信される場合、往復は約1/2秒程度になります。説明する~になる506Mbps到達可能最新のテクノロジを使用すると、次のパケットを送信する前に各パケットが承認されるのを待たずに、この1/2秒ウィンドウで大量のデータを送信できます。もちろん、待ち時間は速度に影響を与えず、承認を待つか再送信を要求するなどの理由で邪魔になることがあります。
質問が提起され、質問の目標は次のとおりです。本物違いは、この情報に加えて、次の質問にのみ答えるということです。
一部のqdiscには速度制限機能が組み込まれています。HTB、TBF、...待機時間を増やすのではなく、帯域幅を制限するための2つの提案は次のとおりです。
-
# tc qdisc add dev eth0 root tbf rate 1024kbit latency 50ms burst 1540いつものように、輸出には制限があります。アクセスを制限するには、IFB私の答えの例のように、デバイスが接続されている必要があります。netem を使用したブリッジインターフェイスでのパケット損失のシミュレーション。
わかりました（そんなに古くはありませんでした）
wondershaperスクリプト (v1.4. Debian などの一部のディストリビューションでは廃止) は驚くべきことがあります。ストリームの優先順位付けと待ち時間を減らすように設計されていますが、速度も下げることができ、すでにIFBを使用して出口と入口を制限する単純化方法を使用しています。# wondershaper -a eth0 -d 1000 -u 100eth0帯域幅はダウンロード1000kbps、アップロード100kbpsに制限されています。
今この質問について...
この質問は関係ありませんmacvtap（そのtap部分はOP設定にも使用されません）macvlan仮想化でもなくtc-netem。これは、同じIP LANを使用して複数のインターフェイスが同じイーサネットLANに配置されているときにルーティングがどのように機能するかに関するものです。
仮想マシンでOPの特定の構成がなければ何が起こっているのかを知る方法がないので、いくつかのネットワークネームスペース「system」で人為的な例を再現します。仲間ping「システム」デュアルカード、どちらも「スイッチ」を介して接続足。
2枚目のカードを追加する前の初期設定：
ip netns del bridge || :
ip netns del twocards || :
ip netns del peer || :
ip netns add bridge
ip netns add twocards
ip netns add peer
ip -n bridge link add bridge0 type bridge
ip -n twocards link add eth0 type veth peer netns bridge name port1
ip -n peer link add eth0 type veth peer netns bridge name port2
ip -n bridge link set port1 master bridge0
ip -n bridge link set port2 master bridge0
ip -n bridge link set port1 up
ip -n bridge link set port2 up
ip -n bridge link set bridge0 up
ip -n twocards link set eth0 up
ip -n peer link set eth0 up
ip -n twocards address add dev eth0 192.0.2.1/24
ip -n peer address add dev eth0 192.0.2.2/24
今：
# ip -n twocards route
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.1
ユビキタスNetworkManagerを使用する一般的なインストールには、一連のイーサネットデバイスがあります。metric 100同じことをしましょう。
ip -n twocards route add 192.0.2.0/24 dev eth0 src 192.0.2.1 metric 100
ip -n twocards route del 192.0.2.0/24 dev eth0 src 192.0.2.1
測定してみましょう：
# ip netns exec peer ping -c2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.060 ms
--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1018ms
rtt min/avg/max/mdev = 0.060/0.088/0.116/0.028 ms
結果は正常です。 2番目のカードを追加し、IPを追加してからnetemキューを追加します。
ip -n twocards link add eth1 type veth peer netns bridge name port3
ip -n bridge link set port3 master bridge0
ip -n bridge link set port3 up
ip -n twocards link set eth1 up
ip -n twocards address add dev eth1 192.0.2.3/24
ip netns exec twocards tc qdisc add dev eth1 root netem delay 40000
新しいルート：
# ip -n twocards route
192.0.2.0/24 dev eth1 proto kernel scope link src 192.0.2.3
192.0.2.0/24 dev eth0 scope link src 192.0.2.1 metric 100
新しい動作（継承仮定rp_filter設定されています）:
# ip netns exec peer ping -c2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
--- 192.0.2.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1021ms
どうしたの？これで、ルーティングとARPの動作が機能します。
# ip -n twocards route get 192.0.2.2 from 192.0.2.1
192.0.2.2 from 192.0.2.1 dev eth1 uid 0
cache
# ip -n twocards -br link
lo DOWN 00:00:00:00:00:00 <LOOPBACK>
eth0@if3 UP 96:45:4d:f0:52:35 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1@if5 UP c2:70:b7:40:6c:40 <BROADCAST,MULTICAST,UP,LOWER_UP>
# ip -n peer neighbour
192.0.2.1 dev eth0 lladdr 96:45:4d:f0:52:35 REACHABLE
ルーティングテーブルデュアルカード今使用しますeth1、でもそれに割り当てられた住所のためにeth0。 Linuxは単にルーティングテーブルのデフォルトの動作に従います。なぜならrp_filter起動後のデバイスeth0（MACはまだ仲間隠れ家）。設定しないと、rp_filter非対称ルーティングに機能します。要求時にping eth0、応答時にping eth1、（遅延netem）まで仲間ARPキャッシュは最終的に期限切れになってからeth1使用されます（通常どおり送信のみが遅延されます）。
ARPキャッシュを削除してみましょう。仲間それからもう一度やり直してください。
# ip -n peer neighbour flush dev eth0
# ip netns exec peer ping -c2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=80.2 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=40.1 ms
--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 40.141/60.178/80.215/20.037 ms
# ip -n peer neighbour
192.0.2.1 dev eth0 lladdr c2:70:b7:40:6c:40 REACHABLE
最初のpingはnetemによって2回だけ遅延されます。 1 回は ARP 要求に対する基本 ARP 応答で、1 回は実際の ping 応答です。
追加のデバイスへのパスを削除してみましょう。デュアルカードARP キャッシュを再度クリアします。仲間:
ip -n twocards route del 192.0.2.0/24 dev eth1
ip -n peer neighbour flush dev eth0
再び正常な結果：
# ip netns exec peer ping -c2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.108 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.050 ms
--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.050/0.079/0.108/0.029 ms
同様に、割り当てられたIPへのpingがeth1パスされます。デュアルカード遅滞なくeth0：
# ip netns exec peer ping -c2 192.0.2.3
PING 192.0.2.3 (192.0.2.3) 56(84) bytes of data.
64 bytes from 192.0.2.3: icmp_seq=1 ttl=64 time=0.143 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=64 time=0.042 ms
--- 192.0.2.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1024ms
rtt min/avg/max/mdev = 0.042/0.092/0.143/0.051 ms
それでは、これについてどうすればよいですか？同じシステムの同じイーサネット LAN で 2 つのネットワークデバイスを使用しないでください。特に同じIP LANを使用している場合、問題が発生する可能性があります。macvlanあるいは、通常、デバイスをmacvtapホストで直接使用しないでください。独自の独立したルーティングスタックを持つVMまたはコンテナ（別のネットワークネームスペース）に渡す必要があるため、一般的な使用では問題になりません。
何らかの理由で同じLAN上にある2つのカードを使用する必要がある場合（ボンディング、チーム構成などを除く）、このような状況を避けるために、やや複雑な追加設定を行う必要があります。 SFに対する私の答えを見るマルチNIC Linuxシステムのゴーストピングもっと学ぶ。
答え2
どんな問題があるのかよく分からないのでスキップします。
プロセス固有のトラフィック形式を調整するには、クラス固有のキュールールを使用する必要があります。 HTBやHSFCがおそらく最善の選択でしょう。これにより、キュールールツリー（netemをリーフのいずれかに接続できます）を作成し、ツリー間でトラフィックを分散できますtc filter。
フィルタリング方法はiptablesタグを見つけるため、フィルタリングは非常に柔軟ですfw。つまり、iptables を使用してトラフィックを選択できます。トラフィックを直接選択することもできます。
ただし、qdiscは発信トラフィックでのみ機能することに注意してください。受信qdiscを持つことができますが、これは非常に制限されており、期待どおりに機能しない可能性があります。
テスト目的のための良いオプションは、2つのインターフェイスを持つ物理仮想マシンを作成し、トラフィックがその仮想マシンを介してルーティングされるように強制することです。いくつかのトリック（たとえば、複数レベルのNAT）が必要な場合があります。その後、仮想マシンの両方のインターフェイスに目的のqdiscを接続して、双方向トラフィックの方向を制御できます。