本文共 10576 字，大约阅读时间需要 35 分钟。

4  系统各模块概述

该系统主要分为客户端与服务端两个部分。客户端通过发送相应的命令给服务端，对其进行控制与操作。服务端接受来自客户端的控制命令，并按照其命令进行操作，将操作后的结果返回给客户端，客户端就能够知道服务端的运行状态与运行结果。

4.1 服务端实现技术

4.1.1 NAT穿越实现

NAT简述，私有(保留)地址的“内部”网络通过路由器发送数据包时，私有地址被转换成合法的IP地址。一个局域网只需使用少量IP地址(甚至是1个)即可实现私有地址网络内所有计算机与Internet的通信需求。 

NAT将自动修改IP报文的源IP地址和目的IP地址，IP地址校验则在NAT处理过程中自动完成。有些应用程序将源IP地址嵌入到IP报文的数据部分中，所以还需要同时对报文进行修改，以匹配IP头中已经修改过的源IP地址。否则，网络数据就不能正常传递。

NAT穿越，由NAT介绍我们知道内网连接外网，内网的IP地址要经过转换才能与外网通信。然而外网主动连接到内网就不能实现，所以要用到NAT穿越。首先让内网主机主动连接至外网，之后才进行通信。然后由于外网主机IP地址不是固定的，所以NAT穿越实现的关键在于获取外网主机的IP地址。

可以利用两种方式来获取外网主机的IP地址。

方法一：客户端上传自己的IP地址到一个固定的FTP服务器中，服务器端就可以在这个固定的FTP空间下载客户端的IP地址，利用TCP协议主动连接至客户端程序，并将自己NAT转换后的IP和端口号告诉客户端，然后与其通信。

方法二：客户端申请空间域名，那么它的IP地址将绑定在这个域名上。内网的服务端可以通过PING操作来获取客户端的IP地址(客户端的开放端口在生成服务端的时候已经设定)，内网服务端利用TCP协议，通过已知的IP地址和端口号就可以连接客户端主机。

4.1.2 匿名管道

匿名管道的实现，管道（Pipe）实际是用于进程间通信的一段共享内存，创建管道的进程称为管道服务器，连接到一个管道的进程为管道客户机。一个进程在向管道写入数据后，另一进程就可以从管道的另一端将其读取出来。

匿名管道的应用，服务端在接收到CMD控制命令的时候，就将控制信息中携带的DOS命令保存起来并将其写入内存，服务端主机自动在后台开启CMD控制程序。CMD控制程序利用匿名管道读取内存中DOS命令并且执行相关的操作，CMD控制程序运行后将返回信息写回到内存中，服务端控制程序再从内存中读取信息，将读取到的返回信息通过TCP协议发回给客户端。图4.2为匿名管道原理图。

4.1.3 消息响应系统

本系统的远程控制是模拟windows消息响应模式来进行设计。

Windows消息机制，windows窗口的控制就是当用户对窗口进行操作的时，实际上是向该窗口发送了不同的消息。窗口根据这个接收到的消息进行响应(执行操作)，自动调用系统API函数或是执行某些特定的函数。用户不知道窗口内部是怎么样实现的，其只要知道什么样的命令可以得到什么样的结果就可以了。 

本系统首先为客户端与服务端约定了一组命令消息，以方便在客户端与服务端通信。当客户端需要操作服务端时，客户端主机就向服务端主机发送命令消息。因为事先已经约定消息，所以当服务端接收到约定的消息时就会执行相应的操作。例如：文件管理命令、服务管理命令、进程管理命令等。当服务端操作结束后再将操作结束后的信息发送给客户端，以方便客户端了解到服务端的工作情况与状态，并且在客户端中可以呈现出从服务端传来的信息。

4.2 客户端实现技术

客户端主要分为三个部分：①操作部分对服务端进行基本的操作控制；②监视部分能对服务端进行必要的监视；③配置相应的服务端，让服务端能连接客户端。见图4.3 客户端结构图。

 

4.2.1 反弹端口和IP地址自动更新

远程控制软件在运行和工作过程中，常常需要突破防火墙。另外，被控端和控制端主机常会变更IP地址。为了更加稳定地显示对远程主机的长期控制，远程控制软件在实际应用中，经常将反弹端口和IP自动更新功能放在一起使用。

反弹端口的原理，简单地说就是由木马的服务端主动连接客户端所在IP对应的计算机的80端口。相信没有哪一个防火墙会拦截这样的连接（因为防火墙一般认为这是用户在浏览网页），所以反弹端口型木马可以“穿墙”。

木马“网络神偷”出现之前，还没有反弹端口类的远程控制软件，防火墙都注重防御来自外部IP的连接。但是道高一尺，魔高一丈，不知道哪位高手分析了防火墙的特性后发现：防火墙对于连入的连接往往会进行非常严格的过滤，而对于连出的连接却疏于防范。因此出现了反弹端口型软件，如“网络神偷”。

与一般的软件相反，反弹端口型软件的服务端（被控制端）主动连接客户端(控制端)。为了隐蔽起见，客户端的端口一般开在80(提供HTTP服务端口)。这样，即使用户使用端口扫描软件检查自己的端口，发现的也是类似 “TCP UserIP：1026 ControllerIP：80 ESTABLISHED”的情况。稍微疏忽，用户就会以为是自己在浏览网页（防火墙也是会这么认为的）。

由于网络的IP地址为动态分配，那么反弹端口型软件的服务端通信就急需解决一个问题，即如何告诉服务端何时开始连接自己，自己的IP地址是多少。这就是我们要讲的IP自动更新，通过IP自动更新功能，可以使服务端得到客户端的IP地址和端口，这样就可以实现通信了。

IP自动更新的原理是：申请一个虚拟主机网站，当客户端需要与服务端建立连接时，客护端首先登陆到FTP服务器管理虚拟空间。在虚拟空间网站根目录写入一个文件，文件中包括自身的IP和端口号，这时，客户端打开端口监听，等待服务端的连接。

服务端启动后，首先会通过反弹端口到虚拟空间读取文件的内容，就会得到客户端的IP和端口，于是主动去连接客户端的IP和端口。

而客户端可以在监听的端口发现服务端连接自己，并下发各种控制指令，如此就完成了客户端和服务端的连接工作。

 下面的通过图例演示反弹端口和IP更新是如何工作的，如图4.4所示

 

由于个人计算机一般都是在局域网内，没有公网IP地址，所以不能被动连接，只能主动连接其他有公网IP地址的计算机，所以非常适合用反弹端口来连接。下面以反弹木马Peepbrowser为例，介绍在实际应用中，如何用反弹端口，打开Peepbrowser的服务器。作为客户端（要求有公网IP地址），并且开放WEB和FTP服务器。客户端通过FTP把自己的IP更新文件放到WEB服务器中。服务端启动后，可以通过访问WEB服务的index.html文件来得到新客户端所在的IP地址。通过新的IP地址就可以连接客户端了。当然还有很多优秀的国产反弹型木马，比如pcshare、灰鸽子、网络神偷、上兴远程控制、流萤、远程控制任我行等。这些反弹型木马界面各有不同，但原理都是一样的。

4.2.2 控制模块操作界面

以下界面在客户端中呈现。

该模块主要是用来显示从服务端中传回来的信息。

（1）文件管理

主要是listbox与listTree两个控件完成，listBox主要是用来显示文件信息包括：文件名、文件大小、修改时间等，listTree用来显示文件目录。如图4.5所示。 

 

（2）进程管理

主要是用到listbox控件完成，来显示进程的ID、进程的名称、进程运行的路径。如图4.6所示

 

（3）服务管理

主要使用listbox控件来实现，在listbox中可以显示服务名称、服务描述、服务状态、启动类型，如图4.7 

（4）键盘记录

主要使用textbox控件来显示记录服务端的键盘信息。如图4.8所示 

（5）CMD远程控制

利用两个textbox，一个textbox用来显示返回信息，一个textbox用来输入控制命令。如图4.9 

（6）屏幕监视

该窗口利用了一个Picture控件来显示服务端的屏幕信息，如图4.10所示 

 

4.3 控制模块

4.3.1获取服务端的信息

实现远程管理服务端计算机，首先要理解服务端计算机的配置信息，比如服务端系统版本。如果是windows2000，就适合搭建WEB等服务；如果是windwos XP ，则更多是个人计算机；如果是windows 2003，就有可能是服务器了。当然这些信息还包括内存大小、CPU的运算速度等，只有对服务端计算机各个配置信息了解清楚，才能更好地远程管理服务端。

服务端通过调用系统API可以获取到计算机名称、系统用户名、系统版本、CPU相关信息、内存大小等。将这些信息存储在一个结构体中，将这些信息发送给客户端，客户端接收到这些信息之后将其显示在界面上。

4.3.2 文件管理

文件管理功能主要实现的是预览、查看远程计算机的文件。相当于一个简单资源管理器。文件管理器的结构同windows资源管理器相仿，都是树形结构。

服务端与客户端都有两个重要的控件listbox和listTree。listTree用来显示文件目录,listbox控件主要是用来显示子文件中的文件。服务端负责枚举自己的文件目录信息，并且将其传递给客户端。当客户端接收到相应的信息后。就在listTree中显示出来，并且在客户端选中某子文件夹的时候，服务端会枚举该子文件中的所有文件并且将其以链表的形式发送给客户端。在客户端中可以观测到服务端的文件名字，该文件的大小，文件的最后修改时间等信息。

4.3.3 服务管理

服务管理子功能主要是读取远程计算机上的服务，以及各个服务的状态。了解服务状态是维护计算机的第一手资料，因为计算机被非法入侵常是被开启了某些服务，比如telnet服务。当个人计算机开启这个服务后，如果该计算机没有设置密码，或者设置的密码比较简单，别人就很容易利用telnet服务远程登录到该计算机上进行破坏。

要想对远程计算机的服务进行管理，就应该得到与服务有关的参数。这些参数包括服务名、服务描述、服务状态、服务启动类型。我们可以通过ListService函数来获得计算机的服务，将其保存在一个链式结构中，然后发送给客户端。客户端接收到该结构信息后，将接收到的结构信息呈现到客户端服务管理窗口中。

4.3.4 进程管理

进程管理是远程控制常见的的功能。通常使用计算机时，经常要用到进程管理程序。比如运行某个程序时，由于程序的BUG死掉了，这时可以通过打开windows自带的任务管理器，寻找到这个程序的进程。当然，如果某个经常占用系统资源过多，则会导致运行缓慢或者有病毒的进程，都可以通过windwos自带的任务管理器来结束进程。

首先看看windwos自带的任务管理器，打开任务管理器的步骤如下：

（1）鼠标右键windows桌面下方的任务栏，在弹出的右键菜单中选择【任务管理器】选项。

（2）在弹出的【任务管理器】窗口，点击【进程】标签，可以看到系统上正在运行的所有程序的进程，如图4.11所示

在这个进程列表中，不仅可以看到对应的程序名，同时可以看到占用CPU的百分率、开启程序的用户名、内存使用和占用的虚拟内存的大小。

（3）以上查看选项都是可以选择的。打开【查看】菜单，弹出【查看】下来菜单，选择【选择列(s)】命令，会弹出【选择列】对话框。在这个对话框中可以选择想要显示的选项。

（4）在进程列表中，可以用鼠标选择想要的结束进程。单击右下方的【结束进程】按钮，结束该程序；当然也可以在想要结束的进程上单击右键，在弹出的右键菜单中选择【结束进程】命令。

以上步骤是在windows XP 上遇到想要结束的进程做法。当服务端运行在远程计算机上，控制端想要管理服务端计算机的进程时，就显得非常困难。加入了进程管理功能就方便了。

要想制作进程管理，首先需要知道其原理，在windwos系统中保存着一个进程链表，这个链表用来保存当前运行的所有进程的信息。进程管理要得到所有的进程名，只要从这个进程链表中把所有的信息保存即可。

要得到进程链表的进程信息，首先调用函数CreateToolhelp32Snapshot,获得进程链表的句柄。然后调用ProcessFirst得到进程链表中第一个进程的信息。这些信息都保存在PROCESSENTRY32结构中。接着检查进程链表是否为空。如果链表不为空，则用函数ProcessNext获得下一个进程信息，保存到进程结构PROCESSENTRY32中。最后用列表空间将这些进程信息显示出来就可以了。

终止一个进程，首先调用OpenProcess函数获得指定函数的句柄，然后调用函数TreminateProcess结束指定的进程。

4.3.5 键盘记录

无论是DOS时代，还是windows系统时代，从windows 9x 到 windows 2000，再到windows XP、windows 2003，键盘总是计算机要用到的设备。在以上的任何一个时期，自从有了远程控制软件，键盘记录功能就都包含在远程控制软件的功能中。

键盘记录功能会记录用户所有的键盘操作，并将在这些键盘操作保存到一个文本文件或者html文件中，以便于查看。键盘记录在远程控制软件中总是存在，而且随着反键盘技术的提高而不断提高。

1998—2000年之间，键盘记录编程非常简单，即直接捕捉键盘消息，并将这些键盘消息保存起来即可。随着技术的不断进步，出现了防范键盘过滤的软键盘。

道高一尺，魔高一丈，键盘记录技术也有了本质的提高，甚至出现了从驱动级别捕捉用户安装消息的工具。这里的键盘记录技术主要用到HOOK、键盘钩子等技术。

键盘钩子：好比鱼钩吊到了一条大鱼时，不管那鱼怎么逃，只要掌握了鱼线总是可以找到这条鱼。键盘钩子就是利用一条一条执行程序的特点，在处理系统代码段里把某一指令替换成一个跳转，让执行行为转转移到自定义的一段代码上。在此代码的结尾处再添加被替换掉的指令，最后转移到原来被替换处的下一条指令处，让原来的系统继续运行。好比电路中被串入了电流表，电路功能没有变化，但操作者获得了工作时的电流信息。

同理，windows窗口在获得键盘消息的时候也是一条一条向下执行，在服务端中当我们利用键盘钩子技术，将本应该传递给窗口的键盘消息钩中，获取服务端中的键盘操作信息。然后将这些键盘信息传递给客户端，并在客户端显示出来。在客户端获取服务端的键盘信息后，又将键盘消息放行并继续执行服务端的键盘操作，这样就可以获取服务端的键盘操作信息，而又不影响到服务端的操作。

4.3.6 CMD控制

从早期的远程控制软件开始，都是把目标计算机作为服务端，在服务端上打开要监听的端口并进行监听。控制端可以和目标主机的监听端口并进行连接，在服务端开启一个CMD命令进程，从而返回一个CMD命令的SHELL。在客户端中可以输入命令，在服务端中进行执行，执行完毕后将执行结果传回客户端，这就涉及进程间通信（IPC）机制，下面使用管道(pipe)的方法来实现开启远程CMDSHELL。

进程间通信(IPC)机制，是指同一台计算机的不同进程之间，或在网络上不同计算机进程之间的通信。Windwos下的方法包括油槽、管道、事件、文件映射等。

管道(pipe)是一种简单的进程间通信机制。实际是一段共享内存，在windows NT、windows 2K，windows 98 下都可以使用。一个进程在向管道写入数据后，另一个进程就可以从管道的另一端将其读取出来。

客户端要使用DOS命令控制服务端的时候，其向服务端发送约定的控制信息，服务端接收到这个信息后将进行解码，得到在服务端上的DOS命令。服务端在本机开启一个CMD进程，然后执行从客户端传来的控制命令，将得到的结果返回给服务端，再由服务端发送返回信息给客户端。结构如右图4.12所示 

4.3.7 屏幕监视

屏幕捕捉是一个从屏幕显示上截取全部或者部分区域作为图像或者文字，然后将这些图像或文字以图形的方式在远程控制端显示出来的过程。很多远程控制软件都有这项功能。远程控制软件提供的这项功能，为管理员远程控制目标计算机提供了很大的帮助。它使远程管理员更加清晰地明白当前在操作什么文件以及如何操作。

下来来介绍下屏幕捕捉程序的结构和远程捕捉屏幕的实现。

在服务端，①获取客户端与服务端约定的屏幕监视消息时，服务端就对接收来的命令进行解析，执行屏幕截取功能；②服务端开始将自己屏幕的内容以图片的方式保存下来；③服务端将保存下来的图片进行压缩以方便传送；④将图片信息发送给客户端。

下面给出伪代码：

While（true）

{

//step 1: 读取COMMAND命令

//Step 2:对命令解析

       Switch(SendMSG.wCmd) {

       Case : CMD_SCREEN_MANAGE

 调用cmd_ctrl_GetScreen()函数过程

   ……………………

}

}

int cmd_ctrl_GetScreen()

{

//Step 1:抓屏

//Step 2:JPEG压缩

//Step 3:发送图像头信息

//Step 4:发送图像部分

}

在客户端中，①屏幕捕获时为了不影响其他功能的使用，开启屏幕捕获线程；②填充与服务端约定的屏幕捕获消息结构体；③发送信息给服务端让其截取屏幕图片；④从服务端那里获取图片的信息，将其保存下来；⑤对保存下的图片信息进行解码；⑥将解码后的信息在Picture控件里显示捕获的图像信息。

SysStartImage()

{

创建ImageCapThread线程

}

 DWORD WINAPI ImagecapThread()

{

While 循环

{

//Step 1：填充sendMsg结构体

//Step 2：发送command命令

//step 3：获取jpeg图像的结构

//step 4：分配内存

//step 5：获得jpeg压缩的图像

//step 6：调用Get_Screen_Data（）函数过程

}

}

Int Get_Screen_Data()

{

//Step 1:设置区域大小

//Step 2:Jpeg解码

//Step 3:在Picture控件里显示捕捉的图像

}

目前处理器屏幕通常采用的都是静态图像压缩方法。这些方法仅仅考虑如何减少单帧图像内的控件冗余，使得传输的图像数据的量依然很大，影响传输及显示效果。与此同时，随着无线计算技术的飞发展，在普通环境下给予服务器计算的应用需求越来越大。人们希望通过各种无线设备以SBC的方式远程访问远端服务器的资源。然而，通常情况下，在无线环境中网络的带宽更窄、更不稳定，这给屏幕数据的传输带来了更大的瓶颈。

另一方面，由于要传输的图像是一系列具有用户界面风格的屏幕持续改变的区域，在两个屏幕图像截取时通常存在大量的时间冗余。尤其在计算机图像界面中，冗余是一种经常发生的动作，也是产生时间冗余的一个重要因素。因此，可以应用这些潜在的时间冗余来进一步减少图像数据的传输。

目前，随着计算机网络的不断推广运用，基于计算机网络的应用软件的研发也就成了众多软件企业与科研机构的主要研发热点之一。这些应用软件中，基于计算机网络的远程实时控制和管理软件具有极其广泛的应用领域，如网络多媒体教室、网络管理与控制、网络服务、在线技术支持等。所以它具有非常良好的发展前景与商业价值。虽然目前已经有一些相关的软件产品，但普遍都存在占用网络带宽过大，实时性差、占用系统资源过多、稳定性差等问题。究其原因，在于远程屏幕图像在网络上传输这个关键技术环节上问题解决得不够理想。

经过广大编程爱好者长期的反复研究与实践，终于找到了一些方法，能够很好地解决远程屏幕图像网络传输占用落网带宽过大、实时性差、占用系统资源过多、稳定性差等关键问题，为这类软件研发中的远程屏幕图像在网络上传输提供了一种非常有价值的可供参考的解决方法，以下便就此开展叙述与探讨。同时，服务器计算(Server-Based Computing,SBC)模式更是使得人们能像访问本地机器一样很方便地访问和控制远程计算机。

近年来，出现了许多基于服务器计算模式的远程访问工具，如VNC、PCAnywhere、Netmeeting。由于这种模式的方便和快捷，这类工具已经在许多实际系统中到了广泛地应用。以图形化屏幕的压缩和传输为基础的远程屏幕同步（Remtoe Screen Synchronization，RSS）机制是其中的关键技术之一。由于被访问的远程计算机(我们称之为服务器)屏幕通常频繁地发生变化，产生大量图像数据，从而在传输过程中消耗大量网络带宽。

为了缓解带宽压力，人们提出各种方法。早期，用来处理服务器屏幕数据的是一些相对简单的算法，如Raw、RRE、Hextile。这些算法基本不涉及数据的压缩，从而使得带宽的消耗很大。随后，TridiaVNC实现了两种被称为Zlib和ZlibHex的算法，它们都采用了标准的Zlib库来实现对Raw和Hextile编码的数据进一步的数据压缩，从而使得需要传输的数据量有所减少。然而，带宽问题依然十分突出。

为进一步解决问题，研究者提出了一些更复杂的方法来压缩和传输图像屏幕数据。Tight是一种新的有效的编码方法，该方法通过采用数据分析器来判断数据的统计特性，从而决定采用哪种预处理过滤器来处理数据。在用Zlib压缩前，不同的数据过滤器被用来预处理不同类型的图像数据。这种方法试图找到一些特殊图像（如单色图像、大面积色块图像），以减少最终传输的压缩数据。这种方法对一些有许多空白区域的简单突袭是有效的，但对于复杂图像，效率不高。

4.3.8 远程屏幕图像在网络上的传输过程

一般这类软件都采用典型的C/S结构，由客户端与服务端两部分构成。客户端主要负责向服务端发出获取服务端屏幕图像的请求，并将从服务端发送而来的屏幕图像在图形控件中实时的显示出来；而服务端主要是负责响应客户端的请求并抓取与发送屏幕图像。由于服务端所抓取的屏幕图像一般为位图格式，其数据量较大，若直接发送则会导致占用网络带宽过大、舒适性差、占用系统资源过多、稳定性差等问题，因此需要经过压缩后才能将其发送给客户端，而客户端相应地也要将接受到的屏幕图像数据进行解压缩后，才能正确地将屏幕图像显示出来。

解决目前普遍存在的问题的关键就在于屏幕数据的压缩与解压缩以及屏幕图像抓取。对于屏幕图像数据的压缩与解压缩这一点，主要追求的是较高的压缩率与较快的压缩与解压缩速度，这可以通过选取一定的压缩与解压缩的速度，可以通过寻找一定的压缩算法如Hufman、RLE、LZW等来实现。已有的这类软件非常注重这点，因此目前这一方面的提高余地非常有限。对于屏幕图像的抓取这一点，很多这类团建字研发过程中却不够注意，甚至忽略了缩选取的屏幕图像抓取方法的重要性，而采用了常用的一般的抓取方法。其实，屏幕图像的抓取与数据的压缩与解压缩一样重要，都将对屏幕图像的实时传输过程产生极其重要的影响。

屏幕抓取模式的选择，屏幕抓取模式有多种，如delphi中可用的抓取模式copymode、cmsrccopy、cmdSrclnvert、cmwlljteness等15中。当采用cmSrcCopy模式时，可直接将待复制的源位图复制至目的画布中。目前普遍的处理方式便是采用这种抓取模式来抓取整个屏幕图像，然后直接将其进行压缩。若采用cmSrclnvert模式时，服务端先将目的画布中已有的位图与大夫之的源位图位值进行XOR（异或）运算后，然后将运算所得的位图进行压缩。在客户端显示时，将解压后的位图位值与当前的位图位值进行XOR运算，运算所得的位图便是服务端当前所传送的屏幕图像。虽然后一种屏幕图像抓取方法比前一种分别在客户端与服务端多了一步位图位值XOR运算，但是经过压缩后，采用后一种方法数据量一般比前一种发放的数据量要小得多。这主要是因为：一般情况下屏幕图像总是在一个局部而非整个屏幕发生变化，将当前屏幕图像与上一个屏幕图像进行XOR运算后，所得屏幕位图未变化部分的位值将为0，而变化部分的位置为1.当屏幕图像变化范围较小时，所抓取的屏幕图像位图的大量位值将为0，同时压缩率与压缩算法有关外，还与带压缩的数据本身有关，因此对其进行压缩将取得更加理想的压缩效果。虽然采用两种抓取模式所获得的屏幕图像数据都一样，但从采用WinZip压缩后的数据量来看，cmSrclnvert模式下的压缩数据量明显小于采用cmSrcCopy模式的压缩数据量。

目前一般都采用的是一次性整屏抓取。由于数据量大，往往无法取得较好的实时效果，尤其在网络带宽有限时这一点特别突出。其实，服务端完全可以通过将屏幕划分为一定数量、大小相等的矩形，分别在抓取模式为cin-Srclnvert下进行抓取与压缩，然后将压缩后的数据添加到一个待发送的队列中去等待传输。或者比较所抓取的矩形区域图形是否发生了变化。若未发生变化，则不处理，接着进行后续处理。与此相对应，客户端从接收到的数据队列中取队头数据进行解压，然后在相应位置上显示出一个矩形大小的图像。

考虑到实时性的要求，实际则称实现时可采用多线程程序设计，利用多个线程分别处理不同的区域的屏幕图像。这种方法能够在不同的网络带宽情况下均获得较好的实时性，占用系统资源也较少，而且也会使软件的稳定性增强。但是必须要注意的是屏幕划分区域的数量应根据实际情况，主要是网络带宽来设定。因为若划分区域的个数过多，则会导致对每个矩形图像进行抓取、压缩、传输、解压以及显示的时间总和超过整屏处理的时间，这样虽然网络带宽占用小，但是性能可能下降。如果划分区域的个数过少，则处理占用的网络带宽下降幅度不大，效果不明显。

下面逐一介绍各部分主要功能。

服务端：

①抓取一个个矩形区域的屏幕图像；

②判断矩形区域图像是否改变；

③对发生的矩形区域图像进行压缩，并放入发送队列；

④跳转到第①步。

客户端：

①从接收队列中取出一个数据块；

②解压数据块，确定矩形区域位置；

③在指定位置显示矩形区域图像；

④跳转到第①步。