Socket与WebSocket与http协议的区别

Socket是一个便于使用 TCP/UDP 的接口规范 WebSocket是一个应用层协议，和http相似。

Socket与WebSocket处于的网络层级是不对等的，很难直接比较。WebSocket在网络七层协议上的层级等同于Http，而Socket位置处于七层协议中的第四层，Socket是操作系统对TCP、UDP的封装。WebSocket处在上层，Socket处在下层，WebSocket依赖于Socket，Socket为WebSocket服务。

那么应该是拿WebSocket与Http进行比较。WebSocket常见于客户端-服务端全双工的场景，客户端可以发送消息给服务端，同时服务端也可以主动发送消息给客户端。而Http是单向的关系。只能客户端发送请求，服务端被动接收，服务端没有主动发起对话的能力。

聊天是一个典型的全双工场景：聊天的双方先将消息发送给服务端，服务端在把消息转给对方。如果使用WebSocket，得益于全双工，整个逻辑非常顺畅。而Http场景下，服务端没有主动发起请求的能力，只能维持Http长链接，或者客户端定时轮询服务端，获取最新的信息。

不过WebSocket并不普及。完整的WebSocket通信，需要客户端（浏览器）、服务端、网关节点、防火墙等一套的支持。尤其对于面向用户的环境来说，用户使用的浏览器、用户所处的网络环境，都是不能控制的。这种情况下建议不要使用WebSocket。

WebSocket协议的实践

WebSocket库

WebSocket 是WebSocket协议的Go实现需要手段处理 心跳机制，数据持久化 问题

Socket.IO库

WebSocket 是一种在服务器和浏览器之间提供全双工和低延迟通道的通信协议，Socket.IO 是一个库，建立在WebSocket协议之上，不是WebSocket 实现，可以在客户端和服务器之间实现低延迟、双向和基于事件的通信。

JavaScript的实现2（可以在浏览器、Node.js 或 React Native 中运行）
- 安装步骤
- API
- 源代码以下是 Socket.IO 在普通 WebSockets 上提供的功能：

HTTP 长轮询

虽然WebSocket也可以，不过他

Even if most browsers now support WebSockets (more than 97%), it is still a great feature as we still receive reports from users that cannot establish a WebSocket connection because they are behind some misconfigured proxy.

自动重连

在某些特定情况下，服务器和客户端之间的 WebSocket 连接可能会中断，而双方都不知道链接的断开状态。

这就是为什么 Socket.IO 包含一个心跳机制，它会定期检查连接的状态。

当客户端最终断开连接时，它会以指数回退延迟自动重新连接，以免使服务器不堪重负。

默认情况下，Socket.IO客户端将每15秒（ 心跳间隔 ）向服务器发送一个心跳，如果服务器在20秒内未从客户端听到任何消息（ 心跳超时
），它将认为客户端已断开连接。

数据包缓冲

当客户端断开连接时，数据包会自动缓冲，并在重新连接时发送。

更多信息在这里。

注意⚠️

缓冲事件

默认情况下，在 Socket 未连接时发出的任何事件都将被缓冲，直到重新连接。

虽然在大多数情况下很有用（当重新连接延迟很短时），但它可能会在连接恢复时导致大量事件。

有几种解决方案可以防止这种行为，具体取决于您的用例：

使用Socket 实例的connected属性

if (socket.connected) {
  socket.emit( /* ... */ );
} else {
  // ...
}

复制

使用易变事件

socket.volatile.emit( /* ... */ );

参考：socket.io/docs/v4/how…

选择哪个库去实现

都可以，哪个更新勤快些，有人维护就用哪个吧

Socket和WebSocket的区别