20211114 HTTP 協議入門
網路分層
網路傳輸需要處理的問題
在兩臺主機間進行網路請求需要處理的問題：
網路分層協議
解決方法：將網路分層，在不同分層中處理不同問題，在層級間通過定義標準化介面進行呼叫
為了簡化網路的複雜度，網路通訊的不同方面被分解為多層次結構，每一層只與緊挨著的上層或者下層進行互動，將網路分層，這樣就可以修改，甚至替換某一層的軟體，只要層與層之間的介面保持不變，就不會影響到其他層
- OSI（ Open System Interconnection Reference Model ）：開放系統互聯參考模型
- TCP/IP 協議族
網路請求的分層解析流程
HTTP 協議
超文字傳輸協議 （ Hyper Text Transfer Protocol ， HTTP ）：一種無狀態的，以請求/應答方式執行的協議，它使用可擴充套件的語義和自描述訊息格式，與基於網路的超文字資訊系統靈活的互動
HTTP 報文格式
HTTP 協議的 請求報文 和 響應報文 的結構基本相同，由三大部分組成：
- 起始行（ start line ）：描述請求或響應的基本資訊
- 頭部欄位集合（ header ）：使用 key-value 形式更詳細地說明報文
- 訊息正文（ entity ）：實際傳輸的資料，它不一定是純文字，可以是圖片、視訊等二進位制資料
請求行報文格式
- 請求方法：如 GET/HEAD/PUT/POST ，表示對資源的操作
- 請求目標：通常是一個 URI ，標記了請求方法要操作的資源
- 版本號：表示報文使用的 HTTP 協議版本。
響應行報文格式
- 版本號：表示報文使用的 HTTP 協議版本
- 狀態碼：一個三位數，用程式碼的形式表示處理的結果，比如 200 是成功， 500 是伺服器錯誤
- 原因：作為數字狀態碼補充，是更詳細的解釋文字，幫助人理解原因
HTTP 頭欄位
頭部欄位是 key-value 的形式， key 和 value 之間用 : 分隔，最後用 CRLF 換行表示欄位結束。比如前後端分離時經常遇到的要與後端協商傳輸資料的型別 Content-type:application/json ，這裡 key 就是 Content-type ， value 就是 application/json 。 HTTP 頭欄位非常靈活，不僅可以使用標準裡的 Host 、 Connection 等已有頭，也可以任意新增自定義頭，這就給 HTTP 協議帶來了無限的擴充套件可能。
頭欄位使用注意事項：
- 欄位名不區分大小寫，欄位名裡不允許岀現空格，可以使用連字元
-，但不能使用下劃線_（有的伺服器不會解析帶下劃線_的頭欄位） - 欄位名後面必須緊接著
:，不能有空格，而:後的欄位值前可以有多個空格 - 欄位的順序是沒有意義的，可以任意排列不影響語義
- 欄位原則上不能重複，除非這個欄位本身的語義允許，例如
Set-Cookie
常用頭欄位
HTTP 協議中有非常多的頭欄位，但基本上可以按照以下分類：
- 請求欄位：請求頭中的頭欄位；如
Host，Referer - 響應欄位：響應頭中的頭欄位，如：
Server，Date - 通用欄位：在請求頭和響應頭裡都可以出現，如
Content-type，Connection
HTTP 請求的完整過程
當用戶在瀏覽器輸入網址回車之後，網路協議都做了哪些工作呢？
- 首先幹活的是瀏覽器應用程式，他要解析出 URL 中的域名
- 根據域名獲取對應的 IP 地址，首先從瀏覽器快取中檢視，如下可以檢視瀏覽器中域名對應 IP 的解析
chrome://net-internals/#events，如果沒有則從本機域名解析檔案 hosts （/etc/hosts）中檢視，還沒有則從 LDNS（ Local dns server ）、 Root server 域名伺服器、國際頂級域名服務商的 DNS 的層層解析 - 拿到 IP 地址後，瀏覽器就可以發起與伺服器的三次握手
- 握手建立之後，就開始組裝 http 請求報文，傳送報文
- 伺服器收到請求報文之後開始，請求報文解析，生成響應資料，傳送響應資料
- 瀏覽器收到響應之後，開始渲染頁面
TCP 協議
TCP （ Transmission Control Protocol ）：面向連線的，可靠的，基於位元組流的傳輸層通訊協議
特點：
- 基於連線的：資料傳輸之前需要建立連線
- 全雙工的：雙向傳輸
- 位元組流：不限制資料大小，打包成報文段，保證有序接收，重複報文自動丟棄
- 流量緩衝：解決雙方處理能力的不匹配
- 可靠的傳輸服務：保證可達，丟包時通過重發機制實現可靠性
- 擁塞控制：防止網路出現惡性擁塞
TCP 報文結構
TCP 連線管理
- TCP 連線：四元組 （源地址，源埠，目的地址，目的埠）
- 確立連線： TCP 三次握手
- 同步通訊雙方初始序列號（ ISN ， initial sequence number ）
- 協商 TCP 通訊引數（ MSS ，視窗資訊，指定校驗和演算法 ）
如何進行握手？
握手時核心發生了什麼？
TCP 四次揮手
- A ：傳送 FIN 資料包，代表 A 不再發送資料
- B ：收到請求，開始應答，避免了 A 重新發送 FIN 重試（應答機制）
- B ：處理完資料之後關閉，關閉連線，以及傳送 FIN 請求
- A ：收到請求後傳送 ACK 應答， B 服務可以釋放連線
等待 2MSL 後釋放連線
- 防止報文丟失，導致 B 重複傳送 FIN
- 防止滯留在網路中的報文，對新建立的連線造成資料擾亂
位元組流的協議
TCP 把應用交付的資料僅僅看成時一連串的無結構的位元組流， TCP 並不知道位元組流的含義， TCP 並不關心應用程式一次將多大的報文傳送到 TCP 的快取中，而是根據對方給出的視窗值和當前網路擁堵的程度來決定一個報文段應該包含多少個位元組。
MSS ： Max Segment Size ，預設 536 byte 實際資料
資料可靠性傳輸
停止等待協議
停止等待就是每傳送完一個分組就停止傳送，等待對方的確認。在收到確認後再發送下一個分組。
重傳機制
-
ack 報文丟失
-
請求報文丟失
滑動
視窗協議與累計確認（延時 ACK ）
滑動視窗大小通過 TCP 三次握手和對端協商，且受網路狀況影響
HTTPS 協議
HTTPS
由於 HTTP 天生 “明文” 的特點，整個傳輸過程完全透明，任何人都能夠在鏈路中截獲、修改或者偽造請求/響應報文，資料不具有可信性。因此就誕生了為安全而生的 HTTPS 協議。
使用 HTTPS 時，所有的 HTTP 請求和響應在傳送到網路之前，都要進行加密
SSL/TLS
SSL 即安全套接層（ Secure Sockets Layer ），由網景公司於 1994 年發明， IETF 在 1999 年把它改名為 TLS （傳輸層安全， Transport Layer Security ）正式標準化，到今天 TLS 已經發展出了主流的三個版本，分別是 2006 年的 1.1 、 2008 年的 1.2 ， 2018 的 1.3 ，每個新版本都緊跟密碼學的發展和網際網路的現狀，持續強化安全和效能，已經成為了資訊保安領域中的權威標準。
摘要演算法
摘要演算法能夠把仼意長度的資料 “壓縮” 成固定長度、而且獨一無二的 “摘要” 字串，就好像是給這段資料生成了一個數字 “指紋” 。任意微小的資料差異，都可以生成完全不同的摘要。所以可以通過把明文資訊的摘要和明文一起加密進行傳輸，資料傳輸到對方之後再進行解密，重新對資料進行摘要，再比對就能發現數據有沒有被篡改。這樣就保證了資料的完整性。
加密演算法
- 對稱金鑰加密演算法 ：編、解碼使用相同金鑰的演算法，如（ AES ，RC4 ， ChaCha20 ）
- 非對稱金鑰加密演算法 ：它有兩個金鑰，一個叫 公鑰 ，一個叫 私鑰 。兩個金鑰是不同的，公鑰可以公開給任何人使用，而私鑰必須嚴格保密。非對稱加密可以解決 ”金鑰交換“ 的問題。網站祕密保管私鑰，在網上任意分發公鑰，你想要登入網站只要用公鑰加密就行了，密文只能由私鑰持有者才能解密。而黑客因為沒有私鑰，所以就無法破解密文。非對稱金鑰加密系統通常需要大量的數學運算，比較慢。如（ DH 、 DSA 、 RSA 、 ECC ）
TLS 裡使用的混合加密方式，即把對稱加密和非對稱加密結合起來呢，兩者互相取長補短，即能髙效地加密解密，又能安全地金鑰交換。大致流程如下
-
通訊開始的時候使用非對稱演算法如 RSA ，ECDHE 先解決金鑰交換的問題
-
用隨機數產生對稱演算法使用的 "會話金鑰"，再用公鑰加密。會話金鑰很短，所以即便使用非對稱加密演算法也可以很快完成加解密
-
對方拿到密文後用私鑰解密，取出會話金鑰。完成對稱金鑰的安全交換，後續就使用對稱演算法發完成資料交換
身份驗證
數字證書組成：CA 資訊，公鑰使用者資訊，公鑰，權威機構的簽名，有效期
數字證書作用：
- 通過數字證書向瀏覽器證明身份
- 數字證書裡面包含了公鑰
數字證書的申請和驗證
如何申請：
- 生成自己的公鑰和私鑰，伺服器自己保留私鑰
- 向 CA 機構提交公鑰，公司，域名資訊等待認證
- CA 機構通過線上，線下多種途徑驗證你提交資訊的真實性，合法性
- 資訊稽核通過， CA 機構則會向你簽發認證的數字證書，包含了公鑰，組織資訊， CA 資訊，有效時間，證書序列號，同時生成一個簽名
簽名步驟： hash(你用於申請證書所提交的明文資訊)=資訊摘要； CA 再使用私鑰對資訊摘要進行加密，密文就是證書的數字簽名
瀏覽器如何驗證：
有了 CA 簽名過的數字證書，當瀏覽器訪問伺服器時，伺服器會返回數字證書給瀏覽器。瀏覽器收到證書後會對數字證書進行驗證。
首先瀏覽器讀取證書中相關的明文資訊，採用 CA 簽名時相同的 hash 函式計算得到資訊摘要 A ，再利用對應的 CA 公鑰解密數字簽名資料得到資訊摘要 B ，如果摘要 A 和摘要 B 一致，則可以確認證書時合法的