RDP на двух мониторах: как разрешение и канал влияют на отзывчивость

Два монитора на рабочем месте бухгалтера — вещь полезная. На левом открыта выписка банка, на правом учётная программа, а между ними не нужно ежеминутно переключать окна. Но стоит перенести такую работу в удалённый сеанс, как появляется неприятный эффект: окно, которое вы тащите через границу двух экранов, движется с едва заметным запаздыванием, будто за курсором тянется резинка. Руки уже привыкли к мгновенной реакции, и любое отставание воспринимается как «всё тормозит».

Фраза «RDP тормозит» при этом объединяет как минимум три разные проблемы. Лечить их приходится по-разному, а перепутав, легко потратить неделю на покупку более толстого канала или более мощного сервера и не получить никакого эффекта. Разберём, из чего складывается ощущение скорости, и построим проверку, которую можно повторить на любом рабочем месте и передать коллеге без громких цифр.

Три разных «тормоза» под одним названием

Представьте цепочку: вы двигаете мышь, сигнал уходит по сети на сервер, сервер что-то делает, рисует изменения на экране, упаковывает их и отправляет обратно, клиент распаковывает картинку и показывает её. Задержаться может любое звено, и каждое проявляется по-своему.

• Задержка отклика. Это время между вашим действием и первой видимой реакцией. Оно зависит от пути пакетов до сервера и обратно, от качества соединения, от того, не теряются ли пакеты и не скачет ли время их доставки. Признак: курсор и ввод текста запаздывают даже тогда, когда на экране почти ничего не меняется. Печатаете в пустом блокноте, а буквы появляются с паузой.
• Объём изменений изображения. Это то, сколько пикселей нужно обновить и передать за единицу времени. Здесь важны разрешение, частота смены кадра и то, что именно на экране происходит. Признак: статичная таблица открывается нормально, а прокрутка большого отчёта, перетаскивание окна или воспроизведение ролика даёт рывки и «лесенку».
• Скорость вычислений приложения. Иногда экран тут вообще ни при чём: тяжёлый отчёт формируется долго, потому что программе не хватает процессора, памяти или диска на сервере, либо она сама неторопливо работает с базой. Признак: окно двигается плавно, но кнопка «Сформировать» отвечает через полминуты, причём точно так же, как отвечала бы на локальном компьютере.

Эти три причины могут накладываться. Но полезно сначала понять, какая из них доминирует, потому что у каждой своё лекарство: сетевая настройка, изменение графических параметров сеанса или разбор нагрузки на сервере.

Что говорит документация о графическом потоке

По описанию в материале Microsoft о полосе RDP, объём передаваемой графики определяется разрешением, частотой изменения экрана и типом содержимого. Видео и быстро меняющиеся изображения, как правило, требуют заметно больше полосы, чем неподвижный текст. Там же подчёркнуто: RDP использует сжатие и передаёт именно изменения экрана, поэтому оценивать нагрузку одной лишь скоростью интернет-тарифа неверно.

Из этого следует практический вывод, который часто упускают. Строка «100 Мбит/с» в договоре с провайдером говорит о максимальной ёмкости трубы, но не о том, как поведёт себя конкретный сеанс. Текстовый интерфейс бухгалтерской программы с редкими обновлениями почти ничего не просит. Зато полноэкранная прокрутка с анимацией, перетаскивание окон с эффектами или видеоконференция в соседнем окне создают поток, который меняется каждую долю секунды.

Разберём это на условном примере, не на измерении. Допустим, на левом мониторе открыта банковская выписка, на правом учётная программа, и в течение минуты пользователь меняет только несколько ячеек и строк. Для RDP это небольшие участки экрана: сеанс передаёт изменившиеся области, а не весь кадр целиком, как следует из материала Microsoft о полосе RDP. Теперь представим, что на правом экране тот же человек начал листать длинный отчёт с цветной подсветкой строк. Теперь меняется почти вся площадь окна, причём много раз в секунду. Число мониторов и тариф провайдера те же, а работы у сжатия и канала стало существенно больше.

Отсюда полезное правило для разбора жалоб: всегда спрашивайте не «сколько у вас мониторов», а «что в этот момент происходило на экране». Жалоба «тормозит на двух экранах» нередко оказывается жалобой «тормозит, когда на втором экране идёт ролик или анимированная панель». Лечится это переносом динамичного содержимого, а не покупкой нового оборудования.

Один монитор против двух: честное сравнение

Чтобы понять, виноваты ли именно два экрана, нужно сравнить одну и две рабочие поверхности при одной и той же задаче. Звучит очевидно, но на практике сравнивают «вчера было быстрее» с «сегодня медленнее», при этом меняется всё сразу: время суток, загрузка сети, число открытых окон.

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

1. Печать в пустом окне. Откройте простой текстовый редактор и наберите одну и ту же строку. Замечаете ли паузу между нажатием и появлением символа? Это почти чистая проверка задержки отклика, графики здесь минимум.
2. Перетаскивание окна. Возьмите окно за заголовок и медленно, затем быстро переведите его с края на край. На двух мониторах повторите, пересекая границу между ними. Отмечайте рывки, «хвост» и запаздывание.
3. Прокрутка длинной таблицы или отчёта. Один и тот же документ, одинаковое число строк, одинаковая скорость прокрутки. Если рывки появляются только здесь, значит, давит объём изменений картинки.
4. Открытие тяжёлой формы или отчёта в вашей программе. Если время ожидания одинаково на одном и двух мониторах и совпадает с тем, что вы видите при локальной работе, вопрос уже не про экраны, а про сам сервер и приложение.

Каждое действие выполняйте в одном и том же порядке на одном экране, затем на двух. Записывайте в таблицу не числа, а наблюдения: «гладко», «заметная пауза», «рывки», «подвисает на секунду». Для передачи коллеге такая таблица ценнее, чем неподкреплённая цифра, потому что показывает картину поведения, а не одно число из случайного момента.

Если на одном мониторе всё гладко, а на двух появляются рывки, это уже говорит о том, что дело в площади изображения, а не в вычислениях. Если же оба режима одинаково вялые, два экрана просто попали под подозрение зря.

Разрешение и масштабирование — отдельная история

Частая ошибка — приравнивать «два монитора» к «вдвое больше работы». На деле важна суммарная площадь в пикселях и то, насколько активно она обновляется. Один монитор с очень высоким разрешением и мелким масштабированием может создавать больше изменяемой площади, чем два скромных экрана. И наоборот: два небольших монитора с обычным разрешением, на которых большую часть времени висит статичный текст, иногда ощущаются легче, чем один широкий экран с постоянной анимацией.

Поэтому число мониторов и разрешение стоит рассматривать как две независимые ручки. Условный пример для наглядности, не как результат измерения: если у сотрудника два экрана Full HD, то суммарно это примерно вдвое больше пикселей, чем на одном таком экране. Если же заменить их одним экраном вдвое большего разрешения по каждой стороне, пикселей станет вчетверо больше. Что из этого ощутимее для канала, зависит от того, как часто картинка меняется.

Масштабирование интерфейса добавляет свой слой. Когда на клиенте включено увеличение, чтобы мелкий текст на плотном экране читался, внешний вид сеанса и фактическое разрешение могут расходиться: изображение рисуется для одного размера и показывается в другом. Иногда это порождает размытость текста, иногда лишнюю работу по перерисовке. Рабочая стратегия такая: менять один параметр за раз и каждый раз прогонять тот же набор из четырёх действий. Тогда видно, какая настройка что дала.

Чтобы масштаб не смешивался с числом экранов, разделите проверки на три прогона. Сначала один монитор с привычным масштабом. Затем те же один монитор, но масштаб 100%, если текст при этом ещё читается. Только после этого подключайте второй экран. Если плавность вернулась уже на втором шаге, причина была в масштабировании, и добавление экрана было ни при чём. Если рывки появились лишь на третьем шаге, вы увидели именно эффект увеличенной площади.

Отдельно стоит учитывать, что размытый текст нередко принимают за проблему сети. Но размытость не связана с паузами: она остаётся и при идеальном канале, потому что рождается из несовпадения размера отрисовки и размера показа. Вывод простой: нечёткие буквы лечатся настройкой масштаба на клиенте, а паузы при вводе — разбором соединения. Смешивать эти два симптома значит искать причину не там.

• Нечёткий текст при ровном вводе: смотрите масштаб и разрешение клиента.
• Ровная картинка, но запаздывание клавиш: смотрите сеть.
• Рывки только при движении больших областей: смотрите площадь и содержимое окон.

Как RDP-клиент работает с несколькими экранами

Клиент mstsc умеет работать с несколькими мониторами и с разными размерами окна, об этом говорит справка Microsoft по mstsc. Там же отмечено важное различие: режим span предъявляет требования к взаимному расположению и разрешению экранов и не равен полноценному режиму с несколькими мониторами. Говоря проще, span склеивает экраны в одну большую поверхность, а полноценная поддержка мониторов воспринимает их как отдельные.

Практическое следствие в том, что при странном поведении на границе экранов, например, окно разъезжается, часть интерфейса оказывается не на своём мониторе или масштаб ведёт себя непредсказуемо, стоит проверить, какой именно режим используется, и сопоставить расположение и разрешение мониторов на клиентском компьютере. Если мониторы стоят с разным разрешением или сдвинуты относительно друг друга, режим span может давать не тот результат, на который рассчитывал пользователь. В таком случае разумно сначала выровнять расположение, а уже потом искать причины в сети.

Пример для проверки границы экранов. Допустим, левый монитор стоит ниже правого на несколько сантиметров, и у них разное разрешение. В режиме span клиент работает с ними как с одной общей поверхностью, а требования mstsc к взаимному расположению и разрешению экранов, о которых говорится в справке Microsoft, при такой раскладке могут не выполняться. Окно, которое пользователь тянет через стык, в этом случае ведёт себя странно, и со стороны это легко принять за сетевую задержку.

Поэтому порядок такой: сначала выровняйте мониторы в настройках экрана клиентского компьютера и, по возможности, уравняйте разрешение, затем повторите перетаскивание окна через границу. Только если рывки остались при ровной геометрии и проводном подключении, переходите к вопросам канала. Такая последовательность экономит время, ведь настройка расположения занимает минуты, а разбор маршрута и потерь пакетов может отнять день.

Конкретные ключи и параметры командной строки берите из справки к mstsc: они зависят от версии клиента, и перечислять их по памяти не стоит.

Кабель или Wi-Fi: проверка сетевой части

Теперь про канал. Самая частая ловушка — думать, что всё упирается в скорость. Скорость, то есть пропускная способность, — только одно из свойств соединения. Для интерактивной работы не менее важны:

• задержка в обе стороны: сколько времени пакет идёт до сервера и возвращается;
• стабильность задержки: ровные 30 условных единиц лучше, чем то 10, то 200;
• потери пакетов: каждая потеря требует повторной передачи, и для пользователя это выглядит как заминка;
• перегрузка соединения: если рядом кто-то качает большой файл или идёт видеозвонок, в общей трубе возникают очереди.

Поэтому формулировка «у нас гигабитный интернет, значит сеть ни при чём» не работает. Материал Microsoft прямо предостерегает от оценки нагрузки лишь по скорости тарифа, и это касается не только расчёта полосы, но и общего понимания сетевой картины.

Беспроводное подключение добавляет свои особенности: уровень сигнала меняется, помехи от соседних сетей и стен вызывают колебания задержки, а несколько устройств делят один эфир. Проводное соединение обычно ровнее, потому что среда не делится так хаотично. Но это общее рассуждение, а не закон: плохой кабель, перегруженный коммутатор или слабый маршрутизатор способны испортить и проводное подключение.

Проверку проводите тем же набором действий, меняя только тип подключения:

1. Тот же компьютер, тот же сеанс, один монитор, Wi-Fi: пройдите четыре действия и запишите наблюдения.
2. То же самое по кабелю.
3. Два монитора по Wi-Fi, затем по кабелю.

Получится четыре столбца наблюдений. Если по кабелю печать и перетаскивание становятся ровнее, а по Wi-Fi возвращаются паузы, виновата нестабильность беспроводной среды, а не число экранов. Если же рывки при перетаскивании на двух мониторах остаются и по кабелю, значит, главная причина — объём изменений картинки, и нужно возвращаться к разрешению, масштабированию и содержимому окон.

Полезно заранее решить, как читать смешанные результаты. Возможна картина, когда по кабелю перетаскивание ровнее, но на двух мониторах всё равно чуть хуже, чем на одном. Это нормальное сочетание двух причин: канал стал стабильнее, а площадь обновления осталась больше. Тогда нет смысла требовать идеала, достаточно оценить, мешает ли остаточная разница реальной работе бухгалтера, у которого окна редко прыгают по экрану.

Обратный случай: на Wi-Fi печать в пустом окне даёт паузы, но они исчезают при переходе на кабель, а рывки перетаскивания остаются. Значит, у вас две независимые проблемы, и чинить их придётся по очереди. Сначала уберите нестабильную среду, потому что пока ввод запаздывает, судить о графике трудно. Затем повторите прогон и посмотрите, что осталось. Такой порядок помогает не гоняться сразу за всем и показывает, какое исправление дало эффект.

Помните, что пропускная способность тут лишь одна из характеристик. Ровная задержка и отсутствие потерь для интерактивной работы нередко важнее запаса по скорости, поэтому не пытайтесь победить нестабильность увеличением тарифа.

Не забывайте и про время проверки. Прогон в разгар рабочего дня, когда в офисе все на видеозвонках, и прогон утром дадут разные картины. Чтобы сравнение было честным, повторяйте его в сопоставимых условиях и отмечайте, что происходило рядом.

Когда виноват сервер, а не экран

Бывает, что экранная часть и сеть в порядке, а работа всё равно вялая. Если при печати и перетаскивании окон всё гладко, но формирование отчёта, открытие большого справочника или проведение документов занимает долго, причина, скорее всего, в вычислительной стороне. Здесь стоит посмотреть на загрузку процессора, оперативной памяти и диска внутри самого сеанса: хватает ли ресурсов при одновременной работе нескольких пользователей, не упирается ли приложение в дисковые операции.

Это принципиально другая задача, и решать её надо измерениями на сервере, а не перенастройкой экранов. Если работа ведётся на арендованном виртуальном сервере, тарифы MAATRIX с разным числом vCPU и объёмом памяти (от Ba с 1 vCPU и 2 ГБ до Djed с 16 vCPU и 32 ГБ) годятся как отправная точка для теста: можно развернуть сеанс, прогнать типичные операции и посмотреть, где именно возникает узкое место. Ресурсы тарифа не равны обещанию ёмкости, так что итоговый выбор определяют ваши наблюдения за реальной нагрузкой, а не строка в каталоге. Более мощный сервер не лечит рывки перетаскивания окон, если проблема в Wi-Fi или в размере картинки, и наоборот: хороший канал не ускорит отчёт, который упирается в диск.

Если на этом же сервере предполагается несколько пользователей, отдельно подумайте о вопросах доступа и лицензирования, они разобраны в статье про Windows Server для нескольких пользователей и RDP.

Воспроизводимая проверка для коллеги

Чтобы результат поняли без вас, оформите его одинаково. Вот шаблон, который можно скопировать в заметку или письмо:

Рабочее место: (кабинет, компьютер)
Мониторы: 1 или 2; разрешение каждого; масштаб в %
Подключение: кабель или Wi-Fi
Время проверки: (утро, середина дня)

Печать в пустом окне: гладко / пауза
Перетаскивание окна: гладко / рывки
Прокрутка длинной таблицы: гладко / рывки
Тяжёлый отчёт: обычно / долго (и как на локальном ПК)

Что менял между прогонами: (одна вещь)

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

Компромисс, при котором человеку удобно

Пройдя все четыре шага, вы получите картину, из которой можно собрать приемлемую настройку. Она редко совпадает с «максимумом» по всем параметрам. Чаще всего вариантов несколько:

• Два экрана, умеренное разрешение, проводное подключение. Подходит, когда работа текстовая и табличная, а на втором экране висят справочные окна без анимации. Площадь удобная, поток изменений небольшой.
• Два экрана, но видео и конференции вынесены за пределы сеанса. Если звонок идёт на локальном компьютере, а в удалённый сеанс уходит только рабочая программа, динамичное содержимое не нагружает RDP.
• Один широкий экран вместо двух. Если граница между мониторами и режим отображения создают проблемы, а Wi-Fi убрать нельзя, иногда проще работать на одной поверхности, но с удобным масштабом.
• Снижение разрешения или упрощение оформления сеанса. Небольшая уступка в красоте часто возвращает плавность, особенно при беспроводном подключении.

Бухгалтеру на самом деле не нужна максимальная частота обновления на втором экране с выпиской из банка. Ему нужно, чтобы цифры читались, окна не разъезжались, а нажатие клавиши сразу давало букву. Если для этого достаточно проложить кабель вместо Wi-Fi или убрать масштаб, который размывает текст, это и есть правильная настройка, даже если на бумаге она выглядит скромнее.

Критерий готовности простой: сотрудник проработал полный день и ни разу не вспомнил про канал. Не цифры в окне диагностики, не красивое разрешение на скриншоте, а отсутствие мыслей о том, что что-то отстаёт. Если после изменений человек просто работает, а вы получили таблицу наблюдений, где видно, какое действие что исправило, проблема решена, и в следующий раз её можно будет повторить на другом рабочем месте за четверть часа.