HTML5本身不提供实时通讯能力，实际依赖WebSocket、WebRTC等JavaScript API实现；WebSocket需服务端配合且协议必须一致；WebRTC需手动处理信令和NAT穿透；HTML标签被动，无原生线程、socket或持久连接。
HTML5 本身不提供实时通讯能力，必须依赖 JavaScript API
HTML5 是标记语言规范，不内置网络通信逻辑。所谓“HTML5 实时通讯”，实际是浏览器通过 WebSocket、WebRTC 等 JavaScript API 实现的，HTML 文件只是承载这些脚本的容器。
常见误解是以为写个 <video> 或加个 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 服务器辅助穿透；浏览器只提供
RTCPeerConnectionAPI，不自带 STUN 服务 -
<video>标签只是渲染载体，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无法维持长连接
这些不是“功能待完善”，而是安全模型决定的边界——浏览器不会给网页授予操作系统级网络权限。
