Покращений пасивний захоплення пакетів:За пристроєм опитування (device polling)

Luca Deri
NETikos S. p.A.
Via Matteucci 34/b
56124 Pisa, Italy
Email: [email protected]
luca.ntop.org/

Пасивний захоплення пакетів широко використовується для налагодження і перевірки мережі. З приходом швидких гігабітних мереж захоплення пакетів стає справжньою проблемойдаже для комп’ютерів, що працюють під управлінням популярних операційних систем. Введення пристрою опитування (device polling) допомогло поліпшити процес захоплення, але не вирішило проблему повністю.
У цій статті описано новий механізм пасивного захоплення пакетів, який разом з пристроєм опитування дозволяє захоплювати і аналізувати пакети, використовуючи протокол NetFlow в гігабітних мережах, використовуючи при цьому звичайні комп’ютери.

Введення

Багато мережеві програми використовують пасивний захоплення пакетів. Принцип роботи наступний: програма захоплює пакет в пасивному режимі з мережного потоку і аналізує його для підрахунку статистики трафіку, складання звіту про використовуваних протоколів, повідомлень про помилки, мережевої безпеки і завантаженості смуги пропускання. Багато мережеві програми [TCPDUMP], [ETHEREAL], [SNORT] для захоплення пакетів використовують популярну бібліотеку [LIBPCAP], яка надає інтерфейс високого рівня для захоплення пакетів.
Основні характеристики:
*Можливість робити захоплення в різних мережних середовищах, будь то Ethernet або віртуальний інтерфейс.
*Багатоплатформність.
*Фільтрація пакетів заснована на BPF ((Berkeley Packet Filtering) яка реалізована в ядрі операційної системи для кращої продуктивності.

В залежності від операційної системи, libpcap використовує віртуальні пристрої для захоплення пакетів з середовища користувача. Незважаючи на відмінність, платформи мають схожий інтерфейс API і libpcap змінюється у відповідності з платформою. При низькій швидкості трафіку захоплення пакету не є великою проблемою, багато системи успішно виробляють захоплення всіх пакетів, але при високих швидкостях ситуація сильно змінюється. В наступній таблиці ви можете спостерігати результат тесту що проводився з використанням генератора пакетів [tcpreplay], встановленим на швидкісному хості (Двопроцесорний 1.8 GHz Athlon, мережевий інтерфейс 3Com 3c59x).

+——————————–+—————+————–+————-+
|Дод. захоплення пакетів|Linux 2.4.x..|FreeBSD 4.8.|Windows 2K|
+——————————–+—————+————–+————-+
|Стандартна Libpcap……|… 0.2 % …|34 % ………|….68 %…|
+———————————+—————+————–+————+
| Mmap libpcap …………….|…..1 %……|……………|…………..|
+———————————+—————+————–+————-+
|Модуль ядра… …….|… 4 %….|……………|…………..|
+———————————+—————-+————–+————-+

Таблиця №1 — захоплення пакетів у відсотках.

Пакети прямували на менш потужний хост (VIA C3 533 MHz, мережевий інтерфейс Intel 100Mbit) який підключений до комутатора (Cisco Catalyst 3548 XL) на швидкості 100 Мбіт.
На Cisco використовувався лічильник отриманих/відправлених пакетів на хост. Багато вважають, що статистика, яка відображається при виведенні ifconfig або netstat правдива, проте це не так, оскільки система не може захоплювати 100% трафіку, як це буде показано далі. Генератор трафіку використав всю потужність каналу (~80 пкт/сек.). Деякий трафік був захоплений передчасно, так як додаток, (PCOUNT) здійснює захоплення, було дуже простим і заснованим на libpcap. Воно лише підраховували кількість пакетів, без подальшого аналізу.

Отриманий досвід з експерименту:
*До 100 Мбіт. мережі на кінцевій точці прийому додаток для захоплення пакетів не може виконати захоплення всіх пакетів (пакети губляться).
*Протягом експерименту хост, на якому було запущено програму захоплення пакетів, не відповідав на пакети які були впроваджені в мережу хостом відправником.
*Windows з [WINPCAP] працює значно краще, ніж популярні UNIX системи.
*Популярна операційна система Linux з запущеним додатком захоплення пакетів, справлялася дуже погано, по відношенню до інших ОС.
*Libpcap-mmap [LIBPCAP-MMAP], спеціальна версія Libpcap, яка використовує системний виклик mmap () для проходження пакета в середу користувача, не поліпшило роботу в цілому.
*Використання в ядрі Linux модуля [netfilter] поліпшило роботу, але як і раніше ОС Linux втрачала найбільше пакетів. Це означає, що ОС Linux витрачає багато часу для передачі пакету від мережевого інтерфейсу в ядро, і трохи часу для передачі з ядра у середу.

Такі показники пояснюються просто — «Активний взаємний лок» (interrupt livelock) [Mogul]. Драйвер мережевої карти генерує переривання у разі, коли пристрою потрібно звернутися до ОС. (іншими словами, інформує операційну систему, про те, що отриманий пакет). У випадку з великим обсягом трафіку, система буде витрачати занадто багато часу на обробку цього переривання і мало на обробку інших. Рішенням проблеми стало «пристрій опитування» (Device Polling) [Rizzo]. Техніка «опитування» використовується в багатьох пристроях, включаючи мережевий адаптер, і працює за наступним принципом:
*Коли пристрій отримує пакет, воно генерує переривання до ядра.
*Операційна система обслуговує дане переривання наступним способом:
— Приховує майбутні переривання, що генеруються мережевою картою (тобто карта не може звернутися до ядра).
— Планувальник завдань періодично опитує пристрій, у разі необхідності.
— Карта генерує переривання так часто, як драйвер обслуговує її.

Але ця техніка також не ефективна, на практиці, вона дає операційній системі контроль над пристроями і запобігає контроль пристроїв над ядром, як у випадку з великим потоком трафіку. FreeBSD почало використовувати «пристрій опитування» починаючи з версії 4.5, в той час як Linux впроваджував це разом з NAPI (New API).Автор повторив попередній експеримент на Linux і FreeBSD (Windows не підтримує «пристрій опитування») з використанням пристрою опитування». Наступний графік показує поведінку системи при наростаючому потоці трафіку. В основному система захоплювала пакети до тих пір, поки вистачало потужності комп’ютера, і практично не видна різниця між налаштуваннями. Але як тільки система без «пристрої опитування» досягала своєї межі, вона починала втрачати пакети, так як витрачалося дуже багато часу на обслуговування переривання від мережевої карти і залишалося все менше і менше часу для інших завдань.

Результати показали, що існує точка в якій пакети в будь-якому випадку починають губитися, незалежно від того, використовується «пристрій опитування» чи ні.

Отриманий досвід з експерименту:*«пристрій опитування» дуже гарне рішення для поліпшення механізму захоплення пакетів так і для показників системи знаходиться під великим навантаженням трафіку.
*«пристрій опитування», особливо для FreeBSD, має деякі недоліки з завантаженням процесора. Більше того, різні експерименти по зміні налаштувань в ядрі (збільшений розмір HZ з 1000 до 5000), libpcap (збільшено буфер прийому pcap) і параметрів ядра (sysctl.kern.polling.*) в цілому не змінили картину як для захоплення пакетів так і для завантаження процесора.
*Навіть з опитуванням ядра, FreeBSD працює значно краще ніж Linux з libpcap.

В наступній главі розповідається, чому «пристрій опитування» це лише початкова точка для розв’язання проблеми а не остаточне рішення.

2. Позаду пристрої опитування

Як було показано в попередньому розділі, одне і теж додаток засноване на libpcap сильно відрізнялося по роботі на Linux і FreeBSD. Для зміни швидкості до Гбіт. на обох ОС використовувалася змінена stream.c (скачати можна www.securiteam.com/unixfocus/5YP0I000DG.html) як генератор трафіку (Двопроцесорний 1.8 GHz Athlon, Гбіт. мережний інтерфейс) який відсилав пакети (Pentium ІІІ 550 MHz, Гбіт. мережний інтерфейс) приєднаний на пряму. Для всіх тестів libpcap був налаштований таким чином, що б читати тільки перші 128 байт даних з пакета (параметр pcap).

|Розмір пакета…|Linux 2.6.1 з NAPI..|Linux 2.6.1 з NAPI|FreeBSD 4.8|
|(в байтах)……..|і станд. Libpcap….|і libpcap-mmap….|з «Polling»….|
|… 64……….|… 2.5 %……….|…..14.9 %……..|. 97.3 %…..|
|… 512………|… 1.1 %………|…..11.7 %… …..|… 47.3 %.|
|…….1500……..|… 34.3 %……..|… 93.5 %……..|… 56.1 %.|

Таблиця №2 — захоплення пакетів у відсотках з використанням пристрою опитування» в ядрі

Після проведення всіх тестів, автор прийшов до висновку, що:
*Linux потребує новий прорив, для ефективного захоплення пакетів в високошвидкісних мережах. Mmap версія libpcap працює краще, але як і раніше неефективно з пакетами малого розміру.
*FreeBSD працює на багато краще ніж Linux з малими пакетами, але продуктивність знижується при збільшення розміру пакета.
*Підтримка ядра «пристрої опитування» не виявилася значною при захопленні (майже) всіх пакетів при будь-якій конфігурації.

Продовжуючи робити вимірювання, створюється враження, що більша частина часу витрачається на передачу пакета з адаптера у середу через структуру ядра і черги.
Libpcap-Mmap() зменшує час руху пакета з ядра в простір користувача, але не покращує пересування пакета з адаптера до ядра. Тому автор розробив нову модель захоплення пакетів заснована на наступних припущеннях і рекомендаціях:*Розробка методів щодо поліпшення захоплення пакетів, не залежить від специфіки драйвера або архітектури операційної системи.
*Зробити мережеві адаптери більш доступні, не так вже і дорого випускати адаптери тільки для пасивного захоплення пакетів. Як перевагу, максимальний захоплення пакетів і загальна вартість залишиться колишньою.
*«Пристрій опитування» довело свою ефективність і при можливості воно має бути використане для поліпшення роботи.
*Для кращої продуктивності, необхідно уникати переміщення пакету від мережевого адаптера до ядра ОС і потім в користувальницьке простір. Замість цього, краще переміщати пакет відразу в користувальницьке простір і ідентифікувати його там, минаючи ядро ОС.
*Використання шаблонів» пакету має бути дуже ефективним. У цій libpcap «шаблон» пакетів використовується в просторі користувача, куди пакет переміщується, порівнюється і лише потім відкидається, на що витрачається дуже багато часу роботи процесора.

Ідеї, що лежать в основі цієї роботи наступні:
*Створити новий тип сокета (PF_RING) оптимізованого для захоплення пакетів в основі якого знаходиться циркулюючий буфер де вхідні пакети будуть копіюватися.
*При створення сокету буде виділятися і буфер, а при видалення, знищаться. Таким чином різні сокети будуть мати різні буфера прийому.
*Якщо PF_RING сокет буде прив’язаний до мережного адаптери (через виклик команди bind()), то в цьому випадку, адаптер буде використовувати його лише в режимі читання, до тих пір, поки сокет не буде знищений.
*Всякий раз, коли пакет надходить від мережевого адаптера (зазвичай через DMA — direct memory access) драйвер пропускає пакет на верхні рівні (в Linux це реалізовано за допомогою функцій netif_receive_skb і netif_rx, робота яких залежить від того, чи є підтримка «пристрої опитування» чи ні). У випадку з PF_RING сокетом кожен вхідний пакет копіюється в нього або відкидається при необхідності (як у випадку з шаблонами, коли певний шаблон не задовольняв умові). У разі повного буфера прийому, пакети будуть відкидатися.
*При отримання пакета для PF_RING сокета він не транспортується на верхні рівні, замість цього він копіюється в сокет і потім відкидається.
*Передача даних з буфера в користувальницьке додаток здійснюється за коштами mmap (т. е PF_RING сокет підтримує mmap).
*Клієнтська програма бажає отримати доступ до буферу, просто відкриває файл, робить виклик mmap () і отримує покажчик на буфер.
*Ядро копіює пакет в сокет (ring) і передає покажчик на запис.
Клієнтська програма робить те ж, тільки з покажчиком на читання.
Знову надійшли пакети замінюють пакети які вже прочитані користувальницьким додатком. Пам’ять не перерозподіляється, а пакети просто перезаписуються в буфер.
*Довжина буфера і розмір блоку можуть змінюватися користувачем.

+—————–+ .+——————-+
|Додаток A|..|Додаток Z..|
+——-^——–+. +———^——–+
…..mmap()… |..|корист.простр-у

ядро
+——————————————+
|index +——–+… +——–+..|
|read|socket|……………|socket|….|
|……|(ring)|…………….|(ring)|…..|
…….| |…index…….| |……|
|……..+——–+ write…+———+…|
|… ^… .^. PF_RING|
+—–|———————–|—————+
…..|……………|
…..+———————-+
……|… Мережевий…..|
……|… адаптер…..|
…………|………..|Вступники пакети
+———————-+

Рис. 2 — архітектура сокета PF_RING

Переваги розташування (ring) буфера всередині сокета очевидні:
*Пакети не стоять у черзі всередині ядра ОС.
*Mmap () надає користувачу з додатком доступ до буферу без подальших системних викликів функцій, як у випадку з сокетом.
*Навіть якщо ядро не підтримує «пристрій опитування» система залишиться працездатною навіть при великому напливі трафіку. Вся справа в тому, що час, необхідний для обробки переривання, порівняно менше, ніж для звичайної обробки пакета.
*Використання шаблонів» пакетів дуже просто і ефективно. За їх використання не потрібно переправлення пакету на верхні рівні де він буде відкинутий, як це відбувається в додатках заснованих на libpcap.
*Кілька програм можуть використовувати PF_RING буфер одночасно без шкоди один для одного.

Головна відмінність від нормального захоплення пакету в тому, що додаток, заснований на libpcap, вимагає нової компіляції за зміну (ring/mmap) версії бібліотек, так як пакет залишається в буфері а не в структурі ядра системи. Тому автор додав підтримку PF_RING в libpcap (в Linux системі libpcap використовує PF_PACKET сокет).

Згідно із запропонованими змінами в архітектурі, автор модифікував ядро Linux і додав підтримку PF_RING сокета в модуль. Нова версія ядра була випробувана в тих же умовах що і попереднє. У таблиці представлені результати:

|Розмір….|Linux 2.6.1|Linux 2.6.1|FreeBSD 4.8|………….Linux 2.6.1|
|пакета….|з NAPI і…|з NAPI……|з «Polling».|c NAPI+PF_RING…..|
|(в байтах)|Стандарт.||і libpcap-mmap ||і розширеним…….|
|………….|Libpcap…..|…………..|…………..|libpcap…………….|
+————+————-+————+————–+————————-+
|… 64…..|… 2.5 %..|…14.9 %.|… 97.3 %…|
+————-+————-+————+————-+————————-+
|… 512 ……|…1.1 %…|…11.7 %.|..47.3 %…|… 47.0 %|
+————–+————+————+————-+————————-+
|..1500…….|… 34.3 %..|… 93.5 %.|… 56.1 %..|… ..92.9 %|
+————–+————+————+————-+————————-+

Таблиця №3 — захоплення пакетів у відсотках з використанням пристрою опитування» в ядрі

Основні висновки :
*Покращений захоплення пакетів по відношенню до стандартного ядра Linux.
*З великими размету пакетами PF_RING також працює швидко як і libpcap-mmap(), але з пакетами малого і середніх розмірів набагато швидше.
*По раніше втрачається багато пакетів, особливо середніх розмірів.

Клієнтська програма має два шляхи доступу до пам’яті буфера: з підтримкою і без підтримки нового «устрою опитування» (ring polling).

+———————————————+————————————————+
Захоплення з використанням……………|Захоплення без використання………………….|
|«пристрої опитування»………………..| «пристрої опитування»………………….|
+———————————————+————————————————————+
sockFd = socket(PF_RING, SOCK_RAW|sockFd = socket(PF_RING,SOCK_RAW,…………|
htons(ETH_P_ALL);……………………|… htons(ETH_P_ALL);…………|
ringBufferPtr=mmap(NULL,ringSize,…..|…………..ringBufferPtr=mmap(NULL,ringSize,…..|
PROT_READ|PROT_WRITE,…|… PROT_READ|PROT_WRITE,……………|
MAP_SHARED,sockFd,0);……|MAP_SHARED,ckFd, 0);………………………………………|
slotId=&ringBufferPtr->slotId;|slotId=&ringBufferPtr->slotId;…………|
while(TRUE){…………………|while(TRUE){………………………………………………….|
/* Loop until a packet arrives*/|if(ringBufferPtr->slot [slotId].isFull) {……………………|
if(ringBufferPtr->slot[slotId].isFull){| readPacket(ringBufferPtr->slot [slotId]);.
readPacket(ringBufferPtr->slot [slotId]);| ringBufferPtr->slot [slotId].isFull=0;……
ringBufferPtr->slot [slotId].isFull=0;|slotId = (slotId + 1) % ringSize;…………………………
slotId=(slotId+1)%ringSize;……….|} else {……………………………………………………
}……………………………………|/* Sleep when nothing happens*/……………………….
}……………………………………|pfd.fd = fd;
………………………………|pfd.events=POLLIN|POLLERR;
……………………………………..|pfd.revents = 0;…………………………………………|
……………………………………..|poll(&pfd, 1, -1);
|…………………………………….|…………………….}
|…………………………………….|… }
+——————————————+—————————————+

Таблиця №4 — передача пакета в користувальницьке додаток з і без використання poll ().

Тести показали, що використання «polling» в користувацькому просторі не так ефективно як ми очікували. Насправді, при використання «polling» в користувацькому просторі призводить до того, що завантаження процесора становить від 12% (з пакетами по 512 байт) до 95% залишаючи зовсім небагато часу для захоплення пакета користувача додатком. Після повторення тесту кілька разів, можна зробити висновок, що використання «polling» в просторі користувача не покращує роботу в цілому або це просто непомітно. З цієї причини, тестовані «ring»-буфери використовували системний виклик «poll()», який практично не навантажує систему, в той час як використання «polling» в просторі користувача призводило до виснаження всіх ресурсів.
Автор звертає увагу на те, що під час тестів, навіть при використання PF_RING і достатнього часу центрального процесора пакети продовжують губитися. Все що дала ідея, так це те, що завантаження процесора становить всього 8 % при захопленні пакету розміром 1500 байт, при цьому втрачається лише 7 % пакетів. Це спростовує думку про те, що система повинна використовувати всі доступні ресурси процесора для захоплення пакетів. Після того, як були зроблені деякі виміри всередині ядра Linux з використанням rdtsc (Real Time Stamp Counter) «rdtsc» інструкція до процесорів Pentium яка повертає кількість тактів роботи процесора з часу його включення.” автор зауважив, що при високому рівні вхідних пакетів:
*Дурний (тобто негайне повернення результатів) виклик функції poll() дорого обходиться (більше 1000 циклів), і вартість дзвінка значно зростає із завантаженістю мережі. При великих швидкостях це означає, що поки додаток користувача очікує відповідь функції poll(), ядро відкидає пакети, так як «ring» буфер заповнений.
*Ядро блокує доступ до PF_RING і ядра, з-за великого часу очікування.

Як результат, пакети губляться, внаслідок того, що клієнтська програма блокує виклик poll(), навіть у випадку, коли система має достатньо процесорного часу. Навіть збільшення розміру буфера не допоможе в цілому, система досі непередбачувана стосовно витрат часу в період активності. З цієї причини автор вирішив знайти патч до ядра Linux який надає передбачуваність, а саме, здатність визначати завершення завдання з обмеженням за часом. Використовуючи патч (rtirq) для того, що б виставляти по пріоритетам переривання, що призводить до зниження і уточнення времtyb очікування в ядрі Linux 2.4.x. Результати тесту драматично змінилися, тепер ми можемо захоплювати всі пакети незалежно від розміру пакета. Раніше втрачаються деякі пакети з-за помилки інтерфейсу (переповнення пакета). Ще одна перевага використання патча rtirq в тому, що завантаження CPU при прийомі пакетів дуже обмежена (менше 30 %) залишаючи багато ресурсів для аналізу трафіку. В наступній таблиці представлено як nProbe 3.0, відкритий код NetFlow v5/v9 написаний автором, веде себе при підрахунку простих пакетів (Автор використовував PC для генерації трафіку, через відсутність доступу до апаратного генератора трафіка для перевірки архітектури на верхню межу. (тобто комутатор другого рівня з відключеним STP, 2 порти в петлі (loop) підключених через крос-кабель, з впровадженням широкомовних пакетів.) Як альтернатива, було запропоновано використовувати швидкість яку міг генерувати PC)

+————-+——————-+—————–+——————-+—————–+
| Розмір |Linux 2.4.23/RTIRQ |FreeBSD 4.8 |Linux 2.4.23/RTIRQ |FreeBSD 4.8 || пакета |NAPI+PF_RING |с «Polling» |NAPI+PF_RING |с «Polling» || (в байтах) |(Pkt Capture) | | (nProbe) | (nProbe) || | | | | |+————-+——————-+—————–+——————-+—————–+
| | | | | || 64 | 207603 пкт/сек | 202013 пкт/сек | 192515 пкт/сек | 142153 пкт/сек|| | | | | |+————-+——————-+—————–+——————-+—————–+
| | | | | || 512 | 172576 пкт/сек | 81691 пкт/сек | 165966 пкт/сек | 64350 пкт/сек|| | | | | |+————-+——————-+—————–+——————-+—————–+
| | | | | || 1500 | 72545 пкт/сек | 40690 пкт/сек | 72156 пкт/сек | 34986 пкт/сек|+————-+——————-+—————–+——————-+—————–+

Таблиця №5 — захоплення і аналіз пакетів (без використання шаблонів)
(Помилки інтерфейсу не включені)

Як показано на таблиці:
*Linux/RTIRQ/PF_RING ” має межу завантаження CPU, аналіз пакетів використовує NetFlow який виконує захоплення простих пакетів з дуже низькими втратами.
*Як говорилося раніше, FreeBSD набагато ефективніше перехоплює пакети, але більша завантаження CPU не дозволяє провести повний аналіз пакетів, як наприклад аналіз NetFlow, а також через обмеження по процесорного часу для користувача додатків.
*Реалізовані рішення:
— Значно зменшено шлях передачі пакету від мережевої карти до користувача додаток і зменшено навантаження на ядро.
— Процес захоплення став незалежним від розміру пакету, в період обробки в ядрі (звичайно, завантажується як PCI шина так і ядро, при рух пакету від мережевої карти до ядра, навіть якщо лише частина пакетів необхідна для аналізу).
*Стало можливим аналізувати трафік за допомогою NetFlow навіть у гігабітних мережах з використанням домашніх пк та програм для дослідження трафіку.

Що б зрозуміти граничну потужність запропонованої архітектури, було проведено кілька бета-тестів: в якості відправника використовувався той же комп’ютер, а приймає PC був замінений на Pentium 4 — 1.7 GHz з мережевою картою 32 bit Intel GE.У таблиці представлені результати тестів:

+————-+——————————–+——————————–+
| Розмір |Linux 2.4.23/RTIRQ |Linux 2.4.23/RTIRQ || пакета |NAPI+PF_RING |NAPI+PF_RING || (в байтах) |(Pkt Capture) | (nProbe) || | | |+————-+——————-+————+——————-+————+
| | | | | || 64 | 550789 пкт/сек | ~202 Мбіт | 376453 пкт/сек | ~144 Мбіт|| | | | | |+————-+——————-+————+——————-+————+
| | | | | || 512 | 213548 пкт/сек | ~850 Мбіт | 213548 пкт/сек | ~850 Мбіт|| | | | | |+————-+——————-+————+——————-+————+
| | | | | || 1500 | 81616 пкт/сек | ~970 Мбіт | 81616 пкт/сек | ~970 Мбіт|+————-+——————-+————+——————-+————+

Таблиця №6 — Оцінка PF_RING (Pentium 4 — 1.7 GHz з мережевою картою 32 bit Intel GE)

Як показано в таблиці, NetFlow обмежений у використанні CPU і це зменшує втрату з маленькими пакетами, тоді як середні і великі за розміром пакета в основному не втрачаються. Помилок на приймаючому інтерфейсі значно менше по відношенню до попередніх установок; ймовірно вони можуть бути знижені до нуля, при використанні 64-бітного мережевого адаптера на приймаючій стороні.Враховуючи те, що зазвичай гігабітні мережі мають величезний (>=9000) MTU, використання PF_RING є прекрасним рішенням для аналізу трафіку в цьому середовищі. Більш того, варто помітити в таблиці №6, що використання повільного комп’ютера на кінці набагато краще, ніж високошвидкісного роутера які представлені на ринку.

3. Робота в майбутньому.

Зараз, PF_PACKET реалізований на Linux 2.4.* і 2.6.*. Автор хотів би перенести цю роботу під FreeBSD, щоб подивитися, чи можуть поліпшення зроблені під Linux перенестися на інші операційні системи. Тим не менш, на даний момент не планується ніякого додавання (навіть мінімального) для FreeBSD, це могло торкнутися показники в нашій роботі.

А так же :
*Положення даної роботи по відношенню до комерційних мережних карт, таких як DAG.
*Оцінити роботу запропонованої архітектури в 10 гігабітних мережах використовуючи швидкі PC.

4. Останнє зауваження.

У цій статті описана розробка і реалізація нового механізму захоплення пакетів, мета якого покращити процес захоплення пакетів в гігабітних мережах.
Процес демонстрував, що:
*Новий тип сокетів, на додаток до змін у ядрі Linux, значно покращує процес захоплення пакетів, при швидкості 100 Мбіт так і 1000 Мбіт.Тепер стає можливим захоплення пакетів з 1000 Мбіт середовищі при цьому використовуючи домашні PC.
*Клієнтська програма, що використовує «ring» буфер, працює набагато швидше, ніж аналогічний модуля ядра без використання «ring» коду запущений на тому ж PC з тим же ядром.
*Втрати пакетів при гігабітних швидкостях дуже малий, навіть якщо використовувати PC з обмеженою процесорної потужністю.

На закінчення можна сказати, що тепер можливо аналізувати трафік в гігабітних мережах, використовуючи комерційний протоколу NetFlow разом з користувальницьким PC без необхідності придбання дорогого устаткування. Коли 10 гігабітні карти стануть дешевше, дослідження будуть відновлені, що б подивитися як реалізація даної архітектури буде працювати при 10 гігабітних швидкостях.

5. Доступність.

Ця робота розповсюджується під ліцензією GPL2 і може бути вільна приклад був викачаний з домашньої сторінки «ntop» (http://www.ntop.org/), або з одного з дзеркал і Інтернеті (http://sourceforge.net/projects/ntop/).

Переведено by: ilya
Спеціально для HackZona.ru