Az eddigiekben azt vettük sorra, hogy egy üzenet hogyan darabolódik szét, hogyan jut el egy géptõl egy másikig, majd ott hogyan áll ismét össze. Mindez még kevés ahhoz, hogy hasznos dolgot lehessen végezni. Szükség van valamilyen módszerre, amelynek segítségével egy másik számítógéppel kapcsolatba lehet lépni, oda be lehet jelentkezni, közölni lehet vele, hogy milyen adatokra van szükségünk, illetve amellyel az adatok átvitelét szabályozni tudjuk. (Más alkalmazás, pl. elektronikus levelezés, esetén is ezzel analóg protokollra van szükség.) Ezt a feladatot az alkalmazási réteg protokolljai végzik el, amelyek a TCP/IP tetején találhatóak. Ez annyit jelent, hogy üzenet küldésekor azt a TCP-nek továbbítják, amely gondoskodik róla, hogy eljusson a célállomáshoz. Mivel a TCP és az IP kezelik a hálózati vonatkozásokat, ezért az alkalmazási protokollok a hálózatot egyszerû byte-folyamnak tekintik, mint például egy terminál- vagy telefonvonalat.
Mielõtt az alkalmazói programokkal kapcsolatban további részletekbe bocsátkoznánk, meg kell vizsgálnunk, hogy hogyan lehet egy alkalmazást megtalálni. Tegyük fel, hogy egy állományt szeretnénk küldeni a hálózaton keresztül a 124.6.4.7 IP címû gépnek. A folyamat elindításához azonban az Internet címnél többre lesz szükség. A célállomás oldalán az FTP kiszolgálóval fel kell venni a kapcsolatot. A hálózati programokat általában külön feladatok elvégzésére programozzák. A különbözõ feladatokat (állományátvitel, bejelentkezés távoli terminálról, levelezés stb...) a legtöbb rendszerben más-más programok végzik. Amikor a fenti példában a 124.6.4.7 címû géppel kapcsolatot építünk ki, akkor azt is meg kell mondanunk, hogy az ottani FTP kiszolgálóval szeretnénk kommunikálni. Ennek megvalósítására minden kiszolgáló jól ismert socket-ekkel ( foglalatok, szolgálatelérési pontok) rendelkezik. Ennek magyarázataképpen tekintsük a következõket. Emlékezzünk vissza, hogy a TCP a különbözõ kommunikációk kézben tartására különbözõ portokat használ. A felhasználói programok többé-kevésbé véletlenszerûen választanak portot, de egyes portok eleve olyan programoknak felelnek meg, amelyek valamilyen kérés kiszolgálására várnak (ezek lennének a kiszolgálók). Állományátvitel esetén például egy "ftp" nevû programot indítunk el, amely a kapcsolat felépítéséhez a saját oldalán véletlenszerûen kijelöl egy portot, mondjuk az 1234-t. A céloldalon viszont a 21-es portot jelöli meg, amely az FTP kiszolgáló hivatalos portjának felel meg. Vegyük észre, hogy itt két különbözõ programról van szó. Az egyik az "ftp", amelyet a küldõ oldalon indítottunk el, és amely a terminálról kapott parancsokat továbbítja a másik oldalhoz; a célállomáson lévõ gépen viszont az FTP kiszolgálóhoz beszélünk. Ezt arra találták ki, hogy a hálózatról parancsokat fogadjon, nem úgy mint egy interaktív terminál. Semmi szükség arra, hogy az "ftp" program jól ismert socket-et használjon. A kiszolgálókkal teljesen más az eset, hiszen a kapcsolatokban parancsokat kell tudniuk fogadni. A hivatalos portok és a hozzájuk rendelt számok az RFC 997-tõl kezdve az "Internet Numbers" (Internet Számok) RFC dokumentumban olvashatók (az írás pillanatában a legutóbbi az RFC 1162). Ez a dokumentum régebben az "Assigned Numbers" (Kiosztott Számok) nevet viselte.
A fentiek után nyilvánvaló, hogy egy kapcsolatot négy szám jellemez: a két Internet cím, és a két TCP port száma. Ez a négy szám minden egyes datagrammban megtalálható. (Az Internet címek az IP fejlécben, a TCP portok száma pedig a TCP fejlécben van.) Az egyediség megkövetelése miatt semelyik két kapcsolat esetén sem lehet ugyanaz mind a négy szám. Ugyanakkor elég, ha csak egy szám tér el a másik négytõl. Semmi nem tiltja például azt, hogy ugyanazon a gépen lévõ két különbözõ felhasználó állományokat vigyen át ugyanarra a távoli gépre. Ennek a megvalósítása például az alábbi paraméterekkel lehetséges:
Internet cím TCP port száma 1. kapcsolat 128.6.4.194, 128.6.4.7 1234, 21 2. kapcsolat 128.6.4.194, 128.6.4.7 1235, 21
Mivel ugyanazokról a gépekrõl van szó, az Internet címek ugyanazok. Továbbá, mivel mind a két kapcsolatban állományátvitelrõl van szó, ezért a kapcsolatok egyik végén az FTP port jól ismert száma (21) található. Az egyetlen dolog, ami különbözik: a felhasználók által futtatott programok portszáma. Ez tökéletesen elegendõ. A kapcsolatok felépítésében az az általános gyakorlat, hogy legalább az egyik oldal utasítja a hálózati szoftvert arra, hogy számára egyedi port-ot allokáljon. A legtöbb esetben ezt a felhasználó felõli oldal teszi meg, mivel a kiszolgálónak egy mindenki által jól ismert számot kell használnia.
Most, hogy már tudjuk hogyan kell kapcsolatot felépíteni, menjünk vissza az alkalmazói programokhoz. Ahogy már fentebb említettük: miután a TCP megnyitott egy kapcsolatot, rendelkezésünkre áll egy vonal, ami akár egy egyszerû drót is lehetne. A feladat rázós részeit a TCP és az IP kezelik. Ez persze még nem elég, ugyanis tudnunk kell, hogy mit küldhetünk át a vonalon. Valójában ez nem más mint a küldhetõ parancsok és azok formátumának leírása. Az átküldött rész lényegében adatok és parancsok egyvelege, amiket a szövegkörnyezet különböztet meg egymástól. Például a levelezést megvalósító protokoll mûködése az alábbi: a felhasználói oldal levelezõ programja kapcsolatot épít fel a célállomás levelezést kiszolgáló programjával. A küldõ program megadja a forrásgép nevét, a küldõ címét és a címzetteket. Ezek után egy parancsot küld, amelyben arról tájékoztat, hogy az üzenet szövege következik. Ettõl a ponttól a kiszolgáló az adatokat nem parancsokként, hanem üzenetként értelmezi mindaddig, amíg egy speciális, az üzenet végét jelentõ jellel (egy egyedül álló pont a sor elején) nem találkozik. Ez után a két oldal ismét parancsokkal kommunikál. Ez a legegyszerûbb módja az üzenetek küldésének, és a legtöbb alkalmazás így is mûködik.
Az állományok átvitele ennél valamivel bonyolultabb. Átvitel esetén két különbözõ kapcsolat épül fel. Az elején minden úgy megy mint a levelezéskor. A felhasználó programja olyan parancsokat küld, mint "jelentkeztess be ilyen és ilyen felhasználóként", "ez a jelszóm", "küldd el ezt és ezt az állományt". Miután az adatkérésre a parancs elment, a tényleges adatok átvitelére egy második kapcsolat épül fel. Persze ezt meg lehetne oldani ugyanazon az egy kapcsolaton keresztül is, ahogy a levelezés teszi. Az ok, amiért ez mégsem így történik, abban rejlik, hogy az állományátvitel általában hosszú ideig tarthat. A tervezéskor úgy érezték, hogy jobb a felhasználónak meghagyni a menet közbeni parancskiadás lehetõségét (például megszakításhoz stb... Lehetséges az is, hogy két különbözõ géphez nyissunk meg kapcsolatot, és egy állományt az egyiktõl a másikhoz küldjünk. Ebben az esetben az adatok nem keveredhetnek a parancsokkal.)
A távoli terminálhívások egy harmadik módszert használnak. A távoli bejelentkezéskor csupán egy kapcsolat épül fel. Normális esetben ezen csak adatok mennek keresztül. Amennyiben parancsot akarunk kiadni (pl. a terminál típusának a beállítására, vagy valamilyen üzemmód átállítására), akkor egy speciális karaktert kell küldeni, amely jelzi, hogy a következõ karakter parancs. Ha ezt a speciális karaktert adatként akarjuk küldeni, akkor kettõt kell egymás után kiadni.
Ebben az ismertetõben az alkalmazási protokollokról részletesen nem szólunk. Ehelyett javasolható a megfelelõ RFC dokumentumok tanulmányozása. Az alkalmazások viszont egy sor olyan konvención alapulnak, amelyeket érdemes részletesen érinteni. Az elsõ ilyen a közös hálózati reprezentáció: a TCP/IP-t úgy tervezték, hogy minden számítógépen alkalmazható legyen. Sajnos nem minden számítógép tárolja ugyanúgy az adatokat. A karakterek (ASCII vs. EBCDIC), a sorvég-jelek kódolásában (kocsi-vissza, soremelés), és abban, hogy a terminálok a karaktereket egyenként vagy soronként küldjék, mind különbségek mutatkoznak. A különbözõképpen mûködõ számítógépek kommunikációjának elõsegítése miatt minden egyes alkalmazói protokoll szabványos reprezentációkat definiál. A TCP és az IP azonban nem törõdik a reprezentációval: a TCP egyszerûen csak okteteket küld. Az oktetek értelmezését persze mind a két oldalnak ugyanúgy kell végeznie. Az alkalmazásokat leíró RFC dokumentumok minden egyes esetben az adott alkalmazás szabványos reprezentációját definiálják. Ez a legtöbbször "tiszta ASCII" formátumnak felel meg: ASCII karakterek használata, sorvég-jelként kocsi-vissza utáni soremeléssel. A távoli bejelentkezés definiál egy "szabványos terminált" is, amely egy visszhangos, félduplex mûködésû terminál. A legtöbb alkalmazásban azonban arra is lehetõség van, hogy két számítógép számukra megfelelõbb reprezentációban állapodjon meg. Például a PDP-10 számítógépekben egy szó 36 bites. Két ilyen gép között lehetséges 36 bites bináris állományok átvitele. Hasonlóan, ha két rendszer inkább teljes duplex kommunikációt preferál, akkor megegyezhetnek annak használatában. Azonban mindezektõl függetlenül minden egyes alkalmazásnak van egy szabványos reprezentációja, amelyet minden gépnek támogatnia kell.
Az alkalmazói protokollok szerkezetének jobb átlátása végett álljon itt az SMTP (Simple Mail Transfer Protocol -- egyszerû levéltovábbítási protokoll), azaz a levelezést megvalósító protokoll egy példája. Tegyük fel, hogy a TOPAZ.RUTGERS.EDU nevû számítógép szeretné az alábbi üzenetet elküldeni.
Date: Sat, 27 Jun 87 13:26:31 EDT From: hedrick@topaz.rutgers.edu To: levy@red.rutgers.edu Subject: meeting Let's get together Monday at 1pm.
Az üzenet formátumát egy Internet szabvány (RFC 822) írja le. A szabványban megfogalmazódik, hogy az üzenetet ASCII karakterekként kell továbbítani. Az üzenet szerkezetének az alábbiak szerint kell kinéznie: fejléc sorok, aztán egy üres sor, majd az üzenet szövege következik. Végül a fejléc sorok szintaxisát definiálja részletesen: általában egy kulcsszó, majd egy érték.
A fenti üzenet címzettje LEVY@RED.RUTGERS.EDU. Kezdetben ez úgy nézett ki, hogy csak a címzett nevét és a gépet írták bele: "személy és gép". A szabványok fejlõdése azonban ezt sokkal rugalmasabbá tette. Ma már más rendszerek üzeneteinek a kezelésére is vannak elõírások (ami persze "magától értetõdõ"). Ezzel lehetõvé válik az Internetbe be nem kapcsolt gépek miatti automatikus átirányítás (forwarding): például az üzenetek egy sor rendszer számára egy központi (mail server) géphez kerülnek. Egyáltalán nem szükséges tehát, hogy létezzen a RED.RUTGERS.EDU névvel jelölt számítógép. A névkiszolgálókat úgy is be lehet állítani, hogy az üzenetek címzettet jelentõ mezõjébe tanszékeket írunk, és minden egyes tanszék üzeneteit egy megfelelõ számítógéphez irányítjuk. Az is lehetséges, hogy a @ jel elõtti részbe ne egy felhasználónak a nevét írjuk, hanem valami mást. Egyes programokat fel lehet készíteni az üzenetek feldolgozására. A levelezési listák, illetve az olyan általános nevek, mint "postmaster" vagy "operator" kezelésére is felkészült a rendszer.
Az üzenet küldésének módját az RFC 821 és 974 dokumentumok tárgyalják. A küldést végzõ program párszor lekérdezi a névkiszolgálót, hogy meghatározza a célállomást. Az elsõ lekérdezés alkalmával arról tájékozódik, hogy mely gépek kezelik a RED.RUTGERS.EDU gépnek szóló leveleket. Ebben az esetben a kiszolgáló válasza, hogy a RED.RUTGERS.EDU saját maga kezeli az üzeneteit. Ez után a program a RED.RUTGERS.EDU címét kéri le, ami 128.6.4.2. Ezek után a levelezõ program egy TCP kapcsolatot nyit meg a 128.6.4.2 gép 25-ös portjára. A 25-ös port a leveleket fogadó foglalatnak felel meg. Miután a kapcsolat létrejött, a levelezõ program megkezdi a parancsok küldését. Az alábbiakban álljon itt egy tipikus kommunikáció. A sorok elõtt az szerepel, hogy az a TOPAZ vagy a RED nevû géptõl származik-e. A példában TOPAZ kezdeményezte a kapcsolatot:
RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT TOPAZ HELO topaz.rutgers.edu RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU TOPAZ MAIL From: <hedrick@topaz.rutgers.edu> RED 250 MAIL accepted TOPAZ RCPT To: <levy.red.rutgers.edu> RED 250 Recipient accepted TOPAZ DATA RED 354 Start mail input; end with <CRLF>.<CRLF> TOPAZ Date: Sat, 27 Jun 87 13:26:31 EDT TOPAZ From: hedrick@topaz.rutgers.edu TOPAZ To: levy@red.rutgers.edu TOPAZ Subject: meeting TOPAZ TOPAZ Let's get together Monday at 1pm. TOPAZ . RED 250 OK TOPAZ QUIT RED 221 RED.RUTGERS.EDU Service closing transmission channel
A parancsokban mindenütt normál szöveg szerepel: ez az Internet szabványokra tipikusan jellemzõ. A protokollok többsége szabványos ASCII parancsokat használ, ami arra is jó, hogy követhessük éppen mi történik, és a problémákat diagnosztizálni lehessen. A levelezõ program például minden ilyen beszélgetést egy állományban naplóz. Ha valami nem a megfelelõ módon történik, akkor az állományt elküldhetjük a postmaster-nak. Mivel ez ASCII fomátumú, ezért látni, hogy mi történt. A dolog arra is jó, hogy közvetlenül a levelezést kiszolgáló géppel lépjünk kapcsolatba tesztelés céljából. (Néhány újabb protokoll annyira összetett, hogy ez nem praktikus. A parancsoknak olyan szintaxis felelne meg, amely szintaktikus elemzõt igényelne. Ez azt jelenti, hogy az újabb protokoll esetében a tendencia a bináris formátumok felé mutat. Általában olyan struktúrákról van szó, mint a C vagy a Pascal nyelvek rekordja.) Második észrevételként említjük, hogy a válaszok mindegyike számmal kezdõdik: ez is az Internet protokollok jellemzõ vonása. A megengedett válaszokat a protokollok definiálják. A számok segítségével a felhasználói programok egyértelmûen kommunikálhatnak. A válaszok maradék része szöveg, ami a könnyebb olvashatóság miatt szerepel, és nincs semmiféle kihatása a programok mûködésére. (Habár van egy pont, ahol a protokoll a válasz szövegének egy részét is felhasználja.) Maguk a parancsok arra használatosak, hogy a levelezõ program a kiszolgálóval közölje azokat az információkat, amelyek az üzenet továbbítása miatt szükségesek. A fenti kiszolgáló az információt az üzenetbõl is kiolvashatja. Bonyolultabb esetekben azonban ez nem lenne biztonságos. Minden kommunikáció a HELO paranccsal kezdõdik, amit a kapcsolatot kezdeményezõ rendszer nevének kell követnie. Ezek után kovetkezik a küldõ és a címzett meghatározása. (Lehet több RCPT parancsot is kiadni, ha több címzett van.) Végül maga az üzenet jön. A szöveget olyan sorral fejezzük be, amiben csak egy pont szerepel. (Ha a szövegben is szerepel ilyen sor, akkor a pont megduplázódik.) Miután az üzenet fogadása megörtént, a küldõ másik üzenetet küldhet, vagy befejezheti a kommunikációt, mint ahogy a fenti példában is történt.
A válaszokat jelölõ számokat egy minta szerint képezzük. A protokoll definiálja azokat a válaszokat, amelyek egy adott parancsra adhatóak. Amennyiben nem érdekes a válaszok részletes elemzése, akkor elég csak az elsõ számjegyet figyelembe venni. A 2-vel kezdõdõ válaszok sikeres parancsot jelölnek. A 3-mal kezdõdõek esetén további parancsokat vár a kiszolgáló (ld. fent is). A 4 ideiglenes hibát jelez (pl. lemezterület megtelt). Az üzenetet ilyenkor el kell menteni, és késõbb újra kell próbálkozni. Az 5 állandó jellegû hibára utal, például nem létezik a címzett. Az üzenetet egy hibaüzenet kíséretében vissza kell küldeni a feladónak.
(A fejezetben említett protokollokkal kapcsolatban további információt szolgáltat az RFC 821/822 a levelezésrõl, az RFC 959 az állományátvitelrõl, és az RFC 854/855 a távoli bejelentkezésrõl.)