摘要 作為一個web開發者，每天都在使用者Http協議，卻總是一知半解。本文參看Http RFC7230規範，梳理了http報文部分。 http 報文構成 start line: 起始行,描述請求或響應的基本信息 ( header field CRLF ): 頭 CRLF [ message bod ...
摘要
作為一個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
