目前做iOS開(kāi)發(fā)以來(lái)，使用的都是HTTP協(xié)議，所幸現(xiàn)在接觸到的東西還是之前的知識(shí)儲(chǔ)備所能夠應(yīng)付的，正好趁著還沒(méi)有入職的這段時(shí)間補(bǔ)充點(diǎn)這方面的知識(shí)，當(dāng)然還是從我比較熟悉的iOS的角度來(lái)進(jìn)行學(xué)習(xí)。最近看的書(shū)是《圖解HTTP》，也算是看了該書(shū)的一個(gè)總結(jié)吧。

shouhuiImage

網(wǎng)絡(luò)基礎(chǔ)

TCP/IP協(xié)議族

首先TCP/IP協(xié)議族不僅包括了TCP協(xié)議和IP協(xié)議，而是很多協(xié)議的總稱。TCP/IP協(xié)議按照層次分為4層，分別是：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。HTTP協(xié)議在應(yīng)用層，之后是傳輸層的TCP協(xié)議，然后是網(wǎng)絡(luò)層的IP協(xié)議，數(shù)據(jù)鏈路層是與硬件相關(guān)的協(xié)議。HTTP協(xié)議規(guī)定一端是客戶端，一端是服務(wù)器，這樣的話數(shù)據(jù)流從客戶端從上至下傳輸，每經(jīng)過(guò)一層就加上報(bào)文頭，到了服務(wù)器端之后數(shù)據(jù)流就會(huì)從下至上逐成解析。

TCP協(xié)議

為了準(zhǔn)確無(wú)誤的將數(shù)據(jù)送到目標(biāo)處，并且能夠確認(rèn)數(shù)據(jù)最終是否送達(dá)到對(duì)方。為了實(shí)現(xiàn)這個(gè)目標(biāo)，TCP采用三次握手的方式。

結(jié)合實(shí)際中的例子比較容易理解三次握手是怎么實(shí)現(xiàn)的。比如在古代，A托商隊(duì)給B一個(gè)東西，并且雙方都要確認(rèn)這條線路的安全性，那么A在這個(gè)東西里面放了一個(gè)標(biāo)志SYN，B收到之后在東西里面放置了ACK表明B已經(jīng)知道了，商隊(duì)回來(lái)的時(shí)候?qū)|西交還給A，A會(huì)看到自己放置的SYN和B放置的ACK，這樣的話A就可以確認(rèn)這條道路的安全性，但是這個(gè)時(shí)候B并不知道A收到了數(shù)據(jù)，所以這個(gè)時(shí)候A還需要在東西里放置ACK給B表明A收到了東西。簡(jiǎn)單的說(shuō)就是每個(gè)端發(fā)送出東西的時(shí)候都要獲得回應(yīng)才能確認(rèn)東西到達(dá)，所以就是三次。

IP協(xié)議

IP協(xié)議的作用就是把各種數(shù)據(jù)包傳給對(duì)方。為了能確保準(zhǔn)確送達(dá)，所以需要IP地址和MAC地址，IP地址指明了節(jié)點(diǎn)被分配的地址，MAC地址指的是網(wǎng)卡所屬的固定地址，IP地址可變換，但是MAC地址是不會(huì)改變的。所以IP間的通信就需要MAC地址，這里就需要知道IP地址和MAC地址的對(duì)應(yīng)關(guān)系，所以又出現(xiàn)了另一種協(xié)議ARP（Address Resolution Protocol），能通過(guò)IP地址查詢到MAC地址。

HTTP數(shù)據(jù)流程圖

HTTP

HTTP協(xié)議

首先先接受幾個(gè)和HTTP相關(guān)的短語(yǔ)。

代理

代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它扮演了位于服務(wù)器和客戶端“中間人”的角色，接收由客戶端發(fā)送的請(qǐng)求并轉(zhuǎn)發(fā)給服務(wù)器，同時(shí)也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶端。

在開(kāi)發(fā)過(guò)程中經(jīng)常需要翻墻，也就是使用在國(guó)外的代理，這樣的話就可以正常訪問(wèn)國(guó)外的網(wǎng)站了。

網(wǎng)關(guān)

網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器，接收從客戶端接收到的請(qǐng)求之后會(huì)對(duì)請(qǐng)求進(jìn)行處理，有時(shí)候客戶端本身并不知道自己對(duì)接的是一個(gè)網(wǎng)關(guān)。

HTTP首部

HTTP協(xié)議首先是客戶端和服務(wù)器之間的協(xié)議，在沒(méi)有擴(kuò)展協(xié)議的情況下只能從客戶端發(fā)起請(qǐng)求然后服務(wù)端返回響應(yīng)。

這是一個(gè)簡(jiǎn)單的示意圖，分別展示了請(qǐng)求報(bào)文首部和響應(yīng)報(bào)文的首部。這里可以看到通用首部字段和實(shí)體首部字段這兩個(gè)部分是相同的，只是在請(qǐng)求首部字段和響應(yīng)首部字段會(huì)有區(qū)別。

GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0
Accept: text/html, application/xml;q=0.9
Accept-language: ja, en-us

這里列舉了幾個(gè)我們經(jīng)常看到的請(qǐng)求報(bào)文首部參數(shù)，這里寫(xiě)明了請(qǐng)求是GET方法的請(qǐng)求，使用的是HTTP/1.1協(xié)議，請(qǐng)求的地址是hackr.jp，客戶端接收的數(shù)據(jù)是HTML數(shù)據(jù)...各種首部非常多，在用到的時(shí)候可以查閱相關(guān)的資料。

iOS中會(huì)用到的首部

HTTP/1.1協(xié)議中有很多的首部，但是大部分是針對(duì)瀏覽器來(lái)使用的，就目前的知識(shí)儲(chǔ)備來(lái)看，在iOS開(kāi)發(fā)當(dāng)中有用到的首部有請(qǐng)求首部If-Match和響應(yīng)首部的Etag配合使用來(lái)做網(wǎng)絡(luò)緩存；還有HTTP的擴(kuò)展協(xié)議Cookie來(lái)記錄用戶的登陸狀態(tài)。

If-Match & Etag

之前看過(guò)一篇文章講的是iOS緩存，其中有一個(gè)講到的就是利用HTTP協(xié)議自帶的網(wǎng)絡(luò)緩存來(lái)實(shí)現(xiàn)。

If-Match: "123456"

只有當(dāng)服務(wù)器資源的Etag的值為 “123456” 時(shí)，才會(huì)對(duì)客戶端的請(qǐng)求作出響應(yīng)，因?yàn)橘Y源的更新那么Etag值就會(huì)發(fā)生更新，所以可以識(shí)別出資源是否已經(jīng)更新或者已經(jīng)過(guò)期。

If-Modifield-Since

這個(gè)參數(shù)是請(qǐng)求報(bào)文首部中的參數(shù)，可以指定資源的有效時(shí)間，從字面上就可以看出如果從給出的時(shí)間上沒(méi)有更新的話，服務(wù)器就會(huì)返回 304 Not Modifield ,如果有更新就會(huì)返回資源并且響應(yīng)首部上也會(huì)加上 Last-Modifield: last time

Cookie && Set-Cookie

Cookie是請(qǐng)求報(bào)文首部字段，Set-Cookie是響應(yīng)報(bào)文首部字段。首先是服務(wù)器返回Set-Cookie字段將Cookie值返回給客戶端，客戶端每次請(qǐng)求的時(shí)候?qū)⒃撝蒂x值給Cookie字段，用這種形式來(lái)確定用戶登錄。我們?cè)陂_(kāi)發(fā)iOS客戶端的時(shí)候往往需要使用Token來(lái)實(shí)現(xiàn)用戶登錄，我們可以利用HTTP的這個(gè)屬性來(lái)進(jìn)行認(rèn)證。

HTTPS

由于iOS要求全面要支持https協(xié)議，所以還是有必要了解下什么是HTTPS協(xié)議。

HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS

HTTPS并非是一個(gè)新的協(xié)議，只是HTTP通信接口部分使用SSL和TLS協(xié)議代替而已。HTTP是直接和TCP通信，HTTPS是先和SSL通信，SSL和TCP通信，所以說(shuō)HTTPS就是套了一層SSL協(xié)議外殼的HTTP協(xié)議。

證書(shū)

iOS開(kāi)發(fā)中對(duì)各種各樣的證書(shū)并不陌生，有開(kāi)發(fā)者證書(shū)、發(fā)布證書(shū)、推送證書(shū)等等...

要了解證書(shū)首先要知道非對(duì)稱加密算法。非對(duì)稱加密算法就是A經(jīng)過(guò)一個(gè)固定的運(yùn)算可以得到B，并且通過(guò)B可以得到A，利用這個(gè)數(shù)學(xué)公式，我們就可以用A來(lái)對(duì)數(shù)據(jù)加密，用B來(lái)對(duì)數(shù)據(jù)解密。這是基于這樣的一個(gè)數(shù)學(xué)公式而產(chǎn)生的算法。這樣的話就可以公開(kāi)A或者B中的一個(gè)，被公開(kāi)的那個(gè)就是公鑰，保留的要私鑰，這樣的話誰(shuí)都可以用公鑰來(lái)加密，但是能解密的只有私鑰。

證書(shū)就是用來(lái)保存公鑰的，且證明公鑰的有效性。因?yàn)楣€是要發(fā)布出去的，但是公鑰也需要證明其自身是有效的，這樣的話就產(chǎn)生了證書(shū)。證書(shū)原本的意思就是權(quán)威機(jī)構(gòu)發(fā)布的能有效證明的文件，那么這里的證書(shū)也是同樣的道理。是權(quán)威機(jī)構(gòu)發(fā)布的對(duì)公鑰有效性的證明文件。這里的權(quán)威機(jī)構(gòu)是被大家所認(rèn)可的幾家機(jī)構(gòu)，如果是想要提交公鑰來(lái)開(kāi)具證書(shū)是需要收費(fèi)的，所以Apple公司為了安全性還是挺舍得花錢(qián)的。

HTTPS的認(rèn)證過(guò)程

https

最后在iOS開(kāi)發(fā)中如果遇到http問(wèn)題的時(shí)候再進(jìn)行補(bǔ)充。