HTTP協議
1. 簡介
HTTP協議（Hyper Text Transfer Protocol，超文本傳輸協議）,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP基於TCP/IP通信協議來傳遞數據。
HTTP基於客戶端/服務端（C/S）架構模型，通過一個可靠的鏈接來交換信息，是一個無狀態的請求/響應協議。
2. 特點
（1）HTTP是無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
（2）HTTP是媒體獨立的：只有客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用合適的MIME-type內容類型。
（3）HTTP是無狀態：無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
HTTP請求報文
HTTP請求報文由3部分組成（請求行+請求頭+請求體）
請求行：
①是請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
②為請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL。
③是協議名稱及版本號。
請求頭：
④是HTTP的報文頭，報文頭包含若干個屬性，格式為“屬性名:屬性值”，服務端據此獲取客戶端的信息。
與緩存相關的規則信息，均包含在header中
請求體：
⑤是報文體，它將一個頁面表單中的組件值通過param1=value1¶m2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數的數據。不但報文體可以傳遞請求參數，請求URL也可以通過類似於“/chapter15/user.html? param1=value1¶m2=value2”的方式傳遞請求參數。
HTTP請求報文頭屬性
Accept
請求報文可通過一個“Accept”報文頭屬性告訴服務端 客戶端接受什么類型的響應。
如下報文頭相當於告訴服務端，俺客戶端能夠接受的響應類型僅為純文本數據啊，你丫別發其它什么圖片啊，視頻啊過來，那樣我會歇菜的~~~
Accept:text/plain
Accept屬性的值可以為一個或多個MIME類型的值（描述消息內容類型的因特網標准， 消息能包含文本、圖像、音頻、視頻以及其他應用程序專用的數據）
cookie
客戶端的Cookie就是通過這個報文頭屬性傳給服務端的哦！如下所示：
Cookie: $Version=1; Skin=new;jsessionid=5F4771183629C9834F8382E23
服務端是怎么知道客戶端的多個請求是隸屬於一個Session呢？注意到后台的那個jsessionid = 5F4771183629C9834F8382E23木有？原來就是通過HTTP請求報文頭的Cookie屬性的jsessionid的值關聯起來的！（當然也可以通過重寫URL的方式將會話ID附帶在每個URL的后面哦）。
Referer
表示這個請求是從哪個URL過來的，假如你通過google搜索出一個商家的廣告頁面，你對這個廣告頁面感興趣，鼠標一點發送一個請求報文到商家的網站，這個請求報文的Referer報文頭屬性值就是http://www.google.com。
Cache-Control
對緩存進行控制，如一個請求希望響應返回的內容在客戶端要被緩存一年，或不希望被緩存就可以通過這個報文頭達到目的。
HTTP響應報文
HTTP的響應報文也由三部分組成（響應行+響應頭+響應體）
響應行：
①報文協議及版本；
②狀態碼及狀態描述；
響應頭：
③響應報文頭，也是由多個屬性組成；
響應體：
④響應報文體，即我們真正要的“干貨”
響應狀態碼
和請求報文相比，響應報文多了一個“響應狀態碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結果。
HTTP的響應狀態碼由5段組成：
- 1xx 消息，一般是告訴客戶端，請求已經收到了，正在處理，別急...
- 2xx 處理成功，一般表示：請求收悉、我明白你要的、請求已受理、已經處理完成等信息.
- 3xx 重定向到其它地方。它讓客戶端再發起一個請求以完成整個處理。
- 4xx 處理發生錯誤，責任在客戶端，如客戶端的請求一個不存在的資源，客戶端未被授權，禁止訪問等。
- 5xx 處理發生錯誤，責任在服務端，如服務端拋出異常，路由出錯，HTTP版本不支持等。
以下是幾個常見的狀態碼：
200 OK
你最希望看到的，即處理成功！
303 See Other
我把你redirect到其它的頁面，目標的URL通過響應報文頭的Location告訴你。
304 Not Modified
告訴客戶端，你請求的這個資源至你上次取得后，並沒有更改，你直接用你本地的緩存吧，我很忙哦，你能不能少來煩我啊！
404 Not Found
你最不希望看到的，即找不到頁面。如你在google上找到一個頁面，點擊這個鏈接返回404，表示這個頁面已經被網站刪除了，google那邊的記錄只是美好的回憶。
500 Internal Server Error
看到這個錯誤，你就應該查查服務端的日志了，肯定拋出了一堆異常，別睡了，起來改BUG去吧！
◆200 (OK): 找到了該資源，並且一切正常。
◆302/307：臨時重定向，指出請求的文檔已被臨時移動到別處, 此文檔的新的url在location響應頭中給出
◆304 (NOT MODIFIED): 該資源在上次請求之后沒有任何修改。這通常用於瀏覽器的緩存機制。
◆401 (UNAUTHORIZED): 客戶端無權訪問該資源。這通常會使得瀏覽器要求用戶輸入用戶名和密碼，以登錄到服務器。
◆403 (FORBIDDEN): 客戶端未能獲得授權。這通常是在401之后輸入了不正確的用戶名或密碼。
◆404 (NOT FOUND): 在指定的位置不存在所申請的資源。
常見的HTTP響應報文頭屬性
Cache-Control
響應輸出到客戶端后，服務端通過該報文頭屬告訴客戶端如何控制響應內容的緩存。
常見的取值有private、public、no-cache、max-age，no-store，默認為private。
private: 客戶端可以緩存
public: 客戶端和代理服務器都可緩存（前端的同學，可以認為public和private是一樣的）
max-age=xxx: 緩存的內容將在 xxx 秒后失效
no-cache: 需要使用對比緩存來驗證緩存數據
no-store: 所有內容都不會緩存
默認為private，緩存時間為31536000秒（365天）也就是說，在365天內再次請求這條數據，都會直接獲取緩存數據庫中的數據，直接使用。
ETag
一個代表響應服務端資源（如頁面）版本的報文頭屬性，如果某個服務端資源發生變化了，這個ETag就會相應發生變化。它是Cache-Control的有益補充，可以讓客戶端“更智能”地處理什么時候要從服務端取資源，什么時候可以直接從緩存中返回響應。
Location
我們在JSP中讓頁面Redirect到一個某個A頁面中，其實是讓客戶端再發一個請求到A頁面，這個需要Redirect到的A頁面的URL，其實就是通過響應報文頭的Location屬性告知客戶端的，如下的報文頭屬性，將使客戶端redirect到iteye的首頁中：
Location: http://www.iteye.com
Set-Cookie
服務端可以設置客戶端的Cookie，其原理就是通過這個響應報文頭屬性實現的：
Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
cookie機制：
客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。
Cookie的maxAge決定着Cookie的有效期，單位為秒（Second）。Cookie中通過getMaxAge()方法與setMaxAge(int maxAge)方法來讀寫maxAge屬性。
如果maxAge屬性為正數，則表示該Cookie會在maxAge秒之后自動失效。
如果maxAge為負數，則表示該Cookie僅在本瀏覽器窗口以及本窗口打開的子窗口內有效，關閉窗口后該Cookie即失效。
如果maxAge為0，則表示刪除該Cookie。
Cookie並不提供修改、刪除操作。如果要修改某個Cookie，只需要新建一個同名的Cookie，添加到response中覆蓋原來的Cookie。
如果要刪除某個Cookie，只需要新建一個同名的Cookie，並將maxAge設置為0，並添加到response中覆蓋原來的Cookie。
Cookie cookie = new Cookie("username","helloweenvsfei"); // 新建Cookie
cookie.setMaxAge(0); // 設置生命周期為0，不能為負數
response.addCookie(cookie); // 必須執行這一句 輸出到客戶端