LinuxでのLinuxコントロールに関する初心者

しばらく前に、リモートブランチで簡単なトラフィックバランシングを設定するように求められました。 彼らは貧しい仲間であり、ADSLを介して働いており、大量の電子メール（ドキュメントスキャン）を送信するとリバースチャネル全体が詰まり、VPNを介したオフィスオンラインプログラムでの作業に問題が生じます。
Linux（Fedora）をゲートウェイとして使用します。 これに先立ち、FreeBSDでipfwを使用してこのバランスがどのように設定されるかを何度か見ました。また、iptablesメカニズムをよく知っているので、特別な問題は予想していませんでした。 しかし、インターネットを検索すると、iptablesが私のアシスタントではないことに不愉快な驚きを覚えました。 また、テーブルとルールを通過するパケットの順序に関する知識は、私にとってはほとんど役に立ちません。 iproute2パッケージからtcを学ぶ必要があります。

思いがけず、私はiproute2を使用したトラフィックバランシングを多少なりとも理解するために2日間を費やしました。 最初は、HTBに関する記事（ ここではありません）は、初心者には最適ではありませんでした。 また、特定のオプションの説明やアプリケーションの意味が含まれていないことが多いため、インターネットからのさまざまな例も愚かでした。 したがって、私は1つの記事で受け取った知識を収集しようとしました。最も重要なのは、初心者がアクセスできるレベルですべてを記述することです。

すぐに予約します。ネットワークインターフェースからのトラフィックのみをカットします。 着信も調整できますが、これには追加のトリックが必要です。

クラスレスの規律

そのため、Linuxでは、トラフィックを制御するために各ネットワークインターフェイスにディシプリン（qdisc）が割り当てられます。 トラフィック管理システム全体が構築されるのは、学問分野からです。 しかし、恐れる必要はありません。実際、規律はネットワークパケットのキューを処理するための単なるアルゴリズムです。
1つのインターフェースに複数のディシプリンが関係する場合があり、いわゆるルートディシプリン（ルートqdisc）がインターフェースに直接接続されます。 さらに、各インターフェイスには独自のルート規則があります。

prio_fast

デフォルトでは、システムの起動後、ルートqdiscはpfifo_fastタイプのパケットを処理するアルゴリズムを設定します。



私たちはチェックします：

＃tc qdisc

qdisc pfifo_fast 0：dev eth0ルートバンド3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 1

pfifo_fastは通常の「最初の入力-最初の出力」アルゴリズムですが、トラフィックに優先順位が付けられています。 このタイプのディシプリンには、異なるパケット処理優先順位を持つ3つのFIFOキューが含まれます。 パケットは、各IPパケットのToS（Type of Service）フラグに基づいてそれらに配置されます。 FIFO0に分類されるパケットは処理の優先度が最も高く、FIFO2では最小になります。 ToS自体には別の議論が必要なので、送信されたIPパケットに割り当てるToSをオペレーティングシステム自体が知っているという事実に限定することを提案します。 たとえば、telnetとpingパケットでは、ToSの値は異なります。

0： -ルートディシプリンへのハンドル。
記述子は、 major_number：minor_numberの形式である必要がありますが、分野では、最小数は常に0である必要があるため、省略できます。

priomapパラメーター1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 1は、ToSフィールドと各内部キュー（バンド）のビット対応を設定するだけです。 たとえば、ToS = 4の場合、パケットはキュー1で処理され、ToS = 7はキュー0で処理されます。

多くの情報源は、pfifo_fast分野のパラメーターを変更できないことを示しています。

TBF

次に、一般的な発信トラフィックの速度を制限する方法を検討します。 これを行うには、 TBFタイプのディシプリン（トークンバケットフィルター）をインターフェイスのルートディシプリンとして割り当てます。

＃tc qdisc add dev eth0 root tbf rate 180kbit latency 20ms buffer 1540

rate 180kbit-インターフェースの伝送速度のしきい値を設定します。

レイテンシー20ミリ秒 -データパケットがトークンの待機に費やした最大時間を設定します。

バッファ1540-トークンバッファのサイズをバイト単位で設定します。 例では、10Mbit / sの制限に対して10Kバイトのバッファーで十分であると書いています。 主なことは、サイズを小さくしすぎないことです。もっと多くのことが可能です。 概算式：rate_in_Bytes / 100。



TBFの規律は、その作業にトークンメカニズムを使用します。 トークンは一定の速度でシステムによって生成され、バッファー（バケット）に配置されます。 インターフェイスからバッファを離れるトークンごとに、IPパケットが送信されます。
パケット転送速度とトークンの生成が一致する場合、データ転送プロセスは遅滞なく進行します。
パケット転送レートがトークンレートよりも低い場合、後者はバッファに蓄積し始め、しきい値よりも高速で短期のデータ送信に使用できます。
パケット転送速度が高い場合、トークンが失われ始めます。 データパケットは新しいトークンをしばらく待ってから、破棄され始めます。

説明されている2つの分野は、いわゆるクラスレス分野に属します。 これらには機能上の制限がいくつかあります。それらはインターフェース（またはエッジクラス）にのみ接続され、さらにパケットフィルターを使用できません。 したがって、メールトラフィックとその支援のバランスを取るという私のタスクは不可能です。
ちなみに、クラスレスの規律の完全なセットはやや広くなります：pfifo、bfifo、sqf（異なるストリームから受信したパケットと同じ速度を提供します）、esqfなど

クラスの分野

分野を水道管のセグメントとして表すことができる場合、クラスはコネクタ（継手）です。 シンプルなフィッティングアダプターでも、数十タップのトリッキーなフィッティングスプリッターでもかまいません。

クラスの親は、ディシプリンまたは別のクラスのいずれかです。
子クラスはクラスに参加できます（複数の継手をドッキング）。

子クラスを持たないクラスは、 リーフクラスと呼ばれます。 ここで、「給水システム」を通過したデータパケットは、交通管制システムを出て、ネットワークインターフェイスによって送信されます。 デフォルトでは、エッジクラスにはfifoタイプのディシプリンがアタッチされており、このクラスのパケットが送信される順序を決定するのはそれです。 しかし、全体の魅力は、この規律を他の人と交換できることです。
子クラスを追加すると、この規律は削除されます。

プリオ

メールトラフィックのバランスをとるタスクに戻って、クラス規律prioを考えてみましょう。
これは、すでに説明したpfifo_fastと非常によく似ています。 ただし、このディシプリンは特別です。割り当てられると、3つのクラスが自動的に作成されます（その数は、bandsパラメーターで変更できます）。

インターフェイスのルートディシプリンをprioに置き換えます。

＃tc qdisc add dev eth0 root handle 1：prio

ハンドル1： -このルートqdiscにハンドルを設定します。 クラス分野では、クラスが接続されたときに表示されます。

規律を確認してください：

＃tc qdisc

qdisc prio 1：dev eth0バンド3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 1

クラスを確認します。

＃tc -d -sクラスshow dev eth0

クラスprio 1：1親1：
734914バイト7875パケットを送信（0をドロップ、0を超過すると0をリキュー）
バックログ0b 0pリキュー0
クラスprio 1：2親1：
送信済み1555058583バイト8280199パケット（124919がドロップされ、26443のリキューが0を超過）
バックログ0b 0pリキュー0
クラスprio 1：3親1：
送信済み57934378バイト802213パケット（ドロップされた70976、284608の再キュー制限0）
バックログ0b 0pリキュー0

IDが1、1、1、2、1：3の3つのクラスがあり、prioタイプの親ディシプリン1：に接続されています（クラスには親と共通のメジャー識別子番号が必要です）。
つまり、pfifo_fastと同じ方法でデータストリームを共有する「パイプ」ルートqdiscに、Tをインストールしました。 ToSにより、優先度の高いトラフィックはクラス1：1に到達し、通常のトラフィックはクラス1：2に到達し、「ゴミ」はクラス1：3に到達します。

リバースチャネルADSLが90KB / sの速度を生成するとします。 メールの場合は20 KB / s、その他の場合は70 KB / cに分けます。

クラス1：1からのトラフィックは特に制限されません。 ToSの優先度が高いため、パケットは常に少なくともチャネル幅全体を占有できますが、このクラスのトラフィック量は他の2つのクラスと比較して無視できます。 したがって、別のストリップを予約しません。

通常、標準トラフィックはクラス1に分類されます。2。 ティークラスの2番目の出力に、規律パイプを70KB / sで接続します。

＃tc qdisc add dev eth0 parent 1：2 handle 10：tfb rate 70kbps buffer 1500 latency 50ms

ティーの3番目の出力で、規律パイプを20KB / sで接続します。

＃tc qdisc add dev eth0 parent 1：3 handle 20：tfb rate 20kbps buffer 1500 latency 50ms

これらの3つのクラスはすべて限界です。

そして今では、以前と同様にメールトラフィックをクラス1：2に向けるのではなく、クラス1：3に向けるだけです。 これは、クラスディシプリンフィルターを使用して行われます。

＃tc filter add dev eth0 parent 1：protocol ip prio 1 u32 match ip dport 25 0xffff flowid 1：3

親1： -フィルターはディシプリンにのみアタッチでき、そこから呼び出されます。 フィルターのトリガーに基づいて、ディシプリンはパケット処理を継続するクラスを決定します。

protocol ip-ネットワークプロトコルのタイプを決定します

prio 1-パラメーターはクラスやフィルターで使用されるため、長い間私を混乱させてきました。さらに、これは専門分野の名前です。 ここで、prioはフィルターをトリガーする優先順位を設定します。prioが低い方のフィルターが最初にアクティブになります。

u32-いわゆるトラフィック分類子。これは、送信者/受信者のIPアドレス、送信元/受信者のポート、プロトコルタイプのいずれかの基準でパケット選択を実行できます。 実際、これらの条件は以下に示されています。

match ip dport 25 0xffff-パケットがポート25に送信されたときにトリガーするフィルターを設定します。0xffffはポート番号のビットマスクです。

flowid 1：3-このフィルターがトリガーされたときにどのクラスのパケットが送信されるかを示します。

ラフに完了しましたが、タスクは完了しました。

パケットパッシングの統計を確認します。

＃tc -s -d qdisq show dev eth0
＃tc -s -d class show dev eth0
＃tc -s -d filter show dev eth0

次のコマンドを使用すると、すべてのクラス、フィルターをすばやく削除し、インターフェイスのルートqdiscを元の状態に戻すことができます。

＃tc qdisc del dev eth0 root

Htb

一方、私たちのリターンチャネルはすでに非常に薄いため、電子メールを送信するためだけに20KB /秒を予約することはできません。 したがって、クラスディシプリンHTB（Hierarchical Token Bucket）を使用することをお勧めします。 親の子クラスから帯域幅を借りることができます。



＃tc qdics add dev eth0 root handle 1：htb default 20

デフォルト20-デフォルトでクラスを設定します。 htb規律の他のクラスに分類されないパケットを処理します。 指定しない場合、「デフォルト0」が割り当てられ、すべての未分類（フィルタリングなし）トラフィックがインターフェイス速度で送信されます。

＃tc class add dev eth0 parent 1：classid 1：1 htb rate 90kbps ceil 90kbps

識別子1でルートqdiscクラスにアタッチします。1。 したがって、インターフェイスの速度を90KB / sに制限します。

classid 1：1-クラス識別子。

レート90kbps-クラスの低帯域幅しきい値を設定します。

ceil 90kbps-クラスの上限帯域幅しきい値を設定します。

＃tc class add dev eth0 parent 1：1 classid 1:10 htb rate 20kbps ceil 70kbps

クラス1:10、クラス1：1の子を作成します。 次に、送信メールトラフィックがフィルターによって送信されます。

レート20kbps-クラスの保証された低帯域幅のしきい値を設定します。

ceil 70kbps-クラスの帯域幅の上限しきい値を設定します。 親クラスに空き帯域幅（「余分な」トークンの存在）がある場合、クラス1:10は、指定された制限の70KB / sまで、データ転送速度を一時的に上げることができます。

＃tc class add dev eth0 parent 1：1 classid 1:20 htb rate 70kbps ceil 90kbps

デフォルトクラスを作成します。 他のすべてのトラフィックはそれに落ちます。 同様に、メールトラフィックが既にない場合は、rateおよびceilパラメーターを設定して帯域幅を拡張します。

＃tc filter add dev eth0 parent 1：protocol ip prio 1 u32 match ip dport 25 0xffff flowid 1:10

u25に基づいてフィルタリングし、ポート25に発信するパケットをクラス1:10に転送します。

ところで、ドキュメンテーションには、実際にはHTBトラフィックシェーピングはエッジクラスでのみ発生すると記載されており、この場合は1:10および1:20です。 他のHTBクラスの帯域幅制限パラメーターの指定は、クラス間で借用システムが機能するためにのみ必要です。

クラスを追加するときに、 prioパラメーターを指定することもできます。 クラスの優先度を設定します（0-最大優先度）。 優先度の高いクラスにデータがある限り、優先度の低いクラスは処理されません。

ソース：
Linux Advanced Routing＆Traffic Control HOWTO
トラフィック制御HOWTO
Linuxとトラフィック管理の物語