Как многие уже знают, не так давно VMware выпустила обновленную версию решения для виртуализации и доставки рабочих окружений пользователей VMware Horizon 7.5. Среди новых возможностей клиентов Horizon View была такая фича: "VMware Blast выбирает оптимальный транспорт автоматически (UDP или TCP) для предоставления лучшего качества обслуживания пользователю (ранее нужно было делать это вручную)".
Оказывается, это очень важная штука, и называется она Blast Extreme Network Intelligent Transport (BENIT). Ранее компания VMware анонсировала механизм Blast Extreme Adaptive Transport (BEAT), который позволял переходить на UDP-протокол в сетях с плохим качеством связи, предоставляя пользователю выбор типа соединения:
Blast Extreme автоматически подстраивается под параметры Bandwidth, Latency и Packet Loss в различных сетях и выбирает наиболее эффективный транспорт: TCP или UDP. Работало это так:
Excellent - предназначен для LAN-сетей с хорошим качеством (высокая скорость и низкие потери пакетов). В этом случае используется только TCP протокол - и для управления передачей, и для отправки самих данных.
В случае выбора Poor протокол Blast Extreme использует только UDP для управления передачей и отсылки данных. Это оптимально для WAN-сетей с большими задержками и коэффициентом потерь пакетов 20% и более.
Дефолтный пункт - Typical - это оптимальный выбор для 99% пользователей. В этом случае будет использоваться TCP для управления передачей, а UDP для основной отправки данных, с учетом адаптивного алгоритма. Если по каким-то причинам UDP будет недоступен (например, заблокирован политикой на сетевом экране), то произойдет незаметное для пользователя переключение на TCP.
Далее в версии VMware Horizon 7.3.1 появились отдельные каналы для для USB и CDR внутри протокола Blast. Это позволило инкапсулировать весь трафик в рамках одного протокола, что удобно с точки зрения управления каналом.
Между тем, некоторые недостатки такого механизма еще оставались, особенно при использовании UDP:
UDP часто заблокирован в корпоративной инфраструктуре или сильно зажат по ширине канала.
Маршрутизация на основе политик может вести TCP и UDP трафик через совершенно разные пути.
Некоторым приложениям (например, копированию файлов) гораздо важнее сырая пропускная способность, чем уровень отклика для пользователя, с чем отлично справляется TCP.
При использовании TCP в протоколе Blast нагрузка на CPU является несколько повышенной, если сравнивать с собственными механизмами оптимизации TCP в операционных системах.
Ну и главным недостатком BEAT было то, что условия соединения пользователя могли меняться в процессе работы - проявлялось влияние разных типов трафика, изменение параметров канала и прочее. Ну и сам пользователь не всегда был в курсе, какую политику BEAT нужно выбрать при работе с тем или иным приложением.
Еще одной проблемой является использование мобильных клиентов - протоколы TCP или Adaptive Transport предоставляют надежное соединение только когда постоянно доступно. Но мобильное устройство может переключиться с Wi-Fi на 3G/LTE, при этом, например, копирование файлов в гостевой ОС не должно прерываться.
Этот протокол предоставляет следующие характеристики:
Надежность - гарантия последовательной доставки данных в условиях прерывания сетевого соединения / переключения сетевых адаптеров.
Переключение транспорта для отдельного приложения на основе отклика приложения в сети.
Балансировка нагрузки за счет одновременного использования обоих транспортов для различных приложений, а также за счет выбора конкретного транспорта для определенного класса трафика (например, File Copy).
Так это выглядит наглядно:
Привязка нужного типа протокола происходит динамически на уровне сессии для каждого приложения или типа трафика через компонент мультиплексор.
Давайте посмотрим на некоторые аспекты такого решения:
Надежность
Тут возникает 2 основных проблемы:
Потеря соединения для транспортного протокола, когда данные были отосланы и, возможно, получены получателем, но источник не получил подтверждение этого. Для протокола BENIT это решается повторной отправкой данных только в случае переключения транспорта для приложения.
Эффект Race condition - когда приложение отправило пакет под одному каналу, а потом произошло переключение транспорта, и оно отправило другой пакет по другому каналу, а ответ для них может прийти в обратном порядке. Эта проблема решается механизмом обнаружения и коррекции ошибок.
Переключение транспорта
Для того, чтобы механизм BENIT работал эффективно, нужна возможность смотреть на производительность транспорта для определенных приложений, которая и реализована в протоколе. Решение по переключению может приниматься на основе заранее заданной политики (дефолтно это потери пакетов > 1%, задержка > 50 мс и пропускная способность < 200 Мб/с), либо с помощью интеллектуального алгоритма, который сам понимает необходимость переключения. Статические политики вы можете задать самостоятельно, на основе эмпирических результатов производительности для отдельных приложений или инфраструктуры в целом.
При работе с соединениями BENIT будет периодически тестировать их характеристики и производить необходимые переключения транспорта для приложений. Это снимает с администраторов и пользователей обязанность самостоятельно производить выбор типа соединения.
Кстати, надо понимать, что переключение транспорта происходит независимо на клиенте и на удаленном десктопе, то есть если на клиенте что-то меняется (например, параметры адаптера), то именно там происходит переключение транспорта, а на десктопе все остается как и было.
Аналитика при переключении транспорта
Здесь все работает таким образом: при использовании одного транспорта и несоблюдении параметров политики по его производительности происходит тестирование сгенерированным трафиком другого канала. Если его характеристики оказываются лучше, происходит переключение на другой транспорт. Но это рождает проблему загрузки сети трафиком тестирования.
Поэтому здесь есть механизм обучения - если, например, произошла серия "плохих" переключений с BEAT на TCP и обратно, то BENIT запомнит эту связь и будет поддерживать TCP-соединение, даже если все требования по переключению будут выполнены.
С точки зрения эффективности переключения на другой транспорт, тут тоже есть 2 механизма:
Lazy switching - если одна порция трафика пока еще целиком не послалась через транспорт, то следующая посылается уже через новый канал, при этом на старом еще некоторое время ожидается квитанция о приеме, и если ее не приходит - то сообщение перепосылается уже через новый канал. Это вызывает некоторую задержку времени переключения, но зато эффективно с точки зрения использования канала.
Rollback and switch - в этом случае недопосланное сообщение аннулируется, происходит мгновенное переключение и перепосылка этого сообщения по новому каналу. Это приводит к максимально быстрому переключению, но часть трафика в канале дублируется.
Некоторые результаты тестирования
Вот так выглядят результаты по FPS при просмотре видео на виртуальном десктопе при использовании протоколов TCP и BENIT в условиях различных сетевых соединений:
Network Profile
BENIT
TCP
Blast Extreme Adaptive Transport
10 Mbps, 20% Loss, 200 ms RTT
13.40 fps
00.65 fps
13.38 fps
10 Mbps, 10% Loss, 200 ms RTT
16.52 fps
02.25 fps
16.52 fps
100 Mbps, 0% Loss, 200 ms RTT
27.52 fps
27.53 fps
25.68 fps
200 Mbps, 0% Loss, 200 ms RTT
28.23 fps
28.25 fps
27.92 fps
А вот результаты по копированию файлов через механизм Drive Redirection:
Network Profile
BENIT
TCP
Blast Extreme Adaptive Transport
10 Mbps, 1% Loss, 50 ms RTT
8.32 Mbps
2.38 Mbps
8.32 Mbps
100 Mbps, 0% Loss, 0 ms RTT
98.8 Mbps
98.8 Mbps
91.28 Mbps
Ну и главное - BENIT позволяет сохранить поток копирования файлов при переключении между соединениями Wi-Fi и 3G/LTE на мобильном интернете или при потере сетевого соединения (по умолчанию настроено время ожидания 120 секунд, его можно изменять):
RSS
