Ինչպես է աշխատում վեբը

01Ընդհանուր պատկերը՝ ռեստորանի անալոգիա

Պատկերացրեք, որ կայք այցելելը նման է պատվեր տալուն մի ռեստորանում, որտեղ երբեք չեք եղել։ Նախ գտնում եք հասցեն (DNS)։ Հետո գնում եք այնտեղ և սեղան ստանում (TCP կապ)։ Մատուցողի հետ պայմանավորվում եք գաղտնի լեզվի մասին, որպեսզի ուրիշ ոչ ոք չլսի (TLS)։ Պատվիրում եք մենյուից (HTTP հարցում)։ Խոհանոցը պատրաստում է (սերվերը կատարում է կոդը և հարցում անում տվյալների բազային)։ Մատուցողը բերում է ափսեն (HTTP պատասխան), և դուք այն դասավորում եք սեղանին ու սկսում ուտել (բրաուզերը parse և render է անում)։ CDN-ը ռեստորանի մասնաճյուղ է ձեր տան մոտ, որտեղ հայտնի ուտեստներն արդեն պատրաստ են։ Այս պատկերը պահեք մտքում․ ներքևի յուրաքանչյուր քայլ դրա մի մասն է։

• URL՝ https://example.com/products?page=2 = scheme + host + path + query։
• Client = բրաուզերը կամ հավելվածը, server = պատասխանող մեքենան։
• Էջերի մեծ մասի համար latency-ն (round-trip time) ավելի կարևոր է, քան bandwidth-ը։

02Քայլ 1–3՝ DNS, TCP և TLS

Բրաուզերին պետք է IP հասցե, ոչ թե անուն։ Այն ստուգում է իր քեշը, օպերացիոն համակարգը, հետո հարցնում recursive resolver-ին (ձեր ISP-ից, 1.1.1.1 կամ 8.8.8.8)։ Resolver-ը անցնում է root սերվերներով, հետո .com սերվերներով, հետո դոմենի authoritative nameserver-ներով և պատասխանը քեշավորում իր TTL-ի չափով։ IP-ն ունենալով՝ բրաուզերը բացում է TCP կապ 443 պորտին՝ եռաքայլ handshake-ով (SYN, SYN-ACK, ACK)։ Հետո աշխատում է TLS 1.3-ը․ բրաուզերն ու սերվերը համաձայնեցնում են բանալիները, իսկ սերվերը սերտիֆիկատով ապացուցում է իր ինքնությունը։ TLS 1.3-ին պետք է մեկ լրացուցիչ round trip․ HTTP/3-ը տրանսպորտն ու TLS-ը միավորում է մեկ QUIC handshake-ի մեջ UDP-ի վրա։ 100 ms latency ունեցող մոբայլ կապի դեպքում այս round trip-երն արդեն 200–300 ms են՝ նախքան HTML-ի առաջին բայթը, ահա թե ինչու են կարևոր վերաօգտագործվող կապերն ու մոտ գտնվող սերվերները։

1# See each phase of a real request with timings
2curl -o /dev/null -s -w "dns: %{time_namelookup}s
3tcp: %{time_connect}s
4tls: %{time_appconnect}s
5first byte: %{time_starttransfer}s
6total: %{time_total}s
7" https://example.com/

03Քայլ 4–6՝ հարցում, սերվեր, պատասխան

Անվտանգ կապով բրաուզերն ուղարկում է HTTP հարցում՝ մեթոդ (GET), path և header-ներ, օրինակ՝ Host, Accept-Language, cookie-ներ և քեշավորման ակնարկներ։ Սերվերի կողմում այն ընդունում է nginx-ի նման վեբ սերվերը։ Այն կարող է անմիջապես պատասխանել ստատիկ ֆայլով կամ հարցումը փոխանցել հավելվածին (Laravel՝ PHP-FPM-ի միջոցով, Node.js պրոցես), որը կատարում է բիզնես լոգիկան, կարդում է տվյալների բազան կամ քեշը և կառուցում HTML կամ JSON։ Պատասխանը վերադառնում է status code-ով (200, 301, 404, 500), header-ներով (Content-Type, Cache-Control, Set-Cookie) և body-ով, որը սովորաբար սեղմված է gzip-ով կամ Brotli-ով։ Time to First Byte-ը (TTFB) չափում է այս ամբողջ շրջանը՝ ցանց գումարած սերվերի աշխատանք։ Դանդաղ TTFB-ն սովորաբար նշանակում է դանդաղ query-ներ, քեշի բացակայություն կամ օգտատիրոջից հեռու գտնվող սերվեր։

1GET /products?page=2 HTTP/1.1
2Host: example.com
3Accept: text/html
4Accept-Encoding: br, gzip
5 
6HTTP/1.1 200 OK
7Content-Type: text/html; charset=utf-8
8Content-Encoding: br
9Cache-Control: public, max-age=60

04Քայլ 7՝ բրաուզերը կառուցում է էջը

Բրաուզերը կարդում է HTML-ը, մինչ այն հոսքով գալիս է, և կառուցում DOM-ը՝ էլեմենտների ծառ։ Երբ հանդիպում է CSS, ներբեռնում և parse է անում այն CSSOM-ի մեջ․ CSS-ը render-blocking է, քանի որ բրաուզերը չի նկարի առանց ոճերի բովանդակություն։ Դասական script թեգերը նույնպես արգելափակում են parsing-ը, եթե չունեն defer կամ async։ DOM-ն ու CSSOM-ը միավորվում են render tree-ի մեջ, հետո բրաուզերը հաշվում է layout-ը (չափեր և դիրքեր), նկարում պիքսելները և GPU-ի վրա composite անում շերտերը։ Պատկերները, ֆոնտերը և լրացուցիչ սկրիպտները բեռնվում են զուգահեռ։ JavaScript-ը կարող է հետո փոխել DOM-ը, ինչը կարող է կրկին layout առաջացնել։ Core Web Vitals-ը չափում է արդյունքը՝ LCP (որքան արագ է հայտնվում հիմնական բովանդակությունը), INP (որքան արագ է էջը արձագանքում մուտքին) և CLS (որքան են տարրերը ցատկոտում)։

• CSS-ը դրեք վաղ, սկրիպտները՝ defer-ով, իսկ պատկերներին տվեք width և height։
• Preload արեք hero պատկերն ու հիմնական ֆոնտը, lazy-load արեք այն, ինչ fold-ից ներքև է։
• Ավելի քիչ JavaScript գրեթե միշտ նշանակում է ավելի արագ և արձագանքող էջ։

05Որտեղ է տեղավորվում CDN-ը

CDN-ը (Content Delivery Network), օրինակ՝ Cloudflare, Fastly կամ CloudFront, սերվերներ ունի հարյուրավոր քաղաքներում։ Երբ ձեր DNS-ը ցույց է տալիս CDN-ը, այցելուի TLS handshake-ն ավարտվում է ամենամոտ edge սերվերում, հաճախ 10–30 ms հեռավորության վրա՝ 150 ms-ի փոխարեն։ Edge-ը քեշավորված ֆայլերը (պատկերներ, CSS, JS, երբեմն ամբողջական HTML էջեր) մատուցում է անմիջապես, և միայն cache miss-երն է փոխանցում ձեր origin սերվերին՝ տաք, վերաօգտագործվող կապով։ Շատ CDN-ներ ավելացնում են նաև DDoS պաշտպանություն, web application firewall և HTTP/3։ Գինը մեկ լրացուցիչ շերտ է, որը պետք է հասկանալ՝ քեշավորման կանոններ, SSL կարգավորումներ edge-ի և origin-ի միջև, և այն փաստը, որ ձեր սերվերն այժմ տեսնում է CDN-ի IP-ն, եթե չվերականգնեք այցելուի իրական IP-ն header-ից։

06Շղթայի debug-ը գործնականում

Երբ ինչ-որ բան սխալ է, գուշակելու փոխարեն հերթով ստուգեք յուրաքանչյուր օղակ։ Անունը resolve լինո՞ւմ է ճիշտ IP-ին։ Կարո՞ղ եք TCP կապ բացել 443 պորտին։ Սերտիֆիկատը վավե՞ր է այս hostname-ի համար։ Ի՞նչ status code և header-ներ են վերադառնում։ Սերվե՞րն է դանդաղ (բարձր TTFB), թե՞ բրաուզերը (երկար scripting կամ rendering DevTools-ում)։ Բրաուզերի Network tab-ը ցույց է տալիս DNS-ի, connect-ի, TLS-ի, սպասման և ներբեռնման ժամանակը յուրաքանչյուր ֆայլի համար։ Performance tab-ն ու Lighthouse-ը ցույց են տալիս parsing-ը, layout-ը և paint-ը։ Սերվերում access և error լոգերը ցույց են տալիս՝ հարցումն ընդհանրապես հասե՞լ է, թե ոչ։

1dig +short example.com A           # 1. DNS
2nc -vz example.com 443             # 2. TCP port open?
3openssl s_client -connect example.com:443 -servername example.com </dev/null | head -n 20   # 3. TLS
4curl -sI https://example.com/      # 4. status + headers
5sudo tail -f /var/log/nginx/access.log   # 5. did it reach the server?

07Ինչու են առաջին 14 KB-ը կարևոր. TCP slow start

Նոր TCP կամ QUIC կապը չգիտի, թե որքան արագ է ճանապարհը, դրա համար սկսում է զգուշորեն։ Ուղարկողը կարող է «օդում» պահել մոտ տասը փաթեթ (սկզբնական congestion window, մոտ 14 KB), հետո պետք է սպասի հաստատումներին, իսկ հետո յուրաքանչյուր round trip-ում կրկնապատկում է այդ ծավալը, քանի դեռ ոչինչ չի կորչում։ Այսինքն՝ թարմ կապով 100 KB HTML փաստաթուղթը պահանջում է մի քանի round trip, ոչ թե մեկ, նույնիսկ արագ գծում։ Ահա թե ինչու critical CSS-ը inline անելը և HTML-ի վերին մասը փոքր պահելը արագացնում են առաջին նկարումը, և ինչու վերօգտագործվող, արդեն «տաքացած» կապերն այդքան ավելի արագ են թվում։ Փաթեթների կորուստը ստիպում է ուղարկողին նորից փոքրացնել պատուհանը, ահա թե ինչու կորուստներով մոբայլ ցանցերն ավելի շատ են վնասում, քան ցույց են տալիս bandwidth-ի թվերը։ Ժամանակակից congestion control-ը, օրինակ BBR-ը, կորուստներին ավելի լավ է արձագանքում, քան հին ալգորիթմները, բայց round trip-ների ֆիզիկան մնում է։

• Փոքր, սերվերում ռենդեր արված HTML-ը critical CSS-ով ավելի շուտ է նկարվում։
• Կապի վերօգտագործումը (keep-alive, HTTP/2 multiplexing) հաջորդ հարցումների համար շրջանցում է slow start-ը։
• Յուրաքանչյուր լրացուցիչ origin նշանակում է նոր DNS lookup, handshake և «սառը» պատուհան։

08Ինչպես է բրաուզերը որոշում, թե ինչն առաջինը բեռնել

Բրաուզերները ռեսուրսները չեն բեռնում էջի հերթականությամբ։ Մինչ հիմնական parser-ը սպասում է script-ին, preload scanner-ը առաջ է կարդում «հում» HTML-ը և սկսում է բեռնել իր գտած նկարները, stylesheet-ները և script-ները։ Յուրաքանչյուր հարցում ստանում է առաջնահերթություն. CSS-ը և blocking script-ները բարձր են, viewport-ի նկարները բարձրացվում են layout-ից հետո, async script-ները և էջի ներքևի նկարները ցածր են։ Սա կարելի է կառավարել։ rel=preload-ը բեռնում է այն, ինչ scanner-ը չի տեսնում, օրինակ՝ font, որին հղում կա միայն CSS-ի ներսում։ fetchpriority=high-ը LCP նկարը նշում է որպես կարևոր։ 103 Early Hints-ը թույլ է տալիս սերվերին կամ CDN-ին preload հղումներն ուղարկել դեռ HTML-ի պատրաստ լինելուց առաջ՝ օգտագործելով սերվերի «մտածելու» ժամանակը։ Թակարդը չափազանց օգտագործելն է. եթե ամեն ինչ բարձր առաջնահերթություն ունի, ուրեմն ոչինչ չունի, իսկ չօգտագործվող ֆայլերի preload-ը կրիտիկական ճանապարհին bandwidth է վատնում։

1<!-- In the <head>: help the browser find critical files early -->
2<link rel="preconnect" href="https://cdn.example.com" crossorigin>
3<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
4<img src="/img/hero.avif" width="1200" height="630" fetchpriority="high" alt="Product hero">
5<img src="/img/footer.webp" width="400" height="300" loading="lazy" alt="Team photo">
6<script src="/js/app.3f9a1c.js" defer></script>

09Քեշի շերտերը օգտատիրոջ և տվյալների բազայի միջև

Հարցմանը կարելի է պատասխանել բազմաթիվ շերտերում, և յուրաքանչյուրն ավելի էժան է հաջորդից։ Բրաուզերում՝ back/forward cache-ը ամբողջ էջերը պահում է հիշողության մեջ՝ ակնթարթային «հետ» նավիգացիայի համար, memory և HTTP disk cache-երը ֆայլեր են պահում ըստ Cache-Control-ի, service worker-ը կարող է պատասխանել իր սեփական քեշից, նույնիսկ offline։ Հետո CDN edge-ն է, երբեմն origin-ի առջև ռեգիոնալ շերտով։ Origin-ում nginx-ի նման reverse proxy-ն կարող է քեշավորել ամբողջական պատասխաններ (microcaching-ը մի քանի վայրկյանով կլանում է տրաֆիկի պիկերը)։ Հավելվածի ներսում Redis-ը կամ memory cache-ը պահում են հաշվարկված տվյալներ, իսկ բազան ունի իր buffer pool-ը։ Ինժեներական հարցը միշտ նույնն է. որտե՞ղ կարելի է այս պատասխանն ապահով վերօգտագործել, ո՞ւմ համար և որքա՞ն ժամանակ։ Անհատականացված տվյալները կարող են ապրել միայն այն քեշերում, որոնց key-ը կապված է տվյալ օգտատիրոջ հետ։

10Վստահությունը շղթայի երկայնքով. ինչը կարելի է կեղծել

Յուրաքանչյուր քայլ ինչ-որ բանի վստահում է։ Սովորական DNS պատասխանները թշնամական ցանցում կարելի է կեղծել, դրա համար էլ գոյություն ունի DNSSEC-ը, իսկ գաղտնագրված DNS-ը (DNS over HTTPS կամ TLS) lookup-ները թաքցնում է լոկալ ցանցից։ Իրական պաշտպանությունը, սակայն, TLS-ն է. նույնիսկ եթե DNS-ը ձեզ սխալ IP ուղարկի, հարձակվողը չի կարող ներկայացնել example.com-ի վավեր սերտիֆիկատ, և բրաուզերը կանգ կառնի։ HSTS-ը վերացնում է առաջին ոչ անվտանգ http:// հարցումը, որը հարձակվողը կարող էր որսալ։ Բրաուզերի ներսում same-origin policy-ն թույլ չի տալիս մի կայքին կարդալ մյուսի տվյալները, SameSite-ով cookie-ները սահմանափակում են cross-site հարցումները, իսկ Content-Security-Policy-ն սահմանափակում է, թե որ script-ները կարող են աշխատել։ Սերվերի կողմում հարցման ամեն ինչ (header-ներ, cookie-ներ, X-Forwarded-For) օգտատիրոջ input է, քանի դեռ վստահելի proxy-ն չի երաշխավորել դրա համար։