TeamViewer 怎么这么快？

Question

抱歉篇幅太长，有点必要。

简介

我正在为 Windows Vista/7 使用 C# 4.0 开发远程桌面软件（只是为了好玩）。我已经克服了一些基本障碍：我有一个强大的 UDP 消息传递系统，相对干净的程序设计，我有一个镜像驱动程序（来自 DemoForge 的免费 DFMirage 镜像驱动程序）启动并运行，我已经为所有人实现了 NAT 遍历NAT 类型，除了对称 NAT（存在于公司防火墙情况中）。

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

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

VNC 使用基于轮询的挂钩来检测屏幕变化，并在最糟糕的情况下进行暴力屏幕捕获/比较。在他们最好的情况下，他们使用像 DFMirage 这样的镜像驱动程序。我就是这个水平。他们使用一种叫做 RFB 协议的东西。

Microsoft Windows 远程桌面显然比 VNC 高出一步。我从 StackOverflow 的某个地方听说 Windows 远程桌面不发送屏幕位图，而是发送实际的绘图命令。这非常棒，因为它可以只发送简单的文本（在这个坐标处绘制这个矩形并用这个渐变着色）！远程桌面确实非常快 - 它是在家工作的标准方式。它使用称为 RDP 协议的东西。

现在 TeamViewer 对我来说完全是个谜。显然，他们发布了版本 2 的源代码（截至 2012 年 2 月，TeamViewer 是版本 7）。人们读过它并说第 2 版毫无用处 - 它只是对具有自动 NAT 遍历的 VNC 的一些改进。

但是第 7 版……现在速度快得离谱了。我的意思是，它实际上比 Windows 远程桌面更快。我已经使用 TeamViewer 流式传输 DirectX 3D 游戏（速度为 1 fps，但 Windows 远程桌面甚至不允许 DirectX 运行）。

顺便说一下，TeamViewer在没有镜像驱动程序的情况下完成了所有这些工作。有一个安装选项，它会更快一点。

问题

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

答案会有些复杂和错综复杂，所以如果你只想说这是因为他们使用 UDP 而不是 TCP，请不要发布你的 0.02 美元（你相信他们真的会这样做吗？使用 TCP 也一样成功）。

我希望 StackOverflow 上的某个地方有 TeamViewer 开发人员。

可能的答案

有人回复后会更新。

1. 我的想法是，首先，TeamViewer 具有非常精细的网络控制。例如，他们将大数据包拆分为刚好低于 MTU 大小，并且从不浪费行程。他们可能有各种花哨的钩子来检测屏幕变化以及极快的 XOR 图像比较。

Answer 1

这里最基本的可能是您不想传输静态图像，而只是更改图像，这本质上类似于视频流。

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

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

Answer 2

通过 TeamViewer 的服务器进行路由需要时间（TeamViewer 通过简单地代理通过其服务器的流量来绕过公司的对称 NAT）

您会发现 TeamViewer 很少需要通过自己的服务器中继流量。 TeamViewer 使用 NAT 遍历穿透 NAT 和 NAT 复杂的网络（我认为是UDP hole-punching，如Google's libjingle）。

他们确实使用自己的服务器作为中间人来进行握手和连接设置，但大多数时候客户端和服务器之间的关系将是 P2P（最好的情况是握手成功时） ）。如果 NAT 穿越失败，TeamViewer 确实会通过自己的服务器中继流量。

不过，我只见过它在客户端使用双 NAT 时这样做。

Answer 3

奇怪。但根据我的经验，TeamViewer 并不比 VNC 更快/响应更快，只是更容易设置。我有几个 win-boxen，我通过 OpenVPN 进行 VNC 进入（因此还有另一个开销层），这是在便宜的 Cable（512 以上）上，我发现正确设置 TightVNC 比 TeamViewer 对同一个 boxen 的响应要快得多。 RDP（自然）更是如此，因为它在很大程度上发送 GUI 绘制命令而不是位图图块。

这让我们：

1. 为什么不使用 VNC？有大量的开源 解决方案，而 Tight 现在可能处于领先地位。

2. 高级 VNC 实现使用有损压缩，这似乎可以实现 比您选择的 PNG 效果更好。此外，IIRC 的其余有效载荷也是 使用 zlib 压缩。 J Tight 和 UltraVNC 都有非常优化的算法，尤其是对于 windows。最重要的是，Tight 是开源的。

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

4. 如果 *nix boxen 是您的主要目标，NX 可能是更好的选择，并且具有开源实现（FreeNX，尽管不如 NoMachine 的专有产品优化）。

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

Tight > 2.0 中必须包含许多这些技巧，因为根据我的经验，它再次击败了 TeamViewer 性能方面的地狱，YMMV。

此外，选择 JIT 编译的运行时而不是 C++ 之类的东西可能会降低性能优势，尤其是在内存受限的机器中（当 Windows 开始大量使用页面文件时，很多性能调整都会落到马桶上）。而且您需要内存来保持之前的图像状态，以便在 DF mirage 提供给您的基础上进行内部比较。

Answer 4

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

想象一下，您的系统上有一个录制编解码器，可以实时录制传入的视频流（您的屏幕）。可能有点像 Fraps。然后想象另一端（远程客户端）的视频播放编解码器。 正如高清录像机可以做到的那样（实时录制，甚至从同一个高清实时回放），你也应该这样做。高清肯定不能比您阅读显示器更快地提供图像，所以这不是瓶颈。瓶颈是视频编解码器。你会发现编码器比解码器更成问题，因为所有解码器大部分都是免费的。

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

Answer 5

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

但是，我认为 TeamView 无法击败微软的 RDP。对我来说这是最好的，但它只能在 Windows PC 之间或从 Mac 到 Windows 之间工作。甚至可以通过手机观看电视。

更新：文章写于 2010 年 1 月，因此这项工作大约在 10 年前完成。另外，我犯了一个错误：他玩的是使命召唤，而不是地震。当您发布您的问题时，如果我的猜测是正确的，那么 TeamViewer 已经使用该工作 3 年了。 从网络档案中阅读该博客文章：x264: the best low-latency video streaming platform in the world。当我在 2010 年读到这篇文章时，我确信作者提到的“要求不具名的初创公司”就是 TeamViewer。