筆記：網絡基礎TCP、HTTP、HTTPS（HTTP+SSL）

[TOC]

@(iOS總結)

一切從簡，用本身的方式記錄。若是你以爲囉嗦，那多是我怕說的不明白；若是你以爲太籠統，那多是我以爲太基礎沒寫出來，或者我還沒認知到；若是你以爲和別的文章過重複，那多是我沒有找到更好的表達方式；

系統學習最好看一下 UNIX網絡編程卷1：套接字聯網API（第3版）.pdf

1、TCP（詳情參考：必須懂的計算機網絡知識—(TCP)）

1.一、網絡模型數據處理過程

1.二、TCP和UDP的區別

TCP位於傳輸層，傳輸層協議還包括UDP、HTTP（超文本傳輸協議）、FTP（文件傳輸協議）、SNMP（簡單網絡管理協議）、Telnet（遠程登陸協議）等。下面的表格列出了TCP和UDP的區別。

傳輸層協議	TCP（Transmission Control Protocol傳輸控制協議）	UDP（User Datagram Protocol用戶數據報協議）
鏈接方式	面向鏈接（一對一）	無鏈接（一對1、一對多、多對1、多對多）
佔用系統資源	多（首部開銷20字節）	少（首部開銷8字節）
可靠性	可靠，保證數據正確（全雙工）	不可靠，可能會丟包
數據順序	保證數據順序	不保證數據順序
擁塞控制	有擁塞控制，面向數據流	無擁塞控制，面向報文
流量控制	有（滑動窗口）	無

注意： 「ping」命令是使用 IP 和網絡控制信息協議 (ICMP)，於是沒有涉及到任何傳輸協議(UDP/TCP) 和應用程序

---

TCP由於是面向鏈接的，因此比UDP要更復雜，創建鏈接須要三次握手，斷開鏈接須要四次揮手。TCP充分實現了數據傳輸時各類控制功能，能夠進行丟包的重發控制，還能夠對次序亂掉的分包進行順序控制。而這些在UDP中都沒有。此外，TCP做爲一種面向有鏈接的協議，只有在確認通訊對端存在時纔會發送數據，從而能夠控制通訊流量的浪費。TCP經過檢驗和、序列號、確認應答、重發控制、鏈接管理以及窗口控制等機制實現可靠性傳輸。

1.三、創建鏈接爲何要三次握手？

假如讓我和你來實現一次完整可靠的鏈接，會怎麼作呢？

• 第一次握手，我告訴你我要和你創建鏈接
• 第二次握手，你告訴我你能收到我發送的消息
• 第三次握手，我告訴你我能收到你發送的消息 而後，你能收到我發送的，我能收到你發送的，咱倆下面就能夠暢聊了

1.四、斷開鏈接爲何要四次揮手？

• 第一次握手：我告訴你，我要和你斷開鏈接
• 第二次握手：你告訴我，你收到我發送的斷開鏈接消息了，可是可能還有數據沒有發送完畢，等一會再告訴我
• 第三次握手：你告訴我，你沒有正在發送的數據了，你能夠和我斷開鏈接了
• 第四次揮手：我告訴你，我收到你發送的能夠和我斷開鏈接的消息了 而後，本次會話完美結束了，沒有漏掉任何消息

1.五、TCP流量控制

所謂的流量控制就是接收方讓發送方的發送速率不要太快，讓接收方來得及接收。利用滑動窗口機制能夠很方便的在TCP鏈接上實現對發送方的流量控制。TCP窗口的單位是字節，不是報文段，發送方的發送窗口不能大於接收方給出的接收窗口（rwnd）的大小。

1.六、TCP擁塞控制

爲了方式網絡的擁塞現象，TCP提出了一系列的擁塞控制機制。擁塞控制的原理主要依賴於一個擁塞窗口（cwnd），發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就增大一寫，以便把更多的分組發送出去。可是隻要出現網絡擁塞，擁塞窗口就減小一些，以便減小注入到網絡中的分組。主要有四種算法：慢啓動（Slow-start)、擁塞避免（Congestion Avoidance)、快重傳（Fast Restrangsmit)、快恢復（Fast Recovery）。

擁塞控制和流量控制的區別

區別	擁塞控制	流量控制
做用範圍	全局性的（設計全部主機、路由器、以及與下降網絡傳輸性能有關的全部因素）	點對點的通訊量控制，是個端到端的問題
控制方	發送方控制	接收方控制
控制結果	控制發送方注入到網絡中的數據量	控制發送端的發送數據速率，以便接收端來得及接收

2、HTTP、HTTPS

2.一、HTTP（詳情參考：HTTP 教程| 菜鳥教程 、關於HTTP協議，一篇就夠了）

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。規範把 HTTP 請求分爲三個部分：狀態行、請求頭、消息主體。

2.1.一、HTTP基礎知識：URL

統一資源定位符（Uniform Resource Locator）是網絡資源的位置和訪問方法的簡潔表示。常見的url包括4個部分，結構以下圖：

組件	含義
方案	使用的協議，如http或https
主機	服務器的域名或IP地址
路徑	服務器上資源的本地名，用（/）與前面的scheme分隔開來
查詢字符串	經過查詢字符串來減少請求資源類型的範圍，如參數

2.1.二、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.三、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.四、HTTP與TCP的區別？

TCP協議對應於傳輸層，HTTP協議對應於應用層，從本質上來講兩者沒有可比性。 不少人喜歡把IP比做告訴公路，TCP是告訴公路上的卡車，他們攜帶的貨物就是HTTP協議。 我以爲這是很不嚴謹的，若是非要舉個形象的例子，我以爲能夠把IP比做電話號碼，TCP就像電話，傳輸去的聲音就像數據包，若是是開會就會遵循電話會議規則（好比HTTP），若是是銷售就會遵循推銷規則（好比FTP），若是是閒聊就按照雙方想要的規則（自定義數據傳輸協議）。 TCP傳輸的數據包能夠任何格式的，能夠自定義規則，能夠遵循HTTP協議，也能夠遵循FTP協議。

2.1.五、如何解決HTTP的無狀態協議？

使用Cookie來解決無狀態的問題，Cookie就至關於一個通行證，第一次訪問的時候給客戶端發送一個Cookie，當客戶端再次來的時候，拿着Cookie(通行證)，那麼服務器就知道這個是」老用戶「。

2.二、HTTPS（詳情參考：詳細解析 HTTP 與 HTTPS 的區別）

https, 全稱Hyper Text Transfer Protocol Secure，相比http，多了一個secure。一句話：HTTPS=HTTP+加密+認證+完整性保護。

理清幾個概念很重要

• 一、CA（數字證書頒發機構）
• 二、非對稱祕鑰：CA的一對非對稱祕鑰、服務器的一對非對稱祕鑰、客戶端的一對非對稱祕鑰
• 三、對稱祕鑰：客戶端隨機生成的，用於認證完成以後的數據加解密（客戶端經過服務器返回的數字證書中的公鑰加密對稱祕鑰後，發送給服務器）
• 四、數字證書：CA頒發給服務器的數字證書（證書中的公鑰是服務器的公鑰，可是簽名使用的是CA的私鑰）、CA根證書（證書中的公鑰是CA本身的公鑰，簽名使用的是CA本身的私鑰<用來保證該證書沒有被中間篡改過>）
• 五、單雙向認證：單向認證，客戶端驗證服務器；雙向認證，客戶端先驗證服務器證書，服務器在驗證客戶端的證書。雙向認證的時候，客戶端須要向服務器請求頒發給本身數字證書 = 用服務器的公鑰（另一對中的）加密摘要獲得的簽名+客戶端信息 + 客戶端公鑰。Https單向認證和雙向認證

瀏覽器、操做系統、或者應用本身內置了信任的根證書，瀏覽器或者客戶端接收到服務器返回的的CA頒發的數字證書，從內置信任的根證書中獲取CA的公鑰，而後對服務器返回的數字證書中的簽名進行解密獲得摘要1，而後對服務器返回的數字證書中的內容進行取摘要運算獲得摘要2，最後對比摘要1與摘要2是否相等，繼而判斷服務方是不是被CA認證的服務方。

2.2.一、SSL解決了通訊中哪些問題？

• 一、認證（Authentication）：沒法確認與我正在通訊的人，就是我真正想通訊的人

• 二、泄露（privacy）：與我通訊的內容，被別人偷聽

• 三、篡改（data integrity）：我接受到的的內容，並非對方原始發送的數據

SSL不解決如下問題： 不可抵賴性（消息的發送者沒辦法不認可消息是本身發出的）。由於SSL並不對傳輸的數據作簽名。可是SSL加上數字簽名證書能夠解決該問題。

2.2.二、檢驗雙方的真實性

HTTPS使用了數字證書（身份認證機構蓋在數字身份證上的一個章或印，或者說加在數字身份證上的一個簽名），這一行爲表示身份認證機構已認定這我的，證書的合法性能夠向CA驗證。客戶端收到服務器的響應後，先向CA驗證證書的合法性，若是校驗不經過瀏覽器就會終止鏈接，並提示用戶證書不安全。 數字證書的組成：

• 證書頒發機構
• 證書頒發機構簽名（數字簽名是什麼？）
• 證書綁定的服務器域名
• 證書版本、有效期
• 簽名使用的算法（非對稱加密算法，RSA）
• 公鑰

2.2.三、數據的保密性

就是對數據進行加密，一般使用兩種加密算法：對稱加密、非對稱加密。

對稱加密： 加密和解密使用相同的密鑰，有點是加解密速度快，缺點是密鑰丟失後沒法作到保密，經常使用的有AES、DES。 非對稱加密： 有一對密鑰，公鑰（向全部人開放）和私鑰（不對外開放）。公鑰加密的數據只能私鑰解密，私鑰加密的數據只能公鑰解密，利用這種特性能夠用來校驗數字簽名。

HTTPS的解決方案是這樣的：用非對稱算法隨機加密出一個對稱密鑰，而後雙方用對稱密鑰進行通訊。具體來講，就是客戶端生成一個隨機密鑰，用服務器的公鑰對這個密鑰進行非對稱加密，服務器用私鑰進行解密，而後雙方就用這個對稱密鑰來進行數據加密了。

2.2.四、數據的完整性

哈希算法能夠將任意長度的數據轉化成固定大小的字符串，而且該過程不可逆，利用這個特性作數據完整性的校驗。

2.2.五、HTTPS完整過程大體以下兩圖

要點： 使用公鑰對摘要加密獲得簽名，使用私鑰解密簽名獲得公鑰

爲何須要數字證書？ 由於網絡通訊的雙方均可能不認識，那麼就須要第三方介紹，這就是數字證書。數字證書是由Certificate Athority(CA認證中心)頒發的。

2.2.六、爲何Charles可以抓取HTTPS報文？

經過上面的分析，咱們知道HTTPS能夠有效防止中間人攻擊，可是Charles，Fiddler是能夠抓取HTTPS請求並解密的，它們是如何作到的呢？

Charles做爲一個中間人代理，當瀏覽器和服務器通訊時，Charles接收服務器的證書，但本身動態生成一張證書發送給瀏覽器，也就是說Charles做爲中間代理在瀏覽器和服務器之間通訊，因此通訊的數據能夠被Charles攔截並解密。因爲Charles更改了證書，瀏覽器校驗不經過會給出安全警告，必須安裝Charles的證書後才能進行正常訪問。

• 一、客戶端向服務器發起HTTPS請求

• 二、Charles攔截客戶端的請求，假裝成客戶端向服務器進行請求

• 三、服務器向「客戶端」（其實是Charles）返回服務器的CA證書

• 四、Charles攔截服務器的響應，獲取服務器證書公鑰，而後本身製做一張證書，將服務器證書替換後發送給客戶端。（這一步，Charles拿到了服務器證書的公鑰）

• 五、客戶端接收到「服務器」（其實是Charles）的證書後，生成一個對稱密鑰，用Charles的公鑰加密，發送給「服務器」（Charles）

• 六、Charles攔截客戶端的響應，用本身的私鑰解密對稱密鑰，而後用服務器證書公鑰加密，發送給服務器。（這一步，Charles拿到了對稱密鑰）

• 七、服務器用本身的私鑰解密對稱密鑰，向「客戶端」（Charles）發送響應

• 八、Charles攔截服務器的響應，替換成本身的證書後發送給客戶端

至此，鏈接創建，Charles拿到了 服務器證書的公鑰 和 客戶端與服務器協商的對稱密鑰，以後就能夠解密或者修改加密的報文了。

HTTPS抓包的原理仍是挺簡單的，簡單來講，就是Charles做爲「中間人代理」，拿到了 服務器證書公鑰 和 HTTPS鏈接的對稱密鑰，前提是客戶端選擇信任並安裝Charles的CA證書，不然客戶端就會「報警」並停止鏈接。這樣看來，HTTPS仍是很安全的。

2.2.七、如何阻止Charles讀取HTTPS數據？

• 方案一：對HTTPS傳輸的數據進行二次對稱加密（對稱祕鑰不能泄露）
• 方案二：使用雙向認證，不只客戶端驗證服務器證書的合法性，服務器也要驗證客戶端證書的合法性

參考資料

TCP和UDP的最完整的區別

SSL解決了通訊中的哪些問題 ?

淺談HTTPS通訊機制和Charles抓包原理

HTTP TCP UDP Socket 關係的幾個經典圖