カーネルがパケットをドロップするのはなぜですか？
tcpdumpを Ctrl+C そして、この合計の要約を得ました：
579204 packets captured
579346 packets received by filter
142 packets dropped by kernel
「カーネルによってドロップされるパケット」とは何ですか？なぜそれが起こるのですか？
Tcpdumpのマニュアルから：
「カーネルによってドロップされた」パケット（これは、OSがアプリケーションにその情報を報告した場合に、tcpdumpが実行されているOSのパケットキャプチャメカニズムによって、バッファースペースの不足のためにドロップされたパケットの数です。そうでない場合は、0として報告されます。
少し説明：
tcpdumpは、ネットワークインターフェイスを通過する未加工パケットをキャプチャします。パケットは、コマンドラインで指定したルールに従って解析およびフィルタリングする必要があります。これには時間がかかるため、着信パケットは処理のためにバッファ（キュー）に入れる必要があります。パケットが多すぎる場合、それらはバッファに保存されますが、処理されるよりも速く保存されるため、最終的にバッファのスペースが不足し、カーネルはバッファに空きスペースができるまで、すべてのパケットをドロップします。
次のように-B（--buffer-size）オプションを使用してバッファサイズを増やすことができます。
tcpdump -B 4096 ....
サイズはキロバイト単位で指定されているため、上の行ではバッファーサイズを4MBに設定しています。
もう1つ考慮/試行することは、tcpdumpがIPをドメイン名に解決するためにDNSクエリを実行するのに多くの時間を費やしている可能性があることです。それらが必要ない場合は、-n（ルックアップなし）フラグ。例えば。：
tcpdump -n port 80
による man tcpdump：
パケットによってドロップされたカーネル（これは、OSのパケットキャプチャメカニズムによって、バッファスペースの不足のためにドロップされたパケットの数です。 OSがその情報をアプリケーションに報告する場合、どのtcpdumpが実行されているか、そうでない場合、0として報告されます。
カーネルは、キャプチャされたパケットを固定サイズキャプチャバッファに入れます。 tcpdumpがそのバッファーをすぐに空にしない場合、カーネルはバッファー内の古いパケットを上書きし始め、それに応じてdroppedカウンターをインクリメントします。そのカウンターの値は、「カーネルによってドロップされた」と見なすものです。
ちなみに、 キャプチャバッファのサイズを変更 ：tcpdumpを渡す-BオプションとKiBサイズ。
マニュアルページに書かれていることに加えて、パケットがカーネルによってドロップされる可能性があるいくつかの追加の理由があるようです。 tcpdumpから100％のパケットドロップが発生しました。ネットワーク上のトラフィックは、1秒あたりPRBSの512Bパケットが1つだけでした。明らかにバッファスペースの説明はここでは意味がありません-私はカーネルが0.5kiB/sを処理できると思います。
私のディストリビューション（Ubuntu 14.04）に付属した何かが、リンクレイヤーで私のテストパケットが気に入らないある種のスマートフィルタリングを行っている可能性があります。私の回避策は、次のように新しいネットワーク名前空間を作成することでした。
Sudo -i
ip netns add debug
ip link set dev eth0 netns debug
ip netns exec debug bash
ifconfig eth0 1.2.3.4 up
内側のnetnsシェルでは、以前に問題を引き起こしていたOSプロセスはすべて図から外れており、tcpdumpには、予想されるすべてのパケットが表示されます。
tcpdump -cオプションを使用すると便利です。このようにして、パケット数を設定してから停止し、バッファを埋めることはできません。
たとえば、これはlocalhostのtcpリクエストをキャプチャします。
tcpdump -ni lo tcp -c 20
「カーネルに落とされない」ようにするために、上記の他の人が推奨している3つすべてを使用する必要があることがわかりました。
tcpdump -c 10000 -n -B 10240