简介基于Qt框架实现的Windows远程控制软件资源包含服务器端被控端与客户端主控端两部分附完整源码与可直接运行的编译程序。服务器端以进程形式后台运行客户端为图形界面程序连接时需指定服务器IP及显示画面的宽高参数整体适合学习Qt网络编程与远程桌面原理的初中级开发者参考实践。压缩包共40个文件涵盖14个C源文件、14个头文件、2个工程配置文件以及编译生成的2个可执行程序和运行所需的QtCore、QtGui、QtNetwork及MinGW运行库等6个DLL文件整体大小6.08MB目录结构简洁便于按源码与运行两大部分查看。已有5329人浏览学习从源码阅读到程序部署均有完整支撑既可用作Qt网络通信课程设计的参考方案也可直接运行体验远程控制的基础操作流程。1. 远程控制软件怎么选型Qt加Windows API的组合到底强在哪远程控制类工具在Windows平台上并不少见但大多数闭源方案的黑匣子问题始终存在——你无法确认它是否在传输过程中夹带私货。这个用Qt从零实现的远程控制软件把服务端和客户端完整开源出来提供了远程桌面观看、键鼠控制、文件传输、命令执行、摄像头调阅这几项核心能力。对于想研究远程控制原理、或者需要在内网搭建一套可控远程运维通道的开发者来说它比用现成开源方案更值得拆开看。项目采用经典的C/S架构服务端负责被动接收连接并管理多个客户端客户端则主动发起连接并等待指令。技术栈上选择了Qt Widgets做界面层底层网络通信基于QTcpSocket而涉及Windows系统级操作的部分——比如模拟键鼠输入、枚举窗口、抓取屏幕——则直接调用Win32 API。这意味着它既能跑在普通Windows桌面环境也能在最小化依赖的情况下编译部署不需要额外安装运行时。我拆完这套代码的感受是它没有用任何花哨的框架但恰恰因为结构朴素反而适合作为二次开发的底座。无论你是想改成内网运维工具还是想加一套加密传输层都能在清晰的模块边界上动刀。2. 系统架构拆解服务端、客户端与通信协议怎么协作2.1 两个进程的分工边界整个项目从编译产物上就分成两个独立的可执行文件服务端程序Server和客户端程序Client。服务端跑在被控电脑上负责监听端口、认证接入、转发指令、推送屏幕画面客户端跑在控制端负责发起连接、渲染远程桌面、捕获用户操作并回传。这两个进程之间没有共享内存也没有本地耦合完全通过网络套接字交互。这样做的好处很明显控制端和被控端可以位于完全不同的网段只要网络能互通远程控制链路就能建立。我一般会把服务端部署在需要被运维的机器上客户端装在自己的工作机上两台机器之间的网络走TCP协议。服务端的线程模型是“每连接一线程”的方式。主线程只负责监听新连接一旦accept成功就为该连接创建工作线程线程内完成认证握手、指令循环、屏幕采集与发送这几个周期任务。这种模型在连接数量不大时比如同时管理几台机器非常稳定代码路径清晰调试时也能直接定位到某个连接的上下文。客户端的结构则更贴近“事件驱动”。用户点击连接按钮后客户端创建套接字并尝试连接服务端握手成功后启动接收线程把服务端推送过来的屏幕帧数据解析成QImage渲染到界面上。同时客户端在主线程捕获鼠标和键盘事件通过协议封装成指令包发送出去。2.2 通信协议设计从一个字节头到指令分发协议是整个项目里最值得先读的部分。它没有引入第三方序列化库而是自定义了一套极简的二进制报文格式。每个报文分成三个部分2字节的指令码、4字节的长度字段、以及可变长的数据体。指令码定义了大量枚举值比如请求屏幕帧、键鼠事件、文件开始传输、文件数据块、命令执行结果等。// 指令枚举定义协议头 enum CommandType { CMD_HELLO 0x01, // 握手 CMD_AUTH 0x02, // 认证 CMD_SCREEN_REQUEST 0x10, // 请求屏幕帧 CMD_SCREEN_DATA 0x11, // 屏幕帧数据 CMD_MOUSE_EVENT 0x20, // 鼠标事件 CMD_KEY_EVENT 0x21, // 键盘事件 CMD_FILE_BEGIN 0x30, // 文件传输开始 CMD_FILE_DATA 0x31, // 文件数据块 CMD_FILE_END 0x32, // 文件传输结束 CMD_SHELL 0x40, // 执行命令 CMD_SHELL_OUTPUT 0x41, // 命令输出 };实际编码时发送端会先构造一个QByteArray依次写入指令码占2字节、长度占4字节、数据体然后一次性通过socket写入。接收端则严格按照这个格式去解析先读6字节头部再根据长度字段读取对应大小的数据体。这里需要注意大小端问题。Qt的QDataStream默认使用大端序但如果你自己用memcpy拼接字节就得显式处理。这套代码里用的是ptrdiff_t强转指针的方式所以默认按小端序解析两端保持一致即可不需要额外转换。2.3 目录结构与各模块职责一览拿到源码后先不要急着编译花十分钟把目录结构过一遍能省掉后面不少定位问题的时间。项目采用Qt Widgets Application的标准结构服务端和客户端各自维护独立的类文件共享部分放在公共目录里。RemoteControl/ ├── Common/ │ ├── protocol.h // 协议定义、指令码、报文结构 │ ├── message.h // 报文封装与解析工具类 │ └── compress.h // 屏幕帧压缩JPEG编码封装 ├── Server/ │ ├── main.cpp │ ├── serverwindow.h/cpp // 服务端主窗口显示连接列表 │ ├── servercore.h/cpp // 核心网络监听与连接管理 │ ├── connectionhandler.h/cpp // 单连接工作线程 │ ├── screensender.h/cpp // 屏幕采集与编码发送 │ └── inputsimulator.h/cpp // 键鼠事件模拟执行 ├── Client/ │ ├── main.cpp │ ├── clientwindow.h/cpp // 客户端主窗口连接管理与显示 │ ├── clientcore.h/cpp // 连接发起与数据接收 │ ├── screendisplay.h/cpp // 远程画面渲染 │ └── inputcatcher.h/cpp // 本地键鼠事件捕获与发送 └── RemoteControl.pro // Qt工程文件包含子目录Common目录是两端的协议契约任何一端的改动都会波及另一端的编译所以二次开发时优先保证这里的接口稳定。Server目录下的ConnectionHandler是服务端的核心工作线程它既负责认证也负责后续所有指令的调度。Client目录下的ClientCore则承担接收数据和处理重连逻辑。3. 核心模块代码实践连接握手、屏幕传输与键鼠模拟3.1 服务端连接接入与认证流程服务端启动后QTcpServer进入监听状态。每次收到新连接servercore会创建一个ConnectionHandler对象并把它移入工作线程。Handler首先启动认证过程发送一个随机挑战字符串给客户端客户端用预共享密钥计算哈希后回传服务端验证一致才继续。// ConnectionHandler 认证握手的核心逻辑 void ConnectionHandler::handleNewConnection() { // 生成随机挑战码 QByteArray challenge generateChallenge(16); sendCommand(CMD_HELLO, challenge); // 等待客户端回传认证数据超时10秒 if (!waitForData(CMD_AUTH_RESPONSE, 10000)) { socket-disconnectFromHost(); return; } // 校验摘要是否匹配 QByteArray expected hashWithSecret(challenge, authSecret); if (receivedDigest ! expected) { sendCommand(CMD_AUTH_FAILED, invalid secret); socket-disconnectFromHost(); return; } sendCommand(CMD_AUTH_OK, welcome); startScreenPushLoop(); }认证逻辑里做了一次挑战-响应握手而不是直接传明文密码这能避免密码在网络上直接裸露。常见做法是把预共享密钥硬编码或通过配置文件读取我一般建议至少用SHA-256对挑战码加盐处理防止简单的重放攻击。连接进入就绪状态后服务端启动屏幕推送循环。这里有个细节值得注意屏幕推送不是客户端拉一次推一次而是服务端以固定帧率主动推送。这样即使客户端界面卡顿也不会因为请求积压导致网络拥塞。3.2 屏幕采集与JPEG压缩发送屏幕采集用的是Win32的BitBlt先把整个屏幕拷贝到内存DC再转成QImage。由于原始位图数据量太大直接传输必然卡顿所以代码里对每一帧做了JPEG压缩把质量参数从0到100可调默认取70。// 屏幕采集与压缩 QByteArray ScreenSender::captureAndCompress(int quality) { HDC screenDC GetDC(nullptr); HDC memDC CreateCompatibleDC(screenDC); int w GetSystemMetrics(SM_CXSCREEN); int h GetSystemMetrics(SM_CYSCREEN); HBITMAP bitmap CreateCompatibleBitmap(screenDC, w, h); SelectObject(memDC, bitmap); BitBlt(memDC, 0, 0, w, h, screenDC, 0, 0, SRCCOPY); // 将HBITMAP转为QImage QImage image convertToQImage(bitmap, w, h); // 编码为JPEG存入QByteArray QByteArray compressed; QBuffer buffer(compressed); buffer.open(QIODevice::WriteOnly); image.save(buffer, JPG, quality); // 释放GDI资源 DeleteObject(bitmap); DeleteDC(memDC); ReleaseDC(nullptr, screenDC); return compressed; }这段代码有一个常见的坑每次采集都重新创建DC和位图频繁调用GDI对象会导致资源泄漏和性能下降。较优的做法是在类初始化时一次性创建好兼容DC和位图屏幕尺寸变化时再重建。屏幕尺寸变化这件事本身不多见但一旦发生旧的DC就会失效所以捕获WM_DISPLAYCHANGE消息触发重建是最稳妥的办法。JPEG压缩的质量参数直接决定带宽占用。质量70在普通办公场景下人眼基本无感但在文字密集型界面下边缘会出现轻微模糊。二次开发时可以把质量参数做成动态可调比如在客户端界面上加一个滑动条。3.3 键鼠事件模拟从捕获到Windows API执行客户端捕获鼠标移动、滚轮、按键事件后按照协议封装为事件结构发送。服务端收到后调用SetCursorPos、mouse_event、keybd_event等Win32 API完成模拟操作。// 服务端执行鼠标事件 void InputSimulator::handleMouseEvent(const QByteArray data) { MouseEvent evt; memcpy(evt, data.constData(), sizeof(MouseEvent)); // 坐标换算发送方传的是百分比坐标乘以当前屏幕宽高 int x evt.xPercent * GetSystemMetrics(SM_CXSCREEN) / 100; int y evt.yPercent * GetSystemMetrics(SM_CYSCREEN) / 100; SetCursorPos(x, y); DWORD flags 0; if (evt.buttonMask MOUSE_LEFT_DOWN) flags | MOUSEEVENTF_LEFTDOWN; if (evt.buttonMask MOUSE_LEFT_UP) flags | MOUSEEVENTF_LEFTUP; if (evt.buttonMask MOUSE_RIGHT_DOWN) flags | MOUSEEVENTF_RIGHTDOWN; if (evt.buttonMask MOUSE_RIGHT_UP) flags | MOUSEEVENTF_RIGHTUP; if (evt.wheelDelta ! 0) { mouse_event(MOUSEEVENTF_WHEEL, 0, 0, evt.wheelDelta, 0); } mouse_event(flags, 0, 0, 0, 0); }这里用了百分比坐标而不是绝对像素坐标是因为两台机器的分辨率可能不一致。如果发送方是1080P屏幕接收方是1366x768用绝对坐标会出现鼠标偏移点不到按钮的情况。这个设计在远程控制软件里属于必踩的坑没做过的人第一次往往会栽在这里。键盘事件的处理思路相同需要特别注意虚拟键码的映射。Qt的KeyEvent里拿到的是Qt::Key枚举必须转换成Windows虚拟键码VK_*比如Qt::Key_A对应VK_A、Qt::Key_F1对应VK_F1。如果忘了转换直接强转数值部分按键会失灵而且很难排查。3.4 文件传输的分块策略与进度反馈文件传输走的是独立的指令通道但复用同一个TCP连接。发送端先把文件路径、大小、修改时间封装成CMD_FILE_BEGIN报文然后按64KB为一块读取并发送数据。接收端每收到一块就写盘并回传一块的确认报文这样发送端可以准确统计传输进度。// 发送端分块传输文件 void sendFile(const QString path) { QFile file(path); if (!file.open(QIODevice::ReadOnly)) { sendCommand(CMD_FILE_ERROR, cannot open file); return; } qint64 fileSize file.size(); FileMeta meta; meta.size fileSize; meta.name QFileInfo(path).fileName().toUtf8(); sendCommand(CMD_FILE_BEGIN, serializeMeta(meta)); char buf[64 * 1024]; qint64 sent 0; while (!file.atEnd()) { int n file.read(buf, sizeof(buf)); if (n 0) break; sendCommand(CMD_FILE_DATA, QByteArray(buf, n)); sent n; // 等待接收端确认用于更新进度条 waitForConfirm(); } sendCommand(CMD_FILE_END, QString::number(sent).toUtf8()); }64KB的分块大小是经验值太小会导致TCP小包过多、吞吐下降太大会让单块传输时间过长出现网络抖动时重传成本变高。这个项目里没有做断点续传二次开发如果要支持需要额外传文件偏移量和总体积并在写文件时使用RandomAccess模式。3.5 命令执行与输出回传命令执行功能相对独立。服务端收到CMD_SHELL指令后用QProcess启动cmd.exe执行传入命令并将标准输出和错误输出捕获后存入缓冲区最后统一封装成CMD_SHELL_OUTPUT报文发回客户端。// 服务端执行shell命令并回传输出 void ConnectionHandler::executeShell(const QString command) { QProcess process; process.setProgram(cmd.exe); process.setArguments({/c, command}); process.start(); // 等待执行完成最多30秒 if (!process.waitForFinished(30000)) { sendCommand(CMD_SHELL_OUTPUT, command timeout); return; } QByteArray output process.readAllStandardOutput(); output process.readAllStandardError(); sendCommand(CMD_SHELL_OUTPUT, output); }waitForFinished用30秒超时是保守选择有些命令启动慢比如网络相关的ipconfig可能会跑几秒。如果你知道对方机器性能较差可以把超时拉长到60秒但如果命令本身是持续输出的进程比如ping -t这个实现就不适用了需要改成流式输出方案。4. 编译、部署与运行从源码到双端连接4.1 环境准备与工程编译编译该项目需要安装Qt开发环境建议使用Qt 5.15或Qt 6.x版本编译器选择MSVC 2019及以上。如果用MinGW工具链部分Win32 API调用也能编译通过但个别GDI相关的头文件在MinGW里路径不同需要额外配置。我一般直接用MSVC编译省掉这些兼容问题。拿到源码后打开RemoteControl.pro工程文件先用qmake生成Makefile再执行编译。如果你使用Qt Creator直接打开.pro文件并构建即可。整个过程会生成两个exe一个在Server目录下一个在Client目录下。# 命令行编译流程Windows MSVC环境 mkdir build cd build qmake ../RemoteControl.pro nmake编译完成后Server.exe和Client.exe所在的目录里还需要Qt运行时依赖。正式交付时建议使用windeployqt把需要的Qt库和插件拷到exe同目录下否则换一台机器就会因为缺DLL启动失败。windeployqt会把platforms、imageformats等目录一并拷好省心很多。4.2 服务端部署与监听配置服务端exe运行后界面会显示本机IP地址列表和当前监听端口默认监听端口是9527。点击“开始监听”按钮后服务线程启动连接列表变为空等待状态。每有一个客户端接入列表里会增加一行显示客户端的IP和用户名信息。端口号可以在配置文件里自定义但需要注意Windows防火墙的拦截。如果服务端机器开了防火墙记得在入站规则里允许该TCP端口否则客户端连接会直接超时。这个是最常见的启动完连不上的原因我每次部署新机器时都会先telnet测一下端口通不通。服务端还提供了断开指定连接的按钮。点击断开后对应的工作线程会主动关闭socket并清理资源。注意清理过程要分离线程或等待线程结束避免直接操作已销毁的QTcpSocket对象导致崩溃。4.3 客户端连接与被控端操作客户端界面相对简单输入服务端IP和端口点击连接。连接成功后界面会切换为远程桌面视图服务端的屏幕画面以约15帧/秒的速度推送过来。鼠标在远程画面上操作时会实时回传键盘输入也同步生效。如果连接时提示“认证失败”检查两端的密钥是否一致。密钥默认写在代码的常量里没有做运行时配置。想要更灵活可以在两端都加一个输入框让用户手动填写但要确保两端一致才能握手成功。远程画面出现花屏或卡顿的排查思路有两个方向。第一是检查JPEG压缩质量是否过高导致单帧数据超过TCP拥塞窗口第二是确认服务端所在机器的GPU占用率如果被控端正在跑图形负载高的任务BitBlt的速度会明显下降。把质量参数降到50帧率降到10基本能恢复流畅。5. 避坑指南远程控制开发中常见的五个翻车现场5.1 屏幕采集黑屏但程序没崩溃现象服务端连接正常客户端界面上接受到的是一整块黑色画面但Service端采集程序本身运行正常。原因服务端进程运行在非交互式会话中比如通过服务管理器启动或通过计划任务以最高权限后台运行。这种情况下Session 0隔离导致BitBlt获取不到当前登录用户的桌面内容。普通双击启动的进程不会有这个问题。解决确保Server.exe以当前登录用户的身份双击启动不要注册为Windows服务也不要用计划任务设置“不管用户是否登录都要运行”。如果确实需要后台常驻用普通用户登录会话下运行最小化窗口即可。5.2 客户端鼠标位置偏移点击错位现象不同分辨率的机器之间远程控制时鼠标箭头位置和实际点击位置不一致越靠近屏幕右下角偏差越大。原因发送端把本地鼠标坐标直接当作远程坐标传输。两台机器分辨率不同横向比例和纵向比例都对不上导致坐标映射错误。解决发送端发送前把坐标换算成百分比即xPercent mouseX * 100 / screenWidthyPercent同理。接收端再按目标机器的实际屏幕宽高还原成绝对像素。这个方案在代码里已经实现二次开发时不要去改动坐标传输格式。5.3 TCP粘包导致指令解析错乱现象连续快速发送鼠标移动事件时客户端收到的指令偶尔解析失败报文长度字段读出来是超大数字。原因TCP是流协议多个指令包可能被内核合并成一个包到达接收端或者一个包被拆成两次读取。接收端如果每次只读缓冲区的一部分就会把下一个包的头部当成当前包的数据体导致错乱。解决接收端必须维护一个缓冲区循环解析。每次先判断缓冲区长度是否大于等于6字节不足则继续读读取头部后判断长度字段是否和缓冲区中剩余数据匹配不匹配则继续等待。代码里Message类的parse逻辑要把这个循环做完整不能边读边解析。5.4 高频屏幕推送导致带宽占满现象远程画面清晰但同一局域网内的其他设备网络延迟飙升ping值暴增。原因单帧JPEG体积约30KB到80KB15帧每秒意味着带宽占用约4MB/s到10MB/s已经超过百兆局域网的理论带宽。解决压缩质量降低帧率改为动态调节——当检测到画面变化剧烈时降低帧率静止画面时又主动限制帧率上限。更高阶的做法是只传输屏幕变化的矩形区域把变化区域裁剪出来压缩静止部分完全跳过。5.5 释放GDI对象不彻底导致内存上涨现象服务端长期运行一整天后进程内存持续攀升远程画面出现卡顿最终系统弹窗提示GDI对象耗尽。原因屏幕采集循环里CreateCompatibleDC和CreateCompatibleBitmap创建的GDI对象没有完全释放或者释放顺序错误导致句柄泄漏。任务管理器查看GDI Object列能确认问题。解决每次采集完毕都要确保DeleteObject(bitmap)和DeleteDC(memDC)成对调用不能遗漏。建议的写法是把采集逻辑放入RAII封装利用析构函数保证释放。更省事的方案是复用成员变量来保存DC和位图只在屏幕分辨率变化时重建。6. 二次开发实战给远程控制软件加上TLS加密通道对远程控制有些了解的开发者应该清楚裸TCP传输在公网环境下基本等于裸奔——屏幕画面、键盘输入、文件内容都是明文传输。一旦被中间人截获等于把机器的控制权直接交了出去。这套代码目前用的是明文传输二次开发时第一优先级就是把通信层改成加密通道。改造思路很直接在现有协议报文的基础上包一层TLS封装。Qt提供了QSslSocket它继承自QTcpSocket所以现有代码里所有socket读写的地方都可以平滑替换。连接阶段改为先做TLS握手证书可以用自签名证书但两端都要提前内置CA证书来验证对端身份防止中间人攻击。// 客户端改用QSslSocket建立加密连接 QSslSocket* sslSocket new QSslSocket(this); sslSocket-setProtocol(QSsl::TlsV1_2); sslSocket-setLocalCertificate(client.pem); sslSocket-setPrivateKey(client.key); sslSocket-setCaCertificates(QSslCertificate::fromPath(ca.pem)); connect(sslSocket, QSslSocket::encrypted, this, ClientCore::onEncrypted); sslSocket-connectToHostEncrypted(serverIp, port);替换之后原有协议解析代码不需要改动QSslSocket会保证在加密通道之上传输的数据按序到达。唯一要注意的是握手阶段需要额外加载证书文件如果证书链不完整会报错“SSL handshake failed”。我一般会在构造函数里提前加载并验证避免运行时才发现证书路径不对。认证机制也可以顺带加强。目前是预共享密钥做挑战-响应但密钥硬编码在代码里换机器还要重新编译。改成读取外部配置文件的方式更灵活也能支持按客户端分配不同的密钥。逻辑上在认证通过后再获取该连接对应的权限级别比如只允许观看桌面、不允许传输文件这样多级权限就能在同一套代码里实现。屏幕传输性能的优化方向同样值得动手。当前是整屏全量采集加JPEG压缩在局域网内表现尚可但放到跨互联网场景下帧率会掉到个位数。可以对每帧和上一帧做差值比较只对变化区域重新编码。实现上先按16x16的像素块比较颜色值记录发生变化的小块矩形集合然后把这些矩形合并成更大的区域后分别压缩能省下大量带宽。除此之外把文件传输的分块大小从固定64KB改成基于动态网络RTT估计的滑动窗口大小可以显著提升高延迟链路下的吞吐率。思路是每发送若干块记录耗时如果耗时低于阈值则增加每块大小反之减半回退类似TCP拥塞控制的简化版。这个改造不复杂但对实际外网传输体验的改善非常明显。从一个简单的远程桌面工具变成能用于生产环境的运维软件往往就差这几步加密可信、权限分级、传输优化。我自己的经验是每次改完通信层都强制走一遍完整的连接-认证-观看-文件传输-断线重连流程确保新增的加密逻辑没有破坏原有协议时序。希望这个项目能给你一个结实的地基少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取
简介基于Qt框架实现的Windows远程控制软件资源包含服务器端被控端与客户端主控端两部分附完整源码与可直接运行的编译程序。服务器端以进程形式后台运行客户端为图形界面程序连接时需指定服务器IP及显示画面的宽高参数整体适合学习Qt网络编程与远程桌面原理的初中级开发者参考实践。压缩包共40个文件涵盖14个C源文件、14个头文件、2个工程配置文件以及编译生成的2个可执行程序和运行所需的QtCore、QtGui、QtNetwork及MinGW运行库等6个DLL文件整体大小6.08MB目录结构简洁便于按源码与运行两大部分查看。已有5329人浏览学习从源码阅读到程序部署均有完整支撑既可用作Qt网络通信课程设计的参考方案也可直接运行体验远程控制的基础操作流程。1. 远程控制软件怎么选型Qt加Windows API的组合到底强在哪远程控制类工具在Windows平台上并不少见但大多数闭源方案的黑匣子问题始终存在——你无法确认它是否在传输过程中夹带私货。这个用Qt从零实现的远程控制软件把服务端和客户端完整开源出来提供了远程桌面观看、键鼠控制、文件传输、命令执行、摄像头调阅这几项核心能力。对于想研究远程控制原理、或者需要在内网搭建一套可控远程运维通道的开发者来说它比用现成开源方案更值得拆开看。项目采用经典的C/S架构服务端负责被动接收连接并管理多个客户端客户端则主动发起连接并等待指令。技术栈上选择了Qt Widgets做界面层底层网络通信基于QTcpSocket而涉及Windows系统级操作的部分——比如模拟键鼠输入、枚举窗口、抓取屏幕——则直接调用Win32 API。这意味着它既能跑在普通Windows桌面环境也能在最小化依赖的情况下编译部署不需要额外安装运行时。我拆完这套代码的感受是它没有用任何花哨的框架但恰恰因为结构朴素反而适合作为二次开发的底座。无论你是想改成内网运维工具还是想加一套加密传输层都能在清晰的模块边界上动刀。2. 系统架构拆解服务端、客户端与通信协议怎么协作2.1 两个进程的分工边界整个项目从编译产物上就分成两个独立的可执行文件服务端程序Server和客户端程序Client。服务端跑在被控电脑上负责监听端口、认证接入、转发指令、推送屏幕画面客户端跑在控制端负责发起连接、渲染远程桌面、捕获用户操作并回传。这两个进程之间没有共享内存也没有本地耦合完全通过网络套接字交互。这样做的好处很明显控制端和被控端可以位于完全不同的网段只要网络能互通远程控制链路就能建立。我一般会把服务端部署在需要被运维的机器上客户端装在自己的工作机上两台机器之间的网络走TCP协议。服务端的线程模型是“每连接一线程”的方式。主线程只负责监听新连接一旦accept成功就为该连接创建工作线程线程内完成认证握手、指令循环、屏幕采集与发送这几个周期任务。这种模型在连接数量不大时比如同时管理几台机器非常稳定代码路径清晰调试时也能直接定位到某个连接的上下文。客户端的结构则更贴近“事件驱动”。用户点击连接按钮后客户端创建套接字并尝试连接服务端握手成功后启动接收线程把服务端推送过来的屏幕帧数据解析成QImage渲染到界面上。同时客户端在主线程捕获鼠标和键盘事件通过协议封装成指令包发送出去。2.2 通信协议设计从一个字节头到指令分发协议是整个项目里最值得先读的部分。它没有引入第三方序列化库而是自定义了一套极简的二进制报文格式。每个报文分成三个部分2字节的指令码、4字节的长度字段、以及可变长的数据体。指令码定义了大量枚举值比如请求屏幕帧、键鼠事件、文件开始传输、文件数据块、命令执行结果等。// 指令枚举定义协议头 enum CommandType { CMD_HELLO 0x01, // 握手 CMD_AUTH 0x02, // 认证 CMD_SCREEN_REQUEST 0x10, // 请求屏幕帧 CMD_SCREEN_DATA 0x11, // 屏幕帧数据 CMD_MOUSE_EVENT 0x20, // 鼠标事件 CMD_KEY_EVENT 0x21, // 键盘事件 CMD_FILE_BEGIN 0x30, // 文件传输开始 CMD_FILE_DATA 0x31, // 文件数据块 CMD_FILE_END 0x32, // 文件传输结束 CMD_SHELL 0x40, // 执行命令 CMD_SHELL_OUTPUT 0x41, // 命令输出 };实际编码时发送端会先构造一个QByteArray依次写入指令码占2字节、长度占4字节、数据体然后一次性通过socket写入。接收端则严格按照这个格式去解析先读6字节头部再根据长度字段读取对应大小的数据体。这里需要注意大小端问题。Qt的QDataStream默认使用大端序但如果你自己用memcpy拼接字节就得显式处理。这套代码里用的是ptrdiff_t强转指针的方式所以默认按小端序解析两端保持一致即可不需要额外转换。2.3 目录结构与各模块职责一览拿到源码后先不要急着编译花十分钟把目录结构过一遍能省掉后面不少定位问题的时间。项目采用Qt Widgets Application的标准结构服务端和客户端各自维护独立的类文件共享部分放在公共目录里。RemoteControl/ ├── Common/ │ ├── protocol.h // 协议定义、指令码、报文结构 │ ├── message.h // 报文封装与解析工具类 │ └── compress.h // 屏幕帧压缩JPEG编码封装 ├── Server/ │ ├── main.cpp │ ├── serverwindow.h/cpp // 服务端主窗口显示连接列表 │ ├── servercore.h/cpp // 核心网络监听与连接管理 │ ├── connectionhandler.h/cpp // 单连接工作线程 │ ├── screensender.h/cpp // 屏幕采集与编码发送 │ └── inputsimulator.h/cpp // 键鼠事件模拟执行 ├── Client/ │ ├── main.cpp │ ├── clientwindow.h/cpp // 客户端主窗口连接管理与显示 │ ├── clientcore.h/cpp // 连接发起与数据接收 │ ├── screendisplay.h/cpp // 远程画面渲染 │ └── inputcatcher.h/cpp // 本地键鼠事件捕获与发送 └── RemoteControl.pro // Qt工程文件包含子目录Common目录是两端的协议契约任何一端的改动都会波及另一端的编译所以二次开发时优先保证这里的接口稳定。Server目录下的ConnectionHandler是服务端的核心工作线程它既负责认证也负责后续所有指令的调度。Client目录下的ClientCore则承担接收数据和处理重连逻辑。3. 核心模块代码实践连接握手、屏幕传输与键鼠模拟3.1 服务端连接接入与认证流程服务端启动后QTcpServer进入监听状态。每次收到新连接servercore会创建一个ConnectionHandler对象并把它移入工作线程。Handler首先启动认证过程发送一个随机挑战字符串给客户端客户端用预共享密钥计算哈希后回传服务端验证一致才继续。// ConnectionHandler 认证握手的核心逻辑 void ConnectionHandler::handleNewConnection() { // 生成随机挑战码 QByteArray challenge generateChallenge(16); sendCommand(CMD_HELLO, challenge); // 等待客户端回传认证数据超时10秒 if (!waitForData(CMD_AUTH_RESPONSE, 10000)) { socket-disconnectFromHost(); return; } // 校验摘要是否匹配 QByteArray expected hashWithSecret(challenge, authSecret); if (receivedDigest ! expected) { sendCommand(CMD_AUTH_FAILED, invalid secret); socket-disconnectFromHost(); return; } sendCommand(CMD_AUTH_OK, welcome); startScreenPushLoop(); }认证逻辑里做了一次挑战-响应握手而不是直接传明文密码这能避免密码在网络上直接裸露。常见做法是把预共享密钥硬编码或通过配置文件读取我一般建议至少用SHA-256对挑战码加盐处理防止简单的重放攻击。连接进入就绪状态后服务端启动屏幕推送循环。这里有个细节值得注意屏幕推送不是客户端拉一次推一次而是服务端以固定帧率主动推送。这样即使客户端界面卡顿也不会因为请求积压导致网络拥塞。3.2 屏幕采集与JPEG压缩发送屏幕采集用的是Win32的BitBlt先把整个屏幕拷贝到内存DC再转成QImage。由于原始位图数据量太大直接传输必然卡顿所以代码里对每一帧做了JPEG压缩把质量参数从0到100可调默认取70。// 屏幕采集与压缩 QByteArray ScreenSender::captureAndCompress(int quality) { HDC screenDC GetDC(nullptr); HDC memDC CreateCompatibleDC(screenDC); int w GetSystemMetrics(SM_CXSCREEN); int h GetSystemMetrics(SM_CYSCREEN); HBITMAP bitmap CreateCompatibleBitmap(screenDC, w, h); SelectObject(memDC, bitmap); BitBlt(memDC, 0, 0, w, h, screenDC, 0, 0, SRCCOPY); // 将HBITMAP转为QImage QImage image convertToQImage(bitmap, w, h); // 编码为JPEG存入QByteArray QByteArray compressed; QBuffer buffer(compressed); buffer.open(QIODevice::WriteOnly); image.save(buffer, JPG, quality); // 释放GDI资源 DeleteObject(bitmap); DeleteDC(memDC); ReleaseDC(nullptr, screenDC); return compressed; }这段代码有一个常见的坑每次采集都重新创建DC和位图频繁调用GDI对象会导致资源泄漏和性能下降。较优的做法是在类初始化时一次性创建好兼容DC和位图屏幕尺寸变化时再重建。屏幕尺寸变化这件事本身不多见但一旦发生旧的DC就会失效所以捕获WM_DISPLAYCHANGE消息触发重建是最稳妥的办法。JPEG压缩的质量参数直接决定带宽占用。质量70在普通办公场景下人眼基本无感但在文字密集型界面下边缘会出现轻微模糊。二次开发时可以把质量参数做成动态可调比如在客户端界面上加一个滑动条。3.3 键鼠事件模拟从捕获到Windows API执行客户端捕获鼠标移动、滚轮、按键事件后按照协议封装为事件结构发送。服务端收到后调用SetCursorPos、mouse_event、keybd_event等Win32 API完成模拟操作。// 服务端执行鼠标事件 void InputSimulator::handleMouseEvent(const QByteArray data) { MouseEvent evt; memcpy(evt, data.constData(), sizeof(MouseEvent)); // 坐标换算发送方传的是百分比坐标乘以当前屏幕宽高 int x evt.xPercent * GetSystemMetrics(SM_CXSCREEN) / 100; int y evt.yPercent * GetSystemMetrics(SM_CYSCREEN) / 100; SetCursorPos(x, y); DWORD flags 0; if (evt.buttonMask MOUSE_LEFT_DOWN) flags | MOUSEEVENTF_LEFTDOWN; if (evt.buttonMask MOUSE_LEFT_UP) flags | MOUSEEVENTF_LEFTUP; if (evt.buttonMask MOUSE_RIGHT_DOWN) flags | MOUSEEVENTF_RIGHTDOWN; if (evt.buttonMask MOUSE_RIGHT_UP) flags | MOUSEEVENTF_RIGHTUP; if (evt.wheelDelta ! 0) { mouse_event(MOUSEEVENTF_WHEEL, 0, 0, evt.wheelDelta, 0); } mouse_event(flags, 0, 0, 0, 0); }这里用了百分比坐标而不是绝对像素坐标是因为两台机器的分辨率可能不一致。如果发送方是1080P屏幕接收方是1366x768用绝对坐标会出现鼠标偏移点不到按钮的情况。这个设计在远程控制软件里属于必踩的坑没做过的人第一次往往会栽在这里。键盘事件的处理思路相同需要特别注意虚拟键码的映射。Qt的KeyEvent里拿到的是Qt::Key枚举必须转换成Windows虚拟键码VK_*比如Qt::Key_A对应VK_A、Qt::Key_F1对应VK_F1。如果忘了转换直接强转数值部分按键会失灵而且很难排查。3.4 文件传输的分块策略与进度反馈文件传输走的是独立的指令通道但复用同一个TCP连接。发送端先把文件路径、大小、修改时间封装成CMD_FILE_BEGIN报文然后按64KB为一块读取并发送数据。接收端每收到一块就写盘并回传一块的确认报文这样发送端可以准确统计传输进度。// 发送端分块传输文件 void sendFile(const QString path) { QFile file(path); if (!file.open(QIODevice::ReadOnly)) { sendCommand(CMD_FILE_ERROR, cannot open file); return; } qint64 fileSize file.size(); FileMeta meta; meta.size fileSize; meta.name QFileInfo(path).fileName().toUtf8(); sendCommand(CMD_FILE_BEGIN, serializeMeta(meta)); char buf[64 * 1024]; qint64 sent 0; while (!file.atEnd()) { int n file.read(buf, sizeof(buf)); if (n 0) break; sendCommand(CMD_FILE_DATA, QByteArray(buf, n)); sent n; // 等待接收端确认用于更新进度条 waitForConfirm(); } sendCommand(CMD_FILE_END, QString::number(sent).toUtf8()); }64KB的分块大小是经验值太小会导致TCP小包过多、吞吐下降太大会让单块传输时间过长出现网络抖动时重传成本变高。这个项目里没有做断点续传二次开发如果要支持需要额外传文件偏移量和总体积并在写文件时使用RandomAccess模式。3.5 命令执行与输出回传命令执行功能相对独立。服务端收到CMD_SHELL指令后用QProcess启动cmd.exe执行传入命令并将标准输出和错误输出捕获后存入缓冲区最后统一封装成CMD_SHELL_OUTPUT报文发回客户端。// 服务端执行shell命令并回传输出 void ConnectionHandler::executeShell(const QString command) { QProcess process; process.setProgram(cmd.exe); process.setArguments({/c, command}); process.start(); // 等待执行完成最多30秒 if (!process.waitForFinished(30000)) { sendCommand(CMD_SHELL_OUTPUT, command timeout); return; } QByteArray output process.readAllStandardOutput(); output process.readAllStandardError(); sendCommand(CMD_SHELL_OUTPUT, output); }waitForFinished用30秒超时是保守选择有些命令启动慢比如网络相关的ipconfig可能会跑几秒。如果你知道对方机器性能较差可以把超时拉长到60秒但如果命令本身是持续输出的进程比如ping -t这个实现就不适用了需要改成流式输出方案。4. 编译、部署与运行从源码到双端连接4.1 环境准备与工程编译编译该项目需要安装Qt开发环境建议使用Qt 5.15或Qt 6.x版本编译器选择MSVC 2019及以上。如果用MinGW工具链部分Win32 API调用也能编译通过但个别GDI相关的头文件在MinGW里路径不同需要额外配置。我一般直接用MSVC编译省掉这些兼容问题。拿到源码后打开RemoteControl.pro工程文件先用qmake生成Makefile再执行编译。如果你使用Qt Creator直接打开.pro文件并构建即可。整个过程会生成两个exe一个在Server目录下一个在Client目录下。# 命令行编译流程Windows MSVC环境 mkdir build cd build qmake ../RemoteControl.pro nmake编译完成后Server.exe和Client.exe所在的目录里还需要Qt运行时依赖。正式交付时建议使用windeployqt把需要的Qt库和插件拷到exe同目录下否则换一台机器就会因为缺DLL启动失败。windeployqt会把platforms、imageformats等目录一并拷好省心很多。4.2 服务端部署与监听配置服务端exe运行后界面会显示本机IP地址列表和当前监听端口默认监听端口是9527。点击“开始监听”按钮后服务线程启动连接列表变为空等待状态。每有一个客户端接入列表里会增加一行显示客户端的IP和用户名信息。端口号可以在配置文件里自定义但需要注意Windows防火墙的拦截。如果服务端机器开了防火墙记得在入站规则里允许该TCP端口否则客户端连接会直接超时。这个是最常见的启动完连不上的原因我每次部署新机器时都会先telnet测一下端口通不通。服务端还提供了断开指定连接的按钮。点击断开后对应的工作线程会主动关闭socket并清理资源。注意清理过程要分离线程或等待线程结束避免直接操作已销毁的QTcpSocket对象导致崩溃。4.3 客户端连接与被控端操作客户端界面相对简单输入服务端IP和端口点击连接。连接成功后界面会切换为远程桌面视图服务端的屏幕画面以约15帧/秒的速度推送过来。鼠标在远程画面上操作时会实时回传键盘输入也同步生效。如果连接时提示“认证失败”检查两端的密钥是否一致。密钥默认写在代码的常量里没有做运行时配置。想要更灵活可以在两端都加一个输入框让用户手动填写但要确保两端一致才能握手成功。远程画面出现花屏或卡顿的排查思路有两个方向。第一是检查JPEG压缩质量是否过高导致单帧数据超过TCP拥塞窗口第二是确认服务端所在机器的GPU占用率如果被控端正在跑图形负载高的任务BitBlt的速度会明显下降。把质量参数降到50帧率降到10基本能恢复流畅。5. 避坑指南远程控制开发中常见的五个翻车现场5.1 屏幕采集黑屏但程序没崩溃现象服务端连接正常客户端界面上接受到的是一整块黑色画面但Service端采集程序本身运行正常。原因服务端进程运行在非交互式会话中比如通过服务管理器启动或通过计划任务以最高权限后台运行。这种情况下Session 0隔离导致BitBlt获取不到当前登录用户的桌面内容。普通双击启动的进程不会有这个问题。解决确保Server.exe以当前登录用户的身份双击启动不要注册为Windows服务也不要用计划任务设置“不管用户是否登录都要运行”。如果确实需要后台常驻用普通用户登录会话下运行最小化窗口即可。5.2 客户端鼠标位置偏移点击错位现象不同分辨率的机器之间远程控制时鼠标箭头位置和实际点击位置不一致越靠近屏幕右下角偏差越大。原因发送端把本地鼠标坐标直接当作远程坐标传输。两台机器分辨率不同横向比例和纵向比例都对不上导致坐标映射错误。解决发送端发送前把坐标换算成百分比即xPercent mouseX * 100 / screenWidthyPercent同理。接收端再按目标机器的实际屏幕宽高还原成绝对像素。这个方案在代码里已经实现二次开发时不要去改动坐标传输格式。5.3 TCP粘包导致指令解析错乱现象连续快速发送鼠标移动事件时客户端收到的指令偶尔解析失败报文长度字段读出来是超大数字。原因TCP是流协议多个指令包可能被内核合并成一个包到达接收端或者一个包被拆成两次读取。接收端如果每次只读缓冲区的一部分就会把下一个包的头部当成当前包的数据体导致错乱。解决接收端必须维护一个缓冲区循环解析。每次先判断缓冲区长度是否大于等于6字节不足则继续读读取头部后判断长度字段是否和缓冲区中剩余数据匹配不匹配则继续等待。代码里Message类的parse逻辑要把这个循环做完整不能边读边解析。5.4 高频屏幕推送导致带宽占满现象远程画面清晰但同一局域网内的其他设备网络延迟飙升ping值暴增。原因单帧JPEG体积约30KB到80KB15帧每秒意味着带宽占用约4MB/s到10MB/s已经超过百兆局域网的理论带宽。解决压缩质量降低帧率改为动态调节——当检测到画面变化剧烈时降低帧率静止画面时又主动限制帧率上限。更高阶的做法是只传输屏幕变化的矩形区域把变化区域裁剪出来压缩静止部分完全跳过。5.5 释放GDI对象不彻底导致内存上涨现象服务端长期运行一整天后进程内存持续攀升远程画面出现卡顿最终系统弹窗提示GDI对象耗尽。原因屏幕采集循环里CreateCompatibleDC和CreateCompatibleBitmap创建的GDI对象没有完全释放或者释放顺序错误导致句柄泄漏。任务管理器查看GDI Object列能确认问题。解决每次采集完毕都要确保DeleteObject(bitmap)和DeleteDC(memDC)成对调用不能遗漏。建议的写法是把采集逻辑放入RAII封装利用析构函数保证释放。更省事的方案是复用成员变量来保存DC和位图只在屏幕分辨率变化时重建。6. 二次开发实战给远程控制软件加上TLS加密通道对远程控制有些了解的开发者应该清楚裸TCP传输在公网环境下基本等于裸奔——屏幕画面、键盘输入、文件内容都是明文传输。一旦被中间人截获等于把机器的控制权直接交了出去。这套代码目前用的是明文传输二次开发时第一优先级就是把通信层改成加密通道。改造思路很直接在现有协议报文的基础上包一层TLS封装。Qt提供了QSslSocket它继承自QTcpSocket所以现有代码里所有socket读写的地方都可以平滑替换。连接阶段改为先做TLS握手证书可以用自签名证书但两端都要提前内置CA证书来验证对端身份防止中间人攻击。// 客户端改用QSslSocket建立加密连接 QSslSocket* sslSocket new QSslSocket(this); sslSocket-setProtocol(QSsl::TlsV1_2); sslSocket-setLocalCertificate(client.pem); sslSocket-setPrivateKey(client.key); sslSocket-setCaCertificates(QSslCertificate::fromPath(ca.pem)); connect(sslSocket, QSslSocket::encrypted, this, ClientCore::onEncrypted); sslSocket-connectToHostEncrypted(serverIp, port);替换之后原有协议解析代码不需要改动QSslSocket会保证在加密通道之上传输的数据按序到达。唯一要注意的是握手阶段需要额外加载证书文件如果证书链不完整会报错“SSL handshake failed”。我一般会在构造函数里提前加载并验证避免运行时才发现证书路径不对。认证机制也可以顺带加强。目前是预共享密钥做挑战-响应但密钥硬编码在代码里换机器还要重新编译。改成读取外部配置文件的方式更灵活也能支持按客户端分配不同的密钥。逻辑上在认证通过后再获取该连接对应的权限级别比如只允许观看桌面、不允许传输文件这样多级权限就能在同一套代码里实现。屏幕传输性能的优化方向同样值得动手。当前是整屏全量采集加JPEG压缩在局域网内表现尚可但放到跨互联网场景下帧率会掉到个位数。可以对每帧和上一帧做差值比较只对变化区域重新编码。实现上先按16x16的像素块比较颜色值记录发生变化的小块矩形集合然后把这些矩形合并成更大的区域后分别压缩能省下大量带宽。除此之外把文件传输的分块大小从固定64KB改成基于动态网络RTT估计的滑动窗口大小可以显著提升高延迟链路下的吞吐率。思路是每发送若干块记录耗时如果耗时低于阈值则增加每块大小反之减半回退类似TCP拥塞控制的简化版。这个改造不复杂但对实际外网传输体验的改善非常明显。从一个简单的远程桌面工具变成能用于生产环境的运维软件往往就差这几步加密可信、权限分级、传输优化。我自己的经验是每次改完通信层都强制走一遍完整的连接-认证-观看-文件传输-断线重连流程确保新增的加密逻辑没有破坏原有协议时序。希望这个项目能给你一个结实的地基少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
