Что такое TCP-over-TCP и как OpenVPN в режиме TCP позволяет избежать этой проблемы?

Question

Этотстатьяобъясняет, почему TCP-over-TCP может привести к катастрофе с производительностью.

Насколько я понимаю, проблема в том, что «внешнее» TCP-соединение решает проблему потери пакетов и перегрузки сети и действует соответственно, увеличивая тайм-ауты (и, таким образом, снижая пропускную способность). Однако «внутреннее» TCP-соединение не видит этих сетевых условий, поскольку они «фиксируются» внешним TCP. И поэтому «внутренний» TCP продолжает отправлять пакеты на прежней скорости и, таким образом, взрывает внутренний буфер отправки «внешнего» TCP-соединения.

У меня есть вопросы:

1. Правильно ли я понимаю?
2. Похоже, что сбой TCP-over-TCP только внутренний (т.е. он влияет только на локальные буферы), но влияет ли он также и на сеть? Вызывает ли он больше перегрузок в сети и ухудшает ли он другие соединения в той же сети?
3. Как VPN на основе TCP решает эту проблему? OpenVPN имеетстатьяоб этом, но не говорится, почему это не является проблемой на практике (или является?)

Большое спасибо за любой ответ!

Answer 1

В моем понимании, проблему «сбоя TCP» решить несложно: нужно лишь установить большой тайм-аут повторной передачи для внутреннего TCP-соединения.

Значительно увеличив минимальный тайм-аут повторной передачи внутреннего TCP-соединения, мы фактически отключили механизм повторной передачи по тайм-ауту внутреннего TCP. Таким образом, проблема с падением TCP устранена.

Например, в 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).

Вы можете установить указанную выше команду как обратный вызов события OpenVPN up. Таким образом, мы фактически избежали проблемы сбоя TCP простым способом.

Мы используем этот метод для оптимизации соединения tcp-over-tcp. Даже на линии с высокой задержкой (сотни миллисекунд) и высокой потерей пакетов мы не обнаружили никаких негативных эффектов.

PS: На линии с высокой задержкой, высокой потерей пакетов и высокой пропускной способностью очевидно, что вам нужно подготовить большое окно для внутренних TCP-соединений, чтобы занять всю пропускную способность.

ОБНОВЛЯТЬ:

Возникает вопрос: почему TCP-over-TCP не оказывает заметного влияния на VPN на базе TCP?

Потому что на высококачественной линии, где пакеты теряются редко, явление сбоя TCP не проявляется.

Answer 2

Я бы сказал, что это больше связано с тем, какТКПработает, и не с OpenVPN как таковым. Вот длинная тирада и мои несколько копеек:

Правильно ли я понимаю?

Грубо говоря, да, но внутреннее TCP-соединение не "защищено". Если внешнее соединение отбрасывает пакет и пропускная способность снижается или задержка увеличивается, внутреннее соединение также будет ограничено этим, обратите внимание, что оно не может использовать полную производительность и начинает отставать.

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

У вас будет только одно TCP-подключение к серверу, поэтому это повлияет только на это конкретное подключение и на то, что в нем находится. То, о чем говорит meltdown, я описал в предыдущем ответе.

Вызывает ли это дополнительную перегрузку сети и ухудшает ли это качество других соединений в той же сети?

Нет, но мне нужно, чтобы здесь было определение "сети". Если у вас плохое подключение к Интернету, то да, все будут страдать от потери пакетов или других проблем с передачей. Если вы имеете в виду, что проблема только с вашим клиентским<=>серверным соединением, то ваши не-VPN-соединения не будут затронуты.

Как VPN на основе TCP решают эту проблему?

Используя одно соединение с сервером, отправляйте трафик внутри этого соединения и надейтесь на лучшее.

У OpenVPN есть статья на эту тему, но в ней не говорится, почему это не является проблемой на практике, и является ли это проблемой на практике.

Да. TCP имеет гораздо более высокие накладные расходы с точки зрения размера пакета, чем UDP, поэтому вы всегда платите штраф за размер, имея два заголовка TCP (внутренний и внешний) в вашем соединении. Повторные отправки и наращивание TCP также повлияют на вашу производительность. Если у вас хорошее соединение, т. е. без обрывов, с низкой задержкой и высокой пропускной способностью, то вы не увидите большого наращивания/отката/повторных отправок, и, следовательно, не заметите этого. Если у вас плохое соединение, то в игру вступает первый ответ: внешние соединения могут снижаться, это повлияет на внутренний трафик, который также будет снижаться, пакеты могут выйти из строя и быть повторно отправленными и так далее, что определенно повлияет на производительность туннеля.

Длинный ответ длинный. Надеюсь, это имело смысл для кого-то большего, чем для меня.