背景
最近同事在做安卓的斷點續(xù)傳下載，然后遇到了在請求頭添加RANGE參數(shù)設(shè)置時：
.addHeader("RANGE", "bytes=" + downloadLength + "-" + (contentLength-1))
網(wǎng)絡(luò)上找的資料都是設(shè)置contentLength,同時測試后，發(fā)現(xiàn)中間下載無法返回206成功，最終發(fā)現(xiàn)是需要end參數(shù)-1.此處稍微記錄一下，主要了解一下相關(guān)的知識。
HTTP Header里的Range和Content-Range參數(shù)
HTTP1.1 協(xié)議（RFC2616）開始支持獲取文件的部分內(nèi)容，這為并行下載以及斷點續(xù)傳提供了技術(shù)支持。它通過在 Header 里兩個參數(shù)實現(xiàn)的，客戶端發(fā)請求時對應(yīng)的是 Range ，服務(wù)器端響應(yīng)時對應(yīng)的是 Content-Range。
Range
用于請求頭中，指定第一個字節(jié)的位置和最后一個字節(jié)的位置，一般格式：
Range:(unit=first byte pos)-[last byte pos]
Range 頭部的格式有以下幾種情況：
Range: bytes=0-499 表示第 0-499 字節(jié)范圍的內(nèi)容
Range: bytes=500-999 表示第 500-999 字節(jié)范圍的內(nèi)容
Range: bytes=-500 表示最后 500 字節(jié)的內(nèi)容
Range: bytes=500- 表示從第 500 字節(jié)開始到文件結(jié)束部分的內(nèi)容
Range: bytes=0-0,-1 表示第一個和最后一個字節(jié)
Range: bytes=500-600,601-999 同時指定幾個范圍
Content-Range
用于響應(yīng)頭中，在發(fā)出帶 Range 的請求后，服務(wù)器會在 Content-Range 頭部返回當(dāng)前接受的范圍和文件總大小。一般格式：
Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]
例如：
Content-Range: bytes 0-499/22400
0－499 是指當(dāng)前發(fā)送的數(shù)據(jù)的范圍，而 22400 則是文件的總大小。
而在響應(yīng)完成后，返回的響應(yīng)頭內(nèi)容也不同：
HTTP/1.1 200 Ok（不使用斷點續(xù)傳方式）
HTTP/1.1 206 Partial Content（使用斷點續(xù)傳方式）
補充（range參數(shù)、格式）
1、客戶端在發(fā)送range請求，會在請求頭中增加range請求頭
常用格式為： Range: bytes=first-end
first，開始數(shù)據(jù)的索引位置
end，結(jié)束數(shù)據(jù)的索引位置
例如
Range: bytes=0-499 其實就是前500個字符
Range: bytes=2-10 第3個字符(索引位置為2)～第11個字符（索引位置為10）
Range: bytes=0- 如省略第二個參數(shù)，即從索引開始位置，到結(jié)束位置
Range:bytes=-500 如省略地一個參數(shù)，即表示最后500個字符
多個集合模式， Range: bytes=p1-p2,m1-m2 表示多個區(qū)段，用","分割
2、服務(wù)器回應(yīng)格式 Content-Range: bytes first-end/total 以及 Content-Length: len
在Content-Range中：
first，數(shù)據(jù)的開始數(shù)據(jù)的位置索引 (inclusive)
end, 數(shù)據(jù)的結(jié)束位置索引（inclusive)
total, 數(shù)據(jù)的整包大小
在Content-Length中
len: 此次回應(yīng)的數(shù)據(jù)大小， 注意該字段和total并不一定相等，是此次請求回應(yīng)的總大小，其實就是 end-first + 1
3、狀態(tài)碼
在收到Range請求后， 如服務(wù)器支持?jǐn)帱c續(xù)傳，可回應(yīng) 206、否則200； 如果請求的range錯誤，回應(yīng) 416。
增強校驗
在實際場景中，會出現(xiàn)一種情況，即在終端發(fā)起續(xù)傳請求時，URL 對應(yīng)的文件內(nèi)容在服務(wù)器端已經(jīng)發(fā)生變化，此時續(xù)傳的數(shù)據(jù)肯定是錯誤的。如何解決這個問題了？顯然此時需要有一個標(biāo)識文件唯一性的方法。
在 RFC2616 中也有相應(yīng)的定義，比如實現(xiàn) Last-Modified 來標(biāo)識文件的最后修改時間，這樣即可判斷出續(xù)傳文件時是否已經(jīng)發(fā)生過改動。同時 FC2616 中還定義有一個 ETag 的頭，可以使用 ETag 頭來放置文件的唯一標(biāo)識。
Last-Modified
If-Modified-Since，和 Last-Modified 一樣都是用于記錄頁面最后修改時間的 HTTP 頭信息，只是 Last-Modified 是由服務(wù)器往客戶端發(fā)送的 HTTP 頭，而 If-Modified-Since 則是由客戶端往服務(wù)器發(fā)送的頭，可以看到，再次請求本地存在的 cache 頁面時，客戶端會通過 If-Modified-Since 頭將先前服務(wù)器端發(fā)過來的 Last-Modified 最后修改時間戳發(fā)送回去，這是為了讓服務(wù)器端進行驗證，通過這個時間戳判斷客戶端的頁面是否是最新的，如果不是最新的，則返回新的內(nèi)容，如果是最新的，則返回 304 告訴客戶端其本地 cache 的頁面是最新的，于是客戶端就可以直接從本地加載頁面了，這樣在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)就會大大減少，同時也減輕了服務(wù)器的負(fù)擔(dān)。
Etag
Etag（Entity Tags）主要為了解決 Last-Modified 無法解決的一些問題。
一些文件也許會周期性的更改，但是內(nèi)容并不改變（僅改變修改時間），這時候我們并不希望客戶端認(rèn)為這個文件被修改了，而重新 GET。
某些文件修改非常頻繁，例如：在秒以下的時間內(nèi)進行修改（1s 內(nèi)修改了 N 次），If-Modified-Since 能檢查到的粒度是 s 級的，這種修改無法判斷（或者說 UNIX 記錄 MTIME 只能精確到秒）。
某些服務(wù)器不能精確的得到文件的最后修改時間。
為此，HTTP/1.1 引入了 Etag。Etag 僅僅是一個和文件相關(guān)的標(biāo)記，可以是一個版本標(biāo)記，例如：v1.0.0；或者說 “627-4d648041f6b80” 這么一串看起來很神秘的編碼。但是 HTTP/1.1 標(biāo)準(zhǔn)并沒有規(guī)定 Etag 的內(nèi)容是什么或者說要怎么實現(xiàn)，唯一規(guī)定的是 Etag 需要放在 “” 內(nèi)。
If-Range
用于判斷實體是否發(fā)生改變，如果實體未改變，服務(wù)器發(fā)送客戶端丟失的部分，否則發(fā)送整個實體。一般格式：
If-Range: Etag | HTTP-Date
也就是說，If-Range 可以使用 Etag 或者 Last-Modified 返回的值。當(dāng)沒有 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 就會被忽略。如果服務(wù)器不支持 If-Range，那么 Range 也會被忽略。
如果請求報文中的 Etag 與服務(wù)器目標(biāo)內(nèi)容的 Etag 相等，即沒有發(fā)生變化，那么應(yīng)答報文的狀態(tài)碼為 206。如果服務(wù)器目標(biāo)內(nèi)容發(fā)生了變化，那么應(yīng)答報文的狀態(tài)碼為 200。
用于校驗的其他 HTTP 頭信息：If-Match/If-None-Match、If-Modified-Since/If-Unmodified-Since。
工作原理
Etag 由服務(wù)器端生成，客戶端通過 If-Range 條件判斷請求來驗證資源是否修改。請求一個文件的流程如下：
第一次請求：
客戶端發(fā)起 HTTP GET 請求一個文件。
服務(wù)器處理請求，返回文件內(nèi)容以及相應(yīng)的 Header，其中包括 Etag（例如：627-4d648041f6b80）（假設(shè)服務(wù)器支持 Etag 生成并已開啟了 Etag）狀態(tài)碼為 200。
第二次請求（斷點續(xù)傳）：
客戶端發(fā)起 HTTP GET 請求一個文件，同時發(fā)送 If-Range（該頭的內(nèi)容就是第一次請求時服務(wù)器返回的 Etag：627-4d648041f6b80）。
服務(wù)器判斷接收到的 Etag 和計算出來的 Etag 是否匹配，如果匹配，那么響應(yīng)的狀態(tài)碼為 206；否則，狀態(tài)碼為 200。
檢測服務(wù)器是否支持?jǐn)帱c續(xù)傳
CURL 實現(xiàn)檢測：文章來源：http://www.zghlxwxcb.cn/news/detail-495123.html
[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，則表明服務(wù)器支持?jǐn)帱c續(xù)傳。有些服務(wù)器還會返回 Accept-Ranges，輸出結(jié)果 Accept-Ranges: bytes ，說明服務(wù)器支持按字節(jié)下載。文章來源地址http://www.zghlxwxcb.cn/news/detail-495123.html
參考文章
- oss斷點續(xù)傳下載
- http斷點續(xù)傳
- http中的range和content-range
到了這里，關(guān)于斷點續(xù)傳下載引出的http header的range和content-range參數(shù)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
