TeamViewer 怎么会这么快？

抱歉长了点，这是必须的。

简介

我正在用 C # 4.0为 Windows Vista/7开发一个远程桌面软件(只是为了好玩)。我已经克服了一些基本的障碍: 我有一个强大的 UDP 消息系统，相对简洁的程序设计，我有一个镜像驱动程序(来自 DemoForge 的免费 DFMirage 镜像驱动程序) ，我已经实现了除对称 NAT (存在于企业防火墙情况下)以外的所有 NAT 类型的 NAT 遍历。

关于屏幕传输/共享，多亏了镜像驱动程序，我会自动获得屏幕区域变化的通知，我可以简单地将镜像驱动程序不断变化的屏幕位图编组到我自己的位图中。然后我将屏幕区域压缩为 PNG 格式，并将其从服务器发送到我的客户端。情况看起来不错，但还不够快。它和 VNC 一样慢(顺便说一下，我没有使用 VNC 协议，只是一个自定义的业余协议)。

从速度最慢的远程桌面软件到速度最快的，列表通常从所有类似 VNC 的实现开始，然后爬到 Microsoft Windows Remote Desktop... 然后... TeamViewer。不太确定是否使用 CrossLoop，LogMeIn-我没有使用过它们，但 TeamViewer 是 疯狂的快速浏览器。简直就是现场直播。我在命令提示符上运行了 tree命令，它更新了20毫秒的延迟。我浏览网页的速度只比笔记本电脑慢几毫秒。在 VisualStudio 中垂直滚动代码有50毫秒的延迟时间。考虑一下 TeamViewer 的屏幕传输解决方案必须有多强大才能完成所有这些工作。

VNC 使用基于轮询的钩子来检测屏幕变化，并在最糟糕的情况下强行捕捉/比较屏幕。在最好的情况下，他们使用像 DFMirage 这样的镜像驱动程序。我已经到这个水平了。他们使用 RFB 协议。

MicrosoftWindowsRemoteDesktop 显然比 VNC 高一级。我从 StackOverflow 的某个地方听说，Windows 远程桌面不发送屏幕位图，而是发送实际的绘图命令。这是相当辉煌的，因为它可以只发送简单的文本(绘制这个矩形在这个坐标和颜色与这个渐变) ！远程桌面确实非常快，而且是在家工作的标准方式。它使用了 RDP 协议。

现在 TeamViewer 对我来说完全是个谜。显然，他们发布了版本2的源代码(TeamViewer 是2012年2月的版本7)。人们已经读过它，并且说版本2是无用的——它只是对带有自动 NAT 遍历的 VNC 的一些改进。

但是第七版... 现在快得离谱。我的意思是，它实际上比 Windows 远程桌面更快。我用 TeamViewer 流媒体播放 DirectX 3D 游戏(1fps，但 Windows 远程桌面甚至不允许 DirectX 运行)。

顺便说一下，TeamViewer 所做的这一切 没有镜像驱动程序。有一个选项来安装一个，它只是得到了一点点快速。

问题

我的问题是 TeamViewer 怎么会这么快？这是不可能的。如果在24位深度(16位深度将是明显的丑陋)下得到1920 × 1080分辨率，那仍然是6,220,800字节的原始数据。即使使用 libjpeg-turbo (大公司使用的最快的 JPG 压缩库之一) ，将其压缩到30KB (让我们非常慷慨地) ，也需要花费时间通过 TeamViewer 的服务器(TeamViewer 绕过公司的对称 NAT，通过简单地代理服务器的流量)。而且 libjpeg-turbo 压缩需要时间来压缩。高质量的 JPG 压缩需要175毫秒的完整1920年由1080截图为我。如果主机的计算机运行 Atom 处理器，这个数字就会上升。我只是不明白 TeamViewer 是如何优化他们的屏幕传输的。同样，小尺寸图像可能被高度压缩，但压缩至少需要几十毫秒。大尺寸的图像不需要时间压缩，但需要很长的时间才能看完。不知何故，TeamViewer 完成了整个过程，得到了大约20-25个帧率。我使用了网络监视器，TeamViewer 在500Kbps 和1Mbps 的速度下仍然没有延迟(在这种传输速率下，VNC 软件会延迟几秒钟)。在我的 tree命令提示符测试期间，TeamViewer 以1Mbps 的速率接收入站数据，并且仍然运行5-6fps。VNC 和远程桌面不这样做。那么，怎么做？

答案会有点复杂和错综复杂，所以 如果你只是想说因为他们使用 UDP 而不是 TCP，请不要发布你的 $0.02(你会相信他们实际上使用 TCP 一样成功)。

我希望在 StackOverflow 上有一个 TeamViewer 开发人员。

潜在答案

人们回复后会更新这个。

  1. 首先，我认为 TeamViewer 具有非常好的网络控制能力。例如，它们将大数据包分割到刚好低于 MTU 大小，并且从不浪费行程。他们可能有各种各样的奇特的钩子来检测屏幕变化以及极快的异或图像比较。
155178 次浏览
小开
最佳答案

这里最基本的事情可能是您不希望传输静态图像，而只希望向图像传输 改变，这在本质上类似于 视频流。

我最好的猜测是一些非常有效的(并且非常专业化和优化的)运动补偿算法，因为通用桌面使用的大部分实际变化是 线性的元素的移动(滚动文本、移动窗口等等，与元素的转换相反)。

1 FPS 的 DirectX 3D 性能似乎在一定程度上证实了我的猜测。

小开

通过 TeamViewer 的服务器路由需要时间(TeamViewer 通过简单地代理服务器的流量来绕过公司的对称 NAT)

您会发现 TeamViewer 很少需要通过自己的服务器转发流量。TeamViewer 使用 NAT 遍历渗透 NAT 和因 NAT 而变得复杂的网络(我认为它是 UDP 冲孔，就像 谷歌的即兴广告词)。

他们确实使用自己的服务器来做中间人的握手和连接设置，但大多数时候客户端和服务器之间的关系将是 P2P (最好的情况下，当握手是成功的)。如果 NAT 遍历失败，那么 TeamViewer 确实会通过自己的服务器转发流量。

不过我只见过有客户支持双重 NAT 的时候才会这样。

小开

奇怪的是。但根据我的经验，TeamViewer 并不比 VNC 更快/响应更快，只是更容易设置。我有几个 win-box，我在 OpenVPN 上安装了 VNC (这样就有了另一个开销层) ，它是在廉价的 Cable (512 up)上安装的，我发现正确地安装 TightVNC 比 TeamViewer 对同一个 box 的响应要快得多。RDP (自然)更是如此，因为它大部分发送 GUI 绘图命令而不是位图块。

这让我们想到:

  1. 你为什么不使用 VNC? 有太多的开放源码 解决方案，而 Tight 现在可能处于游戏的顶端

  2. 高级 VNC 实现使用有损数据压缩，这似乎可以实现 比你选择的 PNG 效果更好。另外，IIRC 的其余有效载荷也是 使用 zlib 压缩。Tight 和 UltraVNC 都有非常优化的算法，尤其是针对窗口的算法。除此之外，Tight 还是开源的。

  3. 如果 win boxen 是您的主要目标，那么 RDP 可能是一个更好的选择，并且有一个开源实现(rdesk)

  4. 如果 * nix boxen 是您的主要目标，那么 NX 可能是一个更好的选择，它有一个开源实现(FreeNX，尽管没有 NoMachine 的专有产品那么优化)。

如果压缩 JPEG 对于算法来说是一个性能问题，我很确定图像比较仍然会带走一些性能。我敢打赌，他们使用最好的情况下压缩每一个特定的情况，即损失的大帧，一些快速和肮脏的内部损失较小的，比较位的图像和发送只有差异的排序和一堆其他优化技巧。

在 Tight > 2.0中一定有很多这样的技巧，因为根据我的经验，它比 TeamViewer 的 YMMV 性能好得多。

此外，选择 JIT 编译运行时而不是 C + + 可能会削弱你的性能优势，尤其是在内存受限的机器上(当 windows 开始大量使用页面文件时，许多性能调优就会失灵)。而且你将需要记忆保持以前的图像状态内部比较什么 DF 海市蜃楼给你之上。

小开

正如有人建议的那样，这听起来确实更像是视频流，而不是图像流。 JPEG/PNG 压缩不适合这种速度，所以忘了它们吧。

想象一下，在您的系统上有一个可以实时记录输入视频流(您的屏幕)的记录编解码器。也许有点像 Fraps。然后想象另一端(远程客户端)的视频播放编解码器。 正如高清录像机可以做到这一点(记录现场，甚至播放现场从同一高清) ，所以应该你，在结束。高清显示器肯定不能比你阅读显示器的速度更快地传输图像，所以这不是瓶颈。瓶颈是视频解码器。你会发现编码器比解码器的问题更多，因为所有的解码器大多是免费的。

我并不是说它很简单; 我自己曾经使用 DirectShow 对一个视频文件进行编码，到目前为止它还不是实时的。但是只要有正确的解码器，我相信它可以工作。

小开

我的随机猜测是: TV 使用具有商业许可证的 X264编解码器(否则 TeamViewer 将不得不发布他们的源代码)。在某个时候(超过5年前) ，我记得 x264的主要开发人员写了一篇文章，关于他对低延迟编码的改进(如果你延迟几帧编码器可以压缩得更好) ，另外他还提到了一些其他的改进，这些改进与 TeamViewer 类似的应用相关。在那篇文章中，他提到通过视频流播放地震没有明显的问题。当时我有点确定谁是这些改进的赞助商，因为当时 TeamViewer 几乎是唯一的选择。X264是 H264视频编解码器的一个开源实现，它是非常好的实现，是最好的一个。同时，它的优化非常好。很可能是由于 x264的实现非常好，所以在较低的 CPU 负载下使用 TV 可以获得更好的结果。AnyDesk 和 ChromeRemote Desk 使用 libvpx，它不如 x264(在优化和视频质量方面)。

然而，我不认为 TeamView 能够打败微软的 RDP。对我来说，它是最好的，但它只能在 Windows PC 之间或从 Mac 到 Windows 之间工作。电视甚至可以通过手机工作。

更新: 文章写于2010年1月，所以这项工作大约是在10年前完成的。而且，我犯了一个错误: 他玩的是使命召唤，而不是地震。当你发布你的问题，如果我的猜测是正确的，TeamViewer 已经使用了3年的工作。 阅读网络档案中的那篇博文: X264: 世界上最好的低延迟视频流平台。当我在2010年读到这篇文章时，我确信作者提到的“已经要求匿名的创业公司”就是 TeamViewer。


提交答案