Trzepak.pl


Forum zablokowane  Ten temat jest zamknięty. Nie można w nim pisać ani edytować postów.
Autor Wiadomość
Post: wt, 09 sie 2016 17:31:26 
   Tytuł: MTU - Kompendium
Zgłoś ten post Odpowiedz z cytatem
Offline
Młodszy czytelnik
Młodszy czytelnik
Awatar użytkownika

Rejestracja: śr, 07 sty 2015 11:08:25
Posty: 54
Lokalizacja: Szczecin
Z powodu, iż na przestrzeni wielu lat istniało sporo zamieszania w kwestii MTU a nikt na forum się nad tym nie rozpisywał, postanowiłem napisać post, który w zwarty i (mam nadzieje) przejrzysty sposób przedstawi wszystkie najważniejsze zagadnienia i problemy związane bezpośrednio z MTU, oraz rozwiąże wszystkie dotychczasowe wątpliwości, ewentualnie uzupełni braki wiedzy.

Zacznijmy od tego co to jest MTU


MTU (ang. Maximum Transmission Unit) jest to maksymalna ilość danych które mogą zostać przeniesione przez protokół warstwy 2. modelu OSI za jednym razem. W przypadku Ethernetu ilość danych zawartych w pojedynczej ramce waha się od 46 bajtów do maksymalnie 1500 bajtów. Tak więc w przypadku standardowego Ethernetu wartość MTU wynosi 1500 bajtów.

Obrazek


Pójdźmy o krok dalej, ile będzie wynosiła wartość MTU dla interfejsu PPPoE?

Lecz najpierw wyjaśnijmy czym jest PPP

PPP (ang. Point to Point Protocol) jest protokołem warstwy łącza danych tak samo jak Ethernet, został on zaprojektowany do enkapsulacji pakietów IP na łączach telefonicznych, jednakże jego elastyczność i możliwość uwierzytelniania doprowadziła do tego, że używany jest do dzisiaj głównie jako warstwa pośrednia. Dwa popularne sposoby jego użycia to protokół PPPoA, gdzie PPP jest warstwą w sieciach ATM, oraz PPPoE gdzie analogicznie PPP jest przenoszone w ramkach Ethernet.

PPP może „załadować” maksymalnie 1500 bajtów danych, co sprawia że wartość MTU dla łącza PPP wynosi 1500 bajtów. Jednakże my musimy go dodatkowo zakapsułkować w ramce Ethernet tak jak robi to PPPoE. Minimalna wielkość nagłówka pakietu PPPoE wynosi 8 bajtów. Oznacza to, że mając dyspozycji 1500 bajtów payload’u Ethernetu, po umieszczeniu w nim pakietu PPPoE nagłówek protokołu zabierze nam 8 bajtów z potencjalnej liczby możliwych do przesłania danych. Poniższy rysunek przedstawia opisaną sytuację

Obrazek


* W rzeczywistości nagłówek PPPoE ma 6 bajtów długości, natomiast kolejne dwa są zarezerwowane dla protokołu PPP, lecz dla uproszczenia i przejrzystości na schemacie zostało zostało to zaznaczone właśnie w taki sposób. #RFC2516

Warto w tym miejscu wspomnieć o tym, że standardowy Ethernet może być rozbudowany o obsługę „Jumbo frame”, rozszerzenie to pozwala na zwiększenie ilości przenoszonych danych przez pojedynczą ramkę nawet do 9000 bajtów.
Warto zauważyć że użycie nieznacznie większej ramki (np. Baby Jumbo) do kapsułkowania PPP niweluje konieczność ograniczania MTU do 1492 bajtów.

Obrazek


Jednak oprócz oczywistej konieczności obsługi Jumbo frame, w celu osiągnięcia payload’u PPPoE większego niż 1492 bajty obydwie strony połączenia muszą wspierać negocjację wartości MTU większej niż domyślne dla PPPoE 1492 bajty. Dokument #rfc4638 opisuje zasadę działania wspomnianego rozszerzenia. Od razu nadmienię, że wszystkie MikroTiki obsługują tę funkcjonalność.

Oczywiście różne protokoły warstwy 2. OSI posiadają odpowiednio różne wartości MTU.

PMTU


Teraz, gdy wiemy już czym jest MTU nadeszła pora by przejść do meritum czyli do „Path Maximum Transmission Unit” w skróce PMTU.

Jak łatwo się domyślić nie wszyscy w Internecie czy w obrębie danej sieci muszą korzystać z tych samych protokołów warstwy łącza danych. Jako, że operujemy na sieciach IP, tras z punktu A do B może być bardzo wiele, co sprawia że trasa pomiędzy np. serwerem a klientem końcowym może prowadzić przez wiele przeskoków a co za tym idzie serwer i klienta dzieli wiele ścieżek. Każda z tych ścieżek może być obsługiwana przez najróżniejsze protokoły łącza danych z czego każda z nich posiada specyficzne dla siebie właściwości. Nas oczywiście interesują wartości MTU każdej z nich. Tak więc PMTU jest to maksymalna wartość MTU, która jest obsługiwana przez wszystkie węzły na danej trasie, przykład:

Obrazek


Na przedstawionej wyżej topologii dla klienta i serwera wartość MTU to 1500 bajtów, natomiast pomiędzy R1 i R2 wartość MTU wynosi 1200 bajtów. Oznacza to, że wartość MTU dla tej ścieżki wynosi 1200 bajtów. Dlaczego? ponieważ R1 nie jest w stanie przesłać do R2 datagramu IP w wielkości 1500 bajtów i vice versa.

IP a MTU

Jak wiemy używając protokołu IP jesteśmy w stanie przesłać w jednym datagramie do 65535 bajtów danych. Jest to więc o wiele więcej niż nasza trasa może przenieść, pytanie które się tu rodzi to: Co się dzieje z naszym datagramem IP jeżeli jest większy niż wartość MTU ścieżki przez którą podróżuje?

Protokół IP został zaprojektowany z pełną świadomością tego, że ujednolicenie wszystkich węzłów do obsługi konkretnego MTU jest niemożliwe. Dlatego też protokół IP dostarcza nam funkcjonalność fragmentowania datagramów IP. Zasada działania jest prosta, kiedy router otrzymuje datagram IP, którego nie jest w stanie przekazać dalej z faktu iż jest on większy niż maksymalny rozmiar pakietu interfejsu przez który musi zostać przekazany następuje fragmentacja. Router, który otrzyma zbyt duży pakiet dzieli go na fragmenty w taki sposób, by mógł zostać przekazany dalej. Do każdego fragmentu dodawane są nagłówki IP z oryginalnego datagramu z ustawionym polem Fragment Offset (domyślnie pole to wynosi 0), które to określa położenie bieżącego fragmentu wewnątrz datagramu. W takiej formie datagramy docierają do odbiorcy, który na podstawie wspomnianego wskaźnika składa fragmenty w całość.

Tak więc operując na powyższym rysunku datagram o wielkości np. 1500 bajtów dotrze do R1, gdzie zostanie podzielony na dwa fragmenty 1200 i 320 bajtowe. Dodatkowe 20 bajtów pojawiły się z faktu, iż do drugiego fragmentu musimy „dokleić” 20 bajtowy nagłówek IP, by mógł się stać datagramem IP.

Obrazek


Takie założenie wczesnego Internetu było bardzo obiecujące i rozwiązywało problem MTU raz na zawsze. Niestety czas udowodnił że fragmentacja IP to fatalne rozwiązanie.

Dlaczego fragmentacja IP jest zła?

  • Przeprowadzanie fragmentacji w routerach ogromnie spowalnia obróbkę datagramów.
  • Wprowadza dodatkowe narzuty, ponieważ używanych jest więcej nagłówków.
  • Większa liczba fragmentów zwiększa prawdopodobieństwo ich utraty lub uszkodzenia.
  • Jeśli pojedynczy fragment zostanie zgubiony lub uszkodzony, protokół warstwy wyższej (np. TCP) musi rozpocząć przesyłanie datagramu od początku, co prowadzi do ponownej fragmentacji a to z kolei do obciążenia routera i marnotrawstwa pasma

Istnieje możliwość ustawienia znacznika DF (don’t fragment) w nagłówku datagramu, co spowoduje że router przekazujący taki pakiet nie może wykonać fragmentacji. W takim przypadku router zobowiązany jest do wysłania komunikatu ICMP typu 3. kodu 4. (destination unreachable, fragmentation needed and DF set).


TCP i opcja MSS

Gdy projektowano protokół TCP istniało pewne założenie, które mówiło, że host nie może wysłać datagramu większego niż 576 bajtów, chyba że ma specyficzną wiedzę o tym, że host docelowy jest przygotowany do odbioru większych pakietów.
Z tego powodu w nagłówku TCP znajduje się opcja Maximum Segment Size, w skrócie MSS, która mówi o tym jaki maksymalny rozmiar segmentu TCP dany host jest w stanie odebrać lub wysłać.

MSS jest to maksymalna wielkość datagramu IP, (czyli de facto MTU) minus nagłówek IP minus nagłówek TCP.

Gdy obydwie strony ogłoszą swoje wartości MSS, transmisja nie może operować na segmentach większych niż najniższa z ogłoszonych wartości MSS.

Domyślna wartość MSS wynosi 536 bajtów (jest ona używana wtedy gdy zdalny host przesyła puste pole MSS) i każdy host musi być w stanie odebrać segment o tej wielkości, nie ważne czy w kawałkach (fragmentacja IP) czy w całości. Pojawia się mały problem, otóż zarówno IP jak i TCP mogą mieć zmienną długość nagłówków, dlatego w dokumencie #RFC879 ustanowiono, że MSS liczony jest na podstawie najmniejszych możliwych nagłówków (czyli po 20 bajtów).
Wartość MSS jest ogłaszana tylko w momencie nawiązywania połączenia czyli podczas standardowego three-way handshake

Aby nie być gołosłownym policzmy wartość MSS dla Ethernetu gdzie MTU wynosi 1500 bajtów.
1500 – 20 – 20 = 1460 [bajtów] – łatwizna ;)

Obrazek

Na powyższym zrzucie widzimy three-way handshake, gdzie host nawiązujący połączenie ogłosił MSS 1460, natomiast serwer 1440 co oznacza, że w trakcie tego połączenia największe segmenty TCP będą miały wielkość 1440 bajtów.

Path MTU Discovery (PMTUD) – tu się zaczyna zabawa

Jak wcześniej pisałem fragmentacja IP okazała się porażką, tak więc protokoły warstwy wyższej nie mogły dłużej polegać na tej funkcjonalności IP. Aby uniknąć fragmentacji protokoły warstwy wyższej musiały mieć sposób na odkrywanie MTU ścieżki, by odpowiednio dopasować rozmiar wysyłanych danych. Sposób ten został opisany w dokumencie #RFC1191.

Metoda działania

Idea działania PMTUD polega na tym by podczas komunikacji posługiwać się pakietami z ustawionym bitem DF (don’t fragment) w nagłówku IP. Jeżeli dowolny router na trasie nie będzie w stanie dostarczyć pakietu w całości, będzie on musiał odesłać do nadawcy komunikat ICMP typu 3. kodu 4. (destination unreachable, fragmentation needed and DF set) dalej nazywany wiadomością PTB (Packet too big message). Co ważne dokument #RFC1191 wymaga od wszystkich hostów, by w przypadku wysyłania wiadomości PTB, w nieużywanym wcześniej polu ICMP została zapisana informacja o wartości MTU kłopotliwego przeskoku. W przypadku otrzymania wiadomości PTB host orientuje się, że wysyłane przez niego pakiety są zbyt duże i redukuje ich wielkość w oparciu o wartość MTU z wiadomości PTB. Jeżeli dalsza komunikacja będzie przebiegała pomyślnie oznacza to, że udało się ustalić prawidłową wartość MTU ścieżki.

Obrazek


Dokument #RFC1191 jasno nakreśla, że od momentu implementacji PMTUD protokoły warstwy wyższej muszą mieć możliwość komunikacji z systemem operacyjnym w celu uzyskania informacji o wartości MTU ścieżki dla danego celu. Od tego momentu system operacyjny zobowiązany jest do przetrzymywania informacji o MTU ścieżek i udostępniania ich protokołom warstwy wyższej. Informacje o ścieżkach muszą być okresowo czyszczone, ze względu na potencjalną możliwość zmiany trasy.

Pewną małą niedogodnością PMTUD jest „round trip time” czyli czas podróży w obie strony. Podczas normalnej komunikacji klient wysyła żądanie, które jest odbierane przez serwer i następuje natychmiastowa odpowiedź. W przypadku kiedy router przerywa poprawną komunikację odrzucając zbyt duży pakiet potrzeba dodatkowego czasu na dotarcie wiadomości PTB do serwera i ponowne nadanie mniejszego pakietu. W przypadku jednego „wąskiego gardła” sytuacja nie wygląda aż tak źle, ale wystarczy sobie wyobrazić co się dzieje gdy takich przeszkód pojawi się kilka. Należy podkreślić że to samo może przytrafić się klientowi, który będzie próbował wysłać duże żądanie lub zwyczajnie wysłać jakąś dużą ilość danych do serwera.

Jako że dokument #RFC1191 opisuje jedynie metodykę działania PMTUD, konieczna jest osobna implementacja dla każdego z protokołów warstwy wyższej. O ile nie ma problemu z protokołami połączeniowymi (np. TCP), tak w przypadku protokołów bezpołączeniowych (np. UDP) programista sam musi zaimplementować PMTUD wewnątrz aplikacji. Najczęściej stosuje się do tego okresowe próbkowania ICMP, gdyż z racji na zastosowanie takiego protokołu rzadko kiedy może nadarzyć się okazja wysłania większej ilości danych.

Problemy PMTUD

ICMP Black Hole

Problem „czarnej dziury” to niepodważalnie największa bolączka PMTUD występująca głównie w implementacji dla TCP, która uderza wprost w podwaliny zasady działania samego protokołu. To właśnie ta dolegliwość w głównej mierze przyczyniła się do szybkiego znienawidzenia protokołu odkrywania MTU ścieżki. Jest to w zupełności uzasadnione, gdyż problem ten jest na tyle poważny, że uniemożliwia on jakąkolwiek dalszą komunikację pomiędzy hostami. Analizując ten przypadek aż dziw bierze, że autorzy pierwotnej wersji nie przewidzieli możliwości wystąpienia sytuacji opisanej poniżej.

Jak wcześniej pisałem, kiedy pakiet jest zbyt wielki by router mógł go przesłać dalej musi zostać wysłana wiadomość zwrotna PTB. Niestety jak się okazuje wiele routerów tego nie robi – zaczynając od przyczyn błędnej konfiguracji kończąc na przesadnych politykach bezpieczeństwa, które są narzucane przez administratorów sieci wycinając cały ruch ICMP. Innym źródłem przyczyniającym się do zablokowania przepływu wiadomości PTB są firewalle, które również potrafią odrzucić wszelki ruch ICMP z rzekomych przyczyn bezpieczeństwa.

Tak więc gdy komunikaty PTB nie docierają do nadawcy, protokół warstwy wyższej w dalszym ciągu próbuje wysyłać duże pakiety, jednak bez odebrania komunikatu ICMP nigdy nie odkrywa że konieczna jest redukcja rozmiaru wysyłanych pakietów. W taki oto sposób host może wysyłać w nieskończoność (do momentu przekroczenia czasu żądania) przytłaczającą ilość retransmisji, które to znikają bezpowrotnie w „czarnej dziurze”. Taka sytuacja powoduje zatrzymanie komunikacji pomiędzy hostami i prowadzi do całkowitego „zawieszenia” się połączenia.

Obrazek


Tak, to właśnie może być przyczyną wiecznego ładowania się strony WWW w przeglądarce internetowej ;)
Jak widzimy pierwotna wersja PMTUD nie jest zbytnio przekonująca, dlatego obecnie administratorzy dokładają wszelkich zmagań by uniknąć konfrontacji z dziurawą funkcjonalnością protokołu TCP.

PLMTUD - Packetization Layer Path MTU Discovery

PLMTUD to opisana w dokumencie #RFC4821 poprawiona wersja pierwotnego PMTUD opisana głównie dla protokołu TCP. Wprowadza ona między innymi funkcję wykrywania zjawiska „czarnej dziury”.

Dokument #RFC4821 opisuje między innymi w jaki sposób maja być wysyłane próbki, co jaki czas mają być one wysyłane i jakich mają być wielkości, dokładnie określa również zachowania jakie należy podjąć podczas ich utraty. Protokół na podstawie informacji o przepływie danych potrafi sam określić czy zgubiona próbka jest wynikiem zatoru czy wystąpienia zjawiska ICMP black hole.

W przypadku wystąpienia ICMP black hole protokół samoczynnie powraca do poprzednich, działających wartości MTU w przypadku gdy połączenie trwa na tyle długo, że została wszczęta ponowna procedura odrywania MTU ścieżki lub stopniowo obniża wielkości wysyłanych pakietów do momentu aż nie zostanie odnaleziona prawidłowa wartość PMTU. W tym przypadku protokół jest w stanie zredukować wielkość datagramów IP maksymalnie do 68 bajtów lub w przypadku IPv6 do 1280 bajtów co odpowiada minimalnym rozmiarom datagramów IP.

W niektórych przypadkach protokół jest w stanie całkowicie wyłączyć funkcję wykrywania MTU ścieżki pozwalając na fragmentację IP poprzez ustawienia bitu DF na 0.

PLMTUD to naprawdę solidnie zaprojektowany protokół, niestety między publikacją pierwotnej wersji PMTU a nową minęło 17 lat. W tym czasie każdy już znał sposób na obejście problemu źle działającego PMTUD.

Jedyną bolączką nowego protokołu jest fakt, że w przypadku nawiązania nowego połączenia protokół potrzebuje trochę czasu na to by zorientować się czy utrudnienia w komunikacji występują z powodu zatoru czy też z wystąpienia ICMP black hole. To niestety przekłada się na opóźnione działanie zapobiegawcze a to z kolei prowadzi do np. długiego ładowania się strony internetowej. Czas ten w moim przypadku zwykle wynosił ok. 8 sekund, co jest niestety wartością o wiele za dużą jeżeli problem ma występować na wszystkich ścieżkach (bo np. stacja kliencka jest „wąskim gardłem”).

Jest jeszcze jeden mały problem. W większości przypadków protokół ten trzeba włączyć….ręcznie a przecież wiadomo, że przeciętny Kowalski podczas wystąpienia problemu z ładowaniem strony WWW nie przejdzie do ustawień systemowych i nie włączy sobie funkcji próbkowania MTU.

MSS Clamping

W związku z tym, że PMTU zawodzi a do czasu pojawienia się PLPMTU minęło 17 lat, administratorzy sieci przez ten czas musieli znaleźć sposób na ominięcie irytującego problemu zawieszających się połączeń.

Z uwagi na fakt, że wśród klientów końcowych na całym świecie dominuje Ethernet, ciężko byłoby aby użytkownik operujący na 1500 bajtowych pakietach nie mieścił się w szerokopasmowych łączach pomiędzy systemami autonomicznymi, dlatego śmiało można wysunąć wniosek, że w ok. 100% przypadków wąskie gardło MTU występuje po stronie providera internetowego. W praktyce oznacza to, że takich przeszkód nie powinno być więcej niż jedna.

Technika MSS Clampingu polega na sztucznej podmianie wartości MSS podczas nawiązywania połączenia tak, by później przesyłane pakiety nie przekraczały MTU routera gdzie mogłyby zostać odrzucone.

Gdy host nawiązuje połączenie TCP wysyła również informację o maksymalnej wielkości segmentu jaki jest w stanie odebrać. Oznacza to, że przesyłane segmenty nigdy nie będą większe niż te ogłoszone przez MSS. Gdy pakiet TCP z ustawioną flagą SYN dociera do urządzenia providera, ten jest w stanie podmienić wartość MSS w taki sposób by przesyłane później pakiety mieściły się w sieci dostawcy. Gdy tak zmodyfikowany pakiet dotrze do hosta docelowego, ten odpowie pakietem SYN, ACK gdzie z kolei będzie się znajdowała jego wartość MSS, która również zostanie podmieniona na urządzeniu providera.

W ten sposób jesteśmy w stanie całkowicie wyeliminować potrzebę użycia PMTUD, co niesie za sobą wiele pozytywów:
  • Unikniemy konfrontacji z ICMP black hole
  • Nie tracimy czasu na round-trip wiadomości PTB
  • Obydwa hosty od razu znają optymalną wartość MTU ścieżki (zakładając, że nigdzie indziej nie wystąpi podobny problem)

Ważne jest by wartość MSS była podmieniana zarówno w pakiecie SYN hosta nawiązującego połączenie jak i hosta zdalnego. W przeciwnym wypadku host inicjujący połączenie nigdy by się nie dowiedział, że MSS dla sesji wynosi mniej i wysyłając zbyt duży segment wszcząłby działanie procedury PMTUD.

Należy pamiętać również o tym, aby zmian w pakietach dokonywać tylko wtedy gdy wartość MSS jest większa od tej, którą potrzebujemy osiągnąć. W sytuacji, gdzie któryś z hostów faktycznie miałby mniejsze MSS a my podmienilibyśmy je na większe, host ten otrzymałby w rezultacie zbyt duży pakiet by mógł go odebrać, co znowu mogłoby postawić na nogi PMTUD.

Obrazek


Oczywiście zastosowanie MSS Clampingu wymaga od routera przeanalizowania każdego pakietu TCP, co przekłada się na bardzo duże obciążenie procesora. Dlatego zalecane jest by zmian wartości MSS dokonywało urządzenie dostępowe po stronie klienta (CPE), aniżeli jeden router.

Warto przypomnieć, że stosując MSS Clamping rozwiązujemy problem jedynie dla protokołu TCP. Tak jak wspomniałem wcześniej, inne protokoły bezpołączeniowe nie dostarczają żadnego mechanizmu wykrywania MTU ścieżki, dlatego muszą być one implementowane bezpośrednio w aplikacji. Najczęściej do tego celu wykorzystuje się komunikaty ICMP z ustawioną flagą DF.



MTU w praktyce


Była teoria, czas na praktykę.

Topologia sieci użyta w trakcie przeprowadzania testów:

Obrazek


1. Odkrywanie MTU ścieżki za pomocą komunikatów ICMP

Najłatwiejszym i najszybszym sposobem na wykrycie MTU ścieżki jest wysłanie PINGa

Obrazek


W moim przypadku używany jest ping z GNU/Linux. Opcja „-M do” wymusza ustawienia flagi DF, natomiast „-s” oznacza wielkość danych ICMP. 1472 + 8 bajtów nagłówka ICMP + 20 bajtów nagłówka IP daje nam 1500 bajtów co jest równoważne z MTU interfejsu z którego ping jest wysyłany.

PC1
Obrazek


Jak widzimy, gdy pierwsze żądanie dociera do R1, ten odpowiada wiadomością PTB z której dowiadujemy się, że MTU następnego przeskoku wynosi 1200 bajtów. Następne próby wysłania pinga kończą się niepowodzeniem, ponieważ od momentu otrzymania wiadomości PTB system pamięta MTU ścieżki do 192.168.3.2 co zresztą możemy zobaczyć poprzez polecenie „ip route get”

Obrazek


Jak łatwo można odczytać, wartość MTU jest domyślnie cachowana na 10 minut.

2. PMTUD

Sprawdźmy teraz jak wygląda proces automatycznego odkrywania MTU ścieżki. Na PC1 uruchomiony jest serwer HTTP z którego spróbujemy pobrać dane za pomocą PC2. Przed rozpoczęciem przechwytywania na PC1 została wyczyszczona pamięć podręczna.

PC1
Obrazek


Jak widzimy podczas nawiązywania połączenia obydwie strony ogłosiły MSS na poziomie 1460 co odpowiada MTU 1500 bajtów. Pakiety te bez problemu zmieściły się w wąskim gardle pomiędzy R1 i R2 podobnie jak żądanie HTTP klienta. Gdy serwer odpowiada na żądanie plikiem html wysyłając pakiet o wielkości 1514 bajtów otrzymuje komunikat PTB od R1. Orientuje się wtedy, że wysyłany przez niego pakiet był zbyt duży i natychmiast rozpoczyna retransmisję jednak tym razem wielkości pakietów nie przekraczają 1214 bajtów dzięki czemu dane docierają do odbiorcy a dalsza komunikacja przebiega bezproblemowo. Wielkości pakietów w programie wireshark liczone są wraz z nagłówki warstwy 2, stąd dodatkowe 14 bajty odpowiadające długości nagłówka Ethernetu.

Jak widać przy sprawnie działających komunikatach ICMP PMTUD działa wyśmienicie, dlatego najwyższy czas by wyciąć cały ruch ICMP i zasymulować ICMP black hole.

3. PMTUD vs ICMP black hole

W celu zasymulowania ICMP black hole na R1 został wycięty ruch ICMP. Następnie w przeglądarce internetowej na PC2 został wpisany adres PC1.

Widok od strony serwera (PC1):
Obrazek


oraz od strony klienta (PC2):
Obrazek


Jak widzimy, nawiązanie połączenia oraz nadanie żądania HTTP przebiegło bezproblemowo, jednak próba wysłania odpowiedzi zakończyła się fiaskiem. Serwer wysyła segmenty TCP w wielkości 1460 bajtów co przekracza MTU ścieżki, jednak nigdy się o tym nie dowiaduje i ponawia próby wysłania danych z coraz to większym interwałem czasowym. Po 5 sekundach od momentu nawiązania połączenia przeglądarka internetowa klienta wysłała pakiet FIN oznaczający chęć zakończenia połączenia. Serwer jednak ma jeszcze do przesłania mnóstwo danych i nie pozwala na zakończenie łączności, przez co przeglądarka w dalszym ciągu sygnalizuje ładowanie się strony. Widoczny na zrzutach ekranu pakiet RST został wygenerowany na skutek zamknięcia okna przeglądarki.

4. PLPMTUD

W celu uruchomienia funkcjonalności PMTUD na systemie GNU/Linux należy zmienić ustawienie kernela:

Obrazek


Następnie analogicznie do poprzedniego testu PC2 próbuje pobrać dane z PC1 za pośrednictwem HTTP, jednakże tym razem w celu uzyskania czytelnego wyniku pobierany jest jedynie plik CSS.

Widok z PC1:

Obrazek


Klient standardowo nawiązuje połączenie z serwerem oraz wysyła żądanie HTTP, jednakże próba wysłania danych przez serwer nie przynosi żadnych rezultatów i po kilku próbach retransmisji zmniejsza wielkość przesyłanego segmentu co przynosi oczekiwany rezultat w postaci potwierdzenia odebranych danych przez klienta. W tym przypadku czas potrzebny na przesłanie danych wynosił ponad 3 sekundy, jednak przy próbie pobrania większego pliku PDF czas ten diametralnie wydłużył się do 80 sekund, co jest niestety nie do zaakceptowania. Podczas próby pobrania całej strony czas ten jeszcze bardziej się wydłużył a to dlatego, że przeglądarka po odebraniu pliku html (co już zabrało parę sekund) nawiązała dodatkowo kilka innych połączeń w celu pobrania plików css i czionek.

Co ciekawe wykryta w ten sposób wartość MTU ścieżki nie została w żaden sposób zapamiętana przez system operacyjny:

Obrazek


Co oznacza, że odświeżenie strony lub przejście na podstronę zajmie równie dużo czasu. Niestety nie sprawdzałem tej funkcjonalności na systemie Windows jednak takie zachowanie jest jest dla mnie niezrozumiałe. Zapamiętanie MTU ścieżki sprawiłoby, że poruszanie się w obrębie jednego serwisu odbywałoby się o wiele szybciej.

5. MSS Clamping

W celu wykonania MSS Clampingu posłużę się standardowym firewallem jakim jest iptables.

Obrazek


W ten sposób każdy przesłany dalej pakiet TCP z flagą SYN będzie modyfikowany pod kątem zmiany wartości MSS w taki sposób by pasował do MTU interfejsu wyjściowego. Jeśli chcielibyśmy ustawić tę wartość na stałe zamiast opcji „--clamp-mss-to-pmtu” należy użyć „--set-mss”.




Podsumowanie

Mam nadzieję, że pisząc ten post wyczerpałem temat MTU i co za tym idzie każdy forumowicz mający problem z tym zagadnieniem trafi w to miejsce i nabędzie solidną porcję wiedzy, która pozwoli mu rozwiązać wszystkie dotychczasowe kłopoty mające podłoże MTU.

Konkludując chciałbym zebrać wszystkie wnioski płynące z tego tekstu w jednym miejscu:

  • Standardowa funkcjonalność TCP w zakresie PMTUD jest wadliwa i należy jej unikać szerokim łukiem.
  • W przypadku kiedy jesteśmy zmuszeni ustawić MTU mniejsze niż 1500 bajtów stosujmy technikę MSS Clampingu.
  • Tam gdzie to tylko możliwe korzystajmy z funkcjonalności „Jumbo Frame” i niwelujmy problem wąskiego gardła.
  • Nie wycinajmy ruchu ICMP a przynajmniej typu 3. nie utrudniajmy życia innym.

Słowem zakończenia chciałbym serdecznie zaprosić wszystkich użytkowników forum do komentowania i ewentualnego zgłaszania błędów w osobnym, przeznaczonym do tego temacie

Pozdrawiam :ok:


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Forum zablokowane  Ten temat jest zamknięty. Nie można w nim pisać ani edytować postów.


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
Dzisiaj jest wt, 27 cze 2017 12:13:57

Strefa czasowa UTC+02:00
Nakarm glodne dziecko - wejdz na strone www.Pajacyk.pl


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
SubSilver2 modified for Trzepak.pl by Colir
Polski pakiet językowy dostarcza phpBB.pl