HTML Info

Webről, magyarul, mindenkinek

Mikor lenyomjuk az Entert

nincs megjegyzés

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

URL a címsorban

2. A böngésző lekéri a domainhez tartozó IP-t

Névfeloldás

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:

  1. 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).
  2. 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.
  3. Router cache – A keresés a legközelebbi routernél folytatódik – általában ezeknek is van saját DNS cache-ük.
  4. 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.
  5. 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:

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

HTTP kérés

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

Átirányítás

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

Átirányítás követése

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

Kérés lekezelése

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

HTML válasz

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:

HTML Megjelenítése

9. A böngésző lekéri a beágyazott objektumokat

Beágyazott objektumok lekérése

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:

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

AJAX kérések

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.

Írta: htmlinfo

2010. 02 26 at 10:00 pm

Kategória: Fordítások

Címkék , ,

Megjegyzés hozzáfűzése