У нас есть сайт в США, на котором есть фиксированная VPN-связь с нашим центром обработки данных в Великобритании через арендную линию 100 Мб.
Наша среда центра обработки данных представляет собой набор сеансов RDS-серверов 2012 R2 с использованием Microsoft Connection Broker, шлюза RDC и веб-портала сбора сеансов, чтобы предоставить пользователю приложение RDP для последующего подключения к одному из серверов сбора сеансов («ферма»). )
Брокеры подключений, серверы шлюза и серверы фермы находятся в одном физическом месте / в одной локальной сети в центре обработки данных Великобритании.
Все клиенты используют последнюю версию RDP 8.1 RemoteFX, которая включена и используется
Задержка от этого места до центра обработки данных в Великобритании составляет 140 мс.
Когда пользователи используют портал сбора сеансов для подключения к ферме, они всегда получают 2 полосы и низкое качество соединения на панели RDP. Результат - неуклюжее вялое исполнение.
Если они обходят веб-портал и подключаются напрямую к одному из серверов «фермы» через MSTSC (помните, что постоянный VPN работает между США и Великобританией), качество их соединения будет от хорошего до отличного, и результат будет идеальным.
Что портал сбора сеансов / брокер подключений / серверы шлюза делают с RDP, что может вызвать такую резкую разницу по сравнению с прямым MSTSC?
Просто для пояснения: в этом месте в США нет проблем с сетью LAN, представьте себе одного самого современного клиента, того же местоположения в локальной сети, 100 МБ полосы пропускания, задержки 140 мс и т. Д., В основном ничего не меняется, кроме использования MSTSC для прямого доступа к один из серверов фермы или через портал / брокеров соединений / шлюзы с использованием RDP через HTTPS.
Убедитесь, что ваш шлюз RDP доступен через UDP от клиентов. Если есть откат к TCP и у вас высокая задержка и / или некоторые потери, вы можете получить снижение производительности и / или качества соединения.
Вот еще немного информации о транспорте и портах.