细节：
我们遇到了第三方供应商的问题,他在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.
解决方法
-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库.
