HTTP —— 超文本傳輸協(xié)議資源
Http協(xié)議是一個基于請求與響應模式的肛捍、無狀態(tài)的隐绵、應用層的協(xié)議。
? ? ? 請求與響應模式：只有在客戶端請求后拙毫，服務器才會返回相應的數(shù)據(jù)給客戶端依许。服務器處理完客戶的請求，并收到客戶的應答后缀蹄，即斷開連接峭跳。
?????? 無狀態(tài)協(xié)議：同一個客戶端的這次請求和上次請求是沒有對應關(guān)系，對http服務器來說缺前，它并不知道這兩個請求來自同一個客戶端蛀醉。 為了解決這個問題， Web程序引入了Cookie機制來維護狀態(tài)衅码。
??????? 在Http/1.1使用了持續(xù)連接：就是萬維網(wǎng)服務器在發(fā)送響應后仍會在一段時間內(nèi)保持這條連接拯刁，使同一個客戶和該服務器可以繼續(xù)在這條連接上傳送后續(xù)的HTTP請求報文和響應報文。這種持續(xù)連接有兩種工作方式：非流水線方式和流水線方式逝段。
??????? 非流水線方式：是客戶在收到前一個響應后才能發(fā)出下一個請求垛玻。
??????? 流水線方式：是客戶在收到Http的響應報文之前就能夠接著發(fā)送新的請求報文。
??????? HTTP協(xié)議以明文方式發(fā)送內(nèi)容惹恃，不提供任何方式的數(shù)據(jù)加密夭谤，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務器之間的傳輸報文，就可以直接讀懂其中的信息巫糙，因此朗儒，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息醉锄。
? ? ? ? 為了解決HTTP協(xié)議的這一缺陷乏悄，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩也唬琀TTPS在HTTP的基礎上加入了SSL/TLS協(xié)議檩小，SSL依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密烟勋。
HTTPS——用安全套接字層傳送的超文本傳輸協(xié)議规求，簡單講是HTTP的安全版
https是以安全為目標的HTTP通道，簡單講是HTTP的安全版卵惦，即HTTP下加入SSL/TLS層阻肿，然后才進入到運輸層傳輸，HTTPS的安全基礎是SSL/TLS沮尿，因此加密的詳細內(nèi)容就需要SSL/TLS丛塌。
HTTPS和HTTP的區(qū)別主要如下：
1、https協(xié)議需要到ca申請證書畜疾，一般免費證書較少赴邻，因而需要一定費用。
2啡捶、http是超文本傳輸協(xié)議姥敛，信息是明文傳輸，https則是具有安全性的SSL/TLS加密傳輸協(xié)議届慈。
3徒溪、http和https使用的是完全不同的連接方式，用的端口也不一樣金顿，前者是80臊泌，后者是443。
4揍拆、http的連接很簡單渠概，是無狀態(tài)的；https協(xié)議是由SSL/TLS + HTTP協(xié)議構(gòu)建的可進行加密傳輸嫂拴、身份認證的網(wǎng)絡協(xié)議播揪，比http協(xié)議安全。
SSL/TLS
SSL：（Secure Socket Layer筒狠，安全套接字層）猪狈，為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全辩恼，利用數(shù)據(jù)加密(Encryption)技術(shù)雇庙，可確保數(shù)據(jù)在網(wǎng)絡上之傳輸過程中不會被截取谓形。它已被廣泛地用于Web瀏覽器與服務器之間的身份認證和加密數(shù)據(jù)傳輸。SSL協(xié)議位于TCP/IP協(xié)議與各種應用層協(xié)議之間疆前，為數(shù)據(jù)通訊提供安全支持寒跳。SSL協(xié)議可分為兩層： SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝竹椒、壓縮童太、加密等基本功能的支持。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上胸完，用于在實際的數(shù)據(jù)傳輸開始前书释，通訊雙方進行身份認證、協(xié)商加密算法舶吗、交換加密密鑰等征冷。
TLS：(Transport Layer Security，傳輸層安全協(xié)議)誓琼，用于兩個應用程序之間提供保密性和數(shù)據(jù)完整性。TLS 1.0建立在SSL 3.0協(xié)議規(guī)范之上肴捉，是SSL 3.0的后續(xù)版本腹侣，可以理解為SSL 3.1，它是寫入了RFC的齿穗。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）傲隶。較低的層為 TLS 記錄協(xié)議，位于某個可靠的傳輸協(xié)議（例如 TCP）上面窃页。
http的請求與響應
狀態(tài)碼
Response 消息中的第一行叫做狀態(tài)行，由HTTP協(xié)議版本號畦木， 狀態(tài)碼袖扛， 狀態(tài)消息
三部分組成。狀態(tài)碼用來告訴HTTP客戶端,HTTP服務器是否產(chǎn)生了預期的Response.HTTP/1.1中定義了5類狀態(tài)碼十籍，
狀態(tài)碼由三位數(shù)字組成蛆封，第一個數(shù)字定義了響應的類別
1XX? 提示信息 - 表示請求已被成功接收，繼續(xù)處理
2XX? 成功 - 表示請求已被成功接收勾栗，理解惨篱，接受
3XX? 重定向 - 要完成請求必須進行更進一步的處理
4XX? 客戶端錯誤 -? 請求有語法錯誤或請求無法實現(xiàn)
5XX? 服務器端錯誤 -?? 服務器未能實現(xiàn)合法的請求
URL解析
URL(Uniform Resource Locator，統(tǒng)一資源定位符) 地址用于描述一個網(wǎng)絡上的資源,? 基本格式如下
schema://host[:port#]/path/.../[?query-string][#anchor]
scheme指定低層使用的協(xié)議(例如：http, https, ftp)
hostHTTP服務器的IP地址或者域名
port#HTTP服務器的默認端口是80围俘，這種情況下端口號可以省略砸讳。
如果使用了別的端口机断，必須指明，例如 http://www.cnblogs.com:8080/
path訪問資源的路徑
query-string發(fā)送給http服務器的數(shù)據(jù)
anchor-錨
URL 的一個例子
http://www.mywebsite.com/sj/test/test.aspx?name=sviergn&x=true#stuff
Schema:? ? ? ? ? ? ? ?? http
host:? ? ? ? ? ? ? ? ?? www.mywebsite.com
path:? ? ? ? ? ? ? ? ?? /sj/test/test.aspx
Query String:? ? ?? name=sviergn&x=true
Anchor:? ? ? ? ? ? ? ?? stuff
iOS如何利用AFN進行HTTPS請求
1绣夺、需要的資源：服務器端.cer證書吏奸，客戶端.p12證書及密碼
2、新建一個類：繼承自AFHTTPSessionManager陶耍，需要設置一下AFSecurityPolicy奋蔚，把模式設置為AFSSLPinningModeCertificate
//? 使用證書驗證模式
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
// allowInvalidCertificates 是否允許無效證書（也就是自建的證書），默認為NO烈钞，如果是需要驗證自建證書泊碑，需要設置為YES
securityPolicy.allowInvalidCertificates = YES;
為了實現(xiàn)客戶端驗證，必須調(diào)用setSessionDidReceiveAuthenticationChallengeBlock并替換AFNetworking的默認實現(xiàn)毯欣，其中包括從client.p12里解析客戶端證書馒过。
http和https參考自：http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html?
