[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傳輸的資料進行二次對稱加密（對稱祕鑰不能洩露）
- 方案二：使用雙向認證，不僅客戶端驗證伺服器證書的合法性，伺服器也要驗證客戶端證書的合法性