TeamViewer如此之快？
对不起长度，这是有必要的。
介绍
我正在为Windows Vista / 7在C＃4.0中开发一个远程桌面软件（只是为了好玩）。 我已经经历了一些基本的障碍：我有一个强大的UDP消息传递系统，相对干净的程序devise，我有一个镜像驱动程序（DemoForge的免费DFMirage镜像驱动程序）启动并运行，我已经实现了所有NAT穿越除了对称NAT之外的NATtypes（存在于企业防火墙情况下）。
关于屏幕传输/共享，感谢镜像驱动程序，我自动通知更改的屏幕区域，我可以简单地将镜像驱动程序的不断变化的屏幕位图编组到我自己的位图。 然后我把这个屏幕区域压缩成PNG格式，然后把它从服务器发送到我的客户端。 事情看起来不错，但速度不够快。 它和VNC一样慢（顺便说一句，我没有使用VNC协议，只是一个自定义的业余协议）。
从最慢的远程桌面软件到最快的列表，通常从类似VNC的实现开始，然后爬上Microsoft Windows远程桌面…然后… TeamViewer。 不太确定CrossLoop，LogMeIn – 我没有使用它们，但TeamViewer 非常快速。 这是相当活的。 我在命令提示符下运行了一个tree命令，并且延迟了20毫秒。 我可以在网上浏览网页，比我的笔记本电脑慢几毫秒。 在Visual Studio中垂直滚动代码有50 ms的延迟时间。 考虑一下TeamViewer的屏幕传输解决scheme必须具备的强大function。
VNC使用基于轮询的钩子检测屏幕变化，并在最差的情况下使用powershell屏幕捕获/比较。 在最好的情况下，他们使用像DFMirage这样的镜像驱动程序。 我在这个级别。 他们使用一种叫做RFB协议的东西。
微软Windows远程桌面显然比VNC高一步。 我从StackOverflow的某个地方听说，Windows远程桌面不会发送屏幕位图，而是实际的绘图命令。 这是相当出色的，因为它可以发送简单的文本（在这个坐标上绘制这个矩形，并用这个渐变来着色）！ 远程桌面确实非常快 – 这是在家工作的标准方式。 它使用一种称为RDP协议的东西。
现在，TeamViewer对我来说是一个完整的秘密。 显然，他们发布了版本2的源代码（截至2012年2月，TeamViewer是第7版）。 人们已经读过它，并说版本2是无用的 – 这只是对自动穿越NAT的VNC的一些改进。
但版本7 …现在是很快的。 我的意思是，它实际上比Windows远程桌面更快。 我使用TeamViewer对DirectX 3D游戏进行了stream式处理（每秒1帧，但Windows远程桌面甚至不允许DirectX运行）。
顺便说一下，TeamViewer在没有镜像驱动程序的情况下执行所有操作。 有一个选项来安装一个，它只是快一点。
问题
我的问题是，TeamViewer如此之快？ 这一定是不可能的。 如果你在24位深度上得到1920×1080的分辨率（16位深度会显着难看），那么仍然是6220800字节。 即使使用libjpeg-turbo（大公司使用的最快速的JPG压缩库之一），将其压缩到30KB（让我们非常慷慨），也需要一段时间才能通过TeamViewer的服务器（TeamViewer绕过企业对称NAT，只需通过代理他们的服务器）。 而libjpeg-turbo压缩需要时间来压缩。 高质量的JPG压缩需要175毫秒的完整1920 x 1080的截图对我来说。 如果主机的电脑运行Atom处理器，那么这个数字就会上升。 我简直不明白TeamViewer如何优化他们的屏幕传输。 再次，小尺寸的图像可能被高度压缩，但是至less需要几十毫秒才能压缩。 大尺寸的图像没有时间压缩，但需要很长时间才能完成。 不知何故，TeamViewer完成了整个过程，以大约每秒20-25帧。 我使用了networking监视器，而TeamViewer在速度为500 Kbps和1 Mbps时仍然没有实现（VNC软件在该传输速率上滞后几秒钟）。 在我的tree命令提示符testing期间，TeamViewer以1 Mbps的速率接收入站数据，仍然运行5-6 fps。 VNC和远程桌面不这样做。 又怎样？
答案会有些复杂和错综复杂，所以请不要发布你的$ 0.02，如果你只是说因为他们使用UDP而不是TCP （你是否相信他们实际上使用TCP就像成功一样）。
我希望在StackOverflow上有一个TeamViewer开发者。
潜在的答案
一旦有人回复，会更新这个。
- 我的想法是，首先，TeamViewer具有非常好的networking控制。 例如，他们将大数据包分割到正好小于MTU的大小，并且不会浪费旅程。 他们可能有各种各样的花式钩子来检测屏幕变化以及极快的XOR图像比较。
这里最基本的东西可能是你不想传输静态图像，而只是改变图像，这本质上类似于videostream 。
我最好的猜测是一些非常有效的（并且专门化和优化的）运动补偿algorithm，因为大多数通用桌面使用的实际变化是元素的线性移动（滚动文本，移动窗口等与元素转换相反）。
1 FPS的DirectX 3D性能似乎在一定程度上证实了我的猜测。
将需要一段时间才能通过TeamViewer的服务器（TeamViewer绕过企业对称NAT，只需通过服务器代理通信）
您会发现TeamViewer很less需要通过自己的服务器来传输stream量。 TeamViewer使用NAT遍历渗透NAT和networking复杂的networking（我认为它是UDP穿孔 ，就像Google的libjingle一样 ）。
他们使用自己的服务器为中间人做握手和连接build立，但大多数时候客户端和服务器之间的关系是P2P（最好的情况，当握手成功时）。 如果NAT穿越失败，那么TeamViewer确实会通过自己的服务器中继stream量。
不过，我只见过这样做，当一个客户端已经支持双NAT的时候。
有点迟来的答案，但我build议你看看一个叫做ConferenceXP的不知名的codeplex项目
ConferenceXP是一个开源的研究平台，使用高带宽networking和Microsoft Windows的高级多媒体function提供简单，灵活和可扩展的会议和协作。 ConferenceXP帮助研究人员和教育工作者开发具有广播质量的audio和video的创新应用和解决scheme，以支持实时分布式协作和远程学习环境。
提供完整的源代码（这是巨大的！）。 它实现了RTP协议 。
这听起来确实像videostream而不是像图像stream，正如有人build议的那样。 JPEG / PNG压缩不是针对这些types的速度，所以忘记它们。
想象一下，在您的系统上有一个录音编解码器，可以实时录制传入的videostream（您的屏幕）。 有点像Fraps也许。 然后设想另一端（远程客户端）上的video回放编解码器。 由于高清录像机可以做到这一点（现场录制，甚至从同一个高清现场直播），最终你也应该如此。 HD肯定不能传送图像比读取显示更快，所以这不是瓶颈。 瓶颈是video编解码器。 你会发现编码器比解码器更多的问题，因为所有的解码器都是免费的。
我不是说这很简单， 我自己已经使用DirectShow来编码video文件，并不是实时的。 但是鉴于正确的编解码器我相信它可以工作。
奇怪。 但根据我的经验，TeamViewer不比VNC更快/响应速度更快，而且更容易设置。 我有一个胜利boxen，我VNC over OpenVPN成（所以有另一个开销层），这是在廉价的电缆（512上），我发现正确设置TightVNC比TeamViewer更响应相同boxen。 RDP（自然）更是如此，因为大部分它发送GUI绘制命令，而不是位图瓦片。
这使我们能够：
-
你为什么不使用VNC？ 有太多的开源解决scheme，Tight现在可能已经成为游戏的重头戏了。
-
先进的VNC实现使用有损压缩，这似乎取得比您select的PNG更好的结果。 另外，IIRC其余的有效载荷也使用zlib压扁。 Bothj Tight和UltraVNC都有非常优化的algorithm，尤其是Windows。 最重要的是，Tight是开源的。
-
如果赢Boxen是你的主要目标RDP可能是一个更好的select，并有一个开源的实施（rdesktop）
-
如果* nix boxen是你的主要目标NX可能是一个更好的select，并有一个开源的实现（FreeNX，尽pipe不如NoMachine的专有产品优化）。
如果压缩JPEG是algorithm的性能问题，我敢肯定，图像比较仍然会带走一些性能。 我敢打赌，他们使用最好的情况下压缩每个特定的情况，即有损帧的大帧，一些快速和肮脏的内部无效的较小的，比较图像的位，并只发送各种各样的差异和一堆其他优化技巧。
而且很多技巧必须在Tight> 2.0中出现，从我的经验来看，它胜过了TeamViewer的性能，YMMV。
同样，selectJIT编译的运行时间比C ++还要快，尤其是在内存受限的机器上（当Windows开始使用页面文件时，大量的性能调优都会进入厕所）。 而你将需要记忆来保持先前的图像状态，以便DF海市蜃楼给你的内部比较。
