HTML5如何实现实时通讯_HTML缺少哪些能力【原理】

html5本身不提供实时通讯能力，实际依赖websocket、WebRTC等javaScript API实现；WebSocket需服务端配合且协议必须一致；WebRTC需手动处理信令和NAT穿透；HTML标签被动，无原生线程、socket或持久连接。

html5 本身不提供实时通讯能力，必须依赖 javascript API

HTML5 是标记语言规范，不内置网络通信逻辑。所谓“HTML5 实时通讯”，实际是浏览器通过 WebSocket、WebRTC 等 JavaScript API 实现的，HTML 文件只是承载这些脚本的容器。

常见误解是以为写个 或加个 async 属性就能实现实时——不行。没有 js 主动建立连接、处理信令、收发数据，HTML 标签本身完全被动。

WebSocket 是最常用的双向实时通道，但需服务端配合

WebSocket 提供全双工、低延迟的 TCP 连接，是 Web 实现实时消息、弹幕、协同编辑的主流选择。但它不是“开箱即用”的：

• 浏览器必须调用 new WebSocket("wss://example.com") 显式发起连接
• 服务端必须运行 WebSocket 服务器（如 node.js 的 ws 库、python 的 websockets），普通 http 服务器（如 nginx 默认配置）会直接拒绝升级请求
• HTTP/https 与 WS/WSS 协议不兼容：用 http:// 页面无法连接 wss://（混合内容被阻止），必须协议一致

const socket = new WebSocket("wss://api.example.com/chat"); socket.onmessage = (event) => {   console.log("收到:", event.data); }; socket.send(json.stringify({ type: "join", room: "dev" }));

WebRTC 支持点对点音视频，但信令和 NAT 穿透需额外处理

WebRTC 能绕过服务器直传音视频流，但 HTML 和浏览器不自动完成以下关键步骤：

立即学习“前端免费学习笔记（深入）”；

• 双方必须交换 SDP（会话描述）和 ICE 候选地址，这个过程叫“信令”——HTML 没有内置信令协议，得用 WebSocket 或 HTTP POST 自己实现
• 大多数用户在 NAT/防火墙后，需要 STUN/TURN 服务器辅助穿透；浏览器只提供 RTCPeerConnection API，不自带 STUN 服务
• 标签只是渲染载体，srcObject 必须手动赋值为 MediaStream，而流来自 navigator.mediaDevices.getUserMedia() 或远程 peerConnection

HTML 缺失的底层能力：无原生线程、无本地 socket、无持久连接管理

对比原生应用，Web 平台在实时通讯上存在硬性限制：

• 没有 fork() 或原生线程：Web Worker 不能直接操作 dom 或创建 socket，复杂信令逻辑仍需主线程协调
• 无法打开原始 TCP/udp socket：所有网络访问必须走 fetch、WebSocket、WebRTC 等沙箱化 API，不能自定义协议或复用已有 socket 库
• 页面卸载时连接立即中断：即使使用 beforeunload 也来不及可靠发送离线状态，Service Worker 无法维持长连接

这些不是“功能待完善”，而是安全模型决定的边界——浏览器不会给网页授予操作系统级网络权限。