iOS探索：網絡相關

HTTP

超文本傳輸協議

• 請求報文

  

咱們來看一下請求報文的格式，首先是請求行，請求行包括方法、URL、協議文本，方法常見的有GET/POST，URL就是咱們的請求地址，協議文本通常是HTTP1.1版本

而後再看一下請求頭，頭部字段都是以key：value的形式組合在一塊兒的，由多個首部字段名構成首部字段區域

以後是咱們的實體主體，通常在GET請求中沒有實體主體，而在POST請求中通常會帶有實體主體

• 響應報文

首先是版本，而後是狀態碼，還有狀態碼的描述，咱們稱之爲短語，而後下面跟請求報文一致，由此組成響應報文

HTTP的請求方式

• GET

• POST

• HEAD

• PUT

• DELETE

• OPTIONS

GET和POST方式的區別

通常你們都知道的是：

• GET請求參數是以？分割拼接到URL後面的，POST請求參數實在Body裏面的

• GET參數長度限制2048個字符，POST通常沒有該限制

• GET請求不太安全，POST請求比較安全

可是從語義的角度來比較的話，是這樣的：

• GET：獲取資源，是安全的、冪等的、可緩存的

• POST：處理資源，是非安全的、非冪等的、不可緩存的

對應的解釋

一、安全性：不該該引發Server端的任何狀態變化，好比說咱們用GET請求屢次去Server端去獲取數據，不會引發Server的一個狀態變化，安全性的請求包括：GET、HEAD、OPTIONS

二、冪等性：同一個請求方法執行屢次和執行一次的效果徹底相同，好比說咱們用GET請求屢次去Server端去獲取數據，執行的效果是徹底相同的，這裏須要注意的是執行的效果，冪等性的請求包括：GET、PUT、DELETE

三、可緩存性：請求是否可緩存，咱們通常在發起一個HTTP請求的過程當中，傳遞的鏈路咱們是不肯定的，雖說實在一條TCP鏈接上，可是網絡路徑在接觸或者經過網關包括一些代理到達咱們的Server端，在這上面會涉及到方方面面的內容，每每對於一些代理服務器會有緩存，而這種緩存性是官方的一種規範，便可以遵照也能夠不遵照，大多數狀況會遵照，因此在GET請求會有相對應的緩存，可緩存性的請求包括：GET、HEAD

狀態碼

1XX：通知

2XX：成功

3XX：重定向

4XX：客戶端錯誤

5XX：服務端錯誤

鏈接創建流程

三次握手

• 首先是客戶端發送一個SYN的請求報文給服務端，請求創建鏈接

• 當服務端收到報文後，服務端會返回給客戶端一個同步ACK的報文

• 當客戶端收到報文後，會返回給服務端一個ACK報文，完成三次握手

四次揮手

• 若是是客戶端發起主動斷開，客戶端會發送一個FIN終止報文給服務端

• 服務端會返回給客戶端一個ACK確認報文，這時客戶端與服務端的鏈接就斷開了，可是服務端到客戶端這個方向，可能還會傳遞數據，在一個合適時機，服務端會向客戶端請求斷開鏈接

• 服務端想要斷開鏈接的時候，會向客戶端發送FIN終止報文

• 而後客戶端會回給服務端一個確認報文，此時完成服務端與客戶端的鏈接斷開

HTTP的特色

• 無鏈接，補償方案爲HTTP的持久鏈接

• 無狀態，補償方案爲Cookie/Session

HTTPS與網絡安全

HTTPS = HTTP + SSL/TLS

HTTPS就是在原有HTTP基礎上，在應用層下面，傳輸層上面插入了一個SSL/TLS協議中間層，爲咱們實現一個安全的網絡機制，也就是說HTTPS是安全的HTTP

HTTPS鏈接創建流程

• 首先由客戶端向服務端發送一個報文，這個報文包括三部分，一個是客戶端支持的TLS版本，客戶端支持的加密算法，以及一個隨機數C

• 而後服務端返回一個握手報文消息，包括一個商定的加密算法，隨機數S還有一個服務端的證書

• 客戶端收到這條報文後，首先會驗證證書，以後會組裝會話祕鑰，這個祕鑰主要經過前面的隨機數C和隨機數S以及一個預主祕鑰進行會話祕鑰的組裝

• 而後客戶端會經過服務端的公鑰對預主祕鑰進行加密傳輸，以後服務端經過私鑰解密獲得預主祕鑰，最後服務端會經過前面的隨機數C、隨機數S以及解密獲得的預主祕鑰組裝會話祕鑰

• 以後再由客戶端向服務端發送一個加密的握手消息，服務端發送一個加密的握手消息，來驗證是否加密完成

TCP/UDP

傳輸層協議

TCP：傳輸控制協議

UDP：用戶數據報協議

UDP（用戶數據報協議）

特色：

一、無鏈接

二、盡最大努力交付

三、面向報文，既不合並，也不拆分

功能包括：

一、複用

二、分用

三、差錯檢測

TCP（傳輸控制協議）

特色：

一、面向鏈接

二、可靠傳輸（無差錯，不丟失，不重複，按序到達）

三、面向字節流

四、流量控制

五、擁塞控制

DNS解析

域名到IP地址的映射，DNS解析請求是採用UDP數據報，且明文

DNS解析查詢方式

• 遞歸查詢 （一層一層的查詢）

• 迭代查詢 （返回結果找對應查詢）

DNS劫持問題

當客戶端發送域名去DNS服務器去查詢時，因爲是UDP數據包而且明文，就會被竊聽，這時若是有一個釣魚服務器劫持了此次查詢，返回給你一個錯誤的IP，這時你就會訪問到一個錯誤的網頁

這裏還須要注意一個點：就是DNS劫持和HTTP是徹底沒有關係的，由於DNS解析是發生在HTTP創建鏈接以前，而且DNS解析請求使用的事UDP數據報，端口號53

那麼如何解決DNS劫持問題呢？

• httpDNS：DNS解析請求使用的事UDP數據報，端口號53，解決方案是使用HTTP協議向DNS服務器的80端口進行請求，不會產生正常的DNS解析，也就不會出現DNS的劫持問題

• 長鏈接：在客戶端和服務端之間創建一個長連服務，也就是一個代理服務器，在客戶端和代理服務器以前創建長連通道，而後再代理服務器和服務端之間經過內網專線進行內網DNS解析，而後進行請求

DNS解析轉發問題

簡單一句話，就是咱們客戶端發送請求時，咱們的DNS服務器可能爲了節省資源等緣由，會轉發給其餘的DNS服務器，會出現跨網訪問，可能會慢一點

Session/Cookie

HTTP協議無狀態特色的補償

Cookie

主要是用來記錄用戶狀態，區分用戶；狀態保存在客戶端，客戶端發送的Cookie在http請求報文的Cookie首部字段中，服務端設置http響應報文的Set-Cookie首部字段

修改Cookie

• 新Cookie覆蓋舊Cookie

• 覆蓋規則：name、path、domain等須要與原Cookie保持一致

刪除Cookie

• 新Cookie覆蓋舊Cookie

• 覆蓋規則：name、path、domain等須要與原Cookie保持一致

• 設置Cookie的expires = 過去的一個時間點，或者maxAge = 0

怎樣保證Cookie的安全性

• 對Cookie進行加密處理

• 只在https上攜帶Cookie

• 設置Cookie爲httpOnly，防止跨站腳本攻擊

Session

也是用來記錄用戶狀態，區分用戶；狀態保存在服務端 Session須要依賴於Cookie機制

至此iOS基礎相關的內容暫時告一段落，寫的可能並非特別詳細，也會有不少的瑕疵，也多謝各位對文章問題的指出，接下來會寫一些數據結構與算法相關的內容，屆時但願你們能夠共同探討，共同進步

iOS探索系列

iOS探索：UI視圖之事件傳遞&視圖響應

iOS探索：UI視圖之卡頓、掉幀及繪製原理

iOS探索：Runtime之基本數據結構

iOS探索：Runtime之消息轉發及動態添加方法

iOS探索：Block解析淺談

iOS探索：RunLoop本質、數據結構以及常駐線程實現

iOS探索：網絡相關