Клиенты удаленного рабочего стола Remote Desktop clients

Применяется к: Windows 10, Windows 8.1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 Applies to: Windows 10, Windows 8.1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2

Управлять удаленным компьютером можно с помощью клиента Удаленного рабочего стола (Майкрософт). You can control a remote PC by using a Microsoft Remote Desktop client. Клиент может работать практически на любом устройстве, в том числе на смартфоне. The client can run on almost any device, including on your mobile smartphone. Клиент предоставляет те же возможности, что и при доступе к клавиатуре компьютера. The client gives you the same powers you would have if you could reach the PC’s keyboard. С помощью клиента можно: Through the client, you can:

• управлять приложениями, которые установлены на компьютере; Operate the apps that are installed on the PC.
• получать доступ к файлам и сетевым ресурсам компьютера; Access the files and network resources of the PC.
• оставлять приложения открытыми после завершения работы клиента. Leave the apps open when you end the client.

Перед началом работы ознакомьтесь со статьей о поддерживаемой конфигурация. Before you start, see the supported configuration article. В этой статье рассматриваются конфигурации компьютеров, к которым могут подключаться клиенты Удаленного рабочего стола. The article discusses the PC configurations that the Remote Desktop clients can connect to. См. также статью с часто задаваемыми вопросами о клиенте. Also see the client FAQ article.

Доступны следующие клиентские приложения. The following client apps are available:

Клиент Client	Получение приложения Get the app	Документация Documentation	Последняя версия Latest version
Настольный компьютер с Windows Windows Desktop	Клиент Удаленного рабочего стола Windows Desktop client	Начало работы, Что нового Get started, What’s new	1.2.1844 1.2.1844
Microsoft Store Microsoft Store	Клиент Windows 10 в Microsoft Store Windows 10 client in the Microsoft Store	Начало работы, Что нового Get started, What’s new	1.2.1810 1.2.1810
Android Android	Клиент Android в Google Play Android client in Google Play	Начало работы, Что нового Get started, What’s new	10.0.10 10.0.10
iOS iOS	Клиент iOS в App Store iOS client in the App Store	Начало работы, Что нового Get started, What’s new	10.2.5 10.2.5
macOS macOS	Клиент macOS в App Store macOS client in the App Store	Начало работы, Что нового Get started, What’s new	10.5.2 10.5.2

Настройка удаленного компьютера Configuring the remote PC

Чтобы настроить удаленный компьютер перед получением к нему удаленного доступа, разрешите доступ к этому компьютеру. To configure your remote PC before accessing it remotely, see Allow access to your PC.

Схема URI для клиента удаленного рабочего стола Remote Desktop client URI scheme

Вы можете интегрировать функции клиентов удаленного рабочего стола на всех платформах с помощью схемы URI. You can integrate features of Remote Desktop clients across platforms by enabling a Uniform Resource Identifier (URI) scheme. Ознакомьтесь с поддерживаемыми атрибутами URI, которые можно использовать с клиентами для iOS, Mac и Android. Learn about the supported URI attributes that you can use with the iOS, Mac, and Android clients.

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

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

Исходная версия продукта: Windows Server 2012 R2
Исходный номер КБ: 186572

Инициализация сервера терминалов Windows

По мере загрузки и загрузки операционной системы Windows Terminal Server служба сервера терминалов (Termsrv.exe) запущена и создает стеки прослушивания (по одному на протокол и на транспортную пару), которые прослушивают входящие подключения. Каждому подключению предоставляется уникальный идентификатор сеанса или sessionID для представления отдельного сеанса серверу терминалов. Каждый процесс, созданный в сеансе, «помечен» связанным sessionID, чтобы отличать пространство имен от любого другого пространства имен подключения.

Консоль (клавиатура сервера терминалов, мышь и видео) всегда загружается первым и рассматривается как подключение клиента в особом случае и назначенное sessionID. Сеанс консоли начинается как обычный сеанс Windows NT с настроенным Windows NT дисплеем, мышью и драйверами клавиатуры.

Затем служба сервера терминалов вызывает диспетчер сеансов Windows NT (Smss.exe), чтобы создать два (по умолчанию = 2) бездействия клиентских сеансов (после создания сеанса консоли), ожидающим клиентских подключений. Чтобы создать сеансы бездействия, диспетчер сеансов выполняет процесс Windows NT подсистемы клиента или сервера (Csrss.exe), и этому процессу назначен новый sessionID. Процесс CSRSS также вызывает процесс Winlogon (Winlogon.exe) и модуль ядра Win32k.sys (Window Manager и интерфейс графического устройства — GDI) в новом связанном sessionID. Измененный загрузчик Windows NT распознает этот Win32k.sys как загружаемый образ SessionSpace по предопределенным битам, установленным в заголке изображения. Затем кодовая часть изображения будет переместиться в физическую память с указателями из виртуального адресного пространства ядра для этого сеанса, если Win32k.sys еще не загружен. По дизайну он всегда присоединяется к ранее загруженным коду изображения (Win32k.sys), если он уже существует в памяти. Например, из любого активного приложения или сеанса.

Затем раздел данных (или не общий) этого изображения будет выделен для нового сеанса из созданного раздела памяти ядра SessionSpace, доступного для страниц. В отличие от сеанса консоли, сеансы клиента сервера терминалов настроены для загрузки отдельных драйверов для дисплея, клавиатуры и мыши.

Новым драйвером дисплея является устройство RDP, Tsharedd.dll. Драйверы мыши и клавиатуры взаимодействуют с стеком через диспетчер стека нескольких экземпляров, termdd.sys. Termdd.sys отправит сообщения о действиях с помощью мыши и клавиатуры драйверу RDP, Wdtshare.sys. Эти драйверы позволяют удаленно и интерактивно использовать клиентский сеанс RDP. Наконец, сервер терминалов также вызывает поток прослушиватель подключения для протокола RDP, который снова управляется диспетчером стека нескольких экземпляров (Termdd.sys), который прослушивает подключения клиентов RDP по номеру порта TCP 3389.

На этом этапе процесс CSRSS существует под собственным пространством имен SessionID, и при необходимости для каждого процесса для каждого процесса будут сданы его данные. Все процессы, созданные в рамках этого SessionID, будут автоматически выполняться в sessionSpace процесса CSRSS. Это предотвращает доступ процессов с разными sessionID к данным другого сеанса.

Подключение клиента

Клиент RDP можно установить и запустить на любом терминале под управлением Windows (на основе WinCE), Windows для workgroups 3.11 с TCP/IP-32b или платформе на основе API Microsoft Win32. Надстройка citrix Metaframe поддерживает клиенты не из Windows. Размер исполняемого файла клиента RDP для Windows для рабочих групп составляет примерно 70 КБ, используется рабочий набор размером 300 КБ и 100 КБ для отображения данных. Размер клиента на основе Win32 составляет примерно 130 КБ, для отображения данных используется рабочий набор размером 300 КБ и 100 КБ.

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

Низкое шифрование шифрует только пакеты, от отправленные клиентом на сервер терминалов. Это «только входное» шифрование используется для защиты ввода конфиденциальных данных, таких как пароль пользователя. Среднее шифрование шифрует исходяющие пакеты от клиента так же, как и низкоуровневый шифрование, но также шифрует все отображаемого пакета, возвращаемого клиенту с сервера терминалов. Этот метод шифрования обеспечивает защиту конфиденциальных данных, так как они по сети отображаются на удаленном экране. Как низкое, так и среднее шифрование используют алгоритм Microsoft-RC4 (измененный алгоритм RC4 с улучшенной производительностью) с 40-битным ключом. При высоком шифровании пакеты шифруются в обоих направлениях, в клиенте и из клиента, но будут использовать стандартный алгоритм шифрования RC4 с 40-битным ключом. Неэкспортируемая версия Windows NT Terminal Server будет обеспечивать 128-битное шифрование RC4 высокого уровня.

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

По умолчанию все клиенты резервируют 1,5 МБ памяти для кэша точечек, который используется для кэширования точек-карт, таких как значки, панели инструментов, курсоры и так далее, но не используется для удержания строк Юникода. Кэш не удается (с помощью ключа реестра) и перезаписывается с помощью алгоритма LRU. Сервер терминалов также содержит буферы, позволяющие управлять потоком передачи обновлений экрана клиентам, а не постоянному потоку. Когда взаимодействие с пользователем в клиенте высоко, буфер очищается приблизительно 20 раз в секунду. Во время простоя или при бездействии пользователя буфер сбрасывается только 10 раз в секунду. Вы можете настроить все эти номера с помощью реестра.

После согласования сведений о сеансе экземпляр стека RDP сервера для этого подключения будет соединен с существующим бездействующим сеансом пользователя Win32k, и пользователю будет предложено Windows NT экрана для Windows NT. Если автономная настройка настроена, зашифрованное имя пользователя и пароль будут переданы серверу терминалов и продолжится процесс логин. Если в настоящее время не существует бездействующим сеансов Win32k, служба сервера терминалов будет вызывать диспетчер сеансов (SMSS), чтобы создать новое пространство пользователей для нового сеанса. Большая часть сеанса пользователя Win32k использует общий код и загружается значительно быстрее после загрузки одного экземпляра.

После вводить имя пользователя и пароль пакеты отправляются на сервер терминалов. Затем процесс Winlogon выполняет необходимую проверку подлинности учетной записи, чтобы убедиться, что пользователь имеет привилегии для входа в систему и передает домен и имя пользователя службе сервера терминалов, которая поддерживает список SessionID домена или имени пользователя. Если с этим пользователем уже связан SessionID (например, отключенный сеанс), текущий активный стек сеанса присоединяется к старому сеансу. Затем удаляется временный сеанс Win32, используемый для первоначального сеанса. В противном случае подключение переходит в обычное состояние, и служба сервера терминалов создает новое сопоставление sessionID домен/имя пользователя. Если по какой-либо причине для этого пользователя активно несколько сеансов, отображается список сеансов, и пользователь решает, какой из них выбрать для повторного подключения.

Запуск приложения

После этого для пользователя отображается рабочий стол (или приложение, если в режиме с одним приложением). Когда пользователь выбирает 32-битное приложение для запуска, команды мыши передаются на сервер терминалов, который запускает выбранное приложение в новое виртуальное пространство памяти (2 ГБ приложения, ядро 2 ГБ). Все процессы на сервере терминалов будут совместно работать с кодом в режимах ядра и пользователя, где это возможно. Чтобы обеспечить общий доступ к коду между процессами, Windows NT виртуальной памяти (VM) использует защиту страниц при копировании при записи. Если нескольким процессам необходимо считывать и записывать одно и то же содержимое памяти, диспетчер ВМ назначит область памяти защиту страниц при копировании при записи. Процессы (сеансы) будут использовать то же содержимое памяти, пока не будет выполнена операция записи, после чего диспетчер виртуальной системы скопирует физический фрейм страницы в другое расположение, обновает виртуальный адрес процесса, указав на новое расположение страницы, а затем пометит страницу как чтение и записи. Копирование при записи удобно и эффективно для приложений, работающих на сервере терминалов.

Когда приложение на основе Win32, например Microsoft Word, загружается в физическую память одним процессом (сеансом), оно помечается как копирование при записи. Когда новые процессы (сеансы) также вызывают Word, загрузчик изображений просто будет указать новые процессы (сеансы) на существующую копию, так как приложение уже загружено в память. Если требуются буферы и пользовательские данные (например, сохранение в файл), необходимые страницы будут скопированы в новое физическое расположение памяти и помечены как чтение и записи для отдельного процесса (сеанса). Диспетчер ВМ защищает это пространство памяти от других процессов. Однако большая часть приложения является кодом для совместной работы и будет иметь только один экземпляр кода в физической памяти независимо от того, сколько раз оно будет запускаться.

Предпочтительно (хотя и необязательно) запускать 32-битные приложения в среде сервера терминалов. 32-bit applications (Win32) will allow sharing of code and run more efficiently in multi-user sessions. Windows NT позволяет запускать 16-битные приложения (Win16) в среде Win32 путем создания виртуального компьютера на основе MS-DOS (VDM) для каждого приложения Win16. Все 16-битные выходные данные преобразуются в вызовы Win32, которые выполняют необходимые действия. Так как приложения Win16 выполняются в своей собственной VDM, код нельзя совместно использовать между приложениями в нескольких сеансах. Для перевода между вызовами Win16 и Win32 также необходимы системные ресурсы. Запуск приложений Win16 в среде сервера терминалов потенциально может потреблять вдвое больше ресурсов, чем в сравнимом приложении на основе Win32.

Отключение сеанса и отключение пользователя

Отключение сеанса

Если пользователь решит отключить сеанс, процессы и все пространство виртуальной памяти останутся на физическом диске, если для других процессов требуется физическая память. Так как сервер терминалов сохраняет сопоставление домена/имени пользователя и связанного с ним sessionID, при повторном подсоединение одного и того же пользователя существующий сеанс будет загружен и снова доступен. Дополнительное преимущество RDP состоит в возможности изменения разрешений экрана сеанса в зависимости от того, что пользователь запрашивает для сеанса. Например, предположим, что пользователь ранее подключился к сеансу сервера терминалов с разрешением 800 x 600 и отключил его. Если пользователь переходит на другой компьютер, который поддерживает разрешение только 640 x 480, и повторно подключен к существующему сеансу, рабочий стол будет перерисован для поддержки нового разрешения.

Вход пользователя

Как правило, выйдите из нее просто. После выхода пользователя из сеанса все процессы, связанные с SessionID, будут завершены, а память, выделенная для сеанса, будет отпущена. Если пользователь работает с 32-битным приложением, например Microsoft Word, и выходит из сеанса, код самого приложения остается в памяти, пока последний пользователь не выйдет из приложения.