這篇文章是講Android
網絡請求的先導文章,主要講Http
工做流程,請求報文和響應報文的格式,以及GET
和POST
方法的具體含義。web
HTTP
是一個客戶端和服務器端請求和應答的標準(TCP
)。客戶端是終端用戶,服務器端是網站。經過使用Web
瀏覽器、網絡爬蟲或者其它的工具,客戶端發起一個到服務器上指定端口(默認端口爲80)的HTTP
請求。(咱們稱這個客戶端)叫用戶代理(user agent
)。應答的服務器上存儲着(一些)資源,好比HTML文件和圖像。(咱們稱)這個應答服務器爲源服務器(origin server
)。在用戶代理和源服務器中間可能存在多箇中間層,好比代理,網關,或者隧道(tunnels
)。儘管TCP/IP協議是互聯網上最流行的應用,HTTP
協議並無規定必須使用它和(基於)它支持的層。 事實上,HTTP
能夠在任何其餘互聯網協議上,或者在其餘網絡上實現。HTTP
只假定(其下層協議提供)可靠的傳輸,任何可以提供這種保證的協議均可以被其使用。
這裏咱們規定下文討論的HTTP
都是基於tcp協議的,至於爲何不是udp,緣由在於(打開)一個網頁必須傳送不少數據,而TCP協議提供傳輸控制,按順序組織數據,和錯誤糾正。
咱們用一個例子來講明http在通訊的時候IP
, TCP
, DNS
分別作了什麼工做。瀏覽器
客戶端發起請求,想要瀏覽百度這個網頁,他先告訴DNS,獲取百度這個網頁的IP地址,而後HTTP協議生成針對目標web服務器的HTTP請求報文,TCP協議則爲了方便通訊,將HTTP請求報文分割成報文段,把每一個報文可靠地傳給對方。IP協議則搜索對方的地址,一邊中轉一邊傳送
服務器端,TCP協議負責從對方那裏接收到報文段,重組到達的報文段,HTTP則負責對WEB服務器請求的內容進行處理。而後結果一樣利用TCP/IP向用戶回傳。緩存
咱們仔細看一下上面的流程,去掉TCP,IP ,DNS在裏面作的工做,首先客戶端發起請求,向服務器請求一個頁面的內容,一般是在瀏覽器裏面輸入一個網址(URL
)這個網址叫URL
(統一資源定位符),他只是表示資源所在的地點,在網絡中更常見的是URI
(統一資源標識符),他是URL
的超集,在後面咱們討論的資源路徑都是用URI
表示的,咱們能夠看一個絕對URI
的例子。服務器
http://user:pass@www.example.cn:80/dir/index.htm?uid=1#ch1 http:協議方案名 user:pass 登陸信息 (登陸服務器的身份認證,可省略) www.example.cn 服務器地址(能夠是DNS可解析的名稱,也能夠時IP) 80 服務器端口號 (可選,不填則默認是80) dir/index.htm 帶層次的文件路徑 (指定服務器上的文件路徑來定位特指的資源) uid=1 查詢字符串 (針對已制定的文件路徑內的資源,使用查詢字符串傳入任意參數) #ch1 片斷標識符 (無明確用法,不予討論 ,可忽略)
那麼在瀏覽器或者其餘工具中輸入URI
後是怎麼應用的呢?答案是HTTP
請求報文(後面會講),HTTP
根據輸入的URI
和其餘參數生成HTTP
請求報文發送給服務器,忽略中間傳輸過程,HTTP
服務器獲得請求報文後,會對其進行解析,而後根據請求內容查詢服務器的資源,再以響應報文的形式傳回給客戶端。客戶端解析響應報文的內容,根據報文的內容進行下一步的任務。網絡
用於HTTP
協議交互的信息被稱爲HTTP
報文。請求端的HTTP
報文叫作請求報文,響應段(服務器端)的叫作響應報文。HTTP
報文自己是由多行數據構成的字符串文本。用(CR+LF作換行符,CR回車符,16進制0x0d,LF換行符,16進制0x0a)
下圖就是請求報文的格式
上圖能夠看到請求報文是由報文首部,空行,報文實體構成的。報文首部在通訊中相當重要,由於重要做用的信息幾乎都在這邊。報文主體是所須要的用戶和資源信息在這邊。
下面咱們重點說一下首部字段。使用首部字段是爲了給瀏覽器和服務器提供報文主體大小,所使用的語言,認證信息等內容。HTTP首部字段是由首部字段名和字段值構成的,中間用冒號":"分割。在請求報文中首部字段根據實際用處被分爲如下3種格式tcp
其中實體首部字段是針對報文的實體部分使用的首部,補充了資源內容更新時間等與實體有關的信息。
下面的表格顯示了經常使用首部字段的類型有哪些
通用首部字段工具
首部字段名 | 說明 |
---|---|
Cache-Control | 控制緩存的行爲 |
Date | 建立報文的日期時間 |
Connection | 逐跳首部、鏈接的管理 |
Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
請求首部字段post
首部字段名 | 說明 |
---|---|
Accept | 用戶代理可處理的媒體類型 |
Accept-Charset | 優先的字符集 |
Accept-Encoding | 優先的內容編碼 |
Accept-Language | 優先的語言(天然語言) |
Authorization | Web認證信息 |
Host | 請求資源所在服務器 |
User-Agent | HTTP 客戶端程序的信息 |
實體首部字段網站
首部字段名 | 說明 |
---|---|
Allow | 資源可支持的HTTP方法 |
Content-Encoding | 實體主體適用的編碼方式 |
Content-Type | 實體主體的媒體類型 |
Content-Length | 實體主體的大小(單位:字節) |
Content-Location | 替代對應資源的URI |
關於每一個字段的含義能夠參考一下《圖解http協議》這本書。
下面咱們看一下響應報文的格式
由上圖能夠看出來,響應報文格式和請求報文大同小異,都是有保溫首部,空行,報文實體組成。不一樣的是,組成報文首段的是通用首部,響應首部和實體首部組成。狀態行的不一樣和響應首部的增長是響應報文有別於請求報文的地方,咱們重點看一下狀態行。
狀態行中須要HTTP的版本,狀態碼和短語
下面的表格顯示了狀態碼和短語ui
狀態碼 | 類別 | 緣由短語 |
---|---|---|
1xx | Informational(信息性狀態碼) | 接收的請求正在處理 |
2xx | Success(成功狀態碼) | 請求正常處理完畢 |
3xx | Redirection(重定向狀態碼) | 須要進行附加操做以完成請求 |
4xx | Client Error(客戶端錯誤狀態碼) | 服務器沒法處理請求 |
5xx | Server Error(服務器錯誤狀態碼) | 服務器處理請求出錯 |
狀態碼種類繁多,咱們介紹實際上經常使用的幾種
200 OK 表示從客戶端發來的請求在服務器端被正常處理了。
204 No Content 該狀態碼錶明服務器接收的請求已成功處理,但在返回的響應報文中不含實體的主體部分。
206 Partial Content 該狀態碼錶示客戶端進行了範圍請求,而服務器成功執行了這部分的 GET 請求。響應報文中包含由 Content-Range 指定範圍的實體內容。
301 Moved Permanently 永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI,之後應使用資源如今所指的 URI
302 Found 臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI,但願用戶(本次)能使用新的 URI 訪問。
303 See Other 該狀態碼錶示因爲請求對應的資源存在着另外一個 URI,應使用 GET 方法定向獲取請求的資源。
304 Not Modified 該狀態碼錶示客戶端發送附帶條件的請求時,服務器端容許請求訪問資源,但未知足條件的狀況。
400 Bad Request 該狀態碼錶示請求報文中存在語法錯誤
401 Unauthorized 該狀態碼錶示發送的請求須要有經過 HTTP 認證(BASIC 認證、DIGEST 認證)的認證信息。另外若以前已進行過 1 次請求,則表示用 戶認證失敗。
403 Forbidden 該狀態碼代表對請求資源的訪問被服務器拒絕了。
404 Not Found 該狀態碼代表服務器上沒法找到請求的資源。除此以外,也能夠在服務器端拒絕請求且不想說明理由時使用。
500 Internal Server Error 該狀態碼代表服務器端在執行請求時發生了錯誤。
503 Service Unavailable 該狀態碼代表服務器暫時處於超負載或正在進行停機維護,如今沒法處理請求。
接下來,咱們看一下響應首部字段的幾個字段的含義。
首部字段名 | 說明 |
---|---|
Accept-Ranges | 是否接受字節範圍請求 |
Retry-After | 對再次發起請求的時機要求 |
ETag | 資源的匹配信息 |
上面就是咱們對請求報文和響應報文的簡單介紹
這篇文章主要是Android網絡請求的先導文章,因此這裏咱們主要介紹Android網絡請求的時候2個主要的方法,GET
和POST
網上有不少說法關於GET和POST的區別,你們能夠看看這篇文章GET和POST真正的區別,這個不是咱們這篇文章要討論的內容,咱們只須要記住一點,GET是從服務器獲取數據,POST是改變服務器數據就能夠了。
GET
方法用於獲取由URI所標示的資源信息,他是將請求參數直接放到URL後面,第一個參數前有一個"?",參數格式爲 參數名=參數值,參數之間經過"&"連接
POST
用於修改服務器的數據,因此他的參數通常存儲在報文的報文主體。