Вопрос или проблема
Эта статья объясняет, почему TCP поверх TCP может стать катастрофой с точки зрения производительности.
Я понимаю проблему так, что ‘внешнее’ TCP-соединение справляется с потерей пакетов и перегрузкой сети и действует соответствующим образом, увеличивая таймауты (и, таким образом, уменьшая пропускную способность). Однако ‘внутреннее’ TCP-соединение не видит этих условий сети, потому что они ‘исправлены’ внешним TCP. Поэтому ‘внутреннее’ TCP продолжает отправлять пакеты с прежней скоростью и тем самым переполняет внутренний буфер отправки ‘внешнего’ TCP-соединения.
Мои вопросы:
- Правильно ли я понимаю?
- Кажется, что катастрофа TCP поверх TCP является только внутренней (т.е. она затрагивает только локальные буферы), но влияет ли она также на сеть? Вызывает ли это большее количество перегрузок в сети и ухудшает ли это другие соединения в той же сети?
- Как VPN на основе TCP решают эту проблему? OpenVPN имеет статью на эту тему, но она не объясняет, почему это не является проблемой на практике (или все-таки является?)
Большое спасибо за любой ответ!
На мой взгляд, проблема “tcp meltdown” несложна для решения: нужно просто установить большой таймаут повторной передачи для внутреннего TCP-соединения.
Сильно увеличив минимальный таймаут повторной передачи внутреннего TCP-соединения, мы на самом деле отключили механизм повторной передачи по таймауту внутреннего TCP. Таким образом, проблема TCP meltdown избегается.
Например, в Linux вы можете использовать ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12s, чтобы увеличить минимальный таймаут повторной передачи всех внутренних соединений, установленных через OpenVPN, с 0.2 секунд до 12 секунд (предполагается, что 192.168.168.1/24 — это ваш сегмент сети OpenVPN).
Вы можете установить вышеуказанную команду в качестве обратного вызова события “up” OpenVPN. Таким образом, мы на самом деле избежали проблемы tcp meltdown простым способом.
Мы используем этот метод для оптимизации соединения tcp-over-tcp. Даже на линии с высокой задержкой (сотни миллисекунд) и высокой потерей пакетов мы не обнаружили никаких негативных эффектов.
PS: На линии с высокой задержкой, высокой потерей пакетов и высокой пропускной способностью очевидно, что необходимо подготовить большое окно для внутренних TCP-соединений, чтобы занять всю пропускную способность.
ОБНОВЛЕНИЕ:
Вопрос в том, почему TCP поверх TCP не оказывает заметного воздействия на VPN на основе TCP?
Потому что на высококачественной линии, которая редко теряет пакеты, явление TCP meltdown не выражено.
Я бы сказал, что это больше связано с тем, как TCP работает, а не с OpenVPN как таковым. Вот длинная тирада и мои несколько cents:
Правильно ли я понимаю?
В общем, да, но внутреннее TCP-соединение не “защищено”. Если внешнее соединение потеряет пакет и пропускная способность уменьшится или задержка увеличится, внутреннее соединение также будет ограничено этим, заметив, что оно не может использовать всю производительность и начнет снижать скорость.
Кажется, что катастрофа TCP поверх TCP является только внутренней (т.е. она затрагивает только локальные буферы), но влияет ли она также на сеть?
У вас будет только одно TCP-соединение с сервером, так что это затронет только это конкретное соединение и то, что в нем. То, на что ссылается катастрофа, это то, что я описал в предыдущем ответе.
Вызывает ли это большее количество перегрузок в сети и ухудшает ли это другие соединения в той же сети?
Нет, но я должен уточнить, что такое “сеть”. Если у вас плохое соединение с Интернетом, то да, все будут страдать от потерь пакетов или других проблем с передачей. Если вы имеете в виду, что проблема только с вашим клиентом<->серверным соединением, тогда ваши некорректные VPN соединения не пострадают.
Как VPN на основе TCP решают эту проблему?
Используя одно соединение с сервером, отправляя трафик внутри этого соединения и надеясь на лучшее.
OpenVPN имеет статью на эту тему, но она не объясняет, почему это не является проблемой на практике, является ли это проблемой на практике.
Да. TCP имеет гораздо большие накладные расходы в терминах размера пакета, чем UDP, так что вы всегда платите штраф за размер, имея два заголовка TCP (внутренний и внешний) в вашем соединении. Повторные отправки и наращивание TCP также повлияют на вашу производительность. Если у вас хорошее соединение, т.е. без потерь, низкая задержка и высокая пропускная способность, то вы не заметите многого из наращивания/снижения скорости/повторных отправок, и, следовательно, не заметите этого. Если у вас плохое соединение, то здесь вступает в силу первый ответ, внешние соединения могут снизить скорость, это повлияет на внутренний трафик, который также снизит скорость, пакеты могут выйти из порядка и повторно отправляться и так далее, что определенно повлияет на производительность канала.
Долгий ответ длинный. Я надеюсь, что это имело смысл для кого-то больше, чем для меня.
Ответ или решение
Что такое TCP-over-TCP и как OpenVPN в режиме TCP решает эту проблему?
Введение
TCP (Transmission Control Protocol) — это протокол, обеспечивающий надежную передачу данных по сети. Однако, когда TCP используется внутри другого TCP-соединения, это приводит к проблеме, известной как TCP-over-TCP или «TCP-распад». В таких случаях каждая из TCP-сессий пытается контролировать потерю пакетов и управлять задержками, что может негативно сказаться на производительности. В этой статье мы рассмотрим суть проблемы TCP-over-TCP и обсудим, как OpenVPN в режиме TCP избегает связанных с ней трудностей.
Проблема TCP-over-TCP
Ваше понимание проблемы TCP-over-TCP абсолютно корректно. В этой ситуации «внешний» TCP-соединение управляет временем ожидания и контролирует потерю пакетов на сети, что может снижать пропускную способность. Однако «внутренний» TCP-соединение не осознает этих условий, так как они предполагаются исправленными внешним TCP. Это приводит к тому, что внутренний TCP продолжает отправлять пакеты с прежней скоростью, заполняя буферы внешнего TCP, что в свою очередь может привести к перегрузке и дополнительным задержкам.
Влияние на сеть
Хотя проблема TCP-over-TCP в основном касается внутренних буферов, она может повлиять и на сеть в случаях, когда активные соединения испытывают значительные задержки и потери пакетов. Это может привести к ухудшению качества других соединений на той же сети, особенно если пропускная способность канала ограничена. Однако в большинстве случаев проблема оказывается локальной и касается только конкретной пары клиент-сервер.
Решения для TCP-виртуальных частных сетей
TCP-направленные VPN, такие как OpenVPN, используют различные методы для минимизации воздействия проблемы TCP-over-TCP. Важнейший аспект заключается в том, что эти VPN-сервисы работают через единственное TCP-соединение: трафик перемещается внутри него, что ограничивает количество дублирующих заголовков и обеспечивает более устойчивое поведение сети.
Одно из предложенных решений заключается в увеличении минимального времени ожидания на внутреннем TCP-соединении. Например, с помощью команды в Linux можно установить длительное время ожидания, что значительно снижает вероятность запуска механизма повторной передачи для внутренних соединений. Это позволяет избежать «распада» TCP, даже в случае подключения с высокой задержкой или частыми потерями пакетов.
Практические аспекты
Как упоминалось ранее, в высококачественных соединениях с низкими значениями потерь и задержек проблема TCP-over-TCP становится менее заметной и, следовательно, не имеет значительного влияния на производительность соединения. Однако, на некачественных ссылках, где наблюдаются частые потери и существенные задержки, это может привести к ухудшению производительности и общей задержке в сети.
Заключение
TCP-over-TCP представляет собой серьезную проблему для передачи данных по сетям, особенно при использовании VPN. Однако OpenVPN и другие TCP-базированные VPN используют механизмы, которые минимизируют влияние этой проблемы, обеспечивая надежную и высокопроизводительную передачу данных. В то время как в идеальных условиях проблемы не заметны, на менее стабильных соединениях важно применять необходимые меры для поддержания высокой производительности. С помощью правильной настройки и понимания работы TCP можно достичь оптимальной работы VPN-соединений даже в сложных условиях сети.