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.