TeamViewer有多快？

抱歉，长度太长了。

介绍

我正在Windows Vista / 7的C＃4.0中开发远程桌面软件（只是为了好玩）。我已经克服了一些基本的障碍：我拥有一个健壮的UDP消息传递系统，相对简洁的程序设计，一个镜像驱动程序（DemoForge提供的免费DFMirage镜像驱动程序）已启动并正在运行，并且我已为所有实现了NAT遍历对称NAT除外的NAT类型（存在于公司防火墙中）。

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

从最慢的远程桌面软件到最快的远程桌面软件，该列表通常从所有类似VNC的实现开始，然后攀升至Microsoft Windows Remote Desktop ...然后是... TeamViewer。对于CrossLoop和LogMeIn不太清楚-我没有使用过它们，但是TeamViewer的速度非常快。从字面上看，它是真实的。我tree在命令提示符下运行了一条命令，并以20毫秒的延迟进行了更新。我可以比笔记本电脑慢几毫秒来浏览网页。在Visual Studio中垂直滚动代码的延迟时间为50毫秒。考虑一下要完成所有这些工作，TeamViewer的屏幕传输解决方案必须多么强大。

VNC使用基于轮询的挂钩来检测屏幕变化，并在最坏的情况下进行暴力屏幕捕获/比较。在最佳状态下，他们使用DFMirage之类的镜像驱动程序。我在这个水平上。他们使用了称为RFB协议的协议。

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

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

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

顺便说一句，TeamViewer 无需镜像驱动程序即可完成所有这些操作。可以选择安装一个，但速度会更快一点。

问题

我的问题是，TeamViewer怎么这么快？一定不可能。如果您即使在24位深度（16位深度也很丑陋）下都具有1920 x 1080分辨率，那仍然是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（请相信他们实际上确实确实使用TCP确实成功），请不要发布0.02美元。

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

潜在答案

人们回复后将对此进行更新。

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

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

我的最佳猜测是一些非常有效的（并且经过专门化和优化的）运动补偿算法，因为通用桌面使用中的大多数实际变化是元素的线性移动（滚动文本，移动窗口等，而不是元素转换）。

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

在TeamViewer的服务器之间路由将花费一些时间（TeamViewer通过简单地代理通过其服务器的流量来绕过公司的对称NAT）。

您会发现TeamViewer很少需要通过自己的服务器中继流量。TeamViewer使用NAT遍历来渗透NAT和复杂的NAT网络（我认为这是UDP漏洞打孔，就像Google的libjingle一样）。

他们确实使用自己的服务器与中间人进行握手和建立连接，但是大多数情况下，客户端和服务器之间的关系将是P2P（最好的情况是，握手成功后）。如果NAT穿越失败，那么TeamViewer确实将通过其自己的服务器中继流量。

不过，我只有在客户端位于双NAT之后才看到它这样做。

答案有点晚了，但是我建议您看一下一个不知名的关于Codeplex的项目，名为ConferenceXP

ConferenceXP是一个开放源代码研究平台，它使用高带宽网络和Microsoft Windows的高级多媒体功能提供了简单，灵活和可扩展的会议和协作。ConferenceXP帮助研究人员和教育工作者开发具有广播质量的音频和视频的创新应用程序和解决方案，以支持实时分布式协作和远程学习环境。

提供了完整的源代码（非常庞大！）。它实现了RTP协议。

就像有人建议的那样，听起来确实像是视频流而不是图像流。JPEG / PNG压缩不适用于这些类型的速度，因此请不要理会它们。

想象一下，您的系统上有一个可以实时记录传入视频流（您的屏幕）的记录编解码器。也许有点像Fraps。然后想象另一端（远程客户端）上的视频播放编解码器。就像高清录像机可以做到的那样（从同一高清实时录制甚至实时回放），最后您也应该这样做。HD肯定无法以比您阅读显示器更快的速度传送图像，因此这不是瓶颈。瓶颈是视频编解码器。您会发现编码器比解码器更多的是问题，因为所有解码器都是免费的。

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

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

但是，我认为TeamView无法击败微软的RDP。对我来说，这是最好的，但是它只能在Windows PC或Mac和Windows之间运行。电视甚至可以在手机上播放。

更新：文章写于2010年1月，因此这项工作大约在10年前完成。另外，我犯了一个错误：他扮演了使命召唤，而不是地震。当您发布问题时，如果我的猜测是正确的，TeamViewer已经使用该作品3年了。阅读来自网络档案馆的博客文章：x264：世界上最好的低延迟视频流平台。当我在2010年阅读该文章时，我确定作者提到的“要求匿名的启动”是TeamViewer。

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

这使我们能够：

1. 为什么不使用VNC？有很多开源解决方案，而Tight可能现在就处于游戏的顶端。

2. 先进的VNC实施使用有损压缩，这似乎比您选择的PNG可获得更好的结果。另外，IIRC的其余有效负载也使用zlib压缩。Tight和UltraVNC都具有非常优化的算法，尤其是对于Windows。最重要的是，Tight是开源的。

3. 如果将win boxen作为主要目标，则RDP可能是一个更好的选择，并且具有开源实现（rdesktop）

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

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

而且从那时起，在Tight> 2.0中必须存在许多这些技巧，以我的经验，它击败了TeamViewer性能wyse YMMV。

同样，选择CIT之类的JIT编译运行时可能会降低性能，特别是在内存受限制的机器中（当Windows开始大量使用页面文件时，很多性能调整都进入了洗手间）。而且，您将需要内存来保持先前的图像状态，以便在DF Mirage给您提供的内容之上进行内部比较。