Késleltetés és hibák a kérés útján

Célok

A lecke végére meg tudod mondani, miből tevődik össze egy oldal betöltési ideje, el tudod különíteni a HTTP előtti és utáni hibákat, és a tünetből ki tudod választani a megfelelő vizsgálati pontot.

Miért nem elég azt mondani, hogy „lassú az internet”?

Ha egy oldal lassú vagy nem nyílik meg, a „rossz az internet” nem elég pontos magyarázat. A névfeloldás, a kapcsolatépítés, a TLS, a szerver válasza, a további erőforrások és a böngésző munkája külön-külön okozhat késést vagy hibát. A megoldás is más: DNS-hiba esetén a névrendszert, lassú szervernél az alkalmazást kell vizsgálni. Aki a tünethez a megfelelő réteget tudja rendelni, gyorsabban jut el az okig.

A késleltetés fogalma

A késleltetés (latency) az az idő, ami egy kérés elindítása és az eredmény megérkezése között telik el. Több összetevője van:

• terjedési idő: a jel fizikai útja; a távolsággal nő. Ezt nem lehet gyorsabb hardverrel megkerülni, csak közelebb vitt tartalommal (CDN, 4.4).
• kapcsolatfelépítés: a névfeloldás, a TCP- és a TLS-kézfogás körbejárásai (4.2).
• szerveroldali feldolgozás: az alkalmazás adatot keres, más szolgáltatásra vár.
• átvitel: a válasz mérete osztva az átviteli sebességgel.
• böngészős feldolgozás: DOM, stílus, elrendezés, JavaScript (3.3).

Az előző lecke mérése azt mutatta, hogy ugyanazt az oldalt kétféleképp elérve más a lépések aránya. Egy távolabbi szolgáltatás mérése (három mérés a www.wikipedia.org címről ugyanarról a gépről, másodpercben):

dns=0.0041 tcp=0.0461 tls=0.0979 ttfb=0.1517 total=0.2615
dns=0.0047 tcp=0.1341 tls=0.1894 ttfb=0.2475 total=0.3782
dns=0.0069 tcp=0.0514 tls=0.1105 ttfb=0.2522 total=0.3678

A TCP-kapcsolat ideje (tcp − dns) 42 és 129 ms között ingadozott, miközben az example.com-nál 9–11 ms volt. A távolság és a hálózati állapot hatása tehát jól látszik; az is, hogy ugyanaz a mérés nem ismétlődik pontosan. Ezért nem egy mérést, hanem eloszlást érdemes nézni (lásd 10.3).

A szakaszok nem mindig adódnak egyszerűen össze: néhány erőforrás párhuzamosan töltődik, egy korábbi kapcsolat vagy gyorsítótári válasz lépéseket takarít meg, máskor egy erőforrás csak egy előző fájl feldolgozása után fedezhető fel. Ezért a konkrét oldal idővonalát kell vizsgálni, nem általános szabályt felmondani.

Ugyanaz a tünet, eltérő ok

Egy hallgató a kurzusoldalt megnyitná, de sokáig üres képernyőt lát. Az ok lehet, hogy a DNS nem ad választ, a kapcsolat lassan jön létre, a szerver dolgozik sokáig, vagy a HTML megérkezett, de a böngésző egy fontos stíluslapra vagy programra vár.

flowchart TD
    T[Lassú vagy hibás oldal] --> D[DNS-válasz?]
    D --> C[Kapcsolat és TLS?]
    C --> H[HTTP-válasz?]
    H --> R[Erőforrások és renderelés?]
    R --> U[Felhasználói művelet működik?]

Az ábra nem automatikus döntési fa. A lépések részben átfedhetnek. A sorrend arra jó, hogy elkülönítsük a HTTP előtt, a válasz közben és a válasz után keletkező problémákat.

Hibák a HTTP előtt

Ha a folyamat a HTTP-kérés előtt akad el, nem érkezik státuszkód. Az alábbi valódi curl hibák mutatják, hol szakadt meg a lánc:

Parancs	Hiba	Hol akadt el?
curl https://kurzuspont.example/	curl: (6) Could not resolve host: kurzuspont.example	DNS: a név nem oldható fel
curl http://localhost:9/	curl: (7) Failed to connect to localhost port 9 ... Couldn't connect to server	TCP: senki nem fogadja a kapcsolatot ezen a porton
curl --max-time 2 http://10.255.255.1/	curl: (28) Connection timed out after 2005 milliseconds	TCP: a cél nem válaszol, a kérés időtúllépés
curl https://expired.badssl.com/	curl: (60) SSL certificate problem: certificate has expired	TLS: a tanúsítvány lejárt

(A curl hibakódjai a lépéseket is jelzik: 6, 7, 28, 60. A böngészőben ugyanezek más szöveggel jelennek meg.)

Hibák a HTTP-ben

Ha a kérés eljutott egy válaszoló webes rendszerhez, HTTP-státuszkódot kapunk (2.4). A 404 HTTP-válasz: a kérés eljutott a szerverig, ott az erőforrást nem találták. Az 500 szerveroldali hibaosztályt jelöl. Egy curl hívás ilyenkor sikeresen lefut:

$ curl -sS -o /dev/null -w 'http_code=%{http_code}\n' http://localhost:8080/nincs
http_code=404

Ez azt is jelenti, hogy a curl kilépési kódja 0 volt (a hálózati művelet sikerült), noha az oldal nem található. A hálózati hiba és a HTTP-hiba tehát két külön kérdés.

Hibák a HTTP után

Egy sikeres fő dokumentum mellett egy alerőforrás külön hibázhat: a hiányzó stíluslapról a hálózati panelben 404-es sor árulkodik, miközben a HTML szövege megjelenik. Egy későn érkező kép a lap stabilitását rontja, egy hosszú JavaScript-feladat pedig a felület reakcióját késlelteti. A hibát ezért erőforrásonként és a felhasználói hatás szerint is értelmezni kell.

Vizsgálat a megfelelő helyen

1. Cím és hosztnév: helyes-e? (DNS)
2. Kapcsolat: elérhető-e a szolgáltatás? (curl, böngésző hibaoldal)
3. Fő dokumentum: státusz, időzítés, tartalomtípus a hálózati panelen.
4. Alerőforrások: melyik hibás vagy lassú?
5. Aktuális DOM és stílusok: az Elements nézetben.
6. Felhasználói művelet: végigvihető-e a feladat?

Egyetlen mérés nem általánosít minden felhasználóra: a hálózat, a hely, az eszköz, a gyorsítótár állapota és a szerver terhelése is változik. A diagnózis megfigyelésekre épülő következtetés, amelynél világosan meg kell mondani, melyik réteghez van bizonyíték és melyikhez nincs.

Végigvezetett példa: lassú a Kurzuspont a hallgatónak

Panasz: „A Kurzuspont nem nyílik meg.” Három lehetséges diagnózis és a tünet:

Megfigyelés	Valószínű réteg	Teendő
„A szerver nem található” hibaoldal	DNS	névszerver-beállítás, TTL
Sokáig forog, aztán időtúllépés	TCP vagy hálózat	elérhetőség, tűzfal
Tanúsítványhiba a böngészőben	TLS	tanúsítvány megújítása
Megnyílik, de 503	alkalmazás vagy túlterhelés	kapacitás, 10. fejezet
Megnyílik, stílus nélkül	alerőforrás	a CSS elérése
Megnyílik, de a gomb nem reagál	böngészős feldolgozás	JavaScript-hiba

A panasz ugyanaz, a teendő sorról sorra más. A szolgáltató felelőssége, hogy a hibaüzenet a felhasználónak is segítsen megkülönböztetni ezeket (lásd 10.1).

Gyakori tévhitek

Állítás	Pontosítás
„Lassú oldal = lassú internet.”	A szerver és a böngésző munkája is késleltethet.
„A 404 azt jelenti, hogy nincs hálózat.”	A 404 már HTTP-válasz egy elért rendszertől.
„Ha a HTML 200-as, minden rendben.”	A további erőforrások vagy a felhasználói művelet hibázhatnak.
„A késések sorban, mindig ugyanúgy adódnak össze.”	A gyorsítótár, a párhuzamosság és az újrahasznált kapcsolat módosítja az idővonalat.
„Egy mérés elég.”	Az értékek mérésről mérésre ingadoznak.

Röviden

• A késleltetés terjedési időből, kapcsolatfelépítésből, szerveroldali feldolgozásból, átvitelből és böngészős feldolgozásból áll.
• A HTTP előtti hibák (DNS, TCP, TLS) nem adnak státuszkódot; a HTTP-hibák igen.
• A hiba lehet a fő dokumentumban vagy egy alerőforrásban is.
• Egy mérés nem mond el mindent: az eloszlás számít.
• A diagnózis a tünetet a megfelelő réteghez rendeli.

Ellenőrző kérdések

1. Melyik réteg hibáját jelzi a „Could not resolve host”?
2. Miért 0 a curl kilépési kódja egy 404-es válasznál?
3. Miért ingadozik ugyanazon az oldalon a kapcsolatfelépítés ideje?
4. Hogyan különböztethető meg egy tanúsítványhiba egy 503-as választól?

Tanulási források

• How the web works (MDN) — a lépések angolul.
• HTTP response status codes (MDN) — a hibakódok listája.