URL協議與HTTP協議簡介
HTTP:(Hypertext transfer protocol)超文字傳輸協議,是用於從全球資訊網(WWW:World Wide Web)伺服器傳輸超文字到本地瀏覽器的傳送協議。
URL:(Uniform Resource Locator)統一資源定位符,對可以從網際網路上得到的資源的位置和訪問方法的一種簡潔的表示,是網際網路上標準資源的地址。
URL協議
HTTP使用統一資源識別符號(URI)來傳輸資料和建立連線。URL是一種特殊型別的URI,包含了用於查詢某個資源的足夠的資訊。
例如一個標準的URL地址:
http://www.aicoder.com:80/index.html?boardID=5&ID=24618&page=1#name
- 協議部分:代表網頁使用的是HTTP協議。在Internet中可以使用多種協議,如HTTP,FTP等等。在"HTTP"後面的“//”為分隔符
- 域名部分:“www.aicoder.com”。一個URL中,也可以使用IP地址作為域名使用
- 埠部分:跟在域名後面的是埠,域名和埠之間使用“:”作為分隔符。埠不是一個URL必須的部分,如果省略埠部分,將採用預設埠80/tcp
- 虛擬目錄部分:從域名後的第一個“/”開始到最後一個“/”為止,是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。
- 檔名部分:從域名後的最後一個“/”開始到“?”為止,是檔名部分,如果沒有“?”,則是從域名後的最後一個“/”開始到“#”為止,是檔案部分,如果沒有“?”和“#”,那麼從域名後的最後一個“/”開始到結束,都是檔名部分。本例中的檔名是“index.asp”。檔名部分也不是一個URL必須的部分,如果省略該部分,則使用預設的檔名
- 錨部分:從“#”開始到最後,都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分(可以理解為定位)
- 引數部分:從“?”開始到“#”為止之間的部分為引數部分,又稱搜尋部分、查詢部分。本例中的引數部分為“boardID=5&ID=24618&page=1”。引數可以允許有多個引數,引數與引數之間用“&”作為分隔符。
HTTP協議
http(超文字傳輸協議)是一個基於請求與響應模式的、無狀態的、應用層的協議,常基於TCP的連線方式,HTTP1.1版本中給出一種持續連線的機制,絕大多數的Web開發,都是構建在HTTP協議之上的Web應用。
HTTP協議請求
http請求由三部分組成,分別是:請求行、訊息報頭、請求正文。
HTTP請求請求方法(所有方法全為大寫)有多種,各個方法的解釋如下:
請求行
請求行以一個方法符號開頭,以空格分開,後面跟著請求的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 | 請求查詢伺服器的效能,或者查詢與資源相關的選項和需求 |
一個完整的GET請求例項:
GET /index.html?id=33 HTTP/1.1
Host aicoder.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Accept image/webp,image/*,*/*;q=0.8 Referer http://www.imooc.com/ Accept-Encoding gzip, deflate, sdch Accept-Language zh-CN,zh;q=0.8 第一部分:請求行,用來說明請求型別,要訪問的資源以及所使用的HTTP版本. GET說明請求型別為GET,[/index.html]為要訪問的資源,該行的最後一部分說明使用的是HTTP1.1版本。 第二部分:請求頭部,緊接著請求行(即第一行)之後的部分,用來說明伺服器要使用的附加資訊 從第二行起為請求頭部,HOST將指出請求的目的地.User-Agent,伺服器端和客戶端指令碼都能訪問它,它是瀏覽器型別檢測邏輯的重要基礎.該資訊由你的瀏覽器來定義,並且在每個請求中自動傳送等等 第三部分:空行,請求頭部後面的空行是必須的 即使第四部分的請求資料為空,也必須有空行。 第四部分:請求資料也叫主體,可以新增任意的其他資料。 這個例子的請求資料為空。
POST請求x-www-form-urlencoded
的請求方式:
POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3
對應的表單請求
<form action="/user/add" method="POST" enctype="application/x-www-form-urlencoded"> .... </form>
POST請求multipart/form-data
的請求方式:
POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryyb1zYhTI38xpQxBK
------WebKitFormBoundaryyb1zYhTI38xpQxBK
Content-Disposition: form-data; name="city_id"
------WebKitFormBoundaryyb1zYhTI38xpQxBK
Content-Disposition: form-data; name="company_id"
------WebKitFormBoundaryyb1zYhTI38xpQxBK
Content-Disposition: form-data; name="file"; filename="chrome.png" Content-Type: image/png PNG ... content of chrome.png ... ------WebKitFormBoundaryyb1zYhTI38xpQxBK-- 對應的表單: <form action="/user/add" method="POST" enctype="multipart/form-data"> .... </form>
HTTP之響應訊息Response
一般情況下,伺服器接收並處理客戶端發過來的請求後會返回一個HTTP的響應訊息。
HTTP響應也由四個部分組成,分別是:狀態行、訊息報頭、空行和響應正文。
例子
HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
<html>
<head></head> <body> <!--body goes here--> </body> </html>
第一部分:狀態行,由HTTP協議版本號, 狀態碼, 狀態訊息三部分組成。
第一行為狀態行,(HTTP/1.1)表明HTTP版本為1.1版本,狀態碼為200,狀態訊息為(ok)
第二部分:訊息報頭,用來說明客戶端要使用的一些附加資訊
第二行和第三行為訊息報頭,
Date:生成響應的日期和時間;Content-Type:指定了MIME型別的HTML(text/html),編碼型別是UTF-8
第三部分:空行,訊息報頭後面的空行是必須的
第四部分:響應正文,伺服器返回給客戶端的文字資訊。
空行後面的html部分為響應正文。
HTTP之狀態碼
狀態程式碼有三位數字組成,第一個數字定義了響應的類別,共分五種類別:
-
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和POST的區別
-
GET提交的資料會放在URL之後,以?分割URL和傳輸資料,引數之間以&相連,如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的資料放在HTTP包的Body中.
-
GET提交的資料大小有限制(因為瀏覽器對URL的長度有限制),而POST方法提交的資料沒有限制.
-
GET方式需要使用請求的QueryString來取得變數的值,而POST方式通過請求的Form來獲取變數的值。
-
GET方式提交資料,會帶來相對不安全的問題
狀態碼
100——客戶必須繼續發出請求
101——客戶要求伺服器根據請求轉換HTTP協議版本
200——交易成功
201——提示知道新檔案的URL
202——接受和處理、但處理未完成
203——返回資訊不確定或不完整
204——請求收到,但返回資訊為空
205——伺服器完成了請求,使用者代理必須復位當前已經瀏覽過的檔案
206——伺服器已經完成了部分使用者的GET請求
300——請求的資源可在多處得到
301——刪除請求資料
302——在其他地址發現了請求資料
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經執行了GET,但檔案未變化
305——請求的資源必須從伺服器指定的地址得到
306——前一版本HTTP中使用的程式碼,現行版本中不再使用
307——申明請求的資源臨時性刪除
400——錯誤請求,如語法錯誤
401——請求授權失敗
402——保留有效ChargeTo頭響應
403——請求不允許
404——沒有發現檔案、查詢或URl
405——使用者在Request-Line欄位定義的方法不允許
406——根據使用者傳送的Accept拖,請求資源不可訪問
407——類似401,使用者必須首先在代理伺服器上得到授權
408——客戶端沒有在使用者指定的時間內完成請求
409——對當前資源狀態,請求不能完成
410——伺服器上不再有此資源且無進一步的參考地址
411——伺服器拒絕使用者定義的Content-Length屬性請求
412——一個或多個請求頭欄位在當前請求中錯誤
413——請求的資源大於伺服器允許的大小
414——請求的資源URL長於伺服器允許的長度
415——請求資源不支援請求專案格式
416——請求中包含Range請求頭欄位,在當前請求資源範圍內沒有range指示值,請求也不包含If-Range請求頭欄位
417——伺服器不滿足請求Expect頭欄位指定的期望值,如果是代理伺服器,可能是下一級伺服器不能滿足請求
500——伺服器產生內部錯誤
501——伺服器不支援請求的函式
502——伺服器暫時不可用,有時是為了防止發生系統過載
503——伺服器過載或暫停維修
504——關口過載,伺服器使用另一個關口或服務來響應使用者,等待時間設定值較長
505——伺服器不支援或拒絕支請求頭中指定的HTTP版本
作者:IT老馬
連結:https://www.jianshu.com/p/4fb712c05b63
來源:簡書