对于长度感到抱歉，这是必要的。
简介
我正在使用C＃4.0 for Windows Vista / 7开发远程桌面软件（只是为了好玩）。我已经遇到了基本障碍：我有一个强大的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版没用 - 它只是对VNC进行自动NAT遍历的一些改进。
但版本7 ......现在它的速度非常快。我的意思是，它实际上比Windows远程桌面更快。我使用TeamViewer流式传输DirectX 3D游戏（1 fps，但Windows远程桌面甚至不允许DirectX运行）。
顺便说一下，TeamViewer在没有镜像驱动程序的情况下完成了所有这些。有一个选项可以安装一个，它会更快一些。
问题
我的问题是，TeamViewer如此快速？一定不可能。如果您在甚至24位深度（16位深度显然很难看）的情况下获得1920×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就像成功一样）。
我希望StackOverflow上有TeamViewer开发人员。
潜在答案
一旦人们回复，我们会更新。
答案 0 :(得分：75)
这里最基本的可能是你不想传输静态图像，只有更改到图像，这基本上类似于视频流。 / p>
我最好的猜测是一些非常有效（并且经过大量专业化和优化）的运动补偿算法，因为通用桌面使用的大多数实际变化是元素的线性运动（滚动文本，移动窗口，等反对元素的转换。）
1 FPS的DirectX 3D性能似乎在一定程度上证实了我的猜测。
答案 1 :(得分：22)
需要时间来路由TeamViewer的服务器（TeamViewer通过简单地通过服务器代理流量来绕过企业对称NAT）
您会发现TeamViewer很少需要通过自己的服务器中继流量。 TeamViewer使用NAT遍历渗透NAT和NAT复杂的网络（我认为它是UDP hole-punching，如Google's libjingle）。
他们确实使用自己的服务器给中间人进行握手和连接设置，但大多数时候客户端和服务器之间的关系都是P2P（最好的情况是握手成功时） ）。如果NAT遍历失败，那么TeamViewer确实会通过自己的服务器中继流量。
但是，当客户端支持双NAT时，我才见过它。
答案 2 :(得分：13)
有点迟到的答案，但我建议您查看一个名为ConferenceXP
的codeplex上一个不为人知的项目ConferenceXP是一个开源研究平台，提供简单， 灵活，可扩展的会议和协作使用 高带宽网络和先进的多媒体功能 微软Windows。 ConferenceXP帮助研究人员和教育工作者 开发具有创新性的应用和解决方案 广播质量的音频和视频，支持实时分发 合作和远程学习环境。
提供完整的源（它很大！）。它实现了RTP protocol。
答案 3 :(得分：6)
有人建议，这听起来确实比视频流更像图像流。 JPEG / PNG压缩不是针对这些类型的速度，所以请忘记它们。
想象一下，在您的系统上有一个可以实时记录传入视频流（您的屏幕）的录制编解码器。有点像Fraps。然后想象一下另一侧的视频播放编解码器（远程客户端）。 由于高清录像机可以做到这一点（实时录制，甚至可以从同一个高清播放），最后也应如此。 HD肯定无法比您阅读显示器更快地提供图像，因此这不是瓶颈。瓶颈是视频编解码器。你会发现编码器比解码器更容易出问题，因为所有的解码器都是免费的。
我不是说这很简单;我自己使用DirectShow对视频文件进行编码，到目前为止还不是实时的。但是如果使用正确的编解码器，我确信它可以工作。
答案 4 :(得分：1)
奇怪。但根据我的经验，TeamViewer并不比VNC更快/响应更快，只是更容易设置。我有一些win-boxen，我通过OpenVPN VNC进入（所以有另一个开销层），这是在廉价的电缆（512上），我发现正确设置TightVNC比TeamViewer更响应相同的boxen。 RDP（自然地）更是如此，因为很大一部分它发送GUI绘图命令而不是位图贴图。
这将我们带到：
你为什么不使用VNC？有太多的开源 解决方案，而Tight现在可能就在它的游戏之上了。
高级VNC实现使用有损压缩，似乎可以实现 比您选择的PNG更好的结果。此外，IIRC剩余的有效载荷也是 用zlib压扁。 Bothj Tight和UltraVNC都有非常优化的算法，特别是对于Windows。最重要的是，Tight是开源的。
如果win boxen是您的主要目标，RDP可能是更好的选择，并且有一个开源实现（rdesktop）
如果* nix boxen是您的主要目标，NX可能是更好的选择并且具有开源实现（FreeNX，尽管不像NoMachine的专有产品那样优化）。
如果压缩JPEG是你的算法的一个性能问题，我很确定图像比较仍然会带走一些性能。我敢打赌他们会针对每种特定情况使用最佳情况压缩，即对于大型帧有损耗，对于较小的帧有些快速和脏的内部无效，比较图像的比特并仅发送排序差异和一堆其他优化技巧。
很多这些技巧必须出现在Tight＆gt; 2.0再次，根据我的经验，它击败了TeamViewer性能wyse，YMMV。
对于像C ++这样的JIT编译运行时的选择可能会从性能优势中获得一些优势，特别是在内存受限的机器中（当Windows开始密集使用页面文件时，很多性能调整都会进入厕所）。而且你需要记忆来保留以前的图像状态，以便在海市蜃楼为你提供内部比较。
答案 5 :(得分：0)
我的随机猜测是：电视使用具有商业许可证的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。