博主最近在復(fù)習(xí)HTTP，之前用書主要是《計(jì)算機(jī)網(wǎng)絡(luò)》謝希仁版本和上野宣的《圖解HTTP》，最近結(jié)合網(wǎng)上博客，進(jìn)行復(fù)習(xí)和提綱式的總結(jié)。

一. 基礎(chǔ)概念

Web 基礎(chǔ)

HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）。
WWW（World Wide Web）的三種技術(shù)：HTML、HTTP、URL。
RFC（Request for Comments，征求修正意見書），互聯(lián)網(wǎng)的設(shè)計(jì)文檔。

URL

• URI（Uniform Resource Indentifier，統(tǒng)一資源標(biāo)識(shí)符）
• URL（Uniform Resource Locator，統(tǒng)一資源定位符）
• URN（Uniform Resource Name，統(tǒng)一資源名稱），例如 urn:isbn:0-486-27557-4。

URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行，所以見到的基本都是 URL。

[圖片上傳失敗...(image-f4e8a5-1532607046850)]

請(qǐng)求和響應(yīng)報(bào)文

• 請(qǐng)求報(bào)文

請(qǐng)求報(bào)文

• 響應(yīng)報(bào)文

響應(yīng)報(bào)文

二. HTTP 方法

客戶端發(fā)送的 請(qǐng)求報(bào)文 第一行為請(qǐng)求行Request Line，包含了方法字段。

GET

獲取資源

當(dāng)前網(wǎng)絡(luò)請(qǐng)求中，絕大部分使用的是 GET 方法。

HEAD

獲取報(bào)文首部

和 GET 方法一樣，但是不返回報(bào)文實(shí)體主體部分。

主要用于確認(rèn) URL 的有效性以及資源更新的日期時(shí)間等。

POST

傳輸實(shí)體主體

POST 主要目的不是獲取資源，而是傳輸存儲(chǔ)在內(nèi)容實(shí)體中的數(shù)據(jù)。

GET 和 POST對(duì)比

1. 安全性

GET 的傳參方式相比于 POST 安全性較差，因?yàn)?GET 傳的參數(shù)在 URL 中是可見的，可能會(huì)泄露私密信息。

GET 和 POST 的請(qǐng)求都能使用額外的參數(shù)，但是

• GET 的參數(shù)是以查詢字符串出現(xiàn)在 URL 中
• POST 的參數(shù)存儲(chǔ)在內(nèi)容實(shí)體

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

2. 編碼

并且 GET 只支持 ASCII 字符，如果參數(shù)為中文則可能會(huì)出現(xiàn)亂碼，而 POST 支持標(biāo)準(zhǔn)字符集。

3. 服務(wù)器狀態(tài)

安全的 HTTP 方法不會(huì)改變服務(wù)器狀態(tài)，也就是說(shuō)它只是可讀的。

GET 方法是安全的，而 POST 卻不是，因?yàn)?POST 的目的是傳送實(shí)體主體內(nèi)容，這個(gè)內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務(wù)器可能把這個(gè)數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，因此狀態(tài)也就發(fā)生了改變。

安全的方法除了 GET 之外還有：HEAD、OPTIONS。

不安全的方法除了 POST 之外還有： PUT、DELETE。

4. 冪等性

冪等的 HTTP 方法，同樣的請(qǐng)求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的。換句話說(shuō)就是，冪等方法不應(yīng)該具有副作用（統(tǒng)計(jì)用途除外）。
在正確實(shí)現(xiàn)的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。所有的安全方法也都是冪等的。

5. 可緩存

如果要對(duì)響應(yīng)進(jìn)行緩存，需要滿足以下條件：

• 請(qǐng)求報(bào)文的 HTTP 方法本身是可緩存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可緩存，POST 在多數(shù)情況下不可緩存的
• 響應(yīng)報(bào)文的狀態(tài)碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
• 響應(yīng)報(bào)文的 Cache-Control 首部字段沒(méi)有指定不進(jìn)行緩存。

6. 響應(yīng)過(guò)程

GET ：
瀏覽器會(huì)把 HTTP Header 和 Data一并發(fā)送出去，服務(wù)器響應(yīng) 200（OK）并返回?cái)?shù)據(jù)。
POST ：
瀏覽器先發(fā)送 Header，服務(wù)器響應(yīng) 100（Continue）之后，瀏覽器再發(fā)送Data，最后服務(wù)器響應(yīng) 200（OK）并返回?cái)?shù)據(jù)。

PUT

上傳文件

由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問(wèn)題，一般不使用該方法。

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>

PATCH

對(duì)資源進(jìn)行部分修改

PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]

DELETE

刪除文件

與 PUT 功能相反，并且同樣不帶驗(yàn)證機(jī)制。

DELETE /file.html HTTP/1.1

OPTIONS

查詢支持的方法

查詢指定的 URL 能夠支持的方法。

會(huì)返回 Allow: GET, POST, HEAD, OPTIONS 這樣的內(nèi)容。

CONNECT

要求在與代理服務(wù)器通信時(shí)建立隧道

使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

CONNECT www.example.com:443 HTTP/1.1

CONNECT

TRACE

追蹤路徑

服務(wù)器會(huì)將通信路徑返回給客戶端。

發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過(guò)一個(gè)服務(wù)器就會(huì)減 1，當(dāng)數(shù)值為 0 時(shí)就停止傳輸。

通常不會(huì)使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。

三. HTTP 狀態(tài)碼

服務(wù)器返回的 響應(yīng)報(bào)文 中第一行為狀態(tài)行Status Line，包含了狀態(tài)碼以及原因短語(yǔ)，用來(lái)告知客戶端請(qǐng)求的結(jié)果。

1XX 信息

2XX 成功

3XX 重定向

注：雖然 HTTP 協(xié)議規(guī)定 301、302 狀態(tài)下重定向時(shí)不允許把 POST 方法改成 GET 方法，但是大多數(shù)瀏覽器都會(huì)在 301、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法。

4XX 客戶端錯(cuò)誤

5XX 服務(wù)器錯(cuò)誤

四. HTTP 首部

有 4 種類型的首部字段：通用首部字段、請(qǐng)求首部字段、響應(yīng)首部字段和實(shí)體首部字段。

各種首部字段及其含義如下（不需要全記，僅供查閱）：

通用首部字段

請(qǐng)求首部字段

響應(yīng)首部字段

實(shí)體首部字段

五. 具體應(yīng)用

Cookie

HTTP 協(xié)議是無(wú)狀態(tài)的，主要是為了讓 HTTP 協(xié)議盡可能簡(jiǎn)單，使得它能夠處理大量事務(wù)。HTTP/1.1 引入 Cookie 來(lái)保存狀態(tài)信息。

Cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)被攜帶并發(fā)送到服務(wù)器上。它用于告知服務(wù)端兩個(gè)請(qǐng)求是否來(lái)自同一瀏覽器，并保持用戶的登錄狀態(tài)。

1. Cookie用途

• 會(huì)話狀態(tài)管理（如用戶登錄狀態(tài)、購(gòu)物車、游戲分?jǐn)?shù)或其它需要記錄的信息）
• 個(gè)性化設(shè)置（如用戶自定義設(shè)置、主題等）
• 瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

Cookie 曾一度用于客戶端數(shù)據(jù)的存儲(chǔ)，因?yàn)楫?dāng)時(shí)并沒(méi)有其它合適的存儲(chǔ)辦法而作為唯一的存儲(chǔ)手段，但現(xiàn)在隨著現(xiàn)代瀏覽器開始支持各種各樣的存儲(chǔ)方式，Cookie 漸漸被淘汰。
由于服務(wù)器指定 Cookie 后，瀏覽器的每次請(qǐng)求都會(huì)攜帶 Cookie 數(shù)據(jù)，會(huì)帶來(lái)額外的性能開銷（尤其是在移動(dòng)環(huán)境下）。新的瀏覽器 API 已經(jīng)允許開發(fā)者直接將數(shù)據(jù)存儲(chǔ)到本地，如使用 Web storage API （本地存儲(chǔ)和會(huì)話存儲(chǔ)）或 IndexedDB。

2. Cookie創(chuàng)建過(guò)程

服務(wù)器發(fā)送的響應(yīng)報(bào)文包含 Set-Cookie 首部字段，客戶端得到響應(yīng)報(bào)文后把 Cookie 內(nèi)容保存到瀏覽器中。

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

客戶端之后對(duì)同一個(gè)服務(wù)器發(fā)送請(qǐng)求時(shí)，會(huì)從瀏覽器中讀出 Cookie 信息通過(guò) Cookie 請(qǐng)求首部字段發(fā)送給服務(wù)器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Set-Cookie

3. Cookie分類

• 會(huì)話期 Cookie：瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除，也就是說(shuō)它僅在會(huì)話期內(nèi)有效。
• 持久性 Cookie：指定一個(gè)特定的過(guò)期時(shí)間（Expires）或有效期（max-age）之后就成為了持久性的 Cookie。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

4. JavaScript 獲取 Cookie

通過(guò) Document.cookie 屬性可創(chuàng)建新的 Cookie，也可通過(guò)該屬性訪問(wèn)非 HttpOnly 標(biāo)記的 Cookie。

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);

5. Secure 和 HttpOnly

標(biāo)記為Secure的 Cookie 只應(yīng)通過(guò)被 HTTPS協(xié)議加密過(guò)的請(qǐng)求發(fā)送給服務(wù)端。但即便設(shè)置了 Secure 標(biāo)記，敏感信息也不應(yīng)該通過(guò) Cookie 傳輸，因?yàn)?Cookie 有其固有的不安全性，Secure 標(biāo)記也無(wú)法提供確實(shí)的安全保障。

標(biāo)記為HttpOnly 的 Cookie 不能被JavaScript 腳本調(diào)用。因?yàn)榭缬蚰_本 (XSS) 攻擊常常使用 JavaScript 的 Document.cookieAPI 竊取用戶的 Cookie 信息，因此使用 HttpOnly 標(biāo)記可以在一定程度上避免 XSS 攻擊。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

6. Cookie作用域

Domain標(biāo)識(shí)指定了哪些主機(jī)可以接受 Cookie。如果不指定，默認(rèn)為當(dāng)前文檔的主機(jī)（不包含子域名）。如果指定了 Domain，則一般包含子域名。例如，如果設(shè)置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如 developer.mozilla.org）。

Path標(biāo)識(shí)指定了主機(jī)下的哪些路徑可以接受 Cookie（該 URL 路徑必須存在于請(qǐng)求 URL 中）。以字符 %x2F ("/") 作為路徑分隔符，子路徑也會(huì)被匹配。

例如，設(shè)置 Path=/docs，則以下地址都會(huì)匹配：/docs、/docs/Web/、/docs/Web/HTTP

7. Session

除了可以將用戶信息通過(guò) Cookie 存儲(chǔ)在用戶瀏覽器中，也可以利用 Session 存儲(chǔ)在服務(wù)器端，存儲(chǔ)在服務(wù)器端的信息更加安全。

Session 可以存儲(chǔ)在服務(wù)器上的文件、數(shù)據(jù)庫(kù)或者內(nèi)存中，現(xiàn)在最常見的是將 Session 存儲(chǔ)在內(nèi)存型數(shù)據(jù)庫(kù)中，比如 Redis。

使用 Session 維護(hù)用戶登錄的過(guò)程

1. 用戶提交
   用戶進(jìn)行登錄時(shí)，用戶提交包含用戶名和密碼的表單，放入 HTTP 請(qǐng)求報(bào)文中
2. 服務(wù)器驗(yàn)證
   服務(wù)器驗(yàn)證該用戶名和密碼
3. 用戶信息存儲(chǔ)
   如果正確則把用戶信息存儲(chǔ)到 Redis 中，它在 Redis 中的 ID 稱為 Session ID
4. 服務(wù)器下發(fā)Cookie到客戶端
   服務(wù)器返回的響應(yīng)報(bào)文的 Set-Cookie 首部字段包含了這個(gè) Session ID，客戶端收到響應(yīng)報(bào)文之后將該 Cookie 值存入瀏覽器中
5. 下次請(qǐng)求直接驗(yàn)證 Session ID
   客戶端之后對(duì)同一個(gè)服務(wù)器進(jìn)行請(qǐng)求時(shí)會(huì)包含該 Cookie 值，服務(wù)器收到之后提取出 Session ID，從 Redis 中取出用戶信息，繼續(xù)之后的業(yè)務(wù)操作

應(yīng)該注意 Session ID 的安全性問(wèn)題，不能讓它被惡意攻擊者輕易獲取，那么就不能產(chǎn)生一個(gè)容易被猜到的 Session ID 值。此外，還需要經(jīng)常重新生成 Session ID。在對(duì)安全性要求極高的場(chǎng)景下，例如轉(zhuǎn)賬等操作，除了使用 Session 管理用戶狀態(tài)之外，還需要對(duì)用戶進(jìn)行重新驗(yàn)證，比如重新輸入密碼，或者使用短信驗(yàn)證碼等方式。

8. 瀏覽器禁用 Cookie

此時(shí)

• 無(wú)法使用 Cookie 來(lái)保存用戶信息，只能使用 Session
• 除此之外，不能再將 Session ID 存放到 Cookie 中，而是使用 URL 重寫技術(shù)，將 Session ID 作為 URL 的參數(shù)進(jìn)行傳遞sid=xxx 。

9. Cookie 與 Session 選擇

• Cookie 只能存儲(chǔ) ASCII 碼字符串，而 Session 則可以存取任何類型的數(shù)據(jù)，因此在考慮數(shù)據(jù)復(fù)雜性時(shí)首選 Session
• Cookie 存儲(chǔ)在瀏覽器中，容易被惡意查看。如果非要將一些隱私數(shù)據(jù)存在 Cookie 中，可以將 Cookie 值進(jìn)行加密，然后在服務(wù)器進(jìn)行解密
• 對(duì)于大型網(wǎng)站，如果用戶所有的信息都存儲(chǔ)在 Session 中，那么開銷是非常大的，因此不建議將所有的用戶信息都存儲(chǔ)到 Session 中

緩存

1. 緩存優(yōu)點(diǎn)

• 緩解服務(wù)器壓力
• 降低客戶端獲取資源的延遲（緩存資源比服務(wù)器上的資源離客戶端更近）。

2. 緩存實(shí)現(xiàn)方法

• 讓代理服務(wù)器進(jìn)行緩存
• 讓客戶端瀏覽器進(jìn)行緩存

3. 控制緩存---Cache-Control

HTTP/1.1 通過(guò) Cache-Control 首部字段來(lái)控制緩存

Cache-Control: 指令

連接管理

短連接與長(zhǎng)連接

短連接與長(zhǎng)連接

當(dāng)瀏覽器訪問(wèn)一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)，除了請(qǐng)求訪問(wèn) HTML 頁(yè)面資源，還會(huì)請(qǐng)求圖片資源，如果每進(jìn)行一次 HTTP 通信就要斷開一次 TCP 連接，連接建立和斷開的開銷會(huì)很大。長(zhǎng)連接只需要建立一次 TCP 連接就能進(jìn)行多次 HTTP 通信。

從 HTTP/1.1 開始默認(rèn)是長(zhǎng)連接的，如果要斷開連接，需要由客戶端或者服務(wù)器端提出斷開，使用 Connection : close；而在 HTTP/1.1 之前默認(rèn)是短連接的，如果需要長(zhǎng)連接，則使用Connection : Keep-Alive

流水線

默認(rèn)情況下，HTTP 請(qǐng)求是按順序發(fā)出的，下一個(gè)請(qǐng)求只有在當(dāng)前請(qǐng)求收到應(yīng)答過(guò)后才會(huì)被發(fā)出。由于會(huì)受到網(wǎng)絡(luò)延遲和帶寬的限制，在下一個(gè)請(qǐng)求被發(fā)送到服務(wù)器之前，可能需要等待很長(zhǎng)時(shí)間。

管線化方式 可以同時(shí)發(fā)送多個(gè)請(qǐng)求和響應(yīng)，而不需要發(fā)送一個(gè)請(qǐng)求然后等待響應(yīng)之后再發(fā)下一個(gè)請(qǐng)求。

內(nèi)容協(xié)商

通過(guò)內(nèi)容協(xié)商返回最合適的內(nèi)容，例如根據(jù)瀏覽器的默認(rèn)語(yǔ)言選擇返回中文界面還是英文界面。

1. 內(nèi)容協(xié)商類型

（一）服務(wù)端驅(qū)動(dòng)型內(nèi)容協(xié)商

客戶端設(shè)置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Languag，服務(wù)器根據(jù)這些字段返回特定的資源。

它存在以下問(wèn)題：

• 服務(wù)器很難知道客戶端瀏覽器的全部信息；
  -客戶端提供的信息相當(dāng)冗長(zhǎng)（HTTP/2 協(xié)議的首部壓縮機(jī)制緩解了這個(gè)問(wèn)題），并且存在隱私風(fēng)險(xiǎn)（HTTP 指紋識(shí)別技術(shù)）。
• 給定的資源需要返回不同的展現(xiàn)形式，共享緩存的效率會(huì)降低，而服務(wù)器端的實(shí)現(xiàn)會(huì)越來(lái)越復(fù)雜。

（二）代理驅(qū)動(dòng)型協(xié)商

服務(wù)器返回 300 Multiple Choices 或者 406 Not Acceptable，客戶端從中選出最合適的那個(gè)資源。

2. Vary

Vary: Accept-Language

在使用內(nèi)容協(xié)商的情況下，只有當(dāng)緩存服務(wù)器中的緩存滿足內(nèi)容協(xié)商條件時(shí)，才能使用該緩存，否則應(yīng)該向源服務(wù)器請(qǐng)求該資源。

例如，一個(gè)客戶端發(fā)送了一個(gè)包含 Accept-Language 首部字段的請(qǐng)求之后，源服務(wù)器返回的響應(yīng)包含 Vary: Accept-Language內(nèi)容，緩存服務(wù)器對(duì)這個(gè)響應(yīng)進(jìn)行緩存之后，在客戶端下一次訪問(wèn)同一個(gè) URL 資源，并且 Accept-Language 與緩存中的對(duì)應(yīng)的值相同時(shí)才會(huì)返回該緩存。

內(nèi)容編碼

內(nèi)容編碼將實(shí)體主體進(jìn)行壓縮，從而減少傳輸?shù)臄?shù)據(jù)量。常用的內(nèi)容編碼有：gzip、compress、deflate、identity。

瀏覽器發(fā)送 Accept-Encoding 首部，其中包含有它所支持的壓縮算法，以及各自的優(yōu)先級(jí)，服務(wù)器則從中選擇一種，使用該算法對(duì)響應(yīng)的消息主體進(jìn)行壓縮，并且發(fā)送 Content-Encoding 首部來(lái)告知瀏覽器它選擇了哪一種算法。由于該內(nèi)容協(xié)商過(guò)程是基于編碼類型來(lái)選擇資源的展現(xiàn)形式的，在響應(yīng)中，Vary 首部中至少要包含 Content-Encoding，這樣的話，緩存服務(wù)器就可以對(duì)資源的不同展現(xiàn)形式進(jìn)行緩存。

范圍請(qǐng)求

如果網(wǎng)絡(luò)出現(xiàn)中斷，服務(wù)器只發(fā)送了一部分?jǐn)?shù)據(jù)，范圍請(qǐng)求可以使得客戶端只請(qǐng)求服務(wù)器未發(fā)送的那部分?jǐn)?shù)據(jù)，從而避免服務(wù)器重新發(fā)送所有數(shù)據(jù)。

1.指定請(qǐng)求的范圍---Range

在請(qǐng)求報(bào)文中添加 Range 首部字段指定請(qǐng)求的范圍。

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023

請(qǐng)求成功的話服務(wù)器返回的響應(yīng)206 Partial Content 狀態(tài)碼。

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
...
(binary content)

2. 指定處理的范圍---Accept-Ranges

響應(yīng)首部字段 Accept-Ranges 用于告知客戶端是否能處理范圍請(qǐng)求，可以處理使用 bytes，否則使用 none。

Accept-Ranges: bytes

3. 響應(yīng)狀態(tài)碼

• 在請(qǐng)求成功的情況下，服務(wù)器會(huì)返回 206 Partial Content 狀態(tài)碼。
• 在請(qǐng)求的范圍越界的情況下，服務(wù)器會(huì)返回 416 Requested Range Not Satisfiable 狀態(tài)碼。
• 在不支持范圍請(qǐng)求的情況下，服務(wù)器會(huì)返回 200 OK 狀態(tài)碼。

分塊傳輸編碼

Chunked Transfer Coding，可以把數(shù)據(jù)分割成多塊，讓瀏覽器逐步顯示頁(yè)面。

多部分對(duì)象集合

一份報(bào)文主體內(nèi)可含有多種類型的實(shí)體同時(shí)發(fā)送，每個(gè)部分之間用 boundary 字段定義的分隔符進(jìn)行分隔，每個(gè)部分都可以有首部字段。

例如，上傳多個(gè)表單時(shí)可以使用如下方式：

Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

虛擬主機(jī)

HTTP/1.1 使用虛擬主機(jī)技術(shù)，使得一臺(tái)服務(wù)器擁有多個(gè)域名，并且在邏輯上可以看成多個(gè)服務(wù)器。

通信數(shù)據(jù)轉(zhuǎn)發(fā)

1. 代理

代理服務(wù)器接受客戶端的請(qǐng)求，并且轉(zhuǎn)發(fā)給其它服務(wù)器。

使用代理的主要目的是：

• 緩存
• 負(fù)載均衡
• 網(wǎng)絡(luò)訪問(wèn)控制
• 訪問(wèn)日志記錄

代理服務(wù)器分為正向代理和反向代理兩種，用戶察覺(jué)得到正向代理的存在，而反向代理一般位于內(nèi)部網(wǎng)絡(luò)中，用戶察覺(jué)不到。

正向代理

[圖片上傳失敗...(image-9dbbff-1532607046850)]

2. 網(wǎng)關(guān)

與代理服務(wù)器不同的是，網(wǎng)關(guān)服務(wù)器會(huì)將 HTTP 轉(zhuǎn)化為其它協(xié)議進(jìn)行通信，從而請(qǐng)求其它非 HTTP 服務(wù)器的服務(wù)。

3. 隧道

使用SSL 等加密手段，為客戶端和服務(wù)器之間建立一條安全的通信線路。

六. HTTPs

HTTP 有以下安全性問(wèn)題：

• 使用明文進(jìn)行通信，內(nèi)容可能會(huì)被竊聽
• 不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝
• 無(wú)法證明報(bào)文的完整性，報(bào)文有可能遭篡改

HTTPs 并不是新協(xié)議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信。也就是說(shuō) HTTPs 使用了隧道進(jìn)行通信。

通過(guò)使用 SSL，HTTPs 具有了加密（防竊聽）、認(rèn)證（防偽裝）和完整性保護(hù)（防篡改）。

HTTPs

加密

1. 對(duì)稱密鑰加密

對(duì)稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。

• 優(yōu)點(diǎn)：運(yùn)算速度快；
• 缺點(diǎn)：無(wú)法安全地將密鑰傳輸給通信方。

對(duì)稱密鑰加密

2. 非對(duì)稱密鑰加密

非對(duì)稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不同的密鑰。

公開密鑰所有人都可以獲得，通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進(jìn)行加密，接收方收到通信內(nèi)容后使用私有密鑰解密。

非對(duì)稱密鑰除了用來(lái)加密，還可以用來(lái)進(jìn)行簽名。因?yàn)樗接忻荑€無(wú)法被其他人獲取，因此通信發(fā)送方使用其私有密鑰進(jìn)行簽名，通信接收方使用發(fā)送方的公開密鑰對(duì)簽名進(jìn)行解密，就能判斷這個(gè)簽名是否正確。

• 優(yōu)點(diǎn)：可以更安全地將公開密鑰傳輸給通信發(fā)送方
• 缺點(diǎn)：運(yùn)算速度慢

非對(duì)稱密鑰加密

3. HTTPs 采用的加密方式

HTTPs 采用混合的加密機(jī)制，使用非對(duì)稱密鑰加密用于傳輸對(duì)稱密鑰來(lái)保證安全性，之后使用對(duì)稱密鑰加密進(jìn)行通信來(lái)保證效率。（下圖中的 Session Key 就是對(duì)稱密鑰）

關(guān)鍵是用公鑰對(duì) Session Key 進(jìn)行加密，傳輸加密之后的內(nèi)容，接收后再用私鑰解密。

HTTPs

認(rèn)證

通過(guò)使用 證書 來(lái)對(duì)通信方進(jìn)行認(rèn)證。

數(shù)字證書認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)。

服務(wù)器的運(yùn)營(yíng)人員向 CA 提出公開密鑰的申請(qǐng)，CA 在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開密鑰，并將該公開密鑰放入公開密鑰證書后綁定在一起。

進(jìn)行 HTTPs 通信時(shí)，服務(wù)器會(huì)把證書發(fā)送給客戶端。客戶端取得其中的公開密鑰之后，先使用數(shù)字簽名進(jìn)行驗(yàn)證，如果驗(yàn)證通過(guò)，就可以開始通信了。

通信開始時(shí)，客戶端需要使用服務(wù)器的公開密鑰將自己的私有密鑰傳輸給服務(wù)器，之后再進(jìn)行對(duì)稱密鑰加密。

完整性保護(hù)

SSL 提供報(bào)文摘要功能來(lái)進(jìn)行完整性保護(hù)。

HTTP 也提供了 MD5 報(bào)文摘要功能，但不是安全的。例如報(bào)文內(nèi)容被篡改之后，同時(shí)重新計(jì)算 MD5 的值，通信接收方是無(wú)法意識(shí)到發(fā)生了篡改。

HTTPs 的報(bào)文摘要功能之所以安全，是因?yàn)樗Y(jié)合了加密和認(rèn)證這兩個(gè)操作。試想一下，加密之后的報(bào)文，遭到篡改之后，也很難重新計(jì)算報(bào)文摘要，因?yàn)闊o(wú)法輕易獲取明文。

HTTPs 的缺點(diǎn)

• 因?yàn)樾枰M(jìn)行加密解密等過(guò)程，因此速度會(huì)更慢
• 需要支付證書授權(quán)的高費(fèi)用

七. Web 攻擊技術(shù)

攻擊模式

主動(dòng)攻擊

直接攻擊服務(wù)器
具有代表性的有

• SQL 注入
• OS 命令注入。

被動(dòng)攻擊

設(shè)下圈套，讓用戶發(fā)送有攻擊代碼的 HTTP 請(qǐng)求，那么用戶發(fā)送了該 HTTP 請(qǐng)求之后就會(huì)泄露 Cookie 等個(gè)人信息
具有代表性的有

• 跨站腳本攻擊(XSS)
• 跨站請(qǐng)求偽造(CSRF)

跨站腳本攻擊---XSS

1. 概念

跨站腳本攻擊（Cross-Site Scripting, XSS），可以將代碼注入到用戶瀏覽的網(wǎng)頁(yè)上，這種代碼包括 HTML 和 JavaScript。

例如有一個(gè)論壇網(wǎng)站，攻擊者可以在上面發(fā)布以下內(nèi)容：

<script>location. + document.cookie</script>

之后該內(nèi)容可能會(huì)被渲染成以下形式：

<p><script>location. + document.cookie</script></p>

另一個(gè)用戶瀏覽了含有這個(gè)內(nèi)容的頁(yè)面將會(huì)跳轉(zhuǎn)到 domain.com 并攜帶了當(dāng)前作用域的 Cookie。如果這個(gè)論壇網(wǎng)站通過(guò) Cookie 管理用戶登錄狀態(tài)，那么攻擊者就可以通過(guò)這個(gè) Cookie 登錄被攻擊者的賬號(hào)了。

2. 危害

• 竊取用戶的 Cookie 值
• 偽造虛假的輸入表單騙取個(gè)人信息
• 顯示偽造的文章或者圖片

3. 防范手段

（一）設(shè)置 Cookie 為 HttpOnly

設(shè)置了 HttpOnly 的 Cookie 可以防止 JavaScript 腳本調(diào)用，就無(wú)法通過(guò) document.cookie 獲取用戶 Cookie 信息。

（二）過(guò)濾特殊字符

例如將 < 轉(zhuǎn)義為 <，將 > 轉(zhuǎn)義為 >，從而避免 HTML 和 Jascript 代碼的運(yùn)行。

許多語(yǔ)言都提供了對(duì) HTML 的過(guò)濾：

PHP 的 htmlentities() 或是 htmlspecialchars()
Python 的 cgi.escape()
Java 的 xssprotect (Open Source Library)
Node.js 的 node-validator

跨站請(qǐng)求偽造---CSRF

1. 概念

跨站請(qǐng)求偽造（Cross-site request forgery，CSRF），是攻擊者通過(guò)一些技術(shù)手段欺騙用戶的瀏覽器去訪問(wèn)一個(gè)自己曾經(jīng)認(rèn)證過(guò)的網(wǎng)站并執(zhí)行一些操作（如發(fā)郵件，發(fā)消息，甚至財(cái)產(chǎn)操作如轉(zhuǎn)賬和購(gòu)買商品）。

由于瀏覽器曾經(jīng)認(rèn)證過(guò)，所以被訪問(wèn)的網(wǎng)站會(huì)認(rèn)為是真正的用戶操作而去執(zhí)行。這利用了 Web 中用戶身份驗(yàn)證的一個(gè)漏洞：簡(jiǎn)單的身份驗(yàn)證只能保證請(qǐng)求發(fā)自某個(gè)用戶的瀏覽器，卻不能保證請(qǐng)求本身是用戶自愿發(fā)出的。

XSS 利用的是用戶對(duì)指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對(duì)用戶瀏覽器的信任。

假如一家銀行用以執(zhí)行轉(zhuǎn)賬操作的 URL 地址如下：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName。

那么，一個(gè)惡意攻擊者可以在另一個(gè)網(wǎng)站上放置如下代碼：

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">。

如果有賬戶名為 Alice 的用戶訪問(wèn)了惡意站點(diǎn)，而她之前剛訪問(wèn)過(guò)銀行不久，登錄信息尚未過(guò)期，那么她就會(huì)損失 1000 資金。

這種惡意的網(wǎng)址可以有很多種形式，藏身于網(wǎng)頁(yè)中的許多地方。此外，攻擊者也不需要控制放置惡意網(wǎng)址的網(wǎng)站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內(nèi)容的網(wǎng)站中。這意味著如果服務(wù)器端沒(méi)有合適的防御措施的話，用戶即使訪問(wèn)熟悉的可信網(wǎng)站也有受攻擊的危險(xiǎn)。

透過(guò)例子能夠看出，攻擊者并不能通過(guò) CSRF 攻擊來(lái)直接獲取用戶的賬戶控制權(quán)，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義執(zhí)行操作。

2. 防范手段

（一）檢查 Referer 首部字段

Referer 首部字段位于 HTTP 報(bào)文中，用于標(biāo)識(shí)請(qǐng)求來(lái)源的地址。檢查這個(gè)首部字段并要求請(qǐng)求來(lái)源的地址在同一個(gè)域名下，可以極大的防止 XSRF 攻擊。

這種辦法簡(jiǎn)單易行，工作量低，僅需要在關(guān)鍵訪問(wèn)處增加一步校驗(yàn)。但這種辦法也有其局限性，因其完全依賴瀏覽器發(fā)送正確的 Referer 字段。雖然 HTTP 協(xié)議對(duì)此字段的內(nèi)容有明確的規(guī)定，但并無(wú)法保證來(lái)訪的瀏覽器的具體實(shí)現(xiàn)，亦無(wú)法保證瀏覽器沒(méi)有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器，篡改其 Referer 字段的可能。

（二）添加校驗(yàn) Token

在訪問(wèn)敏感數(shù)據(jù)請(qǐng)求時(shí)，要求用戶瀏覽器提供不保存在 Cookie 中，并且攻擊者無(wú)法偽造的數(shù)據(jù)作為校驗(yàn)。例如服務(wù)器生成隨機(jī)數(shù)并附加在表單中，并要求客戶端傳回這個(gè)隨機(jī)數(shù)。

（三）輸入驗(yàn)證碼

因?yàn)?strong>CSRF 攻擊是在用戶無(wú)意識(shí)的情況下發(fā)生的，所以要求用戶輸入驗(yàn)證碼可以讓用戶知道自己正在做的操作。

也可以要求用戶輸入驗(yàn)證碼來(lái)進(jìn)行校驗(yàn)。

SQL 注入攻擊

1. 概念

服務(wù)器上的數(shù)據(jù)庫(kù)運(yùn)行非法的 SQL 語(yǔ)句，主要通過(guò)拼接來(lái)完成。

2. 攻擊原理

例如一個(gè)網(wǎng)站登錄驗(yàn)證的 SQL 查詢代碼為：

strSQL = "SELECT * FROM users WHERE 
(name = '" + userName + "') AND (pw = '"+ passWord +"');"

如果填入以下內(nèi)容：

userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";

那么 SQL 查詢字符串為：

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"

此時(shí)無(wú)需驗(yàn)證通過(guò)就能執(zhí)行以下查詢：

strSQL = "SELECT * FROM users;"

3. 防范手段

（一）使用參數(shù)化查詢

以下以 Java 中的 PreparedStatement為例，它是預(yù)先編譯的 SQL 語(yǔ)句，可以傳入適當(dāng)參數(shù)并且多次執(zhí)行。由于沒(méi)有拼接的過(guò)程，因此可以防止 SQL 注入的發(fā)生。

PreparedStatement stmt = connection.prepareStatement(
          "SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

（二）單引號(hào)轉(zhuǎn)換

將傳入的參數(shù)中的單引號(hào)轉(zhuǎn)換為連續(xù)兩個(gè)單引號(hào)，PHP 中的 Magic quote 可以完成這個(gè)功能。

拒絕服務(wù)攻擊---DoS

拒絕服務(wù)攻擊（denial-of-service attack，DoS），亦稱洪水攻擊，其目的在于使目標(biāo)電腦的網(wǎng)絡(luò)或系統(tǒng)資源耗盡，使服務(wù)暫時(shí)中斷或停止，導(dǎo)致其正常用戶無(wú)法訪問(wèn)。

分布式拒絕服務(wù)攻擊（distributed denial-of-service attack，DDoS），指攻擊者使用網(wǎng)絡(luò)上兩個(gè)或以上被攻陷的電腦作為“僵尸”向特定的目標(biāo)發(fā)動(dòng)“拒絕服務(wù)”式攻擊。

八. 各版本比較

HTTP/1.0 與 HTTP/1.1 的區(qū)別

HTTP/1.1 新增了以下內(nèi)容：

• 默認(rèn)為長(zhǎng)連接
• 提供了范圍請(qǐng)求功能
• 提供了虛擬主機(jī)的功能
• 多了一些緩存處理字段
• 多了一些狀態(tài)碼

HTTP/1.1 與 HTTP/2.0 的區(qū)別

1. 多路復(fù)用

HTTP/2.0 使用多路復(fù)用技術(shù)，使用同一個(gè) TCP 連接來(lái)處理多個(gè)請(qǐng)求。

2. 首部壓縮

HTTP/1.1 的首部帶有大量信息，而且每次都要重復(fù)發(fā)送。HTTP/2.0 要求通訊雙方各自緩存一份首部字段表，從而避免了重復(fù)傳輸。

3. 服務(wù)端推送

在客戶端請(qǐng)求一個(gè)資源時(shí)，會(huì)把相關(guān)的資源一起發(fā)送給客戶端，客戶端就不需要再次發(fā)起請(qǐng)求了。例如客戶端請(qǐng)求 index.html 頁(yè)面，服務(wù)端就把 index.js 一起發(fā)給客戶端。

4. 二進(jìn)制格式

HTTP/1.1 的解析是基于文本的，而 HTTP/2.0 采用二進(jìn)制格式。

參考資料
上野宣. 圖解 HTTP[M]. 人民郵電出版社, 2014.
復(fù)習(xí)圖解 HTTP
復(fù)習(xí)HTTP