Многие администраторы продолжают утверждать - на ServerFault и в других местах - насколько плоха идея TCP-over-TCP, например в VPN. Что даже малейшая потеря пакета вызовет, по крайней мере, серьезное снижение пропускной способности, если не сбой TCP, и поэтому следует строго избегать TCP-over-TCP. И это, вероятно, когда-то было правдой, например 2001, когда Эта статья было написано, что до сих пор упоминается.
Но с тех пор мы стали свидетелями значительного прогресса в технологиях и протоколах. В настоящее время мы внедрили «Селективный ACK» почти повсеместно, и закон Мура дал нам гораздо больше памяти, а вместе с ним и большие буферы TCP, оптимизированные для восходящих каналов на Гбит. Кроме того, потеря пакетов в наши дни является гораздо меньшей проблемой для нерадио каналов. Все это должно значительно облегчить проблему 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 будет работать там?
Я постарался соответственно улучшить название и центральный вопрос; Надеюсь, это имеет смысл.
Я думаю, что на самом деле это обсуждается больше, чем вы думаете. По общему признанию, существует старый, связанный с ним FAQ по 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.