Rétegezett architektúra Hálózat
HTTP
felhasználók Alkalmazási
Szállítási
Internet
Hálózat-elérési
felhasználók Alkalmazási
Szállítási
Internet
Hálózat-elérési
– 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.)
TCP, UDP.
IP Pont-pont kapcsolatok, LANok,...
Alkalmazások és alkalmazási rétegbeli prtokollok
A kliens szerver paradigma Egy tipikus hálózati alkalmazás két részből áll: kliens és szerver
application transport network data link physical
application transport network data link physical
Pont-pont kapcsolat, LANok, ...
• 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
HTTP, SMTP, FTP, TELNET, DNS, …
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.
Végponttól végpontig terjedő átvitel, Megbízható átvitel, sorrendbe állítás, QOS, ... A legjobb útvonal kiválasztása ...
A hálózatfejlesztés motorját a hálózati alkalmazások képezik
TCP/IP protokoll készlet Hálózat
Web, e-mail, file transfer, ...
application transport network data link physical
application transport
network Kliens: data link physical • Kezdeményezi a szerverrel való request 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:
• •
reply application transport network data link physical
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
1
A socket specifikálja a szállítási réteg szolgáltatásait
Hogyan kommunikál a kliens és a szerver? API: application 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?
• 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
– 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
– 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
TCP kontra UDP
• 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)
TCP összeköttetés-orientált protokoll megbízhatóbb, mivel visszajelzést ad a szegmensek megérkezéséről lassúbb az összeköttetés létrehozása, de maga az adatátvitel utána gyors az adatfolyamot szegmensekbe tördeli
• •
• •
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
htt p
PC running Explorer
htt p
tp ht
req ues t
res p
req
ons
s re tp ht
Mac running Navigator
e
st ue
e ns po
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
Uniform Resource Locator (URL)
A Web: a HTTP protokoll http: hypertext transfer protocol
Server running NCSA Web server
• • • • •
protocol://authority:port/p/a/th/item_name?query protocol = http authority = server 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 server) a TCP kapcsolat lezárul.
A http “állapot nélküli” •
www.someSchool.edu/someDepartment/home.index
1a. A HTTP kliens a
A szervernek semmi információja sincsen a kliens korábbi kéréseiről
www.someSchool.edu HTTP szerver felé egy TCP kapcsolatot (folyamat) kezdeményez. A HTTP szerver esetén a default port a 80.
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 (folytatás) 4. A HTTP szerver lezárja a kapcsolatot. 5. A HTTP kliens megkapja a html
idı
HTTP példa
Feltételezzük, hogy a felhasználó begépelte a következő URL-t:
á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.
HTTP kérés üzenet: általános formátum
(ez szöveget és 10 jpeg képre való hivatkozást tartalmaz)
2. A HTTP kliens elküld egy HTTP kérés üzenetetet (mely tartalmazza az URL-t) a TCP kapcsolati socketnek
idı
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
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 ü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 data data data data data ...
adat, például az igényelt html állomány
3
HTTP kontra HTML
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 server
404 Not Found
• 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
– requested document not found on this server
– mind HTTP kliens, – mind pedig HTML elemző, értelmező.
505 HTTP Version Not Supported
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 server) 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 web cache-en keresztül: Internet options -> Advanced -> Use HTTP 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 – Ellenkező esetben megkéri az ogjektumot a forrás-szervertől és utána továbbítja azt a klienshez
Forrás szerverek
– Az intézményi/ISP hálózati vonal gyakran szűk kersztmetszetet jelent.
Nyilvános Internet
1.5 Mbps sávszélesség Intézményi hálózat
Proxy
htt st pr server reque equ se est client http tp on t h res sp re po n tp se t h st htt ue pr req e equ ns tp o h est t ttp h sp re res p po n t ht se
client
Forrás szerver
A Web-cache szintjei
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
Forrás szerver
• • • •
Magán a munkaállomáson (a kliensen) Üzemi-vállalati Nemzeti Nemzetközi
100 Mbps LAN
Intézményi cache
4
A válaszidő modellezése Az NLANR cache hierarchia
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 Az állomány átviteli ideje
RTT file received time
time
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 II. Kliens
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 ekereskedelmi 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
Cookie file ebay: 8734
szerver
szokásos http request szokásos http response +
A szerver létrehozza a 1678 ID-t
Set-cookie: 1678 Cookie file amazon: 1678 ebay: 8734
szokásos http request
cookie: 1678 szokásos http response
cookiespecifikus tevékenység
Egy héttel késıbb: Cookie file amazon: 1678 ebay: 8734
szokásos http request
cookie: 1678 szokásos http response
Be Az jeg y ad z és at b a áz is b a
hozz
áfér
és
ho zz áf ér és
Cookies: az “állapot” fenntartása
cookiespecifikus tevékenység
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
Cookie 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
•
Felhasználó-szerver kapcsolat: conditional GET Cél: ne küldjük el az
client objektumot ÚJRA, amennyiben a kliens http request msg naprakész tárolt (cached) If-modified-since: változattal rendelkezik
belőle http response HTTP/1.0 • kliens: specifikálja a HTTP 304 Not Modified kérésében a tárolt változat aktualitását (dátum, időpont) If-modified-since:
• szerver: a válaszában nincs objektum, amennyiben a tárolt változat naprakész HTTP/1.0 304 Not Modified
server Az objektum nincs módosítva
http response HTTP/1.1 200 OK …
Az objektum módosítva van
•
• •
•
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: autentikálás server Cél: a szerver client 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
http request msg
If-modified-since:
meg kell jegyezni
A cookie és a privacy
– Amennyiben elmarad, a szerver megtagadja a kiszolgálást
usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization:line usual http response msg usual http request msg + Authorization:line usual http response msg
idı
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.
6
