大家好，感谢邀请，今天来为大家分享一下谷歌浏览器 websocket的问题，以及和谷歌浏览器 websocket不推送的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

本文目录

1. 手机版的chrome和UC浏览器到底支不支持WEBSOCKET
2. rtsp流浏览器播放方案
3. 微信的内置浏览器支持websocket吗
4. 求教下怎么不用浏览器连接websocket
5. 网页打印时提示websocket没有准备好
6. java websocket CloseStatus 1009 如何解决

一、手机版的chrome和UC浏览器到底支不支持WEBSOCKET

我测试安卓上 ChromeV30 V31可以运行的WEBSCOCKET代码在UC9.4上还是不能运行，但是HTML5TEST网站上显示UC支持WEBSOCKET，这个就不知道为何了,难道UC为了跑分欺骗了HTML5TEST?要知道UC得分还是很高的。

始终不明白的是，UC的内核检测下来还是WEBKIT，和Chrome的一样的，就是版本略低，不知道为何同样内核的UC就么办法和Chrome一样？

二、rtsp流浏览器播放方案

rtsp流在主流浏览器并不支持直接播放。比如大华的视频流：rtsp://admin:123456@

192.168.10.129/cam/realmonitor?channel=1&subtype=0，用vlc可以直接播放。但在浏览器会报ERR_UNKNOWN_URL_SCHEME。那如何在浏览器中播放呢。

1、安装插件（chrome最新版基本都不支持）

类如：kurento，vlc插件（谷歌浏览器版本41以下),vgx插件(不支持高版本，chrome72.0版本可用)等。

2、安装软件（中间件，基本都付费）

类如：Appemit（调用vlc插件播放rtsp），可以免安装的，目前只能windows,免费版会有提示。

猿大师中间件（底层调用VLC的ActiveX控件，实现在主流浏览器网页中内嵌播放多路RTSP的实时视频流），中间件收费的。

PluginOK(牛插)中间件。底层调用ActiveX控件VlcOcx.dll。（商业用途需付费使用）

推流--------------服务器转发--------------拉流

a,vlc软件串流到http协议，网页显示几个视频需启动几个vlc,只适合应急场景。

b,html5+ websocket_rtsp_proxy实现视频流直播，基于MSE（Media Source Extensions,W3C），扩展H5的功能。

步骤：服务器安装streamedian服务器，客户端通过video标签播放。

基于nginx实现rtmp转化，用flash实现播放。由于flash目前大多浏览器默认禁用，不推荐此方式。

步骤：安装ffmpeg工具,安装nginx。

另外nginx-rtmp-module也支持HLS协议,可以搭建基于hls的直播服务器。

d.rtsp转hls播放,通过ffmpeg转码

步骤：安装ffmpeg工具，ffmpeg转码。

ffmpeg-i"rtsp://admin:123456@192.168.10.129/cam/realmonitor?channel=1&subtype=0"-c copy-f hls-hls_time 2.0-hls_list_size 0-hls_wrap 15"D:/hls/test.m3u8"

缺点是直播流延时很大，对实时要求比较高的不满足要求。

案例：基于EasyDarwin拾建转码服务器。参考地址:

e.websocket代理推送，FFMPEG转码

（1）Gin+WebSocket+FFMPEG实现rtsp转码,参考：

通过FFMPEG把rstp转成http，ginrtsp作为转发服务器，但需要自己写相应接口，需要了解go语言。

（2）node+ ffmpeg+ websocket+ flv.js，参考：

步骤：在node服务中建立websocket；通过fluent-ffmpeg转码，将RTSP流转为flv格式；通过flv.js连接websocket，并对获取的flv格式视频数据进行渲染播放。

import WebSocket from'ws'import webSocketStream from'websocket-stream/stream'import ffmpeg from'fluent-ffmpeg'//建立WebSocket服务const wss= new WebSocket.Server({ port: 8888, perMessageDeflate: false})//监听连接wss.on('connection', handleConnection)//连接时触发事件function handleConnection(ws, req){ //获取前端请求的流地址（前端websocket连接时后面带上流地址）  const url= req.url.slice(1) //传入连接的ws客户端实例化一个流  const stream= webSocketStream(ws,{ binary: true}) //通过ffmpeg命令对实时流进行格式转换输出flv格式  const ffmpegCommand= ffmpeg(url)  .addInputOption('-analyzeduration','100000','-max_delay','1000000')  .on('start', function(){ console.log('Stream started.')})  .on('codecData', function(){ console.log('Stream codecData.')})  .on('error', function(err){    console.log('An error occured:', err.message)    stream.end()  })  .on('end', function(){    console.log('Stream end!')    stream.end()  })  .outputFormat('flv').videoCodec('copy').noAudio()  stream.on('close', function(){   ffmpegCommand.kill('SIGKILL') })  try{  //执行命令传输到实例流中返回给客户端   ffmpegCommand.pipe(stream) } catch(error){   console.log(error) }}

优点全部基于js。前端即可搞定。

参考:

三、微信的内置浏览器支持websocket吗

微信的内置浏览器支持websocket。

1、Android版微信没问题，因为使用的是QQ浏览器内核，不受本身系统浏览器影响。

2、iOS版微信没问题，使用的是Safari浏览器。

3、WindowsPhone版微信没问题，使用的是WP8。

WebSocket浏览器端兼容性对比图：

注：虽然Android4.3及以下系统浏览器都不支持WebSocket，但在微信内置QQ浏览器内核，解决了这一问题。

四、求教下怎么不用浏览器连接websocket

1、你可以把 WebSocket看成是 HTTP协议为了支持长连接所打的一个大补丁，它和 HTTP有一些共性，是为了解决 HTTP本身无法解决的某些问题而做出的一个改良设计。在以前 HTTP协议中所谓的 keep-alive connection是指在一次 TCP连接中完成多个 HTTP请求，但是对每个请求仍然要单独发 header；所谓的 polling是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP请求查询是否有新数据。这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。它们建立的“长连接”都是伪.长连接，只不过好处是不需要对现有的 HTTP server和浏览器架构做修改就能实现。

2、WebSocket解决的第一个问题是，通过第一个 HTTP request建立了 TCP连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真.长连接。但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP协议是有区别的，所以它需要对服务器和客户端都进行升级才能实现。在此基础上 WebSocket还是一个双通道的连接，在同一个 TCP连接上既可以发也可以收信息。此外还有 multiplexing功能，几个不同的 URI可以复用同一个 WebSocket连接。这些都是原来的 HTTP不能做到的。

3、另外说一点技术细节，因为看到有人提问 WebSocket可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的 WebSocket真.长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。

4、比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的 WebSocket长连接，就可能在毫不知情的情况下进入了半死不活状态。

5、而解决方案，WebSocket的设计者们也早已想过。就是让服务器和客户端能够发送 Ping/Pong Frame（RFC 6455- The WebSocket Protocol）。这种 Frame是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application的情况下维持住中间网络的连接状态

五、网页打印时提示websocket没有准备好

1、网页打印时提示websocket没有准备好就是浏览器的设置错误，只要换成谷歌就可以正常使用。WebSocket是HTML5一种新的协议。

2、WebSocket实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，建立在TCP之上，同HTTP一样通过TCP来传输数据，一些浏览器反映要慢一些，所以更换浏览器就可以正常使用了。

3、WebSocket是一种双向通信协议，在建立连接后，WebSocket服务器和Browser/ClientAgent都能主动的向对方发送或接收数据，就像Socket一样；

4、WebSocket需要类似TCP的客户端和服务器端通过握手连接，连接成功后才能相互通信。相对于传统HTTP每次请求-应答都需要客户端与服务端建立连接的模式，WebSocket是类似Socket的TCP长连接的通讯模式。

六、java websocket CloseStatus 1009 如何解决

1、之前服务端和客户端都部署在本机时，订阅和接收信息都正常。但是把服务端部署到其他机器，客户端部署在本地通信时，服务端可以收到客户端的订阅信息，但是客户端过了一会就报如上错误。

2、查了官方api介绍说这个错误代码断开连接是正常的，一直找不到原因。

3、后来写了个html的测试界面用谷歌浏览器登录与服务端连接并请求订阅，用谷歌浏览器的开发者工具监控websocket的通讯情况，发现服务端确实是有返回订阅请求信息的！不过数据量很大。

4、后来猜测是服务端发送过来的数据量太大了，通讯时间过长导致客户端以为没有响应信息就自己断开连接了。

5、在客户端加上下面黄色标注的代码，接收数据时先压缩，果然解决了问题

关于谷歌浏览器 websocket和谷歌浏览器 websocket不推送的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。