Explicații · unu

Cum funcționează descărcarea într-o singură trecere

Cea mai mare parte din ce face rapid acest client nu este o cale de rețea mai iute. Este faptul că datele se mișcă o singură dată. Iată ce înseamnă asta în practică, de ce este altceva decât dezarhivarea directă, ce forme de arhivă îi supraviețuiesc, și cât valorează cu adevărat, pe o mașină reală, eliminarea ciclului scrie-și-citește-înapoi.

Punctul de plecare

Ce face în mod tradițional o descărcare Usenet

O postare înseamnă mii de articole mici codificate care împreună formează un set de volume de arhivă, care la rândul lor conțin fișierul pe care îl vrei de fapt. A ajunge de la unul la celălalt au fost în mod tradițional patru sarcini separate, fiecare terminându-se înainte ca următoarea să înceapă.

  1. Descarcă și decodifică. Adu fiecare articol, decodifică-l, și scrie pe disc volumele de arhivă reasamblate. Pentru o lansare de 60 GB asta înseamnă 60 GB scriși.
  2. Verifică. Citește înapoi toți cei 60 GB de pe disc pentru a-i confrunta cu datele de paritate, și repară-i dacă ceva nu e în regulă.
  3. Dezarhivează. Citește volumele din nou, și scrie conținutul extras lângă ele. Acum pe disc sunt 120 GB.
  4. Curăță. Șterge volumele, lăsând conținutul.

Fiecare etapă este corectă, iar rezultatul este bun. Dar conținutul a fost scris de două ori, citit cel puțin de două ori, iar la vârf discul a trebuit să țină două copii complete ale unei sarcini din care voiai o singură copie. Cronometrul pe care îl trăiești sunt toate cele patru etape la rând, motiv pentru care un client poate raporta o descărcare rapidă și totuși să te țină în așteptare.

Schimbarea

Să o facem o singură dată în schimb

O singură trecere înseamnă că octeții merg de la rețea la destinația lor finală fără să devină vreodată un fișier de arhivă pe discul tău. Nu există etapa doi sau trei, fiindcă munca amândurora se petrece în timp ce etapa unu încă rulează.

În practică, fiecare articol este decodificat în memorie pe măsură ce sosește și predat direct la două lucruri deodată. Verificatorul îl confruntă imediat cu datele de paritate, deci corectitudinea se stabilește pe măsură ce datele aterizează, nu recitindu-le mai târziu. Extractorul tratează octeții care sosesc ca pe o poziție în interiorul arhivei, calculează cărei părți a cărui fișier de conținut îi aparțin, și îi scrie acolo.

Volumele arhivei nu sunt niciodată asamblate. Ele există ca o structură pe care extractorul o înțelege cât timp descărcarea este în zbor, iar singurul lucru care ajunge pe discul tău este fișierul pe care îl voiai. Când sosește ultimul articol nu mai rămâne practic nimic de făcut, motiv pentru care timpii noștri de sosire stau aproape de timpul de descărcare însuși, nu de o descărcare plus o coadă.

Consecința măsurabilă: pentru aceeași sarcină scriem cam pe jumătate, citim înapoi mult mai puțin, și avem nevoie de aproximativ dimensiunea proprie a conținutului în spațiu liber, nu de dublul ei. La o lansare de 190 GB asta înseamnă circa 157 GB spațiu liber față de circa 313 GB, și aproximativ o treime din traficul pe disc.

Două lucruri fac asta mai greu decât pare, și ele sunt motivul pentru care este neobișnuit. Articolele nu sosesc în ordine, deci extractorul trebuie să se descurce cu octeți care aterizează în poziții arbitrare, nu ca un flux de la început. Iar o arhivă comprimată nu poate fi decomprimată de la mijloc, deci orice parte a muncii care cere cu adevărat ordine trebuie recunoscută și tratată altfel, nu presupusă rezolvată.

Comparația despre care ni se cere

De ce asta nu este dezarhivare directă

Dezarhivarea directă este o funcție bună și clienții care o au sunt mai buni cu ea. Rezolvă însă altă parte a problemei, iar diferența se vede exact acolo unde contează.

Dezarhivarea directă începe să extragă înainte ca descărcarea să se fi încheiat, așa că etapa trei se suprapune peste etapa unu în loc să o urmeze. Ce nu face este să elimine etapa unu. Volumele arhivei sunt tot scrise integral pe discul tău, fiindcă dezarhivatorul este unul convențional care citește fișiere convenționale; dezarhivarea directă doar îl pornește mai devreme. Cele două copii tot există, cele două scrieri tot se petrec, iar necesarul de spațiu liber rămâne neschimbat.

scrie volumele pe discspațiu liber necesarde câte ori se scrie conținutul
Descarcă, apoi dezarhiveazăda, apoi recitire~2× sarcina2
Dezarhivare directăda, recitit mai devreme~2× sarcina2
O singură trecerenu se scriu niciodată~1× sarcina1

A doua diferență este ce se întâmplă când forma nu este simplă. Fiindcă dezarhivarea directă predă munca unui dezarhivator convențional pe măsură ce apar volumele, are nevoie ca situația să fie neîncurcată: volumele prezente într-o ordine utilizabilă, nicio reparație în așteptare, nimic de deblocat mai întâi, și o arhivă al cărei conținut să nu fie el însuși arhive. Când ceva din asta lipsește, lucrul înțelept este să se retragă și să revină la dezarhivarea de la final, și asta se și întâmplă. Obții un rezultat corect și timpii obișnuiți.

Fiindcă extractorul nostru este construit de la bun început în jurul octeților în dezordine, situațiile acelea nu sunt excepții pentru el. Aceasta este distincția reală: nu că pornim mai devreme, ci că nu ne bazăm pe condiții care adesea nu se împlinesc.

Ce îi supraviețuiește cu adevărat

Formele pe care le duce

Un asemenea proiect merită doar dacă se aplică postărilor pe care le întâlnești cu adevărat, nu unui caz ideal curat. Poziția actuală: niciun format de container nu este tratat doar pe disc. RAR, 7z și zip trec toate prin calea cu o singură trecere.

formăo singură trecerenote
RAR, stocat (fără comprimare)dacazul obișnuit la lansările multimedia
RAR, comprimatdainclusiv o arhivă comprimată ca strat exterior
RAR 1.5, 3, 4 și 5datoate cele patru generații ale formatului
7zdainclusiv conținut comprimat cu deflate
zipdainclusiv conținut bzip2 și LZMA
Conținut criptatdacu parolă, inclusiv zip criptat
Antete criptatedaacolo unde și numele fișierelor sunt ascunse
Lanțuri de paroledaparola fiecărui strat împachetată în stratul de deasupra
Arhive imbricatedadezimbricate din mers, până la o adâncime configurabilă
Deteriorat pe mai multe straturidareparație la fiecare nivel, tot o singură trecere
Seturi împărțite numericdaîmpărțiri în stil name.001
Arhive autoextractibiletrecere pe discarhiva nu începe la începutul fișierului
Zip împărțit (.z01)trecere pe discși câteva variante de zip mai rare
Sarcini reluatetrecere pe disco sarcină continuată după o repornire se încheie în mod convențional

Cele trei refuzuri sunt oneste și se comportă la fel: sarcina se încheie corect, pe calea convențională, iar pentru acea descărcare obții timpii obișnuiți cu două copii. Nimic nu eșuează; doar încetează să fie rapid în felul descris în restul acestei pagini. Arhivele autoextractibile sunt refuzate dintr-un motiv structural, nu din lipsă de efort: identificarea unei arhive după primii ei octeți nu poate funcționa când primii octeți sunt un program.

Rândurile imbricat și criptat sunt cele care merită luate în serios, fiindcă acolo îți dau înapoi sarcina cei mai mulți clienți. Pe un corpus generat de zece forme imbricate, notat după amprenta conținutului astfel încât un client care redenumește conținutul să primească totuși credit, am finalizat 9 din 10 fără intervenție; următorul cel mai bun client a finalizat 5, iar alți doi au finalizat 2. Cea pe care nu o finalizăm automat este o scară cu zece niveluri, care se încheie curat la limita implicită de adâncime cinci, lăsând stratul cel mai adânc ca arhivă sănătoasă, și se finalizează complet dacă ridici limita. Rundele acelea sunt pe pagina de benchmark-uri cu grila întreagă.

De ce merită făcut

Ce aduce cu adevărat eliminarea drumului dus-întors

Este mai rapid, dintr-un motiv lipsit de strălucire. A scrie 60 GB și a-i citi înapoi nu este gratis nici măcar pe un disc SSD rapid, iar pe orice altceva mai lent este adesea adevăratul gât de sticlă în locul rețelei. Eliminarea unei scrieri și a două citiri scoate acel timp din cronometrul tău cu totul. Câștigul este cel mai mare tocmai acolo unde se observă cel mai mult: sarcini mari, și mașini al căror disc nu este partea lor cea mai rapidă.

Înjumătățește uzura. Discurile SSD au în ele un număr finit de scrieri, iar un descărcător care scrie fiecare conținut de două ori cheltuiește bugetul acela în ritm dublu fără vreun beneficiu pentru tine. Pe parcursul câtorva sute de terabytes descărcați, ceea ce este un an obișnuit pentru un utilizator activ, diferența reprezintă o parte însemnată din viața unui disc.

Schimbă ce încape. Spațiul liber nu este o caracteristică de performanță, este un da sau nu. O sarcină care are nevoie de dublul propriei dimensiuni ca marjă ori rulează, ori nu. A avea nevoie de aproximativ dimensiunea conținutului înseamnă că sarcinile se încheie pe mașini și volume unde abordarea convențională pur și simplu se oprește, și de aceea o lansare de 190 GB încape aici în circa 157 GB spațiu liber, nu în circa 313 GB.

Costă mai puțin timp de procesor. A nu trece datele prin disc de două ori elimină munca de a o face, iar verificarea în timpul descărcării înseamnă nicio a doua trecere peste conținut pentru a-l controla. Costul nostru de procesor rămâne plat la aproximativ 1.7 secunde de procesor pe gigabyte, de la o sarcină de 35 GB la una de 190 GB, și aceasta este proprietatea utilă: costul pe gigabyte nu crește odată cu sarcina.

Rulează în mai puțină memorie, și în memorie mărginită. Fiindcă octeții sunt consumați pe măsură ce sosesc și nu adunați, setul de lucru este un buget pe care îl stabilești tu, nu o funcție a dimensiunii sarcinii. Asta permite ca o lansare de 190 GB să fie procesată pe o mașină cu aproximativ 1.1 GB disponibili. Distincția care contează nu este numărul, ci forma: memoria care crește odată cu sarcina va întâlni până la urmă o sarcină pe care mașina ta nu o poate termina, și cedează prin folosirea spațiului de swap sau prin a fi ucisă, nu prin a-ți spune.

Luate împreună, acestea țin mai puțin de câștigarea unui benchmark și mai mult de unde poate rula programul, pur și simplu. Un proiect care are nevoie de jumătate din spațiul liber, jumătate din scrieri și o cantitate mărginită de memorie funcționează pe un mic server de casă, pe un laptop mai vechi sau pe un NAS, și tocmai acolo trăiește o bună parte din acest software.

Fiecare cifră de pe această pagină este măsurată și publicată cu versiunea și data alături pe pagina de benchmark-uri, inclusiv rundele pe care le pierdem. Contraponderea onestă, spusă și acolo: un extractor și un reparator construiți să însoțească o descărcare în curs țin mai multă memorie rezidentă decât un instrument de sine stătător rulat o dată din linia de comandă, deci dacă restricția ta este cea mai mică amprentă posibilă pentru o sarcină unică pe un fișier pe care îl ai deja, uneltele dedicate câștigă coloana aceea.