来源于公众号方丈的寺院,摘要作为服务端,web容器是如何解析http报文的呢?本文以jetty和undertow容器为例,来解析web容器是如何处理http报文的 。
作者cnstonefang
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分别解析
文章插图
文章插图
整体流程
整体有三条路径
- 开始 -> start-line -> header -> 结束
- 开始 -> start-line -> header -> content -> 结束
- 开始 -> start-line -> header -> chunk-content -> 结束
start-line = request-line(请求起始行)/(响应起始行)status-line
文章插图
请求报文解析状态迁移 请求行:START -> METHOD -> SPACE1 -> URI -> SPACE2 -> REQUEST_VERSION
响应报文解析状态迁移 响应行:START -> RESPONSE_VERSION -> SPACE1 -> STATUS -> SPACE2 -> REASON
HEADER 的状态只有一种了,在jetty的老版本中还区分了 HEADER_IN_NAM, HEADER_VALUE, HEADER_IN_VALUE等,9.4中都去除了 。为了提高匹配效率,jetty使用了Trie树快速匹配header头 。
文章插图
content
请求体:
- CONTENT -> END,这种是普通的带Content-Length头的报文,HttpParser一直运行CONTENT状态,直到最后ContentLength达到了指定的数量,则进入END状态
- chunked分块传输的数据 CHUNKEDCONTENT -> CHUNKSIZE -> CHUNK -> CHUNK_END -> END
文章插图
具体处理流程在 HttpRequestParser抽象类中
文章插图
文章插图
与jetty不同的是对content的处理,在header处理完以后,将数据放到 io.undertow.server.HttpServerExchange,然后根据类型,有不同的content读取方式,比如处理固定长度的,FixedLengthStreamSourceConduit 。
文章插图
【web容器是如何解析http报文的】
推荐阅读
- 司母戊鼎是最大的青铜器 司母戊鼎是迄今世界上出土最大的青铜器
- 佛本无言 相逢是缘 茶做点缀 茶已入心
- 休闲鞋跑步效果怎样
- 六朝以前茶史资料表明,巴蜀是茶文化的摇篮
- 什么样的运动是属于有氧运动?
- 跑步能帮助我们瘦身么?
- 淘宝开店年龄限制是多少 开淘宝店铺对年龄有要求吗
- 梦见仇人欺负我是什么意思 梦见仇人威胁恐吓我
- 跳绳减肥健身吗
- 马航真相大白预言家细思极恐 马航预言是什么意思是真的吗