7. IP címek, IP címosztályok

1.sz. ábra

IP címek

    Az IP protokoll alatt a címzés 32 biten történik. (Természetesen ez az eredeti IPv4-re vonatkozik. Az IPv6 esetén 128 bites címzés bevezetése lesz, amivel megoldódni látszik a mostanságnak kevésnek bizonyuló IPv4-es címtartomány. A továbbiakban csak IPv4-el foglalkozunk IP néven.) Minden hálózati eszköz saját IP címet kap. Ami a gyakorlatban hostonkénti IP címet jelent, mivel leggyakrabban hostonként egy hálózati kártya, vagy egy modem szükséges a hálózati kommunikációhoz. Ha olyan helyi hálózatot alakítunk ki, amelynek nincs kapcsolata más hálózatokkal (gyakorlatilag nincs Internet elérés), akkor tetszõlegesen választhatunk címeket az eszközöknek.
    Ellenkezõ esetben, valamely IP címtartomány regisztrátornál kell igényelni (Gyakorlatban az Internet szolgáltatónk tud ebben segítséget nyújtani, akitõl a külsõ elérésünket "vásároljuk").
    A mindennapi életben az IP címek 4 db decimális szám fomájában közöttük ponttal jelennek meg: pl.: 193.225.236.12
    Értelmezzük az IP címet:
    Minden IP cím felbontható két részre:

• egy hálózati összetevõre,    pl.: 193.225.236
• és egy hostra (interfészre) jellemzõ összetevõre 12 (az elõzõ példa alapján).

IP címosztályok
 

Megnevezés	IP címtartomány	Hálózati maszk	Hálózatok, és hálózatba köthetõ hostok száma	Privát, máshol nem kiosztott címtartomány
A osztály	1.0.0.0 - 126.255.255.255	255.0.0.0	126 db hálózatot, és hálózatonként durván 1,6 millió hostot jelent	10.0.0.0 - 10.255.255.255
B osztály	128.0.0.0 - 191.255.255.255	255.255.0.0	Több mint 16000 hálózatot, és hálózatonként több mint 65000 hostot jelent	172.16.0.0 - 172.31.255.255
C osztály	192.0.0.0 - 223.255.255.255	255.255.255.0	Közel 2 millió hálózatot, hálózatonként 254 hostot jelent	192.168.0.0 - 192.168.255.255
D, E, F osztály	224.0.0.0 - 254.255.255.255		Ezek a címtartományok vagy kisérletiek, vagy késõbbi használatra vannak fenntartva.

    Mint láthatjuk az elõzõ példában szereplõ 193.225.236.12-es cím C osztályú.

A táblázatban nem szereplõ címek:
0.0.0.0; 127.0.0.0-127.255.255.255; 255.0.0.0-255.255.255.255 speciális célokra.
A 0.0.0.0 az alapértelmezett útvonal címe;
a 127.0.0.0-127.255.255.255 speciális interfész, az un, loopback (visszahurkolási) interfész címtartománya, neve: lo;
a 255.0.0.0-255.255.255.255 hálózati maszk, továbbiakban netmask címtartománya.

    Az említett 127.0.0.0 hálózat a helyi (hoston belüli) IP forgalomhoz fenntartott tartomány. A 127.0.0.1 cím egy különleges intefészhez (lo néven Linux-on) van hozzárendelve a hoston. Bármely TCP-s UDP-s IP csomag, melyet erre a címre küldünk, rögtön vissza is kerül, mintha most érkezett volna egy külsõ hálózatból. Olyan hoston is tudunk hálózatos mûködést produkálni, melyben maga a fizikai hálózati eszköz nem létezik.

    Ha helyi TCP/IP-s hálózatot alakítunk ki, melynek nem lesz kapcsolata más hálózatokkal, javasolt a "Privát"-ként feltüntetett oszlopból címtartományt választani. Egy késõbbi esetleges "Internetes bõvítésnél" elég egy "címfordítót" (NAT = Network Address Translator) betenni, ami a szükséges címátalakításokat elvégzi (a kimenõ csomagokban a címeket "valós IP címmé", míg a válasz csomagokban a címet a valós címzetthez "irányítja"). Létezõ Linux-os megoldás az IPMasquerading ezt képes megvalósítani. Egy valós IP cím mögé képes egy egész hálózatot "rejteni" és a címzések cseréjét elvégezni. Ilyenkor a belsõ "rejtett" hálózat host-jai mind a "Privát" címtartományból kapják a címeket. Ha nem így tennénk, pl. egy olyan címtatományt választunk ami az Interneten is megtalálható, akkor az adott címtartomány host-jait az Interneten nem érjük el, azokkal kapcsolatot nem tudunk kialakítani, hiszen azok a címek egyben helyi címek is.

    Az IP címek, interfészekkel kapcsolatos parancsok: ifconfig, netstat, tcpdump.
 

8. Címfeloldás - ARP

    Ha az ARP-nak egy adott IP címhez kell az Ethernet címet meghatározni, akkor elõször is megvizsgál egy memóriában tárolt un. ARP cache-t. Két eset lehetséges:

    - ha nem található meg az adott összerendelés az ARP cache-ben, akkor egy "üzenetszórás" broadcast üzenetet küld ki az IP címnek (route táblának) megfelelõ interfészen. Ez egy speciális Ethernet broadcast üzenet az ff:ff:ff:ff:ff:ff címre, (nem összekeverendõ az IP broadcast üzenettel) melyet az összes a szegmensbe bekapcsolt host intefésze megkap és tartalmaz egy lekérdezést az IP címre. Ezt mindegyik host összehasonlítja a saját IP címével, ha megegyeznek, egy ARP választ küld a kérdezõnek. A kérdezõ ezután a válaszból mostmár megtudja a szükséges IP-Ethernet cím összerendelést és a címfeloldása. A késõbbi gyorsabb válaszokhoz, bekerül az ARP cache-be, ahol egy bizonyos ARP-refreshtime ideig megörzésre kerül.
    - ha megtalálható az adott IP-Ethernet cím összerendelés az ARP cache-ben, onnan történik a címfeloldás.

    Egy adott host ARP caché-ben csak az adott Ethernet szegmensen levõ hostok IP-Ethernet cím összerendelései találhatók. Egy másik szegmensen levõ host-tal pl. IP útválasztón (routeren) keresztül kommunikál. Az útválasztóval azonos szegmensen levõ interfészének az IP-Ethernet cím összerendelése van csak a host ARP caché-ben

Ethernet szegmens: azon host-ok, aktív-passzív eszközök összessége, melyben a hostoknak nem kell IP útválasztót (routert) igénybe venni szegmensen belüli, bármely host-host kommunikációhoz. (A szegmensen a network number a hostokon (interfészen) azonos.)

    Egy adott Ethernet címû eszköz küldhet egy kérést a szegmensre, melyben a saját IP címét próbálja felderíteni, erre a szegmensen levõ un. RARP szerver válaszol, válaszában küld egy IP címet. Erre a mûködésre pl. lemez nélküli kliensek esetében lehet szükség.

9. IP routing - Route tábla

    Egy hétköznapi életbõl vett példa alapján:

    Levél címzése a címzett nevén kívül tartalmazza az irányítószámot, várost, utcát, házszámot, esetleg országot. A posta ezek alapján juttatja el a címzett országba, városba, majd az utca, házszám, címzett neve alapján a postaládába. Látszik, hogy az adott postahivatal mindig tudja mit kezdjen a levelekkel, merre is küldje azt tovább, míg az végül megérkezik a címzetthez. Az is világos, hogy egy adott hivatal azt tudja hová küldje tovább a leveleket, de a teljes útvonalról már nem kell tudnia.

Alhálózatok

    Ez a szerkezet az IP címeknek host és hálózati részre való felosztásában tükrözõdik. Alapértelmezés szerint a cél-hálózat az IP cím hálózati részébõl származik. Az azonos IP hálózati számmal (továbbiakban network number) rendelkezõ hostok ugyanazon a hálózaton belül kell megtalálni, és az egy hálózaton belüli hostoknak ugyanaz a network number-ük.
Az alhálózat veszi át azt a feladatot, hogy az adatcsomagokat eljuttassa egy adott IP címtartományba, abból az IP hálózatból, amelynek az része. Ahogy az A, B vagy C osztályt a cím hálózati része azonosította, a hálózati rész kibõvül, hogy magába foglaljon egyes biteket a cím host részébõl. Az alhálózat számként értelmezett bitek számát az un. alhálózatmaszk vagy hálózatmaszk (továbbiakban netmask) adja meg. Ez szintén egy 32 bites szám, amely meghatározza az IP cím hálózati részének bitmaszkját. Pl.: A GATE MFK hálózatának (továbbiakban MFKnet) network number-e: 193.225.236.0, amihez a 255.255.255.0 netmask tartozik. Belsõleg az MFKnet több kisebb hálózati szegmensbõl áll:

• 217 szoba szegmense,
• könyvtári szegmens,
• tanulmányi szegmens,
• 114-es oktatóterem,
• 215-ös oktatóterem,
• kollégium.

Router-ek

    Az alhálózat nemcsak szervezési elõny, hanem gyakran harware-határok következménye. Egy host egy adott fizikai hálózaton (pl. Ethernet) kizárólag azokkal a host-okkal tud közvetlenül kommunikálni, amelyek ugyanazon a hálózaton vannak. A routerek olyan host-ok, amelyek egyidejûleg két vagy több fizikai hálózatra csatlakoznak, és az adatcsomagok hálózatok közötti irányítására vannak konfigurálva. A routerek azonos hálózati rétegek (pl. IP) összekötésére és forgalom irányítására szolgálnak. A routerek interfészeknek különbözõ IP network number-û alhálózatokhoz kell kapcsolódni. A routerek csomagok átirányításakor az adatcsomagban a TTL-értéket (az adatcsomag véges élettartamát) eggyel csökkentik, amivel megakadályozhatók az adatcsomagok esetleges örökös keringése a hálózatban.

    A 2.sz. ábra alapján: pl.: amikor a 193.225.236.32-es alhálózaton a to2-es gép egy adatcsomagok szeretne küldeni a konyvtar5-ös gépre, akkor a saját route táblája alapján soronként haladva a cél IP címet maszkolja az adott sor netmask értékével, ha a keletkezett eredmény megegyezik a sor Destination értékkel, akkor az adott sor Interfészén keresztül elküldi a csomagot. A konyvtar5 esetében ez az utolsó un. defaultroute sor és eth0 interfész lesz, de a 193.225.236.33-re címezve.
    Tehát az ezen az alhálózaton közvetlenül el nem érhetõ IP címzésû csomagokat a 193.225.236.33 címre kell küldeni, az ottani host (router) fogja azt továbbítani. A pepper, mint router mûködik a két alhálózat között. A konyvtar5-nek szóló (to2-tõl érkezett) adatcsomagot a saját route táblájával összevetve (maszkolja a cél IP címet és vizsgálja egyezik-e a Destination-el, egyenlõség esetén) az eth2-es interfészen küldi ki a cél host felé, miután az adatcsomag TTL-értékét csökkentette 1-el. A 193.225.236.64-es alhálózaton a csomag mostmár megérkezhet a cél-hosthoz. Természetesen, ha a to2 egy "külsõ" IP címre (pl.: 195.199.32.125) küldött volna adatcsomagot, router (pepper) a route táblájában nem találta volna, csak a defaultroute sort megfelelõnek, és a 193.225.236.3-as címre küldte volna tovább az adatcsomagot (szintén csökkentve az adatcsomag TTL-értékét).

a to2-es gép route táblája:

Destination	Gateway	Netmask	Interfész
193.225.236.32	*	255.255.255.224	eth0
127.0.0.1	*	255.0.0.0	lo
0.0.0.0	193.225.236.33	0.0.0.0	eth0

a pepper route táblája:

Destination	Gateway	Netmask	Interfész
193.225.236.0	*	255.255.255.224	eth0
193.225.236.32	*	255.255.255.224	eth1
193.225.236.64	*	255.255.255.192	eth2
127.0.0.1	*	255.0.0.0	lo
0.0.0.0	193.225.236.3	0.0.0.0	eth0

a konyvtar5-ös gép route táblája:

Destination	Gateway	Netmask	Interfész
193.225.236.64	*	255.255.255.192	eth0
127.0.0.1	*	255.0.0.0	lo
0.0.0.0	193.225.236.65	0.0.0.0	eth0

Route tábla

    Minden TCP/IP kommunikációban részvevõ host rendelkezik route táblával. Szerepük az útválasztás, mely az elõbb leírtak alapján mûködik. Felépítésük:

• Minden interfészhez tartozik egy bejegyzés.
• Mindig létezik egy loopback interfész (lo).
• A route táblában csak egy defaultroute sor található.
• A route táblában a sorok a netmaskok értékeinek csökkenõ sorrendjében írhatók fel.

    A route tábla megtekintése, módósítása a route paranccsal lehetséges. A route táblával, útvonalakkal kapcsolatos parancsok: ping, netstat, traceroute.
 

10. DNS - hostnév, IP cím meghatározása

    A DNS a hostneveket domain-nek hierarchiájába szervezi. Egy domain olyan helyek gyüjteménye, amelyek valmilyen értelemben rokonok - azért, mert megfelelõ hálózatot képeznek (pl.: a fõiskolai hálózaton levõ összes gép), vagy mert mindegyik egy bizonyos szervezethez tartozik (pl.: az USA kormányához), vagy mert egyszerûen földrajzilag közel vannak. Pl.: a magyar gépek nagyrésze a hu domain-be vannak gyüjtve, mindegyik egyetem vagy fõiskola külön aldomain-t használ, amely alatt a host-jaik vannak. A budapesti Mûszaki Egyetem számára a bme.hu domain-t lehet adni, a matematika tanszék helyi hálózatának pedig a math.bme.hu domain-t. A tanszéki hálózaton levõ hostnévhez (pl. lemma) hozzáadva a tanszéki domain-t (math.bme.hu), így kapnánk a lemma.math.bme.hu-t, mint FQDN-t (Fully Qualified Domain Name) teljes(en minõsített) domain nevet. Lásd 3.sz. ábra.

    Az alábbi ábrán egy névtér részletét mutatja. Ennek a hierachiába szervezett domain rendszernek a csúcsán a pont ".", az un. rootdomain áll, és innen indulki az összes domain. A következõ szinten vannak az un. Top Level Domain-ek (TLD-k) pl.: com, hu, net ...stb. A TLD-k általában az országra jellemzõ ISO-3166 szabványban meghatározott kétbetûs országkód (pl.: fi, at, hu, ch ...stb.), kivétel ezalól az USA TLD-k (org, net, edu, mil, gov ...stb.). Az alájuk tartozó aldomain-ek pl. bme, klte, mfk ...stb. már lehetnek szervezetet, céget, intézményt jelölõ nevek. Az alulról (hostnevektõl kezdve az ágak mentén haladva) összeolvasott név (a domainek között ponttal jelölve a határokat) adja a host (FQDN-t) teljes domainnevét.

    Most a névtér domainhierarchiába való szervezése kellemesen megoldja a névegyediség problémáját; a DNS-nél egy hostnévnek csak a domain-jén belül kell egyedinek lennie, hogy a világ különbözõ részein található összes többi host egyedi legyen. Ezenkívül a teljes domain neveket egész könnyû megjegyezni (www.mfk.hu).
    A domainek kezelését az un. nameserverek végzik. Az egyes domain tartományok (un. zónák) kezelését legalább két domain nameserver végzi. A kettõ ráadásul nem lehet fizikailag egy helyen, így küszöbölve ki, a helyi hálózat meghibásodása esetén, a névfeloldás szünetelését. A zónakezelõ nameszervereket feloszthatjuk funkciójuk szerint master-re(primary) és slave-re(secondary). A master általában a kezelt domain helyihálózatának a közelében, vagy azon található. Ezen kell az új hostneveket felvenni, vagy a megszüntetni kívánt összerendeléseket módosítani, vagy törölni. A nameserver konfigurációja során beállítható, hogy a slave nameserver mennyi idõnként töltse le a teljes zónafile-okat (bennük találhatók a hostnév - IP cím összerendelések az adott zónára), így szinkronizálva magát a masterhez.
 

Névfeloldás a DNS-sel

    Valójában a DNS egy óriási osztott adatbázis. Kezelését nameserverek végzik, amelyek adott domain-re, vagy domainhalmazra vonatkozó információkat biztosítanak. Mindegyik zónához legalább kettõ, de legfeljebb csak néhány nameserver van, amelyek az összes jogosultsági információt a hoston tartják az adott zónában. A www.bme.hu IP címének megszerzéséhez csupán kapcsolatba kell lépnünk a bme.hu zóna nameserver-ével, amely ezután visszaadja a kívánt adatokat, de honnan lehet megtudni kikezeli a bme.hu zónát? Ebben lehet segítségünkre a DNS. Amikor az alkalmazásunk (amely pl. pc114c1.mfk.hu host-on fut és) információt akar szerezni a www.bme.hu-tól, akkor kapcsolatba lép a helyi nameserverrel (193.225.236.10-el), küld neki egy www.bme.hu-s névfeloldási kérést. A nameserver elõször a saját memória cache-ben keresi a választ, ha ott megtalálja, akkor külsõ lekérdezés nélkül válaszol a kliensnek. Amennyiben nem tatálható a nameserver cache-ben, akkor egy lekérdezést küld egy root-nameservernek (ezek listája a nameserver egyik konfigurációs állományában találhatók) A lekérdezés arra vonatkozik, hogy ki a felelõs a hu domain-ért. A root-nameserver válaszában legalább 2 nameserver neve-IP címe érkezik vissza. Ebbõl az egyikre elküld a helyi nameserver egy következõ lekérdezést, amelyben a bme.hu domain-ért felelõs nameserverekre vonatkozik a kérés. A visszaérkezõ válaszban már a bme.hu tartományt kezelõ nameserver lista lesz. A lista valamelyik nameserverétõl már lekérdezhetõ a www.bme.hu IP címe. A választ a helyi nameserver egyrészt tárolja a saját memória cache-ben, és küldi a választ a kliens számára is. A nameserver memória cache-ben csak egy bizonyos ideig tartja frissnek a név - IP cím párost (pár nap), amennyiben ez az idõ lejár, úgy törli azt a cache-bõl.

    Egy példa lekérdezés az nslookup segítségével:

[zsolt@kanga zsolt]$ nslookup
Default Server:  adrienn.mfk.hu
Address:  193.225.236.10

> server A.ROOT-SERVERS.NET
Default Server:  A.ROOT-SERVERS.NET
Address:  198.41.0.4

> set q=ns
> hu
Server:  A.ROOT-SERVERS.NET
Address:  198.41.0.4

Authoritative answers can be found from:
HU      nameserver = NS.NIC.HU
HU      nameserver = NS2.SZTAKI.HU
HU      nameserver = SUNIC.SUNET.SE
HU      nameserver = NS.UU.NET
HU      nameserver = NS2.NIC.FR
NS.NIC.HU       internet address = 193.6.27.62
NS2.SZTAKI.HU   internet address = 193.225.86.1
SUNIC.SUNET.SE  internet address = 192.36.125.2
NS.UU.NET       internet address = 137.39.1.3
NS2.NIC.FR      internet address = 192.93.0.4
> server NS.NIC.HU
Default Server:  NS.NIC.HU
Address:  193.6.27.62

> bme.hu
Server:  NS.NIC.HU
Address:  193.6.27.62

Non-authoritative answer:
bme.hu  nameserver = ns.bme.hu
bme.hu  nameserver = nic.bme.hu

Authoritative answers can be found from:
ns.bme.hu       internet address = 152.66.116.1
nic.bme.hu      internet address = 152.66.115.1
> server ns.bme.hu
Default Server:  ns.bme.hu
Address:  152.66.116.1

> set q=a
> www.bme.hu
Server:  ns.bme.hu
Address:  152.66.116.1

Name:    torpapa.eik.bme.hu
Address:  152.66.116.176
Aliases:  www.bme.hu

> exit
[zsolt@kanga zsolt]$

Fordított keresés (IP címre hostnév)

    Egy hostnévhez tartozó IP cím kikeresése mellett néha szükség van arra, hogy megtaláljuk az IP címhez tartozó teljes domain nevet. Ezt fordított leképzésnek nevezzük, és több hálózat használja kliens azonosítására. Egyetlen hosts file használatakor a fordított keresések egyszerûen egy file-nak a keresését foglalják magukban azon hostok számára, amely a kérdéses IP címmel rendelkezik. DNS-nél a névtér kimerítõ keresése természetesen szóba sem jöhet. Helyette egy különleges domain, az in-addr.arpa jön létre, amely tartalmazza az összes host IP címét fordított pontozott jelöléssel. A 193.225.236.10 IP cím például a 10.236.225.193.in-addr.arpa névnek felel meg. A fordított keresés hasonlóan old fel egy IP címet, mint az elõzõleg leírt névfeloldás (elõször root-nameservernek egy arpa lekérdezés... stb.). Lásd 4.sz. ábra:

    A nameserver konfigurációs állományaiban van beállítva:

• root-nameserverek hostneve - IP címe,
• 0.0.0.127.in-addr.arpa zóna,
• domain zóna, pl.: mfk domain,
• domain reverse zóna, az mfk-hoz: 236.225.192.in-addr.arpa.

 Egy példa a bind v8 nameserver konfigurációs állományaira

11. TELNET, FTP

A telnet protokollal a gépek közötti távoli bejelentkezés oldható meg. A belépés után a terminálról úgy tudunk dolgozni, mintha a távoli gép elõtt ülnénk, azaz a távoli gép operációs rendszerével állunk kapcsolatban, parancsainkat a telnet protokoll adja át a távoli gép operációs rendszerének, és azt a távoli gép hajtja végre, az "eredmény" pedig a terminál képernyõjén jelenik meg. Így válik lehetõvé, hogy a távoli gépen programokat futtassunk, megnézzük az érkezett leveleinket, stb. Folyamatos (on-line) hálózati kapcsolatot igényel. A belépés feltétele, hogy rendelkezzük a távoli gépen un. account-tal (username, password pár).

A telnet kliens parancssori alakja:    telnet távoligép név vagy IP cím portszám

pl.: telnet kanga.mfk.hu 80, ez a parancs létrehoz egy kepcsolatot a TELNET protokoll alatt a kanga.mfk.hu 80-as portjával (http port!). Válasz képpen a következõ jelenik meg:

[zsolt@kanga zsolt]$ telnet kanga.mfk.hu 80
Trying 193.225.236.15...
Connected to kanga.mfk.hu.
Escape character is '^]'.
_

A HTTP protocol ismeretében írhatjuk, hogy:

GET / HTTP/1.0

és két ENTER (egy ENTER-rel zárjuk a kérést, és a protokoll megkövetel egy üressort is a kérés után).
Válasz a kanga.mfk.hu HTTP-szerverének nyitóoldala HTML forrás szöveg formájában.
 

FTP

    Az FTP protokoll a hálózatban levõ gépeken megtalálható file-ok átvitelére használható. Használatához folyamatos hálózati kapcsolat szükséges. Sávszélességigénye jelentõs, adott idõn belül nagyobb mennyiségû adat átvitelét kell megoldani. Ideális esetben néhány kbit/s átviteli sebesség már elfogadható.
    Az FTP protokoll 2 mûködési módja: binary és az ASCII. Az ASCII 7 bites átvitelt használ, így csak szöveges állományok átvitelére alkalmas, míg a binary bármilyen file-ra. A felhasználó csak akkor tud egy szerverre adatot "feltölteni", ha azon rendelkezik a megfelelõ jogosulságokkal.
    A kapcsolat felépítéséhez egy kliens program szükséges, ami a UNIX rendszereken az ftp.
    Lépései:

1.  ftp távoli ftp szerver címe (hostname vagy IP cím)
2. a sikeres bejelentkezéshez username, password gyakoriak az un. anonymous ftp szerverek, melyek nyilvánosak, ingyen letölthetõ állományokat tartalmaznak. Ilyen esetben a username: anonymous, a password: saját e-mail címünk.
3. Sikeres belépés után használhatók az ftp parancsai: cd, lcd, ls, get, put, binary, ascii... stb. Az ftp szerver filerendszerében lehet megkeresni, majd letölteni, vagy feltölteni a kívánt állomány(oka)t.
4. Majd a quit paranccsal lehet az ftp kapcsolatot bontani a távoli szererrel.

Részletesebben:

                                            -------------
                                            |/---------\|
                                            ||   User  ||    --------
                                            ||Interface|<--->| User |
                                            |\----^----/|    --------
                  ----------                |     |     |
                  |/------\|  FTP Commands  |/----V----\|
                  ||Server|<---------------->|   User  ||
                  ||  PI  ||   FTP Replies  ||    PI   ||
                  |\--^---/|                |\----^----/|
                  |   |    |                |     |     |
      --------    |/--V---\|      Data      |/----V----\|    --------
      | File |<--->|Server|<---------------->|  User   |<--->| File |
      |System|    || DTP  ||   Connection   ||   DTP   ||    |System|
      --------    |\------/|                |\---------/|    --------
                  ----------                -------------

                  Server-FTP                   USER-FTP

    Az adatátvitel közben két csatorna épül ki a kliens és a szerver között: egy vezérlõ- és egy adatcsatorna. A kliens program elõször az ftp szerver 21-ös portjával épít ki kapcsolatot, így jön létre a vezérlõcsatorna, itt zajlik az FTP parancsok átvitele és a szerver is itt küldi vissza ezekre a válaszait. Az FTP parancsok határozzák meg az adatcsatorna paramétereit (ftp adatport, átvitel módja, típusa és szerkezete), és a állományok átvitelét (tárolás, letöltés, hozzáfûzés, törlés, ...stb.). A kliensnek kell figyelni az adott porton, és a szerver fogja kezdeményezni az adatcsatorna felépülését a kapott paraméterek, és parancsok alapján. Megjegyzendõ, hogy nem kötelezõ, hogy ugyanaz a kliens figyelje az ftp adatportot, mint amelyik klienssel felépítette a szerver az ftp vezérlõcsatornát, de lennie kell egy kliensnek, amelyik figyeli az adott ftp adatportot. A protokoll megköveteli, hogy a vezérlõcsatorna nyitva legyen, míg az adatátvitel folyamatban van. A kliens programnak (felhasználónak) kell gondoskodni arról, hogy a trenzakció után a vezérlõcsatornát zárja, bár van szerver ami maga végzi ezt. A szerver megállíthatja az adatátvitelt, ha a vezérlõcsatorna parancs nélkül záródik.

FTP parancsok:

Hozzáférési parancsok:

• USER - username, a felhasználó neve
• PASS - password, jelszava
• CWD - change working directory, könyvtár váltás
• CDUP - change to parent directory, egy szinttel feljebb a könyvtárstruktúrában
• QUIT - kilépés
• ACCT, SMNT, REIN.

Adatátvitel paraméteri parancsok:

• PORT - data port, meghatározza az adatátvitelkori HOST-PORT értékét
• PASV - passive mód, a server adat csatorna figyelésbe kezd egy porton, várva a kapcsolatot, ellentétesen a szokásossal, ahol a szerver kezdeményezi a kapcsolatot a kliens adatcsatonájával.
• TYPE, STRU, MODE.

FTP (service) parancsok:

• RETR - retrieve, állomány letöltése a szerverrõl
• STOR - store, állomány feltöltése a szerverre
• ABOR - abort, az elõzõ FTP (service) parancs felfüggesztése
• HELP - help, a parancsok listája
• STOU, APPE, ALLO, REST, RNFR, RNTO, DELE, RMD, MKD, PWD, LIST, NLST, SITE, SYST, STAT, NOOP.

12. E-mail: smtp, pop3, imap

Hogyan épül fel egy e-mail?

    Egy elektronikus levél általában egy üzenettörzsbõl - ami maga az üzenet szövege -, valamin a cimzetteket, átviteli útvonalat stb.meghatározó különleges adatokból áll, hasonlóan egy postai levélhez, és a borítékhoz.
    Ezek az adminisztratív adatok két csoportra bonthatók:

1. az átviteli útvonal: a feladó rendszer címe és adatai, a címzett rendszer címe és adatai, esetleges érintett rendszerek címei. Ezt a részt borítéknak nevezik.
2. a levél kezeléséhez szükséges adatok, amely független a szállítástól, levél címsora, cimzettek listája, küldés dátuma ...stb.

    A fejlécmezõ a következõ általános alakban írható:

    <fejlécmezõ neve>:    <fejlécmezõ értéke>

    Egy levélfejléc minta:

From steve@teleki-mezotur.sulinet.hu  Thu May 20 08:13:24 1999
Return-Path: <steve@teleki-mezotur.sulinet.hu>
Received: from server.teleki-mezotur.sulinet.hu (IDENT:root@server.teleki-mezotur.sulinet.hu [195.199.32.125])
        by adrienn.mfk.hu (8.9.3/8.9.3) with ESMTP id IAA11162
        for <zsolt@mfk.hu>; Thu, 20 May 1999 08:13:16 +0200
Received: from localhost (localhost [[UNIX: localhost]])
        by server.teleki-mezotur.sulinet.hu (8.9.3/8.9.3) id IAA02107;
        Thu, 20 May 1999 08:13:20 +0200
Message-Id: <199905200613.IAA02107@server.teleki-mezotur.sulinet.hu>
Date: Thu, 20 May 1999 08:13:20 +0100
To: zsolt@mfk.hu
X-Mailer: IMHO for Roxen
Content-Type: multipart/mixed;boundary="'ThIs-RaNdOm-StRiNg-/=_.628607942:"
Content-Transfer-Encoding: 8bit
From: Andrássy István <steve@teleki-mezotur.sulinet.hu>
Subject: szakirány eredmények
MIME-Version: 1.0
Status: RO
X-Status:
X-Keywords:

ESMTP

    Az RFC822-ben definiált dokumentumtovábbítási módszer komoly korlátozása a 7-bites NVT ASCII karakterkészlet alkalmazása. E korlátozás miatt például az Internet hálózatban nem küldhetünk olyan dokumentumokat elektronikus levélként, amelyek az ISO Latin-2 kódolás szerint magyar ékezetes betûket tartalmaznak. E korlátozások megkerülésére két mód is van: vagy lazítani kell azon a megkötésen, hogy csak 7-bites NVT ASCII karakterek továbbíthatók elektronikus dokumentumokban, vagy pedig a dokumentumok tartalmát szükség esetén 7-bites NVT ASCII formára kell konvertálni (fejlécmezõk tartalmával együtt). Az elsõ megoldást alkalmazták például az ESMTP (RFC1425, 1426) levéltovábbítási protokoll tervezõi, akik létrehozták az SMTP protokollnak egy általánosan alkalmazható kibõvítési módszerét, és egyben definiálták egy olyan bõvítését, amely lehetõvé teszi tetszõleges byte-ok átvitelét.
    Az ESMTP-t ismerõ levelezõ kliens program egy erre alkalmas paranccsal  jelezheti az ESMTP szervernek azt, ha a levél törzsében nem csak NVT ASCII karaktereket akar küldeni (persze csak miután meggyõzõdött arról, hogy a szerver támogatja ezt a lehetõséget).
 

MIME

    Az RFC822 szabvány nem támogatja az elektronikus üzenetek többféleségét (a bináris adatok, PostScript állományok, multimédiás állományok stb.). Az ezeket a szempontokat lefedõ szabványokat és RFC-ket általánosan MIME (Multipurpose Internet Mail Extensions - RFC 2045, 2046, 2047, 2048, 2049) néven emlegetik. Egyebek közt ez azt is tudatja a címzettel, hogy a szabványos ASCII-tõl eltérõ karakterkészletet használunk-e az üzenet írásakor, például a magyar magánhangzók problémamentes átvitelére.
    A MIME lényege, hogy a fejléc tartalmazhat kódolt ábrázolású szavakat az alábbi ábrázolásmódban (egy ilyen kódolt rész maximum 75 karakter hosszú lehet):

        =?karakterkészlet?kódolási mód?kódolt szöveg?=

    A karakterkészlet az eredeti (kódolatlan) szöveg leírásához használt karakterkészlet azonosítója (us-ascii, vagy iso-8859-x lehet, ahol az x egy számjegy, az alkalmazott karaktrkészlet ISO szabvány szerinti kódja). A kódolási mód rész egyetlen karakter hosszú, és "q" vagy "b" lehet, azt határozza meg, hogy az eredeti (kódolatlan) szövegbõl milyen módon kaptuk meg a kódolt formát. A "q" betûvel jelölt kódolás az eredeti szöveg azon karakterei helyett, amelyeknek a 8. bitje nem nulla, a hexadecimális kódját írja egy egyenlõség "=" jet után. Például a magyar nyelv összes karakterét tartalmazó ISO 8859-2 karakterkészlet "é" betûje helyett az =E9 szöveget írja a fejlécbe. A "b" betûvel jelölt kódolás az un. base-64 kódolási módot azonosítja. Ekkor a szöveg három egymás utáni byte-ja (24 bit) négy db. 6 bites részre lesz felosztva, és e hatbites részek lesznek egy-egy NVT ASCII karakterrel kódolva a következõ szabály szerint:
 

Hatbites kód decimális értéke:	Kódoláshoz használt karakter:
0..25	A..Z
26..51	a..z
52..61	0..9
62	+
63	/

    A kódolt szöveg részben ezeken kívül használhatunk még egyenlõség jeleket helykitöltésre, ha a kódolandó karakterek száma nem osztható hárommal.

    Ugyanezen probléma megoldására kifejlesztettek egy másik eszközt (MIME), ennek lényege az átvitt információnak az RFC822-ben rögzített NVT ASCII formára való alakítása és kiegészítése a visszaalakításhoz szükséges további információkkal (a MIME nem csak NVT ASCII formátumú átvitelt támogatja, de azt minden esetben támogatja). A MIME-szabvány szerinti formára konvertált információkat egy un. MIME-fejléccel kell kiegészíteni, ami segíti az információ eredeti formájára történõ visszaalakítást végzõ program munkáját.
    A MIME által specifikált dokumentum fejléc a következõ mezõket tartalmazhatja:

MIME-Version: 1.0
Content-Type: típus/pontosítás; paraméternév=paraméterérték
Content-Transfer-Encoding:
Content-ID:
Content-Description:

    A MIME alaptípusai:
 

text	Szöveges információ átvitele
image	Képi információ átvitele
audio	Hanginformáció átvitele
video	Mozgóképek átvitele
application	Valamilyen alkalmazás átvitele
message	RFC822 elõírásait követõ dokumentumot tartalmaz
multipart	A MIME-dokumentum több ugyancsak MIME formátumban levõ dokumentumból áll

    A dokumentumtípus azonosítók utalnak ugyan az átvitt adatok eredetére, de a MIME-fejlécben egy "/" után a MIME-dokumentumban levõ információk további jellemzõit is meg kell adni.

    A MIME pontosított dokumentumtípus-specifikációi (csak példák, nem az összes):
 
 

text/plain	Szöveges információ formázatlan szöveggel.
text/hlmt	Hypertext formázási elemeket tartalmazó szöveg, HTML formában.
image/jpeg	JPEG formában tárolt képi információ.
image/gif	GIF formában tárolt képi információ.
audio/basic	8000 Hz-en mintavételezett, mono, 8 bites hang információ.
video/mpeg	MPEG formában tárolt mozgókép információ.
message/rfc822	A törzs egy RFC822-szerint megírt dokumentumot (pl.: e-mailt) tartalmaz.
message/partial	A törzs egy RFC822-szerint megírt dokumentum egy részét tartalmazza. A dokumentum önmagában túl nagy lenne ahhoz, hogy egy levélben küldjék el, ezért feldarabolták.
multipart/mixed	A törzs több ugyancsak MIME-formában levõ dokumentumból áll, amiket egymás után kell feldolgozni.
multipart/digest	A MIME-törzs több részbõl áll, mindegyik rész MIME típusa message/rfc822.
application/octet-stream	A MIME dokumentumot feldolgozó program nem tudja a MIME-törzs tartalmát értelmezni, javasolni kell a felhasználónak, hogy mentse ki a tartalmát egy file-ba.
application/postscript	PostScript lapleíró formáan tárolt dokumentum vagy alkalmazás.

    A Content-Transfer-Encoding mezõ a MIME-törzsben levõ adatok kódolási módját tartalmazza. A MIME öt kódolási módot specifikál, és rögzíti a saját magunk által bevezetett kódolási formák elnevezésének konvencióit.
 

7bit	A tartalom NVT ASCII formában van, nincs kódolva.
8bit	A tartalom tetszõleges 8 bites karaktereket tartalmazó sorokból áll, nincs kódolva.
binary	A tartalom tetszõleges jelekbõl állhat, nincs sorokra bontva.
quoted-printable	A tartalom "q" típusú kódolással van 7-bites NVT ASCII formára kódolva (a kódolási algoritmust a nem NVT ASCII karakterek fejlécekbe illesztésénél láttuk).
base64	A tartalom az elõbb ismertetett "b" típusú (base64) módon van kódolva.
x-valami	Egy saját magunk által kidolgozott kódolási mód neve ilyen alakú lehet.

    A Content-ID MIME-fejlécmezõ a MIME-törzs egyide azonosítóját tartalmazza, amivel más dokumentumokból is hivatkozhatunk a kérdéses dokumentum tartalmára. Ez a mezõ opcionális, megadása nem csak a message/external-body MIME-típus esetén kötelezõ.
    A Content-Description MIME-fejlécmezõ a MIME-törzs tartalmára vonatkozó megjegyzéseket tartalmazza. Ez az üzenet általában a dokumentumot olvasó felhasználónak szóló megjegyzés.

    Álljon itt egy példa MIME-formátumú e-mail-re:

From steve@teleki-mezotur.sulinet.hu  Thu May 20 08:13:24 1999
Return-Path: <steve@teleki-mezotur.sulinet.hu>
Received: from server.teleki-mezotur.sulinet.hu (IDENT:root@server.teleki-mezotur.sulinet.hu [195.
199.32.125])
        by adrienn.mfk.hu (8.9.3/8.9.3) with ESMTP id IAA11162
        for <zsolt@mfk.hu>; Thu, 20 May 1999 08:13:16 +0200
Received: from localhost (localhost [[UNIX: localhost]])
        by server.teleki-mezotur.sulinet.hu (8.9.3/8.9.3) id IAA02107;
        Thu, 20 May 1999 08:13:20 +0200
Message-Id: <199905200613.IAA02107@server.teleki-mezotur.sulinet.hu>
Date: Thu, 20 May 1999 08:13:20 +0100
To: zsolt@mfk.huX-Mailer: IMHO for Roxen
Content-Type: multipart/mixed;boundary="'ThIs-RaNdOm-StRiNg-/=_.628607942:"
Content-Transfer-Encoding: 8bit
From: Andrássy István <steve@teleki-mezotur.sulinet.hu>
Subject: szakirány eredmények
MIME-Version: 1.0
Status: RO
X-Status:
X-Keywords:
 

--'ThIs-RaNdOm-StRiNg-/=_.628607942:
MIME-Version: 1.0
Content-Length: 95
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1

Helló!

Ez itt a levél...

steve
steve@mfk.hu
--'ThIs-RaNdOm-StRiNg-/=_.628607942:
Content-Disposition: attachment;filename=gateszakirpot.xls
MIME-Version: 1.0
Content-Length: 20320
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGwAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAABoAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
.
.
.
.
.
BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAACgAAgEBAAAAAwAAAP/////IVkAAAAAAAAAAAAACAAAAAAAAAAAAAAANAAAAAgAAAAgE
AAAKAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt
AGEAdABpAG8AbgAAAAAAAAD///8AOAACAf///////////////wAAAAAAAAAABAAAAAMAAAAAAAAA
AAAAAF0DAKBEakAAFFxAABIAAAAAEAAAAAAAAA==
--'ThIs-RaNdOm-StRiNg-/=_.628607942:--

    A multipart alaptípusú MIME-dokumentumok részeit elválasztó karaktersorozat kijelölésére a boundary nevû paramétert használjuk A részeket elválasztó sor két kötõjellel ("-") kell, hogy kezdõdjön; ezt a boundary paraméter értéke kell, hogy kövesse, majd esetleg szóközök, és sorvége jel. Az elsõ MIME-komponens az elválasztó sor elsõ elõfordulásánál kezdõdik, és a komponenseket ugyanilyen elválasztó sorok választják el egymástól, illetve zárják le.
 

Levél kézbesítés

    Általában a levelet egy levelezõ kliens programmal állítjuk össze. Ezekez a programokat levelezési felhasználói ügynököknek (MUA - Mail User Agent) nevezzük. Ha küldünk egy e-mailt, akkor a levelezõ kliens program legtöbb esetben ezt egy másik programnak adja át kézbesítésre. Ezt levelezési szállító ügynöknek (MTA - Mail Transfer Agent) nevezzük. Egyes rendszereken különbözõ levelezési szállítási ügynök található a helyi és távol kézbesítésre; másokon csak egy van.
    A levél helyi kézbesítése természetesen többet jelent, mint csupán a bejövõ üzenet hozzáfûzése a címzett postaládájához. A helyi MTA általában érteni fogja az álnevet (aliases - a helyi címzettek címeit, amelyek más címekre mutatnak), valamint a továbbítást (forward - a felhasználói levél másik rendeltetési helyre való átirányítása). A nem kézbesíthetõ leveleket vissza kell küldeni a feladónak egy hibaüzenettel együtt.
    Távoli kézbesítésnél, mivel TCP/IP-t használunk, általában SMTP-t (Simple Mail Transfer Protocol - RFC821) használunk. Az SMTP általában közvetlenül kapcsolódik a címzett gépéhez, a távoli oldal SMTP démonjával egyeztetve az üzenetátvitelt.
 

SMTP

    Az SMTP protokoll a következõ kommunikációs modellen alapul:

               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Sender- |Commands/Replies| Receiver-|
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
 

                Sender-SMTP                Receiver-SMTP

    A levelezõ kliens program, miután a felhasználó megszerkesztette az elküldendõ levelét, az RFC822 és a MIME szerint összeállítja az elektronikus üzenetet és egy kapcsolatot épít ki az SMTP démonnal (tcp, 25-ös port). A kapcsolat felépülése után a levélküldõ kliensprogram az SMTP protokollnak megfelelõ parancsokat küld az SMTP démonnak, amire az válaszokkal reagál. Az adatátvitel végeztével a kliens kezdeményezi a kapcsolat bontását.
    Miután felépült a kapcsolat a küldõ és a fogadó között, akkor egy MAIL parancsot (a feladó e-mail címével) küld a kliens program, amennyiben a SMTP démon kész az üzenetek fogadására, egy OK-t válaszol. Ezután a kliensprogram egy RCPT parancsot (a címzett e-mail címével) küld a kliens program, ha az SMTP démon képes a kézbesítésre, egy OK-t válaszol. Ha nem képes a kézbesítésre, akkor hibaüzenetet kapunk, de a kapcsolat nem bomlik, csak új címzettre (RCPT) vár. Több címzett is lehet (több RCPT parancs egymás után). Ezekután a kliens elküldi magát az üzanetet, speciális karaktersorozattal zárva azt. Ha sikeres levélfogadásra az SMTP démon OK-t válaszol. Ha a címzett "postaládája" nem azon a host-on található, amelyikkel a kliens felépítette a kapcsolatot, és az SMTP démon konfigurációjában engedélyezve van, akkor a démon tovább küldi a címzett host SMTP démonjához kézbesítésre az átvett üzenetet. Ezt a folyamatot relay-zésnek nevezik. Amennyiben nem engedélyezzük a relay-t csak egy bizonyos kliens körnek (pl. egy adott domainnek pl. mfk.hu), akkor külsõ relay kérést az SMTP démon visszautasít.

    Egy e-mail továbbításának lépései az SMTP protokoll szerint:

1. Kapcsolat felépítése az SMTP démonnal (tcp, 25-ös port)
2. HELO küldõ hostnév <CRLF>
3. MAIL FROM: feladó e-mail címe <CRLF>

250 OK a válasz
RCPT TO: címzett e-mail címe <CRLF>
250 OK a válasz
.
.  esetleg több címzett
.
4. DATA <CRLF>

354 ...................  ; end with <CRLF>.<CRLF>
.
.
. a levél maga...
.
.
5. QUIT <CRLF>

E-mail címek

    Elektronikus levelezésnél egy cím legalább a személy postáját kezelõ gép nevébõl és a rendszer által felismert felhasználói azonosítóból áll. Ez lehet a címzett bejelentkezési neve, de bármi más is.
    Az Interneten az RFC822-es szabvány szerint: felhasználó@hostname.domain jelölést követel meg, ahol a hostname.domain a host teljes neve.
 

Levelezési útválasztás

    Egy üzenetnek a címzett host-hoz való irányítását útválasztásnak nevezzük. A küldõ oldaltól a rendeltetési helyig való õtvonal megtalálásán kívül hibaellenörzést és költségoptimalizálást is magában foglal. Az Interneten az adatoknak a címzett host-ra (ha az az IP címe alapján ismert) küldésének fõ feladatát az IP hálózatkezelõ réteg végzi.
    Az Interneten teljesen a rendeltetési hely host-jától függ, hogy valamilyen sajátos levelezési útválasztás végrehajtásra kerül-e. Az alapértelmezés: az üzenetnek közvetlenül a rendeltetési hely host-jára való küldése - az utóbbi IP címét kikeresve és az adatok tényleges útválastását az IP hálózati rétegre hagyva.
    A legtöbb hely általában az összes levelet egy olyan, jól elérhetõ levelezési kiszolgálóra akarja irányítani, amely képes helyileg kezelni mindezt a forgalmat és elosztani a postát. Ehhez a szolgáltatáshoz a helyi DNS adatbázisában egy MX (Mail eXchanger) rekordot kell bejegyezni. Az MX rekorddal bejegyzett host fogja betölteni a helyi domain tartomány levéltovábbítójának a szerepét.
    Az MX rekordoknak van egy velük kapcsolatos preferenciájuk is. Ez egy pozitív egész szám (10, 20...). Ha több MX rekord van egy host-hoz, a levelezési szállítási ügynök meg fogja próbálni átadni az üzenetet a legkisebb preferencia értékû MX rekordú host levelezési szállítási ügynökének, és csak ha ez nem sikerül, akkor fogja megpróbálni egy magasabb értékkel. Ha maga a helyi host is rendelkezik MX rekord bejegyzéssel egy rendeltetési cím számára, nem szabad a sajátjánál magasabb preferenciájú üzeneteket továbbítania az MX rekordú host-okhoz; ez egy biztonságos mód a levélhurkok elkerülésére.
 

POP3 (RFC1081) és IMAP (RFC1730)

    A "levelesládába" érkezõ levelek olvasására többféle levelezõ kliens program alkalmas. Közös bennük, hogy 1-2 kivételtõl eltekintve, (melyek közvetlen a mailbox-ból "olvassák fel" a leveleket) két protokollt használnak a mailbox kezelésére.

    Az egyik a POP3, melynek 3 jól elhatárolható állapota van mûködés közben. Elöljáróban annyit, hogy a POP3 démon sikeres akció esetén a "+OK"-t, míg a sikertelen akció esetén "-ERR"-t válaszol.

    A kliens levelezõ program kapcsolat felépítését kezdeményezi a POP3-as démonnal (tcp, 110-es port).

+OK
1. AUTHORIZATION állapot (AZONOSÍTÁS)

    Ebben az állapotban a démon a kliens azonosítására (felhasználó azonosításra) vár.
    Ebben az állapotban a következõ parancsokat küldheti a kliens:

Parancs:	Válasz:
USER felhasználóneve	+OK / -ERR
PASS felhasználó jelszava	+OK / -ERR
QUIT	Kilépés. (Egyszerû kilépés, nincs UPDATE állapot!)

2. TRANACTION állapot (TRANZAKCIÓS)

    Ebben az állapotban a démon a kliens (felhasználó) postaládájával kapcsolatos tranzakciós parancsaira vár.
    Ebben az állapotban a következõ parancsokat küldheti a kliens:

Parancs:	Válasz:
STAT	+OK max-id total-octets ahol a max-id az összes üzenet száma, a total-octets a postaláda mérete
LIST [id]	+OK id-octets / -ERR ahol a id-octets az adott id üzenet mérete
RETR id	+OK / -ERR +OK esetén az adott id üzenetet küldi a démon válaszul
DELE id	+OK / -ERR +OK esetén az adott id üzenet jelölése törlésre (csak jelölése!)
RSET	+OK kijelölések visszavonása
QUIT	Kilépés, de UPDATE állapotba kerül

3. UPDATE állapot (FRISSÍTÉS)

Ebben az állapotban a démon a kijelölt üzeneteket törli a felhasználó postaládájából és a lefoglalt erõforrásokat felszabadítja.

+OK Sayonara

És bontja a kapcsolatot a klienssel.
 

            +--------------------------------------+
            |initial connection and server greeting|
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      VV           ||            ||
            +--------------------+ ||            ||
            |non-authenticated NA| ||            ||
            +--------------------+ ||            ||
             || (7)   || (4)       ||            ||
             ||       VV           VV            ||
             ||     +-----------------+          ||
             ||     | authenticated A |<=++      ||
             ||     +-----------------+  ||      ||
             ||       || (7)   || (5)    || (6)  ||
             ||       ||       VV        ||      ||
             ||       ||    +----------+ ||      ||
             ||       ||    |selected S|=++      ||
             ||       ||    +----------+         ||
             ||       ||       || (7)            ||
             VV       VV       VV                VV
            +--------------------------------------+
            |     logout and close connection  L   |
            +--------------------------------------+

         (1) connection without pre-authentication (OK greeting)
         (2) pre-authenticated connection (PREAUTH greeting)
         (3) rejected connection (BYE greeting)
         (4) successful LOGIN or AUTHENTICATE command
         (5) successful SELECT or EXAMINE command
         (6) CLOSE command, or failed SELECT or EXAMINE command
         (7) LOGOUT command, server shutdown, or connection closed

    Egy IMAP protokollt ismerõ kliens levelezõ program segítségével a mail serveren tartható karban a felhasználó postaládája; "mappák" készíthetõk, átnevezhetõk, törölhetõk; közöttük a protokoll alapján üzeneteket mozgathatunk egyik mappából a másikba. A mappa kezelés egyszerû file mûveletként zajlik. A felhasználó home könyvtárában alapértelmezett ~/Mail könyvtárban jönnek létre a mappák nevén azok az állományok, melyekben tárolódnak mappánként (állományonként) az üzenetek (pl.: ~/Mail/Trash).

    Az elsõ lépés itt is a kapcsolat felépítése a kliens levelezõ program és az IMAP démon között (tcp, 143-as port). Belépés után a démon üdvözlõ szöveget küld, és vár a parancsokra. Egy parancs elküldése után az IMAP démon választ küld, mely két részbõl áll:
elsõ amiben maga a válasz van, a másik amiben a parancs végrehajtásáról értesít. Egy kliens parancs a következõ képpen néz ki:

    A0001 login usernév jelszó

    Minden kliens parancs egy parancs azonosítóval kezdõdik, és parancsonként egyedi. A következõ maga a parancs és argumentumai. Léteznek olyan parancsok, melyek állapottól függetlenül adhatók ki, vannak olyanok, melyek csak bizonyos állapotban.
Bármely állapotban mûködik a

NOOP - nincs mûvelet. Mindig sikeres.
LOGOUT - kilépés.

1. Non-Authenticated állapot (NA)

    Ebben az állapotban a IMAP démon a felhasználói azonosításra vár. A kapcsolat felépítése után ebbe az állapotba kerül a kiszolgálás, kivétel, ha egy pre-authenticated kapcsolat épült fel, mert akkor egybõl a 2. állapotba.
Parancsok:
LOGIN felhasználóneve jelszava
AUTHENTICATE azonosítási rendszer neve
Sikeres felhasználó azonosítás után a 2. állapotba kerül a kiszolgálás.
 
2. Authenticated állapot (A)

    Ebben az állapotban a IMAP démon a mappákkal kapcsolatos mûveletekre képes (mappa megnyitása, új mappa létrehozása, mappa törlése, mappa átnevezés, lista a mappákról ...stb.).

Parancsok:

 
SELECT mappanév - megnyitja a mappát írásra-olvasásra. Sikeres megnyitással a 3. állapotba kerül a kiszolgálás.
EXAMINE mappanév - megnyitja a mappát csak olvasásra. Sikeres megnyitással a 3. állapotba kerül a kiszolgálás.
CREATE
DELETE
RENAME
SUBSCRIBE
UNSUBSCRIBE
LSUB
APPEND
LIST
3. Selected állapot (S)

    Ebben az állapotban a IMAP démon a kiválasztott mappában az egyes üzenetekkel kapcsolatos mûveletekre képes (üzenet olvasása, üzenet kijelölése ... stb.).

Parancsok:

 
FETCH message set message data item names
    ahol a message set - az üzenet száma (4), vagy üzenetek (3:5)
    ahol a message data item names - az adott üzenetbõl "megjeleníteni" kívánt
                                                           alkotórész pl.: rfc822, rfc822.header, rfc822.body
CLOSE - az összes /Deleted flag-gel jelölt üzenet törlése a mappából (ha SELECT-tel volt kiválasztva a mappa), majd a 2. állapotba kerül a kiszolgálás.
CHECK
EXPUNGE - az összes /Deleted flag-gel jelölt üzenet törlése a mappából (ha SELECT-tel volt kiválasztva a mappa).
SEARCH
PARTIAL
STORE - pl.: az üzenetek flag-jei állítható a paranccsal, például a  /Deleted flag.
UID
4. Logout állapot (L)

    Ebben az állapotban a démon a lefoglalt erõforrásokat felszabadítja és bontja a kapcsolatot a klienssel.

13. HTTP, HTML

14. Proxy szerverek

    Megvizsgálja a cache rendszerét (elõször a cache-memóriát, ha ott nem találja akkor a winchester un. cache-swap területet, természetesen mindkettõ indexelt a gyors találatok érdekében), ha cache találat van, akkor a válasz onnan érkezik a klienshez.
    Amennyiben a cache-ben nem található az adott objektum, úgy a szerver továbbítja a kérést egy a hierarchikus (szülõ-gyerek (parent-child)) proxy-cache szerkezetben egy un. parent cache címére, ha az létezik, akkor az is hasonlóan jár el a hozzáérkezett kéréssel. Jó esetben a cache-ek között a kommunikáció egy un. ICP-n (Internet Cache Protokollon) keresztül zajlik.
    Ha egy beállított idõn belül nem érkezik válasz a felsõbb szintû cache-tõl, vagy nincs felsõbb szinten (a hierarchiában) cache, vagy az õ cache területén sincs meg a keresett objektum, akkor a kérést el kell küldeni a konkrét Internet szerver felé.
    A keresett objektum megérkezése után a proxy-cache szerverek, konfigurációtól függõen, leteszik azt a cache-memóriájukba egy idõbélyeggel. A proxy-cache szerver idõvel ezeket az öregebb objektumokat, beállításától függõen (pl. "frissebb" objektumokkal töltve meg a cache-memóriát), átmozgatja a wincheszter cache-swap területre. Majd üríti a cache-swap területrõl, amennyiben az objektumot már "régóta" nem kérték.
    Látszik a fenti leírásból is, hogy a proxy-cache szerverek (fõképp a hierarciába szervezettek) sok szempont figyelembe vételével konfigurálhatók, beállításuk nem egyszerû feladat, az optimális mûködéshez pedig "hangolásuk" szükséges.

    Egy másik lehetséges felhasználás az un. http-accelerator mód, melynek használatával a proxy-cache szervert egy létezõ HTTP-szerver "elé" tesszük, õ szolgálja ki a klienseket, a tényleges HTTP-szervertõl pedig csak õ kér adatot. Ez fõleg "extra" látogatott helyek esetében érdemes megvlósításra.

    Emellet persze létezik sok más proxy vagy gateway, például Real Audio proxy, irc proxy, ftp gateway vagy news gateway.
 
 
 

A dokumentum még nem teljes, bõvítése hamarosan folytatódik.