Mikor lenyomjuk az Entert
Mi történik, amikor beírjuk a címet a böngészőbe, és lenyomjuk az Entert? Azzal majd’ mindenki tisztában van, hogy a böngészőben lakó kismanók ilyenkor lázas keresgélésbe kezdenek, felütik a nagykönyvet, kikeresik belőle a címet, és elszaladnak a tartalomért, amit végül zsírkrétával, vagy színes ceruzával rajzolnak a monitor belső oldalára.
De mi történik valójában?
1. Beírjuk az URL-t
2. A böngésző lekéri a domainhez tartozó IP-t
Első lépésként ki kell találni a meglátogatandó domain IP címét. A névfeloldás folyamata a következőképp történik:
- Böngésző cache – A böngész bizonyos ideig eltárolja a DNS rekordokat. Érdekes módon az operációs rendszer nem mondja meg a böngészőnek a DNS rekordok életidejét (TTL), így a böngésző fix ideig tárolja ezeket (a tárolás ideje böngészőfüggő, általában 2-30 perc között van).
- OS> cache – Ha a böngész átmeneti tárolójában nem található meg a keresett rekord, a böngésző rendszerhívást intéz az operációs rendszer felé(Windows alatt:
gethostbyname). Ekkor az operációs rendszer körülnéz saját cache-ében, és ha tud, válaszol. - Router cache – A keresés a legközelebbi routernél folytatódik – általában ezeknek is van saját DNS cache-ük.
- ISP DNS cache – Ha itt sem jár eredménnyel, a böngésző az internet szolgáltató DNS szerverét próbálja meg kifaggatni.
- Rekurzív keresés – Az internet szolgáltató DNS szervere rekurzív keresést indít, a root névszervertől indulva, a .com felső szintű névszerveren át, a Facebook névszerveréig. Általában a névszerverek cache-ben tárolják a .com névszerverek neveit, így nem kell a root névszervert zaklatni.
A következő ábrán szemléletesen látható a rekurzív névfeloldás:
A DNS renszerrel kapcsolatban problémaként merül fel, hogy a teljes domainhez egy IP cím tartozik. Szerencsére vannak módszerek arra, hogy a szűk keresztmetszet okozta nehézségeket áthidaljuk:
- A Round-robin DNS egy olyan megoldás, ahol a névfeloldás nem egy, hanem több IP címmel tér vissza.
- A terheléselosztók olyan hardverelemek, amelyek egy megadott IP címet figyelnek, és az arra érkező kéréseket más szerverekhez továbbítják. A nagyobb szervereken drága, nagy teljesítményű terheléselosztókat kell alkalmazni.
- A Geographic DNS egy domain név több IP címhez rendelésével javítja a skálázhatóságot; az IP címeket a lekérő földrajzi helyzetétől függően rendeli a domainhez.
- Az Anycast egy útválasztási technika, ahol egy IP címhez több fizikailag is létező szerver tartozik. Sanlatos módon az anycast nem szívesen működik együtt a TCP protokollal, ezért meglehetősen ritkán használt megoldás.
3. HTTP kérés küldése a webszervernek
Meglehetősen biztosak lehetünk benne, hogy a Facebook honlapjának címe nem lesz meg a böngésző cache-ében, mivel a dinamikus lapok lejárati ideje igen rövid, sőt akár azonnali is lehet).
Így hát a böngésző a következő kérést fogja küldeni a Facebook szervernek:
GET http://facebook.com/ HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...] User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...] Accept-Encoding: gzip, deflate Connection: Keep-Alive Host: facebook.com Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
A GET kérés megnevezi az elhozandó URL-t: “http://facebook.com/”. A böngésző azonosítja magát (User-Agent header), és elmondja, milyen típusú választ vár (Accept és Accept-Encoding headerek). A Connection header megkéri a szervert, hogy tartsa nyitva a TCP kapcsolatot további kérésekhez. A kérés tartalmazza a böngésző által tárolt, a domainhez tartozó cookie(k) leírását is.
4. A szerver állandó átirányítással válaszol
A megszólított Facebook szerver valami ilyesmit küld vissza az alkalmatlankodó böngészőnek:
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
A szerver a 301-es Moved Permanently választ küldi a böngészőnek és a http://facebook.com/” címről átküldi a “http://www.facebook.com/” címre.
Több oka is lehet annak, hogy a szerver miért irányít át ahelyett, hogy rögtön a felhasználót érdeklő tartalmat szolgáltatná.
Az egyik a keresőkben elfoglalt rangsorbeli hely. Ha ugyanannak az oldalnak két URL-je is van, a keresők két különböző webhelyként kezelik, így mindkét URL-hez kevesebb befutó linkkel, és alacsonyabb besorolással. A keresők ugyanakkor értelmezni tudják az átirányítást, és összeadják a befutó linkeket.
Ezenkívül a több URL ugyanahhoz a tartalomhoz legkevésbé sem cache barát megoldás. Ha a tartalom két néven érhető el, könnyen többször is helyet foglalhat a cache-ben.
5. A böngésző követi az átirányítást
A böngésző most már tudja, hogy a “http://www.facebook.com/” a megfelelő URL, így hát másik GET kérést küld:
GET http://www.facebook.com/ HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...] Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...] Accept-Encoding: gzip, deflate Connection: Keep-Alive Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...] Host: www.facebook.com
A headerek jelentése ugyanaz, mint az első kérésben.
6. A szerver “lekezeli” a kérést
A szerver megkapja a GET kérést, feldolgozza, és visszaküldi a választ.
Ez egyszerű feladatnak tűnik, ám a valóságban egy csomó érdekes dolog történik ilyenkor – még egy egyszerű statikus oldal esetén is, hát még egy olyan bonyolult webhelyen, mint a Facebook.
- A webkiszolgáló (pl. Apache vagy IIS) megkapja a HTTP kérést és eldönti, melyik kezelőnek kell végrehajtania a kérést. A kezelő egy program (ASP.NET, PHP, Ruby, stb.), amely értelmezi a kérést és létrehozza a válasznak megfelelő HTML kódot.A legegyszerűbb esetben, a kezelők az URL struktúrának megfelelő fájlhierarchiába vannak szervezve (például: a http://example.com/folder1/page1.aspx URL a /httpdocs/folder1/page1.aspx fálnak felel meg). A webkiszolgálót úgy is lehet konfigurálni, hogy az URL-eket kézzel feleltetjük meg az egyes kezelőknek; ilyenkor a page1.aspx nyilvános URL-je lehet mondjuk a http://example.com/folder1/page1.
- A kezelő értelmezi a kérést, megtekinti a hozzá tartozó paramétereket és sütiket. Kiolvassa és esetleg frissíti a szerveren tárolt adatokat, aztán létrehozza a HTML választ.
Minden dinamikus webhelynek ki kell találnia, hogyan tárolja az adatokat. A kisebb webhelyek gyakran csak egy mezei SQL adatbázist használnak, de a nagy mennyiségű adatot kezelő, vagy nagyszámú látogatóval rendelkező webhelyeknek az adatokat el kell osztaniuk több szerver között. Erre a problémára megoldás lehet a sharding, vagyis egy adatbázis tábla megosztása több adatbázis között, amikor is az elsődleges kulcs biztosítja a konzisztenciát, a replikáció, vagy egyszerűsített adatbázis használata, gyengített konzisztenciával.
Az adatfrissítések elfogadható költségkeretek között tartására kitalált technika a batch, vagy kötegelt feldolgozás.
7. A szerver visszaküldi HTML választ
A szerver által létrehozott és visszaküldött válasz:
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
2b3��������T�n�@����[...]
A Content-Encoding header monda meg a böngészőnek, hogy a válasz törzse a gzip algoritmussal van tömörítve. Kitömörítés után a a várt HTML kód jelenik meg:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
A tömörítésen kívül a headerek meghatározzák vajon kell-e, és ha igen, hogyan kell cache-elni az oldalt, a létrehozandó sütiket (ebben a válaszban nincsenek), az adatvédelmi információkat, stb.
Megjegyzendő, hogy a header a Content-Type-ot (tartalomtípust) text/html értékre állította be. A header azt monda a böngészőnek, hogy a válasz tartalmát HTML-ként jelenítse meg ne fájlként töltse le. A böngésző a headert használja arra, hogy eldöntse: miképp értelmezze a választ, bár más tényezőket is figyelembe vesz, így az URL kiterjesztését is.
8. A böngésző megjeleníti a HTML-t
Még mielőtt a böngészőnek rendelkezésre állna a teles adatkészlet, elkezdi megjeleníteni a HTML-t:
9. A böngésző lekéri a beágyazott objektumokat
Ahogy a böngésző elkezdi megjeleníteni a HTML-t, észreveszi, hogy néhány tag további URL-ekre mutat. Ekkor a böngésző GET kérést küld arrafelé is, hogy megszerezze a hivatkozott fájlokat.
Néhány URL, amely a Facebook betöltődése közben szóba jön:
- Képek
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
… - CSS stíluslapok
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
… - JavaScript fájlok
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
Az URL-ek mindegyike hasonló feldolgozási folyamaton megy keresztül, mint a HTML lapok. Tehát, a böngésző feloldatja a domain nevet, lekéri az URL-t, követi az átirányítást, stb.
Viszont a statikus fájlok – nem úgy, mint a dinamikus oldalak – tárolása megoldható a böngésző cache-ben. E fájlok néhánya visszakereshető a cache-ből, anélkül, hogy a szerverhez kellene fordulni. A böngésző tudja, melyik fájlt menyi ideig tároljon a cache-ben, mivel a fájlt visszaadó válasz tartalmaz egy Expires headert. Ezen kívül, minden válasz tartalmazhat egy ETag headert is, amely úgy működik, mint egy verziószám – ha a böngésző olyan fájlt kezd el letölteni, amely ETag-je megegyezik egy már letárolt fájl ETag-jével, megszakítja a letöltést.
Mit jelent az “fbcdn.net” az URL-ben? “Facebook content delivery network”. A Facebook egy tartalomszolgáltató hálózatot használ (content delivery network – CDN) a statikus tartalmak közvetítéséhez – a képekhez, stíluslapokhoz, JavaScriptekhez. Ezzel a megoldással ezek a fájlok azonos másolatai a föld megannyi szerverére szétoszthatók.
10. A böngésző további aszinkron (AJAX) kéréseket küld
A Web 2.0 szellemében a kliens folytatja a kommunikációt a szerverrel akkor is, amikor a lap megjelenítése befejeződött.
Például, a Facebook chat folyamatosan frissíti a bejelentkezett ismerősök listáját. Ehhez a böngészőben futó JavaScriptnek aszinkron kéréseket kell küldenie a szerver felé. Az aszinkron kérések tulajdonképpen programkódból létrehozott GET és POST kérések, amelyek egy speciális URL felé irányulnak. Facebookos példánkban a kliens POST kérést küld a http://www.facebook.com/ajax/chat/buddy_list.php címre, ahonnan megkapja online ismerőseink listáját.
Ezt az eljárást AJAX-nak is nevezik, amely az Asynchronous JavaScript And XML kifejezésből alkotott betűszó, mégha nincs is különösebb oka annak, hogy a szerver XML formátumban küldje válaszát. A Facebook is JavaScript kódrészleteket küld válaszul az aszinkron kérésekre.
A tippért köszönet Török Gábornak.
Nincsenek kapcsolódó bejegyzések.
2010. 02. 26.
· 
htmlinfo · 
Nincsenek megjegyzések
Címkék: böngésző, HTML, web · Kategória:: Fordítások
Szólj hozzá!