簡述

斷點續傳：指的是在上傳/下載時，將任務（一個檔案或壓縮包）人為的劃分為幾個部分，每一個部分採用一個執行緒進行上傳/下載，如果碰到網路故障，可以從已經上傳/下載的部分開始繼續上傳/下載未完成的部分，而沒有必要從頭開始上傳/下載。可以節省時間，提高速度。

|

斷點續傳的用途

有時使用者上傳/下載檔案需要歷時數小時，萬一線路中斷，不具備斷點續傳的 HTTP/FTP 伺服器或下載軟體就只能從頭重傳，比較好的 HTTP/FTP 伺服器或下載軟體具有斷點續傳能力，允許使用者從上傳/下載斷線的地方繼續傳送，這樣大大減少了使用者的煩惱。

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

在 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 實現檢測：

[[email protected] ~]# 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[[email protected] ~]#

能夠找到 Content-Range，則表明伺服器支援斷點續傳。有些伺服器還會返回 Accept-Ranges，輸出結果 Accept-Ranges: bytes ，說明伺服器支援按位元組下載。