封裝在docker中的TCP dump未占用大量CPU資源，但不能完全抓包

好吧，這個問題我自己來回答啦。

在linux系統(tǒng)上，使用tcpdump抓包結(jié)束之后會提示：

簡單來說， captured是tcpdump處理過之后，得到的數(shù)據(jù)包數(shù)量，亦即最終獲得的pcap文件中數(shù)據(jù)包數(shù)量； received是經(jīng)過過濾器處理的所有數(shù)據(jù)包； dropped則是未經(jīng)處理的數(shù)據(jù)包數(shù)量。
received by filter的結(jié)果這取決于運行tcpdump的操作系統(tǒng)及其配置。如果指定一個過濾器,包無論是否被篩選器表達(dá)式匹配，即使他們被篩選器表達(dá)式匹配，無論tcpdump是否讀取和處理他們，都會進(jìn)行計算，即收到一個包，received by filter會加1。如果sock的接收buffer被填滿時，則把這個數(shù)據(jù)包丟棄，將dropped by kernel加1，所以 received by filter和dropped by kernel的計數(shù)由內(nèi)核維護。
造成丟包的原因，是由于libcap抓到包后，tcpdump上層沒有及時的取出，導(dǎo)致libcap緩沖區(qū)溢出，從而丟棄了未處理包，此處即顯示為dropped by kernel。這里的kernel并不是說是被linux內(nèi)核拋棄的，而是被tcpdump的內(nèi)核，即libcap拋棄掉的。

解決辦法也有一些，比如：
1、-n 參數(shù)，禁止反向域名解析（）
2、-s 參數(shù)，控制抓取數(shù)據(jù)包的長度
（采用更大的捕捉范圍既增加了處理報文的時間,又相應(yīng)的減少了報文的緩沖數(shù)量,可能導(dǎo)致報文的丟失。嘗試把snaplen設(shè)的盡量小,只要能夠容納需要的協(xié)議信息就可以。）
3、將數(shù)據(jù)包輸出到cap文件
4、用sysctl修改SO_REVBUF參數(shù)，增加libcap緩沖區(qū)長度

方法1我試過了，效果不理想。
方法2也試過了，效果不錯。但我本來就是要測抓包性能的，肯定得把包抓全啊，想想之后放棄了這個方案。
方法3這個.....我本來就是輸出到文件里的，但還是有丟包的問題，所以好像并沒有什么卵用。
方法4感覺有點復(fù)雜，不過前面解釋里也提到是因為緩沖區(qū)不夠才導(dǎo)致的丟包，遂覺得這方法有門，不過就是麻煩了一點。然后靈機一動，我查到了tcpdump里有個-B參數(shù)可以修改緩沖區(qū)大小，哈哈??！

所以最后的解決辦法就是：我使用-B參數(shù)修改了tcpdump的緩沖區(qū)大小?。。?br>這里要注意的是如果未指定 -B 選項，那么緩沖區(qū)大小缺省為32768，既然這樣我就乘二試了試，-B 65535。
嘻嘻，一下子什么丟包都飛走了~~