android開發之網絡學習-http/https

HTTP與HTTPS的區別

此標題下先對比學習兩者的一些概念，區別和關系等知識，後面會詳細介紹兩種應用層協議。

HTTP和HTTPS的基本概念

HTTP（HyperText Transfer Protocol）：是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。

HTTPS（Hyper Text Transfer Protocol Secure）：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL（Secure Sockets Layer）層，HTTPS的安全基礎是SSL（Secure Sockets Layer），因此加密的詳細內容就需要SSL。

HTTPS協議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。

HTTP與HTTPS的安全性

HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取瞭Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，所以安全性是很低的。簡單的說，http是HTTP協議運行在TCP之上。所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。

為瞭解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS，為瞭數據傳輸的安全，HTTPS在HTTP的基礎上加入瞭SSL協議，SSL依靠證書來驗證服務器的身份，並為瀏覽器和服務器之間的通信加密。對比http，https是HTTP運行在SSL/TLS之上，SSL/TLS運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行瞭非對稱加密。此外客戶端可以驗證服務器端的身份，如果配置瞭客戶端驗證，服務器方也可以驗證客戶端的身份。

HTTP與HTTPS的區別

簡單的總結一下：

https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。 http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。 http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。 http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

HTTP詳解

HTTP協議特點

1.支持客戶/服務器模式。 2.簡單快速：客戶向服務器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定瞭客戶與服務器聯系的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。 3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。 4.無連接：無連接的含義是限制每次連接隻處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。采用這種方式可以節省傳輸時間。 5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

HTTP協議之URL

HTTP URL (URL是一種特殊類型的URI，包含瞭用於查找某個資源的足夠的信息)的格式如下：
https://host[“:”port][abs_path]
http表示要通過HTTP協議來定位網絡資源；host表示合法的Internet主機域名或者IP地址；port指定一個端口號，為空則使用缺省端口80；abs_path指定請求資源的URI；如果URL中沒有給出abs_path，那麼當它作為請求URI時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
例如:
1、輸入：www.guet.edu.cn 瀏覽器自動轉換成：https://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp

HTTP協議之請求

一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，下圖給出瞭請求報文的一般格式。

請求行

請求行分為三個部分：請求方法、請求地址和協議版本。

請求方法

HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
最常的兩種GET和POST，如果是RESTful接口的話一般會用到GET、POST、DELETE、PUT。

GET　　　　請求獲取Request-URI所標識的資源
POST　　　 在Request-URI所標識的資源後附加新的數據
HEAD　　　 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT　　　　 請求服務器存儲一個資源，並用Request-URI作為其標識
DELETE　　 請求服務器刪除Request-URI所標識的資源
TRACE　　 請求服務器回送收到的請求信息，主要用於測試或診斷
CONNECT　 保留將來使用
OPTIONS　 請求查詢服務器的性能，或者查詢與資源相關的選項和需求

請求地址

URL:統一資源定位符，是一種自願位置的抽象唯一識別方法。
組成：<協議>：//<主機>：<端口>/<路徑>
端口和路徑有時可以省略（HTTP默認端口號是80）

協議版本

協議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1

請求頭部

請求頭部為請求報文添加瞭一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。
常見請求頭如下：

請求頭部的最後會有一個空行，表示請求頭部結束，接下來為請求數據，這一行非常重要，必不可少。

請求數據

可選部分，比如GET請求就沒有請求數據。（因為它是寫在URL中的）
下面是一個POST方法的請求報文：

POST 　/index.php　HTTP/1.1 　　 請求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2　　請求頭
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer:https://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
　　空行
username=aa&password=1234　　請求數據

HTTP協議之響應

HTTP響應報文主要由狀態行、響應頭部、空行以及響應數據組成。

狀態行

由3部分組成，分別為：協議版本，狀態碼，狀態碼描述。
其中協議版本與請求報文一致，狀態碼描述是對狀態碼的簡單描述，所以這裡就隻介紹狀態碼。

狀態碼
狀態代碼為3位數字。
1xx：指示信息–表示請求已接收，繼續處理。
2xx：成功–表示請求已被成功接收、理解、接受。
3xx：重定向–要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤–請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤–服務器未能實現合法的請求。

下面列舉幾個常見的：

響應頭部

與請求頭部類似，為響應報文添加瞭一些附加信息
常見響應頭部如下：

響應數據

用於存放需要返回給客戶端的數據信息。
下面是一個響應報文的實例：（在開發中，我們需要自定義類實現Interceptor接口打印響應的數據，幫助我們乃至服務端更好的定位錯誤，如果您需要，可@我或自行www.baidu.com）

    HTTP/1.1 200 OK　　狀態行
    Date: Sun, 17 Mar 2013 08:12:54 GMT　　響應頭部
    Server: Apache/2.2.8 (Win32) PHP/5.2.5
    X-Powered-By: PHP/5.2.5
    Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/  （重點關註下）
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Pragma: no-cache
    Content-Length: 4393  （重點關註下）
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Content-Type: text/html; charset=utf-8  （重點關註下）
    　　空行

    

　　響應數據


Hello HTTP!

Content-Type學習

常見的媒體格式類型如下：
text/html ： HTML格式
text/plain ：純文本格式
text/xml ： XML格式
image/gif ：gif圖片格式
image/jpeg ：jpg圖片格式
image/png：png圖片格式

以application開頭的媒體格式類型：

application/xhtml+xml ：XHTML格式
application/xml ： XML數據格式
application/atom+xml ：Atom XML聚合格式
application/json ： JSON數據格式
application/pdf ：pdf格式
application/msword ： Word文檔格式
application/octet-stream ： 二進制流數據（如常見的文件下載）
application/x-www-form-urlencoded ： 中默認的encType，form表單數據被編碼為key/value格式發送到服務器（表單默認的提交數據的格式）
另外一種常見的媒體格式是上傳文件之時使用的：
multipart/form-data ： 需要在表單中進行文件上傳時，就需要使用該格式
以上就是我們在日常的開發中，經常會用到的若幹content-type的內容格式。

HTTPS詳解

HTTPS上面已經介紹就不多瞭，下面介紹下HTTPS具體是如何進行加密，解密，驗證的，且看下圖

1. 客戶端發起HTTPS請求

這個沒什麼好說的，就是用戶在瀏覽器裡輸入一個https網址，然後連接到server的443端口。

2. 服務端的配置

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

3. 傳送證書

這個證書其實就是公鑰，隻是包含瞭很多信息，如證書的頒發機構，過期時間等等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS（Transport Layer Security 安全傳輸層協議 用於在兩個通信應用程序之間提供保密性和數據完整性）來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機值。然後用證書對該隨機值進行加密。

5. 傳送加密信息

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通信就可以通過這個隨機值來進行加密解密瞭。

6. 服務段加密信息

服務端用私鑰解密後，得到瞭客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以隻要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。

7. 傳輸加密後的信息

這部分信息是服務段用私鑰加密後的信息，可以在客戶端被還原

8. 客戶端解密信息

客戶端用之前生成的私鑰解密服務段傳過來的信息，於是獲取瞭解密後的內容。整個過程第三方即使監聽到瞭數據，也束手無策。

HTTPS的優缺點

優：
1、SEO方面

谷歌曾在2014年8月份調整搜索引擎算法，並稱“比起同等HTTP網站，采用HTTPS加密的網站在搜索結果中的排名將會更高”。

2、安全性

盡管HTTPS並非絕對安全，掌握根證書的機構、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現行架構下最安全的解決方案，主要有以下幾個好處：

（1）、使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
（2）、HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程中不被竊取、改變，確保數據的完整性。
（3）、HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加瞭中間人攻擊的成本。

缺：

1、SEO方面

據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增加10%到20%的耗電，此外，HTTPS協議還會影響緩存，增加數據開銷和功耗，甚至已有安全措施也會受到影響也會因此而受到影響。
而且HTTPS協議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼作用。
最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國傢可以控制CA根證書的情況下，中間人攻擊一樣可行。

2、經濟方面

（1）、SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
（2）、SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
（3）、HTTPS連接緩存不如HTTP高效，大流量網站如非必要也不會采用，流量成本太高。
（4）、HTTPS連接服務器端資源占用高很多，支持訪客稍多的網站需要投入更大的成本，如果全部采用HTTPS，基於大部分計算資源閑置的假設的VPS的平均成本會上去。
（5）、HTTPS協議握手階段比較費時，對網站的相應速度有負面影響，如非必要，沒有理由犧牲用戶體驗。

補充

也許讀到最後，您對SSL/TSL還有些不理解，TLS1.0和SSL3.0幾乎沒有區別，事實上我們現在用的都是TLS，但因為歷史上習慣瞭SSL這個稱呼，平常還是以SSL為多。