Http簡介
HTTP（Hypertext Transfer Protocol）超文本傳輸協議，從1990年開始在WWW上廣泛應用，目前版本1.1。
HTTP是應用層的協議，當你上網瀏覽網頁的時候，瀏覽器和Web服務器之間就會通過HTTP在Internet上進行數據的發送和接收。
HTTP是一個基於 請求/響應 模式的、無狀態的協議。
Http URL
格式：http://host[“:”port][abs_path]
註釋：
http:通過HTTP協議定位網絡資源
host:合法的Internet主機域名或IP地址（以點分十進制的格式表示）
port:指定端口號，擁有被請求資源的服務器主機監聽該端口的TCP連接，若爲空，或者沒有給出，則使用缺省的端口80
abs_path：指定請求資源的URI(Uniform Resource Identifier,統一資源標誌符)，如果URL中沒有給出abs_path,那麼當它作爲請求URI時，必須以“/”的形式
給出。通常這個工作瀏覽器幫助我們完成
（URI:指定構成Web資源的字符串的各個不同部分的符號結構。URL是一種特殊類型的URI,包含查找某個資源的足夠信息。）
Http請求
包括：
請求行：Method Request_URI HTTP-Version (CRLF)
如：GET /ajax.html HTTP/1.1 (CRLF)
消息報頭
請求正文
詳細解釋：
Method:請求方法
具體請參看下表：
（1） Get
（2） Post
POST方法向母的服務器發出請求，要求服務器接受附加在請求後面的數據。POST方法在表單提交的時候用得比較多
例:
(3) Head
Head方法只請求消息報頭，而不是完整的內容。對於Head請求的迴應部分來說，它的http頭部中包含的信息與通過GET請求得到的信息是相同的
注意：在html文檔中，書寫get和post，大小寫都可以，但http協議中的GET和POST只能是大寫。
Request_URI：統一資源標誌符，標誌了要請求的資源
HTTP-Version：請求的http協議版本
CRTF:回車換行
消息報頭；
請求正文。
Http響應
組成部分：
狀態行:HTTP-Version Status-Code Reason-Phrase CRLF
消息報頭；
響應正文。
詳細解釋：
HTTP-Version:服務器http協議版本
Status-Code:服務器發回的響應代碼
狀態代碼由3位數字組成，表示請求是否被理解或滿足
狀態代碼的第一個數字定義響應的類別，後兩位數字沒有具體分類。第一個數字的5種分類：
- 1xx : 指示信息—表示請求已接收
- 2xx ：成功—請求已經被成功接收、理解、接受
- 3xx ：重定向—要完成請求必須進行更進一步的操作
- 4xx : 客戶端錯誤—請求有語法錯誤或請求無法實現
- 5xx : 服務器錯誤—服務器未能實現合法的請求
詳細說明如下：
Reason-Phrase：狀態代碼的文本描述
狀態描述給出了關於狀態代碼的簡短的文本描述
CRLF:回車換行
如：HTTP/1.1 200 OK (CRLF)
消息報頭；
響應正文。
HTTP消息
HTTP消息由客戶端到服務器的請求和服務器到客戶端的響應組成。請求消息和響應消息都是由 開始行，消息報頭（可選的），空行（只用CRLF的行），消息正文（可選的）組成。
對於請求消息，開始行就是請求行，對於響應消息，開始行就是狀態行。
請求消息的例子
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/x-shockjwave-flash,application/vnd.ms-excel.application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2005 11:21:52 GMT (CRLF)
If-None-Match:W/’’80b1a4c018f3c41:8317” (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE 6.0;Windows NT 5.0) (CRLF)
Host:www.winsunlight.com (CRLF)
Connection:Keep-Alive (CRLF)
CRLF
響應消息例子：
HTTP/1.1 200 OK (CRLF)
Connection-Length:2218 (CRLF)
Content-Type:text/html (CRLF)
Last-Modified:wed,05 Jan 2005 11:21:52 GMT (CRLF)
Accept-Ranges:bytes (CRLF)
ETag:W/’’ 80b1a4c018f3c41:831d’’ (CRLF)
Server:Microsoft-IIS/6.0 (CRLF)
Date:Wed,05 Jan 2006 05:48:54 GMT (CRLF)
CRLF
<html>
<head>
<title>
This is the form page.
</title>
</head>
<body>
…（省略）
</body>
<html>
HTTP消息報頭
包括:
普通報頭
請求報頭
響應報頭
實體報頭
每一個報頭域都是由名字+“:”+空格+值組成，消息報頭域的名字是大小寫無關的。
詳細解釋：
常用普通報頭：
在普通報頭中，有少數報頭域應用於所有的請求和響應信息，但並不用於被傳輸的實體，這些報頭域只用於傳輸的消息
Cache-Control
Cache-Control普通報頭域用於指定緩存指令，該指令將被 請求/響應 鏈中所有的緩存機制所遵循。這些指令將覆蓋缺省的緩存規則。緩存指令是單向的，在請求中出現的緩存指令，並不意味着在響應中也會出現。此外，在一個消息（請求或響應消息）中指定的緩存指令，並不會影響另一個消息處理的緩衝機制。
注意：Cache-Control普通報頭域是在HTTP1.1中新加的，HTTP1.0使用的類似報頭域爲Pragma。
緩存指令分爲請求時的緩存指令和響應時的緩存指令。請求時的緩存指令包括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、s-maxage。其中最常用的是no-cache,用於指示請求或響應消息不能緩存。
例如：爲了指示IE瀏覽器（客戶端）不要緩存頁面，服務器端的JSP程序可以編寫下面的代碼：
Response.setHeader(“Cache-Control”,“no-cache”);
這句代碼將在發送的響應消息中設置普通報頭域：Cache-Control:no-cache。
Date
Date普通報頭域表示消息產生的日期和時間，可以用於HTTP響應中，也可以用於HTPP請求中。作爲服務器端，應該總是在所有的響應中包含Date報頭域。作爲客戶端只有在發送的消息中包含了消息正文的時候，才應該發送Date報頭域，例如，在POST請求的時候。
Connection
Connection普通報頭域允許發送者制定連接的選項。例如制定連接是持續的，或者指定“close”選項，通知服務器，在響應完成後，關閉連接。
Pragma
Pragma普通報頭域被用於包含特定實現的指令，這些指令可能會應用到 請求/響應鏈中的任何一個接受者。最常用的是Pragma:no-cache。在HTTP1.1中，它的含義和Cache-Control:no-cache相同。有時候，我們不知道客戶端瀏覽器是否支持HTTP1.1,可以同時使用Pragma和Cache-Contrl報頭域，來指示客戶端不要緩存響應消息，如下：
Response.setHeader(“Pragma”,“no-cache”);
Response.setHeader(“Cache-Control”,“no-cache”);
常用請求報頭
請求報頭允許客戶端向服務器端傳遞該請求的附加信息以及客戶端自身的信息。
Accept
Accept請求報頭域用於指定客戶端接受哪些類型的信息。例如：Accept
:image/gif,表明客戶端希望接受GIF圖像格式的資源；Accept：text/html,表明客戶端希望接受html文本。
Accept-Charset
Accept-Charset請求報頭域用於指定客戶端接受的字符集。例如：Accept-Charset
:iso-8859-1,gb2312。
如果在請求消息中沒有設置這和域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding請求報頭域類似於Accept,但是它是用於指定可接受的內容編碼。例如：Accept-Encoding：gzip,deflate。如果請求消息中沒有設置這個域，服務器假定客戶端對各種內容編碼都可以接受。
Accept-Language
Accept-Language請求報頭域類似於Accept,但是它是用於指定一種自然語言。例如：Accept-Language： zh-cn。如果請求消息中沒有設置這個域，服務器假定客戶端對各種語言都可接受。
Authorization
Authorization請求報頭域主要用於證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到服務器的響應代碼爲401（未授權），可以發送一個包含Authorization
請求報頭域的請求，要求服務器對其進行驗證。
Host
Host請求報頭域主要用於指定被請求資源的Internet主機和端口號，它通常是從HTTP URL中提取出來的。
例如：我們在瀏覽器的地址欄輸入：
http://www.sunxin.org/index.html
瀏覽器發送的請求消息中，就會包含Host請求報頭域，如下：
Host:www.sunxin.org
後面沒有跟端口號，表明使用的是缺省端口號80
要注意的是，在發送HTTP請求的時候，這個報頭域是必須的。
User-Agent
我們上網登錄論壇的時候，往往會看到一些歡迎信息，其中列出了你的操作系統的名稱和版本，你所用的瀏覽器的名稱和版本。服務器應用程序就是從User-Agent這個請求報頭域中獲取到的這些信息。User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽器和其它屬性告訴服務器。不過，這個報頭域不是必須的，如果我們自己編寫一個瀏覽器，不使用User-Agent請求報頭域，那麼服務器端就無法得知我們的信息了。
常用響應報頭
響應報頭允許服務器傳遞不能放在狀態行中的附加響應信息，以及關於服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息。
Location
Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不在原先的位置，爲了讓客戶端重定向到這個頁面新的位置，服務器端可以發回Location響應報頭域。這種情況還經常發生在更換域名的時候，在舊的域名所對應的服務器上保留一個文件，然後使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源。當我們在JSP中使用重定向語句的時候，服務器端向客戶端發回的響應報頭中，就會有Location響應報頭域。下面是Location響應報頭域的一個例子：
Location:http://www.sunxin.org
Server
Server響應報頭域包含了服務器用來處理請求的軟件信息。它和User-Agent請求報頭域是相對應的，前者發送服務器端軟件的信息，後者發送客戶端軟件（瀏覽器）和操作系統的信息。
下面是Server響應報頭域的一個例子：
Server:Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate響應報頭域必須被包含在401（未授權的）響應消息中，這個報頭域和前面講到的Authorization請求報頭域是相關的，當客戶端收到401響應消息，就要決定是否請求服務器對其進行驗證。如果要求服務器對其進行驗證，就可以發送一個包含了Authorization報頭域的請求。下面是WWW-Authenticate響應報頭域的一個例子：
WWW-Authenticate:Basic realm=“Basic Auth Test!”
從這個響應報頭域，可以知道服務器端對我們所請求的資源採用的是基本驗證機制。
實體報頭
請求和響應消息都可以傳送一個實體。一個實體由實體報頭域和實體正文組成，在大多數情況下，實體正文就是請求消息中的請求正文或者響應消息中的響應正文。但是在發送時，並不是說實體報頭域和實體正文要在一起發送，例如：有些響應可以只包含實體報頭域。實體就好像我們寫的書信，在信中，我們可以寫上標題，加上頁號等，這部分就相當於是實體報頭域，而我們所寫的書信的內容，就相當於是實體正文。前面所講的普通報頭、請求報頭，響應報頭我們可以看成是寫在信封上的郵編、接收者、發送者等內容。
實體報頭定義了關於實體正文（例如：有實體無正文）和請求所標識的資源的元信息。
常用的實體報頭
Content-Encoding
Content-Encoding實體報頭域被用作媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，因而要獲得Content-Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding主要用於記錄文檔的壓縮方法，下面是它的一個例子：
Content-Encoding：gzip
如果一個實體正文采用了編碼方式存儲，在使用之前就必須進行解碼。
Content-Language
Content-Language實體報頭域描述了資源所用的自然語言。Content-Language允許用戶遵照自身的首選語言來識別和區分實體。如果這和實體內容僅僅打算提供給丹麥的閱讀者，那麼可以按照如下的方式設置這個實體報頭域：
Content-Language：da
如果沒有指定Content-Language報頭域，那麼實體內容將提供給所欲語言的閱讀者。
Content-Length
Content-Length實體報頭域用於指明實體正文的長度，以字節方式存儲的十進制數字來表示，也就是一個數字字符佔一個字節，用其對應的ASCII碼存儲傳輸。
要注意的是，這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。
Content-Type
Content-Type實體報頭域用於指明發送給接收者的實體正文的媒體類型。例如：
Content-Type：text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified
Last-Modified實體報頭域用於指示資源最後的修改日期及時間。
Expires
Expires實體報頭域給出響應過期的日期和時間。通常，代理服務器或瀏覽器會緩存一些頁面，當用戶再次訪問這些頁面時，直接從緩存中加載並顯示給用戶，這樣縮短了響應的時間，減少了服務器的負載。爲了讓代理服務器或瀏覽器在一段時間後更新頁面，我們可以使用Expires實體報頭域指定頁面過期的時間。當用戶又一次訪問頁面時，如果Expires
報頭域給出的日期和時間比Date普通報頭域給出的日期和時間要早（或相同），那麼代理服務器或瀏覽器就不會再使用緩存頁面，而是從服務器請求更新的頁面。不過要注意，即使頁面過期了，也並不意味着服務器上的原始資源在此時間之前或之後發生了改變。
Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期和格式，例如：
Expires：Thu,15 Sep 2005 16:00:00 GMT
HTTP1.1的客戶端和緩存必須將其它非法的日期格式（也包括0）看作已經過期。例如，爲了讓瀏覽器不要緩存頁面，我們也可以利用Expires實體報頭域，設置它的值爲0，如下：
Response.setDateHeader(“Expires”,0);
總結
這裏介紹了HTTP協議實現的一些細節，包括HTTP請求與HTTP響應的組成，重點介紹了HTTP消息報頭，其中請求報頭只能用於HTTP請求中，響應報頭只能用於HTTp響應中，普通報頭中有些報頭域既可以用於HTTP請求中，也可以用於HTTP響應中，實體報頭定義了關於實體正文和請求所標識的資源的元信息。
如果想要更深入地學習HTTP協議，可以參看RFC2616。RFC(Request For Comments,請求註釋)，即Internet標準草案。Internet上有各種各樣的技術，需要遵循一定的標準，這些標準以RFC文件的形式在Internet上發佈。每個RFC文件都有一個序列號，討論一個有關Internet技術的主題。大家可以在http://www.ietf.org/rfc 上找到RFC2616文件，或者在 搜索引擎上搜索“RFC2616”關鍵字，查找此文件。建議大家，如果不是要從事HTTP協議的相關開發，沒有必要去看RFC文檔。
此文章只是作爲資料查看，Word文檔大家可以到http://download.csdn.net/source/2451850下載，如有問題請留言。謝謝！
聲明：文字內容來源於孫鑫老師《HTTP協議詳解》視頻資料