CDN ოპტიმიზაცია და ლატენტობა

1) შეფერხებების მიზნები და რუკა

Latency = DNS + TCP/TLS + TTFB (სერვერი/ორიგინალი/ქეში) + შინაარსის მიწოდება (RTT × მოცულობა) + კლიენტის გამყიდველი.
ოპტიმიზაცია = შეამცირეთ RTT რაოდენობა, შეამცირეთ ბაიტი და გადაიტანეთ გამოთვლები/ქეში მომხმარებელთან ახლოს.

2) CDN არქიტექტურა

Anycast POPs არის BGP მარშრუტიზაციის მახლობლად.
Tiered caching/Origin Shield არის „ქოლგის“ შუალედური ფენა, რომელიც ამცირებს მის ქარიშხალს ორიგენზე.
Geo/Regional Routing - ტენანტის/იურისდიქციის კავშირი (მონაცემთა სუვერენიტეტი, ლიცენზია).
Failover - სარეზერვო origin/რეგიონი, Health ტესტები და სწრაფი შეცვლა.

3) კეში: გასაღებები, სათაურები, სტრატეგიები

3. 1 ქეშის გასაღებები

სტანდარტულად: 'scheme + host + path +? query'.
დაამატეთ მხოლოდ საჭირო პარამეტრები ('? v =', '? lang =', '? tenant ='). დანარჩენი ignore-params- შია.
'Vary' - მინიმალური: 'Accept-Encoding', 'Accept-Enanguage' (საჭიროების შემთხვევაში), 'Authorization' ჩვეულებრივ არღვევს ქეშს.

3. 2 პოლიტიკა

საზოგადოებრივი სტატიკა: 'Cache-Control: public, max-age = 31536000, immutable' + rev (სახელით hash).
ნახევარ დინამიკა (კატალოგები, წესები, FAQ): 's-maxage = 300, stale-while-revalidate = 600, stale-if-error = 86400'.
API-GET: გამოიყენეთ ETag/Last-Modified, 'SWR/SIE', ჩართეთ ცხელი გასაღები (ერთი მოთხოვნა).
პირადი: პირადი პასუხები - პერიმეტრზე edge-compute (ESI/kv) ან წინა ტენანტი ქეში.

3. 3 ანტი-ქარიშხალი

Request coalescing - ერთდროული მოთხოვნების დაჭერა.
Serve-stale - მოძველებული ობიექტის მიცემა ორიგენის ჩამოგდების დროს.
Background revalidation - განახლება ფონზე.

4) HTTP/2-3, TCP/TLS და ადრეული დაბრუნება

HTTP/2: მულტიპლექსი, სათაურების შეკუმშვა; შეზღუდეთ 'max concurrent streams', დიდი სათაურები.
HTTP/3 (QUIC): TTFB- ის დიდი ვარდნა მობილური/მაღალი დანაკარგებით; მიჰყევით Initial ბარიერებს და Retry- ს.
TLS 1. 3: 1-RTT handshake; OCSP stapling; HSTS.
0-RTT: მხოლოდ idempotent 'GET "- ისთვის და თუ გათვალისწინებულია replay რისკები.
103 Early Hints: ადრეული 'Link: rel = preload' კრიტიკული რესურსებისთვის.
Preconnect / DNS-prefetch: `<link rel="preconnect" href="https://cdn. example">`.

5) Edge-compute და „თხელი პერსონალიზაცია“

ზღვარზე: სათაურების აღწერილობა, გეო/ტენანტი ფიქსაცია, A/B ეტიკეტი, მსუბუქი პერსონალიზაცია ორიგენისთვის მოთხოვნის გარეშე.
წესი: არ შეინახოთ PII POP კვანძებზე; მხოლოდ დანაყოფების/საჯარო მონაცემების გადახდა.

6) მედიისა და ფორმატის ოპტიმიზაცია

სურათები: ავტომატური კონვერტაცია WebP/AVIF, resize-on-edge, 'srcset/sizes', 'lazyload'.
კომპრესია: Brotli ტექსტებისთვის (HTML/CSS/JS/JSON), gzip fallback.
ვიდეო: HLS/DASH, CDN შეკრების განყოფილება, 'preload = metadata', პლაკატი.
შრიფტები: subset + 'font-display: swap'; ჰოსტინგი გრძელი ქეში.
კრიტიკული CSS: პირველი ეკრანის ინლაინი; დანარჩენი async.

7) API ნიმუშები და ქეშირება

Idempotent GET - ქეშირი მოთხოვნის ღილაკებზე (მონაცემთა ვერსიის ჩათვლით).
ETag: ძლიერი დატვირთვის ჰაში + 'If-None-Match'.
Surrogate-Control (CDN სპეციფიკა) კლიენტის „Cache-Control“ - სგან განსხვავებით.
Signed SET - პირადი სტატიკის/მედიისთვის.
GraphQL: ნორმალიზებული ქეშის გასაღები ოპერაციისთვის/ცვლადი; გამოიყენეთ partial caching/resolver ქეში.
WebSockets: რეალური დროისთვის - შეამცირეთ შეტყობინებები, შეკუმშეთ (permessage-deflate), გქონდეთ WS საშინელება მომხმარებელთან უფრო ახლოს.

8) კონფიგურაციის მაგალითები

8. 1 NGINX (origin: API-GET ქეშირი)

nginx
We give SWR and ETag location/api/v1/catalog/{
proxy_cache api_cache;
proxy_cache_key "$scheme$request_method$host$uri$is_args$args";
proxy_cache_valid 200 5m;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
add_header Cache-Control "public, s-maxage=300, stale-while-revalidate=600, stale-if-error=86400";
add_header ETag $upstream_http_etag;
proxy_ignore_headers Set-Cookie; # do not break the Set-Cookie proxy_hide_header cache;
proxy_pass http://catalog;
}

8. 2 Fastly VCL (SWR, coalescing, ignore cookies)

vcl sub vcl_recv {
set req. hash_ignore_busy = true;   # coalescing if (req. url. qs ~ "^(?!.(lang    v)=)") { remove req. url. qs; }
if (req. http. Cookie) { remove req. http. Cookie; }
}

sub vcl_backend_response {
set beresp. ttl = 300s;
set beresp. stale_if_error = 86400s;
set beresp. stale_while_revalidate = 600s;
if (beresp. http. Set-Cookie) { unset beresp. http. Set-Cookie; }
}

8. 3 Cloudflare (Transform Rules, Cache Rules, Early Hints — псевдо)

json
{
"cache_rule": {
"if": "http. request. uri. path matches \"/assets/.\"",
"action": {"cache": {"eligibility":"eligible", "ttl": 31536000}}
},
"transform_rule": {
"set_headers": [{"name":"Cache-Control","value":"public, s-maxage=300, stale-while-revalidate=600"}]
},
"early_hints": {"enable": true}
}

9) მობილური ქსელები და „არასტაბილური“ ინტერნეტი

აგრესიულად გამოიყენეთ HTTP/3; შეამცირეთ კრიტიკული ბილიკის ზომა (HTML + კრიტიკული CSS <14 KB).
Priority H2/H3: დაადგინეთ პრიორიტეტები (მოგვიანებით HTML).
Retray პოლიტიკა ჯიტერთან, idempotence for API.
Size-budgets და bundling: კოდი splitting, deferred JS, გამოუყენებელი CSS/JS მოცილება.

10) დაკვირვება და SLO

RUM: TTFB, LCP, INP, CLS რეგიონებში/ASN/ტენანტები; განაწილება p95/p99.
სინთეზური: საკონტროლო მარშრუტი „/health/cdn “POP- ის გასწვრივ.
ქეშის მეტრიკა: hit-ratio overall და per-key; origin fetch rate; coalescing savings.
ალერტები: hit-ratio ვარდნა, origin-egress ზრდა, H3 წილის დეგრადაცია, 5xx shield.

11) iGaming/ფინანსების სპეციფიკა

თამაშების კატალოგები/კოეფიციენტები: მოკლე 's-maxage' + SWR; region-aware ключ (`tenant|region|lang`).
ღონისძიების მწვერვალები (მატჩები, გათამაშებები): ქეში (pre-warm) დათბობა, მძიმე პერსონალიზაციის „გაყინვა“, mirror წყაროები.
გადახდის/კაბინეტი: არ დააჩქაროთ პირადი, მაგრამ დააჩქაროთ H3 + edge-TLS და ახლო რეგიონი.
იურისდიქციები: განცალკევებული დომენები/პრეს-რეგიონი; კონტროლი 'Vary: X-Region'.

12) ანტიპატერები

'Vary:' ყველაფერი ზედიზედ; ქეშის გასაღები დამოკიდებულია ზედმეტი ქუქი-ფაილებზე/სათაურებზე.
SWR/SIE- ს არარსებობა არის „შავი ეკრანები“, რომელთა მოკლე ორიგენული წარუმატებლობაა.
ქეში „ყველაფერზე“ გაწმენდა წერტილოვანი ინვალიდობის ნაცვლად ჭდეებში/გასაღებებში.
რესურსები სახელების გადამოწმების გარეშე და „max-age = 0“.
გლობალური deny-cache „Authorization“ - ისთვის, თუნდაც იქ, სადაც public ენიჭება.
Coalescing- ის არარსებობა - ქარიშხალი ორიგინზე.
ნაადრევი „მძიმე“ პერსონალიზაცია POP- ზე.

13) მზადყოფნის ჩეკის სია

Anycast POP + tiered/shield; ჯანმრთელობის შემოწმება და origin failover.
ქეშის გასაღებები მინიმალურია; ზედმეტი query/cookies- ის უგულებელყოფა; 'Surrogate-Control'.
SWR/SIE შედის, coalescing აქტიურია; serve stale შეცდომების დროს.
HTTP/3 ჩართულია; TLS 1. 3; 103 Early Hints შექმნილია კრიტიკული რესურსებისთვის.
სურათები: AVIF/WebP, resize-on-edge; ბროტლი ტექსტებისთვის.
API-GET с ETag/Last-Modified; idempotence/retrai; არ გადაიხადოთ პირადი პროფილები.
Preconnect სტატიკის დომენებზე; კრიტიკული CSS ინლაინი.
მეტრიკა: hit-ratio, origin-egress, TTFB/LCP p95, H3 წილი, რეგიონების/ტენანტების მიხედვით.
ქეშის დათბობის გეგმა მოვლენების წინ; წერტილოვანი ინვალიდობა (ჭდეები).
Vary/keys/TTL დოკუმენტაცია; ინციდენტების ფლეიბუკი (hit-ratio ვარდნა).

14) TL; DR

შეამცირეთ კამპანიები origine: tiered/shield + რეგულარული cache-keys + SWR/SIE + coalescing. ჩართეთ HTTP/3/TLS 1. 3, გამოიყენეთ 103 Early Hints და preconnect. შეკუმშეთ და გადააკეთეთ მედია ზღვარზე, შეინარჩუნეთ კრიტიკული CSS. API- სთვის - ETag, სისუფთავე 'Vary', იდემპოტენტობა და გონივრული ქეშირება 'GET'. გაზომეთ hit-ratio, TTFB/LCP p95, origin egress და წინასწარ გაათბეთ ქეში მწვერვალებზე.

CDN ოპტიმიზაცია და ლატენტობა

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით