.Net Framework 開發Http協議

標籤：style   blog   http   io   ar   color   os   使用   sp   

一、Http的基本原理

1.HTTP協議的運作方式
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HTTP協議是基於請求／響應範式的。一個客戶機與伺服器建立串連後，發送一個請求給伺服器，請求方式的格式為，統一資源識別項、協議版本號碼，後邊是 MIME資訊包括請求修飾符、客戶機資訊和可能的內容。伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行包括資訊的協議版本號碼、一個成功或錯誤的代碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。
它分四個過程，在HTTP協議中，服務端是指提供HTTP服務的部分，用戶端是指你使用的瀏覽器或者下載工具等等。在通訊時，由用戶端發出請求串連，服務端建立串連；然後，用戶端發出HTTP請求（Request），服務端返迴響應資訊（Respond），由此完成一個HTTP操作。

HTTP狀態檢測（HTTP Header）

HTTP協議狀態代碼表示的意思
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1×× 保留
2×× 表示請求成功地接收
3×× 為完成請求客戶需進一步細化請求
4×× 客戶錯誤
5×× 伺服器錯誤

2.URI,URL,URN的基本概念

 

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。一個URI執行個體可以代表絕對的，也可以是相對的，只要它符合URI的文法規則。而URL類則不僅符合語義，還包含了定位該資源的資訊，因此它不能是相對的，schema必須被指定。

總結一下：URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的資訊。URI是一種語義上的抽象概念，可以是絕對的，也可以是相對的，而URL則必須提供足夠的資訊來定位，所以，是絕對的，而通常說的relative URL，則是針對另一個absolute URL，本質上還是絕對的。

舉例說明下URL和URI的區別：

URI 是從可以是虛擬根路徑開始的
URL必須是整個連結，可以根據URL唯一定位到頁面的連結。
如URL http://zhidao.baidu.com/question/68016373.html  
URI 是/question/68016373.html(只要能標識資訊就可以了)

在百度那邊伺服器上把http://zhidao.baidu.com/製作成了虛擬路徑
的根

3.URL的結構：

4.HTTP是無狀態的協議以及Cookie和Session的應用：

在用戶端發送HTTP請求並收到伺服器端響應後，串連就會斷開，下一次的訪問與前一次的訪問無關，因此如果需要維護用戶端的資訊，必須在伺服器端維持狀態資料。

   Http是無狀態的協議的理解：

協議的狀態是指下一次傳輸可以“記住”這次傳輸資訊的能力. Http是一個無狀態協議，同一個會話的連續兩個請求互相不瞭解，他們由最新執行個體化的環境進行解析，除了應用本身可能已經儲存在全域對象中的所有資訊外，該環境不儲存與會話有關的任何資訊。

http是不會為了下一次串連而維護這次串連所傳輸的資訊的.

無狀態是指，當瀏覽器發送請求給伺服器的時候，伺服器響應，但是同一個瀏覽器再發送請求給伺服器的時候，他會響應，但是他不知道你就是剛才那個瀏覽器，簡單地說，就是伺服器不會去記得你，所以是無狀態協議。
而DNS是有狀態協議 。

在這種用戶端與伺服器進行動態互動的Web應用程式出現之後，HTTP無狀態的特性嚴重阻礙了這些應用程式的實現，畢竟互動是需要承前啟後的，簡單的購物車程式也要知道使用者到底在之前選擇了什麼商品。於是，兩種用於保持HTTP串連狀態的技術就應運而生了，一個是Cookie，而另一個則是Session。

        Cookie是通過用戶端保持狀態的解決方案。從定義上來說，Cookie就是由伺服器發給用戶端的特殊資訊，而這些資訊以文字檔的方式存放在用戶端，然後用戶端每次向伺服器發送請求的時候都會帶上這些特殊的資訊。讓我們說得更具體一些：當使用者使用瀏覽器訪問一個支援Cookie的網站的時候，使用者會提供包括使用者名稱在內的個人資訊並且提交至伺服器；接著，伺服器在向用戶端回傳相應的超文本的同時也會發回這些個人資訊，當然這些資訊並不是存放在HTTP響應體（Response Body）中的，而是存放於HTTP回應標頭（Response Header）；當用戶端瀏覽器接收到來自伺服器的響應之後，瀏覽器會將這些資訊存放在一個統一的位置，對於Windows作業系統而言，我們可以從：[系統硬碟]:\Documents and Settings\[使用者名稱]\Cookies目錄中找到儲存的Cookie；自此，用戶端再向伺服器發送請求的時候，都會把相應的Cookie再次發回至伺服器。而這次，Cookie資訊則存放在HTTP要求標頭（Request Header）了。
        有了Cookie這樣的技術實現，伺服器在接收到來自用戶端瀏覽器的請求之後，就能夠通過分析存放於要求標頭的Cookie得到用戶端特有的資訊，從而動態產生與該用戶端相對應的內容。通常，我們可以從很多網站的登入介面中看到“請記住我”這樣的選項，如果你勾選了它之後再登入，那麼在下一次訪問該網站的時候就不需要進行重複而繁瑣的登入動作了，而這個功能就是通過Cookie實現的。
        與Cookie相對的一個解決方案是Session，它是通過伺服器來保持狀態的。由於Session這個詞彙包含的語義很多，因此需要在這裡明確一下Session的含義。首先，我們通常都會把Session翻譯成會話，因此我們可以把用戶端瀏覽器與伺服器之間一系列互動的動作稱為一個Session。從這個語義出發，我們會提到Session持續的時間，會提到在Session過程中進行了什麼操作等等；其次，Session指的是伺服器端為用戶端所開闢的儲存空間，在其中儲存的資訊就是用於保持狀態。從這個語義出發，我們則會提到往Session中存放什麼內容，如何根據索引值從Session中擷取匹配的內容等。
        要使用Session，第一步當然是建立Session了。那麼Session在何時建立呢？當然還是在伺服器端程式啟動並執行過程中建立的，不同語言實現的應用程式有不同建立Session的方法，而在Java中是通過調用HttpServletRequest的getSession方法（使用true作為參數）建立的。在建立了Session的同時，伺服器會為該Session產生唯一的Session id，而這個Session id在隨後的請求中會被用來重新獲得已經建立的Session；在Session被建立之後，就可以調用Session相關的方法往Session中增加內容了，而這些內容只會儲存在伺服器中，發到用戶端的只有Session id；當用戶端再次發送請求的時候，會將這個Session id帶上，伺服器接受到請求之後就會依據Session id找到相應的Session，從而再次使用之。正式這樣一個過程，使用者的狀態也就得以保持了。有關Session的內容還比較多，在以後的Post中，我還將繼續講述。

        綜上所述，HTTP本身是一個無狀態的連線協定，為了支援用戶端與伺服器之間的互動，我們就需要通過不同的技術為互動儲存狀態，而這些不同的技術就是Cookie和Session了。

5.Http請求與響應的結構：

(1)Http請求的結構

(2)Http響應的結構

 

 

(3)Http 的Get 方法和Post方法

二、使用Http協議的.Net類

1. .Net中與http相關的類：

2.同步調用與非同步呼叫

 

同步：提交請求->等待伺服器處理->處理完畢返回。這個期間用戶端瀏覽器不能幹任何事。

非同步: 請求通過事件觸發->伺服器處理（這是瀏覽器仍然可以作其他事情）->處理完畢。

舉個生動的例子吧：

同步就是你叫我去吃飯，我聽到了就和你去吃飯；如果沒有聽到，你就不停的叫，直到我告訴你聽到了，才一起去吃飯。

非同步就是你叫我，然後自己去吃飯，我得到訊息後可能立即走，也可能等到下班才去吃飯。

所以，要我請你吃飯就用同步的方法，要請我吃飯就用非同步方法，這樣你可以省錢。

再舉個例子，打電話時同步，發簡訊是非同步。

在設計中普通的B/S模式就是同步，而AJAX技術就是非同步，當然XMLHttpReques有同步的選項。

3、.Net關於HTTP具體代碼開發執行個體

(1)、同步請求

(2)非同步請求：非同步請求的好處是不阻塞當前線程，但相對於同步請求略為複雜，至少要添加兩個回調方法來擷取非同步事件。

 

參考：http://wenku.baidu.com/link?url=Rd3gArVjeyzVEOtSlSyjxu2wpBzjIMOXsyXiut-Cy0EHnMQIcJSb7UKzCjibcfbxaGaGfMdgA32RdEXf1lD-D-1DlZ1cP_LMfeRmjBfpdRO

.Net Framework 開發Http協議