精华内容
下载资源
问答
  • 浏览器实现远程桌面
    2021-07-31 08:02:02

    您想连接到Windows Server 2003的“远程桌面”维护服务器,但是客户机却没有终端访问工具。这时您是不是很着急呢?如果您遇到过这种情况,那么下文介绍的内容也许会对您有所帮助。

    与Windows 2000相比,Widows Server 2003在远程维护服务器方面一个最明显的改进就是提供了“远程桌面”功能,该功能可以帮助网络管理员十分方便地远程维护服务器。不过要想使用该功能,除了必须在服务端允许远程连接到服务器外,客户机还要有连接“远程桌面”的终端访问工具。这对于系统平台是Windows XP的客户机而言并不是难事(因为其自身已经集成了连接“远程桌面”的工具),而对于Windows 9X/2000而言则必须另外安装终端访问工具。不难想象,并不是所有的客户机都已经安装了终端访问工具。这与我们所追求的“随时随地维护服务器”的目标并不相符。然而您知道吗?利用Windows Server 2003自带的“Web远程管理”服务,我们可以通过任何一台客户机的IE浏览器直接进行“远程桌面”连接,根本不需要终端访问工具。下面我们将简单谈谈该功能的使用方法。

    一、安装Web远程管理

    在Widows Server 2003中安装“IIS管理器”后Web远程管理并没有被默认安装,需要进行手动添加。依次打开“控制面板”→“添加和删除程序”→“添加/删除Windows组件”对话框,然后依次点击“Internet信息服务(IIS)”→“详细信息”→“万维网服务”→“详细信息”选项。在打开的“万维网服务”对话框中勾选“远程管理(HTML)”选项并依次点击“确定”→“下一步”→“完成”按钮完成安装。接着打开“Internet信息服务(IIS)管理器”对话框,

    依次展开“hostname(本地计算机)”→“网站”目录。右键点击“Administration”选项→执行“属性”命令,打开“Administration属性”对话框。在该对话框的“网站”选项卡中点击“IP地址”右侧的下拉三角, 点选本机IP地址。最后点击“确定”按钮并关闭管理器窗口。

    小提示:如果Windows Server 2003启用了防火墙,则必须开放“8098”端口。因为该端口是进行Web远程管理的默认端口。

    二、进行“远程桌面”连接

    假设客户机使用的是Windows 9X系统,我们在IE地址栏中键入如下地址“https://192.×.×.×:8098”,iz育2:Xl理网T6教然后键入系统管理员的用户名和密码并回车即可登录Web远程管理界面。在打开的“服务管理”界面中,点击顶部主导航栏上的“维护”标签,然后点击“远程桌面”按钮。稍等片刻就会看到熟悉的Windows 2003登录对话框。用户名已经默认填写了登录Web远程管理时使用的系统管理员名称,只需键入密码并点击“确定”按钮即可连接到服务器的桌面了。经过在局域网环境中实际操作,使用相当流畅。

    可见,只要有安装了IE浏览器的客户机,我们可以随时连接到“远程桌面”对服务器进行维护,真正实现了无障碍登录。

    小提示:“远程桌面”功能只允许同时建立两个远程桌面会话,如果已经有两个会话正在运行,则新用户将被拒绝进行访问。

    更多相关内容
  • 主要给大家介绍了关于no-vnc和node.js实现web远程桌面的完整步骤,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
  • lsb_release -a ; hostname -I; hostname ; getconf LONG_BIT apt-get install xfce4 xfce4-* vnc4server novnc websockify python-numpy -y vncserver vncserver -kill :1 mv ~/.vnc/xstartup ~/.vnc/xstartup.bak ...
    lsb_release -a ; hostname -I; hostname ; getconf LONG_BIT
    apt-get install xfce4 xfce4-* vnc4server novnc websockify python-numpy -y
    vncserver
    vncserver -kill :1
    mv ~/.vnc/xstartup ~/.vnc/xstartup.bak
    vim ~/.vnc/xstartup
    
    #!/bin/bash
    xrdb $HOME/.Xresources
    startxfce4 &
    
    chmod +x ~/.vnc/xstartup
    vncserver
    cd /etc/ssl ; openssl req -x509 -nodes -newkey rsa:2048 -keyout novnc.pem -out novnc.pem -days 365
    chmod 644 novnc.pem
    websockify -D --web=/usr/share/novnc/ --cert=/etc/ssl/novnc.pem 6080 localhost:5901
    
    https://X.X.X.X:6080/vnc.html
    

    如果登录出现
    Security failure: Too many authentication failures

    ubuntu@instance-r5zywgpr:~$ pgrep vnc
    18119
    30517
    root@instance-r5zywgpr:/home/ubuntu:~$ kill 18119
    root@instance-r5zywgpr:/home/ubuntu:~$ kill 30517
    root@instance-r5zywgpr:/home/ubuntu:~$ vncserver
    
    
    展开全文
  • 前几篇文章分别阐述了如何抓取windows桌面图像,以及相关摄像头,电脑内部声音等采集,相关连接如下: http://blog.csdn.net/fanxiushu/article/details/73269286 (抓屏技术总览 MirrorDriver,DXGI,GDI) ...

                                            by Fanxiushu 2017-12-21   转载或引用请注明原始作者。


    前几篇文章分别阐述了如何抓取windows桌面图像,以及相关摄像头,电脑内部声音等采集,相关连接如下:
    http://blog.csdn.net/fanxiushu/article/details/73269286  (抓屏技术总览 MirrorDriver,DXGI,GDI)
    http://blog.csdn.net/fanxiushu/article/details/76039801  (抓屏技术之MirrorDriver镜像驱动开发)
    http://blog.csdn.net/fanxiushu/article/details/77013158  (电脑内部声音采集,录音采集,摄像头视频采集)

    这篇文章描述如何在浏览器中,直接打开网页方式而且不需要任何插件就可以浏览远程桌面,同时进行鼠标键盘等控制。

    记得很早前,当初热衷于远程桌面图像技术,就一直想着在浏览器中直接浏览远程桌面图像,同时进行控制,因为这样感觉很酷。
    奈何当时并没有HTML5技术,而且也并没有WebSocket等技术出现,要在浏览器中达到这种效果,就只能以插件方式实现这种功能。
    比如ActiveX控件,或者java的applet插件等,相当于还是得在客户端实现一个原生程序,原生程序以插件方式嵌入到浏览器中。
    这跟直接做一个客户端程序没啥区别,而且要兼容各种浏览器就得实现每种浏览器的插件接口。
    随着这些年互联网技术的发展,HTML5标准的出现,WebSocket在网页开发技术中的应用,使得直接在各个浏览器中,
    通过JS脚本的开发,就能轻松的实现在普通页面浏览和控制远程桌面。
    这给我们带来什么好处?首先就是因为不需要插件,能在绝大部分现代浏览器中正常运行,包括各种移动设备。
    目前的现状与以前不同,以前的终端设备大部分是PC电脑为主,现在各种手机以及其他移动设备,当然还包括平板,笔记本,PC台式机等。
    各种各样的终端设备,如果都要开发原生程序,得做好几套程序。
    如果你为了省事,而且也不需要深度使用远程桌面功能,就在浏览器中使用也未尝不是一个好选择。
    当然为了获得更好的体验效果,还是得开发原生的客户端远程桌面程序,因为不论是解压图像时候CPU占用率,还是画质效果以及起他功能,
    都不是浏览器中的远程桌面能与之比拟的。

    这篇文章讲述如何通过JS脚本开发,通过WebSocket网络通讯,HTML5标准的canvas绘画,
    WebAudio声音来展现一个完整的远程桌面效果。
    其中图像和音频的javascript解压缩利用开源库h264bsd和jsmpeg。
    因为我不是做JS脚本和HTML5网页的开发工程师,只是因为想要在浏览器中实现远程桌面功能,才开始接触这些方面的内容。
    因此文章有何不妥之处,请指出。

    我们先来了解普通远程桌面客户端的开发过程。
    首先得制定一套通讯协议,用来传输桌面图像数据,电脑内部的音频数据,鼠标键盘等控制信息数据。
    RDP协议,VNC协议,SPICE协议等,这些都是公开使用的通讯协议,基本上是建立在TCP通讯之上。
    比如windows的远程桌面使用的RDP协议,我们只有在各种客户端操作系统中,
    开发出符合RDP协议的程序,就能在各种客户端远程控制windows系统平台。
    类似RDP产品很多,基本上Android,iOS,MacOS等操作系统中都有对应的RDP软件。
    而像VNC,则是类似Linux,MacOS等系统常用的远程控制协议。
    这里并不打算介绍这类公开通讯协议,而是使用我们自己建立在TCP上的私有协议进行通讯。
    远程桌面通讯协议有个最大的特点,就是基本上都是基于一个一个的数据包进行数据传输,包括数据包的推送和拉取。
    而且是建立在TCP这种流套接字的基于数据包方式的通讯,这跟我在如下的文章介绍的TCP工作方式是一致的。
    http://blog.csdn.net/fanxiushu/article/details/50631626  (基于TCP流协议的数据包通讯)
    因此我们设计的私有协议也应具备类似的工作方式的。
    这种一个一个数据包传输方式跟HTTP协议的请求-应答模式有很大差别。
    这就是为什么在 WebSocket 没出现前,要在浏览器使用js解决远程桌面的通讯问题是个很大的麻烦,很多时候必须依靠插件才能完成。

    当制定好一套私有通讯协议,被控制端根据通讯协议格式传输经过编码压缩的图像和音频的一个一个数据包到控制端(客户端)。
    客户端接收到一个一个的图像数据包,根据每个数据包的指示,采用不同的解码方式对图像或音频解码。
    解码之后,就是原始的YUV或者RGB图像数据,然后使用画图函数把图像画到窗口中,从而就显示出远程被控制端的桌面图像。
    再把解码之后的音频数据送到播放设备播放。
    这就是一个远程客户端的开发大致流程。其实,我们完全可以把远程桌面理解成直播系统,被控制端相当于直播的推流。
    只是这个直播系统要求的实时性非常高,不能超过一秒(估计一秒的延时都够呛),
    否则当使用鼠标键盘控制远程系统的时候,那种延迟基本是不能接受的。

    再看看浏览器中的实现,WebSocket的出现,帮我们解决了远程桌面通讯协议的麻烦,
    而图像最终要显示到窗口中,HTML5的canvas的出现,可以在canvas上边画图,又帮我们解决了图像显示的问题。
    HTML5的WebAudio的出现,帮我们解决了在浏览器中播放音频数据块的问题。
    因此在现代的浏览器中增加了这些基本内容,就完全帮我们解决了以前只有插件才能做到的事情。

    我们使用WebSocket连接到被控服务端获取数据。在js中调用
    var ws = new WebSocket("ws://www.dns.com/wsock_stream");
    就创建一个到 www.dns.com主机的WebSocket连接,请求的uri是 /wsock_stream 。
    然后
    ws.onclose=function(e){ ...}   // WebSocket 关闭
    ws.οnerrοr=function(e){ ... }   // WebSocket 连接出错
    ws.onopen=function(e){...}     // WebSocket 成功建立了连接
    ws.onmessage=function(e){....} //接收到数据包
    ws.send(...)  // 发送数据包。
    看起来够简单吧,比起 c++中使用BSD Socket简单多了。
    再看看WebSocket服务端,服务端不是使用现成比如node.js做开发,
    而是用C/C++语言直接BSD Socket来解析处理WebSocket协议,以及解析处理HTTP协议。
    因为从镜像驱动采集桌面图像,到图像转换编码压缩,到网络传输,清一色都是使用此语言实现的。
    在其中嵌入网页方式的远程桌面只是其中一个附加功能。自然,实现的是简单的嵌入式Web服务端。
    至于程序,稍后可以到GITHUB或者CSDN下载下来玩玩。

    C++中实现WebSocket,我们就得熟悉WebSocket协议格式,
    WebSocket首先发送一个跟HTTP协议格式一样的数据包(HTTP请求)到服务端,服务端回复 101 的HTTP应答,
    之后这个连接切换到WebSocket通讯。WebSocket实际上是基于TCP上的数据包方式的通讯模式。
    WebSocket头一个字节包含操作码等信息,接下来一个字节是数据包长度,这个长度表示方式比较特别,
    如果数据长度<126,这个字节就代表实际的数据长度,如果  126<=数据长度 < 65536 ,这个字节固定126,接下两个字节表示真实长度。
    如果数据长度超过 65536 这个字节固定127,接下来 8个字节代表真实数据长度。
    更详细的WebSocket协议说明,请查看 RFC文档,相对而言不复杂,可以使用C++封装成类似 js 那样的函数调用方式。

    接下来还得在js端解决WebSocket断线重连问题,让网络连接能自动恢复。
    我们可以在 onerror, onclose,以及异常里边重新创建 WebSocket连接,
    同时调用 setTimout 定时发送心跳包来保持连接,具体可查看稍后发布到 CSDN或GITHUB上的 javascript代码。

    然后就是我们的主题:在WebSocket里承载我们的私有协议数据包,用来传递图像数据,音频数据,以及鼠标键盘等控制数据。
    我们这里使用每个数据包都是用一个公共的头,然后接下来是对应的数据。
    这个公共的头如下定义数据结构:
    struct net_header_t
    {
        unsigned char   cmd; // 0, noop, 1 login,  2 RECTs, 3 audio AAC, 4 Mouse input, 5 keyboard input, 6 param set, 7 display change , 8 cursor
        unsigned char   subcmd; // when cmd=0 1 request, 2 reply; when cmd=2, subcmd=all data compress methed

        /
        union {
            login_t           login;//登录信息

            display_change_t  display_change;//屏幕大小改变
           
            image_rect_t      image_rect;//图像数据
           
            audio_sample_t    audio_sample;//音频数据
           
            kbd_event_t       kbd_event;//键盘事件
           
            mouse_event_t     mouse_event;//鼠标事件

            cursor_t          cursor;//鼠标形状

            proxy_t           proxy; // 通过服务端中转数据结构

            param_t           param; // 设置获取参数
            /

        };

    };
    这样每个数据包,都包含 net_header_t 头,
    其中image_rect_t 代表的是图像数据,在cmd=2,使用image_rect_t这个结构。
    audio_sample_t代表的是音频数据头,cmd=3时候使用。
    当代表图像数据时候,接下来包含至少一个或者多个 ( image_rect_header_t 头 + 压缩的图像数据 )。
    这样可以在一个数据包里同时传递多个变化的图像数据,这是在当初设计时候,需要传输远程桌面变化的矩形框区域图像。
    然后我们在websocket的onmessage回调函数中接收到数据包,这个数据包可能是图像包,也可能是音频包或者其他,
    因为网页端能找到开源的javascript解码源代码非常有限,目前只找到h264bsd和jsmpeg解码,
    而自己并不擅长做图像编解码更不擅长用js解码,因此发送到网页端的只是编码算法中的H264和MPEG1,音频是MP2.
    具体如何使用jsmpeg和h264bsd可以查看它们的example或者查看稍后发布到CSDN或GITHUB的这部分javascript代码。

    javascript解码其实就是利用CPU运算的软解码。
    即使直接C语言+汇编开发的图像软解码程序解码类似H264这样的算法,消耗的CPU都非常高。
    就更别提使用js脚本来解码了。在现代的PC电脑中的CPU利用js解码还能凑合使用,到了移动平台比如手机,CPU基本就不在一个层次了。
    比如我的iPhone6手机,在iOS自带浏览器中远程桌面1920X1080的图像,如果远程桌面不是经常变化,凑合还能接受,
    如果在远程桌面播放视频,在iPhone6手机里基本不能正常运行,MPEG1和H264都不行,也许你的最新的手机CPU能扛得住。
    (下面会提到使用MJPG方式来实现流畅播放。)
    不过如果换成是PC(最近两三年新的CPU)的浏览器,chrome或者firefox或者opera或者edge等,(IE对HTM5支持并不好,排除在外)
    即使1920X1080远程桌面中播放视频也比较流畅。

    使用javascript解码图像前,其实想了许久,想了多种其他在网页中显示图像的解决办法。
    前面说过了,远程桌面可以理解成实时性要求很高的直播系统。
    一开始想到的是HLS,因为它协议够简单,能使用普通HTTP协议承载视频,而且是利用HTML5的video标签播放,
    利用video标签意味着浏览器内部是使用硬件解码加速,比起js纯软解码效率高了许多,尤其是在手机这样的移动平台,
    利用video标签流畅播放1080P视频都不是问题。
    但是仔细去分析HLS协议,会发现延时非常高,动不动就几十秒的延时,无论如何也做不到1秒内的延时,这对远程桌面是不可接受的。
    因此只能放弃这种方案。
    然后就是RTMP协议,还有flv直播,可惜这都需要依赖Flash控件,在电脑端使用Flash没啥问题,到了移动端就没辙了。
    当初要实现网页方式控制,主要目的就是为了各自平台都能使用,而且不用开发各种平台的客户端程序。
    想来想去,在各种平台都兼容的网页中实现高实时性直播,是个蛋疼的问题。
    使用HTML5的video标签来解决直播问题更是蛋疼。因此只好考虑在HTML5中利用js解码来到达既能兼容各种平台,又能保证高实时性。

    最后简单说说MJPG。
    在以前提供的桌面图像采集源代码中,简单使用了MJPG流在浏览器中展现远程桌面,
    下载连接如下:
    http://download.csdn.net/download/fanxiushu/9910360  (windows平台抓屏源代码下载)
    本来后来的开发中,打算放弃MJPG这种方案,因为占用网络带宽太高,尤其是在远程桌面播放视频的时候。
    但是利用了H264和MPEG1的js软解码,结果在手机平台挺糟糕,因此只好重新完善MJPG流方式。

    利用img标签来显示MJPG流,这个在chrome,firefox,opera,Microsoft Edge,以及Safari(苹果iOS和MacOS自带浏览器)
    都能支持MJPG流,但是IE不支持(当然以IE为内核的也不支持)。
    这里说的MJPG流,其实就是一张一张的JPG图片,只是在HTTP应答头中 的Content-Type设置为 multipart/x-mixed-replace类型。
    然后就循环不停的一段一段的传输JPG图片。MJPG流的C++实现代码可从上边的连接下载,其实是挺简单的。
    因此我们只需要简单的在网页端 <img src="URL" /> 这样就能展现MJPG流。
    然后再结合WebSocket传输音频数据和鼠标键盘数据,也就是图像流使用HTTP协议传输,其他数据使用WebSocket传输。
    这里有个问题就是断线重连问题,img标签没法实现断线重连。因此想了一个办法,在服务端生成一个唯一ID,
    同时传给WebSocket作为URL参数和MJPG流的URL参数,然后在WebSocket中定时发送查询命令到服务端检测MJPG的这个唯一ID。
    如果不存在,说明已经断线了,这个时候把本地图片,请重新上传img标签重新刷新。详细实现可查看稍后发布的js代码。

    GITHUB上下程序载地址:
    https://github.com/fanxiushu/xdisp_virt
    CSDN上下载地址

    http://download.csdn.net/download/fanxiushu/10168823

    程序一共两个,
    1, xdisp_virt.exe 这个是核心程序,负责抓屏,编码压缩,本身也提供给浏览器连接和原始客户端程序连接,同时也提供连接到
                               xdisp_server服务端,
    2, xdisp_server.exe 这个是中转服务端程序,就是当许多机器处于复杂局域网环境时候,可以把xdisp_server部署到公网上,
                                    然后让所有xdisp_virt.exe程序连接到这个服务端,这就等于是xdisp_server管理和中转了所有xdisp_virt机器。

    这是开发中的一个版本,计划有点大,
    比如还没实现远程文件传输功能,复制粘贴也需要实现。
    打算实现windows桌面扩展功能,类似iDisplay软件,这个需要开发WDDM驱动,正好借此机会熟练WDDM驱动。
    手机端还得实现原生APP来采集手机屏幕和相机,然后连接到xdisp_server程序。这样桌面采集不单局限于windows平台了
    然而计划跟不上变化,到时能做到什么程度,看当时的心情和是否有利可图了,
    因为有些东西纯粹就是一大堆无聊代码,做起来又浪费时间和精力,个人精力有限。

    下面展现的是开发的这个程序在浏览器的一些图片效果

    下图是用浏览器登录到xdisp_server中转服务端页面图(当然也没挺简单)


    下图是选择一个连接后出现的三种图像编码方式:

    下图显示远程桌面(这张图尺寸太大 可能会看不清,远程控制的是 2560X1600 的电脑屏幕):

     
    下图是iPhone手机上系统自带浏览器效果:

    展开全文
  • 基于properJavaRDP实现调用远程桌面,有两种方式,一种是普通java程序,一种是java web方式,包含详细的使用说明,用到的jar包及源码,还有示例工程。
  • 从而达到在浏览器端既能使用video标签进行高效渲染,也能很大程度上解决某些受限制的网络环境也能正常使用的问题。 总结起来就一点:在xdisp_virt中实现WebRTC的 TURN的TCP传输。 使用的webrtc依然是开源的亚马逊...

    by fanxiushu 2022-07-13 转载或引用请注明原始作者。
    接续同系列文章:
    Windows远程桌面实现之十三:浏览器客户端使用WebRTC传输,以及WebRTC和MSE渲染显示(二)_雨中风华的博客-CSDN博客_websocket 远程桌面

    本来是不该有此文的,只是现实总让理想绕道。
    在上一篇文中讲过, xdisp_virt 软件中实现WebRTC渲染之后,在浏览器中看视频和游戏,
    已经不再像之前只有WebGL渲染的情况:浏览器远程看视频或游戏,WebGL会让浏览器占用大量CPU等资源。

    然而,WebRTC特殊和复杂的底层通信模式, 在些网络环境中让人非常头大。
    在一般的局域网和有线内网中,WebRTC问题都不大。头大的是在复杂的互联网环境下。
    一旦屏蔽UDP通信,WebRTC基本就凉凉了。
    中国的网络,UDP多少会遭到一定程度的限制或者直接屏蔽。
    其实这也可以理解,当UDP因为各种P2P软件的原因,造成主干网带宽不断被挤压,
    而正常的TCP服务通信遭到威胁的时候,作为运营商,肯定得想办法限制这种情况。
    因此这种情况也并不会限于国内,其他国家地区根据情况多少也会有些限制。
    还比如有防火墙下,或者公司内部只允许有限的端口上网(比如只开启443,80等端口),这些情况下,webrtc基本也是凉凉。
    比如还有些个人情况,有人想用 ngrok等类似的反向代理工具 搭建一个能访问内网的环境,然后想用 xdisp_virt进行远控。
    这种情况,webrtc也只能凉凉,现在唯一能用的就只有 xdisp_virt中的WebGL渲染模式,
    因为他是通过websocket方式传输数据,能透过 ngrok 的代理模式。
    。。。等等,这些情况,在现实网络环境中很多的这类情景。

    所以说得难听点,WebRTC只能在理想的网络环境中使用。
    于是,牛哄哄的集成各种通信协议的WebRTC,
    什么 ICE,STUN/TURN,DTLS,SRTP/SCTP 等等,某些时候好像还真成了玩具。
    若不是为了让xdisp_virt能在浏览器中进行远控,其实也不会去实现WebRTC。
    实现WebRTC的目的其实就是为了让浏览器能用video标签渲染图像。
    发现了WebRTC这种通讯问题之后,尝试着想办法在浏览器端只让WebRTC渲染图像,去掉它的通信功能。
    但是好像没办法,反正最终没能成功。

    于是再次想到,能不能在浏览器端,用js同时实现 WebRTC的服务端和客户端,
    也就是通过常规websocket方式把H264等视频编码数据发到浏览器端,
    然后浏览器实现一个WebRTC接收这个数据,作为WebRTC的数据提供者,
    然后在同一个浏览器内部,用js再实现另一个WebRTC,用来接收前一个WebRTC的数据并用video标签显示出图像。
    虽然这样非常迂回绕道,但是只要能实现,也能解决通信问题。
    只是非常可惜,花了许多时间去研究,依然无法实现。

    再后来发现TURN协议支持TCP中转传输,是作为 TURN的一个附加协议添加的。
    这给WebRTC处理上面的网络问题带来了一点希望,
    因为不确定现代浏览器是否都支持 TCP传输的 TURN,于是在linux服务器搭建了coturn服务器。
    测试下来,最新版本的chrome, firefox,iOS的safari等的WebRTC都支持TCP方式的TURN中转传输,
    Android因为没设备所以没测试,不过既然与chrome是同一家,应该也支持。

    写这篇文章正是基于以上各种网络通信原因,不得不实现 WebRTC中的TCP的TURN中转通信,
    从而达到在浏览器端既能使用video标签进行高效渲染,也能很大程度上解决某些受限制的网络环境也能正常使用的问题。
    总结起来就一点:在xdisp_virt中实现WebRTC的 TURN的TCP传输。
    使用的webrtc依然是开源的亚马逊WebRTC。
    不过TCP的TURN服务端是需要自己实现,因为我需要把它同 websocket,http/https等协议集成到同一个端口中,
    这样使用起来更加方便。
    好在 TCP的TURN协议并不太复杂。

    WebRTC的TURN,与我们通常理解的中转服务器,其实没什么本质区别,无非就是实现的协议不同而已。
    xdisp_virt实现目标:
    在xdisp_virt中实现kvswebrtc(亚马逊的WebRTC),同时实现TCP协议的Turn服务端 tcp turnserver,
    kvswebrtc获取视频数据,并且转发到同一个程序内部的tcp turnserver,因为在同一个程序内,它们可以直接使用 127.0.0.1通信。
    tcp turnserver同时也接收来自客户端浏览器的连接。
    这样tcp turnserver同时中转处理 kvswebrtc和客户端浏览器的webrtc。
    而在外面的网络看起来,
    客户端浏览器和xdisp_virt之间的WebRTC连接通信都是通过 tcp turnserver,不再像WebRTC默认的行为模式有一大堆的UDP请求。

    在kvswebrtc和浏览器中实现WebRTC的 TCP TURN中转,其实挺简单。
    在kvswebrtc中,只需在 turn的url中添加 ?transport=tcp ,比如:
    turn:127.0.0.1:11000?transport=tcp
    并且在 createPeerConnection创建接口的时候设置 ICE_TRANSPORT_POLICY_RELAY 参数即可。
    在浏览器中javascript实现与kvswebrtc差不多。如下伪代码:
       ice_svr_addr = {
              iceServers: [
                   { urls: ['turn:192.168.88.8:11000?transport=tcp'],
                      credential: '123456', username: 'turn' }],
              iceTransportPolicy: 'relay' }

      pc = new RTCPeerConnection(ice_svr_addr );

    经过这样的设置,浏览器的WebRTC 和 kvswebrtc都只会直接连接到 TCP  turnserver服务器端。
    当然WebRTC的基本步骤依然没变,依然会收集 sdp,candidate等信息,这些信息依然要通过其他方式发送到对方。
    不过candidate信息就只有有关 TURN中转服务器信息,不再包括webrtc所在电脑的信息。

    kvswebrtc全程是通过TLS与TURN连接的,而浏览器却很奇怪,好像并没对TCP的TURN TLS提供支持,
    反正我把上面的 turn改成 turns,目前所有的浏览器都会报错。
    这会带来什么结果,其实也没啥,就是我们用抓包软件能顺抓取识别到 STUN数据包,防火墙想阻止STUN数据包,也能顺阻止。

    接着我们再来看看 tcp turnserver的通信过程。
    TCP 的TURN协议具体可以查询 RFC6062以及RFC5766等,反正也有好几个RFC文档,
    看下来也会觉得挺累的。因此最好的办法是经过实践之后,再来结合RFC文档查看。

    好在我们只需实现 TCP 的TURN,而且经过抓包分析,基本上也只需要以下几个命令:
    1,ALLOCATE
    2, CREATE PERM
    3,REFRESH lifetime
    4,   BINDCHANNEL
    5, INDICATION DATA

    1,不管是 kvswebrtc还是浏览器的webrtc,经过相互交换 candidate等信息之后,然后连接到TCP turn server,
    第一个请求命令就是 ALLOCATE,意思是请求分配relay port,
    实际上就是告诉TURN服务器:请给我留一个位置,好让我与其他连上来的WebRTC进行通讯。
    turn 服务端需要检查身份信息,通过查看 是否存在USERNAME和MESSAGE-INTEGARY,
    并且做 long-term验证,具体如何验证,可以去查阅 RFC文档。
    这里只是简单阐述一下,
    每个TURN消息,都有个消息头,消息头大小是 20字节,STUN和TURN消息头的格式都是一样的。如下
    /// protocol stun header
    struct proto_stun_header_t
    {
        uint16_t   type;
        uint16_t   length;
        uint32_t   cookie;
        uint8_t    number[12];
    };
    验证办法是 user:realm:password 组成字符串,然后做MD5运算,
    运算的16字节作为 HMAC的key,然后把数据包括 TURN头(但是除开MESSAGE-INTEGARY)做 HMAC运算。
    运算结果与MESSAGE-INTEGARY属性里的结果进行比较,如果前后一致,说明验证通过。
    基本上除了 INDICATION DATA 和 Channel数据之外,基本都需要做验证。

    2,分配的relay port有时间限制的,客户端就需要定时发送REFRESH liftetime命令续命。
    当lifetime=0表示主动结束连接。

    3,当ALLOCATE成功后,其实就可以开始传输数据了,但是为了防止没有授权的乱发。
    所以有了 CREATE PERM命令,表示告诉TCP TURN服务端,我接下来需要把数据转发给谁。

    4,当 CREATE PERM之后,其实就可以使用 INDICATION 传输数据了。
    INDICATION 主要包括两个属性, 一是 XOR-PEER-ADDRESS,表示我这个数据的传输目的站,
    二是 DATA,这个就是具体的数据内容了。

    5,如果使用 INDICATION传输数据,则会每次都要包含20字节的STUN头和16个字节属性,也就是有36个字节的额外损耗。
    因此为了减少这种通讯损耗,采用了 BINDCHANNEL方式。
    告诉turn服务器,与某个客户端的数据转发,与2个字节的chanel number绑定。
    这样以后每次通信只需要 2个字节的channel number + 2字节数据大小 +数据内容就可以了。
    这样把原本需要36个字节的头,减少为只需要4字节的头部。
    这样会出现一个问题,如何区分到来的数据包究竟是 常规的STUN头部的数据包,还是 channel number的数据?
    好在RFC文档规定,范围在 0x4000-0x7FFF是channel number。
    因此我们可以这样判断,先接收2个字节的数据,然后判断是STUN还是 channel number。
    然后再做后面的处理。

    TCP TurnServer通信内容大致就是这些。
    至于更多细节,请查阅RFC,如果查看RFC文档比较头大,可以一边抓包分析,一般查看RFC。

    下图是实现了 WebRTC的TCP 方式传输的 xdisp_virt :
    有兴趣可以去我的GITHUB下载使用。

     

    展开全文
  • 对于windows server2012服务器一般都是默认能够支持两用户远程登录,而通过安装远程桌面服务里的远程桌面会话主机和远程桌面授权,并对其进行配置,即可实现多用户远程登录
  • 我正在规划/建模阶段开发远程桌面共享解决方案,该解决方案必须基于Web浏览器.换句话说:用户将能够使用他的网络浏览器查看某人的远程桌面并与之交互.除了他的浏览器之外,想要共享他的桌面的用户将需要的所有内容都是...
  • 下面小编就为大家分享一篇vue项目中引入noVNC远程桌面的方法,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
  • vue noVNC实现远程桌面连接

    千次阅读 2022-01-06 15:48:29
    vue 网页版实现noVnc
  • VNC 是在基于 UNIX 和 Linux 操作系统的免费的开源软件,远程控制能力强大,高效实用,其性能可以和 Windows 和MAC中的任何远程控制软件媲美。 VNC基本上是由两部分组成:一部分是客户端的应用程序(vnc viewer);...
  • } 其次,因为我们需要实时性的MSE,因此一个非常重要做的事情,就是得不断清空多余的缓存, 我也不清楚现在的浏览器实现MSE的时候,为何总是喜欢缓存,缓存一旦变大,很大的延迟就会来了, 这对于远程桌面这类需求...
  • 5 分钟,使用内网穿透快速实现远程桌面

    千次阅读 多人点赞 2021-10-10 14:39:10
    本篇文章将介绍如何使用「 内网穿透 」实现远程桌面管理 2. 内网穿透 Frp 常见实现内网穿透的方案有:Frp、Ngrok、natapp 其中,Frp 是一款开源的、简洁易用、高性能的反向代理软件 它支持 TCP、.
  • Windows远程桌面剪贴板支持文本复制与粘贴,但是不支持文件级别的复制与粘贴。有时我们需要传送文件到远程机器,实现起来很麻烦。幸好现代浏览器都支持File API,我们可以利用文本传送的方式实现两台机器间任意文件...
  • 远程桌面服务是一项由若干角色服务组成的服务器角色,默认情况下,服务器只能提供两个用户远程桌面登陆,而通过安装远程桌面服务里的远程桌面会话主机和远程桌面授权,并对其进行配置,即可实现多用户远程登录。...
  • 1,摘要 ...(2) 实践通过命令方式调用远程桌面系统; (3) 编写JS脚本页面,通过IE浏览器调用远程桌面程序; (4) 遗留问题:MAC电脑远程访问,CHROME浏览器远程访问的方法; 2. WINDOWS自带的m...
  • Springboot及Websocket实现windows远程桌面控制一、背景说明二、实现过程1.先进行Robot类进行截图的单元测试2.新建一个springboot工程,并添加websocket支持3.在springboot工程启动时开启定时任务进行截图抓取任务的...
  • 这是Windows选项卡式远程桌面应用程序,其UI旨在类似于Chrome浏览器。 当前,它支持Microsoft的远程桌面协议(RDP),安全Shell(SSH),PowerShell和VNC,但具有旨在支持第三方支持Citrix等其他协议的插件体系结构...
  • ThinVNC是纯Web远程访问实现(基于HTML5和AJAX)。 该网络客户端可在任何兼容HTML5的浏览器上运行,例如Chrome,Firefox,Safari,Opera,IE或Edge。 注意:此项目是Thinfinity解决方案的第一个版本。 请访问我们的...
  • 随着webrtc的普及,分享桌面已经远远满足不了我们的需求了,编译介绍一个基于浏览器远程桌面 jsmpeg-vnc https://github.com/phoboslab/jsmpeg-vnc 框架主要用ffmpeg 压缩视频 webscoket 传送 jsmpeg js浏览器...
  • 配置网络:实现多个远程桌面连接

    千次阅读 2021-06-17 10:33:24
    远程桌面连接能够从其它计算机访问计算机的桌面、程序、文件等,不管是在隔壁房间或是在世界的另外一端。远程计算机上运行程序时就如同是操作者坐在本地电脑前一样。配置计算机接受这些连接并不复杂,不过,通过...
  • 飞哈远程桌面连接软件也叫 远程桌面连接器,同时也是一个小型浏览器,是纯绿色软件!单文件!可以替代Windows系统默认的远程桌面连接,可以批量管理WINDOWS 3389 服务器,适合拥有很多Windows服务器和VPS的朋友使用,当然也...
  • 在前面阐述windows远程桌面实现的一系列文中,其实主要阐述的内容是如何采集桌面图像和电脑声音为主, 包括windows下的各种采集方式,linux平台,macOS平台,iOS平台, 所以基本上70%-80%的内容,都是跟”采集“相关...
  • 远程桌面Web连接

    2013-06-21 16:03:14
    让IIS完美支持“远程桌面Web连接”功能 让IIS完美支持“远程桌面Web连接”功能,IIS 发布之后访问远程桌面
  • mstsc.js Mstsc.js是使用nodejs, 和socket.io的纯JavaScript Microsoft RDP(远程桌面客户端)客户端。 它允许您通过Web浏览器(针对Firefox进行了优化,但也与chrome和Internet Explorer 11兼容)连接到任何与终端...
  • VNC 是在基于 UNIX和 Linux操作系统的免费的开源软件,远程控制能力强大,高效实用,其性能可以和 Windows和MAC中的任何远程控制软件媲美。 VNC基本上是由两部分组成:一部分是客户端的应用程序(vnc viewer);另外...
  • Guacamole可以同HTML5来代理远程桌面协议(如: VNC, RDP, Telnet, SSH) 官网: http://guac-dev.org/ 其由许多部件组成的轻量级web应用程序,大部分的功能依靠Guacamole的底层组件>来完成。 用户通过浏览器连接到...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,710
精华内容 13,084
关键字:

浏览器实现远程桌面