In quali circostanze TCP-over-TCP ha prestazioni significativamente peggiori rispetto al solo TCP (2014)?


25

Molti amministratori continuano a perpetuare - su ServerFault e altrove - quanto sia cattiva l'idea del TCP-over-TCP, ad esempio nelle VPN. Che anche la minima perdita di pacchetti farà soffrire almeno un grave degrado del throughput, se non del crollo del TCP, e che TCP-over-TCP deve quindi essere rigorosamente evitato. E questo probabilmente una volta era tutto vero, ad esempio nel 2001 quando è stato scritto questo articolo a cui si fa ancora riferimento.

Ma da allora abbiamo visto importanti progressi nella tecnologia e nei protocolli. Oggi abbiamo 'ACK selettivo' implementato quasi ovunque, e la legge di Moore ci ha fornito molta più memoria, e con essa sono arrivati ​​grandi buffer TCP ottimizzati per uplink Gbit. Anche la perdita di pacchetti è molto meno un problema in questi giorni su collegamenti non radio. Tutto ciò dovrebbe alleviare in modo significativo il problema TCP-over-TCP, no?

Si noti che esistono scenari del mondo reale in cui, ad esempio, le VPN basate su TCP sono più facili da implementare e da utilizzare rispetto a quelle basate su UDP / ESP (vedere più sotto). Pertanto la mia domanda:

In quali circostanze (perdita e latenza dei pacchetti di collegamento) TCP-over-TCP ha prestazioni significativamente peggiori rispetto al solo TCP, presupponendo il supporto SACK e buffer TCP di dimensioni decenti su entrambe le estremità?

Sarebbe bello quindi vedere alcune misurazioni che mostrano le correlazioni tra perdita / latenza di pacchetti (connessione esterna) e throughput / jitter (connessione interna) - per TCP-over-TCP e solo per TCP. Ho trovato questo articolo interessante , ma sembra preoccupato solo della latenza e di non affrontare la perdita (esterna) di pacchetti.

Inoltre: esistono impostazioni consigliate (ad es. Opzioni TCP, impostazioni buffer, riduzione di MTU / MSS, ecc.) Per ridurre il divario di prestazioni tra TCP e TCP-over-TCP?


Aggiornamento: la nostra logica.

Questa domanda è ancora molto rilevante in alcuni scenari del mondo reale. Ad esempio, implementiamo dispositivi integrati in grandi edifici che raccolgono i dati dei sensori e li inseriscono nella nostra piattaforma tramite VPN. Il problema che stiamo affrontando sono i firewall e gli uplink configurati in modo errato che non siamo sotto il nostro controllo, combinati con dipartimenti IT riluttanti. Vedi un esempio dettagliato discusso qui .

In molti di questi casi, il passaggio da una rete non TCP a una VPN basata su TCP (molto semplice se si utilizza OpenVPN come noi) è una soluzione rapida che ci consente di sfuggire a battaglie in punta di dita in salita. Ad esempio, spesso la porta TCP 443 è generalmente consentita (almeno tramite proxy), oppure possiamo superare i problemi Path-MTU riducendo semplicemente l'opzione MSS di TCP.

Sarebbe bene sapere in quali circostanze una VPN basata su TCP può essere considerata un'alternativa praticabile, quindi possiamo prendere una decisione informata che superi i pro ei contro di entrambe le opzioni. Ad esempio, sappiamo che TCP-VPN è ok per noi su collegamenti non radio, ma abbiamo una buona dose di client remoti su uplink 3G con significativa perdita di pacchetti e latenza elevata: come si comporterebbe un TCP-VPN lì?

Ho cercato di migliorare il titolo e la domanda centrale di conseguenza; spero abbia senso.


Noterai rapidamente la differenza tra TCP su TCP vs UDP (ecc.) Su TCP VPN quando li usi per sessioni interattive, ad esempio ssh. Noterai latenza se non diminuisce la sessione. YMMV, TIAS
Daniel S. Sterling,

Solo se la connessione "esterna" è soggetta a un certo grado di latenza o perdita di pacchetti in primo luogo. Ho un sacco di sessioni SSH su VPN basate su TCP e molte funzionano bene senza ritardi evidenti.
Nils Toedtmann,

In effetti, funziona quando si dispone di una buona rete. Se non hai sempre una buona rete, non sempre funziona
Daniel S. Sterling

Che cos'è una buona rete? Se tutto funziona in una singola regione AWS, la rete è abbastanza buona?
ricco richiamo

Risposte:


7

Penso che in realtà sia più dibattuto di quanto sembri. Esiste una FAQ Linux correlata, dichiaratamente precedente: http://www.tldp.org/HOWTO/VPN-HOWTO/

Ho usato un PPP-over-ssh-over-ADSL per più di 12 anni, e non mi ha mai deluso, quindi per esperienza, oserei dire che i profeti del giudizio probabilmente esagerano ampiamente. TCP su TCP è probabilmente una cattiva idea con connessioni RTC, collegamenti satellitari e altri collegamenti con throughput molto basso o ritardi molto lunghi, ma per la maggior parte degli usi funziona .

Ora la vera domanda è: perché si usa il protocollo TCP su TCP a tutti ? Quando ho impostato il mio PPP-over-ssh, è stato in gran parte perché allora era di gran lunga il modo più semplice per costruire una VPN veloce; poi l'ho usato da allora per pura pigrizia.

Al giorno d'oggi ci sono strumenti pratici e facili da configurare come OpenVPN, VPN IPSec in modo che non dovresti mai doverti disturbare con questo problema TCP-over-TCP.


1
Ci sono situazioni in cui TCP-over-TCP è una soluzione semplice a una serie di problemi di rete. Ho aggiunto una sezione che elabora la nostra logica.
Nils Toedtmann,

Spero in una risposta più specifica sulle condizioni in cui TCP-over-TCP diventa un problema. Uno dei nostri casi d'uso sono i collegamenti radio con vari gradi di latenza e perdita di pacchetti.
Nils Toedtmann,

TCP su TCP su TCP (il traffico TCP in un OpenVPN TCP a cui si accede tramite un forward TCP SSH) mi è costato circa 5 Mb / s. Non mi ha mai deluso, ma non lo consiglierei solo perché è uno spreco enorme.
Sirene,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.