1.1 介紹
HTTP是Hyper Text Transfer Protocol(超文本傳輸協(xié)議)的縮寫(xiě)。它的發(fā)展是萬(wàn)維網(wǎng)協(xié)會(huì)(World Wide Web Consortium)和Internet工作小組IETF(Internet Engineering Task Force)合作的結(jié)果，(他們)最終發(fā)布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個(gè)版本——HTTP 1.1。
HTTP協(xié)議(HyperText Transfer Protocol，超文本傳輸協(xié)議)是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。
HTTP是一個(gè)應(yīng)用層協(xié)議，由請(qǐng)求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶(hù)端服務(wù)器模型。HTTP是一個(gè)無(wú)狀態(tài)的協(xié)議。
1.2 在TCP/IP協(xié)議棧中的位置
HTTP協(xié)議通常承載于TCP協(xié)議之上，有時(shí)也承載于TLS或SSL協(xié)議層之上，這個(gè)時(shí)候，就成了我們常說(shuō)的HTTPS。如下圖所示：
默認(rèn)HTTP的端口號(hào)為80，HTTPS的端口號(hào)為443。
1.3 HTTP的請(qǐng)求響應(yīng)模型
HTTP協(xié)議永遠(yuǎn)都是客戶(hù)端發(fā)起請(qǐng)求，服務(wù)器回送響應(yīng)。見(jiàn)下圖：
這樣就限制了使用HTTP協(xié)議，無(wú)法實(shí)現(xiàn)在客戶(hù)端沒(méi)有發(fā)起請(qǐng)求的時(shí)候，服務(wù)器將消息推送給客戶(hù)端。
HTTP協(xié)議是一個(gè)無(wú)狀態(tài)的協(xié)議，同一個(gè)客戶(hù)端的這次請(qǐng)求和上次請(qǐng)求是沒(méi)有對(duì)應(yīng)關(guān)系。
1.4 工作流程
一次HTTP操作稱(chēng)為一個(gè)事務(wù)，其工作過(guò)程可分為四步：
1)首先客戶(hù)機(jī)與服務(wù)器需要建立連接。只要單擊某個(gè)超級(jí)鏈接，HTTP的工作開(kāi)始。
2)建立連接后，客戶(hù)機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符(URL)、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶(hù)機(jī)信息和可能的內(nèi)容。
3)服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。
4)客戶(hù)端接收服務(wù)器所返回的信息通過(guò)瀏覽器顯示在用戶(hù)的顯示屏上，然后客戶(hù)機(jī)與服務(wù)器斷開(kāi)連接。
如果在以上過(guò)程中的某一步出現(xiàn)錯(cuò)誤，那么產(chǎn)生錯(cuò)誤的信息將返回到客戶(hù)端，有顯示屏輸出。對(duì)于用戶(hù)來(lái)說(shuō)，這些過(guò)程是由HTTP自己完成的，用戶(hù)只要用鼠標(biāo)點(diǎn)擊，等待信息顯示就可以了。
1.5 使用Wireshark抓TCP、http包
打開(kāi)Wireshark，選擇工具欄上的“Capture”->“Options”，界面選擇如圖1所示：
一般讀者只需要選擇最上邊的下拉框，選擇合適的Device，而后點(diǎn)擊“Capture Filter”，此處選擇的是“HTTP TCP port(80)”，選擇后點(diǎn)擊上圖的“Start”開(kāi)始抓包。
例如在瀏覽器中打開(kāi)http://image.baidu.com/，抓包如圖3所示：
http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-3.jpg
在上圖中，可清晰的看到客戶(hù)端瀏覽器(ip為192.168.2.33)與服務(wù)器的交互過(guò)程：
1)No1：瀏覽器(192.168.2.33)向服務(wù)器(220.181.50.118)發(fā)出連接請(qǐng)求。此為T(mén)CP三次握手第一步，此時(shí)從圖中可以看出，為SYN，seq:X (x=0)
2)No2：服務(wù)器(220.181.50.118)回應(yīng)了瀏覽器(192.168.2.33)的請(qǐng)求，并要求確認(rèn)，此時(shí)為：SYN，ACK，此時(shí)seq：y(y為0)，ACK：x+1(為1)。此為三次握手的第二步;
3)No3：瀏覽器(192.168.2.33)回應(yīng)了服務(wù)器(220.181.50.118)的確認(rèn)，連接成功。為：ACK，此時(shí)seq：x+1(為1)，ACK：y+1(為1)。此為三次握手的第三步;
4)No4：瀏覽器(192.168.2.33)發(fā)出一個(gè)頁(yè)面HTTP請(qǐng)求;
5)No5：服務(wù)器(220.181.50.118)確認(rèn);
6)No6：服務(wù)器(220.181.50.118)發(fā)送數(shù)據(jù);
7)No7：客戶(hù)端瀏覽器(192.168.2.33)確認(rèn);
8)No14：客戶(hù)端(192.168.2.33)發(fā)出一個(gè)圖片HTTP請(qǐng)求;
9)No15：服務(wù)器(220.181.50.118)發(fā)送狀態(tài)響應(yīng)碼200 OK
……
1.6 頭域
每個(gè)頭域由一個(gè)域名，冒號(hào)(:)和域值三部分組成。域名是大小寫(xiě)無(wú)關(guān)的，域值前可以添加任何數(shù)量的空格符，頭域可以被擴(kuò)展為多行，在每行開(kāi)始處，使用至少一個(gè)空格或制表符。
在抓包的圖中，No14點(diǎn)開(kāi)可看到如圖4所示：
http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-4.jpg
1.6.1 host頭域
Host頭域指定請(qǐng)求資源的Intenet主機(jī)和端口號(hào)，必須表示請(qǐng)求url的原始服務(wù)器或網(wǎng)關(guān)的位置。HTTP/1.1請(qǐng)求必須包含主機(jī)頭域，否則系統(tǒng)會(huì)以400狀態(tài)碼返回。
圖5中host那行為：
1.6.2 Referer頭域
Referer頭域允許客戶(hù)端指定請(qǐng)求uri的源資源地址，這可以允許服務(wù)器生成回退鏈表，可用來(lái)登陸、優(yōu)化cache等。他也允許廢除的或錯(cuò)誤的連接由于維護(hù)的目的被追蹤。如果請(qǐng)求的uri沒(méi)有自己的uri地址，Referer不能被發(fā)送。如果指定的是部分uri地址，則此地址應(yīng)該是一個(gè)相對(duì)地址。
在圖4中，Referer行的內(nèi)容為：
1.6.3 User-Agent頭域
User-Agent頭域的內(nèi)容包含發(fā)出請(qǐng)求的用戶(hù)信息。
在圖4中，User-Agent行的內(nèi)容為：
http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-8.jpg
1.6.4 Cache-Control頭域
Cache-Control指定請(qǐng)求和響應(yīng)遵循的緩存機(jī)制。在請(qǐng)求消息或響應(yīng)消息中設(shè)置Cache-Control并不會(huì)修改另一個(gè)消息處理過(guò)程中的緩存處理過(guò)程。請(qǐng)求時(shí)的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。
在圖5中的該頭域?yàn)椋?
1.6.5 Date頭域
Date頭域表示消息發(fā)送的時(shí)間，時(shí)間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時(shí)間表示世界標(biāo)準(zhǔn)時(shí)，換算成本地時(shí)間，需要知道用戶(hù)所在的時(shí)區(qū)。
圖5中，該頭域如下圖所示：
1.7 HTTP的幾個(gè)重要概念
1.7.1連接：Connection
一個(gè)傳輸層的實(shí)際環(huán)流，它是建立在兩個(gè)相互通訊的應(yīng)用程序之間。
在http1.1，request和reponse頭中都有可能出現(xiàn)一個(gè)connection的頭，此header的含義是當(dāng)client和server通信時(shí)對(duì)于長(zhǎng)鏈接如何進(jìn)行處理。
在http1.1中，client和server都是默認(rèn)對(duì)方支持長(zhǎng)鏈接的， 如果client使用http1.1協(xié)議，但又不希望使用長(zhǎng)鏈接，則需要在header中指明connection的值為close;如果server方也不想支持長(zhǎng)鏈接，則在response中也需要明確說(shuō)明connection的值為close。不論request還是response的header中包含了值為close的connection，都表明當(dāng)前正在使用的tcp鏈接在當(dāng)天請(qǐng)求處理完畢后會(huì)被斷掉。以后client再進(jìn)行新的請(qǐng)求時(shí)就必須創(chuàng)建新的tcp鏈接了。
1.7.2消息：Message
HTTP通訊的基本單位，包括一個(gè)結(jié)構(gòu)化的八元組序列并通過(guò)連接傳輸。
1.7.3請(qǐng)求：Request
一個(gè)從客戶(hù)端到服務(wù)器的請(qǐng)求信息包括應(yīng)用于資源的方法、資源的標(biāo)識(shí)符和協(xié)議的版本號(hào)。
1.7.4響應(yīng)：Response
一個(gè)從服務(wù)器返回的信息包括HTTP協(xié)議的版本號(hào)、請(qǐng)求的狀態(tài)(例如“成功”或“沒(méi)找到”)和文檔的MIME類(lèi)型。
1.7.5資源：Resource
由URI標(biāo)識(shí)的網(wǎng)絡(luò)數(shù)據(jù)對(duì)象或服務(wù)。
1.7.6實(shí)體：Entity
數(shù)據(jù)資源或來(lái)自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個(gè)請(qǐng)求或響應(yīng)信息中。一個(gè)實(shí)體包括實(shí)體頭信息和實(shí)體的本身內(nèi)容。
1.7.7客戶(hù)機(jī)：Client
一個(gè)為發(fā)送請(qǐng)求目的而建立連接的應(yīng)用程序。
1.7.8用戶(hù)代理：UserAgent
初始化一個(gè)請(qǐng)求的客戶(hù)機(jī)。它們是瀏覽器、編輯器或其它用戶(hù)工具。
1.7.9服務(wù)器：Server
一個(gè)接受連接并對(duì)請(qǐng)求返回信息的應(yīng)用程序。
1.7.10源服務(wù)器：Originserver
是一個(gè)給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。
1.7.11代理：Proxy
一個(gè)中間程序，它可以充當(dāng)一個(gè)服務(wù)器，也可以充當(dāng)一個(gè)客戶(hù)機(jī)，為其它客戶(hù)機(jī)建立請(qǐng)求。請(qǐng)求是通過(guò)可能的翻譯在內(nèi)部或經(jīng)過(guò)傳遞到其它的服務(wù)器中。一個(gè)代理在發(fā)送請(qǐng)求信息之前，必須解釋并且如果可能重寫(xiě)它。
代理經(jīng)常作為通過(guò)防火墻的客戶(hù)機(jī)端的門(mén)戶(hù)，代理還可以作為一個(gè)幫助應(yīng)用來(lái)通過(guò)協(xié)議處理沒(méi)有被用戶(hù)代理完成的請(qǐng)求。
1.7.12網(wǎng)關(guān)：Gateway
一個(gè)作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請(qǐng)求就好象對(duì)被請(qǐng)求的資源來(lái)說(shuō)它就是源服務(wù)器;發(fā)出請(qǐng)求的客戶(hù)機(jī)并沒(méi)有意識(shí)到它在同網(wǎng)關(guān)打交道。
網(wǎng)關(guān)經(jīng)常作為通過(guò)防火墻的服務(wù)器端的門(mén)戶(hù)，網(wǎng)關(guān)還可以作為一個(gè)協(xié)議翻譯器以便存取那些存儲(chǔ)在非HTTP系統(tǒng)中的資源。
1.7.13通道：Tunnel
是作為兩個(gè)連接中繼的中介程序。一旦激活，通道便被認(rèn)為不屬于HTTP通訊，盡管通道可能是被一個(gè)HTTP請(qǐng)求初始化的。當(dāng)被中繼的連接兩端關(guān)閉時(shí)，通道便消失。當(dāng)一個(gè)門(mén)戶(hù)(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時(shí)通道被經(jīng)常使用。
1.7.14緩存：Cache
反應(yīng)信息的局域存儲(chǔ)。
2.1 HTTP/1.0和HTTP/1.1的比較
RFC 1945定義了HTTP/1.0版本，RFC 2616定義了HTTP/1.1版本。
筆者在blog上提供了這兩個(gè)RFC中文版的下載地址。
RFC1945下載地址：
http://www.blogjava.net/Files/amigoxie/RFC1945(HTTP)中文版.rar
RFC2616下載地址：
http://www.blogjava.net/Files/amigoxie/RFC2616(HTTP)中文版.rar
2.1.1建立連接方面
HTTP/1.0 每次請(qǐng)求都需要建立新的TCP連接，連接不能復(fù)用。HTTP/1.1 新的請(qǐng)求可以在上次請(qǐng)求建立的TCP連接之上發(fā)送，連接可以復(fù)用。優(yōu)點(diǎn)是減少重復(fù)進(jìn)行TCP三次握手的開(kāi)銷(xiāo)，提高效率。
注意：在同一個(gè)TCP連接中，新的請(qǐng)求需要等上次請(qǐng)求收到響應(yīng)后，才能發(fā)送。
2.1.2 Host域
HTTP1.1在Request消息頭里頭多了一個(gè)Host域, HTTP1.0則沒(méi)有這個(gè)域。
Eg：
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
可能HTTP1.0的時(shí)候認(rèn)為，建立TCP連接的時(shí)候已經(jīng)指定了IP地址，這個(gè)IP地址上只有一個(gè)host。
2.1.3日期時(shí)間戳
(接收方向)
無(wú)論是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
(發(fā)送方向)
HTTP1.0要求不能生成第三種asctime格式的date/time stamp;
HTTP1.1則要求只生成RFC 1123(第一種)格式的date/time stamp。
2.1.4狀態(tài)響應(yīng)碼
狀態(tài)響應(yīng)碼100 (Continue) 狀態(tài)代碼的使用，允許客戶(hù)端在發(fā)request消息body之前先用request header試探一下server，看server要不要接收request body，再?zèng)Q定要不要發(fā)request body。
客戶(hù)端在Request頭部中包含
Expect: 100-continue
Server看到之后呢如果回100 (Continue) 這個(gè)狀態(tài)代碼，客戶(hù)端就繼續(xù)發(fā)request body。這個(gè)是HTTP1.1才有的。
另外在HTTP/1.1中還增加了101、203、205等等性狀態(tài)響應(yīng)碼
2.1.5請(qǐng)求方式
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請(qǐng)求消息
2.2.1請(qǐng)求消息格式
請(qǐng)求消息格式如下所示：
請(qǐng)求行
通用信息頭|請(qǐng)求頭|實(shí)體頭
CRLF(回車(chē)換行)
實(shí)體內(nèi)容
其中“請(qǐng)求行”為：請(qǐng)求行 = 方法 [空格] 請(qǐng)求URI [空格] 版本號(hào) [回車(chē)換行]
請(qǐng)求行實(shí)例：
Eg1：
GET /index.html HTTP/1.1
Eg2：
POST http://192.168.2.217:8080/index.jsp HTTP/1.1
HTTP請(qǐng)求消息實(shí)例：
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
2.2.2請(qǐng)求方法
HTTP的請(qǐng)求方法包括如下幾種：
GET
POST
HEAD
PUT
DELETE
OPTIONS
TRACE
CONNECT
2.3 HTTP響應(yīng)消息
2.3.1響應(yīng)消息格式
HTTP響應(yīng)消息的格式如下所示：
狀態(tài)行
通用信息頭|響應(yīng)頭|實(shí)體頭
CRLF
實(shí)體內(nèi)容
其中：狀態(tài)行 = 版本號(hào) [空格] 狀態(tài)碼 [空格] 原因 [回車(chē)換行]
狀態(tài)行舉例：
Eg1：
HTTP/1.0 200 OK
Eg2：
HTTP/1.1 400 Bad Request
HTTP響應(yīng)消息實(shí)例如下所示：
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的狀態(tài)響應(yīng)碼
2.3.2.1 1**：請(qǐng)求收到，繼續(xù)處理
100——客戶(hù)必須繼續(xù)發(fā)出請(qǐng)求
101——客戶(hù)要求服務(wù)器根據(jù)請(qǐng)求轉(zhuǎn)換HTTP協(xié)議版本
2.3.2.2 2**：操作成功收到，分析、接受
200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請(qǐng)求收到，但返回信息為空
205——服務(wù)器完成了請(qǐng)求，用戶(hù)代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過(guò)的文件
206——服務(wù)器已經(jīng)完成了部分用戶(hù)的GET請(qǐng)求
2.3.2.3 3**：完成此請(qǐng)求必須進(jìn)一步處理
300——請(qǐng)求的資源可在多處得到
301——?jiǎng)h除請(qǐng)求數(shù)據(jù)
302——在其他地址發(fā)現(xiàn)了請(qǐng)求數(shù)據(jù)
303——建議客戶(hù)訪(fǎng)問(wèn)其他URL或訪(fǎng)問(wèn)方式
304——客戶(hù)端已經(jīng)執(zhí)行了GET，但文件未變化
305——請(qǐng)求的資源必須從服務(wù)器指定的地址得到
306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用
307——申明請(qǐng)求的資源臨時(shí)性刪除
2.3.2.4 4**：請(qǐng)求包含一個(gè)錯(cuò)誤語(yǔ)法或不能完成
400——錯(cuò)誤請(qǐng)求，如語(yǔ)法錯(cuò)誤
401——未授權(quán)
HTTP 401.1 - 未授權(quán)：登錄失敗
HTTP 401.2 - 未授權(quán)：服務(wù)器配置問(wèn)題導(dǎo)致登錄失敗
HTTP 401.3 - ACL 禁止訪(fǎng)問(wèn)資源
HTTP 401.4 - 未授權(quán)：授權(quán)被篩選器拒絕
HTTP 401.5 - 未授權(quán)：ISAPI 或 CGI 授權(quán)失敗
402——保留有效ChargeTo頭響應(yīng)
403——禁止訪(fǎng)問(wèn)
HTTP 403.1 禁止訪(fǎng)問(wèn)：禁止可執(zhí)行訪(fǎng)問(wèn)
HTTP 403.2 - 禁止訪(fǎng)問(wèn)：禁止讀訪(fǎng)問(wèn)
HTTP 403.3 - 禁止訪(fǎng)問(wèn)：禁止寫(xiě)訪(fǎng)問(wèn)
HTTP 403.4 - 禁止訪(fǎng)問(wèn)：要求 SSL
HTTP 403.5 - 禁止訪(fǎng)問(wèn)：要求 SSL 128
HTTP 403.6 - 禁止訪(fǎng)問(wèn)：IP 地址被拒絕
HTTP 403.7 - 禁止訪(fǎng)問(wèn)：要求客戶(hù)證書(shū)
HTTP 403.8 - 禁止訪(fǎng)問(wèn)：禁止站點(diǎn)訪(fǎng)問(wèn)
HTTP 403.9 - 禁止訪(fǎng)問(wèn)：連接的用戶(hù)過(guò)多
HTTP 403.10 - 禁止訪(fǎng)問(wèn)：配置無(wú)效
HTTP 403.11 - 禁止訪(fǎng)問(wèn)：密碼更改
HTTP 403.12 - 禁止訪(fǎng)問(wèn)：映射器拒絕訪(fǎng)問(wèn)
HTTP 403.13 - 禁止訪(fǎng)問(wèn)：客戶(hù)證書(shū)已被吊銷(xiāo)
HTTP 403.15 - 禁止訪(fǎng)問(wèn)：客戶(hù)訪(fǎng)問(wèn)許可過(guò)多
HTTP 403.16 - 禁止訪(fǎng)問(wèn)：客戶(hù)證書(shū)不可信或者無(wú)效
HTTP 403.17 - 禁止訪(fǎng)問(wèn)：客戶(hù)證書(shū)已經(jīng)到期或者尚未生效
404——沒(méi)有發(fā)現(xiàn)文件、查詢(xún)或URl
405——用戶(hù)在Request-Line字段定義的方法不允許
406——根據(jù)用戶(hù)發(fā)送的Accept拖，請(qǐng)求資源不可訪(fǎng)問(wèn)
407——類(lèi)似401，用戶(hù)必須首先在代理服務(wù)器上得到授權(quán)
408——客戶(hù)端沒(méi)有在用戶(hù)指定的餓時(shí)間內(nèi)完成請(qǐng)求
409——對(duì)當(dāng)前資源狀態(tài)，請(qǐng)求不能完成
410——服務(wù)器上不再有此資源且無(wú)進(jìn)一步的參考地址
411——服務(wù)器拒絕用戶(hù)定義的Content-Length屬性請(qǐng)求
412——一個(gè)或多個(gè)請(qǐng)求頭字段在當(dāng)前請(qǐng)求中錯(cuò)誤
413——請(qǐng)求的資源大于服務(wù)器允許的大小
414——請(qǐng)求的資源URL長(zhǎng)于服務(wù)器允許的長(zhǎng)度
415——請(qǐng)求資源不支持請(qǐng)求項(xiàng)目格式
416——請(qǐng)求中包含Range請(qǐng)求頭字段，在當(dāng)前請(qǐng)求資源范圍內(nèi)沒(méi)有range指示值，請(qǐng)求也不包含If-Range請(qǐng)求頭字段
417——服務(wù)器不滿(mǎn)足請(qǐng)求Expect頭字段指定的期望值，如果是代理服務(wù)器，可能是下一級(jí)服務(wù)器不能滿(mǎn)足請(qǐng)求長(zhǎng)。
2.3.2.5 5**：服務(wù)器執(zhí)行一個(gè)完全有效請(qǐng)求失敗
HTTP 500 - 內(nèi)部服務(wù)器錯(cuò)誤
HTTP 500.100 - 內(nèi)部服務(wù)器錯(cuò)誤 - ASP 錯(cuò)誤
HTTP 500-11 服務(wù)器關(guān)閉
HTTP 500-12 應(yīng)用程序重新啟動(dòng)
HTTP 500-13 - 服務(wù)器太忙
HTTP 500-14 - 應(yīng)用程序無(wú)效
HTTP 500-15 - 不允許請(qǐng)求 global.asa
Error 501 - 未實(shí)現(xiàn)
HTTP 502 - 網(wǎng)關(guān)錯(cuò)誤
2.4 使用telnet進(jìn)行http測(cè)試
在Windows下，可使用命令窗口進(jìn)行http簡(jiǎn)單測(cè)試。
輸入cmd進(jìn)入命令窗口，在命令行鍵入如下命令后按回車(chē)：
telnet www.baidu.com 80
而后在窗口中按下“Ctrl+]”后按回車(chē)可讓返回結(jié)果回顯。
接著開(kāi)始發(fā)請(qǐng)求消息，例如發(fā)送如下請(qǐng)求消息請(qǐng)求baidu的首頁(yè)消息，使用的HTTP協(xié)議為HTTP/1.1：
GET /index.html HTTP/1.1
注意：copy如上的消息到命令窗口后需要按兩個(gè)回車(chē)換行才能得到響應(yīng)的消息，第一個(gè)回車(chē)換行是在命令后鍵入回車(chē)換行，是HTTP協(xié)議要求的。第二個(gè)是確認(rèn)輸入，發(fā)送請(qǐng)求。
可看到返回了200 OK的消息，如下圖所示：
可看到，當(dāng)采用HTTP/1.1時(shí)，連接不是在請(qǐng)求結(jié)束后就斷開(kāi)的。若采用HTTP1.0，在命令窗口鍵入：
GET /index.html HTTP/1.0
此時(shí)可以看到請(qǐng)求結(jié)束之后馬上斷開(kāi)。
讀者還可以嘗試在使用GET或POST等時(shí)，帶上頭域信息，例如鍵入如下信息：
GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com
2.5 常用的請(qǐng)求方式
常用的請(qǐng)求方式是GET和POST.
GET方式：是以實(shí)體的方式得到由請(qǐng)求URI所指定資源的信息，如果請(qǐng)求URI只是一個(gè)數(shù)據(jù)產(chǎn)生過(guò)程，那么最終要在響應(yīng)實(shí)體中返回的是處理過(guò)程的結(jié)果所指向的資源，而不是處理過(guò)程的描述。
POST方式：用來(lái)向目的服務(wù)器發(fā)出請(qǐng)求，要求它接受被附在請(qǐng)求后的實(shí)體，并把它當(dāng)作請(qǐng)求隊(duì)列中請(qǐng)求URI所指定資源的附加新子項(xiàng)，Post被設(shè)計(jì)成用統(tǒng)一的方法實(shí)現(xiàn)下列功能：
1：對(duì)現(xiàn)有資源的解釋;
2：向電子公告欄、新聞組、郵件列表或類(lèi)似討論組發(fā)信息;
3：提交數(shù)據(jù)塊;
4：通過(guò)附加操作來(lái)擴(kuò)展數(shù)據(jù)庫(kù) 。
從上面描述可以看出，Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請(qǐng)求;而Post是向服務(wù)器提交數(shù)據(jù)的一種請(qǐng)求，要提交的數(shù)據(jù)位于信息頭后面的實(shí)體中。
GET與POST方法有以下區(qū)別：
(1) 在客戶(hù)端，Get方式在通過(guò)URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到;POST方式，數(shù)據(jù)放置在HTML HEADER內(nèi)提交。
(2) GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒(méi)有此限制。
(3) 安全性問(wèn)題。正如在(1)中提到，使用 Get 的時(shí)候，參數(shù)會(huì)顯示在地址欄上，而 Post 不會(huì)。所以，如果這些數(shù)據(jù)是中文數(shù)據(jù)而且是非敏感數(shù)據(jù)，那么使用 get;如果用戶(hù)輸入的數(shù)據(jù)不是中文字符而且包含敏感數(shù)據(jù)，那么還是使用 post為好。
(4) 安全的和冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。冪等的意味著對(duì)同一 URL 的多個(gè)請(qǐng)求應(yīng)該返回同樣的結(jié)果。完整的定義并不像看起來(lái)那樣嚴(yán)格。換句話(huà)說(shuō)，GET 請(qǐng)求一般不應(yīng)產(chǎn)生副作用。從根本上講，其目標(biāo)是當(dāng)用戶(hù)打開(kāi)一個(gè)鏈接時(shí)，她可以確信從自身的角度來(lái)看沒(méi)有改變資源。比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請(qǐng)求會(huì)返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。反之亦然。POST 請(qǐng)求就不那么輕松了。POST 表示可能改變服務(wù)器上的資源的請(qǐng)求。仍然以新聞?wù)军c(diǎn)為例，讀者對(duì)文章的注解應(yīng)該通過(guò) POST 請(qǐng)求實(shí)現(xiàn)，因?yàn)樵谧⒔馓峤恢笳军c(diǎn)已經(jīng)不同了(比方說(shuō)文章下面出現(xiàn)一條注解)。
2.6 請(qǐng)求頭
HTTP最常見(jiàn)的請(qǐng)求頭如下：
Accept：瀏覽器可接受的MIME類(lèi)型;
Accept-Charset：瀏覽器可接受的字符集;
Accept-Encoding：瀏覽器能夠進(jìn)行解碼的數(shù)據(jù)編碼方式，比如gzip。Servlet能夠向支持gzip的瀏覽器返回經(jīng)gzip編碼的HTML頁(yè)面。許多情形下這可以減少5到10倍的下載時(shí)間;
Accept-Language：瀏覽器所希望的語(yǔ)言種類(lèi)，當(dāng)服務(wù)器能夠提供一種以上的語(yǔ)言版本時(shí)要用到;
Authorization：授權(quán)信息，通常出現(xiàn)在對(duì)服務(wù)器發(fā)送的WWW-Authenticate頭的應(yīng)答中;
Connection：表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”，或者看到請(qǐng)求使用的是HTTP 1.1(HTTP 1.1默認(rèn)進(jìn)行持久連接)，它就可以利用持久連接的優(yōu)點(diǎn)，當(dāng)頁(yè)面包含多個(gè)元素時(shí)(例如Applet，圖片)，顯著地減少下載所需要的時(shí)間。要實(shí)現(xiàn)這一點(diǎn)，Servlet需要在應(yīng)答中發(fā)送一個(gè)Content-Length頭，最簡(jiǎn)單的實(shí)現(xiàn)方法是：先把內(nèi)容寫(xiě)入ByteArrayOutputStream，然后在正式寫(xiě)出內(nèi)容之前計(jì)算它的大小;
Content-Length：表示請(qǐng)求消息正文的長(zhǎng)度;
Cookie：這是最重要的請(qǐng)求頭信息之一;
From：請(qǐng)求發(fā)送者的email地址，由一些特殊的Web客戶(hù)程序使用，瀏覽器不會(huì)用到它;
Host：初始URL中的主機(jī)和端口;
If-Modified-Since：只有當(dāng)所請(qǐng)求的內(nèi)容在指定的日期之后又經(jīng)過(guò)修改才返回它，否則返回304“Not Modified”應(yīng)答;
Pragma：指定“no-cache”值表示服務(wù)器必須返回一個(gè)刷新后的文檔，即使它是代理服務(wù)器而且已經(jīng)有了頁(yè)面的本地拷貝;
Referer：包含一個(gè)URL，用戶(hù)從該URL代表的頁(yè)面出發(fā)訪(fǎng)問(wèn)當(dāng)前請(qǐng)求的頁(yè)面。
User-Agent：瀏覽器類(lèi)型，如果Servlet返回的內(nèi)容與瀏覽器類(lèi)型有關(guān)則該值非常有用;
UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE瀏覽器所發(fā)送的非標(biāo)準(zhǔn)的請(qǐng)求頭，表示屏幕大小、顏色深度、操作系統(tǒng)和CPU類(lèi)型。
2.7 響應(yīng)頭
HTTP最常見(jiàn)的響應(yīng)頭如下所示：
Allow：服務(wù)器支持哪些請(qǐng)求方法(如GET、POST等);
Content-Encoding：文檔的編碼(Encode)方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類(lèi)型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時(shí)間。Java的GZIPOutputStream可以很方便地進(jìn)行g(shù)zip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應(yīng)該通過(guò)查看Accept-Encoding頭(即request.getHeader("Accept-Encoding"))檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁(yè)面，為其他瀏覽器返回普通頁(yè)面;
Content-Length：表示內(nèi)容長(zhǎng)度。只有當(dāng)瀏覽器使用持久HTTP連接時(shí)才需要這個(gè)數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢(shì)，可以把輸出文檔寫(xiě)入ByteArrayOutputStram，完成后查看其大小，然后把該值放入Content-Length頭，最后通過(guò)byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容;
Content-Type： 表示后面的文檔屬于什么MIME類(lèi)型。Servlet默認(rèn)為text/plain，但通常需要顯式地指定為text/html。由于經(jīng)常要設(shè)置Content-Type，因此HttpServletResponse提供了一個(gè)專(zhuān)用的方法setContentTyep。 可在web.xml文件中配置擴(kuò)展名和MIME類(lèi)型的對(duì)應(yīng)關(guān)系;
Date：當(dāng)前的GMT時(shí)間。你可以用setDateHeader來(lái)設(shè)置這個(gè)頭以避免轉(zhuǎn)換時(shí)間格式的麻煩;
Expires：指明應(yīng)該在什么時(shí)候認(rèn)為文檔已經(jīng)過(guò)期，從而不再緩存它。
Last-Modified：文檔的最后改動(dòng)時(shí)間?？蛻?hù)可以通過(guò)If-Modified-Since請(qǐng)求頭提供一個(gè)日期，該請(qǐng)求將被視為一個(gè)條件GET，只有改動(dòng)時(shí)間遲于指定時(shí)間的文檔才會(huì)返回，否則返回一個(gè)304(Not Modified)狀態(tài)。Last-Modified也可用setDateHeader方法來(lái)設(shè)置;
Location：表示客戶(hù)應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過(guò)HttpServletResponse的sendRedirect方法，該方法同時(shí)設(shè)置狀態(tài)代碼為302;
Refresh：表示瀏覽器應(yīng)該在多少時(shí)間之后刷新文檔，以秒計(jì)。除了刷新當(dāng)前文檔之外，你還可以通過(guò)setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁(yè)面。注意這種功能通常是通過(guò)設(shè)置HTML頁(yè)面HEAD區(qū)的 實(shí)現(xiàn)，這是因?yàn)?，自?dòng)刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的HTML編寫(xiě)者十分重要。但是，對(duì)于Servlet來(lái)說(shuō)，直接設(shè)置Refresh頭更加方便。注意Refresh的意義是“N秒之后刷新本頁(yè)面或訪(fǎng)問(wèn)指定頁(yè)面”，而不是“每隔N秒刷新本頁(yè)面或訪(fǎng)問(wèn)指定頁(yè)面”。因此，連續(xù)刷新要求每次都發(fā)送一個(gè)Refresh頭，而發(fā)送204狀態(tài)代碼則可以阻止瀏覽器繼續(xù)刷新，不管是使用Refresh頭還是 。注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分，而是一個(gè)擴(kuò)展，但Netscape和IE都支持它。
2.8實(shí)體頭
實(shí)體頭用坐實(shí)體內(nèi)容的元信息，描述了實(shí)體內(nèi)容的屬性，包括實(shí)體信息類(lèi)型，長(zhǎng)度，壓縮方法，最后一次修改時(shí)間，數(shù)據(jù)有效性等。
Allow：GET,POST
Content-Encoding：文檔的編碼(Encode)方法，例如：gzip，見(jiàn)“2.5 響應(yīng)頭”;
Content-Language：內(nèi)容的語(yǔ)言類(lèi)型，例如：zh-cn;
Content-Length：表示內(nèi)容長(zhǎng)度，eg：80，可參考“2.5響應(yīng)頭”;
Content-Location：表示客戶(hù)應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n，例如：http://www.dfdf.org/dfdf.html，可參考“2.5響應(yīng)頭”;
Content-MD5：MD5 實(shí)體的一種MD5摘要，用作校驗(yàn)和。發(fā)送方和接受方都計(jì)算MD5摘要，接受方將其計(jì)算的值與此頭標(biāo)中傳遞的值進(jìn)行比較。Eg1：Content-MD5:。Eg2：dfdfdfdfdfdfdff==;
Content-Range：隨部分實(shí)體一同發(fā)送;標(biāo)明被插入字節(jié)的低位與高位字節(jié)偏移，也標(biāo)明此實(shí)體的總長(zhǎng)度。Eg1：Content-Range: 1001-2000/5000，eg2：bytes 2543-4532/7898
Content-Type：標(biāo)明發(fā)送或者接收的實(shí)體的MIME類(lèi)型。Eg：text/html; charset=GB2312 主類(lèi)型/子類(lèi)型;
Expires：為0證明不緩存;
Last-Modified：WEB 服務(wù)器認(rèn)為對(duì)象的最后修改時(shí)間，比如文件的最后修改時(shí)間，動(dòng)態(tài)頁(yè)面的最后產(chǎn)生時(shí)間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT.
2.8擴(kuò)展頭
在HTTP消息中，也可以使用一些再HTTP1.1正式規(guī)范里沒(méi)有定義的頭字段，這些頭字段統(tǒng)稱(chēng)為自定義的HTTP頭或者擴(kuò)展頭，他們通常被當(dāng)作是一種實(shí)體頭處理。
現(xiàn)在流行的瀏覽器實(shí)際上都支持Cookie,Set-Cookie,Refresh和Content-Disposition等幾個(gè)常用的擴(kuò)展頭字段。
Refresh：1;url=http://www.dfdf.org //過(guò)1秒跳轉(zhuǎn)到指定位置;
Content-Disposition：頭字段,可參考“2.5響應(yīng)頭”;
Content-Type：WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的類(lèi)型。
eg1：Content-Type：application/xml ;
eg2：applicaiton/octet-stream;
3.1 Cookie和Session
Cookie和Session都為了用來(lái)保存狀態(tài)信息，都是保存客戶(hù)端狀態(tài)的機(jī)制，它們都是為了解決HTTP無(wú)狀態(tài)的問(wèn)題而所做的努力。
Session可以用Cookie來(lái)實(shí)現(xiàn)，也可以用URL回寫(xiě)的機(jī)制來(lái)實(shí)現(xiàn)。用Cookie來(lái)實(shí)現(xiàn)的Session可以認(rèn)為是對(duì)Cookie更高級(jí)的應(yīng)用。
3.1.1兩者比較
Cookie和Session有以下明顯的不同點(diǎn)：
1)Cookie將狀態(tài)保存在客戶(hù)端，Session將狀態(tài)保存在服務(wù)器端;
2)Cookies是服務(wù)器在本地機(jī)器上存儲(chǔ)的小段文本并隨每一個(gè)請(qǐng)求發(fā)送至同一個(gè)服務(wù)器。Cookie最早在RFC2109中實(shí)現(xiàn)，后續(xù)RFC2965做了增強(qiáng)。網(wǎng)絡(luò)服務(wù)器用HTTP頭向客戶(hù)端發(fā)送cookies，在客戶(hù)終端，瀏覽器解析這些cookies并將它們保存為一個(gè)本地文件，它會(huì)自動(dòng)將同一服務(wù)器的任何請(qǐng)求縛上這些cookies。Session并沒(méi)有在HTTP的協(xié)議中定義;
3)Session是針對(duì)每一個(gè)用戶(hù)的，變量的值保存在服務(wù)器上，用一個(gè)sessionID來(lái)區(qū)分是哪個(gè)用戶(hù)session變量,這個(gè)值是通過(guò)用戶(hù)的瀏覽器在訪(fǎng)問(wèn)的時(shí)候返回給服務(wù)器，當(dāng)客戶(hù)禁用cookie時(shí)，這個(gè)值也可能設(shè)置為由get來(lái)返回給服務(wù)器;
4)就安全性來(lái)說(shuō)：當(dāng)你訪(fǎng)問(wèn)一個(gè)使用session 的站點(diǎn)，同時(shí)在自己機(jī)子上建立一個(gè)cookie，建議在服務(wù)器端的SESSION機(jī)制更安全些.因?yàn)樗粫?huì)任意讀取客戶(hù)存儲(chǔ)的信息。
3.1.2 Session機(jī)制
Session機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器使用一種類(lèi)似于散列表的結(jié)構(gòu)(也可能就是使用散列表)來(lái)保存信息。
當(dāng)程序需要為某個(gè)客戶(hù)端的請(qǐng)求創(chuàng)建一個(gè)session的時(shí)候，服務(wù)器首先檢查這個(gè)客戶(hù)端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí) - 稱(chēng)為 session id，如果已包含一個(gè)session id則說(shuō)明以前已經(jīng)為此客戶(hù)端創(chuàng)建過(guò)session，服務(wù)器就按照session id把這個(gè) session檢索出來(lái)使用(如果檢索不到，可能會(huì)新建一個(gè))，如果客戶(hù)端請(qǐng)求不包含session id，則為此客戶(hù)端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個(gè) session id將被在本次響應(yīng)中返回給客戶(hù)端保存。
3.1.6 Session的實(shí)現(xiàn)方式
3.1.6.1 使用Cookie來(lái)實(shí)現(xiàn)
服務(wù)器給每個(gè)Session分配一個(gè)唯一的JSESSIONID，并通過(guò)Cookie發(fā)送給客戶(hù)端。
當(dāng)客戶(hù)端發(fā)起新的請(qǐng)求的時(shí)候，將在Cookie頭中攜帶這個(gè)JSESSIONID。這樣服務(wù)器能夠找到這個(gè)客戶(hù)端對(duì)應(yīng)的Session。
流程如下圖所示：
3.1.6.2 使用URL回顯來(lái)實(shí)現(xiàn)
URL回寫(xiě)是指服務(wù)器在發(fā)送給瀏覽器頁(yè)面的所有鏈接中都攜帶JSESSIONID的參數(shù)，這樣客戶(hù)端點(diǎn)擊任何一個(gè)鏈接都會(huì)把JSESSIONID帶會(huì)服務(wù)器。
如果直接在瀏覽器輸入服務(wù)端資源的url來(lái)請(qǐng)求該資源，那么Session是匹配不到的。
Tomcat對(duì)Session的實(shí)現(xiàn)，是一開(kāi)始同時(shí)使用Cookie和URL回寫(xiě)機(jī)制，如果發(fā)現(xiàn)客戶(hù)端支持Cookie，就繼續(xù)使用Cookie，停止使用URL回寫(xiě)。如果發(fā)現(xiàn)Cookie被禁用，就一直使用URL回寫(xiě)。jsp開(kāi)發(fā)處理到Session的時(shí)候，對(duì)頁(yè)面中的鏈接記得使用response.encodeURL() 。
3.1.3在J2EE項(xiàng)目中Session失效的幾種情況
1)Session超時(shí)：Session在指定時(shí)間內(nèi)失效，例如30分鐘，若在30分鐘內(nèi)沒(méi)有操作，則Session會(huì)失效，例如在web.xml中進(jìn)行了如下設(shè)置：
30//單位：分鐘
2)使用session.invalidate()明確的去掉Session。
3.1.4與Cookie相關(guān)的HTTP擴(kuò)展頭
1)Cookie：客戶(hù)端將服務(wù)器設(shè)置的Cookie返回到服務(wù)器;
2)Set-Cookie：服務(wù)器向客戶(hù)端設(shè)置Cookie;
3)Cookie2 (RFC2965))：客戶(hù)端指示服務(wù)器支持Cookie的版本;
4)Set-Cookie2 (RFC2965)：服務(wù)器向客戶(hù)端設(shè)置Cookie。
3.1.5Cookie的流程
服務(wù)器在響應(yīng)消息中用Set-Cookie頭將Cookie的內(nèi)容回送給客戶(hù)端，客戶(hù)端在新的請(qǐng)求中將相同的內(nèi)容攜帶在Cookie頭中發(fā)送給服務(wù)器。從而實(shí)現(xiàn)會(huì)話(huà)的保持。
流程如下圖所示：
3.2 緩存的實(shí)現(xiàn)原理
3.2.1什么是Web緩存
WEB緩存(cache)位于Web服務(wù)器和客戶(hù)端之間。
緩存會(huì)根據(jù)請(qǐng)求保存輸出內(nèi)容的副本，例如html頁(yè)面，圖片，文件，當(dāng)下一個(gè)請(qǐng)求來(lái)到的時(shí)候：如果是相同的URL，緩存直接使用副本響應(yīng)訪(fǎng)問(wèn)請(qǐng)求，而不是向源服務(wù)器再次發(fā)送請(qǐng)求。
HTTP協(xié)議定義了相關(guān)的消息頭來(lái)使WEB緩存盡可能好的工作。
3.2.2緩存的優(yōu)點(diǎn)
q 減少相應(yīng)延遲：因?yàn)檎?qǐng)求從緩存服務(wù)器(離客戶(hù)端更近)而不是源服務(wù)器被相應(yīng)，這個(gè)過(guò)程耗時(shí)更少，讓web服務(wù)器看上去相應(yīng)更快。
q 減少網(wǎng)絡(luò)帶寬消耗：當(dāng)副本被重用時(shí)會(huì)減低客戶(hù)端的帶寬消耗;客戶(hù)可以節(jié)省帶寬費(fèi)用，控制帶寬的需求的增長(zhǎng)并更易于管理。
3.2.3與緩存相關(guān)的HTTP擴(kuò)展消息頭
q Expires：指示響應(yīng)內(nèi)容過(guò)期的時(shí)間，格林威治時(shí)間GMT
q Cache-Control：更細(xì)致的控制緩存的內(nèi)容
q Last-Modified：響應(yīng)中資源最后一次修改的時(shí)間
q ETag：響應(yīng)中資源的校驗(yàn)值，在服務(wù)器上某個(gè)時(shí)段是唯一標(biāo)識(shí)的。
q Date：服務(wù)器的時(shí)間
q If-Modified-Since：客戶(hù)端存取的該資源最后一次修改的時(shí)間，同Last-Modified。
q If-None-Match：客戶(hù)端存取的該資源的檢驗(yàn)值，同ETag。
3.2.4客戶(hù)端緩存生效的常見(jiàn)流程
服務(wù)器收到請(qǐng)求時(shí)，會(huì)在200OK中回送該資源的Last-Modified和ETag頭，客戶(hù)端將該資源保存在cache中，并記錄這兩個(gè)屬性。當(dāng)客戶(hù)端需要發(fā)送相同的請(qǐng)求時(shí)，會(huì)在請(qǐng)求中攜帶If-Modified-Since和If-None-Match兩個(gè)頭。兩個(gè)頭的值分別是響應(yīng)中Last-Modified和ETag頭的值。服務(wù)器通過(guò)這兩個(gè)頭判斷本地資源未發(fā)生變化，客戶(hù)端不需要重新下載，返回304響應(yīng)。常見(jiàn)流程如下圖所示：
3.2.5 Web緩存機(jī)制
HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請(qǐng)求，同時(shí)在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量;HTTP利用一個(gè)“過(guò)期(expiration)”機(jī)制來(lái)為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬;HTTP用“驗(yàn)證(validation)”機(jī)制來(lái)為此目的。
HTTP定義了3種緩存機(jī)制：
1)Freshness：允許一個(gè)回應(yīng)消息可以在源服務(wù)器不被重新檢查，并且可以由服務(wù)器和客戶(hù)端來(lái)控制。例如，Expires回應(yīng)頭給了一個(gè)文檔不可用的時(shí)間。Cache-Control中的max-age標(biāo)識(shí)指明了緩存的最長(zhǎng)時(shí)間;
2)Validation：用來(lái)檢查以一個(gè)緩存的回應(yīng)是否仍然可用。例如，如果一個(gè)回應(yīng)有一個(gè)Last-Modified回應(yīng)頭，緩存能夠使用If-Modified-Since來(lái)判斷是否已改變，以便判斷根據(jù)情況發(fā)送請(qǐng)求;
3)Invalidation： 在另一個(gè)請(qǐng)求通過(guò)緩存的時(shí)候，常常有一個(gè)副作用。例如，如果一個(gè)URL關(guān)聯(lián)到一個(gè)緩存回應(yīng)，但是其后跟著POST、PUT和DELETE的請(qǐng)求的話(huà)，緩存就會(huì)過(guò)期。
3.3 斷點(diǎn)續(xù)傳和多線(xiàn)程下載的實(shí)現(xiàn)原理
q HTTP協(xié)議的GET方法，支持只請(qǐng)求某個(gè)資源的某一部分;
q 206 Partial Content 部分內(nèi)容響應(yīng);
q Range 請(qǐng)求的資源范圍;
q Content-Range 響應(yīng)的資源范圍;
q 在連接斷開(kāi)重連時(shí)，客戶(hù)端只請(qǐng)求該資源未下載的部分，而不是重新請(qǐng)求整個(gè)資源，來(lái)實(shí)現(xiàn)斷點(diǎn)續(xù)傳。
分塊請(qǐng)求資源實(shí)例：
Eg1：Range: bytes=306302- ：請(qǐng)求這個(gè)資源從306302個(gè)字節(jié)到末尾的部分;
Eg2：Content-Range: bytes 306302-604047/604048：響應(yīng)中指示攜帶的是該資源的第306302-604047的字節(jié)，該資源共604048個(gè)字節(jié);
客戶(hù)端通過(guò)并發(fā)的請(qǐng)求相同資源的不同片段，來(lái)實(shí)現(xiàn)對(duì)某個(gè)資源的并發(fā)分塊下載。從而達(dá)到快速下載的目的。目前流行的FlashGet和迅雷基本都是這個(gè)原理。
多線(xiàn)程下載的原理：
q 下載工具開(kāi)啟多個(gè)發(fā)出HTTP請(qǐng)求的線(xiàn)程;
q 每個(gè)http請(qǐng)求只請(qǐng)求資源文件的一部分：Content-Range: bytes 20000-40000/47000;
q 合并每個(gè)線(xiàn)程下載的文件。
3.4 https通信過(guò)程
3.4.1什么是https
HTTPS(全稱(chēng)：Hypertext Transfer Protocol over Secure Socket Layer)，是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容請(qǐng)看SSL。
見(jiàn)下圖：
https所用的端口號(hào)是443。
3.4.2 https的實(shí)現(xiàn)原理
有兩種基本的加解密算法類(lèi)型：
1)對(duì)稱(chēng)加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對(duì)稱(chēng)加密算法有DES、AES等;
2)非對(duì)稱(chēng)加密：密鑰成對(duì)出現(xiàn)(且根據(jù)公鑰無(wú)法推知私鑰，根據(jù)私鑰也無(wú)法推知公鑰)，加密解密使用不同密鑰(公鑰加密需要私鑰解密，私鑰加密需要公鑰解密)，相對(duì)對(duì)稱(chēng)加密速度較慢，典型的非對(duì)稱(chēng)加密算法有RSA、DSA等。
下面看一下https的通信過(guò)程：
https通信的優(yōu)點(diǎn)：
1)客戶(hù)端產(chǎn)生的密鑰只有客戶(hù)端和服務(wù)器端能得到;
2)加密的數(shù)據(jù)只有客戶(hù)端和服務(wù)器端才能得到明文;
3)客戶(hù)端到服務(wù)端的通信是安全的。
3.5 http代理
3.5.1 http代理服務(wù)器
代理服務(wù)器英文全稱(chēng)是Proxy Server，其功能就是代理網(wǎng)絡(luò)用戶(hù)去取得網(wǎng)絡(luò)信息。形象的說(shuō)：它是網(wǎng)絡(luò)信息的中轉(zhuǎn)站。
代理服務(wù)器是介于瀏覽器和Web服務(wù)器之間的一臺(tái)服務(wù)器，有了它之后，瀏覽器不是直接到Web服務(wù)器去取回網(wǎng)頁(yè)而是向代理服務(wù)器發(fā)出請(qǐng)求，Request信號(hào)會(huì)先送到代理服務(wù)器，由代理服務(wù)器來(lái)取回瀏覽器所需要的信息并傳送給你的瀏覽器。
而且，大部分代理服務(wù)器都具有緩沖的功能，就好象一個(gè)大的Cache，它有很大的存儲(chǔ)空間，它不斷將新取得數(shù)據(jù)儲(chǔ)存到它本機(jī)的存儲(chǔ)器上，如果瀏覽器所請(qǐng)求的數(shù)據(jù)在它本機(jī)的存儲(chǔ)器上已經(jīng)存在而且是最新的，那么它就不重新從Web服務(wù)器取數(shù)據(jù)，而直接將存儲(chǔ)器上的數(shù)據(jù)傳送給用戶(hù)的瀏覽器，這樣就能顯著提高瀏覽速度和效率。
更重要的是：Proxy Server(代理服務(wù)器)是Internet鏈路級(jí)網(wǎng)關(guān)所提供的一種重要的安全功能，它的工作主要在開(kāi)放系統(tǒng)互聯(lián)(OSI)模型的對(duì)話(huà)層。
3.5.2 http代理服務(wù)器的主要功能
主要功能如下：
1)突破自身IP訪(fǎng)問(wèn)限制，訪(fǎng)問(wèn)國(guó)外站點(diǎn)。如：教育網(wǎng)、169網(wǎng)等網(wǎng)絡(luò)用戶(hù)可以通過(guò)代理訪(fǎng)問(wèn)國(guó)外網(wǎng)站;
2)訪(fǎng)問(wèn)一些單位或團(tuán)體內(nèi)部資源，如某大學(xué)FTP(前提是該代理地址在該資源的允許訪(fǎng)問(wèn)范圍之內(nèi))，使用教育網(wǎng)內(nèi)地址段免費(fèi)代理服務(wù)器，就可以用于對(duì)教育 網(wǎng)開(kāi)放的各類(lèi)FTP下載上傳，以及各類(lèi)資料查詢(xún)共享等服務(wù);
3)突破中國(guó)電信的IP封鎖：中國(guó)電信用戶(hù)有很多網(wǎng)站是被限制訪(fǎng)問(wèn)的，這種限制是人為的，不同Serve對(duì)地址的封鎖是不同的。所以不能訪(fǎng)問(wèn)時(shí)可以換一個(gè)國(guó) 外的代理服務(wù)器試試;
4)提高訪(fǎng)問(wèn)速度：通常代理服務(wù)器都設(shè)置一個(gè)較大的硬盤(pán)緩沖區(qū)，當(dāng)有外界的信息通過(guò)時(shí)，同時(shí)也將其保存到緩沖區(qū)中，當(dāng)其他用戶(hù)再訪(fǎng)問(wèn)相同的信息時(shí)， 則直接由緩沖區(qū)中取出信息，傳給用戶(hù)，以提高訪(fǎng)問(wèn)速度;
5)隱藏真實(shí)IP：上網(wǎng)者也可以通過(guò)這種方法隱藏自己的IP，免受攻擊。
3.5.3 http代理圖示
http代理的圖示見(jiàn)下圖：
對(duì)于客戶(hù)端瀏覽器而言，http代理服務(wù)器相當(dāng)于服務(wù)器。
而對(duì)于Web服務(wù)器而言，http代理服務(wù)器又擔(dān)當(dāng)了客戶(hù)端的角色。
3.6 虛擬主機(jī)的實(shí)現(xiàn)
3.6.1什么是虛擬主機(jī)
虛擬主機(jī)：是在網(wǎng)絡(luò)服務(wù)器上劃分出一定的磁盤(pán)空間供用戶(hù)放置站點(diǎn)、應(yīng)用組件等，提供必要的站點(diǎn)功能與數(shù)據(jù)存放、傳輸功能。
所謂虛擬主機(jī)，也叫“網(wǎng)站空間”就是把一臺(tái)運(yùn)行在互聯(lián)網(wǎng)上的服務(wù)器劃分成多個(gè)“虛擬”的服務(wù)器，每一個(gè)虛擬主機(jī)都具有獨(dú)立的域名和完整的Internet服務(wù)器(支持WWW、FTP、E-mail等)功能。一臺(tái)服務(wù)器上的不同虛擬主機(jī)是各自獨(dú)立的，并由用戶(hù)自行管理。但一臺(tái)服務(wù)器主機(jī)只能夠支持一定數(shù)量的虛擬主機(jī)，當(dāng)超過(guò)這個(gè)數(shù)量時(shí)，用戶(hù)將會(huì)感到性能急劇下降。
3.6.2虛擬主機(jī)的實(shí)現(xiàn)原理
虛擬主機(jī)是用同一個(gè)WEB服務(wù)器，為不同域名網(wǎng)站提供服務(wù)的技術(shù)。Apache、Tomcat等均可通過(guò)配置實(shí)現(xiàn)這個(gè)功能。
相關(guān)的HTTP消息頭：Host。
例如：Host: www.baidu.com
客戶(hù)端發(fā)送HTTP請(qǐng)求的時(shí)候，會(huì)攜帶Host頭，Host頭記錄的是客戶(hù)端輸入的域名。這樣服務(wù)器可以根據(jù)Host頭確認(rèn)客戶(hù)要訪(fǎng)問(wèn)的是哪一個(gè)域名。
