从本文开始，我们将介绍一系列RDP协议的相关实现技术。

一、RDP协议的诞生

实际上，微软RDP协议在诞生之初，是基于ITU-T（国际电信联盟）的T.120协议集中T.128应用程序共享协议（在设计之初，国际电信联盟对其的名称为T.share）进行改进而来，T.120描述了如何为一系列应用程序和服务提供实时，多点数据通信的支持。它由CiscoWebEx的MeetingCenter，Microsoft NetMeeting，Nortel CS 2100和Lotus Sametime等产品使用，以支持应用程序共享，实时文本会议和其他功能。实际上其是一个远程的应用程序共享协议，为终端计算机提供远程计算机上的应用程序共享、实时文本等图像信息，我们也可以理解为是一个远程的共享显示协议。微软在T.128应用程序共享协议的基础上进行改进，最终推出RDP协议的第一个版本（名为版本4.0）。所以其实严格从远程显示协议上来说，其RDP就是基于国际电信联盟进行设计并且建构的T.128应用程序共享协议（T.share协议）进行改进而来。T.128应用程序共享技术最初由国际电信联盟进行设计并且建构，后来英国软件开发商DataConnection Limited基于T.128应用程序共享协议（T.share协议）进行改进，由微软从英国软件开发商Data Connection Limited收购到该技术。

但是我们为什么要有这种远程的图形显示协议呢？远程的图形显示协议其本质是远程控制技术，远程控制技术早在 DOS 时代就已经产生了萌芽，当时的计算机技术研究者们提出了Telnet 协议来通过网络登录、访问和控制远端的计算机。那时候还没有桌面系统，Telnet 协议是基于字符界面以及虚终端的，由于当时的网络比较落后，加之那时计算机只是及少的一部分人能够使用的贵重物品，所以对于远程访问技术既没有完全成熟技术或者条件支持，同时也几乎没有市场需求，所以远程控制技术自然的不需要图形的显示。在桌面系统诞生之后，远程控制技术再继续使用Telnet协议去登录、访问和控制远端的计算机已经达不到用户对远程控制技术的要求了。必须要有一个图形的界面的显示远端计算机的桌面系统。其实那个时候微软本身已经有了针对于远程图形显示技术和协议，就是收购T.128应用程序共享技术来构建的一个具有图形显示的远程协议。微软最初是根据Windows 用户对图形界面的需求，将该协议最先使用于NetMeeting项目，也就是说RDP协议其实是起源于NetMeeting项目派生的代码，而NetMeeting项目又源于国际电联标准（T.120系列）。

有了图形化的远程图形显示技术之后，微软将其放置在了Windows Server的系统中，并将其作为WindowsServer终端系统的一部分进行发布。WindowsServer终端系统使得用户可以访问终端服务器上安装的基于 Windows 的程序或访问完整的Windows 桌面。用户访问终端服务器上的某个程序时，在服务器上执行该程序。只有键盘、鼠标和显示器信息才通过网络传输。每个用户只能看到自己的会话。服务器操作系统透明地管理会话，与任何其他客户端会话无关。微软认为这样的终端服务结合远程图形显示技术可以为企业带来诸多好处。但是在终端服务这里，微软遇见了第一个难题：服务器操作系统如何支持多个会话同时远程登录？这个时候微软发现了Citrix的MultiWin技术，Citrix的MultiWin技术可以同时支持多个用户和会话登录Windows Server的系统。因此微软向Citrix购买其MultiWin技术授权用于Windows Server的终端系统中。有了Citrix的MultiWin技术集成到终端系统中运行多用户和会话同时登录运行在服务器操作系统上，并且用户可以使用远程图形显示技术访问服务器上的应用程序以及Windows桌面，这就就完美的构成了微软的远程桌面技术。

但是从本质上来说，我们应该把微软的远程桌面技术分成两个部分：远程图形显示协议和终端服务（在高版本的服务器系统中更名为远程桌面服务）。所以单就远程图形显示协议而言，其实是和思杰公司没有任何关系的。目前的终端服务（远程桌面服务）支持除了RDP协议之外，还支持第三方远程图形显示协议，比如Citrix ICA/HDX协议。

二、RDP协议的基础

• [RFC2104] HMAC：键入-散列法用于信息身份验证。目前网上有关于RFC的全集中文版，大家可以去网上收索查看RFC2104的规范了解。
• [RFC2119] RFC（Request For Comments）指的关于互联网标准的正式文件它们的内容必须写得非常清楚。表达的时候，必须严格区分哪些是"建议"（suggestion），哪些是"要求"（requirement）。所以，RFC2119专门对一些词语的涵义做出了规定，定义了五个关键词，表示"要求"的严格程度。
• [RFC2246]RFC2246规范就是TLS标准，TLS标准是指明协议如何用TLS来增加安全性。但是如何初始化TLS握手和如何解释证书交换认证的决定都留给设计者和运行在TLS之上的协议实施者来决定。香港回归的千禧之年，TLS安全加密标准发布，RDP也增加了对TLS加密的支持。
• [RFC4346]和RFC2246一样，是SSL/TLS 协议的规范，处于TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
• [RFC5246]基于TLS1.2的版本的规范。
• [RFC2118] Microsoft点对点压缩（MPPC）协议。
• [SSL3] SSL 3.0规范，http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00。
• [T122]国际电信联盟多点通信服务-服务定义规范。http://www.itu.int/rec/T-REC-T.122/en该文档为收费文档。
• [T123]国际电信联盟多媒体会议的网络特定数据协议栈规范。http://www.itu.int/rec/T-REC-T.123/en。该文档为收费文档。
• [T124] 国际电信联盟通用会议控制（GCC）规范。http://www.itu.int/rec/T-REC-T.124/en。该文档为收费文档。
• [T125]国际电信联盟多点通信服务协议规范。指定基于多点通信的信息数据格式和控制传输连接的程序。http://www.itu.int/rec/T-REC-T.125-199802-I/en。该文档为收费文档。
• [T128] 国际电信联盟多点应用程序共享协议规范。此规范是RDP协议的核心协议。http://www.itu.int/rec/T-REC-T.128-199802-S/en。该文档为收费文档。
• [X224]国际电信联盟信息技术-开放系统互连-用于提供连接模式传输服务的协议规范。http://www.itu.int/rec/T-REC-X.224-199511-I/en该文档为收费文档。

就如上列表所述，RDP协议是一个庞大的协议集合体。比方说包含了基本连接和远程图形处理协议、多点通讯服务协议、模式传输服务协议、Microsoft点对点压缩（MPPC）协议、Netlogon远程协议、远程过程调用协议、终端服务网关服务器协议、多媒体会议网络特定数据协议以及远程桌面网关服务器协议等等的协议集。这些协议经过组合、调用以及集成，完美的展现出用户终端计算机系统和远程计算机系统之间的系统交互。

三、RDP协议栈架构

RDP的协议栈模型如图所示。上图可以看出，RDP协议栈分为五个层次，自上向下分别为应用层（也可以称为RDP层，因为应用就是RDP，主要是基于T.128协议）、安全层（用于加密，主要是RFC2246、RFC5246和RFC4346等）、MCS层（MCS和GCC都是国际电信联盟 (ITU) T.120 系列的一部分）、ISO层（包含国际电信联盟 (ITU) X224协议）和TCP/IP层。我们也可以将其细分为传输协议（TCP/IP）部分和会话专用通信协议（RDP）部分。上图中，有黄色方框框起来的部分就是会话专用通信协议（RDP）部分。

下面将由下层到上层逐一介绍这五层的作用。

• 应用程序层（RDP层）：

应用程序层定义了如何将用户操作产生的鼠标、键盘数据传输给服务器端以及将服务器端的图像信息返回给客户端的标准。该标准基于多点应用程序共享协议。这种机制相对复杂，它协商在连接期间所使用的操作并且管理一些数据的高速缓存信息，并减少网络负载。

• 安全层

安全层包括所有加密和签名服务。该层通过对数据的加密和签名，防止未授权用户监视RDP连接和传输的数据流被截获、修改。此外，安全层还管理用户认证和相关远程连接所需的许可证。

• MCS层(GCC)

该层主要提供的是组播服务。组播服务允许点对点和点对多点连接。这是使用多个端点（例如，远程控制）实现功能的唯一方法。MCS是国际电信联盟 (ITU)多点通信服务协议的简称，,位于ISO层之上，包括域管理、通道管理、数据传输和标记管理服务。多点通信服务协议使用T.120系列协议。其由其中的两种标准组成: T.122，定义了多点服务和T.125，指定的数据传输协议。MCS控制通道 (通过在协议内的预定义虚拟通道多路复用数据) 的分配、 优先级别和发送的数据的分段。它实质上是将多个 RDP 堆栈抽象成单一实体，从GCC(通用会议控制) 的角度来看。GCC负责管理这些频道。GCC 允许创建和删除由 MCS 提供的会话连接和控制资源。RDP协议通信拥有多达64,000个虚拟通道用于数据传输。比如说将屏幕作为光栅图形（位图）从服务器传输到客户端或终端。客户端将键盘和鼠标交互传输到服务器。在RDP协议中，这些通过虚拟通道进行通信时极不对称。比方说在RDP4.0中只有一个通道被用来传送键盘、鼠标的数据，在更高级的RDP版本中，光是鼠标就有好几个虚拟通道用来继续数据传输。不仅如此，RDP协议在通常情况下大多数数据都是从服务器传输到客户端。

• ISO层

ISO层为传输服务层，负责将连续的字节流分成多个大小不同的传输数据包并调用底层的TCP服务。RDP最初设计为支持不同的网络拓扑。在当前状态下，它只能通过TCP/IP网络执行，并且在内部被分为上述所说的层次结构。其原因在于，在最低级别上，根据ISO模型的一些相当复杂的规范，对RDP所基于的T.120协议族进行了优化。这些主要是服务等级机制。因为这些机制不能映射到TCP/IP协议上，所以位于ISO层的X.224兼容适配协议将ISO层指定的服务原语映射到TCP/IP协议的服务原语。基本上，只需要四个服务原语，其中三个用于连接管理：连接请求，连接确认和断开请求。这些连接和断开都来自客户端，服务器端只会进行连接确认，而且当服务器结束连接时，不会专门通知客户端。也就是说客户端在连接的过程中处于主动的位置，而服务器端在连接的时候是被动进行应答。当服务器需要主动关闭连接时，不会和客户端确认自己的关闭连接行为。在这种情况下，客户端实现需要通过相应的异常处理来解决来自服务器端通知自己定义的行为。第四个服务原语为处理数据传输。

• TCP/IP层

通常，RDP使用TPKT作为其传输协议。TPKT在TCP上运行; 当用于传输RDP时，其默认的TCP端口是3389，而不是正常的TPKT端口102。应用程序通过RDP协议栈将数据传输到TCP/IP协议栈。通过上述的几层模型，数据被引导到通道，并进行加密，划分为预定义的部分（适合于网络协议），根据路由进行寻址、发送。在接收端，此过程反向进行，使数据可用于目标程序。TCP/IP协议栈是具体用于传输数据使用的，而RDP协议栈则是具体负责会话专用通信的。RDP协议栈将自己的会话通讯数据通过服务原语的转换，发送到TCP/IP协议栈，TCP/IP协议栈再将其按照TCP/IP封包格式进行封包、路由、寻址和传送。

以TCP/IP层为标志，我们就可以将RDP协议栈细分为传输协议（TCP/IP）部分和会话专用通信协议（RDP）部分。严格意义上来说，RDP协议栈就只包含我们上述所说的应用层、安全层、MCS层以及ISO层。TCP/IP层是一个通用的层。其在该层都会添加IP包头以及TCP包头。因此整个RDP协议栈广义上，其数据包格式组成就如下图所示：

这个数据包格式和TCP/IP的封包过程类型，首先数据在最开始的时候添加的是RDP头部，再往下，添加安全头部、MCS头部以及ISO头部，最后传递给TCP/IP进行标准的TCP头部封包以及IP头部封包。在接收端，其拆包过程正好与其相反。

四、RDP协议的连接流程

下面介绍RDP协议连接操作流程以及排序信息：

RDP协议连接序列的目标是交换客户端和服务器的设置，并协商在连接期间所使用的公共设置，以便可以在客户端和服务器之间交换和处理输入、图形和其他数据。RDP协议连接顺序如下图所示。此图中的所有消息交换都严格按照顺序进行。

图：远程桌面协议（RDP）连接顺序

连接顺序可以分为十个不同的阶段：

1. ConnectionInitiation(连接初始化)：客户端通过向服务器发送Class 0 X.224 ConnectionRequest PDU启动连接请求。服务器使用Class 0 X.224Connection Confirm PDU进行响应。

重点：在这之后，客户端和服务器之间发送的所有后续数据都被包裹在X.224数据协议数据单元（PDU）中。

其中，X.224：用于提供连接模式传输服务的协议，X.224根据下层网络的不同质量，规定了五个协议等级(从Class 0到Class 4)，RDP中采用Class 0 X.224，Class 0 X.224提供最简单类型的传输连接并且不提供任何的差错恢复机制。

2. BasicSettings Exchange(交换基本设置)：通过使用MCS Connect Initial PDU和MCS Connect Response PDU在客户端和服务器之间交换基本设置。连接初始化PDU包含通用会议控制（GCC）会议创建请求，而连接响应PDU包含GCC会议创建响应。GCC的全称是 Generic Conference Control。GCC 作为 T.124 的标准协议，用于连续传输大量数据时，将数据整理分块传输。RDP 的 MCS 层总与 GCC 紧密结合，保障了 RDP 连接初始阶段客户端与服务端大量数据交换的稳定性。比如在交换基本设置的这个阶段，这两个GCC 的包便包含了客户端和服务端的大量设置信息的数据块（例如核心数据，安全数据和网络数据）。

多点通信服务（MCS）：ITU T.120标准，是[T122]和[T125]定义的数据传输协议和服务集合。

图：MCS连接初始化PDU

图：MCS连接响应PDU

3. Channel Connection（通道连接）：基本连接建立成功之后，客户端向服务器端发送一个MCS Erect Domain Request PDU，然后紧接着再发送一个MCS Attach User Request PDU，该包附上了MCS域的用户身份标识。服务端收到这两个包之后，回复一个MCS Attach User Confirm PDU进行响应，该PDU包括用户通道ID号。然后，客户端根据得到的通道ID号加入用户虚拟通道；这个通信过程完成之后，经过客户端依次分别发送每个虚拟通道的请求PDU、服务端依次回复虚拟通道应答包后，客户端就可以继续的加入到了输入/输出（I/O）通道和所有静态虚拟通道（I/O和其他静态虚拟通道ID都是从GCC包中的数据信息中获得的）。客户端使用多个MCS Channel Join Request PDUs发起加入通道的请求。服务器使用MCS Channel Join Confirm PDU确认客户端加入的每个通道。（备注：在RDP 4.0,5.0,5.1,5.2,6.0,6.1,7.0,7.1和8.0客户端版本中只有在接收到先前发送的请求的通道加入确认之后才向服务器发送后续通道加入请求，而RDP 8.1,10.0和10.1客户端在单个批处理中会一次性将所有通道加入请求发送到服务器，从而加快总连接顺序时间）。

从这一点开始，从客户端发送到服务器的所有后续数据都被包裹在MCS Send Data Request PDU中，而从服务器发送到客户端的数据被包裹在MCS Send Data Indication PDU中。这是除了由X.224数据PDU包装的数据之外的数据信息。

4. RDP SecurityCommencement（RDP安全初始化）：如果正在使用标准RDP安全机制并且加密有效（这通过检查嵌入在GCC会议创建响应分组中的数据参数来确定），则客户端发送Security ExchangePDU（包含加密的32字节随机数）到服务器。该随机数用服务器的公钥加密（服务器的公钥和服务器生成的一个32字节的随机数都是从嵌入在GCC会议创建的数据参数中获得的）。然后，客户端和服务器利用这两个32字节的随机数生成会话密钥，用于加密和验证后续RDP流量的完整性。一旦加密机制启动，那么接下来的 RDP 通信包中都必须包含一个加密安全头。这个安全头紧跟 X.224 包头和 MCS 包头，它用来标示之后的通信数据是否被加密（虽然客户端到服务端的通信数据必须被加密，但是服务端至客户端的通信数据不一定被加密）。

5. SecureSettings Exchange（交换安全设置数据）：通过使用Client Info PDU将客户端安全数据（例如用户名，密码和自动重新连接cookie）发送到服务器。该 PDU一般是在经过 RDP 安全设置交换之后发送，如果在低安全级别的 RDP 连接中缺省安全设置交换环节的话，客户端信息 PDU 一般在所有的虚拟通道建立之后发出。

6. OptionalConnect-Time Auto-Detection（可选的连接时自动检测）：在可选的连接时自动检测阶段，目标是确定网络的特性，例如往返延迟时间和服务器与客户端之间的链路的带宽质量。这是通过在预定时间段内交换具有足够多数据的PDU的集合来确保所检测的结果。

7. Licensing（许可证）：许可阶段需要进行许可检查和交换。许可交换的目的是将许可从服务器传送到客户端。客户端存储此许可证，并在后续连接时将许可证发送到服务器进行验证。但是，在某些情况下，客户端无法颁发许可证来存储。实际上，在协议的这个阶段期间交换的PDU取决于服务器采用的许可机制。有关在许可阶段发生的更高级许可方案的详细信息，我们在后面单独讲解。

8. OptionalMultitransport Bootstrapping（可选多传输引导）：在连接安全并且许可阶段运行完成后，服务器可以选择启动多传输连接（后续讲解）。如果启动多传输连接，那么服务器会发生一个Multitransport Request PDU到客户端，客户端就会使用来自RDP-UDP，TLS，DTLS和多传输协议的消息进行带外创建多个传输连接。如果无法建立多传输连接或服务器在服务器多传输通道数据中只支持软同步，则客户端向服务器发送Multitransport Response PDU进行回应。

9. CapabilitiesExchange（交换功能）：服务器在DemandActive PDU中将他所支持的一组功能发送给客户端。接着可能会继续发送一个Monitor Layout PDU道客户端（该PDU是可选的）。客户端通过发送Demand Active PDU（包含客户端的功能）来和服务器进行确认。通过这两次的相互交换，双方都知道了对方都有哪些功能或者支持哪些功能。

10. ConnectionFinalization（连接完成）：在这一阶段，客户端和服务器端需要多次交换 PDU来完成整个 RDP 连接的细节。在这一阶段客户端发送至服务端的 PDU 不受服务端发送至客户端的 PDU 影响或干扰。以下下几个 PDU 由客户端顺序发送给服务器端：

• 在发送确认活动PDU之后发送客户端同步PDU。
• 在发送客户端同步PDU之后发送客户端控制（协同）PDU。
• 在发送客户端控制（协同）PDU之后发送客户端控制（请求控制）PDU。
• 在发送客户端控制（请求控制）PDU之后发送持久性密钥列表PDU(可选)。
• 在发送持久性密钥列表PDU之后发送字体列表PDU，或者如果未发送持久性密钥列表PDU，则在发送客户端控制（请求控制）PDU之后发送字体列表PDU。

服务端在该阶段收到客户端发送的 PDU 后，分别回复相应的应答包。

• 在接收到客户端确认活动PDU之后发送服务器同步PDU以进行响应。
• 在接收到客户端控制（协同）PDU之后发送服务器控制（协同）PDU以进行响应。
• 在接收到客户端控制（请求控制）PDU之后服务器控制（授权控制）PDU以进行响应。
• 在接收到客户端字体列表PDU之后发送服务器字体映射PDU以进行响应。

至此，整个 RDP 连接的初始化工作就完成了，但是微软为了提高远程桌面的效率以及反映速度，RDP 的控制信息通信以及图像信息通信工作在 RDP 连接建立的末端还未结束是就已经开始了。其表现在：一旦客户端发送了确认活动PDU，它就可以开始向服务器发送鼠标和键盘输入，并且在接收到字体列表PDU时，服务器可以开始向客户端发送图形输出。

除了输入和图形数据之外，在连接已经完成之后可以在客户端和服务器之间交换的其他数据，包括连接管理信息和虚拟通道消息（在客户端插件和服务器端应用之间交换）。

后续将会介绍RDP协议的一系列虚拟通道技术，欢迎关注：