有時會發生網絡丟包現象，此處的丟包有兩種，真正意義上的丟包和邏輯丟包(此處以tcp協議棧丟包為例)。之前falcon-agent也上報了相應的指標，在此處對一些疑問給出盡量詳細的解釋。
linux系統pakcet接收的過程過程簡單概括為
網卡收到包以后通過DMA傳至ring buffer
網卡觸發硬件中斷，中斷處理函數調用包接受軟中斷（softirq）
Softirq檢測各cpu的網卡poll list，并輪詢相應網卡的ring buffer
包從相應packet desciptor 中移到更上一層處理，并把該packet descriptor重置
真實的丟包就是說這三個階段的任一階段收到了包，但因為某些原因把它丟棄了。
發生真實丟包的原因
當ring buffer滿了并且kernel softirq并不能及時處理后續的進來的包，那就會導致丟包。可以通過ethtool -G eth1 rx number增大receive buffer的值可以緩解丟包，同理也可以設置transfer buffer。
當socket backlog滿了導致丟包，可以設置/proc/sys/net/ipv4/tcp_max_syn_backlog來增加tcp syn隊列的長度。
真實丟包判斷
可以通過ethtool、ifconfig、netstat命令查看丟包統計，也可以直接查看/proc/net/dev、/sys/class/net/dev_name查看，如ifconfig eth0
第三行，第四行表示收包和發包的情況，errors，dropped，overruns，frame不為0即表示發生了真正的丟包。
RX errors: 表示總的收包的錯誤數量，這包括 too-long-frames 錯誤，Ring Buffer 溢出錯誤，crc 校驗錯誤，幀同步錯誤，fifo overruns 以及 missed pkg 等等。
RX dropped: 表示數據包已經進入了 Ring Buffer，但是由于內存不夠等系統原因，導致在拷貝到內存的過程中被丟棄。
RX overruns: 表示了 fifo 的 overruns，這是由于 Ring Buffer(aka Driver Queue) 傳輸的 IO 大于 kernel 能夠處理的 IO 導致的，而 Ring Buffer 則是指在發起 IRQ 請求之前的那塊 buffer。很明顯，overruns 的增大意味著數據包沒到 Ring Buffer 就被網卡物理層給丟棄了，而 CPU 無法即使的處理中斷是造成 Ring Buffer 滿的原因之一，上面那臺有問題的機器就是因為 interruprs 分布的不均勻(都壓在 core0)，沒有做 affinity 而造成的丟包
RX frame: 表示 misaligned 的 frames。
對于 TX 的來說，出現上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error，而 collisions 則表示由于 CSMA/CD 造成的傳輸中斷。
邏輯意義上的丟包
相信大家多少都了解tcp協議棧，tcp協議棧中有超時重傳算法，此處的邏輯丟包指的是接收方沒有在發出ack后收到正確序號范圍的packet
邏輯意義上的丟包原因及判斷方法
原因很可能是發生了網絡問題，具體包括如網絡擁塞、網線松動、網絡不穩定及其他線路故障，也有可能是網絡流量突增，但是我們做監控的不能去實時的拿著線路檢測儀去檢查線路，當前擬定使用如下指標，來源/proc/net/netstat：
TcpExt.TCPLoss，tcp協議棧丟失數據包而進行恢復的次數，此時falcon-agent所在主機為接收方
TcpExt.TCPTimeouts tcp數據在指定時間內沒有受到應答ack而超時的次數，此時falcon-agent所在主機為發送方
TcpExt.TCPLossFailures，tcp協議棧丟失數據包進行恢復失敗的次數
TcpExt.TcpFastRetrans，tcp快速重傳的次數
