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.1Host: example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Sec-WebSocket-Version: 13

2.服务器响应

如果服务器支持WebSocket并同意升级，它会返回一个101状态码(Switching Protocols)，并确认升级到WebSocket协议

    HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-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中

    @OnClosepublic void onClose(Session session){sessions.remove(session);broadcast("User "+session.getId()+" disconnected",session);}@OnErrorpublic 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<>());@OnOpenpublic void onOpen(Session session) {sessions.add(session);broadcast("User connected: "+ session.getId(),session);}@OnMessagepublic void onMessage(String message,Session  session){broadcast("User "+session.getId()+" : "+message,session);}@OnClosepublic void onClose(Session session){sessions.remove(session);broadcast("User "+session.getId()+" disconnected",session);}@OnErrorpublic 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.高延迟容忍度

如果应用对延迟要求不高，或者可以接受一定的延迟，使用轮询或长轮询可能是更简单且有效的解决方案。