linux – 进行TCP转储而不丢失数据包

如何建立TCP转储,以确保捕获真正通过网络的所有数据包,并且没有遗漏任何内容？

细节：
我们遇到了第三方供应商的问题,他在SCTP堆栈之上提供了解决方案,他也实现了这一点.
在相当高的吞吐量(52 000消息/秒,平均消息大小为500字节)下,SCTP链路中断.
我们认为该bug存在于供应商的SCTP堆栈中.
但是厂商说,这是因为SCTP堆栈发送消息,没有接收到ACK,发送多次重传,也没有接收到它们的ACK并关闭SCTP链路.
所以供应商说,这是一个有罪的网络,因为它丢失了数据包.

在双方,客户端和服务器的TCP转储中,我们看到原始消息到达服务器并看到服务器没有应答ACK.但供应商表示TCP转储不可靠,在捕获TCP转储时,可能无法捕获某些数据包,因为libpcap库仅在一个硬件线程内工作,其功率可能不足以记录所有数据包.

技术数据：
52 000消息/秒,平均消息大小为500字节,因此总共26 MB /秒,使用4个SCTP链路.
硬件：cpu E5-2670,2.6 GHz,8个HW线程
网络：10 GBit,流量位于HP刀片之间,HP刀片位于一个机架中.
RHEL 6.

解决方法

在你的流量,我会声称libpcap应该没有丢弃数据包的麻烦,除非你有一个特别低效的设置.如果您使用tcpdump进行捕获,它将报告其最终输出行中丢弃的数据包的数量.如果您看到丢弃的数据包,您可能希望通过提供 the -B option来设置一个远高于默认值2 MB的值来增加tcpdump的缓冲区大小.

不过,您可能想看看PF_RING：

Who needs PF_RING™?

Basically everyone who has to handle many packets per second. The term
‘many’ changes according to the hardware you use for traffic analysis.
It can range from 80k pkt/sec on a 1,2GHz ARM to 14M pkt/sec and above
on a low-end 2,5GHz Xeon. PF_RING™ not only enables you to capture
packets faster,it also captures packets more efficiently preserving
cpu cycles. Just to give you some figures you can see how fast nProbe,
a NetFlow v5/v9 probe,can go using PF_RING™,or have a look at the
tables below.

10 Gigabit tests performed on a Core2Duo 1.86 GHz and a low-end Xeon
2,5 Ghz

ixgbe 
            Application                                 Rate 
pfcount (RX,with PF_RING™ DNA)        11 Mpps (Core2Duo),14.8 Mpps (Xeon) 
pfsend (TX,with PF_RING™ DNA)         11 Mpps (Core2Duo),14.8 Mpps (Xeon)

PF_RING user guide解释了如果您坚持使用libpcap应用程序进行数据包捕获,如何编译和配置启用PF_RING的libpcap库.