吃透Netty源码系列四十五之HttpObjectAggregator详解

聚合消息

前面我们讲了， 一个HTTP请求最少也会在HttpRequestDecoder里分成两次往后传递，第一次是消息行和消息头，第二次是消息体，哪怕没有消息体，也会传一个空消息体。如果发送的消息体比较大的话，可能还会分成好几个消息体来处理，往后传递多次，这样使得我们后续的处理器可能要写多个逻辑判断，比较麻烦，那能不能把消息都整合成一个完整的，再往后传递呢，当然可以，用HttpObjectAggregator。

先介绍一下一些属性

HTTP有个头属性Except:100-continue用来优化服务器和客户端数据传输的，在要发送比较大的数据的时候，不会直接发送，而是会先征求下服务器意见是否可以继续发送数据，服务器可以允许也可以不允许，都应该响应一下。具体介绍可以参考这篇文章。

	//接受100-continue，响应状态码100
    private static final FullHttpResponse CONTINUE =//Except:100-continue的响应
            new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.CONTINUE, Unpooled.EMPTY_BUFFER);
            
	//不接受，响应状态码417 不支持
    private static final FullHttpResponse EXPECTATION_FAILED = new DefaultFullHttpResponse(
            HttpVersion.HTTP_1_1, HttpResponseStatus.EXPECTATION_FAILED, Unpooled.EMPTY_BUFFER);

	//不接受，响应状态码413 消息体太大而关闭连接
    private static final FullHttpResponse TOO_LARGE_CLOSE = new DefaultFullHttpResponse(
            HttpVersion.HTTP_1_1, HttpResponseStatus.REQUEST_ENTITY_TOO_LARGE, Unpooled.EMPTY_BUFFER);

	//不接受，响应状态码413 消息体太大，没关闭连接
    private static final FullHttpResponse TOO_LARGE = new DefaultFullHttpResponse(
        HttpVersion.HTTP_1_1, HttpResponseStatus.REQUEST_ENTITY_TOO_LARGE, Unpooled.EMPTY_BUFFER);

    static {
   
   //设定头消息
        EXPECTATION_FAILED.headers().set(CONTENT_LENGTH, 0);
        TOO_LARGE.headers().set(CONTENT_LENGTH, 0);

        TOO_LARGE_CLOSE.headers().set(CONTENT_LENGTH, 0);
        TOO_LARGE_CLOSE.headers().set(CONNECTION, HttpHeaderValues.CLOSE);//关闭头信息
    }

    private final boolean closeOnExpectationFailed;//如果消息过大是否关闭连接，报异常

结构

看到他有4个泛型，分别对应是聚合HTTP类型的，HTTP通用消息请求行和请求头的，HTTP消息体，HTTP完整通用消息，包括消息体

对应的父类的泛型就是：

这些类型直接会影响到后续的逻辑判断，所以要弄清楚对应的关系。

MessageAggregator

主要的逻辑代码在这里，这个是通用的模板，里面就是模板方法啦，先看下他的一些属性吧，他会把HTTP的消息体都封装成一个缓冲区，加到复合缓冲区里。

  private static final int DEFAULT_MAX_COMPOSITEBUFFER_COMPONENTS = 1024;//最大复合缓冲区组件个数

    private final int maxContentLength;//最大消息图长度
    private O currentMessage;//当前消息
    private boolean handlingOversizedMessage;//是否处理过大消息

    private int maxCumulationBufferComponents = DEFAULT_MAX_COMPOSITEBUFFER_COMPONENTS;//累加组件的最大个数
    private ChannelHandlerContext ctx;//处理器上下文
    private ChannelFutureListener continueResponseWriteListener;// 100-continue响应监听器

    private boolean aggregating;//是否正在聚合

acceptInboundMessage判断类型

判断是否是泛型I类型，也就是我们HttpObjectAggregator泛型中的HttpObject类型，是才会处理，否则就不处理。然后会判断是否聚合好了，如果没开始聚合就进行聚合，如果还在聚合就继续。

@Override
    public boolean acceptInboundMessage(Object msg) throws Exception {
   
   

        if (!super.acceptInboundMessage(msg)) {
   
   //是否是泛型I类型，比如HttpObject类型
            return false;
        }
        @SuppressWarnings("unchecked")
        I in = (I) msg;

        if (isAggregated(in)) {
   
   //是否聚合好了
            return false;
        }
        if (isStartMessage(in)) {
   
   //是否是开始聚合
            aggregating = true;//开始聚合
            return true;
        } else if (aggregating && isContentMessage(in)) {
   
   //正在内容聚合
            return true;
        }

        return false;
    }

decode真正的聚合

这个方法比较长，但是做的事情分那么几个：

• 如果是开始消息，也就不是请求体，那就开始判断是否有Except:100-continue头信息，有的话根据长度和是否支持来判断是否要返回响应。之后判断如果前面解码失败，就直接整合消息体返回，否则就创建复合缓冲区，如果是消息体的话就添加进去，然后封装成一个完整的消息类型。
• 如果是消息体了，就加入到复合画冲去里，然后判断是否是最后一个消息体，是的话就进行最后的整合，其实就是设置Content-Length头信息。

    @Override
    protected void decode(final ChannelHandlerContext ctx, I msg, List<Object> out) throws Exc