iOS探索:網絡相關

NO IMAGE

HTTP

超文本傳輸協議

  • 請求報文
    iOS探索:網絡相關

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

然後再看一下請求頭,頭部字段都是以key:value的形式組合在一起的,由多個首部字段名構成首部字段區域

之後是我們的實體主體,一般在GET請求中沒有實體主體,而在POST請求中一般會帶有實體主體

  • 響應報文
iOS探索:網絡相關

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

HTTP的請求方式
  • GET

  • POST

  • HEAD

  • PUT

  • DELETE

  • OPTIONS

GET和POST方式的區別

一般大家都知道的是:

  • GET請求參數是以?分割拼接到URL後面的,POST請求參數實在Body裡面的

  • GET參數長度限制2048個字符,POST一般沒有該限制

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

但是從語義的角度來比較的話,是這樣的:

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

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

對應的解釋

1、安全性:不應該引起Server端的任何狀態變化,比如說我們用GET請求多次去Server端去獲取數據,不會引起Server的一個狀態變化,安全性的請求包括:GET、HEAD、OPTIONS

2、冪等性:同一個請求方法執行多次和執行一次的效果完全相同,比如說我們用GET請求多次去Server端去獲取數據,執行的效果是完全相同的,這裡需要注意的是執行的效果,冪等性的請求包括:GET、PUT、DELETE

3、可緩存性:請求是否可緩存,我們一般在發起一個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(用戶數據報協議)

特點:

1、無連接

2、盡最大努力交付

3、面向報文,既不合並,也不拆分

功能包括:

1、複用

2、分用

3、差錯檢測

TCP(傳輸控制協議)

特點:

1、面向連接

2、可靠傳輸(無差錯,不丟失,不重複,按序到達)

3、面向字節流

4、流量控制

5、擁塞控制

DNS解析

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

iOS探索:網絡相關

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探索:網絡相關

相關文章

iOS封裝原生二維碼掃描和生成

iOS傳感器集錦

iOSCoreData(二)版本升級和數據庫遷移

iOSCoreData(一)增刪改查