Zowel server als client gebruiken het HTTP/1.1 protocol dat "keep alive" verbindingen ondersteunt. Bij dergelijke verbindingen wordt het transmissiekanaal (socket genaamd) open gehouden, zodat de overhead dat gepaard gaat met het opzetten van een virtuele verbinding vermeden wordt.

Een TCP verbinding kan voor een onbepaalde duur blijven bestaan en verbruikt geen bandbreedte als er geen data verstuurd wordt. De meeste verbindingen worden automatisch verbroken

• na het versturen van de data, bijvoorbeeld de data-verbinding van het fpt protocol (bestandsuitwisseling),
• na een korte tijd bijvoorbeeld http, dat wil zeggen het binnenhalen van webpagina (de verbinding blijft een korten tijd open voor het geval er een andere pagina of nog meer pagina-elementen binnengehaald moeten worden).
• De verbinding kan ook gewoon blijven bestaan, bijvoorbeeld een mailserver-verbinding (IMAP). De server kan automatisch een nieuw mailbericht door de open verbinding “pushen” als er een nieuw bericht toekomt. De client moet niet om de zoveel minuten een verbinding maken met de server en vragen of er nieuwe berichten toegekomen zijn (“poppen”)

Servers hebben constant een wachtroutine die blijft luisteren of er pakketten op de betreffende poort binnenkomen. De luisterpoorten zitten meestal vast: bij een webserver is dat poort 80. Clients starten enkel een wachtroutine op als er een verbinding aangelegd wordt (en er dus pakkets uitgewisseld zullen worden), en deze routine blijft bestaan zolang de verbinding bestaat.

In dit voorbeeld gebruiken wij dezelfde getallenvoorbeelden (zie "werking van een router").

De tekening geeft de vragen aan (stuur mij "index.htm" op, "logo.gif" en "foto.jpg"). In feite is de tekening niet 100% in orde, want de vraag voor logo.gif en foto.jpg komt eigenlijk te vroeg (de index-pagina moet namelijk voldoende ingelezen en verwerkt worden vooralleer de onderdelen van de pagina binnengehaald kunnen worden).

Doorgaans past de vraag ("stuur mij index.htm") in één enkele packet, maar voor complexe vragen (waarbij ook cookies uitgewisseld worden of waarbij een formulier ingevuld moet worden) zijn er meerdere pakketten nodig.

De server geeft voor ieder ontvangen pakket een bevestiging (ACK). Deze bevestigingspaketten zijn de kleinst mogelijke paketten (54 bytes). Als de server een pakket met een fout zou ontvangen, dan stuurt het een negatieve ontvangstbevestiging.
Zo werkt TCP nu eenmaal: voor iedere verbinding moet er een retourleiding voorzien worden. Door het retourkanaal worden de bevestigingen doorgestuurd.
De client weet met welke poort van de server een verbinding moet aangegaan worden (doorgaans is dat poort 80). De client krijgt zijn bevestigingen en nadien het antwoord via de retourleiding. Dit is altijd een poort boven de gereserveerde poorten (1024): een vrije poort wordt gebruikt voor het zenden van de vraag en nadien voor het ontvangen van het antwoord. Dit gebeurt volledig transparant voor de gebruiker: alles gebeurt achter de schermen.

Uitsturen van het antwoord
Client Eigen ip: 81.164.242.39 Luistert op poort: 5000	Server Eigen ip: 81.241.241.58 Stuurt uit op poort: 80

Het antwoord (index.htm, logo.gif, foto.jpg,...) kan meestal niet in één pakket verstuurd worden. Ieder antwoordpakket wordt individueel bevestigd (al was het mogelijk geweest een tiental bevestigingen in één pakket op te nemen). Zo werkt TCP nu eenmaal.

Bij HTTP wordt het antwoord via dezelfde weg gestuurd (bij FTP, het protocol voor bestandsoverdracht, wordt een apart data-kanaal opgezet naast het control-kanaal). De antwoord-paketten hebben hier meestal de maximaal toegelaten pakketgrootte (1500 bytes). Voor ieder ontvangen pakket geeft de client hier ook een bevestiging.

De bevestiging is zeer belangrijk bij het TCP protocol: het is een teken voor de server dat de verstuurde pakketten goed toegekomen zijn en dat hij die uit zijn buffer mag wissen. De bevestigingen worden ook gebruikt voor de sliding window, zodat er nooit teveel pakketten onderweg zouden zijn, wat tot overbelasting van het netwerk zou kunnen leiden.

Voor details over de elementen van de verbinding (TCP-laag, programma-laag, ...) moet je terecht op de pagina over het OSI-model. De applikatie (bovenste laag) ziet de verbinding als een perfekte virtuele verbinding. Het zijn de onderliggende lagen (transportlaag in het bijzonder) die voor een foutloze data-overdracht instaan. Maarw at er precies overgedragen wordt weten deze lagen niet.

De verbindingen zijn virtueel, want ze bestaan niet in het echt. Paketten worden gewoon het internet ingestuurd, en de routers onderweg moeten maar hun plan trekken. Omdat ieder pakket zijn eigen weg volgt gebeurt het zelfs dat de pakketten in de verkeerde volgorde toekomen (vergelijk het internet protocol (IP) bijvoorbeeld met ATM of met IPv6). Het TCP protocol moet ervoor zorgen dat de paketten in de juiste volgorde bij de applikatie afgeleverd worden en moet daarom de gegevens bufferen tot een stream dat aan de applikatie afgeleverd kan worden.

Een normale verbinding met het internet is asymmetrisch, want in het algemeen vraag je meer gegevens aan dan dat je gegevens uitstuurt. De "A" van ADSL (Asymmetric Digital Subscriber Line) staat voor asymetrisch. Bij Telenet is de asymmetrie nog groter, wat tot ongewenste effekten kan leiden. De asymmetrie kan niet weggewerkt worden zoals bij ADSL wel het geval is (SDSL en aanverwanten) omdat de kabel oorspronkelijk gemaakt werd voor dataverkeer in één enkele richting.

Default gateway

Vroeger (heel lang geleden...) was internet via satelliet de enige manier om een snelle internet-verbinding te bekomen als men enkel kon beschikken over een analoge modem (dat was voor de tijd van digitale telefoonlijnen).