《圖解HTTP》讀書筆記

1. TCP/IP分層

TCP/IP協(xié)議族分為四層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。OSI模型將網(wǎng)絡(luò)通信分為七層：應(yīng)用層、表示層、會(huì)話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。

利用TCP/IP協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過分層順序與對(duì)方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則往應(yīng)用層往上走。
發(fā)送端的客戶端在應(yīng)用層（HTTP協(xié)議)發(fā)送一個(gè)想看到某個(gè)Web頁面的Http請(qǐng)求。在傳輸層（TCP協(xié)議）把應(yīng)用層處接收到的數(shù)據(jù)（HTTP請(qǐng)求報(bào)文）進(jìn)行分割，并將各個(gè)報(bào)文打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。在網(wǎng)絡(luò)層(IP協(xié)議)，增加作為通信目的地的MAC 地址后轉(zhuǎn)發(fā)給鏈路層，直至發(fā)送到接收端服務(wù)器。接收端服務(wù)器接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用層。

發(fā)送端在層與層傳輸數(shù)據(jù)時(shí)，每經(jīng)過一層必定打上一個(gè)該層所屬的首部信息，例如http首部，TCP 首部，ip首部，以太網(wǎng)首部。接收端在層與層傳輸數(shù)據(jù)時(shí)，每經(jīng)過一層會(huì)將對(duì)應(yīng)的首部消掉。

IP 地址指明了節(jié)點(diǎn)被分配的地址，MAC 地址是指網(wǎng)卡所屬固定的地址。IP地址可以與MAC 地址進(jìn)行配對(duì)。IP 地址可變換，但是MAC 地址基本上不會(huì)更改

使用ARP協(xié)議憑借MAC地址進(jìn)行通信。

2. TCP 三次握手

為準(zhǔn)確無誤的將數(shù)據(jù)送達(dá)目標(biāo)處，TCP 協(xié)議采用三次握手策略。握手過程使用TCP標(biāo)志（flag)-SYN(synchronize)和ACK(acknowledgement)。發(fā)送端首先發(fā)送一個(gè)帶有SYN標(biāo)志的數(shù)據(jù)包給對(duì)方。接收到后回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。最后發(fā)送端再回傳一個(gè)帶有ACK標(biāo)志的數(shù)據(jù)包，代表“握手”結(jié)束。

3. URI

URI(統(tǒng)一資源標(biāo)識(shí)符)用字符串標(biāo)識(shí)某一互聯(lián)網(wǎng)資源，而
URL(統(tǒng)一資源定位符)表示資源的地點(diǎn)（互聯(lián)網(wǎng)上所處的位置）?？梢奤RL是URI的子集。

4. HTTP報(bào)文

  1. 請(qǐng)求報(bào)文是有請(qǐng)求方法、請(qǐng)求URL、協(xié)議版本、可選的請(qǐng)求首部字段 和內(nèi)容實(shí)體構(gòu)成。
  2. 響應(yīng)報(bào)文是有協(xié)議版本號(hào)、狀態(tài)碼、狀態(tài)碼原因短語、可選的響應(yīng)首部字段以及實(shí)體主體構(gòu)成。
  3. Http 是一種不保存狀態(tài)的協(xié)議,可通過cookie實(shí)現(xiàn)狀態(tài)管理
  4. HTTP 報(bào)文不一定有報(bào)文主體，例如HEAD 方法返回的報(bào)文。
  5. HTTP 報(bào)文本身是有多行（CR+LF作為換行符）數(shù)據(jù)構(gòu)成的字符串文本。 可以分為報(bào)文首部，及報(bào)文主體

5. 提高HTTP 效率

HTTP協(xié)議初始版本中，每進(jìn)行一次HTTP通信就要斷開一次TCP連接，協(xié)議后來提高效率方式有

  1. 持久連接，減少TCP重復(fù)建立和斷開所造成的額外開銷，減少服務(wù)器負(fù)載，提高響應(yīng)效率。
  2. 管線化。HTTP 初始版本，發(fā)送請(qǐng)求需等待并受到響應(yīng)，才能發(fā)送下個(gè)請(qǐng)求。管線化后可不用等待，可同時(shí)并發(fā)多個(gè)請(qǐng)求。

HTTP/1.1 所以連接默認(rèn)都是持久連接。但在HTTP/1.0內(nèi)并未標(biāo)準(zhǔn)化。

6. 狀態(tài)碼

  • 1XX,信息性狀態(tài)碼，接受請(qǐng)求正在處理
  • 2XX，成功狀態(tài)碼，請(qǐng)求正常處理完畢
  • 3XX, 重定向狀態(tài)碼，需要進(jìn)行附加操作以完成請(qǐng)求
  • 4XX,客戶端錯(cuò)誤狀態(tài)碼，服務(wù)器無法處理請(qǐng)求
  • 5XX,服務(wù)器錯(cuò)誤狀態(tài)碼，服務(wù)器處理請(qǐng)求出
  • 301：永久重定向，表示該請(qǐng)求資源已被分配了新的URL,以后應(yīng)使用資源現(xiàn)在所指定的URI。
  • 302：臨時(shí)性重定向，表示請(qǐng)求資源已被分配新的URL,希望用戶本次能使用新的URI訪問。
  • 301、302標(biāo)準(zhǔn)是禁止將POST方法改變成GET方法

7、 首部

  1. 當(dāng)首部重復(fù)，目前規(guī)范尚未明確，不同瀏覽器處理邏輯各部相同。
  2. 客戶端請(qǐng)求首部包含Cache-Control：no-cache,則表明客戶端將不會(huì)接受緩存過的響應(yīng)，于是中間的緩存服務(wù)器必須將客戶端請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。
  3. 客戶端請(qǐng)求頭包含max-age指令，如果判定緩存資源緩存時(shí)間數(shù)比指定數(shù)值更小，那么客戶端就接受緩存資源。當(dāng)指定max-age為0，那么緩存服務(wù)器通常需要將請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。
  4. HTTP/1.1版本緩存服務(wù)器遇到Expires首部及max-age指令，會(huì)忽略掉Expires首部，而HTTP/1.0版本相反，max-age指令會(huì)被忽略掉。
  5. HTTP/1.1版本默認(rèn)是持久連接。當(dāng)服務(wù)器想明確斷開連接時(shí)，則指定Connction 首部字段值為Close。而之前HTTP協(xié)議版本默認(rèn)都是非持久化連接。如果希望在舊版本HTTP協(xié)議維持持久化連接，則指定Connecton首部字段值為Keep-Alive.
  6. 首部字段Upgrade 用于升級(jí)協(xié)議版本。使用首部Upgrade時(shí)，還需要額外指定Connection:Upgrade。
  7. 首部字段Host會(huì)告知服務(wù)器，請(qǐng)求資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號(hào)。Host是HTTP/1.1規(guī)范中唯一一個(gè)必須被包含在請(qǐng)求內(nèi)的首部字段。Host 在單臺(tái)服務(wù)器，分配多個(gè)域名虛擬主機(jī)。用 來明確指出請(qǐng)求主機(jī)名。

8. Cookie

  1. 服務(wù)器通過Set-Cookie首部控制cookie,包含NAME=VALUE、expires=DATE、path=PATH、domain=域名、Secure、HttpOnly
  2. 當(dāng)省略expires屬性，其Cookie有效期及限于維持瀏覽器會(huì)話（Session)時(shí)間段內(nèi)。這通常限于瀏覽器應(yīng)用被關(guān)閉之前。
  3. 添加secure屬性用于限制Web頁面僅在Https安全連接時(shí)，才可以發(fā)送Cookie.
  4. HttpOnly屬性使Cookie不能被JavaScript腳本訪問，主要目的為防止跨站腳本攻擊（XSS)對(duì)Cookie信息的竊取。
  5. 一旦Cookie 從服務(wù)器發(fā)送給客戶端，服務(wù)端就不存在可以顯示刪除Cookie的方法，但是可以通過覆蓋已過期Cookie,實(shí)現(xiàn)對(duì)客戶端Cookie實(shí)質(zhì)性刪除操作。

9. HTTP缺點(diǎn)

  • 無狀態(tài)協(xié)議
  • 通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽（竊聽風(fēng)險(xiǎn)）
  • 不驗(yàn)證通信放身份，因此有可能遭遇偽裝（冒充風(fēng)險(xiǎn)）
  • 無法驗(yàn)證報(bào)文完整性，英雌可能已遭篡改。（篡改風(fēng)險(xiǎn)）

10.HTTPS

  • Https是身披SSL外殼的HTTP,并非是應(yīng)用層的一種新協(xié)議，只是Http通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協(xié)議代替而已。通常HTTP直接和TCP通信，當(dāng)時(shí)用SSL時(shí)，則演變成先和SSL通信，再由SSL和TCP通信。
  • 采用SSL 后，HTTP擁有HTTPS的加密、證書和完整性保護(hù)。
  • SSL 時(shí)獨(dú)立于HTTP的協(xié)議，其他應(yīng)用層的協(xié)議均可配合SSL協(xié)議使用
  • HTTPS使用SSL和TLS這兩個(gè)協(xié)議，TLS是以SSL為原型開發(fā)的協(xié)議，有時(shí)統(tǒng)稱SSL。當(dāng)前主流為SSL3.0和TLS1.0
  • HTTPS 采用共享密鑰加密（對(duì)稱密鑰加密）和公開密鑰加密（不對(duì)稱密鑰加密）兩者并用混合加密機(jī)制。交換密鑰環(huán)節(jié)使用公開密鑰加密方式，之后建立通信交換報(bào)文階段則使用共享密鑰加密方式。
  • 公開密碼加密通信存在無法證明公開密鑰就是貨真價(jià)實(shí)的公開密鑰?？墒褂脭?shù)字證書認(rèn)證機(jī)構(gòu)和其他相關(guān)機(jī)構(gòu)頒發(fā)的公開證書。
  • 整個(gè)SSL握手階段都不加密（也沒法加密），都是明文的。建立SSL連接采用對(duì)稱加密報(bào)文。

11. HTTPS 缺點(diǎn)

  • 證書成本
  • 降低訪問速度（多次握手）
  • 改造HTTPS后，之前HTTP 跳轉(zhuǎn)到 HTTPS 的方式增加了用戶訪問耗時(shí)（多數(shù)網(wǎng)站采用302跳轉(zhuǎn)）
  • HTTPS 涉及到的安全算法會(huì)消耗 CPU 資源

12. HTTPs 為啥能安全通信

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密

  • 保證公鑰不必篡改：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的
  • 減少公鑰加密時(shí)間： 非對(duì)稱公鑰只用于SSL 握手階段加密"對(duì)話密鑰"本身，建立SSL連接后，通過對(duì)稱密鑰加密報(bào)文，減少非對(duì)稱密碼加密解密耗時(shí)。
  • SSL/TLS協(xié)議的基本過程：
    • 客戶端向服務(wù)器索要并驗(yàn)證公鑰
    • 雙方協(xié)商對(duì)話密碼
    • 雙方采用對(duì)話密碼進(jìn)行加密通信。

13. HTTPS 通信過程

  1. 客戶端通過發(fā)送CLient Hello 報(bào)文開始SSL 通信，報(bào)文中包含客戶端支持的SSL版本、加密算法、支持壓縮方法、生成隨機(jī)數(shù)。
  2. 服務(wù)器可進(jìn)行SSL通信時(shí)，會(huì)以Server Hello報(bào)文作為應(yīng)答。在報(bào)文中確認(rèn)通信SSL協(xié)議、加密方法 及生成的隨機(jī)數(shù)，稍后用于生成"對(duì)話密鑰"
  3. 之后服務(wù)器發(fā)送Cerficate報(bào)文，報(bào)文包含公開密鑰證書
  4. 最后服務(wù)器發(fā)送Server Hello Done 報(bào)文通知客戶端，最初SSL 握手協(xié)商部分結(jié)束
  5. 客戶端收到證書后，首先驗(yàn)證服務(wù)器證書。如果證書不是可信機(jī)構(gòu)頒布、或者證書中的域名與實(shí)際域名不一致、或者證書已經(jīng)過期，就會(huì)向訪問者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信，客戶端以Client Key Exchange報(bào)文作為回應(yīng)，報(bào)文中包含通信加密中使用的Pre-master secret 隨機(jī)密鑰串。
  6. 客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文。提示服務(wù)，在此報(bào)文之后通信會(huì)采用Pre-master secret 密鑰加密
  7. 客戶端發(fā)送Finished 報(bào)文。報(bào)文包含連接至今全部報(bào)文的全體校驗(yàn)值。這次握手協(xié)商是否能成功，要以服務(wù)器是否能夠正確解密該報(bào)文作為判斷標(biāo)準(zhǔn)
  8. 服務(wù)器同樣發(fā)送Change Cipher Spec 報(bào)文
  9. 服務(wù)器同樣發(fā)送Finished 報(bào)文
  10. SSL 連接建立完成，通信受SSL保護(hù)，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用"會(huì)話密鑰"加密內(nèi)容。

14. 瀏覽器驗(yàn)證證書

  • 瀏覽器讀取服務(wù)器發(fā)送過來的證書，對(duì)證書所有者、有效期等信息進(jìn)行一一校驗(yàn)，看是否過期等
  • 瀏覽器開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)CA，與服務(wù)器發(fā)來的證書中的頒發(fā)者CA比對(duì)，用于校驗(yàn)證書是否為合法機(jī)構(gòu)頒發(fā)
  • 如果找不到，瀏覽器就會(huì)報(bào)錯(cuò)，說明服務(wù)器發(fā)來的證書是不可信任的
  • 如果找到，那么瀏覽器就會(huì)從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰，然后對(duì)服務(wù)器發(fā)來的證書里面的簽名進(jìn)行解密
  • 瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來的證書的hash值，將這個(gè)計(jì)算的hash值與證書中簽名做對(duì)比
  • 對(duì)比結(jié)果一致，則證明服務(wù)器發(fā)來的證書合法，沒有被冒充
  • 此時(shí)瀏覽器就可以讀取證書中的公鑰，用于后續(xù)加密了

15. HTTPS 升級(jí)操作

  • 獲取證書
  • 安裝證書 (證書可以放在/etc/ssl目錄（Linux 系統(tǒng)）)
  • 修改鏈接:因?yàn)榧用芫W(wǎng)頁內(nèi)如果有非加密的資源，瀏覽器是不會(huì)加載那些資源的,需要將http鏈接改成Https鏈接）
  • 301重定向：使用 301 重定向，將 HTTP 協(xié)議的訪問導(dǎo)向 HTTPS 協(xié)議
  • 參考：

16. session 管理及認(rèn)證過程

  • 客戶端將用戶名和密碼等登錄信息放入報(bào)文實(shí)體部分提交給服務(wù)器。
  • 服務(wù)器對(duì)客戶端發(fā)送過來的登錄信息進(jìn)行身份驗(yàn)證，并生成識(shí)別用戶的session ID,將用戶身份信息及認(rèn)證狀態(tài)與Session綁定記錄在服務(wù)端。向客戶端返回響應(yīng)，在首部字段Set-Cookie寫入Session ID
  • 客戶端接受到從服務(wù)器發(fā)來的Session ID后，會(huì)將作為Cookie保存在本地。
  • 客戶端下次向服務(wù)器請(qǐng)求，瀏覽器自動(dòng)發(fā)送Cookie,Session ID 也隨之發(fā)送到服務(wù)器。
  • 服務(wù)器通過驗(yàn)證接收到的Session ID識(shí)別用戶和其認(rèn)證狀態(tài)。

17. HTTP 標(biāo)準(zhǔn)缺點(diǎn)

  • 一條連接上只可發(fā)送一個(gè)請(qǐng)求
  • 請(qǐng)求只能從客戶端開始，客戶端不可以接受除響應(yīng)以外的指令
  • 請(qǐng)求/響應(yīng)首部未經(jīng)壓縮就發(fā)送。首部信息越多延遲越大
  • 發(fā)送冗長(zhǎng)的首部。每次互相發(fā)送相同的首部造成的浪費(fèi)較多。
  • 可任意選擇數(shù)據(jù)壓縮格式。非強(qiáng)制壓縮發(fā)送

18. SPDY

  • SPDY 沒有完全改寫HTTP 協(xié)議，而是在TCP/IP的應(yīng)用于傳輸層之間通過新加的會(huì)話層形式運(yùn)作。同時(shí)，考慮安全性問題，SPDY規(guī)定通信中使用SSL。SPDY 以會(huì)話層的形式加入，控制對(duì)數(shù)據(jù)的流動(dòng)，但還是采用HTTP 建立通信連接。
  • 優(yōu)點(diǎn)：
    • 多路復(fù)用
    • 賦予請(qǐng)求優(yōu)先級(jí)
    • 壓縮HTTP 首部
    • 推送功能
    • 服務(wù)器提示功能

19. Websocket

  • WebSocket通過Http建立連接，然后升級(jí)到WebSocket協(xié)議，之后所有的通信都依靠這個(gè)專門的協(xié)議進(jìn)行。
  • 與HTTP相比，Websocket連接建立后就希望一直保持連接狀態(tài)，減少每次連接開銷，而且Websocket首部信息很小，通信量也減少。

20. 網(wǎng)絡(luò)攻擊

  • 因輸出值轉(zhuǎn)義不完全引發(fā)安全漏洞
    • 跨站腳本攻擊（XSS)
    • SQL注入（SQL injection)
    • OS命令注入攻擊（OS Command Injection)
    • HTTP首部注入攻擊（HTTP Header Injection)
    • 郵件首部注入攻擊（Mail Header Injection)
    • 目錄遍歷攻擊（Directory Traversal)
    • 遠(yuǎn)程文件包含漏洞
  • 設(shè)計(jì)上缺陷導(dǎo)致安全漏洞
    • 強(qiáng)制瀏覽
    • 不正確的錯(cuò)誤消息處理
    • 開放重定向
  • 會(huì)話管理疏忽引發(fā)安全漏洞
    • 會(huì)話劫持（Session Hijack)
    • 會(huì)話固定攻擊
    • 跨站點(diǎn)請(qǐng)求偽造（CSRF)
  • 其他安全漏洞
    • 密碼破解
    • 點(diǎn)擊劫持（Clickjacking)
    • DoS攻擊（Denial of Service attack)
    • 后門程序
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 前面兩篇文章中關(guān)于 HTTP 相關(guān)知識(shí)基本上介紹的差不多了，這篇文章是對(duì) HTTP 協(xié)議的補(bǔ)充，主要介紹以下三點(diǎn)內(nèi)...
    lijiankun24閱讀 1,393評(píng)論 2贊 3
  • 1.1 http的概念及歷史版本 http的概念: 超文本傳輸協(xié)議，當(dāng)年http的出現(xiàn)主要是為了解決文本傳輸?shù)碾y題...
    細(xì)雨菲菲v閱讀 412評(píng)論 0贊 1
  • 4天讀完 一、了解web及網(wǎng)絡(luò)基礎(chǔ) 1.1 三項(xiàng)www構(gòu)建技術(shù)： HTML：超文本標(biāo)記語言 HTTP：文本傳輸協(xié)議...
    一波不是一波閱讀 887評(píng)論 1贊 4
  • 本文是《圖解HTTP》讀書筆記的第二篇，主要包括此書的第六章內(nèi)容，因?yàn)榈诹碌膬?nèi)容較多，而且比較重要，所以單獨(dú)寫為...
    lijiankun24閱讀 1,498評(píng)論 0贊 6
  • 本文是《圖解HTTP》讀書筆記的第一篇，主要包括此書的前五章內(nèi)容，簡(jiǎn)要記錄一下。大概分為以下幾部分： TCP/IP...
    lijiankun24閱讀 1,412評(píng)論 0贊 2

友情鏈接更多精彩內(nèi)容