TeamViewer 怎么这么快？

Posted 2023-02-16

【中文标题】TeamViewer 怎么这么快？

【英文标题】：How is TeamViewer so fast?

【发布时间】：2012-03-18 22:11:21

【问题描述】：

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

简介

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

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

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

顺便说一下，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 也一样成功）。

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

可能的答案

有人回复后会更新。

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

【问题讨论】：

您是否尝试过对协议进行逆向工程？ （似乎他们使用 PKI 进行会话设置，所以如果可行的话，这可能并不容易）

期待这个问题的答案取决于公司是否愿意分享他们的商业秘密。他们的首要任务，就是让他们继续营业的那个。你有一个强烈的不，得到一个是的唯一方法就是打电话给他们。我想问问他们的专利。

这很奇怪。我自己并不觉得它比远程桌面快 - 远非如此！ RDP 对我来说 WAY 更快 - 更像是使用本地虚拟机。您实际上是通过 Internet 还是在某种本地设置上进行测试？您是否打开了防火墙以允许直接连接 teamviewer？

似乎您只是在本地网络上进行测试。根据我的经验，TeamViewer 似乎使用了有损压缩（通过慢速连接，质量有时真的很差）。会不会是 VNC 比 TeamViewer 使用更多的处理时间和更少的带宽，反之亦然？然后根据您的环境（两台机器上的处理器能力和网络链接的质量），有时 VNC 可能会更快，有时 TeamViewer。

不，我不只是在本地网络上测试。

【参考方案1】：

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

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

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

【讨论】：

这里有免费的 TechSmith 屏幕捕获编解码器。压缩效率高且无损。

TechSmith 网站提供 2 个免费解码器供下载。但单独使用它们是无用的，因为屏幕录像机软件很昂贵。

【参考方案2】：

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

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

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

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

【讨论】：

很少有企业防火墙允许 NAT 穿越或 UPnP，但这是 TeamViewers 的主要市场。我怀疑大多数连接都是在现实生活中中继的......

有时您甚至可以通过企业防火墙/NAT“推动自己的方式”——Skype 在这方面非常擅长。基本上，客户端 A 发出将被 NAT/防火墙阻止的请求，并通知外部服务器使用的端口。客户端 B 然后从外部服务器获取有关端口的信息并连接到该端口。 A 的 NAT 会认为这是对第一个请求的回复（确实被 B 的 NAT 阻止）并让它通过。当 A 在该连接上应答时，B 的 NAT 将允许它通过，因为连接是由 B 发起的。=> 你有一个连接。

许多公司只有 http 代理，根本没有 NAT 和路由到外部。 Teamviewer 通过 http 端口 443 建立隧道。那是 tcp，teamviewer 仍然快得要命。

@Daniel：首先阅读***上有关“UDP打孔”和“STUN”的文章。

@DanielLiuzzi Google 的开源 libjingle 包含一个打孔器：developers.google.com/talk/libjingle/developer_guide。他们曾经（并且可能仍然这样做，我不知道）将它用于 GChat、环聊等。

【参考方案3】：

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

这让我们：

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

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

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

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

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

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

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

【讨论】：

当人们建议使用 VNC 作为 TeamViewer 的替代品时，我感到很恼火。我建议您可能没有使用 TeamViewer 来了解它相对于 VNC 等免费软件的优势？ VNC 可能可以访问您自己的计算机，但对于屏幕共享和主持会议等，它甚至无法进行模糊比较。上次我检查时，VNC 甚至没有任何开放的中继服务器，因此它甚至在 95% 的情况下都无法工作，因为它会被防火墙屏蔽（除非您拥有并操作自己的防火墙或服务器）。

讨论不是关于 VNC 客户端工具与 TeamViewer（我每天都广泛使用这两种工具，但我确实操作了很多防火墙和服务器并且拥有不少）。讨论是关于协议的内部工作和实现它们

刚刚在慢速 3G 网络上尝试了 UltraVNC 和 TeamViewer，性能差异很大。使用 UltraVNC，我在单击远程计算机上的某些内容和看到响应之间经历了 1-2 秒的延迟。迟缓有用。 TeamViewer 速度更快（与 RDP 一样快）并且速度足够快，可以在同一链接上使用。

我收到的关于这个答案的 cmets 真的很荒谬。在 VNC 客户端开发 4 到 5 年后，人们几乎停止了（并且 TeamViewer 不断投入大量开发资源来微调他们的软件），并且完全忽略了我的建议的要点，而不是重新发明***（作为软件DEVELOPER NOT USER) 最好从开源 VNC 实现开始，然后从那里开始至少获得一些（少量）地面，例如 TeamViewer，而不是从 0 行代码中删除它。

【参考方案4】：

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

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

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

【参考方案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。

【讨论】：

您确定 AnyDesk 使用 libvpx 吗？他们将 DeskRT 宣传为自己专为桌面环境设计的编解码器。