HTTP斷點續傳（分塊傳輸）（HTTP頭格式很是清楚）

簡述

斷點續傳：指的是在上傳/下載時，將任務（一個文件或壓縮包）人爲的劃分爲幾個部分，每個部分採用一個線程進行上傳/下載，若是碰到網絡故障，能夠從已經上傳/下載的部分開始繼續上傳/下載未完成的部分，而沒有必要從頭開始上傳/下載。能夠節省時間，提升速度。

 

• 簡述
• 斷點續傳的用途
• Range Content-Range
• 加強校驗
  • Last-Modified
  • Etag
  • If-Range
  • 工做原理
• 檢測服務器是否支持斷點續傳

 

斷點續傳的用途

有時用戶上傳/下載文件須要歷時數小時，萬一線路中斷，不具有斷點續傳的 HTTP/FTP 服務器或下載軟件就只能從頭重傳，比較好的 HTTP/FTP 服務器或下載軟件具備斷點續傳能力，容許用戶從上傳/下載斷線的地方繼續傳送，這樣大大減小了用戶的煩惱。

常見的支持斷點續傳的上傳/下載軟件：QQ 旋風、迅雷、快車、電驢、酷六、土豆、優酷、百度視頻、新浪視頻、騰訊視頻、百度雲等。

在 Linux/Unix 系統下，經常使用支持斷點續傳的 FTP 客戶端軟件是 lftp。

Range & Content-Range

HTTP1.1 協議（RFC2616）開始支持獲取文件的部份內容，這爲並行下載以及斷點續傳提供了技術支持。它經過在 Header 裏兩個參數實現的，客戶端發請求時對應的是 Range ，服務器端響應時對應的是 Content-Range。

Range

用於請求頭中，指定第一個字節的位置和最後一個字節的位置，通常格式：

Range:(unit=first byte pos)-[last byte pos]

Range 頭部的格式有如下幾種狀況：

Range: bytes=0-499 表示第 0-499 字節範圍的內容 
Range: bytes=500-999 表示第 500-999 字節範圍的內容 
Range: bytes=-500 表示最後 500 字節的內容 
Range: bytes=500- 表示從第 500 字節開始到文件結束部分的內容 
Range: bytes=0-0,-1 表示第一個和最後一個字節 
Range: bytes=500-600,601-999 同時指定幾個範圍

Content-Range

用於響應頭中，在發出帶 Range 的請求後，服務器會在 Content-Range 頭部返回當前接受的範圍和文件總大小。通常格式：

Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]

例如：

Content-Range: bytes 0-499/22400

0－499 是指當前發送的數據的範圍，而 22400 則是文件的總大小。

而在響應完成後，返回的響應頭內容也不一樣：

HTTP/1.1 200 Ok（不使用斷點續傳方式） 
HTTP/1.1 206 Partial Content（使用斷點續傳方式）

加強校驗

在實際場景中，會出現一種狀況，即在終端發起續傳請求時，URL 對應的文件內容在服務器端已經發生變化，此時續傳的數據確定是錯誤的。如何解決這個問題了？顯然此時須要有一個標識文件惟一性的方法。

在 RFC2616 中也有相應的定義，好比實現 Last-Modified 來標識文件的最後修改時間，這樣便可判斷出續傳文件時是否已經發生過改動。同時 FC2616 中還定義有一個 ETag 的頭，可使用 ETag 頭來放置文件的惟一標識。

Last-Modified

If-Modified-Since，和 Last-Modified 同樣都是用於記錄頁面最後修改時間的 HTTP 頭信息，只是 Last-Modified 是由服務器往客戶端發送的 HTTP 頭，而 If-Modified-Since 則是由客戶端往服務器發送的頭，能夠看到，再次請求本地存在的 cache 頁面時，客戶端會經過 If-Modified-Since 頭將先前服務器端發過來的 Last-Modified 最後修改時間戳發送回去，這是爲了讓服務器端進行驗證，經過這個時間戳判斷客戶端的頁面是不是最新的，若是不是最新的，則返回新的內容，若是是最新的，則返回 304 告訴客戶端其本地 cache 的頁面是最新的，因而客戶端就能夠直接從本地加載頁面了，這樣在網絡上傳輸的數據就會大大減小，同時也減輕了服務器的負擔。

Etag

Etag（Entity Tags）主要爲了解決 Last-Modified 沒法解決的一些問題。

1. 一些文件也許會週期性的更改，可是內容並不改變（僅改變修改時間），這時候咱們並不但願客戶端認爲這個文件被修改了，而從新 GET。
2. 某些文件修改很是頻繁，例如：在秒如下的時間內進行修改（1s 內修改了 N 次），If-Modified-Since 能檢查到的粒度是 s 級的，這種修改沒法判斷（或者說 UNIX 記錄 MTIME 只能精確到秒）。
3. 某些服務器不能精確的獲得文件的最後修改時間。

爲此，HTTP/1.1 引入了 Etag。Etag 僅僅是一個和文件相關的標記，能夠是一個版本標記，例如：v1.0.0；或者說 「627-4d648041f6b80」 這麼一串看起來很神祕的編碼。可是 HTTP/1.1 標準並無規定 Etag 的內容是什麼或者說要怎麼實現，惟一規定的是 Etag 須要放在 「」 內。

If-Range

用於判斷實體是否發生改變，若是實體未改變，服務器發送客戶端丟失的部分，不然發送整個實體。通常格式：

If-Range: Etag | HTTP-Date

也就是說，If-Range 可使用 Etag 或者 Last-Modified 返回的值。當沒有 ETage 卻有 Last-modified 時，能夠把 Last-modified 做爲 If-Range 字段的值。

例如：

If-Range: 「627-4d648041f6b80」 
If-Range: Fri, 22 Feb 2013 03:45:02 GMT

If-Range 必須與 Range 配套使用。若是請求報文中沒有 Range，那麼 If-Range 就會被忽略。若是服務器不支持 If-Range，那麼 Range 也會被忽略。

若是請求報文中的 Etag 與服務器目標內容的 Etag 相等，即沒有發生變化，那麼應答報文的狀態碼爲 206。若是服務器目標內容發生了變化，那麼應答報文的狀態碼爲 200。

用於校驗的其餘 HTTP 頭信息：If-Match/If-None-Match、If-Modified-Since/If-Unmodified-Since。

工做原理

Etag 由服務器端生成，客戶端經過 If-Range 條件判斷請求來驗證資源是否修改。請求一個文件的流程以下：

第一次請求：

1. 客戶端發起 HTTP GET 請求一個文件。
2. 服務器處理請求，返回文件內容以及相應的 Header，其中包括 Etag（例如：627-4d648041f6b80）（假設服務器支持 Etag 生成並已開啓了 Etag）狀態碼爲 200。

第二次請求（斷點續傳）：

1. 客戶端發起 HTTP GET 請求一個文件，同時發送 If-Range（該頭的內容就是第一次請求時服務器返回的 Etag：627-4d648041f6b80）。
2. 服務器判斷接收到的 Etag 和計算出來的 Etag 是否匹配，若是匹配，那麼響應的狀態碼爲 206；不然，狀態碼爲 200。

檢測服務器是否支持斷點續傳

CURL 實現檢測：

[root@localhost ~]# curl -i --range 0-9 http://www.baidu.com/img/bdlogo.gif HTTP/1.1 206 Partial Content Date: Mon, 21 Nov 2016 05:26:29 GMT Server: Apache P3P: CP=" OTI DSP COR IVA OUR IND COM " Set-Cookie: BAIDUID=0CD0E23B4D4F739954DFEDB92BE6CE03:FG=1; expires=Tue, 21-Nov-17 05:26:29 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1 Last-Modified: Fri, 22 Feb 2013 03:45:02 GMT ETag: "627-4d648041f6b80" Accept-Ranges: bytes Content-Length: 10 Cache-Control: max-age=315360000 Expires: Thu, 19 Nov 2026 05:26:29 GMT Content-Range: bytes 0-9/1575 Connection: Keep-Alive Content-Type: image/gif GIF89a[root@localhost ~]#

可以找到 Content-Range，則代表服務器支持斷點續傳。有些服務器還會返回 Accept-Ranges，輸出結果 Accept-Ranges: bytes ，說明服務器支持按字節下載。

http://blog.csdn.net/liang19890820/article/details/53215087