Протокол RDP

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

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

История появления

Протокол удаленного рабочего стола, а именно так расшифровывается аббревиатура RDP, появился в далеком 1998 году. Этот проприетарный протокол прикладного уровня, в то время входил в состав ОС Windows NT 4.0 Terminal Server, и позволял реализовать идею удаленного функционирования клиент-серверных приложений. Как вы понимаете, не всегда есть возможность обеспечить все рабочие места мощными компьютерами, а уж в те далекие годы производительность оставляла желать лучшего.

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

Описание протокола RDP

• По умолчанию, для подключения используется порт TCP 3389
• Как уже упомянуто выше, при подключении предоставляется возможность работать с файлами на удаленном машине
• Для обеспечения безопасности реализовано шифрование и 56 и 128 битным ключами
• Также для функций безопасности, используется возможности протоколов TLS
• Общий буфер обмена — вы можете копировать данные и удаленной машины, и вставлять их на локальный ПК.
• Реализована возможность подключения локальных ресурсов к удаленному ПК.
• Протокол RDP предоставляет доступ к портам локального компьютера (последовательные и параллельные)

Принцип работы

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

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

Аутентификация

Если настроена система обеспечения безопасности протокола RDP, аутентификация происходит следующим образом:

1. При инициализации подключения формируется пара RSA ключей
2. Далее создается специальный сертификат открытого ключа
3. Операционная система проводит процесс подписи сертификата RSA ключем
4. Далее клиент осуществляем подключение к серверу, получает от него сертификат, и если тот проходит проверку, инициализируется сессия удаленного управления

Как запустить

В операционных системах, таких как Windows XP, Vista, Seven, по умолчанию включено клиентское ПО Remote Desktop Connection. Для его запуска вам необходимо нажать сочетание клавиш Win+R , набрать mstsc и нажать Enter.

В результате появится окно, в котором необходимо настроить параметры подключения посредством протокола RDP. Следует указать ip адрес сервера или его DNS имя, выбрать подключаемые ресурсы, пару логин/пароль и тд.

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

Пользователи ищут сайт по запросам: гаджет таймер выключения компьютера windows 7, viber на айпад, установить ватсап на айпад , кнопка Пуск в Windows — StartisBack для Windows 10, Яндекс Диск как пользоваться.

Обзор нового высокопроизводительного RDP кодека / Habr

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

Ниже мы поговорим о революции в RDP. Новом высокопроизводительном кодеке h364 AVC444, который пришел на смену AVC420.

Теперь для комфортной работы с 3d моделями, программами рисования и прочими графически сложными системами не требуется ничего, кроме Windows 10 и RDP. Не требуется RemoteFX технология, не требуется профессиональный графический ускоритель вроде Quadro.

Видео сравнения старого RDP и c новым (обратите внимание на загрузку сети)

Youtube сильно жмет видео, четкость заметно падает. Это особенно заметно в играх (ниже), так как там плохое освещение. Поэтому я выложил файлы с видео на Яндекс диск.

Видео было захвачено с Hyper-V виртуальных машин, без подключения RemotFX видеоускорителей.

Качество видео в новом RDP выше, практически нет разрывов картинки. Кроме того нагрузка на сеть снижается в 2-5 раз! Так же новый кодек более подходит для нестабильных 3g соединений. Он быстро адаптируется к скорости канала и пользователь может получать мгновенный отклик даже с плохим интернет каналом.

Вся эта красота была, вообщем-то, доступна уже с Windows 10 1703, но тогда это требовало настроек групповых политик и иногда на экране появлялись раздражающие артефакты, которые можно было «стереть» поводив по ним любым окошком. Протирание артефактов «тряпочкой» настолько раздражало, что это перевешивало все плюсы технологии.

Вероятно, к настоящему времени Microsoft нашла решение этой проблемы и использует новый кодек по-умолчанию. Я провел всестороннее тестирование, чем и хочу поделиться.

Мои ощущения от нового RDP

Я проводил тесты, сидя за ноутбуком с i5-6300U. Когда я первый раз подключился к игровому PC, стоящему в соседней комнате, я ощутил, будто мой ноутбук вдруг стал работать быстрее и отзывчивее. Это было непередаваемое ощущение, не имеющее ничего общего с работой по RDP в прошлом!

Я проверил работу в IDE, Word, Excel, браузере, Paint и могу сказать со всей ответственностью — черт возьми, у них получилось! Никакого заметного input лаг.

Работа в SketchUp через новый RDP

На видео может показаться, что есть тормоза, но это иллюзия, SketchUP сам по-себе так работает. Интерфейс программы отзывается на действия пользователя мгновенно.

Захотелось странного. Ниже тесты RDP в нескольких играх

Попытка запуска Dota2 через RDP

Играть в доту через новый RDP вполне можно! В видео (ближе к концу) будет дисконнект из-за проблем с Ethernet кабелем. После того, как я воткнул кабель обратно, трансляция автоматически возобновилась… впрочем, как обычно.Попытка запуска платформера Ori через RDP

Играбельно. Есть небольшой input лаг по сравнению со STEAM трансляцией, но ведь RDP никогда и не задумывался как протокол стриминга игр!

Обиднее всего, что не вышло подключить свой Elite Xbox one контроллер. К сожалению даже RemoteFX не позволяет этого сделать. Контроллер просто не появляется в списке:

Попытка запуска Serious Sam

К сожалению, есть проблемы с чувствительностью мыши. Небольшое перемещение мыши приводит к тому, что персонаж выполняет пируэт «юла». Подробности на видео. Мне подсказали что, многие шутеры так себя ведут во время RDP сеанса.

Заключение

Это самое большое событие в жизни протокола RDP на моей памяти. Дело в том, что помимо отличного качества и скорости, мы получаем ОГРОМНОЕ снижение нагрузки на каналы связи! Кроме того, новый кодек так же помогает в ситуациях, когда сервер расположен далеко, скажем, за океаном. Работать стало гораздо комфортнее!

PS: Я тут обнаружил, что YouTube довольно сильно жмет видео, так что, реальное качество картинки выше! Выложил на яндекс диск исходные видео.

RDP vs RemoteFX / Habr

В группе предприятий «Х» используют терминальные сервера.
Начался новый сезон и в одном из представительств загрузка cpu начала достигать 100 процентов, что есть плохо, особенно после того, как пользователи начали жаловаться на скорость работы.
Причина возникновения проблемы была не понятна, количество сотрудников не менялось, софт не менялся… Все представительства в одинаковых условиях.

Собрал тестовый стенд и начал искать решение…
Долго перебирал разные настройки сервера и клиентских мест, это отдельная тема.
В творческом поиске сравнил протоколы RDP и RemoteFX, результаты решил опубликовать.

Сервер:
HP ML350 G6, 1*Xeon5620, 42gb RAM.
DirectX аппаратная видеокарта отсутствует.
СХД:
HP MSA P2000 G3 SAS, из 4х дисков SAS собран массив R5.
ПО:
На сервера установлен ESXi 5.1.
Терминальные сервера представляют из себя VM, выделено 4 vcpu(8000мгц) и 20gb RAM, в качестве гостевой ОС используется Windows Server 2008R2 SP1.

Сравнивалась нагрузка на процессор в трех приложениях: IE11, Adobe PDF Reader 11, 1c8.
Делал 8-10 замеров, в момент замеров на сервере работал только подопытный пользователь и пользователь администратора.
В качестве клиентских мест использовал два ноутбука с Windows XP и Windows 7 SP1, и тонкий клиент HP t510 c установленной ОС HP Smart Zero 4.4.

Результаты

IE11, запускался тестовый ролик, который находился на youtube.
RDP – Нагрузка на процессор 21-23%
RemoteFX – Нагрузка на процессор 11-18%

После замены ноутбуков на тонкий клиент HP.
RDP – Нагрузка на процессор 17-21%
RemoteFX – Нагрузка на процессор 10-12%

В лабораторных условия разница составила 5-10% процесорного времени в пользу RemoteFX.
Добавлю, что RDP по плавности проигрывания видео и рядом не находится с RemoteFX, при включенном RemoteFX, на первый взгляд, разницы в сравнении с обычным ПК не видна.

Все дальнейшие измерения решил проводить на тонком клиенте HP.

Переходим к документу PDF и скроллингу.
RDP – Нагрузка на процессор 16-20%
RemoteFX – Нагрузка на процессор 12-17%
Разница в пользу RemoteFX составила 3-4%.

Настала очередь 1с8, опять будем заниматься скроллингом списка документов.
RDP – Нагрузка на процессор 14-17%
RemoteFX – Нагрузка на процессор 17-18%
Разница в пользу RDP составила 1-3%.

Честно говоря, результат 1с8 мне не понравился. Решил все проверить и сделать дополнительные замеры.
Повторно замерял результаты, вроде все ок, укладываюсь в ошибку при измерениях, примерно 1-2%.
Результаты 1с можно списать на ошибку измерения, в итоге получается, что 1с все равно, как подключается пользователь — по RDP или RemoteFX.

Если подвести предварительные итоги

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

Раньше я пробовал смотреть на PCoIP, результат мне не понравился, может, нужно посмотреть снова, но как не крути, а RemoteFX будет стоить меньше PCoIP, да и концепция VDI мне нравится меньше терминальных серверов.

В случае предприятия «Х» на одном процессоре Xeon5620 с нагрузкой в 40-80% работают 18-24 пользователей, и параллельно с терминальным сервером работает домен контроллер, и еще некоторые мелкие vm.

Как мне видится, внедрение RemoteFX позволит снизить на 20-30% нагрузку на процессор сервера, или позволит добавить примерно 5-7 пользователей.

Интерес к RemoteFX начал расти, и замеры решил продолжить

Сначала будем сравнивать, как влияет увеличение качества передаваемого звука.
В стандартных настройках качество звука подбирается динамически, когда на сервере работает достаточное количество пользователей — это слышно.

Смотрим ролик на ютюбе(RDP), нагрузка на процессор 18-22%, с стандартными настройками результат 17-21%.
Смотрим ролик на ютюбе(RemoteFX), нагрузка на процессор 10-16%, с стандартными настройками результат 10-12%.

Делаю вывод, что разница минимальная и при желании можно смело выставить высокое качество.

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

Далее, как RemoteFX будет работать при изменении настроек, частота кадров, качество картинки, оптимизация кодека

Screen capture rate = Lowest
Screen Image Quality = Medium (default)

Ролик на ютюбе:
Нагрузка на процессор 5-8%

PDF и скроллинг:
Нагрузка на процессор 14-18%

1с8 и скроллинг:
Нагрузка на процессор 12-18%.

В случае медиа получаем выигрыш, но сразу заметно, что видео играет не так плавно и видны подергивания, аналогичные как при RDP.
Если задуматься, в этом нет нечего плохого, все зависит от задач, которые должны выполнять пользователи.

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

Screen capture rate = Medium (default)
Screen Image Quality = Lowest

Ролик на ютюбе
Нагрузка на процессор 5-11%

PDF и скроллинг
Нагрузка на процессор 12-16%

1с8 и скроллинг
Нагрузка на процессор 18-21%.

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

Screen capture rate = Lowest
Screen Image Quality = Lowest

Ролик на ютюбе
Нагрузка на процессор 5-10%

PDF и скроллинг
Нагрузка на процессор 12-16%

1с8 и скроллинг
Нагрузка на процессор 16-19%.

Без комментариев.

Screen capture rate = Highest (best quality)
Screen Image Quality = Highest (best quality)

Ролик на ютюбе:
Нагрузка на процессор 9-13%.

Для получения результатов для 1с и PDF, как оказалось, у меня не хватило терпения.

От настроек Highest (best quality) я ожидал другой результат, а полученный можно списать на ошибку измерения.

Далее на очереди ооптимизация кодека, Text vs Rich Multimedia

Стандартная настройка кодека Rich Multimedia.

PDF и скроллинг:
Нагрузка на процессор 13-16%

1с8 и скроллинг:
Нагрузка на процессор 16-19%

Сводная таблица

Итого

На всех терминальных серверах я включил RemoteFX, хуже точно не будет.
Стало интересно, как изменится результат, если добавить аппаратную видеокарту.

Терминальный доступ — Википедия

Материал из Википедии — свободной энциклопедии

Терминальный доступ — доступ к информационной системе (ИС), организованный так, что локальная машина-терминал не выполняет вычислительной работы, а лишь осуществляет перенаправление ввода информации (от мыши и клавиатуры) на центральную машину (терминальный сервер) и отображает графическую информацию на монитор. Причём вся вычислительная работа в терминальной системе выполняется на центральной машине.

В более широком смысле под терминальным доступом подразумевается такая организация работы, когда информация хранится и обрабатывается на некотором удалённом сервере, а оборудование пользователя выполняет лишь функцию ввода и вывода. Пример: терминалы для оплаты покупок банковскими картами. Терминал считывает с карты данные для аутентификации покупателя. Далее сама аутентификация и транзакция производятся на сервере банка. Результат операции — списание средств или отказ — передаются обратно на терминал.

Исторически терминальный доступ впервые был организован на компьютерах, способных одновременно обслуживать несколько вычислительных процессов. Это позволило более рационально распределять вычислительные ресурсы между пользователями первых очень дорогих вычислительных машин. С появлением дешёвых персональных компьютеров (ПК) роль терминального доступа стала несколько снижаться, так как сложилось мнение, что достаточную производительность ИС можно получить на рабочем столе каждого пользователя ПК.

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

Для улучшения информационной безопасности (например, для предотвращения изъятия данных с рабочих станций) крупные компании всё чаще и чаще используют терминалы для предоставления доступа к своим бухгалтерским, юридическим, банковским и другим системам.

Терминальный сервер — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 18 февраля 2018; проверки требует 1 правка. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 18 февраля 2018; проверки требует 1 правка.

Терминальный сервер, сервер терминалов (англ. terminal server) — сервер, предоставляющий клиентам вычислительные ресурсы (процессорное время, память, дисковое пространство) для решения задач. Технически терминальный сервер представляет собой очень мощный компьютер (либо кластер), соединенный по сети с терминальными клиентами — которые, как правило, представляют собой маломощные или устаревшие рабочие станции, либо специализированные решения для доступа к терминальному серверу. Терминальный сервер служит для удалённого обслуживания пользователя с предоставлением рабочего стола.

Терминальный клиент после установления связи с терминальным сервером пересылает на последний вводимые данные (нажатия клавиш, перемещения мыши) и, возможно, предоставляет доступ к локальным ресурсам (например, принтер, дисковые ресурсы, устройство чтения смарт-карт, локальные порты (COM/LPT)). Терминальный сервер предоставляет среду для работы (терминальная сессия), в которой исполняются приложения пользователя. Результат работы сервера передается на клиента, как правило, это изображение для монитора и звук (при его наличии).

Преимущества терминального сервера

• Снижение временных расходов на администрирование
• Повышение безопасности — снижение риска инсайдерских взломов
• Снижение затрат на программное и аппаратное обеспечения
• Снижение расхода электроэнергии

Недостатки

• Концентрация всей функциональности в рамках одного (нескольких) серверов — выход из строя любого элемента между приложением и клиентами (сервер, коммутаторы, СКС) приводит к простою многих пользователей.
• Усиливаются негативные последствия ошибок конфигурации и работы ПО (последствия ошибок сказываются не на отдельных пользователях, а на всех пользователях сервера сразу же)
• Проблемы с лицензированием (некоторое ПО не предусматривает ситуации работы нескольких пользователей на одном компьютере или требует использования более дорогих версий).

В условиях использования свободнораспространяемого ПО (такого, как X Window System) проблема лицензирования не возникает. Для ПО, предусматривающего в лицензионном соглашении ограничение на количество копий/пользователей, возникают затруднения.

В условиях терминального сервера могут использоваться следующие модели лицензирования:

• Per seat (per device — на рабочее место) — для каждого устройства (тонкого клиента или рабочей станции) требуется отдельная лицензия, вне зависимости от количества пользователей. Подобная схема используется при лицензировании Terminal Services в составе Windows Server.
• Per user (на пользователя) — для каждого пользователя (вне зависимости от числа одновременно работающих пользователей) требуется отдельная лицензия.
• Per connection (конкурентная лицензия) — для каждого соединения требуется отдельная лицензия, при этом количество пользователей/рабочих мест не играет роли — важно количество одновременно обслуживаемых пользователей. Такую систему лицензирования использует Citrix Metaframe. В этом случае существует пул лицензий, каждое новое соединение забирает одну лицензию из пула. Лицензия возвращается в пул при окончании соединения.

Во многих крупных пакетах ПО предусматривается особый сервис — сервер лицензий (приложение, занимающееся учётом, выдачей и приёмом лицензий). В условиях крупных сетей рекомендуется выделение под сервер лицензий отдельного компьютера (или нескольких — для резервирования).

Виды терминальных серверов[править | править код]

См. также[править | править код]

• Тодд Мазерс. Часть ІІІ. Реализация служб терминалов и пакета Сitrix Metaframe // Администрирование Windows Server 2003/2000 на терминальном сервере = Windows Server 2003/2000 Thin Client Solutions. — 3-е изд. — М.: «Вильямс», 2007. — С. 1072. — ISBN 1-57870-276-3.

РДП — это… Что такое РДП?

Однако плавание под РДП было небезопасным (в 1961 году именно из-за неисправности РДП погибла подводная лодка Северного флота С-80).[2]

Я хорошо помню, какое напряжение воцарялось на центральном посту, когда наша подводная лодка становилась под РДП.

Кроме шахты РДП над водой торчат, точнее, режут ее выдвижные антенны и оба перископа — зенитный и командирский.

Конструкция РДП — устройства для подачи воздуха дизелям в подводном положении — допускала весьма опасное соседство труб газовыхлопа и воздухозабора — это потом уже обе системы были разнесены друг от друга.

Сколько бы ни всплывали «под РДП» — (режим «работа дизеля под водой») как бы срочно не уходили на глубину, все работали как черти, не допустив ни одного сбоя… Хотя однажды мотористы, валившиеся с ног от усталости допустили ошибку, которая едва не стала роковой — при срочном погружении они не успели задраить шахту подачи воздуха дизелям и в пятый отсек хлынули тонны забортной воды… К счастью успели во вовремя перекрыть широкогорлую трубу.

Рассказ об этом впереди — Н.Ч.) Да и подводный наш ракетоносец К-129 принял свою смерть именно в таком же режиме движения — под РДП.

Около 01 часов 27 минут 27 января лодка провалилась ниже перископной глубины, что привело к захлестыванию шахты РДП.

После обнаружения поступления воды в 5-й отсек трюмный машинист ошибочно вместо закрытия воздушной захлопки РДП, повернул расположенный рядом маховик комплекса «Лира», в результате чего вода продолжала затоплять отсек, создавая угрожающий дифферент на корму.

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

В Германии первыми широко освоили применение «шнорхеля» — устройства обеспечения работы дизеля на перископной глубине (РДП).