Internetprotocols (deel 2)

Het internet werkt met tcp/ip en dat omvat twee netwerkprotocols die samenwerken: ip (internet protocol) en tcp (transmission control protocol). Dat vormt de basis voor alles, ook voor alle protocols die daar nog bovenop draaien.

Internetapplicaties babbelen met elkaar via een applicatieprotocol. Om te babbelen moet je met z’n tweeën zijn. Eentje is de client en de ander is de server of daemon (spreek uit: diemen). Voor onze discussie maakt het niet uit wie client en wie daemon is, maar in de praktijk zul jij als eindgebruiker vaak de clientzijde van een internetapplicatie vertegenwoordigen en zal de server op internet waarmee je contact zoekt de daemon draaien.

Tcp-poort
Elk applicatieprotocol heeft een tcp-poort (sommige protocols gebruiken meerdere poorten) nodig waarlangs alle communicatie draait. De meest gebruikte applicatieprotocols hebben een eigen standaardpoort, maar dat wil niet zeggen dat je verplicht bent die te gebruiken. Zo gebruikt http de standaardpoort 80, maar als jij een webserver met info over zwarte magie en duivelverering wil draaien op poort 666, dan kan dat. Je zit dan wel met het probleem dat een http-client of webbrowser alleen maar met die webserver kan werken als hij iedere keer opgeeft welke poort gebruikt moet worden. Werk je met de standaardpoort, dan hoeft dat niet en kan iedere webclient ermee werken zodra hij het adres kent.
Dit principe geldt voor alle internetapplicaties. Je mag, maar moet hun standaardpoort niet gebruiken. Omdat een tcp-poortnummer twee bytes omvat, kunnen er 65536 mogelijke poorten en evenveel applicaties zijn. De meeste poorten onder 1000 kregen standaardapplicaties toegewezen, maar daar hoef je je dus niet per se aan te houden als je dat niet wil. Andere mensen kunnen mogelijk wel niet met je systeem werken als je bepaalde standaardpoorten voor andere doeleinden gebruikt. Als je het alleen voor eigen gebruik doet, kun je natuurlijk doen wat je maar wil.
In het vorige artikel gaven we enkele voorbeelden van heel bekende poorten: 21 voor ftp, 23 voor telnet, 25 voor smtp, 53 voor domeinnaamvertalingen, 67 voor dhcp-servers, 68 voor dhcp-clients, 80 voor http en 110 voor pop3.

Client en server
Een gebruiker start een applicatieclient en zoekt contact met een applicatiedaemon. Die daemon kan op een andere pc aan de andere kant van de wereld draaien, maar dat hoeft niet. Het is best mogelijk om een client en daemon op dezelfde computer te draaien. Als je bijvoorbeeld dynamische websites ontwerpt, zul je gewoonlijk op je ontwerp-pc verschillende daemons draaien (zoals een webserver en een databaseserver) om het resultaat van je noeste arbeid gemakkelijk te kunnen bekijken met een applicatieclient zoals je webbrowser en desgewenst meteen weer veranderen. Als we een schema zouden moeten tekenen van de algemene werking van een applicatieclient en -daemon, zou er dat ongeveer als volgt uitzien:

Een gebruiker communiceert dus met zijn applicatieclient. Die client maakt ook gebruik van het bestandssysteem in het besturingssysteem van je pc om data op je harde schijf of elders te bewaren. De applicatieclient zoekt dan contact met de applicatiedaemon en wisselt authenticatie- en autorisatiegegevens uit, waarna bevelen en replieken daarop uitgewisseld worden. Die bevelen kunnen de uitwisseling van data tot gevolg hebben.
Het is overigens best mogelijk dat de uitwisseling van bevelen en replieken daarop (de zogenaamde administratieve uitwisseling) en de uitwisseling van data (of informatieve uitwisseling) over aparte tcp-poorten lopen, maar dat hoeft dus zeker niet. FTP, waarop we later nog terugkomen, is een voorbeeld van een protocol waar je de keuze hebt. (Gewone ftp met gescheiden uitwisselingen via meerdere poorten, of ‘passieve’ ftp met administratieve en informatie uitwisseling via dezelfde poort.)
De meeste protocols, zoals SMTP, POP3, HTTP en vele andere doen alle uitwisselingen via dezelfde poort. De administratieve uitwisseling bestaat overigens altijd uit gewone ASCII tekst. Dit wil zeggen: de client werkt met een aantal voorgedefinieerde kernwoorden om bevelen (al dan niet met bijbehorende parameters) aan de daemon te geven. De daemon zal een standaard repliek geven op elk bevel. Zo’n standaardrepliek begint gewoonlijk met een getalcode die de status van het antwoord aangeeft (informatie, waarschuwing, foutmelding, dat soort dingen) en de repliektekst die dan van belang is voor de gebruiker. De applicatieclientsoftware zal gewoonlijk de voor de gebruiker niet-relevante informatie (zoals statuscodes) verwijderen en alleen beknopte en/of samengevatte mededelingen naar de gebruiker sturen.

HTTP: HyperText Transfer Protocol
We beginnen met HTTP omdat dat, ondanks wat je misschien zou denken, een van de meest eenvoudige applicatieprotocollen is. Een HTTP-client (webbrower) begint altijd met het versturen van een ‘request’ (verzoek) naar de HTTP-daemon (webserver). Zo’n verzoek bestaat uit een methode (GET, POST, HEAD, …) gevolgd door een objectidentifactie (gewoonlijk een verwijzing naar een webpagina in het bestandssysteem van de server waarop de http-daemon draait). In essentie is dat alles. Gewoonlijk wordt zo’n verzoek nog aangevuld met een bende infomatie zoals met wat voor soort client je werkt en welke versie, je eigen systeemidentificatie (ip-adres of hostnaam) en nog veel meer. De webserver antwoordt met een statuscode en bijbehorende statustekst, gevolgd door het gevraagde object. De client ontvangt het object (de http-data) en moet die dan decoderen en weergeven. Meer is er eigenlijk niet aan. Laten we even kijken wat er precies gebeurt als je met een browser contact zoekt met een webserver. De browser is hier Mozilla v1.3 en de webserver is een Apache 1.3.2 en we vragen de indexpagina op.

GET /index.html HTTP/1.1

Dit is de tekstlijn die door de webbrowser naar de webserver gestuurd wordt. Mozilla stuurt in feite nog meer (zoals alle mogelijke inlichtingen over zichzelf en het systeem waarop hij draait), maar dit is het belangrijkste. Zoals je ziet is het een GET-verzoek van het object ‘/index.html’ volgens de HTTP-standaard 1.1. De Apache webserver reageert met:

200 1337

gevolgd door de inhoud van index.html. Die 餠’ is de statuscode voor ‘alles OK’ en daarachter krijg je het aantal te verwachten bytes: 1.337 inclusief CR/LF aan het eind en dat is dus wat meteen vanaf de volgende regel doorgestuurd wordt. In feite is dat dus heel erg simpel. Het meeste werk zit ‘m in wat de client en de daemon zelf beslissen uit te wisselen en het decodeerwerk van de client om de hypertext op je scherm te tonen in al zijn glorie. Bij het decoderen van index.html zal de client nieuwe links naar andere objecten aantreffen, waarna er nieuwe GET-opdrachten verstuurd zullen worden om die ook allemaal binnen te halen.