Android技能樹 — 網絡小結(3)之HTTP/HTTPS

前言

介於本身的網絡方面知識爛的一塌糊塗，因此準備寫相關網絡的文章，可是考慮所有寫在一篇太長了，因此分開寫，但願你們能仔細看，最好能夠指出個人錯誤，讓我也能糾正。

1.講解相關的整個網絡體系結構：

Android技能樹 — 網絡小結(1)之網絡體系結構

2.講解相關網絡的重要知識點，好比不少人都聽過相關網絡方面的名詞，可是僅限於聽過而已，什麼tcp ,udp ,socket ,websocket, http ,https ,而後webservice是啥，跟websocket很像，socket和websocket啥關係長的也很像，session,token,cookie又是啥。

Android技能樹 — 網絡小結(2)之TCP/UDP

Android技能樹 — 網絡小結(3)之HTTP/HTTPS

Android技能樹 — 網絡小結(4)之socket/websocket/webservice

相關網絡知識點小結- cookie/session/token（待寫）

3.相關的第三方框架的源碼解析，畢竟如今面試個大點的公司，okhttp和retrofit源碼是必問的。

Android技能樹 — 網絡小結(6)之 OkHttp超超超超超超超詳細解析

Android技能樹 — 網絡小結(7)之 Retrofit源碼詳細解析

---

正文

平時面試別人，問他們http和https的區別，不少都會回答：https 更安全， 可是問他們具體的http相關基礎，https爲啥更安全了，不少人就都答不上來了。因此此次咱們來看下具體相關的知識點。

1.Http請求報文

咱們發給服務器的內容看上去只是傳了幾個參數值給他們，但實際上也是會封裝成一個包，而後發過去。

咱們先來看咱們平時發送給服務器的請求包：

主要有四塊：

1. 請求行
2. 請求頭部
3. 空行
4. 請求數據

可能有些人不太清楚，咱們一一來進行說明：

1.1 請求行

1.1.1 請求行 - 請求方法

請求方法無非是：

固然不少接口並無嚴格按照Restful來進行：

在Restful以前的操做：
http://127.0.0.1/user/query/1 GET  根據用戶id查詢用戶數據
http://127.0.0.1/user/save POST 新增用戶
http://127.0.0.1/user/update POST 修改用戶信息
http://127.0.0.1/user/delete GET/POST 刪除用戶信息

RESTful用法：
http://127.0.0.1/user/1 GET  根據用戶id查詢用戶數據
http://127.0.0.1/user  POST 新增用戶
http://127.0.0.1/user  PUT 修改用戶信息
http://127.0.0.1/user  DELETE 刪除用戶信息
複製代碼

因此更多的不少人員的信息提交給後臺更多的仍是使用了GET 及 POST。

GET 和 POST的區別：

你們之前可能也常常看到過GET 和 POST的區別，說GET 不安全，是明文，POST更安全一些，看不到相關提示信息，並且GET 有字數限制等。其實這些都是更加相對於之前的web瀏覽器時代,由於之前get請求咱們直接能夠在瀏覽器的輸入欄裏面看到相關信息；並且所謂的GET請求的字數限制，是由於瀏覽器對於url的字數長度作了限制。

結論：

• 安卓開發都是直接手機app直接發出請求到服務器，你看不到相應的url,並且你若是不用https的話，get和post都是明文，抓包抓一些也都看獲得信息。
• 並且由於不是瀏覽器，對於url的字數長度也沒有限制。
• 不過Get中文須要編碼，URLEncoder.encode(params, "gbk");

因此理論上你用get和post在移動端開發的時候差異不大，不過仍是規範點好，通常咱們都是直接獲取信息是用get，而後提交信息給服務器是使用post。

1.1.2 請求行 - URL

HTTP URL (URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息)的格式以下： http://host[「:」port][abs_path]

http表示要經過HTTP協議來定位網絡資源；
host表示合法的Internet主機域名或者IP地址；
port指定一個端口號，爲空則使用缺省端口80；
abs_path指定請求資源的URI；

若是URL中沒有給出abs_path，那麼當它做爲請求URI時，必須以「/」的形式給出，一般這個工做瀏覽器自動幫咱們完成。
例如: 一、輸入：www.guet.edu.cn 瀏覽器自動轉換成：www.guet.edu.cn/
二、http:192.168.0.116:8080/index.jsp

這個很簡單，就是咱們日常要跟服務器交互的某個接口的url。這個就很少說了。

1.1.3 請求行 - 協議版本

HTTP協議咱們主要有三種 ： HTTP/1.0,HTTP/1.1,HTTP/2.0

HTTP/1.0 與 HTTP/1.1的差異：

• 長鏈接： HTTP 1.0須要使用keep-alive參數來告知服務器端要創建一個長鏈接，而HTTP1.1默認支持長鏈接。在同一個TCP的鏈接中可傳送多個HTTP請求 & 響應（畢竟http基於TCP，不是長鏈接每次都要三次握手，效率過低）
• 節約帶寬： HTTP 1.1支持只發送header信息(不帶任何body信息)
• 多個請求 & 響應可同時進行、可重疊
• 引入更加多的請求頭 & 響應頭（如 與身份認證、狀態管理 & Cache緩存等機制相關的、HTTP1.0無host字段）

HTTP/1.1 與 HTTP/2.0的差異：

• 多路複用： HTTP2.0使用了多路複用的技術，作到同一個鏈接併發處理多個請求，並且併發請求的數量比HTTP1.1大了好幾個數量級。
• 數據壓縮： HTTP1.1不支持header數據的壓縮，HTTP2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快。
• 服務器推送： 當咱們對支持HTTP2.0的web server請求數據的時候，服務器會順便把一些客戶端須要的資源一塊兒推送到客戶端，省得客戶端再次建立鏈接發送請求到服務器端獲取。這種方式很是合適加載靜態資源。

---

1.2 請求頭部

咱們能夠看到請求頭是由一些列的鍵值對組成，好比：

報文主體對象類型
Content-Type : text/html

字段值對應單個HTTP首部字段能夠有多個值，如
Keep-Alive : timeout=15, max=100
複製代碼

若HTTP首部字段重複瞭如何 根據瀏覽器的不一樣，處理狀況可能不能，有些瀏覽器優先處理第一次出現的首部字段，而有些則會優先處理最後出現的首部字段。

1.2.1 請求頭部 - 通用首部字段

請求報文和響應報文兩方都會使用的首部。

1.2.2 請求頭部 - 請求首部字段

客戶端發送請求報文給服務器時使用，補充了請求的附加內容，客戶端信息，響應內容相關的優先級等信息

1.2.3 請求頭部 - 實體首部字段

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

1.3 空行

分割請求頭和請求體的做用，表示接下來的內容爲請求體。

1.4 請求數據

可選部分，如 GET請求就能夠無請求數據，請求數據就是咱們主動填的傳過去的內容，這個請求數據具體有下面幾種格式：

1.5 請求報文總結

---

2. 響應報文

咱們知道日常咱們收到後臺傳來的信息是：

{
    "success":true,
    "msg":"xxxx",
    "data":{
        "key1":value1,
        "key2":value2
    }
}
(固然其中的``success``通常的也是會用``code``值來返回，
而後移動端來判斷是不是200便可。)
複製代碼

同理和上面同樣，也是封裝成一個包發送給咱們，因此咱們看下相應報文的結構：

咱們能夠看到 響應頭部和請求頭部相似，響應正文也和請求正文同樣，差異在於狀態行與請求行的區別。咱們分別一個個來看

2.1 狀態行

這個估計不少人都知道的。就不細說了。（PS：有次面試問我302具體是啥，和301，303啥區別。印象很深。）

2.2 響應頭部

其實和請求頭部很相似，差異就是中間的請求首部字段換成了響應首部字段：

因此咱們重點看下響應首部字段 ：

2.3 空行

同請求報文的空行

2.4 響應正文

同請求正文，也仍是那三種格式。

2.5 請求報文總結

---

3. HTTPS安全的緣由

咱們知道https安全，那到底安全在哪裏呢？？

HTTPS = HTTP + SSL/TLS

1. 非對稱加密
2. 對稱加密
3. 散列算法

咱們看到上面的三個名詞，單獨問這三個名詞的含義，我估計百分之99的人都知道，其實https裏面就用了這三者，具體怎麼用這三者的呢？

1. 咱們知道日常咱們想保護咱們的數據安全，確定要對數據進行加密，通常都是用對稱加密，而後加密後給對方，可是要提早二我的都知道密鑰，若是提早不知道，就要經過某種方式把密鑰傳過去，那就存在問題了，由於傳的時候可能被盜取，被盜取後加密就如同明文。
2. 那問題就轉變成怎麼樣才能安全的把對稱加密的密鑰給對方，那麼就用到了非對稱加密方式，服務器拿着私鑰，而後給發送方公鑰，而後發送方拿着公鑰來加密對稱加密的密鑰，這樣這個密鑰只有拿着私鑰的服務器能解開拿到。而後就能夠用對稱的密鑰進行加密數據交互了。
3. 上面的問題又演變成我怎麼提早把非對稱加密的公鑰安全的給發送方，而不會中間被人偷偷換掉公鑰。這時候就須要用CA證書（這個證書至關於公鑰了）。

有些人會問爲啥不直接使用非對稱加密來進行數據加密傳輸，由於非對稱加密解密的速度比對稱加密慢。

採用HTTPS協議的服務器必需要有一套數字證書（CA證書），能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。

咱們來個更完整的流程：

1. 客戶端發起HTTPS請求

2. 服務端的配置： 採用HTTPS協議的服務器必需要有一套數字證書，能夠是本身製做或者CA證書。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用CA證書則不會彈出提示頁面。這套證書其實就是一對公鑰和私鑰。公鑰給別人加密使用，私鑰給本身解密使用。

3. 傳送證書： 這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等。

4. 客戶端解析證書： 這部分工做是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等，若是發現異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨即值，而後用證書對該隨機值進行加密。

5. 傳送加密信息： 這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

6. 服務段解密信息： 服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。

7. 傳輸加密後的信息： 這部分信息是服務段用私鑰加密後的信息，能夠在客戶端被還原。

8. 客戶端解密信息： 客戶端用以前生成的私鑰解密服務段傳過來的信息，因而獲取瞭解密後的內容。

---

4. HTTP 與 HTTPS區別

結語：

emmmm.......輕噴便可。有錯請留言，我能夠進行修改。其中文章配圖部分引自下面參考文章。

參考文章：

HTTP與HTTPS握手的那些事

HTTP首部（一）

計算機網絡：這是一份全面& 詳細 HTTP知識講解

分分鐘讓你理解HTTPS

個人博客即將搬運同步至騰訊雲+社區，邀請你們一同入駐：cloud.tencent.com/developer/s…