HTTP協議詳解（三）

接着第二篇繼續學習...

6 HTTP的幾個重要概念

6.1鏈接：Connection

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

在http1，request和reponse頭中都有可能出現一個connection的頭，此header的含義是當client和server通訊時對於長連接如何進行處理。

在http1中，client和server都是默認對方支持長連接的， 若是client使用http1協議，但又不但願使用長連接，則須要在header中指明connection的值爲close；若是server方也不想支持長連接，則在response中也須要明確說明connection的值爲close。不論request仍是response的header中包含了值爲close的connection，都代表當前正在使用的tcp連接在當天請求處理完畢後會被斷掉。之後client再進行新的請求時就必須建立新的tcp連接了。

從HTTP1以後默認使用了長鏈接，在HTTP1.0中使用的是HTTP首部Connection：Keep-alive來進行長鏈接的實驗性拓展。長鏈接使數據傳輸完成以後保持TCP鏈接不斷開，等待在同域名下繼續使用這個通道傳輸數據，與之相對應的就是短鏈接，從HTTP1開始要在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編碼的具體格式這裏暫不贅述。

6.2消息：Message

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

6.3請求：Request

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

6.4響應：Response

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

6.5資源：Resource

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

6.6實體：Entity

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

6.7客戶機：Client

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

6.8用戶代理：UserAgent

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

6.9服務器：Server

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

6.10源服務器：Originserver

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

6.11代理：Proxy

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

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

6.12網關：Gateway

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

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

6.13通道：Tunnel

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

6.14緩存：Cache

反應信息的局域存儲。

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選項。

7 關於HTTP以及HTTPS的安全性

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

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

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

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

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

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

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

 

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

 

後面還有....