1. 從一次失敗的下載說(shuō)起為什么我們需要分片那天下午我正在從公司內(nèi)網(wǎng)服務(wù)器拉取一個(gè)將近10GB的虛擬機(jī)鏡像文件。進(jìn)度條緩慢地爬到了78%網(wǎng)絡(luò)突然閃斷了一下。等我重新連接發(fā)現(xiàn)下載工具彈出了一個(gè)冰冷的提示“網(wǎng)絡(luò)錯(cuò)誤下載失敗”。更讓人崩潰的是它沒(méi)有提供任何恢復(fù)選項(xiàng)我只能眼睜睜看著那78%已下載的數(shù)據(jù)被清空一切從頭開(kāi)始。這個(gè)場(chǎng)景我相信很多開(kāi)發(fā)者都遇到過(guò)。無(wú)論是下載大型安裝包、媒體文件還是處理數(shù)據(jù)備份傳統(tǒng)的單線程、從頭到尾的HTTP下載方式在文件體積增大和網(wǎng)絡(luò)環(huán)境不穩(wěn)定的雙重夾擊下顯得異常脆弱。它就像用一根吸管去喝一大桶水一旦中途松口水就灑了得重新開(kāi)始。而“HTTP文件分片下載”就是解決這個(gè)痛點(diǎn)的標(biāo)準(zhǔn)方案。它的核心思想非常直觀把一個(gè)大文件切成多個(gè)小塊分片然后同時(shí)開(kāi)多個(gè)“吸管”連接去喝并且記錄下每根吸管喝到了哪里。這樣即使某根吸管斷了網(wǎng)絡(luò)波動(dòng)或者整個(gè)喝水過(guò)程暫停了我們也能知道哪些部分已經(jīng)喝完了下次可以從斷掉的地方接著喝而不是把整桶水倒掉重來(lái)。這背后依賴的是HTTP/1.1協(xié)議中一個(gè)非常經(jīng)典但強(qiáng)大的頭部字段Range。服務(wù)器通過(guò)響應(yīng)頭Accept-Ranges: bytes來(lái)宣告“我支持按字節(jié)范圍獲取數(shù)據(jù)”。客戶端則可以通過(guò)請(qǐng)求頭Range: bytes0-1023來(lái)精確指定“我只要文件開(kāi)頭的1024個(gè)字節(jié)”。當(dāng)服務(wù)器成功處理了這個(gè)請(qǐng)求它會(huì)返回狀態(tài)碼206 Partial Content部分內(nèi)容并在響應(yīng)頭中通過(guò)Content-Range: bytes 0-1023/10240來(lái)告知“這是你要的0到1023字節(jié)文件總大小是10240字節(jié)”。所以我們今天要聊的遠(yuǎn)不止是調(diào)用一個(gè)庫(kù)的API。我會(huì)帶你從協(xié)議原理開(kāi)始親手實(shí)現(xiàn)一個(gè)支持分片與斷點(diǎn)續(xù)傳的下載器并深入那些真正決定項(xiàng)目成敗的細(xì)節(jié)如何優(yōu)雅地處理網(wǎng)絡(luò)異常如何管理分片狀態(tài)以及如何避開(kāi)那些教科書(shū)上不會(huì)寫(xiě)的“坑”。2. 協(xié)議基石深入理解HTTP Range請(qǐng)求與響應(yīng)在動(dòng)手寫(xiě)代碼之前我們必須把Range和Content-Range這兩個(gè)頭部的玩法徹底吃透。很多實(shí)現(xiàn)上的Bug根源都在于對(duì)協(xié)議細(xì)節(jié)的一知半解。2.1 Range請(qǐng)求的語(yǔ)法與語(yǔ)義Range頭部的格式是固定的Range: bytesstart-end。這里的start和end都是基于0的字節(jié)偏移量并且end是包含在內(nèi)的。這一點(diǎn)非常重要因?yàn)楹芏嗑幊陶Z(yǔ)言中的切片slice操作是左閉右開(kāi)的但HTTP Range是閉區(qū)間。Range: bytes0-499獲取第1個(gè)到第500個(gè)字節(jié)共500字節(jié)。Range: bytes500-999獲取第501個(gè)到第1000個(gè)字節(jié)。Range: bytes-500獲取最后500個(gè)字節(jié)。這是一種特殊語(yǔ)法start被省略意為從文件末尾向前推500字節(jié)開(kāi)始。Range: bytes500-獲取從第501個(gè)字節(jié)開(kāi)始到文件結(jié)束的所有內(nèi)容。end被省略。一個(gè)請(qǐng)求中甚至可以指定多個(gè)不連續(xù)的范圍例如Range: bytes0-99, 200-299但這種情況相對(duì)少見(jiàn)而且服務(wù)器不一定支持響應(yīng)會(huì)是206但主體部分是multipart/byteranges類型處理起來(lái)更復(fù)雜。在我們的分片下載場(chǎng)景中通常是一個(gè)分片對(duì)應(yīng)一個(gè)單一的Range請(qǐng)求。2.2 服務(wù)器的響應(yīng)206、416與200客戶端發(fā)出Range請(qǐng)求后服務(wù)器的響應(yīng)決定了后續(xù)流程。206 Partial Content (成功)這是最理想的響應(yīng)。意味著服務(wù)器理解并成功處理了Range請(qǐng)求。響應(yīng)中必須包含Content-Range頭部格式為Content-Range: bytes start-end/total或Content-Range: bytes start-end/*如果服務(wù)器不知道總大小。同時(shí)響應(yīng)體就是請(qǐng)求的字節(jié)范圍。注意即使請(qǐng)求的范圍超出了文件大小例如文件只有1000字節(jié)但請(qǐng)求bytes900-1999合規(guī)的服務(wù)器也應(yīng)返回206但Content-Range中的end會(huì)是999文件末尾實(shí)際返回的數(shù)據(jù)量會(huì)小于請(qǐng)求的范圍。416 Range Not Satisfiable (范圍無(wú)效)這是我們需要重點(diǎn)處理的錯(cuò)誤。當(dāng)請(qǐng)求的Range頭字段中的所有范圍都無(wú)效時(shí)服務(wù)器返回此狀態(tài)。最常見(jiàn)的原因是start大于等于文件長(zhǎng)度。例如文件大小為1000字節(jié)請(qǐng)求Range: bytes1000-或bytes1500-就會(huì)觸發(fā)416。根因分析在我們分片下載的場(chǎng)景下遇到416通常意味著我們記錄的分片起始位置信息存儲(chǔ)在本地與服務(wù)器上的文件實(shí)際狀態(tài)不一致。可能的原因有文件在服務(wù)器端已被修改或替換例如版本更新長(zhǎng)度發(fā)生了變化。本地狀態(tài)文件損壞記錄了錯(cuò)誤的位置。在多線程環(huán)境下?tīng)顟B(tài)管理出現(xiàn)競(jìng)態(tài)條件導(dǎo)致某個(gè)分片被重復(fù)請(qǐng)求了超出范圍的部分。解決方案一個(gè)健壯的下載器不能一遇到416就報(bào)錯(cuò)退出。正確的做法是立即停止當(dāng)前分片的下載。可選嘗試重新獲取一次文件的完整信息如通過(guò)一個(gè)HEAD請(qǐng)求獲取Content-Length和ETag。根據(jù)新的文件信息重置該分片的起始位置為當(dāng)前已知的文件末尾或0并更新本地狀態(tài)記錄。這相當(dāng)于承認(rèn)之前記錄的狀態(tài)已失效從安全的位置重新開(kāi)始下載該分片。200 OK (完全內(nèi)容)如果服務(wù)器不支持Range請(qǐng)求即響應(yīng)中沒(méi)有Accept-Ranges: bytes或者直接忽略Range頭它會(huì)直接返回整個(gè)文件狀態(tài)碼為200。對(duì)于我們的下載器這需要作為一個(gè)降級(jí)方案來(lái)處理既然無(wú)法分片就只能單線程下載整個(gè)文件且無(wú)法實(shí)現(xiàn)斷點(diǎn)續(xù)傳。在實(shí)現(xiàn)時(shí)應(yīng)該檢測(cè)到200響應(yīng)后給出明確提示。2.3 關(guān)鍵輔助頭部Content-Length, ETag Last-Modified要實(shí)現(xiàn)可靠的斷點(diǎn)續(xù)傳僅靠Range是不夠的。Content-Length文件總大小。通過(guò)初始的HEAD請(qǐng)求獲取用于計(jì)算分片策略和總進(jìn)度。ETag文件的實(shí)體標(biāo)簽通常是文件內(nèi)容的哈希值或版本標(biāo)識(shí)符。這是實(shí)現(xiàn)可靠斷點(diǎn)續(xù)傳的黃金標(biāo)準(zhǔn)。在發(fā)起一系列Range請(qǐng)求之前先獲取文件的ETag并保存。每次恢復(fù)下載時(shí)先發(fā)一個(gè)HEAD請(qǐng)求獲取最新的ETag與本地保存的對(duì)比。如果不一致說(shuō)明服務(wù)器文件已變更必須提示用戶或重新開(kāi)始整個(gè)下載任務(wù)。這能有效避免“416”或下載到錯(cuò)誤版本的文件。Last-Modified文件最后修改時(shí)間。可以作為ETag的備用方案。恢復(fù)下載時(shí)檢查此時(shí)間戳是否變化。但它的精度不如ETag因?yàn)榧词刮募?nèi)容沒(méi)變只是移動(dòng)了位置修改時(shí)間也可能更新。一個(gè)健壯的下載器在開(kāi)始下載前應(yīng)該執(zhí)行這樣一個(gè)“握手”流程發(fā)送HEAD請(qǐng)求到目標(biāo)URL。檢查Accept-Ranges是否為bytes確認(rèn)支持分片。記錄Content-Length、ETag優(yōu)先和Last-Modified。將這些元數(shù)據(jù)與本地已下載的部分如果有的元數(shù)據(jù)進(jìn)行比較決定是繼續(xù)、重啟還是報(bào)錯(cuò)。3. 核心架構(gòu)設(shè)計(jì)一個(gè)健壯的分片下載器如何組成理解了協(xié)議我們就可以設(shè)計(jì)下載器的骨架了。一個(gè)工業(yè)級(jí)的分片下載器絕不是簡(jiǎn)單開(kāi)幾個(gè)線程去拉數(shù)據(jù)那么簡(jiǎn)單。它需要精心設(shè)計(jì)的狀態(tài)管理和錯(cuò)誤處理機(jī)制。3.1 分片策略與狀態(tài)管理首先我們需要決定如何把文件“切”開(kāi)。常見(jiàn)的策略有固定大小分片每個(gè)分片大小相同如1MB或5MB。計(jì)算簡(jiǎn)單易于管理。分片數(shù) ceil(文件總大小 / 分片大小)。動(dòng)態(tài)分片根據(jù)網(wǎng)絡(luò)狀況或服務(wù)器負(fù)載動(dòng)態(tài)調(diào)整分片大小。更復(fù)雜但可能更高效。對(duì)于大多數(shù)場(chǎng)景固定大小分片足夠用了。關(guān)鍵在于我們必須為每一個(gè)分片維護(hù)一個(gè)獨(dú)立的狀態(tài)。這個(gè)狀態(tài)至少包括index: 分片序號(hào)。start: 分片起始字節(jié)。end: 分片結(jié)束字節(jié)。downloaded: 該分片已下載的字節(jié)數(shù)用于斷點(diǎn)續(xù)傳。status: 狀態(tài)pending,downloading,completed,error。這些狀態(tài)需要持久化到磁盤比如一個(gè)JSON文件或小型數(shù)據(jù)庫(kù)。這樣當(dāng)程序崩潰或主動(dòng)退出后重新啟動(dòng)時(shí)能讀取狀態(tài)知道每個(gè)分片下載到哪了從而實(shí)現(xiàn)真正的“斷點(diǎn)續(xù)傳”。3.2 多線程/協(xié)程的調(diào)度與并發(fā)控制分片下載天然適合并發(fā)。我們可以為每個(gè)分片或每批分片分配一個(gè)獨(dú)立的線程或協(xié)程在Python中asyncioaiohttp是絕佳選擇去下載。這里有幾個(gè)關(guān)鍵控制點(diǎn)并發(fā)數(shù)限制不要無(wú)限制地創(chuàng)建連接。通常根據(jù)網(wǎng)絡(luò)環(huán)境和目標(biāo)服務(wù)器承受能力設(shè)置一個(gè)并發(fā)上限如5-10個(gè)。這可以通過(guò)線程池/信號(hào)量來(lái)實(shí)現(xiàn)。任務(wù)隊(duì)列將所有狀態(tài)為pending的分片放入一個(gè)隊(duì)列。工作線程/協(xié)程從隊(duì)列中獲取任務(wù)執(zhí)行。流量與進(jìn)度聚合每個(gè)工作單元下載時(shí)需要定期如每下載64KB更新其分片的downloaded狀態(tài)并通知一個(gè)全局的進(jìn)度管理器以計(jì)算和顯示整體下載速度與進(jìn)度。這里要注意線程安全對(duì)共享狀態(tài)如全局已下載字節(jié)數(shù)的更新需要加鎖或使用原子操作。3.3 錯(cuò)誤處理與重試機(jī)制網(wǎng)絡(luò)請(qǐng)求充滿不確定性。我們必須為每個(gè)分片下載任務(wù)設(shè)計(jì)健壯的重試邏輯。可重試的錯(cuò)誤連接超時(shí)、讀取超時(shí)、TCP連接重置、HTTP 5xx服務(wù)器錯(cuò)誤、429 Too Many Requests等。對(duì)于這些錯(cuò)誤應(yīng)該進(jìn)行指數(shù)退避重試?yán)绲谝淮蔚却?秒第二次2秒第三次4秒。不可重試/需特殊處理的錯(cuò)誤HTTP 416范圍無(wú)效需重置分片狀態(tài)、403/404資源問(wèn)題應(yīng)停止整個(gè)任務(wù)、ETag不匹配文件已變更需用戶決策。分片級(jí)重試 vs 任務(wù)級(jí)重試一個(gè)分片下載失敗只重試該分片不影響其他分片。只有當(dāng)遇到全局性錯(cuò)誤如文件不存在時(shí)才終止整個(gè)下載任務(wù)。4. 手把手實(shí)現(xiàn)用Python構(gòu)建分片下載器理論說(shuō)再多不如一行代碼。我們使用Python的asyncio和aiohttp庫(kù)來(lái)實(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: 代表一個(gè)下載分片及其狀態(tài) index: int start: int end: int downloaded: int 0 status: ChunkStatus ChunkStatus.PENDING # 用于恢復(fù)下載時(shí)記錄臨時(shí)文件的路徑 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)接下來(lái)是主下載器類的核心骨架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請(qǐng)求獲取文件元數(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)建一個(gè)覆蓋整個(gè)文件的分片 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) # 為每個(gè)分片分配一個(gè)臨時(shí)文件 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. 如果無(wú)狀態(tài)則初始化分片 self._initialize_chunks() # 4. 啟動(dòng)并發(fā)下載 await self._download_chunks_concurrently() # 5. 合并分片文件 await self._merge_chunks() # 6. 清理臨時(shí)文件 self._cleanup() async def _download_chunks_concurrently(self): 使用信號(hào)量控制并發(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): 下載單個(gè)分片支持?jǐn)帱c(diǎn)續(xù)傳 async with semaphore: # 如果分片已部分下載則從斷點(diǎn)開(kāi)始 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 # 以追加模式打開(kāi)臨時(shí)文件 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ù)寫(xiě)入臨時(shí)文件并更新chunk.downloaded # 同時(shí)更新全局進(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() # 重新開(kāi)始下載這個(gè)分片這里簡(jiǎn)化處理實(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í)文件合并成最終文件 # 實(shí)現(xiàn)略按chunk.index順序讀取所有.part文件寫(xiě)入output_path pass def _cleanup(self): 清理臨時(shí)文件和狀態(tài)文件 # 實(shí)現(xiàn)略 pass以上代碼勾勒出了下載器的核心框架。_download_single_chunk方法包含了關(guān)鍵的重試邏輯和對(duì)206、416狀態(tài)碼的處理。_load_state和_save_state是實(shí)現(xiàn)斷點(diǎn)續(xù)傳的關(guān)鍵需要將分片列表、ETag等信息序列化到JSON文件中。4.2 進(jìn)度顯示與用戶體驗(yàn)一個(gè)沒(méi)有進(jìn)度提示的下載器是難以忍受的。我們可以使用tqdm庫(kù)來(lái)創(chuàng)建美觀的進(jìn)度條。在progress.py中我們可以設(shè)計(jì)一個(gè)類來(lái)聚合所有分片的下載進(jìn)度并實(shí)時(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í)例在每個(gè)分片下載到數(shù)據(jù)塊時(shí)調(diào)用progress.update(len(data))。5. 進(jìn)階議題與實(shí)戰(zhàn)避坑指南把基礎(chǔ)功能跑通只是第一步。在實(shí)際生產(chǎn)環(huán)境中你會(huì)遇到更多棘手的問(wèn)題。5.1 服務(wù)器兼容性與降級(jí)策略不是所有服務(wù)器都規(guī)規(guī)矩矩地遵守HTTP/1.1協(xié)議。你需要處理各種“奇葩”情況聲稱支持Range但行為異常有些服務(wù)器返回Accept-Ranges: bytes但你發(fā)送Range請(qǐng)求后它依然返回整個(gè)文件狀態(tài)碼200。我們的代碼需要檢測(cè)這種情況如果請(qǐng)求了范圍但返回的Content-Length遠(yuǎn)大于請(qǐng)求的范圍大小或者狀態(tài)碼是200就應(yīng)該觸發(fā)降級(jí)回退到單線程全量下載并警告用戶。Content-Range格式不標(biāo)準(zhǔn)極少數(shù)服務(wù)器返回的Content-Range可能缺少總大小如bytes 0-499/*。這時(shí)我們無(wú)法計(jì)算總進(jìn)度進(jìn)度條會(huì)不準(zhǔn)確但下載可以繼續(xù)。連接數(shù)限制與429狀態(tài)碼過(guò)于激進(jìn)的并發(fā)可能導(dǎo)致服務(wù)器返回429 Too Many Requests。一個(gè)良好的下載器應(yīng)該能捕獲這個(gè)狀態(tài)碼并動(dòng)態(tài)降低并發(fā)數(shù)或者進(jìn)入一段時(shí)間的休眠。5.2 大文件合并與內(nèi)存管理當(dāng)分片下載完成后我們需要將數(shù)百甚至數(shù)千個(gè)臨時(shí)文件合并成一個(gè)。最樸素的做法是打開(kāi)最終文件然后循環(huán)打開(kāi)每個(gè)分片文件讀取其全部?jī)?nèi)容并寫(xiě)入。這對(duì)于超大文件是災(zāi)難性的可能會(huì)耗盡內(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)這樣無(wú)論分片文件多大內(nèi)存占用都保持在chunk_size級(jí)別。5.3 完整性校驗(yàn)不可或缺的最后一步下載完成就萬(wàn)事大吉了嗎不網(wǎng)絡(luò)傳輸可能引入靜默錯(cuò)誤盡管TCP有校驗(yàn)和但應(yīng)用層仍需把關(guān)。特別是對(duì)于分片下載合并過(guò)程也可能出錯(cuò)。因此下載完成后必須進(jìn)行完整性校驗(yàn)。如果服務(wù)器提供了ETag通常是MD5或SHA哈希在下載完成后計(jì)算本地文件的哈希值與之前保存的ETag進(jìn)行比較。這是最可靠的方法。如果服務(wù)器沒(méi)有提供ETag可以計(jì)算本地文件的MD5或SHA256哈希如果可能的話與官方源提供的哈希值進(jìn)行比對(duì)。很多開(kāi)源軟件發(fā)布時(shí)會(huì)附帶sha256sum.txt文件。分片級(jí)校驗(yàn)可選但推薦在每個(gè)分片下載完成后立即計(jì)算該分片的哈希并保存。在合并前再次校驗(yàn)每個(gè)分片。這可以快速定位是哪個(gè)分片在傳輸或存儲(chǔ)中損壞只需重新下載該分片而不必重下整個(gè)文件。5.4 那些我踩過(guò)的“坑”臨時(shí)文件清理不徹底程序異常退出時(shí)臨時(shí)目錄.tmp和狀態(tài)文件.json.state可能殘留。下次啟動(dòng)時(shí)如果直接加載舊狀態(tài)而源文件已更新會(huì)導(dǎo)致混亂。最佳實(shí)踐在加載舊狀態(tài)前檢查臨時(shí)文件是否完整存在并與狀態(tài)記錄匹配。不匹配則視為無(wú)效狀態(tài)重新初始化下載。進(jìn)度保存過(guò)于頻繁每下載一小塊數(shù)據(jù)就保存一次狀態(tài)到磁盤I/O壓力巨大影響下載速度。解決方案設(shè)置一個(gè)閾值例如每下載完成1MB數(shù)據(jù)或每隔5秒才批量保存一次狀態(tài)。也可以使用WALWrite-Ahead Logging思想先寫(xiě)日志再異步更新主狀態(tài)文件。默認(rèn)User-Agent被屏蔽一些服務(wù)器會(huì)屏蔽aiohttp或Python的默認(rèn)User-Agent。在創(chuàng)建ClientSession時(shí)最好設(shè)置一個(gè)常見(jiàn)的瀏覽器User-Agent字符串。SSL證書(shū)驗(yàn)證問(wèn)題在訪問(wèn)一些自簽名HTTPS站點(diǎn)時(shí)可能會(huì)遇到證書(shū)錯(cuò)誤。對(duì)于不可信的公開(kāi)站點(diǎn)不要輕易禁用SSL驗(yàn)證connectoraiohttp.TCPConnector(sslFalse)這有安全風(fēng)險(xiǎn)。對(duì)于內(nèi)部可信環(huán)境可以傳入自定義的SSL上下文。永遠(yuǎn)不要在生產(chǎn)代碼中全局禁用SSL驗(yàn)證。分片大小選擇不當(dāng)分片太小如10KB會(huì)導(dǎo)致請(qǐng)求頭開(kāi)銷占比過(guò)高且創(chuàng)建大量臨時(shí)文件降低效率。分片太大如100MB則斷點(diǎn)續(xù)傳的粒度太粗網(wǎng)絡(luò)中斷時(shí)浪費(fèi)的已下載數(shù)據(jù)更多。經(jīng)過(guò)多次測(cè)試對(duì)于大多數(shù)公網(wǎng)下載1MB到10MB是一個(gè)比較均衡的范圍。你可以根據(jù)首次連接的延遲和帶寬動(dòng)態(tài)估算一個(gè)初始值。實(shí)現(xiàn)一個(gè)健壯、高效、用戶友好的HTTP分片下載器是一個(gè)將網(wǎng)絡(luò)協(xié)議、并發(fā)編程、狀態(tài)管理和錯(cuò)誤處理融會(huì)貫通的絕佳練習(xí)。它沒(méi)有用到多么高深的算法但對(duì)工程細(xì)節(jié)的考量決定了它是“玩具”還是“工具”。希望這篇長(zhǎng)文能幫你避開(kāi)我當(dāng)年踩過(guò)的那些坑當(dāng)你下次需要傳輸一個(gè)大文件時(shí)可以自信地寫(xiě)出屬于自己的下載解決方案。