在現代網絡應用中，我們習以為常的功能，如斷點續傳、多線程下載和在線視頻快進快退，都依賴于 HTTP 協議中的一個強大特性：范圍請求（Range Requests）。這項技術讓客戶端能夠聰明地只請求文件的一部分，而不是一次性獲取整個資源。

1. 為什么我們需要它？

傳統的 HTTP 請求模式效率低下，特別是在處理大型文件時。如果一個 2GB 的下載任務因網絡中斷而失敗，傳統的做法是只能從頭開始重新下載。這不僅耗費用戶的時間，也浪費了服務器的帶寬。

范圍請求的出現，就是為了解決這個痛點。它的核心思想很簡單：客戶端可以告訴服務器，我只需要文件從第 X 個字節到第 Y 個字節的內容。 這極大地提升了數據傳輸的效率和可靠性。

2. 客戶端：如何“提出要求”？

客戶端通過在 HTTP 請求頭中添加一個特殊的字段來實現范圍請求，這個字段就是 Range。它精確地定義了客戶端所需要的字節范圍。

• 請求部分文件：要請求文件從 0 字節到 499 字節的部分，請求頭如下。這是最基礎的范圍請求形式。

  GET /movie.mp4 HTTP/1.1
  Host: movie.com
  Range: bytes=0-499
  

• 從某個位置開始，一直到文件末尾：這是實現“斷點續傳”的關鍵。客戶端檢查已下載的字節數，然后請求從該位置開始繼續下載。

  GET /movie.mp4 HTTP/1.1
  Host: movie.com
  Range: bytes=500-
  

• 請求文件的最后若干字節：省略起始字節，常用于流媒體應用，快速獲取文件末尾的元數據（如視頻總時長）。

  GET /movie.mp4 HTTP/1.1
  Host: movie.com
  Range: bytes=-500
  

• 請求多個不連續的部分：通過逗號分隔，可以一次性請求文件的多個片段。這在多線程下載器中非常常見。

  GET /movie.mp4 HTTP/1.1
  Host: movie.com
  Range: bytes=0-499, 1000-1499
  

---

3. 服務器：如何“回應要求”？

服務器收到包含 Range 的請求后，會根據請求的有效性做出回應。

• 成功響應：206 Partial Content
  這是最常見的成功狀態碼，表示服務器已滿足客戶端的部分內容請求。在 206 響應中，服務器會返回兩個關鍵頭部：Content-Range 和 Content-Length。

  • Content-Length 指示當前響應體中數據的實際字節數。
  • Content-Range 告知客戶端本次響應的字節范圍以及文件的總大小。其格式為 bytes [起始]-[結束]/[總大小]。

  報文示例：

  HTTP/1.1 206 Partial Content
  Content-Type: application/zip
  Content-Length: 500
  Content-Range: bytes 0-499/12345
  

  此報文告訴客戶端，返回了文件總長 12345 字節中的第 0 到 499 字節，共 500 字節。

• 請求無效：416 Range Not Satisfiable
  如果客戶端請求的范圍超出了文件的實際大小，服務器會返回 416 狀態碼。此時，Content-Range 頭部會設置為 */[總大小]，明確告知客戶端請求的范圍無法滿足。

  HTTP/1.1 416 Range Not Satisfiable
  Content-Range: bytes */12345
  

• 不支持范圍請求：200 OK
  如果服務器不支持 Range 請求，它會忽略 Range 頭部，直接返回 200 OK 狀態碼，并發送整個文件。客戶端必須做好相應的處理。

---

4. 高級應用：If-Range 確保數據一致性

在斷點續傳場景中，一個潛在的風險是文件在服務器上可能已經被修改。如果客戶端繼續請求舊文件的剩余部分，并與新文件拼接，將導致數據損壞。為解決這個問題，HTTP 引入了 If-Range 頭部。

• 工作原理：客戶端在發起范圍請求時，會同時附帶 If-Range 頭部，其值通常是上次下載時服務器返回的 Etag（文件唯一標識符）或 Last-Modified 時間。

  • 如果服務器上的文件標識符與 If-Range 值匹配，說明文件未改變，服務器返回 206 并繼續發送數據。
  • 如果標識符不匹配，說明文件已更新，服務器會忽略 Range 請求，返回 200 OK 并發送整個最新的文件，強制客戶端重新下載。

  報文示例：

  GET /large-file.zip HTTP/1.1
  Host: example.com
  Range: bytes=1000-
  If-Range: "abcde-12345"
  

5. 復雜場景：多范圍請求與 multipart/byteranges

當客戶端一次性請求多個不連續的范圍時，服務器會返回一個多部分響應（Multipart Response）。

• Content-Type：響應頭中的 Content-Type 會設置為 multipart/byteranges; boundary=...，其中 boundary 是一個隨機生成的字符串，用于在響應體中分隔不同的文件部分。
• 響應體：每個部分都有獨立的 Content-Type 和 Content-Range 頭部，詳細說明其內容。最后一個分隔符后會加上 -- 后綴，表示響應的結束。

報文示例：

HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
Content-Length: 797--THIS_STRING_SEPARATES
Content-Type: application/zip
Content-Range: bytes 0-499/12345...[前500字節的數據]...
--THIS_STRING_SEPARATES
Content-Type: application/zip
Content-Range: bytes 1000-1499/12345...[第1000到1499字節的數據]...
--THIS_STRING_SEPARATES--

這個復雜的報文結構確保了即使是多段不連續的數據，客戶端也能準確地解析和重組。

通過這些關鍵頭部、狀態碼和報文結構，HTTP 范圍請求實現了高效、可靠的數據分塊傳輸，是現代網絡應用中不可或缺的一項關鍵技術。