Zarządzanie ruchem wymiany plików peer-to-peer

Popularność aplikacji wymiany plików peer-to-peer (P2P) w ostatnich kilku latach osiągnęła rozmiary astronomiczne. Analizy wskazują, że P2P stanowi ponad 50-60% całego ruchu w sieci. Teoretycznie dochody operatora rosną, ale zwiększają się również wydatki na utrzymanie infrastruktury oraz koszt łączy do Internetu. Problemem jest także to, że P2P równie często jest wykorzystywane do wymiany plików przez pracowników firm.

Popularność aplikacji wymiany plików peer-to-peer (P2P) w ostatnich kilku latach osiągnęła rozmiary astronomiczne. Analizy wskazują, że P2P stanowi ponad 50-60% całego ruchu w sieci. Teoretycznie dochody operatora rosną, ale zwiększają się również wydatki na utrzymanie infrastruktury oraz koszt łączy do Internetu. Problemem jest także to, że P2P równie często jest wykorzystywane do wymiany plików przez pracowników firm.

Przy powszechnej asymetrii ruchu w obecnie dominujących technologiach dostępowych (DSL, sieci kablowe), wymiana plików doprowadza do symetrii ruchu przychodzącego i wychodzącego. Bardzo często większą część ruchu P2P generuje ok. 10% klientów, uniemożliwiając poprawne działanie popularnych usług internetowych. Aplikacje P2P działają w tle, więc nie wymagają interaktywności użytkownika. W sieciach korporacyjnych powodują ogólne zmniejszenie wydajności sieci, a także ograniczają możliwość kontroli legalności instalowanego oprogramowania.

O ile całkowita blokada usług P2P jest sensownym i koniecznym rozwiązaniem w sieciach korporacyjnych, o tyle w sieciach komercyjnych jest wręcz niemożliwa. Wszelkie próby ograniczania powodują wzrost niezadowolenia użytkowników, a w rezultacie rezygnację z oferowanych usług. Oczywiście, pewnym rozwiązaniem jest zwiększanie przepustowości łączy do Internetu oraz inwestycje w wydajniejszy sprzęt sieciowy. Zdecydowanie lepszą metodą jest jednak inteligentne monitorowanie, nadzorowanie i ograniczanie ruchu P2P. Zysk to nie tylko oszczędności, ale również kontrola nad użytkownikami sieci wymiany plików.

Trochę historii

Architektura centralna P2P

Architektura centralna P2P

Pierwszą internetową aplikacją P2P był stworzony w maju 1999 r. przez Shawna Fanninga program o nazwie Napster. Strukturę sieci stworzonej przez Napstera można uznać za scentralizowaną, co oznacza, że tworzyły ją dwa elementy: centralny indeks zasobów oraz węzły P2P (peers). Projekt ten można uznać za pierwszą generację internetowych sieci P2P.

Centralne serwery indeksujące magazynowały informacje o udostępnianych plikach muzycznych. Serwery stanowiły centralne jednostki i były konfigurowane przez twórców programu.

Wymiana plików przebiegała zawsze według następującego schematu. Kiedy aktywny peer chciał ściągnąć plik muzyczny, wysyłał zapytanie do centralnego serwera Napster, który odsyłał zwrotnie informację o węzłach udostępniających dany plik. Po uzyskaniu tych informacji peer łączył się z innymi węzłami bezpośrednio, uzyskując dostęp do poszukiwanych danych.

Wadą sieci Napster była centralna architektura. W przypadku gdy centralne serwery były z różnych powodów nieaktywne, cała sieć stawała się bezużyteczna. Przypadek niepowodzenia Napstera miał świetny wpływ na rozwój aplikacji P2P.

Decentralizacja sieci

Architektura hybrydowa P2P

Architektura hybrydowa P2P

Z powodów prawnych, bezpieczeństwa, skalowalności, anonimowości, coraz więcej aplikacji P2P pracuje obecnie w całkowicie lub częściowo zdecentralizowanej strukturze. Wszystkie główne protokoły wymiany plików, takie jak eDonkey, Kad, FasTtrack, Overnet opierają się na tej koncepcji.

Decentralizacja oznacza strukturę sieci bez dedykowanego centralnego serwera indeksującego. Obecnie wiele systemów P2P używa własnej sieci i protokołu, ale ich sieciowa struktura jest całkowicie lub częściowo zdecentralizowana. Niektóre aplikacje P2P, takie jak eMule i eDonkey, wspierają w pełni zdecentralizowany protokół, taki jak Kademlia, który nie potrzebuje centralnego serwera.

W zdecentralizowanej sieci nadal jest potrzebny serwer, ale nie musi być on dedykowany ani statyczny. Niektóre węzły o większej mocy, lepszym łączu dostępowym itp. będą automatycznie przejmowały funkcje centralnych serwerów indeksujących. Taki ultrapeer jest komputerem wybranym spośród innych węzłów i obsługującym ich grupę.

Utworzone w ten sposób serwery komunikują się ze sobą, tworząc szkielet hybrydowej, zdecentralizowanej sieci. Aby przyłączyć się do sieci, peer musi znaleźć drogę do połączenia z jednym lub kilkoma serwerami. Pobiera on ich listę, wykorzystując dane zapisane w programie lub stronę internetową. Po połączeniu z serwerem aplikacja P2P musi stale komunikować się z siecią P2P - w celu sprawdzania dostępnych serwerów itp. W odróżnieniu od typowego transferu pobieranie plików przez sieć P2P wymaga od klienta ciągłej kontroli sytuacji w zmiennym czasowo środowisku.

Jak działają popularne sieci P2P?

Dominującym obecnie środowiskiem P2P są hybrydowe, najczęściej zdecentralizowane sieci. Rozpoznanie popularnych sieci P2P nie jest łatwe. Opiera się głównie na analizie pakietów w warstwie aplikacji i badaniu etapu nawiązywania połączenia oraz transferu plików. Standardowo realizowane są następujące dwie fazy w przypadku pobierania pliku przez sieć P2P:

  • sygnalizacja - w czasie fazy sygnalizacji klient szuka zawartości i określa, które węzły są w stanie ją udostępnić. W przypadku użycia wielu protokołów nie jest możliwa bezpośrednia komunikacja z węzłami, które będą dostarczały zawartość.

  • pobieranie - w tej fazie host kontaktuje się z jednym lub kilkoma węzłami bezpośrednio, pobierając zawartość.

Bardzo popularną siecią P2P jest obecnie eDonkey, głównie za sprawą aplikacji klienta sieci o nazwie eMule. Sieć eDonkey składa się z klientów oraz serwerów. Każdy klient jest podłączony do własnego serwera przez protokół TCP. W fazie sygnalizacji jest wysyłane zapytanie wyszukiwania do danego serwera. Opcjonalnie klient może przez UDP wysłać bezpośrednie zapytanie wyszukiwania do innych serwerów (rozszerzone wyszukiwanie w eDonkey). Po otrzymaniu zapytania centralny komputer przeszukuje spis udostępnionych plików i odsyła do pytającego odpowiedź, kto posiada poszukiwane zbiory. Aby pobrać plik, należy ustanowić połączenie do znalezionego węzła bezpośrednio przez protokół TCP.

Architektura rozproszona P2P

Architektura rozproszona P2P

Sieć eDonkey wprowadziła dodatkową funkcjonalność - hashowanie. Zabezpieczenie to tworzy sumę kontrolną obliczaną na podstawie zawartości pliku. Klient, pobierając plik oraz jego sumę kontrolną, może stwierdzić poprawność pobranego zbioru. Funkcja ta jest wykorzystywana także w technice Intelligent Corruption Handling (ICH), umożliwiającej zmniejszenie ilości danych niezbędnych do ponownego pobrania, w przypadku uszkodzenia pliku.

Protokół eDonkey umożliwia także wznawianie połączeń. Pobierany plik jest sprawdzany pod kątem poprawności sumy kontrolnej, a następnie jest dzielony na małe fragmenty. Opcja umożliwia jednoczesne pobieranie danego pliku w częściach od wielu użytkowników.

Nie mniej popularna niż eDonkey jest sieć Kazaa z rozproszoną i samoorganizującą się strukturą. W sieciach Kazaa klienci z szybkimi łączami oraz mocnymi komputerami są automatycznie selekcjonowani jako supernodes (superwęzły). W typowej sytuacji klient łączy się z sąsiednim superwęzłem, aby przekazać informacje o plikach, które udostępnia, oraz w celu uruchomienia przeszukiwania. Aplikacja Kazaa wysyła dość charakterystyczne komunikaty. Wiadomość wywołująca pobieranie w Kazaa zawiera następujący nagłówek http:

GET /.files HTTP/1.1\r\n

Host: IP address/port\r\n

UserAgent: KazaaClient\r\n

X-Kazaa-Username: \r\n

X-Kazaa-Network: KaZaA\r\n

X-Kazaa-IP: \r\n

X-Kazaa-SupernodeIP: \r\n

Odpowiedź Kazaa zawiera następujący nagłówek http:

HTTP/1.1 200 OK\r\n

Content-Length: \r\n

Server: KazaaClient\r\n

X-Kazaa-Username: \r\n

X-Kazaa-Network: \r\n

X-Kazaa-IP: \r\n

X-Kazaa-SupernodeIP: \r\n

Content-Type: \r\n

W nowszych wersjach Kazaa peer może wysłać krótki szyfrowany komunikat przed przesłaniem powyższej odpowiedzi. Ważną informacją jest to, że obie wiadomości zawierają pole o nazwie X-Kazaa-SupernodeIP. Pole określa adres IP komputera superwęzła, do którego peer jest podłączony, włączając w to port usługi TCP/UDP supernode. Przedstawione informacje mogą zostać użyte do identyfikacji sygnalizacji przy użyciu zapisu ruchu całej komunikacji.

Dość nietypową strukturą jest sieć BitTorrent, ponieważ brak w niej sygnalizacji komunikacji przy wyszukiwaniu. Struktura zawiera klientów oraz centralne serwery. Klienci łączą się ze sobą bezpośrednio w celu wysyłania i odbierania porcji pojedynczych plików. Centralny serwer (nazywany tracker) koordynuje działania klientów oraz zarządza połączeniami. Serwer BitTorrent nie odpowiada za lokalizację wyszukanych dla klienta plików. Sieć lokalizuje pliki przez strony webowe, a połączenie jest inicjowane przez wskazanie odnośnika.