为什么TeamViewer可以拷贝的这么快

2014/11/05

在研究最快的桌面区域拷贝函数的时候，我看到了下面这篇讨论，觉得有必要收藏起来：

 

How is TeamViewer so fast?

up vote83down votefavorite 48

Sorry about the length, it's kinda necessary. Introduction 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). 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). 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. 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 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. 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. 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). 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. The Question 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? 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). I'm hoping there's a TeamViewer developer somewhere here on StackOverflow. Potential Answers Will update this once people reply. My thoughts are, first of all, that TeamViewer has very fine network control. For example, they split large packets to just under the MTU size and never waste a trip. They probably have all sorts of fancy hooks to detect screen changes along with extremely fast XOR image comparisons. performance network-programming operating-system udp remote-desktop share|improve this question asked Feb 29 '12 at 12:06 Jason 2,99121533

1   Have you tried reverse engineering the protocol? (It seems that they use PKI for session setup so it might not easy, if feasible at all) –  Kimvais Feb 29 '12 at 12:28 2   Expecting an answer on this question hinges on the willingness of a company to share their trade secret. Their primary one at that, the one that keeps them in business.  You've got a strong no, the only way to get a yes is to call them.  Ask about their patents, I guess.                 –         Hans Passant                 Feb 29 '12 at 14:15                                                                            Makes sense. I'll wait for more suggestions. –  Jason Feb 29 '12 at 19:05 2   That's odd. I don't find it's faster than remote desktop myself - far from it! RDP for me is WAY faster - more like using a local virtual machine. Are you actually testing over the Internet or on some kind of local setup? Have you opened your firewall to permit direct teamviewer connections? –  NickG Nov 6 '12 at 14:20 1   Seems like you are only testing on local network. From my experience it seems like TeamViewer uses lossy compression (over slow connection the quality is sometimes really nad). Could it be VNC uses more processing time and less bandwith than TeamViewer and vice versa? Then depending on your environment (processor power on both machines and quality of the network link) sometimes VNC might be faster, sometimes TeamViewer. –  Axel Feb 6 '13 at 9:46 show 2 more comments

6 Answers

activeoldestvotes

up vote45down voteaccepted

The most fundamental thing here probably is that you don't want to transmit static images but onlychanges to the images, which essentially is analogous to video stream. 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). The DirectX 3D performance of 1 FPS seems to confirm my guess to some extent. share|improve this answer answered Feb 29 '12 at 12:46 Kimvais 13.1k24684

Theres the free TechSmith screen capture codec. It compresses efficiently and losless. –  sinni800 Jun 20 at 12:26 add a comment

up vote8down vote

would take time to route through TeamViewer's servers (TeamViewer bypasses corporate Symmetric NATs by simply proxying traffic through their servers) You'll find that TeamViewer rarely needs to relay traffic through their own servers. TeamViewer penetrates NAT and networks complicated by NAT using NAT traversal (I think it is UDP hole-punching, like Google's libjingle). They do use their own servers to middle-man in order to do the handshake and connection set-up, but most of the time the relationship between client and server will be P2P (best case, when the hand-shake is successful). If NAT traversal fails, then TeamViewer will indeed relay traffic through its own servers. I've only ever seen it do this when a client has been behind double-NAT, though. share|improve this answer answered Mar 31 '12 at 19:59 Jamie Edwards 175112

4   Very few corporate firewalls allow NAT traversal or UPnP though and that's TeamViewers main market. I suspect that most connections are relayed in real life... –  NickG Nov 6 '12 at 14:18 6   Sometimes you can "push your way" even through corporate firewalls/NAT - skype is quite good at this. Basically, client A sends out a requests that will be blocked by NAT/firewall, and informs the external server about the port used. Client B then gets information about port from external server and connects to that port. A's NAT will think it's a reply to the first request (that really was blocked by B's NAT) and let it through. When A answers on that connection, B's NAT will let it through because connection was initiated by B. => You have a connection. –  Axel Feb 6 '13 at 9:59   Many corporates have only http proxies and no NAT and routing to the outside at all. There Teamviewer tunnels through http port 443. Thats tcp and teamviewer is STILL fast as hell. –  sinni800 Jun 20 at 12:28 add a comment

up vote2down vote

Oddly. but in my experience TeamViewer is not faster/more responsive than VNC, only easier to setup. I have a couple of win-boxen that I VNC over OpenVPN into (so there is another overhead layer) and that's on cheap Cable (512 up) and I find properly setup TightVNC to be much more responsive than TeamViewer to same boxen. RDP (naturally) even more so since by large part it sends GUI draw commands instead of bitmap tiles. Which brings us to: Why are you not using VNC? There are plethora of open source solutions, and Tight is probably on top of it's game right now. Advanced VNC implementations use lossy compression and that seems to achieve better results than your choice of PNG. Also, IIRC the rest of the payload is also squashed using zlib. Bothj Tight and UltraVNC have very optimized algos, especially for windows. On top of that Tight is open-source. If win boxen are your primary target RDP may be a better option, and has an opensource implementation (rdesktop) If *nix boxen are your primary target NX may be a better option and has an open source implementation (FreeNX, albeit not as optimised as NoMachine's proprietary product). If compressing JPEG is a performance issue for your algo, I'm pretty sure that image comparison would still take away some performance. I'd bet they use best-case compression for every specific situation ie lossy for large frames, some quick and dirty internall losless for smaller ones, compare bits of images and send only diffs of sort and bunch of other optimisation tricks. And a lot of those tricks must be present in Tight > 2.0 since again, in my experience it beats the hell out of TeamViewer performance wyse, YMMV. Also the choice of a JIT compiled runtime over something like C++ might take a slice from your performance edge, especially in memory constrained machines (a lot of performance tuning goes to the toilet when windows start using the pagefile intensively). And you will need memory to keep previous image states for internal comparison atop of what DF mirage gives you. share|improve this answer answered Oct 8 '12 at 7:04   community wiki   Bojan Markovic

7   It annoys me when people suggest VNC as an alternative to TeamViewer. I would suggest that perhaps you've not used TeamViewer to know of the advantages it gives over free software like VNC? VNC might be OK for accessing your own computer, but for screen sharing and hosting meetings etc, it doesn't even vaguely compare. Last time I checked, VNC didn't even have any open relay servers, so it wouldn't even work in 95% of cases as it would be firewalled out (unless you own and operate your own firewall or server). – NickG Nov 6 '12 at 14:24 2   The discussion was not about VNC client tools versus TeamViewer (of which I EXTENSIVELY use both on daily basis, tho I do operate a lot of firewalls and servers and own quite a few).  The discussion was about internal work of protocols and implementing them –  Bojan Markovic Nov 6 '12 at 16:37    Just tried UltraVNC and TeamViewer over a slow 3G network, and the performance difference was huge. With UltraVNC, I experienced 1-2s delays between clicking something on the remote computer and seeing the response. To sluggish to be useful. TeamViewer was way faster (as fast as RDP) and quick enough to be usable on the same link. –  John Reynolds Jul 29 at 18:36   Yep. I have to agree with NickG. ANYONE still trying to posit that VNC as as fast as TeamViewer must have never used TeamViewer. Ridiculous assertion. This answer should be down voted. I've used all of the tricks suggested in this post with VNC, and it doesn't even remotely compare to TeamViewer performance wise. – crush Oct 6 at 20:32 add a comment

up vote5down vote

It sounds indeed like video streaming more than image streaming, as someone suggested. JPEG/PNG compression isn't targeted for these types of speeds, so forget them. Imagine having a recording codec on your system that can realtime record an incoming video stream (your screen). A bit like Fraps perhaps. Then imagine a video playback codec on the other side (the remote client). As HD recorders can do it (record live and even playback live from the same HD), so should you, in the end. The HD surely can't deliver images quicker than you can read your display, so that isn't the bottleneck. The bottleneck are the video codecs. You'll find the encoder much more of a problem than the decoder, as all decoders are mostly free. I'm not saying it's simple; I myself have used DirectShow to encode a video file, and it's not realtime by far. But given the right codec I'm convinced it can work. share|improve this answer answered Nov 23 '12 at 19:53 Ruud van Gaal 5911

Cool, thanks. 2char –  Jason Nov 23 '12 at 23:33   Techsmith screen capture codec  basically.                 –                      sinni800                 Jun 20 at 12:29     add a comment

up vote7down vote

A bit late answer, but I suggest you have a look at a not well known project on codeplex calledConferenceXP ConferenceXP is an open source research platform that provides simple, flexible, and extensible conferencing and collaboration using high-bandwidth networks and the advanced multimedia capabilities of Microsoft Windows. ConferenceXP helps researchers and educators develop innovative applications and solutions that feature broadcast-quality audio and video in support of real-time distributed collaboration and distance learning environments. Full source (it's huge!) is provided. It implements the RTP protocol. share|improve this answer answered Dec 8 '12 at 9:40 Simon Mourier 51.9k569118

1   This is excellent! I downloaded the binaries but there appear to be no one else online in the other rooms. I'll have to test with another computer later. Many thanks! –  Jason Dec 8 '12 at 23:19 add a comment

up vote-1down vote

This is how I see it. Its very hard to say which is the fastest protocol: RDP or TeamViewer. Comparing versions I would say RDP 7.1 is faster than RDP 7. Also RDP 7.1+ with RemoteFX might be faster that any other windowed remote desktop solution. RDP supports about 4 different compression algorithms that you can choose from on the server side. Don't forget that RDP transports printers and other data's. So, I think we are comparing oranges with apples. I would say that the intelligent compression algorithms adapting over network conditions along with client side caching might be the trick. I hope this helps: http://www.microsoft.com/en-us/download/details.aspx?id=23236 share|improve this answer edited Feb 6 '13 at 9:43   answered Feb 6 '13 at 9:36 Dragos 1625

add a comment

--------------------- 本文来自 大势燎原 的优快云 博客 ，全文地址请点击：https://blog.youkuaiyun.com/narutojzm1/article/details/49703225?utm_source=copy