WebSocket如何实现浏览器与服务器实时通信?

摘要:在很多开发者的认知里,Web 开发似乎总是围绕着 HTTP 请求 → 服务器响应 这套经典流程。 比如: 刷新页面获取新数据轮询接口查看是否有更新每隔几秒请求一次服务器 但问题来了—— 如果你要做 聊天系统、实时股票行情、在线游戏、协同编辑
在很多开发者的认知里,Web 开发似乎总是围绕着 HTTP 请求 → 服务器响应 这套经典流程。 比如: 刷新页面获取新数据轮询接口查看是否有更新每隔几秒请求一次服务器 但问题来了—— 如果你要做 聊天系统、实时股票行情、在线游戏、协同编辑、直播弹幕 呢? 难道每一秒都发一次 HTTP 请求? 服务器可能会直接“原地去世”。 于是,一个改变 Web 实时通信方式的技术诞生了: WebSocket。 今天这篇文章,我们就从零开始,一次性把 WebSocket 讲透。 看完你将会明白: WebSocket 为什么会出现WebSocket 和 HTTP 的区别WebSocket 的工作原理WebSocket 的实际应用场景WebSocket 在项目中的使用方式 如果你是 大三计算机学生 / 后端开发初学者 / 正在准备实习,这篇文章绝对值得收藏。
一、为什么会有 WebSocket? 在 WebSocket 出现之前,浏览器和服务器通信几乎全部依赖 HTTP 协议。 HTTP 有一个非常重要的特点: 它是“请求-响应”模型。 也就是说: 客户端必须先发起请求,服务器才能返回数据。 简单来说就是: 客户端问一句 服务器答一句 比如: 浏览器:给我用户信息 服务器:好的,这是数据 但如果服务器想主动通知客户端呢? 比如: 新消息来了股票价格变化了游戏玩家位置更新协同文档被别人修改 HTTP 就有点尴尬了。 因为: 服务器不能主动推送数据。
传统解决方案 在 WebSocket 出现之前,开发者尝试过很多“曲线救国”的方案。 1 轮询(Polling) 最简单粗暴: 每隔1秒请求一次服务器 伪代码: setInterval(()=>{ fetch("/message") },1000) 问题也很明显: 请求数量爆炸服务器压力巨大很多请求其实没有新数据 总结一句话: 浪费资源。
2 长轮询(Long Polling) 改进版的轮询。
阅读全文