За яких обставин TCP-над-TCP працює значно гірше, ніж лише TCP (2014)?


25

Багато адміністраторів продовжують продовжувати - як на ServerFault, так і в інших місцях - наскільки погана ідея TCP-over-TCP, наприклад, у VPN. Якщо навіть найменша втрата пакета змусить страждати від принаймні сильної деградації пропускної здатності, якщо не зриву TCP, і тому TCP-над-TCP суворо уникати. І це, мабуть, колись все було правдою, наприклад 2001 р., Коли ця стаття була написана, про яку й досі йдеться.

Але відтоді ми спостерігаємо значні досягнення в галузі технологій та протоколів. На сьогоднішній день у нас «Селективний ACK» впроваджений майже скрізь, і закон Мура дав нам набагато більше пам’яті, і разом з ним з'явилися великі буфери TCP, оптимізовані для Gbit-посилань. Також втрата пакетів набагато менша проблема в ці дні на нерадіоканалах. Все це повинно суттєво полегшити проблему TCP-over-TCP, чи не так?

Зауважте, що існують сценарії в реальному світі, де, наприклад, VPN на основі TCP легше реалізувати та працювати, ніж такі, які базуються на UDP / ESP (див. Докладніше нижче). Тому моє запитання:

За яких обставин (втрата та затримка пакетів зв’язків) TCP-над-TCP працює значно гірше, ніж сам TCP, припускаючи підтримку SACK та пристойні розміри буферів TCP з обох кінців?

Було б чудово, тому подивіться деякі вимірювання, які показують кореляцію між (зовнішнім з'єднанням) втратою / затримкою пакету та (внутрішнім з'єднанням) пропускною здатністю / тремтінням - для TCP-над-TCP і лише для TCP. Я знайшов цю цікаву статтю , але, здається, вона стурбована лише затримкою, а не адресовані (зовнішні) втрати пакетів.

Також: Чи є рекомендовані параметри (наприклад, параметри TCP, настройки буфера, зменшення MTU / MSS тощо), щоб зменшити розрив у продуктивності між TCP та TCP-над-TCP?


Оновлення: Наше обгрунтування.

Це питання все ще є дуже актуальним у деяких реальних сценаріях. Наприклад, ми розміщуємо вбудовані пристрої у великих будівлях, які збирають дані сенсорів і передають їх на нашу платформу через VPN. Проблема, з якою ми стикаємося, - це брандмауери та неправильно налаштовані посилання, які не знаходяться під нашим контролем, у поєднанні з неохоче ІТ-відділами. Дивіться детальний приклад, обговорений тут .

У багатьох таких випадках перехід від не-TCP до VPN на основі TCP (дуже просто, якщо ви використовуєте OpenVPN, як ми) - це швидке виправлення, яке дозволяє нам ухилятися від боїв, що вказують пальцями вгору. Наприклад, часто TCP-порт 443 дозволений (принаймні, через проксі), або ми можемо подолати проблеми Path-MTU, просто зменшивши MSS-параметр TCP.

Було б добре знати, за яких обставин VPN на основі TCP можна вважати життєздатною альтернативою, тому ми можемо приймати обгрунтоване рішення, що переважає плюси та мінуси будь-якого варіанту. Наприклад, ми знаємо, що TCP-VPN добре для нас на нерадіопосиланнях, але у нас є велика частка віддалених клієнтів у 3G посиланнях зі значними втратами пакетів та високою затримкою - як би тут працював TCP-VPN?

Я намагався відповідно вдосконалити назву та центральне питання; Сподіваюся, це має сенс.


Ви швидко помітите різницю між TCP над TCP проти UDP (тощо) через TCP VPN, використовуючи їх для інтерактивних сесій, наприклад, ssh. Ви помітите затримку, якщо не буде крапель сеансу. YMMV, TIAS
Даніель С. Стерлінг

Тільки якщо "зовнішнє" з'єднання в першу чергу залежить від певної затримки або втрати пакетів. У мене безліч сеансів SSH через VPN на основі TCP, і багато хто працює добре, без помітного відставання.
Нілс Тодтман

Дійсно - це працює, коли у вас хороша мережа. Якщо ви не завжди маєте хорошу мережу, це не завжди працює
Daniel S. Sterling

Що таке хороша мережа? Якщо все працює в одному регіоні AWS, чи достатньо хороша мережа?
багатий ремер

Відповіді:


7

Я думаю, що це насправді більш дискусійно, ніж ти здаєшся. Існує, правда, старе, пов'язане з Linux питання: http://www.tldp.org/HOWTO/VPN-HOWTO/

Я використовував PPP-over-ssh-over-ADSL більше 12 років, і це ніколи не підводило мене, тому зі свого досвіду я б наважився сказати, що доляри, ймовірно, значною мірою перебільшують. TCP через TCP - це, мабуть, погана ідея з підключеннями RTC, супутниковими та іншими посиланнями або з дуже низькою пропускною здатністю, або з дуже тривалими затримками, але для більшості застосувань це просто працює .

Тепер істинний питання: навіщо використовувати TCP через TCP взагалі ? Коли я налаштував PPP-over-ssh, це було багато в чому тому, що тоді це був найпростіший спосіб побудувати швидкий VPN; тоді я користувався ним з тих пір, як з лінощів.

На сьогоднішній день є такі практичні, прості в налаштуванні такі інструменти, як OpenVPN, IPSec VPN, щоб вам ніколи не потрібно було турбувати вас із цією проблемою TCP-over-TCP.


1
Бувають ситуації, коли TCP-over-TCP - це просте виправлення низки мережевих проблем. Я додав розділ, який розробив наше обгрунтування.
Нілс Тодтманн

Я сподіваюся на відповідь, більш конкретну щодо умов, за яких TCP-над-TCP стає проблемою. Один з наших випадків використання - радіопосилання, які мають різний ступінь затримки та втрати пакетів.
Нілс Тодтманн

TCP через TCP через TCP (TCP-трафік у TCP OpenVPN, доступ до якого здійснюється через SSH вперед TCP), коштував мені приблизно 5 Мбіт / с. Це ніколи мене не підводило, але я б не рекомендував це тільки тому, що це величезна трата.
Сирени
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.