potwierdzenie przez TCP nie gwarantuje, że dane zostały dostarczone

W RFC 793 jest część dotycząca potwierdzania segmentów TCP:

Gdy TCP przesyła segment zawierający dane, umieszcza kopię w kolejce retransmisji i uruchamia stoper; po otrzymaniu potwierdzenia dla tych danych segment jest usuwany z kolejki. Jeśli potwierdzenie nie zostanie odebrane przed upływem czasu, segment jest retransmitowany.

Potwierdzenie przez TCP nie gwarantuje, że dane zostały dostarczone do użytkownika końcowego , ale tylko, że odbierający TCP wziął na to odpowiedzialność.

To jest interesujące. W naszym NOC często rozwiązujemy problemy z łącznością między naszą siecią a zewnętrzną siecią kliencką i za każdym razem, gdy wąchamy ruch na zaporze i widzimy bity SYN i ACK wysyłane i odbierane w obu kierunkach, zakładamy, że połączenie zostało ustanowione i problem nie ma nic do zrobić z siecią.

Ale teraz ten RFC zmusił mnie do zastanowienia się - co jeszcze powinienem sprawdzić (bez konfigurowania Wiresharka), czy połączenie TCP zostało nawiązane, ale użytkownicy nadal mają problemy z łącznością?

Ta część RFC dotyczy przekazania odpowiedzialności systemowi operacyjnemu lub innemu etapowi procesu. Zasadniczo dotyczy separacji warstw.

Potwierdzenie przez TCP nie gwarantuje, że dane zostały dostarczone do użytkownika końcowego, ale tylko, że odbierający TCP wziął na to odpowiedzialność.

Zawsze o tym myślałem:

• System operacyjny może ulec awarii między wysłaniem ACK a danymi docierającymi do procesu klienta („klient” oznacza tutaj klienta systemu operacyjnego, a nie „klienta sieciowego”)
• Proces klienta może być wadliwy lub ulegać awarii, lub po prostu znacznie wolniej niż się spodziewano, aby zająć się przychodzącymi danymi lub w rzeczywistości czytać je tylko w nieoczywistych okolicznościach
• Jeśli klient wysyła dane dalej, być może do pliku na dysku, plik mógł nie zostać jeszcze zapisany lub wyczyszczony
• Jeśli klient wysyła dane dalej za pośrednictwem protokołu TCP, TCP po drugiej stronie może nie przesłać danych, odebrał potwierdzenie ACK lub proces z powodzeniem wykorzystał dane

Mówi tylko, że jest to potwierdzenie warstwy 3 („Słyszę twoje bajty”), a nie wyższe potwierdzenie warstwy . Weźmy na przykład różnicę między TCP ACK, SMTP 250 OKpo bramie poczty następnego przeskoku akceptuje wiadomość, wiadomość odbioru wiadomości (np. Zgodnie z RFC 3798 ), piksel śledzenia otwierany wiadomości, podziękowanie od PA, i odpowiedź: „Tak, zrobię to”.

Innym konkretnym przykładem może być drukarka:

• Musi potwierdzić dane wcześniej, zanim będzie wiedział, co zawiera ich koniec (może to być plik Postscript rozpoczynający się od dołączonej biblioteki większej niż okno transmisji TCP)
• Może zawierać zapytanie o status („czy masz papier?”, Które oczywiście można wykonać)
• Może zawierać polecenie drukowania („wydrukuj to”, co może się nie powieść, jeśli zabraknie papieru)

Sugerowałbym, że jeśli użytkownicy widzą i wysyłają ACK, ale nadal występują problemy z łącznością, prawdopodobieństwo wystąpienia zatorów, systemu operacyjnego lub aplikacji jest większe niż w przypadku ściśle związanych z siecią.

Aby zdiagnozować, sugeruję poszukiwanie retransmisji, a nie w szczególności ACK.

Z perspektywy RFC „użytkownikiem końcowym” jest aplikacja. Nie ma gwarancji, że aplikacja otrzyma dane, tylko proces TCP je otrzyma.

Z punktu widzenia NOC sieć działa, a dane docierały do ​​hosta końcowego. Prawdopodobnie na tym wszystkim ci zależy.

Możesz to zobaczyć w ten sposób.

Jesteś M.Smith i chcesz wysłać list do M.Toto (osoby są warstwą aplikacji).

Aby wysłać list, idź do lokalnego urzędu pocztowego A, który wyśle ​​list do lokalnego urzędu pocztowego B T. M. Toto (urzędy pocztowe są warstwą TCP).

Wszystko może przebiegać dobrze między tobą, poczta A i poczta B - B wyślemy ACK na pocztę A. Ale nic nie gwarantuje, że list dotrze do M. Toto. Wszystko może się zdarzyć między pocztą B a M.Toto.

Tak właśnie mówi RFC.