今天在使用URLSessionDownloadTask實現(xiàn)斷點續(xù)傳功能時發(fā)現(xiàn)在暫停時始終拿不到resumeData數(shù)據(jù)，導(dǎo)致無法實現(xiàn)斷點續(xù)傳。
使用cancel方法data始終為nil
task?.cancel(byProducingResumeData: { (data) in
})
從頭檢查了很多遍，沒有任何問題，最后通過查閱官方文檔，終于發(fā)現(xiàn)了問題所在。
文檔中準(zhǔn)確描述了response的header中需要包括ETag or Last-Modified，我們后臺提供的下載鏈接的header中并沒有包含這兩個字段，加上后斷點續(xù)傳就成功了。
為什么需要加入這兩個字段呢？
Last-Modified
客戶端在第一次請求某個URL成功后，服務(wù)器返回的response中會包含Last-Modified，用來表示服務(wù)器資源最后一次被修改的時間，格式如下
Last-Modified: Wed, 23 Mar 2022 16:35:58 GMT
當(dāng)?shù)诙卧L問這個URL后，客戶端會在header中傳入If-Modified-Since，用來詢問服務(wù)器這個時間之后是否有過修改，格式如下
If-Modified-Since: Wed, 23 Mar 2022 16:35:58 GMT
如果沒有修改，則服務(wù)器會返回304，告訴客戶端沒有修改，則客戶端可以使用緩存數(shù)據(jù)，如果有修改，則服務(wù)器會返回新的數(shù)據(jù)。
ETag
ETag在HTTP 協(xié)議規(guī)格的定義為“被請求變量的實體值”。ETag表示資源標(biāo)識是否有變更，而Last-Modified更傾向于時間狀態(tài)。
ETag:"623b4c6e-1+8e4947"
ETag一般是文件內(nèi)容的hash值生成的，當(dāng)文件內(nèi)容發(fā)生變化，ETag也會發(fā)生變化，由于Last-Modified最小時間是秒，所以可能在數(shù)據(jù)變化很快的情況下，Last-Modified會有不準(zhǔn)確的缺點。這是使用ETag就要比Last-Modified用更加準(zhǔn)確。（事實上，很多時候會將這兩個一起使用）
和Last-Modified相似，在第一次請求拿到ETag后，客戶端會在第二次訪問服務(wù)器時在header中傳入If-None-Match將ETag返回給服務(wù)器，如果相等，服務(wù)器也會返回304，不相等則返回新的數(shù)據(jù)。
