本節(jié)主要理解：
1.HTTP1.0和HTTP1.1和HTTP2.0的區(qū)別
2.HTTP請求報文頭內(nèi)容
3.https證書校驗原理
4.https的加密原理
5.AFNetworking的簡介
6.AFNetworking2.0與3.0與4.0的區(qū)別
7.中間人攻擊的原理孽尽，如何預(yù)防中間人攻擊藐鹤？

一.http與https的對比

什么是http？

超文本傳輸協(xié)議漏策，是一個基于請求與響應(yīng)，無狀態(tài)的舀寓，應(yīng)用層的協(xié)議歧匈，潮嵫基于TCP/IP協(xié)議傳輸數(shù)據(jù)昼捍，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個標準识虚。設(shè)計HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法。

什么是https?

《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP妒茬。HTTPS是一種通過計算機網(wǎng)絡(luò)進行安全通信的傳輸協(xié)議担锤，經(jīng)由HTTP進行通信，利用SSL/TLS建立全信道乍钻，加密數(shù)據(jù)包肛循。HTTPS使用的主要目的是提供對網(wǎng)站服務(wù)器的身份認證，同時保護交換數(shù)據(jù)的隱私與完整性银择。

1 HTTP1.0和HTTP1.1的區(qū)別
1.1 長連接(Persistent Connection)---加快響應(yīng)速度
HTTP1.1支持長連接和請求的流水線處理多糠，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲浩考，在HTTP1.1中默認開啟長連接keep-alive夹孔，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點。HTTP1.0需要使用keep-alive參數(shù)來告知服務(wù)器端要建立一個長連接析孽。

1.2 節(jié)約帶寬
HTTP1.0中存在一些浪費帶寬的現(xiàn)象搭伤，例如客戶端只是需要某個對象的一部分，而服務(wù)器卻將整個對象送過來了袜瞬，并且不支持斷點續(xù)傳功能怜俐。HTTP1.1支持只發(fā)送header信息（不帶任何body信息），如果服務(wù)器認為客戶端有權(quán)限請求服務(wù)器邓尤，則返回100拍鲤，客戶端接收到100才開始把請求body發(fā)送到服務(wù)器；如果返回401汞扎，客戶端就可以不用發(fā)送請求body了節(jié)約了帶寬季稳。

1.3 HOST域
在HTTP1.0中認為每臺服務(wù)器都綁定一個唯一的IP地址，因此澈魄，請求消息中的URL并沒有傳遞主機名（hostname）绞幌，HTTP1.0沒有host域。隨著虛擬主機技術(shù)的發(fā)展一忱，在一臺物理服務(wù)器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址谭确。HTTP1.1的請求消息和響應(yīng)消息都支持host域帘营，且請求消息中如果沒有host域會報告一個錯誤（400 Bad Request）。

1.4緩存處理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準逐哈，HTTP1.1則引入了更多的緩存控制策略例如Entity tag芬迄，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

1.5錯誤通知的管理
在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼昂秃，如409（Conflict）表示請求的資源與資源的當前狀態(tài)發(fā)生沖突禀梳；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除杜窄。

2 HTTP1.1和HTTP2.0的區(qū)別
2.1 多路復(fù)用---加快響應(yīng)速度
HTTP2.0使用了多路復(fù)用的技術(shù)，做到同一個連接并發(fā)處理多個請求算途，而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級塞耕。HTTP1.1也可以多建立幾個TCP連接，來支持處理更多并發(fā)的請求嘴瓤，但是創(chuàng)建TCP連接本身也是有開銷的扫外。

2.2 頭部數(shù)據(jù)壓縮---節(jié)省帶寬
在HTTP1.1中，HTTP請求和響應(yīng)都是由狀態(tài)行廓脆、請求/響應(yīng)頭部筛谚、消息主體三部分組成。一般而言停忿，消息主體都會經(jīng)過gzip壓縮驾讲，或者本身傳輸?shù)木褪菈嚎s過后的二進制文件，但狀態(tài)行和頭部卻沒有經(jīng)過任何壓縮席赂，直接以純文本傳輸吮铭。隨著Web功能越來越復(fù)雜，每個頁面產(chǎn)生的請求數(shù)也越來越多氧枣，導(dǎo)致消耗在頭部的流量越來越多沐兵，尤其是每次都要傳輸UserAgent、Cookie這類不會頻繁變動的內(nèi)容便监，完全是一種浪費扎谎。
HTTP1.1不支持header數(shù)據(jù)的壓縮，HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮烧董，這樣數(shù)據(jù)體積小了毁靶，在網(wǎng)絡(luò)上傳輸就會更快。

2.3 服務(wù)器推送
服務(wù)端推送是一種在客戶端請求之前發(fā)送數(shù)據(jù)的機制逊移。網(wǎng)頁使用了許多資源：HTML预吆、樣式表、腳本胳泉、圖片等等拐叉。在HTTP1.1中這些資源每一個都必須明確地請求。這是一個很慢的過程扇商。瀏覽器從獲取HTML開始凤瘦，然后在它解析和評估頁面的時候，增量地獲取更多的資源案铺。因為服務(wù)器必須等待瀏覽器做每一個請求蔬芥，網(wǎng)絡(luò)經(jīng)常是空閑的和未充分使用的。
為了改善延遲，HTTP2.0引入了server push笔诵，它允許服務(wù)端推送資源給瀏覽器返吻，在瀏覽器明確地請求之前，免得客戶端再次創(chuàng)建連接發(fā)送請求到服務(wù)器端獲取乎婿。這樣客戶端可以直接從本地加載這些資源测僵，不用再通過網(wǎng)絡(luò)。

2.HTTP請求報文頭內(nèi)容
常見的HTTP請求報文頭屬性
Accept
請求報文可通過一個“Accept”報文頭屬性告訴服務(wù)端 客戶端接受什么類型的響應(yīng)次酌。

Accept:text/plain

Cookie
如上報文頭相當于告訴服務(wù)端恨课，俺客戶端能夠接受的響應(yīng)類型僅為純文本數(shù)據(jù)啊，你丫別發(fā)其它什么圖片啊岳服，視頻啊過來剂公，那樣我會歇菜的~~~：

客戶端的Cookie就是通過這個報文頭屬性傳給服務(wù)端的哦！如下所示：
Cookie: $Version=1; Skin=new jsessionid=5F4771183629C9834F8382E23BE13C4C

服務(wù)端是怎么知道客戶端的多個請求是隸屬于一個Session呢吊宋？注意到后臺的那個jsessionid=5F4771183629C9834F8382E23BE13C4C木有纲辽？原來就是通過HTTP請求報文頭的Cookie屬性的jsessionid的值關(guān)聯(lián)起來的！（當然也可以通過重寫URL的方式將會話ID附帶在每個URL的后面哦）璃搜。

Referer
表示這個請求是從哪個URL過來的拖吼，假如你通過google搜索出一個商家的廣告頁面，你對這個廣告頁面感興趣这吻，鼠標一點發(fā)送一個請求報文到商家的網(wǎng)站吊档，這個請求報文的Referer報文頭屬性值就是http://www.google.com。

Cache-Control

對緩存進行控制唾糯，如一個請求希望響應(yīng)返回的內(nèi)容在客戶端要被緩存一年怠硼，或不希望被緩存就可以通過這個報文頭達到目的。

如以下設(shè)置移怯，相當于讓服務(wù)端將對應(yīng)請求返回的響應(yīng)內(nèi)容不要在客戶端緩存：
Cache-Control: no-cache

3.HTTP特點：
1.無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲香璃，對事物處理沒有“記憶”能力，比如訪問一個網(wǎng)站需 要反復(fù)進行登錄操作
2.無連接：HTTP/1.1之前舟误，由于無狀態(tài)特點葡秒，每次請求需要通過TCP三次握手四次揮手，和服務(wù)器重新建立連接嵌溢。比如某個客戶機在短時間多次請求同一個資源眯牧，服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過用戶的請求，所以每次需要重新響應(yīng)請求赖草，需要耗費不必要的時間和流量炸站。
3.基于請求和響應(yīng)：基本的特性，由客戶端發(fā)起請求疚顷，服務(wù)端響應(yīng)
4 簡單快速、靈活
5.通信使用明文、請求和響應(yīng)不會對通信方進行確認腿堤、無法保護數(shù)據(jù)的完整性
PS:TLS是傳輸層加密協(xié)議阀坏，前身是SSL協(xié)議，由網(wǎng)景公司1995年發(fā)布笆檀，有時候兩者不區(qū)分

HTTPS特點：
內(nèi)容加密：采用混合加密技術(shù)忌堂，中間者無法直接查看明文內(nèi)容
驗證身份：通過證書認證客戶端訪問的是自己的服務(wù)器
保護數(shù)據(jù)完整性：防止傳輸?shù)膬?nèi)容被中間人冒充或者篡改

二.HTTPS的數(shù)據(jù)傳輸

HTTPS采用的是非對稱加密+對稱加密結(jié)合的方式保證數(shù)據(jù)加密的

圖片.png

中文版??????

圖片.png

大概過程
https證書校驗原理（簡介版）
1.客戶端向服務(wù)端發(fā)其請求，服務(wù)端發(fā)送證書酗洒。
2.客戶端本地有內(nèi)置的證書簽發(fā)機構(gòu)對應(yīng)的公鑰士修，客戶端使用公鑰解密簽名，然后自己計算hash看是否一致樱衷。

如果不一致棋嘲，客戶端會進行信任鏈的驗證操作。

重點＞毓稹沸移！

1）服務(wù)器用RSA生成公鑰和私鑰
2）客戶端發(fā)起https請求，連接到服務(wù)端的443端口
3）服務(wù)端將公鑰放在證書中傳給客戶端侄榴，私鑰自己保存
4）客戶端驗證證書合法性雹锣，驗證成功的話，生成一串隨機數(shù)作為數(shù)據(jù)傳輸對稱加密的密鑰癞蚕，我們稱之為對稱密鑰
5）然后客戶端用公鑰對密鑰進行加密, 再發(fā)給服務(wù)器
6）服務(wù)端收到客戶端發(fā)出的數(shù)據(jù)蕊爵，使用私鑰解密，獲取到隨機數(shù)密鑰桦山。即可進行數(shù)據(jù)傳輸

三.AFNetworking與HTTPS

1.AFNetworking簡介
框架結(jié)構(gòu)

這里分析4.0版本的結(jié)構(gòu)攒射。主要分為五個部分：

1、NSURLSession：網(wǎng)絡(luò)通信模塊度苔，兩個文件AFURLSessionManager匆篓，AFHTTPSessionManager。AFHTTPSessionManager繼承與AFURLSessionManager

2寇窑、Reachability 網(wǎng)絡(luò)狀態(tài)監(jiān)聽鸦概，AFNetworkReachabilityManager

3、Security 網(wǎng)絡(luò)通訊安全策略模塊甩骏，AFSecurityPolicy

4窗市、Serialization 序列化，AFURLResponseSerialization饮笛，AFURLRequestSerialization

5咨察、UIKit 對于UIKit的擴展庫

AFNetworking的請求AFHTTPSessionManager 有一個專門的屬性來處理加密策略，AFSecurityPolicy
1.創(chuàng)建一個AFSecurityPolicy

AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];

傳入?yún)?shù)表示https驗證模式福青，一共三種選項

typedef NS_ENUM(NSUInteger, AFSSLPinningMode) {
    //不驗證
    AFSSLPinningModeNone,
    //只驗證公鑰
    AFSSLPinningModePublicKey,
    //驗證證書
    AFSSLPinningModeCertificate,
};

此外AFSecurityPolicy還有三個重要屬性

//可以去匹配服務(wù)端證書驗證的證書
@property (nonatomic, strong, nullable) NSSet <NSData *> *pinnedCertificates;
//是否支持非法的證書（例如自簽名證書）
@property (nonatomic, assign) BOOL allowInvalidCertificates;
//是否去驗證證書域名是否匹配
@property (nonatomic, assign) BOOL validatesDomainName;

我們項目使用的是機構(gòu)頒發(fā)的證書所以配置比較簡單

- (AFSecurityPolicy *)customSecurityPolicy {
    NSData *data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"server" ofType:@"p12"]];
    AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
    securityPolicy.allowInvalidCertificates = NO;
    securityPolicy.validatesDomainName = NO;
    securityPolicy.pinnedCertificates = [NSSet.alloc initWithObjects:data, nil];
    return securityPolicy;
}

2.AFNetworking3.0與2.0的區(qū)別

最大區(qū)別： AFNetworking2.0使用的NSURLConnection,3.0使用的是NSURLSession

1）NSURLConnection下載文件時摄狱，先是將整個文件下載到內(nèi)存脓诡，然后再寫入到沙盒，如果文件比較大媒役，就會出現(xiàn)內(nèi)存暴漲的情況祝谚。而使用NSURLSessionUploadTask下載文件，會默認下載到沙盒中的tem文件中酣衷，不會出現(xiàn)內(nèi)存暴漲的情況交惯。

2）NSURLConnection停止請求的發(fā)送，停止后不能繼續(xù)訪問穿仪，需要創(chuàng)建新的請求席爽。NSURLSession有三個控制方法，取消(cancel)啊片、暫停(suspend)只锻、繼續(xù)(resume)，暫停以后可以通過繼續(xù)恢復(fù)當前的請求任務(wù)钠龙。

3）AFN3.0 NSURLSession 不需要2.0NSURLConnection 的常駐線程炬藤。
2.0需要常駐線程是因為請求回調(diào)依賴當前線程，而AFN3.0 NSURLSession的請求回調(diào)不需要依賴當前線程碴里，可以指定回調(diào)的delegateQueue沈矿，這樣也就不需要再對線程進行保活咬腋。

7.中間人攻擊的原理羹膳，如何預(yù)防中間人攻擊？
SSL劫持攻擊

SSL劫持攻擊即SSL證書欺騙攻擊根竿，攻擊者為了獲得HTTPS傳輸?shù)拿魑臄?shù)據(jù)陵像，需要先將自己接入到客戶端和目標網(wǎng)站之間；在傳輸過程中偽造服務(wù)器的證書寇壳，將服務(wù)器的公鑰替換成自己的公鑰醒颖，這樣，中間人就可以得到明文傳輸帶Key1壳炎、Key2和Pre-Master-Key泞歉，從而竊取客戶端和服務(wù)端的通信數(shù)據(jù)；

但是對于客戶端來說匿辩，如果中間人偽造了證書腰耙，在校驗證書過程中會提示證書錯誤，由用戶選擇繼續(xù)操作還是返回铲球，由于大多數(shù)用戶的安全意識不強挺庞，會選擇繼續(xù)操作，此時稼病，中間人就可以獲取瀏覽器和服務(wù)器之間的通信數(shù)據(jù)

圖片.png

參考文章
AFNetworking之于https認證
HTTP和HTTPS協(xié)議，看一篇就夠了
https原理

over !!