TCP wewnątrz SSTP: dlaczego retransmisja zdarza się dwa razy

Plotka dociera przed protokołem. Zapytaj wokół, a SSTP jest tym wolnym, opcją, której unikasz, chyba że coś cię zmusi. Ta reputacja opisuje jeden tryb awarii na jednym rodzaju ścieżki.

Mechanizm jest realny. Jest też warunkowy, o czym reputacja nigdy nie wspomina.

Dwa niezawodne strumienie na jednej ścieżce

SSTP owija swój tunel w sesję HTTPS. HTTPS działa przez TCP, a ten zewnętrzny strumień gwarantuje uporządkowane dostarczanie. Dlatego jeden brakujący segment wstrzymuje wszystko, co stoi w kolejce za nim. Późniejsze bajty należące do innych wewnętrznych rozmów i tak czekają.

Wewnętrzne strumienie TCP zachowują własną kolejność i kontrolę przeciążenia. Nie widzą zewnętrznego odtwarzania, więc jedyne, co obserwują, to zastój. Zastój to sygnał, który mówi im, że ścieżka jest przeciążona.

Teraz obie warstwy cofają się jednocześnie. To cała interakcja, a jeden utracony segment wystarczy, by ją rozpocząć.

Gdzie efekt się pojawia, a gdzie nie

Na czystej ścieżce zewnętrzny strumień rzadko coś odtwarza. Interakcja nigdy się nie uruchamia, a SSTP doskonale przenosi ruch interaktywny. Ogólne twierdzenie zawodzi dokładnie w tym punkcie.

Efekt pojawia się, gdy utrata lub zmiana kolejności dociera do ścieżki bazowej. Przeciążone łącze Wi-Fi lub połączenie mobilne o zmiennym opóźnieniu tworzą warunki. Zablokowana zewnętrzna kolejka zamienia się wtedy w widoczne opóźnienie wewnątrz tunelu.

Efekt rośnie też wraz z obciążeniem. Wiele równoległych strumieni zapełnia kolejkę i pogarsza blokowanie na czele kolejki. Jedna sesja interaktywna na tej samej ścieżce może wydawać się akceptowalna.

Czym objaw zwykle nie jest

Nie każda wolna sesja to ten problem. Stałe niskie tempo od pierwszego pakietu wskazuje na przepustowość, kształtowanie lub limit serwera. Pauzy pokrywające się z lokalnym przeciążeniem wskazują na kolejki na łączu dostępowym.

Środki się różnią, dlatego diagnoza przychodzi pierwsza. Strojenie buforów nic nie daje w przypadku kształtowanego łącza. Zmiana protokołów nic nie daje serwerowi, któremu skończyła się przepustowość. Powtarzane resety wskazują zupełnie inne miejsce.

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

Wykonaj pomiar, gdy problem występuje. Zapis zrobiony w zdrowej minucie niczego nie dowodzi o pętli działającej w tej złej.

Porównanie, któremu warto zaufać

Jeśli inny transport jest naprawdę dostępny, porównaj go w kontrolowanych warunkach. Ten sam host, ta sama sieć, ten sam cel i to samo zadanie. Oba przebiegi muszą mieścić się w tych samych dziesięciu minutach, aby warunki ścieżki były zgodne.

Zmiana portu nie zmienia protokołu. Import niepowiązanego profilu do klienta SSTP nie tworzy alternatywnego transportu. Porównanie ma sens tylko wtedy, gdy serwer oferuje drugą opcję.

Utrzymuj weryfikację TLS przez cały czas. Praca nad wydajnością nie jest powodem, by akceptować niezweryfikowany certyfikat. Jeśli zastoje pojawiają się głównie wtedy, gdy łącze wysyłowe jest nasycone, sprawdź kolejki, zanim obwinisz warstwy.