Šta se zapravo dogodi za 500 ms nakon što korisnik ukuca tutorijali.app?

Naslovna ilustracija je shematska. Ne prikazuje izmerene faze ni garantovano trajanje.

Ažurirano: 5. oktobar 2026.

Od jednog unosa u browser do DNS rezolucije, šifrovane QUIC konekcije, CDN edge čvora, prvih bajtova HTML-a i piksela na ekranu.

Korisnik unese tutorijali.app u adresnu traku i pritisne Enter. Ubrzo se pojavi stranica. Između te dve radnje browser može da proveri više keševa, pronađe ili ponovo upotrebi mrežnu vezu, dogovori šifrovanje, pošalje zahtev edge čvoru, primi HTML i počne da ga prikazuje. Neke faze se preskoče, neke se preklapaju, a neke se odvijaju paralelno.

Zato je „prvih 500 ms“ koristan način da se priča ispriča, ali nije štoperica. 500 ms nije univerzalno vreme učitavanja niti fiksni raspored protokola. Stvarni rezultat zavisi od keša browsera i operativnog sistema, postojeće konekcije, DNS resolvera, mreže, geografskog rutiranja, gubitka paketa, edge čvora, servera, sadržaja i uređaja.

500 ms kao mapa, ne kao raspored

Vremenska linija iznad prikazuje moguće faze jednog učitavanja. Ona ne tvrdi da DNS uvek potroši 80 ms, da ECH sledi posle DNS-a u tačno određenom trenutku ili da CDN mora da kontaktira origin. Browser može već imati važeći DNS odgovor i otvorenu HTTP/2 ili HTTP/3 konekciju. Service Worker može da vrati odgovor bez izlaska na mrežu. CDN može da vrati keširani sadržaj. Parser može da počne obradu HTML-a pre nego što je ceo dokument preuzet.

Kod hladnijeg scenarija više posla zaista stane između Entera i prvog odgovora. Kod toplijeg scenarija deo toga se preskoči ili ponovo upotrebi. „Hladno“ i „toplo“ zato traže opis uslova: HTTP keš može biti prazan, ali DNS keš i konekcija i dalje topli; otvoren DevTools može isključiti HTTP keš, ali ne mora da isprazni sistemski resolver ili da ukloni sve prethodno naučene parametre QUIC-a.

01Browser prvo razume adresu

Adresna traka nije samo tekstualno polje za URL. Browser određuje da li unos predstavlja adresu ili pretragu, parsira scheme, ime hosta, port, putanju i query parametre, a zatim primenjuje pravila navigacije. Kod https://tutorijali.app/post/... fragment poput #izvori ostaje u browseru i ne šalje se serveru u HTTP zahtevu.

Pre mrežnog poziva browser može da proveri HSTS pravilo, istoriju, predkeširane resurse, ekstenzije, Service Worker i postojeću konekciju. HSTS nalaže HTTPS za hostove koje pokriva, ali to nije isto što i opšte pravilo da svaki tekstualni unos automatski postane isti zahtev. Omnibox može da predloži pretragu, a browser može da nadogradi navigaciju na bezbedniji scheme prema lokalnoj politici.

HTTP keš, Service Worker, DNS keš i konekcioni pool su različite stvari. Ako serveru pripada odgovor koji je još svež u HTTP kešu, browser možda neće slati novi zahtev za taj resurs. Ako postojeća konekcija je još upotrebljiva, browser može da šalje zahtev njome bez novog TCP ili QUIC uspostavljanja. Ti slučajevi menjaju i ono što čitalac vidi u DevTools-u.

02Kako ime domene postaje odredište

DNS je distribuiran sistem zapisa. Browser ili sistemski resolver traži informacije za host, obično adresne zapise kao što su A za IPv4 i AAAA za IPv6. U praksi odgovor može doći iz više nivoa keša: browsera, operativnog sistema, lokalnog mrežnog uređaja ili rekurzivnog resolvera.

Kada resolver već ima važeći odgovor, pun put do root, TLD i autoritativnih servera ne ponavlja se za svaki zahtev. Ako mu podatak nedostaje, rekurzivni resolver može sam da prati delegacije i pribavi odgovor. Browser obično pita resolver koji mu je konfigurisan, a ne kontaktira direktno root server. TTL u DNS zapisima ograničava koliko dugo se odgovor sme zadržati u kešu; stvarne implementacije imaju dodatne politike.

Browseri i sistemi mogu paralelno da traže IPv4, IPv6 ili dodatne zapise. Ako je dostupno više odredišta, mehanizmi izbora adrese mogu pokušati različite putanje. Zbog toga jedan red „DNS Lookup“ u Network panelu nije nužno potpun prikaz svih DNS aktivnosti koje su uticale na navigaciju.

DNS i DNS over HTTPS rešavaju različite probleme

DNS opisuje upit i odgovor za ime domene. DNS over HTTPS (DoH) opisuje način prenosa DNS poruka kroz HTTPS vezu do izabranog DoH resolvera. Slično tome, DNS over TLS (DoT) i DNS over QUIC (DoQ) koriste druge šifrovane prenose. DoH ne menja značenje A ili AAAA zapisa; štiti kanal između DoH klijenta i tog resolvera.

Šifrovan kanal otežava lokalnom mrežnom posmatraču čitanje konkretnog DNS upita. Resolver kome je upit poslat i dalje obrađuje ime domena, a odredišna IP adresa i drugi obrasci saobraćaja mogu ostati vidljivi. DoH zato nije sinonim za anonimnost. DNSSEC rešava drugo pitanje: kriptografsku proveru autentičnosti DNS podataka. DoH i DNSSEC su nezavisni i mogu se koristiti zajedno.

HTTPS/SVCB zapisi i ECH konfiguracija

HTTPS i SVCB su DNS zapisi koji mogu da opišu dostupnu uslugu, kao što su alternativno ime hosta, port, ALPN protokoli i drugi parametri. U odgovarajućoj konfiguraciji mogu da prenesu i ECH konfiguraciju. To je mogući put do podešavanja, ne obavezna dodatna stanica svakog učitavanja.

Encrypted Client Hello (ECH) omogućava browseru da šifruje unutrašnji ClientHello za server. Time se štite SNI (Server Name Indication) i neka druga polja TLS rukovanja. Spoljašnji ClientHello i dalje postoji, a ECH je zamišljen tako da više servisa može pripadati istoj grupi za anonimnost. Zaštita zato zavisi od konfiguracije, podrške klijenta i prihvatanja na serveru.

ECH ne skriva IP adresu, ne skriva sve metapodatke i ne sprečava resolver da vidi ime koje mu je zatraženo. Ako ECH konfiguracija nije dostupna ili server je odbije, rezultat nije ravnopravan sa uspešno prihvaćenim ECH-om. U martu 2026. objavljen je RFC 9849 za TLS Encrypted Client Hello, a RFC 9848 opisuje bootstrapping ECH-a preko DNS Service Binding zapisa.

03QUIC, TLS 1.3 i HTTP/3 čine jedan povezani put

Kada browseru treba nova konekcija, moguća su dva česta slučaja:

• HTTP/3 koristi QUIC, standardizovan transport preko UDP-a. QUIC koristi TLS 1.3 ili noviji TLS za kriptografsko rukovanje, a dogovoreni ALPN protokol može biti h3.
• HTTP/2 se najčešće koristi preko TCP-a i TLS-a. ALPN vrednost može biti h2.

Nije ispravno zamišljati QUIC rukovanje pa odvojeno, potpuno sekvencijalno TLS rukovanje kao dve nezavisne konekcije. TLS poruke su integrisane u QUIC rukovanje. Ako HTTP/3 nije dostupan ili put preko UDP-a ne radi, browser može da koristi drugi ponuđeni protokol. Podrška i izbor se zato proveravaju na konkretnoj konekciji, ne zaključuju iz samog postojanja TLS-a.

QUIC multiplexuje tokove, pa gubitak paketa koji pripada jednom toku ne mora da zaustavi napredak svih ostalih tokova na isti način kao gubitak u jednoj TCP vezi. I dalje postoje kašnjenja zbog retransmisije, zagušenja, servera i uređaja. HTTP/3 može da pomogne u nekim mrežama, ali nije uvek brži od HTTP/2. Rezultat zavisi od latencije, gubitka paketa, implementacije i toga da li je konekcija nova ili nastavljena.

TLS 1.3 i QUIC podržavaju nastavak prethodne sesije. U nekim slučajevima klijent može da pošalje 0-RTT podatke pre dovršetka novog rukovanja. To nije univerzalno dostupno ni bezbedno za svaki zahtev: server mora da omogući prihvatanje ranih podataka, a mogući su replay napadi. Aplikacioni protokol mora da ograniči koji su zahtevi prihvatljivi za takav prenos.

04Zahtev stiže do edge-a, keša ili origin-a

Pošto su odredište i upotrebljiva konekcija poznati, browser šalje HTTP zahtev. Kod HTTPS-a zaglavlja i telo zahteva šifrovani su na putu između krajeva TLS veze. U browseru, DevTools-u i serveru mogu se videti u zavisnosti od pristupa i konfiguracije; pasivni posmatrač običnog TLS saobraćaja ne dobija ih kao čitljiv tekst.

CDN veže sadržaj za distribuirane edge tačke i mehanizme keširanja. Saobraćaj može da stigne do edge-a koji odgovara mrežnom rutiranju, anycast-u i provajderskim pravilima, a ne nužno do čvora koji je geografski najbliži u pravoj liniji. Za kešabilan zahtev edge može vratiti HIT; kod MISS ili dinamičkog sadržaja može pozvati origin, dobiti odgovor i vratiti ga browseru. Personalizovani sadržaj, kolačići, Cache-Control, Vary, autorizacija i podešavanje platforme utiču na rezultat.

„Origin“ označava logički izvor sadržaja; ne mora biti jedna fizička mašina dostupna direktno sa interneta. CDN može terminirati TLS, proslediti zahtev drugom sloju ili primeniti drugačiji put po ruti. Zaglavlje odgovora može dati trag, ali jedno zaglavlje nije potpuna mapa arhitekture.

05Šta TTFB meri, a šta ne meri

Time to First Byte (TTFB) meri vreme od početka navigacije do trenutka kada browser primi prvi bajt odgovora dokumenta. U Navigation Timing API-ju to se izračunava kao responseStart - startTime. Vrednost zato može uključiti preusmeravanja, DNS, uspostavljanje veze, TLS/QUIC rukovanje, slanje zahteva i čekanje na početak odgovora.

TTFB nije čisto serversko procesiranje. Deo vremena može da potroši put do edge-a i nazad, a Service Worker ili lokalni keš mogu da promene šta se meri. DevTools termin „Waiting (TTFB)“ opisuje čekanje na prvi bajt posle slanja zahteva, dok TTFB za glavnu navigaciju često prikazuje širi interval. Browseri i paneli ne grupišu sve faze identično.

Jedno zabeleženo učitavanje tutorijali.app

U jednom Chrome učitavanju rute https://tutorijali.app/tutorijali, zabeleženom 5. oktobra 2026, PerformanceNavigationTiming.nextHopProtocol vratio je h2. Isto merenje dalo je sledeće vrednosti:

Ovo je jedan browser, jedna ruta i jedna mrežna sesija. Rezultati nisu očekivane vrednosti za svakog čitaoca i ne dokazuju da HTTP/3 nikad nije dostupan: potvrđuju samo da je ta navigacija koristila h2. Browser Performance API takođe ne potvrđuje da je ECH prihvaćen. Za ovaj uzorak nisu zabeleženi cold/warm par, Firefox rezultat ni ponovljena merenja; postupak u nastavku omogućava njihovo zasebno prikupljanje pod kontrolisanim uslovima.

Windows Resolve-DnsName upit tokom pregleda vratio je A zapise 64.29.17.2 i 216.198.79.66, oba sa TTL-om 1800 sekundi. Upiti za AAAA i CNAME nisu vratili odgovarajući Answer zapis. Cloudflare DoH upit za HTTPS i SVCB zapise za tutorijali.app takođe nije vratio Answer zapis. Ovo su odgovori dva konkretna resolvera u jednom trenutku; ne isključuju drugi DNS put, alternativnu isporuku ECH konfiguracije niti kasniju promenu zapisa.

Odvojeni curl.exe -I -L HTTP HEAD upit ka glavnoj adresi vratio je HTTP/1.1 200 sa zaglavljima Server: Vercel i X-Vercel-Cache: STALE. To je jedan odgovor za HEAD, ne dokaz da svaki GET, ruta ili cache ključ prolazi istim putem. curl.exe --version u ovom okruženju ne navodi HTTP/2 ni HTTP/3 podršku, pa nije mogao da posluži za proveru tih protokola. Kasniji curl -vI pokušaj zaustavljen je pre TLS rukovanja, jer okruženje nije dozvolilo TCP vezu. Zbog toga iz ovog terminala nisu nezavisno potvrđeni verzija TLS-a, detalji sertifikata, redirect chain ni HTTP/3 podrška.

06Kako da se čita Network waterfall

Chrome DevTools Network panel beleži zahteve koji se dese dok panel prati stranicu. Svaki red predstavlja resurs, a Waterfall prikazuje njihov vremenski odnos. Red dokumenta obično predstavlja glavni HTML; redovi za CSS, JavaScript, fontove, slike i API odgovore mogu da se preklapaju.

Za jednu navigaciju korisno je pregledati:

• Name i Type: koji je resurs zatražen i koje je vrste;
• Status: HTTP rezultat, uključujući preusmeravanje, uspeh ili grešku;
• Protocol: h2 ili h3 za konkretan zahtev kada ga browser izloži;
• Initiator: kod ili resurs koji je pokrenuo zahtev;
• Size: veličinu odgovora i napomene o kešu;
• Timing: DNS, connection start, slanje zahteva, čekanje i preuzimanje, kada ih browser može izdvojiti.

Chrome može da prikaže DNS vreme kao 0 kada je odgovor bio u kešu ili DNS merenje nije izdvojeno; konekcija može biti ponovo upotrebljena. U Firefox Network Monitor-u nazivi i grupisanje faza mogu se razlikovati. HTTPS-om zaštićen sadržaj ostaje šifrovan na mreži, dok browserov Network panel posmatra zahteve pre ili posle šifrovanja.

Uredan waterfall nije dokaz da su faze serijske. CSS i slike mogu da se preuzimaju paralelno, HTTP/2 i HTTP/3 mogu multiplexovati više tokova, a browser može da šalje preconnect, prefetch ili preload zahteve pre nego što parser dođe do odgovarajuće oznake.

Vrednosti prikazuju jednu zabeleženu navigaciju /tutorijali; grafikon nije screenshot DevTools-a niti univerzalno očekivanje.

07Meri se i trenutak prikaza

DOMContentLoaded, load, First Contentful Paint (FCP) i Largest Contentful Paint (LCP) odgovaraju na različita pitanja:

• DOMContentLoaded se emituje pošto je glavni HTML dokument parsiran i odgovarajuće odložene skripte su izvršene. Ne čeka sve slike i podresurse.
• load čeka završetak učitavanja zavisnih resursa koji učestvuju u tom događaju, ali ne govori da li je stranica korisniku već delovala brza.
• FCP označava prvi prikaz teksta, slike ili drugog sadržajnog elementa.
• LCP prati vreme prikaza najvećeg relevantnog sadržajnog elementa u vidljivom delu stranice; kandidat može da se promeni tokom učitavanja.

Browser može da obrađuje HTML dok bajtovi stižu. HTML parser gradi DOM, CSS se obrađuje u CSSOM-u, a browser može da otkrije resurse unapred. CSS može da odloži prvi prikaz, a parser-blocking skripta može da zadrži parser. Posle stilova slede računanje layout-a, paint i compositing slojeva. Detalji implementacije razlikuju se među browserima; ova podela je koristan model, ne obavezna lista diskretnih faza.

Prvi piksel, prvi sadržajni paint i najveći sadržajni paint nisu sinonimi. Browser može već da prikaže naslov dok se velika slika još preuzima; ili stranica može vizuelno da se menja posle FCP-a. Sam load događaj nije zamena za Core Web Vitals.

08Ponovljiv eksperiment u Chrome-u i Firefox-u

Za poređenje hladnijeg i toplijeg učitavanja korisnik prvo beleži iste uslove: browser i verziju, rutu, mrežu, vreme, cache podešavanje i da li je postojao raniji zahtev. Jedan prolaz ne predstavlja tipičan rezultat; više ponavljanja i medijana daju korisniju sliku.

Chrome DevTools

1. Korisnik otvara DevTools pre ponovnog učitavanja i bira Network.
2. Preserve log se uključuje samo kada treba zadržati redove preko preusmeravanja ili navigacije.
3. Korisnik uključuje kolonu Protocol ako nije prikazana i posmatra h2 ili h3 uz glavni document red.
4. Sa uključenim Disable cache, korisnik ponavlja navigaciju i beleži glavnu stavku, Status, Size i Timing. Ova opcija važi dok su DevTools otvoreni.
5. Korisnik isključuje Disable cache i ponavlja isti URL radi poređenja sa browser HTTP kešom.
6. U odvojenom prolazu korisnik pregleda Performance panel za parsing, script work, FCP/LCP i layout događaje.

Disable cache nije kompletan „cold internet“ prekidač: DNS keš, postojeća konekcija, TLS resumption, QUIC stanje, edge keš i OS ponašanje mogu da ostanu relevantni. Za bolju izolaciju koristan je privremeni browser profil i svež proces, uz napomenu da keš u sistemu, resolveru i CDN-u i dalje može biti topao. Application → Service Workers može da pokaže da li Service Worker učestvuje; testiranje njegovog zaobilaženja treba posebno zabeležiti.

Firefox Developer Tools

Firefox Network Monitor prikazuje zahteve, waterfall, status, veličinu i detalje kao što su DNS resolution, connecting, sending, waiting i receiving. Firefox nije učestvovao u ovom merenju; ovaj pregled njegovih alata služi za zaseban uporedni test. Za HTTPS zahtev postoji i Security prikaz detalja veze. Redosled kolona i terminologija nisu potpuno isti kao u Chrome-u, pa se poređenje oslanja na definiciju metrike, ne na identičan naziv dugmeta.

Performance API u konzoli

Ovaj primer čita metrike poslednje navigacije dokumenta u aktivnoj kartici. On ne šalje podatke nigde; vrednosti ostaju u browseru dok ih čitalac sam ne kopira ili prosledi.

const nav = performance.getEntriesByType('navigation')[0];
const paint = performance.getEntriesByType('paint');

console.table({
  protocol: nav?.nextHopProtocol || 'nije izložen',
  dnsMs: nav ? nav.domainLookupEnd - nav.domainLookupStart : null,
  connectionMs: nav ? nav.connectEnd - nav.connectStart : null,
  requestToFirstByteMs: nav ? nav.responseStart - nav.requestStart : null,
  ttfbMs: nav ? nav.responseStart - nav.startTime : null,
  domContentLoadedMs: nav ? nav.domContentLoadedEventEnd - nav.startTime : null,
  loadMs: nav ? nav.loadEventEnd - nav.startTime : null,
  firstContentfulPaintMs:
    paint.find((entry) => entry.name === 'first-contentful-paint')?.startTime ?? null,
});

Ako je DNS keširan ili se postojeća konekcija koristi, DNS ili connection interval mogu biti nula. Nula ne znači nužno da protokol ne postoji. Ako navigacija unutar Next.js aplikacije pređe na drugu rutu bez ponovnog učitavanja dokumenta, Navigation Timing može i dalje opisivati prvobitni dokument. FCP se može pročitati iz Paint Timing zapisa; LCP se prikuplja preko PerformanceObserver-a:

new PerformanceObserver((list) => {
  const candidate = list.getEntries().at(-1);
  if (candidate) console.log('LCP kandidat:', candidate.startTime, candidate.element);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Za svaki uzorak korisno je sačuvati rutu, vreme, browser, protokol, cache uslove i informaciju o Service Worker-u. Sama jedna brojka bez tih uslova retko objašnjava uzrok.

09Terminal i DNS provera

curl --version pokazuje koje protokole lokalni curl build podržava. Za običan odgovor može se proveriti status i zaglavlja; rezultat HEAD zahteva nije identičan GET navigaciji.

curl.exe --version
curl.exe -I -L https://tutorijali.app/
curl.exe -sS -L -o NUL -w "http=%{http_version} status=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s`n" https://tutorijali.app/

--http2 ili --http3-only mogu se dodati kada ih lokalni build podržava. Ako opcija nije dostupna ili QUIC/UDP nije prohodan, greška opisuje ograničenje probe, ne nužno podršku browsera ili servera. CLI TTFB i Chrome Navigation Timing takođe nisu ista merenja.

Windows Resolve-DnsName može da proveri uobičajene A i AAAA zapise:

Resolve-DnsName -Name tutorijali.app -Type A
Resolve-DnsName -Name tutorijali.app -Type AAAA

Podrška za tip HTTPS u toj komandi zavisi od verzije Windows DNS alata. U prethodnoj proveri ovog okruženja korišćen je eksplicitni DoH upit Cloudflare resolveru za tip HTTPS; to je odgovor tog resolvera u jednom trenutku, ne potpuni pogled na svaki browser ili DNS put.

10Šta Wireshark vidi, a šta ne

Packet capture može da pokaže adrese izvora i odredišta, vreme, veličinu paketa, DNS upite koji nisu šifrovani, TCP/TLS tokove ili UDP/QUIC tokove. Tačan prikaz zavisi od interfejsa, filtera, verzije Wireshark-a, protokola i toga da li je klijent izvezao ključeve sesije.

U ovom okruženju wireshark.exe i tshark.exe nisu pronađeni u PATH-u, pa nije snimljen capture za tutorijali.app. U nastavku su navedene mogućnosti protokola, a ne rezultati snimka saobraćaja ovog sajta.

Shematski prikaz, a ne Wireshark capture tutorijali.app. HTTP/3 zaglavlja i telo ostaju šifrovani bez odgovarajućih session secrets i dekripcije.

Kod HTTPS-a sadržaj HTTP zahteva i odgovora po pravilu nije čitljiv u pasivnom capture-u. Wireshark može da dešifruje podržanu sesiju kada su dostupni odgovarajući session secrets i kada isti saobraćaj postoji u capture-u. To nije isto što i razbijanje TLS-a. QUIC takođe šifruje podatke aplikacije; vidljivost pojedinih početnih polja ne znači da je HTML plaintext.

Praktičan pregled može da koristi display filtere kao što su dns, tls, quic, tcp.port == 443 ili udp.port == 443. Za DoH se DNS sadržaj obično ne pojavljuje kao običan DNS paket, već kao HTTPS saobraćaj ka resolveru. ECH štiti unutrašnji ClientHello, dok spoljni metapodaci poput IP adrese ostaju relevantni.

Key log fajl može omogućiti dekripciju za podržani browser i sesiju, ali sadrži tajne koje daju pristup šifrovanom saobraćaju iz te sesije. Takav fajl i povezani capture ne dele se javno; njihovo korišćenje pripada kontrolisanom, sopstvenom testu.

Jedna slika za kraj

Sledeća shema sažima moguću putanju. Keš može da preskoči DNS ili mrežu; HTTP/2 je moguća alternativa HTTP/3; origin se kontaktira samo kada to traže cache pravila ili aplikacija. Na telefonu slika može da se uveća dodirom.

Shematski dijagram mogućih grana, ne vremensko merenje jedne sesije.

tutorijali.app → URL parsing → browser / OS keš?
                                  ├─ odgovor ili postojeća konekcija
                                  └─ DNS cache? → DNS / DoH → HTTPS/SVCB → ECH?
                                                      → QUIC + TLS 1.3 / HTTP/3
                                                      ili TCP + TLS / HTTP/2
                                                      → CDN edge → HIT ili MISS → origin
                                                      → HTML → DOM + CSSOM → layout
                                                      → paint → compositing → piksel

Često postavljana pitanja

Šta se prvo dešava kada se ukuca web adresa?

Browser najpre parsira unos i proverava važeće lokalno stanje, bezbednosna pravila i keš. DNS nije nužno prvi mrežni događaj, a ponekad novog mrežnog događaja uopšte nema.

Da li DNS uvek mora da se izvrši?

Ne. Browser, operativni sistem ili rekurzivni resolver mogu već imati važeći odgovor, a browser može koristiti postojeću konekciju.

Koja je razlika između DNS-a i DoH-a?

DNS je sistem upita i zapisa. DoH prenosi DNS poruke kroz HTTPS vezu do konfigurisanog resolvera; sam po sebi ne obezbeđuje anonimnost.

Šta ECH skriva?

ECH šifruje unutrašnji ClientHello i štiti SNI i druga polja koja bi inače mogla biti vidljiva. Zaštita zavisi od dostupne konfiguracije i prihvatanja na serveru.

Da li ECH skriva IP adresu?

Ne. Mrežni posmatrač i dalje može da vidi IP adresu sa kojom se uređaj povezao, kao i deo metapodataka saobraćaja.

Da li HTTP/3 koristi TCP?

Ne. HTTP/3 koristi QUIC, koji se prenosi preko UDP-a. HTTP/2 se najčešće prenosi preko TCP-a i TLS-a.

Da li je QUIC samo UDP?

Ne. UDP je transportni protokol ispod QUIC paketa; QUIC definiše tokove, pouzdanu isporuku podataka, upravljanje zagušenjem, konekcije i integraciju sa TLS-om.

Da li je HTTP/3 uvek brži od HTTP/2?

Ne. Rezultat zavisi od mreže, gubitka paketa, ponovne upotrebe konekcije, servera i implementacije. Protokol treba proveriti na konkretnom zahtevu.

Šta je TTFB?

TTFB je vreme od početka navigacije do prvog bajta odgovora. Može obuhvatiti mrežu, DNS, konekciju, TLS/QUIC, preusmeravanja i čekanje na odgovor; nije samo vreme rada aplikacije na serveru.

Zašto DevTools nekada prikazuje DNS kao 0 ms?

Odgovor možda dolazi iz DNS keša, korišćena je postojeća konekcija ili browser nije izdvojio zasebno merenje. Nula ne dokazuje da DNS kao sistem nije učestvovao ranije.

Zašto TLS vreme nekada ne postoji kao posebna faza?

Konekcija je možda ponovo upotrebljena, rukovanje je obavljeno van intervala koji panel prikazuje ili browser grupiše QUIC/TLS događaje drugačije. Navigation Timing nije packet trace.

Kako se proverava da li sajt koristi HTTP/3?

U Chrome DevTools Network panelu proverava se kolona Protocol za konkretan zahtev; vrednost može biti h3. U Firefox-u se proveravaju detalji konkretnog zahteva. Jedan h2 rezultat ne govori da HTTP/3 nikada nije ponuđen.

Može li Wireshark da pročita HTTPS sadržaj?

Ne iz običnog capture-a bez ključeva sesije. Dekripcija može biti moguća kada je podržani browser izvezao odgovarajuće session secrets i capture sadrži istu sesiju.

Kada browser počinje da renderuje HTML?

Često počinje dok bajtovi još stižu: parser gradi DOM, obrađuju se stilovi i otkrivaju resursi. Tačan trenutak prvog vidljivog prikaza zavisi od HTML-a, CSS-a, skripti i browsera.

Da li 500 ms znači da je ceo sajt učitan?

Ne. 500 ms je samo didaktički okvir. Prvi paint, LCP, DOMContentLoaded i load predstavljaju različite događaje, a sadržaj može nastaviti da se preuzima i menja posle prvog piksela.

Zaključak: jedan Enter pokreće distribuiran sistem

Korisnik vidi jednu radnju: unos adrese i pritisak na Enter. Browser može zatim da uskladi lokalne keše, sistemski resolver, DNS infrastrukturu, TLS ili QUIC, HTTP, edge čvor, origin, HTML parser, JavaScript engine i compositor. U posmatranom Chrome uzorku tutorijali.app/tutorijali koristio je HTTP/2 i TTFB od 181,1 ms; drugi browser, ruta ili naredno učitavanje mogu dati drugačiji rezultat.

Suština nije u jednoj vrednosti od 500 ms. Moderni web je paralelan, keširan, ponovo upotrebljava konekcije i često šifruje sadržaj. Prvi piksel je vidljivi kraj nekoliko koordinisanih procesa, a ne potvrda da je svaki resurs završen ili da se svaka moguća faza dogodila.

Izvori i dalja provera

• RFC 1034 - Domain Names: Concepts and Facilities
• RFC 8484 - DNS Queries over HTTPS
• RFC 9076 - DNS Privacy Considerations
• RFC 9460 - SVCB and HTTPS Resource Records
• RFC 9848 - Bootstrapping TLS ECH with DNS Service Bindings
• RFC 9849 - TLS Encrypted Client Hello
• RFC 8446 - TLS 1.3
• RFC 9000 - QUIC transport
• RFC 9001 - Using TLS to Secure QUIC
• RFC 9114 - HTTP/3
• Chrome DevTools: Network panel
• Firefox Developer Tools: Network Monitor request details
• MDN: Navigation and resource timings
• MDN: PerformanceNavigationTiming
• web.dev: Largest Contentful Paint
• WHATWG HTML Standard: parsing
• Wireshark User’s Guide