De nombreux administrateurs continuent de perpétuer - sur ServerFault et ailleurs - la gravité d'une idée TCP-sur-TCP, par exemple dans les VPN. Que même la moindre perte de paquets fera souffrir une dégradation au moins sévère du débit sinon la fusion TCP, et que TCP-over-TCP est donc strictement à éviter. Et c'était probablement une fois vrai, par exemple en 2001, lorsque cet article a été écrit, auquel il est encore fait référence.
Mais depuis lors, nous avons vu des avancées majeures dans la technologie et les protocoles. De nos jours, nous avons implémenté 'Selective ACK' presque partout, et la loi de Moore nous a donné beaucoup plus de mémoire, et avec elle sont venus de grands tampons TCP optimisés pour les liaisons montantes Gbit. De plus, la perte de paquets est beaucoup moins problématique de nos jours sur les liaisons non radio. Tout cela devrait atténuer considérablement le problème TCP sur TCP, n'est-ce pas?
Notez qu'il existe des scénarios réels où, par exemple, les VPN basés sur TCP sont plus faciles à implémenter et à utiliser que ceux basés sur UDP / ESP (voir plus ci-dessous). Par conséquent ma question:
Dans quelles circonstances (perte et latence des paquets de liaison), TCP-sur-TCP fonctionne-t-il de manière nettement pire que TCP seul, en supposant la prise en charge de SACK et des tampons TCP de taille décente aux deux extrémités?
Ce serait formidable, alors voyez quelques mesures qui montrent les corrélations entre la perte / latence des paquets (connexion externe) et le débit / gigue (connexion interne) - pour TCP sur TCP et pour TCP seul. J'ai trouvé cet article intéressant , mais il semble ne s'intéresser qu'à la latence et ne pas traiter la perte de paquets (externe).
Aussi: Existe-t-il des paramètres recommandés (par exemple, les options TCP, les paramètres de tampon, la réduction de MTU / MSS, etc.) pour réduire l'écart de performances entre TCP et TCP sur TCP?
Mise à jour: notre justification.
Cette question est toujours très pertinente dans certains scénarios du monde réel. Par exemple, nous déployons des appareils intégrés dans de grands bâtiments qui collectent les données des capteurs et les injectent dans notre plateforme via VPN. Le problème auquel nous sommes confrontés est les pare-feu et les liaisons montantes mal configurés que nous ne contrôlons pas, combinés à des services informatiques réticents. Voir un exemple détaillé discuté ici .
Dans de nombreux cas, le passage d'un VPN non TCP à un VPN basé sur TCP (très facile si vous utilisez OpenVPN comme nous) est une solution rapide qui nous permet d'échapper aux batailles pointues en montée. Par exemple, souvent le port TCP 443 est généralement autorisé (au moins via un proxy), ou nous pouvons surmonter les problèmes Path-MTU en réduisant simplement l'option MSS de TCP.
Il serait bon de savoir dans quelles circonstances un VPN basé sur TCP peut être considéré comme une alternative viable, afin que nous puissions prendre une décision éclairée l'emportant sur les avantages et les inconvénients de l'une ou l'autre option. Par exemple, nous savons que TCP-VPN est correct pour nous sur les liaisons non radio, mais nous avons une bonne part de clients distants sur les liaisons montantes 3G avec une perte de paquets importante et une latence élevée - comment un TCP-VPN fonctionnerait-il là-bas?
J'ai essayé d'améliorer le titre et la question centrale en conséquence; J'espère que ça a du sens.