[TOC]
@(iOS總結)
一切從簡,用自己的方式記錄。如果你覺得囉嗦,那可能是我怕說的不明白;如果你覺得太籠統,那可能是我覺得太基礎沒寫出來,或者我還沒認知到;如果你覺得和別的文章太重複,那可能是我沒有找到更好的表達方式;
系統學習最好看一下 UNIX網路程式設計卷1:套接字聯網API(第3版).pdf
一、TCP(詳情參考:必須懂的計算機網路知識—(TCP))
1.1、網路模型資料處理過程
1.2、TCP和UDP的區別
TCP
位於傳輸層,傳輸層協議還包括UDP
、HTTP
(超文字傳輸協議)、FTP
(檔案傳輸協議)、SNMP
(簡單網路管理協議)、Telnet
(遠端登入協議)等。下面的表格列出了TCP
和UDP
的區別。
傳輸層協議 | TCP(Transmission Control Protocol傳輸控制協議) | UDP(User Datagram Protocol使用者資料包協議) |
---|---|---|
連線方式 | 面向連線(一對一) | 無連線(一對一、一對多、多對一、多對多) |
佔用系統資源 | 多(首部開銷20位元組) | 少(首部開銷8位元組) |
可靠性 | 可靠,保證資料正確(全雙工) | 不可靠,可能會丟包 |
資料順序 | 保證資料順序 | 不保證資料順序 |
擁塞控制 | 有擁塞控制,面向資料流 | 無擁塞控制,面向報文 |
流量控制 | 有(滑動視窗) | 無 |
注意: “
ping
”命令是使用 IP 和網路控制資訊協議 (ICMP
),因而沒有涉及到任何傳輸協議(UDP/TCP
) 和應用程式
TCP
因為是面向連線的,所以比UDP
要更復雜,建立連線需要三次握手
,斷開連線需要四次揮手
。TCP充分實現了資料傳輸時各種控制功能,可以進行丟包的重發控制
,還可以對次序亂掉的分包進行順序控制
。而這些在UDP中都沒有。此外,TCP作為一種面向有連線的協議,只有在確認通訊對端存在時才會傳送資料,從而可以控制通訊流量的浪費。TCP通過檢驗和
、序列號
、確認應答
、重發控制
、連線管理
以及視窗控制
等機制實現可靠性傳輸
。
1.3、建立連線為什麼要三次握手?
假如讓我和你來實現一次完整可靠的連線,會怎麼做呢?
- 第一次握手,
我
告訴你
我要和你建立連線 - 第二次握手,
你
告訴我
你能收到我傳送的訊息 - 第三次握手,
我
告訴你
我能收到你傳送的訊息 然後,你能收到我傳送的,我能收到你傳送的,我們倆下面就可以暢聊了
1.4、斷開連線為什麼要四次揮手?
- 第一次握手:
我
告訴你
,我要和你斷開連線 - 第二次握手:
你
告訴我
,你收到我傳送的斷開連線訊息了,但是可能還有資料沒有傳送完畢,等一會再告訴我 - 第三次握手:
你
告訴我
,你沒有正在傳送的資料了,你可以和我斷開連線了 - 第四次揮手:
我
告訴你
,我收到你傳送的可以和我斷開連線的訊息了 然後,本次會話完美結束了,沒有漏掉任何訊息
1.5、TCP流量控制
所謂的流量控制
就是接收方讓傳送方的傳送速率
不要太快,讓接收方來得及接收。利用滑動視窗機制
可以很方便的在TCP連線上實現對傳送方的流量控制。TCP視窗的單位是位元組,不是報文段,傳送方的傳送視窗
不能大於接收方給出的接收視窗
(rwnd)的大小。
1.6、TCP擁塞控制
為了方式網路的擁塞現象,TCP提出了一系列的擁塞控制機制
。擁塞控制的原理主要依賴於一個擁塞視窗(cwnd)
,傳送方控制擁塞視窗的原則是:只要網路沒有出現擁塞,擁塞視窗就增大一寫,以便把更多的分組傳送出去。但是隻要出現網路擁塞,擁塞視窗就減少一些,以便減少注入到網路中的分組。主要有四種演算法:慢啟動(Slow-start)
、擁塞避免(Congestion Avoidance)
、快重傳(Fast Restrangsmit)
、快恢復(Fast Recovery)。
擁塞控制和流量控制的區別
區別 | 擁塞控制 | 流量控制 |
---|---|---|
作用範圍 | 全域性性的(設計所有主機、路由器、以及與降低網路傳輸效能有關的所有因素) | 點對點的通訊量控制,是個端到端的問題 |
控制方 | 傳送方控制 | 接收方控制 |
控制結果 | 控制傳送方注入到網路中的資料量 | 控制傳送端的傳送資料速率,以便接收端來得及接收 |
二、HTTP、HTTPS
2.1、HTTP(詳情參考:HTTP 教程| 菜鳥教程 、關於HTTP協議,一篇就夠了)
HTTP協議是Hyper Text Transfer Protocol(超文字傳輸協議)的縮寫,是用於從全球資訊網(WWW:World Wide Web )伺服器傳輸超文字到本地瀏覽器的傳送協議。規範把 HTTP 請求分為三個部分:狀態行
、請求頭
、訊息主體
。
2.1.1、HTTP基礎知識:URL
統一資源定位符(Uniform Resource Locator)是網路資源的位置和訪問方法的簡潔表示。常見的url包括4個部分,結構如下圖:
元件 | 含義 |
---|---|
方案 | 使用的協議,如http或https |
主機 | 伺服器的域名或IP地址 |
路徑 | 伺服器上資源的本地名,用(/)與前面的scheme分隔開來 |
查詢字串 | 通過查詢字串來減小請求資源型別的範圍,如引數 |
2.1.2、HTTP之狀態碼
狀態程式碼有三位數字組成,第一個數字定義了響應的類別,共分五種類別: 1xx:指示資訊--表示請求已接收,繼續處理 2xx:成功--表示請求已被成功接收、理解、接受 3xx:重定向--要完成請求必須進行更進一步的操作 4xx:客戶端錯誤--請求有語法錯誤或請求無法實現 5xx:伺服器端錯誤--伺服器未能實現合法的請求
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤,不能被伺服器所理解
401 Unauthorized //請求未經授權,這個狀態程式碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden //伺服器收到請求,但是拒絕提供服務
404 Not Found //請求資源不存在,eg:輸入了錯誤的URL
500 Internal Server Error //伺服器發生不可預期的錯誤
503 Server Unavailable //伺服器當前不能處理客戶端的請求,一段時間後可能恢復正常
複製程式碼
2.1.3、HTTP請求方法
根據HTTP標準,HTTP請求可以使用多種請求方法。 HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法。 HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
GET 請求指定的頁面資訊,並返回實體主體。
HEAD 類似於get請求,只不過返回的響應中沒有具體的內容,用於獲取報頭
POST 向指定資源提交資料進行處理請求(例如提交表單或者上傳檔案)。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT 從客戶端向伺服器傳送的資料取代指定的文件的內容。
DELETE 請求伺服器刪除指定的頁面。
CONNECT HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
OPTIONS 允許客戶端檢視伺服器的效能。
TRACE 回顯伺服器收到的請求,主要用於測試或診斷。
複製程式碼
2.1.4、HTTP與TCP的區別?
TCP
協議對應於傳輸層,HTTP
協議對應於應用層,從本質上來說二者沒有可比性。 很多人喜歡把IP
比作告訴公路,TCP
是告訴公路上的卡車,他們攜帶的貨物就是HTTP
協議。 我覺得這是很不嚴謹的,如果非要舉個形象的例子,我覺得可以把IP
比作電話號碼
,TCP
就像電話
,傳輸去的聲音
就像資料包
,如果是開會就會遵循電話會議規則(比如HTTP
),如果是銷售就會遵循推銷規則(比如FTP
),如果是閒聊就按照雙方想要的規則(自定義資料傳輸協議
)。TCP
傳輸的資料包可以任何格式的,可以自定義規則
,可以遵循HTTP
協議,也可以遵循FTP
協議。
2.1.5、如何解決HTTP的無狀態協議?
使用Cookie來解決無狀態的問題,Cookie就相當於一個通行證,第一次訪問的時候給客戶端傳送一個Cookie,當客戶端再次來的時候,拿著Cookie(通行證),那麼伺服器就知道這個是”老使用者“。
2.2、HTTPS(詳情參考:詳細解析 HTTP 與 HTTPS 的區別)
https, 全稱Hyper Text Transfer Protocol Secure,相比http,多了一個secure。一句話:HTTPS=HTTP+加密+認證+完整性保護
。
理清幾個概念很重要
- 1、CA(數字證書頒發機構)
- 2、非對稱祕鑰:CA的一對非對稱祕鑰、伺服器的一對非對稱祕鑰、客戶端的一對非對稱祕鑰
- 3、對稱祕鑰:客戶端隨機生成的,用於認證完成之後的資料加解密(客戶端通過伺服器返回的數字證書中的公鑰加密對稱祕鑰後,傳送給伺服器)
- 4、數字證書:CA頒發給伺服器的數字證書(證書中的公鑰是伺服器的公鑰,但是簽名使用的是CA的私鑰)、CA根證書(證書中的公鑰是CA自己的公鑰,簽名使用的是CA自己的私鑰<用來保證該證書沒有被中間篡改過>)
- 5、單雙向認證:單向認證,客戶端驗證伺服器;雙向認證,客戶端先驗證伺服器證書,伺服器在驗證客戶端的證書。雙向認證的時候,客戶端需要向伺服器請求頒發給自己數字證書 = 用伺服器的公鑰(另外一對中的)加密摘要得到的簽名+客戶端資訊 + 客戶端公鑰。Https單向認證和雙向認證
瀏覽器
、作業系統
、或者應用
自己內建了信任的根證書
,瀏覽器或者客戶端接收到伺服器返回的的CA頒發的數字證書,從內建信任的根證書中獲取CA的公鑰,然後對伺服器返回的數字證書中的簽名進行解密得到摘要1,然後對伺服器返回的數字證書中的內容進行取摘要運算得到摘要2,最後對比摘要1與摘要2是否相等,繼而判斷服務方是否是被CA認證的服務方。
2.2.1、SSL解決了通訊中哪些問題?
-
1、
認證(Authentication)
:無法確認與我正在通訊的人,就是我真正想通訊的人 -
2、
洩露(privacy)
:與我通訊的內容,被別人偷聽 -
3、
篡改(data integrity)
:我接受到的的內容,並不是對方原始傳送的資料
SSL不解決以下問題: 不可抵賴性(訊息的傳送者沒辦法不承認訊息是自己發出的)。因為SSL並不對傳輸的資料做簽名。但是SSL加上數字簽名證書可以解決該問題。
2.2.2、檢驗雙方的真實性
HTTPS使用了數字證書(身份認證機構蓋在數字身份證上的一個章或印,或者說加在數字身份證上的一個簽名),這一行為表示身份認證機構已認定這個人,證書的合法性可以向CA驗證。客戶端收到伺服器的響應後,先向CA驗證證書的合法性,如果校驗不通過瀏覽器就會終止連線,並提示使用者證書不安全。 數字證書的組成:
- 證書頒發機構
- 證書頒發機構簽名(數字簽名是什麼?)
- 證書繫結的伺服器域名
- 證書版本、有效期
- 簽名使用的演算法(非對稱加密演算法,RSA)
- 公鑰
2.2.3、資料的保密性
就是對資料進行加密,通常使用兩種加密演算法:對稱加密
、非對稱加密
。
對稱加密: 加密和解密使用相同的金鑰,有點是加解密速度快,缺點是金鑰丟失後無法做到保密,常用的有AES、DES。 非對稱加密: 有一對金鑰,公鑰(向所有人開放)和私鑰(不對外開放)。公鑰加密的資料只能私鑰解密,私鑰加密的資料只能公鑰解密,利用這種特性可以用來校驗數字簽名。
HTTPS的解決方案是這樣的:用非對稱演算法隨機加密出一個對稱金鑰,然後雙方用對稱金鑰進行通訊。具體來說,就是客戶端生成一個隨機金鑰,用伺服器的公鑰對這個金鑰進行非對稱加密,伺服器用私鑰進行解密,然後雙方就用這個對稱金鑰來進行資料加密了。
2.2.4、資料的完整性
雜湊演算法可以將任意長度的資料轉化成固定大小的字串,並且該過程不可逆,利用這個特性做資料完整性的校驗。
2.2.5、HTTPS完整過程大致如下兩圖
要點: 使用公鑰對摘要加密得到簽名,使用私鑰解密簽名得到公鑰
為什麼需要數字證書? 因為網路通訊的雙方都可能不認識,那麼就需要第三方介紹,這就是數字證書。數字證書是由Certificate Athority(CA認證中心)頒發的。
2.2.6、為什麼Charles
能夠抓取HTTPS報文?
通過上面的分析,我們知道HTTPS可以有效防止中間人攻擊,但是Charles
,Fiddler
是可以抓取HTTPS請求並解密的,它們是如何做到的呢?
Charles作為一個中間人代理
,當瀏覽器和伺服器通訊時,Charles接收伺服器的證書,但自己動態生成一張證書傳送給瀏覽器,也就是說Charles作為中間代理在瀏覽器和伺服器之間通訊,所以通訊的資料可以被Charles攔截並解密。由於Charles更改了證書,瀏覽器校驗不通過會給出安全警告,必須安裝Charles的證書後才能進行正常訪問。
-
1、客戶端向伺服器發起HTTPS請求
-
2、Charles攔截客戶端的請求,偽裝成客戶端向伺服器進行請求
-
3、伺服器向“客戶端”(實際上是Charles)返回伺服器的CA證書
-
4、Charles攔截伺服器的響應,獲取伺服器證書公鑰,然後自己製作一張證書,將伺服器證書替換後傳送給客戶端。(這一步,Charles拿到了伺服器證書的公鑰)
-
5、客戶端接收到“伺服器”(實際上是Charles)的證書後,生成一個對稱金鑰,用Charles的公鑰加密,傳送給“伺服器”(Charles)
-
6、Charles攔截客戶端的響應,用自己的私鑰解密對稱金鑰,然後用伺服器證書公鑰加密,傳送給伺服器。(這一步,Charles拿到了對稱金鑰)
-
7、伺服器用自己的私鑰解密對稱金鑰,向“客戶端”(Charles)傳送響應
-
8、Charles攔截伺服器的響應,替換成自己的證書後傳送給客戶端
至此,連線建立,Charles拿到了 伺服器證書的公鑰 和 客戶端與伺服器協商的對稱金鑰,之後就可以解密或者修改加密的報文了。
HTTPS抓包的原理還是挺簡單的,簡單來說,就是Charles作為“中間人代理”,拿到了 伺服器證書公鑰 和 HTTPS連線的對稱金鑰,前提是客戶端選擇信任並安裝Charles的CA證書,否則客戶端就會“報警”並中止連線。這樣看來,HTTPS還是很安全的。
2.2.7、如何阻止Charles讀取HTTPS資料?
- 方案一:對HTTPS傳輸的資料進行二次對稱加密(對稱祕鑰不能洩露)
- 方案二:使用雙向認證,不僅客戶端驗證伺服器證書的合法性,伺服器也要驗證客戶端證書的合法性