HTTP range requests përdorin fixed cache chunks, jo tuning
HTTP range requests i lejojnë një klienti të kërkojë bajte të përzgjedhura nga një skedar, në vend që të shkarkojë të gjithë objektin. Në një përshkrim teknik të datës 23 tetor 2026, Cloudflare paraqiti një implementim të ri që përdor chunks me madhësi fikse, të cilat përdoren tashmë nga Pingora cache, në vend që t'u kërkojë klientëve të zgjedhin një madhësi range. Ndryshimi trajton një problem më të gjerë të infrastrukturës: një madhësi slice e zgjedhur manualisht nuk mund të shërbejë me efikasitet çdo zhvendosje në video, rifillim shkarkimi, tërheqje pakete, madhësi skedari dhe strukturë cache.
Një range request është veçanërisht i dobishëm për objekte të mëdha. Një luajtës videosh mund të tërheqë të dhëna rreth një pozicioni të ri të riprodhimit, ndërsa një menaxher shkarkimesh mund të rifillojë një transferim të ndërprerë. Menaxherët e paketave mund të tërheqin vetëm një pjesë të një artefakti dhe klientët mund të shqyrtojnë fundin e një skedari pa transferuar më parë gjithçka që ndodhet përpara tij. Klienti vendos nëse do ta dërgojë kërkesën, duke përdorur Range header, i cili përcakton pozicionet e kërkuara të bajteve. Cloudflare thotë se nuk e ndryshon atë kërkesë të klientit. Origin Range Requests ndryshon mënyrën se si rrjeti i tij i merr dhe i kthen të dhënat e kërkuara.
Kur origin server, domethënë sistemi që mban skedarin origjinal, e mbështet kërkesën, ai mund të kthejë HTTP status `206 Partial Content`. Një `Content-Range` response header identifikon se cilat bajte janë dhënë dhe madhësinë e plotë të skedarit. Cloudflare jep një shembull që përfshin bajtet nga 1048576 deri në 2097151 të një skedari me 524288000 bajte, me një `Content-Length` prej 1048576 bajtesh. Ky header i fundit i tregon klientit se sa të dhëna përmban përgjigjja.
Implementimi i mëparshëm i Cloudflare përdorte konfigurim statik për çdo zone, kufirin e tij të konfigurimit për një faqe interneti. Ai ngjante me metodën cache slicing të përshkruar në një postim në blogun e nginx: çdo kërkesë e klientit vendosej mbi seksione me madhësi fikse të një skedari, ndërsa administratorët konfiguronin si madhësinë e seksionit, ashtu edhe prapashtesat përkatëse të skedarëve. Një cache është hapësirë ruajtjeje e përkohshme që i mban të dhënat e marra më parë më pranë klientëve, në mënyrë që ato të shërbehen sërish pa një transferim tjetër të plotë nga origin.
Kjo qasje impononte një kompromis të vështirë. Ranges të vegjël të konfiguruar gjeneronin shumë kërkesa të vogla drejt origin dhe rritnin presionin mbi memorien, ndërsa Cloudflare bashkonte në memorie kërkesat e njëkohshme. Ranges të mëdhenj mund ta detyronin rrjetin të shkarkonte dukshëm më shumë të dhëna nga sa kishte kërkuar klienti. Meqenëse madhësia e zgjedhur ishte pjesë e cache key, identifikuesit që përdoret për të gjetur një përgjigje të ruajtur, ndryshimi i këtij konfigurimi zhvlerësonte gjithashtu entries ekzistuese.
Concurrency krijonte një problem tjetër. Kërkesat e vendosura në të njëjtin range të konfiguruar mund të bllokonin njëra-tjetrën, edhe kur klientët kërkonin bajte shumë larg njëri-tjetrit brenda atij seksioni. Cache i Cloudflare i bazuar në nginx gjithashtu nuk mund ta kombinonte në mënyrë të sigurt range caching me concurrent streaming, i cili u lejon klientëve të fillojnë ta lexojnë një objekt nga cache ndërsa cache ende po e merr atë. Aktivizimi i të dyjave mund t'i ndërpriste përgjigjet para përfundimit. Si rezultat, një range i plotë duhej të mbërrinte përpara se klienti të mund ta lexonte dhe një skedar popullor kërkonte një tërheqje të veçantë nga origin për çdo range.
Over-fetching mund të përhapej përmes disa shtresave. Bajtet e panevojshme mund të udhëtonin nga origin drejt një qendre të dhënash, të lëviznin ndërmjet cache tiers dhe më pas të vazhdonin drejt klientit. Çdo hap e shtonte transferimin e shpërdoruar. Cloudflare arriti në përfundimin se asnjë madhësi e vetme range e konfiguruar nuk funksiononte njësoj mirë për një zhvendosje të shkurtër, një shkarkim sekuencial, një objekt të madh mediatik, çdo origin dhe çdo topologji cache. Për pasojë, këto kufizime të brendshme u kthyen në një barrë konfigurimi për klientët.
Kalimi nga nginx te një caching server i bazuar në Pingora ofroi një model tjetër. Pingora e ruan tashmë çdo skedar të vendosur në cache në disk si chunks me madhësi fikse, në mënyrë që shkarkimet e ndërprera të mund të rifillojnë. Origin Range Requests i ripërdor këto chunks. Edge, domethënë vendndodhja e rrjetit që i shërben klientit, kontrollon fillimisht se cilat bajte të kërkuara janë të pranishme. Ai i kthen drejtpërdrejt të dhënat e disponueshme dhe më pas i kërkon origin ranges që mungojnë, të përafruara me kufijtë e chunks. Të dhënat e marra rishtazi vendosen në të njëjtat chunks që përdoren për objektet e zakonshme në cache, ndërsa klienti merr vetëm bajtet që ka kërkuar.
Për shembull, një kërkesë e klientit për bajtet nga 150 deri në 250 mund ta bëjë cache të tërheqë të gjithë chunk e përafruar që përmban atë interval. Downstream response vazhdon të përfshijë vetëm bajtet nga 150 deri në 250. Kjo nuk e eliminon të gjithë transferimin shtesë: një kërkesë më e vogël se një chunk mund të kërkojë përsëri të gjithë chunk që e përmban dhe ranges që nuk përputhen me kufijtë kërkojnë përpunim shtesë. Avantazhi i deklaruar nga Cloudflare është se kjo punë është e kufizuar dhe e parashikueshme, në vend që të kontrollohet nga një madhësi e zgjedhur prej klientit, me efekte potencialisht të paparashikueshme mbi cache dhe origin.
Detyra e vështirë inxhinierike nuk është parsing i Range header, por ndërtimi i një përgjigjeje të saktë kur bajtet e saj janë të shpërndara ndërmjet diskut, një përgjigjeje nga origin dhe shkarkimeve tashmë në proces. Cloudflare thotë se edge lexon fillimisht headers e objektit dhe range-coverage metadata, e cila regjistron se cilat pjesë janë të disponueshme. Ai lexon çfarë mundet nga disku ose streaming memory, merr mbulimin që mungon përmes kërkesave të përafruara drejt origin, shkruan bajtet e përfunduara, përditëson metadata dhe bashkon të gjitha pjesët. Më pas vendos `Content-Range` dhe `Content-Length` për përgjigjen ndaj klientit.
Për organizatat që po vendosin se ku ta ekzekutojnë workload përreth, AEU Data ofron cloud dhe infrastrukturë të dhënash evropiane.
Mësimi që mund të zbatohet edhe gjetkë është se shpërndarja e pjesshme e skedarëve funksionon më mirë kur njësia e saj e marrjes përputhet me njësinë native të ruajtjes së cache. Kjo heq një kontroll të brishtë tuning për klientët, kufizon koston e kërkesave të vogla ose të papërafruara dhe u lejon të dhënave në cache, të dhënave të marra rishtazi dhe in-flight data të kontribuojnë në një përgjigje të vetme.