Реализация WebSocket Netty

задняя часть Spring Netty WebSocket

Платформа 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. Сначала сервер устанавливает заголовок исходного запроса

план 1:

Прежде чем запрашивать веб-сокет, вы можете сначала запросить через ajax.Разрешение на вход в фоновом режиме успешно генерирует ключ и возвращается к внешнему интерфейсу.Внешний интерфейс инициирует запрос веб-сокета с этим токеном, а затем фон может подтвердить личность.

Сценарий 2:

Обратный прокси настраивает пользовательский фильтр в web.xml.После проверки авторизации определяет, был ли сделан запрос вебсокета, а затем обратное проксирование запроса.Это решение слишком сложное.Есть технология обратного прокси реализована через java,вы можешь попробовать