DEV Community: Jamal Ali

HTTP cache header-larını düzgün qurmaq

Jamal Ali — Sat, 29 Aug 2026 12:47:48 +0000

HTTP keşini “sürət düyməsi” kimi təsəvvür etmək rahatdır: max-age əlavə et, server yükü azalsın, səhifə də sürətlənsin. Problem ondadır ki, keş yanlış cavabı çox səmərəli şəkildə çoxalda da bilir. Bir istifadəçinin məlumatı başqasına görünəndə və ya köhnə HTML yeni JavaScript bundle-a işarə etməyəndə qazandığımız bir neçə millisaniyə artıq təsəlli vermir.

Fərq vacibdir.

Düzgün siyasət header adlarını əzbərləməklə qurulmur. Əvvəl hər resurs üçün üç suala cavab lazımdır: cavab nə qədər müddət dəyişmədən qala bilər, onu kimlər paylaşa bilər və köhnələndə origin serverlə yoxlanmalıdırmı? Üç sual. Qalan seçimlər onların cavabından çıxır.

Keşin iki ayrı işi var

HTTP cache cavabı saxlaya və sonrakı uyğun request-də yenidən istifadə edə bilər. Browser cache adətən bir istifadəçiyə xidmət edən private cache-dir. CDN və reverse proxy isə bir cavabı çox istifadəçiyə verən shared cache rolundadır. Eyni Cache-Control sətri hər ikisinə təsir edə bilər, amma onların riskləri eyni deyil.

Burada iki anlayış tez-tez qarışır: freshness və validation. Fresh cavabın müəyyən edilmiş ömrü hələ bitməyib, ona görə cache origin-ə getmədən onu işlədə bilər. Stale cavabın ömrü bitib. Bu, cavabın mütləq yararsız olması demək deyil; validator varsa cache kiçik conditional request göndərib nüsxəsinin hələ aktual olub-olmadığını soruşa bilər. RFC 9111 HTTP cache davranışını məhz saxlama, freshness və validation qaydaları üzərindən müəyyənləşdirir.

max-age=300 cavabın yaradıldığı və ya son uğurlu validation edildiyi andan beş dəqiqə sonra stale sayılacağını bildirir. Beş dəqiqə ərzində cache hit origin-ə request göndərməyə bilər. Bu müddəti yalnız trafikə baxıb seçmək yarımçıq yanaşmadır, çünki əsas ölçü biznesin həmin cavabın köhnəlməsinə nə qədər dözə bilməsi və yanlış məlumatın hansı əməliyyata təsir göstərməsidir.

Cache-Control: public, max-age=300

public cavabı açıq şəkildə cacheable edir və shared cache üçün də istifadəyə imkan yaradır. Hər public resursa bu direktivi əlavə etmək məcburi deyil, çünki bəzi cavablar onsuz da cacheable olur; API və CDN konfiqurasiyasında niyyəti aydın göstərmək isə yenə faydalıdır.

no-cache, no-store və private eyni şey deyil

Adına görə ən çox çaşdıran direktiv no-cache-dir. Cavabı saxlamağı qadağan etmir. Cache saxlanmış cavabı yenidən verməzdən əvvəl origin serverdə uğurla validate etməlidir. Bu, tez-tez dəyişən HTML üçün yaxşı seçim ola bilər: browser nüsxəni saxlayır, ETag ilə soruşur, məzmun dəyişməyibsə server body əvəzinə 304 Not Modified qaytarır.

Cache-Control: no-cache
ETag: "page-v42"

ETag cavab variantının identifikatorudur. Növbəti request If-None-Match header-ı ilə gedir. Serverdə təqdimat eynidirsə bütün body yenidən daşınmır, amma network gediş-gəlişi qalır; deməli validation bandwidth-i azalda bilər, latency-ni sıfırlamır.

no-store daha sərtdir: cache request və response-u saxlamamalı, həmin response-u başqa request-i cavablandırmaq üçün istifadə etməməlidir. Bank çıxarışı, birdəfəlik token və həssas şəxsi məlumat kimi cavablarda məntiqlidir. Bununla belə, no-store şifrələmə və access control əvəzi deyil, komprometasiya edilmiş cache və ya şəbəkədə dinləmə riskini bu header təkbaşına həll etmir.

private başqa sərhəd çəkir. Shared cache cavabı saxlamır, istifadəçinin private cache-i isə digər şərtlər imkan verirsə saxlaya bilər. Login olmuş istifadəçinin profil səhifəsi dəyişməz deyil, amma hər naviqasiyada bütün body-ni yenidən daşımaq da lazım olmaya bilər:

Cache-Control: private, no-cache
ETag: "profile-8d91"

Bu kombinasiya browser-ə cavabı saxlamağa, hər istifadədən əvvəl isə yoxlamağa imkan verir. Təkcə Set-Cookie görüb response-un cache edilməyəcəyini düşünmək təhlükəlidir, çünki Set-Cookie özü caching-i dayandırmır və siyasət Cache-Control ilə açıq yazılmalıdır.

Browser və CDN üçün ayrı ömür

Bəzən browser-in cavabı qısa müddət saxlaması, CDN-in isə daha uzun saxlaması məqsədəuyğundur. s-maxage yalnız shared cache üçün maksimum yaşı müəyyən edir və həmin cache-də max-age və Expires dəyərini üstələyir.

Cache-Control: public, max-age=60, s-maxage=600

Bu nümunədə browser bir dəqiqəlik freshness görür, CDN isə cavabı on dəqiqə fresh saya bilər. Risk də böyüyür. Daha uzun CDN ömrü bütün istifadəçilərə köhnə məlumat yayır, buna görə endpoint-in cavabı regiona, dilə və ya başqa request header-ına görə dəyişirsə cache key həmin fərqi mütləq bilməlidir.

Vary: Accept-Encoding cache-ə sıxılma variantlarını ayırmağı deyir. Vary: Accept-Language dilə görə ayrıca variant yaradır. Vary-də göstərilən request header-ları uyğun gəlmirsə saxlanmış cavab yoxlanmadan istifadə edilə bilməz. Hər şeyi Vary-yə əlavə etmək çıxış yolu deyil, variantların sayı artdıqca hit ratio düşür, cache-in faydası əriyir və xüsusən Vary: User-Agent çox geniş kombinasiya yarada bilər.

İstifadəçiyə görə dəyişən cavabı shared cache-də saxlamaq istəyərkən məsələ daha qəlizdir. Cache key həqiqətən istifadəçini ayırmırsa, public və uzun s-maxage təhlükəli seçimdir. Belə cavabı private saxlamaq və ya public hissə ilə fərdi hissəni ayrı endpoint-lərə bölmək daha aydın sərhəd yaradır.

Statik asset və HTML fərqli ömür istəyir

Content hash daşıyan app.a81f3c.js faylının məzmunu dəyişəndə adı da dəyişir. Bu tip immutable asset üçün uzun freshness uyğundur:

Cache-Control: public, max-age=31536000, immutable

Köhnə faylı zorla invalidasiya etməyə ehtiyac qalmır. Yeni deploy yeni URL yaradır, HTML də həmin URL-ə işarə edir. Amma hash daşımayan /app.js üçün eyni birillik siyasət deploy-dan sonra köhnə kodun uzun müddət qalmasına səbəb ola bilər; cache busting query parametrindən istifadə edilirsə parametr hər məzmun dəyişikliyində sabit qayda ilə dəyişməlidir.

HTML isə adətən qısa freshness və ya validation istəyir, çünki yeni asset ünvanlarını o daşıyır. HTML uzun müddət köhnə qalsa, serverdə artıq silinmiş bundle-a request gedə bilər. Release prosesi köhnə asset-ləri bir müddət saxlamaqla bu keçidi yumşalda bilər, lakin əsas siyasət yenə resursların dəyişmə modelinə uyğun olmalıdır.

Expires eyni məqsəd üçün tarix verir, amma max-age olduqda recipient Expires-ı nəzərə almır. Müasir konfiqurasiyada nisbi saniyə dəyəri deploy və saat fərqləri baxımından daha rahatdır. Header ümumiyyətlə verilməyəndə bəzi cache-lər heuristic freshness hesablaya bilər; davranışı infrastruktura buraxmaqdansa niyyəti açıq yazmaq daha proqnozlaşdırılandır.

Siyasəti production-da görmək

Konfiqurasiya faylında düzgün görünən header yolun sonunda dəyişə bilər. CDN qaydası origin header-ını əvəz edir, framework middleware-i yalnız bəzi status kodlarına işləyir, reverse proxy isə Vary sahəsini itirir. Ona görə yoxlama browser devtools ilə bitmir. Origin və CDN cavabları ayrıca izlənir, Age, Cache-Control, ETag, Vary və status kodu birlikdə oxunur.

Age shared cache-də cavabın təxmini yaşını saniyə ilə göstərir. Ardıcıl request-lərdə artması cavabın origin-dən yox, aradakı cache-dən gəldiyinə işarə edə bilər. Validation baş verəndə 304, fresh hit zamanı isə çox vaxt normal status və cache vendor-una aid əlavə hit header-ı görünür.

Keş siyasəti endpoint növünə görə sənədləşdiriləndə dəyişikliklər də təhlükəsiz olur: hashed asset uzunömürlüdür, HTML validate edilir, public kataloq cavabı qısa müddət shared cache-də qalır, şəxsi məlumat isə shared cache-dən uzaq tutulur. Eyni universal header daha az konfiqurasiya kimi görünür. Sonradan açdığı başağrısı isə xeyli universaldır.

Tez-tez verilən suallar

no-cache cavabın saxlanmasını qadağan edirmi?

Xeyr. no-cache cavabın sonrakı request üçün istifadə edilməzdən əvvəl origin serverdə uğurla yoxlanmasını tələb edir.

no-store ilə private arasında fərq nədir?

no-store cavabın cache-də saxlanmasını qadağan edir. private isə shared cache-i kənarda saxlayır, amma istifadəçinin browser cache-inə saxlamağa icazə verə bilər.

Dəyişməz statik fayllara uzun max-age vermək təhlükəlidirmi?

Faylın URL-i content hash və ya versiya daşıyırsa təhlükə xeyli azalır, çünki məzmun dəyişəndə URL də dəyişir. Eyni URL altında məzmun dəyişəcəksə uzun ömür uyğun deyil.

Mənbələr

Cisco ACE load balancer-i idarə edərkən nəyə baxmaq lazımdır?

Jamal Ali — Sat, 29 Aug 2026 09:34:53 +0000

Cisco ACE ilə işləyən administratorun qarşısında qəribə vəziyyət dayanır: cihaz zəngin funksiyalara malikdir, trafik yolunun tam ortasındadır, amma özü artıq keçmiş nəsil platformadır. Buna görə konfiqurasiyaya yalnız “request hansı serverə getsin?” sualı ilə baxmaq kifayət etmir. Tətbiqin sağlamlığı, session davranışı, SSL sərhədi və cihaz sıradan çıxanda baş verəcək hadisələr eyni xəritədə görünməlidir.

Problem də budur.

ACE 4710 ayrıca appliance kimi, ACE modulları isə şəbəkə avadanlığının daxilində application delivery funksiyası verirdi. Cisco bu iki məhsulu data center üçün load balancing və application delivery həlli kimi təsvir edir. Bu sinif cihaz client ilə backend arasında reverse proxy və ya Layer 4 load balancer rolunda dayanır; client virtual IP-yə qoşulur, ACE uyğun server farm-ı tapır, işlək real server seçir və bağlantını ora ötürür. Kağız üzərində sadədir. Production-da isə hər oxun öz state-i və nasazlıq ssenarisi var.

Trafik ACE-dən necə keçir?

Konfiqurasiyanı oxumağın rahat yolu ayrı-ayrı komandaları əzbərləmək deyil, obyektlər arasındakı yolu izləməkdir. Virtual IP xidmətin xarici ünvanıdır. Class map trafiki tanıyır, policy map həmin trafikə load balancing davranışı bağlayır, server farm backend hovuzunu saxlayır, real server isə konkret tətbiq instansiyasıdır. Health probe real serverin rotasiyada qalıb-qalmayacağına qərar verir.

Diaqram — orijinal məqalədə

Bu axında class map və policy map giriş trafikinin hansı xidmətə aid olduğunu müəyyən edir. Server farm seçildikdən sonra predictor işlək real serverlər arasından birini seçir. Cavab client-ə ACE üzərindən qayıdırsa, cihaz connection state-i saxlayır; asimmetrik routing yaranarsa paketlərin bir hissəsi bu state-dən yan keçə və bağlantı qırıla bilər. Deməli, routing dizaynı load balancer konfiqurasiyasından ayrı məsələ deyil.

Predictor serverin həqiqi yükünü həmişə bilmir

ACE-də round-robin və least connections davranışları fərqli məqsədlərə xidmət edir. Weighted round-robin standart predictor-dur. Weight böyükdürsə, server daha çox yeni bağlantı alır; eyni gücdə və oxşar workload daşıyan backend-lər üçün bu, proqnozlaşdırılması asan seçimdir.

Least connections açıq bağlantısı daha az olan serverə üstünlük verir. Uzunömürlü bağlantılar və qeyri-bərabər request müddətləri olan sistemdə bu, faydalı görünür, amma connection sayı CPU, yaddaş və ya queue dərinliyi deyil. On min yüngül keep-alive bağlantısı bəzən yüz ağır hesablama request-indən ucuz başa gəlir. Siqnal natamamdır.

Yeni serveri bir anda tam trafikə salmaq da yaxşı fikir deyil. ACE-nin least-connections predictor-u üçün slow start mexanizmi yeni real serverə əvvəlcə az bağlantı göndərir, sonra yükü tədricən artırır. Bu, cache-i soyuq olan və ya connection pool-u yenicə qurulan instansiyanın ilk saniyələrdə boğulmasının qarşısını ala bilər.

Hash əsaslı seçim başqa ehtiyacı həll edir. ACE ünvan, cookie, HTTP header və URL əsasında server seçə bilir. Müəyyən açar eyni backend-ə düşür. Açarlar bərabər paylanmırsa isə serverlərdən biri həddindən artıq yüklənə bilər, buna görə qərarı alqoritmin adı yox, tətbiqin real trafik forması müəyyən edir.

Health probe port yoxlamasından artıq olmalıdır

Probe-un işi backend-in trafik qəbul edib-etmədiyini müəyyənləşdirməkdir. ACE ICMP, TCP, HTTP, HTTPS, DNS və başqa yoxlama növləri ilə konfiqurasiya oluna bilir. TCP probe portun bağlantı qəbul etdiyini göstərir, daha artığını yox. Tətbiq database-ə çata bilmirsə və bütün request-lərə xəta qaytarırsa, açıq portun çox təsəllisi yoxdur.

HTTP probe üçün ayrıca, ucuz health endpoint seçmək daha düzgün siqnal verir. Endpoint tətbiqin trafik qəbul edə bildiyini yoxlamalıdır, amma hər probe-da bütün asılılıqlara ağır sorğu göndərməməlidir. Interval həddən artıq qısa, uğursuzluq həddi isə çox sərt seçiləndə qısa şəbəkə titrəyişi serverləri növbə ilə rotasiyadan çıxara bilər. Bu dəfə load balancer problemi azaltmır, özü trafik dalğası yaradır.

Server probe-dan keçməyəndə mövcud bağlantıların taleyi əvvəlcədən məlum olmalıdır. Yeni bağlantıları dayandırmaqla aktiv connection-ları dərhal sıfırlamaq eyni davranış deyil. Fərq böyükdür. Uzun download, WebSocket və ya stateful transaction daşıyan sistemdə istifadəçi bunu dərhal görür; nasazlıq testi buna görə backend-i söndürüb bir yeni request yoxlamaqla bitməməli, aktiv bağlantını, bərpanı və serverin yenidən rotasiyaya qoşulmasını da əhatə etməlidir.

Stickiness rahatlıq verir, sonra hesabını istəyir

ACE eyni client-in sonrakı bağlantılarını eyni real serverə bağlamaq üçün source IP, cookie, HTTP header və SSL session ID kimi stickiness üsullarını dəstəkləyir. Lokal yaddaşda session saxlayan köhnə tətbiq üçün bu, zəruri ola bilər; backend dəyişəndə istifadəçi login vəziyyətini itirmir.

Amma source IP stickiness NAT arxasındakı minlərlə istifadəçini bir serverə yığa bilər. Cookie əsaslı üsul daha dəqiqdir, bunun müqabilində cookie-nin müddəti, adı və təhlükəsizlik atributları idarə olunmalıdır. Server rotasiyadan çıxanda sticky qeydin hara yönələcəyi də ayrıca failover qərarıdır. Stateless tətbiq və ortaq session store mümkündürsə, load balancer-də yığılan bu gizli state-dən qurtulmaq sistemi xeyli sadələşdirir.

SSL termination tətbiq serverlərindən kriptoqrafik işi götürür və HTTP səviyyəli routing imkanı açır. RFC 7098 SSL reverse proxy-nin session boyu SSL, TCP və bəzən HTTP state-i saxladığını qeyd edir. State artır. Bunun əvəzində sertifikatın yenilənməsi, private key-in qorunması, cipher siyasəti və ACE-dən backend-ə gedən trafikin şifrələnib-şifrələnməməsi cihazın məsuliyyətinə çevrilir; load balancer trafik paylayan qutu olmaqdan çıxıb təhlükəsizlik sərhədinə çevrilir.

Əsas risk artıq cihazın yaşıdır

Cisco ACE üçün köhnəlmə nəzəri risk deyil. ACE ailəsi artıq retired və dəstəksiz platformadır. Üstəlik, CVE-2016-6399 qeydində ACE30 və ACE 4700 cihazlarında xüsusi SSL və ya TLS paketləri ilə uzaqdan denial-of-service yaradıb cihazı reload etməyin mümkün olduğu göstərilir. Bu ciddi fərqdir. İşlək cihaz dəstəklənən cihaz demək deyil.

Legacy ACE saxlanılırsa, inventarda yalnız model və IP ünvanı olmamalıdır. Software versiyası, konfiqurasiya backup-ı, lisenziyalar, sertifikatlar, ehtiyat cihaz, failover nəticəsi və cihazı əvəz edə biləcək platformaya keçid planı birlikdə sənədləşdirilməlidir. Xüsusilə SSL termination aktivdirsə, dəstəklənməyən proqram təminatını internet trafikinin qarşısında saxlamaq təhlükəsizlik riskini böyüdür.

Miqrasiyada ən asan hissə virtual IP yaratmaqdır. Çətin hissə illər ərzində yığılmış sticky qaydalarını, probe davranışını, timeout-ları, NAT siyasətini, SSL sertifikatlarını və qeyri-adi routing asılılıqlarını tapmaqdır. Mövcud konfiqurasiya obyekt-obyekt deyil, xidmət-xidmət xəritələnəndə boşluqlar daha tez görünür: hansı client gəlir, hansı qayda işə düşür, hansı backend seçilir, cavab hansı yolla qayıdır və nasazlıq zamanı aktiv bağlantı necə bağlanır.

Cisco ACE-ni idarə etmək bu gün daha çox legacy sistem mühəndisliyidir. Cihazın predictor və probe imkanları hələ də load balancing məntiqini öyrətmək üçün yaxşı modeldir, amma production qərarında əsas ölçü funksiyaların sayı yox, təhlükəsiz yenilənmə və bərpa imkanının qalıb-qalmamasıdır.

Tez-tez verilən suallar

Cisco ACE hələ production mühitində istifadə oluna bilərmi?

Texniki olaraq işlək cihaz mövcud trafiki daşıya bilər, lakin platforma rəsmi dəstəkdən çıxıb. Təhlükəsizlik yeniləmələri, ehtiyat hissə, vendor dəstəyi və bərpa müddəti nəzərə alınmadan onu production-da saxlamaq ciddi əməliyyat riskidir.

Round-robin ilə least connections arasında fərq nədir?

Round-robin yeni bağlantıları serverlər arasında növbə ilə paylayır. Least connections isə mövcud açıq bağlantı sayını nəzərə alaraq daha az bağlantısı olan serverə üstünlük verir.

Stickiness nə vaxt lazımdır?

Tətbiq session vəziyyətini yalnız lokal yaddaşda saxlayırsa, eyni istifadəçinin ardıcıl bağlantılarını eyni backend-ə yönəltmək lazım gələ bilər. Stateless tətbiqdə isə stickiness çox vaxt yükün qeyri-bərabər paylanmasına səbəb olur.