TeamViewer有多快? [英] How is TeamViewer so fast?

问题描述

很抱歉，长度是必需的.

Sorry about the length, it's kinda necessary.

简介

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

I'm developing a remote desktop software (just for fun) in C# 4.0 for Windows Vista/7. I've gotten through basic obstacles: I have a robust UDP messaging system, relatively clean program design, I've got a mirror driver (the free DFMirage mirror driver from DemoForge) up and running, and I've implemented NAT traversal for all NAT types except Symmetric NATs (present in corporate firewall situations).

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

Regarding screen transfer/sharing, thanks to the mirror driver, I'm automatically notified of changed screen regions and I can simply marshal the mirror driver's ever-changing screen bitmap to my own bitmap. Then I compress the screen region as a PNG and send it off from the server to my client. Things are looking pretty good, but it's not fast enough. It's just as slow as VNC (btw, I don't use the VNC protocol, just a custom amateur protocol).

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

From the slowest remote desktop software to the fastest, the list usually begins at all VNC-like implementations, then climbs up to Microsoft Windows Remote Desktop...and then...TeamViewer. Not quite sure about CrossLoop, LogMeIn - I haven't used them, but TeamViewer is insanely fast. It's quite literally live. I ran a tree command on Command Prompt and it updated with 20 ms delay. I can browse the web just a few milliseconds slower than on my laptop. Scrolling code vertically in Visual Studio has 50 ms lag time. Think about how robust TeamViewer's screen-transfer solution must be to accomplish all this.

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

VNCs use poll-based hooks for detecting screen change and brute force screen capturing/comparing at their worst. At their best, they use a mirror driver like DFMirage. I'm at this level. And they use something called the RFB protocol.

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

Microsoft Windows Remote Desktop apparently goes one step higher than VNC. I heard, from somewhere on StackOverflow, that Windows Remote Desktop doesn't send screen bitmaps, but actual drawing commands. That's quite brilliant, because it can just send simple text (draw this rectangle at this coordinate and color it with this gradient)! Remote Desktop really is pretty fast - and it's the standard way of working from home. And it uses something called the RDP protocol.

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

Now TeamViewer is a complete mystery to me. Apparently, they released their source code for Version 2 (TeamViewer is Version 7 as of February 2012). People have read it and said that Version 2 is useless - that it's just a few improvements over VNC with automatic NAT traversal.

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

But Version 7...it's ridiculously fast now. I mean, it's actually faster than Windows Remote Desktop. I've streamed DirectX 3D games with TeamViewer (at 1 fps, but Windows Remote Desktop doesn't even allow DirectX to run).

顺便说一句，TeamViewer在没有镜像驱动程序的情况下完成了所有这些操作.可以选择安装一个，但安装速度会快一点.

By the way, TeamViewer does all this without a mirror driver. There is an option to install one, and it gets just a bit faster.

问题

我的问题是，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和远程桌面不这样做.那怎么办?

My question is, how is TeamViewer so fast? It must not be possible. If you've got 1920 by 1080 resolution at even 24 bit depth (16 bit depth would be noticeably ugly), thats still 6,220,800 bytes raw. Even using libjpeg-turbo (one of the fastest JPG compression libraries used by large corporations), compressing it down to 30KB (let's be extremely generous), would take time to route through TeamViewer's servers (TeamViewer bypasses corporate Symmetric NATs by simply proxying traffic through their servers). And that libjpeg-turbo compression would take time to compress. High-quality JPG compression takes 175 milliseconds for a full 1920 by 1080 screenshot for me. And that number goes up if the host's computer runs an Atom processor. I simply don't understand how TeamViewer has optimized their screen transfer so well. Again, small-size images might be highly compressed, but take at least tens of milliseconds to compress. Large-size images take no time to compress, but take a long time to get through. Somehow, TeamViewer completes this entire process to get roughly 20-25 frames per second. I've used a network monitor, and TeamViewer is still lagless at speeds of 500 Kbps and 1 Mbps (VNC software lag for a few seconds at that transfer rate). During my tree Command Prompt test, TeamViewer was receiving inbound data at a rate of 1 Mbps and still running 5-6 fps. VNC and remote desktop don't do that. So, how?

答案会有些复杂和复杂，因此如果您只是说这是因为他们使用UDP而不是TCP ，请不要过帐您的$ 0.02(您会相信他们确实会这样做吗?同样成功地使用TCP.)

The answers will be somewhat complicated and intricate, so please don't post your $0.02 if you're only going to say it's because they use UDP instead of TCP (would you believe they actually do use TCP just as successfully though).

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

I'm hoping there's a TeamViewer developer somewhere here on StackOverflow.

潜在答案

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

Will update this once people reply.

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

推荐答案

这里最基本的事情可能是您不想传输静态图像，而只对图像进行更改，这实际上是类似于视频流.

The most fundamental thing here probably is that you don't want to transmit static images but only changes to the images, which essentially is analogous to video stream.

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

My best guess is some very efficient (and heavily specialized and optimized) motion compensation algorithm, because most of the actual change in generic desktop usage is linear movement of elements (scrolling text, moving windows, etc. opposed to transformation of elements).

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

The DirectX 3D performance of 1 FPS seems to confirm my guess to some extent.

这篇关于TeamViewer有多快?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！