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：處理資源，是非安全的、非冪等的、不可快取的
對應的解釋
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資料包，且明文
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基礎相關的內容暫時告一段落，寫的可能並不是特別詳細，也會有很多的瑕疵，也多謝各位對文章問題的指出，接下來會寫一些資料結構與演算法相關的內容，屆時希望大家可以共同探討，共同進步