Optymalizacja parametrów konfiguracyjnych protokołu TCP

Transkrypt

1 Rok akademicki 2013/2014 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki PRACA DYPLOMOWA INŻYNIERSKA Marek Piotr Bajor Optymalizacja parametrów konfiguracyjnych protokołu TCP Opiekun pracy mgr inż. Paweł Radziszewski Ocena: Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

2 Kierunek: Specjalność: Informatyka Inżynieria Systemów Informatycznych Data urodzenia: 18 kwietnia 1991 r. Data rozpoczęcia studiów: 1 października 2010 r. Życiorys Urodziłem się 18 kwietnia 1991 r. w Myszkowie. W latach uczyłem się w Szkole Podstawowej nr 3 im. T. Kościuszki w Myszkowie, a następnie do roku 2007 w Gimnazjum nr 3 im. C.K. Norwida w Myszkowie, w którym przez dwa lata pełniłem funkcję Przewodniczącego Samorządu Uczniowskiego. W 2010 r. ukończyłem Liceum Ogólnokształcące im. mjr. H. Sucharskiego w Myszkowie, gdzie uczęszczałem do klasy o profilu matematyczno-fizycznym. Po zdaniu egzaminu maturalnego, w październiku 2010 r. rozpocząłem studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej, na kierunku Informatyka. Na piątym semestrze studiów wybrałem specjalizację Inżynieria Systemów Informatycznych. Po III roku studiów odbyłem praktykę zawodową w Centrum Badawczo-Rozwojowym Samsung Polska. Poza informatyką, moją pasją jest transport publiczny, w szczególności kolejowy.... Podpis studenta EGZAMIN DYPLOMOWY Złożył egzamin dyplomowy w dniu... z wynikiem... Ogólny wynik studiów:... Dodatkowe wnioski i uwagi Komisji:

3 STRESZCZENIE W niniejszej pracy zaprezentowano wpływ wartości parametrów konfiguracyjnych protokołu TCP w systemie Linux na wydajność działania protokołu w różnych środowiskach sieciowych, takich jak sieci przewodowe oraz sieci bezprzewodowe i mobilne. Skupiono się głównie na różnych algorytmach kontroli przeciążeń. Na podstawie pomiarów wydajności łączy, przeprowadzonych w środowisku symulującym różne metody dostępu do sieci, opracowano profile konfiguracyjne mające na celu zwiększenie wydajności protokołu w zależności od używanego środowiska sieciowego. Stworzono także prosty program z graficznym interfejsem użytkownika umożliwiający łatwe wprowadzanie zmian w konfiguracji protokołu TCP w systemie Linux. Słowa kluczowe: TCP, optymalizacja, parametry, konfiguracja, wydajność, Linux OPTIMIZATION OF TCP CONFIGURATION PARAMETERS The thesis presents how different values of TCP configuration parameters in Linux operating system affect performance of the protocol, used in various network environments, such as: wired networks or wireless and mobile networks. The focus is mainly on the impact of various congestion control algorithms. Based on measurements that were performed using the simulated network environments, configuration profiles were prepared. The profiles are intended to improve the TCP performance, depending on the network environment. Also a simple program with a graphical user interface that allows easy setup of TCP parameters on Linux was created. Keywords: TCP, optimization, parameters, configuration, performance, Linux

4 Spis treści 1. Wprowadzenie Cel i układ pracy Charakterystyka protokołu TCP Cechy protokołu TCP Format nagłówka TCP Otwieranie i zamykanie połączenia TCP Kontrola przepływu Kontrola przeciążenia Slow start (powolny start) Congestion avoidance (unikanie przeciążenia) Fast retransmit (szybka retransmisja), fast recovery (szybkie odtworzenie) Selective Acknowledgements (SACK) TCP NewReno Forward Acknowledgements (FACK) TCP BIC i TCP CUBIC TCP Vegas TCP Veno TCP Westwood HighSpeed TCP TCP Hybla Dostosowanie protokołu TCP do różnych środowisk sieci Sieci przewodowe Sieci LAN Sieci WAN Możliwe usprawnienia Sieci bezprzewodowe Sieci WLAN (WiFi) Sieci komórkowe Możliwe usprawnienia Implementacja protokołu TCP w systemie Linux Parametry konfiguracyjne

5 5. Dokumentacja projektowa Specyfikacja wymagań Opis słowny aplikacji Słownik pojęć Wymagania funkcjonalne Wymaganie niefunkcjonalne Projekt aplikacji Diagramy klas Diagramy sekwencji Implementacja, testowanie Implementacja Testowanie Analiza możliwości optymalizacji działania protokołu TCP Badanie wydajności protokołu TCP Przypadki testowe Pomiar parametrów różnych środowisk sieci Symulowanie różnych środowisk sieci Wydajność domyślnej konfiguracji protokołu TCP Wpływ parametrów konfiguracyjnych protokołu na jego wydajność Metodologia pomiarów Pomiary wydajności protokołu po zmianie wartości jednego parametru Propozycje profili konfiguracyjnych dla różnych środowisk sieci Wydajność proponowanych profili konfiguracyjnych Podsumowanie Bibliografia Instrukcja użytkowania programu Optymalizacja TCP

6 1. Wprowadzenie We współczesnym świecie przetwarzanie i przesyłanie informacji odgrywają bardzo ważną rolę. Ilość danych przesyłanych przez ludzi między sobą nieustannie rośnie. Powoduje to konieczność zapewnienia coraz większej dostępności usług telekomunikacyjnych związanych z przesyłaniem informacji. Postępujący rozwój elektroniki i telekomunikacji spowodował, że, poza dostępem przewodowym do sieci Internet, coraz powszechniejszy staje się dostęp bezprzewodowy i mobilny. Mobilny dostęp do Internetu, daje możliwość korzystania przesyłania informacji z dowolnego miejsca pokrytego zasięgiem sieci komórkowych. Ponadto, zarówno w przypadku dostępu przewodowego, jak i bezprzewodowego można uszczegółowić używane środowiska sieciowe: np. LAN czy DSL jako sieci przewodowe oraz WLAN, EDGE czy HSPA+ wśród sieci bezprzewodowych i mobilnych. Każdy z wymienionych typów sieci charakteryzuje się innymi parametrami. Sieci przewodowe na ogół charakteryzują się niewielkimi opóźnieniami i wysokimi przepływnościami. W sieciach bezprzewodowych opóźnienia są większe, a dostępne pasmo mniejsze. Popularny protokół komunikacyjny TCP, wykorzystywany do nawiązywania połączeń podczas korzystania z sieci Internet, w momencie powstania zaprojektowany był do działania w sieciach przewodowych. Nie przewidywano wówczas zjawiska przeciążenia sieci, które bardzo negatywnie wpływa na działanie protokołu. Rozwój Internetu oraz metod dostępu spowodował, że powstało wiele rozszerzeń i modyfikacji tego protokołu, mających na celu dostosowanie go do wydajnego działania w różnych środowiskach sieciowych. Opracowane odmiany oraz dodatkowe opcje protokołu TCP pozwalają na osiągnięcie lepszej wydajności, w zależności od używanej metody dostępu do sieci. Jednocześnie mnogość parametrów konfiguracyjnych może powodować, że dobranie odpowiednich ich wartości dla danego środowiska może być zadaniem nieoczywistym Cel i układ pracy Celem niniejszej pracy było zbadanie wydajności działania protokołu TCP w różnych środowiskach sieciowych, jak: sieć LAN, sieć WLAN, łącze DSL, sieć EDGE, sieć HSPA+ oraz sieć UMTS o ograniczonej przepustowości, przy zastosowaniu różnych wartości parametrów konfiguracyjnych protokołu TCP w systemie Linux. Na podstawie otrzymanych wyników opracowano zestawy wartości parametrów, zwanych profilami, mających na celu zastosowanie optymalnych nastaw parametrów w zależności od typu łącza używanego do połączenia z siecią. Ponadto, w języku Java stworzony został prosty program z interfejsem graficznym, pozwalający na szybkie zastosowanie wybranego profilu w konfiguracji systemu Linux. 6

7 Rozdział drugi opisuje zasady działania protokołu TCP. Opisano w nim podstawowe cechy protokołu, format nagłówka pakietu, sposób nawiązywania i zamykania połączenia, problem kontroli przepływu oraz problem kontroli przeciążeń wraz z krótkimi opisami opracowanych modyfikacji protokołu, stanowiącymi różne podejścia do zapobiegania wystąpienia zjawiska przeciążenia sieci. W rozdziale trzecim opisano problemy występujące podczas korzystania z połączeń TCP w sieciach przewodowych i bezprzewodowych. Kolejny rozdział zawiera opis implementacji protokołu TCP w systemie Linux wraz z opisem poszczególnych parametrów konfiguracyjnych. Rozdział piąty to dokumentacja projektowa powstałej aplikacji, służącej do łatwego manipulowania wartościami parametrów konfiguracyjnych. W rozdziale szóstym opisano pomiary wydajności protokołu oraz opracowanie profili konfiguracyjnych. 7

8 2. Charakterystyka protokołu TCP Protokół TCP (ang. Transmission Control Protocol protokół sterowania transmisją) to połączeniowy, strumieniowy, niezawodny protokół komunikacyjny, będący ważną częścią rodziny TCP/IP [1]. Jest on standardową metodą gwarantowanego dostarczenia danych. TCP działa w trybie klient-serwer: serwer oczekuje na nawiązanie połączenia, klient inicjuje połączenie do serwera. W przeciwieństwie do protokołu UDP, TCP gwarantuje poprawne dostarczenie wszystkich pakietów w całości, w określonej kolejności Cechy protokołu TCP Podstawowymi cechami protokołu TCP są [1]: Obsługa wielu strumieni danych od różnych aplikacji (multipleksowanie) protokół TCP umożliwia korzystanie z usług komunikacyjnych wielu aplikacjom, uruchomionym na jednej stacji. Protokół TCP musi zatem być zdolny do jednoczesnego przyjmowania danych od wielu procesów oraz odbierania danych przeznaczonych dla wielu aplikacji. Identyfikacja aplikacji docelowych dla odbieranych pakietów jest możliwa dzięki numerom portów. Połączenie przed rozpoczęciem transmisji, następuje logiczne nawiązanie połączenia, zestawienie wirtualnego obwodu między urządzeniami. Każde połączenie ma dokładnie dwa końce. Protokół TCP nie wspiera modelów transmisji multicast oraz broadcast. Niezawodność protokół wykrywa uszkodzenie, utratę, powielenie lub zmianę kolejności danych. Dopóki odbiorca nie potwierdzi poprawnego otrzymania danych, nadawca przechowuje ich kopię, aby była możliwa ewentualna retransmisja w przypadku wystąpienia błędów w transmisji. Kontrola przepływu umożliwia dostosowanie szybkości transmisji do możliwości przetwarzania przez odbiorcę otrzymywanych danych. Strumieniowość protokół TCP jest protokołem strumieniowym, mimo że opiera się on na transmisji pakietowej. Aplikacja wysyła ciągłą sekwencję oktetów, natomiast dane nie muszą być dostarczone do odbiorcy w takich samych fragmentach jak wysłane przez nadawcę Format nagłówka TCP Nagłówek protokołu TCP standardowo ma długość 20 bajtów, może być rozszerzony o pole opcji. Po nagłówku występują dane aplikacji. Budowa nagłówka TCP przedstawia się następująco: Port źródłowy (ang. source port) [16 bitów] numer portu źródłowego. 8

9 Port docelowy (ang. destination port) [16 bitów] numer portu docelowego. Numer sekwencyjny (ang. sequence number) [32 bity] numer sekwencyjny pierwszego oktetu danych segmentu. Wartość jest generowana i unikalna dla każdego połączenia, w celu wyeliminowania możliwości błędnej interpretacji danych opóźnionych poprzedniego połączenia jako poprawnych danych połączenia bieżącego. Numer sekwencyjny jest konieczny do ustalenia kolejności otrzymywanych danych. Numer potwierdzenia (ang. acknowledgment number) [32 bity] za pomocą tego pola odbiorca potwierdza poprawność odebrania danych. Numer potwierdzenia jest o 1 większy niż numer sekwencyjny ostatniego oktetu danych, co jest równoważne numerowi sekwencyjnemu kolejnego, spodziewanego przez odbiorcę segmentu. Długość nagłówka (ang. header offset) [4 bity] pole określa długość nagłówka TCP wyrażoną w liczbie 32-bitowych słów. W przypadku standardowego nagłówka, niezawierającego dodatkowych opcji, wartość pola wynosi 5. Zarezerwowane (ang. reserved) [3 bity] bity zarezerwowane na przyszłe potrzeby lub do celów eksperymentalnych. Znaczniki (ang. flags) [9 bitów] dziewięć jednobitowych znaczników, określających dodatkowe opcje: o NS (ang. nonce sum) suma kontrolna znaczników ECN, o CWR (ang. Congestion Window Reduced) znacznik potwierdzający odebranie powiadomienia ECE przez nadawcę, o ECE (ang. Explicit Congestion Notification Echo) znacznik ustawiany przez odbiorcę w momencie otrzymania pakietu z informacją o przeciążeniu sieci, o URG (ang. urgent) wskaźnik pilności zawiera dane, o ACK (ang. acknowledgment) pole potwierdzenia zawiera dane, o PSH (ang. push) operacja wypchnięcia danych, o RST (ang. reset) przerwanie połączenia, o SYN (ang. synchronize) synchronizacja przy ustanawianiu nowego połączenia, o FIN (ang. finished) ostatni segment wysłany przez nadawcę. Rozmiar okna odbiorcy (ang. window size) [16 bitów] określa dostępne miejsce w buforze odbiorcy. Rozmiar okna odbiorcy jest wykorzystywany przez nadawcę do celów kontroli przepływu. Suma wartości tego pola oraz numeru potwierdzenia określa największy numer sekwencyjny, który odbiorca jest w stanie odebrać. Suma kontrolna (ang. checksum) zabezpiecza segment przed uszkodzeniem. Suma kontrolna wyliczana jest na podstawie nagłówka TCP, danych aplikacji 9

10 oraz pseudonagłówka składającego się z adresu źródłowego i docelowego IP oraz długości nagłówka IP. Wskaźnik pilności (ang. urgent pointer) określa numer sekwencyjny ostatniego oktetu danych pilnych. Opcje (ang. options) opcje rozszerzają funkcjonalność nagłówka TCP. Każdą opcję poprzedzają dwa bajty, pierwszy określa rodzaj opcji, drugi zawiera rozmiar pola opcji w bajtach. Rysunek 1. Nagłówek pakietu protokołu TCP 2.3. Otwieranie i zamykanie połączenia TCP Usługi TCP zorientowane na połączenie wykorzystują dwie procedury otwierania oraz zamykania połączenia. Połączenie otwierane jest przed rozpoczęciem wysyłania danych. Wraz z zakończeniem przesyłania danych połączenie musi zostać zamknięte [2]. Proces otwierania połączenia TCP oparty jest o trójstronne uzgodnienie (ang. three-way handshaking). Przebiega ono w następujący sposób: Klient wysyła do serwera segment, w którego nagłówku ustawiono znacznik SYN, zawierający początkową wartość numeru sekwencyjnego, który będzie używany przez klienta w tym połączeniu. Serwer wysyła do klienta segment zawierający ustawione znaczniki SYN i ACK. Numer potwierdzenia jest o 1 większy od odebranego wcześniej od klienta numeru sekwencyjnego, co oznacza, że serwer oczekuje oktetu danych o kolejnym numerze sekwencyjnym. Dodatkowo serwer wysyła własny początkowy numer sekwencyjny. Początkowe numery sekwencyjne klienta i serwera mogą się różnić. Na koniec, klient za pomocą segmentu z ustawionym znacznikiem ACK, potwierdza numer sekwencyjny serwera, wpisując w pole numeru potwierdzenia wartość o 1 większą. Po tych czynnościach klient i serwer są gotowe do wymiany danych. Proces zakończenia połączenia jest natomiast oparty na czterostronnym uzgodnieniu (ang. four-way handshaking). Może być on zainicjowany przez dowolną ze stron połączenia. Przebiega on w czterech następujących etapach: 10

11 Węzeł A, inicjujący zamknięcie połączenia, wysyła do węzła B segment, w którego nagłówku ustawiony jest znacznik FIN, oznaczający chęć zakończenia połączenia. Węzeł B wysyła segment z ustawionym znacznikiem ACK, potwierdzający odebranie segmentu FIN. Od tej chwili ustaje komunikacja od węzła A do węzła B. Węzeł B może kontynuować komunikację w kierunku do węzła A, jeżeli nie jest jeszcze gotowy do zakończenia połączenia. Gdy węzeł B jest gotów do zamknięcia połączenia, wysyła do inicjatora segment FIN. Etapy 2. i 3. są ze sobą powiązane, ponieważ węzeł B nie musi być gotowy do zamknięcia połączenia w chwili odebrania segmentu FIN od węzła A. Węzeł A potwierdza odebranie segmentu FIN od węzła B za pomocą segmentu ACK. Połączenie jest zakończone po obu stronach. Połączenie może również zostać zamknięte awaryjnie, poprzez wysłanie segmentu z ustawionym znacznikiem RST segment taki nie wymaga potwierdzenia. Każde uzgodnienie wnosi pewne opóźnienie (segmenty SYN i FIN muszą zostać wysłane do drugiego z węzłów). W komunikacji długodystansowej (na przykład w sieciach satelitarnych) uzgadnianie jest głównym źródłem opóźnień [3] Kontrola przepływu Kontrola przepływu jest mechanizmem, który zapobiega wysyłaniu nadmiernej liczby segmentów przez szybkiego nadawcę do wolnego odbiorcy. Każdy odbiorca przydziela połączeniu TCP pewien bufor. Umieszczane są w nim odebrane dane, które powinny zostać jak najszybciej pobrane przez odpowiednią aplikację. W wielu sytuacjach (na przykład pobieranie pliku z szybkiego serwera w sieci LAN) aplikacja działająca w komputerze odbierającym może nie nadążyć za napływającymi danymi, co może doprowadzić do zapełnienia się bufora odbiorcy. Aby zapobiec w takim przypadku zapełnieniu się bufora odbiorcy, TCP zaczyna kontrolować przepływ danych [4]. W TCP do kontroli przepływu użyto mechanizmu zwanego przesuwnym oknem (ang. sliding window). Odbiorca odsyła nadawcy potwierdzenie, określające zakres dopuszczalnych numerów sekwencyjnych, wyższych niż numer ostatniego odebranego segmentu. Okno określa zakres dopuszczalnych numerów sekwencyjnych. Rozmiar okna jest zarazem liczbą oktetów, które nadawca może wysłać nie oczekując na sukcesywne potwierdzenia. Lewa krawędź okna wyznacza oktet o najniższym numerze sekwencyjnym spośród pakietów niepotwierdzonych. Okno stopniowo jest przesuwane jego lewa krawędź przemieszcza się w prawo, gdy zostanie odebrane potwierdzenie otrzymania danych. Pakiet potwierdzenia zawiera również informację o pożądanym rozmiarze okna nadawania. Odesłanie przez odbiorcę wartości rozmiaru okna równej 0 sygnalizuje nadawcy, że bufor odbierania jest pełny i żadne dane nie powinny być wysyłane. W protokole zostały 11

12 jednak uwzględnione mechanizmy zmniejszania rozmiaru okna, jeśli grozi on nadmiernym spiętrzeniem danych, jak również zwiększania jego rozmiaru, gdy zanika problem przeciążania. Rysunek 2. Okno odbiorcze po zainicjowaniu połączenia Rysunek 3. Okno odbiorcze po poprawnym odebraniu dwóch pierwszych bajtów Mechanizm okna przesuwnego ma na celu zapewnienie wykorzystania możliwości kanału przesyłowego i zredukowanie opóźnień wywołanych przez oczekiwanie na potwierdzenia [2] Kontrola przeciążenia Zmieniając dynamicznie wartość rozmiaru okna przesuwnego, tak by zawierała ilość wolnego miejsca w buforze odbiorcy, mechanizm kontroli przepływu skutecznie zapobiega zapełnieniu się bufora odbiorcy. Jednak mechanizm kontroli przepływu nie rozwiązuje problemu zapełnienia się buforów routerów pośredniczących. Żeby poradzić sobie z przeciążeniem sieci, w TCP zaimplementowano mechanizmy nazywane ogólnie mechanizmami kontroli przeciążenia (ang. congestion control) [2]. Mechanizmy kontroli przeciążenia są różnie realizowane w różnych odmianach protokołu TCP (por. rozdz ). Podstawą działania mechanizmów kontroli przeciążenia jest takie dostosowanie rozmiaru okna nadawcy, które pozwoli zapobiec zapełnieniu się bufora nie tylko u odbiorcy, ale również w stacjach pośredniczących. Do tego celu TCP używa parametru nazywanego oknem przeciążenia (ang. congestion window). Ponieważ routery sieciowe nie używają warstwy TCP, nie mogą wysyłać segmentów ACK, zawierając w nich informację o rozmiarze okna. Aby rozwiązać ten problem, TCP w swojej podstawowej wersji zakłada, że w sieci występuje przeciążenie za każdym razem, gdy występuje konieczność retransmisji (zegar retransmisji doliczył do zera). W wersjach TCP implementujących mechanizmy szybkiej retransmisji i szybkiego odtworzenia nadawca zakłada, że przeciążenie wystąpiło, gdy otrzyma więcej niż jeden pakiet z takim samym numerem potwierdzenia (powielone potwierdzenia ang. duplicated ACK, DupACK). Odpowiedzią TCP na przeciążenie jest zmiana wartości okna przeciążenia. 12

13 Początkowa wartość okna przeciążenia jest niewielka. Następnie jest ona stopniowo zwiększana, aż do momentu wystąpienia pierwszych symptomów przeciążenia sieci. Wtedy przywracana jest początkowa wartość okna przeciążenia (redukowana jest ilość wysyłanych danych) i cała procedura jest powtarzana. W taki sposób prędkość przesyłania danych waha się blisko przepustowości sieci [5] Slow start (powolny start) Zadaniem mechanizmu powolnego startu jest oszacowanie prędkości, z jaką możliwe jest wysyłanie danych, unikając utraty pakietów. Podczas otwierania nowego połączenia, wartość okna przeciążenia ustawiana jest na 1 segment. Podczas transmisji, rozmiar okna jest zwiększany o jeden segment po otrzymaniu każdego potwierdzenia ACK. Nadawca może wysyłać pakiety bez oczekiwania na ich potwierdzenie pod warunkiem, że liczba niepotwierdzonych segmentów nie przekracza wartości okna przeciążenia oraz wartości okna odbiorczego [5]. Nadawca zaczyna od wysłania jednego segmentu i oczekuje na nadejście potwierdzenia odebrania go przez odbiorcę. Po jego otrzymaniu, wartość okna przeciążenia zwiększana jest o jeden, nadawca może wysłać jednocześnie dwa segmenty, nie oczekując na potwierdzenie. Przy założeniu, że każdemu wysłanemu segmentowi odpowiada jedno potwierdzenie, działanie mechanizmu powoduje wykładniczy wzrost wartości okna przeciążenia, a zatem wykładniczy wzrost prędkości, wbrew znaczeniu nazwy mechanizmu. Ze względu na powszechne stosowanie opóźnionych potwierdzeń, powyższe założenie nie do końca jest spełnione, pomimo tego wzrost wartości pozostaje bliski wykładniczemu [2]. Wykładniczy (lub bliski wykładniczemu) wzrost prędkości wysyłania może w pewnym momencie doprowadzić do utraty pakietów wskutek przeciążenia sieci. Nadawca stwierdzi wtedy upłynięcie czasu oczekiwania na potwierdzenie lub otrzyma pakiet z takim samym jak poprzednio numerem potwierdzenia, wysłany przez odbiorcę w skutek wykrycia brakującego pakietu. Nadawca powinien wówczas zmniejszyć prędkość wysyłania danych. Ustawiana jest wtedy wartość progu powolnego startu (ang. slow-start threshold, ssthresh) na połowę aktualnego rozmiaru okna (ale nie mniej niż 2 segmenty). W przypadku upłynięcia czasu retransmisji ponownie inicjowane jest działanie mechanizmu powolnego startu, natomiast po wykryciu powielonego potwierdzenia następuje przejście do fazy unikania przeciążenia (por. rozdz ). W momencie, gdy rozmiar okna przeciążenia osiągnie wartość progową ssthresh, mechanizm powolnego startu kończy działanie, dalsze sterowanie wartością okna przeciążenia realizowane jest przez mechanizm unikania przeciążenia. 13

14 Congestion avoidance (unikanie przeciążenia) Mechanizm unikania przeciążenia implementowany jest łącznie z mechanizmem powolnego startu w celu zahamowania wykładniczego wzrostu wartości okna przeciążenia i badania przepustowości sieci od pewnego momentu w sposób bliski liniowemu. Algorytm ten zakłada, że prawdopodobieństwo utraty pakietu z powodu jego uszkodzenia jest niewielkie, co oznacza, iż większość zagubionych pakietów sygnalizuje przeciążenie sieci. Za następstwo przeciążenia sieci, algorytm przyjmuje wyczerpanie się czasu oczekiwania na potwierdzenie (ang. retransmission timeout, RTO) lub powielające się potwierdzenia [3]. Mechanizm ten zwiększa wartość okna przeciążenia o jeden segment po każdorazowym upłynięciu czasu RTT (ang. round-trip time), wyznaczanego na podstawie odebranych pakietów potwierdzeń. Odpowiada to zwiększeniu wartości okna przeciążeniowego o jej odwrotność po otrzymaniu każdego potwierdzenia ACK. Pozwala to na precyzyjniejsze, niż w wypadku mechanizmu powolnego startu, dążenie do optymalnej wartości, przy dalszym unikaniu przeciążenia sieci. W przypadku sieci o dużych przepustowościach lub dużych czasach RTT, osiągnięcie optymalnej prędkości transmisji, przy jej liniowym wzroście, może trwać bardzo długo. Ponadto, po jej osiągnięciu, mechanizm wciąż będzie zwiększał wartość okna przeciążenia, co doprowadzi do przeciążenia sieci i utraty pakietów [2]. Po wykryciu przeciążenia sieci z powodu wyczerpania się czasu RTO, mechanizm zachowuje się podobnie, jak mechanizm powolnego startu: aktualizuje wartość ssthresh i ponownie inicjowany jest algorytm powolnego startu. Rysunek 4. Działanie algorytmów powolnego startu oraz unikania przeciążenia (bez mechanizmów fast retransmit i fast recovery) Po otrzymaniu kilku identycznych potwierdzeń, kontrolę przejmą algorytmy fast retransmit i fast recovery, których celem jest szybkie zmniejszenie przeciążenia sieci, nie powodując dużego spadku prędkości transmisji danych [5]. 14

15 Fast retransmit (szybka retransmisja), fast recovery (szybkie odtworzenie) Zmiana kolejności odbieranych pakietów nie jest rzadkim zjawiskiem. Retransmisja segmentu po odebraniu jednego powielonego potwierdzenia byłaby nieekonomiczna. Zakłada się, że dopiero otrzymanie trzech powielonych potwierdzeń z dużym prawdopodobieństwem świadczy, że segment rzeczywiście zaginął, a nie spóźnił się. Otrzymanie czterech potwierdzeń oznacza, że odbiorca odebrał co najmniej trzy inne segmenty, zatem przeciążenie sieci pomiędzy nadawcą a odbiorcą jest niewielkie, więc ponowne aktywowanie mechanizmu powolnego startu byłoby niezasadne. Wystarczającym rozwiązaniem jest chwilowe ograniczenie prędkości wysyłania. Efektem jest szybka retransmisja (ang. fast retransmit) utracony pakiet jest wysyłany ponownie, pomijając oczekiwanie na upłynięcie czasu RTO. Aktywowany jest również mechanizm szybkiego odtwarzania (ang. fast recovery), którego zadaniem jest uniknięcie znacznej redukcji okna przeciążenia. Algorytm szybkiego odtwarzania aktualizuje wartość ssthresh (analogicznie jak w przypadku mechanizmu powolnego startu), następnie ustawia wartość okna przeciążenia na nową wartość progową, zwiększoną o wielkość trzech segmentów (które wcześniej zostały już poprawnie dostarczone), po otrzymaniu kolejnych powielonych potwierdzeń, wartość okna przeciążenia zwiększana jest o jeden segment, natomiast po otrzymaniu potwierdzenia odebrania zagubionego segmentu, wartość okna przeciążeniowego ustawiana jest na wartość progową, co kończy działanie mechanizmu szybkiego odtwarzania, następuje powrót do mechanizmu unikania przeciążenia [6]. Algorytm fast recovery jest skuteczny w wypadku utraty pojedynczego segmentu danych. W przypadku uszkodzenia większej ilości segmentów z jednego okna danych, ujawniają się niedoskonałości mechanizmu. Po stronie nadawcy algorytmy szybkiej retransmisji i szybkiego odtwarzania uruchamiane są kilkukrotnie, dla każdego utraconego segmentu. Konieczne jest zakończenie retransmisji jednego segmentu, aby przejść do retransmisji kolejnego. Redukcja wartości okna przeciążenia może również sprawić, że jego rozmiar będzie zbyt mały, by uruchomić mechanizm szybkiej retransmisji. Konieczne będzie oczekiwanie na upłynięcie czasu retransmisji, co spowoduje przejście do fazy powolnego startu, co znacznie obniży wydajność protokołu. Rozwiązaniem problemu jest jednoczesna retransmisja wszystkich zagubionych segmentów. Mechanizmy powolnego startu, unikania przeciążenia oraz szybkiej retransmisji wdrożone zostały w odmianie TCP zwanej Tahoe (istnieje także starsza odmiana Old Tahoe, niewykorzystująca mechanizmu szybkiej retransmisji), natomiast algorytm szybkiego odtwarzania dołączony został do pozostałych w odmianie Reno [2]. 15

16 Rysunek 5. Porównanie działania TCP Tahoe i TCP Reno Rysunek 6. Zachowanie okna przeciążenia podczas działania TCP Reno Selective Acknowledgements (SACK) Gdy utracie ulega wiele pakietów jednego okna transmisyjnego, nadawca na podstawie potwierdzeń powielonych może wywnioskować tylko o utracie pierwszego pakietu. Po ponownym wysłaniu utraconego pakietu, aby wykryć utratę następnego pakietu, nadawca musi czekać na pojawienie się nowego potwierdzenia powielonego. W wyniku tego, TCP może w czasie RTT naprawiać utratę tylko jednego pakietu. Opcja TCP selektywnego potwierdzania (ang. Selective Acknowledgement, SACK) umożliwia określenie w każdym potwierdzeniu nie tylko ostatniego odebranego pakietu należącego do ciągłej sekwencji, ale również do trzech ciągłych bloków danych odebranych poza tym pakietem. Na tej podstawie nadawca może wywnioskować, które pakiety zostały utracone i wysłać je bez czekania na dodatkowe potwierdzenie powielone [7]. Mechanizm selektywnego potwierdzania wymagał wprowadzenia zmian w protokole zarówno po stronie nadawczej, jak i odbiorczej. Aby zachować kompatybilność ze stacjami niewspierającymi selektywnych potwierdzeń, korzystanie z tego mechanizmu 16

17 należy wynegocjować podczas otwierania połączenia. Służy temu opcja SACK-permitted TCP NewReno Użycie selektywnych potwierdzeń skutkuje wyraźnym wzrostem wydajności połączeń TCP o wysokiej stopie błędów. Jednakowoż konieczność aktualizacji oprogramowania w znacznej liczbie urządzeń sieciowych spowodowała, że wdrażanie SACK przebiegało powoli. Zaproponowano, aby nadawca wykorzystywał zmodyfikowaną odmianę Reno w transmisjach do odbiorcy nieobsługującego selektywnych potwierdzeń. Modyfikacja ta jest znana pod nazwą NewReno; zmiany dotknęły głównie algorytmu szybkiego odtwarzania. W pierwotnej wersji zakończenie działania mechanizmu fast recovery następowało po otrzymaniu potwierdzenia odebrania przynajmniej jednego oktetu nowych danych. W odmianie NewReno, procedura szybkiego odtwarzania kończy swoje działanie po otrzymaniu potwierdzenia odebrania wszystkich danych, wysłanych od rozpoczęcia działania procedury. Zmiana ta umożliwiła retransmisję wielu utraconych pakietów w ramach pojedynczego okna danych, zapobiegając zbędnej redukcji okna przeciążenia [8]. Modyfikacja ta pozwala na osiągnięcie większej wydajności w sieciach o wysokiej stopie błędów, ale jest to tylko częściowe rozwiązanie. Zaleca się korzystanie z selektywnych potwierdzeń, jeżeli tylko jest to możliwe Forward Acknowledgements (FACK) Mechanizm potwierdzeń generowanych w przód (ang. Forward Acknowledgement, FACK) bazuje na podstawowych algorytmach kontroli przeciążenia, wykorzystując również informacje niesione przez opcję SACK. Podobnie, jak mechanizm selektywnych potwierdzeń, zapewnia on efektywniejsze odtwarzanie wielu utraconych pakietów z jednego okna danych. Działanie mechanizmu opiera się na wykorzystaniu dodatkowych informacji z opcji SACK do określenia najwyższej wartości numeru sekwencyjnego poprawnie odebranego segmentu i wyraźnego obliczenia całkowitej ilości zaległych danych. Podstawowe działanie algorytmu pozwala nadawcy na wysłanie jednego pakietu dla każdych dwóch zduplikowanych potwierdzeń odebranych podczas jednego czasu RTT. Dzięki temu protokół TCP podczas procesu odtwarzania wysyła odpowiednią ilość danych przed zakończeniem okresu odtwarzania, ale reguluje tempo wysyłania i rozkłada transmisje równomiernie zamiast skupiać je w drugiej połowie czasu RTT. Unikanie impulsowości ruchu jest korzystne, ponieważ odciąża to bufory routerów. 17

18 TCP BIC i TCP CUBIC Odmiany opierające się o metodę poszukiwań binarnych. Znane są dwie wartości okno minimalne, czyli ostatnie, przy którym nie doznano utraty pakietów oraz maksymalne ostatnie, o którym wiadomo, że traci się pakiety. Metodą poszukiwań binarnych wyznacza się okno próbne, które po sprawdzeniu staje się odpowiednio nowym oknem minimalnym lub maksymalnym [9]. Poza tym stosowane jest dodatkowo zwiększanie addytywne okna, podobnie jak w standardowym TCP, przełączane przy osiągnięciu pewnego progu. W odmianie TCP BIC próg jest wyznaczany funkcją logarytmiczną, w TCP CUBIC funkcją wielomianową (sześcienną), przez co jest mniej agresywny od protoplasty [10]. Począwszy od wersji jądra Linux, TCP CUBIC jest domyślnie stosowaną odmianą protokołu TCP w tym systemie operacyjnym TCP Vegas Podejście to bazuje na opóźnieniu, w przeciwieństwie do poprzednio opisanych metod, bazujących na utracie pakietów. Algorytm szacuje ilość danych, jaką może przesłać w pewnym odcinku czasu, i porównuje ją z ilością danych, którą udało mu się rzeczywiście przesłać. Jeżeli ta druga jest mniejsza od tej pierwszej, wnioskowane jest prawdopodobieństwo przeciążenia sieci i transmisja jest spowalniana (zmniejszane jest okno przeciążenia), natomiast gdy udało się wysłać więcej danych okno przeciążenia jest zwiększane [11] TCP Veno Odmiana Veno [12] jest modyfikacją odmiany Reno, wprowadzającą niewielkie modyfikacje bazujące na odmianie Vegas, mające na celu poprawę wydajności protokołu TCP w sieciach bezprzewodowych. TCP Veno stara się odróżnić dwa powody utraty pakietów utratę spowodowaną przeciążeniem sieci oraz utratę losową, metodą zaczerpniętą z TCP Vegas. W TCP Veno zmodyfikowano algorytm zwiększania okna przeciążenia: w przypadku wykrycia przeciążenia sieci okno zwiększane jest nie po otrzymaniu każdego potwierdzenia, ale po co drugim potwierdzeniu. Pozwala to na wydłużenie okresu przed koniecznością powrotu do fazy powolnego startu. Odmiana ta stosuje także zmodyfikowany algorytm szybkiej retransmisji: w przypadku utraty o charakterze losowym próg powolnego startu ustalany na poziomie 80% wielkości okna przeciążenia, zamiast połowy wartości stosowanej w Reno. W pozostałych przypadkach zachowanie jest takie samo, jak w odmianie TCP Reno [12] TCP Westwood TCP Westwood [13] jest modyfikacją TCP Reno wpływającą jedynie na zachowanie nadawcy. Ustalanie rozmiaru okna przeciążenia i progu powolnego startu opiera się na estymowaniu dostępnego pasma. Odbywa się to poprzez uśrednianie filtrem dolnoprzepustowym wskaźnika otrzymywanych potwierdzeń. Na tej podstawie TCP 18

19 Westwood ustala zależnie od potencjalnie dostępnego pasma rozmiar okna przeciążenia, zamiast arbitralnego dwukrotnego zmniejszenia stosowanego w TCP Reno HighSpeed TCP Odmiana protokołu dla szybkich środowisk, gdzie szczególnie odczuwalny jest spadek wydajności przy powrocie do fazy powolnego startu oraz zwiększono liniowy wzrost okna przeciążenia w fazie unikania przeciążenia [14]. Wprowadzono dolny limit okna, w fazie unikania przeciążenia wprowadzono nachylenie prostej wzrostu okna przeciążenia, w zależności od pasma i opóźnienia, w fazie powolnego startu wprowadzono natomiast górny próg zwiększania okna, niwelując szybki wykładniczy wzrost [14] TCP Hybla Celem tej odmiany protokołu TCP jest wyeliminowanie ograniczania strumieni TCP cechujących się wysokimi opóźnieniami, a w konsekwencji wysokim czasem RTT [15]. Rozmiar okna przeciążenia nie zależy bezpośrednio od RTT, a od stosunku RTT do czasu znormalizowanego, będącego parametrem konfiguracyjnym tego algorytmu (wartość zalecana to 25 ms). Dynamiczna adaptacja rozmiaru okna dobrze współpracuje z opcjami SACK oraz znacznikami czasu, pozwalając szczególnie na lepsze działanie połączeń w sieciach satelitarnych o znaczących wartościach opóźnień [15]. 19

20 3. Dostosowanie protokołu TCP do różnych środowisk sieci Protokół TCP powstał z myślą o sieciach przewodowych. Mimo tego jest obecnie używany w różnych sieciach, jak sieci lokalne, bezprzewodowe czy mobilne. Jest to możliwe dzięki wprowadzonym udoskonaleniom, poprawiającym pracę protokołu w różnych środowiskach Sieci przewodowe Protokół TCP został pierwotnie zaprojektowany dla wojskowej, przewodowej sieci ARPANET. Cechował ją początkowo znaczny zapas przepustowości. Wraz z jej rozwojem i podłączeniem kolejnych użytkowników do sieci, pojawiały się problemy z utratą pakietów i spadkiem wydajności. Aby przeciwdziałać tym zjawiskom, wprowadzono mechanizmy kontroli przeciążenia. Protokół TCP zakłada, że w sieci przewodowej czas pętli zwrotnej jest stosunkowo stabilny, utrata pakietów jest skutkiem przeciążenia sieci. Założono również, że przepustowość sieci jest stabilna, a do odległego węzła prowadzi jednoznacznie wybierana najlepsza ścieżka, przez co zmiana kolejności pakietów jest zjawiskiem rzadko występującym Sieci LAN Protokół TCP zachowuje się w sieciach LAN w optymalny sposób. Są one rozwinięciem sieci ARPANET, dla której został zaprojektowany, mają znacznie lepsze parametry przepustowość typowo do 1 Gb/s, przy nieznacznych opóźnieniach, rzędu pojedynczych milisekund. W przypadku sieci LAN podłączonych poprzez router do sieci Internet, gdzie przepustowość łącza nie jest podzielona w stałych proporcjach pomiędzy użytkowników, pojawić się mogą problemy związane z przeciążeniem sieci nagłe rozpoczęcie transferu ze zdalnego serwera przez jednego z użytkowników, może spowodować błędne zachowanie się protokołu TCP u innych użytkowników, skutkujące ograniczeniem szybkości transmisji Sieci WAN Początkowo sieci WAN, ze względu na rozległość, cechowały się niższą przepustowością i większymi opóźnieniami, niż sieci LAN. Wraz z rozwojem, ich parametry jakościowe zbliżały się tak, że obecnie sieci WAN cechują się prędkościami rzędu Gb/s, przy opóźnieniach do 500 ms. W sieciach rozległych istotnym parametrem TCP jest rozmiar okna wymagają one dużej jego wartości. Optymalne wykorzystanie sieci szerokopasmowych zależy od 20

21 utrzymania niskiego poziomu błędów. Redukcja okna przeciążenia spowoduje wyraźny spadek prędkości przesyłu danych Możliwe usprawnienia W sieciach przewodowych utrata pakietów zazwyczaj jest skutkiem wystąpienia przeciążenia łącza. W sieciach lokalnych wykorzystanie standardowych mechanizmów kontroli przeciążenia, skupionych w odmianie TCP Reno, skutkuje optymalnym działaniem protokołu. W przypadku sieci korzystającej ze współdzielonego, zewnętrznego łącza, gdzie nagłe rozpoczęcie przez jednego z użytkowników transmisji wykorzystującej znaczną część łącza może skutkować wystąpieniem problemów u innych użytkowników, skuteczniejsze może być zastosowanie mechanizmu selektywnych potwierdzeń. W szerokopasmowych sieciach WAN, ze względu na duże rozmiary okna, wprowadzono koncepcję HighSpeed TCP. W przypadku wykrycia przeciążenia, rozmiar okna nie jest zmniejszany tak znacząco, jak w standardowej implementacji, co ogranicza opóźnienia po utracie pakietów i pozwala w pełni wykorzystać przepływność kanału [14]. Pewne problemy występują także w popularnych obecnie łączach asymetrycznych, jak na przykład ADSL. W takich łączach przepustowość w jednym kierunku jest kilku- lub nawet kilkunastokrotnie niższa niż przepustowość w kierunku przeciwnym. Aby zredukować ewentualną utratę potwierdzeń, stosuje się mechanizmy takie jak kompresja nagłówków TCP czy filtrowanie potwierdzeń oparte na fakcie, iż informacje zawarte w pakietach ACK o wyższych numerach sekwencyjnych oznaczają poprawne dostarczenie danych w pakietach o niższych numerach sekwencyjnych [3] Sieci bezprzewodowe Prężny rozwój sieci bezprzewodowych spowodował, iż protokoły warstwy transportowej są ciągle udoskonalane, aby jak najwydajniej pracować w tego typu sieciach. Ze względu na to, że protokół TCP został zaprojektowany dla sieci przewodowych, w zastosowaniach bezprzewodowych ujawnia pewne mankamenty spadek prędkości transmisji, częściowe wykorzystanie dostępnej przepustowości, przerwy w transmisji. Jest to związane z odmiennymi własnościami transmisji bezprzewodowej oraz z założeniami TCP dotyczącymi utraty pakietów. Jakość łączy bezprzewodowych zależy od warunków środowiskowych, przeszkód terenowych i odbić czy zakłóceń od innych urządzeń. Sieci bezprzewodowe cechują się dużą stopą błędów (ang. bit-error rate, BER). Błędy transmisji są podstawową przyczyną problemów z wydajnością w sieciach bezprzewodowych. Równie poważną przyczyną problemów jest występowanie tymczasowych rozłączeń podczas komunikacji. 21

22 Obie z wymienionych przyczyn powodują utratę pakietów oraz potwierdzeń. Utrata pakietów w typowej implementacji TCP jest traktowana jako dowód istnienia w sieci przeciążenia, na które protokół reaguje, zmniejszając wielkość okna przeciążenia. W większości przypadków błędy pojawiające się w sieciach bezprzewodowych nie są wynikiem przeciążenia, zatem niepotrzebne zmniejszenie okna przeciążeniowego powoduje zmniejszenie szybkości przesyłania danych Sieci WLAN (WiFi) Sieci WLAN (WiFi) w ostatnich latach znacznie przybrały na znaczeniu. Są one dziś niemal wszechobecne. Powoduje to występowanie pewnych problemów, związanych z wydajnością łącza. Ze względu na mnogość sieci na jednym obszarze, czasem można zaobserwować sieci działające na częstotliwościach nakładających się częściowo lub całkowicie (standard b/g definiuje do 14 kanałów). W związku z tym sygnały sieci interferują, powodując występowanie opóźnień czy utraty pakietów. Na pogorszenie sygnału, a w konsekwencji pogorszenie parametrów połączenia, wpływ mają także inne czynniki środowiskowe, takie jak przeszkody fizyczne, tłumiące sygnał, czy urządzenia emitujące fale elektromagnetyczne, np. kuchenka mikrofalowa Sieci komórkowe Usługa mobilnego dostępu do Internetu przez sieć komórkową cieszy się dużą popularnością. Zależnie od wykorzystywanej technologii, różnią się parametry łącza. Wraz z rozwojem technologii komórkowych ograniczenia i problemy takie jak szybkość transmisji czy opóźnienia, redukują się, ale nie są całkowicie wyeliminowane. Podczas korzystania z protokołu TCP w sieciach komórkowych, napotyka on na problemy i ograniczenia, typowe dla sieci bezprzewodowych: znaczne opóźnienia są one związane z dostępem do kanału radiowego i narzutem procesów warstwy fizycznej, związanych z redukcją błędów (FER), szybkość transmisji użytkownicy komórki konkurują o dostęp do sieci, co negatywnie wpływa na stabilność szybkości transmisji, przekazywanie transmisji ponieważ parametry transmisji są uzgadniane tylko podczas otwierania połączenia TCP, przekazywanie transmisji pomiędzy komórkami (może skutkować to przełączeniem pomiędzy siecią 3G a 2G) może mieć negatywny wpływ na wydajność protokołu TCP, wzrosty opóźnienia powodują one wyczerpanie czasu retransmisji, co jest traktowane przez protokół za objaw przeciążenia sieci, natomiast są one skutkiem chwilowego zaniku zasięgu sieci komórkowej, przełączenia pomiędzy stacjami bazowymi czy chwilowym zawieszeniem transmisji. 22

23 Możliwe usprawnienia Sieci bezprzewodowe charakteryzują się częstym występowaniem błędów i opóźnień. Powoduje to częste występowanie konieczności retransmisji danych. Utracone pakiety bardzo często należą do jednego okna. Podstawowym rozwiązaniem problemów związanych z koniecznością retransmisji wielu pakietów jest mechanizm selektywnych potwierdzeń. Ze względu na podobieństwo do mechanizmu SACK, warto rozważyć użycie mechanizmu potwierdzeń generowanych w przód, którego przewagą nad mechanizmem SACK jest dokładniejsze obliczanie ilości zaległych danych. Ważnym zagadnieniem jest również prawidłowy dobór rozmiaru okna. Właściwy rozmiar okna powinien bazować na wartości iloczynu szerokości pasma i opóźnienia pomiędzy punktami końcowymi transmisji. Wartość ta określa ilość danych, które pozostają niepotwierdzone, gwarantujących pełne wykorzystanie kanału przy danej przepustowości łącza. Zwiększenie początkowego rozmiaru okna przez nadawcę do czterech segmentów, pozwala natomiast ograniczyć niepotrzebny czas bezczynności w początkowej fazie połączenia [3]. Istotne jest także prawidłowe określenie czasu RTT oraz czasu retransmisji (RTO), aby zniwelować wpływ impulsowych wzrostów opóźnień na niesłuszne redukowanie wielkości okna, spowodowane błędną interpretacją opóźnienia jako objawu poważnego przeciążenia sieci [2]. 23

24 4. Implementacja protokołu TCP w systemie Linux System Linux jest otwartym systemem operacyjnym, zyskującym nieprzerwanie od kilku lat coraz większą popularność, głównie w środowisku programistów. Źródła systemu Linux są publicznie dostępne, co sprawia, że jest on chętnie używany do badania wielu zagadnień informatycznych. Stworzenie spójnej implementacji protokołu w oparciu o wiele odrębnych specyfikacji nie jest prostym zadaniem. W systemie Linux mechanizm obsługi protokołów sieciowych jest zwarty, często wykorzystywany jest wspólny kod dla odmiennych algorytmów. Aby uniknąć zawiłości i zbytniego skomplikowania, niektóre z zastosowanych rozwiązań odbiegają od wymagań dokumentów RFC oraz od innych implementacji protokołu [16] Parametry konfiguracyjne Począwszy od wersji system Linux pozwala na dokonanie własnych zmian w parametrach jądra bez konieczności jego ponownego kompilowania, przy pomocy polecenia sysctl. Ponadto, parametry te są odwzorowane na pliki w pseudo-systemie plików /proc/sys. Wśród nich znajdują się parametry dotyczące działania protokołu TCP. Są to między innymi: net.ipv4.tcp_allowed_congestion_control lista algorytmów sterowania przeciążeniami, dostępnych dla procesów nieuprzywilejowanych, net.ipv4.tcp_available_congestion_control lista dostępnych algorytmów sterowania przeciążeniami, net.ipv4.tcp_congestion_control algorytm sterowania przeciążeniami wykorzystywany przez nowe połączenie, net.ipv4.tcp_ecn mechanizm jawnego powiadamiania o przeciążeniu ECN, net.ipv4.tcp_fack mechanizm generowania potwierdzeń wprzód FACK, net.ipv4.tcp_rmem rozmiar okna odbiorczego (minimalny, domyślny, maksymalny), net.ipv4.tcp_sack mechanizm selektywnego potwierdzania SACK, net.ipv4.tcp_slow_start_after_idle resetowanie rozmiaru okna przeciążenia po bezczynności połączenia, net.ipv4.tcp_window_scaling mechanizm skalowania okna, net.ipv4.tcp_wmem rozmiar okna nadawczego (minimalny, domyślny, maksymalny). 24

25 5. Dokumentacja projektowa 5.1. Specyfikacja wymagań Opis słowny aplikacji Przeznaczeniem projektowanej aplikacji jest umożliwienie użytkownikowi usprawnienia działania połączeń TCP w systemie Linux, poprzez modyfikację parametrów konfiguracyjnych protokołu, zgodnie z wcześniej predefiniowanymi oraz własnymi profilami. Predefiniowane profile zawierają określone wartości parametrów konfiguracyjnych, w zależności od wybranego środowiska sieci. Nie dotyczy to jedynie bezpośredniego połączenia użytkownika z siecią użytkownik wiedząc, że po drodze wykorzystywane jest połączenie o gorszych parametrach, wybiera profil takiego połączenia, aby dostosować działanie protokołu TCP do możliwych problemów występujących przy transmisji danych. Użytkownik ma także możliwość samodzielnej modyfikacji parametrów konfiguracyjnych protokołu Słownik pojęć Użytkownik osoba korzystająca z aplikacji, mająca prawa administratora systemu. Parametr wielkość definiująca pewną własność, zachowanie protokołu TCP, będąca atrybutem systemu operacyjnego zapisywanym w systemie plików /proc/sys, ze zbioru: net.ipv4.tcp_congestion_control algorytm sterowania przeciążeniami wykorzystywany przez nowe połączenie, net.ipv4.tcp_fack mechanizm generowania potwierdzeń wprzód FACK net.ipv4.tcp_sack mechanizm selektywnego potwierdzania SACK net.ipv4.tcp_slow_start_after_idle resetowanie rozmiaru okna przeciążenia po bezczynności połączenia net.ipv4. tcp_timestamps mechanizm znaczników czasu Profil konfiguracyjny (profil) zbiór parametrów związanych z konkretnym środowiskiem sieci. Profil predefiniowany zbiór parametrów zaproponowany przez autora aplikacji wartości parametrów dostosowane do pracy w sieciach: LAN DSL/cable 25

26 WLAN (WiFi) GSM (GPRS, EDGE) UMTS (HSPA) Profil użytkownika zbiór parametrów dobranych ręcznie przez użytkownika Wymagania funkcjonalne Rysunek 7. Diagram przypadków użycia FU1. Przeglądanie listy zdefiniowanych profili Aktor: Użytkownik Opis: Umożliwia Użytkownikowi zapoznanie się z proponowanymi wartościami parametrów konfiguracyjnych, oferowanymi przez zapamiętane w programie profile konfiguracyjne. Priorytet: Wysoki Warunki początkowe: W programie istnieje co najmniej jeden zapamiętany profil konfiguracyjny. Warunki końcowe: Program wczytał i wyświetlił zapamiętane wartości parametrów konfiguracyjnych protokołu TCP dla profilu wybranego przez Użytkownika. Scenariusz główny: 1) Użytkownik wybiera opcję przeglądania profili konfiguracyjnych. 2) Program wyświetla listę zapamiętanych profili. 3) Użytkownik wybiera z listy interesujący go profil. 26

27 Wyjątki: 2A) W programie nie ma zapamiętanego żadnego profilu. 2A.1) Program wyświetla komunikat o braku zapamiętanych profili. FU2. Zastosowanie profilu Aktor: Użytkownik Opis: Umożliwia Użytkownikowi wprowadzenie zmian w konfiguracji systemu operacyjnego w zakresie protokołu TCP, zgodnie z wybranym przez niego profilem konfiguracyjnym. Priorytet: Wysoki Warunki początkowe: W programie istnieje co najmniej jeden zapamiętany profil konfiguracyjny. Warunki końcowe: Program wprowadził wartości parametrów z wybranego profilu do plików konfiguracyjnych systemu operacyjnego. Scenariusz główny: rozszerza funkcję FU1 4) Użytkownik wybiera opcję zastosowania wybranego profilu konfiguracyjnego w systemie operacyjnym. 5) Program zapisuje wartości wybranego profilu konfiguracyjnego do plików konfiguracyjnych systemu operacyjnego. 6) Program wyświetla komunikat o poprawnym wprowadzeniu zmian. Wyjątki: 5A) System operacyjny nie umożliwił dostępu do pliku zawierającego wartość parametru. 5A.1) Program wyświetla komunikat o błędzie zapisu, wstrzymuje dalsze wykonywanie operacji. FU3. Usuwanie profilu Aktor: Użytkownik Opis: Umożliwia Użytkownikowi usunięcie z konfiguracji programu zapamiętanego profilu. Priorytet: Średni Warunki początkowe: W programie istnieje co najmniej jeden zapamiętany profil konfiguracyjny. 27

28 Warunki końcowe: Program usunął ze swojej konfiguracji żądany profil. Scenariusz główny: rozszerza funkcję FU1 4) Użytkownik wybiera opcję usunięcia profilu konfiguracyjnego. 5) Program usuwa profil ze swojej konfiguracji. Wyjątki: 5A) Wybrany profil jest profilem predefiniowanym. 5A.1) Program nie umożliwia Użytkownikowi wybrania opcji usunięcia profilu. FU4. Edytowanie profilu Aktor: Użytkownik Opis: Umożliwia Użytkownikowi edycję wartości parametrów w zapamiętanym profilu konfiguracyjnym. Priorytet: Średni Warunki początkowe: W programie istnieje co najmniej jeden zapamiętany profil konfiguracyjny. Warunki końcowe: Program zapamiętał wprowadzone przez Użytkownika zmiany w profilu konfiguracyjnym. Scenariusz główny: rozszerza funkcję FU1 4) Użytkownik wybiera opcję edycji profilu konfiguracyjnego. 5) Program wyświetla formularz umożliwiający edycję zapamiętanych parametrów, wyświetlający aktualne wartości. 6) Użytkownik wprowadza nowe wartości parametrów konfiguracyjnych. 7) Użytkownik zatwierdza wprowadzone zmiany. 8) Program zapamiętuje nowe wartości parametrów w swojej konfiguracji. Wyjątki: 6A) Wprowadzona przez Użytkownika wartość parametru jest niedozwolona. 6A.1) Program wyświetla komunikat o niedozwolonej wartości parametru. 6A.2) Użytkownik koryguje błędną wartość. 6A.3) Powrót do scenariusza głównego. 28

29 FU5. Tworzenie nowego profilu Aktor: Użytkownik Opis: Umożliwia Użytkownikowi stworzenie nowego profilu konfiguracyjnego na podstawie wprowadzonych przez niego wartości parametrów. Priorytet: Średni Warunki początkowe: brak Warunki końcowe: Tworzony profil został zapamiętany w programie. Scenariusz główny: rozszerza funkcję FU4 w punkcie 6) 7) Użytkownik wprowadza nową nazwę profilu. 8) Użytkownik wybiera opcję utworzenia profilu. 9) Program zapamiętuje utworzony profil w swojej konfiguracji. Wyjątki: 7A) W programie zapamiętano już profil o takiej samej nazwie. 7A.1) Program wyświetla komunikat o powielonej nazwie profilu. 7A.2) Użytkownik wprowadza nową nazwę dla tworzonego profilu. 7A.3) Powrót do scenariusza głównego. FU6. Wczytanie aktualnych parametrów konfiguracyjnych protokołu Aktor: Użytkownik Opis: Umożliwia Użytkownikowi wczytanie do programu aktualnych wartości parametrów konfiguracyjnych protokołu TCP, przechowywanych w drzewie /proc/sys oraz zapoznanie się z tymi wartościami i ich znaczeniem. Priorytet: Niski Warunki początkowe: brak Warunki końcowe: Program wczytał i wyświetlił aktualne wartości parametrów konfiguracyjnych protokołu TCP. Scenariusz główny: rozszerza funkcję FU4 w punkcie 5) 6) Użytkownik wybiera opcję wczytania aktualnych wartości parametrów. 7) Program wczytuje i wyświetla aktualne wartości parametrów. 29

30 Wyjątki: 6A) System operacyjny nie umożliwił dostępu do pliku zawierającego wartość parametru. 6A.1) Program wyświetla komunikat o błędzie odczytu, wstrzymuje dalsze wykonywanie operacji Wymaganie niefunkcjonalne NF1. środowisko program jest aplikacją działającą lokalnie na komputerze użytkownika, działającym pod kontrolą systemu Linux; ze względu na implementację w języku Java, do uruchomienia wymagana jest obecność maszyny wirtualnej Javy, w wersji 7 lub nowszej. NF2. wydajność program wykorzystuje niewielką ilość zasobów komputera. NF3. bezpieczeństwo program nie wpływa negatywnie na bezpieczeństwo i stabilność działania komputera. NF4. dostępność program musi być uruchomiony z uprawnieniami administratora, ze względu na modyfikowanie parametrów jądra systemu, poprzez dostęp do systemu plików /proc. NF5. interfejs graficzny program udostępnia użytkownikowi prosty interfejs graficzny, umożliwiający wygodną pracę z aplikacją. NF6. zapamiętywanie ustawień program zapisuje zdefiniowane przez użytkownika profile do pliku na dysku twardym w celu ich późniejszego odtworzenia. NF7. rozszerzalność budowa programu umożliwia rozszerzenie zbioru modyfikowanych parametrów konfiguracyjnych protokołu bez konieczności znacznej ingerencji w kod programu. 30

31 5.2. Projekt aplikacji Diagramy klas Rysunek 8. Diagram klas modelu programu Klasa Opis Parameter Klasa abstrakcyjna; opisuje pojedynczy parametr konfiguracyjny protokołu, modyfikowany przez program. BooleanParameter Opisuje parametr konfiguracyjny dwuwartościowy: 0-1, pozwalający na aktywację/dezaktywację funkcji protokołu. EnumParameter NumericParameter Opisuje parametr konfiguracyjny, przyjmujący jako wartość ciąg znaków ze ściśle określonego zbioru. Opisuje parametr konfiguracyjny, przyjmujący jako wartość liczbę całkowitą. TripleNumericParameter Opisuje parametr konfiguracyjny, przyjmujący jako wartość trzy liczby całkowite (tj. wartość minimalną, wartość domyślną, wartość maksymalną). Profile Zawiera dane opisujące pojedynczy profil konfiguracyjny. 31

32 Rysunek 9. Diagram klas interfejsu graficznego Klasa MainFrame ProfilesList ProfileRadioButton Opis Główne okno aplikacji. Lista zapamiętanych profili konfiguracyjnych. Przycisk wyboru profilu. ParametersFrame Okno prezentujące wartości parametrów konfiguracyjnych, umożliwiające również edycję profili. ParameterPanel BooleanParameterPanel EnumParameterPanel NumericParameterPanel TripleNumericParameter Panel Klasa abstrakcyjna; panel zawierający opis (nazwę) parametru oraz obiekt umożliwiający edycję wartości. Panel parametru dwuwartościowego 0-1, zawierający przycisk wyboru stanu. Panel parametru tekstowego, zawierający listę wyboru wartości parametru z określonego zbioru. Panel parametru liczbowego, zawierający pole tekstowe do wpisania wartości w postaci liczby całkowitej. Panel parametru liczbowego, zawierający trzy pola tekstowe do wpisania wartości w postaci liczb całkowitych. 32

33 Diagramy sekwencji Poniżej zaprezentowane są trzy przykładowe diagramy sekwencji, prezentujące zależności przy współpracy Użytkownika z programem oraz wewnętrznych obiektów aplikacji. Rysunek 10. Diagram sekwencji funkcji FU1. Przeglądanie listy zdefiniowanych profili Rysunek 4. przedstawia diagram sekwencji funkcji FU1. Przeglądanie listy zdefiniowanych profili. Po uruchomieniu aplikacji przez Użytkownika uruchamiane jest główne okno aplikacji, prezentujące listę zdefiniowanych profili. Obiekt klasy ProfilesList pobiera od obiektów klasy Profile nazwy profili. Rysunek 11. Diagram sekwencji funkcji FU4. Edytowanie profilu Rysunek 5. przedstawia diagram sekwencji częściowej funkcjonalności FU4. Edytowanie profilu, prezentujący pobranie aktualnie zapisanych wartości. Użytkownik po wybraniu interesującego go profilu, wybiera opcję edytowania. Okno główne aplikacji pobiera 33

34 z listy profili identyfikator aktualnie zaznaczonego profilu, a następnie tworzy okno prezentacji wartości parametrów. Przed uwidocznieniem okna, z obiektów klas dziedziczących z klasy abstrakcyjnej Parameter, poprzez obiekt klasy Profile, reprezentujący wybrany profil konfiguracyjny, pobierane są wartości parametrów zapisane w tym profilu. Rysunek 12. Diagram sekwencji FU2. Zastosowanie profilu Rysunek 6. przedstawia diagram sekwencji funkcji FU2. Zastosowanie profilu. Użytkownik po zaznaczeniu interesującego go profilu, wybiera opcję zastosowania profilu w konfiguracji systemu operacyjnego. Zapisanie wartości parametrów w plikach konfiguracyjnych odbywa się poprzez metodę klasy Parameter Implementacja, testowanie Implementacja Program został zaimplementowany w języku Java w wersji 7. Oprócz języka Java, rozważane było użycie języka C++. Wybór języka Java podyktowany był dużą popularnością programów napisanych w tym języku, co pomaga wyeliminować problemy związane z nieobecnością bibliotek koniecznych do uruchomienia programu podstawowe biblioteki języka C++ nie wspierają tworzenia aplikacji z interfejsem użytkownika, dostępnych jest wiele niezależnych bibliotek, jak GTK, Qt czy wxwidgets, natomiast w przypadku języka Java zainstalowana na komputerze standardowa maszyna wirtualna Javy w wersji 7 jest wystarczającym środowiskiem do uruchomienia i korzystania z powstałej aplikacji. Standardowe biblioteki języka Java, wbudowane w środowisko uruchomieniowe, umożliwiają łatwe stworzenie prostego interfejsu graficznego użytkownika, co jest istotną częścią powstałej aplikacji. Ze względu na to, że 34

35 odczyt i modyfikacja parametrów konfiguracyjnych jądra systemu Linux odbywa się poprzez dostęp do plików w systemie plików /proc, nie jest konieczne korzystanie z wywołań systemowych, co jednak mogłoby być kłopotliwe z poziomu aplikacji stworzonej w języku Java. Do tworzenia kodu wykorzystane zostało zintegrowane środowisko programistyczne Eclipse. Platforma rozwijana jest przez programistów dla programistów, przez co oferuje wiele przydatnych przy tworzeniu aplikacji, jak na przykład autouzupełnianie kodu, podstawowa analiza statyczna kodu, automatyczne formatowanie. Funkcje te wpływają na wygodę programowania, zapewniając, że kod programu jest czytelny, kompletny i nie zawiera nadmiarowych elementów, mogących negatywnie wpłynąć na działanie programu Testowanie Ze względu na stosunkowo niewielki rozmiar oraz mało skomplikowane funkcje aplikacji, poprawność działania testowana była manualnie oraz przy użyciu prostych testów jednostkowych, testujących poprawność obsługi plików. Poniżej przedstawiono przeprowadzone przypadki testowe: ID Funkcja Opis Oczekiwany rezultat T1. Odczyt z pliku 1. Odczytano zawartość pliku. 2. Porównano odczytaną zawartość z rzeczywistą zawartością pliku. T2. Zapis do pliku 1. Zapisano do pliku określoną wartość. 2. Porównano zawartość zapisanego pliku z przygotowaną wartością do zapisu. Odczytana zawartość jest równa rzeczywistej zawartości pliku. Zawartość zapisanego pliku jest równa przygotowanej wartości. T3. Odczyt z pliku wraz z konwersją typu 1. Odczytano zawartość pliku. 2. Dokonano konwersji odczytanych danych na określony typ (boolean, wartość liczbowa). 3. Porównano zawartość odczytanej zmiennej z rzeczywistą zawartością pliku. Odczytana zawartość jest odpowiedniego typu, wartość jest równa rzeczywistej zawartości pliku. 35

36 T4. Zapis do pliku wraz z konwersją typu T5. Zapis do plików konfiguracyjnych bez uprawnień T6. Brak pliku konfiguracyjnego z profilami 1. Dokonano konwersji danych określonego typu (boolean, wartość liczbowa) na łańcuch znaków. 2. Zapisano do pliku otrzymany łańcuch znaków. 3. Porównano zawartość zapisanego pliku z przygotowaną wartością do zapisu. 1. Uruchomiono program bez uprawnień administratora. 2. Wybrano opcję zastosowania jednego z dostępnych profili konfiguracyjnych. 1. Usunięto z katalogu programu plik konfiguracyjny. 2. Uruchomiono program. Zawartość zapisanego pliku jest równa przygotowanej wartości. Wyświetlony komunikat o błędzie w dostępie do pliku; zakończenie działania programu. Wyświetlony komunikat o błędzie w dostępie do pliku; zakończenie działania programu. Testy wykonywane były na bieżąco w trakcie implementacji programu pozwoliło to na wyeliminowanie błędów powstałych podczas tworzenia aplikacji. Po zakończeniu implementacji powyższy zbiór testów został przeprowadzony na aplikacji kilkukrotnie, w każdym przebiegu otrzymane rezultaty były zgodne z oczekiwanymi. 36

37 6. Analiza możliwości optymalizacji działania protokołu TCP Domyślna konfiguracja protokołu TCP w systemie Linux zapewnia jego stabilne działanie bez względu na sposób połączenia z siecią. Jednak przedstawione w rozdziale 3. niniejszej pracy różnice w zachowaniu protokołu TCP działającego w różnych środowiskach sieci ukazują, że istnienie tylko jednego zestawu wartości parametrów konfiguracyjnych protokołu TCP dla wszystkich rodzajów sieci może być niewystarczające. Możliwość zmiany wartości parametrów konfiguracyjnych jądra systemu Linux daje szansę na stworzenie alternatywnych zestawów wartości parametrów, lepiej dostosowanych do konkretnego środowiska sieci Badanie wydajności protokołu TCP Przed rozpoczęciem próby optymalizacji działania należy zbadać zachowanie protokołu przy wykorzystaniu domyślnych wartości parametrów konfiguracyjnych. Jednak przed rozpoczęciem pomiarów trzeba określić, jakie wielkości określają wydajność działania protokołu TCP. Najważniejszym wskaźnikiem wydajności jest to, jak wydajnie aplikacje działają z punktu widzenia użytkownika. Decyduje o tym kilka parametrów opisanych poniżej: opóźnienie w jednym kierunku (ang. one-way delay, OWD) - czas przekazu pakietu między dwoma punktami w sieci. Jest to różnica pomiędzy czasem otrzymania pakietu przez odbiorcę a czasem wysłania go przed nadawcę. Na OWD składają się dwa elementy związane z łączami sieciowymi: opóźnienie propagacji, czyli czas pokonania przez pakiet odcinka od jednego do drugiego końca danego łącza sieciowego oraz opóźnienie przetwarzania, będące czasem potrzebnym na konwersję pakietu na jednostkę transmisji szeregowej, np. bity. Niektóre rodzaje łączy mogą wprowadzać dodatkowe opóźnienia do OWD, ze względu na zastosowanie takich mechanizmów jak unikanie kolizji czy retransmisja uszkodzonych pakietów. czas podróży w obie strony (ang. round trip time, RTT) czas, w którym należy spodziewać się odpowiedzi od partnera komunikacji. W przypadku takich protokołów transportowych jak TCP, RTT ma wpływ na maksymalną przepustowość, jaką udaje się osiągnąć. utrata pakietów prawdopodobieństwo, że pakiet zostanie utracony podczas transmisji między lokalizacją źródłową a docelową. Głównymi przyczynami utraty pakietów są opisane we wcześniejszych częściach pracy zjawiska przeciążenia sieci i występowanie błędów transmisji. Utracone pakiety wymagają retransmisji, co zmniejsza faktyczną przepustowość sieci. przepustowość maksymalna ilość informacji, jaka może być przesłana przed dane łącze w jednostce czasu. 37

38 Najbardziej znaczącymi parametrami sieci mającymi wpływ na wydajność są opóźnienie w jednym kierunku oraz utrata pakietów. Pomiar opóźnienia w jednym kierunku jest złożonym problemem. Aby zmierzyć opóźnienie OWD, należy porównać czas wysłania pakietu przez nadawcę oraz czas odebrania go przez odbiorcę. W tym celu zegary w obu punktach komunikacji muszą być bardzo dokładnie ze sobą zsynchronizowane. Rząd dokładności synchronizacji zegarów z wykorzystaniem popularnego protokołu synchronizacji czasu NTP jest zbliżony do opóźnienia OWD w szybkich sieciach przewodowych, zatem dokładność ta może nie być dostateczna do prawidłowego oszacowania opóźnienia OWD w szybkich sieciach. Konieczna może być manualna korekta nastawy czasu lub wartości zmierzonego opóźnienia. Do pomiaru utraty pakietów należy wykorzystać monitor sieci. Strona nadająca pakiet zasygnalizuje utratę pakietów, gdy nie otrzyma potwierdzenia odebrania go przez odbiorcę Przypadki testowe Do przeprowadzenia badania wydajności protokołu TCP, wykorzystane zostały połączenia HTTP. Protokół ten jest najczęściej wykorzystywanym podczas korzystania z sieci Internet z protokołów działających w oparciu o połączenia TCP. W celu odtworzenia i zasymulowania różnych rodzajów sesji HTTP, odpowiadającym różnemu wykorzystaniu protokołu przez jego użytkowników, opracowano kilka przypadków testowych, różniących się czasem trwania oraz ilością przesyłanych danych, które przedstawiono poniżej: transmisja pojedyncza, plik o wielkości 1 KB przypadek testowy, odwzorowujący pobranie pojedynczej strony WWW (pliku *.html) bez zawartości multimedialnej, mieszczącego się w pojedynczym segmencie transmisji, transmisja pojedyncza, plik o wielkości 5 MB przypadek testowy, odwzorowujący pobranie średniej wielkości pliku z serwera WWW (np. instalatora programu), transmisja pojedyncza, plik o wielkości 50 MB przypadek testowy odwzorowujący pobranie większego pliku z serwera WWW (np. pliku instalacyjnego), transmisja wielokrotna (keep-alive), 5 plików o wielkości 100 KB, w odstępach 1-sekundowych przypadek testowy odwzorowujący pobranie strony WWW, zawierającej obrazy, animacje, transmisja wielokrotna (keep-alive), 5 plików o wielkości 5 MB, w odstępach 1-sekundowych przypadek testowy odwzorowujący przeglądanie strony WWW z dynamiczną zawartością, np. animacje Flash, przeglądarka map. 38

39 Opracowane przypadki testowe pozwalają na zbadanie zachowania się protokołu TCP w różnych warunkach. Podczas transmisji małego pliku protokół nie uruchomi złożonych algorytmów sterowania przeciążeniem, co pozwala przeanalizować zachowanie protokołu w pierwszych fazach połączenia. Transmisja dużego pliku pozwala rozpatrzyć działanie protokołu w fazie działania algorytmów kontroli przeciążenia. Transmisje wielokrotne z kolei pozwalają zbadać zachowanie protokołu podczas transferów impulsowych, z przerwami pomiędzy przesyłaniem kolejnych segmentów danych Pomiar parametrów różnych środowisk sieci Do wykonania pomiarów wykorzystano dwa komputery z zainstalowanym systemem operacyjnym Linux z jądrem w wersji Jeden z testowych komputerów podłączony był stale do routera poprzez kabel Ethernet, natomiast drugi z komputerów był łączony z siecią (LAN lub Internet) w różny sposób. W przypadku wykorzystania sieci Internet, pierwszy z komputerów korzystał z łącza typu ADSL, zestawionego z ww. routerem. Wykorzystane metody dostępu do sieci dla drugiej z maszyn testowych zostały przedstawione poniżej: sieć LAN komputer podłączony kablem Ethernet (100 Mb/s) do przełącznika wspólnego dla obu komputerów, bez wykorzystania sieci Internet, sieć WLAN komputer podłączony do tej samej domowej sieci lokalnej o niedużej liczbie podłączonych urządzeń, poprzez kartę bezprzewodową WiFi typu n, bez wykorzystania sieci Internet, łącze DSL komputer podłączony do sieci Internet z wykorzystaniem łącza DSL, różnego od połączenia wykorzystywanego przez drugi z komputerów, sieć komórkowa 2G komputer podłączony do sieci Internet poprzez modem sieci komórkowej drugiej generacji, z wykorzystaniem technologii EDGE (Orange), sieć komórkowa 3G komputer podłączony do sieci Internet poprzez modem sieci komórkowej trzeciej generacji, z wykorzystaniem technologii HSPA+ (Orange), sieć komórkowa 3G o ograniczanym transferze komputer podłączony do sieci Internet poprzez modem sieci komórkowej trzeciej generacji, z wykorzystaniem technologii UMTS/HSPA, przepustowość połączenia ograniczona przez operatora do 512 kb/s, duże wykorzystanie sieci przez innych użytkowników około godziny 19:00 (Bezpłatny Dostęp do Internetu Aero2). W celu bardzo dokładnego zsynchronizowania zegarów obu komputerów, wykorzystany został protokół NTP. Dokładność wstępnej synchronizacji nie była wystarczająca do przeprowadzenia precyzyjnych pomiarów, dlatego w celu zniwelowania różnicy, przed rozpoczęciem pomiarów uruchomiona została sesja ping, podczas której na obu maszynach uruchomiony był monitor sieci Wireshark. Na podstawie zgromadzonych 39

40 czasów wysłania i odebrania pakietów echo, poprzez przeanalizowanie sekwencji tychże pakietów, skorygowano czas systemowy obu maszyn, aby ewentualna różnica nie wpływała na wyniki pomiarów w sposób znaczący. Sesja testowa protokołu TCP polegała na pobraniu pliku poprzez protokół HTTP tak, aby nastąpiło przesłanie 500 pakietów. Opóźnienie w jednym kierunku zostało obliczone jako różnica pomiędzy czasami wysłania i otrzymania pakietów odpowiednio przez nadawcę i odbiorcę. Otrzymane wyniki zostały uśrednione. Uzyskane wyniki przedstawione zostały w poniższej tabeli: Typ sieci Minimalne opóźnienie Średnie opóźnienie Maksymalne opóźnienie Odchylenie standardowe Utracone pakiety LAN 0,012 ms 0,174 ms 1,295 ms 0,039 ms 0% WLAN 0,113 ms 11,524 ms 31,125 ms 6,576 ms 0,01% łącze DSL 1,602 ms 5,423 ms 24,211 ms 4,487 ms 0% 2G EDGE 241,01 ms 312,644 ms 387,879 ms 28,178 ms 0,1% 3G HSPA+ 37,098 ms 57,843 ms 83,027 ms 6,634 ms 0,05% 3G 512 kb/s 216,647 ms 280,978 ms 526,462 ms 81,772 ms 0,5% Tabela 1. Parametry środowisk sieciowych Testowane połączenia sieciowe charakteryzują się różnymi parametrami specyfikującymi ich wydajność. Wyraźnie widać, że łącza komórkowe charakteryzują się opóźnieniami znacznie wyższymi od łączy kablowych czy nowoczesnych łączy WiFi, występuje w nich też stosunkowo częsta utrata pakietów, co powoduje konieczność retransmisji, a w rezultacie obniżenie efektywnej przepustowości połączenia Symulowanie różnych środowisk sieci W celu zapewnienia jednorodnych warunków podczas pomiarów wpływu parametrów konfiguracyjnych protokołu TCP na jego wydajność, dalsze badania przeprowadzono w symulowanych środowiskach sieci. Rozwiązanie to pozwala na minimalizację wpływu wahań wartości parametrów sieci, jak opóźnienie czy utrata pakietów, na rezultaty pomiarów symulowane środowisko zapewnia powtarzalne warunki dla kolejnych przebiegów pomiarów. Jedno z możliwych do zastosowania rozwiązań to wykorzystanie gotowego symulatora sieci, pozwalającego na użycie maszyn wirtualnych oraz na modyfikowanie parametrów łącza. Drugie z rozważanych rozwiązań to implementacja własnego generatora opóźnień i strat pakietów z wykorzystaniem systemu z dwoma interfejsami sieciowymi. Z tych dwóch rozwiązań wybrane zostało zastosowanie gotowego symulatora sieci. Przewaga rozwiązania polega na braku konieczności samodzielnej poprawnej implementacji generatora, mogącej sprawić trudności ze względu na potrzebę korzystania z niskopoziomowych funkcji systemu operacyjnego. Ponadto, możliwość zastosowania 40

41 maszyn wirtualnych pozwala na wykorzystanie dwóch niezależnych maszyn, co w rezultacie może być wykorzystane do niezależnego manipulowania parametrami konfiguracyjnymi protokołu TCP po obu stronach transmisji. Umożliwia to sprawdzenie, czy w przypadku zmiany domyślnych wartości parametrów konfiguracyjnych protokołu wyłącznie po jednej stronie połączenia spowoduje wzrost wydajności działania, czy też do osiągnięcia poprawy wymagana jest zmiana wartości parametru po obu stronach. Do symulowania sieci wykorzystany został pakiet VDE (Virtual Distributed Ethernet) [17], wchodzący w skład projektu VirtualSquare, rozwijanego przez Uniwersytet Boloński [18]. Pakiet VDE umożliwia stworzenie wirtualnej sieci komputerowej, mogącej łączyć zarówno maszyny wirtualne, jak i rzeczywiste. Połączenia pomiędzy węzłami sieci mają wiele możliwości konfiguracyjnych: zdefiniować można m.in. maksymalną przepustowość łącza, opóźnienia pakietów, poziom utraty czy duplikacji pakietów. Jako urządzenia końcowe wykorzystano maszyny wirtualne stworzone w środowisku wirtualizacyjnym VirtualBox [19], które posiada natywne wsparcie dla pakietu VDE. Środowisko testowe do przeprowadzania pomiarów zostało stworzone z wykorzystaniem dwóch niezależnych maszyn wirtualnych działających pod kontrolą systemu Debian, z jądrem Linux w wersji Zostały one ze sobą połączone poprzez węzły vde_switch i połączenie typu wirefilter, pozwalające na specyfikowanie parametrów łącza. Rysunek 13. Schemat środowiska testowego W poniższej tabeli przedstawione zostały parametry profili łącza, wprowadzane za pomocą modułu wirefilter pakietu VDE, mające na celu odwzorowanie zachowania różnych środowisk sieciowych, oparte na rezultatach pomiarów przedstawionych w rozdziale 6.2: Typ sieci Średnie opóźnienie Odchylenie standardowe Utrata pakietów LAN 0,2 ms 0,1 ms 0% WLAN 11,5 ms 6,5 ms 0,01% łącze DSL 5,5 ms 4,5 ms 0% 2G EDGE 310 ms 30 ms 0,1% 3G HSPA+ 60 ms 7 ms 0,05% 3G 512 kb/s 280 ms 80 ms 0,5% Tabela 2. Parametry konfiguracyjne symulatora VDE dla różnych środowisk sieciowych 41

42 6.4. Wydajność domyślnej konfiguracji protokołu TCP Przed rozpoczęciem opracowywania i testowania profili konfiguracyjnych protokołu TCP dla różnych środowisk sieci, należało zbadać działanie protokołu w standardowej konfiguracji (bez modyfikacji). Jako konfigurację domyślną przyjęto niezmodyfikowaną konfigurację istniejącą w systemie Debian 7.5.0, bezpośrednio po zainstalowaniu. Wartości parametrów branych pod uwagę przy optymalizacji nastaw zostały przedstawione poniżej: net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_fack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_timestamps = 1 W tak skonfigurowanym środowisku przeprowadzono testy zgodnie z zaplanowanymi w rozdziale przypadkami testowymi, dla różnych parametrów łącza określonych w rozdziale 6.3 pracy. Dla każdej pary środowisko sieciowe przypadek testowy sesja została powtórzona trzykrotnie, otrzymane wyniki zostały uśrednione. Rezultaty testów w postaci średniego całkowitego czasu trwania sesji testowych przedstawione zostały w poniższej tabeli: LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,08s 0,05s 1,34s 0,25s 1,19s 5 MB 0,48s 1,56s 2,49s 3m26,15s 9,07s 1m48,35s 50 MB 4,42s 14,58s 22,64s 33m47,53s 1m32,28s 17m46,42s 100 KB/1s 4,19s 4,81s 4,58s 35,21s 8,36s 23,42s 5MB/1s 6,33s 12,44s 15,76s 17m6,63s 54,96s 9m8,17s Tabela 3. Czasy trwania sesji testowych dla domyślnej konfiguracji protokołu TCP Różnice w czasach zmierzonych w trzech kolejnych powtórzeniach przy tej samej konfiguracji kształtowały się na poziomie ±5%. W dwóch ostatnich scenariuszach, do całkowitego czasu trwania wliczono czterokrotne jednosekundowe oczekiwanie na kolejną transmisję Wpływ parametrów konfiguracyjnych protokołu na jego wydajność Parametry konfiguracyjne protokołu TCP decydują o zachowaniu połączenia, wpływając na jego wydajność. W zależności od środowiska sieci, dany parametr może wpływać pozytywnie albo negatywnie na wydajność protokołu Metodologia pomiarów Podczas testowania wpływu różnych nastaw parametrów konfiguracyjnych, modyfikowano ich zestaw jedynie po jednej stronie połączenia. Przy rzeczywistych 42

43 połączeniach, użytkownik przeważnie nie ma możliwości zmiany konfiguracji protokołu (jak i w ogóle całego środowiska) po drugiej stronie transmisji. Na drugiej z maszyn testowych pozostawiona została domyślna konfiguracja (por. rozdz. 6.4), uwzględniając konieczność aktywowania poszczególnych opcji protokołu TCP po obu stronach tak, aby mogły poprawnie funkcjonować (por. SACK, FACK, itp.). W pierwszej fazie pomiarów badano wpływ zmiany wartości pojedynczych parametrów konfiguracyjnych na zachowanie i wydajność połączenia. Następnie, na podstawie zgromadzonych wyników, po przeanalizowaniu wpływu poszczególnych parametrów, oceniono korelację pomiędzy zmianami wartości wielu parametrów jednocześnie Pomiary wydajności protokołu po zmianie wartości jednego parametru Wyniki testów przeprowadzonych po zmianie wartości jednego z parametrów konfiguracyjnych protokołu, przy zachowaniu domyślnych wartości dla pozostałych parametrów, w postaci uśrednionego całkowitego czasu trwania sesji testowych (przy trzech powtórzeniach, podobnie jak w rozdziale 6.4) przedstawione zostały w poniższych tabelach: LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,09s 0,05s 1,35s 0,27s 1,21s 5 MB 0,47s 1,84s 2,38s 3m46,67s 11,70s 1m55,02s 50 MB 4,42s 15,05s 22,94s 34m15,55s 1m38,72s 18m10,29s 100 KB/1s 4,17s 4,86s 4,58s 37,11s 9,38s 25,26s 5MB/1s 6,50s 13,15s 15,84s 17m23,85s 56,70s 9m24,40s Tabela 4. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_sack=0 LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,08s 0,05s 1,32s 0,27s 1,20s 5 MB 0,47s 1,72s 2,37s 3m20,80s 8,73s 1m46,45s 50 MB 4,38s 13,73s 22,61s 33m45,11s 1m28,55s 17m38,47s 100 KB/1s 4,19s 4,84s 4,56s 33,68s 7,63s 30,70s 5MB/1s 6,35s 12,69s 15,97s 17m10,99s 55,31s 8m44,46s Tabela 5. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_fack=0 LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,07s 0,05s 1,39s 0,27s 1,23s 5 MB 0,45s 1,58s 2,39s 3m28,98s 8,89s 1m56,61s 50 MB 4,33s 14,31s 22,03s 33m38,28s 1m24,59s 16m55,34s 100 KB/1s 4,17s 4,82s 4,57s 34,62s 7,35s 30,39s 5MB/1s 6,30s 11,94s 16,26s 17m28,55s 52,61s 9m1,21s Tabela 6. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_timestamps=0 43

44 LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,08s 0,05s 1,34s 0,28s 1,23s 5 MB 0,47s 1,61s 2,43s 3m25,18s 9,28s 1m46,05s 50 MB 4,38s 14,79s 22,80s 33m46,28s 1m30,18s 17m27,69s 100 KB/1s 4,20s 4,98s 4,57s 33,56s 8,39s 25,47s 5MB/1s 6,31s 12,37s 16,20s 17m9,75s 53,89s 9m1,94s Tabela 7. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_slow_start_after_idle=0 LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,07s 0,05s 1,36s 0,27s 1,17s 5 MB 0,46s 1,52s 2,39s 3m24,76s 10,52s 1m42,85s 50 MB 4,38s 15,56s 22,66s 33m46,77s 1m24,06s 17m12,35s 100 KB/1s 4,18s 4,82s 4,55s 34,31s 7,45s 23,47s 5MB/1s 6,31s 12,34s 16,21s 17m11,03s 52,61s 8m55,20s Tabela 8. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_congestion_control=vegas LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,08s 0,05s 1,31s 0,27s 1,21s 5 MB 0,47s 1,41s 2,38s 3m23,33s 10,97s 1m43,13s 50 MB 4,38s 13,15s 22,71s 33m59,73s 1m27,05s 16m54,49s 100 KB/1s 4,19s 4,80s 4,55s 34,11s 7,41s 24,62s 5MB/1s 6,34s 11,48s 15,94s 17m14,61s 52,31s 8m50,19s Tabela 9. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_congestion_control=veno LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,07s 0,05s 1,35s 0,27s 1,25s 5 MB 0,46s 1,57s 2,37s 3m24,04s 9,43s 1m44,85s 50 MB 4,38s 14,66s 22,71s 34m3,88s 1m23,84s 17m13,07s 100 KB/1s 4,19s 4,95s 4,56s 34,06s 7,49s 25,19s 5MB/1s 6,33s 13,63s 16,26s 17m27,72s 50,44s 8m54,79s Tabela 10. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_congestion_control=westwood LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,08s 0,05s 1,36s 0,28s 1,23s 5 MB 0,46s 1,58s 2,40s 3m25,82s 9,77s 1m48,33s 50 MB 4,37s 14,59s 22,72s 33m34,16s 1m34,47s 16m57,72s 100 KB/1s 4,16s 4,85s 4,55s 33,74s 7,38s 23,59s 5MB/1s 6,32s 12,92s 15,73s 17m2,71s 54,14s 8m57,04s Tabela 11. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_congestion_control=highspeed 44

45 LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,07s 0,05s 1,35s 0,27s 1,23s 5 MB 0,46s 1,59s 2,35s 3m30,10s 9,68s 1m43,79s 50 MB 4,38s 14,29s 22,54s 33m45,33s 1m23,91s 17m36,56s 100 KB/1s 4,17s 4,86s 4,59s 33,78s 7,40s 28,53s 5MB/1s 6,32s 12,42s 15,95s 17m1,28s 50,34s 8m54,53s Tabela 12. Czasy trwania sesji testowych dla parametru net.ipv4.tcp_congestion_control=hybla Powyższe wyniki odzwierciedlają działanie poszczególnych opcji protokołu TCP. Przy wyłączonej opcji SACK, zaobserwować można wyraźne wydłużenie trwania sesji testowych w środowiskach bezprzewodowych, zwłaszcza w sieci 3G o sztucznie ograniczonej przepustowości do 512 kb/s, cechującej się wysokimi wahaniami opóźnienia oraz wyższym poziomem utraty pakietów. W przypadku wyłączenia opcji znaczników czasowych, zaobserwować można wzrost wydajności bardzo szybkich łączy, jak sieć LAN. spowodowane jest to wyeliminowaniem konieczności generowania tych znaczników dla pakietów czas trwania tej operacji w stosunku do częstotliwości wysyłania pakietów w sieciach gigabitowych może wprowadzać znaczące opóźnienie. Testując zachowanie różnych algorytmów kontroli przeciążeń, zaobserwować można, iż odmiany Veno i Westwood cechują się niewielką poprawą wydajności protokołu w sieciach bezprzewodowych o większych opóźnieniach, natomiast zastosowanie odmiany HighSpeed pozwoliło osiągnąć lepsze czasy pobierania w szybkich sieciach o niewielkich opóźnieniach Propozycje profili konfiguracyjnych dla różnych środowisk sieci Na postawie powyższych badań wpływu podstawowych parametrów konfiguracyjnych protokołu TCP na jego wydajność, opracowane zostały profile konfiguracyjne dla różnych środowisk sieciowych, których zastosowanie ma na celu poprawienie wydajności połączeń TCP. Profil LAN szybkie sieci lokalne net.ipv4.tcp_congestion_control = highspeed net.ipv4.tcp_fack = 0 net.ipv4.tcp_sack = 1 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_timestamps = 0 Profil WLAN bezprzewodowe sieci lokalne net.ipv4.tcp_congestion_control = veno net.ipv4.tcp_fack = 0 net.ipv4.tcp_sack = 1 45

46 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_timestamps = 0 Profil DSL/cable przewodowe sieci DSL i kablowe net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_fack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_timestamps = 1 Profil HSPA sieci komórkowe >3G net.ipv4.tcp_congestion_control = westwood net.ipv4.tcp_fack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_timestamps = 0 Profile EDGE sieci komórkowe 2G, 3G o niewielkiej przepustowości net.ipv4.tcp_congestion_control = hybla net.ipv4.tcp_fack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_timestamps = Wydajność proponowanych profili konfiguracyjnych Działanie protokołu TCP po zastosowaniu opracowanych profili konfiguracyjnych zostało przetestowane przeprowadzając pomiary czasu trwania sesji testowych, podobnie jak w rozdziałach 6.4 oraz pomiary powtórzono trzykrotnie, a otrzymane wyniki uśredniono. Otrzymane wartości przedstawione zostały w poniższej tabeli: LAN WLAN DSL EDGE HSPA+ 3G 512kb/s 1 KB 0,02s 0,07s 0,05s 1,33s 0,27s 1,23s 5 MB 0,45s 1,42s 2,35s 3m28,41s 9,49s 1m45,47s 50 MB 4,34s 13,16s 22,60s 33m46,18s 1m23,96s 17m18,29s 100 KB/1s 4,17s 4,79s 4,57s 33,73s 7,39s 29,04s 5MB/1s 6,31s 11,52s 15,76s 17m2,05s 50,78s 8m52,71s Tabela 13. Czasy trwania sesji testowych po zastosowaniu opracowanych profili 46

47 7. Podsumowanie Przeprowadzona analiza działania poszczególnych rozszerzeń i modyfikacji protokołu TCP oraz badania w symulowanym środowisku sieciowym pozwoliły na opracowanie zestawów parametrów pozwalających korzystać z protokołu w sposób bardziej wydajny. Zastosowanie różnych wartości parametrów powodowało, iż wydajność protokołu wzrastała lub malała. Nie można zatem przyjąć, iż istnieje jedna optymalna konfiguracja. Otrzymane wyniki nie są jednak nader imponujące maksymalne z uzyskanych przyspieszeń oscylują wokół poziomu 10%. System Linux udostępnia znacznie więcej możliwości konfigurowania działania interfejsu sieciowego. Symulowane środowisko nie pozwoliło na wykorzystanie części z nich, jak opcja ECN, wykorzystywana przez zaawansowane routery do jawnego powiadamiania o przeciążeniu. Założono także stałą konfigurację drugiej strony transmisji, która również ma wpływ na wydajność działania protokołu. Uwzględnienie tych ustawień prawdopodobnie wpłynęłoby na możliwość opracowania bardziej akomodacyjnych profili. Przyjęte założenia pozwoliły jednak na pomyślne zrealizowanie podstawowego celu pracy, czyli opracowanie profili konfiguracyjnych optymalizujących działanie protokołu oraz stworzenie prostej aplikacji umożliwiającej ich łatwe stosowanie. 47

48 8. Bibliografia [1] J. Postel, Transmission Control Protocol, RFC 793, [2] K. Fall i W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols (2nd Edition), [3] M. Hassan i R. Jain, High Performance TCP/IP Networking, [4] R. Braden, Requirements for Internet Hosts - Communication Layers, RFC 1122, [5] V. Jacobson, Congestion Avoidance and Control, w Proc. ACM SIGCOMM, [6] M. Allman, V. Paxson i E. Blanton, TCP Congestion Control, RFC 5681, [7] M. Mathis, J. Mahdavi, S. Floyd i A. Romanow, TCP Selective Acknowledgement Options, RFC 2018, [8] S. Floyd, T. Henderson i A. Gurtov, The NewReno Modification to TCP's Fast Recovery Algorith, RFC 3782, [9] L. Xu, K. Harfoush i I. Rhee, Binary Increase Congestion Control for Fast, Long Distance Networks, [10] I. Rhee i L. Xu, CUBIC: A New TCP-Friendly High-Speed TCP Variant, [11] L. Wang, L. Peterson i S. Low, Understanding TCP Vegas: Theory and Practice, [12] C. P. Fu i S. C. Liew, TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks, IEEE, [13] S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi i R. Wang, TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links, [14] S. Floyd, HighSpeed TCP for Large Congestion Windows, RFC 3649, [15] C. Caini i R. Firrincieli, TCP Hybla: a TCP enhancement for heterogeneous networks, [16] P. Sarolahti i A. Kuznetsov, Congestion Control in Linux TCP, w Proceedings of Usenix, [17] R. Davoli, Virtual Square - VDE, Uniwersytet Boloński, [Online]. Adres: [Data uzyskania dostępu: 20 sierpnia 2014]. 48

49 [18] R. Davoli, Virtual Square - Main Page, Uniwersytet Boloński, [Online]. Adres: [Data uzyskania dostępu: 20 sierpnia 2014]. [19] Oracle, Oracle VM VirtualBox, [Online]. Adres: [Data uzyskania dostępu: 20 sierpnia 2014]. [20] M. Handley, J. Padhye i S. Floyd, TCP Congestion Window Validation, RFC 2861, [21] V. Jacobson, R. Braden i D. Borman, TCP Extensions for High Performance, RFC 1323, [22] J. Postel, The TCP Maximum Segment Size and Related Topics, RFC 879, [23] K. Ramakrishnan, S. Floyd i D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168,

50 9. Instrukcja użytkowania programu Optymalizacja TCP Program Optymalizacja TCP przeznaczony jest dla użytkowników systemów z rodziny Linux. Pozwala on na zmodyfikowanie wartości pięciu parametrów konfiguracyjnych protokołu TCP tak, by umożliwić jego wydajniejszą pracę w różnych środowiskach sieciowych. Program udostępnia 5 predefiniowanych profili konfiguracyjnych: LAN dla szybkich sieci przewodowych, WLAN dla lokalnych sieci bezprzewodowych, DSL/cable dla sieci typu DSL lub sieci kablowych, HSPA dla szybkich sieci mobilnych, >3G, EDGE dla wolnych sieci mobilnych, np. EDGE, sieć o limitowanej przepustowości. Profile zostały dobrane przez autora programu na podstawie badań wpływu poszczególnych parametrów na działanie protokołu. Ich użycie powinno pozwolić na wydajniejsze działanie transmisji TCP. Ponadto, możliwe jest dodawanie własnych profili konfiguracyjnych, stworzonych na podstawie już istniejących. Do uruchomienia programu wymagana jest maszyna wirtualna Javy w wersji 7 lub nowszej oraz uprawnienia administratora (konieczne w celu wprowadzenia zmian w konfiguracji systemu). Przygotowany skrypt uruchamiający tcp_param.sh, dołączony do programu, sprawdza podstawowe warunki uruchomienia (istnienie wymaganych plików oraz uprawnienia administratora). Przykładowe wywołanie skryptu: sudo./tcp_param.sh. Po uruchomieniu programu, na ekranie pojawia się główne okno programu. Zaprezentowane są w nim aktualnie zapamiętane profile. Program podczas uruchamiania sprawdza aktualną konfigurację systemu i zaznacza aktualnie obowiązujący profil, w przypadku braku odpowiadającego profilu, tworzony jest dodatkowy profil Aktualne ustawienia. Rysunek 14. Okno główne programu 50

51 Przyciski na dole ekranu odnoszą się do aktualnie zaznaczonego profilu. Przycisk Zastosuj powoduje wprowadzenie zmian zdefiniowanych w danym profilu do konfiguracji systemu. Przycisk Edytuj uruchamia okno edycji zaznaczonego profilu. Przycisk Usuń usuwa zaznaczony profil z konfiguracji programu. Podczas edycji profilu, dostępne jest okno prezentujące ustawienia danego profilu. Możliwa jest modyfikacja ustawień oraz zapisanie zmian w tym samym profilu lub stworzenie nowego profilu. W celu stworzenia nowego profilu, w polu Nazwa profilu należy podać nową, unikalną nazwę dla tworzonego profilu w przypadku wystąpienia wybranej nazwy w innym profilu, program poinformuje o błędzie i pozwoli na wprowadzenie nowej nazwy. Nie jest możliwa zarówno edycja, jak i usunięcie profilu predefiniowanego. Rysunek 15. Okno edycji profilu 51