サードパーティのライブラリなしで毎秒数千万パケットのLinuxパケットキャプチャ

私の記事では、Netmap、PF_RING、DPDKなどのライブラリを使用せずに、毎秒1,000万パケットを受信する方法を説明します。 通常のLinuxカーネルバージョン3.16と、CおよびC ++のコードを使用してこれを行います。







最初に、pcapがどのように機能するかについていくつかの言葉を共有したいと思います-パケットをキャプチャするためのよく知られた方法 iftop、tcpdump、arpwatchなどの一般的なユーティリティで使用されます。 さらに、プロセッサの負荷が非常に高くなります。



したがって、それらのインターフェイスを開いて、通常のアプローチ-bind / recvを使用して、そこからパッケージを待機しています。 次に、カーネルはネットワークカードからデータを受信し、カーネルスペースに保存します。その後、ユーザーがユーザースペースでデータを受信したいことを検出し、このデータを格納するバッファーアドレスをrecvコマンドに引数で渡します。 カーネルはデータを忠実にコピーします（2回目！）。 かなり複雑になりますが、それがすべてのpcapの問題ではありません。



さらに、recvはシステムコールであり、インターフェイスに着信するすべてのパケットに対して呼び出すことを思い出してください。通常、システムコールは非常に高速ですが、最新の10GEインターフェイスの速度（1秒あたり最大1,460万回の呼び出し）でも非常に軽い呼び出しになります呼び出しの頻度だけのためにシステムのコストがかかります。



また、サーバーには通常2つ以上の論理コアがあることに注意してください。 そして、データはそれらのどれにでも飛ぶことができます！ また、pcapを使用してデータを受信するアプリケーションは、シングルコアを使用します。 ここでカーネル側のロックがオンになり、キャプチャプロセスが大幅に遅くなります。現在、メモリのコピー/パケットの処理だけでなく、他のカーネルが占有しているロックの解放を待っています。 私を信じて、ロックは多くの場合、サーバー全体のプロセッサリソースの最大90％を占めることがあります。



問題の良いリスト？ だから、私たちはそれらすべてを英雄的に解決しようとします！



したがって、明確にするために、ミラーポートで作業することを修正します（つまり、ネットワークの外部から特定のサーバーのすべてのトラフィックのコピーを取得することを意味します）。 次に、トラフィックを受信します-14.6 mpps / 7.6GEの速度で最小サイズのSYNフラッドパケット。



SourceForgeのネットワークixgbeドライバー、4.1.1、Debian 8 Jessie。 モジュール構成：modprobe ixgbe RSS = 8.8（これは重要です！）。 8つの論理コアを備えたi7 3820プロセッサーを使用しています。 したがって、8（コード内を含む）を使用する場合は常に、使用しているコアの数を使用する必要があります。

割り込みを既存のカーネルに配布する

宛先MACアドレスがネットワークカードのMACアドレスと一致しないパケットがポートに到着することに注意してください。 そうしないと、LinuxスタックがTCP / IP操作を開始し、マシンがトラフィックで窒息します。 この点は非常に重要です。他の人のトラフィックのキャプチャについてのみ説明し、このマシン宛てのトラフィックの処理については説明していません（ただし、この方法は使いやすいです）。



次に、すべてのトラフィックのリッスンを開始した場合に受け入れることができるトラフィックの量を確認しましょう。



ネットワークカードで無差別モードをオンにします。

ifconfig eth6 promisc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、htopに非常に不快な画像が表示されます-コアの1つの完全なオーバーロード：

 1 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ |||||||||||| 100.0％]     
 2 [0.0％]     
 3 [0.0％]     
 4 [0.0％]     
 5 [0.0％]
 6 [0.0％]
 7 [0.0％]
 8 [0.0％]

インターフェイスの速度を決定するには、特別なpps.shスクリプトを使用します： gist.github.com/pavel-odintsov/bc287860335e872db9a5



インターフェイスの速度はかなり小さく、1秒あたり400万パケットです。

bash /root/pps.sh eth6

 TX eth6：0 pkts / s RX eth6：3882721 pkts / s
 TX eth6：0 pkts / s RX eth6：3745027 pkts / s

この問題を解決し、すべての論理コア（8つあります）に負荷を分散するには、次のスクリプトを実行する必要があります。



すごい、速度はすぐに最大12mppsになりました（ただし、これはキャプチャではありません。これは、ネットワークからこの速度でトラフィックを読み取ることができることを示しています）。

  bash /root/pps.sh eth6
 TX eth6：0 pkts / s RX eth6：12528942 pkts / s
 TX eth6：0 pkts / s RX eth6：12491898 pkts / s
 TX eth6：0 pkts / s RX eth6：12554312 pkts / s

そして、コアの負荷が安定しました：

 1 [|||||  7.4％]     
 2 [||||||||  9.7％]     
 3 [||||||  8.9％]    
 4 [||  2.8％]     
 5 [|||  4.1％]
 6 [|||  3.9％]
 7 [|||  4.1％]
 8 [|||||  7.8％]

テキストで2つのコードサンプルが使用されることにすぐに注目します。

AF_PACKET、AF_PACKET + FANOUT： gist.github.com/pavel-odintsov/c2154f7799325aed46ae

AF_PACKET RX_RING、AF_PACKET + RX_RING + FANOUT： gist.github.com/pavel-odintsov/15b7435e484134650f20



これらは、最大レベルの最適化を備えた完全なアプリケーションです。 中間（明らかに遅いバージョンのコード）は提供しませんが、すべての最適化を管理するためのすべてのフラグが強調表示され、boolとしてコードで宣言されます-自宅で簡単にパスを繰り返すことができます。

最適化なしでAF_PACKETキャプチャを実行する最初の試み

そのため、AF_PACKETを使用してトラフィックをキャプチャするアプリケーションを起動します。

処理：222048 pps
処理：186315 pps

そして天井の負荷：

 1 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ |||||||||  86.1％]     
 2 [||||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||  84.1％]     
 3 | | ||||  79.8％]     
 4 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||  88.3％]     
 5 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ |||||||  83.7％]
 6 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||  86.7％]
 7 | | |||||||||||  89.8％]
 8 [|||||||||||||||||||||||||||||||||||||||||||||||||||| ||||||||||||| 90.9％]

カーネルがロックでdrれた理由は、すべてのプロセッサー時間を消費します。

サンプル：イベント 'cpu-clock'の303K、イベントカウント（約）：53015222600
   59.57％[カーネル] [k] _raw_spin_lock
    9.13％[カーネル] [k] packet_rcv
    7.23％[ixgbe] [k] ixgbe_clean_rx_irq
    3.35％[カーネル] [k] pvclock_clocksource_read
    2.76％[カーネル] [k] __netif_receive_skb_core
    2.00％[カーネル] [k] dev_gro_receive
    1.98％[カーネル] [k] consumer_skb
    1.94％[カーネル] [k] build_skb
    1.42％[カーネル] [k] kmem_cache_alloc
    1.39％[カーネル] [k] kmem_cache_free
    0.93％[カーネル] [k] inet_gro_receive
    0.89％[カーネル] [k] __netdev_alloc_frag
    0.79％[カーネル] [k] tcp_gro_receive

FANOUTでAF_PACKETキャプチャを最適化する

それではどうしますか？ 少し考えると:)複数のプロセッサが1つのリソースを使用しようとするとロックが発生します。 私たちの場合、これは、1つのソケットがあり、1つのアプリケーションによって処理されるという事実によるものです。これにより、残りの8つの論理プロセッサが常に期待される状態になります。



ここでは、優れた機能が私たちの助けになります-FANOUT、そしてロシア語の場合-分岐。 AF_PACKETの場合、複数を実行できます（もちろん、このケースで最も最適なのは、論理コアの数に等しいプロセスの数です）。 さらに、これらのソケットを介してデータを配布するアルゴリズムを指定できます。 PACKET_FANOUT_CPUモードを選択しました。私の場合、データはネットワークカードキュー間で非常に均等に分散されており、これはリソース集中型のバランシングオプションとしては最小だと思います（保証はできませんが、カーネルコードを確認することをお勧めします）。



サンプルコードでは、bool use_multiple_fanout_processes = true;を修正します。



そして再びアプリケーションを起動します。



奇跡！ 10倍の加速：

処理：2250709 pps
処理：2234301 pps
処理：2266138 pps

もちろん、プロセッサはまだ完全にロードされています：

 1 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 92.6％]     
 2 [||||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 93.1％]     
 3 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 93.2％]     
 4 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 93.3％]     
 5 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 93.1％]
 6 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 93.7％]
 7 [|||||||||||||||||||||||||||||||||||||||||||||||||||！ ||||||||||||| 93.7％]
 8 [|||||||||||||||||||||||||||||||||||||||||||||||||||| ||||||||||||| 93.2％]

しかし、perfのトップマップは完全に異なって見えます-もうロックはありません：

サンプル：1Mのイベント「cpu-clock」、イベントカウント（約）：110166379815
   17.22％[ixgbe] [k] ixgbe_clean_rx_irq      
    7.07％[カーネル] [k] pvclock_clocksource_read          
    6.04％[カーネル] [k] __netif_receive_skb_core    
    4.88％[カーネル] [k] build_skb     
    4.76％[カーネル] [k] dev_gro_receive    
    4.28％[カーネル] [k] kmem_cache_free 
    3.95％[カーネル] [k] kmem_cache_alloc 
    3.04％[カーネル] [k] packet_rcv 
    2.47％[カーネル] [k] __netdev_alloc_frag 
    2.39％[カーネル] [k] inet_gro_receive
    2.29％[カーネル] [k] copy_user_generic_string
    2.11％[カーネル] [k] tcp_gro_receive
    2.03％[カーネル] [k] _raw_spin_unlock_irqrestore

さらに、ソケット（AF_PACKETについてはわかりませんが）に受信バッファーSO_RCVBUFを設定する機能がありますが、テストスタンドで結果が得られませんでした。

RX_RINGリングバッファーを使用してAF_PACKETキャプチャを最適化する

何をすべきか、それでもなぜ遅いのですか？ 答えはbuild_skb関数にあります。これは、カーネル内でメモリの2つのコピーがまだ作成されていることを意味します！



ここで、RX_RINGを使用してメモリの割り当てを把握してみましょう。



そして4 MPPSのトップが乾杯！

処理：3582498 pps
処理：3757254 pps
処理：3669876 pps
処理：3757254 pps
処理：3815506 pps
処理：3873758 pps

この速度の向上は、ネットワークカードバッファからのメモリのコピーが1回のみ行われるようになったことにより保証されました。 また、カーネル空間からユーザー空間に転送する場合、繰り返しコピーは実行されません。 これは、カーネルに割り当てられ、ユーザー空間でスキップされる共有バッファーによって保証されます。



動作するアプローチも変化しています-パケットが到着したときにハングしてリッスンできなくなりました（これはオーバーヘッドです！）、今度はポーリング呼び出しで、ブロック全体がいっぱいになったときにシグナルを期待できます！ そして、処理を開始します。

FANOUTによるRX_RINGを使用したAF_PACKETキャプチャの最適化

それでも、ロックには問題があります！ それらを打ち負かすには？ 古い方法は、FANOUTを有効にして、各ハンドラスレッドにメモリブロックを割り当てることです！

サンプル：778Kのイベント「cpu-clock」、イベントカウント（約）：87039903833
   74.26％[カーネル] [k] _raw_spin_lock
    4.55％[ixgbe] [k] ixgbe_clean_rx_irq
    3.18％[カーネル] [k] tpacket_rcv
    2.50％[カーネル] [k] pvclock_clocksource_read
    1.78％[カーネル] [k] __netif_receive_skb_core
    1.55％[カーネル] [k] sock_def_readable
    1.20％[カーネル] [k] build_skb
    1.19％[カーネル] [k] dev_gro_receive
    0.95％[カーネル] [k] kmem_cache_free
    0.93％[カーネル] [k] kmem_cache_alloc
    0.60％[カーネル] [k] inet_gro_receive
    0.57％[カーネル] [k] kfree_skb
    0.52％[カーネル] [k] tcp_gro_receive
    0.52％[カーネル] [k] __netdev_alloc_frag

そこで、RX_RINGバージョンのFANOUTモードを接続します！



ほら！ 記録!!! 9 MPPS !!!

処理：9611580 pps
処理：8912556 pps
処理：8941682 pps
処理：8854304 pps
処理：8912556 pps
処理：8941682 pps
処理：8883430 pps
処理：8825178 pps

パフォーマンストップ：

サンプル：224Kのイベント「cpu-clock」、イベントカウント（約）：42501395417
   21.79％[ixgbe] [k] ixgbe_clean_rx_irq
    9.96％[カーネル] [k] tpacket_rcv
    6.58％[カーネル] [k] pvclock_clocksource_read
    5.88％[カーネル] [k] __netif_receive_skb_core
    4.99％[カーネル] [k] memcpy
    4.91％[カーネル] [k] dev_gro_receive
    4.55％[カーネル] [k] build_skb
    3.10％[カーネル] [k] kmem_cache_alloc
    3.09％[カーネル] [k] kmem_cache_free
    2.63％[カーネル] [k] prb_fill_curr_block.isra.57

ちなみに、公平のために、カーネル4.0.0ブランチを更新しても、それほど高速化されませんでした。 速度は同じ制限内に維持されました。 しかし、コアの負荷は大幅に低下しました！

 1 | |  55.1％]     
 2 [||||||||||||||||||||||||||||||||||||||！  52.5％]     
 3 [|||||||||||||||||||||||||||||||||||||||||||||||||||  62.5％]     
 4 [|||||||||||||||||||||||||||||||||||||||||||||||||||  62.5％]     
 5 [|||||||||||||||||||||||||||||||||||||||||||||  57.7％]
 6 [|||||||||||||||||||||||||||||||||||||  47.7％]
 7 [|||||||||||||||||||||||||||||||||||||||||||||  55.9％]
 8 [|||||||||||||||||||||||||||||||||||||||||||||||||  61.4％]

結論として、Linuxは、特殊なカーネルモジュールを構築できない環境でも、トラフィック分析のための単純な素晴らしいプラットフォームであると付け加えます。 とても幸せです。 カーネルの次のバージョンでは、1800メガヘルツプロセッサを使用して、1460万/秒のパケットのフルワイヤスピードで10GEを処理できることが期待されています:)



推奨資料：

www.kernel.org/doc/Documentation/networking/packet_mmap.txt

man7.org/linux/man-pages/man7/packet.7.html