HTTP是一種協議，允許web服務器和瀏覽器通過互聯網進行來發送和接受數據。它是一種請求和響應協議。
客戶端請求一個文件而服務器響應請求。HTTP使用可靠的TCP連接–TCP默認使用80端口。第一個HTTP版是HTTP/0.9，然後被HTTP/1.0所替代。正在取代HTTP/1.0的是當前版本HTTP/1.1，它定義於徵求意見文檔(RFC) 2616，可以從http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf下載。 注意：本節涵蓋的HTTP 1.1只是簡略的幫助你理解web服務器應用發送的消息。假如你對更多詳細信息感興趣，請閱讀RFC 2616。 在HTTP中，始終都是客戶端通過建立連接和發送一個HTTP請求從而開啓一個事務。web服務器不需要聯繫客戶端或者對客戶端做一個回調連接。無論是客戶端或者服務器都可以提前終止連接。舉例來說，當你正在使用一個web瀏覽器的時候，可以通過點擊瀏覽器上的停止按鈕來停止一個文件的下載進程，從而有效的關閉與web服務器的HTTP連接。
1.HTTP請求：
HTTP請求報文由3部分組成（請求行+請求頭+請求體）：
1.方法—統一資源標識符(URI)—協議/版本
2.請求的頭部
3.主體內容
下面是一個HTTP請求的例子：
POST /examples/default.jsp HTTP/1.1
Accept: text/plain; text/html
Accept-Language: en-gb
Connection: Keep-Alive
Host: localhost
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Content-Length: 33
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
lastName=Franks&firstName=Michael
方法—統一資源標識符(URI)—協議/版本出現在請求的第一行。 POST /examples/default.jsp HTTP/1.1
這裏POST是請求方法，/examples/default.jsp是URI，而HTTP/1.1是協議/版本部分。
每個HTTP請求可以使用HTTP標準裏邊提到的多種方法之一。HTTP 1.1支持7種類型的請求：GET, POST, HEAD, OPTIONS, PUT, DELETE和TRACE。GET和POST在互聯網應用裏邊最普遍使用的。
URI完全指明瞭一個互聯網資源。URI通常是相對服務器的根目錄解釋的。因此，始終一斜線/開頭。統一資源定位器(URL)其實是一種URI(查看http://www.ietf.org/rfc/rfc2396.txt)
來的。該協議版本代表了正在使用的HTTP協議的版本。
請求的頭部包含了關於客戶端環境和請求的主體內容的有用信息。例如它可能包括瀏覽器設置的語言，主體內容的長度等等。每個頭部通過一個回車換行符(CRLF)來分隔的。
對於HTTP請求格式來說，頭部和主體內容之間有一個回車換行符(CRLF)是相當重要的。CRLF告訴HTTP服務器主體內容是在什麼地方開始的。在一些互聯網編程書籍中，CRLF還被認爲是HTTP請求的第四部分。
在前面一個HTTP請求中，主體內容只不過是下面一行：
此處空格
lastName=Franks&firstName=Michael 實體內容在一個典型的HTTP請求中可以很容易的變得更長。
圖片分析（本圖摘自其它地方）：
請求行：
| ①是請求方法，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”的方式傳遞請求參數。 |
請求的詳細分析：
常見的請求頭字段屬性含義：
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
對緩存進行控制，如一個請求希望響應返回的內容在客戶端要被緩存一年，或不希望被緩存就可以通過這個報文頭達到目的。
更多的請求頭屬性參見：請求頭屬性大全
2.HTTP響應：
類似於HTTP請求，一個HTTP響應也包括三個組成部分：
1.方法—統一資源標識符(URI)—協議/版本
2.響應的頭部
3.主體內容
HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Mon, 5 Jan 2004 13:13:33 GMT
Content-Type: text/html
Last-Modified: Mon, 5 Jan 2004 13:13:12 GMT
Content-Length: 112
<html>
<head>
<title>HTTP Response Example</title>
</head>
<body>
Welcome to Brainy Software
</body>
</html>響應頭部的第一行類似於請求頭部的第一行。第一行告訴你該協議使用HTTP 1.1，請求成功(200=成功)，表示一切都運行良好。 響應頭部和請求頭部類似，也包括很多有用的信息。響應的主體內容是響應本身的HTML內容。頭部和主體內容通過CRLF分隔開來。
圖片分析（本圖摘自其它地方）：
響應行：
| ①報文協議及版本； |
| ②狀態碼及狀態描述； |
響應頭：
| ③響應報文頭，也是由多個屬性組成； |
響應體：
| ④響應報文體，即我們真正要的“數據信息”（json、xml、html等） |
響應狀態碼：
和請求報文相比，響應報文多了一個“響應狀態碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結果。
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); // 必須執行這一句 輸出到客戶端
要
更多的響應頭屬性信息參考：響應頭信息大全