Jas*_*son 155 performance operating-system udp network-programming remote-desktop
抱歉长度,这是必要的.
介绍
我正在使用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 x 1080分辨率,那么原始数据仍为6,220,800字节.即使使用libjpeg-turbo(大公司使用的最快的JPG压缩库之一),将其压缩到30KB(让我们非常慷慨),也需要时间来通过TeamViewer的服务器(TeamViewer通过简单地代理流量来绕过公司的Symmetric 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开发人员.
潜在的答案
一旦人们回复,将更新此内容.
Kim*_*ais 75
这里最基本的可能是你不想传输静态图像而只是改变图像,这基本上类似于视频流.
我最好的猜测是一些非常有效(并且经过大量专业化和优化)的运动补偿算法,因为通用桌面使用的大多数实际变化是元素的线性移动(滚动文本,移动窗口等与元素转换相对).
1 FPS的DirectX 3D性能似乎在一定程度上证实了我的猜测.
Jam*_*rds 22
需要时间来通过TeamViewer的服务器进行路由(TeamViewer通过简单地通过服务器代理流量来绕过公司的Symmetric NAT)
您会发现TeamViewer很少需要通过自己的服务器中继流量.TeamViewer使用NAT遍历渗透NAT和NAT复杂的网络(我认为它是UDP打孔,就像谷歌的libjingle).
他们确实使用自己的服务器给中间人进行握手和连接设置,但大多数时候客户端和服务器之间的关系都是P2P(最好的情况是握手成功时).如果NAT遍历失败,那么TeamViewer确实会通过自己的服务器中继流量.
但是,当客户端支持双NAT时,我才会看到它这样做.
Sim*_*ier 13
回答有点迟,但我建议你看一下名为ConferenceXP的 Codeplex上一个不为人知的项目
ConferenceXP是一个开源研究平台,使用高带宽网络和Microsoft Windows的高级多媒体功能提供简单,灵活,可扩展的会议和协作.ConferenceXP帮助研究人员和教育工作者开发具有广播质量音频和视频的创新应用和解决方案,以支持实时分布式协作和远程学习环境.
提供完整的源(它是巨大的!).它实现了RTP协议.
小智 6
有人建议,这听起来确实比视频流更像图像流.JPEG/PNG压缩不适用于这些类型的速度,因此请忘记它们.
想象一下,在您的系统上有一个录制编解码器,可以实时记录传入的视频流(您的屏幕).有点像Fraps.然后想象一下另一侧的视频播放编解码器(远程客户端).由于高清录像机可以做到这一点(实时录制,甚至可以从同一个高清播放),最后也应如此.HD肯定无法比您阅读显示器更快地提供图像,因此这不是瓶颈.瓶颈是视频编解码器.你会发现编码器比解码器更容易出问题,因为所有的解码器都是免费的.
我不是说这很简单; 我自己使用DirectShow对视频文件进行编码,到目前为止还不是实时的.但鉴于正确的编解码器,我确信它可以工作.