第1章引言
1.1研究背景和意义
原本桌面环境下，因为用户信息都存放在本地PC，所以内部泄密漏洞较多，此外会受到多种网络攻击，进而造成数据缺失。云接入桌面环境下，终端和信息彼此分割，本地终端仅仅是显示设施，不具备储存功能，因此全部桌面数据都汇聚在公司数据库，不需要害怕公司智力资产泄密。此外，TC认证连接、加密传送等安全制度，确保云接入桌面系统的稳定性。
原本桌面系统问题频发，根据研究，一般400台PC机就需要专业IT人员负责维修，此外不同PC维护环节（问题申报->安排人员维护->问题定位->开展维护）一般需要2到4小时。在云接入桌面环境中，可确保资源自主管理，维护简单便利，节约IT资源。
此外，节约资源、没有噪音的TC部署，可以在一定程度上处理密集办公环境的温度与噪音难题。TC让办公室噪音从五十分贝下降到十分贝，环境更加适合工作。TC与液晶显示器的综合功耗大概是60W，终端低损耗能有高效减少降温成本。此外云接入桌面处理方案具备安装便利、部署效率高的优势。在顾客现场，需要服务器上电，开展云接入桌面软件的向导式装置，联系网络且开展有关业务配置就能顺利开展业务发放，在一定程度上提升效率。
1.2国内外研究现状
1.2.1国外研究现状
在目前国外云接入领域的关键技术主要是桌面云的接入协议技术，目前业界知名的有微软的RDP协议、思杰的ICA、红帽的Spice协议（接入协议关键技术并非仅指通信协议本身，还包括协议服务器端的实现与客户端的实现）。桌面协议包括具体的远程显示、远程控制、远程音频、远程外设等关键技术，由于目前桌面云主要应用的操作系统基本都是微软的Windows操作系统，所以以上桌面交付协议也是针对Windows系统的显示、外设、音频等功能设计的。
1.2.2国内研究现状
国内生产桌面云解决方案的厂家有华为Fusion Cloud、深信服aDesk等，其中系统架构大同小异，但是交付协议有着一定的不同，但是其主要的设计目标均是在尽量低的网络占用下，提供尽可能好的客户体验，其中主流厂家均可以在1Mbps的网络占用下提供稳定的服务。几乎所有的解决方案均包含瘦终端（TC），本设计就是在以树莓派作为瘦终端进行开发，设计客户端以及服务器端软件，实现主要功能。
1.3主要内容和工作安排
本文主要划分成五方面
第一部分叙述文章背景、对各个国家有关远程桌面客户端发展情况开展分析，研究部分具备典型性的远程桌面客户端的作用，功能和问题，和对本文内容和结构开展科学筹划；
第二部分是理论研究，基于设计目标中提出的几点要求进行分析，找到可行的解决办法，并对各种办法进行分析。
第三部分为设计目标的具体实现，在对设计目标的分析中找到行之有效的解决方案，且开展代码编写，对实现时期的主要技术难点和处理方式开展叙述。
第四部分是测试环境搭建，结束代码的编写后，需要装机测试以检测各个功能是否与预期运行情况相符，因此进行测试环境的搭建。
第五部分为具体测试，本部分对交付协议的各个功能模块进行了单独、整体测试，保证了代码运行与预期情况相符合，并针对测试中出现的瑕疵进行调整，或重写。
最后一部分为总结与展望。
第2章桌面云交付协议原理
2.1远程显示
桌面云交付协议中的远程显示技术在表面上是个较为简单的技术，通过操作系统接口来抓取屏幕内容，在经过一定的压缩处理即可在客户端显示服务器端的屏幕内容。
我们需要远程看到显示的内容，就好像将PC的显示器拉到远端一样，通常Windows操作系统中计算机屏幕显示需要有图形接口、Windows图形子系统、Windows图形驱动交互接口、Windows显示驱动和显卡显示器多方面构成，参考图2.1内容。
交付协议的远程显示中，显然缺失了“Windows显示驱动”这一部分，所以，如果将“Windows显示驱动”发往显卡的数据传输至瘦终端上的显卡上，即可达到远程显示的效果。目前，业界的实现通常会为运行在虚拟化平台中的虚拟机安装一个远程虚拟显示驱动，通过虚拟显示驱动来高性能地获取显示的图形指令数据，并将这些数据传送到远程客户机进行显示。通常应用程序会通过Windows平台提供接口来绘图，这些图形接口调用会通过Windows图形子系统的转换来调用到虚拟显示驱动中（这些图形接口调用我们暂且称为图形指令），图形指令内部的参数描述了图形程序的具体显示，这些数据可以被传输到远程客户端进行重新绘制显示。如图2.2
然而如果传输未经压缩的RGB图像，服务器端获取的图像将非常巨大，树莓派内置的100MBps网卡是远远不够的，所以需要加入许多优化处理，通常采用对图像进行有损压缩以及通过缓存来监视服务与客户端之间的冗余数据交换的方式，在本设计中，将采取通过Win32API抓取Windows操作系统实时显示的画面，并对抓取到的图像以位图、颜色缓存的方式来发送到客户端中，以降低对带宽的需求。
2.2外设重定向
在通用系统上，常用的外设种类有USB外设、并口外设、串口外设等，目前来看USB外设占据主流，解决USB外设的支持即可满足目前最为流行的外设硬件支持。实现该部分功能需要认识目前传统USB外设工作的原理。
参考图2.3内容，全部USB外设的一般任务在软件部分依靠USB总线驱动。应用需要采用USB外设需要和USB设施驱动开展交互，其中后者工作全部依靠USB总线驱动来交互设施数据，和硬件的交互全部由总线驱动来负责。从USB总线驱动着手是软件层面最科学的模式，把USB总线驱动和硬件交互远程化，转化为本地USB总线驱动与远程客户机USB硬件总线的交互。如图2.4.
利用在虚拟机内部完成虚拟USB总线驱动能和客户端硬件设施开展通信交互，交互并非直接通信，此时要在客户端内增设虚拟USB设施驱动，利用虚拟化USB设备驱动和客户机的USB总线驱动完成交互。在出现设施插入时，后者会出现新设备进入，此刻启动虚拟化USB设备驱动的实例，假如出现众多设施需要被同时定向时，需要众多虚拟USB设备驱动实例开始运作。而设施对照的真实USB设备驱动安装且运作在虚拟机内，和其USB总线驱动完成交互，如此对虚拟机内USB设备驱动来说不存在较大感知，对应用程序也没有太大感知，原因是，远程的这种数据交互会带来延时，有些设备驱动在设计的时候考虑了一些超时的处理。所以这种方法能够很好地支持各种外设。
2.3音频处理
通常桌面协议服务器端可以在虚拟机里面实现一个音频驱动，音频驱动会与Windows的音频子系统（音频引擎）进行交互。在放音阶段，音频驱动将收到Windows音频子系统发送过来的音频数据，经过压缩处理后传输到桌面云客户端，客户端进行解码并进行放音。在录音阶段，客户端将获取客户端本地的录音数据，并将数据进行压缩后传输到服务器端，服务器端进行解码后由音频驱动返回给Windows音频子系统。
2.4本章小结
此协议旨在通过将图形显示信息从远程计算机传输到用户,并将输入命令从用户传输到远程计算机来方便用户与远程计算机系统的交互,其中输入命令在远程计算机内重播。上述协议也供应可扩展的传输制度,可以在用户与远程计算机上运作的组件之间开展单独通信。
第3章桌面云交付协议设计
3.1协议连接序列
由于服务器端和客户端需要交换交换如图形信息、外设信息以及音频信息，为了确保上述几种数据能在服务器端以及客户端进行有效地交换，所以在本设计中，服务器端与客户端的信息交换都需要按照图3.1所示的方法进行通信，
整个连接序列可以分为8个阶段
1）连接初始化：客户端通过发放Class 0 x.224连接请求数据包来开启操作。响应Class 0 x.224连接确认数据包。从这一点来说,在客户端和服务器之间发送的所有后续数据都被封装x.224数据协议数据包中。
2）基本设置信息交换：通过使用MCS连接初始化数据包和MCS连接响应数据包,在客户端和服务器之间交换基本设置。连接初始数据包中含有一个GCC（Generic Conference Control下同）创建请求,而连接响应数据包中含有GCC创建响应。这两个GCC数据包包含的设置数据(如核心数据、安全数据和网络数据)可由客户端以及服务器端读取。
3）通道连接过程：在基本设置信息交换完成后，客户端会向服务器端发送一个MCS建立域的请求链接，并发送一个MCS附加用户请求包，这个数据包同时带有MCS域的用户ID。当服务器端收到此二者后，将恢复一个MCS附加用户响应数据包，上述数据包涵盖用户通道的ID号。此通信过程结束后，通过客户端按照顺序发送到所有虚拟通道的请求数据包、服务端按照顺序回复虚拟通道应答包之后，客户端就顺利进入用户、输入输出和全部静态虚拟通道。
RDP安全初始化：假设RDP安全加密机制被开启(主要和GCC会议
创建请求包内参数相关)，此时客户端可以发送相关数据包到其他部分，其中主要包含加密后32字节随机数。上述数和加密公钥主要从使用原本得到的GCC会议创建应答包内嵌入的数据包。上述环节结束之后，两者使用上述32位的加密后的随机数来形成会话密钥，进而加密和解密双方RDP通信信息。假如加密制度实施，此时RDP通信包内涵盖加密安全头，随后跟随X.224与MCS包头，主要是标示此后的通信数据是否被加密(即便客户端到服务端的通信数据需要被加密，然而反过来的通信信息不需要全部加密)。
4）安全设置数据交换:安全信息，主要包含用户名、密码与自动连接Cookie等利用客户端数据包发放到其他部分。上述数据包通常经过RDP安全设置交换以后下发，假如在低安全等级的RDP连接内缺少安全设置交换过程，此部分信息数据包通常在全部虚拟通道创建后发出。
5）证书发放阶段:证书交换主要目标是从服务端向客户端发送单个证书。客户端存放上述证书，然而在很多时候(安全等级设置不高)客户端也许不需要也缺少证书能被接收与存放。实际上、证书传播时期主要由服务端是否加载且采用认证组织来确定。所以上述时期是否需要和安全等级需求相关。
6）功能需求信息置换:服务端利用主要功能需求数据包发放一个它可以支持的功能汇聚到客户端;在其得到之后应答包含全部求功能集合的具体确认数据包回来。接下来全面研究上述需求和确认数据包的具体构造。
7）RDP连接完成时期:在此时期，客户端与服务器端要数次交换数据包来完成所有RDP连接的细节。在此时期客户端发送到服务端的数据包不会受到其他数据包的波及或者影响。接下来数据包需要按照顺序下发。
3.2图像显示
3.2.1绘图数据生成
服务端得到PDU最先进行相应整合操作后，得出RDP内容信息，进而通过下图流程对其开展解压，分类等操作，得到具体绘图信息。
在经过处理取得RDP内容以后，最先依照头部字段判定具体数据种类，之后根据压缩情况判定具体状态，假如需要的话，要提前解压，之后进入后续流程，假如不存在被压缩问题，可以马上进入后续流程，也就是参考Type字段的值来判定此数据块的具体类型。假如是窗口类型数据块，需要进入对应的处理流程得出相关信息，且开展参数更新；假如是图像更新类数据，就需要进行相应处理，利用update Type数值来判定具体情况，假如是位图更新数据就要进入位图更新数据处理环节，得出位图数据；假如是Palette更新数据就需要步入Palette更新数据环节得到绘图命令数据。上述过程所得出的绘图命令信息与位图信息是关键的部分。绘图命令数据需要让对应的处理模块负责，位图信息需要让对应的模块处负责。
图3.2绘图数据生成流程图
3.2.2绘图命令数据处理
从上一时期得出绘图命令数据以后，利用命令数据的order_type类型可判定命令种类，之后划分多种类，寻找合适的处理方式，具体处理环节参考3.3内容。
假如其是order命令数据，那么后续环节相对简洁，需要依照order命令的类型调用多种接口开展图像绘制。假如是secondary命令数据，就代表上述数据块的数据在处理后要存放到对照的缓存区，而并给马上播放。处理secondary命令的环节为：
（1）第一判定secondary命令的具体种类，假如是位图存储命令数据就要进入第二步，假如是字体图像存储命令数据就进入第三步。
（2）对上述命令数据开展整合，得到位图参数与信息，之后得到对应的存储位图数据的缓存索引，此后参考此位图信息压缩情况，没有压缩的在处理后存放到相应缓存，假如压缩，就要提前进行解压，此后把其存放到特定的缓存。
（3）对字体图像存储命令数据需要得到字具体参数，之后参考长度字段得出实际数据情况，且得到字体图像数据。此后得出对应缓存，把得到的参数和数据进行缓存。
3.2.3位图数据处理流程设计
位图数据是桌面图片呈现的关键方面，主题呈现也需要依靠其的帮助。此类数据处理详情参考图3.4内容。最先依照数据块num_updates标志位的值统计出需要替换的所有数目。此处图数据代表单个长方形显示块，主要包含起始位置的具体坐标（左上角），宽、高和压缩参数等。之后进入处理循环的实际时期，全部结束条件设定是处理次数超过num_updates。循环内按照顺序读取位图参数的数据，判定压缩状态，假如没有就能得到最初数据，假如被压缩需要提前解压得出原本的位图内容。
3.2.3显示模块
显示模块是rdp的重要呈现模块，其包含显示初始化和更新作用。因为rdp远程桌面需要和远程主机完成彼此交互，所以桌面更新也需要实时呈现在rdp桌面上，上述功能完成的逻辑处理模块需要让C/C++代码负责，其中桌面显示信息的接收与缓存需要让C语言完成的底层数据处理模块来负责。此方式一般代码为：
{
HDC hdc;
int negHeight;
HBITMAP bitmap;
BITMAPINFO bmi;
BYTE*cdata=NULL;
UINT32 dstFormat=srcFormat;
negHeight=(height<0)?height:height*(-1);
hdc=GetDC(NULL);
bmi.bmiHeader.biSize=sizeof(BITMAPINFO);
bmi.bmiHeader.biWidth=width;
bmi.bmiHeader.biHeight=negHeight;
bmi.bmiHeader.biPlanes=1;
bmi.bmiHeader.biBitCount=GetBitsPerPixel(dstFormat);
bmi.bmiHeader.biCompression=BI_RGB;
bitmap=CreateDIBSection(hdc,&bmi,DIB_RGB_COLORS,(void**)&cdata,NULL,0);
if(data)
freerdp_image_copy(cdata,dstFormat,0,0,0,width,height,data,srcFormat,0,
0,0,&wfc->context.gdi->palette,FREERDP_FLIP_NONE);
if(pdata)
*pdata=cdata;
ReleaseDC(NULL,hdc);
GdiFlush();
return bitmap;
}
调用其就能调用C功能函数内的更新图片函数，其可以得到Bitmap类的地址且修改具体信息。此部分更新桌面显示图片只更新过的部分内容，主要参数是（x,y,x+width,y+height），也就是要更新部分是（x，y）坐标是左上角起点，长为是width宽是height的地区。因此，假如要按时更新桌面内容，则需要调用GDI绘图来完成，代码如下：
void wf_gdi_register_update_callbacks(rdpUpdate*update)
{
rdpPrimaryUpdate*primary=update->primary;
update->Palette=wf_gdi_palette_update;
update->SetBounds=wf_gdi_set_bounds;
primary->DstBlt=wf_gdi_dstblt;
primary->PatBlt=wf_gdi_patblt;
primary->ScrBlt=wf_gdi_scrblt;
primary->OpaqueRect=wf_gdi_opaque_rect;
primary->MultiOpaqueRect=wf_gdi_multi_opaque_rect;
primary->LineTo=wf_gdi_line_to;
primary->Polyline=wf_gdi_polyline;
primary->MemBlt=wf_gdi_memblt;
primary->Mem3Blt=wf_gdi_mem3blt;
update->SurfaceFrameMarker=wf_gdi_surface_frame_marker;
}
void wf_update_canvas_diff(wfContext*wfc)
{
RECT rc_client,rc_wnd;
int dx,dy;
GetClientRect(wfc->hwnd,&rc_client);
GetWindowRect(wfc->hwnd,&rc_wnd);
dx=(rc_wnd.right-rc_wnd.left)-rc_client.right;
dy=(rc_wnd.bottom-rc_wnd.top)-rc_client.bottom;
if(!wfc->disablewindowtracking)
{
wfc->diff.x=dx;
wfc->diff.y=dy;
}
}
到现在，图像显示模块就全面完成，利用部分更新形式高效提升整体反应效率，促使用户可以感知到的延迟变小，尤其是在4G网络与Internet网络条件下，上述优点被充分体现。
3.3RDP协议设计
RDP协议遵从T.120协议要求，可以完成T.128应用程序多点共享制度。此部分需要涵盖用户态与内核态两部分模块，上述层次也具备部分MCS功能。RDP在用户态完成RDP扩展协议，RDPWSX负责接收与处置源自客户端的报文信息。登陆处理(Winlogon)、会话管理器（SMSS）与运行时服务(Csrss.exe)模块全部在用户态被调用。RDP在内核态的执行包含TERMDD（终端服务器设施驱动）、RDPWD（控制台驱动设施）和TDTCP等众多部分，也具有设施驱动、虚拟通道通信、图形显示等多部分作用。在Windows 7中某个被叫做终端服务(termsrv.exe)的进程管理服务。此部分一般功能涵盖会话监管、初始化、暂停与事件告知。
用户会话空间涵盖内核态和用户态两方面，前者位于MultiWin子系统内，其是众多用户会话映射WIN32K.SYS设施驱动子系统与RDP显示设施驱动模块，后者映射Win32子系统。
会话连接具体过程是：RDP系统监听源自TCP 3389端口的对应客户求报文，TCP/IP上交连接请求给予TERMDD模块负责，之后把请求转移给RDPWSX模块，让对应请求终端服务进程建设单个线程来服务相关请求，用户会话空间的映射主要被终端服务进程负责。RDP协议收发信息的操作环节遵从OSI七层协议模型。从应用程序传播的信息目前主要通过多个环节进行处理，在MCS控制下经过多重操作，被打包到网络层协议，最后被寻址传送给最终的部分。返回数据根据实际顺序被处理，去除包头，解密一直到上交数据转移给应用程序操作。RDP协议的一般是处理OSI协议族的第四到七层，数据基于顺序被进行多种操作，最终完成传输任务。RDP报文数据主要是键盘输入等多个部分。
3.3.1 RDP程序模块
RDP客户端的设计一般被划分成两方面，主要是RDP程序模块，客户端底层设计模块。
前者一般实现RDP协议；后者利用设计和调节Linux系统，让程序与网算机硬件平台整合在一起，促使彼此间可以无障碍融合和使用。RDP程序一般包含两部分，彼此间留存接口。RDP协议模块一般解析内部协议，和具体平台之间没有关系；GUI模块一般管理图形显示和鼠标内容传播，和具体平台也没有任何关系。图3.5是详细结构图。
RDP程序实施之后，主要从配置文件内选取服务器IP地址，本机IP地址等参数，之后联系服务器，在全面连接之后，创建窗口，下载登陆界面，之后步入窗口消息循环，程序只负责鼠标、键盘指令，处理传播的RDP数据。参考RDP协议的层次结构把所有模块分类成TCP层、ISO层、MCS层、SEC层、RDP层。主要是文件tcp.c、iso.c、mcs.c、sec.c、rdp.c来完成。按照功能分类，能分类成RDP会话连接、数据传送和解析、RDP数据整合和上传。
1）RDP会话连接
在RDP协议所有层内均涵盖connect与disconnect函数，创建连接从TCP层着手，之后到RDP层，断开连接的方式也不一样。TCP连接最先采用Linux的API函数Socket建设套接字，此后使用connect函数和服务器确定联系。必须在此部分顺利结束之后，才可以开展ISO连接。
ISO连接：在顺利连接之后，向服务器发放connect请求，在得到connect的comfirm，ISO顺利连接，假如不顺利，调用tcp_disconnect()断开连接。
MCS连接：在ISO顺利连接之后，开始发放mcs请求，必须依次得到多种想要的响应，mcs连接才顺利完结，假如无法顺利完结，把调用iso_disconnect()断开以往连接。连接顺利之后会在创建需要使用的虚拟通道。SEC连接：在MCS顺利连接后，可以得出想要的部分信息，继而处理上述得到的内容。
RDP连接：在SEC顺利连接后，向服务器发放登陆信息包（login_info_packet）。服务器会返回单个demandactivePDU，客户端得到次数据单元之后，开展众多性能设定（包含位图与定制数据和多种缓存等）。
2）RDP数据接受与解析
在和服务器创建连接之后，会创建窗口。Microwwindows提供select制度，把套接字描述符增加到窗口消息循环序列内，在套接字描述符上等到数据接收事件的形成。在开始窗口消循环之后，假如得到服务器传播信息，Microwindows会发送单个窗口指令，在相关消息处理函数内进行相应操作。上述过程一般负责接受tcp数据流，且开始解析，向其他部分传送。最终RDP层得出对应的数据流。
3）RDP数据处理
通过接收、解析服务器下载的信息，得出RDP数据单元，对上述内容进行分类开展科学处理，确保清晰的桌面显示。RDP数据类型一般涵盖鼠标光标、更新和铃声等种类。此处更新数据主要是位图、定制、调色板等信息。定制数据主要是主定制和辅定制两类。
鼠标光标数据一般是POINTER_MOVE、PINTER_COLOR等，对应处理是移动、新建等相关数据存储在缓冲区。RDP协议5.1颜色只支持256色，也就是上述颜色内16位色，桌面显示以将以上颜色当做前提。在正式开启时，直接下载调色板，通过全局形式存放；在桌面颜色变动明显的时候，会传播到全新的调色板。得到全新调色板，覆盖之前的调色板。
位图数据比划分成非压缩与压缩两部分，大多数是后者，要提前进行解缩。位图数据没有调色板，应有之前需要下载。
主定制数据涵盖DestinatonBlt、Frame、Line、DesktopSAve、MemoryBlt等多种类，主要处理方式是调用对照GUI函数。辅定制数据涵盖ColorCache、fontCache、BitmapCache等种类。在具体结构上，定制数据类型更多，把其处理放到orders.c内；图形显示内容主要放在mwin.c内，缓存放到cache.c内。
4.）数据上传
上传数据一般包含鼠标，键盘数据和更新区域等。传送与接收存在一定的差异，按照顺利，加密，打包，之后利用RDP协议进行传送。
在客户端，假如出现鼠标点击，键盘操作等行为时，系统Linux主要利用驱动完成响应，Microwindows会在上述前提下妥善处理，变成发送消息。需要在消息处理程序内将上述消息数据传送给服务器处理。
3.3.2客户端底层模块设计
RDP客户端模块主要包含两个单独程序，Rdplog管理界面与处理用户配置，mw是RdP客户端程序。在脚本rdp内循环使用上述单独程序，促使用户所了解具体情况和页面内容，能从界面点击图标开启所需程序。在启动脚本/etc/rc.d/rc.sysinit中随之开启rdp脚本。启动流程如图3.6所示。
3.4频处理模块设计
在音频压缩部分，通常将音频划分成两种，也就是语音与音乐。前者具备频谱窄，能量汇聚在中频的特征，其中音乐的频谱更宽，此外高频与低频内容对音乐影响具备关键功能，不能随便舍弃。因为上述音频具有多种频谱特征，此外用户对其压缩编码的质量标准各不相同，所以通常使用多种编码方式。一般使用音乐编码方式是MP3(MPEG1audio,layer3)，AAC(MPEG2audio)，WMA等，普遍使用的语音编码方式是G.711，G.723，G.729，G.726等。评估某个编码器的功能一般使用压缩比，时延，时间复杂度，采样率等标准。充分思考语音质量和CPU占用率，其还能支持G.711和G.729两类方式。
在多媒体传输部分，采用RTP(Real-timeTransportProtocol)是开展音视频传输的主要方式。然而，在很多特定使用场合。TCP具备较好的传送效果。此刻，采用RTP就可以得到繁琐的程序设计。本文完成远程桌面系统一般依靠的网络环境很好，此外思考音频占据带宽比值不高和具体设计的简洁性，所以使用TCP当做最佳传送方式。
在服务器和客户端协调好音频传输端口号和具体编码方式之后，前者会自主连接后者开放的TCP端口，完成音频传送。在两者创建TCP连接以后，就可以进入音频传输服务环节，参考图3.7内容。
总结与展望
主要工作与创新点
在互联网高速发展的今天，新型号的硬件令大家目不暇接，然而硬件性能的逐渐增长并没有给IT行业传统办公带来过多的变革，反而使企业的硬件更新成本和TCO（Total Cost of Ownership，总体拥有成本）大幅提高，而且拥有强大的硬件并不一定代表拥有更强的生产力，所以提升硬件利用率是势在必行的。本设计基于树莓派开发了一套桌面云远程桌面交付协议，实现了“云主机+瘦终端”的交付模式，其功耗更小、硬件利用率更高且本地不储存数据，所有数据均在云主机中，安全性上也能得到保证。
比如本文重要任务与创新点为：
1)重点分析各国远程与移动远程桌面客户端的实际发展现情况，研究内容主要是具有典型意义的远程桌面客户端运作状况、水平、效果与不足。为未来此领域发展提供借鉴，且了解其优势与不足。之后，对系统研发中采用的非开源RDP协议开展分析和数据整理，且对RDP的工作流程开展研究。研究不同流程相关的数据报文的结构。为未来发展奠定良好的准备。
2）在奠定良好基础之后，参考同类型其余软件的优势和缺点、和基于用户发展对系统功能与效果开展研究，对具体功能需求开展研究，且在功能需求研究的前提下对性能需求开展解析。之后对具体功能分模块开展整合，为未来的系统综合设计奠定良好的准备。
3）在需求研究之后，对综合工作流程开展设计，之后参考具体工作环节，把系统划分成底层数据处理、连接功能模块等多个模块。且主要对不同模块开展全面的论述与研究。此处参考以往对RDP的数据研究活动设计RDP连接时期的关键数据结构，且对控制模块的信息怎样封装也提出相应要求，为未来顺利实现奠定良好基础。
4）在之前对系统多个模块功能进行设计的前提下，确定发展方向，开始代码编写，对所有功能模块进行设计，对实现时期的关键技术难点和处理方式进行叙述。
5）最终对系统所有功能模块与功能开展实验。
后续研究工作展望
本设计对基于树莓派的远程桌面交付协议进行了详细的研究，而且实现了完整的远程显示、远程音频以及远程控制功能。但是时间比较伧俗，代码比较粗糙，在很多地方都有待完善的地方。
1）桌面显示效果不能与真机显示向媲美，为了降低网络占用，客户端中的画面不是整幅刷新，而是逐块刷新，这样就会偶尔造成画面撕裂、不同步的情况。而且客户机使用16位的即256色的颜色输出，个别情况写颜色会存在失真的问题。后期准备通过LZX压缩的方式来进行解决。
2）在代码基础上，本系统实现代码也需要相应的改善。利用改善，也许能让系统功能更好。此外，降低代码耦合性是目前需要处理的问题，如此就可以让未来增加新功能变得更便利。
3）在功能部分，本设计只能实现远程办公、网页浏览等轻度使用功能。而对游戏、专业图形工作等需要GPU支持的场景无能为力，后期若需实现上述功能，需要添加GPU虚拟化技术或者GPU直通功能。
参考文献
[1]王建.远程桌面控制协议研究与实现[D].电子科技大学，2006.
[2]罗劢.基于RDP协议的安全方案研究与实现[D].电子科技大学，2012.
[3]顾炯炯.云计算架构技术与实践[M].清华大学出版社,2016.
[4]姜凯.桌面虚拟化实战宝典[M].电子工业出版社,2014.
[5]刘凡.基于嵌入式Linux的远程桌面技术研究及实现[D].华中科技大学，2011.
[6]Microsoft,RemoteDesktopProtocolFeaturesandPerfor-manceWhitePaper,2000.6.
[7]NetworkWorkingGroup,RFC905ITUISO,1984.4
[8]MicrosoftCorporation.RemoteDesktopProtocol:BasicConnectivityandGraphicsRemotingSpecification[S].Washington:MicrosoftCorporation.2009.
下载提示：
1、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“文章版权申述”（推荐），也可以打举报电话：18735597641(电话支持时间：9:00-18:30)。
2、网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。
3、本站所有内容均由合作方或网友投稿，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务。
原创文章，作者：写文章小能手，如若转载，请注明出处：https://www.447766.cn/chachong/14473.html,
