Niedzielny ciąg dalszy Sesji Linuksowej: filtrowanie pakietów
Wczorajsza sesja traktowała między innymi o alternatywnych użyciach interfejsów sieciowych, pozwalających na ominięcie, a przynajmniej przechytrzenie, domyślnego stosu TCP/IP. Przewaga owych alternatyw wynika ze słabości niskopoziomowych implementacji BSD Sockets, które pojawiają się dopiero przy bardzo wysokim obciążeniu.
Zalogowani mogą więcej
Możesz zapisać ten artykuł na później. Znajdziesz go potem na swoim koncie użytkownika
Nic więc nie dolega klasycznym socketom. Co więcej, Maciej Czekaj podkreślał, że ich implementacja jest bardzo dobra. Dlatego wartościową wiedzą jest znajomość funkcjonalności dostarczanych przez sieciowe narzędzia z Berkeley. Nie tylko samych socketów, ale także narzędzi obsługi strumieni, jak Berkeley Packet Filter. Ich temat przybliża Michał Rostecki.
BPF do filtrowania wykorzystuje bytecode, czyli skompilowaną, wydajną postać instrukcji do interpretowania przez oprogramowanie (dla przykładu, skryptowy język Python dla zwiększenia wydajności stosuje kompilacje do plików bytecode'owych PYC). Pozwala to zwiększyć prędkość przetwarzania danych, a także – co odbywa się dzięki działaniu bliżej sprzętu sieciowego – otrzymywać od razu wyfiltrowane dane, bez konieczności grzebania w nich w przestrzeni użytkownika.
Prelekcja skupia się na wyczuwanych intuicyjnie, acz niekoniecznie oczywistych przewagach, jakie ma BPF względem mechanizmu netfilter i ich konsekwencji dla iptables. Warstwa BPF wprowadza do socket API nowy typ pakietu, zwany AF_XDP (w ramach projektu Cilium). Ze względu na warstwę, na której działają, definicje BPF mogą zastąpić netfilter swoim dedykowanym filtrem bpfilter. Dla narzędzi takich, jak /sbin/iptables jest to zmiana przezroczysta, a więc niezauważalna dla administratora oraz... wyższych warstw, jak firewalld.
