最近因为工作需要，学习了一段时间Netty的源码，并做了一个简单的分享，研究还不是特别深入，继续努力。因为分享也不涉及公司业务，所以这里也把这次对源码的研究成果分享出来 以下都是在游戏服务器开发中针对Netty使用需要了解知识点以及相关优化,这次分享主要设计以下内容,客户端连接数的限制,端口号资源,文件描述符资源,
,客户端连接数与服务器线程数比例是n:1,
, 所有IO在同一个NIO线程完成（处理连接，分派请求，编码，解码，逻辑运算，发送）,
优点：,
缺点：,
reactor单线程模型图：,
,
netty reactor单线程模型图：,
,Netty对应实现方式,根据单线程模型，io处理中最耗时的编码，解码，逻辑运算等cpu消耗较多的部分，可提取出来使用多线程实现，并充分利用多核cpu的优势,
优点：,多线程处理逻辑运算，提高多核CPU利用率,
缺点：,对于单Reactor来说，大量链接的IO事件处理依然是性能瓶颈,
reactor多线程模型图：,
,
netty reactor多线程模型图：,
,Netty对应实现方式,根据多线程模型，可把它的性能瓶颈做进一步优化，即把reactor由单个改为reactor线程池，把原来的reactor分为mainReactor和subReactor,
优点：,
reactor主从多线程模型图：,
,
netty reactor主从多线程模型图：,
,Netty对应实现方式,由以上源码可得知，bind只在起服调用一次，因此bossGroup仅调用一次regist，也就是仅调用一次next，因此只有一根线程是有用的，其余线程都是废弃的，所以bossGroup线程数设置为1即可,poll(时间复杂度O(n))：同select，不过把fd数组换成了fd链表，去掉了fd最大连接数（1024个）的数量限制,epoll(时间复杂度O(1))：解决了select/poll的几个缺陷,epoll是操作系统基于事件关联fd，做了以下优化：,epoll仅在Linux系统上支持,netty依然基于epoll做了一层封装，主要做了以下事情：,（1）java的nio默认使用水平触发，Netty的Epoll默认使用边缘触发，且可配置,（2）Netty的Epoll提供更多的nio的可配参数。,（3）调用c代码，更少gc，更少synchronized 具体可以参考源码NioEventLoop.run和EpollEventLoop.run进行对比,
线程组类图,
,
channel类图,
,TCP链路探活,重用处于TIME_WAIT但是未完全关闭的socket地址，让端口释放后可立即被重用。默认关闭，需要手动开启,IP报文格式,
,TCP报文格式,
,开启则禁用TCP Negal算法，优点低延时，缺点在大量小数据包的情况下，网络利用率低,关闭则开启TCP Negal算法，优点提高网络利用率（数据缓存到一定量才发送），缺点延时高,Negal算法,MSS计算规则 MSS的值是在TCP三次握手建立连接的过程中，经通信双方协商确定的 802.3标准里，规定了一个以太帧的数据部分(Payload)的最大长度是1500个字节(MTU),结论：因为游戏服务器的实时性要求，在网络带宽足够的情况下，建议开启TCP_NODELAY，关闭Negal算法，带宽可以浪费，响应必须及时,注意：需要客户端服务器均关闭Negal算法，否则仍然会有延迟发送，影响传输速度,操作系统内核中维护的两个队列,netty对于backlog的默认值设置在NetUtil类253行,结论：,Linux下/proc/sys/net/core/somaxconn一定存在，所以backlog一定取得它的值，我参考prod机器的参数配置的65535，也就是不设置backlog的情况下，服务器运行缓存65535个全连接,
,默认分配ByteBuffAllocator赋值如下： ByteBufUtil.java,RCVBUF_ALLOCATOR默认AdaptiveRecvByteBufAllocator,以上就是游戏服务器中的Netty应用以及源码剖析的详细内容，更多关于Netty游戏服务器的资料请关注其它相关文章！
