Netty 从netty角度分析http协议解析（一）HttpServerCodec

最新推荐文章于 2024-03-05 17:29:09 发布
最新推荐文章于 2024-03-05 17:29:09 发布
阅读量2.9k 收藏 3
点赞数 1
分类专栏： Java-Netty
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/anLA_/article/details/110913086
版权

Netty 从netty角度分析http协议解析，本文主要研究 HttpServerCodec 工作原理。

本文以netty 自带sample为例进行分析：
https://github.com/netty/netty/tree/4.1/example/src/main/java/io/netty/example/http/helloworld

HttpServerCodec

先看看 HttpServerCodec 的类定义：

public final class HttpServerCodec extends CombinedChannelDuplexHandler<HttpRequestDecoder, HttpResponseEncoder>
        implements HttpServerUpgradeHandler.SourceCodec {
}

CombinedChannelDuplexHandler 是结合了 ChannelInboundHandler 和 ChannelOutboundHandler 特性的 ChannelHandler。
即他结合了解码与编码为一体。
CombinedChannelDuplexHandler 定义：

public class CombinedChannelDuplexHandler<I extends ChannelInboundHandler, O extends ChannelOutboundHandler>
        extends ChannelDuplexHandler {

    private static final InternalLogger logger = InternalLoggerFactory.getInstance(CombinedChannelDuplexHandler.class);

    private DelegatingChannelHandlerContext inboundCtx;
    private DelegatingChannelHandlerContext outboundCtx;
    private volatile boolean handlerAdded;

    private I inboundHandler;
    private O outboundHandler;

里面定义了inbound和outbound两个handler以及对应的 handlerContext。

总体而言， HttpServerCodec 就是作为一个门面，具体实现由泛型传入的 I 和 O来实现。
对于 HttpServerCodec，则是 HttpRequestDecoder 和 HttpResponseEncoder。

HttpRequestDecoder

http 请求解码器：

public class HttpRequestDecoder extends HttpObjectDecoder {
...
}

默认的参数为 ：

      maxInitialLineLength = 4096,
      maxHeaderSize = 8192
      maxChunkSize = 8192.

主要实现都在其父类 HttpObjectDecoder 中维护。

HttpObjectDecoder

HttpObjectDecoder 是一个抽象类，它继承自ByteToMessageDecoder：

public abstract class HttpObjectDecoder extends ByteToMessageDecoder {
}

具体的http解码操作就是这里，解码出的结果为 HttpMessage。
这个方法很长，但是可以从里面了解更深层次的http协议，本文将从里面case 语句进行一步一步分析。

第一段
        if (resetRequested) {
            resetNow();
        }

如果reset了，说明在某个解析阶段，触发了HttpExpectationFailedEvent事件， 解析报错了，则重置HttpObjectDecoder 变量信息。

第二段

接下来就是判断 currentState 状态。

        switch (currentState) {
        case SKIP_CONTROL_CHARS:
            // Fall-through
        case READ_INITIAL: try {
            AppendableCharSequence line = lineParser.parse(buffer);
            if (line == null) {
                return;
            }
            String[] initialLine = splitInitialLine(line);
            if (initialLine.length < 3) {
                // Invalid initial line - ignore.
                currentState = State.SKIP_CONTROL_CHARS;
                return;
            }

            message = createMessage(initialLine);
            currentState = State.READ_HEADER;
            // fall-through
        } catch (Exception e) {
            out.add(invalidMessage(buffer, e));
            return;
        }
  1. 初始读，READ_INITIAL 处理的会读取http的请求行，即：方法，协议版本，uri。
    initialLine：GET, /, HTTP/1.1
    如果 initialLine 不足3个，则说明是一个非法的请求行，那么重置状态为下一次准备。
    调用 DefaultHttpRequest 创建一个 HttpMessage 返回，默认返回是一个 DefaultHttpRequest。
        return new DefaultHttpRequest(
                HttpVersion.valueOf(initialLine[2]),
                HttpMethod.valueOf(initialLine[0]), initialLine[1], validateHeaders);

最后将状态变为 READ_HEADER。

第三段

本段主要为读取header信息，由于http协议中，header有多行，并且每个header都会有属性会影响，所以会在读取中影响判断的逻辑。

        case READ_HEADER: try {
            State nextState = readHeaders(buffer);
            if (nextState == null) {
                return;
            }
            currentState = nextState;
            switch (nextState) {
            case SKIP_CONTROL_CHARS:
                // fast-path
                // No content is expected.
                out.add(message);
                out.add(LastHttpContent.EMPTY_LAST_CONTENT);
                resetNow();
                return;
            case READ_CHUNK_SIZE:
                if (!chunkedSupported) {
                    throw new IllegalArgumentException("Chunked messages not supported");
                }
                // Chunked encoding - generate HttpMessage first.  HttpChunks will follow.
                out.add(message);
                return;
            default:
                /**
                 * <a href="https://tools.ietf.org/html/rfc7230#section-3.3.3">RFC 7230, 3.3.3</a> states that if a
                 * request does not have either a transfer-encoding or a content-length header then the message body
                 * length is 0. However for a response the body length is the number of octets received prior to the
                 * server closing the connection. So we treat this as variable length chunked encoding.
                 */
                long contentLength = contentLength();
                if (contentLength == 0 || contentLength == -1 && isDecodingRequest()) {
                    out.add(message);
                    out.add(LastHttpContent.EMPTY_LAST_CONTENT);
                    resetNow();
                    return;
                }

                assert nextState == State.READ_FIXED_LENGTH_CONTENT ||
                        nextState == State.READ_VARIABLE_LENGTH_CONTENT;

                out.add(message);

                if (nextState == State.READ_FIXED_LENGTH_CONTENT) {
                    // chunkSize will be decreased as the READ_FIXED_LENGTH_CONTENT state reads data chunk by chunk.
                    chunkSize = contentLength;
                }

                // We return here, this forces decode to be called again where we will decode the content
                return;
            }
        } catch (Exception e) {
            out.add(invalidMessage(buffer, e));
            return;
        }

readHeaders方法 中处理逻辑如下

  1. readHeaders 方法主要为读取header信息，一行一行循环的读，并将其加入到 HttpMessage 的headers中。
  2. 读取完后，会读取content-length 字段，有则会记录在 contentLength 用于读http消息体信息。
  3. 判断如果既有 transfer-encoding 头，又有 content-length，则根据http协议，会将 content-length 删掉，并且以 trasfer-encoding 为主。
    并且将 当前解析状态为 State.READ_CHUNK_SIZE，等待下一次解码时，直接进入到 State.READ_CHUNK_SIZE 的case 中执行。
  4. 如果contentlenght >0，则返回 State.READ_FIXED_LENGTH_CONTENT。
  5. 否则返回 State.READ_VARIABLE_LENGTH_CONTENT，进行下一次实际解析具体content-length中数据。

再回看第三段：

  1. 如果是返回 SKIP_CONTROL_CHARS，则会添加 message即 DefaultHttpRequest 和一个LastHttpContent 标识为空的http信息返回。并执行 resetNow 方法，标识本次解析已失败。
  2. 如果返回 READ_CHUNK_SIZE，则由于会进一步解析成 HttpChunk 数据，所以并未执行 resetNow 方法。
  3. 否则如果content-length =0，则直接返回并重置解析。
  4. 如果返回 READ_FIXED_LENGTH_CONTENT 信息，则说明需要解析 content-length信息，就会执行：
chunkSize = contentLength;

给chunkSize赋值供下次使用。

总的来看，HttpObjectDecoder 解析出来的out集合，解析的http协议，会包括多份数据，这一段只会返回 一个DefaultHttpMessage以及一个 空的 HttpContent。

第四段
        case READ_VARIABLE_LENGTH_CONTENT: {
            // Keep reading data as a chunk until the end of connection is reached.
            int toRead = Math.min(buffer.readableBytes(), maxChunkSize);
            if (toRead > 0) {
                ByteBuf content = buffer.readRetainedSlice(toRead);
                out.add(new DefaultHttpContent(content));
            }
            return;
        }

本段开始解析可变长度的 content-length，由此可见，解析content-length时，并不会判断是get还是post。直接会读取content的信息。

  1. 获取一个toRead长度，一次性读取的最大maxChunkSize数据，默认为8192，即8kb。
  2. 读取完之后，直接将字节容器 ByteBuf 传入到 一个 DefaultHttpContent 并out返回。
    注意，此处并没有更改currentState状态，所以下一次仍然是READ_VARIABLE_LENGTH_CONTENT，一直会读到这次http协议终止。
    由于http协议是无状态的，所以会一直读，读一次会放一个 DefaultHttpContent。

如果没有退出，又为 State.READ_VARIABLE_LENGTH_CONTENT，则会按照这种方式一直读。

第五段
        case READ_FIXED_LENGTH_CONTENT: {
            int readLimit = buffer.readableBytes();

            // Check if the buffer is readable first as we use the readable byte count
            // to create the HttpChunk. This is needed as otherwise we may end up with
            // create an HttpChunk instance that contains an empty buffer and so is
            // handled like it is the last HttpChunk.
            //
            // See https://github.com/netty/netty/issues/433
            if (readLimit == 0) {
                return;
            }

            int toRead = Math.min(readLimit, maxChunkSize);
            if (toRead > chunkSize) {
                toRead = (int) chunkSize;
            }
            ByteBuf content = buffer.readRetainedSlice(toRead);
            chunkSize -= toRead;

            if (chunkSize == 0) {
                // Read all content.
                out.add(new DefaultLastHttpContent(content, validateHeaders));
                resetNow();
            } else {
                out.add(new DefaultHttpContent(content));
            }
            return;
        }

本节为读取 固定content-length内容处理逻辑：

  1. 判断当前ByteBuf是否有可读信息，利用maxChunkSize，得到一个最大读取值，设置一个本次读取最大限制。
  2. 每次读完之后，都会变更 chunkSize 值，chunkSize 则是 header中的content-length数据，读完就不会读了。
  3. 同样，如果是读完了，就会填充一个 DefaultLastHttpContent 放在末尾，否则会填充一个普通的 DefaultHttpContent 信息。
第六段

本段主要读取chunk相关配置项。
transfer-encoding:chunked 含义是什么呢？

Transfer-Encoding: chunked 表示输出的内容长度不能确定，普通的静态页面、图片之类的基本上都用不到这个。
但动态页面就有可能会用到，但我也注意到大部分asp,php,asp.net动态页面输出的时候大部分还是使用Content-Length，没有使用Transfer-Encoding: chunked。
不过如果结合：Content-Encoding: gzip 使用的时候，Transfer-Encoding: chunked还是比较有用的。
记得以前实现：Content-Encoding: gzip 输出时，先把整个压缩后的数据写到一个很大的字节数组里(如 ByteArrayOutputStream)，然后得到数组大小 -> Content-Length。
如果结合Transfer-Encoding: chunked使用，就不必申请一个很大的字节数组了，可以一块一块的输出，更科学，占用资源更少。

即一段一段的传输，减少一次性申请一个大的数据。
分块传输的规则：

  1. 每个分块包含一个 16 进制的数据长度值和真实数据。
  2. 数据长度值独占一行，和真实数据通过 CRLF(\r\n) 分割。
  3. 数据长度值，不计算真实数据末尾的 CRLF，只计算当前传输块的数据长度。
  4. 最后通过一个数据长度值为 0 的分块，来标记当前内容实体传输结束。

详细可以结合 https://www.cnblogs.com/jamesvoid/p/11297843.html 理解。

读取chunkSize
        case READ_CHUNK_SIZE: try {
            AppendableCharSequence line = lineParser.parse(buffer);
            if (line == null) {
                return;
            }
            int chunkSize = getChunkSize(line.toString());
            this.chunkSize = chunkSize;
            if (chunkSize == 0) {
                currentState = State.READ_CHUNK_FOOTER;
                return;
            }
            currentState = State.READ_CHUNKED_CONTENT;
            // fall-through
        } catch (Exception e) {
            out.add(invalidChunk(buffer, e));
            return;
        }

首先从buffer中，读取一行，并将其从16进制转为int类型，记录chunkSize。

  1. 如果chunkSize=0，则标记currentState为 State.READ_CHUNK_FOOTER;，表明读到底了。
  2. 否则读完chunkSize，就要去读chunkContent了，标记为 State.READ_CHUNKED_CONTENT;。
读取chunkContent
        case READ_CHUNKED_CONTENT: {
            assert chunkSize <= Integer.MAX_VALUE;
            int toRead = Math.min((int) chunkSize, maxChunkSize);
            toRead = Math.min(toRead, buffer.readableBytes());
            if (toRead == 0) {
                return;
            }
            HttpContent chunk = new DefaultHttpContent(buffer.readRetainedSlice(toRead));
            chunkSize -= toRead;

            out.add(chunk);

            if (chunkSize != 0) {
                return;
            }
            currentState = State.READ_CHUNK_DELIMITER;
            // fall-through
        }

根据 Math.min((int) chunkSize, maxChunkSize) 来获取一个可读值。

  1. 如果读取成功，则封装一个 DefaultHttpContent 加入到content中。
  2. 如果读完了，直接返回，注意此时状态仍然是 READ_CHUNKED_CONTENT，所以仍然会一直读到connect结束。
  3. 如果没有读完，说明http指定的chunkSize太大了，一个maxChunkSize大小的 DefaultHttpContent装不下，所以需要继续读，直接返回。
  4. 如果读完了，即chunkSize=0了，就说明这个chunk读完了， 将 currentState 设置为 State.READ_CHUNK_DELIMITER。
读取chunk的delimiter
        case READ_CHUNK_DELIMITER: {
            final int wIdx = buffer.writerIndex();
            int rIdx = buffer.readerIndex();
            while (wIdx > rIdx) {
                byte next = buffer.getByte(rIdx++);
                if (next == HttpConstants.LF) {
                    currentState = State.READ_CHUNK_SIZE;
                    break;
                }
            }
            buffer.readerIndex(rIdx);
            return;
        }

这一段是读取分隔符，即会一直读到writeIndex位置，指导读到 byte 值=10的分割付位置，然后将 重新设置currentState为State.READ_CHUNK_SIZE，表示读取下一个chunk块大小。

读取chunk的footer
        case READ_CHUNK_FOOTER: try {
            LastHttpContent trailer = readTrailingHeaders(buffer);
            if (trailer == null) {
                return;
            }
            out.add(trailer);
            resetNow();
            return;
        } catch (Exception e) {
            out.add(invalidChunk(buffer, e));
            return;
        }

本文则是读取到一个footer块，从而标识本次http协议读取结束，并构造一个 LastHttpContent 信息返回。

读取 bad request
        case BAD_MESSAGE: {
            // Keep discarding until disconnection.
            buffer.skipBytes(buffer.readableBytes());
            break;
        }

如果http报文不符合规范，则 currentState会被设置为 BAD_MESSAGE，直接会跳过所有课读取信息，直接返回。

解析UPGRADED
        case UPGRADED: {
            int readableBytes = buffer.readableBytes();
            if (readableBytes > 0) {
                // Keep on consuming as otherwise we may trigger an DecoderException,
                // other handler will replace this codec with the upgraded protocol codec to
                // take the traffic over at some point then.
                // See https://github.com/netty/netty/issues/2173
                out.add(buffer.readBytes(readableBytes));
            }
            break;
        }

解析到了upgrade，http返回101的websocket升级协议，则直接将ByteBuf添加到out集合中。

总结

在 HttpServerCodec 解析过程中，有以下特点：

  1. netty的http解析过程，是一个循环往复的过程，根据http协议特点，会解析request，也会解析response，会首先构造一个 HttpMessage 来存储request或者response的 请求行和header信息
  2. 在HttpMessage后面，会有一个或者多个HttpContent信息，HttpContent中主要会包ByteBuf信息。
  3. 在结尾，会带上一个LastHttpContent 类型的作为结尾。

关注博主公众号: 六点A君。
哈哈哈，一起研究Netty：
在这里插入图片描述

6点A君
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Netty的httpserver执行流程分析
importsys的博客
05-28 617
Netty的httpserver执行流程分析 在上一篇文章，我们用Netty进行了一个建议的HttpServer的编写，在本文，我们对该server的执行流程做简要的分析。 回调函数介绍 我们在上一节编写的TestHttpServerHandler类是继承SimpleChannelInboundHandler类，该类是专门对客户端发送请求进行处理的类。通过观察源码，我们发现该类又继承了Channe...
Netty学习（四）- 基于Netty的HTTP协议栈应用
noaman_wgs的博客
08-30 1233
前言 HTTP服务器在我们日常开发中，常见的实现方式就是实现一个Java Web项目，基于Nginx+Tomcat的方式就可以提供HTTP服务。但是很多场景是非Web容器的场景，这个时候再使用Tomcat就大材小用了。这个时候就可以使用基于Netty的HTTP协议。那么基于Netty开发的HTTP服务器有什么优势呢？ Netty的多线程模型和异步非阻塞特性能够支持高并发； 相比于Tomcat H...
Netty HttpServerCodec和HttpObjectAggregator
最新发布
weixin_42286658的博客
03-05 1196
从上可以看出，当我们用POST方式请求服务器的时候，对应的参数信息是保存在message body中的,如果只是单纯的用HttpServerCodec是无法完全的解析Http POST请求的，因为HttpServerCodec只能获取uri中参数，所以需要加上HttpObjectAggregator。HttpServerCodec是netty针对http编解码的处理类，但是这些只能处理像http get的请求,也就是数据带在url问号后面的http请求参数。POST请求包括三个部分。
使用netty 作为 http服务器
weixin_34336526的博客
10-11 140
为什么80%的码农都做不了架构师？>>> ...
Netty中的HttpServerCodec和HttpObjectAggregator
weixin_41866717的博客
04-13 777
会将一个Http请求分为多个数据类型，如请求头、请求体、数据过大时分片（有限状态机实现），后续的ChannelHandler可以根据不同的类型来处理，如果想直接处理完整的Http请求，可在pipeline后面加上。作为HttpServer，需要加入来自client的Request的Http协议的Decoder和server回复Response的Http协议的Encoder，而这两个部分集成在了Netty提供的。（只处理入站请求），该类会聚合一个请求的所有东西生成一个。都继承自该类，而这里。
Netty进阶 协议设计与解析 HttpServerCodec、自定义协议Codec，源码分析
清风
11-25 3480
上一篇我们讲解了一些Netty给我们提供的一些编解码器，使得我们可以自己来设计一些数据的格式。 1.HttpServerCodec 服务器的编解码器，遵从HTTP协议 一般以Codec结尾的既可以做解码也可以编码，Decoder意为解码，Encoder意为编码。其中解码是ChannelInboundHandlerAdapter的子类(即入站handler)，Encoder为ChannelOutboundHandlerAdapter的子类(即出站handler) 只需在服务器加上如下代码.
netty关于http和tcp协议整合
11-13
对于HTTP，Netty提供了一个完整的HTTP解码器和编码器链，包括HttpServerCodec，它可以自动处理HTTP请求和响应的编码和解码。此外，还可以使用HttpObjectAggregator来聚合多个HTTPContent片段到单个FullHttpRequest或...
netty学习demo（初学代码结构+固定消息+自定义分隔符+自定义协议+心跳+http+序列化压缩+自动断线)
09-07
首先，让我们从初学者的角度来看Netty的代码结构。在Netty中，通常会有一个启动类，它负责初始化`ServerBootstrap`并绑定监听端口。`ChannelInitializer`是用于配置新创建的`Channel`的，它会添加`ChannelHandler`到...
netty-http：带有JAX-RS的基于Netty的HTTP服务
02-03
Netty 是一个高性能、异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。在本文中，我们将深入探讨如何利用 Netty 实现一个带有 JAX-RS 支持的 HTTP 服务，这将使我们能够构建 ...
Netty HTTP协议简单实现
08-11
HTTP（超文本传输协议）是互联网上应用最为广泛的一种网络协议，用于从万维网服务器传输超文本到本地浏览器的传输协议。Netty 提供了对 HTTP 协议的全面支持，包括 HTTP/1.x 和 HTTP/2。 1. **Netty 框架简介** ...
netty案例，netty4.1中级拓展篇十一《Netty基于ChunkedStream数据流切块传输》源码
10-11
netty案例，netty4.1中级拓展篇十一《Netty基于ChunkedStream数据流切块传输》源码 https://mp.weixin.qq.com/s?__biz=MzIxMDAwMDAxMw==&mid=2650724953&idx=1&sn=42a0031e9b757f4d941a02b686e64e12&scene=19#wechat_redirect
Netty 源码中如何解析Http协议
Rapper金馆长的博客
03-29 1130
通过netty官方的example看如何用netty解析http请求报头
netty系列之:使用netty实现支持http2的服务器
程序那些事
10-22 9007
文章目录简介基本流程CleartextHttp2ServerUpgradeHandlerHttp2ConnectionHandler总结 简介 上一篇文章中，我们提到了如何在netty中配置TLS，让他支持HTTP2。事实上TLS并不是https的一个必须要求，它只是建议的标准。那么除了TLS之外，还需要如何设置才能让netty支持http2呢？一起来看看吧。 基本流程 netty支持http2有两种情况，第一种情况是使用tls，在这种情况下需要添加一个ProtocolNegotiationHandler来
基于Netty实现HttpClinet/HttpServer
鸟哥哥的专栏
05-03 1526
基于 Netty 实现 HTTP Server 和 HTTP Client，基于Netty实现RPC。
Netty 知识整理 （2）HttpServerCodec和HttpObjectAggregator用法
m0_45406092的博客
03-16 6322
GET请求 Get请求包括两个部分： request line(包括method，request uri，protocol version)) header HttpServerCodec是netty针对http编解码的处理类，但是这些只能处理像http get的请求,也就是数据带在url问号后面的http请求 POST请求 POST请求包括三个部分 request line(包括meth...
HttpServerCodec和HttpObjectAggregator如何解析Http协议
woshizw27的专栏
02-28 9050
1、首先开始看HttpServerCodec 可以看到他继承了ChannelHandlerAppender，并且创建了一个HttpRequestDecode和一个HttpResponseEncoder。 Appender内部有一个Entry的list按顺序存放这两个编码解码器 ps：在initchannelhandler时，添加的是HttpServerCode，查看addLast方法...
Codec
sn_gis的专栏
11-30 2397
已经提供的ChannelHandler和Codec本章包括 使用SSL/TLS使得Netty安全 构建Netty HTTP/HTTPS 应用 处理空闲连接和超时 基于分隔符和长度协议的解码器 写大的数据 序列化数据 前一章展示了如何创建你的codec。有了这些知识你就可以为你的应用写 codec了。 然而，如果Netty提供了一些标准的ChannelHandlers and codecs岂不是更好。
facebook/swift:构建thrift http server(2)--HttpServerCodec
10km的专栏
05-04 1368
在为facelog选择XHR实现方案时，我反复看过[facebook/swift](https://github.com/facebookarchive/swift),了解到它依赖的底层通讯框架是[netty](https://github.com/netty/netty)，说实话，我之前对netty并不太了解，藉于这次任务需要，我才花时间进一步了解了一下netty是什么。 我好像明白facebook/swift为什么要基于netty设计了，netty本就是一个高效的异步通讯框架，你可以利用它实现你想要的任
netty对http协议解析原理解析
月夜楓
03-12 835
1. http协议 1.1 描述 标示 ASCII 描述 字符 CR 13 Carriage return LF 10 Line feed SP 32 Horizontal space(空 COLON 58 COLON(冒号) : http协议主要使用CRLF进行分 1.2 请求包 主要包含三部分：请求行(line)，请求头(header)，请求正文(body) ...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值