本系列下載地址：http://www.tkk7.com/Files/amigoxie/http協議學習系列-阿蜜果.rar
  上一篇：基礎概念篇
  下一篇：深入了解篇

                                        蜜果私塾：http協議學習系列
                                 ——協議詳解篇

文：阿蜜果

日期：2009-12-2

2. 協議詳解篇

2.1 HTTP/1.0和HTTP/1.1的比較

RFC 1945定義了HTTP/1.0版本，RFC 2616定義了HTTP/1.1版本。

筆者在blog上提供了這兩個RFC中文版的下載地址。

RFC1945下載地址：

http://www.tkk7.com/Files/amigoxie/RFC1945（HTTP）中文版.rar

RFC2616下載地址：

http://www.tkk7.com/Files/amigoxie/RFC2616（HTTP）中文版.rar

2.1.1建立連接方面

HTTP/1.0 每次請求都需要建立新的TCP連接，連接不能復用。HTTP/1.1 新的請求可以在上次請求建立的TCP連接之上發送，連接可以復用。優點是減少重復進行TCP三次握手的開銷，提高效率。

注意：在同一個TCP連接中，新的請求需要等上次請求收到響應后，才能發送。

2.1.2 Host域

HTTP1.1在Request消息頭里頭多了一個Host域, HTTP1.0則沒有這個域。

Eg：

    可能HTTP1.0的時候認為，建立TCP連接的時候已經指定了IP地址，這個IP地址上只有一個host。

2.1.3日期時間戳

(接收方向)

無論是HTTP1.0還是HTTP1.1，都要能解析下面三種date/time stamp：

       (發送方向)

HTTP1.0要求不能生成第三種asctime格式的date/time stamp；

HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。

2.1.4狀態響應碼

狀態響應碼100 (Continue) 狀態代碼的使用，允許客戶端在發request消息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發request body。

客戶端在Request頭部中包含

       Server看到之后呢如果回100 (Continue) 這個狀態代碼，客戶端就繼續發request body。這個是HTTP1.1才有的。

另外在HTTP/1.1中還增加了101、203、205等等性狀態響應碼

2.1.5請求方式

HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方法.

       Method         = "OPTIONS"                ; Section 9.2

                      | "GET"                    ; Section 9.3

                      | "HEAD"                   ; Section 9.4

                      | "POST"                   ; Section 9.5

                      | "PUT"                    ; Section 9.6

                      | "DELETE"                 ; Section 9.7

                      | "TRACE"                  ; Section 9.8

                      | "CONNECT"                ; Section 9.9

                      | extension-method

       extension-method = token

2.2 HTTP請求消息

2.2.1請求消息格式

請求消息格式如下所示：

請求行

通用信息頭|請求頭|實體頭

CRLF(回車換行)

實體內容

其中“請求行”為：請求行 = 方法 [空格] 請求URI [空格] 版本號 [回車換行]

請求行實例：

Eg1：

       Eg2：

POST http://192.168.2.217:8080/index.jsp HTTP/1.1

HTTP請求消息實例：

2.2.2請求方法

       HTTP的請求方法包括如下幾種：

q      GET

q      POST

q      HEAD

q      PUT

q      DELETE

q      OPTIONS

q      TRACE

q      CONNECT

2.3 HTTP響應消息

2.3.1響應消息格式

HTTP響應消息的格式如下所示：

狀態行

通用信息頭|響應頭|實體頭

CRLF

實體內容

其中：狀態行 = 版本號 [空格] 狀態碼 [空格] 原因 [回車換行]

狀態行舉例：

Eg1：

      Eg2：

     HTTP響應消息實例如下所示：

2.3.2 http的狀態響應碼

2.3.2.1  1**：請求收到，繼續處理

100——客戶必須繼續發出請求

101——客戶要求服務器根據請求轉換HTTP協議版本

2.3.2.2  2**：操作成功收到，分析、接受

200——交易成功
201——提示知道新文件的URL

202——接受和處理、但處理未完成

203——返回信息不確定或不完整

204——請求收到，但返回信息為空

205——服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件

206——服務器已經完成了部分用戶的GET請求

2.3.2.3  3**：完成此請求必須進一步處理

300——請求的資源可在多處得到

301——刪除請求數據

302——在其他地址發現了請求數據

303——建議客戶訪問其他URL或訪問方式

304——客戶端已經執行了GET，但文件未變化

305——請求的資源必須從服務器指定的地址得到

306——前一版本HTTP中使用的代碼，現行版本中不再使用

307——申明請求的資源臨時性刪除

2.3.2.4  4**：請求包含一個錯誤語法或不能完成

400——錯誤請求，如語法錯誤

401——未授權

HTTP 401.1 - 未授權：登錄失敗

　　HTTP 401.2 - 未授權：服務器配置問題導致登錄失敗

　　HTTP 401.3 - ACL 禁止訪問資源

　　HTTP 401.4 - 未授權：授權被篩選器拒絕

HTTP 401.5 - 未授權：ISAPI 或 CGI 授權失敗

402——保留有效ChargeTo頭響應

403——禁止訪問

HTTP 403.1 禁止訪問：禁止可執行訪問

　　HTTP 403.2 - 禁止訪問：禁止讀訪問

　　HTTP 403.3 - 禁止訪問：禁止寫訪問

　　HTTP 403.4 - 禁止訪問：要求 SSL

　　HTTP 403.5 - 禁止訪問：要求 SSL 128

　　HTTP 403.6 - 禁止訪問：IP 地址被拒絕

　　HTTP 403.7 - 禁止訪問：要求客戶證書

　　HTTP 403.8 - 禁止訪問：禁止站點訪問

　　HTTP 403.9 - 禁止訪問：連接的用戶過多

　　HTTP 403.10 - 禁止訪問：配置無效

　　HTTP 403.11 - 禁止訪問：密碼更改

　　HTTP 403.12 - 禁止訪問：映射器拒絕訪問

　　HTTP 403.13 - 禁止訪問：客戶證書已被吊銷

　　HTTP 403.15 - 禁止訪問：客戶訪問許可過多

　　HTTP 403.16 - 禁止訪問：客戶證書不可信或者無效

HTTP 403.17 - 禁止訪問：客戶證書已經到期或者尚未生效

404——沒有發現文件、查詢或URl

405——用戶在Request-Line字段定義的方法不允許

406——根據用戶發送的Accept拖，請求資源不可訪問

407——類似401，用戶必須首先在代理服務器上得到授權

408——客戶端沒有在用戶指定的餓時間內完成請求

409——對當前資源狀態，請求不能完成

410——服務器上不再有此資源且無進一步的參考地址

411——服務器拒絕用戶定義的Content-Length屬性請求

412——一個或多個請求頭字段在當前請求中錯誤

413——請求的資源大于服務器允許的大小

414——請求的資源URL長于服務器允許的長度

415——請求資源不支持請求項目格式

416——請求中包含Range請求頭字段，在當前請求資源范圍內沒有range指示值，請求也不包含If-Range請求頭字段

417——服務器不滿足請求Expect頭字段指定的期望值，如果是代理服務器，可能是下一級服務器不能滿足請求長。

2.3.2.5  5**：服務器執行一個完全有效請求失敗

　　HTTP 500 - 內部服務器錯誤

　　HTTP 500.100 - 內部服務器錯誤 - ASP 錯誤

　　HTTP 500-11 服務器關閉

　　HTTP 500-12 應用程序重新啟動

　　HTTP 500-13 - 服務器太忙

　　HTTP 500-14 - 應用程序無效

　　HTTP 500-15 - 不允許請求 global.asa

　　Error 501 - 未實現

HTTP 502 - 網關錯誤

2.4 使用telnet進行http測試

       在Windows下，可使用命令窗口進行http簡單測試。

       輸入cmd進入命令窗口，在命令行鍵入如下命令后按回車：

       而后在窗口中按下“Ctrl+]”后按回車可讓返回結果回顯。

接著開始發請求消息，例如發送如下請求消息請求baidu的首頁消息，使用的HTTP協議為HTTP/1.1：

   注意：copy如上的消息到命令窗口后需要按兩個回車換行才能得到響應的消息，第一個回車換行是在命令后鍵入回車換行，是HTTP協議要求的。第二個是確認輸入，發送請求。

可看到返回了200 OK的消息，如下圖所示：

       可看到，當采用HTTP/1.1時，連接不是在請求結束后就斷開的。若采用HTTP1.0，在命令窗口鍵入：

      此時可以看到請求結束之后馬上斷開。

       讀者還可以嘗試在使用GET或POST等時，帶上頭域信息，例如鍵入如下信息：

2.5 常用的請求方式

       常用的請求方式是GET和POST.

l         GET方式：是以實體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數據產生過程，那么最終要在響應實體中返回的是處理過程的結果所指向的資源，而不是處理過程的描述。

l         POST方式：用來向目的服務器發出請求，要求它接受被附在請求后的實體，并把它當作請求隊列中請求URI所指定資源的附加新子項，Post被設計成用統一的方法實現下列功能：

1：對現有資源的解釋；

2：向電子公告欄、新聞組、郵件列表或類似討論組發信息；

3：提交數據塊；

4：通過附加操作來擴展數據庫 。

從上面描述可以看出，Get是向服務器發索取數據的一種請求；而Post是向服務器提交數據的一種請求，要提交的數據位于信息頭后面的實體中。

GET與POST方法有以下區別：

（1）   在客戶端，Get方式在通過URL提交數據，數據在URL中可以看到；POST方式，數據放置在HTML HEADER內提交。

（2）   GET方式提交的數據最多只能有1024字節，而POST則沒有此限制。

（3）   安全性問題。正如在（1）中提到，使用 Get 的時候，參數會顯示在地址欄上，而 Post 不會。所以，如果這些數據是中文數據而且是非敏感數據，那么使用 get；如果用戶輸入的數據不是中文字符而且包含敏感數據，那么還是使用 post為好。

（4）   安全的和冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。冪等的意味著對同一 URL 的多個請求應該返回同樣的結果。完整的定義并不像看起來那樣嚴格。換句話說，GET 請求一般不應產生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。POST 請求就不那么輕松了。POST 表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 POST 請求實現，因為在注解提交之后站點已經不同了（比方說文章下面出現一條注解）。
 

2.6 請求頭

HTTP最常見的請求頭如下：

l         Accept：瀏覽器可接受的MIME類型；

l         Accept-Charset：瀏覽器可接受的字符集；

l         Accept-Encoding：瀏覽器能夠進行解碼的數據編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間；

l         Accept-Language：瀏覽器所希望的語言種類，當服務器能夠提供一種以上的語言版本時要用到；

l         Authorization：授權信息，通常出現在對服務器發送的WWW-Authenticate頭的應答中；

l         Connection：表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然后在正式寫出內容之前計算它的大?。?/span>

l         Content-Length：表示請求消息正文的長度；

l         Cookie：這是最重要的請求頭信息之一；

l         From：請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它；

l         Host：初始URL中的主機和端口；

l         If-Modified-Since：只有當所請求的內容在指定的日期之后又經過修改才返回它，否則返回304“Not Modified”應答；

l         Pragma：指定“no-cache”值表示服務器必須返回一個刷新后的文檔，即使它是代理服務器而且已經有了頁面的本地拷貝；

l         Referer：包含一個URL，用戶從該URL代表的頁面出發訪問當前請求的頁面。

l         User-Agent：瀏覽器類型，如果Servlet返回的內容與瀏覽器類型有關則該值非常有用；

l         UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操作系統和CPU類型。

2.7 響應頭

HTTP最常見的響應頭如下所示：

l         Allow：服務器支持哪些請求方法（如GET、POST等）；

l         Content-Encoding：文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應該通過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面；

l         Content-Length：表示內容長度。只有當瀏覽器使用持久HTTP連接時才需要這個數據。如果你想要利用持久連接的優勢，可以把輸出文檔寫入ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發送內容；

l         Content-Type： 表示后面的文檔屬于什么MIME類型。Servlet默認為text/plain，但通常需要顯式地指定為text/html。由于經常要設置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentTyep。 可在web.xml文件中配置擴展名和MIME類型的對應關系；

l         Date：當前的GMT時間。你可以用setDateHeader來設置這個頭以避免轉換時間格式的麻煩；

l         Expires：指明應該在什么時候認為文檔已經過期，從而不再緩存它。

l         Last-Modified：文檔的最后改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置；

l         Location：表示客戶應當到哪里去提取文檔。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302；

l         Refresh：表示瀏覽器應該在多少時間之后刷新文檔，以秒計。除了刷新當前文檔之外，你還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。注意這種功能通常是通過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現，這是因為，自動刷新或重定向對于那些不能使用CGI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁面或訪問指定頁面”，而不是“每隔N秒刷新本頁面或訪問指定頁面”。因此，連續刷新要求每次都發送一個Refresh頭，而發送204狀態代碼則可以阻止瀏覽器繼續刷新，不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。注意Refresh頭不屬于HTTP 1.1正式規范的一部分，而是一個擴展，但Netscape和IE都支持它。

2.8實體頭

實體頭用坐實體內容的元信息，描述了實體內容的屬性，包括實體信息類型，長度，壓縮方法，最后一次修改時間，數據有效性等。

l         Allow：GET,POST

l         Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見“2.5 響應頭”；

l         Content-Language：內容的語言類型，例如：zh-cn；

l         Content-Length：表示內容長度，eg：80，可參考“2.5響應頭”；

l         Content-Location：表示客戶應當到哪里去提取文檔，例如：http://www.dfdf.org/dfdf.html，可參考“2.5響應頭”；

l         Content-MD5：MD5 實體的一種MD5摘要，用作校驗和。發送方和接受方都計算MD5摘要，接受方將其計算的值與此頭標中傳遞的值進行比較。Eg1：Content-MD5: <base64 of 128 MD5 digest>。Eg2：dfdfdfdfdfdfdff==；

l         Content-Range：隨部分實體一同發送；標明被插入字節的低位與高位字節偏移，也標明此實體的總長度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898

l         Content-Type：標明發送或者接收的實體的MIME類型。Eg：text/html; charset=GB2312       主類型/子類型；

l         Expires：為0證明不緩存；

l         Last-Modified：WEB 服務器認為對象的最后修改時間，比如文件的最后修改時間，動態頁面的最后產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.

2.8擴展頭

在HTTP消息中，也可以使用一些再HTTP1.1正式規范里沒有定義的頭字段，這些頭字段統稱為自定義的HTTP頭或者擴展頭，他們通常被當作是一種實體頭處理。

現在流行的瀏覽器實際上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等幾個常用的擴展頭字段。

l         Refresh：1;url=http://www.dfdf.org  //過1秒跳轉到指定位置；

l         Content-Disposition：頭字段,可參考“2.5響應頭”；

l         Content-Type：WEB 服務器告訴瀏覽器自己響應的對象的類型。

eg1：Content-Type：application/xml ；

eg2：applicaiton/octet-stream；

Content-Disposition：attachment; filename=aaa.zip。
  附錄：參考資料

《HTTP1.1和HTTP1.0的區別》：

http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx

《HTTP請求（GET和POST區別）和響應》：

http://www.tkk7.com/honeybee/articles/164008.html
 

《HTTP請求頭概述_百度知道》：

http://zhidao.baidu.com/question/32517427.html

《實體頭和擴展頭》：

http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html