Платформа websocket push, реализованная netty
Веб-сокет Нетти реализация
Цель
Для бизнес-требований вам необходимо подписаться на внешний браузер, чтобы подтолкнуть бизнес и принять внутренний толчок.Перед использованием amq.js (activemq реализован на основе опроса) есть большие проблемы с производительностью и производительностью в реальном времени. не может быть гарантировано, поэтому используется netty.
Веб-сокет Основываясь на реализации H5, IE младшей версии не поддерживает (ie8)
Иногда веб-страница и мобильный терминал должны иметь один и тот же протокол push-уведомлений, а мобильному клиенту также может потребоваться реализовать push-уведомление через веб-сокет.
Адрес перевода и описания официального сайта протокола WebSocket (RFC6455)
Каталог проекта и координация среды
Поскольку это тестовый проект, могут быть и другие коды фреймворка, но это не повлияет на среду фреймворка, а также доказывает, что этот фреймворк 0 навязчив, и его можно использовать, скопировав его.
Описание исходного кода
1. server 包
netty 的serverBootstrap 的启动与端口监听类
2. handler 包
netty 的channelHandler的实现,主要实现了(通过工厂模式) 用来处理websocket 的请求(http升级,握手,以及对于请求处理)
具体处理逻辑在:WebSocketChannelHandler.java 的 channelRead() 方法中
调用 upgradeResolver 处理http 升级请求,可以处理 uri ,过滤拦截,异常处理
调用 requestHandlerMapping 获取对应uri 的 HandlerAdapter 请求处理类
webSocketCacheManager 整个netty 框架中存储和保活的存储层,里面封装了一层dao层,做好存储框架替换的准备
3. adapter 包
websocket请求握手成功后,服务端和客户端的通信是基于frame 的(data frame 和 control frame)
adapter 包中定义了 HandlerAdapter 接口,三个方法
/* 用来处理客户端发送的数据 */
handleRequest();
/** 服务端处理(或者是推送处理)或者是聊天业务中获取目标对象的id 查找到对应的 HandlerAdapter 和 channel 进行推送聊天消息 **/
handleResponse();
/** 连接完成时调用* */
onUpgradeCompleted();
该接口我实现了2个抽象父类
一. 用来处理control frame 的AbstractFrameHandlerAdapter 因为毕竟大部分的control frame 的处理都是一样的,可以继承它,或者对于特定的frame可以自己重写方法实现
二. KeepAliveHandlerAdapter 用来处理保活,心跳机制的处理类,同上,也是因为几乎所有用websocket的业务都需要这样的处理,所以也可以封装成父类进行实现,具体保活机制在类的注释上
4. chat 和 common 包
这两个包下的实现类,并不属于框架源码,是作者用来测试不同业务的实现
chat 包下是实现聊天业务的实现
common 包下两个类实现了不同的推送订阅的处理
скопировать код
Исходный каталог
Проект основан на jdk1.8 из netty + spring + maven.
нетти адрес мавена:
<!-- https://mvnrepository.com/artifact/io.netty/netty-all -->
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.1.11.Final</version>
</dependency>
скопировать код
В проекте есть контейнер Spring, и вам нужно только ввести конфигурацию websocket в контексте Spring в приложении (или веб-приложении), чтобы запустить:
<import resource="./spring-netty-websocket.xml"/>
скопировать код
Местоположение источника:
所有源码都在这个包下
com.java.core.netty.websocket
注意:
源码包中的
chat 与 common 包,是具体业务的实现!!(example)
还有个测试的service类,用来测试推送业务,即开启定时器,向订阅的客户端发送对应的推送内容 WebSocketTestService.java
com.java.service.WebSocketTestService.java
скопировать код
весна-нетти-websocket.xml Файл представляет собой реализацию netty-websocket, в которой операции бизнес-классов сетевых запросов websocket управляются контейнером spring.
бизнес-пример
Компании, которым необходимо использовать веб-сокеты, обнаруженные на текущей странице браузера (или android/ios) 1. Чат 2. Отправка информации
Эти функции также примерно реализованы в проекте
поболтать с
com.java.core.netty.websocket.chat 包下
ChatHandlerAdapter.java 类用来实现聊天业务:
前端发送对方的id (可以是channelId ,或者与channelId关联的任何key ,最后都要通过channelId 找到具体的对方也就是接收方的channel ,发送聊天消息)
ChatOnlineListHandlerAdapter.java 类用来实现,聊天人员的列表推送,使得前端有实时的在线人员进行选择,发送数据
当然这两个业务放在同一个处理类下进行处理是没有问题的
скопировать код
толкать
例子:
com.java.service.WebSocketTestService.java 中
的
frameHandlerAdapter.handleResponse(frameParams);
和
locationHandlerAdapter.handleResponse(locParams);
用来推送服务端消息
скопировать код
Оригинальный проект
Безопасность
нетти Реализовать разрешения веб-сокета в
Поскольку многие приложения развернуты в tomcat, используйте фильтр tomcat для проверки разрешений.
И служба netty прослушивает другой порт (например, 38888), будут проблемы с доступом к безопасности.
- Сначала сервер устанавливает заголовок исходного запроса
план 1:
Прежде чем запрашивать веб-сокет, вы можете сначала запросить через ajax.Разрешение на вход в фоновом режиме успешно генерирует ключ и возвращается к внешнему интерфейсу.Внешний интерфейс инициирует запрос веб-сокета с этим токеном, а затем фон может подтвердить личность.
Сценарий 2:
Обратный прокси настраивает пользовательский фильтр в web.xml.После проверки авторизации определяет, был ли сделан запрос вебсокета, а затем обратное проксирование запроса.Это решение слишком сложное.Есть технология обратного прокси реализована через java,вы можешь попробовать