1. 從一次失敗的下載說起為什么我們需要分片那天下午我正在從公司內(nèi)網(wǎng)服務(wù)器拉取一個將近10GB的虛擬機(jī)鏡像文件。進(jìn)度條緩慢地爬到了78%網(wǎng)絡(luò)突然閃斷了一下。等我重新連接發(fā)現(xiàn)下載工具彈出了一個冰冷的提示“網(wǎng)絡(luò)錯誤下載失敗”。更讓人崩潰的是它沒有提供任何恢復(fù)選項(xiàng)我只能眼睜睜看著那78%已下載的數(shù)據(jù)被清空一切從頭開始。這個場景我相信很多開發(fā)者都遇到過。無論是下載大型安裝包、媒體文件還是處理數(shù)據(jù)備份傳統(tǒng)的單線程、從頭到尾的HTTP下載方式在文件體積增大和網(wǎng)絡(luò)環(huán)境不穩(wěn)定的雙重夾擊下顯得異常脆弱。它就像用一根吸管去喝一大桶水一旦中途松口水就灑了得重新開始。而“HTTP文件分片下載”就是解決這個痛點(diǎn)的標(biāo)準(zhǔn)方案。它的核心思想非常直觀把一個大文件切成多個小塊分片然后同時開多個“吸管”連接去喝并且記錄下每根吸管喝到了哪里。這樣即使某根吸管斷了網(wǎng)絡(luò)波動或者整個喝水過程暫停了我們也能知道哪些部分已經(jīng)喝完了下次可以從斷掉的地方接著喝而不是把整桶水倒掉重來。這背后依賴的是HTTP/1.1協(xié)議中一個非常經(jīng)典但強(qiáng)大的頭部字段Range。服務(wù)器通過響應(yīng)頭Accept-Ranges: bytes來宣告“我支持按字節(jié)范圍獲取數(shù)據(jù)”?？蛻舳藙t可以通過請求頭Range: bytes0-1023來精確指定“我只要文件開頭的1024個字節(jié)”。當(dāng)服務(wù)器成功處理了這個請求它會返回狀態(tài)碼206 Partial Content部分內(nèi)容并在響應(yīng)頭中通過Content-Range: bytes 0-1023/10240來告知“這是你要的0到1023字節(jié)文件總大小是10240字節(jié)”。所以我們今天要聊的遠(yuǎn)不止是調(diào)用一個庫的API。我會帶你從協(xié)議原理開始親手實(shí)現(xiàn)一個支持分片與斷點(diǎn)續(xù)傳的下載器并深入那些真正決定項(xiàng)目成敗的細(xì)節(jié)如何優(yōu)雅地處理網(wǎng)絡(luò)異常如何管理分片狀態(tài)以及如何避開那些教科書上不會寫的“坑”。2. 協(xié)議基石深入理解HTTP Range請求與響應(yīng)在動手寫代碼之前我們必須把Range和Content-Range這兩個頭部的玩法徹底吃透。很多實(shí)現(xiàn)上的Bug根源都在于對協(xié)議細(xì)節(jié)的一知半解。2.1 Range請求的語法與語義Range頭部的格式是固定的Range: bytesstart-end。這里的start和end都是基于0的字節(jié)偏移量并且end是包含在內(nèi)的。這一點(diǎn)非常重要因?yàn)楹芏嗑幊陶Z言中的切片slice操作是左閉右開的但HTTP Range是閉區(qū)間。Range: bytes0-499獲取第1個到第500個字節(jié)共500字節(jié)。Range: bytes500-999獲取第501個到第1000個字節(jié)。Range: bytes-500獲取最后500個字節(jié)。這是一種特殊語法start被省略意為從文件末尾向前推500字節(jié)開始。Range: bytes500-獲取從第501個字節(jié)開始到文件結(jié)束的所有內(nèi)容。end被省略。一個請求中甚至可以指定多個不連續(xù)的范圍例如Range: bytes0-99, 200-299但這種情況相對少見而且服務(wù)器不一定支持響應(yīng)會是206但主體部分是multipart/byteranges類型處理起來更復(fù)雜。在我們的分片下載場景中通常是一個分片對應(yīng)一個單一的Range請求。2.2 服務(wù)器的響應(yīng)206、416與200客戶端發(fā)出Range請求后服務(wù)器的響應(yīng)決定了后續(xù)流程。206 Partial Content (成功)這是最理想的響應(yīng)。意味著服務(wù)器理解并成功處理了Range請求。響應(yīng)中必須包含Content-Range頭部格式為Content-Range: bytes start-end/total或Content-Range: bytes start-end/*如果服務(wù)器不知道總大小。同時響應(yīng)體就是請求的字節(jié)范圍。注意即使請求的范圍超出了文件大小例如文件只有1000字節(jié)但請求bytes900-1999合規(guī)的服務(wù)器也應(yīng)返回206但Content-Range中的end會是999文件末尾實(shí)際返回的數(shù)據(jù)量會小于請求的范圍。416 Range Not Satisfiable (范圍無效)這是我們需要重點(diǎn)處理的錯誤。當(dāng)請求的Range頭字段中的所有范圍都無效時服務(wù)器返回此狀態(tài)。最常見的原因是start大于等于文件長度。例如文件大小為1000字節(jié)請求Range: bytes1000-或bytes1500-就會觸發(fā)416。根因分析在我們分片下載的場景下遇到416通常意味著我們記錄的分片起始位置信息存儲在本地與服務(wù)器上的文件實(shí)際狀態(tài)不一致?？赡艿脑蛴形募诜?wù)器端已被修改或替換例如版本更新長度發(fā)生了變化。本地狀態(tài)文件損壞記錄了錯誤的位置。在多線程環(huán)境下狀態(tài)管理出現(xiàn)競態(tài)條件導(dǎo)致某個分片被重復(fù)請求了超出范圍的部分。解決方案一個健壯的下載器不能一遇到416就報(bào)錯退出。正確的做法是立即停止當(dāng)前分片的下載?？蛇x嘗試重新獲取一次文件的完整信息如通過一個HEAD請求獲取Content-Length和ETag。根據(jù)新的文件信息重置該分片的起始位置為當(dāng)前已知的文件末尾或0并更新本地狀態(tài)記錄。這相當(dāng)于承認(rèn)之前記錄的狀態(tài)已失效從安全的位置重新開始下載該分片。200 OK (完全內(nèi)容)如果服務(wù)器不支持Range請求即響應(yīng)中沒有Accept-Ranges: bytes或者直接忽略Range頭它會直接返回整個文件狀態(tài)碼為200。對于我們的下載器這需要作為一個降級方案來處理既然無法分片就只能單線程下載整個文件且無法實(shí)現(xiàn)斷點(diǎn)續(xù)傳。在實(shí)現(xiàn)時應(yīng)該檢測到200響應(yīng)后給出明確提示。2.3 關(guān)鍵輔助頭部Content-Length, ETag Last-Modified要實(shí)現(xiàn)可靠的斷點(diǎn)續(xù)傳僅靠Range是不夠的。Content-Length文件總大小。通過初始的HEAD請求獲取用于計(jì)算分片策略和總進(jìn)度。ETag文件的實(shí)體標(biāo)簽通常是文件內(nèi)容的哈希值或版本標(biāo)識符。這是實(shí)現(xiàn)可靠斷點(diǎn)續(xù)傳的黃金標(biāo)準(zhǔn)。在發(fā)起一系列Range請求之前先獲取文件的ETag并保存。每次恢復(fù)下載時先發(fā)一個HEAD請求獲取最新的ETag與本地保存的對比。如果不一致說明服務(wù)器文件已變更必須提示用戶或重新開始整個下載任務(wù)。這能有效避免“416”或下載到錯誤版本的文件。Last-Modified文件最后修改時間?？梢宰鳛镋Tag的備用方案?；謴?fù)下載時檢查此時間戳是否變化。但它的精度不如ETag因?yàn)榧词刮募?nèi)容沒變只是移動了位置修改時間也可能更新。一個健壯的下載器在開始下載前應(yīng)該執(zhí)行這樣一個“握手”流程發(fā)送HEAD請求到目標(biāo)URL。檢查Accept-Ranges是否為bytes確認(rèn)支持分片。記錄Content-Length、ETag優(yōu)先和Last-Modified。將這些元數(shù)據(jù)與本地已下載的部分如果有的元數(shù)據(jù)進(jìn)行比較決定是繼續(xù)、重啟還是報(bào)錯。3. 核心架構(gòu)設(shè)計(jì)一個健壯的分片下載器如何組成理解了協(xié)議我們就可以設(shè)計(jì)下載器的骨架了。一個工業(yè)級的分片下載器絕不是簡單開幾個線程去拉數(shù)據(jù)那么簡單。它需要精心設(shè)計(jì)的狀態(tài)管理和錯誤處理機(jī)制。3.1 分片策略與狀態(tài)管理首先我們需要決定如何把文件“切”開。常見的策略有固定大小分片每個分片大小相同如1MB或5MB。計(jì)算簡單易于管理。分片數(shù) ceil(文件總大小 / 分片大小)。動態(tài)分片根據(jù)網(wǎng)絡(luò)狀況或服務(wù)器負(fù)載動態(tài)調(diào)整分片大小。更復(fù)雜但可能更高效。對于大多數(shù)場景固定大小分片足夠用了。關(guān)鍵在于我們必須為每一個分片維護(hù)一個獨(dú)立的狀態(tài)。這個狀態(tài)至少包括index: 分片序號。start: 分片起始字節(jié)。end: 分片結(jié)束字節(jié)。downloaded: 該分片已下載的字節(jié)數(shù)用于斷點(diǎn)續(xù)傳。status: 狀態(tài)pending,downloading,completed,error。這些狀態(tài)需要持久化到磁盤比如一個JSON文件或小型數(shù)據(jù)庫。這樣當(dāng)程序崩潰或主動退出后重新啟動時能讀取狀態(tài)知道每個分片下載到哪了從而實(shí)現(xiàn)真正的“斷點(diǎn)續(xù)傳”。3.2 多線程/協(xié)程的調(diào)度與并發(fā)控制分片下載天然適合并發(fā)。我們可以為每個分片或每批分片分配一個獨(dú)立的線程或協(xié)程在Python中asyncioaiohttp是絕佳選擇去下載。這里有幾個關(guān)鍵控制點(diǎn)并發(fā)數(shù)限制不要無限制地創(chuàng)建連接。通常根據(jù)網(wǎng)絡(luò)環(huán)境和目標(biāo)服務(wù)器承受能力設(shè)置一個并發(fā)上限如5-10個。這可以通過線程池/信號量來實(shí)現(xiàn)。任務(wù)隊(duì)列將所有狀態(tài)為pending的分片放入一個隊(duì)列。工作線程/協(xié)程從隊(duì)列中獲取任務(wù)執(zhí)行。流量與進(jìn)度聚合每個工作單元下載時需要定期如每下載64KB更新其分片的downloaded狀態(tài)并通知一個全局的進(jìn)度管理器以計(jì)算和顯示整體下載速度與進(jìn)度。這里要注意線程安全對共享狀態(tài)如全局已下載字節(jié)數(shù)的更新需要加鎖或使用原子操作。3.3 錯誤處理與重試機(jī)制網(wǎng)絡(luò)請求充滿不確定性。我們必須為每個分片下載任務(wù)設(shè)計(jì)健壯的重試邏輯。可重試的錯誤連接超時、讀取超時、TCP連接重置、HTTP 5xx服務(wù)器錯誤、429 Too Many Requests等。對于這些錯誤應(yīng)該進(jìn)行指數(shù)退避重試?yán)绲谝淮蔚却?秒第二次2秒第三次4秒。不可重試/需特殊處理的錯誤HTTP 416范圍無效需重置分片狀態(tài)、403/404資源問題應(yīng)停止整個任務(wù)、ETag不匹配文件已變更需用戶決策。分片級重試 vs 任務(wù)級重試一個分片下載失敗只重試該分片不影響其他分片。只有當(dāng)遇到全局性錯誤如文件不存在時才終止整個下載任務(wù)。4. 手把手實(shí)現(xiàn)用Python構(gòu)建分片下載器理論說再多不如一行代碼。我們使用Python的asyncio和aiohttp庫來實(shí)現(xiàn)因?yàn)樗鼈兡茌p松處理高并發(fā)I/O操作非常適合這種網(wǎng)絡(luò)密集型任務(wù)。4.1 項(xiàng)目結(jié)構(gòu)與核心類設(shè)計(jì)chunk_downloader/ ├── downloader.py # 主下載器類 ├── chunk.py # 分片狀態(tài)類 ├── progress.py # 進(jìn)度條顯示類 ├── utils.py # 工具函數(shù)保存狀態(tài)、計(jì)算哈希等 └── main.py # 程序入口我們先定義分片狀態(tài)類chunk.pyimport json from dataclasses import dataclass, asdict, field from enum import Enum from typing import Optional class ChunkStatus(Enum): PENDING pending DOWNLOADING downloading COMPLETED completed ERROR error dataclass class DownloadChunk: 代表一個下載分片及其狀態(tài) index: int start: int end: int downloaded: int 0 status: ChunkStatus ChunkStatus.PENDING # 用于恢復(fù)下載時記錄臨時文件的路徑 temp_file_path: Optional[str] None property def total_size(self) - int: return self.end - self.start 1 property def remaining(self) - int: return self.total_size - self.downloaded def to_dict(self): return asdict(self) classmethod def from_dict(cls, data): data[status] ChunkStatus(data[status]) return cls(**data)接下來是主下載器類的核心骨架downloader.pyimport aiohttp import asyncio import os import hashlib from pathlib import Path from typing import List, Optional, Dict import logging from .chunk import DownloadChunk, ChunkStatus logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class ChunkDownloader: def __init__(self, url: str, output_path: str, chunk_size: int 1024*1024, max_concurrent: int 5): self.url url self.output_path Path(output_path) self.chunk_size chunk_size self.max_concurrent max_concurrent self.chunks: List[DownloadChunk] [] self.total_size 0 self.etag: Optional[str] None self.last_modified: Optional[str] None self.support_range False self.state_file self.output_path.with_suffix(.json.state) self.temp_dir self.output_path.parent / f{self.output_path.name}.tmp self.temp_dir.mkdir(exist_okTrue) async def _fetch_metadata(self): 發(fā)送HEAD請求獲取文件元數(shù)據(jù) async with aiohttp.ClientSession() as session: async with session.head(self.url) as resp: if resp.status ! 200: raise Exception(fFailed to fetch metadata: HTTP {resp.status}) self.support_range resp.headers.get(Accept-Ranges) bytes self.total_size int(resp.headers.get(Content-Length, 0)) self.etag resp.headers.get(ETag) self.last_modified resp.headers.get(Last-Modified) logger.info(fFile size: {self.total_size}, Supports Range: {self.support_range}, ETag: {self.etag}) def _initialize_chunks(self): 根據(jù)文件大小和分片大小初始化分片列表 if not self.support_range or self.total_size 0: # 不支持分片或空文件創(chuàng)建一個覆蓋整個文件的分片 self.chunks [DownloadChunk(index0, start0, endself.total_size-1 if self.total_size0 else 0)] return num_chunks (self.total_size self.chunk_size - 1) // self.chunk_size self.chunks [] for i in range(num_chunks): start i * self.chunk_size end min(start self.chunk_size - 1, self.total_size - 1) chunk DownloadChunk(indexi, startstart, endend) # 為每個分片分配一個臨時文件 chunk.temp_file_path str(self.temp_dir / fchunk_{i:06d}.part) self.chunks.append(chunk) logger.info(fInitialized {len(self.chunks)} chunks.) async def download(self): 主下載流程 # 1. 獲取元數(shù)據(jù) await self._fetch_metadata() # 2. 嘗試加載之前保存的狀態(tài) if not self._load_state(): # 3. 如果無狀態(tài)則初始化分片 self._initialize_chunks() # 4. 啟動并發(fā)下載 await self._download_chunks_concurrently() # 5. 合并分片文件 await self._merge_chunks() # 6. 清理臨時文件 self._cleanup() async def _download_chunks_concurrently(self): 使用信號量控制并發(fā)度下載所有分片 semaphore asyncio.Semaphore(self.max_concurrent) async with aiohttp.ClientSession() as session: tasks [] for chunk in self.chunks: if chunk.status ! ChunkStatus.COMPLETED: task asyncio.create_task(self._download_single_chunk(session, chunk, semaphore)) tasks.append(task) await asyncio.gather(*tasks, return_exceptionsTrue) async def _download_single_chunk(self, session: aiohttp.ClientSession, chunk: DownloadChunk, semaphore: asyncio.Semaphore): 下載單個分片支持?jǐn)帱c(diǎn)續(xù)傳 async with semaphore: # 如果分片已部分下載則從斷點(diǎn)開始 range_start chunk.start chunk.downloaded range_end chunk.end headers {Range: fbytes{range_start}-{range_end}} retry_count 0 max_retries 3 while retry_count max_retries: try: async with session.get(self.url, headersheaders, timeoutaiohttp.ClientTimeout(total30)) as resp: if resp.status 206: # Partial Content # 以追加模式打開臨時文件 mode ab if chunk.downloaded 0 else wb async with aiohttp.StreamReader() as stream: async for data in resp.content.iter_chunked(8192): # 這里需要將數(shù)據(jù)寫入臨時文件并更新chunk.downloaded # 同時更新全局進(jìn)度略需線程安全操作 pass chunk.status ChunkStatus.COMPLETED self._save_state() # 定期保存狀態(tài) logger.info(fChunk {chunk.index} completed.) break # 成功跳出重試循環(huán) elif resp.status 416: # Range Not Satisfiable logger.warning(fChunk {chunk.index} requested invalid range ({range_start}-{range_end}). Resetting.) # 處理416重置該分片下載進(jìn)度 chunk.downloaded 0 self._save_state() # 重新開始下載這個分片這里簡化處理實(shí)際可能需要重新計(jì)算范圍 continue else: logger.error(fUnexpected status {resp.status} for chunk {chunk.index}) chunk.status ChunkStatus.ERROR break except (aiohttp.ClientError, asyncio.TimeoutError) as e: retry_count 1 logger.warning(fChunk {chunk.index} failed (attempt {retry_count}/{max_retries}): {e}) if retry_count max_retries: chunk.status ChunkStatus.ERROR else: await asyncio.sleep(2 ** retry_count) # 指數(shù)退避 if chunk.status ChunkStatus.ERROR: logger.error(fChunk {chunk.index} failed after {max_retries} retries.) def _load_state(self) - bool: 從磁盤加載下載狀態(tài) # 實(shí)現(xiàn)略讀取state_file恢復(fù)self.chunks, self.etag等 pass def _save_state(self): 保存下載狀態(tài)到磁盤 # 實(shí)現(xiàn)略將self.chunks等狀態(tài)序列化到state_file pass async def _merge_chunks(self): 將所有分片臨時文件合并成最終文件 # 實(shí)現(xiàn)略按chunk.index順序讀取所有.part文件寫入output_path pass def _cleanup(self): 清理臨時文件和狀態(tài)文件 # 實(shí)現(xiàn)略 pass以上代碼勾勒出了下載器的核心框架。_download_single_chunk方法包含了關(guān)鍵的重試邏輯和對206、416狀態(tài)碼的處理。_load_state和_save_state是實(shí)現(xiàn)斷點(diǎn)續(xù)傳的關(guān)鍵需要將分片列表、ETag等信息序列化到JSON文件中。4.2 進(jìn)度顯示與用戶體驗(yàn)一個沒有進(jìn)度提示的下載器是難以忍受的。我們可以使用tqdm庫來創(chuàng)建美觀的進(jìn)度條。在progress.py中我們可以設(shè)計(jì)一個類來聚合所有分片的下載進(jìn)度并實(shí)時顯示。from tqdm.asyncio import tqdm import asyncio class DownloadProgress: def __init__(self, total_size: int, descDownloading): self.pbar tqdm(totaltotal_size, unitB, unit_scaleTrue, descdesc, ncols100) self._lock asyncio.Lock() self._current 0 async def update(self, size: int): 線程安全地更新進(jìn)度 async with self._lock: self._current size self.pbar.update(size) def close(self): self.pbar.close()然后在下載器類中注入進(jìn)度條實(shí)例在每個分片下載到數(shù)據(jù)塊時調(diào)用progress.update(len(data))。5. 進(jìn)階議題與實(shí)戰(zhàn)避坑指南把基礎(chǔ)功能跑通只是第一步。在實(shí)際生產(chǎn)環(huán)境中你會遇到更多棘手的問題。5.1 服務(wù)器兼容性與降級策略不是所有服務(wù)器都規(guī)規(guī)矩矩地遵守HTTP/1.1協(xié)議。你需要處理各種“奇葩”情況聲稱支持Range但行為異常有些服務(wù)器返回Accept-Ranges: bytes但你發(fā)送Range請求后它依然返回整個文件狀態(tài)碼200。我們的代碼需要檢測這種情況如果請求了范圍但返回的Content-Length遠(yuǎn)大于請求的范圍大小或者狀態(tài)碼是200就應(yīng)該觸發(fā)降級回退到單線程全量下載并警告用戶。Content-Range格式不標(biāo)準(zhǔn)極少數(shù)服務(wù)器返回的Content-Range可能缺少總大小如bytes 0-499/*。這時我們無法計(jì)算總進(jìn)度進(jìn)度條會不準(zhǔn)確但下載可以繼續(xù)。連接數(shù)限制與429狀態(tài)碼過于激進(jìn)的并發(fā)可能導(dǎo)致服務(wù)器返回429 Too Many Requests。一個良好的下載器應(yīng)該能捕獲這個狀態(tài)碼并動態(tài)降低并發(fā)數(shù)或者進(jìn)入一段時間的休眠。5.2 大文件合并與內(nèi)存管理當(dāng)分片下載完成后我們需要將數(shù)百甚至數(shù)千個臨時文件合并成一個。最樸素的做法是打開最終文件然后循環(huán)打開每個分片文件讀取其全部內(nèi)容并寫入。這對于超大文件是災(zāi)難性的可能會耗盡內(nèi)存。正確的做法是使用流式合并def merge_chunks_safely(chunk_files, output_path, chunk_size1024*1024): with open(output_path, wb) as outfile: for chunk_file in sorted(chunk_files): # 確保按順序合并 with open(chunk_file, rb) as infile: while True: data infile.read(chunk_size) # 分塊讀取避免一次性加載 if not data: break outfile.write(data)這樣無論分片文件多大內(nèi)存占用都保持在chunk_size級別。5.3 完整性校驗(yàn)不可或缺的最后一步下載完成就萬事大吉了嗎不網(wǎng)絡(luò)傳輸可能引入靜默錯誤盡管TCP有校驗(yàn)和但應(yīng)用層仍需把關(guān)。特別是對于分片下載合并過程也可能出錯。因此下載完成后必須進(jìn)行完整性校驗(yàn)。如果服務(wù)器提供了ETag通常是MD5或SHA哈希在下載完成后計(jì)算本地文件的哈希值與之前保存的ETag進(jìn)行比較。這是最可靠的方法。如果服務(wù)器沒有提供ETag可以計(jì)算本地文件的MD5或SHA256哈希如果可能的話與官方源提供的哈希值進(jìn)行比對。很多開源軟件發(fā)布時會附帶sha256sum.txt文件。分片級校驗(yàn)可選但推薦在每個分片下載完成后立即計(jì)算該分片的哈希并保存。在合并前再次校驗(yàn)每個分片。這可以快速定位是哪個分片在傳輸或存儲中損壞只需重新下載該分片而不必重下整個文件。5.4 那些我踩過的“坑”臨時文件清理不徹底程序異常退出時臨時目錄.tmp和狀態(tài)文件.json.state可能殘留。下次啟動時如果直接加載舊狀態(tài)而源文件已更新會導(dǎo)致混亂。最佳實(shí)踐在加載舊狀態(tài)前檢查臨時文件是否完整存在并與狀態(tài)記錄匹配。不匹配則視為無效狀態(tài)重新初始化下載。進(jìn)度保存過于頻繁每下載一小塊數(shù)據(jù)就保存一次狀態(tài)到磁盤I/O壓力巨大影響下載速度。解決方案設(shè)置一個閾值例如每下載完成1MB數(shù)據(jù)或每隔5秒才批量保存一次狀態(tài)。也可以使用WALWrite-Ahead Logging思想先寫日志再異步更新主狀態(tài)文件。默認(rèn)User-Agent被屏蔽一些服務(wù)器會屏蔽aiohttp或Python的默認(rèn)User-Agent。在創(chuàng)建ClientSession時最好設(shè)置一個常見的瀏覽器User-Agent字符串。SSL證書驗(yàn)證問題在訪問一些自簽名HTTPS站點(diǎn)時可能會遇到證書錯誤。對于不可信的公開站點(diǎn)不要輕易禁用SSL驗(yàn)證connectoraiohttp.TCPConnector(sslFalse)這有安全風(fēng)險(xiǎn)。對于內(nèi)部可信環(huán)境可以傳入自定義的SSL上下文。永遠(yuǎn)不要在生產(chǎn)代碼中全局禁用SSL驗(yàn)證。分片大小選擇不當(dāng)分片太小如10KB會導(dǎo)致請求頭開銷占比過高且創(chuàng)建大量臨時文件降低效率。分片太大如100MB則斷點(diǎn)續(xù)傳的粒度太粗網(wǎng)絡(luò)中斷時浪費(fèi)的已下載數(shù)據(jù)更多。經(jīng)過多次測試對于大多數(shù)公網(wǎng)下載1MB到10MB是一個比較均衡的范圍。你可以根據(jù)首次連接的延遲和帶寬動態(tài)估算一個初始值。實(shí)現(xiàn)一個健壯、高效、用戶友好的HTTP分片下載器是一個將網(wǎng)絡(luò)協(xié)議、并發(fā)編程、狀態(tài)管理和錯誤處理融會貫通的絕佳練習(xí)。它沒有用到多么高深的算法但對工程細(xì)節(jié)的考量決定了它是“玩具”還是“工具”。希望這篇長文能幫你避開我當(dāng)年踩過的那些坑當(dāng)你下次需要傳輸一個大文件時可以自信地寫出屬于自己的下載解決方案。