W jakich okolicznościach TCP-over-TCP działa znacznie gorzej niż sam TCP (2014)?

25

Wielu administratorów nieustannie utrwala - zarówno na ServerFault, jak i gdzie indziej - jak kiepski jest pomysł TCP-over-TCP, np. W VPN. Że nawet najmniejsza utrata pakietów spowoduje, że ktoś ucierpi z powodu co najmniej poważnego pogorszenia przepustowości, jeśli nie załamanie TCP, i dlatego należy bezwzględnie unikać TCP-over-TCP. I to chyba kiedyś było prawdą, np. W 2001 r., Kiedy napisano ten artykuł, o którym wciąż się mówi.

Ale od tego czasu zaobserwowaliśmy znaczny postęp w technologii i protokołach. Obecnie „Selektywne ACK” jest wdrażane prawie wszędzie, a prawo Moore'a dało nam o wiele więcej pamięci, a wraz z nim pojawiły się duże bufory TCP zoptymalizowane pod połączenia w górę Gbit. Również utrata pakietów jest obecnie znacznie mniejszym problemem w przypadku łączy innych niż radiowe. Wszystko to powinno znacznie złagodzić problem TCP-over-TCP, prawda?

Należy pamiętać, że istnieją rzeczywiste scenariusze, w których np. Sieci VPN oparte na TCP są łatwiejsze do wdrożenia i obsługi niż te oparte na UDP / ESP (patrz więcej poniżej). Dlatego moje pytanie:

W jakich okolicznościach (utrata i opóźnienie pakietu łącza) TCP-over-TCP działa znacznie gorzej niż sam TCP, zakładając obsługę SACK i bufory TCP o odpowiedniej wielkości na obu końcach?

Byłoby wspaniale, więc zobacz niektóre pomiary, które pokazują korelacje między utratą / opóźnieniem pakietu (połączenie zewnętrzne) a przepustowością / fluktuacją (połączenie wewnętrzne) - dla TCP-over-TCP i tylko dla TCP. Znalazłem ten interesujący artykuł , ale wydaje się, że martwi się on jedynie opóźnieniami i nie zajmuje się (zewnętrzną) utratą pakietów.

Ponadto: Czy istnieją zalecane ustawienia (np. Opcje TCP, ustawienia bufora, zmniejszenie MTU / MSS itp.) W celu zmniejszenia różnic w wydajności między TCP a TCP-over-TCP?


Aktualizacja: Nasze uzasadnienie.

To pytanie jest nadal bardzo istotne w niektórych rzeczywistych scenariuszach. Przykładowo, wdrażamy urządzenia osadzone w dużych budynkach, które zbierają dane z czujników i wprowadzają je na naszą platformę przez VPN. Problemem, przed którym stoimy, są zapory ogniowe i niepoprawnie skonfigurowane łącza w górę, których nie mamy pod kontrolą, w połączeniu z niechętnymi działami IT. Zobacz szczegółowy przykład omówiony tutaj .

W wielu takich przypadkach przejście z sieci innej niż TCP na opartą na TCP sieć VPN (bardzo łatwe, jeśli używasz OpenVPN jak my) to szybka poprawka, która pozwala nam uniknąć bitew pod palcami. Np. Często port TCP 443 jest ogólnie dozwolony (przynajmniej przez proxy), lub możemy rozwiązać problemy Path-MTU, po prostu zmniejszając opcję MSS TCP.

Dobrze byłoby wiedzieć, w jakich okolicznościach VPN oparty na TCP można uznać za realną alternatywę, abyśmy mogli podjąć świadomą decyzję przewyższającą zalety i wady każdej z opcji. Na przykład wiemy, że TCP-VPN jest dla nas odpowiedni w przypadku łączy innych niż radiowe, ale mamy spory udział zdalnych klientów w łączach typu uplink 3G ze znaczną utratą pakietów i dużym opóźnieniem - jak tam działałby TCP-VPN?

Starałem się odpowiednio poprawić tytuł i główne pytanie; mam nadzieję, że to ma sens.

Nils Toedtmann
źródło
Szybko zauważysz różnicę między TCP przez TCP a UDP (itp.) Przez TCP VPN podczas korzystania z nich w sesjach interaktywnych, np. Ssh. Zauważysz opóźnienie, jeśli nie spadnie sesja. YMMV, TIAS
Daniel S. Sterling
Tylko jeśli połączenie „zewnętrzne” podlega przede wszystkim pewnym opóźnieniom lub utracie pakietów. Mam wiele sesji SSH w sieciach VPN opartych na TCP i wiele z nich działa dobrze bez zauważalnego opóźnienia.
Nils Toedtmann,
Rzeczywiście - działa, gdy masz dobrą sieć. Jeśli nie zawsze masz dobrą sieć, to nie zawsze działa
Daniel S. Sterling,
Co to jest dobra sieć? Jeśli wszystko działa w jednym regionie AWS, to czy sieć jest wystarczająco dobra?
rich remer

Odpowiedzi:

7

Myślę, że tak naprawdę jest to bardziej dyskutowane niż się wydaje. Istnieje co prawda stary, związany z Linuksem FAQ: http://www.tldp.org/HOWTO/VPN-HOWTO/

Używam PPP-over-ssh-over-ADSL od ponad 12 lat i nigdy mnie to nie zawiodło, więc z własnego doświadczenia ośmieliłbym się powiedzieć, że skazańcy prawdopodobnie w dużej mierze przesadzają. TCP przez TCP jest prawdopodobnie złym pomysłem z połączeniami RTC, łączami satelitarnymi i innymi łączami o bardzo niskiej przepustowości lub bardzo długich opóźnieniach, ale do większości zastosowań prostu działa .

Teraz prawdziwe pytanie brzmi: dlaczego miałbyś używać TCP przez TCP w ogóle ? Kiedy skonfigurowałem PPP-over-ssh, było to w dużej mierze spowodowane tym, że wtedy był to zdecydowanie najłatwiejszy sposób na zbudowanie szybkiej sieci VPN; potem używam go od tego czasu z czystego lenistwa.

W dzisiejszych czasach istnieją praktyczne, łatwe w konfiguracji narzędzia, takie jak OpenVPN, IPSec VPN, dzięki czemu nie powinieneś martwić się tym problemem TCP-over-TCP.

wazoox
źródło
1
Są sytuacje, w których TCP-over-TCP jest prostym rozwiązaniem wielu problemów z siecią. Dodałem sekcję wyjaśniającą nasze uzasadnienie.
Nils Toedtmann
Mam nadzieję, że odpowiedź będzie bardziej szczegółowa na temat warunków, w których TCP-over-TCP staje się problemem. Jednym z naszych przypadków użycia łącza radiowe o różnym stopniu opóźnienia i utraty pakietów.
Nils Toedtmann
TCP przez TCP przez TCP (ruch TCP w TCP OpenVPN dostępny poprzez przekazywanie TCP SSH) kosztuje mnie około 5 Mb / s. Nigdy mnie to nie zawiodło, ale nie poleciłbym tego tylko dlatego, że to ogromne marnotrawstwo.
Syreny