# netty-demo

**Repository Path**: 547415987/netty-demo

## Basic Information

- **Project Name**: netty-demo
- **Description**: No description available
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2018-11-02
- **Last Updated**: 2020-12-31

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## 不同I/O模型对比

|                     | 同步阻塞I/O(BIO) | 伪异步I/O           | 非阻塞I/O(NIO)                    | 异步I/O(AIO)                           |
| ------------------- | ---------------- | ------------------- | --------------------------------- | -------------------------------------- |
| 客户端个数：I/O线程 | 1:1              | M:N(其中M可以大于N) | M:1(1个I/O线程处理多个客户端连接) | M:0(不需要启动额外的I/O线程，被动回调) |
| I/O类型(阻塞)       | 阻塞I/O          | 阻塞I/O             | 非阻塞I/O                         | 非阻塞I/O                              |
| I/O类型(同步)       | 同步I/O          | 同步I/O             | 同步I/O(I/O多路复用)              | 异步I/O                                |
| API使用难度         | 简单             | 简单                | 非常复杂                          | 复杂                                   |
| 调试难度            | 简单             | 简单                | 复杂                              | 复杂                                   |
| 可靠性              | 非常差           | 差                  | 高                                | 高                                     |
| 吞吐量              | 低               | 中                  | 高                                | 高                                     |



## Netty介绍

Netty是业界最流行的NIO框架之一，它的健壮性、功能、性能、可定制和可扩展性在同类框架中都是首屈一指的，它已经得到成百上千的商业项目验证

>Hadoop的RPC框架avro使用Netty作为底层通信框架
>
>很多其他业界主流的RPC框架



## 优势

API使用简单，开发门槛低



功能强大，预置了多种编解码功能，支持多种主流协议



定制能力强，可以通过ChannelHandler对通信框架进行灵活地扩展



性能高，通过与其他业界主流的NIO框架对比，Netty的综合性能最优



成熟、稳定迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会加入

## 

经历了大规模的商业应用考验，质量得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证明了它已经完全能够满足不同行业的商业应用了



## TCP粘包/拆包

TCP是个"流"协议

流就是没有界限的一串数据

### 发生的原因

应用程序write写入的字节大小大于套接口发送缓冲区大小

进行MSS大小的TCP分段

以太网帧的payload大于MTU进行IP分片

### 解决策略

消息定长，例如每个报文的大小为固定长度200字节，如果不够，空位补空格



在包尾增加回车换行符进行分割，例如FTP协议



将消息分为消息头和消息体，消息头中包含表示消息总长度(或者消息体长度)的字段，通常设计思路为消息头的第一个字段使用int32来表示消息的总长度



更复杂的应用层协议

### LineBasedFrameDecoder和StringDecoder的原理分析

LineBasedFrameDecoder的工作原理是它依次遍历ByteBuf中的可读字节，判断看是否有"\n"或者"\r\n"

>如果有，就以此位置为结束位置，从可读索引到结束位置区间的字节就组成一行

StringDecoder 将接收到的对象转换成字符串，然后继续调用后面的handler

## 评判一个编解码框架的优劣时，需要考虑的因素

是否支持跨语言，支持的语言种类是否丰富

编码后码流大小

编解码的性能

类库是否小巧，API使用是否方便

使用者需要手工开发的工作量和难度



## Google Protobuf编解码

Protobuf是一个灵活、高效、结构化的数据序列化框架，相比于XML等传统的序列化工具，它更小，更快，更简单

Protobuf的优点

>在谷歌内部长期使用，产品成熟度高
>
>跨语言，支持多种语言，包括C++、Java和Python
>
>编码后的消息更小，更有利于存储和传输
>
>编解码的性能非常高
>
>支持不同协议版本的前后兼容
>
>支持定义可选和必选字段