这是一个创建于 2025 天前的主题，其中的信息可能已经有所发展或是发生改变。
创建虚拟局域网？
websocket ？
p2p ？
websocket ？
p2p ？
第 1 条附言 · 2019-05-02 13:52:01 +08:00
之前的主题太简单了，让大家误解了我的意思。
我指的不是仅仅是推送更不是 xhr 轮询，。
在局域网中，可以通过广播（多播？）收到消息然后马上回应。
那么 ws 的技术原理是什么？
在 web 之外，实时通信非常常见，聊天工具，多人游戏，他们的原理是什么，
p2p 的原理又是什么？
据我所知，魔兽争霸（红色警戒）只要在同一个局域网就可以发现对方联网，不知道 BN 的原理是什么，浩方等对战平台是建立一个虚拟局域网。现在万人房间，在游戏之前不知道是什么，在开始游戏时，就只有这几个人的虚拟局域网。
虚拟局域网的原理是什么？
webrtc 只是一个框架，他支持各种各样的实时通信，但本身不提供实时通信。
我指的不是仅仅是推送更不是 xhr 轮询，。
在局域网中，可以通过广播（多播？）收到消息然后马上回应。
那么 ws 的技术原理是什么？
在 web 之外，实时通信非常常见，聊天工具，多人游戏，他们的原理是什么，
p2p 的原理又是什么？
据我所知，魔兽争霸（红色警戒）只要在同一个局域网就可以发现对方联网，不知道 BN 的原理是什么，浩方等对战平台是建立一个虚拟局域网。现在万人房间，在游戏之前不知道是什么，在开始游戏时，就只有这几个人的虚拟局域网。
虚拟局域网的原理是什么？
webrtc 只是一个框架，他支持各种各样的实时通信，但本身不提供实时通信。
 |
1
Flasky 2019-05-02 01:13:40 +08:00 via Android
以前用过 websocket 来控制小车，加上 WiFi 延迟，实时性还是可以的，至少肉眼感觉不出来
|
 |
2
dfjslkjdf 2019-05-02 01:19:37 +08:00
是指网页吗？
websocket |
 |
3
2kCS5c0b0ITXE5k2 2019-05-02 01:26:42 +08:00
ws
|
 |
4
ochatokori 2019-05-02 03:49:09 +08:00 via Android
1、ws
2、网页微信那种：轮询+延迟响应 |
 |
5
zzjas98 2019-05-02 05:35:46 +08:00
1. WebSocket
2. HTTP Pull |
 |
6
luozic 2019-05-02 06:02:25 +08:00 via iPhone
完全实时的 web ？那是不用想了。 准实时的 websocket 自行包装一下啥 Rsocket 等等都可以做。
|
 |
7
Enochyun 2019-05-02 06:56:00 +08:00
websocket 稳稳的
|
 |
8
tomoya92 2019-05-02 08:24:00 +08:00 via iPhone
我用 socketio 写了个任务管理系统，楼主可以参考一下，操作全都是 ws 通信 https://github.com/tomoya92/pyteam
|
 |
9
linchengzzz 2019-05-02 08:32:58 +08:00 via Android
Web socket
|
 |
10
dremy 2019-05-02 08:48:40 +08:00 via iPhone
Web Real-Time Communication，简称 Web RTC
|
 |
11
zuoakang 2019-05-02 08:55:31 +08:00 via Android
ws
|
 |
12
BBCCBB 2019-05-02 09:10:16 +08:00
long pooling http
|
 |
13
jinliming2 2019-05-02 09:44:59 +08:00 via iPhone  3
Web 的话，受浏览器限制，与服务器通信只有通过浏览器提供的接口，XHR / fetch 或是 WebSocket，当然还有 WebRTC。其他的，也只能是这些的封装罢了，或是浏览器根据新标准推出新的 API。各种第三方库也都是普通封装，比如 Socket.IO 封装了 WebSocket，帮你处理心跳包，并对文本进行格式化封装以支持直接发送 JavaScript 对象数组（ JSON ），在 WebSocket 连接失败后自动切换到短轮询。gRPC-Web 则是引入了 protobuf 二进制库，然后通过 POST 与中间代理服务器进行通讯，代理服务器将请求掐头去尾转给后端 RPC 服务。
GET、POST 以及其他方法也都受限制，比如同源策略，GET 不能带 body 之类的（其他地方则没有这个限制，比如 ElasticSearch 带 body 的 GET 请求），URL 必须编码，并且总长度有限制之类的。 在没有 Websocket 和 WebRTC 之前，用的长轮询、短轮询。 短轮询就是你本地不断请求服务器的一个 API 接口，没消息的话服务器会直接返回空，本地延迟几秒再重新请求。这种方法貌似没多少在用：本地延迟短的话，HTTP 请求消耗太大（那时还是 HTTP/1.1 ），本地延迟长的话，消息不够及时。 长轮询也是你本地不断请求服务器的一个 API 接口，不一样的是没消息的话，服务器不返回数据，一直持有这个连接，而本地也一直等待服务器返回，一旦有新消息，服务器会通过持有的这个连接立即返回数据。如果长时间没有消息的话，有个超时时间，超时后连接断开，本地无延迟立即重新请求。这个相比短轮询就好很多了，在 Websocket 出来之前，这种方法算是主流，常年不维护的 QQ 邮箱就是这种方法一直用到今天还在用。 Websocket 出来之后，就取代了长轮询，其实原理和长轮询差不多，也是请求一个接口，然后进行协商协议升级，从 HTTP 升级到 WebSocket，服务器持有这个连接不断开，就可以一直发送消息了。相比长轮询，这个连接没有浏览器硬性的超时时间限制，并且无需断开，支持双向同时通信，无限发送消息文本或二进制数据，并且不用每次发消息都带臃肿巨大的 HTTP 协议头，可以节省很大的资源。为避免 TCP 意外断开，会要求每隔几秒发个心跳包，这个只要一两个字节就够了。 WebRTC 则更多的是面向实时视频、音频这类多媒体服务的。当然，也可以传任意文本、二进制。 |
 |
14
nolest 2019-05-02 09:51:41 +08:00
Websocket
WebRTC 看对于延迟的需求 其实就是帧结构的解析 服务端对流打包 H264 什么的 |
 |
15
abowloflrf 2019-05-02 11:35:23 +08:00
前几天刚写了一篇简单的对比文章： https://ruofeng.me/2019/04/27/realtime-in-web/
|
 |
16
ipwx 2019-05-02 11:41:12 +08:00
单向：long poll, server event push, websocket
双向：websocket |
Select Language