Android HTTP協議請求網路(一)之認識探索

艾陽丶發表於2017-05-08
AndroidHTTP協議

Android HTTP協議請求網路(二)之HttpClient方式

Android HTTP協議請求網路(三)之HttpURLConnection方式

gitHup整合Demo地址：https://github.com/aiyangtianci/NetworkRequestDemo


一、HTTP協議初級探索：

1、HTTP（Hypertext Transfer Protocol）中文 “超文字傳輸協議”，是一種為分散式，合作式，多媒體資訊系統服務，面向應用層的協議，是Internet上目前使用最廣泛的應用層協議，它基於傳輸層的TCP協議進行通訊，HTTP協議是通用的、無狀態的協議。

這幾個名詞有一種通俗的解釋：

  • 通訊協議：雙方對話的標準
  • 通用的：用了都說好，誰用誰知道
  • 無狀態的：翻臉不認人
  • 超文字：除了文字，還可以是音訊、視訊

2、HTTP與Android之間的關係：

3、HTTP學習的知識點：

Http協議基礎概念、請求響應模型、提交請求的不同方法、響應狀態判斷、獲取響應以及解析響應、資料下載的實現方法、資料上傳的實現方法、請求頭詳細內容、響應頭詳細內容等

二、HTTP協議概念：

1、HTTP協議定義：
WWW是以Internet作為傳輸媒介的一個應用系統，WWW網上基本的傳輸單位是Web網頁。WWW的工作是基於客戶機/伺服器計算模型，由Web瀏覽器和Web伺服器構成，兩者之間採用超文字傳輸協議HTTP進行通訊。
HTTP協議時基於TCP/IP協議之上的協議，是Web瀏覽器和Web伺服器之間的應用層的協議，是通用的、無狀態的物件導向的協議。 
如果要實現網路互聯我們要思考兩個需要解決的技術問題：

  • 第一：瀏覽器和伺服器是通過什麼來連線的。
  • 第二：這種連線方式是怎麼實現的。
通過Internet去傳送到伺服器當中，而Internet內部可以通過三種方式來實現傳送資訊和資料：
  • 第一種：HTTP協議，也是在工作中最常用的，是建立在TCP/IP基礎上實現的。
  • 第二種：FTP協議
  • 第三種：TCP/IP協議，它也是最底層的協議，其它的方式必須是要通過它，但是要想實現這種協議必須要實現socket程式設計，這種方法是用來上傳一些比較大的檔案，視訊，進行斷點續傳的操作。
2、客戶端連線伺服器實現內部的原理如下：


分析上圖，步驟如下：
  • 第一步：在瀏覽器客戶端中得到使用者輸入的內容。 
  • 第二步：瀏覽器得到這個網址之後，內部會將這個域名傳送到DNS上，進行域名解析。得到它的IP之後就會連結到指定的伺服器上，假如伺服器的地址是：221.104.13.32:80，從瀏覽器到伺服器埠它使用到最底層的TCP/IP協議。 
  • 第三步：實現TCP/IP協議用Socket來完成，使用了Socket的套接字。 
  • 第四步：伺服器端的80埠監聽客戶端的連結，這樣客戶端到伺服器就連結上了。
  • 伺服器接收到這些內容之後，並按照這些請求的路徑找到對應的頁面，進一步找到對應的網頁內容，返回給客戶端。
通俗一點講，使用者在瀏覽器輸入網址，通過http協議發出去，網址經過DNS域名解析，解析成指定的ip地址，並在80埠上監聽使用者的請求。伺服器監聽到請求之後，會以三種方式返回給客戶端：HTML、XML、JASON。
HTTP返回請求資料的三種方式:
  • 1、以HTML程式碼內容返回。 
  • 2、以XML字串的形式返回，在以後的android開發中這種形式返回資料比較多。 
  • 3、以JSON物件形式返回，在網路流量上考慮JSON要比XML方式要好一些，便於解析。
在Android當中，一般使用xml和Json資料解析。


三、使用HTTP協議訪問網路：

Android中的WebView控制元件已經在後臺幫我們處理好了傳送HTTP請求、接收服務響應、解析返回資料，以及最終的頁面展示這幾步工作，不過由於它封裝得太好了，反而不能直觀地看出HTTP協議是如何工作的。因此需要我們通過手動傳送HTTP請求的方式，來更加深入的瞭解這一過程。

在Android上傳送HTTP請求的方式一般有兩種：HttpURLConnection和HttpCient。接下來幾篇文章將陸續講解實戰用法並附帶原始碼demo。



四、HTTP協議請求詳解：

這裡寫圖片描述

  • 客戶端->伺服器 
    客戶端向伺服器傳送請求主要包含以下資訊：請求的Url地址、請求頭以及可選的請求體，開啟百度首頁，客戶端向伺服器傳送的資訊如下所示：

    這裡寫圖片描述

    • 請求URL（Request URL） 
      上圖中的Request URL就是請求的Url地址，即https://www.baidu.com，該Url沒有附加其他的引數。其實可以通過？和&符向URL地址後面追加一系列的鍵值對引數，比如地址https://www.baidu.com/s?ie=utf-8&wd=Android，該Url包含兩個鍵值對,ie=utf-8，以及wd=Android，ie和wd是key，utf-8和Android分別是其對應的value，服務端可以獲取ie和wd所對應的value的值。由此我們可以看出，Url可以攜帶額外的資料資訊。一般情況下，URL的長度不能超過2048個字元，即2KB，超過此限制的話伺服器可能就不識別。

    • 請求頭（Request Headers） 
      上圖中Request Headers部分就是請求頭，請求頭其實也是一些鍵值對，不過這些鍵值通常都是W3C定義了的一些標準的Http請求頭的名稱，請求頭包含了客戶端想告訴服務端的一些後設資料資訊，注意是後設資料，而不是資料，比如請求頭User-Agent會告訴伺服器這條請求來自於什麼瀏覽器，再比如請求頭Accept-Encoding會告訴伺服器客戶端支援的壓縮格式。除了這些標準的請求頭，我們還可以新增自定義的請求頭。

    • 請求體（Request Body） 
      之前我們提到，URL的最大長度就是2048個字元，如果我們傳送的資料很大，超過了2KB怎麼辦？我們可以將很大的資料放到請求體中，GET請求不支援請求體，只有POST請求才能設定請求體。請求體中可以放置任意的位元組流，從而可以很方便地傳送任意格式的資料，服務端只需要讀取該輸入流即可。

  • 伺服器->客戶端 
    伺服器接收到客戶端發來的請求後，會進行相應的處理，並向客戶端輸出資訊，輸出的資訊包括響應頭和響應體。

    • 響應頭 （Response Headers） 
      響應頭也是一些鍵值對，如下所示： 
      這裡寫圖片描述

      響應頭包含了伺服器想要告訴客戶端的一些後設資料資訊，注意不是資料，是後設資料，比如通過響應頭Content-Encoding告訴客戶端伺服器所採用的壓縮格式，響應頭Content-Type告訴客戶端響應體是什麼格式的資料，再比如服務端可以通過多個Set-Cookie響應頭向客戶端寫入多條Cookie資訊，等等。剛剛提到的幾個請求頭都是W3C規定的標準的請求頭名稱，我們也可以在服務端向客戶端寫入自定義的響應頭。

    • 響應體 （Response Body） 
      響應體是服務端向客戶端傳輸的實際的資料資訊，本質就是一堆位元組流，可以表示文字，也可以表示圖片或者其他格式的資訊，如下所示： 
      這裡寫圖片描述

GET vs POST

Http協議支援的操作有GET、POST、HEAD、PUT、TRACE、OPTIONS、DELETE，其中最最常用的還是GET和POST操作，下面我們看一下GET和POST的區別。

GET:

  • GET請求可以被快取。
  • 我們之前提到，當傳送鍵值對資訊時，可以在URL上面直接追加鍵值對引數。當用GET請求傳送鍵值對時，鍵值對會隨著URL一起傳送的。
  • 由於GET請求傳送的鍵值對時隨著URL一起傳送的，所以一旦該URL被黑客截獲，那麼就能看到傳送的鍵值對資訊，所以GET請求的安全性很低，不能用GET請求傳送敏感的資訊（比如使用者名稱密碼）。
  • 由於URL不能超過2048個字元，所以GET請求傳送資料是有長度限制的。
  • 由於GET請求較低的安全性，我們不應該用GET請求去執行增加、刪除、修改等的操作，應該只用它獲取資料。

POST:

  • POST請求從不會被快取。
  • POST請求的URL中追加鍵值對引數，不過這些鍵值對引數不是隨著URL傳送的，而是被放入到請求體中傳送的，這樣安全性稍微好一些。
  • 應該用POST請求傳送敏感資訊，而不是用GET。
  • 由於可以在請求體中傳送任意的資料，所以理論上POST請求不存在傳送資料大小的限制。
  • 當執行增減、刪除、修改等操作時，應該使用POST請求，而不應該使用GET請求。

相關文章