http協議:Hypertext Transfer Protocol,超文本傳輸協議。是瀏覽器和服務器間進行的通訊的一種規範。html
iso公司制定的osi7層協議,只是在理論層面,實際更加傾向於5層(會話、表示、應用合爲一層)而所謂的Tcp\Udp協議就是跑在傳輸層與應用層之間的。web
tcp可靠,但須要鏈接瀏覽器
udp不可靠服務器
----------->可靠,不須要鏈接的協議http協議(bs架構須要可靠傳輸) 架構
一個完整的http請求消息,包含一個請求行,若干個消息頭,換行,實體內容。app
一、請求行tcp
二、消息頭ide
1、Host 請求的web服務器域名地址 二、User-Agent HTTP客戶端運行的瀏覽器類型的詳細信息。 經過該頭部信息,web服務器能夠判斷出http請求的客戶端的瀏覽器的類型。 3、Accept 指定客戶端可以接收的內容類型,內容類型的前後次序表示客戶都接收的前後次序 四、Accept-Lanuage 指定HTTP客戶端瀏覽器用來展現返回信息優先選擇的語言 五、Accept-Encoding 指定客戶端瀏覽器能夠支持的web服務器返回內容壓縮編碼類型。表示容許服務器在將輸出內容發送到客戶端 之前進行壓縮,以節約帶寬。而這裏設置的就是客戶端瀏覽器所可以支持的返回壓縮格式。 六、Accept-Charset HTTP客戶端瀏覽器能夠接受的字符編碼集 七、Content-Type 顯示此HTTP請求提交的內容類型。通常只有post提交時才須要設置該屬性 有關Content-Type屬性值有以下兩種編碼類型: (1)「application/x-www-form-urlencoded」: 表單數據向服務器提交時所採用的編碼類型, 默認的缺省值就是「application/x-www-form-urlencoded」。 然而,在向服務器發送大量的文本、包含非ASCII字符的文本或二進制數據時這種編碼方式效率很低。 (2)「multipart/form-data」: 在文件上載時,所使用的編碼類型應當是「multipart/form-data」, 它既能夠發送文本數據,也支持二進制數據上載。 當提交爲表單數據時,能夠使用「application/x-www-form-urlencoded」;當提交的是文件時, 就須要使用「multipart/form-data」編碼類型。 八、Keep-Alive 表示是否須要持久鏈接。若是web服務器端看到這裏的值爲「Keep-Alive」,或者看到請求使用的是HTTP 1.1 (HTTP 1.1默認進行持久鏈接),它就能夠利用持久鏈接的優勢
POST / HTTP1.1 Host:www.wrox.com User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Content-Type:application/x-www-form-urlencoded Content-Length:40 Connection: Keep-Alive name=Professional%20Ajax&publisher=Wiley
三、換行post
四、實體內容編碼
就是指瀏覽器端經過http協議發送給服務器的實體數據。
get請求時,經過url傳給服務器的值。
post請求時,經過表單發送給服務器的值。
一個完整的http響應消息,包含一個狀態行,若干個消息頭,實體內容。
一、消息頭
二、狀態行
三、實體內容
響應包含瀏覽器可以解析的靜態內容,例如:html,純文本,圖片等等信息
一、簡單快速
客戶向服務器請求服務式,只須要傳送方法和路徑。
方法:POST 、GET、HEAD
--------》程序規模小,通訊速度快
二、靈活
容許任何類型的數據對象傳輸,類型由Context-Type加以標記
三、無鏈接
限制每次鏈接只處理一個請求。處理完斷開,能夠節約時間。
四、無狀態
無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息,則它必須重傳,這樣可能致使每次鏈接傳送的數據量增大。另外一方面,在服務器不須要先前信息時它的應答就較快。
狀態代碼有三位數字組成,第一個數字定義了響應的類別,共分五種類別:
1xx:指示信息--表示請求已接收,繼續處理
2xx:成功--表示請求已被成功接收、理解、接受
3xx:重定向--要完成請求必須進行更進一步的操做
4xx:客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx:服務器端錯誤--服務器未能實現合法的請求
常見狀態碼:
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤,不能被服務器所理解
401 Unauthorized //請求未經受權,這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用
403 Forbidden //服務器收到請求,可是拒絕提供服務
404 Not Found //請求資源不存在,eg:輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable //服務器當前不能處理客戶端的請求,一段時間後可能恢復正常
一、GET提交,請求的數據會附在URL以後,以?分割URL和傳輸數據,多個參數用&鏈接;例 如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。若是數據是英文字母/數字,原樣發送,若是是空格,轉換爲+,若是是中文/其餘字符,則直接把字符串用BASE64加密,得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX爲該符號以16進製表示的ASCII。
POST提交,把提交的數據放在HTTP包的包體中。
二、傳輸數據的大小
HTTP協議沒有對傳輸的數據大小進行限制,HTTP協議規範也沒有對URL長度進行限制。
實際狀況:
GET方式須要使用Request.QueryString來取得變量的值,而POST方式經過Request.Form來獲取變量的值。