標籤:
上篇文章介紹了傳輸層TCP協議的理論知識,本文主要介紹了TCP協議基礎之上HTTP協議和HTTPS協議的理論知識。
HTTP協議基於TCP協議定義了用戶端向伺服器請求資料的方式,它是面向事務的應用程式層協議具有靈活、簡單快速、無串連和無狀態的特點,是網路中交換各類資料的基礎。
HTTP協議的請求與響應報文
HTTP報文的格式如下所示:
我們可以看出,HTTP協議的報文主要分為報文首部和報文主體兩部分,中間用空行隔開。下面讓我們詳細介紹一下請求報文和響應報文:
請求報文
請求報文由三部分組成:請求行,請求前序,報文主體(請求資料)。如所示
請求行中包括了要求方法、URI、協議版本三部分資訊。
其中要求方法包括以下八種,常用的是GET和POST:
- GET 請求擷取Request-URI所標識的資源
- POST 在Request-URI所標識的資源後附加新的資料
- HEAD 請求擷取由Request-URI所標識的資源的響應訊息前序
- PUT 請求伺服器儲存一個資源,並用Request-URI作為其標識
- DELETE 請求伺服器刪除Request-URI所標識的資源
- TRACE 請求伺服器回送收到的請求資訊,主要用於測試或診斷
- CONNECT 保留將來使用
- OPTIONS 請求查詢服務器的效能,或者查詢與資源相關的選項和需求
請求的URI標識了請求資源的位置,而協議版本主要有HTTP/1.0和HTTP/1.1兩個版本。
請求前序中包含了有關請求的各種資訊,例如
User-Agent:產生請求的瀏覽器類型。
Accept:用戶端可識別的內容類型列表。
Host: 請求的主機名稱,允許多個網域名稱同處一個IP地址,即虛擬機器主機。
報文主體中存放了請求的資料,主要是在post方法中使用,適用於提交表單等場合。
響應報文
響應報文也由三部分構成:狀態行,響應前序,報文主體,如所示:
狀態行中包括HTTP協議版本,響應狀態代碼以及狀態代碼的文本描述。其中狀態代碼有五類:
1xx:指示資訊--表示請求已接收,繼續處理
2xx:成功--表示請求已被成功接收、理解、接受
3xx:重新導向--要完成請求必須進行更進一步的操作
4xx:用戶端錯誤--請求有語法錯誤或請求無法實現
5xx:伺服器端錯誤--伺服器未能實現合法的請求
響應前序中包含了有關響應的各種資訊。在報文主體中包含了需要傳輸的響應資料,例如HTML,二進位的資料等等。
介紹完了HTTP協議的請求與響應報文,下面以瀏覽器請求HTML頁面為例,我們看一下HTTP用戶端與伺服器之間的互動過程:
- 用戶端瀏覽器分析URL,向DNS請求解析地址
- 網域名稱系統DNS解析出伺服器的IP地址返回給用戶端
- 用戶端與伺服器建立TCP串連並發送GET請求報文
- 伺服器給出響應,把相應html檔案發送給用戶端瀏覽器
- 釋放TCP串連
- 瀏覽器顯示HTML檔案
HTTP使用了TCP協議保證了可靠傳輸,但其本身是不需連線的,也就是說雙方在發送報文之前無需建立串連。同時,HTTP協議也是無狀態的,伺服器不儲存用戶端資訊,更容易支援大量並發的HTTP請求。在HTTP1.0中,每次請求一個連線物件,都要發起一次串連,這樣會導致請求很低效。在HTTP1.1中,使用了持續串連,也就是說伺服器在響應用戶端請求後在一段時間內保持串連,這樣用戶端與伺服器之間在一段時間內可以持續保持著條串連。HTTP1.1協議持續串連有兩種工作方式:
- 非流水線方式:用戶端在收到一個響應報文後才發送下一個請求。伺服器在發送完一個對象後,TCP串連處於空閑狀態,浪費了伺服器資源。
- 流水線方式:用戶端在收到響應報文之前就可以連續發送請求報文,提高了傳輸效率。
cookie
上面提到HTTP協議是無狀態的,無論用戶端還是服務端都不記錄HTTP相關資訊。但是可以通過cookie來儲存用戶端和服務端儲存資訊,機制如下:
cookie是一種很小的文字檔,用於在用戶端儲存由伺服器確定的內容,請求報文會自動添加cookie中的內容。
HTTPS協議
HTTP協議在傳輸過程中採用明文,並且無認證和完整性驗證。而HTTPS就是使用了SSL協議的HTTP協議,雖然犧牲了速度,但是保證了資料的安全性,適用於金融支付環境。
總結完HTTP協議的知識,下一篇文章將會介紹在Android開發中會用到的HttpClient和UrlConnection庫。
Android網路編程隨想錄(2)