序言

    此篇是在本人学习过程中的感悟与摘录总结，欢迎大家来学习了解、
若存在偏差或错误，希望可以多多留言补充指正一起学习。

    谨以此篇来给更多的初学小白了解指惑，并用作自己的日后梳理与
复习。也希望可以通过此篇对您有所帮助，节约搜索时间。

一、什么是WebSocket？

如果用一句话来概括：WebSocket一种基于TCP的全双工通信协议，允许客户端和服务器之间建立持久连接，双方可以随时互相发送数据，无需客户端反复发起请求。

若HTTP是打电话的话（问一句，答一句，不提问不应答）详情可见第二部分HTTP的轮询机制。那么WebSocket就是打视频（双方互相能说话、展示画面，一直保持连接状态）。

由此WebSocket特点便是：持久连接、全双工、双向实时、轻量（header小）、基于TCP（可靠传输）。

二、WebSocket的由来——诞生于HTTP

（1）HTTP的发展历程及设计初衷

HTTP诞生于20世纪90年代，互联网刚起步，核心目的是“让用户通过浏览器访问远程服务器上的静态资源”（如HTML页面、图片、文本文件）。

设计初期开发者并没有考虑到：现在的网页游戏等众多需要时时交互的场景，HTTP的设计初衷，是“高效、简单地完成静态资源的单向请求与响应”，本质是一种「请求-响应式」的短连接协议，只够适配当时互联网“浏览静态内容”的大环境。

大致可总结为以下三点：

• 简单易用：协议逻辑简单，客户端（浏览器）只需发送请求（携带资源路径），服务器只需返回响应（携带资源内容），无需复杂的连接维护，降低开发者和浏览器厂商的实现成本。

• 无状态：服务器不记录客户端的请求历史，每个请求都是独立的“一次性交互”——这在当时是优势，因为静态资源请求无需上下文，无状态可减少服务器内存占用，支持更多客户端并发。

• 可扩展：协议本身预留了扩展空间（如请求头、响应头可自定义字段），为后续支持动态资源、缓存、认证等功能埋下伏笔，适配互联网的快速发展。

①HTTP定时轮询（Polling）

定时轮询机制：客户端通过定时器（如JavaScript的setInterval），每隔固定时间（如1秒、3秒），主动向服务器发送HTTP请求，查询是否有新数据。服务器无论是否有新数据，都会立即返回响应，响应结束后断开连接。无持久连接。常见于登录界面。

优点：实现简单，无需修改服务器核心逻辑。

缺点：① 资源浪费严重：即使没有新数据，客户端也会频繁发送请求，占用客户端带宽、服务器CPU和连接资源；② 延迟明显：延迟取决于轮询间隔（间隔短→资源浪费更严重，间隔长→延迟更高）。

总结来说这只适用于：对实时性要求极低、并发量小的场景（如后台简单通知、非核心数据更新等）。

②HTTP长轮询（Long Polling）

HTTP长轮询：客户端向服务器发送HTTP请求后，服务器不会立即返回响应。

• 若有新数据，立即返回。
• 若没有新数据，服务器会“挂起”该请求（保持连接一段时间，如30秒），期间如果有新数据产生，立即返回响应；若超时（30秒内无新数据），则返回空响应，客户端收到响应后，立即重新发起新的长轮询请求，循环往复。

HTTP长轮询优化了定时轮询的资源浪费问题，但仍基于HTTP请求-响应模式。

• 请求挂起→有数据立即响应→超时重连

优点：① 比定时轮询更节省资源：无新数据时，不会频繁发送请求，仅保持一个挂起的连接；② 延迟低于定时轮询（有新数据立即返回）。

缺点：① 服务器压力较大：挂起的请求会占用服务器连接资源，并发量高时，服务器易被压垮；② 超时处理复杂：需处理请求超时、网络波动导致的连接断开，客户端重连逻辑繁琐；③ 仍有轻微延迟（取决于服务器挂起超时时间）。

总结来看长轮询适用于：对实时性有一定要求、并发量适中的场景（用户登录、网页聊天、简单消息推送等）。

（2）HTTPS的发展历程及设计初衷

HTTPS和HTTP同根同源：HTTPS在不改变HTTP核心逻辑和功能的前提下，通过增加加密层，实现“数据加密传输、身份验证、数据完整性校验”，保障敏感数据的传输安全。
核心目标是“兼容HTTP、弥补安全短板”，而非替代HTTP。

20世纪90年代末，互联网开始从“静态浏览”向“动态交互”升级，电商、在线支付、用户登录等场景逐渐普及，“数据传输安全”成为刚需。HTTP的明文传输、无身份验证、无完整性校验三大缺陷，无法满足敏感场景需求：

• 明文传输：数据在客户端与服务器之间传输时，未经过加密，中间节点（如路由器、网关）可直接窃取内容。

• 无身份验证：客户端无法确认服务器是否为“真实目标服务器”，易遭受钓鱼攻击。

• 无完整性校验：数据传输过程中，易被中间节点篡改（如篡改网页内容、订单金额），客户端无法察觉。

（3） HTTP与HTTPS——“同源共生，安全与基础的关系”

    HTTPS是HTTP的“增强版”，而非“替代版”，二者核心关系如下：

• 两者关系：HTTPS = HTTP + TLS/SSL加密层，二者核心请求-响应逻辑完全一致，HTTPS没有改变HTTP的任何核心功能，只是在HTTP的基础上增加了加密、身份验证、完整性校验的能力。

• 两者区别：核心差异在于“是否加密”（详见表格），HTTP明文传输、不安全，适合非敏感场景（如静态页面浏览）；HTTPS加密传输、安全，适合敏感场景（如登录、支付、用户信息传输）。

• 两者应用场景：同一个Web应用中，可同时存在HTTP和HTTPS（目前主流是HTTPS）。静态资源（图片、CSS）可通过HTTP传输，敏感接口（登录、支付）可通过HTTPS传输。HTTP使用80端口，HTTPS使用443端口；浏览器对HTTP网站标记“不安全”，对HTTPS网站标记“安全”（显示小锁图标）。

（4）HTTP/HTTPS与WebSocket——“基础与衍生，单向与双向（半双工、全双工）的关系”

还记得WebSocket的特点吗？允许客户端和服务器之间建立持久连接，双方可以随时互相发送数据。

WebSocket基于HTTP/HTTPS诞生的，核心解决HTTP/HTTPS“请求-响应”单向通信的痛点：

1. WebSocket依赖HTTP/HTTPS完成“握手初始化”：

• 若为普通场景，WebSocket通过HTTP请求（80端口）完成协议升级，流程与原有一致。

• 若为安全场景，WebSocket通过HTTPS请求（443端口）完成协议升级，此时称为“WSS协议”（WebSocket Secure），本质是“WebSocket + TLS/SSL加密”，与HTTPS的加密逻辑一致。

  无论基于HTTP还是HTTPS，WebSocket握手时的核心字段（Upgrade: 
  websocket、Connection: Upgrade）不变，仅端口和加密方式不同
  (详情可见第三部分的WebSocket握手流程)。
  

2. 两者区别：二者通信模型完全不同，HTTP/HTTPS是“请求-响应”单向通信，服务器只能被动响应；WebSocket是“全双工”双向通信，连接建立后，双方可随时互相发送数据，无需频繁请求。

3. 应用场景：在实际Web应用中，三者通常协同工作（如实时聊天+支付功能）：

   ①用户打开页面：通过HTTPS请求（443端口）获取页面静态资源（HTML、CSS、JS），保障资源传输安全。

   ② 用户登录/支付：通过HTTPS接口完成身份验证、支付操作，保障敏感数据安全。

   ③实时聊天/消息推送：页面加载完成后，通过WSS协议（基于HTTPS的WebSocket）与服务器建立持久连接，实现消息实时发送与接收。

   ④非敏感接口请求：若有普通列表查询等非敏感操作，可通过HTTP接口完成（目前主流仍用HTTPS，保障整体安全）。

对比种类	HTTP	HTTPS	WebSocket
通信模型	请求-响应（单向）	请求-响应（单向）	全双工（双向）
连接状态	HTTP/1.0短连接；HTTP/1.1+长连接	请求-响应（单向）	持久连接（握手后保持连接）
核心定位	基础资源传输，非敏感场景	安全资源传输，敏感场景	实时双向通信，高频交互场景
安全特性	明文传输，无安全保障	TLS/SSL加密，身份验证、完整性校验	普通WS明文；WSS（基于TLS）加密
依赖关系	独立协议，无需依赖其他协议	依赖HTTP，基于HTTP增加加密层	依赖HTTP/HTTPS完成握手初始化
常用端口	80	443	WS：8080；WSS：8443

三、WebSocket的握手流程

WebSocket依赖HTTP完成“握手初始化”
WebSocket本身不具备“建立连接”的初始化能力，它需要借助HTTP的请求流程，
完成协议升级，具体过程如下：

1. 客户端想要建立WebSocket连接时，会先发送一个「特殊的HTTP请求」，请求头中携带关键字段，告知服务器“我要升级为WebSocket协议”：

   • Connection: Upgrade （配合Upgrade，标识该HTTP请求是一个协议升级请求）
   • Upgrade: websocket （核心字段，表明要升级协议为WebSocket）
   • Sec-WebSocket-Key: 随机字符串（用于服务器验证，防止误升级）

2. 服务器接收请求后，验证字段合法性，若支持WebSocket协议，则返回HTTP 101响应（切换协议），响应头中携带：

   • Connection: Upgrade
   • Upgrade: websocket
   • Sec-WebSocket-Accept: 由客户端的Sec-WebSocket-Key加密生成（确认握手成功）

3. 响应完成后，HTTP连接正式升级为WebSocket连接，后续通信不再走HTTP协议，直接通过TCP传输数据（全双工、持久连接）。

总得来说：首先要经过TCP的三次握手，再将HTTP协议升级为WS协议，之后双反再按照WS的数据格式进行通信。他的连接初始化，完全依赖HTTP的请求-响应流程，没有HTTP，WebSocket无法完成握手建立连接。

四、WebSocket的应用——前端网页的视频通话（理论上的实现）

此部分主要讲的是第五小节中流程图上，所涉及到的、围绕WebSocket来实现的相关技术，
建议和第五小节中的示意图一起查看。

（1）Netty

①什么是Netty

Netty是一款基于Java NIO（非阻塞I/O）的高性能、可扩展的网络通信框架，核心作用是“简化TCP/UDP服务器/客户端的开发”，解决原生Java NIO编程复杂、易出错、性能优化繁琐的问题。

②Netty的由来

Netty起源于JBoss公司，最初是为了解决JBoss Remoting（JBoss的远程调用框架）中的网络通信痛点而研发。早期Java NIO编程复杂度极高，手动处理I/O多路复用、线程管理、异常恢复等场景易出错，且开发效率低下，Netty的核心初衷就是“封装原生Java NIO，提供一套简单易用、高性能的网络通信开发框架”，后来独立成为开源项目，成为Java领域最主流的网络框架之一。

③Netty作用——保证IO

• 简化网络编程复杂度，封装原生NIO的底层细节（如I/O多路复用、TCP粘包/拆包、异常处理）。
• 提供高性能支撑，通过Reactor线程模型、零拷贝、内存池、事件驱动等核心特性，解决原生NIO的性能瓶颈和线程安全问题。
• 可支撑高并发、低延迟的网络通信场景；有极强的可扩展性，支持自定义协议编解码、断线重连、流量控制等，适配各类网络通信场景（TCP/UDP、HTTP、WebSocket等）。

对于WebSocket：

• 简化WebSocket服务端开发，原生Java实现WebSocket服务需手动处理TCP握手,WebSocket帧解析、并发连接管理等,Netty提供了成熟的WebSocket编解码器(WebSocketServerCodec),可直接复用，快速搭建WebSocket服务。
• 提升WebSocket服务性能，Netty的高性能特性的能支撑万级、十万级客户端同时在线的WebSocket连接（如直播弹幕、大规模实时通知），解决原生实现的并发瓶颈。
• 增强WebSocket服务的稳定性和可维护性，内置完善的异常处理、心跳检测机制，可有效避免WebSocket连接异常断开、资源泄漏等问题，降低后期维护成本。

（2）WebRTC

①什么是WebRTC

WebRTC全称Web Real-Time Communications（网页实时通信），是一套开源的实时音视频通信技术标准，由JavaScript API + 底层通信协议组成，核心特点是“无需安装插件/客户端，仅通过浏览器（或原生应用）就能实现端到端的实时音视频、数据传输”，本质是“让网页/应用具备实时通信能力的技术工具包”。

②WebRTC的由来

WebRTC最初由Google公司研发，起源于2010年Google收购的Global IP Solutions（GIPS）公司的相关技术——当时网页实时音视频通信存在“依赖插件、兼容性差、开发复杂、收费昂贵”的痛点，Google收购后整合自身技术，将其开源并提交给万维网联盟（W3C）和互联网工程任务组（IETF）标准化，最终在2021年成为W3C和IETF正式推荐标准，成为线上实时音视频通信的核心技术基石。

③WebRTC的作用——与WebSocket配合使用

• 提供三大核心能力（开发者高频用到）—— 媒体捕获（获取设备摄像头、麦克风、屏幕内容）、媒体编解码（对音视频数据压缩/解压，保证传输效率和质量）、P2P连接（端到端直接通信，减少服务器中转，降低延迟、节省带宽）。
• 简化实时音视频开发流程，无需手动处理音视频采集、编解码、网络传输等复杂底层细节，通过其提供的API就能快速实现功能；支持跨平台兼容（主流浏览器、移动端、桌面端均支持），降低跨设备开发成本；开源免费，无需支付第三方音视频组件的授权费用，降低项目成本。
• 网页/APP实时音视频通话（客服通话、视频会议）、屏幕共享（远程协助、在线授课）、实时直播连麦、点对点文件传输、AR/VR实时互动等。

总结：WebRTC 不依赖WebSocket，但常与WebSocket配合使用—— WebRTC负责端到端的音视频传输，WebSocket负责传递“通话建立/断开指令、房间管理、用户状态”等控制消息；二者不是替代关系，而是互补关系，常用于复杂实时通信场景（如多人视频会议）。

（3）ICE（Interactive Connectivity Establishment）

①ICE定义

ICE（Interactive Connectivity Establishment）是一套更全面的NAT穿透框架（不是单一服务器），核心作用是“统筹STUN服务器、TURN服务器（可选，用于极端穿透失败场景），为两台内网设备找到一条可行的P2P连接路径”，确保WebRTC等实时通信能顺利建立。

②ICE核心作用

• 收集“候选连接地址”—— ICE会收集设备的所有可能用于连接的地址，包括：设备自身的内网IP（本地地址）、通过STUN服务器获取的公网反射地址、（可选）通过TURN服务器获取的中继地址。

• 筛选最优连接路径—— ICE会将收集到的候选地址传递给对方设备（通常通过WebSocket传递控制消息），然后对每一对候选地址进行“连接测试”（通过STUN协议发送测试消息），筛选出延迟最低、最稳定的连接路径。

• 降级兜底—— 如果所有P2P路径测试都失败（比如两台设备均处于严格的对称NAT后），ICE会自动降级到TURN服务器（中继模式），通过TURN服务器转发音视频数据，确保通信不中断（ICE框架包含STUN和TURN的适配逻辑）。

（4）STUN（Session Traversal Utilities For Nat）

①STUN定义

STUN（Session Traversal Utilities For Nat）是一套简单的网络协议+服务器程序，核心作用是“帮助内网设备获取自己的外网IP和端口”，并判断自身所处的NAT类型，为后续建立P2P连接提供基础信息。

②STUN核心作用

• 获取内网设备的公网IP和端口（称为“反射地址”），比如你的电脑在内网（IP：192.168.1.100），通过STUN服务器查询后，能获取到路由器分配的公网IP（如220.181.xxx.xxx）和端口，这个公网地址就是你设备在公网上的“唯一标识”。

• 检测设备所处的NAT类型（如锥形NAT、对称NAT），不同NAT类型的穿透难度不同，STUN会将检测结果返回给设备，供ICE协议选择合适的连接方式。

（5）图示总结

①通讯流程

• 首先：A和B并不清楚自己的IP和端口。向服务器发送请求，此时已经记录下来了A的IP和端口。并返回给双方（相当于查询），而服务器就是通信双方互相认识的媒介。
• 其次：真正做通信管理的还是后端的Netty和WebSocket技术，netty保证了通信/IO可靠（通信双方互相稳定可听可见），WebSocket保证两端的长连接。
• 最后：若要在网页进行通信，需要用到WebRTC技术（浏览器中内置技术。支持音视频通信，实现音视频采集编码。），但是此技术不负责让两个设备进行连接。此时就需要用到WebRTC中的ICE技术，解决让两个不同的网络设备找到彼此的框架。
• 信令交换：相当于“敲门+协商”——告诉对方“我要和你视频”“我这边的音视频参数是什么“我的网络地址是什公”，由WebSocket+Netty 负责。
• 端到端音视频传输：协商完成后，直接在两个客户端之间传输音视频数据，不经过服务端中转 (P2P)，由WebRTC负责。

②总结

客户端A— WebSocket 连接→ Netty 服务端 （注册）
客户端B— WebSocket 连接→ Netty 服务端 （注册）

客户端A发起呼叫——→信令（含 SDP 提议）——→服务端转发——→客户端B——→
客户端B应答——→信令（含 SDP 应答) ——→服务端转发——→客户端 A双方交换ICE 候选（网络地址）——→建立 WebRTC P2P 连接——→实时音视频传输

转载自CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/m0_50871819/article/details/157770721