来源于公众号方丈的寺院 ，

作者cnstonefang

摘要

作为服务端，web容器是如何解析http报文的呢？本文以jetty和undertow容器为例，来解析web容器是如何处理http报文的。

http报文其实就是一定规则的字符串，那么解析它们，就是解析字符串，看看是否满足http协议约定的规则。

start-line: 起始行,描述请求或响应的基本信息
*( header-field CRLF ): 头
CRLF
[message-body]: 消息body，实际传输的数据

jetty

以下代码都是jetty9.4.12版本

如何解析这么长的字符串呢，jetty是通过状态机来实现的。具体可以看下 org.eclipse.jetty.http.HttpParse类

总共分成了21种状态，然后进行状态间的流转。在 parseNext方法中分别对起始行 -> header -> body content分别解析

整体流程

整体有三条路径

1. 开始 -> start-line -> header -> 结束
2. 开始 -> start-line -> header -> content -> 结束
3. 开始 -> start-line -> header -> chunk-content -> 结束

起始行

start-line = request-line(请求起始行）/（响应起始行）status-line

1. 
   请求报文解析状态迁移 请求行：START -> METHOD -> SPACE1 -> URI -> SPACE2 -> REQUEST_VERSION
2. 
   响应报文解析状态迁移 响应行：START -> RESPONSE_VERSION -> SPACE1 -> STATUS -> SPACE2 -> REASON

header 头

HEADER 的状态只有一种了，在jetty的老版本中还区分了 HEADER_IN_NAM, HEADER_VALUE, HEADER_IN_VALUE等，9.4中都去除了。为了提高匹配效率，jetty使用了Trie树快速匹配header头。

content

请求体：

1. CONTENT -> END，这种是普通的带Content-Length头的报文，HttpParser一直运行CONTENT状态，直到最后ContentLength达到了指定的数量，则进入END状态
2. chunked分块传输的数据 CHUNKEDCONTENT -> CHUNKSIZE -> CHUNK -> CHUNK_END -> END

undertow

undertow是另一种web容器，它的处理方式与jetty有什么不同呢 状态机种类不一样了， io.undertow.util.HttpString.ParseState

具体处理流程在 HttpRequestParser抽象类中

与jetty不同的是对content的处理，在header处理完以后，将数据放到 io.undertow.server.HttpServerExchange,然后根据类型，有不同的content读取方式，比如处理固定长度的， FixedLengthStreamSourceConduit。