如何在确保所有通过networking传输的数据包都被捕获的情况下进行TCP转储，并且不会丢失任何内容？
详细信息：我们在第三方供应商处遇到了一个问题，他在SCTP堆栈上提供了一个解决scheme，他也实施了这个解决scheme。
在相当高的吞吐量（52 000消息/秒，平均消息大小为500字节）的情况下，SCTP链路断开。
我们认为这个bug是在供应商的SCTP堆栈中。
但厂商表示，这是因为SCTP堆栈发送消息，没有收到ACK，发送一些重传，也没有收到ACK，并closuresSCTP链接。
所以厂商说，这是有罪的networking，因为它丢包。
在双方的TCP转储，客户端和服务器，我们看到，原来的消息到达服务器，看到服务器不应答与ACK。 但是供应商说，TCP转储不可靠，当捕获TCP转储时，有些数据包可能不被捕获，因为libpcap库只能在一个硬件线程中工作，所以它的能力不足以logging所有的数据包。
技术数据：每秒52 000个消息，平均消息大小为500个字节，因此总共有26 MB /秒，使用4个SCTP链接。
硬件：CPU E5-2670,2.6 GHz，8个硬件线程
networking：10 GBit，stream量位于HP刀片之间，位于一个机架中。
RHEL 6。
在你的stream量上，我会声称libpcap应该没有问题，除非你有一个特别低效的安装。 如果使用tcpdump进行捕获，则会报告最终输出行中丢弃的数据包数量。 如果看到丢包，则可能需要通过提供-B选项来增大tcpdump的缓冲区大小，以将值设置为比默认2 MB大得多的值。
不过，你可能想看看PF_RING ：
谁需要PF_RING™？
基本上每个人必须每秒处理很多数据包。 术语“许多”根据您用于stream量分析的硬件而改变。 它的范围可以从1,2GHz ARM上的80k pkt / sec到低于2.5GHz的Xeon上的14M pkt / sec以上。 PF_RING™不仅可以使您更快地捕获数据包，还可以更有效地捕获数据包，从而保护CPU周期。 只是给你一些数字，你可以看到NetFlow v5 / v9探针nProbe可以使用PF_RING™多快，或者看看下面的表格。
在Core2Duo 1.86 GHz和低端Xeon 2.5 Ghz上执行10千兆位testing
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用户指南解释如何编译和configuration启用PF_RING的libpcap库，如果您坚持使用libpcap应用程序进行数据包捕获。