Internettprotokollpakke - Internet protocol suite

Den Internet protokollrekke, vanligvis kjent som TCP / IP, er det sett av kommunikasjonsprotokoller som brukes i Internett og lignende datanettverk . De nåværende grunnprotokollene i pakken er Transmission Control Protocol (TCP) og Internet Protocol (IP).

Under utviklingen ble versjoner av den kjent som Department of Defense ( DoD ) -modellen fordi utviklingen av nettverksmetoden ble finansiert av USAs forsvarsdepartement gjennom DARPA . Implementeringen er en protokollstabel .

Internettprotokollpakken gir ende-til-ende-datakommunikasjon som spesifiserer hvordan data skal pakkes, adresseres, overføres, dirigeres og mottas. Denne funksjonaliteten er organisert i fire abstraksjonslag , som klassifiserer alle relaterte protokoller i henhold til hver protokols omfang av nettverk. Fra laveste til høyeste er lagene koblingslaget , som inneholder kommunikasjonsmetoder for data som forblir innenfor et enkelt nettverkssegment (lenke); den internett-lag , som gir internettkommunikasjon mellom uavhengige nett; den transportlaget , håndtering vert til vert-kommunikasjon; og applikasjonslaget , som gir prosess-til-prosess-datautveksling for applikasjoner.

De tekniske standardene som ligger til grunn for Internett -protokollpakken og dens konstituerende protokoller opprettholdes av Internet Engineering Task Force (IETF). Internettprotokollpakken går foran OSI -modellen , et mer omfattende referanseramme for generelle nettverkssystemer.

Historie

Tidlig forskning

Diagram over den første internettarbeidede tilkoblingen
En SRI International Packet Radio Van , brukt til den første treveis internettbaserte overføringen.

Internettprotokollpakken kom fra forskning og utvikling utført av Defense Advanced Research Projects Agency ( DARPA ) på slutten av 1960 -tallet. Etter å ha startet den banebrytende ARPANET i 1969, startet DARPA arbeidet med en rekke andre dataoverføringsteknologier. I 1972 begynte Robert E. Kahn i DARPA Information Processing Technology Office , hvor han jobbet på både satellittpakkenettverk og bakkebaserte radiopakkenettverk, og anerkjente verdien av å kunne kommunisere på tvers av begge. Våren 1973 begynte Vinton Cerf , som hjalp med å utvikle den eksisterende ARPANET Network Control Program (NCP) -protokollen, med Kahn for å jobbe med modeller for åpen sammenkobling med det mål å designe den neste protokollgenerasjonen for ARPANET. De trakk på erfaringene fra forskningsmiljøet ARPANET og International Networking Working Group , som Cerf ledet.

Sommeren 1973 hadde Kahn og Cerf utarbeidet en grunnleggende omformulering, der forskjellene mellom lokale nettverksprotokoller ble skjult ved å bruke en felles internettprotokoll , og i stedet for at nettverket var ansvarlig for pålitelighet, som i de eksisterende ARPANET -protokollene , ble denne funksjonen delegert til vertene. Cerf tilskriver Hubert Zimmermann og Louis Pouzin , designer av CYCLADES -nettverket, med viktig innflytelse på dette designet. Den nye protokollen ble implementert som Transmission Control Program i 1974.

I utgangspunktet administrerte Transmission Control Program både datagramoverføringer og ruting, men etter hvert som erfaringen med protokollen vokste, anbefalte samarbeidspartnere oppdeling av funksjonalitet i lag med forskjellige protokoller. Advokater inkluderte Jonathan Postel fra University of Southern California's Information Sciences Institute , som redigerte Request for Comments (RFCs), den tekniske og strategiske dokumentserien som både har dokumentert og katalysert internettutvikling, og forskergruppen til Robert Metcalfe ved Xerox PARC . Postel uttalte: "Vi skrukker opp i vårt design av internettprotokoller ved å bryte lagdelingsprinsippet." Innkapsling av forskjellige mekanismer var ment å skape et miljø der de øvre lagene bare kunne få tilgang til det som var nødvendig fra de nedre lagene. En monolitisk design ville være lite fleksibel og føre til skalerbarhetsproblemer. I versjon 3 av TCP, skrevet i 1978, ble Transmission Control Program delt inn i to forskjellige protokoller, Internett-protokollen som et forbindelsesfritt lag og Transmission Control Protocol som en pålitelig tilkoblingsorientert tjeneste .

Utformingen av nettverket inkluderte erkjennelsen av at det bare skulle gi funksjonene til effektiv overføring og dirigering av trafikk mellom sluttnoder og at all annen intelligens skulle være plassert i utkanten av nettverket, i sluttnodene. Denne designen er kjent som ende-til-ende-prinsippet . Ved å bruke dette designet ble det mulig å koble andre nettverk til ARPANET som brukte det samme prinsippet, uavhengig av andre lokale egenskaper, og derved løse Kahns første internettarbeidsproblem. Et populært uttrykk er at TCP/IP, det endelige produktet av Cerf og Kahns arbeid, kan kjøre over "to blikkbokser og en snor." År senere, som en spøk, ble IP over Avian Carriers formelle protokollspesifikasjon opprettet og testet.

DARPA inngikk kontrakt med BBN Technologies , Stanford University og University College London for å utvikle operasjonelle versjoner av protokollen på flere maskinvareplattformer. Under utviklingen av protokollen gikk versjonsnummeret til pakkerutingslaget videre fra versjon 1 til versjon 4, sistnevnte ble installert i ARPANET i 1983. Det ble kjent som Internet Protocol versjon 4 (IPv4) som protokollen som fremdeles er i bruk på Internett, sammen med den nåværende etterfølgeren, Internet Protocol versjon 6 (IPv6).

Tidlig implementering

I 1975 ble det utført en to-nettverks IP-kommunikasjonstest mellom Stanford og University College London. I november 1977 ble det utført en IP-test med tre nettverk mellom nettsteder i USA, Storbritannia og Norge. Flere andre IP -prototyper ble utviklet ved flere forskningssentre mellom 1978 og 1983. Før "1. flaggdagen" 1. januar 1983 brukte Internett NCP i stedet for TCP som transportlagsprotokoll.

En datamaskin som kalles en ruter, er utstyrt med et grensesnitt til hvert nettverk. Den videresender nettverkspakker frem og tilbake mellom dem. Opprinnelig ble en ruter kalt gateway , men begrepet ble endret for å unngå forvirring med andre typer gateways .

Adopsjon

I mars 1982 erklærte det amerikanske forsvarsdepartementet TCP/IP som standarden for alle militære datanettverk. Samme år vedtok NORSAR og Peter Kirsteins forskningsgruppe ved University College London protokollen. Migreringen av ARPANET til TCP/IP ble offisielt fullført på flaggdagen 1. januar 1983, da de nye protokollene ble permanent aktivert.

I 1985 holdt Internet Advisory Board (senere Internet Architecture Board ) en tredagers TCP/IP-workshop for dataindustrien, deltatt av 250 leverandørrepresentanter, som promoterte protokollen og førte til økende kommersiell bruk. I 1985 fokuserte den første Interop -konferansen på nettverksinteroperabilitet ved bredere adopsjon av TCP/IP. Konferansen ble grunnlagt av Dan Lynch, en tidlig internettaktivist. Fra begynnelsen deltok store selskaper, som IBM og DEC, på møtet.

IBM, AT&T og DEC var de første store selskapene som tok i bruk TCP/IP, til tross for at de konkurrerte proprietære protokoller . I IBM, fra 1984, utførte Barry Appelmans gruppe TCP/IP -utvikling. De navigerte i bedriftspolitikken for å få en strøm av TCP/IP -produkter for forskjellige IBM -systemer, inkludert MVS , VM og OS/2 . Samtidig begynte flere mindre selskaper, som FTP Software og Wollongong Group , å tilby TCP/IP -stabler for DOS og Microsoft Windows . Den første VM/CMS TCP/IP -stakken kom fra University of Wisconsin.

Noen av de tidlige TCP/IP-stablene ble skrevet på egen hånd av noen få programmerere. Jay Elinsky og Oleg Vishnepolsky  [ ru ] fra IBM Research skrev TCP/IP -stabler for henholdsvis VM/CMS og OS/2. I 1984 skrev Donald Gillies ved MIT en ntcp multi-connection TCP som kjørte på toppen av IP/PacketDriver-laget som ble vedlikeholdt av John Romkey på MIT i 1983–4. Romkey utnyttet denne TCP i 1986 da FTP Software ble grunnlagt. Fra 1985 opprettet Phil Karn en TCP-applikasjon med flere tilkoblinger for skinkeradiosystemer (KA9Q TCP).

Spredningen av TCP/IP ble drevet ytterligere opp i juni 1989, da University of California, Berkeley gikk med på å plassere TCP/IP -koden utviklet for BSD UNIX i allmennheten. Ulike bedriftsleverandører, inkludert IBM, inkluderte denne koden i kommersielle TCP/IP -programvareutgivelser. Microsoft gitt ut en lokal TCP / IP-stakken i Windows 95. Denne hendelsen bidro sement TCP / IP dominans i forhold til andre protokoller på Microsoft-baserte nettverk, som inkluderte IBMs Systems Network Architecture (SNA), og på andre plattformer som Digital Equipment Corporation 's DECnet , Open Systems Interconnection (OSI) og Xerox Network Systems (XNS).

I en periode på slutten av 1980 -tallet og begynnelsen av 1990 -tallet ble ingeniører, organisasjoner og nasjoner imidlertid polarisert i spørsmålet om hvilken standard , OSI -modellen eller Internett -protokollpakken som ville resultere i de beste og mest robuste datanettverk.

Formell spesifikasjon og standarder

De tekniske standardene som ligger til grunn for Internett -protokollpakken og dens konstituerende protokoller er delegert til Internet Engineering Task Force (IETF).

Den karakteristiske arkitekturen til Internet Protocol Suite er dens brede inndeling i driftsomfang for protokollene som utgjør kjernefunksjonaliteten. Den definerende spesifikasjonen for suiten er RFC 1122, som i grove trekk skisserer fire abstraksjonslag . Disse har stått tidstesten, ettersom IETF aldri har endret denne strukturen. Som en slik nettverksmodell går Internet Protocol Suite foran OSI -modellen, et mer omfattende referanseramme for generelle nettverkssystemer.

Viktige arkitektoniske prinsipper

Konseptuell dataflyt i en enkel nettverkstopologi med to verter ( A og B ) forbundet med en kobling mellom deres respektive rutere. Applikasjonen på hver vert utfører lese- og skriveoperasjoner som om prosessene var direkte forbundet med hverandre av en slags datarør. Etter etablering av dette røret, er de fleste detaljer om kommunikasjonen skjult for hver prosess, ettersom de underliggende kommunikasjonsprinsippene er implementert i de nedre protokollagene. I analogi, på transportlaget fremstår kommunikasjonen som vert-til-vert, uten kunnskap om applikasjonsdatastrukturer og tilkoblingsrutere, mens på internettarbeidslaget krysses individuelle nettverksgrenser på hver ruter.
Innkapsling av applikasjonsdata synkende gjennom lagene beskrevet i RFC 1122

Den ende-til-ende-prinsippet har utviklet seg over tid. Det opprinnelige uttrykket satte opprettholdelsen av tilstand og generell intelligens på kantene, og antok at Internett som koblet kantene beholdt ingen tilstand og konsentrerte seg om hastighet og enkelhet. Virkelige behov for brannmurer, nettverksadresseoversettere, webinnholdsbuffere og lignende har tvunget til endringer i dette prinsippet.

De robusthet prinsippet heter det: "Generelt, en implementering må være konservativ i sin sending atferd, og liberale i sin mottaks atferd vil si at det må være forsiktig med å sende velformet datagrammer, men må akseptere enhver datagram at det kan tolke (. f.eks. ikke protestere mot tekniske feil der betydningen fremdeles er klar). " "Den andre delen av prinsippet er nesten like viktig: programvare på andre verter kan inneholde mangler som gjør det uklokt å utnytte lovlige, men uklare protokollfunksjoner."

Innkapsling brukes til å tilby abstraksjon av protokoller og tjenester. Innkapsling er vanligvis på linje med inndelingen av protokollpakken i lag med generell funksjonalitet. Generelt bruker en applikasjon (modellens høyeste nivå) et sett med protokoller for å sende dataene sine nedover lagene. Dataene er ytterligere innkapslet på hvert nivå.

Et tidlig arkitekturdokument, RFC  1122 , understreker arkitektoniske prinsipper over lagdeling. RFC 1122, med tittelen Host Requirements , er strukturert i avsnitt som refererer til lag, men dokumentet refererer til mange andre arkitektoniske prinsipper og legger ikke vekt på lagdeling. Den definerer løst en firelags modell, med lagene som har navn, ikke tall, som følger:

  • Det Applikasjonslaget er omfanget innenfor hvilke programmer eller prosesser , opprette brukerdata og kommunisere denne informasjonen til andre programmer på en annen eller den samme vert. Applikasjonene bruker tjenestene som tilbys av de underliggende nedre lagene, spesielt transportlaget som gir pålitelige eller upålitelige rør til andre prosesser. Kommunikasjonspartnerne er preget av applikasjonsarkitekturen, for eksempel klient-server-modellen og peer-to-peer- nettverk. Dette er laget der alle applikasjonsprotokoller, for eksempel SMTP, FTP, SSH, HTTP, opererer. Prosesser adresseres via porter som i hovedsak representerer tjenester .
  • De sportlags utfører vert-til-vert-kommunikasjon på enten lokalt nettverk eller fjernnett separert ved rutere. Det gir en kanal for kommunikasjonsbehov for applikasjoner. UDP er den grunnleggende transportlagsprotokollen, som gir en upålitelig tilkoblingsløs datagramtjeneste. Transmission Control Protocol gir flytkontroll, etablering av tilkoblinger og pålitelig overføring av data.
  • De internett lags utveksling datagrammer over nettverksgrenser. Det gir et enhetlig nettverksgrensesnitt som skjuler den faktiske topologien (layout) for de underliggende nettverkstilkoblingene. Det er derfor også laget som etablerer internettarbeid. Faktisk definerer og etablerer den Internett. Dette laget definerer adresserings- og rutingstrukturene som brukes for TCP/IP -protokollpakken. Hovedprotokollen i dette omfanget er Internett -protokollen, som definerer IP -adresser . Funksjonen i ruting er å transportere datagrammer til den neste verten, som fungerer som en IP -ruter, som har tilkobling til et nettverk nærmere den endelige datadestinasjonen.
  • Det Link-laget definerer nettverks metoder innenfor rammen av det lokale nettverket koblingen på hvilke verter kommuniserer uten mellomliggende rutere. Dette laget inkluderer protokollene som brukes til å beskrive den lokale nettverkstopologien og grensesnittene som trengs for å påvirke overføringen av Internett-lagdatagrammer til vertene til naboen.

Linklag

Protokollene til koblingslaget opererer innenfor omfanget av den lokale nettverkstilkoblingen som en vert er knyttet til. Dette regimet kalles lenken i TCP/IP -språk og er det laveste komponentlaget i pakken. Koblingen inkluderer alle verter som er tilgjengelige uten å krysse en ruter. Størrelsen på lenken bestemmes derfor av maskinvaredesignet for nettverket. I prinsippet er TCP/IP designet for å være maskinvareuavhengig og kan implementeres på praktisk talt hvilken som helst lenketeknologi. Dette inkluderer ikke bare maskinvareimplementeringer, men også virtuelle koblingslag som virtuelle private nettverk og nettverkstunneler .

Koblingslaget brukes til å flytte pakker mellom Internett -laggrensesnittene til to forskjellige verter på samme lenke. Prosessene for overføring og mottak av pakker på lenken kan styres i enhetsdriveren for nettverkskortet , så vel som i fastvaren eller med spesialiserte brikkesett . Disse utfører funksjoner, for eksempel innramming, for å forberede internettlagspakkene for overføring, og til slutt overføre rammene til det fysiske laget og over et overføringsmedium . TCP/IP-modellen inneholder spesifikasjoner for å oversette nettverksadressemetodene som brukes i Internett-protokollen til adresser med lenke, for eksempel MAC-adresser ( media access control ). Alle andre aspekter under dette nivået antas imidlertid implisitt å eksistere, og er ikke eksplisitt definert i TCP/IP -modellen.

Koblingslaget i TCP/IP -modellen har tilsvarende funksjoner i lag 2 i OSI -modellen.

Internett -lag

Internettarbeid krever at data sendes fra kildenettverket til destinasjonsnettverket. Denne prosessen kalles ruting og støttes av vertsadressering og identifikasjon ved hjelp av det hierarkiske IP -adresseringssystemet . Det Internett lag gir en upålitelig gram overføringsanlegg mellom maskiner plassert på potensielt forskjellige IP-nettverk ved å videresende datapakker til et passende neste-hopp-ruter for ytterligere videresending til sitt bestemmelsessted. Internettlaget har ansvaret for å sende pakker over potensielt flere nettverk. Med denne funksjonaliteten gjør internettlaget mulig internettarbeid, samhandling av forskjellige IP -nettverk, og det etablerer i hovedsak Internett.

Internett -laget skiller ikke mellom de forskjellige transportlagsprotokollene. IP bærer data for en rekke forskjellige øvre lagprotokoller . Disse protokollene er hver identifisert med et unikt protokollnummer : for eksempel Internet Control Message Protocol (ICMP) og Internet Group Management Protocol (IGMP) er henholdsvis protokoll 1 og 2.

Internettprotokollen er hovedkomponenten i internettlaget, og den definerer to adressesystemer for å identifisere nettverksverter og for å lokalisere dem på nettverket. Det originale adressesystemet til ARPANET og dens etterfølger, Internett, er Internet Protocol versjon 4 (IPv4). Den bruker en 32-biters IP-adresse og er derfor i stand til å identifisere omtrent fire milliarder verter. Denne begrensningen ble eliminert i 1998 ved standardisering av Internet Protocol versjon 6 (IPv6) som bruker 128-biters adresser. IPv6 -produksjonsimplementeringer dukket opp i omtrent 2006.

Transportlag

Transportlaget etablerer grunnleggende datakanaler som applikasjoner bruker for oppgavespesifikk datautveksling. Laget etablerer vert-til-vert-tilkobling i form av ende-til-ende-meldingstjenester som er uavhengige av det underliggende nettverket og uavhengig av strukturen til brukerdata og logistikken for utveksling av informasjon. Tilkobling på transportlaget kan kategoriseres som enten tilkoblingsorientert , implementert i TCP eller tilkoblingsløs , implementert i UDP. Protokollene i dette laget kan gi feilkontroll , segmentering , flytkontroll , overbelastningskontroll og applikasjonsadressering ( portnumre ).

Med det formål å tilby prosesspesifikke overføringskanaler for applikasjoner, etablerer laget konseptet med nettverksporten . Dette er en nummerert logisk konstruksjon som er tildelt spesielt for hver av kommunikasjonskanalene et program trenger. For mange typer tjenester har disse portnumrene blitt standardisert slik at klientdatamaskiner kan adressere spesifikke tjenester til en servercomputer uten involvering av serviceoppdagelse eller katalogtjenester .

Fordi IP bare gir best mulig innsats , tilbyr noen transportlagsprotokoller pålitelighet.

TCP er en tilkoblingsorientert protokoll som adresserer mange pålitelighetsproblemer ved å tilby en pålitelig byte-strøm :

  • data kommer i rekkefølge
  • data har minimal feil (dvs. korrekthet)
  • dupliserte data forkastes
  • tapte eller kastede pakker sendes på nytt
  • inkluderer trafikkbelastningskontroll

Den nyere Stream Control Transmission Protocol (SCTP) er også en pålitelig, tilkoblingsorientert transportmekanisme. Det er meldingsstrøm-orientert, ikke byte-strøm-orientert som TCP, og gir flere strømmer multiplekset over en enkelt tilkobling. Det gir også multihoming -støtte, der en tilkoblingsende kan representeres av flere IP -adresser (som representerer flere fysiske grensesnitt), slik at hvis en mislykkes, blir forbindelsen ikke avbrutt. Den ble opprinnelig utviklet for telefoni -applikasjoner (for å transportere SS7 over IP).

Pålitelighet kan også oppnås ved å kjøre IP over en pålitelig datalink-protokoll, for eksempel High-Level Data Link Control (HDLC).

Den User Datagram Protocol (UDP) er en forbindelsesløs datagram protokoll. I likhet med IP er det en upålitelig og upålitelig protokoll. Pålitelighet adresseres gjennom feildeteksjon ved hjelp av en kontrollsumalgoritme. UDP brukes vanligvis for applikasjoner som streamingmedier (lyd, video, Voice over IP osv.) Der ankomst i tide er viktigere enn pålitelighet, eller for enkle spørrings-/svarprogrammer som DNS- oppslag, der overhead for å sette opp en pålitelig tilkobling er uforholdsmessig stor. Sanntids transportprotokoll (RTP) er en datagramprotokoll som brukes over UDP og er designet for sanntidsdata som streaming media .

Applikasjonene på en gitt nettverksadresse kjennetegnes ved sin TCP- eller UDP -port. Etter konvensjon er visse kjente porter knyttet til spesifikke applikasjoner.

TCP/IP-modellens transport- eller vert-til-vert-lag tilsvarer omtrent det fjerde laget i OSI-modellen, også kalt transportlaget.

Påføringslag

Det Applikasjonslaget omfatter protokollene som brukes ved de fleste anvendelser for å tilveiebringe brukertjenester eller utveksling av applikasjonsdata over de viste nettverksforbindelsene fastlagt av de lavere nivå-protokoller. Dette kan inkludere noen grunnleggende nettverkstjenester, for eksempel rutingsprotokoller og vertskonfigurasjon. Eksempler på applikasjonslagsprotokoller inkluderer Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) og Dynamic Host Configuration Protocol (DHCP). Data kodet i henhold til applikasjonslagsprotokoller er innkapslet i protokollenheter for transportlag (for eksempel TCP -strømmer eller UDP -datagrammer), som igjen bruker protokoller for lavere lag for å utføre faktisk dataoverføring.

TCP/IP -modellen tar ikke hensyn til detaljene i formatering og presentasjon av data og definerer ikke ytterligere lag mellom applikasjons- og transportlagene som i OSI -modellen (presentasjons- og sesjonslag). I følge TCP/IP -modellen er slike funksjoner riket til biblioteker og programmeringsgrensesnitt . Applikasjonslaget i TCP/IP -modellen blir ofte sammenlignet med en kombinasjon av det femte (sesjonen), det sjette (presentasjonen) og det syvende (applikasjons) laget av OSI -modellen.

Applikasjonslagsprotokoller er ofte knyttet til bestemte klient-server- applikasjoner, og vanlige tjenester har velkjente portnumre reservert av Internet Assigned Numbers Authority (IANA). For eksempel bruker HyperText Transfer Protocol serverport 80 og Telnet bruker serverport 23. Klienter som kobler seg til en tjeneste bruker vanligvis flyktige porter , dvs. portnumre som bare er tildelt tilfeldig eller under et spesifikt område som er konfigurert i applikasjon.

På applikasjonslaget skiller TCP/IP -modellen mellom brukerprotokoller og støtteprotokoller . Støtteprotokoller gir tjenester til et system med nettverksinfrastruktur. Brukerprotokoller brukes for faktiske brukerprogrammer. For eksempel er FTP en brukerprotokoll og DNS er en støtteprotokoll.

Selv om applikasjonene vanligvis er klar over viktige kvaliteter ved transportlagsforbindelsen, for eksempel sluttpunktets IP -adresser og portnumre, behandler applikasjonslagsprotokoller generelt transportlag (og nedre) protokoller som svarte bokser som gir en stabil nettverkstilkobling som de kan kommunisere over . Transportlaget og lagene på lavere nivå er ikke bekymret for detaljene i applikasjonslagsprotokollene. Rutere og svitsjer undersøker vanligvis ikke den innkapslede trafikken, de gir bare en kanal for den. Noen brannmur- og båndbredde -applikasjoner bruker imidlertid dyp pakkeinspeksjon for å tolke applikasjonsdata. Et eksempel er Resource Reservation Protocol (RSVP). Noen ganger er det også nødvendig for applikasjoner som er berørt av NAT, å vurdere applikasjonens nyttelast.

Lagnavn og antall lag i litteraturen

Tabellen nedenfor viser ulike nettverksmodeller. Antall lag varierer mellom tre og syv.

RFC 1122, Internett STD 3 (1989) Cisco Academy Kurose, Forouzan Kommer, Kozierok Stallings Tanenbaum Arpanet referansemodell (RFC 871) OSI -modell
Fire lag Fire lag Fem lag Fire+ett lag Fem lag Fem lag Tre lag Sju lag
"Internettmodell" "Internettmodell" "Fem-lags internettmodell" eller "TCP/IP-protokolsuite" "TCP/IP 5-lags referansemodell" "TCP/IP -modell" "TCP/IP 5-lags referansemodell" "Arpanet referansemodell" OSI -modell
applikasjon applikasjon applikasjon applikasjon applikasjon applikasjon Søknadsprosess applikasjon
Presentasjon
Økt
Transportere Transportere Transportere Transportere Vert til vert eller transport Transportere Vert til vert Transportere
Internett Internettarbeid Nettverk Internett Internett Internett Nettverk
Lenke Nettverksgrensesnitt Data lenke Datalink (nettverksgrensesnitt) Nettverkstilgang Data lenke Nettverksgrensesnitt Data lenke
Fysisk (Maskinvare) Fysisk Fysisk Fysisk

Noen av nettverksmodellene er fra lærebøker, som er sekundære kilder som kan komme i konflikt med hensikten med RFC 1122 og andre primære IETF -kilder.

Sammenligning av TCP/IP og OSI -lagdeling

De tre øverste lagene i OSI -modellen, det vil si applikasjonslaget, presentasjonslaget og sesjonslaget, skilles ikke separat i TCP/IP -modellen som bare har et applikasjonslag over transportlaget. Mens noen rene OSI -protokollapplikasjoner, for eksempel X.400 , også kombinerte dem, er det ikke noe krav om at en TCP/IP -protokollstabel må pålegge monolitisk arkitektur over transportlaget. For eksempel kjører NFS -applikasjonsprotokollen over XDR -presentasjonsprotokollen ( External Data Representation ), som igjen kjører over en protokoll kalt Remote Procedure Call (RPC). RPC gir pålitelig rekordoverføring, slik at den trygt kan bruke UDP-transporten best mulig.

Ulike forfattere har tolket TCP/IP -modellen annerledes, og er uenige om koblingslaget eller et hvilket som helst aspekt av TCP/IP -modellen dekker problemer med OSI -lag 1 ( fysisk lag ), eller om TCP/IP antar at det finnes et maskinvarelag under lenke lag.

Flere forfattere har forsøkt å inkorporere OSI -modellens lag 1 og 2 i TCP/IP -modellen siden disse ofte refereres til i moderne standarder (for eksempel av IEEE og ITU ). Dette resulterer ofte i en modell med fem lag, der koblingslaget eller nettverkstilgangslaget er delt inn i OSI -modellens lag 1 og 2.

IETF -protokollutviklingsarbeidet er ikke opptatt av streng lagdeling. Noen av protokollene passer kanskje ikke rent inn i OSI -modellen, selv om RFC -er noen ganger refererer til den og ofte bruker de gamle OSI -lagnummerene. IETF har gjentatte ganger uttalt at utvikling av Internett-protokoll og arkitektur ikke er ment å være OSI-kompatibel. RFC 3439, som refererer til internettarkitekturen, inneholder en seksjon med tittelen: "Layering anses som skadelig".

For eksempel anses sesjons- og presentasjonslagene i OSI -pakken å være inkludert i applikasjonslaget i TCP/IP -pakken. Funksjonen til sesjonslaget finnes i protokoller som HTTP og SMTP og er mer tydelig i protokoller som Telnet og Session Initiation Protocol (SIP). Øktlagsfunksjonalitet blir også realisert med portnummereringen til TCP- og UDP-protokollene, som er inkludert i transportlaget i TCP/IP-pakken. Funksjonene til presentasjonslaget realiseres i TCP/IP -applikasjonene med MIME -standarden i datautveksling.

IETF -protokoller kan innkapsles rekursivt, som demonstrert av tunnelingsprotokoller som Generic Routing Encapsulation (GRE). GRE bruker den samme mekanismen som OSI bruker for tunneling ved nettverkslaget.

Implementeringer

Internettprotokollpakken forutsetter ikke noe bestemt maskinvare- eller programvaremiljø. Det krever bare at maskinvare og et programvarelag finnes som er i stand til å sende og motta pakker på et datanettverk. Som et resultat har suiten blitt implementert på praktisk talt alle databehandlingsplattformer. En minimal implementering av TCP/IP inkluderer følgende: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP) og Internet Group Management Protokoll (IGMP). I tillegg til IP, krever ICMP, TCP, UDP, Internet Protocol versjon 6 Neighbor Discovery Protocol (NDP), ICMPv6 og Multicast Listener Discovery (MLD) og er ofte ledsaget av et integrert IPSec -sikkerhetslag.

Se også

Bibliografi

Referanser

Eksterne linker