TCP/IPs referansemodell er ikke spesielt godt dokumentert i standardokumentene (RFCene), men [23] beskriver den kort. Den er også beskrevet i flere bøker, bl.a. [10]. Referansemodellen består av 5 lag:
På transportlaget brukes hovedsakelig Transmission Control Protocol (TCP) [24] og User Datagram Protocol (UDP) [21]. I internettlaget er Internet Protocol (IP) [23] den viktigste protokollen. I denne oppgaven er hovedvekten lagt på TCP og lavere nivås protokoller.
IP kjennetegnes ved at denne protokollen kan brukes over så godt som alle overføringskanaler, f.eks. brevduer [32]. En av designmålene bak TCP/IP var at det skulle være mulig å implementere protokollene på så mange arkitekturer som mulig [20]. Dette gjør at IP ogå kan kjøre over en eller flere serielle linker som GSM dataoverføring.
TCP gjør få forutsetninger om hvordan det underliggende nettverket håndterer datastrømmen. Pakker som sendes kan forsvinne, dupliseres, endres og komme frem i forskjellig rekkefølge uten at det bryter med designet.
Internettlaget overfører pakker fra en kilde til en mottager over et system av sammenkoblede nettverk. Dette laqget tilbyr ingen funksjonalitet for flytkontroll, pålitelig levering eller adressering av prosesser hos mottageren.
IP har en header![[*]](foot_motif.gif)
som normalt er på 20 bytes. I tillegg kan det
komme opsjoner, som ikke brukes under normal bruk. Hvis datagrammene
er større an det som maksimalt kan overføres i linklaget vil
datagrammet deles opp i flere segmenter som foverføres uavhengig av
hverandre. Normalt vil datagrammer på ca 1500 bytes overføres i de
fleste nett uten at de blir fragmentert.
Transportlaget gir adressering til en enkelt prosess på mottagermaskinen og kan også tilby flytkontroll, pålitelig levering o.l.
UDP er designet for å tilby en metode for pakkebasert transmisjon mellom to brukerprosesser. I UDP er det et minimum av overhead i tillegg til IP, headeren er på 8 bytes. UDP har mulighet for sjekksum på dataene som overfløres, men tilbyr ikke pålitelig overføring, flytkontroll e.l.
Dette prosjektet behandler ikke UDP videre.
TCP er en sliding-window protokoll for pålitelig overføring av datastrømmer mellom to brukerprosesser. Den er basis for de aller fleste tjenester i Internett i dag, bl.a. World Wide Web, e-post og FTP. Derfor legges hovedvekten av dette prosjektet på TCP-baserte tjeneser.
TCP er en forholdsvis avansert protokoll. Nedenfor beskrives noen av de viktigste mekanismene i protokollen. For en mer komplett beskrivelse vises det til lærebøker om TCP/IP, som f.eks. [10] og [29]. RFCene [24,8,25,18,30] inneholder også beskrivelser av de viktigste aspektene ved TCP.
De fleste implementasjoner av TCP vil samarbeide med internettlaget for å utnytte maksimal pakkestørrelse o.l. på best mulig måte [29]. Ved bulkoverføring av data vil det derfor, som oftest, kun overføres datagrammer av maksimal størrelse for å unngå fragmentering i nettet.
TCP bruker 3 pakker for å sette opp en forbindelse og 2 pakker for å avslutte forbindelsen. ACK for mottatte data kan sendes i samme pakke som andre data, og ACK for alle mottatte data sendes også med i alle pakker. For flytkontroll er tre teknikker definert i [30]:
Av disse teknikkene forutsetter både Slow Start og Congestion Avoidance at en meget liten del av pakkene som ikke kommer fram skyldes transmisjonsfeil, [30] sier at dette utgjør betydelig mindre enn 1% av samlet pakketap. For bruk over GSM transparente kanaler er det verdt å merke seg at dette er en forutsetning som ikke holder, da det kan bli en betydelig mengde bitfeil. TCP er derfor en lite egnet protokoll for overføring av data over slike kanaler.
Slow start er flytkontroll iverksatt av senderen av data. Over en ny forbindelse vil ikke TCP sende ut flere segmenter det ikke er mottatt ACK for enn antall segmenter det tidligere er mottatt ACK for. Antall segmenter som kan være sent ut uten ACK øker altså eksponensielt. Begrenset kapasitet i det mellomliggende nett vil ved metning føre til at pakker/segmenter ikke komme fram. Da vet senderen at vinduet som brukes er for stort.
TCP sender et nytt ACK segment for hver gang det mottas et segment, selv om det kommer i feil rekkefølge. Flere ACKer der ikke nye data ACKes er altså en klar indikasjon på at et segment ikke har kommet fram. Hvis 3 ACKer for de samme datene kommer sender TCP det neste segmentet etter det ACKede dataene på nytt, uten å vente på at Retransmit Timer skal trigge.
Etter Fast Retransmit settes ikke Slow Start i verk. Dette kalles Fast Recovery, og gjøres fordi dupliserte ACKer tyder på at senere sente segmenter har kommert fram. Da må det være bare begrenset congestion på nettet.
TCP bruker tiden det tar fra et segment sendes ut til ACk for det tilsvarende segmentet er mottat for å estimere hvor lang Round Trip Time (RTT) det er over det aktuelle nettverket. ACK for segmenter som er sendt flere ganger brukes ikke i estimeringen av RTT. Før et segment sendes på nytt settes en Retransmit Timer for hvert segment. Denne timeren settes til en verdi som avhenger av RTT.