Http協議簡介

標籤：頭資訊   server   代理服務   ati   資源   action   多個   password   緩衝機制   

Http協議簡介

HTTP(HyperText Transfer Protocol)是一套電腦通過網路進行通訊的規則。HTTP目前協議的版本是1.1.HTTP是一種無狀態的協議。

無狀態是指Web瀏覽器和Web伺服器之間不需要建立持久的串連，這意味著當一個用戶端向伺服器端發出請求，然後Web伺服器返迴響應(response)，串連就被關閉了，在伺服器端不保留串連的有關資訊。

1. Http協議通訊過程

HTTP遵循請求(Request)/應答(Response)模型。Web瀏覽器向Web伺服器發送請求，Web伺服器處理請求並返回適當的應答。所有HTTP串連都被構造成一套請求和應答。

 

在一次完整的HTTP通訊過程中，Web瀏覽器與Web伺服器之間將完成下列7個步驟：

   (1) 建立TCP串連

 

 (2) Web瀏覽器向Web伺服器發送請求

 

 (3) Web瀏覽器發送要求標頭資訊

瀏覽器發送其請求之後，還要以頭資訊的形式向Web伺服器發送其它資訊，之後瀏覽器發送了一空白行來通知伺服器，它已經結束了該頭資訊的發送。

 

 (4) Web伺服器應答

 客戶機向伺服器發出請求後，伺服器會客戶機回送應答，

 HTTP/1.1 200 OK 

 應答的第一部分是協議的版本號碼和應答狀態代碼

 

 (5) Web伺服器發送應答頭資訊

 

 (6) Web伺服器向瀏覽器發送資料

Web伺服器向瀏覽器發送頭資訊後，它會發送一個空白行來表示頭資訊的發送到此為結束，接著，它就以Content-Type應答頭資訊所描述的格式發送使用者所請求的實際資料。

 

 (7) Web伺服器關閉TCP串連

一般情況下，一旦Web伺服器向瀏覽器發送了請求資料，它就要關閉TCP串連，如果瀏覽器或者伺服器在其頭資訊加入了這行代碼:

 Connection:keep-alive 

 TCP串連在發送後將仍然保持開啟狀態。

 

2. 統一資源定位器（URL）

URI(uniform resource identifier)，統一資源識別項，用來唯一的標識一個資源。而URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何定位這個資源。URN，uniform resource name，統一資源命名，是通過名字來標識資源。

簡單來說，URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI的實現。

3. Http請求

  http請求由三部分組成，分別是：請求行、訊息前序、請求本文。

(1) 請求行

請求行以一個方法符號開頭，以空格分開，後面跟著請求的URI和協議的版本，格式如下:

 Method Request-URI HTTP-Version CRLF 

其中 Method表示要求方法；Request-URI是一個統一資源識別項；HTTP-Version表示請求的HTTP協議版本；CRLF表示斷行符號和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字元）。

要求方法

GET　　         請求擷取Request-URI所標識的資源

POST　　       在Request-URI所標識的資源後附加新的資料

HEAD　　      請求擷取由Request-URI所標識的資源的響應訊息前序

PUT　　　　    請求伺服器儲存一個資源，並用Request-URI作為其標識

DELETE　　    請求伺服器刪除Request-URI所標識的資源

TRACE　　　　請求伺服器回送收到的請求資訊，主要用於測試或診斷

CONNECT 　　保留將來使用

OPTIONS　　  請求查詢服務器的效能，或者查詢與資源相關的選項和需求

   1. GET請求

GET用於資訊擷取，Http協議對GET請求定義了兩個條件：

(1) GET用於擷取資訊而非修改資訊，

(2) 對同一URL的多個請求返回的結果僅有伺服器行為決定。（這一點與POST方法有著明顯區別）

 

.GET請求的資料會附在URL之後（就是把資料放置在HTTP協議頭中），以?分割URL和傳輸資料，參數之間以&相連，如：

 login.action?name=loginAction&password=forgetten&verify=%E4%BD%A0%E5%A5%BD 

如果資料是英文字母/數字，原樣發送，如果是空格，轉換為+，如果是中文/其他字元，則直接把字串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進位表示的ASCII。

因為GET是通過URL提交資料，那麼GET可提交的資料量就跟URL的長度有直接關係了。Http協議並沒有直接限制URL的長度，但是不同的瀏覽器和伺服器通常對URL的長度定義了上限。

   2. POST請求

POST表示可能修改變伺服器上的資源的請求，POST把提交的資料則放置在是HTTP包的包體中。一般來說POST請求通常與表單配合使用，因為資料不包含在URL中，資訊相對安全。

實質上，GET和POST只是發送機制不同，並不是一個取一個發！通過GET提交資料，使用者名稱和密碼將明文出現在URL上，因為登入頁面有可能被瀏覽器緩衝，其他人查看瀏覽器的曆史紀錄，那麼別人就可以拿到你的帳號和密碼了；除此之外，使用GET提交資料還可能會造成Cross-site request forgery攻擊。

  3. HEAD請求

HEAD方法與GET方法幾乎是一樣的，對於HEAD請求的回應部分來說，它的HTTP頭部中包含的資訊與通過GET請求所得到的資訊是相同的。利用這個方法，不必傳輸整個資源內容，就可以得到Request-URI所標識的資源的資訊。該方法常用於測試超連結的有效性，是否可以訪問，以及最近是否更新。

  (2) 要求標頭

要求標頭包含許多有關的用戶端環境和請求本文的有用資訊。例如，要求標頭可以聲明瀏覽器所用的語言，請求本文的長度等。

Accept:image/gif.image/jpeg.*/*Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhostUser-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)Accept-Encoding:gzip,deflate.

每個請求前序域由一個網域名稱，冒號（:）和域值三部分組成。網域名稱是大小寫無關的，域值前可以添加任何數量的空格符，請求前序域可以被擴充為多行，在每行開始處，使用至少一個空格或定位字元。

Host請求前序域指定請求資源的Intenet主機和連接埠號碼，必須表示請求url的原始伺服器或網關的位置。HTTP/1.1請求必須包含主機請求前序域，否則系統會以400狀態代碼返回。

Accept請求前序域用於指定用戶端接受哪些類型的資訊。eg：Accept：image/gif，表明用戶端希望接受GIF圖象格式的資源；Accept：text/html，表明用戶端希望接受html文本。

Accept-Charset請求前序域用於指定用戶端接受的字元集。eg：Accept-Charset:iso-8859-1,gb2312.如果在請求訊息中沒有設定這個域，預設是任何字元集都可以接受。

Accept-Encoding請求前序域類似於Accept，但是它是用於指定可接受的內容編碼。eg：Accept-Encoding:gzip.deflate.如果請求訊息中沒有設定這個網域服務器假定用戶端對各種內容編碼都可以接受。

Accept-Language請求前序域類似於Accept，但是它是用於指定一種自然語言。eg：Accept-Language:zh-cn.如果請求訊息中沒有設定這個請求前序域，伺服器假定用戶端對各種語言都可以接受。

Authorization請求前序域 主要用於證明用戶端有權查看某個資源。當瀏覽器訪問一個頁面時，如果收到伺服器的響應代碼為401（未授權），可以發送一個包含Authorization請求請求前序域的請求，要求伺服器對其進行驗證。

Referer請求前序域允許用戶端指定請求uri的源資源地址，這可以允許伺服器產生回退鏈表，可用來登陸、最佳化cache等。他也允許廢除的或錯誤的串連由於維護的目的被追蹤。

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。

Date請求前序域表示訊息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道使用者所在的時區。

  (3) 請求本文

要求標頭和請求本文之間是一個空行，這個行非常重要，它表示要求標頭已經結束，接下來的是請求本文。

4.Http應答

在接收和解釋請求訊息後，伺服器返回一個HTTP響應訊息。HTTP響應也是由三個部分組成，分別是：狀態行、回應標頭、響應本文

 

(1) 狀態行

狀態行格式如下：

 HTTP-Version Status-Code Reason-Phrase CRLF 

HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態碼；Reason-Phrase表示狀態碼的文本描述。

狀態代碼：

狀態碼有三位元字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx：指示資訊--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重新導向--要完成請求必須進行更進一步的操作

4xx：用戶端錯誤--請求有語法錯誤或請求無法實現

5xx：伺服器端錯誤--伺服器未能實現合法的請求

 

常見狀態碼、狀態原因、說明：

200 OK     用戶端請求成功

400 Bad Request    用戶端請求有語法錯誤，不能被伺服器所理解

401 Unauthorized   請求未經授權，

這個狀態碼必須和WWW-Authenticate報請求前序域一起使用 

403 Forbidden    伺服器收到請求，但是拒絕提供服務

404 Not Found    請求資源不存在

500 Internal Server Error 伺服器發生不可預期的錯誤

503 Server Unavailable   伺服器當前不能處理用戶端的請求，一段時間後可能恢複正常

 

(2) 回應標頭

響應前序允許伺服器傳遞不能放在狀態行中的附加響應資訊，以及關於伺服器的資訊和對Request-URI所標識的資源進行下一步訪問的資訊。

 

Location響應前序域用於重新導向接受者到一個新的位置。Location響應前序域常用在更換網域名稱的時候。

Server響應前序域 包含了伺服器用來處理請求的軟體資訊。與User-Agent請求前序域是相對應的。

實體前序

請求和響應訊息都可以傳送一個實體。一個實體由實體前序域和實體本文組成，但並不是說實體前序域和實體本文要在一起發送，可以只發送實體前序域。

 

Content-Encoding實體前序域 被用作媒體類型的修飾符，它的值指示了已經被應用到實體本文的附加內容的編碼，因而要獲得Content-Type前序域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法，eg：Content-Encoding：gzip

 

Content-Language實體前序域描述了資源所用的自然語言。沒有設定該域則認為實體內容將提供給所有的語言閱讀

者。eg：Content-Language:da

 

Content-Length實體前序域 用於指明實體本文的長度，以位元組方式儲存的十進位數字來表示。

 

Content-Type實體前序域 用語指明發送給接收者的實體本文的媒體類型。eg：

Content-Type:text/html;charset=ISO-8859-1

Content-Type:text/html;charset=GB2312

 

Last-Modified實體前序域用於指示資源的最後修改日期和時間。

 

Expires實體前序域 給出響應到期的日期和時間。為了讓Proxy 伺服器或瀏覽器在一段時間以後更新緩衝中(再次訪問曾訪問過的頁面時，直接從緩衝中載入，縮短回應時間和降低伺服器負載)的頁面，我們可以使用Expires實體前序域指定頁面到期的時間。

 

(3) 響應本文

響應本文即為伺服器返回的資源。

 

Http協議簡介