Создание TCP вывести без пакетной потери
Как заставить TCP вывести, где гарантируется, что все пакеты, которые действительно проходят через сеть, получены, и ничто не пропущено?
Подробнее: У нас есть проблема со сторонним поставщиком, который предоставляет решение сверху стека SCTP, который он также реализует.
Под довольно высокой пропускной способностью (52 000 сообщений/секунда, средний размер сообщения составляет 500 байтов), повреждения ссылки SCTP.
Мы полагаем, что ошибка находится в стеке SCTP поставщика.
Но поставщик говорит, это происходит, потому что стек SCTP отправляет сообщение, не получает ACK на нем, отправляет, много ретранслируют, не получают ACKs на них также и закрывают ссылку SCTP.
Таким образом, поставщик говорит, это - сеть, которая виновна, потому что она теряет пакеты.
В дампах TCP с обеих сторон, клиент и сервер мы видим, что исходные сообщения достигают сервера, и посмотрите, что сервер не отвечает ACK. Но поставщик говорит, что дампы TCP не надежны, что при получении дампа TCP, некоторые пакеты не могли быть получены, потому что libpcap библиотека работает только в одном аппаратном потоке, его питания может быть недостаточно для входа всех пакетов.
Технические данные: 52 000 сообщений/секунда, средний размер сообщения составляет 500 байтов, таким образом, 26 МБ/с всего, 4 ссылки SCTP используются.
Оборудование: ЦП E5-2670, 2,6 ГГц, 8 потоков HW
Сеть: 10 GBit, трафик между блейдами HP, которые расположены в одной стойке.
RHEL 6.
При вашем объеме трафика я бы утверждал, что libpcap не должен испытывать проблем с брошенными пакетами, если только у вас нет особенно неэффективной установки. Если вы используете tcpdump для перехвата, то он будет сообщать о количестве пропущенных пакетов в своей конечной выходной линии. Если вы видите выпавшие пакеты, вы можете захотеть увеличить размер буфера tcpdump, поставив опцию -B, чтобы установить значение, значительно превышающее 2 МБ по умолчанию.
Тем не менее, вы можете посмотреть на PF_RING:
Кому нужен PF_RING™?
В основном, каждому, кто должен обрабатывать большое количество пакетов в секунду. Термин много" изменений в зависимости от аппаратного обеспечения, которое вы используете для анализа трафика. Он может варьироваться от 80k pkt/sec на ARM с частотой 1,2 ГГц до 14M pkt/sec и выше. на низкочастотной 2,5 ГГц "Сон". PF_RING™ не только позволяет делать снимки. Пакеты быстрее, он также захватывает пакеты более эффективно сохраняя Циклы процессора. Просто чтобы дать вам некоторые цифры, вы можете увидеть, как быстро nProbe, зонд NetFlow v5/v9, можно использовать PF_RING™, или посмотреть на Таблицы ниже.
10 Гигабитные тесты, выполненные на Core2Duo 1,86 ГГц и низкоскоростной 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 объясняет, как скомпилировать и настроить библиотеки libpcap с поддержкой PF_RING, если вы настаиваете на использовании libpcap-приложений для захвата пакетов.