Ce se întâmplă când scrii un URL în browser

Tastezi reprofil.ro în bara de adrese, apeși Enter și, de obicei în mai puțin de o secundă, pagina apare pe ecran. Între cele două momente au loc zeci de pași: rezolvare DNS, conexiuni criptate, cereri HTTP, servere intermediare, cache-uri și un motor de randare care transformă text în pixeli. Ghidul de față îi parcurge pe rând, la nivelul de detaliu de care ai nevoie la un interviu tehnic sau atunci când depanezi un site lent.

1. Browserul interpretează ce ai scris

Prima decizie: ai scris o adresă sau un termen de căutare? Dacă textul nu arată ca un domeniu sau ca un URL (de exemplu cum învăț programare), bara de adrese îl trimite motorului de căutare implicit. Dacă arată ca o adresă, browserul îl completează până la un URL complet.

Un URL are mai multe componente. Pentru https://www.reprofil.ro:443/roadmaps?filtru=backend#resurse:

Componentă	Valoare	Rol
Schema	https	Protocolul folosit
Host	www.reprofil.ro	Domeniul care trebuie tradus în adresă IP
Port	443	Implicit 443 pentru HTTPS și 80 pentru HTTP, de aceea rar îl vezi
Path	/roadmaps	Resursa cerută de la server
Query	?filtru=backend	Parametri suplimentari
Fragment	#resurse	Poziția în pagină; nu ajunge niciodată la server

Înainte să iasă vreun pachet din calculator, browserul mai face câteva verificări:

• HTTPS implicit. Dacă ai scris doar reprofil.ro, browserele moderne încearcă mai întâi varianta securizată.
• HSTS. Dacă domeniul a trimis anterior header-ul Strict-Transport-Security sau se află pe lista HSTS preload inclusă în browser, orice adresă http:// este transformată intern în https://, fără nicio cerere nesecurizată.
• Domenii cu diacritice. Un nume precum școală.ro este convertit într-o formă ASCII numită Punycode, care începe cu xn--, pentru că DNS-ul lucrează cu caractere ASCII.
• Cache-ul local. Dacă resursa este deja în cache-ul browserului și este încă validă, rețeaua poate fi sărită complet. Un service worker înregistrat de site poate și el să intercepteze cererea și să răspundă direct.

2. DNS: de la nume la adresă IP

Calculatoarele comunică prin adrese IP, nu prin nume. Sistemul DNS (Domain Name System) face traducerea, iar căutarea trece prin mai multe niveluri, de la cel mai apropiat la cel mai îndepărtat:

1. Cache-ul DNS al browserului.
2. Sistemul de operare: propriul cache și fișierul hosts (/etc/hosts pe Linux și macOS, C:\Windows\System32\drivers\etc\hosts pe Windows).
3. Resolver-ul recursiv: de obicei al furnizorului de internet sau unul public, precum 1.1.1.1 sau 8.8.8.8.
4. Căutarea iterativă, dacă nici resolver-ul nu are răspunsul în cache. Acesta întreabă un root server, care îl trimite la serverele TLD pentru .ro (administrate de RoTLD), care la rândul lor indică serverele autoritative ale domeniului reprofil.ro. Acestea dau răspunsul final.

Fiecare răspuns vine cu un TTL (time to live), adică numărul de secunde cât poate fi păstrat în cache. De aceea o modificare de DNS nu se vede instantaneu peste tot.

Tipurile de înregistrări pe care le vei întâlni cel mai des:

Tip	Ce conține
A	Adresa IPv4
AAAA	Adresa IPv6
CNAME	Un alias către alt nume de domeniu
MX	Serverele de e-mail ale domeniului
TXT	Text arbitrar: verificări de domeniu, SPF, DKIM
NS	Serverele autoritative pentru domeniu
HTTPS	Parametri de conexiune, de exemplu suportul pentru HTTP/3 (RFC 9460)

Poți vedea singur răspunsul:

dig reprofil.ro A

;; ANSWER SECTION:
reprofil.ro.        300     IN      A       203.0.113.10

Adresa din exemplu face parte dintr-un interval rezervat pentru documentație, iar 300 este TTL-ul în secunde. Pe Windows, dacă nu ai dig, folosește nslookup reprofil.ro sau Resolve-DnsName reprofil.ro în PowerShell.

Un detaliu modern: browserele pot trimite interogările DNS criptat, prin DNS over HTTPS (DoH), astfel încât rețeaua locală să nu vadă ce domenii accesezi.

3. Conexiunea: TCP, TLS și QUIC

Cu adresa IP în mână, browserul deschide o conexiune cu serverul. Numărul de „drumuri dus-întors” (round trips, RTT) necesare depinde de protocol, iar pe o conexiune mobilă fiecare RTT poate însemna zeci sau chiar sute de milisecunde.

TCP: three-way handshake

TCP garantează că datele ajung complete și în ordine. Înainte de orice, cele două părți se sincronizează:

Client  ── SYN ─────────▶  Server
Client  ◀───── SYN-ACK ──  Server
Client  ── ACK ─────────▶  Server

TLS: canalul criptat

Peste TCP, browserul negociază TLS. Cu TLS 1.3, versiunea curentă, handshake-ul durează un singur RTT:

• ClientHello: browserul trimite algoritmii suportați, o cheie publică temporară, numele domeniului dorit (SNI, Server Name Indication, necesar când pe același IP stau mai multe site-uri) și protocoalele de aplicație acceptate (ALPN, de exemplu h2 sau http/1.1).
• ServerHello: serverul alege parametrii și trimite certificatul.
• Browserul verifică certificatul: este emis pentru acest domeniu, nu a expirat și este semnat, printr-un lanț de certificate, de o autoritate de certificare (CA) în care are încredere. Dacă oricare verificare eșuează, apare avertismentul de securitate pe tot ecranul.
• Din cheile schimbate, ambele părți derivă chei simetrice, iar de aici încolo tot traficul este criptat.

În TLS clasic, SNI circulă necriptat, deci rețeaua vede la ce domeniu te conectezi. O extensie mai nouă, Encrypted Client Hello (ECH), ascunde și această informație, acolo unde browserul și serverul o suportă.

HTTP/3 și QUIC

HTTP/3 renunță la TCP și folosește QUIC, un protocol construit peste UDP care combină handshake-ul de transport cu cel TLS 1.3. O conexiune nouă este gata după un singur RTT, iar la reconectare clientul poate trimite date chiar din primul pachet (0-RTT). Browserul află că serverul suportă HTTP/3 din header-ul Alt-Svc al unui răspuns anterior sau din înregistrarea DNS HTTPS. Dacă UDP este blocat în rețea, revine la TCP.

Versiune	Transport	Mai multe cereri pe aceeași conexiune
HTTP/1.1	TCP	Nu în paralel; browserele deschid mai multe conexiuni
HTTP/2	TCP + TLS	Da, multiplexate, dar un pachet pierdut întârzie toate fluxurile
HTTP/3	QUIC peste UDP	Da, iar un pachet pierdut afectează doar fluxul lui

4. Cererea HTTP

Conexiunea este gata, așa că browserul trimite cererea propriu-zisă. În formatul text al HTTP/1.1 arată așa:

GET /roadmaps HTTP/1.1
Host: reprofil.ro
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...
Accept: text/html,application/xhtml+xml
Accept-Language: ro-RO,ro;q=0.9,en;q=0.8
Accept-Encoding: gzip, br, zstd
Cookie: session=abc123

• Metoda (GET) și path-ul spun ce vrei.
• Host spune ce site, pentru că același server poate găzdui multe domenii.
• Header-ele Accept-* anunță ce formate, limbi și algoritmi de compresie înțelege browserul.
• Cookie trimite cookie-urile salvate pentru acest domeniu, de exemplu identificatorul sesiunii tale.

În HTTP/2 și HTTP/3 aceleași informații circulă în cadre binare comprimate, cu pseudo-header-e precum :method, :path și :authority. Formatul text de mai sus este doar cel mai ușor de citit.

5. Drumul cererii pe partea de server

Rareori cererea ajunge direct la codul aplicației. Un traseu tipic:

1. CDN (Content Delivery Network): un server apropiat geografic de tine poate răspunde direct din cache pentru fișiere statice sau chiar pentru pagini întregi.
2. Load balancer: distribuie cererile între mai multe instanțe ale aplicației.
3. Reverse proxy (de exemplu Nginx): termină conexiunea TLS, comprimă răspunsurile, servește fișiere statice.
4. Serverul de aplicație: identifică ruta, verifică sesiunea, rulează logica de business, interoghează baza de date sau un cache precum Redis și construiește răspunsul, fie HTML randat pe server, fie JSON pentru o aplicație client.

Timpul scurs între trimiterea cererii și sosirea primului octet din răspuns se numește TTFB (Time to First Byte). Un TTFB mare indică de obicei probleme pe server: interogări lente, lipsa cache-ului sau un server aflat foarte departe de utilizator.

6. Răspunsul HTTP

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Cache-Control: public, max-age=0, must-revalidate
ETag: "a1b2c3"
Strict-Transport-Security: max-age=31536000; includeSubDomains
Set-Cookie: theme=dark; Path=/; Secure; SameSite=Lax

<!doctype html>
<html lang="ro">
...

Codul de status spune rezultatul. Familiile lor merită știute pe de rost:

Familie	Sens	Exemple
1xx	Informațional	103 Early Hints
2xx	Succes	200 OK, 204 No Content
3xx	Redirecționare	301, 302, 304 Not Modified, 308
4xx	Eroare a clientului	400, 401, 403, 404, 429
5xx	Eroare a serverului	500, 502, 503, 504

La un 301 sau 308 (de exemplu de la reprofil.ro la www.reprofil.ro), browserul ia procesul de la capăt pentru noua adresă, de aceea redirecționările în lanț costă timp. Header-ele Cache-Control și ETag decid dacă la următoarea vizită browserul va cere din nou resursa, o va revalida (și va primi un 304, fără body) sau o va reutiliza direct din cache.

7. Randarea: de la HTML la pixeli

Browserul nu așteaptă tot documentul. Începe să-l proceseze pe măsură ce sosesc octeții:

1. Parsing HTML → DOM. Textul devine un arbore de noduri, Document Object Model.
2. Preload scanner. Un parser secundar caută din timp resursele (<link>, <script>, <img>) și le cere în paralel. Pentru fiecare domeniu nou se repetă pașii DNS, TCP și TLS, de aceea contează câte domenii terțe încarci.
3. CSS → CSSOM. Stilurile devin propriul lor arbore. CSS-ul blochează randarea: browserul nu afișează nimic până nu are stilurile din <head>.
4. JavaScript. Un <script> obișnuit oprește parsing-ul până se descarcă și se execută. Cu defer, execuția este amânată până după parsing, păstrând ordinea; cu async, scriptul rulează imediat ce sosește; scripturile type="module" sunt amânate implicit.
5. Render tree, layout, paint, composite. DOM-ul și CSSOM-ul se combină în arborele elementelor vizibile, se calculează poziția și dimensiunea fiecăruia (layout), se desenează pixelii (paint), iar straturile rezultate sunt compuse, adesea pe GPU.

<head>
  <link rel="stylesheet" href="/styles.css">
  <script src="/app.js" defer></script>
</head>

Când documentul a fost parcurs integral se declanșează evenimentul DOMContentLoaded, iar după ce s-au încărcat și imaginile și celelalte resurse, evenimentul load. Experiența reală a utilizatorului se măsoară astăzi prin Core Web Vitals: LCP (cât de repede apare conținutul principal), INP (cât de repede răspunde pagina la interacțiuni) și CLS (cât de stabil rămâne layout-ul în timpul încărcării).

Cum vezi totul cu ochii tăi

Nu trebuie să crezi pe cuvânt nimic din cele de mai sus:

• DevTools → Network. Deschide-l cu F12, reîncarcă pagina și dă click pe prima cerere. Tab-ul Timing arată separat DNS Lookup, Initial connection, SSL, Waiting for server response (TTFB) și Content Download. Activează coloana Protocol ca să vezi h2 sau h3.
• DevTools → Performance. Înregistrează o încărcare și vei vedea parsing-ul, execuția JavaScript, layout-ul și paint-ul pe o axă a timpului.
• curl în terminal. curl -v https://reprofil.ro afișează conexiunea, handshake-ul TLS și header-ele, iar comanda de mai jos măsoară fiecare etapă:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://reprofil.ro

Valorile sunt cumulative, măsurate de la începutul cererii. În PowerShell scrie curl.exe în loc de curl și NUL în loc de /dev/null. Rulează comanda de două ori și compară: a doua oară DNS-ul vine de obicei din cache.

Pentru detalii despre fiecare header și cod de status, referința de bază este documentația MDN despre HTTP, iar metricile de performanță sunt explicate pe web.dev.

Pașii următori

• Dacă te atrage partea vizibilă (randare, performanță, JavaScript), continuă cu roadmap-ul Frontend.
• Dacă te interesează ce se întâmplă după ce cererea ajunge la server, mergi pe roadmap-ul Backend și apoi pe System Design, unde CDN-urile, load balancer-ele și cache-urile devin subiecte de sine stătătoare.
• Exercițiu practic: alege trei site-uri pe care le folosești zilnic, analizează-le în tab-ul Network și notează protocolul, TTFB-ul și numărul de domenii contactate. Dacă te blochezi, întreabă tutorele AI de pe reprofil.ro.