http協議學習系列

時間 2019-11-30

原文原文鏈接

http協議學習系列
html

1. 基礎概念篇

1.1 介紹

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。java

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。web

HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。算法

1.2 在TCP/IP協議棧中的位置

HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。以下圖所示：
數據庫

默認HTTP的端口號爲80，HTTPS的端口號爲443。瀏覽器

1.3 HTTP的請求響應模型

HTTP協議永遠都是客戶端發起請求，服務器回送響應。見下圖：
緩存

這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。安全

HTTP協議是一個無狀態的協議，同一個客戶端的此次請求和上次請求是沒有對應關係。服務器

1.4 工做流程

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：cookie

1）首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。

2）創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。

3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。

4）客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。

若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

1.5 使用Wireshark抓TCP、http包

打開Wireshark，選擇工具欄上的「Capture」->「Options」，界面選擇如圖1所示：

圖1 設置Capture選項

通常讀者只須要選擇最上邊的下拉框，選擇合適的Device，然後點擊「Capture Filter」，此處選擇的是「HTTP TCP port（80）」，選擇後點擊上圖的「Start」開始抓包。

圖2 選擇Capture Filter

例如在瀏覽器中打開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

圖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

……

1.6 頭域

每一個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前能夠添加任何數量的空格符，頭域能夠被擴展爲多行，在每行開始處，使用至少一個空格或製表符。

在抓包的圖中，No14點開可看到如圖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

圖4 http請求消息

迴應的消息如圖5所示：

圖5 http狀態響應信息

1.6.1 host頭域

Host頭域指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，不然系統會以400狀態碼返回。

圖5中host那行爲：

1.6.2 Referer頭域

Referer頭域容許客戶端指定請求uri的源資源地址，這能夠容許服務器生成回退鏈表，可用來登錄、優化cache等。他也容許廢除的或錯誤的鏈接因爲維護的目的被追蹤。若是請求的uri沒有本身的uri地址，Referer不能被髮送。若是指定的是部分uri地址，則此地址應該是一個相對地址。

在圖4中，Referer行的內容爲：

1.6.3 User-Agent頭域

User-Agent頭域的內容包含發出請求的用戶信息。

在圖4中，User-Agent行的內容爲：
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指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置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中的該頭域爲：

1.6.5 Date頭域

Date頭域表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，須要知道用戶所在的時區。

圖5中，該頭域以下圖所示：

1.7 HTTP的幾個重要概念

1.7.1鏈接：Connection

一個傳輸層的實際環流，它是創建在兩個相互通信的應用程序之間。

在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連接了。

1.7.2消息：Message

HTTP通信的基本單位，包括一個結構化的八元組序列並經過鏈接傳輸。

1.7.3請求：Request

一個從客戶端到服務器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號。

1.7.4響應：Response

一個從服務器返回的信息包括HTTP協議的版本號、請求的狀態(例如「成功」或「沒找到」)和文檔的MIME類型。

1.7.5資源：Resource

由URI標識的網絡數據對象或服務。

1.7.6實體：Entity

數據資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的自己內容。

1.7.7客戶機：Client

一個爲發送請求目的而創建鏈接的應用程序。

1.7.8用戶代理：UserAgent

初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。

1.7.9服務器：Server

一個接受鏈接並對請求返回信息的應用程序。

1.7.10源服務器：Originserver

是一個給定資源能夠在其上駐留或被建立的服務器。

1.7.11代理：Proxy

一箇中間程序，它能夠充當一個服務器，也能夠充當一個客戶機，爲其它客戶機創建請求。請求是經過可能的翻譯在內部或通過傳遞到其它的服務器中。一個代理在發送請求信息以前，必須解釋而且若是可能重寫它。

代理常常做爲經過防火牆的客戶機端的門戶，代理還能夠做爲一個幫助應用來經過協議處理沒有被用戶代理完成的請求。

1.7.12網關：Gateway

一個做爲其它服務器中間媒介的服務器。與代理不一樣的是，網關接受請求就好象對被請求的資源來講它就是源服務器；發出請求的客戶機並無意識到它在同網關打交道。

網關常常做爲經過防火牆的服務器端的門戶，網關還能夠做爲一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。

1.7.13通道：Tunnel

是做爲兩個鏈接中繼的中介程序。一旦激活，通道便被認爲不屬於HTTP通信，儘管通道多是被一個HTTP請求初始化的。當被中繼的鏈接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通信時通道被常用。

1.7.14緩存：Cache

反應信息的局域存儲。

附錄：參考資料

《http_百度百科》：http://baike.baidu.com/view/9472.htm

《結果編碼和http狀態響應碼》：http://blog.tieniu1980.cn/archives/377

《分析TCP的三次握手》：

http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747e0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu

《使用Wireshark來檢測一次HTTP鏈接過程》：

http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/

《http協議的幾個重要概念》：http://nc.mofcom.gov.cn/news/10819972.html

《http協議中connection頭的做用》：

http://blog.csdn.net/barfoo/archive/2008/06/05/2514667.aspx

2. 協議詳解篇

2.1 HTTP/1.0和HTTP/1.1的比較

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

2.1.1創建鏈接方面

HTTP/1.0 每次請求都須要創建新的TCP鏈接，鏈接不能複用。HTTP/1.1 新的請求能夠在上次請求創建的TCP鏈接之上發送，鏈接能夠複用。優勢是減小重複進行TCP三次握手的開銷，提升效率。

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

2.1.2 Host域

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。

2.1.3日期時間戳

(接收方向)

不管是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。

2.1.4狀態響應碼

狀態響應碼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中還增長了10一、20三、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：

GET /index.html HTTP/1.1

Eg2：

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

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

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：

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的狀態響應碼

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進入命令窗口，在命令行鍵入以下命令後按回車：

telnet www.baidu.com 80

然後在窗口中按下「Ctrl+]」後按回車可以讓返回結果回顯。

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

GET /index.html HTTP/1.1

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

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

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

GET /index.html HTTP/1.0

此時能夠看到請求結束以後立刻斷開。

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

GET /index.html HTTP/1.1
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 請求實現，由於在註解提交以後站點已經不一樣了（比方說文章下面出現一條註解）。

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，而後在正式寫出內容以前計算它的大小；

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 四、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.blogjava.net/honeybee/articles/164008.html

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

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

《實體頭和擴展頭》：

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

3. 深刻了解篇

3.1 Cookie和Session

Cookie和Session都爲了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是爲了解決HTTP無狀態的問題而所作的努力。

Session能夠用Cookie來實現，也能夠用URL回寫的機制來實現。用Cookie來實現的Session能夠認爲是對Cookie更高級的應用。

3.1.1二者比較

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機制更安全些.由於它不會任意讀取客戶存儲的信息。

3.1.2 Session機制

Session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。

當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲 session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個 session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個 session id將被在本次響應中返回給客戶端保存。

3.1.6 Session的實現方式

3.1.6.1 使用Cookie來實現

服務器給每一個Session分配一個惟一的JSESSIONID，並經過Cookie發送給客戶端。

當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器可以找到這個客戶端對應的Session。

流程以下圖所示：

3.1.6.2 使用URL回顯來實現

URL回寫是指服務器在發送給瀏覽器頁面的全部連接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個連接都會把JSESSIONID帶會服務器。

若是直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。

Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，若是發現客戶端支持Cookie，就繼續使用Cookie，中止使用URL回寫。若是發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的連接記得使用response.encodeURL() 。

3.1.3在J2EE項目中Session失效的幾種狀況

1）Session超時：Session在指定時間內失效，例如30分鐘，若在30分鐘內沒有操做，則Session會失效，例如在web.xml中進行了以下設置：

<session-config>
<session-timeout>30</session-timeout> //單位：分鐘
</session-config>

2）使用session.invalidate()明確的去掉Session。

3.1.4與Cookie相關的HTTP擴展頭

1）Cookie：客戶端將服務器設置的Cookie返回到服務器；

2）Set-Cookie：服務器向客戶端設置Cookie；

3）Cookie2 (RFC2965)）：客戶端指示服務器支持Cookie的版本；

4）Set-Cookie2 (RFC2965)：服務器向客戶端設置Cookie。

3.1.5Cookie的流程

服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。

流程以下圖所示：

3.2 緩存的實現原理

3.2.1什麼是Web緩存

WEB緩存(cache)位於Web服務器和客戶端之間。

緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：若是是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。

HTTP協議定義了相關的消息頭來使WEB緩存儘量好的工做。

3.2.2緩存的優勢

q 減小相應延遲：由於請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。

q 減小網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶能夠節省帶寬費用，控制帶寬的需求的增加並更易於管理。

3.2.3與緩存相關的HTTP擴展消息頭

q Expires：指示響應內容過時的時間，格林威治時間GMT

q Cache-Control：更細緻的控制緩存的內容

q Last-Modified：響應中資源最後一次修改的時間

q ETag：響應中資源的校驗值，在服務器上某個時段是惟一標識的。

q Date：服務器的時間

q If-Modified-Since：客戶端存取的該資源最後一次修改的時間，同Last-Modified。

q If-None-Match：客戶端存取的該資源的檢驗值，同ETag。

3.2.4客戶端緩存生效的常見流程

服務器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端須要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器經過這兩個頭判斷本地資源未發生變化，客戶端不須要從新下載，返回304響應。常見流程以下圖所示：

3.2.5 Web緩存機制

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的請求的話，緩存就會過時。

3.3 斷點續傳和多線程下載的實現原理

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 合併每一個線程下載的文件。

3.4 https通訊過程

3.4.1什麼是https

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容請看SSL。

見下圖：

https所用的端口號是443。

3.4.2 https的實現原理

有兩種基本的加解密算法類型：

1）對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；

2）非對稱加密：密鑰成對出現（且根據公鑰沒法推知私鑰，根據私鑰也沒法推知公鑰），加密解密使用不一樣密鑰（公鑰加密須要私鑰解密，私鑰加密須要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

下面看一下https的通訊過程：

https通訊的優勢：

1）客戶端產生的密鑰只有客戶端和服務器端能獲得；

2）加密的數據只有客戶端和服務器端才能獲得明文；

3）客戶端到服務端的通訊是安全的。

3.5 http代理

3.5.1 http代理服務器

代理服務器英文全稱是Proxy Server，其功能就是代理網絡用戶去取得網絡信息。形象的說：它是網絡信息的中轉站。

代理服務器是介於瀏覽器和Web服務器之間的一臺服務器，有了它以後，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，Request信號會先送到代理服務器，由代理服務器來取回瀏覽器所須要的信息並傳送給你的瀏覽器。

並且，大部分代理服務器都具備緩衝的功能，就好象一個大的Cache，它有很大的存儲空間，它不斷將新取得數據儲存到它本機的存儲器上，若是瀏覽器所請求的數據在它本機的存儲器上已經存在並且是最新的，那麼它就不從新從Web服務器取數據，而直接將存儲器上的數據傳送給用戶的瀏覽器，這樣就能顯著提升瀏覽速度和效率。

更重要的是：Proxy Server(代理服務器)是Internet鏈路級網關所提供的一種重要的安全功能，它的工做主要在開放系統互聯(OSI)模型的對話層。

3.5.2 http代理服務器的主要功能

主要功能以下：

1）突破自身IP訪問限制，訪問國外站點。如：教育網、169網等網絡用戶能夠經過代理訪問國外網站；

2）訪問一些單位或團體內部資源，如某大學FTP(前提是該代理地址在該資源的容許訪問範圍以內)，使用教育網內地址段免費代理服務器，就能夠用於對教育網開放的各種FTP下載上傳，以及各種資料查詢共享等服務；

3）突破中國電信的IP封鎖：中國電信用戶有不少網站是被限制訪問的，這種限制是人爲的，不一樣Serve對地址的封鎖是不一樣的。因此不能訪問時能夠換一個國外的代理服務器試試；

4）提升訪問速度：一般代理服務器都設置一個較大的硬盤緩衝區，當有外界的信息經過時，同時也將其保存到緩衝區中，當其餘用戶再訪問相同的信息時，則直接由緩衝區中取出信息，傳給用戶，以提升訪問速度；

5）隱藏真實IP：上網者也能夠經過這種方法隱藏本身的IP，免受攻擊。

3.5.3 http代理圖示

http代理的圖示見下圖：

對於客戶端瀏覽器而言，http代理服務器至關於服務器。

而對於Web服務器而言，http代理服務器又擔當了客戶端的角色。

3.6 虛擬主機的實現

3.6.1什麼是虛擬主機

虛擬主機：是在網絡服務器上劃分出必定的磁盤空間供用戶放置站點、應用組件等，提供必要的站點功能與數據存放、傳輸功能。

所謂虛擬主機，也叫「網站空間」就是把一臺運行在互聯網上的服務器劃分紅多個「虛擬」的服務器，每個虛擬主機都具備獨立的域名和完整的Internet服務器（支持WWW、FTP、E-mail等）功能。一臺服務器上的不一樣虛擬主機是各自獨立的，並由用戶自行管理。但一臺服務器主機只可以支持必定數量的虛擬主機，當超過這個數量時，用戶將會感到性能急劇降低。