Trwający przez dłuższy czas brak wyświetlania niektórych stron internetowych, regularne kilkudziesięciosekundowe zamierania transferu, przesyłki nie dochodzące do adresata to problemy, które często pojawiają się w Waszej korespondencji. Sieć i tematyka transmisji ma tyle wspólnego z informatyką co chirurgia oka z medycyną ogólną. Nic więc dziwnego, że zanim podjęłam ten temat musiałam się znów czegoś douczyć. Ze względu na stopień złożoności tematu, niezbędną wydaje się na początek odrobina teorii, która pozwoli łatwiej poruszać się w temacie nawet jeśli nie znajdziecie tu rozwiązania wszystkich Waszych problemów. Zjawisko fragmentacji pakietu Wbrew pozorom przesyłany w sieci pakiet danych rzadko porusza się w niej w całości. Najczęściej pakiet, lub jak kto woli datagram, jest dzielony na mniejsze części (fragmenty), które podróżują w sieci jako oddzielne datagramy. Trafiając do ostatecznego odbiorcy muszą zostać złożone. Przypomina to segmentowe ściąganie plików takimi narzędziami jak NetTransport czy GetRight. Gdy jakiś fragment zostanie zagubiony, datagram nie może zostać odtworzony, a w efekcie przesyłka nie dociera do adresata. Trzeba też wiedzieć, że maszyna odbierająca z chwilą otrzymania fragmentu początkowego, uruchamia zegar składania. Gdy czas na zegarze przekroczy określoną wartość, zanim nadejdą wszystkie fragmenty, maszyna odbierająca porzuca otrzymane fragmenty bez przetwarzania datagramu. Jest zatem oczywiste, że wraz z pojawieniem się fragmentacji prawdopodobieństwo utraty danych wzrasta, gdyż utrata pojedynczego fragmentu pociąga utratę całego datagramu. Jak to się dzieje, że poszczególne fragmenty pakietu nie są gubione permanentnie? Kontrola fragmentacji Każdy z fragmentów zawiera nagłówek, w którym jest powielona znaczna część zawartości nagłówka pierwotnego pakietu. Do kontroli procesów fragmentacji i składania datagramów służą trzy pola nagłówka: identyfikacja, znaczniki i przesunięcie fragmentu. 16-bitowe pole identyfikacja zawiera unikalny identyfikator i to właśnie on zapobiega wymieszaniu się fragmentów pochodzących od różnych datagramów. Wszystkie kawałki będące częściami tego samego pakietu pierwotnego muszą zatem posiadać ten sam identyfikator. 3-bitowe pole znaczniki służy do właściwej kontroli fragmentacji. Pierwszy z trzech bitów nie jest używany. Jeżeli drugiemu nada się wartość 1 będzie to oznaczało bezwzględny zakaz fragmentacji. Stąd prosty wniosek, że jeśli datagram nie będzie mógł być przesłany w całości to zostanie odrzucony, a nadawca otrzyma, przynajmniej teoretycznie, komunikat o błędzie. Ostatni z bitów - przesunięcie fragmentu - umożliwia z kolei identyfikację ostatniego kawałka datagramu, w którym ma wartość 0, a w pozostałych fragmentach pakietu - 1. Czwarte pole nagłówka to czas życia TTL które określa jak długo, w sekundach, datagram może pozostawać w sieci. Wymogiem protokołu TCP/IP jest aby każdy router podczas przetwarzania nagłówka datagramu zmniejszał wartość tego pola co najmniej o 1, nawet jeśli rzeczywiste przetwarzanie trwało krócej. Jeżeli jednak router jest przeciążony i czas przetwarzania jest dłuższy, wówczas wartość pola TTL zmniejsza się o czas faktycznego pozostawania datagramu wewnątrz routera. Gdy wartość pola zmaleje do zera router porzuca datagram i wysyła do nadawcy komunikat o błędzie. Zaletą tego mechanizmu jest to, że zapobiega on w ten sposób podróżowaniu datagramów w sieci w nieskończoność, np. gdy tablice tras są nieaktualne, albo adres odbiorcy nie istnieje. To jeszcze nie wszystkie pola nagłówka, ale w naszych rozważaniach najważniejsze. Jak łatwo zauważyć, to czy pakiet w ogóle dotrze do odbiorcy zależy w głównej mierze od jego wielkości i czasu przebywania w sieci. Idealnym zatem rozwiązaniem byłoby przesyłanie datagramu, który nie ulegnie fragmentacji i bez pośrednictwa routerów. Jest to możliwe tylko wówczas gdy dwa komputery podłączone są do tej samej sieci fizycznej np. Ethernet. W rzeczywistości jednak zmuszeni jesteśmy korzystać z wielu sieci fizycznych połączonych przez specjalizowane routery,  które wybierają trasy przesyłania na podstawie informacji o najkrótszych ścieżkach. Te jednak często różnią się maksymalną jednostką transmisyjną, która wymusza fragmentację pakietu. I tak dochodzimy wreszcie do parametrów, które decydują o sygnalizowanych problemach, a tym samym mogą mieć wpływ na ich ograniczenie. Podstawowe parametry konfiguracyjne MTU (Maximum Transmission Unit) – to parametr wyznaczający maksymalny rozmiar przesyłanego pakietu danych. Inaczej można powiedzieć, że jest to jednostka określająca maksymalną ilość danych jakie mogą "przełknąć" routery dostawców Internetu. W skład Windows wchodzi specjalny program, który zajmuje się dobieraniem tego parametru, a jego wybór jest dokonywany podczas nawiązywania każdego połączenia z dostawcą usług internetowych. Wielkość MTU ustawiona domyślnie dostosowana jest do obsługi sieci lokalnych i wynosi 1500 bajtów, co powinno gwarantować optymalną szybkość transmisji danych w sieciach LAN oraz przy większości rodzajów łączy stałych. Tak jest jednak w teorii. Właśnie ta wielkość była powodem poważnych problemów użytkowników Neostrady Plus. Okazało się bowiem, że do przesyłania informacji używa ona protokołu PPPoE (PPP over Ethernet), w którym zmodyfikowano nagłówek powiększając go o 8 bajtów. Tym samym domyślna wartość MTU powinna być ustawiona w systemie na 1492 bajty, a nie na 1500. Ta niewielka różnica spowodowała jednak, że zbyt duży pakiet nie mógł być odebrany przez router w całości i w rezultacie odsyłał on do serwera komunikat ICMP o złym rozmiarze pakietu. W normalnej sytuacji, serwer po otrzymaniu takiego komunikatu powinien wysłać wszystkie następne pakiety w zmniejszonym rozmiarze. Rzecz w tym, że wiele serwerów w obawie przed przeciążeniem blokuje komunikaty ICMP, a nie otrzymując informacji o błędach - kontynuuje wysyłanie pakietu, który jest za duży. Skutkiem było właśnie przerywanie transmisji i problemy z otwieraniem stron www. Załóżmy jednak, że komunikat ICMP dociera prawidłowo i praktyka pokrywa się z teorią. Jeśli pakiet okaże się dla serwera dostępowego za duży to siłą rzeczy musi on początkowo odmówić ich przyjęcia. Po nieudanej próbie kontaktu system dopasuje wielkość wysyłanych pakietów do wymagań serwera. Niestety za każdym razem tracimy nawet kilka sekund na dostrajanie się systemu. Biorąc to pod uwagę bezpieczna wartość MTU dla sieci LAN, dla DSL oraz dla modemów kablowych powinna być ustawiona na 1492, natomiast dla modemu 56K - na 576. Czy to już zapobiegnie fragmentacji? Nie do końca. Ponieważ pakiety wędrują po sieci między różnymi routerami może się zdarzyć, że trafimy na router, który nie radzi sobie z pakietami takiej wielkości i pomimo wszystko podzieli je na kilka mniejszych, które później będą składane. Dobierając jednak odpowiednią wartość unikniemy niepotrzebnych przestojów, a protokoły komunikacyjne po nawiązaniu połączenia od razu będą mogły przystąpić do wymiany danych. MSS (Maximum Segment Size) - to maksymalny rozmiar pakietu danych, jaki może być przesłany za pośrednictwem protokołu TCP/IP. Parametr MSS jest w zasadzie pochodną MTU i odnosi się do wielkości samych informacji zawartych w pakietach danych. Różnica polega jedynie na tym, że wielkość MTU dotyczy całego pakietu - czyli zarówno przesyłanej informacji jak i nagłówków TCP i IP, a MSS tylko samej informacji. Z uwagi na to, że wspomniane nagłówki zajmują w każdym pakiecie 40 bajtów, wartość parametru MSS na przykład dla połączeń dial-up wynosi zwykle 536 bajtów. RWIN (Receive Window) – to parametr określający maksymalny rozmiar pakietu jaki może wysłać serwer zanim otrzyma potwierdzenie odbioru. Jako że wydajność połączenia w dużej mierze zależy od przepustowości odcinka sieci między dwoma komputerami, ustala on maksymalną wielkość danych jakie komputer może wysłać do nadawcy bez uzyskania gwarancji (potwierdzenia), że poprzednio wysłane pakiety dotarły do celu. Im połączenie jest wolniejsze a Sieć bardziej przeciążona, tym częstotliwość relacjonowania odbioru pakietów powinna być większa. Wartość RWIN uzależniona jest od MTU (a dokładnie od MSS) i stanowi jego parzystą wielokrotność. Zależnie od systemu operacyjnego zaleca się stosować różne wielokrotności chociaż delikatnie mówiąc najlepiej z nimi trochę poeksperymentować. Według autorów programu Accelerate 2K2 dla wersji systemów Windows 9x i ME, RWIN powinien wynosić 4 lub 6 krotną wartość MSS, natomiast systemy NT, 2000 i XP są w stanie obsłużyć ośmio, a nawet dziesięciokrotną wartość MSS. Oczywiście parametry te trzeba dostosować także do szybkości posiadanego łącza. TTL (Time To Live) - ten parametr, o którym była już mowa wyżej, ma kolosalne znaczenie, ponieważ określa tzw. czas życia pakietu danych. Często spotyka się nie do końca poprawną definicję, że jest to wartość w nagłówku IP, która wyznacza liczbę routerów, przez które może przejść pakiet w drodze do celu. Byłoby tak, gdyby rzeczywisty czas przetwarzania na każdym z nich nie przekraczał 1 sekundy. Modyfikując ten parametr, można jednak z pewnym przybliżeniem określić, jaką maksymalną drogę, liczoną liczbą routerów może przebyć datagram. Jest taki sprytny program Visual Route, w którym wystarczy wpisać określony adres internetowy na świecie aby otrzymać specyfikację wszystkich routerów jakie brały udział w połączeniu. Jeżeli ich liczba wyniosła np. 36 to z góry możemy być pewni, że przesłany datagram nigdy nie dotrze do adresata przy domyślnych ustawieniach TTL, które wynoszą 32. Zaleca się zatem zmodyfikowanie tego parametru zwiększając go do 128. W przypadku Windows 2000 i XP system poradzi sobie z takimi ustawieniami, natomiast przy Win 98 i ME może się to nie udać. Jeśli w czasie połączeń otrzymacie komunikaty z informacją typu "connection timeout" może to oznaczać, że wartość TTL w systemie ma ustawioną zbyt niską poprzeczkę i wysyłane pakiety po prostu nie docierają do miejsca przeznaczenia. Przy tej okazji warto wspomnieć także o trzech innych funkcjach: PMTU Auto Discovery (Path Maximum Transfer Unit Auto Discovery) - funkcja ta zawarta w niektórych akceleratorach, odpowiada za możliwość negocjowania wielkości pakietów MTU. Oznacza to, że zależnie od serwera, z którym nasz komputer nawiązuje połączenie, wartość MTU może się odpowiednio zmieniać. Można ją także wykorzystać do zapobiegania fragmentacji pakietów poprzez zablokowanie parametru PMTU jednak kosztem znacznego spowolnienia transferu danych, a nawet ich utraty gdy pakiet na swej drodze będzie musiał być podzielony. PMTU Black Hole Detection - funkcja zależna od PMTU Discovery. Próbuje ona wykrywać routery, które po nadejściu zbyt dużych pakietów o zablokowanej możliwości fragmentacji odrzucają ich obsługę, nie zgłaszając przy tym użytkownikowi żadnego ostrzeżenia. Standardowo zaleca się wyłączyć tę opcję, chyba że celowo blokujemy wielkość wysyłanych pakietów. Session Keep Alive - odpowiada za podtrzymywanie aktywnej sesji połączenia z serwerem w czasie, gdy ani nasz komputer ani serwer nie zgłaszają zapotrzebowań na kolejne bity danych. Mówiąc prościej – gdy oglądamy stronę www nasze połączenie z serwerem, mimo że pozostaje aktywne, nie generuje żadnego ruchu, a to z kolei doprowadzić może do automatycznego zerwania połączenia. Aby temu zapobiec opcja Session Keep Alive pozwala określić co jaki czas system ma wysyłać do serwera kontrolny pakiet podtrzymujący aktywne, choć „milczące” połączenie. System Windows standardowo wysyła do serwera potwierdzenie aktywności co 60 minut. Akceleratory internetowe pozwalają jednak modyfikować ten okres nawet do 1 sekundy, co w wyjątkowych sytuacjach może być przydatne. Skoro już wszystko wiemy – jak zmodyfikować nasze domyślne ustawienia? Modyfikacja ustawień w Rejestrze W celu zmiany domyślnych ustawień Windows przechodzimy do klucza: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces Otworzy się nam lista wszystkich obecnych w systemie interfejsów sieciowych. Będzie ich z pewnością więcej niż jeden, ponieważ MS Windows za urządzenie sieciowe uznaje każde urządzenie bądź interfejs programowy, który może przesyłać dane. W jednym z nich, w prawej części okna, znajdziemy nasz adres IP. To właśnie w tym kluczu zmodyfikujemy wartość DWORD MTU wstawiając odpowiedni parametr. Niezależnie od orientacyjnych wartości jakie podałam wyżej warto sprawdzić je praktycznie porównując opóźnienia przy różnych wielkościach MTU. Jak to zrobić? Z menu Start wybieramy Uruchom i wpisujemy cmd Teraz w wierszu poleceń: ping –f –l 548 www.onet.pl lub inną polska stronę

Wartość 548 to sprawdzana wielkość MTU zmniejszona w każdym przypadku o 28. Jak widać przesłanie pakietu o wielkości charakterystycznej dla modemu 56K nie sprawiło problemu i dotarł on w całości, a co ciekawe w czasie niewiele krótszym niż pakiet 1472 bajtowy. Oznacza to, że moje połączenie kablowe może obsłużyć z powodzeniem pakiet o takiej wielkości. Tu jednak mała uwaga. Zmieniając adresata przesyłki może się zdarzyć coś takiego:

Oznacza to, że pakiet trafił po drodze na router, który musi go podzielić, ale funkcja taka została zablokowana. Lepiej więc nie przesadzać z wielkością pakietu. Wróćmy jednak do Rejestru. Pozostałe parametry znajdziemy w kluczu: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters] w którym modyfikujemy lub dodajemy następujące wartości DWORD: EnablePMTUBHDetect (patrz funkcja PMTU Black Hole Detection) Włącza lub wyłącza wykrywanie "czarnej dziury" w połączeniach TCP/IP. Najlepiej jeśli jest wyłączony – 0 DefaultTTL To ustawienie decyduje o tym jak długo pakiet "pozostanie przy życiu" - TTL (Time to Live Acitve). Możliwe ustawienia to 32, 64, 96, 128, 256. Najlepiej ustawić 128. EnablePMTUDiscovery To ustawienie włącza automatyczne wykrywanie MTU (Max. Transmition Unit) przez system. Najlepiej jeśli jest włączone – 1 TCPWindowSize Jest to wielokrotność ustawienia MSS. Należy zatem sprawdzić najlepszą dla siebie wartość MTU odjąć od niej 40 i dopiero pomnożyć (dla modemu 56K – czterokrotnie) Tcp1323Opts i Tcp1320Opts Włącza lub wyłącza support dla "dużych okien TCP" (large TCP window). Jeżeli funkcja ta zostanie wyłączona czyli zmienna przyjmie wartość 0, to wielkość okna zostanie ograniczona do 64K. Zaleca się ustawienia na Win.Scaling with Timestamp - 3 lub Win.Scaling without Timestamp - 1 StackOpts Jeżeli poprzednia funkcję włączyliśmy to tę również należy włączyć i wartości DWORD przypisać zmienną 1. Zamiast ręcznej i dość żmudnej pracy można posłużyć się jednym z dostępnych tweakerów lub narzędzi specjalnie w tym celu zaprojektowanych. Osobiście polecam SG TCP Optymizer, który jest już w dziale Downloads.

Jak widać uwzględnia on także protokół DSL (PPPoE) wykorzystywany przez Neostradę Plus. Można z jego pomocą o wiele prościej wykonać testowy ping i otrzymać natychmiast podpowiedź jaka wartość MTU możemy zastosować. Program optymalizuje parametry połączenia internetowego ale także zezwala na własne ustawienia i automatycznie dopisuje je do Rejestru.  Niektóre z nich możemy przeprowadzić także za pomocą Madonote. Dodatkową zaletą SG TCP Optimizer jest to, że nic nie kosztuje. Oczywiście to nie jedyne narzędzie. Warto sprawdzić także: Internet Accelerator 1.31 - umożliwia zmniejszenie czasu otwierania stron internetowych oraz optymalizuje połączenie z Siecią. Internet Cyclone 1.86 - służy do optymalizacji ustawień systemowych w celu zwiększenia wydajności połączenia z Internetem. Aplikacja umożliwia automatyczną optymalizację łącza bądź też pozwala użytkownikowi modyfikować poszczególne parametry. Throttle 6.12.13.2004 - pozwala modyfikować ustawienia systemowe dla wszelkiego typu modemów, dzięki czemu prędkość połączenia z Internetem może znacząco wzrosnąć. Dodatkowo program (bez modyfikowania ustawień sprzętowych) eliminuje częste zrywanie połączenia i zawieszanie się modemu. Życzę płynnego serfowania na maksymalnej szybkości.