При каких обстоятельствах TCP-over-TCP работает значительно хуже, чем один TCP (2014)?

Многие администраторы продолжают увековечивать - на ServerFault и в других местах - насколько плоха идея TCP-over-TCP, например, в VPN. То, что даже малейшая потеря пакета приведет к как минимум серьезному ухудшению пропускной способности, если не к падению TCP, и что поэтому строго избегать TCP-over-TCP. И это, вероятно, когда-то было правдой, например, в 2001 году, когда была написана эта статья, на которую все еще ссылаются.

Но с тех пор мы наблюдаем значительные успехи в технологиях и протоколах. В настоящее время мы применяем «избирательный ACK» практически везде, и закон Мура дал нам намного больше памяти, а вместе с ним появились большие буферы TCP, оптимизированные для восходящих каналов Gbit. Кроме того, потеря пакетов является гораздо меньшей проблемой в наши дни на не радиоканалах. Все это должно значительно облегчить проблему TCP-over-TCP, не так ли?

Обратите внимание, что существуют реальные сценарии, в которых, например, VPN на основе TCP легче внедрить и использовать, чем на основе UDP / ESP (подробнее см. Ниже). Поэтому мой вопрос:

При каких обстоятельствах (потеря пакетов и задержка пакетов) TCP-over-TCP работает значительно хуже, чем один TCP, предполагая поддержку SACK и приемлемые размеры буферов TCP на обоих концах?

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

Также: Существуют ли рекомендуемые настройки (например, параметры TCP, настройки буфера, уменьшение MTU / MSS и т. Д.), Чтобы уменьшить разрыв в производительности между TCP и TCP-over-TCP?

Обновление: наше обоснование.

Этот вопрос все еще очень актуален в некоторых реальных сценариях. Например, мы внедряем встроенные устройства в больших зданиях, которые собирают данные датчиков и подают их на нашу платформу через VPN. Проблема, с которой мы сталкиваемся - это брандмауэры и неправильно настроенные каналы связи, которые мы не контролируем, в сочетании с неохотными ИТ-отделами. Смотрите подробный пример, обсуждаемый здесь .

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

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

Я попытался улучшить заголовок и центральный вопрос соответственно; Я надеюсь, что это имеет смысл.

Я думаю , что это на самом деле больше обсуждается , чем сделать это появится. Существует, по общему признанию, старый, связанный с Linux FAQ: 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.