由淺入深看HTTP

一. HTTP協議的應用簡單概況javascript

HTTP協議的主要特色可歸納以下：html

1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。java

HTTP協議對其用戶來說實際上是透明的，不一樣於如SMTP等協議的是，HTTP的報文並不是是直接交付給用戶去看的，最多見的場合是HTTP協議將超文本交付給瀏覽器或者其餘超文本解析的軟件來進行處理，超文本可使用任意的標籤語言如HTML，XSL，XML，XHTML。web

（1）靜態超文本數據庫

客戶端直接經過URL請求到服務端相對應的資源，服務端直接將部署在數據庫或者文件系統中的標籤語言文件返還給客戶端，其中能夠包括其餘的URL來使得客戶端再次和網絡中的其餘主機發送HTTP請求來遞歸地完成超文本的解析，如HTML中的img標籤。瀏覽器

（2）動態超文本緩存

動態超文本須要經過軟件技術來實現建立和處理動態文本，例如CGI，JavaServlet等技術，將URL中‘？’以後的動態部分作解析並生成動態文檔，而且能夠嵌入腳本語言交付給瀏覽器中的解析引擎來提升動態文檔的效率，使文檔中沒必要要的重複的部分獨立解析完成，甚至能夠實現活動文檔，直接在文檔上運行字節碼形式的java程序或者javascript腳本。安全

二. HTTP運行事務服務器

（1）HTTP報文分組cookie

以下兩圖所示，爲通用的HTTP請求和響應報文模型

　　　　　　　　　　請求報文　　　　　　　　　　　　　　　　　　　　　　　響應報文

1.請求報文

一個HTTP的完整請求報文的具體格式以下：

A.請求行--方法：

GET：請求服務器的文檔

HEAD：請求關於文檔的信息，但不是這個文檔自己

POST：從客戶向服務器發送一些信息

PUT：從服務器向客戶發送文檔

TRACE：把到達的請求回送

CONNECT：保留

DELETE：刪除Web網頁

OPTIONs：詢問關於可用的選項

B.請求行--URL：

URL：統一資源定位符，是在因特網上知名任何種類的信息的標準，URL定義的是四樣東西：

協議：// 主機：端口 / 路徑

具體詳細不屬於HTTP內容範疇，暫且不贅述。

C.請求行--版本：

目前HTTP的最新版本是1.1，舊版本還有1.0等，具體相關定義在對應RFC中能夠查找。

D.請求報文的首部行：（個別書上也把這個叫作頭域）

首部行是客戶向服務器發送信息時的附加信息，數量爲零到多個，如上圖所示的格式，每一個首部行佔有一個首部名，一個冒號，一個空格和一個首部值。在RFC中完整的首部值列表及分類以下所示：（其中上顏色的爲較經常使用首部名稱）

a.通用首部：既能夠出如今請求報文中，也能夠出如今響應報文中。這些是客戶端和服務器均可以使用的通用首部。能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能。不論報文是何種類型，都爲其提供一些有用的信息。例如無論是構建請求報文仍是響應報文，建立報文的日期時間都是同一個意思，所以提供這類信息的首部對這兩種類型的報文來講都是通用的。下面用表格的形式給出通用的信息性首部。

通用的信息性首部：

首部　　　　　　　　　　描述
Connection 　　　　　　容許客戶端和服務器指定與請求/響應鏈接有關的選項
Date 　　　　　　　　　提供日期和時間標誌，說明報文是什麼時間建立的
MIME-Version 　　　　　給出了發送端使用的MIME版本
Trailer 　　　　　　　　　若是報文采用了分塊傳輸編碼(chunked transfer encoding)方式，就能夠用這個首部列出位於報文拖鞋 (trailer)部分的首部集合。
Transfer-Encoding 　　告知接收端爲了保證報文的可靠傳輸，對報文采用了什麼編碼方式。
Update 　　　　　　　　給出了發送端可能想要"升級"使用的新版本或協議
Via 　　　　　　　　　　顯示了報文通過的中間節點(代理、網關)

通用緩存首部：

首部　　　　　　　　　　描述
Cache-Control 　　　　用於隨報文傳送緩存指示
Pragma 　　　　　　　　另外一種隨報文傳送指示的方式，但並不專用於緩存

b.請求首部：提供更多有關請求的信息。請求首部是在請求報文中有意義的首部。用於說明是誰或什麼在發送請求，請求源自何處，或者客戶端的喜愛及能力。服務器能夠根據請求首部給出的客戶端的信息，試着爲客戶端提供更好的響應。

首部　　　　　　　　　　　　描述
Client-IP 　　　　　　　　　　提供了運行客戶端的機器的IP地址
From 　　　　　　　　　　　提供了客戶端用戶的E-mail地址
Host 　　　　　　　　　　　給出了接收請求的服務器的主機名和端口號
Referer 　　　　　　　　　　提供了包含當前請求URI的文檔的URL
UA-Color 　　　　　　　　　提供了與客戶端顯示器的顯示顏色有關的信息
UA-CPU 　　　　　　　　　　給出了客戶端CPU的類型或製造商
US-Disp 　　　　　　　　　　提供了與客戶端顯示器(屏幕)能力有關的信息
US-OS 　　　　　　　　　　給出了客戶端顯示器的像素信息
UA-Pixels 　　　　　　　　　提供了客戶端顯示器的像素信息
User-Agent 　　　　　　　　將發起請求的應用程序名稱告知服務器(User-Agent)用戶代理

Accept首部爲客戶端提供了一種將其喜愛和能力告知服務器的方式，包括他們想要什麼，可使用什麼，以及最重要的，他們不想要什麼。這樣服務器就能夠根據這些額外信息，對要發送的內容作出更明智的決定。Accept首部會使鏈接的兩端都受益。客戶端會獲得他們想要的內容，服務器則不會浪費其時間和帶寬來發送客戶端沒法使用的東西。

首部　　　　　　　　　　描述
Accept 　　　　　　　　告訴服務器可以發送哪些媒體類型
Accept-Charset 　　　　告訴服務器可以發送哪些字符集
Accept-Encoding 　　　　告訴服務器可以發送哪些編碼方式
Accept-Language 　　　告訴服務器可以發送哪些語言
TE 　　　　　　　　　　　告訴服務器可使用哪些擴展傳輸編碼

條件請求首部：有時客戶端但願爲請求加上某些限制。好比客戶端已經有了一份副本，就但願只在服務器上的文檔與客戶端擁有的副本有所區別時，才請求服務器傳輸文檔。經過條件請求首部，客戶端就能夠加上這種限制，要求服務器在對請求進行相應以前，確保某個請求爲真。

首部　　　　　　　　　　描述
Expect 　　　　　　　　容許客戶端列出某請求所要求的服務器行爲
If-Match 　　　　　　　　若是實體標記與文檔當前的實體標記相匹配，就或者這份文檔
If-Modified-Since 　　　　除非在某個指定的日期以後資源被修改過，不然就限制這個請求
If-Range 　　　　　　　　容許對文檔的某個範圍進行條件請求
If-Unmodified-Since 　　除非在某個指定的日期以後資源沒有被修改過，不然就限制這個請求
Range 　　　　　　　　　若是服務器支持範圍請求，就請求資源的指定範圍

安全請求首部：HTTP自己就支持一種簡單的機制，能夠對請求進行質詢/響應認證。這種機制要求客戶端在獲取特定的資源以前，先對自身進行認證，這樣就可使事務稍微安全一些。

首部　　　　　　　　　　描述
Authorization 　　　　　包含了客戶端提供給服務器，以便對其自身進行認證的數據
Cookie 　　　　　　　　　客戶端用它想服務器傳送一個令牌-他並非真正的安全首部，但倒是隱含了安全功能
Cookie2 　　　　　　　　用來講明請求端支持的cookie版本

代理請求首部：隨着因特網上代理的廣泛應用，人們定義了幾個首部來協助其更好地工做。

首部　　　　　　　　　　描述
Max-Forword 　　　　　在通往源端服務器的路徑上，將請求轉發給其餘代理或網關的最大次數-與TRACE方法一同使用
Proxy-Authorization 　　與Authorization首部相同，但這個首部是在與代理進行認證時使用的
Proxy-Connection 　　　與Connection首部相同，但這個首部是在於代理創建鏈接時使用的

c.響應首部：提供更多有關響應的信息。響應報文由本身的響應首部集。響應首部爲客戶端提供了一些額外的信息，好比誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些首部有助於客　　　　　戶端處理響應，並在未來發起更好的請求。

首部　　　　　　　　描述
Age 　　　　　　　　 (從最初建立開始)響應持續時間
Public 　　　　　　　服務器爲其資源支持的請求方法列表
Retry-After 　　　　若是資源不可用的話，再第二天期或時間重試
Server 　　　　　　　服務器應用程序軟件的名稱和版本
Title 　　　　　　　　對HTML文檔來講，就是HTML文檔的源端給出的標題
Warning 　　　　　　比緣由短語中更詳細的一些警告報文

協商首部：若是資源有多種表示方法-好比，若是服務器上有某文檔的法語和德語譯稿，HTTP/1.1能夠爲服務器和客戶端提供對資源進行協商的能力。

首部　　　　　　　　描述
Accept-Ranges 　　對此資源來講，服務器可接受的範圍類型
Vary 　　　　　　　服務器查看的其餘首部的列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最合適的資源版本發送給客戶端。

安全響應首部：

咱們已經看到過安全請求首部了，本質上這裏說的就是HTTP的質詢/響應認證機制的響應側。

首部　　　　　　　　描述

Proxy-Authenticate　來自代理的對客戶端的質詢列表
Set-Cookie　　　　不是真正的安全首部，但隱含有安全功能；能夠在客戶端設置一個令牌，以便服務器對客戶端進行標識。
Set-Cookie2　　　　與Set-Cookie相似。
WWW-Authenticate 來自服務器的對客戶端的質詢列表

d、實體首部：描述主體的長度和內容，或者資源自身。有不少首部能夠用來描述HTTP報文的負荷。因爲請求和響應文本中均可能包含實體部分，因此在這兩種類型的報文中均可能出現這些首部。實體首部提供了有關實體及其內容的大量信息，從有關對象類型的信息，到可以對資源使用的各類有效的請求方法。總之，實體首部能夠告知報文的接收者它在對什麼進行處理。

首部　　　　　　　描述
Allow 　　　　　　列出了能夠對此實體執行的請求方法
Location 　　　　告知客戶端實體實際上位於何處；用於將接收端定向到資源的位置上去

內容首部：內容首部提供了與實體內容有關的特定信息，說明了其類型、尺寸以及處理它所需的其餘有用信息。好比，Web瀏覽器能夠經過查看返回的內容類型，得知如何顯示對象。

首部　　　　　　　　　　　描述
Content-Base 　　　　　　解析主體中的相對URL時使用的基礎URL
Content-Encoding 　　　　對主體執行的任意編碼方式
Content-Language 　　　　理解主體時最適宜使用的天然語言
Content-Length 　　　　　主體的長度或尺寸
Content-Location 　　　　　資源實際所處的位置
Content-MD5 　　　　　　　主體的MD5校驗
Content-Range 　　　　　　在整個資源中此實體表示的字節範圍
Content-Type 　　　　　　這個主體的對象模型

實體緩存首部：通用的緩存首部說明了如何或何時進行緩存。實體的緩存首部提供了與被緩存實體有關的信息，好比驗證已緩存的資源副本是否仍然有效所需的信息，以及更好地估計已緩存資源合適失效所需的線索。

首部　　　　　　描述
ETag 　　　　　與此實體有關的實體標記
Expires 　　　　實體不在有效，要從原始的源端再次獲取此實體的日期和時間
Last-Modified 　這個實體最後一次被修改的日期和時間

首部行有的時候爲了提升可讀性會被分爲多行來提升可讀性，將其值劃分爲多個延續行，每一個延續行的前面至少要有一個空格或者一個製表符。請求報文的實體是一些須要發送的備註性信息。

2.響應報文

一個HTTP的完整響應報文的具體格式以下：

A.狀態行--版本：同請求行--版本

B.狀態行--狀態碼：

大體分類以下所示：

100-199 用於指定客戶端應相應的某些動做。
200-299 用於表示請求成功。
300-399 用於已經移動的文件而且常被包含在定位頭信息中指定新的地址信息。
400-499 用於指出客戶端的錯誤。
500-599 用於支持服務器錯誤。

具體的狀態碼參見：http://www.cnblogs.com/lxinxuan/archive/2009/10/22/1588053.html

C.狀態行--短語：所謂的短語是和狀態碼相對應的，如常見的404狀態碼對應Not found，403對應Forbidden

D.響應報文的首部行：參見請求報文的首部行

響應報文的實體與請求報文不一樣，主要存放的是服務端向客戶端發送的文檔，若是響應不是錯誤報文，則實體出如今響應報文中。

（2）鏈接模型

如上圖所示，儘管服務端使用了80號端口做爲TCP鏈接的接收端，但HTTP自己是個無狀態的協議，服務端不會保留關於客戶端的信息，每次HTTP永遠是客戶端先發起請求，而後服務端回送響應。

關於長鏈接和短鏈接：

從HTTP1.1以後默認使用了長鏈接，在HTTP1.0中使用的是HTTP首部Connection：Keep-alive來進行長鏈接的實驗性拓展。長鏈接使數據傳輸完成以後保持TCP鏈接不斷開，等待在同域名下繼續使用這個通道傳輸數據，與之相對應的就是短鏈接，從HTTP1.1開始要在HTTP請求報文中使用Connection：close來通知不但願使用長鏈接。在短鏈接中，對每個請求/響應都要創建一次TCP鏈接，舉個例子如某一個超文本文檔上有N個位於同一個服務器的圖片時，那麼就要前後對該圖片所在的服務器打開和關閉N+1次TCP鏈接，短連接會給服務器帶來巨大的沒必要要的開銷，也減慢了鏈接創建和關閉的過程。在使用了長鏈接以後，服務器容許TCP鏈接的保持已減小握手過程，服務器也能夠在客戶端請求時或者請求超時時關閉這個鏈接，在某些狀況下，服務器並不知道要發送的文檔的長度，那麼服務器就要把長度未知這個首部通知客戶，並在發送數據後關閉這個鏈接，所以客戶就能夠知道數據結束的地方就要到了。另外在首部中能夠經過定義Keep-Alive首部來定義TCP鏈接的最長使用限時。實際上頭部有了Connection： Keep-alive這個首部並不表明服務器必定就會使用長鏈接，客戶端和服務端均可以忽略這個首部的定義。以下所示爲長鏈接的鏈接模式圖：

長鏈接模式下。當客戶端向服務器發生請求以後，客戶端如何判斷服務器的數據已經發生完成？除了經過服務器關閉鏈接來被動的關閉HTTP的TCP鏈接以外，能夠經過消息首部字段Content-Length來判斷數據傳輸是否完畢，單位爲字節，另外也能夠經過使用消息首部字段Transfer-Encoding來協助完成判斷，Transfer-Encoding：clunk或者Transfer-Encoding：clunked模式能夠將數據分爲一塊一塊的傳輸，clunk編碼的具體格式這裏暫不贅述。

關於HTTP中的Cookie：

Cookie的實質就是一個鍵值對，當一個客戶端向服務端發送請求的時候，瀏覽器就查找在Cookie目錄中是否有那個服務器發送的Cookie，若是有的話就會把相應的Cookie包含對請求之中，當這個Cookie包含在請求之中的時候服務端就能夠知道這個客戶是一個老客戶，cookie的使用者和消費者都是服務端，這對於瀏覽器和消費者都是透明的。在HTTP報文分組中，與其功能相關的首部是Cookie首部和Set-Cookie首部。具體格式以下所示：

Set-Cookie:value [ ;expires=date][ ;domain=domain][ ;path=path][ ;secure]

Cookie : value

Cookie:value1 ; value2 ; name1=value1

在Set-Cookie中，能夠經過定義選項的值來進一步肯定Cookie的功能。

1.有效期選項（The expires option）

緊跟cookie值後面的每一個選項都以分號和空格分割，而且每一個選項都指定cookie什麼時候應該被髮送到服務器。第一個選項是expires，其指定了cookie什麼時候不會再被髮送到服務器端的，所以該cookie可能會被瀏覽器刪掉。例如：

 
      1 
      Set-Cookie:name=Nicholas;expires=Sat, 02 May 2009 23:38:25 GMT

在沒有expires選項時，cookie的壽命僅限於單一的會話中。瀏覽器的關閉意味這一次會話的結束，因此會話cookie只存在於瀏覽器保持打開的狀態之下。這就是爲何當你登陸到一個web應用時常常看到一個checkbox，詢問你是否選擇存儲你的登陸信息：若是你選擇是的話，那麼一個expires選項會被附加到登陸的cookie中。若是expires選項設置了一個過去的時間點，那麼這個cookie會被當即刪除。

2.域選項（The domain option）

下一個選項是domain，指示cookie將要發送到哪一個域或那些域中。默認狀況下，domain會被設置爲建立該cookie的頁面所在的域名。例如本站中的cookie的domain屬性的默認值爲www.nczonline.com。domain選項被用來擴展cookie值所要發送域的數量。例如:

 
      1 
      Set-Cookie:name=Nicholas;domain=nczonline.net

domain設置的值必須是發送Set-Cookie消息頭的域名。例如，我沒法向google.com發送一個cookie，由於這個產生安全問題。不合法的domain選項只要簡單的忽略便可。

3.Path選項（The path option）

另外一個控制什麼時候發送Cookie消息頭的方式是指定path選項。與domain選項相同的是，path指明瞭在發Cookie消息頭以前必須在請求資源中存在一個URL路徑。這個比較是經過將path屬性值與請求的URL從頭開始逐字符串比較完成的。若是字符匹配，則發送Cookie消息頭，例如：

 
      1 
      Set-Cookie:name=Nicholas;path=/blog

在這個例子中，path選項值會與/blog,/blogrool等等相匹配；任何以/blog開頭的選項都是合法的。要注意的是隻有在domain選項覈實完畢以後纔會對path屬性進行比較。path屬性的默認值是發送Set-Cookie消息頭所對應的URL中的path部分。

4.secure選項（The secure option）

最後一個選項是secure。不像其它選項，該選項只是一個標記而且沒有其它的值。一個secure cookie只有當請求是經過SSL和HTTPS建立時，纔會發送到服務器端。這種cookie的內容意指具備很高的價值而且可能潛在的被破解以純文本形式傳輸。例如

 
      1 
      Set-Cookie:name=Nicholas;secure

現實中，機密且敏感的信息毫不應該在cookies中存儲或傳輸，由於cookies的整個機制都是本來不安全的。默認狀況下，在HTTPS連接上傳輸的cookies都會被自動添加上secure選項。

關於HTTP的安全：

HTTP自己並不提供安全，然而經過在傳輸層和應用層中使用安全套接層（SSL）可使HTTP運行在安全的環境下，即HTTPS，HTTPS能夠提供保密性，客戶和服務器鑑別以及數據的完整性。

SSL的設計時爲了給應用層生成的數據提供安全以及壓縮服務，通常來講SSL能接收來自任何應用層協議的數據，但最多狀況下這個應用層的協議就是HTTP，SSL對應用層傳來的數據提供多種服務：

分片：SSL把數據劃分爲長度小於或者等於2的14次字節的數據分片

壓縮：數據分片經過使用一種由客戶端和服務器協商好的無損壓縮方式進行壓縮，這個服務是可選的。

報文完整性：爲了保護數據的完整性，SSL使用密鑰散列函數來建立MAC。

保密：爲了提供保密性，原始的數據和MAC一塊兒用對稱密鑰加密技術來加密。

組幀：先在被加密的有效載荷上添加一個首部，而後再把這個惡有效載荷傳遞給可靠的運輸層協議。