吃透Netty源码系列四十二之Http处理预备知识

HTTP的基本知识

其实这个到处都有，我就讲几点Netty里比较关注的。首先先看下这个协议的格式，这个是请求，响应差不多的：

找个真实的数据看看：
这个是POST方法的：

这个是GET的：

至于区别什么的百度下吧，这里就想说几个点，Netty里会碰到。

POST消息体传输方式

直接发送消息体

最长见的就是直接在POST请求头里设置了Content-Length属性，也就是所谓的定长，只要接收端根据这个去读定长的字节就行，这个方便是方便，但是如果一个比较大的数据，可能要消耗比较大的内存。

块传输

还有一种是Transfer-Encoding: chunked，然后消息体可以分成好几次传，有一定的格式规范，这个其实就可以降低接收端的内存消耗，特别是一些不定长的数据。比如要从数据库里源源不断的读消息传出去，你可能不知道总共有多大，只有读了才知道。

Netty关于HTTP设计的一些类的简单介绍

其实有很多相关的接口，真的很多，所以打算画个结构图，大致了解下他们的用途和之间的关系，虚线框表示是接口，主要netty把相同消息行部分和消息头都抽离出来了，最后进行一个整合。后面会稍微介绍下，具体还是看源码比较好：

DecoderResult编码结果

要对HTTP数据解码，得有个成功失败的结果吧。这个就是封装了编码的结果，主要有成功，失败，还未完成。

DecoderResultProvider编码结果提供器

用来设置和获取编码结果。

public interface DecoderResultProvider {

    DecoderResult decoderResult();

    void setDecoderResult(DecoderResult result);
}

HttpObject编码结果提供接口

其实是一个Http编码结果提供接口，唯一的方法还被标记弃用了：

ByteBufHolder对HTTP消息体的一些操作

这个主要是针对接受和发送的消息体缓冲区的一些操作和管理。

public interface ByteBufHolder extends ReferenceCounted {

    /**
     * Return the data which is held by this {@link ByteBufHolder}.
     */
    ByteBuf content();

    /** 深拷贝一份
     * Creates a deep copy of this {@link ByteBufHolder}.
     */
    ByteBufHolder copy();

    /** 浅拷贝副本
     * Duplicates this {@link ByteBufHolder}. Be aware that this will not automatically call {@link #retain()}.
     */
    ByteBufHolder duplicate();

    /** 保留的这个副本
     * Duplicates this {@link ByteBufHolder}. This method returns a retained duplicate unlike {@link #duplicate()}.
     *
     * @see ByteBuf#retainedDuplicate()
     */
    ByteBufHolder retainedDuplicate();

    /** 创建一个新的
     * Returns a new {@link ByteBufHolder} which contains the specified {@code content}.
     */
    ByteBufHolder replace(ByteBuf content);

    @Override
    ByteBufHolder retain();

    @Override
    ByteBufHolder retain(int increment);

    @Override
    ByteBufHolder touch();

    @Override
    ByteBufHolder touch(Object hint);
}

HttpMessage协议和头信息接口

公共的就是协议版本号和一些头信息。

HttpContent消息体接口

LastHttpContent最后一个消息体接口

最后接受的一个消息体，头信息是空的。

HttpRequest包含请求行和请求头的接口

请求行相关独有接口，无消息体接口。

public interface HttpRequest extends HttpMessage {
    HttpMethod method();
    HttpRequest setMethod(HttpMethod method);
    String uri();
    HttpRequest setUri(String uri);
    @Override
    HttpRequest setProtocolVersion(HttpVersion version);
}

HttpResponse包含响应行和响应头的接口

响应行相关独有接口，无消息体接口。

FullHttpMessage请求和响应的通用HTTP信息接口

除了请求行的方法和URI和相应行的状态码之外的所有通用HTTP信息，也就是消息头，协议版本，消息体。

FullHttpRequest完整HTTP请求消息接口

FullHttpResponse完整HTTP响应消息接口

基本的介绍完了，其他的都整合基本的，自己看下就好了。

Netty有关Http的编解码器

HttpRequestDecoder请求解码器

首先会将请求行和请求头解析出来，根据请求头中是否有Content-Length或者Transfer-Encoding: chunked属性来判断是否还需要进行解码，如果需要，还持续进行解码，直到把消息体全部收完为止，而且期间会解码一次传递一次消息，因此自定义的处理器会不断的收到消息，第一次是消息行和消息头，后面就是消息体，直到收到最后一次消息体才会结束。基本上是按这么解码的，每一块都会被向后传递：

如果是比较大的包，比如文件，可以直接用这个，块传输，边传输边进行其他操作，比如一遍下载一遍看视频，断点续传啊这类。占用内存少，接受一个处理完可以释放内存，或者复用。

HttpObjectAggregator消息聚合器

在后面加在处理器，这个就是可以解决上面的问题，可以把消息聚合成一个复合缓冲区，一起给后面的处理器，直接封装成AggregatedFullHttpRequest类型传递下去。这样就不需要在处理器中判断是否接受到一半的逻辑了。但是这个有一个指定接受的长度限制，超过长度了直接就丢弃不处理了。主要可以用于接收一些相对较小的消息，不用后面处理器再去判断是否是个完整的包，但是如果包很大可能占用很大内存。

基本的先了解这些，其实里面还有很多，有了这些理解的基础才可以去看，不然看到那么多接口和类真的很晕。后面的内容在讲具体解码流程的时候会有更多的介绍。

好了，今天就到这里了，希望对学习理解有帮助，大神看见勿喷，仅为自己的学习理解，能力有限，请多包涵。