| Tik-110.300 Tietoliikennearkkitehtuurit | Teemu Ikonen |
| Harjoitus 10. Essee | 44023A |
| Tik N |
30. Lokakuuta 1999
Teemu Ikonen
Ti N
Teknillinen korkeakoulu
Teemu.Ikonen@iki.fi
Kukaan ei aloita tietoliikenneohjelmointia täysin puhtaalta pöydältä, alla on aina jotain tietoa ohjelmointikielen rakenteesta, sen tiedon esittämistavoista ja kontrollirakenteista. Huolimatta tästä tiedosta, on tietoliikenneohjelmoinnissa paljon juuri omaan alaansa sidonnaista jota ei tarvitse ottaa huomioon muunlaisessa ohjelmoinnissa. Tietoliikenne voi mm. olla synkronista tai ansynkronista, siinä voi esiintyä virheitä tai tieto voi olla saatavissa vain pieninä palasina vähän kerrallaan. Monet kokeneetkin ohjelmoijat ovat itse asiassa olleet hyvin vähän tekemisissä TCP/IP-Rajapinnan kanssa ja protokollien suunnittelussa.Tämä essee käsittelee tyypillisiä tilanteita internet-ohjelmoinnissa käytetyimmillä UNIX, Windows 32 ja Java-alustoilla. Internetohjemoinnissa yleisin käytetty siirtokerroksen protokolla on TCP/UDP, joka on tässä esseessä verkkoohjelmointiin käytetty työkalu. Aihepiiriin kuuluvat myös ohjelmointiesimerkit ja pohdintaa sekä näkökantoja ohjelmistojen ja protokollien suunnittelusta ja implementaatiosta.
Tämän hetken suosituin tietoliikenneohjelmiston arkkitehtuuri on ns. asiakas-palvelin arkkitehtuuri. Tämä tarkoittaa useimmiten toimintojen ja käyttöliittymän jakamista kahteen eri osaan. Palvelin osalla on se informaatio jota asiakas tarvitsee, eli suhde on monen suhde yhteen. Monta asiakasta ja yksi palvelin. [6] Samalla termillä voidaan myös tarkoittaa palvelujen keskittämistä yhteen paikkaan. Hyvänä esimerkkinä edellisestä jälkimmäisestä on WWW-sivusto.Monet suurimmista järjestelmisä on toteuttu asiakas-palvelin arkkitehtuurilla, joita käytetään tällä hetkellä pääasiassa kahta eri muotoa. 2-taso ja 3-taso mallit. 2-tasoinen malli on aito perinteinen asiakas-palvelin arkkitehtuuri jossa on yksi palvelin ja monta asiakassovellusta. Jokainen asiakassovellus ottaa yhteyttä tähän palvelimeen ja palvelin vastaa vuorollaan jokaiseen pyyntöön. [6] FTP-tiedostopalvelin on tyypillinen kaksitasoinen palvelin. 3-tasomallin mukaiset arkkitehtuurit ovat myös perusteiltaan asiakas-palvelin arkkitehtuureita mutta sillä erotuksella, että niissä on 'middleware' tai tapahtumamonitori joka huolehtii tapahtumien synkronoinnista ja resurssien jaosta. Tälläistä järjestelmää ei ole laajassa mielessä käytössä internetissä mutta paikallissa yritysten tietojärjestelmissä se on paljonkin käytetty.
Internet on perusluonteeltaan vapaa, eli suomeksi sanottuna turvaton. Verkkoon ei voi lähettää yhtäkään tavua samalla olettamatta että se on samalla vapaasti kaikkien saatavilla. Puuttuvan Internetin tietoturvan vuoksi on ulkoisissa yhteyksissä tietoturva enemmän kuin tarpeellinen työkalu hyödyllisen tietoliikenneohjelmiston rakentamisessa [5]. Turvallinen yhteys voidaan saada aikaan vain kryptaamalla liikenne siten, että sitä on mahdoton kolmannen osapuolen murtaa käyttämällä resursseja jotka olisivat järkevässä taloudellisessa suhteessa tiedosta saatavaan hyötyyn. Tämä tarkoittaa sitä, että tiedon ollessa tärkeää se on suojattava hyvin ja sen ollessa vähemmän tärkeää, esim. merkityksellistä vain lähettäjälle ja vastaanottajalle, se voidaan ehkä jättää suojaamatta. Samoin tilanne on jos ohjelmistoa tullaan käyttämään vain ja ainoastaan suljetussa LAN-verkossa tai muuten liisattujen yhteyksien yli. Tällöin täytyy kuitenkin muistaa ohjelmistoihin kohdistuva jatkuva muutospaine, jonain päivänä asiakas voi vaatia www-liittymää jolloin ohjelmisto tarvitsee hyvän tietoturvamallin ja kryptatut yhteydet.Tietoturva ja käyttäjäystävällisyys eivät kulje käsikädessä. Salasanat yms. turvatoimet hankaloittavat usein sujuvaa työskentelyä, mutta toisaalta ne mahdollistavat mm. pankkitoiminnan ja internet-kaupan nykyisessä laajuudeessaan. Tietoturvaa ei koskaan voi saavuttaa pelkästään teknisillä toimenpiteillä, vaan tietoturvan ydin on aina tietoturvapolitiikka mitä käytetään, paraskaan järjestelmä ei auta jos joku on jättänyt salasanansa post-it lappuun koneen kylkeen. Tälläinen piittaamattomus on valitettavan yleistä.
Nykypäivänä käytetyimmät tietoturvan välineet Internetissä ovat RSA, SSL ja SSH. SSL-Protokolla perustuu kolmannen osapuolen autentikointiin jolla voidaan näin varmistaa ettei kukaan pysty kuuntelemaan lähetystä tai matkimaan toista osapuolta [4]. SSH-protokolla perustuu julkiseen ja salaiseen avaimeen jolla koneet varmistuvat toistensa identiteetistä [8]. SSL-protokollasta on saatavilla ilmainen versio SSLeay joka on tarpeeksi hyvä useimpiin sovellusalueisiin. Samoin SSH on vapaasti levitettävä ei-kaupalliseen käyttöön. RSA mahdollistaa suojattujen yhteyksien rakentamisen turvattomia kanavia pitkin. IPv6 lupaa suuria parannuksia tietoturvaan, mutta sen tarjoamat palvelut eivät liity suoraan tietoliikenneohjelmointiin.
Protokolla on tapa jolla kaksi tai useampi verkkoa käyttävä ohjelma välittävää informaatiota. Protokolla kuvaa tiedon esittämistavan ja mallin jolla tietoa välitetään. HTTP-protokolla kuvaa WWW-sivun ja siihen liittyvien lisäosien, kuten kuvien, siirtoa WWW-palvelimesta selaimeen. Se kertoo komennot jotka asiakassovelluksen täytyy kirjoittaa palvelimelle ja miten tietoa otetaan vastaan. Protokolla tarvitaan myös varmistamaan että data joka verkossa liikkuu menee turvallisesti perille, TCP-yhteys on melko varma, mutta silti ei voida ikinä olettaa että lähetetyt tavut todella ovat menneet perille. Tavut ovat tietysti voineet mennä perille, mutta mikään ei takaa sitä, että asiakkaan pyyntö oli onnistunut. Tälläisessä tapauksessa tarvitaan aina jonkinlainen menetelmä varmistamaan tiedonsiirron tai tapahtuman onnistuminen. Tyypillisessä protokollassa asiakassovellus odottaa palvelimelta kuittausta että tieto on käsitelty. Tässä oletetaan käytettäväksi varmistettuja protokollia joissa siis käytetään kuittausta. Tämä siksi että ne ovat kaikken yleisimmin käytettyjä protokollia.Protokollat voidaan jakaa ohjelmoinnissa karkeasti kahteen osaan, yleiset ja erityiset. Yleiset protokollat välittävät tietoja siten, että ne eivät ota kantaa tietoon tai tiedon rakenteeseen. Esimerkkinä tälläisestä voisi olla segmenttiprotokolla jossa segmentti on annettu vapaamuotoisena kuvauksena.
Segmentti on merkkijono jonka kentät on eroteltu tavulla ':'. Jokaisella segmentillä on ainakin kaksi kenttää josta ensimmäinen kertoo segmentin nimen ja toinen kenttien lukumäärän. Viesti koostu yhdestä CONTROL-tyypin segmentistä ja mielivaltaisesta määrästä segmenttejä. Viesti loppuu merkkijonoon '\r\n'.Viesti voi siis näyttää seuraavalta.CONTROL:5:FILEMSG:23:34:11:tikonen:FILE:4:R:512:\r\nEDI on esimerkkinä tämäntyyppisestä protokollasta. Prokollan vahva puoli on sen luettavuus, joka ei ole todellakaan pieni etu ajatellessa virheenetsintää. Samoin tietoa voidaan esittää mielivaltaisen pituisilla kentillä ja mikään ei ole oikeastaan kiinteää koko protokollassa. Tälläinen protokolla on helppo muuntaa ottamaan vastaan erilaisia viestejä ja se kestää hyvin muutospaineita. Protokollan ongelma on sen vaatima laskentateho, sillä esimerkiksi ':'-merkin lähettäminen vaatii koko viestin escape-koodaamista. Ongelmia tulee myös teknisestä toteutuksesta, kuinka paljon tavuja pitää lukea jos kerran ei voida tietää kuinka paljon tietoa tulee? Entä jos puskuriin saadaan seuraavan viestin alkuosa?Erityinen protokolla on vahvasti sidottu tiedon rakenteeseen, sitä voidaan käyttää esimerkiksi ohjelmointirajapinnassa jossa tekniset syyt pakottavat verkotettuun ratkaisuun. Tyypillisesti tälläisen protokollan näkee Ad-Hoc tyylillä tehdyssä ratkaisussa jossa ongelma on vain haluttu nopeasti alta pois. Tyypillisesti protokollan välittämä data on määritelty ohjelmointikielen rakenteella.
Tälläisen protokollan ongelma on se, ettei se esimerkiksi ole kannettava eri arkkitehtuureiden välillä, 32-bittinen 'int' ei ole samanlainen kaikissa koneissa jo pelkän tavu-järjestyksen takia. Protokollan hyvä puoli on sen helppo implementointi, kaikki tietävät kuinka paljon dataa odottaa ja se on suoran osoituksen takia hyvin nopea.typedef struct { int magic; int requestno; int opno; char fileno[512]; char buffer[1024]; } FILEMSG;
Ongelma joka protokolliin kohdistuu on muutospaine. Ohjelmien muuttuessa muuttuu usein tiedon laatu ja määrä jota verkossa kuljetetaan. Usein muutos on kuitenkin kasvavaa, joten vanhojen versioiden toimivuus voidaan varmistaa toteuttamalla protokolla versiointia tukevaksi. Ongelmana on kuitenkin se, miten versiointi on paras suorittaa. Monesti tietoa voidaan joutua tuplaamaan, kun siitä pitää lähettää sekä vanhan ohjelman että uuden version haluamassa muodossa.
Tällä hetkellä alalta löytyy kaksi käytettyä rajapintaa eli API:a, Berkeley Sockets- ja WinSocket-rajapinnat [1]. Toisen ollessa UNIX- ja toisen Microsoft Windows-ympäristön rajapinta. Java, joka on laitteistoriippumaton [10], käyttää kummassakin ympäristössä näitä rajapintoja oman rajapintansa implementointiin. Visual basic tarjoaa myös oman ohjelmointirajapinnan verkkoon [2], mutta se ei ole kovinkaan yleinen. On myös huomioitavaa että Windows 98:sta lähtien windows tarjoaa käytännössä täydellisen Berkeley Sockets rajapinnan [9], tämän vuoksi windows-esimerkkejä ei kannata mainita erikseen.Sockets rajapinta on mahdollisimman yksinkertainen liittymä TCP/UDP-siirtoprotokolliin. Idea näissä on luoda yhteys (socket) ja kirjoittaa tavut puskurista tähän yhteyteen sekä lukea vastaus. Kun siirto on valmis, voivat ohjelmat sulkea tämän yhteyden. TCP/UDP-protokollan yhteysosoite on koneen ip-osoite ja TCP-portti tässä osoitteessa. Näin useat ohjelmat voivat jakaa saman yhteyden ilman että tarvitaan lisää fyysisiä linjoja.
Postitusohjelma on yleisin internetissä käytetty ohjelma. Sen protokolla on tehty käytettäväksi telnet-ohjelman avulla käyttäen suoraa käyttöliittymää palvelimen kanssa. Tämän vuoksi ohjelmalliset sovellutukset joutuvat toimimaan hieman erikoisemmin. Yksinkertainen SMTP asiakassovellus C-kielellä ja Berkeley Socket-rajapinnalla toteutettuna on seuraavanlainen
Käytetyistä funktioista on olemassa erittäin hyvä erillinen dokumentaatio, mutta tässä on hyvä huomioida bittijärjestyksen aiheuttama ongelma. Eri arkkitehtuurit käyttävät erilaista 32 bittisen kokonaisluvun esitystapaa, joten htons()-kutsu ja sen sukulaiset tarvitaan kääntämään tieto verkon ja tietokoneen arkkitehtuurin välillä [3].#include <sys/types.h> #include <sys/socket.h> #include <getdb.h> #include <unistd.h> void main() { int s; const struct hostent *h; struct sock_addr sin; /* luo TCP-socket */ s = socket( PF_INET, SOCK_STREAM, PF_INET ); /* Kysy DNS:ltä kohdekoneen numeerinen osoite */ h = gethostbyname( "vipunen.hut.fi"); /* Muuta osoite connect()-kutsun ymmärtämään muotoon*/ memset( &sin, 0, sizeof(sin)); memcpy( &sin.sin_addr, h->h_addr, h->h_length ); sin.sin_family = h->h_addrtype; /* SMTP majailee TCP-portissa 25 */ sin.sin_port = htons(25); /* Luo yhteys kohdeosoitteeseen*/ connect( s, (struct sockaddr *)(&sin), sizeof(sin)); /* Suorita transaktio SMTP-palvelimen kanssa*/ write( "HELO myhost.fi\r\n",16); write( "MAIL FROM: tikonen\r\n", 20 ); write( "RCPT TO: tlark@tcm.hut.fi\r\n",28); write( "DATA\r\n", 6 ); write( "Subject: palautus\nSarja 10\n44023A\n1. http://www.hut.fi/~tikonen/tik-110.300/essee.html\r\n.\r\n", 60 ); write( "QUIT\r\n", 6 ); /* Transaktio on suoritettu, sulje yhteys */ close( s ); /* Nyt posti on lähetetty, joten ohjelma voi lopettaa */ exit(0); }Edelläkuvattua protokolla käyttävä palvelin olisi huomattavasi vaikeampaa implementoida, koska mitään tietoa datan koosta ei ole, ohjelman täytyy siis parseroida lukemansa teksti.
Palvelinsovellusesimerkkinä käytetään nyt ohjelmaa joka käyttää yksinkertaista protokollaa kirjoittamaan ruudulle tekstiä. Palvelimeen otetaan yhteyksiä, jonka jälkeen se olettaa että 4 ensimmäista tavua ilmaisee tulevan data määrän poislukien nämä neljä tavua.
Ohjelmaesimerkeissä ei ole minkäänlaista virheenhallintaa, mikä on oikeassa ohjelmistossa anteeksiantamaton virhe. Käytännössä jokainen kutsu tulisi tarkistaa ja ryhtyä toimenpiteisiin jos syytä ilmenee. Socket ohjelmoinnissa on syytä muistaa seuraavat asiat joita ei usein tulla ajatelleeksi ensimmäisiä ohjelmistoja tehtäessä#include <sys/types.h> #include <sys/socket.h> #include <getdb.h> #include <unistd.h> void main() { int ss, cs; struct sockaddr_in sa; struct sockaddr_in from; int ialen, dlen; char buffer[1024]; /* luo TCP-socket */ ss = socket( PF_INET, SOCK_STREAM, PF_INET ); /* Rakenna osoite bind()-kutsun ymmärtämään muotoon*/ memset( &sa, 0, sizeof(sa)); /* Kuunnellaan TCP-porttia 2000 */ sa.sin_port = htons(25); sa.sin_family = AF_INET; sa.sin_addr.s_addr = htonl( INADDR_ANY ); /* Yhdistä socket haluttuun TCP-porttiin*/ bind( ss, (struct sockaddr *)&sa, sizeof(sa)); listen( ss, 50 ); /* Odota yhteyspyyntöjä */ while( 1 ) { ialen = sizeof(from); /* Odota yhteyttä */ cs = accept( ss, (struct sockaddr *)&from, &ialen ); /* Selvitä luettavan datan pituus */ read( cs, &dlen, 4 ); /* lue data */ read( cs, buffer, dlen ); /* kirjoita data ruudulle */ buffer[dlen] = '\0'; printf( "%s\n", buffer ); /* Transaktio on suoritettu, sulje yhteys ja ala odottamaan uutta yhteyttä*/ close( cs ); } }Ohjelmistorajapinta on melko yksinkertainen, eikä esimerkeissä ole kovinkaan paljon lisättävää. Käyttämällä mahdollisimman yksinkertaista rajapintaa saadaan ohjelma siirrettävämmäksi eri ympäristöjen välillä.
- read/write kutsut voivat kirjoittaa ja lukea vähemmän tavuja kuin oli ohjelmoijan tarkistus. Funktioiden paluuarvot täytyy aina tarkistaa.
- Monet kutsut voivat palauttaa -1 virheen merkiksi vaikka mitään virhettä ei olisikaan. Tämä tilanne saadaan esim. silloin kun ulkopuolinen keskeytys on keskeyttänyt verkkotoimenpiteen.
- bind() kutsu voi varata portin pitkäksikin aikaa, tällöin esim. palvelimen uudellenkäynnistys voi päättyä virheeseen vaikka portilla ei mitään kuuntelijaa olekaan. Tällöin on syytä lisätä ohjelmaan setsocketotp kutsu SO_REUSEADDR-lipulla
- Monet funktiokutsut voivat jäädä 'jumiin' pitkäksi aikaa, jopa minuuteiksi. Mitään reaaliaikaisuutta verkoilla ei voi toteuttaa.
- Byte-Order Jokaisella eri arkkitehtuurilla on erilainen tapa esittää kokonaislukuja, eli niiden bittien järjestys on erilainen. Tämän vuoksi ei voida suoraan lähettää esim. kokonaislukua toiselle koneelle vaan sitä on käsiteltävä hton ja ntoh-makroilla.
Ohjelmiston tärkein mittari on toimivuus, se että se tekee sen mitä määrittelyssä sanotaan. Seuraavana mittarina on ylläpidettävyys. Ohjelmistot ovat jatkuvan muutospaineen alla, eivätkä ne ole koskaan valmiita. Jos oletetaan että ohjelmisto on rakennettu huolellisesti tukemaan muutoksia, jää vielä yksi ongelma. Verkko-ohjelmoinnissa on luonnollinen seuraus se, että ohjelmistolla on ulkoisia yhteyksiä. Tällöin yhteen osa-ohjelmistoon tehdyt muutokset vaikuttavat usein protokollaan jolla järjestelmä toimii, tämä taas vaatii sen että em. kaltaisissa muutostilanteissa joudutaan kaikki vanhat versiot päivittämään. Täydellinen yhtäaikainen päivitys voi olla liian suuri, ellei jopa mahdoton työ suuressa hajautetussa verkossa. On siis tärkeää huomioida muutospaine protokollaa suunniteltaessa, tai sitten suunnitella ohjelmat niin etteivät ne suostu koskaan toimimaan jos protokolla ei ole niille mieleinen, tällöin käyttäjät pakotetaan päivitykseen. Teknisesti vaativin ratkaisu on protokollan kuvauskannan käyttämistä, jossa protokollan kuvaus haetaan jostain ennen tietoliikenteen aloittamista.Windows 98:sta lähtien windows sockets rajapinta on ollut yhteensopiva berkely sockets rajapinnan kanssa joka on parantanut huomattavasti ohjelmistojen siirrettävyyttä UNIX-alustalta Windows-ympäristöön.
Tietoliikenteessä tapahtuu virheitä. Alla olevat kerrokset useimmiten korjaavat pahimmat virheet uudelleenlähetyksiä käyttäen, mutta joskus virheet näkyvät ohjelmoijalle asti yhteyden katkeamisena tai datavuon loppumisena. Virheiden korjaus siirtokerroksessa aiheuttaa joskus pitkiäkin viiveitä joita ei mielellään saisi näyttää loppukäyttäjälle jonka tulkinta on usein, että ohjelma on 'jumiutunut'.Nykyisillä rajapinnoilla saadaan virheet helposti kiinni, joten käytännössä ei ole mahdollista saada virheellistä bittijonoa tietoliikenneyhteydestä, tälläisen tilanteen mahdolisuus on häviävän pieni [11].
Koska nykyiset verkot ja varsinkin TCP-protokolla ovat hyvin varmoja työkaluja ohjelmoijalle, jää ohjelmoijan huoleksi ohjelmien kaatumisilta suojautuminen. Tällöin protokollassa on syytä olla jonkinlainen kuittaustoiminto jolla asiakassovellus tietää menikö tieto perille, jos ei mennyt, voi ohjelma lähettää sen myöhemmin uudelleen. Tälläisen ohjelmiston voi toteuttaa ns. mail-box rakenteella jossa lähetettävät tiedot kirjoitetaan ensin levylle ja poistetaan sitten kun ne ovat varmasti siirretty vastaanottajalle.
Eräs kosmeettinen aspekti tietoliikenneohjelmoinnissa on verkkoviiveiden piilottaminen. Useimmiten käyttöliittymissä käyttäjää ei saa odottuttaa muutamia sekunteja pidemmäksi aikaa. Toisaalta taas verkkoviiveet suurien tiedostojen siirroissa voivat olla minuuttien tai tuntien luokkaa, tällöin käyttälle on tarjottava jokin merkki siitä että ohjelmisto toimii. Esimerkkinä voi mainita Netscape- tai IExplorer-selaimen pienen nurkka- ja statusikkunan jotka kertovat missä vaiheessa operaatio on menossa. Nämä ohjelmat pyrkivät myös hyödyntämään luettua dataa näyttämällä sen mahdollisimman aikaisin ruudulla.
Tietoliikenneohjelmointi ei ole helppoa ja se vaikeutuu järjestelmien monimutkaistuessa. Nykypäivänä osa tarpeesta voidaan korvata käyttämällä olemassaolevia palveluita kuten WWW-liittymiä tai muita vastaavia helposti verkotettavia malleja, Vaikeimmat sovellukset on aina jouduttava tekemään melko alhaisella tasolla. Kriittisin linkki tietoliikenneohjelmiston toiminnassa on protokolla joka siis huolehtii käytännössä kaikesta työstä. TCP-protokolla ratkaisee suurimman osan teknistä alemman tason ongelmista [7], joten mm. ylläpidettävyys nousee protokollan tärkeimipien ominaisuuksien joukkoon.
[1] Davis Eric, UNIX Network programming [viitattu 18.9.1999]
<http://www.nas.nasa.gov/~edavis/unix_net_prog.html>
[2] devWire.com, Advanced Visual Basic [viitattu 18.9.1999]
[3] Gregg, Andrew , Berkeley Sockets Interface, 24.2.1997 [viitattu 30.10.1999]
<http://www.infc.ulst.ac.uk/~drew/ac425/week2.htm >
[4] Hickman, Kipp E.B. , The SSL Protocol, Netscape Communications Corp. [viitattu 18.9.1999]
<http://www.netscape.com/eng/security/SSL_2.html>
[5] Lazaar Aurel A., Programming telecommunications networks, International Workshop on Quality of Service, Columbia University, New York, NY, 21-23.5.1997 [viitattu 29.10.1999]
<http://www.xbind.com/pub4.html>
[6] Nattey Joseph O. , Client/Server Technology, Kent State University. [viitattu 18.9.1999]
<http://www.personal.kent.edu/~jnattey/natteypres.htm>
[7] Patterson Ross, What is TCP/IP, and Why Should I Care? , Sterling Software VM Software Division [viitattu 18.9.1999]
<http://ss1.reston.vmd.sterling.com/whtpaper/patters.html>
[8] SSH Communications security Ltd, SSH 2.0 Protocol Specifications. [viitattu 18.9.1999]
[9] StarDust Technologies, WinSock channel, [viitattu 18.9.1999]
<http://www.stardust.com/winsock/index.htm>
[10] Sun microsystems, JDK API 1.1.8 Documentation. [viitattu 18.9.1999]
<http://java.sun.com/products/jdk/1.1/docs/index.html>
[11] Tanenbaum Andrew S, Computer Networks, 3. Painos, Prentice-Hall International Inc. 1996, 813 s.
Aihetta sivuava luentosarja hajaututeista järjestelmistä
<http://www.comet.columbia.edu/distributed/lectures/.index.html>
C/C++ ohjelmointitietoa
<http://www.cprogramming.com/>
Yleistietoa aiheesta
<http://www.it.kth.se/edu/gru/Fingerinfo/telesys.finger/INW.VT96/Lectures/>
Microsoftin ohjelmistokehittäjien tukisivut
<http://msdn.microsoft.com/default.asp>
RFC-kokoelma
<http://www.garlic.com/~lynn/rfcietf.htm>
EDI - Yleinen kaupallisissa sovelluksissa käytetty tiedonsiirtoprotokolla
FTP - File Transfer Protocol. Tiedostojen siirtoon tehty protokolla. Erittäin suosittu mutta samalla vakava turvallisuusreikä.
HTTP - Hyper Text Transfer Protocol, WWW sivujen siirtoprotokolla
IPv6 - Interprotokollan seuraava versio
RSA - Julkisen avaimen salausmenetelmä.
SMTP - Simple Mail Transfer Protocol. Käytetyin Internet-palvelu, sähköpostin lähettäminen.
SSH - Secure shell. Korvaa salatulla turvallisella yhteydellä perinteisiä etäyhteyksiä, kuten telnet ja rlogin. Ohjelman variaatio scp on myös tekemässä ftp-ohjelmiston tarpeettomaksi.
SSL - Secure Socket Layer. Rakenne joka mahdollistaa salatun yhteyden kahden koneen välille julkisen verkon yli.
TCP - Transmit Control Protocol. Virtuaalisesti virheettömän end-to-end yhteyden tarjoava protokolla.
UDP - Unified Datagram Protocol. Pakettiprotokolla joka on TCP-yhteyteen verrattuna kevyt mutta epävarma.