一、基礎知識
1、TCP/IP協議族
- IP協議：網絡層協議，保證了計算機之間可以發送和接收數據。
- TCP協議：傳輸層協議，一種端到端的協議，建立一個虛擬鏈路用于發送和接收數據，基于重發機制，提供可靠的通信連接。為了方便通信，將報文分割成多個報文段發送。
- UDP協議：傳輸層協議，一種無連接的協議，每個數據報都是一個獨立的信息，包括完整的源地址或目的地址，它在網絡上以任何可能的路徑傳往目的地，因此能否到達目的地，到達目的地的時間以及內容的正確性都是不能被保證的。
通信雙方一方作為服務器等待客戶提出請求并予以響應?？蛻魟t在需要服務時向服務器提出申請。服務器一般作為守護進程始終運行，監聽網絡端口，一旦有客戶請求，就會啟動一個服務進程來響應該客戶，同時自己繼續監聽服務端口，使后來的客戶也能及時得到服務。一個socket（通常都是server socket）等待建立連接時，另一個socket可以要求進行連接，一旦這兩個socket連接起來，它們就可以進行雙向數據傳輸，雙方都可以進行發送或接收操作。
2、TCP3次握手，4次揮手過程
2.1、建立連接協議（三次握手）
（1）客戶端發送一個帶SYN標志的TCP報文到服務器。（聽得到嗎？）
（2）服務端回應客戶端的報文同時帶ACK（acknowledgement，確認）標志和SYN（synchronize）標志。它表示對剛才客戶端SYN報文的回應；同時又標志SYN給客戶端，詢問客戶端是否準備好進行數據通訊。（聽得到，你能聽到我嗎？）
（3）客戶必須再次回應服務端一個ACK報文。（聽到了，我們可以說話了）
為什么需要“三次握手”？
在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，并一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由于收不到確認，就知道client并沒有要求建立連接?！薄?主要目的防止server端一直等待，浪費資源。
2.2、連接終止協議（四次揮手）
由于TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
（1） TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送（報文段4）。
（2） 服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
（3） 服務器關閉客戶端的連接，發送一個FIN給客戶端（報文段6）。
（4） 客戶段發回ACK報文確認，并將確認序號設置為收到序號加1（報文段7）。
為什么需要“四次揮手”？
那可能有人會有疑問，在tcp連接握手時為何ACK是和SYN一起發送，這里ACK卻沒有和FIN一起發送呢。原因是因為tcp是全雙工模式，接收到FIN時意味將沒有數據再發來，但是還是可以繼續發送數據。
3、請求報文
3.1、請求行
由3部分組成，分別為：請求方法、URL以及協議版本，之間由空格分隔
請求方法：GET、HEAD、PUT、POST等方法，但并不是所有的服務器都實現了所有的方法，部分方法即便支持，處于安全性的考慮也是不可用的
協議版本：常用HTTP/1.1
3.2、請求頭部
請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔
-
Host接受請求的服務器地址，可以是IP:端口號，也可以是域名 -
User-Agent發送請求的應用程序名稱 -
Connection指定與連接相關的屬性，如Connection:Keep-Alive -
Accept-Charset通知服務端可以發送的編碼格式 -
Accept-Encoding通知服務端可以發送的數據壓縮格式 -
Accept-Language通知服務端可以發送的語言 -
Range正文的字節請求范圍，為斷點續傳和并行下載提供可能，返回狀態碼是206
請求頭部的最后會有一個空行，表示請求頭部結束，接下來為請求正文，這一行非常重要，必不可少
3.3、請求正文
可選部分，比如GET請求就沒有請求正文
4、響應報文
由3部分組成，分別為：協議版本，狀態碼，狀態碼描述，之間由空格分隔
狀態碼：為3位數字，2XX表示成功，3XX表示資源重定向，4XX表示客戶端請求出錯，5XX表示服務端出錯
206狀態碼表示的是：客戶端通過發送范圍請求頭Range抓取到了資源的部分數據，得服務端提供支持
4.1、響應頭部
-
Server服務器應用程序軟件的名稱和版本 -
Content-Type響應正文的類型（是圖片還是二進制字符串） -
Content-Length響應正文長度 -
Content-Charset響應正文使用的編碼 -
Content-Encoding響應正文使用的數據壓縮格式 -
Content-Language響應正文使用的語言 -
Content-Range正文的字節位置范圍 -
Accept-Rangesbytes：表明服務器支持Range請求，單位是字節；none：不支持
正文的內容可以用gzip等進行壓縮，以提升傳輸速率
5、http協議中的多部分對象
報文的主體內可以包含多部分對象，通常用來發送圖片、文件或表單等。
5.1、multipart/form-data
Connection: keep-alive
Content-Length: 123
X-Requested-With: ShockwaveFlash/16.0.0.296
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Content-Type: multipart/form-data; boundary=Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.8
Range: bytes=0-1024
Cookie: bdshare_firstime=1409052493497
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Content-Disposition: form-data; name="position"
1425264476444
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Content-Disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain
...(file1.txt的數據)...
ue_con_1425264252856
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1
Content-Disposition: form-data; name="cm"
100672
--Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1--
a）在請求頭中Content-Type: multipart/form-data; boundary=Ij5ei4KM7KM7ae0KM7cH2ae0Ij5Ef1是必須的，boundary字符串可以隨意指定
b）上面有3個部分，分別用--boundary進行分隔。Content-Disposition: form-data; name="參數的名稱" + "\r\n" + "\r\n" + 參數值
c）--boundary-- 作為結束
二、Https
1、Http的缺點
- 通信使用明文，內容可能會被竊聽 —— 加密通信線路
- 不驗證通信方，可能遭遇偽裝 —— 證書
- 無法驗證報文的完整性，可能已被篡改 —— 數字簽名
Http+加密+認證+完整性保護=Https
Https就是身披SSL（Secure Socket Layer，安全套接層）協議這層外殼的Http。當使用了SSL之后，Http先和SSL通信，SSL再和TCP通信。
SSL（secure sockets layer）：安全套接層，它是在上世紀90年代中期，由網景公司設計的，為解決 HTTP 協議傳輸內容會被偷窺（嗅探）和篡改等安全問題而設計的，到了1999年，SSL成為互聯網上的標準，名稱改為TLS（transport layer security）：安全傳輸層協議，兩者可視為同一種東西的不同階段。
2、Https的工作原理
HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，TLS/SSL中使用了非對稱加密，對稱加密以及HASH算法。握手過程的具體描述如下：
- 瀏覽器將自己支持的一套加密規則發送給網站。
- 網站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發回給瀏覽器。證書里面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
- 瀏覽器獲得網站證書之后瀏覽器要做以下工作：
a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄里面會顯示一個小鎖頭，否則會給出證書不受信的提示。
b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，并用證書中提供的公鑰加密。
c) 使用約定好的HASH算法計算握手消息，并使用生成的隨機數對消息進行加密，最后將之前生成的所有信息發送給網站。 - 網站接收瀏覽器發來的數據之后要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，并驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手消息，發送給瀏覽器。 - 瀏覽器解密并計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之后所有的通信數據將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。
這里瀏覽器與網站互相發送加密的握手消息并驗證，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數據，為后續真正數據的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH算法如下：
- 非對稱加密算法：RSA，DSA/DSS
- 對稱加密算法：AES，RC4，3DES
- HASH算法：MD5，SHA1，SHA256
HTTPS對應的通信時序圖如下：
3、證書分類
SSL 證書大致分三類:
- 認可的證書頒發機構(如: VeriSign), 或這些機構的下屬機構頒發的證書.
- 沒有得到認可的證書頒發機構頒發的證書.
- 自簽名證書， 自己通過JDK自帶工具keytool去生成一個證書，分為臨時性的(在開發階段使用)或在發布的產品中永久性使用的兩種.
只有第一種, 也就是那些被安卓系統認可的機構頒發的證書, 在使用過程中不會出現安全提示。對于向權威機構（簡稱CA，Certificate Authority）申請過證書的網絡地址,用OkHttp或者HttpsURLConnection都可以直接訪問 ，不需要做額外的事情 。但是申請需要$$ （每年要交 100 到 500 美元不等的費用）。
CA機構頒發的證書有3種類型：
域名型SSL證書（DV SSL）：信任等級普通，只需驗證網站的真實性便可頒發證書保護網站；
企業型SSL證書（OV SSL）：信任等級強，須要驗證企業的身份，審核嚴格，安全性更高；
增強型SSL證書（EV SSL）：信任等級最高，一般用于銀行證券等金融機構，審核嚴格，安全性最高，同時可以激活綠色網址欄。
4、HTTPS協議和HTTP協議的區別：
- https協議需要到ca申請證書，一般免費證書很少，需要交費。
- http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
- http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
- http的連接很簡單,是無狀態的 。
- HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議， 要比http協議安全。
