詳解http報文(2)-web容器是如何解析http報文的

  • 2019 年 10 月 9 日
  • 筆記

摘要

詳解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,    ![](https://img2018.cnblogs.com/blog/1147363/201910/1147363-20191009220439773-204646534.png),          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;      }

整體流程

整體有三條路徑

  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頭。

static      {          CACHE.put(new HttpField(HttpHeader.CONNECTION,HttpHeaderValue.CLOSE));          CACHE.put(new HttpField(HttpHeader.CONNECTION,HttpHeaderValue.KEEP_ALIVE));        // 以下省略了很多了通用header頭

content

請求體:

  1. CONTENT -> END,這種是普通的帶Content-Length頭的報文,HttpParser一直運行CONTENT狀態,直到最後ContentLength達到了指定的數量,則進入END狀態
  2. chunked分塊傳輸的數據
    CHUNKED_CONTENT -> CHUNK_SIZE -> 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

關注公眾號【方丈的寺院】,第一時間收到文章的更新,與方丈一起開始技術修行之路
在這裡插入圖片描述

參考

http://www.blogjava.net/DLevin/archive/2014/04/19/411673.html

https://www.ph0ly.com/2018/10/06/jetty/connection/http-parser/

https://webtide.com/http-trailers-in-jetty/

http://undertow.io/undertow-docs/undertow-docs-2.0.0/