1 HTTP協(xié)議
1.1請求報文
1.2 響應(yīng)報文
1.3 http的請求方式有哪些
1.4 HTTP擴(kuò)展方法
1.5 GET和POST的區(qū)別(從語義的角度)
1.6 狀態(tài)碼
1.7 首部
1.8 連接建立過程
1.9 HTTP的特點
2 HTTP與網(wǎng)絡(luò)安全
2.1 HTTPS連接建立流程是怎樣的
2.2 HTTPS都使用了那些加密手段？為什么
3 TCP/UDP傳輸層協(xié)議
3.1 DNS解析
3.1.1 了解DNS解析
3.1.2 DNS解析查詢方式
3.1.3 DNS解析存在哪些常見問題
3.1.3.1 DNS劫持問題
3.1.3.2 DNS解析轉(zhuǎn)發(fā)問題
3.1.3.3 怎么解決DNS劫持
4 Session/Cookie
1 HTTP協(xié)議
HTTP是超文本傳輸協(xié)議
了解報文流的概念：
HTTP報文在客戶端、服務(wù)器、和代理之間的傳遞可以形象的稱為流動。術(shù)語“流入”、“流出”、“上游”、“下游”是在流的基礎(chǔ)上定義的，用來描述報文方向。
“流入”意為報文從客戶端到達(dá)服務(wù)器；“流出”，則和流入相反?？梢钥闯觯@兩個術(shù)語是針對服務(wù)器而言。
“上游”和“下游”，不管是請求報文還是響應(yīng)報文，所有報文都會向“下游”流動。所有報文的發(fā)送者都在接收者的“上游”。
1.1請求報文
1.2 響應(yīng)報文
? HTTP報文結(jié)構(gòu):
實例 ：請求和響應(yīng)報文
各部分的作用如下:
- 起始行和首部是由行分割的ASCII文本，每行由一個回車符(\n)和一個換行符(\r)組成的序列結(jié)束。這個序列可以寫作CRLF。
- method，客戶端希望服務(wù)器執(zhí)行的動作。
- request-url，請求的資源路徑。
- version，HTTP的版本，如HTTP/1.0。不同版本有不同的特性。
- status，3位數(shù)，描述了請求過程中的情況。具體介紹在后面。
- reason-phrase，和status對應(yīng)，是其描述。
- headers，可以沒有或多個。具體介紹在后面。
- entity-body，數(shù)據(jù)塊，主體是可選的，可以為二進(jìn)制或文本。
1.3 HTTP的請求方式有哪些
HTTP規(guī)定了這些方法，具體服務(wù)器是否支持，由服務(wù)器確定。
| HTTP的請求方式 | 描述 | 詳細(xì)描述 |
|---|---|---|
| GET | 告知服務(wù)器，需要從服務(wù)器向客戶端發(fā)送命名資源 | 從服務(wù)器獲取資源，HTTP/1.1要求實現(xiàn)的方法。 |
| HEAD | 僅發(fā)送命名資源響應(yīng)中的HTTP首部 | 和GET方法類似，但是響應(yīng)報文中不會包含主體部分。使用該特性，可以在不真正獲取資源的情況下完成：判斷資源類型 查看對應(yīng)資源是否存在 查看資源是否被修改 HTTP/1.1規(guī)范中要求實現(xiàn)該方法，并且對于同一資源，該方法響應(yīng)首部應(yīng)該和GET方法返回的相同。 |
| PUT | 將客戶端的數(shù)據(jù)存儲的命名的服務(wù)器資源中 | 和GET相反，請求服務(wù)器在指定位置創(chuàng)建文件，內(nèi)容為請求主體的內(nèi)容。若對應(yīng)資源存在，則替換。 |
| POST | 將客戶端數(shù)據(jù)發(fā)送到一個服務(wù)器應(yīng)用程序 | 客戶端向服務(wù)器發(fā)送數(shù)據(jù)。常用來提交表單。 |
| TRACE | 追溯一個請求 | 客戶端發(fā)出請求后，可能經(jīng)過中間的網(wǎng)關(guān)、代理等，原始請求可能被修改，使用TRACE可以查看最終到達(dá)服務(wù)器的請求具體是什么樣子（服務(wù)器在響應(yīng)報文的主體中包含其收到的請求報文）。TRACE通常用于診斷一個請求是否能到達(dá)服務(wù)器，不能帶有主體部分。 |
| OPTIONS | 查看服務(wù)器對資源支持的操作 | 用于查看服務(wù)器對特定資源所支持的方法。在請求報文中若使用*代替URL，則意為查看服務(wù)器對所有資源的通用方法。 |
| DELETE | 從服務(wù)器刪除資源 | 請求服務(wù)器刪除指定資源。當(dāng)然，具體是否刪除，由服務(wù)器決定 |
1.4 HTTP擴(kuò)展方法
HTTP擴(kuò)展方法指的是沒有在HTTP規(guī)范中定義的方法。例如，下面是在WebDAV HTTP擴(kuò)展中的方法：
| 擴(kuò)展方法名 | 描述 |
|---|---|
| LOCK | 告知服務(wù)器，對指定資源鎖定，防止其他人對其更改 |
| MKCOL | 允許用戶創(chuàng)建資源 |
| COPY | 允許用戶 復(fù)制資源 |
| MOVE | 移動服務(wù)器資源 |
1.5 GET和POST的區(qū)別
1.6 狀態(tài)碼
1.7 首部
1.8 連接建立過程
三次揮手(建立連接)
第一次：建立連接時，客戶端發(fā)送SYN包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次：服務(wù)器收到SYN包，向客戶端返回ACK（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進(jìn)入SYN_RCVD狀態(tài)；
第三次：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)，也就是ESTABLISHED狀態(tài)。
三次握手保證了不會建立無效的連接，從而浪費資源。
四次揮手(斷開連接)
第一次： TCP客戶端發(fā)送一個FIN，用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送。
第二次：服務(wù)器收到這個FIN，它發(fā)回一個ACK，確認(rèn)序號為收到的序號加1。和SYN一樣，一個FIN將占用一個序號。
第三次：服務(wù)器關(guān)閉客戶端的連接，發(fā)送一個FIN給客戶端。
第四次：客戶端發(fā)回ACK報文確認(rèn)，并將確認(rèn)序號設(shè)置為收到序號加1。
1.9 HTTP的特點
支持客戶/服務(wù)器模式-
簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。 -
靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type（Content-Type是HTTP包中用來表示內(nèi)容類型的標(biāo)識）加以標(biāo)記。 -
無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。 -
無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。
持久連接：
2 HTTP與網(wǎng)絡(luò)安全
2.1 HTTPS連接建立流程是怎樣的
2.2 HTTPS都使用了那些加密手段？為什么
3 TCP/UDP傳輸層協(xié)議
3.1 DNS解析
4 Session/Cookie
參考文章：
《圖解HTTP》— HTTP報文信息
【讀】這一次,讓我們再深入一點 - HTTP報文
iOS http & https & 網(wǎng)絡(luò)請求過程
詳細(xì)解析 HTTP 與 HTTPS 的區(qū)別
IOS 網(wǎng)絡(luò)請求之 NSURLSession 使用
iOS網(wǎng)絡(luò)層詳解和優(yōu)化
HTTP協(xié)議詳解(一)
HTTP協(xié)議詳解(二)
