《圖解HTTP》讀書筆記

摘要： 1. TCP/IP分層 TCP/IP協議族分為四層：應用層、傳輸層、網路層和資料鏈路層。OSI模型將網路通訊分為七層：應用層、表示層、會話層、傳輸層、網路層、資料鏈路層、物理層。 利用TCP/IP協議族進行網路通訊時，會通過分層順序與對方進行通訊。傳送端從應用層往下走...

1. TCP/IP分層

TCP/IP協議族分為四層：應用層、傳輸層、網路層和資料鏈路層。OSI模型將網路通訊分為七層：應用層、表示層、會話層、傳輸層、網路層、資料鏈路層、物理層。

利用TCP/IP協議族進行網路通訊時，會通過分層順序與對方進行通訊。傳送端從應用層往下走，接收端則往應用層往上走。

傳送端的客戶端在應用層（HTTP協議)傳送一個想看到某個Web頁面的Http請求。在傳輸層（TCP協議）把應用層處接收到的資料（HTTP請求報文）進行分割，並將各個報文打上標記序號及埠號後轉發給網路層。在網路層(IP協議)，增加作為通訊目的地的MAC 地址後轉發給鏈路層，直至傳送到接收端伺服器。接收端伺服器接收到資料，按序往上層傳送，一直到應用層。

傳送端在層與層傳輸資料時，每經過一層必定打上一個該層所屬的首部資訊，例如http首部，TCP 首部，ip首部，乙太網首部。接收端在層與層傳輸資料時，每經過一層會將對應的首部消掉。

IP 地址指明瞭節點被分配的地址，MAC 地址是指網絡卡所屬固定的地址。IP地址可以與MAC 地址進行配對。IP 地址可變換，但是MAC 地址基本上不會更改

使用ARP協議憑藉MAC地址進行通訊。

2. TCP 三次握手

為準確無誤的將資料送達目標處，TCP 協議採用三次握手策略。握手過程使用TCP標誌（flag)-SYN(synchronize)和ACK(acknowledgement)。傳送端首先發送一個帶有SYN標誌的資料包給對方。接收到後回傳一個帶有SYN/ACK標誌的資料包以示傳達確認資訊。最後傳送端再回傳一個帶有ACK標誌的資料包，代表“握手”結束。

3. URI

URI(統一資源識別符號)用字串標識某一網際網路資源，而

URL(統一資源定位符)表示資源的地點（網際網路上所處的位置）。可見URL是URI的子集。

4. HTTP報文

1. 請求報文是有請求方法、請求URL、協議版本、可選的請求首部欄位 和內容實體構成。
2. 響應報文是有協議版本號、狀態碼、狀態碼原因短語、可選的響應首部欄位以及實體主體構成。
3. Http 是一種不儲存狀態的協議,可通過cookie實現狀態管理
4. HTTP 報文不一定有報文主體，例如HEAD 方法返回的報文。
5. HTTP 報文字身是有多行（CR+LF作為換行符）資料構成的字串文字。 可以分為報文首部，及報文主體

5. 提高HTTP 效率

HTTP協議初始版本中，每進行一次HTTP通訊就要斷開一次TCP連線，協議後來提高效率方式有

1. 持久連線，減少TCP重複建立和斷開所造成的額外開銷，減少伺服器負載，提高響應效率。
2. 管線化。HTTP 初始版本，傳送請求需等待並受到響應，才能傳送下個請求。管線化後可不用等待，可同時併發多個請求。

HTTP/1.1 所以連線預設都是持久連線。但在HTTP/1.0內並未標準化。

6. 狀態碼

• 1XX,資訊性狀態碼，接受請求正在處理
• 2XX，成功狀態碼，請求正常處理完畢
• 3XX, 重定向狀態碼，需要進行附加操作以完成請求
• 4XX,客戶端錯誤狀態碼，伺服器無法處理請求
• 5XX,伺服器錯誤狀態碼，伺服器處理請求出
• 301：永久重定向，表示該請求資源已被分配了新的URL,以後應使用資源現在所指定的URI。
• 302：臨時性重定向，表示請求資源已被分配新的URL,希望使用者本次能使用新的URI訪問。
• 301、302標準是禁止將POST方法改變成GET方法

7、 首部

Cache-Control：no-cache

8. Cookie

1. 伺服器通過Set-Cookie首部控制cookie,包含NAME=VALUE、expires=DATE、path=PATH、domain=域名、Secure、HttpOnly
2. 當省略expires屬性，其Cookie有效期及限於維持瀏覽器會話（Session)時間段內。這通常限於瀏覽器應用被關閉之前。
3. 新增secure屬性用於限制Web頁面僅在Https安全連線時，才可以傳送Cookie.
4. HttpOnly屬性使Cookie不能被JavaScript指令碼訪問，主要目的為防止跨站指令碼攻擊（XSS)對Cookie資訊的竊取。
5. 一旦Cookie 從伺服器傳送給客戶端，服務端就不存在可以顯示刪除Cookie的方法，但是可以通過覆蓋已過期Cookie,實現對客戶端Cookie實質性刪除操作。

9. HTTP缺點

• 無狀態協議
• 通訊使用明文（不加密），內容可能會被竊聽（竊聽風險）
• 不驗證通訊放身份，因此有可能遭遇偽裝（冒充風險）
• 無法驗證報文完整性，英雌可能已遭篡改。（篡改風險）

10.HTTPS

• Https是身披SSL外殼的HTTP,並非是應用層的一種新協議，只是Http通訊介面部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協議代替而已。通常HTTP直接和TCP通訊，當時用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊。
• 採用SSL 後，HTTP擁有HTTPS的加密、證書和完整性保護。
• SSL 時獨立於HTTP的協議，其他應用層的協議均可配合SSL協議使用
• HTTPS使用SSL和TLS這兩個協議，TLS是以SSL為原型開發的協議，有時統稱SSL。當前主流為SSL3.0和TLS1.0
• HTTPS 採用共享金鑰加密（對稱金鑰加密）和公開金鑰加密（不對稱金鑰加密）兩者並用混合加密機制。交換金鑰環節使用公開金鑰加密方式，之後建立通訊交換報文階段則使用共享金鑰加密方式。
• 公開密碼加密通訊存在無法證明公開金鑰就是貨真價實的公開金鑰。可使用數字證書認證機構和其他相關機構頒發的公開證書。
• 整個SSL握手階段都不加密（也沒法加密），都是明文的。建立SSL連線採用對稱加密報文。

11. HTTPS 缺點

• 證書成本
• 降低訪問速度（多次握手）
• 改造HTTPS後，之前HTTP 跳轉到 HTTPS 的方式增加了使用者訪問耗時（多數網站採用302跳轉）
• HTTPS 涉及到的安全演算法會消耗 CPU 資源

12. HTTPs 為啥能安全通訊

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向伺服器端索要公鑰，然後用公鑰加密資訊，伺服器收到密文後，用自己的私鑰解密

• 保證公鑰不必篡改：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的
• 減少公鑰加密時間： 非對稱公鑰只用於SSL 握手階段加密"對話金鑰"本身，建立SSL連線後，通過對稱金鑰加密報文，減少非對稱密碼加密解密耗時。
• SSL/TLS協議的基本過程：
  • 客戶端向伺服器索要並驗證公鑰
  • 雙方協商對話密碼
  • 雙方採用對話密碼進行加密通訊。

13.HTTPS 通訊過程

1. 客戶端通過傳送CLient Hello 報文開始SSL 通訊，報文中包含客戶端支援的SSL版本、加密演算法、支援壓縮方法、生成隨機數。
2. 伺服器可進行SSL通訊時，會以Server Hello報文作為應答。在報文中確認通訊SSL協議、加密方法 及生成的隨機數，稍後用於生成"對話金鑰"
3. 之後伺服器傳送Cerficate報文，報文包含公開金鑰證書
4. 最後伺服器傳送Server Hello Done 報文通知客戶端，最初SSL 握手協商部分結束
5. 客戶端收到證書後，首先驗證伺服器證書。如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊，客戶端以Client Key Exchange報文作為迴應，報文中包含通訊加密中使用的Pre-master secret 隨機金鑰串。
6. 客戶端繼續傳送Change Cipher Spec報文。提示服務，在此報文之後通訊會採用Pre-master secret 金鑰加密
7. 客戶端傳送Finished 報文。報文包含連線至今全部報文的全體校驗值。這次握手協商是否能成功，要以伺服器是否能夠正確解密該報文作為判斷標準
8. 伺服器同樣傳送Change Cipher Spec 報文
9. 伺服器同樣傳送Finished 報文
10. SSL 連線建立完成，通訊受SSL保護，客戶端與伺服器進入加密通訊，就完全是使用普通的HTTP協議，只不過用"會話金鑰"加密內容。

14. 瀏覽器驗證證書

• 瀏覽器讀取伺服器傳送過來的證書，對證書所有者、有效期等資訊進行一一校驗，看是否過期等
• 瀏覽器開始查詢作業系統中已內建的受信任的證書釋出機構CA，與伺服器發來的證書中的頒發者CA比對，用於校驗證書是否為合法機構頒發
• 如果找不到，瀏覽器就會報錯，說明伺服器發來的證書是不可信任的
• 如果找到，那麼瀏覽器就會從作業系統中取出 頒發者CA 的公鑰，然後對伺服器發來的證書裡面的簽名進行解密
• 瀏覽器使用相同的hash演算法計算出伺服器發來的證書的hash值，將這個計算的hash值與證書中籤名做對比
• 對比結果一致，則證明伺服器發來的證書合法，沒有被冒充
• 此時瀏覽器就可以讀取證書中的公鑰，用於後續加密了

15. HTTPS 升級操作

• 獲取證書
• 安裝證書 (證書可以放在/etc/ssl目錄（Linux 系統）)
• 修改連結:因為加密網頁內如果有非加密的資源，瀏覽器是不會載入那些資源的,需要將http連結改成Https連結）
• 301重定向：使用 301 重定向，將 HTTP 協議的訪問導向 HTTPS 協議
• 參考：
  • ofollow,noindex">HTTPS 升級指南

16. session 管理及認證過程

• 客戶端將使用者名稱和密碼等登入資訊放入報文實體部分提交給伺服器。
• 伺服器對客戶端傳送過來的登入資訊進行身份驗證，並生成識別使用者的session ID,將使用者身份資訊及認證狀態與Session繫結記錄在服務端。向客戶端返回響應，在首部欄位Set-Cookie寫入Session ID
• 客戶端接受到從伺服器發來的Session ID後，會將作為Cookie儲存在本地。
• 客戶端下次向伺服器請求，瀏覽器自動傳送Cookie,Session ID 也隨之傳送到伺服器。
• 伺服器通過驗證接收到的Session ID識別使用者和其認證狀態。

17. HTTP 標準缺點

• 一條連線上只可傳送一個請求
• 請求只能從客戶端開始，客戶端不可以接受除響應以外的指令
• 請求/響應首部未經壓縮就傳送。首部資訊越多延遲越大
• 傳送冗長的首部。每次互相傳送相同的首部造成的浪費較多。
• 可任意選擇資料壓縮格式。非強制壓縮傳送

18. SPDY

• SPDY 沒有完全改寫HTTP 協議，而是在TCP/IP的應用於傳輸層之間通過新加的會話層形式運作。同時，考慮安全性問題，SPDY規定通訊中使用SSL。SPDY 以會話層的形式加入，控制對資料的流動，但還是採用HTTP 建立通訊連線。
• 優點：
  • 多路複用
  • 賦予請求優先順序
  • 壓縮HTTP 首部
  • 推送功能
  • 伺服器提示功能

19. Websocket

• WebSocket通過Http建立連線，然後升級到WebSocket協議，之後所有的通訊都依靠這個專門的協議進行。
• 與HTTP相比，Websocket連線建立後就希望一直保持連線狀態，減少每次連線開銷，而且Websocket首部資訊很小，通訊量也減少。

20. 網路攻擊

• 因輸出值轉義不完全引發安全漏洞
  • 跨站指令碼攻擊（XSS)
  • SQL%E6%B3%A8%E5%85%A5/">SQL注入（SQL injection)
  • OS命令注入攻擊（OS Command Injection)
  • HTTP首部注入攻擊（HTTP Header Injection)
  • 郵件首部注入攻擊（Mail Header Injection)
  • 目錄遍歷攻擊（Directory Traversal)
  • 遠端檔案包含漏洞
• 設計上缺陷導致安全漏洞
  • 強制瀏覽
  • 不正確的錯誤訊息處理
  • 開放重定向
• 會話管理疏忽引發安全漏洞
  • 會話劫持（Session Hijack)
  • 會話固定攻擊
  • 跨站點請求偽造（CSRF)
• 其他安全漏洞
  • 密碼破解
  • 點選劫持（Clickjacking)
  • DoS攻擊（Denial of Service attack)
  • 後門程式