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

青蛙要fly發表於2018-08-06

前言

介於自己的網路方面知識爛的一塌糊塗，所以準備寫相關網路的文章，但是考慮全部寫在一篇太長了，所以分開寫，希望大家能仔細看，最好可以指出我的錯誤，讓我也能糾正。

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.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時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
例如: 1、輸入：www.guet.edu.cn 瀏覽器自動轉換成：www.guet.edu.cn/
2、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

非對稱加密
對稱加密
雜湊演算法

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

我們知道平常我們想保護我們的資料安全，肯定要對資料進行加密，一般都是用對稱加密，然後加密後給對方，但是要提前二個人都知道金鑰，如果提前不知道，就要通過某種方式把金鑰傳過去，那就存在問題了，因為傳的時候可能被盜取，被盜取後加密就如同明文。
那問題就轉變成怎麼樣才能安全的把對稱加密的金鑰給對方，那麼就用到了非對稱加密方式，伺服器拿著私鑰，然後給傳送方公鑰，然後傳送方拿著公鑰來加密對稱加密的金鑰，這樣這個金鑰只有拿著私鑰的伺服器能解開拿到。然後就可以用對稱的金鑰進行加密資料互動了。
上面的問題又演變成我怎麼提前把非對稱加密的公鑰安全的給傳送方，而不會中間被人偷偷換掉公鑰。這時候就需要用CA證書（這個證書相當於公鑰了）。

有些人會問為啥不直接使用非對稱加密來進行資料加密傳輸，因為非對稱加密解密的速度比對稱加密慢。

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

我們來個更完整的流程：

客戶端發起HTTPS請求
服務端的配置： 採用HTTPS協議的伺服器必須要有一套數字證書，可以是自己製作或者CA證書。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用CA證書則不會彈出提示頁面。這套證書其實就是一對公鑰和私鑰。公鑰給別人加密使用，私鑰給自己解密使用。
傳送證書： 這個證書其實就是公鑰，只是包含了很多資訊，如證書的頒發機構，過期時間等。
客戶端解析證書： 這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨即值，然後用證書對該隨機值進行加密。
傳送加密資訊： 這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通訊就可以通過這個隨機值來進行加密解密了。
服務段解密資訊： 服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將資訊和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠複雜，資料就夠安全。
傳輸加密後的資訊： 這部分資訊是服務段用私鑰加密後的資訊，可以在客戶端被還原。
客戶端解密資訊： 客戶端用之前生成的私鑰解密服務段傳過來的資訊，於是獲取瞭解密後的內容。