1. 程式人生 > >http請求響應模型

http請求響應模型

Internet的基本協議是TCP/IP協議(傳輸控制協議和網際協議),目前廣泛使用的FTP、HTTP(超文字傳輸協議)、Archie Gopher都是建立在TCP/IP上面的應用層協議,不同的協議對應不同的應用。而HTTP協議是Web應用所使用的主要協議。

HTTP協議是基於請求響應模式的。客戶端向伺服器傳送一個請求,請求頭包含請求的方法、URI、協議版本、以及包含請求修飾符、客戶端資訊和內容的類似MIME的訊息結果。伺服器則以一個狀態行作為響應,相應的內容包括訊息協議的版本、成功 或者錯誤編碼加上包含伺服器資訊、實體元資訊以及可能的實體內容。

HTTP是無狀態協議,依賴於瞬間或者近乎瞬間的請求處理。請求資訊被立即傳送,理想的情況是 沒有延時的進行敕處理,不過,延時還是客觀存在的。HTTP有一種內建的機制,在訊息的傳遞時間上由一定的靈活性:超時機制。一個超時就是客戶機等待請求 訊息的返回資訊的最長時間。

HTTP的請求和響應訊息如果沒有傳送並傳遞成功的話,不儲存任何已傳遞的資訊。比如,單擊“提交”按鈕,如果表單沒有傳送出去,則瀏覽器將顯示錯誤資訊頁,並且返回空白表單。雖然沒有傳送成功,但是HTTP不儲存表單資訊。

由於HTTP協議的上述特點,通常,客戶端每次需要更新資訊都必須重新向伺服器發起請求,客戶端收到伺服器返回的資訊後再更新螢幕內容。

基於HTTP協議的客戶端/伺服器請求響應機制的資訊交換過程包括四個步驟:

  • 建立連線:客戶端與伺服器建立TCP連線;
  • 傳送請求:開啟一個連線後,客戶端把請求訊息送到伺服器的相應埠上,完成請求動作提交;
  • 傳送響應:伺服器在處理完客戶端請求之後,要向客戶端傳送響應訊息;
  • 關閉連線:客戶端和伺服器雙方都可以通過關閉套接字來結束TCP/IP對話。

HTTP的工作機制是請求訊息和響應訊息,最簡單的情況,一個使用者輸入一個站點地址,傳送一個請求。之後,瀏覽器返回所請求的頁面,這個頁面可能是簡單的HTML頁面,也可能是動態編譯後的頁面。如果這個頁面有錯誤或者不存在,則Web伺服器將傳送錯誤資訊頁面。

Web伺服器傳送錯誤資訊頁是因為HTTP沒有內建的處理機制,是無狀態的,傳輸協議不記憶從 一條請求訊息到另一條請求訊息的任何資訊。這個特點可以保證Web的一致性。但是,使用者常常需要記憶一些設定內容或者瀏覽過程,這就需要在Web頁面或者URL中攜帶各種引數及其值。HTTP請求有多種樣式,其中常用的有Post、Get、Head。

2、  Get請求

Get請求返回以URL形式表示的資源,當用戶輸入一個簡單的URL 時,就是使用Get請求。Get請求可以傳送Query String(就是在URL後用?附加一個引數列表),代表URL編碼字串的實際意義。

3、  Post請求

Post請求則將表單體置入Web伺服器中,傳送訊息到公告板、新聞組、郵件列表或者其他機構 中,或者為資料處理機制提供諸如提交表單後的結果等資料。Post請求的功能由Web伺服器決定,依賴於URL所指向的應用程式。長期以來,在填好的表單 提交之後,單擊瀏覽器“後退”按鈕,表單內容是空白的,這避免了使用者由於疏忽兩次提交表單的可能。不過很多瀏覽器還是會自動儲存已經發送過的表單資訊,單 擊瀏覽器“後退”按鈕也會看到剛剛提交的部分表單內容。

使用Get和Post提交表單的主要不同之處是Get顯示追加了查詢字串的表單引數,Post連同請求訊息體一起傳送表單引數。

4、Head請求

除了伺服器禁止在響應中傳送訊息體外,Head的傳送方式和Get一致。Head請求的HTTP頭所包含的資訊與Get請求的響應中的資訊相同,可以使用Head請求獲取沒有傳送訊息體而由該請求暗指的訊息的有關元資訊。也可以使用請求訊息 測試超文字連線的有效性、科訪問性以及最新變動。

5、  狀態管理

正如前面所提到的,HTTP協議是無狀態的,不能儲存每次提交的資訊,即當伺服器返回與請求相對應的應答之後,這次事務的所有資訊就丟掉了。如果使用者發來一個新的請求,伺服器無法知道它是否與上次的請求有聯絡。

對於簡單的靜態HTML檔案來說,這種特性很是適用,但是對於那些需要多次提交親切才能完成的Web操作比如購物車來說,就成問題了。伺服器端Web應用程式必須允許使用者通過多個步驟才能完整全部的物品採購。這種情況下,應用程式必須跟蹤由同一個 瀏覽器發出的多個請求所提供的資訊,即記住使用者的交易狀態。

通常,採取兩種方法來解決這個問題。一是在每次應答中都返回完整的狀態,讓瀏覽器把它作為下一次請求的一部份再發送回來。二是把狀態儲存在伺服器的某個地方,只發送回一個識別符號,瀏覽器在下次提交中再把這個識別符號傳送回來;這樣就可以定位儲存在伺服器上的狀態資訊了。

在這兩種方法中,資訊可以通過下列三種方法之一發送給瀏覽器:作為Cookie、作為隱藏域嵌入HTML表單中、附加在主體的URL中(通常作為指向其他應用程式頁面的連結,即URL重寫)。

Cookie是伺服器在應答資訊中傳送給瀏覽器的名稱/值對。瀏覽器儲存這些Cookie,保 存的期限由Cookie的有效期屬性決定。當瀏覽器向伺服器傳送一個請求時,它檢查Cookie設定,並將它從同一個伺服器收到的所有Cookie都注入 請求資訊中。使用Cookie是處理狀態問題的一個簡單的方法,但不是所有的瀏覽器都支援,使用者也可能禁用Cookie。

如果使用HTML表單中隱藏域來向瀏覽器傳送狀態資訊的話,當表單提交時,瀏覽器將以常規HTTP引數的方式將這些資訊返回伺服器。當狀態資訊被注入URL時,它將作為請求URL的一部分被傳送到伺服器。

在瀏覽器和伺服器之間反覆的來回傳送所有狀態資訊不是一種高效的方法,所以大部分的伺服器還是 選擇在伺服器上儲存資訊,而只在瀏覽器和伺服器之間傳送一個識別符號。這個就是所謂的會話(Session)跟蹤。來自瀏覽器的所有包含同一個識別符號(這裡 是會話ID)的請求同屬於一個會話,伺服器則對與會話有關的所有資訊保持跟蹤。會話的有效期直到它被顯式的中止,或者當用戶在一段時間內沒有動作,有服務 器自動設定為過期。目前沒有辦法通知伺服器使用者已經關閉瀏覽器,因為在瀏覽器和伺服器之間並不存在持久的連線,並且當瀏覽器關閉時也不向伺服器傳送訊息。 同時,關閉瀏覽器通常意味著會話ID丟失;Cookie將過期,或者注入了資訊的URL將不能再使用。所以,當用戶再次開啟瀏覽器的時候,伺服器無法將新 的請求與以前的會話聯絡起來,而只能建立一個新的會話。然而,所有與前一個會話有關的資料依然存在伺服器上,直到會話過期被清除為止