一吧兔、什么是HTTP協(xié)議 ?

HTTP本質(zhì)上是一種協(xié)議彻消，全稱是Hypertext Transfer Protocol久免，即超文本傳輸協(xié)議邪码。HTTP是一個(gè)基于TCP/IP通信協(xié)議來(lái)傳遞數(shù)據(jù), 從名字上可以看出該協(xié)議用于規(guī)定客戶端與服務(wù)端之間的傳輸規(guī)則是复，所傳輸?shù)膬?nèi)容不局限于文本(其實(shí)可以傳輸任意類型的數(shù)據(jù))删顶。

image.png

二、HTTP請(qǐng)求/響應(yīng)報(bào)文

當(dāng)我們往服務(wù)端發(fā)送一條HTTP請(qǐng)求時(shí)都發(fā)送了哪些東西過去呢淑廊？先看一個(gè)POST請(qǐng)求的示例圖：

image.png

以上示例圖中其實(shí)已經(jīng)包含了一個(gè)HTTP請(qǐng)求所必備的幾大要素：
請(qǐng)求行逗余、請(qǐng)求頭(headerField)、請(qǐng)求體(body)季惩；同理录粱，響應(yīng)也有狀態(tài)行腻格、響應(yīng)頭、實(shí)體內(nèi)容啥繁。

下圖給出了請(qǐng)求報(bào)文的一般格式菜职。

image.png

2.1 請(qǐng)求行

請(qǐng)求行包含請(qǐng)求方法(Method)、請(qǐng)求統(tǒng)一資源標(biāo)識(shí)符(URI)旗闽、HTTP版本號(hào)

image.png

• 請(qǐng)求方法就是我們所熟悉的POST酬核、GET、HEAD适室、PUT等
• URI就是URL中排除掉Host剩下的部分嫡意，也就是資源在服務(wù)器本地上的路徑
• HTTP版本號(hào)，目前主流的版本是1.1(1999年開始采用)捣辆，最新的版本是2.0(2015年5月發(fā)布)蔬螟。

2.2 請(qǐng)求頭

請(qǐng)求頭主要存放對(duì)客戶端想給服務(wù)端的附加信息下, 如下圖所示

image.png

HTTP請(qǐng)求在iOS中用NSURLRequest與NSMutableRequest表示；HTTP響應(yīng)用NSHTTPURLResponse表示罪帖。

• Host: 目標(biāo)服務(wù)器的網(wǎng)絡(luò)地址
• Accept: 讓服務(wù)端知道客戶端所能接收的數(shù)據(jù)類型促煮，如text/html /
• Content-Type: body中的數(shù)據(jù)類型，如application/json; charset=UTF-8
• Accept-Language: 客戶端的語(yǔ)言環(huán)境整袁，如zh-cn
• Accept-Encoding: 客戶端支持的數(shù)據(jù)壓縮格式菠齿，如gzip
• User-Agent: 客戶端的軟件環(huán)境，我們可以更改該字段為自己客戶端的名字坐昙，比如QQ music v1.11绳匀，比如瀏覽器Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Maxthon/4.5.2
• Connection: keep-alive，該字段是從HTTP 1.1才開始有的炸客，用來(lái)告訴服務(wù)端這是一個(gè)持久連接疾棵，“請(qǐng)服務(wù)端不要在發(fā)出響應(yīng)后立即斷開TCP連接”。關(guān)于該字段的更多解釋將在后面的HTTP版本簡(jiǎn)介中展開痹仙。
• Content-Length: body的長(zhǎng)度是尔，如果body為空則該字段值為0。該字段一般在POST請(qǐng)求中才會(huì)有开仰。
• Cookie: 記錄者用戶信息的保存在本地的用戶數(shù)據(jù)拟枚，如果有會(huì)被自動(dòng)附上

值得一提的是，在iOS中當(dāng)你發(fā)送一個(gè)任意請(qǐng)求時(shí)众弓，不管你愿不愿意恩溅，NSURLRequest都會(huì)自動(dòng)幫你記錄你所訪問的URL上設(shè)置的cookie。在iOS中用NSHTTPCookieStorage表示谓娃，是一個(gè)單例脚乡。通過
NSHTTPCookieStorage *cookieJar = [NSHTTPCookieStorage  sharedHTTPCookieStorage];
    for (NSHTTPCookie *cookie in [cookieJar cookies]) {
     NSLog(@"%@", cookie);
    }

以上就是我們?nèi)粘ｉ_發(fā)中比較經(jīng)常遇到的請(qǐng)求頭，其實(shí)還有其他的field滨达。那在iOS中如何設(shè)置添加這些field呢奶稠？可以使用-[NSMutableURLRequest addValue: forHTTPHeaderField:]方法俯艰，獲取當(dāng)前請(qǐng)求已經(jīng)設(shè)置的field可以用-[NSURLRequest allHTTPHeaderFields]。也就是我們可以通過以上接口定制我們所需要的請(qǐng)求頭窒典，但是有些field是不能改的

2.3蟆炊、請(qǐng)求體

真正需要發(fā)給服務(wù)端的數(shù)據(jù)稽莉，在使用POST-multipart上傳請(qǐng)求中請(qǐng)求體就是上傳文件的二進(jìn)制NSData類型數(shù)據(jù)瀑志；在GET請(qǐng)求中請(qǐng)求體為空；在普通的POST請(qǐng)求中請(qǐng)求體就是一些表單數(shù)據(jù)污秆。在iOS中一般用NSURLRequest與NSMutableURLRequest的HTTPBody屬性表示劈猪，添加body用-[NSMutableURLRequest setHTTPBody:]。

2.4良拼、響應(yīng)行

狀態(tài)行是服務(wù)端返回給客戶端的狀態(tài)信息战得，包含HTTP版本號(hào)、狀態(tài)碼庸推、狀態(tài)碼對(duì)應(yīng)的英文名稱常侦。
以下就是典型的正確狀態(tài)行：
HTTP/1.1 200 OK
這個(gè)部分需要講的是錯(cuò)誤碼。事實(shí)上HTTP請(qǐng)求錯(cuò)誤碼可以根據(jù)錯(cuò)誤碼從左往右第一個(gè)數(shù)字大致分為以下幾類：

1XX：信息提示贬媒。不代表成功或者失敗聋亡，表示臨時(shí)響應(yīng)，比如100表示繼續(xù)际乘，101表示切換協(xié)議
2XX: 成功
3XX: 重定向
4XX:客戶端錯(cuò)誤坡倔，很有可能是客戶端發(fā)生問題，如親切可愛的404表示未找到文件脖含，說明你的URI是有問題的罪塔，服務(wù)器機(jī)子上該目錄是沒有該文件的；414URI太長(zhǎng)
5XX: 服務(wù)器錯(cuò)誤养葵，比如504網(wǎng)關(guān)超時(shí)

HTTP狀態(tài)碼詳細(xì)列表: http://www.runoob.com/http/http-status-codes.html

2.5征堪、響應(yīng)頭與響應(yīng)實(shí)體

這部分與請(qǐng)求部分差異不大，響應(yīng)頭的字field會(huì)有稍許不同关拒，響應(yīng)頭中的header field同樣移步請(qǐng)求頭響應(yīng)頭列表佃蚜。

三、HTTP版本簡(jiǎn)介

這里我把HTTP版本簡(jiǎn)單分為三類：1.1之前夏醉，1.1爽锥，2.0，針對(duì)這三類做個(gè)主要差異的介紹：

• HTTP 1.1之前
  • 不支持持久連接畔柔。一旦服務(wù)器對(duì)客戶端發(fā)出響應(yīng)就立即斷開TCP連接
  • 無(wú)請(qǐng)求頭跟響應(yīng)頭
  • 客戶端的前后請(qǐng)求是同步的氯夷。下一個(gè)請(qǐng)求必須等上一個(gè)請(qǐng)求從服務(wù)端拿到響應(yīng)后才能發(fā)出，有點(diǎn)類似多線程的同步機(jī)制靶擦。

• HTTP 1.1(主流版本)
  • 與1.1之前的版本相比腮考，做了以下性能上的提升
  • 增加請(qǐng)求頭跟響應(yīng)頭
  • 支持持久連接雇毫。客戶端通過請(qǐng)求頭中指定Connection為keep-alive告知服務(wù)端不要在完成響應(yīng)后立即釋放連接踩蔚。HTTP是基于TCP的棚放，在HTTP 1.1中一次TCP連接可以處理多次HTTP請(qǐng)求
  • 客戶端不同請(qǐng)求之間是異步的腾么。下一個(gè)請(qǐng)求不必等到上一個(gè)請(qǐng)求回來(lái)后再發(fā)出梅垄，而可以連續(xù)發(fā)出請(qǐng)求，有點(diǎn)類似多線程的異步處理艳吠。

• HTTP 2.0
  • 本著向下兼容的原則福也，1.1版本有的特性2.0都具備局骤，也使用相同的API。但是2.0將只用于https網(wǎng)址暴凑。由于2.0的普及還需要比較長(zhǎng)的一段時(shí)間峦甩，這里不展開

我們重點(diǎn)關(guān)注一下當(dāng)前1.1版本所做幾點(diǎn)改變。支持持久連接有什么好處呢现喳？

HTTP是基于TCP連接的凯傲，如果連接被頻繁地啟動(dòng)然后斷開就會(huì)花費(fèi)很多資源在TCP三次握手以及四次揮手上，效率低下嗦篱。以請(qǐng)求一個(gè)網(wǎng)頁(yè)為例冰单，我們知道，一個(gè)html網(wǎng)頁(yè)上的圖片資源并不是直接嵌入在網(wǎng)頁(yè)上默色，而只是提供url球凰，圖片仍需要額外發(fā)HTTP 請(qǐng)求去下載。一個(gè)網(wǎng)頁(yè)從請(qǐng)求到最終加載到本地往往需要經(jīng)過過個(gè)HTTP請(qǐng)求腿宰。在1.1版本之前請(qǐng)求一個(gè)網(wǎng)頁(yè)就需要發(fā)生多次"握手-揮手"的過程呕诉，每次連接之間相互獨(dú)立；而1.1及之后的版本最少只需要一次就夠吃度。

再來(lái)就是請(qǐng)求異步甩挫，其好處參考多線程異步處理，在此不展開椿每。

以上特性可以用圖2.3表示：

image.png

我們可以看到：1伊者、N次請(qǐng)求其實(shí)只建立了1次TCP連接，2间护、N次請(qǐng)求連續(xù)異步發(fā)出亦渗。

四 、HTTP協(xié)議特點(diǎn)

HTTP 是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議汁尺，HTTP 協(xié)議一共有五大特點(diǎn)：1法精、支持客戶/服務(wù)器模式；2、簡(jiǎn)單快速搂蜓；3狼荞、靈活；4帮碰、無(wú)連接相味；5、無(wú)狀態(tài)殉挽。

1. 支持客戶/服務(wù)器模式丰涉。
2. 簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑此再。請(qǐng)求方法常用的有GET昔搂、HEAD、POST输拇。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡(jiǎn)單贤斜，使得HTTP服務(wù)器的程序規(guī)模小策吠，因而通信速度很快。
3. 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象瘩绒。正在傳輸?shù)念愋陀蒀ontent-Type（Content-Type是HTTP包中用來(lái)表示內(nèi)容類型的標(biāo)識(shí)）加以標(biāo)記猴抹。
4. 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求锁荔，并收到客戶的應(yīng)答后蟀给，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間阳堕。
5. 無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議跋理。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息恬总，則它必須重傳前普，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面壹堰，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快拭卿。

五、HTTP建立過程

• 首先需要進(jìn)行 Tcp 的三次握手
• HTTP 的請(qǐng)求/響應(yīng)過程
• Tcp 四次揮手連接釋放

如下圖所示:

image.png

五贱纠、HTTP峻厚、Socket、TCP的區(qū)別

這三個(gè)概念經(jīng)常被談到谆焊，也是比較容易被混掉的概念惠桃。在回顧之前我們先看一下這三者在TCP/IP協(xié)議族中的位置關(guān)系：

image.png

HTTP是應(yīng)用層的協(xié)議，更靠近用戶端；TCP是傳輸層的協(xié)議刽射；而socket是從傳輸層上抽象出來(lái)的一個(gè)抽象層军拟，本質(zhì)是接口。所以本質(zhì)上三種還是很好區(qū)分的誓禁。盡管如此懈息，有時(shí)候你可能會(huì)懵逼，HTTP連接摹恰、TCP連接辫继、socket連接有什么區(qū)別？好吧俗慈，如果上面的圖解釋的還是不夠清楚的話姑宽，我們繼續(xù)往下看。

4.1 TCP連接與HTTP連接的區(qū)別

上文提過闺阱，HTTP是基于TCP的炮车，客戶端往服務(wù)端發(fā)送一個(gè)HTTP請(qǐng)求時(shí)第一步就是要建立與服務(wù)端的TCP連接，也就是先三次握手酣溃，“你好瘦穆，你好，你好”赊豌。從HTTP 1.1開始支持持久連接扛或，也就是一次TCP連接可以發(fā)送多次的HTTP請(qǐng)求。
小總結(jié)：HTTP基于TCP

4.2碘饼、TCP連接與Socket連接的區(qū)別

在圖4.1中我們提到熙兔，socket層只是在TCP/UDP傳輸層上做的一個(gè)抽象接口層，因此一個(gè)socket連接可以基于TCP艾恼，也有可能基于UDP住涉。基于TCP協(xié)議的socket連接同樣需要通過三次握手建立連接蒂萎，是可靠的秆吵；基于UDP協(xié)議的socket連接不需要建立連接的過程，不過對(duì)方能不能收到都會(huì)發(fā)送過去五慈，是不可靠的纳寂，大多數(shù)的即時(shí)通訊IM都是后者。
小總結(jié)：Socket也可以基于TCP

4.3泻拦、HTTP連接與Socket連接的區(qū)別

區(qū)分這兩個(gè)概念是比較有意義的毙芜，畢竟TCP看不見摸不著，HTTP與Socket是實(shí)實(shí)在在能用到的争拐。

• HTTP是短連接腋粥，Socket(基于TCP協(xié)議的)是長(zhǎng)連接晦雨。盡管HTTP1.1開始支持持久連接，但仍無(wú)法保證始終連接隘冲。而Socket連接一旦建立TCP三次握手闹瞧，除非一方主動(dòng)斷開，否則連接狀態(tài)一直保持展辞。
• HTTP連接服務(wù)端無(wú)法主動(dòng)發(fā)消息奥邮，Socket連接雙方請(qǐng)求的發(fā)送先后限制。這點(diǎn)就比較重要了罗珍，因?yàn)樗鼘Q定二者分別適合應(yīng)用在什么場(chǎng)景下洽腺。HTTP采用“請(qǐng)求-響應(yīng)”機(jī)制，在客戶端還沒發(fā)送消息給服務(wù)端前覆旱，服務(wù)端無(wú)法推送消息給客戶端蘸朋。必須滿足客戶端發(fā)送消息在前，服務(wù)端回復(fù)在后扣唱。Socket連接雙方類似peer2peer的關(guān)系藕坯，一方隨時(shí)可以向另一方喊話。

4.4画舌、問題來(lái)了：什么時(shí)候該用HTTP堕担，什么時(shí)候該用socket

這個(gè)問題的提出是很自然而然的。當(dāng)你接到一個(gè)與另一方的網(wǎng)絡(luò)通訊需求曲聂，自然會(huì)考慮用HTTP還是用Socket。

• 用HTTP的情況：雙方不需要時(shí)刻保持連接在線佑惠，比如客戶端資源的獲取朋腋、文件上傳等
• 用Socket的情況：大部分即時(shí)通訊應(yīng)用(QQ、微信)膜楷、聊天室旭咽、蘋果APNs等

在iOS中，發(fā)HTTP請(qǐng)求一般用原生的NSURLConnection赌厅、NSURLSession或者開源的AFNetWorking(推薦)穷绵、ASIHttpRequest(已停止更新)。連接Socket連接我用的比較多是robbiehanson大神的[CocoaAsyncSocket] (XMPPFramework也是出自他手)特愿。

六. TCP/UDP

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協(xié)議屬于傳輸層協(xié)議仲墨。其中TCP提供IP環(huán)境下的數(shù)據(jù)可靠傳輸，它提供的服務(wù)包括數(shù)據(jù)流傳送揍障、可靠性目养、有效流控、全雙工操作和多路復(fù)用毒嫡。通過面向連接癌蚁、端到端和可靠的數(shù)據(jù)包發(fā)送。而UDP則不為IP提供可靠性、流控或差錯(cuò)恢復(fù)功能努释。一般來(lái)說碘梢，TCP對(duì)應(yīng)的是可靠性要求高的應(yīng)用，而UDP對(duì)應(yīng)的則是可靠性要求低伐蒂、傳輸經(jīng)濟(jì)的應(yīng)用煞躬。

6.1 TCP

TCP(傳輸控制協(xié)議)是基于連接的協(xié)議，是面向連接的, 也就是說饿自，在正式收發(fā)數(shù)據(jù)前汰翠，必須和對(duì)方建立可靠的連接。一個(gè)TCP連接必須要經(jīng)過三次“對(duì)話”才能建立起來(lái)經(jīng)過三次“對(duì)話”之后昭雌，主機(jī)A才向主機(jī)B正式發(fā)送數(shù)據(jù)复唤。

TCP協(xié)議能為應(yīng)用程序提供可靠的通信連接，使一臺(tái)計(jì)算機(jī)發(fā)出的字節(jié)流無(wú)差錯(cuò)地發(fā)往網(wǎng)絡(luò)上的其他計(jì)算機(jī)烛卧，對(duì)可靠性要求高的數(shù)據(jù)通信系統(tǒng)]往往使用TCP協(xié)議傳輸數(shù)據(jù)佛纫。

6.2 UDP

UDP(用戶數(shù)據(jù)報(bào)協(xié)議)是與TCP相對(duì)應(yīng)的協(xié)議。它是面向非連接的協(xié)議总放，它不與對(duì)方建立連接呈宇，而是直接就把數(shù)據(jù)包發(fā)送過去！UDP適用于一次只傳送少量數(shù)據(jù)局雄、對(duì)可靠性要求不高的應(yīng)用環(huán)境可以使用UDP

6.3 TCP/ UDP區(qū)別

1. TCP面向連接（三次握手）;UDP是無(wú)連接的甥啄，即發(fā)送數(shù)據(jù)之前不需要建立連接
2. TCP提供可靠的服務(wù)。也就是說炬搭，通過TCP連接傳送的數(shù)據(jù)蜈漓，無(wú)差錯(cuò)，不丟失宫盔，不重復(fù)融虽，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付, Tcp通過校驗(yàn)和灼芭，重傳控制有额，序號(hào)標(biāo)識(shí)，滑動(dòng)窗口彼绷、確認(rèn)應(yīng)答實(shí)現(xiàn)可靠傳輸巍佑。如丟包時(shí)的重發(fā)控制，還可以對(duì)次序亂掉的分包進(jìn)行順序控制苛预。
3. UDP具有較好的實(shí)時(shí)性句狼，工作效率比TCP高，適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信热某。
4. 每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一腻菇，一對(duì)多胳螟，多對(duì)一和多對(duì)多的交互通信
5. TCP對(duì)系統(tǒng)資源要求較多，UDP對(duì)系統(tǒng)資源要求較少筹吐。

七. DNS

域名系統(tǒng)(DomainNameSystem糖耸，縮寫：DNS）是[互聯(lián)網(wǎng)]的一項(xiàng)服務(wù)。它作為將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)丘薛，能夠使人更方便地訪問[互聯(lián)網(wǎng)], 工作原理如下圖:

image.png

DNS解析查詢方式

• （1）遞歸查詢

  遞歸查詢是一種DNS 服務(wù)器的查詢模式嘉竟，在該模式下DNS 服務(wù)器接收到客戶機(jī)請(qǐng)求，必須使用一個(gè)準(zhǔn)確的查詢結(jié)果回復(fù)客戶機(jī)洋侨。如果DNS 服務(wù)器本地沒有存儲(chǔ)查詢DNS 信息舍扰，那么本地服務(wù)器就會(huì)成為DNS中的一臺(tái)客戶機(jī)，并向上級(jí)域名服務(wù)器發(fā)出查詢請(qǐng)求希坚，這種過程將持續(xù)到找到具有相關(guān)信息的域名服務(wù)器為止边苹，然后將返回的查詢結(jié)果提交給客戶機(jī)。

  過程中如果沒有找到查詢結(jié)果裁僧，重復(fù)遞歸上述操作直至根域名服務(wù)器个束，根域名服務(wù)器收到DNS請(qǐng)求后，把所查詢得到的所請(qǐng)求的DNS域名中發(fā)送給頂級(jí)域名服務(wù)器聊疲，讓頂級(jí)域名服務(wù)器去往下級(jí)域名服務(wù)器請(qǐng)求查找茬底，如果找到了就原路返回。某域名服務(wù)器-->...->頂級(jí)域名服務(wù)器-->根域名服務(wù)器-->下一級(jí)域名服務(wù)器-->...-->本地域名服務(wù)器-->客戶機(jī)获洲。如果沒有找到就報(bào)錯(cuò)阱表，表示無(wú)法查詢到相關(guān)信息;

  
  
  image.png

• （2）迭代查詢
  DNS 服務(wù)器另外一種查詢方式為迭代查詢，DNS 服務(wù)器會(huì)向客戶機(jī)提供其他能夠解析查詢請(qǐng)求的DNS 服務(wù)器地址贡珊，當(dāng)客戶機(jī)發(fā)送查詢請(qǐng)求時(shí)捶枢，DNS 服務(wù)器并不直接回復(fù)查詢結(jié)果，而是告訴客戶機(jī)另一臺(tái)DNS 服務(wù)器地址飞崖，客戶機(jī)再向這臺(tái)DNS 服務(wù)器提交請(qǐng)求，依次循環(huán)直到返回查詢的結(jié)果為止谨胞。

  
  
  image.png

DNS劫持問題

DNS劫持又稱(域名劫持), 是指在劫持的網(wǎng)絡(luò)范圍內(nèi)攔截域名解析的請(qǐng)求固歪，分析請(qǐng)求的域名，把審查范圍以外的請(qǐng)求放行胯努，否則返回假的IP地址或者什么都不做使請(qǐng)求失去響應(yīng)牢裳，其效果就是對(duì)特定的網(wǎng)絡(luò)不能訪問或訪問的是假網(wǎng)址。

image.png

DNS劫持問題解決方案:

• HTTPDNS
  HTTPDNS 利用 HTTP 協(xié)議與 DNS 服務(wù)器交互叶沛，代替了傳統(tǒng)的基于 UDP 協(xié)議的 DNS 交互蒲讯，繞開了運(yùn)營(yíng)商的 Local DNS，有效防止了域名劫持灰署，提高域名解析效率判帮。

  
  
  image.png

參考鏈接:

http://www.runoob.com/http/http-tutorial.html
https://www.cnblogs.com/xuxinstyle/p/9813654.html
https://blog.csdn.net/qq_34115899/article/details/82981007