关于rdp的一些简单明了的说明,转载过来的,原文地址:

http://m.newsmth.net/article/MSDN/single/2/3

终端服务是基于ITU-T.120系列协议基础上。
RDP协议分成五层:
rdp
sec
mcs
iso
tcp
加密算法采用MD5和RC4.
连接建立前,客户端发送关于自己capacility,比如支持的RDP协议版本,颜色位数,加密级别,键盘布局,通道数以及自己的时区(Time zone).键盘和时区是国际化需要,特别是不通国家或地区的员工登陆到同一台终端服务器上,能正确处理和显示正确的时间。
2000的RDP5.0支持8位色,而winxp和2k3支持16位甚至24位色,其实,在这方面微软只是在服务器端做了扩充,然后在客户端发送新的capacility,这样服务器就会传回给客户增强的颜色。当然,传回来的位图一般都是压缩过的。对于8位色还是真彩色,解压位图的算法还遵循T.128 Page 147里说明的。真彩色仅仅是传回来的每个象素的字节数改变而已,这影响客户端的显示处理过程,并不影响解压过程。比如:8位色,客户端发送的是0xca01,当服务器端支持真彩色时,客户端又可以发送:

8位色:0xca02;

16位色:0xca03,

24位色:0xca04.
同样,客户端在发送的capacility里可以包含自己需要的virtual channel.通过virtual channel,可以实现打印、剪贴板和声音等重定向功能,甚至是驱动器映射。

连接建立后,客户端收到的是RDP_PDU_DEMAND_ACTIVE,在处理完process_demand_active后主要是处理RDP_PDU_DATA。在处理RDP_PDU_DATA中,主要是RDP_DATA_PDU_UPDATE。在RDP_DATA_PDU_UPDATE中主要是RDP_UPDATE_ORDERS、RDP_UPDATE_BITMAP、RDP_UPDATE_PALETTE。在RDP_UPDATE_ORDERS中主要是对Primary和second order的处理。Primary order是处理关于画线、屏幕保存等一些图像处理过程。Second order是辅助Primary order
提供bitmap、color、font等信息的。
RDP_UPDATE_BITMAP是解压位图,这里依据的是T.128 page 147.RDP_UPDATE_PALETTE故名思意是处理调色板更新的。
可以在不修改RDP协议基础上,通过对virtual channel的支持,实现许多新的特性。

virtual channel其实是:1)在服务器端有个DLL 2)在客户端也有相应的DLL,当然对于linux来讲,可以是普通的应用程序。当客户端需要virtual channel支持时,在连接建立前,自己的客户端特定的应用程序先行注册,设置callback等。然后再发送
一些capacility给服务器。之后服务器会装载相应的服务器端DLL,以后对于virtual channel的处理就主要是服务端的DLL和客户端的特定应用程序的事情了。
通过对virtual channel的支持,客户端可以做以前只有在服务器端才能做的事情,说不定哪天我们就可以对PDA synchronization,用不着再跑到服务器端了。当然我们也可以在客户端使用U盘了。

我正着手研究通过virtual channel的本地声音实现,欢迎交流和指正。
参考:
1) ITU-T T.120系列(它的协议是需要$的,不过国内可以找到)
2)www.rdesktop.org
3)http://www.microsoft.com/msj/1099/terminal/terminal.aspx
4)  microsoft msdn