那只总慢半拍的鼠标：远程协作技术里的延迟账本

周三下午，评审会。我共享屏幕，鼠标从“通过”挪到“驳回”，那条箭头在后面追了半秒。对面同事说，你手抖？我手没抖。是远程协作技术在中间喘了口气。

这半秒很烦。更烦的是白板。你画一条线，笔尖到了，线还没到。等线到了，你已经画到下一笔。于是两个人对着屏幕互相等。说实话，远程协作技术最容易被忽略的，不是能不能连上，而是连上之后那点延迟怎么分配。

延迟不是一根管子，是一串收费站

很多人以为延迟就是网速。带宽像水管，管子粗就快。不对。带宽决定“一次能搬多少”，延迟决定“搬一趟要多久”。你家里千兆，照样可能卡成幻灯片。为什么？画面从你屏幕到对方屏幕，中间要过采集、编码、传输、转发、解码、渲染。每一站都收一点时间。

采集先来一刀。屏幕共享不是截屏一次就完事，它是连续抓帧。抓快了，CPU 喊疼；抓慢了，鼠标轨迹就断。编码再砍一刀。视频编码把画面切成块，找前后帧的相似处。关键帧像整箱快递，I 帧；后续帧像补丁，P 帧、B 帧。补丁便宜，但依赖前面的箱子。丢一个关键帧，后面一串都懵。

传输这站最看网络脸色。RTP 走 UDP，图的是快，不保证到。丢了怎么办？NACK 让发送端重传，FEC 提前塞冗余包。听起来稳，可重传要往返时间。RTT 五十毫秒，重传一次就多五十。你等得起吗？白板笔迹等不起。

转发是会议里的大头。多人会议不是你把流发给每个人就完事。上行带宽先炸。于是有了 SFU，选择性转发单元。每个人把流发给服务器，服务器挑着转发。它不混流，只转发，CPU 省，但下行带宽涨。MCU 会混流，服务器把多路画面拼成一路，终端省带宽，服务器累。P2P 是网状，小会省钱，大会把上行打穿。对吧，技术选型不是比谁高级，是看你的会开多大、网有多烂、预算有多紧。

还有个细节：鼠标光标常常不在视频画面里。很多系统把光标单独渲染，本地显示，远端叠加。你看到的拖影，有时不是视频帧率，是坐标同步频率。光标坐标走数据通道，视频画面走媒体通道。两条流不同步，箭头就会像喝多了。

屏幕共享还分“抓屏”和“窗口捕获”。抓屏抓整个桌面，窗口捕获只抓一个窗口。前者简单，后者省资源。但窗口捕获遇到硬件加速渲染，可能抓到黑屏。你以为是远程协作技术坏了，其实是显卡和捕获 API 打架。

白板笔迹和视频会议，脾气不一样

视频会议可以容忍一点糊。你眨眼，画面糊一下，大脑能补。白板笔迹不行。笔迹是交互，是“我画你猜”。延迟超过一百多毫秒，人就觉得笔不跟手。超过两百，两个人会抢笔。这里的关键不是清晰度，是端到端交互延迟。

所以很多远程协作技术把白板单独抽出来。笔迹走数据通道，WebRTC 的 DataChannel，可靠或部分可靠。视频走媒体通道，可以降分辨率、降帧率。两条路，不同脾气。你把白板塞进视频流里共享，等于让笔迹坐卡车。能到，但慢。

我见过一个团队，白板卡顿，第一反应是升带宽。升完还卡。后来发现是共享的是 4K 屏幕，编码器每帧都在啃硬骨头。降到 1080p，限制帧率，笔迹立刻顺了。不是带宽不够，是编码器忙不过来。这个坑很常见。

低延迟的代价：宁可糊一下，也别卡住

实时协作有个残酷取舍：延迟和可靠性打架时，实时系统通常先保延迟。视频会议丢一帧，你未必发现；等重传三百毫秒，所有人都发现。于是拥塞控制上场。WebRTC 里常见 GCC，谷歌拥塞控制，靠延迟梯度和丢包估带宽。估高了，排队延迟涨；估低了，画面糊。它像个司机，一边踩油门一边看后视镜。

还有个误解：分辨率越高越专业。错。共享代码、共享表格，文字边缘要清楚，但帧率可以低。共享操作演示，帧率要稳，分辨率可以让。你把两者都拉满，编码器、网络、终端一起喘。最后用户体验不是“清晰”，是“一顿一顿的清晰”。

安全这块也别装看不见。远程协作技术把屏幕、麦克风、摄像头、文件传输全串起来。SFU 转发意味着媒体流经过服务端。端到端加密怎么做，密钥谁管，录制谁授权，都是边界。别等出事再补条款。

所以下次你看到那只慢半拍的鼠标，别只骂网。它背后是一串收费站：采集在赶，编码在算，网络在排队，服务器在转发，解码在追。远程协作技术不是魔法，它是一笔延迟账本。你能做的，是别让每一站都超支。