RDP协议详览：基本连接与图形远程技术规格

4星 · 超过85%的资源需积分: 50 101 浏览量更新于2024-07-28 1 收藏 8.34MB PDF 举报

RDP协议白皮书，即Microsoft Remote Desktop Protocol (RDP) Basic Connectivity and Graphics Remoting Specification，是微软公司于2009年发布的一份详细文档，版权归微软所有。这份文档涵盖了RDP协议的核心功能，包括基本连接和图形远程访问，旨在促进远程桌面访问和虚拟化技术的发展。 RDP是一种在Windows系统之间进行远程控制和资源共享的标准协议，它允许用户通过网络从一台计算机访问另一台计算机，实现远程登录、屏幕共享、文件传输等功能。该协议的重要性在于其广泛应用于企业环境中的远程工作、远程支持以及云桌面解决方案，如Office 365和AWS WorkSpaces等。在白皮书中，Microsoft强调了以下几点： 1. **版权声明**：文档的使用受到微软版权保护，允许开发者复制和实施RDP协议，用于创建自己的产品或文档。开发者可以分发包含在文档中的部分代码示例和相关元数据，只要是为了正确展示其产品的实现细节。同时，引用的其他文档也受此许可。 2. **非商业秘密**：微软申明这份文档中没有包含任何未公开的商业秘密信息，用户可以放心使用。 3. **专利权**：尽管如此，微软可能拥有与RDP相关的专利，因此开发者在实现RDP功能时需注意潜在的专利风险，确保其产品不侵犯微软的知识产权。该白皮书详细阐述了RDP协议的工作原理，包括握手过程、加密机制（如TLS/SSL），以及图像压缩、多通道音视频传输、输入设备支持等关键技术。此外，还包括了错误处理、性能优化和安全设置等内容，以便开发人员能够理解和实现一个稳定、安全的远程桌面服务。对于IT专业人员而言，深入理解RDP协议不仅有助于优化网络架构，提升用户体验，还能在遇到问题时快速定位和解决，从而推动企业的数字化转型。同时，这份白皮书也是对RDP协议最新版本的官方指南，对于开发者和系统管理员来说，是不可或缺的学习和参考资源。

16 / 378

[MS-RDPBCGR] — v20090223

Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification

Release: Monday, February 23, 2009

Figure 1: Remote Desktop Protocol (RDP) connection sequence

The connection sequence can be broken up into eight distinct phases:

1. Connection Initiation: The client initiates the connection by sending the server an X.224

Connection Request PDU (class 0). The server responds with an X.224 Connection Confirm PDU

(class 0).

From this point, all subsequent data sent between client and server is wrapped in an X.224 Data

Protocol Data Unit (PDU).

2. Basic Settings Exchange: Basic settings are exchanged between the client and server by using

the MCS Connect Initial and MCS Connect Response PDUs. The Connect Initial PDU contains a

18 / 378

[MS-RDPBCGR] — v20090223

Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification

Release: Monday, February 23, 2009

Figure 3: MCS Connect Response PDU

3. Channel Connection: The client sends an MCS Erect Domain Request PDU, followed by an MCS

Attach User Request PDU to attach the primary user identity to the MCS domain. The server

responds with an MCS Attach User Response PDU containing the user channel ID. The client then

proceeds to join the user channel, the input/output (I/O) channel and all of the static virtual

channels (the I/O and static virtual channel IDs are obtained from the data embedded in the GCC

packets) by using multiple MCS Channel Join Request PDUs. The server confirms each channel

with an MCS Channel Join Confirm PDU. (The client only sends a Channel Join Request after it

has received the Channel Join Confirm for the previously sent request.)

From this point, all subsequent data sent from the client to the server is wrapped in an MCS Send

Data Request PDU, while data sent from the server to the client is wrapped in an MCS Send Data

Indication PDU. This is in addition to the data being wrapped by an X.224 Data PDU.

4. RDP Security Commencement: If Standard RDP Security mechanisms are being employed and

encryption is in force (this is determined by examining the data embedded in the GCC

Conference Create Response packet) then the client sends a Security Exchange PDU containing

an encrypted 32-byte random number to the server. This random number is encrypted with the

public key of the server (the server's public key, as well as a 32-byte server-generated random

number, are both obtained from the data embedded in the GCC Conference Create Response

packet). The client and server then utilize the two 32-byte random numbers to generate session

keys which are used to encrypt and validate the integrity of subsequent RDP traffic.

From this point, all subsequent RDP traffic can be encrypted and a security header is included

with the data if encryption is in force (the Client Info and licensing PDUs are an exception in that

they always have a security header). The Security Header follows the X.224 and MCS Headers

and indicates whether the attached data is encrypted. Even if encryption is in force, server-to-

19 / 378

[MS-RDPBCGR] — v20090223

Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification

Release: Monday, February 23, 2009

client traffic may not always be encrypted, while client-to-server traffic will always be encrypted

by Microsoft RDP implementations (encryption of licensing PDUs is optional, however).

5. Secure Settings Exchange: Secure client data (such as the username, password, and auto-

reconnect cookie) is sent to the server using the Client Info PDU.

6. Licensing: The goal of the licensing exchange is to transfer a license from the server to the client.

The client should store this license and on subsequent connections send the license to the server

for validation. However, in some situations the client may not be issued a license to store. In

effect, the packets exchanged during this phase of the protocol depend on the licensing

mechanisms employed by the server. Within the context of this document, it is assumed that the

client will not be issued a license to store. For details regarding more advanced licensing

scenarios that take place during the Licensing Phase, see [MS-RDPELE].

7. Capabilities Exchange: The server sends the set of capabilities it supports to the client in a

Demand Active PDU. The client responds with its capabilities by sending a Confirm Active PDU.

8. Connection Finalization: The client and server send PDUs to finalize the connection details. The

client-to-server and server-to-client PDUs exchanged during this phase may be sent concurrently

as long as the sequencing in either direction is maintained (there are no cross-dependencies

between any of the client-to-server and server-to-client PDUs). After the client receives the Font

Map PDU it can start sending mouse and keyboard input to the server, and upon receipt of the

Font List PDU the server can start sending graphics output to the client.

Besides input and graphics data, other data that can be exchanged between client and server after

the connection has been finalized includes connection management information and virtual channel

messages (exchanged between client-side plug-ins and server-side applications).

1.3.1.2 Security-Enhanced Connection Sequence

The RDP Connection Sequence does not provide any mechanisms which ensure that the identity of

the server is authenticated, and as a result it is vulnerable to man-in-the-middle attacks (these

attacks can compromise the confidentiality of the data sent between client and server).

The goal of the Security-Enhanced Connection Sequence is to provide an extensible mechanism

within RDP so that well-known and proven security protocols (such as Secure Socket Layer (SSL) or

Kerberos) can be used to fulfill security objectives and to wrap RDP traffic. There are two variations

of the Security-Enhanced Connection Sequence. The negotiation-based approach aims to provide

backward-compatibility with previous RDP implementations, while the Direct Approach favors more

rigorous security over interoperability.

Negotiation-Based Approach: The client advertises the security packages which it supports (by

appending a negotiation request structure to the X.224 Connection Request PDU and the server

selects the package to use (by appending a negotiation response structure to the X.224 Connection

Confirm PDU). After the client receives the X.224 Connection Confirm PDU the negotiated security

package is executed and used to secure all subsequent RDP traffic.

Direct Approach: Instead of negotiating a security package, the client and server immediately

execute a predetermined security protocol (for example, the CredSSP Protocol) prior to any RDP

traffic being exchanged on the wire. This approach results in all RDP traffic being secured using the

hard-coded security package. However, it has the disadvantage of not working with servers that

expect the connection sequence to be initiated by an X.224 Connection Request PDU.

For more details about Enhanced RDP Security, see section 5.4.

20 / 378

[MS-RDPBCGR] — v20090223

Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification

Release: Monday, February 23, 2009

1.3.1.3 Deactivation-Reactivation Sequence

After the connection sequence has run to completion, the server may determine that the client

needs to be connected to a waiting, disconnected session. To accomplish this task the server signals

the client with a Deactivate All PDU. A Deactivate All PDU implies that the connection will be

dropped or that a capability re-exchange will occur. If a capability re-exchange needs to be

performed then the server will re-execute the connection sequence, starting with the Demand Active

PDU (the Capability Exchange and Connection Finalization phases as described in section 1.3.1.1)

but excluding the Persistent Key List PDU.

1.3.1.4 Disconnection Sequences

1.3.1.4.1 User-Initiated on Client

The user can initiate a client-side disconnect by closing the RDP client application. To implement this

type of disconnection the client sends the server a Shutdown Request PDU. The server will deny this

request and send the client a Shutdown Request Denied PDU. At this point the client behavior is

implementation-dependent. The Microsoft RDP client displays a dialog box specifying that the

session will be disconnected. If the user chooses to disconnect, the client sends the server an MCS

Disconnect Provider Ultimatum PDU (with the reason code set to "user requested") and closes the

connection.

1.3.1.4.2 User-Initiated on Server

The user can initiate a server-side disconnect by ending the remote session (or application) running

on the server. To implement this type of disconnection, the server first sends the client a Deactivate

All PDU followed by an optional MCS Disconnect Provider Ultimatum PDU (with the reason code set

to "user requested"). The connection is then closed by the server.

1.3.1.4.3 Administrator-Initiated on Server

The administrator of a server can force a user to be logged off from their session or disconnect

sessions outside of the user's control. To implement this type of disconnection, the server first sends

the client a Deactivate All PDU followed by an optional MCS Disconnect Provider Ultimatum PDU

(with the reason code set to "provider initiated"). The connection is then closed by the server.

1.3.1.5 Automatic Reconnection

The Automatic Reconnection feature allows a client to reconnect to an existing session (after a

short-term network failure has occurred) without having to resend the user's credentials to the

server.

After a successful log on, the server sends the client an "auto-reconnect cookie" in the Save Session

Info PDU. This cookie is bound to the current user's session and is stored by the client. In the case

of a disconnection due to a network error, the client can try to automatically reconnect to the

server. If it can connect, it sends a cryptographically modified version of the cookie to the server in

the Client Info PDU (the Secure Settings Exchange phase of the connection sequence, as specified in

section 1.3.1.1). The server uses the modified cookie to confirm that the client requesting auto-

reconnection is the last client that was connected to the session. If this check passes, then the client

is automatically connected to the desired session upon completion of the connection sequence.

The auto-reconnect cookie associated with a given session is flushed and regenerated whenever a

client connects to the session or the session is reset. This ensures that if a different client connects

to the session, then any previous clients that were connected can no longer use the auto-reconnect

剩余377页未读，继续阅读

上三行

粉丝: 58
资源: 22

RDP协议详览：基本连接与图形远程技术规格

RDP下述X224协议详解

RDP协议简要分析 PDF格式

RDP协议白皮书文档

IOS端开发RDP协议

guacamole 1.4.0 版本中 RDP协议是什么版本的

windows7 RDP协议版本如何查看

RDP协议消息传输是明文还是加密

rdp协议和ssh协议有什么区别？

如何在IOS端使用FreeRDP协议

RDP协议从4.0到5.2版本有哪些关键功能升级？如何在Linux平台上使用RDP进行终端服务连接？

最新资源