前言
做軟件開發(fā)少不了與網(wǎng)絡(luò)打交道，在大學學習的計算機網(wǎng)絡(luò)知識僅能撐起一張補考試卷，工作中需要時就感覺四肢乏力、大腦空虛、萬劫不復(fù)，于是經(jīng)過數(shù)次的翻查網(wǎng)上的資料，整理了一篇文章，以后自己忘掉后少走些彎路，多一點參考。
轉(zhuǎn)載需注明出處。
原文鏈接
1. HTTP
這是一個非常龐大的知識體，網(wǎng)上資料也鋪天蓋地鋪來，維基百科上說“HTTP(超文本傳輸協(xié)議)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，設(shè)計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。通過HTTP或者HTTPS協(xié)議請求的資源由統(tǒng)一資源標識符（Uniform Resource Identifiers，URI）來標識。HTTP是一個客戶端終端（用戶）和服務(wù)器端（網(wǎng)站）請求和應(yīng)答的標準”。就像2000年Roy Fielding博士在他的論文中提出REST（Representational State Transfer）風格的軟件架構(gòu)模式成為了Web API的標準，HTTP的發(fā)展是由Tim Berners-Lee在CERN發(fā)起由W3C和IETF制定的一套規(guī)范。蒂姆·伯納斯-李作為萬維網(wǎng)的發(fā)明者，在去年(2016年)獲得圖靈獎。
本篇只提供iOS開發(fā)相關(guān)知識點，如果深入挖掘，TCP/IP, UDP, OSI模型, 三次握手等知識點是挖掘不完的，就像一只爬蟲，爬到多少是個頭呢，所以說花至半開酒致微醉最佳，本章簡要總結(jié)請求格式和響應(yīng)格式。
-
請求格式
發(fā)出的請求信息（message request）包括請求行，請求頭，空行，消息體。
-
請求行
請求行是請求消息的第一行，由三部分組成：分別是請求方法（GET/POST/DELETE/PUT/HEAD）、請求資源的URI路徑、HTTP的版本號。
GET / HTTP/1.1 -
請求頭
請求頭中的信息有和緩存相關(guān)的頭（Cache-Control，If-Modified-Since）、客戶端身份信息（User-Agent）等等。
Host: faichou.space Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/527.36 (KHTML, like Gecko) Chrome/57.0.2557.133 Safari/557.37 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4 Cookie: _ga=GA1.2.1965313251.1464240344; _gat=1 If-Modified-Since: Sun, 26 Mar 2017 14:29:48 GMT?
-
空行
空的行。
-
消息體
請求體是客戶端發(fā)給服務(wù)端的請求數(shù)據(jù)，這部分數(shù)據(jù)并不是每個請求必須的。
-
-
響應(yīng)格式
服務(wù)器接收處理完請求后返回一個HTTP響應(yīng)消息給客戶端。HTTP響應(yīng)消息的格式包括：狀態(tài)行、響應(yīng)頭、空行、消息體。每部分內(nèi)容占一行。
-
狀態(tài)行
狀態(tài)行位于相應(yīng)消息的第一行，有HTTP協(xié)議版本號，狀態(tài)碼和狀態(tài)說明三部分構(gòu)成。
HTTP/1.1 304 Not Modified -
響應(yīng)頭
響應(yīng)頭是服務(wù)器傳遞給客戶端用于說明服務(wù)器的一些信息，以及將來繼續(xù)訪問該資源時的策略
Server: GitHub.com Date: Sat, 08 Apr 2017 07:15:29 GMT Last-Modified: Sun, 26 Mar 2017 14:29:48 GMT Access-Control-Allow-Origin: * Expires: Sat, 08 Apr 2017 07:25:29 GMT Cache-Control: max-age=600 X-GitHub-Request-Id: F804:6693:14F6B41:1C1E639:58E88E11?
-
空行
空的行。
-
消息體
響應(yīng)體是服務(wù)端返回給客戶端的HTML文本內(nèi)容，或者其他格式的數(shù)據(jù)，比如：視頻流、圖片或者音頻數(shù)據(jù)。
-
2. Cookie
指某些網(wǎng)站為了辨別用戶身份而儲存在用戶本地終端（Client Side）上的數(shù)據(jù)（通常經(jīng)過加密）?！?wikipedia
Cookie解決了HTTP連接無狀態(tài)的問題，是客戶端和服務(wù)器共同保持維護一些狀態(tài)數(shù)據(jù)。Cookie會被附加到http請求中，大多數(shù)瀏覽器都支持，無需用戶做額外操作，當然用戶可以手動刪除cookie。cookie的最大長度是4KB左右。使用cookie可以維持用戶的登錄態(tài)，只需要在cookie中添加一個token就可以。
客戶端請求信息，服務(wù)器響應(yīng)返回，那么cookie被放在哪里呢？
通常是在響應(yīng)頭中，被放置在Set-Cookie字段中。這個字段瀏覽器會自動識別，并保存下來，下次請求時候會將cookie附加到請求頭中去。
舉個栗子
瀏覽器第一次給m.itdecent.cn發(fā)送請求
GET / HTTP/1.1
Host: m.itdecent.cn
...
服務(wù)器返回帶有兩個Set-Cookie字段的頭
HTTP/1.1 200 OK
Server: Tengine
Date: Sat, 08 Apr 2017 07:38:22 GMT
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...
服務(wù)器返回的信息除了包含首頁外，還有兩個重要的頭部信息Set-Cookie，它指示瀏覽器保存下來。
Cookie的分類
Cookie總是保存在客戶端中，按在客戶端中的存儲位置，可分為內(nèi)存Cookie和硬盤Cookie。
內(nèi)存Cookie由瀏覽器維護，保存在內(nèi)存中，瀏覽器關(guān)閉后就消失了，其存在時間是短暫的。硬盤Cookie保存在硬盤里，有一個過期時間，除非用戶手工清理或到了過期時間，硬盤Cookie不會被刪除，其存在時間是長期的。所以，按存在時間，可分為非持久Cookie和持久Cookie。
按照以上分類，服務(wù)器返回的兩個Cookie一個是內(nèi)存Cookie(session cookie)另一個是硬盤Cookie(persistent cookie)。theme指定了網(wǎng)頁的主題是亮色，它不包含Expires或Max-Age字段，故生存期短，瀏覽器關(guān)閉即死亡。sessionToken是客戶端和服務(wù)器共同保持一個長登陸態(tài)的標志，它生存到Wed, 09 Jun 2021 10:18:14 GMT，所以說它是一個persistent cookie。
接下來，瀏覽器繼續(xù)請求錢包頁面，其中請求頭中包含Cookie字段，字段中有上次服務(wù)器發(fā)來的theme和sessionToken
GET /wallet HTTP/1.1
Host: m.itdecent.cn
Cookie: theme=light; sessionToken=abc123
...
這樣服務(wù)器就知道這個用戶的這次請求是和前一次請求是相關(guān)的。服務(wù)器再收到請求后，返回錢包頁面，并且返回新的Set-Cookie給用戶。這樣就可以指示用戶添加新cookie，更新cookie，或者刪除cookie了。
3. HTTPS
HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure，它是一個網(wǎng)絡(luò)安全傳輸協(xié)議。HTTPS經(jīng)由HTTP通信，利用TSL/SSL來加密數(shù)據(jù)包。
在計算機網(wǎng)絡(luò)知識中，TSL/SSL介于應(yīng)用層和TCP層之間。應(yīng)用層數(shù)據(jù)不再直接傳遞給傳輸層，而是傳遞給TSL/SSL層，TSL/SSL層對從應(yīng)用層收到的數(shù)據(jù)進行加密，并增加自己的TSL/SSL頭。
與HTTP的URL由http://起始且默認使用端口80不同，HTTPS的URL由https://起始且默認使用端口443。
HTTPS比HTTP多的就是安全，HTTP的數(shù)據(jù)是明文傳輸，在OSI模型中，任意一層捕獲到數(shù)據(jù)，既可以一覽無余，導(dǎo)致信息泄露，甚至可能被篡改，運營商流量劫持就是一個很好的例子。
在原理上是如何做到安全的呢？我們知道建立TCP連接需要三次握手，而TLS握手需要九次，而這個過程主要就是用來做非對稱加密。這里引申出來兩個重要概念，非對稱加密和對稱加密，理解它們有助于理解Charles抓HTTPS包。
-
對稱加密
對稱加密就是加解密使用同一個密鑰?？蛻舳撕头?wù)器通信一般會動態(tài)生成一個密鑰，所以密鑰如何安全傳遞就成了問題。非對稱加密正是為了解決這個問題，也就是密鑰交換（也叫密鑰協(xié)商）。
-
非對稱加密
瀏覽器和服務(wù)器每次新建會話時都使用非對稱密鑰交換算法協(xié)商出對稱密鑰，使用這些對稱密鑰完成應(yīng)用數(shù)據(jù)的加解密和驗證，整個會話過程中的密鑰只在內(nèi)存中生成和保存，而且每個會話的對稱密鑰都不相同（除非會話復(fù)用），中間者無法竊取。
服務(wù)器有一對公鑰和私鑰，公鑰用于加密，私鑰用于解密。密鑰交換過程：服務(wù)器的公鑰是公開的，私鑰是不公開的，只有服務(wù)器持有。瀏覽器先向服務(wù)器取得公鑰，然后用公鑰加密自己的私鑰連同自己私鑰加密的請求一并發(fā)送給服務(wù)器。服務(wù)器使用自己私鑰解密得到瀏覽器的私鑰，使用瀏覽器的私鑰解密請求。然后再用瀏覽器的私鑰加密response發(fā)送回服務(wù)器。
4. Charles
Charles 是在 Mac 下常用的網(wǎng)絡(luò)封包截取工具，在做移動開發(fā)時，我們?yōu)榱苏{(diào)試與服務(wù)器端的網(wǎng)絡(luò)通訊協(xié)議，常常需要截取網(wǎng)絡(luò)封包來分析。
Charles 通過將自己設(shè)置成系統(tǒng)的網(wǎng)絡(luò)訪問代理服務(wù)器，使得所有的網(wǎng)絡(luò)訪問請求都通過它來完成，從而實現(xiàn)了網(wǎng)絡(luò)封包的截取和分析。
除了在做移動開發(fā)中調(diào)試端口外，Charles 也可以用于分析第三方應(yīng)用的通訊協(xié)議。配合 Charles 的 SSL 功能，Charles 還可以分析 Https 協(xié)議。
傳統(tǒng)的中間人攻擊是無法攻擊HTTPS的，那么Charles是如何抓取的呢？
之前一直好奇，總認為Charles不能獲取服務(wù)器的秘鑰，是怎么抓取解密到包呢？簡直是魔法呀！
其實Charles也是個中間人，只不過它偽裝成了服務(wù)器，也打扮成了客戶端，是一個雙重身份。Charles使用時我們需要手動添加證書信任。這樣瀏覽器眼中的服務(wù)器就是Charles，而服務(wù)器眼中的客戶端也是Charles，從而實現(xiàn)了雙向數(shù)據(jù)解密。是不是很簡單呢。
