摘要
作為一個web開發者，每天都在使用者Http協議，卻總是一知半解。本文參看Http RFC7230規范，梳理了http報文部分。
http 報文構成
start-line: 起始行,描述請求或響應的基本信息
*( header-field CRLF ): 頭
CRLF
[ message-body ]: 消息body，實際傳輸的數據
header
起始行
起始行的格式就是
start-line = request-line(請求起始行）/（響應起始行）status-line
header頭
這些格式就是規則，用來解析的
順序
理論上頭字段的key順序是無所謂的，但是最佳實踐是將控制字段放在前面，比如請求的時候Host,響應的Date，這樣可以盡快發現是否需要處理。
重復
除了Set-Cookie這個key，其他都不行，如果發送方發了重復的key，接收方會將它合並，值是以逗號分隔。
字段限制
協議本身對每個頭字段沒有限制，但是在工程實踐中的得出過一些實踐，沒有通用的限制，和字段具體的語義有關。整體的header大小限制沒有定義標准值，有些4K，有些8K。server端檢查到header頭超過了限制值，處於安全考慮，不會忽略掉。而是會拋出4XX錯誤。
只有Host字段是請求頭中必須帶的,其他無所謂。
| 字段 | 請求頭 | 響應頭 | 解釋 |
|---|---|---|---|
| Host | 1 | 0 | 告訴服務器應該由哪個主機處理 |
| User-Agent | 1 | 0 | 標識瀏覽器類型，雖然已經被用爛了，不太可信，但有時候可以用來自定義類型 |
| Accept | 1 | 0 | 可以接收的body類型 mime type,比如text/html |
| Accept-Charset | 1 | 0 | 可以接收的字符集 |
| Accept-Encoding | 1 | 0 | 可以接收的編碼格式 |
| Accept-Language | 1 | 0 | 可以接收的多語言 |
| Content-Type | 1 | 1 | 發送的body類型mime type |
| Content-Encoding | 1 | 1 | 發送的編碼 |
| Content-Language | 1 | 1 | 發送的語言 |
這邊有完整的分類
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
body
header是必須有要有的，但是body就不一定要用。
body就是傳輸的內容。因為Http是應用層協議，所以除了傳輸數據，還需要定義傳輸的數據格式。這些格式定義在header中指定。Content-Length請求或者響應的body長度，必須要帶上這個字段，以便對方可以方便的分辨出報文的邊界，也就是Body數據何時結束。如果Body太大，需要邊計算邊傳輸，不到最后計算結束是無法知道整個Body大小的，這個時候可以使用chunk傳輸，通過Transfer-Encoding指定，這兩個header key是互斥的，只能指定一個，如果指定了兩個，接收端優先處理Transfer-Encoding字段。通常body的數據比較多時，都使用chunk來傳輸，效率比較高。沒有了length，怎么知道數據傳輸結束了，通過一個長度為 0的chunk，對應的分塊數據沒有內容，來表示body內容結束。
jetty 干了什么
jetty 是web容器，需要解析Http Request,發送Http Response。具體干了什么下回分析
關注公眾號【方丈的寺院】，第一時間收到文章的更新，與方丈一起開始技術修行之路
參考
https://tools.ietf.org/pdf/rfc7230.pdf
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers