OK ... najpierw łatwe części.
MTU to maksymalna jednostka transmisji w łączu sieciowym. Zasadniczo określa to, jak duży pakiet może obsłużyć łącze sieci lokalnej ... jest to rozmiar „warstwy 2” (zwykle Ethernet), więc IP, TCP, UDP i inne nagłówki liczą się do tej wartości. Całkiem proste.
MSS to maksymalny rozmiar segmentu. Jest to wartość TCP wysyłana w pakietach SYN (zarówno SYN, jak i SYN / ACK). Określa ilość danych, które mogą być zawarte w segmencie TCP. Jest to element na poziomie TCP, więc jeśli pakiet IP zostanie pofragmentowany podczas transportu, MSS odnosi się do ilości danych w segmencie TCP ponownie złożonego pakietu. Nieco mniej proste, ale wciąż dość łatwe do rozgryzienia.
Teraz sprawy się komplikują.
RWIN to WINdow odbierający TCP. Jest to wartość określona po stronie odbiorcy połączenia TCP w polu „Rozmiar okna” nagłówka TCP. Okno stale dostosowuje swój rozmiar podczas trwania połączenia TCP. Dla każdego kierunku połączenia TCP jest okno. Punkty końcowe TCP nie będą idealnie zsynchronizowane ze sobą co do aktualnego rozmiaru okna kierunku połączenia TCP na czas trwania połączenia TCP.
OK, pamiętaj więc, że TCP reprezentuje bajt danych. Punkt końcowy będzie miał bufor pamięci w systemie operacyjnym do odbierania danych TCP dla połączenia. Bufor ten jest reprezentowany (przynajmniej teoretycznie) przez rozmiar okna. Gdy dane są umieszczane w buforze, rozmiar okna zmniejsza się, a gdy dane są odczytywane z bufora przez aplikację, rozmiar okna będzie się zwiększał.
Strona wysyłająca połączenia TCP nie przesyła więcej danych niż rozmiar okna, dopóki nie otrzyma z powrotem pakietów potwierdzenia, które zwiększają rozmiar okna.
OK ... trochę głębiej, tutaj ...
Rozważmy hipotetyczną jednostronną transmisję danych o wielkości bufora w odbiorniku 10 bajtów. Na początku połączenia rozmiar okna wyniesie 10.
Nadawca wysyła segment zawierający 5 bajtów danych. Nadawca uważa teraz, że okno ma rozmiar 5 bajtów (nadal trzyma te 5 wysłanych bajtów na wypadek, gdyby musiał je ponownie wysłać, dopóki nie otrzyma potwierdzenia). Odbiornik nie otrzymał jeszcze pakietu, więc nadal uważa, że jego rozmiar okna wynosi 10 bajtów.
Nadawca wysyła następnie segment zawierający 3 bajty danych. Nadawca uważa, że okno ma teraz rozmiar 2 bajtów (10–5 = 5, 5–3 = 2). Odbiornik nadal nie otrzymał żadnych pakietów, więc nadal uważa, że rozmiar okna wynosi 10. Nadawca trzyma teraz 8 bajtów danych w celu potencjalnej retransmisji.
Odbiornik odbiera pierwszy segment, przechowuje dane w buforze i wysyła potwierdzenie. Należy zauważyć, że system operacyjny odebrał dane i potwierdza ich otrzymanie, ale aplikacja nadal nie ma danych. Potwierdzenie będzie miało potwierdzenie ACK wynoszące 5 (w stosunku do wybranych początkowych numerów sekwencji) i rozmiar okna wynoszący 5 (ponieważ dane nadal siedzą w buforze, zajmując 5 bajtów bufora 10 bajtów).
Nadawca otrzymuje potwierdzenie 5 bajtów, więc może przerzucić pierwsze 5 bajtów, które wstrzymywał w celu retransmisji, ponieważ wie, że udało się dotrzeć do odbiorcy. Wciąż utrzymuje pozostałe 3 bajty z drugiego segmentu, ponieważ nie zostały jeszcze potwierdzone. Nadawca widzi, że rozmiar okna wysłany przez odbiorcę wynosi 5, ale reprezentuje 5 bajtów od numeru potwierdzenia. Nadawca wie, że wysłał już kolejne 3 bajty, dla których nie otrzymał potwierdzenia, więc nadal uważa, że rozmiar okna to 2 bajty.
Nadawca wysyła teraz segment zawierający 2 bajty danych. Teraz widzi zerowe okno TCP, co oznacza, że nie może wysłać więcej danych, dopóki odbiornik nie otworzy tego okna dalej. Nadawca ponownie trzyma 5 bajtów danych w celu potencjalnej retransmisji (3 z drugiego segmentu i 2 z trzeciego segmentu).
Odbiornik odbiera drugi segment z 3 bajtami. Teraz ma 8 bajtów danych w buforze. Wysyła pakiet potwierdzający o numerze potwierdzenia 8 (w stosunku do numeru sekwencji początkowej) i rozmiarze okna 2. Te 8 bajtów danych wciąż znajduje się w buforze systemu operacyjnego.
Teraz aplikacja odczytuje 7 bajtów danych z bufora. Bufor ma teraz 1 bajt danych. Całkowity rozmiar okna wynosił 10, ale z jednym bajtem danych, co pozostawia 9 bajtów dostępnych, więc odbiornik wysyła pakiet z numerem potwierdzenia 8 (ponieważ nie otrzymano żadnych nowych danych), ale rozmiar okna jest teraz 9 (w porównaniu z 2 poprzednio). W ten sposób okno się powiększa, aby nadawca mógł wysyłać więcej danych.
Nadawca otrzymuje ACK 8 bajtów o rozmiarze okna 2. Nadawca może podrzucić 3 bajty danych z 2. segmentu, ale wysłał już kolejne 2 bajty, a rozmiar okna w tym pakiecie wynosi 2, więc nadawca nadal widzi okno o zerowym rozmiarze i nie może wysłać więcej danych.
Odbiornik otrzymuje trzeci segment z 2 bajtami. Umieszcza 2 bajty w buforze, pozostawiając 7 bajtów wolnych. Wysyła pakiet z ACK 10 (5 + 3 + 2) i rozmiarem okna 7.
Nadawca otrzymuje ACK z numerem potwierdzenia 8 i rozmiarem okna 9. Wysłał już ogółem 10 bajtów, więc nadal widzi dwa bajty zaległe, więc widzi rozmiar okna 7 (9 - 2).
Nadawca ma tylko 5 dodatkowych bajtów do wysłania. To pasuje całkowicie do rozmiaru okna, więc wysyła 5 bajtów. Teraz widzi okno o rozmiarze 2, ale tak naprawdę nie ma znaczenia, ponieważ nie ma już danych do wysłania. Przechowuje teraz 7 bajtów danych w celu potencjalnej retransmisji.
Nadawca otrzymuje ACK z numerem potwierdzenia 10 i rozmiarem okna 7. Rzuca 2 bajty z trzeciego segmentu, wciąż ma 5 bajtów, które może zatrzymać w celu potencjalnej retransmisji.
Odbiornik otrzymuje czwarty segment z 5 bajtami danych, dodaje te dane do swojego bufora (nie zawierającego 8 bajtów), wysyła ACK o numerze potwierdzenia 15 i rozmiarze okna 2.
Aplikacja następnie odczytuje 8 bajtów siedzących w buforze, więc bufor jest teraz pusty. Odbiornik wysyła potwierdzenie z numerem potwierdzenia 15 i rozmiarem okna z powrotem na pełne 10.
Nadawca otrzymuje ACK z numerem potwierdzenia 15 i rozmiarem okna 2. Może teraz podrzucić ostatnie dane, które przechowywał w celu potencjalnej retransmisji. Wie, że wszystkie jego dane dotarły do odbiorcy. Tak naprawdę nie przejmuje się wielkością okna 2, ponieważ i tak nie ma już danych do wysłania.
Nadawca otrzymuje ostatnie potwierdzenie z numerem potwierdzenia 15 i rozmiarem okna 10.
OK, to wszystko dla hipotetycznego ... mam nadzieję, że pomoże ci zrozumieć, jak działa okno odbierania i jest obsługiwane przez każdą ze stron. To samo dzieje się przy użyciu numerów sekwencyjnych, numerów potwierdzeń i rozmiaru okna dla dowolnych danych przesyłanych w drugą stronę przez połączenie TCP.
Wartości RWIN w pakietach z bitami FIN powinny mieć takie samo znaczenie. Czy możesz podać przykład tego, co widzisz w Wireshark, abyśmy mogli pomóc w ich interpretacji?