摘要
在詳解http封包一文中，詳細介紹了http封包的文本結構。那麼作為服務端，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
類
public enum State { START, METHOD,, SPACE1, STATUS, URI, SPACE2, REQUEST_VERSION, REASON, PROXY, HEADER, CONTENT, EOF_CONTENT, CHUNKED_CONTENT, CHUNK_SIZE, CHUNK_PARAMS, CHUNK, TRAILER, END, CLOSE, // The associated stream/endpoint should be closed CLOSED // The associated stream/endpoint is at EOF } 複制
總共分成了21種狀态，然後進行狀态間的流轉。在
parseNext
方法中分别對起始行 -> header -> body content分别解析
public boolean parseNext(ByteBuffer buffer) { try { // Start a request/response if (_state==State.START) { // 快速判斷 if (quickStart(buffer)) return true; } // Request/response line 轉換 if (_state.ordinal()>= State.START.ordinal() && _state.ordinal()<State.HEADER.ordinal()) { if (parseLine(buffer)) return true; } // headers轉換 if (_state== State.HEADER) { if (parseFields(buffer)) return true; } // content轉換 if (_state.ordinal()>= State.CONTENT.ordinal() && _state.ordinal()<State.TRAILER.ordinal()) { // Handle HEAD response if (_responseStatus>0 && _headResponse) { setState(State.END); return handleContentMessage(); } else { if (parseContent(buffer)) return true; } } return false; } 複制
整體流程
整體有三條路徑
- 開始 -> 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 頭
HEADER 的狀态隻有一種了，在jetty的老版本中還區分了
HEADER_IN_NAM
,
HEADER_VALUE
,
HEADER_IN_VALUE
等，9.4中都去除了。為了提高比對效率，jetty使用了Trie樹快速比對header頭。
static { CACHE.put(new HttpField(HttpHeader.CONNECTION,HttpHeaderValue.CLOSE)); CACHE.put(new HttpField(HttpHeader.CONNECTION,HttpHeaderValue.KEEP_ALIVE)); // 以下省略了很多了通用header頭 複制
content
請求體：
- CONTENT -> END，這種是普通的帶Content-Length頭的封包，HttpParser一直運作CONTENT狀态，直到最後ContentLength達到了指定的數量，則進入END狀态
- chunked分塊傳輸的資料 CHUNKEDCONTENT -> CHUNKSIZE -> CHUNK -> CHUNK_END -> END
undertow
undertow是另一種web容器，它的處理方式與jetty有什麼不同呢 狀态機種類不一樣了，
io.undertow.util.HttpString.ParseState
public static final int VERB = 0; public static final int PATH = 1; public static final int PATH_PARAMETERS = 2; public static final int QUERY_PARAMETERS = 3; public static final int VERSION = 4; public static final int AFTER_VERSION = 5; public static final int HEADER = 6; public static final int HEADER_VALUE = 7; public static final int PARSE_COMPLETE = 8; 複制
具體處理流程在
HttpRequestParser
抽象類中
public void handle(ByteBuffer buffer, final ParseState currentState, final HttpServerExchange builder) throws BadRequestException { if (currentState.state == ParseState.VERB) { //fast path, we assume that it will parse fully so we avoid all the if statements // 快速處理GET final int position = buffer.position(); if (buffer.remaining() > 3 && buffer.get(position) == 'G' && buffer.get(position + 1) == 'E' && buffer.get(position + 2) == 'T' && buffer.get(position + 3) == ' ') { buffer.position(position + 4); builder.setRequestMethod(Methods.GET); currentState.state = ParseState.PATH; } else { try { handleHttpVerb(buffer, currentState, builder); } catch (IllegalArgumentException e) { throw new BadRequestException(e); } } // 處理path handlePath(buffer, currentState, builder); // 處理版本 if (failed) { handleHttpVersion(buffer, currentState, builder); handleAfterVersion(buffer, currentState); } // 處理header while (currentState.state != ParseState.PARSE_COMPLETE && buffer.hasRemaining()) { handleHeader(buffer, currentState, builder); if (currentState.state == ParseState.HEADER_VALUE) { handleHeaderValue(buffer, currentState, builder); } } return; } handleStateful(buffer, currentState, builder); } 複制
與jetty不同的是對content的處理，在header處理完以後，将資料放到
io.undertow.server.HttpServerExchange
,然後根據類型，有不同的content讀取方式，比如處理固定長度的，
FixedLengthStreamSourceConduit
。