简介Zero远控_04 是远程控制技术系列教程的第四部分配套源码面向具备 C 基础、希望动手理解远程控制原理的开发者与学习者。代码以客户端与服务端两个子工程组织可对照学习身份验证、连接建立、指令传输与屏幕实时同步的完整链路也涉及加密通信、权限分级与操作日志等设计要点。压缩包共 31 个文件、约 59KB以 9 个 cpp 源文件与 7 个 h 头文件为主体分别承载套接字封装、服务端与客户端业务逻辑另有 2 个 .pro 工程文件与 .user 配置便于直接用 Qt 打开编译配套 .ui 界面文件、.qrc 资源清单、.rc 与 .ico 图标及若干 png 素材构成可直接运行的最小工程骨架。目前已有 244 人学习。借助这份体量轻巧却结构完整的代码读者可理清两个子工程的模块划分与职责边界掌握 TCP 收发、界面与逻辑分离、工程资源配置等实践细节并在此基础上扩展多平台支持与安全加固。1. Zero远控第 04 版一套能自己改的自建远程桌面源码包值班时被喊去看一台无人值守的采集机屏幕还亮着、键鼠没反应人走到现场要四十分钟。这时候真正缺的不是再装一个成品客户端而是一套能自己改参数、能翻日志、能定位到第几帧丢的远程桌面代码。Zero远控_04 就是这样一个源码包它把屏幕采集、帧编码、传输中继、输入注入、会话鉴权拆成五个可以单独替换的模块第 04 版把重点放在帧差分和回执确认这两块的重写上也就是最影响手感的两处。它适合两类人一类是要在隔离网络里给自己或授权设备做远程运维的开发者另一类是始终没搞明白远程桌面为什么卡这个黑匣子的人。读懂它不需要图形学功底但要愿意动手改参数、看日志、复现现象。2. 链路拆解从屏幕帧到控制回执的六段流水线怎么排一套远程桌面系统的复杂度八成不在能不能连上而在连上之后稳不稳。Zero远控_04 的目录结构基本就是按数据流切的采集端出帧、编码端出包、发送端出字节、中继端做转发、接收端做贴图、注入端做回执。六段里任何一段阻塞用户看到的现象都是同一个字——卡。所以读这份源码别从 main 函数顺着读按链路一段一段啃出问题时才能快速落到具体模块。2.1 Agent 端三条线程的职责边界采集、编码、发送不能混最常见的错误写法是一个循环里把采集、压缩、send 全做完。本地跑 1080p 看不出问题一旦网络抖动send 阻塞几百毫秒采集也跟着停画面就变成一顿一顿的幻灯。Zero远控_04 把这三件事拆成三条线程用两个有界队列串起来队列长度就是你的背压缓冲。import queue import threading # 有界队列容量决定你能容忍多大的瞬时抖动 frame_q queue.Queue(maxsize2) # 采集 - 编码只留最新两帧 packet_q queue.Queue(maxsize64) # 编码 - 发送按包粒度排队 def producer(): while running: frame grab_screen() if frame_q.full(): try: frame_q.get_nowait() # 丢掉最旧的帧保实时性 except queue.Empty: pass frame_q.put(frame) def encoder(): while running: frame frame_q.get() packet encode_frame(frame) packet_q.put(packet) def sender(sock): while running: packet packet_q.get() sock.sendall(packet) # 允许阻塞阻塞的只是这一条线程逻辑上很简单采集线程永远不被网络拖住编码线程只关心拿到最新帧发送线程阻塞也只影响自己。参数上frame_q容量设成 2 而不是 10是因为远程桌面场景里旧帧没有任何价值攒着只会让延迟越滚越大packet_q给到 64是因为编码后的包本身小且发送端需要一点缓冲来吸收 TCP 窗口收缩。踩过的一个边界是队列满时的丢弃策略必须丢最旧如果写成put阻塞采集线程会跟着卡死等于白拆线程。2.2 传输层为什么选 WebSocket 而不是裸 TCP裸 TCP 最大的麻烦不是性能是帧边界。你得自己设计包头、自己处理粘包半包、自己实现心跳和重连写完这一套代码量已经超过业务本身。Zero远控_04 选 WebSocket看中的是四点消息自带边界二进制帧可以直接承载编码后的图像块控制指令走文本通道与图像通道天然分离浏览器端可以直接当控制端用省掉一个客户端。代价是每帧多几字节头部相对几十 KB 的图像块可以忽略。提示新版本 websockets 库把serve挪到了websockets.asyncio.server命名空间下老写法websockets.serve会直接抛 ImportError。拿到源码先看 import 那一行对不上就改这一处不要怀疑到协议层去。控制指令不跟图像混在一条通道上是这份源码里比较关键的一个设计决定。图像走 binary指令走 text 且带自增序号这样即使图像通道因为大包被 TCP 排队点击指令也不会排在一堆图像块后面等着。{t:mouse,seq:1043,x:0.4213,y:0.6620,btn:1,act:down} {t:ack,seq:1043,ts:1718000000123}坐标用 0 到 1 的归一化浮点而不是绝对像素。原因在第四章会展开控制端和采集端的屏幕分辨率往往不一样传绝对像素等于把分辨率耦合写死进协议换个显示器就全乱。2.3 中继服务端与会话表谁该记住谁两台机器都在内网、又都不在同一个网段时直连基本没戏中继是绕不开的一环。中继的职责要克制只做字节转发和会话映射不解码图像、不解析指令内容这样它的 CPU 占用基本只跟带宽走。会话表结构简单到一张字典就够session_id映射到 agent 连接和 viewer 连接。import asyncio, json import websockets # session_id - {agent: ws, viewer: ws} SESSIONS {} async def handler(ws): role, sid None, None try: hello json.loads(await ws.recv()) # 首帧必须是握手 role, sid hello[role], hello[sid] # 握手阶段做准入校验别等到转发时才判断 if not check_token(hello.get(token, ), sid): await ws.close(code4003, reasondenied) return SESSIONS.setdefault(sid, {})[role] ws peer_key viewer if role agent else agent async for msg in ws: peer SESSIONS.get(sid, {}).get(peer_key) if peer is not None: await peer.send(msg) # 原样转发不做解析 finally: if sid and role: SESSIONS.get(sid, {}).pop(role, None) async def main(): async with websockets.serve(handler, 127.0.0.1, 8765, max_size4 * 1024 * 1024): await asyncio.Future() asyncio.run(main())这段代码里三个参数值得单独说。max_size必须放大默认值大约 1MB而一帧高质量 JPEG 加上包头很容易顶到边界超了就是连接被直接关掉日志里只留一句 1009很容易误判成网络问题。check_token放在握手阶段而不是每条消息里校验是因为转发路径上做鉴权会把中继变成瓶颈。SESSIONS的清理写在finally里任何一个角色断开都要把自己摘掉否则重连时旧连接对象还在表里转发会静默丢包。还有一条经验中继不要试图做智能路由比如根据消息类型决定要不要转发、要不要缓存。这类逻辑一旦加进去排查难度会指数上升因为你在链路上多了一个会改数据的节点出问题时无法判断是端上错还是中继错。3. 屏幕采集与帧编码把整帧发送压到块级更新的实操带宽是远程桌面的硬约束。1080p 全屏无损 BGRA 一帧大约 8MB30 帧就是 240MB/s任何网络都扛不住。所以真正的工程量集中在这一帧里有多少内容真的变了。第 04 版把整帧发送换成了块级更新这一改对静态办公场景的带宽削减非常明显同时也带来了新的坑块边界撕裂。3.1 采集接口与帧率闸门跨平台采集最省事的做法是mss它封装了各平台的原生接口返回 BGRA 的 numpy 数组。省事归省事必须自己加帧率闸门否则采集线程会以 CPU 能跑多快就跑多快的速度出帧把编码线程直接压死。import time import mss import numpy as np FPS_CAP 30 INTERVAL 1.0 / FPS_CAP def grab_loop(frame_q, stop_flag): with mss.mss() as sct: # monitors[0] 是所有屏幕的并集monitors[1] 才是主屏 monitor sct.monitors[1] last 0.0 while not stop_flag.is_set(): now time.perf_counter() wait INTERVAL - (now - last) if wait 0: time.sleep(wait) # 闸门在这里不在编码端 continue last time.perf_counter() raw np.asarray(sct.grab(monitor)) # 形状 H x W x 4BGRA frame raw[:, :, 2::-1].copy() # BGRA - RGB必须 copy if frame_q.full(): try: frame_q.get_nowait() except Exception: pass frame_q.put(frame)monitors的索引是最容易翻车的地方0 是全部屏幕拼起来的虚拟桌面1 是主屏2 以后是各块副屏。做多屏支持时如果直接用 0拿到的图宽度是所有屏之和坐标映射全部要对齐虚拟桌面原点很多人第一步就错在这。另外raw[:, :, 2::-1]这种切片视图必须补.copy()否则底层 buffer 被下一次 grab 覆盖你发出去的是薛定谔的画面。3.2 脏矩形差分把整帧发送换成块级更新块级更新的思路是把画面切成固定大小的网格逐块比较当前帧和上一帧差异像素占比超过阈值才认为这块脏只编码并发送脏块。接收端维护一张完整的画布收到哪块就贴哪块。BLOCK 64 # 块边长必须是 16 的倍数方便后续对齐 DIFF_RATIO 0.03 # 差异像素占比阈值 PIXEL_DELTA 12 # 单像素差值阈值过滤传感器噪声和光标残影 def dirty_blocks(prev, cur): h, w cur.shape[:2] out [] for y in range(0, h, BLOCK): for x in range(0, w, BLOCK): a prev[y:yBLOCK, x:xBLOCK] b cur[y:yBLOCK, x:xBLOCK] if a.shape ! b.shape: # 分辨率变了整块算脏 out.append((x, y, b)) continue d np.abs(b.astype(np.int16) - a.astype(np.int16)).sum(axis2) if np.count_nonzero(d PIXEL_DELTA) / (b.shape[0] * b.shape[1]) DIFF_RATIO: out.append((x, y, b)) return outBLOCK取 64 是个折中块越小脏块更精准、带宽更省但块数量和元数据开销上升Python 侧的比较循环也会变慢块越大单块编码浪费的面积越大。DIFF_RATIO定在 0.03 是压测出来的经验值低于 0.01 时鼠标光标的抗锯齿边缘会导致大片误判高于 0.08 时滚动页面里的小字更新会被漏掉。PIXEL_DELTA则是用来吃掉编码噪声的全屏重绘类的内容比如播放视频会把这块的判定全部打穿那种场景应该直接切回整帧模式别死磕差分。接收端贴图的顺序也有讲究先贴整帧关键帧再按序贴增量块关键帧丢失时后续所有增量块都是错的所以要有一个请求关键帧的反向指令且限频否则丢一次就会引发关键帧风暴。3.3 编码参数表与实测取舍编码器的参数不是越高质量越好参数之间是互相拉扯的。下表是这几个参数在常见场景下的取值建议数值来自本地压测具体环境还要自己再调。参数静态办公网页滚动视频播放说明编码格式JPEGJPEG整帧 JPEG差分场景下 WEBP 收益不足以抵消 CPU质量因子554570低于 40 时文字边缘明显糊关键帧间隔300 帧300 帧每帧静态场景可以拉得很长块大小6464128大块减少元数据开销单帧包数上限32648防止大帧挤占指令通道质量因子这一栏特别值得说。很多人下意识调到 80觉得画质好实际结果是每帧体积翻倍TCP 排队变长手感反而更差。远程桌面的主观体验里延迟的权重远高于画质——宁可稍微糊一点也不要让鼠标拖动延迟 200 毫秒。我一般会把质量因子压到 45 到 55 之间靠 2 倍的下采样来保证文字可读性比直接调高质量划算得多。4. 输入注入链路坐标归一化、事件节流与回执确认画面通了只能算一半真正让人用不下去的往往是控制端点不准、拖不动、连点变成一次。输入链路的坑比采集链路更隐蔽因为它的错误不会报异常只会让操作手感变得玄学。4.1 坐标归一化先把绝对像素换成 0 到 65535Windows 的SendInput在绝对坐标模式下要求的不是屏幕像素而是 0 到 65535 的归一化值且这个归一化是相对整个虚拟桌面所有显示器拼起来的矩形而言的。所以正确顺序是客户端发 0 到 1 的相对坐标服务端先还原成虚拟桌面内的绝对像素再映射到 0 到 65535。import ctypes from ctypes import wintypes u32 ctypes.windll.user32 SM_XVIRTUALSCREEN, SM_YVIRTUALSCREEN 76, 77 SM_CXVIRTUALSCREEN, SM_CYVIRTUALSCREEN 78, 79 def virtual_screen(): return (u32.GetSystemMetrics(SM_XVIRTUALSCREEN), u32.GetSystemMetrics(SM_YVIRTUALSCREEN), u32.GetSystemMetrics(SM_CXVIRTUALSCREEN), u32.GetSystemMetrics(SM_CYVIRTUALSCREEN)) def to_absolute(nx, ny): vx, vy, vw, vh virtual_screen() px vx int(nx * (vw - 1)) # 归一化 - 虚拟桌面像素 py vy int(ny * (vh - 1)) ax int(px * 65535 / max(vw - 1, 1)) ay int(py * 65535 / max(vh - 1, 1)) return vx, vy, vw, vh, ax, aymax(vw - 1, 1)这个保护不能省。单屏 1x1 缩放的极端情况下分母会是 0算出来直接是除零或者溢出然后你会在注入端看到光标飞到屏幕角落。另外SM_XVIRTUALSCREEN可能是负数——副屏摆在主屏左边时虚拟桌面原点在负坐标区忽略这一点会导致左侧副屏上的点击全部向右偏移一个屏宽这是多屏场景下最典型的错位原因。4.2 注入节流与回执为什么要点一次确认一次鼠标移动事件在高刷屏上每秒能产生几百条全都转发过去会把指令通道塞满。节流的原则是移动事件可以合并按下抬起绝对不能合并。合并窗口取 16 毫秒左右正好对齐 60Hz 的渲染节奏人眼已经感知不到差异。import time import threading pending {x: None, y: None} lock threading.Lock() def on_mouse_move(nx, ny): with lock: pending[x], pending[y] nx, ny # 只记最新位置 def flush_loop(send_fn, stop_flag): last 0.0 while not stop_flag.is_set(): time.sleep(0.004) now time.perf_counter() if now - last 0.016: continue with lock: if pending[x] is None: continue x, y pending[x], pending[y] pending[x] pending[y] None last now send_fn({t: mouse, x: x, y: y, act: move})按键和点击则走另一条路径每条指令带自增seq注入端执行完回一条ack控制端收到ack才认为这次操作生效。回执超时只重发一次不无限重试。原因很实在——重发机制一旦没有上限网络恢复的瞬间会把积压的点击全部补发出去用户看到的就是点了一下弹了五个窗口。这条我踩过代价是一次误操作把一台机器的设置面板叠了十几层。节流还有一个容易忽略的边界拖拽操作。按下之后如果移动事件被合并过度拖拽轨迹会变成折线某些控件比如滑块、画布会认为拖拽中断。所以按下状态期间要把合并窗口缩短到 8 毫秒以内或者干脆标记为关键帧移动不合并。4.3 会话准入与鉴权别把校验写在转发路径上会话准入要解决三个问题这条连接是谁、它能操作哪台设备、它能不能操作。Zero远控_04 的做法是双因子结构握手时提交一次性会话令牌令牌由设备侧生成并带有效期同时校验设备 ID 与请求的目标 ID 是否在允许列表内。令牌的存放位置也有讲究。放在 URL 查询串里最省事但会被各级日志记下来属于典型的图省事留后患放在首个握手帧的 JSON 里配合短有效期是目前比较平衡的做法。有效期建议控制在 5 分钟以内过期即拒让控制端重新申请而不是在服务端做续期状态机。还有一条边界鉴权失败时不要返回细粒度的失败原因比如设备不存在和令牌错误分开报等于把设备列表给探测出来了。统一返一个 4003 关闭码日志里再区分才是可维护又不失安全感的做法。5. 联调避坑五条从现场捞回来的翻车记录这一章每一条都是真实跑出来的现象不是假想。远程桌面的坑有个共同特点现象都在表现层根因都在数据层光看客户端界面永远猜不到。5.1 画面一顿一顿但 CPU 只有 8%现象是画面每隔一两秒卡一下任务管理器里 CPU 全程个位数看起来完全不像是性能问题。原因是 GIL采集、编码、发送三条线程都在同一个 Python 进程里numpy 的比较和 JPEG 编码虽然部分释放 GIL但队列操作和 Python 层的循环仍然串行。表面 CPU 低实际是三条线程在轮流等锁。解决办法是先把编码搬到独立进程multiprocessing用共享内存传 RGB 数据进程间只传块坐标再把queue.Queue换成collections.deque(maxlen2)配合自旋短暂等待减少锁竞争。改完之后卡顿消失端到端延迟从 400ms 降到 120ms 左右。5.2 鼠标点得到但拖不动现象是单击正常一拖拽就断滑动条拖到一半松手位置停在半路。原因是移动事件合并把按下之后的头几个移动点吃掉了控件收到了按下—大跳变—抬起判定为非法拖拽。另外还有一层某些控件要求按下和移动之间的时间间隔大于系统双击判定阈值。解决办法是引入按下状态位mousedown之后的前三帧移动强制不合并同时把合并窗口从 16ms 缩到 8ms抬起时先发一条带最终坐标的移动再发mouseup保证落点准确。这个顺序细节不注意拖拽落点会差几个像素。5.3 多屏机器上光标跑到屏幕外面现象是主屏操作正常鼠标移到副屏区域远端光标直接跳到屏幕边缘或者消失。原因是注入用的是主屏尺寸做归一化而虚拟桌面原点在负坐标或者宽度是两块屏之和。控制端发来的归一化坐标是基于采集到的那块画面服务端却按虚拟桌面去还原两套参照系对不上。解决办法是把采集区域和注入区域绑定成同一个矩形采集时把monitor的left/top/width/height一起发给控制端控制端的所有坐标都相对这个矩形归一化注入时先还原成矩形内像素再加上矩形原点换算到虚拟桌面坐标。改完再测三屏横排、竖排、混合缩放都对得上。5.4 中继转发半小时后必然断连现象非常规律大约每半小时断一次重连后又能用半小时。原因是中间某一层反向代理或负载均衡有空闲超时WebSocket 在这段时间内如果没有数据往来就会被判定为空闲连接掐掉。静态办公场景下画面没变化差分算下来没有脏块就真的一个字节都不发。解决办法是加应用层心跳服务端每 20 秒发一次 ping 帧客户端回 pong同时把代理侧的空闲超时调到 120 秒以上。注意心跳不要用数据帧伪装直接用 WebSocket 协议层的 ping/pong中间设备识别得更准也不会被业务逻辑误判成图像包。5.5 高分屏下画面糊成马赛克现象是笔记本接 4K 屏采集出来的画面尺寸正常但客户端显示明显模糊文字边缘全是锯齿。原因是 DPI 感知没开。进程默认是 DPI 不感知的系统会把窗口内容按 150% 或 200% 缩放后再交给你实际抓到的位图分辨率低于物理分辨率等于是先降采样再放大。解决办法是在进程启动最早期调用SetProcessDpiAwarenessContext声明为 per-monitor aware让系统不做缩放采集接口拿到的就是物理像素。这个调用必须在创建任何窗口之前执行写在if __name__ __main__:的第一行最保险。6. 进阶排查用回放日志把丢帧定位到具体模块链路上任何一处出问题最终表现都是卡靠肉眼永远分不清是采集慢、编码慢、网络慢还是贴图慢。第 04 版里最值钱的其实不是差分算法而是一套轻量回放日志每个出站的帧都带一个固定长度的头记录模块、时间戳和负载长度落地成二进制文件事后用脚本统计。import struct # 帧头模块标识(1B) 毫秒时间戳(8B) 负载长度(4B) HEAD struct.Struct(BQI) MODULE {1: capture, 2: encode, 3: send, 4: inject} def write_record(fp, module_id, ts_ms, payload_len): fp.write(HEAD.pack(module_id, ts_ms, payload_len)) def scan(path): gaps {capture: [], encode: [], send: []} with open(path, rb) as fp: while True: head fp.read(HEAD.size) if len(head) HEAD.size: break mid, ts, size HEAD.unpack(head) fp.seek(size, 1) # 跳过负载只看时序 name MODULE.get(mid) if name in gaps: gaps[name].append(ts) for name, seq in gaps.items(): if len(seq) 2: continue deltas sorted(b - a for a, b in zip(seq, seq[1:])) p95 deltas[int(len(deltas) * 0.95)] if deltas else 0 print(f{name}: n{len(seq)} p95_interval{p95}ms max{deltas[-1] if deltas else 0}ms) scan(session.bin)判断逻辑很直接如果capture的 p95 间隔已经超过 40ms说明采集端被拖慢去查帧率闸门和 GIL如果采集正常而encode间隔抖动大去查质量因子和块数量如果两者都正常、send间隔成片变大那基本就是网络或者中继排队往下查max_size和代理超时。三种情况对应的排查路径完全不同没有这份日志就只能靠猜。压测的方式也要朴素一点本地起三个 viewer 连同一个 agent观察中继进程的 CPU 和内存是否线性增长。会话表里的连接对象忘了在finally里清理时内存会缓慢爬升半小时后开始出现转发延迟跟网络抖动的现象一模一样用这种方法几分钟就能分辨出来。注意回放文件里既有画面负载也有控制指令落盘前把令牌和坐标之外的用户数据脱敏日志留着方便排查但也别让它变成新的风险点。这套日志机制我现在已经变成条件反射了——任何一次卡一下的反馈先要一份回放文件再谈优化绝不靠感觉改参数。从那以后我每次调完编码参数都强制走一遍采集、编码、发送三段 p95 对比确认瓶颈真的挪走了才收工。希望帮到你。本文还有配套的精品资源点击获取