Webfejlesztő tudásbázis, második rész: Kliens-szerver kommunikáció

2013-05-01 kms Tananyag

Mostanra ismerjük egy URL és a DNS rendszer felépítését, így jogosan várhatjuk el, hogy – működő internet-kapcsolat esetén – megkapjuk a kért honlapot.

Mivel sokszor használunk otthon összeállított környezetet a fejlesztéshez/teszteléshez, érdemes tudni miként viszonyul a szerver a kéréseinkhez és hogyan szolgáltat választ rá.

Ehhez először azt kell tisztázni, miként küld kéréseket a böngészőnk a szerver felé, mert ez a kiindulópontunk.
A grafikus böngészők megjelenésével egy időben kezdtek el gondolkodni a sávszélesség-problémákon, mivel akkoriban sokkal szűkösebb keretek voltak elérhetőek.

Az első – és több követő – generációs böngészők korlátozásai közé tartozott, hogy egyszerre párhuzamosan legfeljebb két kérést küldtek el egy szerver felé. Ennek a sávszélességre vonatkozó előnye is volt (folyamatosabbnak érezhető a betöltés), illetve kiküszöbölt egy problémát a szerverek túlterhelésével kapcsolatban.

Ez a szám mára a szerverek fejlődésével és a sávszélességek növekedésével szintén emelkedett. Egy v18-as Firefox például egyszerre hat kérést küld el ugyanannak a szervernek.

Ez a fejlődés a megfelelő sávszélességgel együtt gyorsabb oldalletöltést eredményez a beágyazott tartalmakban gazdag oldalakon.

Azért csak menjünk szép sorjában.

Kérés

Ahhoz, hogy meglássuk milyen tartalom van egy URL mögött, össze kell állítani az arra irányuló kérést:

GET / HTTP1.1
Host: mikoandras.hu

A példában épp csak a domain-t írtuk be a böngészőbe, és ennyi elegendő is a tartalom lekéréséhez.

A válaszban egy html oldalt kapunk, ami az – apache szerveren a DirectoryIndex által megadott beállítás szerinti – alapértelmezett file-nak megfelelő tartalom.

Ez a html a cikk írásának idején 12 beágyazott képet, 3 css-t és egy külső script-et tartalmaz. Ez a html kód mellett még 16 letöltendő file-t jelent, amit valamilyen formában/sorrendben meg kell szerezni az oldal helyes megjelenítéséhez. Nem meglepő módon a böngésző elolvassa a html kódot, és amikor külső erőforrásra való hivatkozást talál (link, img, script, object, …), akkor az ott található linket értelmezve egy újabb kérést gyárt, és az URL-feloldási szabályoknak megfelelően elküldi az azt kiszolgáló szerver felé.

GET /wp-content/themes/black-with-orange/style_all.css HTTP1.1
Host: static.mikoandras.hu

A stíluslap egy másik szerveren kapott helyet, hogy ezzel kicselezzem a maximum 6 egyidejű kapcsolat korlátját.

Ezt a lépést hatja végre a böngésző minden belinkelt képre, kódra, stíluslapra, objektumra és a stíluslap(ok)ban említett képekre szintén.

A kérések a fenti példákban elég minimalista jellegűek, de ez nem minden esetben van így. Sok kiegészítő információ is utazik egy-egy ilyen csomagban. Többek között a kliens-oldal nyelvi preferenciájától a tömörítési eljárás engedélyezésén keresztül a böngészőt azonosító leírásig.

GET / HTTP1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: hu-hu,hu;q=0.8,en-US;q=0.5,en;q=0.3
Cache-Control: max-age=0
Connection: keep-alive
Host: mikoandras.hu
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0

Eddig feltételeztük, hogy a kérésekre szabályszerű, helyes és időn belüli válasz érkezett. A való világ ennél kicsit bonyolultabb, és emiatt nem csak 200-as hibakód létezik.

Válaszlehetőségek

Az előbb említett 200-as hibakód érkezik általában a válasszal, amennyiben minden rendben van. Ez a 2xx-es csoportba tartozik, ami a sikeres végrehajtás csoportja. Ezenkívül még 1xx, 3xx, 4xx és 5xx csoport létezik, melyek információs, átirányítási, kliens hiba és szerver hiba, ebben a sorrendben.

Ezek közül a leginkább ismertek: 200, 301, 302, 304, 307, 400, 401, 403, 404 és a fejlesztés közben legkevésbé kívánt 500.

Kéréstípusok

A válaszlehetőségek mellett a kérés sem csak egyfél lehet. A GET mellett sokat használt a POST típus – főleg AJAX scriptek használata esetén, illetve űrlapoknál.

Az URL-nél megismert paraméterátadás működik hasonló formában POST kérések esetén is, és az a hozzáadott előnye is megvan, hogy az URL maga nem változik, nem “csúnyul el” a paraméterek felsorolásával. Ezenkívül egy POST sokkal nagyobb adattömeget képes megmozgatni.

POST / HTTP1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: hu-hu,hu;q=0.8,en-US;q=0.5,en;q=0.3
Cache-Control: max-age=0
Connection: keep-alive
Host: mikoandras.hu
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0

username=myself&date=2013.05.01&message=nem%20tudom

A példában szereplő kérés kitalált, semmilyen összefüggésben nincs a honlapon működő kóddal, de teljes értékűen szemlélteti az adatátadás működését.

Firebug

Az egyik legelterjedtebb módja a fejlesztés közben ellenőrizni a kliens-szerver kommunikációt, a böngészőbe épített kiegészítőkön keresztül ismert.
Ez a három legnagyobb böngésző esetén az F12 gombbal elérhető. Chrome-ban és IE-ben én a beépített eszközt szoktam használni, Firefox-hoz pedig az alcímben elérhető Firebug kiegészítőt.

Összefoglalás

A szerver és kliens közötti beszélgetés ennél jóval összetettebb és bonyolultabb is lehet, mivel belekeveredik mindemellett a kiszolgált tartalom típusa is. Ennek ellenére jó kiindulási alap lehet, és ösztönzök is mindenkit a saját vonalon történő utánaolvasásra, tesztelgetésre.

kliens-szerver, kommunikáció, tudnivaló

A pénzfeldobás tényleges esélyei MySQL jogosultság-szervezés