Введение
Протокол удаленного рабочего стола (RDP) лежит в основе многих развертываний удаленного доступа, от небольших ИТ-поддерживающих установок до крупных корпоративных сред. Однако один ключевой фактор производительности часто остается незамеченным: проходит ли трафик RDP в основном по TCP или UDP. Этот выбор напрямую влияет на задержку, отзывчивость и пользовательский опыт, особенно через WAN и VPN. В этом руководстве мы объясняем, как RDP использует UDP и TCP, когда каждый транспорт работает лучше всего, и что вы можете настроить в Windows и вашей сети для обеспечения более плавных и надежных удаленных сеансов.
TSplus Бесплатная пробная версия удаленного доступа
Ультимативная альтернатива Citrix/RDS для доступа к рабочему столу/приложениям. Безопасно, экономично, на месте/в облаке
Почему выбор транспорта RDP важен для удаленной производительности?
RDP больше не является простым "скрин-скрейпером". Современный RDP передает сжатую графику, мультимедиа, события ввода, данные печати и содержимое буфера обмена. Каждый из этих потоков по-разному реагирует на задержки и потерю пакетов. Если используется неправильный транспорт, пользователи наблюдают задержки, дерганое видео или медленную реакцию клавиатуры, даже когда пропускная способность выглядит нормально.
Понимание того, когда RDP предпочитает UDP, а не TCP, помогает ИТ-командам проектировать шлюзы, VPN и правила брандмауэра которые поддерживают реальную производительность, а не просто «зеленые галочки» на панелях мониторинга. Это особенно важно для смешанных сред, где некоторые пользователи подключаются через оптоволокно, в то время как другие подключаются через загруженные VPN-концентраторы или мобильные точки доступа.
Каковы основы TCP и UDP для RDP?
- Что гарантирует TCP
- Что оптимизирует UDP
Что гарантирует TCP (и почему это стоит задержки)
Протокол управления передачей (TCP) ориентирован на соединение. TCP устанавливает сессию, номера пакетов, подтверждает их и повторно передает потерянные. Этот дизайн гарантирует доставку в порядке, надежную, что идеально подходит для передачи файлов, веб-трафика и электронной почты. Однако каждая повторная передача добавляет задержку, а алгоритмы управления перегрузкой дополнительно замедляют пропускную способность при потере пакетов.
Для RDP это означает, что один потерянный пакет может заблокировать последующие обновления экрана до завершения восстановления. На каналах с высокой задержкой или потерями TCP может преувеличивать дрожание и создавать "липкий" рабочий стол, где мышь и клавиатура ощущаются с задержкой, даже если связь технически работает.
Что оптимизирует UDP (и где он может сломаться)
Протокол пользовательских датаграмм (UDP) является безсоединительным и легковесным. UDP не отслеживает состояние, не выполняет рукопожатия и не гарантирует доставку; он просто отправляет датаграммы и позволяет приложению справляться с потерей или порядком. Отсутствие накладных расходов делает UDP привлекательным для голосовой связи, видео и игр, где своевременность важнее, чем идеальная доставка.
Когда RDP использует UDP, графика и ввод могут передаваться с меньшей задержкой и большей пропускной способностью. Если кадр потерян, RDP может отправить новый вместо ожидания. Однако, если потеря пакетов или дрожание высоки, сессия может показывать видимые артефакты или "блочные" обновления, потому что протокол отдает предпочтение свежести перед гарантированной реконструкцией.
Как современный RDP использует TCP и UDP вместе?
- Двойная транспортная архитектура с RDP 8.0 и далее
- RemoteFX, графика и ввод по UDP
Двойная транспортная архитектура с RDP 8.0 и далее
Изначально RDP полагался исключительно на TCP. Начиная с RDP 8.0 (Windows 8 и Windows Server 2012), Microsoft представила двойную транспортную модель, которая использует TCP и UDP вместе. RDP по-прежнему начинается с TCP-соединения для согласования возможностей и безопасности, а затем пытается установить параллельный UDP-канал для медиа и графики.
Если UDP доступен и политики это позволяют, RDP перенаправляет соответствующий трафик на канал UDP, сохраняя TCP в качестве контрольного и резервного пути. Если UDP не может быть установлен, RDP продолжает полностью работать через TCP, обеспечивая совместимость со старыми сетями и ограничительными брандмауэрами.
RemoteFX, графика и ввод по UDP
С помощью модели с двумя каналами RDP может отправлять сжатую графику, битмапы и некоторые события ввода по UDP. Это улучшает отзывчивость в типичных сценариях WAN, особенно когда рабочие столы отображают богатые пользовательские интерфейсы, потоковые панели управления или видео. RemoteFX и связанные с ним оптимизации были разработаны с учетом этого поведения.
На практике пользователи замечают более быстрые перемещения окон, более плавную прокрутку и более быстрое обновление экрана, когда UDP активен в стабильных сетях. С административной стороны это поведение в основном автоматическое; основная задача заключается в том, чтобы убедиться, что UDP разрешен и что групповая политика его не отключает.
Как сравнивается производительность UDP и TCP?
- Сравнительная таблица
- Практические сценарии: WAN, VPN и LAN
Сравнительная таблица
| Функция / сценарий | RDP по TCP | RDP по UDP |
|---|---|---|
| Надежность | Высокая, заказная доставка с ретрансляцией | Наилучшие усилия, без гарантий доставки или заказа |
| Задержка | Выше, особенно при убытках | Ниже, более устойчивый к дрожанию |
| Пропускная способность | Снижено за счет подтверждений и управления перегрузками | Более высокий, меньшая нагрузка протокола |
| Лучшие условия сети | Высокоутратные, непредсказуемые или сильно формируемые ссылки | Стабильные, с низкими потерями, с низкой задержкой сети |
| Совместимость с брандмауэром/VPN | Отлично; использует TCP 3389 | Может потребоваться явное правило UDP 3391 на брандмауэрах и VPN. |
| Резервное поведение | Всегда доступно | Используется при наличии; переходит на TCP в случае проблем |
| Восприятие пользователя | Безопасно, но иногда с задержками | "Быстро и плавно", когда условия подходят |
В лабораторных и полевых испытаниях RDP по UDP может обеспечить в несколько раз большую эффективную пропускную способность, чем TCP в чистых сетях, что приводит к более высокому разрешению, лучшему воспроизведению видео и более плавному движению курсора. Фактическое улучшение зависит от пропускной способности, потерь и того, насколько агрессивно сеть формирует трафик.
Практические сценарии: WAN, VPN и LAN
На проводной локальной сети с низкой задержкой и незначительными потерями пакетов UDP обычно является явным победителем. Пользователи получают почти локальную отзывчивость, даже при подключении с другого этажа или здания. По управляемой WAN или SD-WAN связи UDP также, как правило, показывает лучшие результаты, при условии что Качество обслуживания настроен, и потеря пакетов остается умеренной.
При перегруженных VPN, мобильных точках доступа или спутниковых каналах TCP может обеспечить более стабильный опыт. Его механизмы управления перегрузкой могут адаптироваться к изменяющимся условиям, в то время как трафик UDP может стать прерывистым или визуально ухудшенным. В этих сценариях приоритетом является предсказуемая, пусть и немного более медленная, сессия.
Когда предпочитать UDP или TCP для сеансов RDP?
- Идеальные условия для RDP по UDP
- Когда TCP является более безопасным значением по умолчанию
Идеальные условия для RDP по UDP
Для большинства современных развертываний UDP должен быть целевым путем, когда это возможно. UDP идеален, когда сеть имеет стабильную задержку, низкие потери и разумный запас пропускной способности. Высокоскоростные локальные сети, хорошо управляемые MPLS или SD-WAN каналы, а также связи между дата-центрами и филиалами обычно соответствуют этому профилю.
UDP также является лучшим выбором, когда конечные пользователи работают с медиа-насыщенными приложениями, панелями управления с частыми обновлениями или пользовательскими интерфейсами, которые перерисовывают большие участки экрана. Для этих рабочих нагрузок снижение задержки оказывает большее влияние на воспринимаемую производительность, чем максимизация сырой надежности.
Когда TCP является более безопасным значением по умолчанию
TCP остается ценным в враждебных или непредсказуемых сетях. Если пользователи подключаются через Wi-Fi в отелях, публичные точки доступа или пути с частыми микроперебоями, надежность и поведение TCP в условиях перегрузки могут быть более снисходительными. Аналогично, некоторые старые VPN-устройства, прокси или устройства инспекции неправильно обрабатывают UDP 3391, заставляя RDP использовать TCP независимо от конфигурации.
Если регуляторные или аудиторские требования требуют простых, легко объясняемых сетевых правил, администраторы также могут выбрать стандартизацию на TCP для определенных групп пользователей. В таких случаях цель заключается в ясности и соблюдении требований, в то время как UDP зарезервирован для доверенных сайтов и управляемых конечных точек.
Как настроить RDP для оптимального использования UDP?
- Проверьте версию RDP и возможности
- Открыть и проверить необходимые порты
- Настройки групповой политики для UDP и опыта
- QoS и оптимизация на уровне сети
- Монитор, какой транспорт использует RDP
Проверьте версию RDP и возможности
Поддержка UDP начинается с RDP 8.0. Убедитесь, что как клиент RDP, так и хост работают на поддерживаемых версиях, таких как Windows 8 / 10 / 11 или Windows Server 2012 и более поздние версии. Согласно Microsoft Learn, для включения новых функций RDP часто требуются определенные обновления Windows, а также роли служб удаленного рабочего стола.
На клиенте Windows вы можете проверить основную версию RDP в реестре:
reg query "HKLM\SOFTWARE\Microsoft\Terminal Server Client" /v RDPCoreVersion
В старых доменах подтвердите, что групповые политики не заставляют RDP работать в режимах совместимости, которые отключают UDP.
Открыть и проверить необходимые порты
RDP использует TCP порт 3389 для базового соединения и UDP-порта 3391 для оптимизированного медиапути в стандартных конфигурациях. Межсетевые экраны, маршрутизаторы и VPN-шлюзы должны разрешать эти порты в обоих направлениях, если это применимо.
Документ, который показывает, какие устройства выполняют NAT или инспекцию, и проверяет, что UDP 3391 не теряется без уведомления или не ограничивается по скорости. Используйте простые инструменты, такие как
Тест-СетевогоСоединения
или захваты пакетов, чтобы подтвердить, что UDP-пакеты достигают сервера и что ответы видны на стороне клиента.
Настройки групповой политики для UDP и опыта
На хосте RDP или хосте сеанса откройте управление групповыми политиками и перейдите к:
Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленного рабочего стола > Хост сеансов удаленного рабочего стола > Среда удаленного сеанса
Ключевые настройки включают:
- Оптимизируйте для опыта, а не для RD Gateway или аналогичных оптимизаций опыта.
- Используйте транспорт UDP → установите на Включено.
Избегайте конфликтующих политик, которые отключают UDP одновременно с включением оптимизаций опыта. После изменений выполните
gpupdate /force
и повторно подключить тестовые сеансы, чтобы подтвердить, что теперь используется UDP.
QoS и оптимизация на уровне сети
В крупных средах политики качества обслуживания (QoS) могут значительно улучшить отзывчивость RDP. Пометьте трафик RDP, особенно UDP-потоки, соответствующим значением DSCP и убедитесь, что маршрутизаторы WAN учитывают эти пометки. Рассмотрите возможность размещения трафика RDP в классе приоритета или гарантированной пересылки, а не позволяйте ему конкурировать с массовыми передачами.
В то же время поддерживайте постоянный MTU на VPN и WAN-соединениях, чтобы избежать фрагментации, которая может негативно сказаться на производительности UDP. Сетевые команды также должны отслеживать потерю пакетов и джиттер на путях, используемых трафиком удаленного рабочего стола, чтобы выявить проблемные каналы.
Монитор, какой транспорт использует RDP
Windows записывает выборы транспорта RDP в Просмотре событий под журналом RemoteDesktopServices-RdpCoreTS. Общие события включают:
- Событие ID 131: сеанс RDP установлен только с использованием TCP
- Событие ID 132: используется транспорт UDP
- Событие ID 140: попытка UDP, но переключение на TCP
Просмотрите эти события, когда пользователи сообщают о "медленных" рабочих столах. Скомбинируйте их с сетевыми метриками и захватами пакетов, чтобы решить, заключается ли исправление в включении UDP, настройке QoS или упрощении сетевых путей.
Почему RDP возвращается к TCP для устранения неполадок?
- Проблемы с подключением и брандмауэром
- Политика, несоответствия клиента и сервера
Проблемы с подключением и брандмауэром
Если RDP постоянно использует TCP даже на современных клиентах и серверах, начните с базовых проверок подключения. Подтвердите, что UDP 3391 разрешен от конца до конца, а не только на хосте Windows. Брандмауэры, которые разрешают TCP 3389, но молча блокируют UDP 3391, заставят RDP работать только в режиме TCP.
Для удаленных сайтов убедитесь, что политики VPN или устройства SD-WAN не переписывают или блокируют UDP. Некоторые системы безопасности требуют явных правил или "определений приложений" для UDP-канала RDP. Захваты пакетов с обеих сторон туннеля могут быстро показать, проходят ли UDP-пакеты полный круг.
Политика, несоответствия клиента и сервера
Групповая политика может явно отключить транспорт UDP, даже если сеть это позволяет. Проверьте как компьютерные, так и пользовательские политики на наличие настроек RDP и убедитесь, что более старые шаблоны не переопределяют новые значения по умолчанию. Аналогично, устаревшие клиенты RDP могут не поддерживать полный UDP или могут быть ограничены местной политикой.
Также проверьте, что конфигурация служб удаленных рабочих столов сервера соответствует базовым стандартам безопасности домена. Шаблоны жесткой настройки из предыдущих проектов иногда отключают новые функции протокола. В случае сомнений сравните настройки с актуальными базовыми стандартами и документацией Microsoft для вашей версии Windows Server.
Улучшите свой опыт RDP с TSplus Remote Access
Устранение проблем с производительностью RDP или планирование более масштабируемой архитектуры удаленного доступа? TSplus Удаленный доступ позволяет вам публиковать рабочие столы и приложения через веб с помощью легковесного шлюза, безопасности TLS и оптимизированной обработки RDP.
Нужна безопасная, доступная публикация приложений без сложности уровня Citrix? Начните свою бесплатную пробную версию TSplus и посмотрите, как быстро вы можете развернуть быстрые удаленные сеансы, оптимизированные для UDP.
Заключение
Нет единственного "победителя" между RDP по UDP и TCP. UDP обеспечивает наилучший пользовательский опыт в чистых, хорошо управляемых сетях, обеспечивая сессии с низкой задержкой и высокой пропускной способностью. TCP остается основой для совместимости и устойчивости, когда условия менее предсказуемы.
Настоящая цель состоит в том, чтобы позволить современному RDP использовать UDP, где это возможно, сохраняя автоматическое переключение на TCP, когда это необходимо. Проверяя версии, открывая правильные порты, настраивая групповую политику и контролируя использование транспорта, вы можете обеспечить быстрые и надежные удаленные рабочие столы. TSplus Удаленный доступ помогает превратить эту настройку в последовательную, безопасную платформу для ваших пользователей.
TSplus Бесплатная пробная версия удаленного доступа
Ультимативная альтернатива Citrix/RDS для доступа к рабочему столу/приложениям. Безопасно, экономично, на месте/в облаке