Podsumowując - sześć produktów uzyskało zadowalające wyniki po uruchomieniu testu mierzącego przepływność pierwotną (Rys. 1). Zapory firm TopLayer, Nokia i NetScreen pracowały z szybkością ok. 120 Mb/s (krótkie pakiety) i 200 Mb/s (długie pakiety), z tym że w przypadku obsługi krótkich pakietów zapory TopLayer i Nokia spisywały się nieco lepiej (130 Mb/s) niż zapora NetScreen (120 Mb/s).

Natomiast zapora NetScreen-100 wyprzedziła znacznie zapory AppSwitch 3500 (TopLayer) i IP650 (Nokia) po wyliczeniu opóźnień szczytowych. Opóźnienie to było w przypadku zapory AppSwitch 3500 siedem razy większe, a w przypadku IP650 sześć razy większe niż w przypadku NetScreen-100. Oczywiście im większe jest to opóźnienie, tym niższa jest wydajność zapory.

Kolejne trzy miejsca w tej kategorii oceny (przepływność pierwotna) zajęły produkty firm Cisco, Lucent i CyberGuard. Zapory te, obsługując krótkie pakiety, pracowały z szybkością 50-70 Mb/s; obsługując długie pakiety z szybkością 200 Mb/s. Ze względu na platformę (SCO Unix i standardowy komputer PC) na szczególne uznanie zasługuje zapora KnightStar (CyberGuard). Spisywała się ona lepiej niż niejedno rozwiązanie oparte na dedykowanej warstwie sprzętowej.

Wymieniona powyżej szóstka zapór wyraźnie przewodzi całej stawce. Jeśli więc zależy nam przede wszystkim na wydajności, warto wybrać jedną z nich.

Są takie zapory (rozwiązania firm Enternet, Secure Computing i WatchGuard), które obsługują długie pakiety z szybkością 200 Mb/s, ale ich przepływność bardzo wyraźnie spada, gdy zaczynają obsługiwać krótkie pakiety. Najpierw więc należy w miarę dokładnie określić długość pakietów krążących po naszej sieci, a następnie przystąpić do wyboru zapory, biorąc pod uwagę wyniki podane przez nasz test.

Obsługa połączeń masowych

Drugi test sprawdza, jak zapora radzi sobie z bardzo dużą liczbą połączeń TCP. Test bada, czy zapora nie gubi wtedy pakietów albo nie retransmituje ich. Możliwość obsługi dużej liczby połączeń TCP to szczególnie pożądana cecha zapór chroniących wiele serwerów webowych. Protokół TCP został bowiem tak zaprojektowany, że utraty pakietów (albo duże opóźnienia występujące podczas ustanawiania połączenia) są szczególnie dotkliwe dla klientów korzystających z usług serwera webowego. Widać to wyraźnie w przypadku aplikacji webowych, kiedy jedna strona może się składać z kilkunastu, a niekiedy nawet z kilkudziesięciu elementów, a każdy z nich wymaga oddzielnego połączenia z serwerem.

Testy symulowały różną liczbę połączeń TCP (od 25 000 do 120 000) i różne szybkości (od 100 do 15 000 połączeń na sekundę). Serwer webowy akceptujący np. 100 połączeń TCP na sekundę obsłuży po ośmiu godzinach pracy prawie 3 mln połączeń.

Trzy czwarte testowanych zapór uzyskało zadowalające wyniki, obsługując co najmniej 500 połączeń na sekundę. Pomiary prowadzono dla ruchu dwukierunkowego, dotyczą więc połączeń przychodzących i wychodzących. Na początku uruchomiono test generujący 100 i 1000 połączeń na sekundę (ruch jednokierunkowy; tylko połączenia wychodzące), po to, aby skonfigurować w odpowiedni sposób zaporę i upewnić się, że wszystko pracuje poprawnie. Tylko połowa urządzeń radzi sobie z ruchem dwukierunkowym generowanym z szybkością 10 000 połączeń na sekundę. Serwer webowy może przy takim ruchu obsłużyć w ciągu jednego miesiąca 25 mld żądań. Tylko niewiele przedsiębiorstw ma takie wymagania. Dla większości wystarczy wydajność ok. 1 mld żądań na miesiąc, co odpowiada 500 połączeniom na sekundę. Większość testowanych produktów spełnia takie wymaganie.