請求報文
HTTP 請求整體的報文結構由 請求行-請求頭-請求數據 三部分構成，其中請求行格式是固定的，標識了請求方法/請求URL和協議版本它們之間用空格間隔。
請求頭是我們為請求添加的附加信息，也就是一些額外的控制位。我們可以選擇性的為請求添加請求頭，除了一種特殊情況，POST 請求時請求頭中必須包含 Content-Length 字段，用於標識請求體中的數據長度，來為本次請求的報文定界。
除此之外，我們看一下平常生產中那些比較常見的請求頭，常見的服務端與客戶端對這些請求頭的支持決定了我們的通信過程。
常見的請求報文請求頭
Accept： 瀏覽器可接受的MIME類型。
Accept-Charset：瀏覽器可接受的字符集。
Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。
Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到。
Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中。
Content-Length：表示請求消息正文的長度。
Host： 客戶機通過這個頭告訴服務器，想訪問的主機名。Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀態碼返回。
If-Modified-Since：客戶機通過這個頭告訴服務器，資源的緩存時間。只有當所請求的內容在指定的時間后又經過修改才返回它，否則返回304“Not Modified”應答。
Referer：客戶機通過這個頭告訴服務器，它是從哪個資源來訪問服務器的(防盜鏈)。包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。
User-Agent：User-Agent頭域的內容包含發出請求的用戶信息。瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用。
Cookie：客戶機通過這個頭可以向服務器帶數據，這是最重要的請求頭信息之一。
Pragma：指定“no-cache”值表示服務器必須返回一個刷新后的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝。
From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它。
Connection：處理完這次請求后是否斷開連接還是繼續保持連接。如果Servlet看到這里的值為“Keep- Alive”，或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久連接)，它就可以利用持久連接的優點，當頁面包含多個元素時(例如Applet，圖片)，顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小。
Range：Range頭域可以請求實體的一個或者多個子范圍。例如，
表示頭500個字節：bytes=0-499
表示第二個500字節：bytes=500-999
表示最后500個字節：bytes=-500
表示500字節以后的范圍：bytes=500-
第一個和最后一個字節：bytes=0-0,-1
同時指定幾個范圍：bytes=500-600,601-999
但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206(PartialContent)返回而不是以200 (OK)。
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標准的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。
-空行
它的作用是通過一個空行，告訴服務器請求頭部到此為止。
-請求數據
若方法字段是GET，則此項為空，沒有數據
若方法字段是POST,則通常來說此處放置的就是要提交的數據
比如要使用POST方法提交一個表單，其中有user字段中數據為“admin”, password字段為123456，那么這里的請求數據就是 user=admin&password=123456，使用&來連接各個字段。
響應報文
響應報文由三部分組成：響應行、響應頭、空行、響應體。響應行一般由協議版本/狀態碼以及其描述組成。比較常見的狀態碼有以下幾種：
100~199：表示成功接收請求，要求客戶端繼續提交下一次請求才能完成整個處理過程。
200~299：表示成功接收請求並已完成整個處理過程。常用200
300~399：為完成請求，客戶需進一步細化請求。例如：請求的資源已經移動一個新地址、常用302(重定向),307和304(可以使用緩存，別來煩服務器了)
400~499：客戶端的請求有錯誤，常用404(意味着你請求的資源在web服務器中沒有)403(服務器拒絕訪問，權限不夠)
500~599：服務器端出現錯誤，常用500
需要說明的是瀏覽器對 302 的反應：
常見的響應報文響應頭
與請求頭的作用一樣。請求頭是客戶端為請求附加的控制位，告訴服務端本次請求該如何處理。響應頭則是服務端為響應報文附加的控制位，告訴服務端該如何處理響應的數據。
設置HTTP響應頭往往和狀態碼結合起來發揮作用的。
比如，代表重定向的幾個狀態碼會與響應頭中的 Location 字段成對出現，客戶端收到重定向狀態碼則以自己的方式請求Location中的地址。在服務端，我們使用 sendRedirect 即可直接設置 Location 字段。
再比如 401(Unauthorized) 無權限訪問狀態代碼會與一個WWW-Authenticate頭成對出現，告訴客戶端需要提供何種的授權信息。
當然除此之外，即使沒有狀態碼對應，響應頭也可以自己發揮相應的作用。比如大名鼎鼎的 Cookie，指定修改日期，指示瀏覽器按照指定的間隔刷新頁面，聲明文檔的長度以便利用持久HTTP連接等等。有些狀態碼需要結合響應頭使用，告訴客戶端下一步該怎么辦，但響應頭並不一定需要結合狀態碼使用，它們本身就是一些控制位。只要客戶端支持便可以單獨發揮作用。
Allow：服務器支持哪些請求方法(如GET、POST等)。
Content-Encoding：文檔的編碼(Encode)方法。只有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE4、IE5才支持它。因此，Servlet應該通過查看Accept-Encoding頭(即request.getHeader(“Accept- Encoding”))檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。因為短鏈接並不存在報文定界問題，我們只要將緩沖區中的數據全部讀入便是一次完整的請求。如果你想要利用持久連接的優勢，可以把輸出文檔寫入 ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容。
Content- Type：表示后面的文檔屬於什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由於經常要設置 Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType。
Date：當前的GMT時間，例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標准時，換算成本地時間，需要知道用戶所在的時區。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩。
Expires：告訴瀏覽器把回送的資源緩存多長時間，-1或0則是不緩存。
Last-Modified：文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲於指定時間的文檔才會返回，否則返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設置。
Location：這個頭配合302狀態碼使用，用於重定向接收者到一個新URI地址。表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。
Refresh：告訴瀏覽器隔多久刷新一次，以秒計。
Server：服務器通過這個頭告訴瀏覽器服務器的類型。Server響應頭包含處理請求的原始服務器的軟件信息。此域能包含多個產品標識和注釋，產品標識一般按照重要性排序。Servlet一般不設置這個值，而是由Web服務器自己設置。
Set-Cookie：設置和頁面關聯的Cookie。Servlet不應使用response.setHeader(“Set-Cookie”, …)，而是應使用HttpServletResponse提供的專用方法addCookie。
Transfer-Encoding：告訴瀏覽器數據的傳送格式。
WWW-Authenticate：客戶應該在Authorization頭中提供什么類型的授權信息?在包含401(Unauthorized)狀態行的應答中這個頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=\”executives\”“)。注意Servlet一般不進行這方面的處理，而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問。
注：設置應答頭最常用的方法是HttpServletResponse的setHeader，該方法有兩個參數，分別表示應答頭的名字和值。和設置狀態代碼相似，設置應答頭應該在發送任何文檔內容之前進行。
setDateHeader方法和setIntHeadr方法專門用來設置包含日期和整數值的應答頭，前者避免了把Java時間轉換為GMT時間字符串的麻煩，后者則避免了把整數轉換為字符串的麻煩。
HttpServletResponse還提供了許多設置 VIP 響應頭的方法，因為它們被使用的頻率實在太高了：
setContentType：設置Content-Type頭。大多數Servlet都要用到這個方法。
setContentLength：設置Content-Length頭。對於支持持久HTTP連接的瀏覽器來說，這個函數是很有用的。
addCookie：設置一個Cookie(Servlet API中沒有setCookie方法，因為應答往往包含多個Set-Cookie頭)。
-空行
-響應體
響應體就是響應的消息體，如果是純數據就是返回純數據，如果請求的是HTML頁面，那么返回的就是HTML代碼，如果是JS就是JS代碼，如此之類。
除上述常見的請求頭與響應頭外，還有一些請求與響應均可以使用的頭部字段稱為通用頭。
通用頭
通用頭域包含請求和響應消息都支持的頭域，通用頭域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支持此擴展，如果存在不支持的通用頭域，一般將會作為實體頭域處理。下面簡單介紹幾個通用頭域。
常見通用頭含義：
Cache-Control：指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置 Cache-Control並不會修改另一個消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下：
Public指示響應可被任何緩存區緩存。 Private指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。這允許服務器僅僅描述當用戶的部分響應消息，此響應消息對於其他用戶的請求無效。 no-cache指示請求或響應消息不能緩存 no-store用於防止重要的信息被無意的發布。在請求消息中發送將使得請求和響應消息都不使用緩存。 max-age指示客戶機可以接收生存期不大於指定時間(以秒為單位)的響應。 min-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。 max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值，那么客戶機可以接收超出超時期指定值之內的響應消息。
Date：表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標准時，換算成本地時間，需要知道用戶所在的時區。
Pragma：用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache-Control:no-cache相同。
最后一個實體頭：
實體頭
實體標頭是描述消息正文內容的HTTP標頭。實體標頭用於HTTP請求和響應中。頭狀Content-Length，Content-Language，Content-Encoding是實體頭。
即使實體標頭既不是請求標頭也不是響應標頭，它們通常也包含在這些術語中。
在以下示例中，Content-Length是實體頭，而Host和User-Agent是請求頭。
POST /myform.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Content-Length: 128實體頭也是請求頭部的一部分，只是因為它們是用來描述報文正文內容的標頭，所以被單獨列了一個分類，本質上與其它類型的頭部字段沒有區別。
頭部就是用來為報文附加額外的控制信息的，它們想要發揮作用需要基於服務端和客戶端對它們的支持，本質上只是通信雙方約定好的控制位。我們需要着重了解的是主流的服務端與客戶端常用的那些控制位，以此可以窺探雙方通信的過程，使我們對整個通信的流程有更深的把控。