What is the principle behind breakpoint resume? The download stopped and I kept going. I caught a packet and saw that Range and 206 worked together like this

last month, I helped my cousin install a Feiniu image image, with over four GB of storage, and 97% of the time his device tripped. After the call, he stared at the downloader's "Continue" button and asked: Should I start over from the beginning, or continue from 97%? If you start over, is the app showing '3.9G downloaded' just a scam?

I was vague about this before. After reading it thoroughly, I realized: Breakpoint resume isn't a trick invented by the downloader itself, but a pair of pre-programmed partners in the HTTP protocol—Range request header and 206 status code . Today, I'll break down this duo and explain it clearly, and also explain why multithreaded downloaders are fast.

first break down the three "cut pieces" to avoid mixing them together

Break point resume can easily be confused with the other two "cut pieces," so draw a clear line first.

One is packet fragmentation at the cable level. Your broadband MTU is 1500, but large packets need to be disassembled at the network layer. That's a matter between routers, not the downloader. I previously wrote an article about what MTU means specifically discussing it.

Another is the application layer cutting its own chunks. Video sites split a single video into thousands of 10-second files—that's HLS's approach. watch videos, you can just drag the progress bar count them, and 64 clips are cut in 10 minutes. For BT downloads, I also cut them into 1MB blocks myself, each with fingerprint verification. magnetic links, I opened them up and that's exactly what you saw. The "blocks" from these two companies are real, independent files, each set up separately.

HTTP breakpoint resume is different: there is only one complete file on the server, and no one has cut it. The downloader says in the request, "I only want bytes to bytes," and the server cuts a segment from the same file for you on the spot. The files haven't changed; what changes are the way you want.

Range ask for it? How did the server respond

I used a 39,050-byte graph from my own site and ran an experiment, adding a line of Range to the request header to see how the server would respond.

the first 1024 bytes, write Range: bytes = 0 - 1023. The first line of the server's reply is 206 Partial Content—note it's not 200, 200 means "the entire file is for you," and 206 is "the part you want." Followed by a line Content-range: bytes 0-1023/39050. The segment before the slash is 0-1023, and the slash is 39050 for the total length of the text. When it landed, it was exactly 1024 bytes—not a cent more.

want a tail as well, write Range: bytes=38026-, leave the ending unwritten, and the server will automatically fill it to the end of the file. The return is still 206, Content-range: bytes 38026-39049/39050, on-site 1024 bytes. There is also a variant of this "no beginning to write" version: bytes = -1024 represents "the last 1024 bytes," which is popular when the downloader verges the file end.

what if it's a segment that doesn't exist? I deliberately set bytes = 99999 - , so the total file is only 39050. The server replied with a 416, and the reply included Content-range: bytes */39050—the asterisk means "The paragraph you want doesn't exist, but the whole text is this long, do as you see fit."

this 416 Eye Whites has another clever use. I ran wget -c again on a file that had already been fully downloaded. It locally recorded '39050 bytes existed', so I started bytes=39050-—starting from the end of the file, which means I got a segment that doesn't exist. Server returns to 416, with bytes */39050. Wget understood as soon as it appeared: the file length I wanted was exactly the file length, not a single byte missing, downloaded and done. In the resume log, 'confirm complete' is done just like this—not by counting bytes until it's enough, but by asking for one more time, letting the server stamp it with 416. 206 is responsible for stamping Duan, and 416 is responsible for stamping. These two brothers mentioned their names in the status code ledger of 404 and 502; this is where they really work.

by the way, I previously wrote about the difference between HTTP and HTTP for encryption layershttp the rules for range segments are the same under both protocols; what you see when capturing packets is the same.

the password before resuming: Is the file still the same one

I know it's about to be cut, how do I reconnect the disconnected download? Actually, it's just three steps: the downloader stores the number of downloaded bytes locally. For example, if it drops to 3.9G and it cuts, when resuming the transfer, it sends Range: bytes = 4187593088-. The server counts from the breakpoint backward, and the received bytes are appended directly to the end of the local file.

But there's a hidden pitfall: Are the files on server still the same as before? if the webmaster updates the file in the middle and you have 3.9GB from the old version, connect it to the new version's tail, and piece together a mismatched mess—installing the system is just a mess.

so before continuing the story, you have to check the code. The first download included two credentials in the response header: ETag and Last-Modified—in my experiment, it was etag: "6ac4ef6d-988a" plus a modification time. When resuming transfer, the downloader brings back these two credentials as they are. The server pairs: if they match, 206 will continue to provide them; If not, just give you 200 and give you the whole new file, which is basically forcing a new beginning. This set of credentials is the same set as the 304 used for browser caching. the about the page always showing old content, I explained how they work.

the most intuitive command line iswget -c, continue where you stop; curl corresponds to curl -C -, and the horizontal bar means 'You can calculate the breakpoint position yourself.' The browser uses this system for direct download, but it doesn't show you the process.

multithreaded downloader does: cutting into 4 segments and piecing them back. I tested it md5

Once you understand Range, the trump card of multithreaded downloaders is revealed. So-called 8 threads and 16 threads mean dividing the total file length by the number of threads, sending a range of different threads per thread, pulling in parallel, and finally splintering a file locally.

I split the 39050-byte diagram into 4 segments and ran a back-and-forth experiment: Thread 1 needs 0-9762, Thread 2 needs 9763-19525, Thread 3 needs 19526-29287, Thread 4 needs 29288-39049. Four requests are sent simultaneously, each pulling back bytes 9763, 9763, 9762, and 9762 bytes, then concatenating them in order, resulting in 39,050 bytes. Then compare it with the fully downloaded original file with MD5—ce42d41f3e6ac0080839fa144a6702d2, both are exactly the same. Byte-level restoration with no check-in patches in between because every segment is cut from the original file.

why does multithreading seem so fast? To be honest, it doesn't have a "speed" boost; your broadband is still the same bandwidth, bandwidth, negotiated speed, and actual speed are all of the third-tier ledger. What it does is fill up the pipe: during single-threaded downloads, if the server limits a single connection to 500KB/s, or if there is idle waiting during transmission, the pipeline is wasted; Each of the 8 connections is limited to 500KB/s, which adds up to 4MB/s. In the early days, the "acceleration" hype about download tools mostly involved looping connections and speed limits. Currently, BT downloaders also have a segmented approach built in. NAS the downloader , the connection counts you see when downloading QBittorrent are actually the on-site parallel block pulling on end-to-end.

some things are inherently unrenewable

and not all downloads can. Three conditions must be met for resumed transfer at breakpoints: the server recognizes the Range, the file is stationary, and the downloader records progress.

I tried using a test interface, and the request clearly sent a 'Range' at the top, but the other party ignored it and replied to 200, stuffing the entire file from scratch. This is a server that doesn't support Range—note it doesn't get errors, silently downgrade to full retransmission, you might think it's a resumption, but you've already started over. Some free cloud drive users limit speed, with single-thread speeds of several hundred KB, relying on not recognizing Range or limiting multi-threading. Membership "acceleration" basically means opening up these loopholes.

there's another thing that can't be continued: dynamically generated content. Some pages are only formed at the moment of request; the two requests produce different things, the byte position doesn't match, the Etag doesn't match, so you have to take the whole copy. The way to check is simple: check if the first response header contains Accept-Ranges: bytes this line, if it does, it means the price is clearly marked and supports segmentation; If not, it's probably the server's fault.

a table to wrap up

order is to wrap up: for large files, first confirm the response header contains __. HTML172__Accept-Ranges: bytes further down; If the download is interrupted, don't delete half of the local file. Click Resume; Before installing the system after continuing the transfer, I checked the official MD5 and took ten seconds to avoid realizing the assembly was broken halfway through. My cousin's one was 97%. Later, wget -c finished in three minutes, and the previous 3.9G was worth buying a byte.