HTTP Hálózat Rétegezett architektúra felhasználók Alkalmazási Web, e-mail, file transfer,... Szállítási Internet Hálózat-elérési Végponttól végpontig terjedő átvitel, Megbízható átvitel, sorrendbe állítás, QOS,... A legjobb útvonal kiválasztása... Pont-pont kapcsolat, LANok,... Hálózat Alkalmazási Szállítási Internet Hálózat-elérési TCP/IP protokoll készlet felhasználók HTTP, SMTP, FTP, TELNET, DNS, TCP, UDP. IP Pont-pont kapcsolatok, LANok,... A hálózatfejlesztés motorját a hálózati alkalmazások képezik Fontos megértenünk, hogy a hálózati alkalmazások képezik az OKÁT annak, hogy a hálózati infrastruktúra épül A fejlődési ív a 80as évek népszerű hálózati alkalmazásai parancssoros vezérlésűek (Command Line Interface = CLI) és szövegesek voltak (mint a telnet, ftp, news, chat, stb.), napjaink alkalmazásai viszont multimédiásak (Web böngésző, audio és video streaming, realtime videokonferencia, stb.) Alkalmazások és alkalmazási rétegbeli prtokollok Alkalmazások: kommunikáló elosztott folyamatok, melyek a hálózati állomásokon, a felhasználói térben futnak az üzenetváltástól az alkalmazás implementálásáig terjednek, például: email, file transfer, Web Az alkalmazási rétegbeli protokollok az alkalmazások egy darabját jelentik, definiálják az alkalmazások által meghatározott üzeneteket és cselekszenek alacsonyabb rétegbeli protokollok által biztosított felhasználói szolgáltatásokat nyújtanak. A kliens szerver paradigma Egy tipikus hálózati alkalmazás két részből áll: kliens és szerver Kliens: Kezdeményezi a szerverrel való kapcsolatot ( elsőként beszél ) Tipikusan a szerver szolgáltatását veszi igénybe, A Web esetében, a klienst a böngésző alkotja, e-mail esetében pedig a levelező program olvasó változata Szerver: Elsőként fut Biztosítja a kliens által kért szolgáltatást, például a Web szerver esetén elküldi a kívánt oldalt, mail szerver esetén a kívánt levelet request reply 1
Hogyan kommunikál a kliens és a szerver? API: programming interface Meghatározza az alkalmazási és a szállítási réteg közötti kapcsolatot socket: Internet API Két folyamat, mely adatot küld a socketnek és adatot olvas a socketből Kérdés: hogyan azonosítja egy folyamat azt a másik folyamatot, amellyel kommunikálni kíván? a másik folyamatot futtató állomás IP címe port címek lehetővé teszik a fogadó állomás számára, hogy meghatározza: a helyi folyamatok közül melyik számára szállítsa le a kapott üzenetet A socket specifikálja a szállítási réteg szolgáltatásait Meghatározza az alkalmazási és a szállítási réteg közötti interfészt Az alkalmazás választja ki a szállítási réteg típusát azáltal, hogy kiválasztja a socket típusát TCP Sockets Java esetén Socket/ServerSocket, C esetén SOCK_STREAM UDP Sockets Java esetén DatagramSocket, C esetén SOCK_DGRAM A kliens és a szerver megállapodik a socket típusáról, a szerver portszámáról és a protokollról. Tervezési tér Mi két alkalmazási rétegbeli protokollt tárgyalunk: a HTTP a TCP protokollt használja, a DNS pedig általában az UDP protokollt (ritkán a TCP-t) összeköttetés-orientált protokoll megbízhatóbb, mivel visszajelzést ad a szegmensek megérkezéséről TCP kontra UDP TCP lassúbb az összeköttetés létrehozása, de maga az adatátvitel utána gyors az adatfolyamot szegmensekbe tördeli UDP összeköttetés nélküli protokoll nem megbízható, mivel nincs benne visszajelzés a szegmensek megérkezéséről igen gyors és hatékony az alkalmazások adatai elférnek egy szegmensben, így nem szükséges szakaszokra tördelnie A Web: a HTTP protokoll Uniform Resource Locator (URL) http: hypertext transfer protocol A Web alkalmazási rétegbeli protokollja kliens/szerver modell kliens: a böngésző igényli, megkapja és megjeleníti a Web objektumokat szerver: a Web szerver fér hozzá ahhoz a tárterülethez, ahol a Web dokumentumok elhelyezkednek: a kérésekre válaszként másolatot küld róluk http1.0: RFC 1945 http1.1: RFC 2068 PC running Explorer Mac running Navigator Server running NCSA Web protocol://authority:port/p/a/th/item_name?query protocol = http authority = machine Port = 80 by default /p/a/th/item_name = specifikálja vagy magát a válaszként küldendő állományt, vagy azt a programot, amelyet futtatni kell ahhoz, hogy előálljon a válaszként küldendő állomány 2
A http protocol: továbbiak HTTP: TCP szállítási rétegbeli szolgáltatás: a kliens kezdeményezi a TCP kapcsolatot (létrehozza a socketet) a szerverrel a 80-as porton keresztül a szerver fogadja a klienstől érkező TCP kapcsolatot HTTP üzeneteket (alkalmazási rétegbeli protokoll üzeneteket) cserél a böngésző (HTTP kliens) és a Web szerver (HTTP ) a TCP kapcsolat lezárul. A http állapot nélküli A szervernek semmi információja sincsen a kliens korábbi kéréseiről egyébként Azok a protokollok, melyek az állapotot kezelik, igen összetettek! A történetet (állapot) követni kell ha a szerver/kliens összeomlik, inkonzisztens lehet az állapotuk, amit látnak, s ezt kezelni kell HTTP példa Feltételezzük, hogy a felhasználó begépelte a következő URL-t: www.someschool.edu/somedepartment/home.index idı 1a. A HTTP kliens a www.someschool.edu HTTP szerver felé egy TCP kapcsolatot (folyamat) kezdeményez. A HTTP szerver esetén a default port a 80. 2. A HTTP kliens elküld egy HTTP kérés üzenetetet (mely tartalmazza az URL-t) a TCP kapcsolati socketnek (ez szöveget és 10 jpeg képre való hivatkozást tartalmaz) 1b. A www.someschool.edu HTTP szerver a 80-as porton várja a TCP kapcsolatot. Fogadja azt és értesíti erről a klienst 3. A HTTP szerver megkapja a kérést, kialakít egy válasz üzenetet, mely tartalmazza a kért objektumot (somedepartment/home.ind ex), s elküldi az üzenetet a socketnek idı HTTP példa (folytatás) 5. A HTTP kliens megkapja a html állományt tartalmazó választ és azt megjeleníti. Elemzi a html állományt és 10.jpeg objektumra való hivatkozást talál benne. 6. Az 1-5 lépés megismétlődik mind a 10.jpeg objektum esetén. 4. A HTTP szerver lezárja a kapcsolatot. HTTP üzenet formátum : kérés A HTTP üzeneteknek két formátuma van: kérés, válasz HTTP kérés üzenet: ASCII (ember számára olvasható formátum) Kérés sor (GET, POST, HEAD parancs) Fejléc sorok Carriage return, line feed jelzi az üzenet végét GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) HTTP kérés üzenet: általános formátum HTTP üzenet formátum : válasz Állapot sor (protokoll Status-kód Status-szöveg) Fejléc sorok HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998... Content-Length: 6821 Content-Type: text/html adat, például az igényelt html állomány data data data data data... 3
HTTP válasz status-kódok a szerver->kliens válasz üzenet első sorában Néhány példa-kód: 200 OK request succeeded, requested object later in this message 301 Moved Permanently requested object moved, new location specified later in this message (Location:) 400 Bad Request request message not understood by 404 Not Found requested document not found on this 505 HTTP Version Not Supported HTTP kontra HTML A HTML formátum pontosan specifikált, de csupán egy HTTP üzenet adataként vagy törzseként kezelt A HTML NEM része a HTTP protokollnak A rétegelt modellre példa: minden réteg a párjával kommunikál és azzal egyezik meg a nyelv és a protokoll tekintetében Ebben az esetben mindkettőt a web böngésző kezeli. A web böngésző tehát mind HTTP kliens, mind pedig HTML elemző, értelmező. Statikus kontra dinamikus kontra aktív Web oldalak Statikus: egy állományban tároljuk és változás nélküli Stored in a file and unchanging Dinamikus: A szerver alakítja ki az állomás kérésének megfelelően, igény alapján. Például egy program outputja (például Common Gateway Interface (CGI) ) Aktív: a kliens oldalon fut! Egy számítógép program (nem csupán egy output), mely képes a felhasználóval interaktívan kommunikálni (például egy Java applet) Web Caches (proxy ) Cél: a kliens igények kielégítése a forrás-szerver bevonása nélkül A felhasználó beállítja a böngészőt: Web hozzáférés Proxy web cache-en keresztül: Internet options -> Advanced -> Use HTTP client 1.1 trough proxy connections A kliens minden HTTP kérést a web cache-hez küld Amennyiben az objektum benne van a web cache-ben, a web cache azonnal küldi az objektumot a HTTP válaszban client Ellenkező esetben megkéri az ogjektumot a forrás-szervertől és utána továbbítja azt a klienshez Forrás szerver Forrás szerver Mire szolgál a Web Caching? Összegzés: a cache közelebb van a klienshez (például ugynaabban a hálózatban) Rövidebb válaszidő: a cache közelebb van a klienshez A távoli szerverhez irányuló forgalom mérséklése Az intézményi/isp hálózati vonal gyakran szűk kersztmetszetet jelent. Intézményi hálózat Nyilvános Internet 1.5 Mbps sávszélesség Forrás szerverek 100 Mbps LAN Intézményi cache A Web-cache szintjei Magán a munkaállomáson (a kliensen) Üzemi-vállalati Nemzeti Nemzetközi 4
Az NLANR cache hierarchia A válaszidő modellezése Az RTT definíciója: kis üzenet küldési ideje a klienstől a szerverhez és vissza. Válaszidő: Egy RTT a TCP kapcsolat kiépítése Egy RTT a HTTP kérés és a HTTP válasz első bájtjainak megérkezése Az állomány átviteli ideje Összesen = 2RTT+az állomány átviteli ideje initiate TCP connection RTT request file RTT file received time time Az állomány átviteli ideje Non-persistent és persistent kapcsolatok Non-persistent HTTP/1.0 A szerver elemzi a kérést, válaszol, és lezárja a TCP kapcsolatot Minden egyes objektum lehívási ideje: 2 RTT Minden objektum-ávitel szenved a lassú starttól Persistent default a HTTP/1.1 esetén Ugyanazon TCP kapcsolaton: a szerver elemzi a kérést, válaszol, és elemzi az újabb kérést A kliens, mihelyt megkapta az alap HTMLt, azonnal kéri az összes hivatkozott objektumot Kevesebb RTT és kevésbé lassú a start A HTTP 1.1 jellemzői Persistent kapcsolatok Hostname azonosítás Lehetővé teszi, hogy egyetlen fizikai Web-szerver több logikai web-szerverként funkcionáljon Tartalom-egyeztetés Lehetővé teszi, hogy a kliens az erőforrás megfelelő verzióját kérje Chunked Transfers A dinamikus tartalom esetén a szervernek nem kell előre definiálnia az összes jellemzőt, például a méretet Byte Ranges A kliensek a dokumentumot kisebb részekben kérhetik Proxy és cache támogatás Cookies: az állapot fenntartása Sok, nagyobb web-oldal használ cookie-t Négy komponens: 1) cookie header line a HTTP válaszban 2) cookie header line in HTTP kérésben 3) A kliens gép tárolja a cookie fájlt és azt a kliens oldali böngésző kezeli 4) háttér-adatbázis az webszerveren Példa: Tamás mindig ugyanarról a gépről megy ki az internetre Először látogat meg egy e- kereskedelmi oldalt Amikor az iniciáló HTTP kérés megérkezik az webszerverhez, az létrehoz egy Tamást azonosító egyedi ID-t és ehhez az egyedi IDhoz készít egy bejegyzést a web-szerveren lévő adatbázisba Cookies: az állapot fenntartása II. Kliens szerver Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 Egy héttel késıbb: Cookie file amazon: 1678 ebay: 8734 szokásos szokásos http response + Set-cookie: 1678 szokásos cookie: 1678 szokásos szokásos cookie: 1678 szokásos A szerver létrehozza a 1678 ID-t cookiespecifikus tevékenység cookiespecifikus tevékenység Bejegyzés a Az adatbázisba hozzáférés hozzáférés 5
Felhasználó-szerver kapcsolat: cookies A szerver összeveti a kapott cookie-t az általa tárolttal: autentikálás így emlékezik a felhasználói preferenciákra és a korábbi választásokra Mit eredményezhet a cookie : Bejelentkezést (pl. Google webmastertools) vevőkártyát ajánlatokat felhasználói adatok küldését (pl. tárhelyszolgáltatónál az űrlapjában kitölti az adataimat) Tehát így emlékezik a szerver a felhasználói preferenciákra és a korábbi választásokra Cookie meg kell jegyezni A cookie és a privacy Cookie lehetővé teszi, hogy az adott web-oldal sokmindent megtudjon rólunk Eljuttathatjuk a nevünket, mailcímunket a web-oldalnak A kereső-motorok átirányítást és cookie-t használnak, hogy még többet megtudjanak rólunk A hirdetési cégek ezek segítségével gyűjtenek rólunk információkat Felhasználó-szerver kapcsolat: conditional GET Cél: ne küldjük el az objektumot ÚJRA, client amennyiben a kliens naprakész tárolt (cached) változattal rendelkezik belőle kliens: specifikálja a HTTP kérésében a tárolt változat aktualitását (dátum, időpont) If-modified-since: <date> szerver: a válaszában nincs objektum, amennyiben a tárolt változat naprakész HTTP/1.0 304 Not Modified msg If-modified-since: <date> HTTP/1.0 304 Not Modified msg If-modified-since: <date> HTTP/1.1 200 OK <data> Az objektum nincs módosítva Az objektum módosítva van Felhasználó-szerver kapcsolat: autentikálás Cél: a szerver dokumentumaihoz történő hozzáférés engedélyezése Állapot nélküli: a kliensnek minden kérés esetén autentikálnia kell magát autentikálás: tipikusan felhsználónév és jelszó autentikálás: a kérés fejlécének sorában Amennyiben elmarad, a szerver megtagadja a kiszolgálást client usual msg 401: authorization req. WWW authenticate: usual msg + Authorization:line usual msg usual msg + Authorization:line usual msg A böngészı képes a felhasználónév és jelszó tárolására, így a felhasználónak nem kell újra bevinnie. idı 6