版權聲明：本文為部落客原創文章，未經部落客允許不得轉載。
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t0">基礎概念篇</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t1">1 介紹</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t2">2 在TCPIP協定棧中的位置</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t3">3 HTTP的請求響應模型</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t4">4 工作流程</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t5">5 使用Wireshark抓TCPhttp包</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t6">6 頭域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t7">61 host頭域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t8">62 Referer頭域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t9">63 User-Agent頭域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t10">64 Cache-Control頭域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t11">65 Date頭域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t12">7 HTTP的幾個重要概念</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t13">71連接配接Connection</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t14">72消息Message</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t15">73請求Request</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t16">74響應Response</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t17">75資源Resource</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t18">76實體Entity</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t19">77客戶機Client</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t20">78使用者代理UserAgent</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t21">79伺服器Server</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t22">710源伺服器Originserver</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t23">711代理Proxy</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t24">712網關Gateway</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t25">713通道Tunnel</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t26">714緩存Cache</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t27"> 附錄參考資料</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t28">協定詳解篇</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t29">1 HTTP10和HTTP11的比較</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t30">11建立連接配接方面</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t31">12 Host域</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t32">13日期時間戳</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t33">14狀态響應碼</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t34">15請求方式</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t35">2 HTTP請求消息</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t36">21請求消息格式</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t37">22請求方法</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t38">3 HTTP響應消息</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t39">31響應消息格式</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t40">321 1請求收到繼續處理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t41">322 2操作成功收到分析接受</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t42">323 3完成此請求必須進一步處理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t43">324 4請求包含一個錯誤文法或不能完成</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t44">325 5伺服器執行一個完全有效請求失敗</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t45">4 使用telnet進行http測試</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t46">6 請求頭</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t47">7 響應頭</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t48">8實體頭</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t49">8擴充頭</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t50">1 Cookie和Session</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t51">11兩者比較</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t52">12 Session機制</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t53">16 Session的實作方式</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t54">161 使用Cookie來實作</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t55">162 使用URL回顯來實作</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t56">13在J2EE項目中Session失效的幾種情況</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t57">14與Cookie相關的HTTP擴充頭</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t58">15Cookie的流程</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t59">2 緩存的實作原理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t60">21什麼是Web緩存</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t61">22緩存的優點</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t62">23與緩存相關的HTTP擴充消息頭</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t63">24用戶端緩存生效的常見流程</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t64">25 Web緩存機制</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t65">3 斷點續傳和多線程下載下傳的實作原理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t66">4 https通信過程</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t67">41什麼是https</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t68">42 https的實作原理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t69">5 http代理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t70">51 http代理伺服器</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t71">52 http代理伺服器的主要功能</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t72">53 http代理圖示</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t73">6 虛拟主機的實作</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t74">61什麼是虛拟主機</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t75">62虛拟主機的實作原理</a>
<a href="http://blog.csdn.net/lmh12506/article/details/7794512#t76">附錄參考資料</a>
http協定學習系列
HTTP是Hyper Text Transfer Protocol（超文本傳輸協定）的縮寫。它的發展是網際網路協會（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結果，（他們）最終釋出了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。
HTTP協定（HyperText Transfer Protocol，超文本傳輸協定）是用于從WWW伺服器傳輸超文本到本地浏覽器的傳送協定。它可以使浏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正确快速地傳輸超文本文檔，還确定傳輸文檔中的哪一部分，以及哪部分内容首先顯示(如文本先于圖形)等。
HTTP是一個應用層協定，由請求和響應構成，是一個标準的用戶端伺服器模型。HTTP是一個無狀态的協定。
HTTP協定通常承載于TCP協定之上，有時也承載于TLS或SSL協定層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：
預設HTTP的端口号為80，HTTPS的端口号為443。
HTTP協定永遠都是用戶端發起請求，伺服器回送響應。見下圖：
這樣就限制了使用HTTP協定，無法實作在用戶端沒有發起請求的時候，伺服器将消息推送給用戶端。
HTTP協定是一個無狀态的協定，同一個用戶端的這次請求和上次請求是沒有對應關系。
一次HTTP操作稱為一個事務，其工作過程可分為四步：
1）首先客戶機與伺服器需要建立連接配接。隻要單擊某個超級連結，HTTP的工作開始。
2）建立連接配接後，客戶機發送一個請求給伺服器，請求方式的格式為：統一資源辨別符（URL）、協定版本号，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的内容。
3）伺服器接到請求後，給予相應的響應資訊，其格式為一個狀态行，包括資訊的協定版本号、一個成功或錯誤的代碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的内容。
4）用戶端接收伺服器所傳回的資訊通過浏覽器顯示在使用者的顯示屏上，然後客戶機與伺服器斷開連接配接。
如果在以上過程中的某一步出現錯誤，那麼産生錯誤的資訊将傳回到用戶端，有顯示屏輸出。對于使用者來說，這些過程是由HTTP自己完成的，使用者隻要用滑鼠點選，等待資訊顯示就可以了。
打開Wireshark，選擇工具欄上的“Capture”->“Options”，界面選擇如圖1所示：
圖1 設定Capture選項
一般讀者隻需要選擇最上邊的下拉框，選擇合适的Device，而後點選“Capture Filter”，此處選擇的是“HTTP TCP port（80）”，選擇後點選上圖的“Start”開始抓包。
圖2 選擇Capture Filter
https://yqfile.alicdn.com/img_2feffa185791a583f53a7779baca2e97.jpg
圖3 抓包
在上圖中，可清晰的看到用戶端浏覽器（ip為192.168.2.33）與伺服器的互動過程：
1）No1：浏覽器（192.168.2.33）向伺服器（220.181.50.118）發出連接配接請求。此為TCP三向交握第一步，此時從圖中可以看出，為SYN，seq:X （x=0）
2）No2：伺服器（220.181.50.118）回應了浏覽器（192.168.2.33）的請求，并要求确認，此時為：SYN，ACK，此時seq：y（y為0），ACK：x+1（為1）。此為三次握手的第二步；
3）No3：浏覽器（192.168.2.33）回應了伺服器（220.181.50.118）的确認，連接配接成功。為：ACK，此時seq：x+1（為1），ACK：y+1（為1）。此為三次握手的第三步；
4）No4：浏覽器（192.168.2.33）發出一個頁面HTTP請求；
5）No5：伺服器（220.181.50.118）确認；
6）No6：伺服器（220.181.50.118）發送資料；
7）No7：用戶端浏覽器（192.168.2.33）确認；
8）No14：用戶端（192.168.2.33）發出一個圖檔HTTP請求；
9）No15：伺服器（220.181.50.118）發送狀态響應碼200 OK
……
每個頭域由一個域名，冒号（:）和域值三部分組成。域名是大小寫無關的，域值前可以添加任何數量的空格符，頭域可以被擴充為多行，在每行開始處，使用至少一個空格或制表符。
在抓包的圖中，No14點開可看到如圖4所示：
圖4 http請求消息
回應的消息如圖5所示：
圖5 http狀态響應資訊
Host頭域指定請求資源的Intenet主機和端口号，必須表示請求url的原始伺服器或網關的位置。HTTP/1.1請求必須包含主機頭域，否則系統會以400狀态碼傳回。
圖5中host那行為：
Referer頭域允許用戶端指定請求uri的源資源位址，這可以允許伺服器生成回退連結清單，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接配接由于維護的目的被追蹤。如果請求的uri沒有自己的uri位址，Referer不能被發送。如果指定的是部分uri位址，則此位址應該是一個相對位址。
在圖4中，Referer行的内容為：
User-Agent頭域的内容包含送出請求的使用者資訊。
在圖4中，User-Agent行的内容為：
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。
在圖5中的該頭域為：
Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界标準時，換算成本地時間，需要知道使用者所在的時區。
圖5中，該頭域如下圖所示：
一個傳輸層的實際環流，它是建立在兩個互相通訊的應用程式之間。
在http1.1，request和reponse頭中都有可能出現一個connection的頭，此header的含義是當client和server通信時對于長連結如何進行處理。
在http1.1中，client和server都是預設對方支援長連結的， 如果client使用http1.1協定，但又不希望使用長連結，則需要在header中指明connection的值為close；如果server方也不想支援長連結，則在response中也需要明确說明connection的值為close。不論request還是response的header中包含了值為close的connection，都表明目前正在使用的tcp連結在當天請求處理完畢後會被斷掉。以後client再進行新的請求時就必須建立新的tcp連結了。
HTTP通訊的基本機關，包括一個結構化的八元組序列并通過連接配接傳輸。
一個從用戶端到伺服器的請求資訊包括應用于資源的方法、資源的辨別符和協定的版本号。
一個從伺服器傳回的資訊包括HTTP協定的版本号、請求的狀态(例如“成功”或“沒找到”)和文檔的MIME類型。
由URI辨別的網絡資料對象或服務。
資料資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應資訊中。一個實體包括實體頭資訊和實體的本身内容。
一個為發送請求目的而建立連接配接的應用程式。
初始化一個請求的客戶機。它們是浏覽器、編輯器或其它使用者工具。
一個接受連接配接并對請求傳回資訊的應用程式。
是一個給定資源可以在其上駐留或被建立的伺服器。
一個中間程式，它可以充當一個伺服器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在内部或經過傳遞到其它的伺服器中。一個代理在發送請求資訊之前，必須解釋并且如果可能重寫它。
代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個幫助應用來通過協定處理沒有被使用者代理完成的請求。
一個作為其它伺服器中間媒介的伺服器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源伺服器；送出請求的客戶機并沒有意識到它在同網關打交道。
網關經常作為通過防火牆的伺服器端的門戶，網關還可以作為一個協定翻譯器以便存取那些存儲在非HTTP系統中的資源。
是作為兩個連接配接中繼的中介程式。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接配接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。
反應資訊的局域存儲。
《分析TCP的三次握手》：
<a href="http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747e0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu">http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747e0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu</a>
《使用Wireshark來檢測一次HTTP連接配接過程》：
http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/
《http協定中connection頭的作用》：
RFC 1945定義了HTTP/1.0版本，RFC 2616定義了HTTP/1.1版本。
筆者在blog上提供了這兩個RFC中文版的下載下傳位址。
RFC1945下載下傳位址：
http://www.blogjava.net/Files/amigoxie/RFC1945（HTTP）中文版.rar
RFC2616下載下傳位址：
http://www.blogjava.net/Files/amigoxie/RFC2616（HTTP）中文版.rar
HTTP/1.0 每次請求都需要建立新的TCP連接配接，連接配接不能複用。HTTP/1.1 新的請求可以在上次請求建立的TCP連接配接之上發送，連接配接可以複用。優點是減少重複進行TCP三向交握的開銷，提高效率。
注意：在同一個TCP連接配接中，新的請求需要等上次請求收到響應後，才能發送。
HTTP1.1在Request消息頭裡頭多了一個Host域, HTTP1.0則沒有這個域。
Eg：
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
可能HTTP1.0的時候認為，建立TCP連接配接的時候已經指定了IP位址，這個IP位址上隻有一個host。
(接收方向)
無論是HTTP1.0還是HTTP1.1，都要能解析下面三種date/time stamp：
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
(發送方向)
HTTP1.0要求不能生成第三種asctime格式的date/time stamp；
HTTP1.1則要求隻生成RFC 1123(第一種)格式的date/time stamp。
狀态響應碼100 (Continue) 狀态代碼的使用，允許用戶端在發request消息body之前先用request header試探一下server，看server要不要接收request body，再決定要不要發request body。
用戶端在Request頭部中包含
Expect: 100-continue
Server看到之後呢如果回100 (Continue) 這個狀态代碼，用戶端就繼續發request body。這個是HTTP1.1才有的。
另外在HTTP/1.1中還增加了101、203、205等等性狀态響應碼
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
請求消息格式如下所示：
請求行
通用資訊頭|請求頭|實體頭
CRLF(回車換行)
實體内容
其中“請求行”為：請求行 = 方法 [空格] 請求URI [空格] 版本号 [回車換行]
請求行執行個體：
Eg1：
GET /index.html HTTP/1.1
Eg2：
HTTP請求消息執行個體：
GET /hello.htm HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 17 Oct 2007 02:15:55 GMT
If-None-Match: W/"158-1192587355000"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 192.168.2.162:8080
Connection: Keep-Alive
HTTP的請求方法包括如下幾種：
GET
POST
HEAD
PUT
DELETE
OPTIONS
TRACE
CONNECT
HTTP響應消息的格式如下所示：
狀态行
通用資訊頭|響應頭|實體頭
CRLF
其中：狀态行 = 版本号 [空格] 狀态碼 [空格] 原因 [回車換行]
狀态行舉例：
HTTP/1.0 200 OK
Eg2：
HTTP/1.1 400 Bad Request
HTTP響應消息執行個體如下所示：
HTTP/1.1 200 OK
ETag: W/"158-1192590101000"
Last-Modified: Wed, 17 Oct 2007 03:01:41 GMT
Content-Type: text/html
Content-Length: 158
Date: Wed, 17 Oct 2007 03:01:59 GMT
Server: Apache-Coyote/1.1
2.3.2 http的狀态響應碼
100——客戶必須繼續送出請求
101——客戶要求伺服器根據請求轉換HTTP協定版本
200——交易成功
201——提示知道新檔案的URL
202——接受和處理、但處理未完成
203——傳回資訊不确定或不完整
204——請求收到，但傳回資訊為空
205——伺服器完成了請求，使用者代理必須複位目前已經浏覽過的檔案
206——伺服器已經完成了部分使用者的GET請求
300——請求的資源可在多處得到
301——删除請求資料
302——在其他位址發現了請求資料
303——建議客戶通路其他URL或通路方式
304——用戶端已經執行了GET，但檔案未變化
305——請求的資源必須從伺服器指定的位址得到
306——前一版本HTTP中使用的代碼，現行版本中不再使用
307——申明請求的資源臨時性删除
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頭字段指定的期望值，如果是代理伺服器，可能是下一級伺服器不能滿足請求長。
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 - 網關錯誤
在Windows下，可使用指令視窗進行http簡單測試。
輸入cmd進入指令視窗，在指令行鍵入如下指令後按回車：
telnet www.baidu.com 80
而後在視窗中按下“Ctrl+]”後按回車可讓傳回結果回顯。
接着開始發請求消息，例如發送如下請求消息請求baidu的首頁消息，使用的HTTP協定為HTTP/1.1：
注意：copy如上的消息到指令視窗後需要按兩個回車換行才能得到響應的消息，第一個回車換行是在指令後鍵入回車換行，是HTTP協定要求的。第二個是确認輸入，發送請求。
可看到傳回了200 OK的消息，如下圖所示：
可看到，當采用HTTP/1.1時，連接配接不是在請求結束後就斷開的。若采用HTTP1.0，在指令視窗鍵入：
GET /index.html HTTP/1.0
此時可以看到請求結束之後馬上斷開。
讀者還可以嘗試在使用GET或POST等時，帶上頭域資訊，例如鍵入如下資訊：
connection: close
Host: www.baidu.com
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 請求實作，因為在注解送出之後站點已經不同了（比方說文章下面出現一條注解）。
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，然後在正式寫出内容之前計算它的大小；
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類型。
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 Allow：GET,POST
l Content-Encoding：文檔的編碼（Encode）方法，例如：gzip，見“2.5 響應頭”；
l Content-Language：内容的語言類型，例如：zh-cn；
l Content-Length：表示内容長度，eg：80，可參考“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.
在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的差別》：
<a href="http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx">http://blog.csdn.net/yanghehong/archive/2009/05/28/4222594.aspx</a>
《HTTP請求（GET和POST差別）和響應》：
<a href="http://www.blogjava.net/honeybee/articles/164008.html">http://www.blogjava.net/honeybee/articles/164008.html</a>
《HTTP請求頭概述_百度知道》：
<a href="http://zhidao.baidu.com/question/32517427.html">http://zhidao.baidu.com/question/32517427.html</a>
《實體頭和擴充頭》：
<a href="http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html">http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html</a>
3. 深入了解篇
Cookie和Session都為了用來儲存狀态資訊，都是儲存用戶端狀态的機制，它們都是為了解決HTTP無狀态的問題而所做的努力。
Session可以用Cookie來實作，也可以用URL回寫的機制來實作。用Cookie來實作的Session可以認為是對Cookie更進階的應用。
Cookie和Session有以下明顯的不同點：
1）Cookie将狀态儲存在用戶端，Session将狀态儲存在伺服器端；
2）Cookies是伺服器在本地機器上存儲的小段文本并随每一個請求發送至同一個伺服器。Cookie最早在RFC2109中實作，後續RFC2965做了增強。網絡伺服器用HTTP頭向用戶端發送cookies，在客戶終端，浏覽器解析這些cookies并将它們儲存為一個本地檔案，它會自動将同一伺服器的任何請求縛上這些cookies。Session并沒有在HTTP的協定中定義；
3）Session是針對每一個使用者的，變量的值儲存在伺服器上，用一個sessionID來區分是哪個使用者session變量,這個值是通過使用者的浏覽器在通路的時候傳回給伺服器，當客戶禁用cookie時，這個值也可能設定為由get來傳回給伺服器；
4）就安全性來說：當你通路一個使用session 的站點，同時在自己機子上建立一個cookie，建議在伺服器端的SESSION機制更安全些.因為它不會任意讀取客戶存儲的資訊。
Session機制是一種伺服器端的機制，伺服器使用一種類似于散清單的結構（也可能就是使用散清單）來儲存資訊。
當程式需要為某個用戶端的請求建立一個session的時候，伺服器首先檢查這個用戶端的請求裡是否已包含了一個session辨別 - 稱為 session id，如果已包含一個session id則說明以前已經為此用戶端建立過session，伺服器就按照session id把這個 session檢索出來使用（如果檢索不到，可能會建立一個），如果用戶端請求不包含session id，則為此用戶端建立一個session并且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字元串，這個 session id将被在本次響應中傳回給用戶端儲存。
伺服器給每個Session配置設定一個唯一的JSESSIONID，并通過Cookie發送給用戶端。
當用戶端發起新的請求的時候，将在Cookie頭中攜帶這個JSESSIONID。這樣伺服器能夠找到這個用戶端對應的Session。
流程如下圖所示：
URL回寫是指伺服器在發送給浏覽器頁面的所有連結中都攜帶JSESSIONID的參數，這樣用戶端點選任何一個連結都會把JSESSIONID帶會伺服器。
如果直接在浏覽器輸入服務端資源的url來請求該資源，那麼Session是比對不到的。
Tomcat對Session的實作，是一開始同時使用Cookie和URL回寫機制，如果發現用戶端支援Cookie，就繼續使用Cookie，停止使用URL回寫。如果發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的連結記得使用response.encodeURL() 。
1）Session逾時：Session在指定時間内失效，例如30分鐘，若在30分鐘内沒有操作，則Session會失效，例如在web.xml中進行了如下設定：
<session-config>
<session-timeout>30</session-timeout> //機關：分鐘
</session-config>
2）使用session.invalidate()明确的去掉Session。
1）Cookie：用戶端将伺服器設定的Cookie傳回到伺服器；
2）Set-Cookie：伺服器向用戶端設定Cookie；
3）Cookie2 (RFC2965)）：用戶端訓示伺服器支援Cookie的版本；
4）Set-Cookie2 (RFC2965)：伺服器向用戶端設定Cookie。
伺服器在響應消息中用Set-Cookie頭将Cookie的内容回送給用戶端，用戶端在新的請求中将相同的内容攜帶在Cookie頭中發送給伺服器。進而實作會話的保持。
WEB緩存(cache)位于Web伺服器和用戶端之間。
緩存會根據請求儲存輸出内容的副本，例如html頁面，圖檔，檔案，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應通路請求，而不是向源伺服器再次發送請求。
HTTP協定定義了相關的消息頭來使WEB緩存盡可能好的工作。
q 減少相應延遲：因為請求從緩存伺服器（離用戶端更近）而不是源伺服器被相應，這個過程耗時更少，讓web伺服器看上去相應更快。
q 減少網絡帶寬消耗：當副本被重用時會減低用戶端的帶寬消耗；客戶可以節省帶寬費用，控制帶寬的需求的增長并更易于管理。
q Expires：訓示響應内容過期的時間，格林威治時間GMT
q Cache-Control：更細緻的控制緩存的内容
q Last-Modified：響應中資源最後一次修改的時間
q ETag：響應中資源的校驗值，在伺服器上某個時段是唯一辨別的。
q Date：伺服器的時間
q If-Modified-Since：用戶端存取的該資源最後一次修改的時間，同Last-Modified。
q If-None-Match：用戶端存取的該資源的檢驗值，同ETag。
伺服器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，用戶端将該資源儲存在cache中，并記錄這兩個屬性。當用戶端需要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分别是響應中Last-Modified和ETag頭的值。伺服器通過這兩個頭判斷本地資源未發生變化，用戶端不需要重新下載下傳，傳回304響應。常見流程如下圖所示：
HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。後者減少了網絡應用的帶寬；HTTP用“驗證（validation）”機制來為此目的。
HTTP定義了3種緩存機制：
1）Freshness：允許一個回應消息可以在源伺服器不被重新檢查，并且可以由伺服器和用戶端來控制。例如，Expires回應頭給了一個文檔不可用的時間。Cache-Control中的max-age辨別指明了緩存的最長時間；
2）Validation：用來檢查以一個緩存的回應是否仍然可用。例如，如果一個回應有一個Last-Modified回應頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據情況發送請求；
3）Invalidation： 在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關聯到一個緩存回應，但是其後跟着POST、PUT和DELETE的請求的話，緩存就會過期。
q HTTP協定的GET方法，支援隻請求某個資源的某一部分；
q 206 Partial Content 部分内容響應；
q Range 請求的資源範圍；
q Content-Range 響應的資源範圍；
q 在連接配接斷開重連時，用戶端隻請求該資源未下載下傳的部分，而不是重新請求整個資源，來實作斷點續傳。
分塊請求資源執行個體：
Eg1：Range: bytes=306302- ：請求這個資源從306302個位元組到末尾的部分；
Eg2：Content-Range: bytes 306302-604047/604048：響應中訓示攜帶的是該資源的第306302-604047的位元組，該資源共604048個位元組；
用戶端通過并發的請求相同資源的不同片段，來實作對某個資源的并發分塊下載下傳。進而達到快速下載下傳的目的。目前流行的FlashGet和迅雷基本都是這個原理。
多線程下載下傳的原理：
q 下載下傳工具開啟多個發出HTTP請求的線程；
q 每個http請求隻請求資源檔案的一部分：Content-Range: bytes 20000-40000/47000；
q 合并每個線程下載下傳的檔案。
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目标的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，是以加密的詳細内容請看SSL。
見下圖：
https所用的端口号是443。
有兩種基本的加解密算法類型：
1）對稱加密：密鑰隻有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
2）非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
下面看一下https的通信過程：
https通信的優點：
1）用戶端産生的密鑰隻有用戶端和伺服器端能得到；
2）加密的資料隻有用戶端和伺服器端才能得到明文；
3）用戶端到服務端的通信是安全的。
代理伺服器英文全稱是Proxy Server，其功能就是代理網絡使用者去取得網絡資訊。形象的說：它是網絡資訊的中轉站。
代理伺服器是介于浏覽器和Web伺服器之間的一台伺服器，有了它之後，浏覽器不是直接到Web伺服器去取回網頁而是向代理伺服器送出請求，Request信号會先送到代理伺服器，由代理伺服器來取回浏覽器所需要的資訊并傳送給你的浏覽器。
而且，大部分代理伺服器都具有緩沖的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷将新取得資料儲存到它本機的存儲器上，如果浏覽器所請求的資料在它本機的存儲器上已經存在而且是最新的，那麼它就不重新從Web伺服器取資料，而直接将存儲器上的資料傳送給使用者的浏覽器，這樣就能顯著提高浏覽速度和效率。
更重要的是：Proxy Server(代理伺服器)是Internet鍊路級網關所提供的一種重要的安全功能，它的工作主要在開放系統互聯(OSI)模型的對話層。
主要功能如下：
1）突破自身IP通路限制，通路國外站點。如：教育網、169網等網絡使用者可以通過代理通路國外網站；
2）通路一些機關或團體内部資源，如某大學FTP(前提是該代理位址在該資源的允許通路範圍之内)，使用教育網内位址段免費代理伺服器，就可以用于對教育 網開放的各類FTP下載下傳上傳，以及各類資料查詢共享等服務；
3）突破中國電信的IP封鎖：中國電信使用者有很多網站是被限制通路的，這種限制是人為的，不同Serve對位址的封鎖是不同的。是以不能通路時可以換一個國 外的代理伺服器試試；
4）提高通路速度：通常代理伺服器都設定一個較大的硬碟緩沖區，當有外界的資訊通過時，同時也将其儲存到緩沖區中，當其他使用者再通路相同的資訊時， 則直接由緩沖區中取出資訊，傳給使用者，以提高通路速度；
5）隐藏真實IP：上網者也可以通過這種方法隐藏自己的IP，免受攻擊。
http代理的圖示見下圖：
對于用戶端浏覽器而言，http代理伺服器相當于伺服器。
而對于Web伺服器而言，http代理伺服器又擔當了用戶端的角色。
虛拟主機是用同一個WEB伺服器，為不同域名網站提供服務的技術。Apache、Tomcat等均可通過配置實作這個功能。
相關的HTTP消息頭：Host。
用戶端發送HTTP請求的時候，會攜帶Host頭，Host頭記錄的是用戶端輸入的域名。這樣伺服器可以根據Host頭确認客戶要通路的是哪一個域名。
《了解Cookie和Session機制》：
<a href="http://sumongh.javaeye.com/blog/82498">http://sumongh.javaeye.com/blog/82498</a>
《淺析HTTP協定》：
<a href="http://203.208.39.132/search?q=cache:CdXly_88gjIJ:www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html+http%E5%8D%8F%E8%AE%AE+web%E7%BC%93%E5%AD%98&cd=27&hl=zh-CN&ct=clnk&gl=cn&st_usg=ALhdy2-vzOcP8XTG1h7lcRr2GJrkTbH2Cg">http://203.208.39.132/search?q=cache:CdXly_88gjIJ:www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html+http%E5%8D%8F%E8%AE%AE+web%E7%BC%93%E5%AD%98&cd=27&hl=zh-CN&ct=clnk&gl=cn&st_usg=ALhdy2-vzOcP8XTG1h7lcRr2GJrkTbH2Cg</a>
《http代理_百度百科》：
<a href="http://baike.baidu.com/view/1159398.htm">http://baike.baidu.com/view/1159398.htm</a>
《虛拟主機_百度百科》：
<a href="http://baike.baidu.com/view/7383.htm">http://baike.baidu.com/view/7383.htm</a>
《https_百度百科》：
<a href="http://baike.baidu.com/view/14121.htm">http://baike.baidu.com/view/14121.htm</a>
【新浪微網誌】 張昺華--sky
【twitter】 @sky2030_
【facebook】 張昺華 zhangbinghua
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利.