來源於公眾號方丈的寺院 ，

作者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。