网站 推广 工具,网上注册公司需要哪些材料和流程,上海做网站就用乐云seo十年,优秀的电子商务网站一、前言#xff1a;为何需要服务端主动推送#xff1f;
在现代应用中#xff0c;很多功能都依赖于“消息推送”。比如#xff1a;
小红点提醒#xff1a;我们经常在手机应用里看到的一个小红点提示#xff0c;表示有新的消息或任务需要我们关注。新消息提醒#xff1…一、前言为何需要服务端主动推送
在现代应用中很多功能都依赖于“消息推送”。比如
小红点提醒我们经常在手机应用里看到的一个小红点提示表示有新的消息或任务需要我们关注。新消息提醒在聊天应用中当有新消息时服务端需要通知客户端让用户看到新的内容。审批流提醒企业内部审批流程中一旦某个任务有了新的进展系统会主动推送通知提醒相关人员及时处理。 这些功能听起来非常常见但它们的实现并不是那么简单。特别是当需要实时或者高效地推送大量数据时如何选择合适的推送技术就变得至关重要。
为什么需要服务端主动推送 在很多应用中我们并不希望客户端频繁地去向服务器请求数据这不仅增加了客户端的负担也浪费了服务器和网络资源。因此服务端主动推送消息成为了一种更加高效的方式。 想象一下你的手机每天都需要向应用的服务器询问“有没有新消息有没有新任务”这种方式就叫做轮询。但轮询会有一些问题
频繁请求客户端需要定时向服务器发送请求检查是否有新内容。这不仅会浪费大量的网络带宽也给服务器带来很大的负担。延迟问题即使轮询的间隔很短客户端依然会有一些延迟不能做到完全实时。
相比之下服务端主动推送就解决了这个问题。它的工作原理是
当服务端有新消息时主动“推送”到客户端。客户端只需“监听”服务端的消息当消息到来时客户端立刻处理不再主动请求。 这就像是你打开了一个“收信箱”一旦有新信件信箱会自动通知你而不是你一直去查“有没有新信件”。这样不仅省去了频繁询问的麻烦还能让你第一时间获取到最新的消息。
服务端推送的好处
提高实时性因为服务端直接推送消息用户可以第一时间收到更新不会有等待或延迟。减少无效请求避免了客户端频繁向服务器发送请求节省了网络带宽也减轻了服务器负担。降低客户端资源消耗客户端不再需要频繁检查新消息减少了 CPU 和电池消耗特别是在移动端应用中尤为重要。
举个例子 想象一下你正在使用一个聊天应用。每当有人给你发新消息时你希望立刻看到。通过服务端主动推送的方式服务器会在有新消息时立刻把消息推送到你手机上而不是让你的手机每隔几秒钟去检查一次服务器是否有新消息。
这就是服务端主动推送的基本思路它能提高实时性、降低无效请求和资源消耗。
总结 服务端主动推送技术解决了频繁轮询带来的性能问题使得实时性更强、系统负担更轻。接下来的内容我们将介绍几种常见的推送技术帮助你更好地理解如何实现服务端主动推送。
二、常见的推送方案 在前一部分我们了解了为什么需要服务端主动推送消息现在我们来介绍几种常见的推送方案。每种方案都有自己的特点和适用场景了解这些方案可以帮助我们做出最合适的选择。
1. 短轮询 短轮询是一种最简单的方式它的原理就是客户端定期向服务器发送请求询问是否有新消息。如果服务器有新消息就会返回如果没有新消息则返回空。
工作原理
客户端每隔一定时间比如几秒钟就向服务器发送一个请求。服务器收到请求后检查是否有新消息。如果有就返回消息如果没有就返回空。
适用场景
适合一些对实时性要求不高的应用。比如扫码登录、简单的OA系统等用户不需要即时获取所有更新。
优缺点
优点实现简单容易部署。客户端只需要发请求服务器返回数据即可。缺点 无效请求即使没有新消息客户端也会不断向服务器发送请求这会浪费大量的网络资源。服务器压力大每次请求都要经过网络传输和处理服务器压力会很大尤其是用户量多时。
2. 长轮询
长轮询是在短轮询的基础上做了一些改进。和短轮询不同的是长轮询不会立刻返回空结果而是让客户端的请求“挂起”一段时间直到服务器有新消息时再返回。
工作原理
客户端发送请求后如果服务器没有新消息就不会马上返回而是会“挂起”客户端请求直到有新消息时再返回。如果请求在一定时间内没有新消息就会超时客户端会重新发起请求。
适用场景
适合对实时性要求较高但又不能使用更复杂的方案的应用。比如聊天应用、通知提醒系统等。
优缺点
优点 减少无效请求相比短轮询减少了无用请求的开销因为只有在新消息到来时服务器才会返回数据。较低的延迟相比短轮询长轮询的响应速度更快能够提供更好的用户体验。缺点 服务器压力仍然存在虽然每次请求不是都返回空但仍然存在大量的挂起请求服务器依然需要处理这些挂起的连接。复杂度较高服务器需要支持挂起请求、超时处理等额外的功能增加了系统的复杂度。
3. WebSocket WebSocket 是一种更为高效的方案它允许客户端和服务器建立一个长期保持的连接。通过这个连接服务器可以在任何时刻主动向客户端发送消息而不需要客户端频繁请求。
工作原理
客户端和服务器通过一个TCP连接建立双向通信的通道。这个连接是持久的客户端和服务器可以在这个通道中实时交换数据。一旦建立连接客户端不需要再发起请求服务器可以随时推送消息。
适用场景
适用于需要高实时性、高频率推送的应用。比如即时通讯IM应用、多人在线游戏、股票行情实时推送等。
优缺点
优点 高效实时性连接建立后服务器可以随时向客户端推送消息延迟非常低。减少服务器压力只有一个持久连接减少了频繁的连接和断开避免了大量的请求。资源消耗少相比轮询方案WebSocket只需要维护一个连接客户端和服务器都不需要频繁地交换信息节省了资源。缺点 实现复杂相比轮询方案WebSocket的实现要复杂得多。需要支持连接管理、心跳检测、连接断开重连等功能。连接数限制由于每个客户端都需要保持一个长连接因此服务器需要处理大量的并发连接负载会比较重。不适合所有场景并不是所有应用都需要实时双向通信如果只是偶尔推送通知WebSocket可能显得过于复杂。
4. 方案对比总结
方案优点缺点适用场景短轮询实现简单易于部署无效请求多服务器压力大扫码登录简单的OA系统等长轮询较低延迟减少无效请求服务器压力仍然较大系统复杂度高聊天应用通知提醒系统等WebSocket高效实时性减少资源消耗服务器压力小实现复杂连接数受限不适合所有场景即时通讯应用股票实时行情推送等
总结
如果你的应用对实时性要求不高而且用户量不大短轮询可以满足基本需求。如果你需要更低的延迟和较好的用户体验但对服务器压力的处理要求不是非常高长轮询是一个不错的选择。如果你的应用需要非常高效的实时性和较高的并发连接且能接受更复杂的实现WebSocket是最合适的方案。
三、WebSocket 协议实现方案 在上一部分我们了解了 WebSocket 是如何高效地实现服务器主动推送消息的。接下来我们将介绍两种常见的 WebSocket 协议实现方案Tomcat 和 Netty。
1. Tomcat 实现 WebSocket Tomcat 是一个非常常见的 Java Web 服务器它提供了对 WebSocket 协议的原生支持。Tomcat 通过在 Java Servlet API 的基础上扩展了 WebSocket 功能使得开发者能够直接利用 Tomcat 来实现 WebSocket 连接。
工作原理
Tomcat 会为每个 WebSocket 客户端创建一个专用的连接这些连接会一直保持直到客户端主动关闭连接或服务器关闭连接。客户端连接到服务器后Tomcat 会处理 WebSocket 协议的握手过程建立持久的双向通信通道。在这个连接建立后服务器可以主动向客户端发送数据客户端也可以发送数据到服务器。
优缺点
优点 集成简单Tomcat 本身就支持 WebSocket所以不需要额外的依赖配置相对简单。兼容性好Tomcat 是一个广泛使用的 Java Web 服务器许多企业应用和框架都支持 Tomcat因此可以很容易集成 WebSocket。缺点 性能瓶颈Tomcat 使用的是基于线程的方式每个连接会分配一个线程这对于大量并发连接的场景来说可能会产生性能瓶颈。每增加一个连接就增加了一个线程的开销。不适合高并发场景Tomcat 更适合处理相对较少的并发连接如果你的系统需要处理成千上万的并发连接可能会面临性能问题。
适用场景
小型到中型 Web 应用或者对 WebSocket 连接的数量要求不高的场景。
2. Netty 实现 WebSocket Netty 是一个基于 NIO非阻塞 I/O的网络通信框架专门用于开发高性能、高并发的网络应用。Netty 相比 Tomcat 更加灵活特别适用于需要处理大量并发连接的场景。它通过事件驱动和多路复用的机制能够高效地管理大规模的 WebSocket 连接。
工作原理
Netty 使用的是基于事件驱动的架构通过一个或少数几个线程来处理成千上万的并发连接。它通过 NIO非阻塞 I/O技术减少了线程数量从而显著提高了服务器的吞吐量和并发处理能力。当客户端发起 WebSocket 连接时Netty 会通过 Channel 管理客户端连接并通过 Pipeline 进行数据的编解码、消息处理等。一旦连接建立客户端和服务器之间的数据交换会通过 Netty 提供的 EventLoop 实现高效的事件驱动处理。
优缺点
优点 高性能高并发由于使用了 NIO 和事件驱动架构Netty 在处理大量并发连接时具有显著的性能优势。灵活性强Netty 提供了丰富的功能可以方便地自定义协议、消息格式和处理器非常适合复杂的网络应用。可扩展性强通过 PipelineNetty 支持灵活的组件扩展开发者可以根据需求添加前置和后置的处理逻辑比如心跳检测、数据加密等。缺点 学习曲线陡峭Netty 的使用和配置比 Tomcat 更为复杂尤其是对于不熟悉事件驱动和 NIO 的开发者来说可能需要一些时间来适应。开发和调试难度较大由于 Netty 提供了更多的自由度和配置选项开发和调试的难度也相对较高。
适用场景
高并发的即时通讯IM系统、大规模多人在线游戏、实时数据推送等对性能要求极高的场景。
3. 方案对比总结
方案优点缺点适用场景Tomcat集成简单兼容性好适合中小型应用性能瓶颈不适合高并发小型到中型 Web 应用对连接数要求不高的场景Netty高性能高并发灵活性强适用于复杂协议学习曲线陡峭配置和调试较复杂高并发系统实时通讯应用数据推送等高性能场景
总结
如果你的系统对并发连接数的要求较低且希望使用现有的 Java Web 容器Tomcat 会是一个简单易用的选择特别适合中小型应用。如果你的系统需要处理大量的并发连接且对性能有严格要求Netty 是一个更加合适的选择尽管它的学习和配置会相对复杂。 在实际选择时我们需要根据项目的规模和需求来决定使用 Tomcat 还是 Netty。对于大部分小型应用Tomcat 足够使用但对于高并发、低延迟的场景Netty 的优势不可忽视。
四、WebSocket 连接的具体过程 WebSocket 连接的建立和数据传输是服务端和客户端实现双向实时通信的关键。接下来我们将详细介绍 WebSocket 连接的具体过程从 握手 到 数据传输再到 连接关闭一步步讲解如何建立和维护 WebSocket 连接。
1. 客户端发起连接握手请求 WebSocket 连接的过程从客户端发起连接开始。客户端通过浏览器、应用或者其他支持 WebSocket 的客户端向服务端发起连接请求。
请求过程 客户端通过 HTTP 协议向服务端发送一个特定的 WebSocket 握手请求这个请求与普通的 HTTP 请求有些不同它包含了一些额外的头部信息来告诉服务端它想要升级协议到 WebSocket。 请求头示例 GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ
Sec-WebSocket-Version: 13关键字段说明 Upgrade: websocket表示客户端希望从 HTTP 协议切换到 WebSocket 协议。Connection: Upgrade表示此次请求是一个协议升级请求。Sec-WebSocket-Key客户端生成的一个随机值用于进行握手过程的安全验证。Sec-WebSocket-Version指定 WebSocket 协议版本版本 13 是最新标准。
2. 服务端接受连接握手响应 当服务端收到客户端的握手请求后会检查请求是否合法确认是否支持 WebSocket 协议。如果支持服务端会返回一个握手响应告诉客户端可以建立 WebSocket 连接。
响应过程 服务端会发送一个 HTTP 101 状态码表示协议切换来响应客户端的请求并返回一个带有一些特定字段的响应头。 响应头示例 HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: x3JJHMbDL1EzLkh9K1sdd2Yog关键字段说明 Upgrade: websocket确认协议切换为 WebSocket。Connection: Upgrade确认这是一个协议升级请求。Sec-WebSocket-Accept服务端计算并返回的一个值是 Sec-WebSocket-Key 字段经过特定算法加密后的结果用于确保连接的安全性。 如果客户端的请求和服务端的响应符合 WebSocket 协议标准连接就建立成功服务端和客户端之间就可以进行双向数据传输了。
3. 数据传输过程 WebSocket 连接一旦建立服务端和客户端之间就可以通过这个连接进行 全双工 数据传输。也就是说客户端和服务端都可以随时向对方发送消息而不需要等待对方的请求。
数据传输过程 WebSocket 连接通过 帧 来传输数据。每一帧可以是文本、二进制数据等内容。文本消息通常使用 UTF-8 编码二进制消息可以是 Blob 或 ArrayBuffer 等格式。 客户端向服务端发送消息 客户端可以通过 JavaScript 代码使用 WebSocket.send() 方法向服务器发送消息例如 let socket new WebSocket(ws://example.com/chat);
socket.onopen function(event) {socket.send(Hello, Server!);
};服务端向客户端发送消息 服务端也可以使用类似的 API例如在 Netty 或 Tomcat 中的 WebSocket API来向客户端发送消息 // 服务端向客户端发送消息
session.getBasicRemote().sendText(Hello, Client!);消息格式 WebSocket 消息的格式通常由以下几部分组成 数据帧头包含控制信息如是否是最后一帧消息、消息类型等。负载数据实际的数据内容通常是文本或二进制数据。
4. 维持连接心跳机制 WebSocket 连接在长时间的使用过程中可能会出现 连接中断 或 超时断开 的问题。为了避免这种情况通常会在客户端和服务端之间加入 心跳机制定期发送数据包来确保连接的存活。
心跳机制的实现
客户端心跳客户端可以定时向服务端发送一个小的心跳消息比如 ping 或者空白数据包来告知服务端它依然在线。服务端心跳服务端也可以定期向客户端发送心跳消息来确认连接的有效性。
例如在 Netty 中可以使用 PingFrame 和 PongFrame 来实现心跳检测。
5. 连接关闭
当 WebSocket 连接不再需要时客户端或服务端可以发起 连接关闭 的请求正常关闭连接。
关闭过程
客户端或服务端发送一个 Close 帧关闭帧通知对方连接关闭。接收方收到关闭帧后会发送一个确认帧也是 Close 帧确认关闭连接。连接被关闭后双方都可以释放资源WebSocket 连接不再可用。
关闭的代码示例 客户端关闭连接 socket.close();服务端关闭连接 session.close();6. 连接异常处理 在实际应用中WebSocket 连接可能会遇到网络不稳定、服务器故障等情况这时就需要处理异常。通常WebSocket 客户端和服务端都可以定义 事件监听器 来捕获连接错误和断开事件。
客户端示例
socket.onerror function(event) {console.error(WebSocket error observed:, event);
};服务端示例
OnError
public void onError(Throwable throwable) {System.err.println(WebSocket error: throwable.getMessage());
}总结
WebSocket 连接的建立过程分为 客户端握手请求 和 服务端握手响应 两部分一旦建立成功就可以进行双向的数据传输。数据通过 帧 进行传输支持文本和二进制数据。为了保持连接的稳定性通常会使用 心跳机制 来维持连接的活跃状态。连接关闭时客户端和服务端都会发送关闭帧来正常关闭连接。
通过上述过程WebSocket 连接能够实现服务端主动向客户端推送消息从而支持高效的实时通信。
五、总结WebSocket 方案的优势与应用 WebSocket 作为一种实现实时通信的技术具有显著的优势尤其适用于需要频繁交换数据的应用场景。接下来我们将总结 WebSocket 方案的优势以及它在实际中的应用。
1. WebSocket 的优势
1实时双向通信 WebSocket 的最大优势就是 全双工通信也就是说客户端和服务端可以随时向对方发送消息而不需要等待对方的请求。这与传统的 HTTP 请求/响应模式不同HTTP 是单向的客户端必须发起请求服务器才能响应。WebSocket 的实时性使得它非常适合聊天应用、实时通知、在线游戏等需要实时数据交互的场景。
2减少网络开销 与传统的 短轮询 和 长轮询 方法相比WebSocket 节省了大量的网络带宽和服务器资源。短轮询和长轮询需要客户端频繁地发起请求即使没有新数据服务端也需要响应空数据而 WebSocket 只需要一次连接双方可以持续交换数据避免了重复的 HTTP 请求和响应开销。
3低延迟 WebSocket 的连接一旦建立客户端和服务端可以随时交换数据。因为 WebSocket 使用的是持久连接也就是 TCP 长连接数据可以迅速传输不需要重新建立连接。这使得 WebSocket 在低延迟、高频率的数据传输方面具有显著优势适合需要快速响应的应用。
4支持大规模并发 WebSocket 在处理大规模并发连接方面比传统的 HTTP 更加高效。传统的 HTTP 每个连接都需要占用一个线程来处理而 WebSocket 通过使用事件驱动的方式能够用较少的线程处理更多的连接。例如基于 Netty 的 WebSocket 服务端能够支持上万甚至更多的并发连接。
5简单的协议 WebSocket 协议相对简单不需要复杂的请求和响应格式数据传输可以使用文本、二进制数据等格式。开发者可以通过简单的 API如 JavaScript 中的 WebSocket 对象实现 WebSocket 客户端和服务端的通信非常易于使用和理解。
2. WebSocket 的应用场景 WebSocket 因其独特的优势广泛应用于许多需要实时数据交换的场景。以下是几个典型的应用场景
1即时通讯 即时通讯应用如聊天应用、社交平台需要客户端和服务端之间保持实时双向通信以便能够及时发送和接收消息。WebSocket 非常适合这类场景因为它支持全双工通信可以即时将消息从服务端推送到客户端。
例如
聊天应用客户端和服务端之间实时推送消息。社交平台用户在线状态更新、消息提醒、好友请求通知等。
2在线游戏 在线多人游戏要求客户端和服务端之间实时同步游戏状态例如玩家位置、分数、战斗情况等。WebSocket 的低延迟和高效性非常适合用于游戏数据的实时传输。
例如
即时战斗游戏玩家之间的实时互动。虚拟世界玩家与虚拟世界中的物体进行交互所有动作即时反馈。
3实时数据推送 一些需要实时更新数据的应用比如股票交易、体育赛事直播、天气预报等WebSocket 也能提供有效的解决方案。服务端可以在数据更新时主动推送数据到客户端而无需客户端频繁请求。
例如
股票行情实时显示股票价格的变化。体育赛事实时更新比赛的分数和进程。
4在线协作 WebSocket 适用于实时多人协作的应用场景尤其是文档编辑、设计协作等领域。多个用户可以在同一文档上进行实时编辑所有操作即时同步到其他用户。
例如
在线文档编辑用户可以同时编辑文档实时看到其他人的修改。设计协作平台设计人员实时协作、同步编辑设计稿。
5实时监控 WebSocket 还可用于实时监控系统帮助管理员即时了解系统状态如服务器负载、应用性能、日志监控等。
例如
服务器监控实时更新服务器健康状况。应用性能监控实时展示应用运行数据和性能指标。
3. 总结 WebSocket 是一种强大而高效的技术它能够解决传统 HTTP 协议无法实现的实时双向通信问题。相比于轮询机制WebSocket 更节省带宽和服务器资源能够支持低延迟和高并发的需求特别适用于即时通讯、在线游戏、实时数据推送等需要频繁交换数据的场景。
通过 WebSocket服务端可以主动向客户端推送消息极大地提高了用户体验使得实时性强的应用得以顺畅运行。如果你正在开发一个需要即时响应的应用WebSocket 无疑是一个值得考虑的技术方案。
六、推荐方案为什么选择 Netty 实现 WebSocket 在决定实现 WebSocket 的方案时我们会遇到多个选择。虽然 Tomcat 也可以支持 WebSocket但我们推荐使用 Netty 作为 WebSocket 的实现框架。接下来我们将详细讲解为什么选择 Netty并通过简单的对比帮助大家理解。
1. Netty 的优势
1基于 NIO支持高并发 Netty 是基于 NIONew I/O 的框架而 NIO 的最大特点就是通过 事件驱动 和 多路复用 机制可以在 少量线程 的情况下处理大量的并发连接。这样它非常适合用来搭建 高并发的 WebSocket 服务。 相比之下Tomcat 是基于 传统的多线程模型每个连接都会占用一个独立的线程线程数量越多服务器的性能就会越低。当并发连接数增多时Tomcat 的性能可能会大幅下降导致响应变慢甚至崩溃。
总结Netty 更擅长处理 大量并发连接而 Tomcat 更适合处理 较少并发连接。
2单线程处理节省资源 在 Netty 中所有的连接和数据处理通常由一个或少数几个线程来完成。这种方式通过 事件驱动 和 多路复用 使得 Netty 在处理上万甚至更多的连接时能够 节省大量的系统资源。而 Tomcat 则会为每个连接分配一个线程这样就需要消耗更多的系统资源限制了它的扩展性。
总结Netty 的 单线程或少线程 模型非常适合高并发场景节省资源而 Tomcat 的线程模型则比较消耗资源。
3丰富的功能与高度的灵活性 Netty 提供了丰富的功能和强大的 扩展性可以方便地构建自定义的网络协议和处理器。例如Netty 提供了 Pipeline 机制允许你定义请求的处理流程可以非常灵活地处理网络请求、编解码、消息转发等任务。
Tomcat 在这些方面相对较弱它的功能主要集中在 HTTP 协议和 Web 容器的功能上定制化程度不如 Netty。
总结Netty 提供了更高的灵活性可以根据具体需求定制处理过程而 Tomcat 的定制化相对较少。
4内建的心跳机制与连接管理 WebSocket 需要维护长连接因此需要处理 连接的心跳机制以确保连接正常运行并防止超时断开。Netty 提供了 内建的心跳机制 和 连接状态检查可以自动检测和管理连接减少开发者的工作量。
Tomcat 也能支持 WebSocket但其心跳机制和连接管理需要额外配置和开发比较繁琐。
总结Netty 的 心跳机制和连接管理 非常完善能够减少开发工作量而 Tomcat 需要手动配置和扩展。
5高效的编码和解码处理 WebSocket 数据传输过程中通常需要对数据进行编码和解码操作。Netty 提供了强大的 编解码器可以高效处理各种数据格式包括文本、二进制数据等。同时Netty 提供了自定义编解码的接口可以根据需要灵活处理数据。
而 Tomcat 的 WebSocket 处理器虽然也支持基本的编解码操作但相比 Netty 更加简化灵活性和效率相对较低。
总结Netty 提供了高效、灵活的 编解码功能可以满足复杂的数据处理需求而 Tomcat 在这方面稍显不足。
2. 适用场景
1高并发应用 对于需要同时处理大量并发 WebSocket 连接的应用Netty 无疑是更好的选择。比如 IM 聊天应用、实时数据推送服务等Netty 可以更高效地处理成千上万的并发连接保证系统的稳定性和性能。
2需要高灵活性和扩展性的应用 如果你需要在 WebSocket 连接中实现复杂的协议或者需要自定义消息的处理流程Netty 会提供更高的灵活性。例如你可以使用 Netty 轻松实现自己需要的编解码规则、业务逻辑等而 Tomcat 的自定义能力较弱。
3低延迟和高性能要求的应用 如果你的应用需要低延迟、高吞吐量比如实时在线游戏、金融交易系统等Netty 的事件驱动和高效的资源管理能够帮助你在高负载下保持较低的延迟和稳定性。
3. 总结为什么选择 Netty 实现 WebSocket 通过以上分析我们可以得出结论Netty 更适合大规模并发、高性能和高灵活性要求的应用场景。它通过 NIO 机制、高效的线程管理和强大的扩展性能够支持更加复杂和高并发的 WebSocket 实现。而 Tomcat 虽然也可以处理 WebSocket但它在处理大规模连接和自定义协议方面的能力远远不及 Netty。 如果你的系统需要处理大量实时连接或者需要更灵活的协议和消息处理选择 Netty 实现 WebSocket 将是一个更优的方案。
