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开发人员。 潜在答案 人们回复后将对此进行更新。 我的想法是，首先，TeamViewer具有很好的网络控制。例如，他们将大数据包拆分为MTU大小以下，并且从不浪费行程。他们可能有各种各样的花哨的钩子来检测屏幕变化以及非常快的XOR图像比较。