WebSocket知识点笔记(一)
WebSocket
WebSocket是一种在单个TCP连接上进行全双工通信的协议。它使得客户端和服务端之间的消息传递更加高效，允许服务器主动向客户端推送数据。
一.WebSocket全双工通信
WebSocket提供了真正的双向通信，客户端和服务端可以同时发送和接收消息
1.1传统HTTP模型 vs WebSocket全双工模型
1.1.1 HTTP请求/响应模型
1.客户端发起请求，服务器响应
2.每次通信都需要建立新的TCP连接，增加了延迟
3.服务器不能主动向客户端推送数据，只能在客户端请求时响应
1.1.2 WebSocket全双工通信
1.单个TCP连接保持打开状态，用于双向通信
2.客户端和服务端可以随时发送消息，无需等待对方完成操作
3.服务器可以主动向客户端推送数据，实现真正的实时通信
1.2 全双工通信的工作原理
1.2.1 连接建立(通过HTTP升级请求实现协议转换)
客户端通过WebSocket对象发起连接请求，使用HTTP协议中的Upgrade头将连接升级为WebSocket协议，服务器同意升级后，返回101状态码，并保持连接打开，直到被显式关闭。
1.初始HTTP请求
客户端通过标准的HTTP协议发起一个请求，该请求包含一个Upgrade头，表示希望将连接升级为WebSocket协议
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
2.服务器响应
如果服务器支持WebSocket并同意升级，它会返回一个101状态码(Switching Protocols)，并确认升级到WebSocket协议
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
3.连接保持打开
一旦握手成功，HTTP连接升级为WebSocket连接并保持打开状态，用于后续的双向通信，直到被显式关闭。
1.2.2 数据帧传输(使用帧结构封装数据，支持文本和二进制格式)
一旦连接建立，客户端和服务器可以在任何时候发送消息，消息以帧的形式进行传输，每个帧包含一个或多个数据包，客户端和服务器之间的消息传递是独立的，互不干扰的。
1.消息分帧
WebSocket使用帧(frame)来封装数据，每个帧包含一个或多个数据包，并且可以是文本或二进制数据。每个帧都有一个固定的头部结构，包括操作码(opcode)、负载长度等字段。
2.消息传递
客户端和服务器可以在任何时候发送帧，无需等待对方完成操作，发送的消息可以是完整的，也可以是分段的(多个帧组成一个完整的消息)。
3.控制帧
除了数据帧，WebSocket还定义了多种控制帧，如关闭帧(Close Frame)、Ping帧和Pong帧，用于管理和维护连接状态。
1.2.3 并发通信(客户端和服务器可以同时发送消息)
1.独立的数据流
WebSocket连接中的数据流是独立的，客户端和服务器可以同时发送和接收消息，互不干扰，这个特性使得双方可以在同一时间进行多任务处理，例如客户端发送用户输入的同时，服务器推送最新的通知。
1.2.4 连接管理(通过心跳机制和异常处理确保连接的稳定性和可靠性)
1.心跳机制
为了确保连接的有效性，WebSocket提供了心跳机制，客户端和服务端可以定期发送Ping和Pong帧来检测连接状态。如果一段时间内没有收到对方的响应，可以认为连接已断开，并采取相应的措施(如重连)。
2.异常处理
当出现网络故障或其他异常情况时，WebSocket连接可能会中断，此时客户端和服务器可以通过捕获异常时间(如onError和onClose)来进行处理。
例如，在Java中
@OnClose
public void onClose(Session session){
sessions.remove(session);
broadcast("User "+session.getId()+" disconnected",session);
}
@OnError
public void onError(Session session,Throwable error){
error.printStackTrace();
sessions.remove(session);
broadcast("User "+session.getId()+" encountered an error :" + error.getMessage(),session);
}
1.2.5 连接关闭
1.正常关闭
客户端或服务器可以主动发送关闭帧(Close Frame)来关闭连接，对方收到关闭帧后，也会发送一个关闭帧作为确认，然后双方关闭连接。
2.异常关闭
如果一方突然断开连接(如网络故障)，另一方会在一定时间内检测到连接丢失，并触发关闭事件。
二.WebSocket的优缺点
2.1 WebSocket的优势
2.1.1 低延迟
相比于传统的HTTP请求/响应模式，WebSocket减少了通信延迟，因为不需要每次都建立新的连接，减少了每次通信的握手时间。
1.即时消息传递
在传统的HTTP请求/响应模型中，客户端必须先发起请求，服务器才能响应。而WebSocket连接一旦建立，服务器可以主动向客户端推送数据，无需等待客户端请求。
这种即时消息传递显著减少了通信延迟，特别适合需要实时更新的应用场景。
2.减少握手开销
每次HTTP请求都需要重新建立TCP连接，这会增加额外的握手时间，而WebSocket连接保持打开状态，减少了频繁建立和关闭连接的开销，从而减低延迟。
2.1.2 高效资源利用
单个连接可以处理多条消息，减少了频繁建立和关闭连接的开销。
1.单个连接多个用途
WebSocket使用单个TCP连接进行双向通信，避免了频繁创建和销毁连接带来的资源消耗。相比于轮询(polling)和长轮询(long polling),WebSocket显著减少了网络带宽和服务器资源的占用。
2.轻量级协议头
WebSocket协议头信息非常小，相比于HTTP协议头，减少了不必要的网络流量，进一步提高了效率。
2.1.3 实时性
服务器可以主动推送数据给客户端，非常适合需要实时更新的应用场景
1.服务器推送
WebSocket允许服务器主动向客户端推送数据，实现了真正的实时通信，这对于需要及时更新的应用非常重要。
2.事件驱动架构
客户端和服务器可以在任何时候发送消息，基于事件驱动的架构使得应用能够快速响应用户操作和服务器通知，提供更好的用户体验。
2.1.4 简化开发
1.易于实现
WebSocket提供了简单的API，使得开发者可以轻松地在客户端和服务器之间建立双向通信。
例如，在Java中使用WebSokcet只需少量代码+注解即可实现基本功能。
@ServerEndpoint("/chat")
public class ChatServer {
private static Set<Session> sessions = Collections.synchronizedSet(new HashSet<>());
@OnOpen
public void onOpen(Session session) {
sessions.add(session);
broadcast("User connected: "+ session.getId(),session);
}
@OnMessage
public void onMessage(String message,Session session){
broadcast("User "+session.getId()+" : "+message,session);
}
@OnClose
public void onClose(Session session){
sessions.remove(session);
broadcast("User "+session.getId()+" disconnected",session);
}
@OnError
public void onError(Session session,Throwable error){
error.printStackTrace();
sessions.remove(session);
broadcast("User "+session.getId()+" encountered an error :" + error.getMessage(),session);
}
private void broadcast(String message,Session exclude){
synchronized (sessions){
for(Session session:sessions){
try {
if(session.equals(exclude)){
continue;
}
session.getBasicRemote().sendText(message);
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}
2.丰富的库支持
许多编程语言和框架都提供了对WebSocket的良好支持，developer可以选择适合自己项目的库或框架，快速构建WebSocket应用。
2.1.5 增强用户体验
1.无缝交互
WebSocket的全双工通信使得应用可以更流程地与用户互动，提供无缝的用户体验。例如，在线聊天应用中，用户可以立即看到其他用户的回复，而无需刷新页面。
2.实时反馈
对于需要实时反馈的应用，如在线游戏或协作编辑工具，WebSocket可以确保用户操作得到即时响应，增强用户的参与感和满意度。
2.1.6 适用于多种应用场景
1.实时聊天室
WebSocket可以实现实时的消息传递，非常适合构建聊天室或即时通讯应用，无需轮询服务器，提供流程的聊天体验。
2.协作编辑工具
允许多个用户同时编辑同一个文档，并实时同步修改。
3.在线游戏
对于需要低延迟交互的游戏，WebSocket提供了更好的性能，确保玩家的操作和游戏状态同步更新。
4.金融数据更新
WebSocket可以用来实时推送最新的股票价格或其他金融数据，帮助用户及时做出决策。
5.物联网设备监控
实时监控设备状态并推送更新给客户端，提高设备管理的效率。
2.2 WebSocket的缺点
2.2.1 连接保持开销
1.长时间占用资源
WebSocket连接一旦建立，会一直保持打开状态，直到显示关闭，这可能导致服务器资源(如内存、文件描述符等)被长时间占用，尤其是在高并发场景下。
2.网络带宽消耗
虽然WebSocket协议头比较小，但长时间保持连接仍然会占用一定的网络带宽，特别是在大量用户同时在线的情况下。
2.2.2 防火墙和代理问题
1.企业级网络限制
某些企业或组织的防火墙和代理服务器可能会组织WebSocket连接，因为它们默认只允许HTTP/HTTPS流量通过，这种限制可能需要额外的配置或使用HTTPS WebSocket(wss://)，但这增加了复杂性。
2.2.3 不支持断点续传
1.数据完整性问题
WebSocket不支持断点续传功能，如果连接意外中断，未完成的消息传输将丢失，需要重新发送整个消息。对于大文件传输或长时间的任务，这可能会导致效率低下或数据丢失。
2.2.4 浏览器兼容性
1.旧浏览器支持有限
尽管现代浏览器普遍支持WebSocket，但在一些老旧版本的浏览器中，WebSocket支持可能缺失或不稳定，developer可能需要提供回退机制(如轮询或长轮询)以确保兼容性。
2.2.5 复杂的错误处理
1.异常情况处理复杂
WebSocket连接可能会因为网络故障，服务器重启等原因突然断开，developer需要实现复杂的状态管理和重连逻辑，以确保应用的稳定性和可靠性。
2.心跳机制维护
为了确保连接的有效性，通常需要实现心跳机制(Ping/Pong帧)。虽然这有助于检测连接状态，但也增加了开发和维护的复杂性。
2.2.6 安全性考虑
1.加密需求
WebSocket默认不加密，必须通过WSS(WebSocket Secure)协议(使用TLS加密)来确保数据传输的安全性。实现WSS需要额外的配置和证书管理，增加了部署的复杂性。
2.跨域安全
WebSocket也面临跨域资源共享(CORS)的问题，需要在服务端进行适当的配置以确保安全访问。
2.2.7 不适合所有应用场景
1.非实时需求
对于不需要实时通信的应用场景，WebSocket可能是过度设计。例如，简单的表单提交或静态页面加载，使用传统的HTTP请求/响应模型更为合适。
2.高延迟容忍度
如果应用对延迟要求不高，或者可以接受一定的延迟，使用轮询或长轮询可能是更简单且有效的解决方案。