- 服务器端
在分析客户端的代码时，我们已经对Bootstrap启动Netty有了一个大致的认识，那么接下来分析服务器端时，就会相对简单一些了。首先还是来看一下服务器端的启动代码
public final class EchoServer {
static final boolean SSL = System.getProperty("ssl") != null;
static final int PORT = Integer.parseInt(System.getProperty("port", "8007"));
public static void main(String[] args) throws Exception {
// Configure SSL.
final SslContext sslCtx;
if (SSL) {
SelfSignedCertificate ssc = new SelfSignedCertificate();
sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();
} else {
sslCtx = null;
}
// Configure the server.
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 100)
.handler(new LoggingHandler(LogLevel.INFO))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
if (sslCtx != null) {
p.addLast(sslCtx.newHandler(ch.alloc()));
}
//p.addLast(new LoggingHandler(LogLevel.INFO));
p.addLast(new EchoServerHandler());
}
});
// Start the server.
ChannelFuture f = b.bind(PORT).sync();
// Wait until the server socket is closed.
f.channel().closeFuture().sync();
} finally {
// Shut down all event loops to terminate all threads.
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
}
}
和客户端的代码相比，没有很大的差别，基本上也是进行了如下几个部分的初始化：
- EventLoopGroup:不论是服务器端还是客户端，都必须指定EventLoopGroup，在这个例子中，指定了NioEventLoopGroup，表示一个Nio的EventLoopGroup，不够服务器端需要指定两个EventLoopGroup，一个是bossGroup，用于处理客户端的连接请求；另一个是workGroup，用于处理与各个客户端连接的IO操作
- ChannelType：指定Channel的类型，因为是服务器端，因此使用NioServerSocketChannel
- Handler：设置数据的处理器
- Channel的初始化过程
我们在分析客户端的Channel初始化过程中，已经提到，Channel是对Java底层Socket连接的抽象，并且知道了客户端的Channel的具体类型是NioSocketChannel，那么自然地，服务端的Channel类型就是NioServerSocketChannel了 - Channel类型的确定
同样的分析套路，我们已经知道了，在客户端中，Channel的类型其实是在初始化时，通过Bootstap.channel()方法设置的，服务端自然也不例外
在服务器端，我们调用了ServerBootstrap.channel(NioServerSocketChannel.class)，传递了一个NioServerSocketChannel Class对象，这样的话，按照和分析客户端代码一样的流程，我们就可以确定，NioServerSocketChannel的实例化是通过BoostrapChannelFactoru工厂类来完成，而BootstrapChannelFactory中的class字段被设置为NioServerSocketChannel.class,因此当调用BootstrapChannelFactory.newChannel()时：
@Override
public T newChannel() {
// 删除 try 块
return clazz.newInstance();
}
就获取到了一个NioServerSocketChannel的实例
总结：
- ServerBootstrap中的ChannelFactory的实现是BootrapChannelFactory
- 生成的Channel的具体类型是NioServerSocketChannel
Channel的实例化过程，其实就是调用ChannelFactory.newChannel(),而实例化的Channel的具体类型又是和在初始化ServerBootstrap时传入的channel()方法的参数相关。因此对于我们这个例子中的服务器端的ServerBootstrap而言，生成的Channel实例就是NioServerSocketChannel
-
NioServerSocketChannel的实例化过程
5.png
首先，我们来看一下它的默认的构造器。和NioSocketChannel类似，构造器都是调用了newSocket来打开一个java的Nio Socket，不过需要注意的是，客户端的newSocket调用的是openSocketChannel，而服务器端的newSocket调用的是openServerSocketChannel。顾名思义，一个是客户端的java SocketChannel，一个是服务器端的java ServerSocketChannel
private static ServerSocketChannel newSocket(SelectorProvider provider) {
return provider.openServerSocketChannel();
}
public NioServerSocketChannel() {
this(newSocket(DEFAULT_SELECTOR_PROVIDER));
}
接下来会调用重载的构造器
public NioServerSocketChannel(ServerSocketChannel channel) {
super(null, channel, SelectionKey.OP_ACCEPT);
config = new NioServerSocketChannelConfig(this, javaChannel().socket());
}
这个构造器中，调用弗雷构造器，传入的参数是SelectionKey.OP_ACCEPT.作为对比，我们回想一下，在客户端的Channel初始化时，传入的参数是Selection.OP_READ.原因是Java NIO是一种Reactor模式，我们通过selector来实现I/O的多路复用，在一开始时，服务器端需要监听客户端的连接请求，因此在这里我们设置了SelectionKey.OP_ACCEPT,即通知selector我们对客户端的连接请求感兴趣
接着和客户端的分析一样，会逐级的调动父类的构造器NioServerSocketChannel->AbstractNioMessageChannel->AbstractNioChannel->AbstractChannel
同样的，在AbstractChannel中会实例化一个unsafe和pipeline：
protected AbstractChannel(Channel parent) {
this.parent = parent;
unsafe = newUnsafe();
pipeline = new DefaultChannelPipeline(this);
}
不过，这里有一点需要注意的是，客户端的unsafe是一个AbstractNioByteChannel#NioByteUnsafe的实例，而在服务器端，因为AbstractNioMessageChannel重写了newUnsafe方法
@Override
protected AbstractNioUnsafe newUnsafe() {
return new NioMessageUnsafe();
}
因此在服务器端，unsafe字段其实是一个AbstractNioMessageChannel#AbstractNioUnsafe实例
总结在NioServerSocketChannel实例化过程中，所需要做的工作
- 调用NioServerSocketChannel.newSocket(DEFAULT_SELECTOR_PROVIDER)打开一个新的Java NIO ServerSocketChannel
- AbstractChannel(Channel parent)中初始化AbstractChannel的属性
- parent属性置为null
- unsafe通过newUnsafe()实例化一个unsafe对象，它的类型是AbstractNioMessageChannel#AbstractNioUnsafe内部类
- pipeline是new DefaultChannelPipeline(this)新创建的实例
- AbstractNioChannel 中的属性
- SelectableChannel ch 被设置为 Java ServerSocketChannel, 即 NioServerSocketChannel#newSocket 返回的 Java NIO ServerSocketChannel.
- readInterestOp 被设置为 SelectionKey.OP_ACCEPT
- SelectableChannel ch 被配置为非阻塞的 ch.configureBlocking(false)
- NioServerSocketChannel中的属性：
- ServerSocketChannelConfig config = new NioServerSocketChannelConfig(this,javaChannel().socket)
- 关于bossGroup与workerGroup
在客户端的时候，我们只提供了一个EventLoopGroup对象，而在服务器端的初始化时，我们设置了两个EventLoopGroup，一个是bossGroup，另一个是workerGroup，那么这两个EventLoopGroup都是干什么用的呢？其实呢，bossGroup是用于服务端的accept的，即用于处理客户端的连接请求。首先，客户端bossGroup不断地监听是否有客户端的连接，当发现有一个新的客户端连接到来时，bossGroup就会为此连接初始化各项资源，然后从workerGroup中选出一个EventLoop绑定到此客户点连接中，那么接下来的服务器与客户端的交互过程就全部在此分配的EventLoop中了
源码如下
首先在ServerBoostrap初始化时，调用了b.group(bossGroup,workerGroup)设置了两个EventLoopGroup
public ServerBootstrap group(EventLoopGroup parentGroup, EventLoopGroup childGroup) {
super.group(parentGroup);
...
this.childGroup = childGroup;
return this;
}
显然，这个方法初始化了两个字段，一个是group=parentGroup，它是在super.group(parentGroup)中初始化的，两一个是childGroup = childGroup。接下来我们启动程序调用了b.bind方法来监听一个本地端口。
AbstractBootstrap.bind -> AbstractBootstrap.doBind -> AbstractBootstrap.initAndRegister
AbstractBootstrap.initAndRegister在分析客户端程序时，也有
final ChannelFuture initAndRegister() {
final Channel channel = channelFactory().newChannel();
... 省略异常判断
init(channel);
ChannelFuture regFuture = group().register(channel);
return regFuture;
}
这里group()方法返回的是上面我们提到的bossGroup，而这里的channel我们也已经分析过了，他是一个NioServerSocketChannel实例，因此我们可以知道，group().register(channel)将bossGroup和NioServerSocketChannel关联起来了。那么workerGroup实在哪里与NioSocketChannel关联起来呢？
我们继续看init(channel)方法
@Override
void init(Channel channel) throws Exception {
...
ChannelPipeline p = channel.pipeline();
final EventLoopGroup currentChildGroup = childGroup;
final ChannelHandler currentChildHandler = childHandler;
final Entry<ChannelOption<?>, Object>[] currentChildOptions;
final Entry<AttributeKey<?>, Object>[] currentChildAttrs;
p.addLast(new ChannelInitializer<Channel>() {
@Override
public void initChannel(Channel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
ChannelHandler handler = handler();
if (handler != null) {
pipeline.addLast(handler);
}
pipeline.addLast(new ServerBootstrapAcceptor(
currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
}
});
}
init方法在ServerBootstrap中重写了，从上面的代码片段中我们出道，它为pipeline中添加了一个ChannelInitializer，而这个ChannelInitializer中添加了一个关键的ServerBootstrapAcceptor handler。关于handler的添加与初始化的过程，我们下面介绍，现在关注一下ServerBoostrapAcceptor类。
ServerBootstrapAcceptor中重写了channelRead方法,其代码如下：
@Override
@SuppressWarnings("unchecked")
public void channelRead(ChannelHandlerContext ctx, Object msg) {
final Channel child = (Channel) msg;
child.pipeline().addLast(childHandler);
...
childGroup.register(child).addListener(...);
}
ServerBoostrapAccept中的childGroup是构造此对象时传入的currentChildGroup，即我们的workerGroup，而Channel是一个NioSocketChannel的实例，因此这里的childGroup.register就是将workerGroup中某个EventLoop和NioSocketChannel关联了。既然这样，那么现在的问题是，ServerBoostrapAcceptor.channelRead方法是怎么被调用的呢？其实当一个client连接到server时，Java底层的Nio ServerSocketChannel会有一个SelectionKey.OP_ACCEPT就绪时间，接着就会调用到NioServerSocketChannel.doReadMessage:
@Override
protected int doReadMessages(List<Object> buf) throws Exception {
SocketChannel ch = javaChannel().accept();
... 省略异常处理
buf.add(new NioSocketChannel(this, ch));
return 1;
}
在doReadMessage()中，通过javaChannel().accept()获取到客户端新连接的SocketChannel，接着就实例化一个NioSocketChannel并且传入NioServerSocketChannel对象（即this），由此可知，我们创建的而这个NioSocketChannel的父Channel就是NioServerSocketChannel实例。
接下来就经由Netty的ChannelPipeline机制，将读时间逐级发送到各个handler中，于是就会触发前面我们提到的ServerBoostrapAcceptor.channelRead方法啦
- handler的添加过程
服务器端的handler的添加过程和客户端的有点区别，和EventLoopGroup一样，服务器端的handler也有连个，一个是通过handler()方法设置handler字段，另一个通过childHandler()设置childHandler字段，通过前面的bossGroup和workerGroup的分析，其实我们在这里可以大胆地猜测：handler子弹与accept过程有关，即这个handler负责处理客户端的连接请求；而childHandler就是负责和客户端的连接的IO交互。
在关于bossGroup与workerGroup小节中，我们提到，serverBootstrap重写了init方法，在这个方法中添加了handler;
@Override
void init(Channel channel) throws Exception {
...
ChannelPipeline p = channel.pipeline();
final EventLoopGroup currentChildGroup = childGroup;
final ChannelHandler currentChildHandler = childHandler;
final Entry<ChannelOption<?>, Object>[] currentChildOptions;
final Entry<AttributeKey<?>, Object>[] currentChildAttrs;
p.addLast(new ChannelInitializer<Channel>() {
@Override
public void initChannel(Channel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
ChannelHandler handler = handler();
if (handler != null) {
pipeline.addLast(handler);
}
pipeline.addLast(new ServerBootstrapAcceptor(
currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
}
});
}
上面代码的initChannel方法中，首先通过handler()方法获取一个handler，如果获取的handle不为空，则添加到pipeline中，然后接着，添加了一个ServerBootstrapAcceptor实例，那么这里handler()方法返回的是那个对象呢？其实它返回的是handler字段，而这个字段就是我们在服务器端的启动代码中设置的：
b.group(bossGroup, workerGroup)
...
.handler(new LoggingHandler(LogLevel.INFO))
那么这个时候，pipeline中的handler情况如下：
根据我们原来分析客户端的经验，我们制定，当channel绑定到eventLoop后（在这里是NioServerSocketChannel绑定到bossGroup）中时，会在pipeline中发出fireChannelRegister时间，接着就会触发ChannelInitializer.initChannel方法的调用。因此在绑定完成后，此时的pipeline的内容如下
前面我们在分析bossGroup和workerGroup时，已经知道了在ServerBoostrapAcceptor.channelRead中会为新建的Channel设置handler并注册到一个eventLoop中，即
@Override
@SuppressWarnings("unchecked")
public void channelRead(ChannelHandlerContext ctx, Object msg) {
final Channel child = (Channel) msg;
child.pipeline().addLast(childHandler);
...
childGroup.register(child).addListener(...);
}
而这里的childHandler就是我们在服务器端启动代码中设置的handler
b.group(bossGroup, workerGroup)
...
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline p = ch.pipeline();
if (sslCtx != null) {
p.addLast(sslCtx.newHandler(ch.alloc()));
}
//p.addLast(new LoggingHandler(LogLevel.INFO));
p.addLast(new EchoServerHandler());
}
});
当这个客户端连接Channel注册后，就会触发ChannelInitializer.initChannel方法的调用，此后的客户端连接的ChannelPipeline状态如下：
最后我们来总结一下服务器端的handler与childHandler的区别与联系
- 在服务器NioServerSocketChannel的pipeline中添加的handler与ServerBoostrapAeecptor。
- 当有新的客户端连接请求时，ServerBoostrapAcceptor.channelRead中负责新建此连接的NioSocketChannel并添加childHandler到NioSocketChannel对应的pipeline中，并将此channel绑定到workerGroup中的某个eventLoop中。
- handler是在accept阶段起作用，他处理客户端的连接请求
-
childHandler是在客户端连接建立以后起作用的，它负责客户端连接的IO交互。
4.png
