Чтобы полностью понять Нетти, этой статьи достаточно

С Netty вы можете реализовать свой собственный HTTP-сервер, FTP-сервер, UDP-сервер, RPC-сервер, сервер WebSocket, прокси-сервер для Redis, прокси-сервер для MySQL и т. д.  

Давайте рассмотрим принципы традиционных HTTP-серверов.

1. Создайте ServerSocket, прослушайте и привяжите порт

2. Серия клиентов для запроса этого порта

3. Сервер использует Accept для получения объекта подключения Socket от клиента.

4. Запустите новый поток для обработки соединения

4.1 Чтение сокета для получения потока байтов

4.2 Декодировать протокол и получить объект запроса Http

4.3. Обработайте запрос Http, получите результат и инкапсулируйте его в объект HttpResponse.

4.4 Протокол кодирования, сериализация результата в поток байтов Написать сокет, отправить поток байтов клиенту

5. Продолжайте повторять шаг 3.

Причина, по которой HTTP-сервер называется HTTP-сервером, заключается в том, что протокол кодирования и декодирования является протоколом HTTP.Если протокол является протоколом Redis, он становится сервером Redis, если протоколом является WebSocket, он становится сервером WebSocket и скоро. Используя Netty, вы можете настроить протокол кодека и реализовать свой собственный сервер для конкретного протокола.

NIO

Выше показан традиционный сервер, который обрабатывает http, но в среде с высокой степенью параллелизма количество потоков будет больше, а загрузка системы будет выше, поэтому есть NIO.

while true {
    events = takeEvents(fds)  // 获取事件，如果没有事件，线程就休眠
    for event in events {
        if event.isAcceptable {
            doAccept() // 新链接来了
        } elif event.isReadable {
            request = doRead() // 读消息
            if request.isComplete() {
                doProcess()
            }
        } elif event.isWriteable {
            doWrite()  // 写消息
        }
    }
}

Модель резьбы Reactor

Однопоточная модель Reactor

Один поток NIO + один поток принятия:

Многопоточная модель Reactor

Модель ведущий-ведомый реактора

Netty можно гибко настроить на основе трех вышеуказанных моделей.

Суммировать

Почему выбирают Нетти

Если вы не используете netty и используете собственный JDK, возникают следующие проблемы:

Для Нетти его API простой, высокопроизводительный и активный в сообществе (его используют dubbo, RocketMQ и т. д.)

Что такое склеивание/распаковка TCP

Феномен

Сначала посмотрите на следующий код.В этом коде используется netty для повторной записи данных со стороны клиента на сторону сервера 100 раз.ByteBuf — это байтовый контейнер netty, в котором хранятся данные, которые необходимо отправить.

public class FirstClientHandler extends ChannelInboundHandlerAdapter {    
    @Override    
    public void channelActive(ChannelHandlerContext ctx) {       
        for (int i = 0; i < 1000; i++) {            
            ByteBuf buffer = getByteBuf(ctx);            
            ctx.channel().writeAndFlush(buffer);        
        }    
    }    
    private ByteBuf getByteBuf(ChannelHandlerContext ctx) {        
        byte[] bytes = "你好，我的名字是1234567!".getBytes(Charset.forName("utf-8"));        
        ByteBuf buffer = ctx.alloc().buffer();        
        buffer.writeBytes(bytes);        
        return buffer;    
    }
}

Данные, считанные со стороны клиента:

Как видно из консольного вывода сервера, есть три вида вывода

1. Один из них — обычный строковый вывод.
2. Во-первых, несколько строк «липнут» вместе, и мы определяем этот ByteBuf как липкий пакет.
3. Во-первых, строка «распаковывается» для формирования сломанного пакета, и мы определяем этот ByteBuf как полупакет.

Анализировать причину через явление

Прикладной уровень использует Netty, но для операционной системы он распознает только протокол TCP.Хотя наш прикладной уровень отправляет данные в единицах ByteBuf, а сервер считывает их в соответствии с Bytebuf, они все равно отправляются в соответствии с байтовым потоком когда они поступают в нижележащую операционную систему.Поэтому, когда данные поступают на сервер, они также считываются в виде потока байтов, а затем на уровне приложения Netty они пересобираются в ByteBuf, и ByteBuf здесь может быть не равным ByteBuf, отправляемому клиентом последовательно. Следовательно, нам нужно собрать пакеты данных нашего прикладного уровня на стороне клиента в соответствии с пользовательским протоколом, а затем собрать пакеты данных в соответствии с нашим протоколом прикладного уровня на стороне сервера.Этот процесс обычно называется распаковкой на стороне сервера. , так и на стороне клиента. Концы называются липкими пакетами.

Как решить

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

В Netty встроено множество типов распаковщиков, мы просто используем их напрямую:

После выбора распаковщика просто добавьте распаковщик в chanelPipeline в клиентской части и серверной части кода:

В приведенном выше примере:

Клиент:

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));

Сервер:

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));