Informasjonsoverføring er et begrep som forener mange fysiske prosesser for informasjonsbevegelse i rommet. I noen av disse prosessene er komponenter som en kilde og mottaker av data, et fysisk medium for informasjon og en kanal (medium) for overføringen involvert.
Informasjonsoverføringsprosess
De originale datalagrene er forskjellige meldinger som sendes fra kildene til mottakere. Informasjonsoverføringskanaler er plassert mellom dem. Spesielle tekniske enheter-omformere (kodere) danner fysiske databærere - signaler - basert på innholdet i meldinger. Sistnevnte gjennomgår en rekke transformasjoner, inkludert koding, komprimering, modulering, og sendes deretter til kommunikasjonslinjene. Etter å ha gått gjennom dem, gjennomgår signalene inverse transformasjoner, inkludert demodulering, utpakking og dekoding, som et resultat av at de originale meldingene, oppfattet av mottakerne, trekkes ut fra dem.
Informasjonsmeldinger
En melding er en slags beskrivelse av et fenomen eller et objekt, uttrykt som en samling av data som har tegn på en begynnelse og en slutt. Noen meldinger, som tale og musikk, er kontinuerlige funksjoner for lydtrykktid. I telegrafkommunikasjon er en melding teksten til et telegram i form av en alfanumerisk sekvens. En TV-melding er en sekvens av bildemeldinger som "ses" av en TV-kameralinse og fanger dem med en bildefrekvens. Det overveldende flertallet av meldinger som nylig er overført gjennom informasjonsoverføringssystemer er numeriske matriser, tekst, grafikk, samt lyd- og videofiler.
Informasjonssignaler
Overføring av informasjon er mulig hvis den har et fysisk medium, hvis egenskaper endres avhengig av innholdet i den overførte meldingen, slik at de overvinner overføringskanalen med minimal forvrengning og kan gjenkjennes av mottakeren. Disse endringene i det fysiske lagringsmediet danner et informasjonssignal.
I dag overføres og behandles informasjon ved hjelp av elektriske signaler i kablede og radiokommunikasjonskanaler, samt takket være optiske signaler i fiberoptiske kommunikasjonslinjer.
Analoge og digitale signaler
Et velkjent eksempel på et analogt signal, dvs. kontinuerlig endring i tid, er spenningen fjernet fra mikrofonen, som bærer en stemme eller musikalsk informasjonsmelding. Den kan forsterkes og overføres over kablede kanaler til lydgjengivelsessystemene i konsertsalen, som vil frakte tale og musikk fra scenen til publikum i galleriet.
Hvis amplituden eller frekvensen av høyfrekvente elektriske oscillasjoner i radiosenderen kontinuerlig endres over tid, i samsvar med størrelsen på spenningen ved mikrofonens utgang, kan et analogt radiosignal sendes over luften. En fjernsynssender i et analogt fjernsynssystem genererer et analogt signal i form av en spenning proporsjonal med gjeldende lysstyrke til bildeelementene som oppfattes av kameralinsen.
Men hvis den analoge spenningen fra mikrofonutgangen sendes gjennom en digital-til-analog omformer (DAC), vil utgangen ikke lenger være en kontinuerlig funksjon av tiden, men en sekvens av avlesninger av denne spenningen tatt med jevne mellomrom med en samplingsfrekvens. I tillegg utfører DAC også kvantisering i henhold til nivået på startspenningen, og erstatter hele det mulige området av verdiene med et begrenset sett med verdier bestemt av antall binære sifre i utgangskoden. Det viser seg at en kontinuerlig fysisk mengde (i dette tilfellet denne spenningen) blir til en sekvens av digitale koder (er digitalisert), og deretter, allerede i digital form, kan den lagres, behandles og overføres gjennom informasjonsoverføringsnettverk. Dette øker hastigheten og støyimmuniteten til slike prosesser betydelig.
Kommunikasjonskanaler
Vanligvis refererer dette begrepet til komplekset av tekniske midler som er involvert i overføring av data fra kilden til mottakeren, så vel som miljøet mellom dem. Strukturen til en slik kanal, ved bruk av typiske midler for informasjonsoverføring, er representert av følgende sekvens av transformasjoner:
AI - PS - (CI) - CC - M - LPI - DM - DK - CI - PS
AI er en kilde til informasjon: en person eller et annet levende vesen, en bok, et dokument, et bilde på et ikke-elektronisk medium (lerret, papir), etc.
PS - omformer av informasjonsmelding til informasjonssignal, utfører det første trinnet av dataoverføring. Mikrofoner, fjernsyns- og videokameraer, skannere, fakser, PC-tastaturer osv. kan fungere som PS-er.
KI er en koder for informasjon i et informasjonssignal for å redusere volumet (komprimering) av informasjon for å øke overføringshastigheten eller redusere frekvensbåndet som kreves for overføring. Denne lenken er valgfri, som vist i parentes.
KK - kanalkoder for å forbedre immuniteten til informasjonssignalet.
M - signalmodulator for å endre egenskapene til mellombæresignaler, avhengig av størrelsen på informasjonssignalet. Et typisk eksempel er amplitudemodulasjon av et bærebølgesignal med høy bærefrekvens avhengig av størrelsen på det lavfrekvente informasjonssignalet.
LPI er en informasjonsoverføringslinje som representerer en kombinasjon av et fysisk medium (for eksempel et elektromagnetisk felt) og tekniske midler for å endre tilstanden for å overføre et bæresignal til en mottaker.
DM - demodulator for å skille informasjonssignalet fra bæresignalet. Til stede kun hvis M.
DC - kanaldekoder for å oppdage og/eller korrigere feil i informasjonssignalet som har oppstått på LPI. Kun tilgjengelig hvis det er en QC.
CI - informasjonsdekoder. Tilstede bare hvis det er en CI.
PI - mottakeren av informasjon (datamaskin, skriver, skjerm, etc.).
Hvis overføringen av informasjon er toveis (duplekskanal), er det på begge sider av LPI-en modemenheter (Modulator-DEModulator), som kombinerer M- og DM-koblinger, samt kodek-blokker (COder-DECoder), som kombinerer kodere (CI og CK) og dekodere (DI og DK).
Kjennetegn på overføringskanaler
De viktigste kjennetegnene til kanalene er båndbredde og støyimmunitet.
I kanalen er informasjonssignalet utsatt for støy og forstyrrelser. De kan være forårsaket av naturlige årsaker (for eksempel atmosfæriske for radiokanaler) eller være spesielt skapt av fienden.
Støyimmuniteten til overføringskanaler økes ved å bruke ulike typer analoge og digitale filtre for å skille informasjonssignaler fra støy, samt spesielle metoder for å sende meldinger som minimerer effekten av støy. En av disse metodene er å legge til ekstra tegn som ikke har nyttig innhold, men som hjelper til med å kontrollere riktigheten av meldingen, samt rette feil i den.
Kanalkapasiteten er lik det maksimale antallet binære symboler (kbits) som overføres av den i fravær av interferens i løpet av ett sekund. For ulike kanaler varierer det fra noen få kbps til hundrevis av Mbps og bestemmes av deres fysiske egenskaper.
Informasjonsoverføringsteori
Claude Shannon er forfatteren av en spesiell teori for koding av overførte data, som oppdaget metoder for å håndtere støy. En av hovedideene til denne teorien er behovet for redundans for den digitale koden som sendes over informasjonsoverføringslinjer. Dette gjør det mulig å gjenopprette tapet hvis en del av koden går tapt under overføringen. Slike koder (digitale informasjonssignaler) kalles anti-jamming-koder. Imidlertid kan redundansen til koden ikke gjøres for stor. Dette fører til det faktum at overføringen av informasjon er forsinket, samt til økningen i kostnadene for kommunikasjonssystemer.
Digital signalbehandling
En annen viktig komponent i teorien om informasjonsoverføring er et system med metoder for digital signalbehandling i overføringskanaler. Disse metodene inkluderer algoritmer for digitalisering av de originale analoge informasjonssignalene med en viss samplingshastighet bestemt på grunnlag av Shannons teorem, samt metoder for å danne støyimmune bæresignaler for overføring over kommunikasjonslinjer og digital filtrering av mottatte signaler for å skille dem fra forstyrrelser.
Datalinklaget er det første laget (fra bunn til topp) som opererer i pakkesvitsjemodus. På dette nivået blir PDƯ vanligvis referert til som en ramme.
Linklagsfunksjonalitet er definert annerledes for LAN og WAN.
I lokale nettverk skal lenkelaget sørge for levering av en ramme mellom eventuelle noder i nettverket. Det antas at nettverket har en typisk topologi, for eksempel en felles buss, ring, stjerne eller tre (hierarkisk stjerne). Eksempler på LAN-teknologier, hvis bruk er begrenset til typiske topologier, er Ethernet, FDDI, Token Ring.
I wide area-nettverk må datalinklaget sikre levering av en ramme kun mellom to nabonoder forbundet med en individuell kommunikasjonslink. Eksempler på punkt-til-punkt-protokoller (som sådan
protokoller) kan være mye brukte protokoller PPP og HDLC. På grunnlag av punkt-til-punkt-lenker kan nettverk av vilkårlig topologi bygges.
For tilkobling av lokale nettverk med hverandre eller for levering av meldinger mellom eventuelle endenoder av det globale nettverket, brukes midler for et høyere nettverkslag.
En av funksjonene til datalinklaget er å opprettholde grensesnitt med det underliggende fysiske laget og det høyere nettverkslaget. Nettverkslaget dirigerer pakken til datalinklaget for overføring til nettverket eller mottar fra det en pakke mottatt fra nettverket. Det fysiske laget brukes av kanalen som et verktøy som mottar og overfører bitsekvenser til nettverket.
La oss begynne å undersøke arbeidet til koblingslaget, fra det øyeblikket senderens nettverkslag sender en pakke til koblingslaget, samt en indikasjon på hvilken node den skal sendes til. For å løse dette problemet lager lenkelaget en ramme som har et datafelt og en overskrift. Koblingslaget plasserer (¡kapsler inn) pakken i datafeltet til rammen og fyller rammeoverskriften med den tilsvarende tjenesteinformasjonen. Den viktigste informasjonen til rammeoverskriften er destinasjonsadressen, på grunnlag av hvilken nettverkssvitsjene vil videresende pakken.
En av oppgavene til datalinklaget er feildeteksjon og retting. For å gjøre dette, fikser datalinklaget grensene til rammen ved å plassere en spesiell bitsekvens ved begynnelsen og slutten, og legger deretter til en kontrollsum til rammen, som også kalles Frame Check Sequence (FCS). Kontrollsummen beregnes i henhold til en eller annen algoritme som en funksjon av alle byte i rammen. Basert på FCS-verdien vil destinasjonsnoden være i stand til å bestemme om rammedataene har blitt ødelagt eller ikke under overføring over nettverket.
Men før du videresender rammen til det fysiske laget for direkte overføring av data til nettverket, kan det hende at lenkelaget må løse et annet viktig problem. Hvis nettverket bruker delte medier, må lenkelaget kontrollere tilgjengeligheten til mediet før det fysiske laget begynner å overføre data. Funksjonene for å sjekke tilgjengeligheten til et delt medie er noen ganger delt opp i et separat underlag for medietilgangskontroll (MAC).
Hvis det delte mediet er ledig (når det ikke brukes, så hoppes en slik sjekk selvfølgelig over), overføres rammen ved hjelp av det fysiske laget til nettverket, går gjennom kommunikasjonskanalen og ankommer i form av en sekvens av biter til disposisjon for det fysiske laget til destinasjonsnoden. Dette laget overfører på sin side de mottatte bitene "opp" til koblingslaget til noden. Sistnevnte grupperer bitene i rammer, beregner sjekksummen av de mottatte dataene igjen og sammenligner resultatet med sjekksummen som sendes i rammen. Hvis de samsvarer, anses rammen som riktig. Hvis kontrollsummene ikke stemmer, registreres en feil. Linklagsfunksjonen inkluderer ikke
bare feildeteksjon, men også deres korrigering ved å sende skadede rammer på nytt. Denne funksjonen er imidlertid valgfri og er ikke tilgjengelig i enkelte lenkelagsimplementeringer, som Ethernet, Token Ring, FDDI og Frame Relay.
Linklagsprotokoller implementeres av datamaskiner, motorer, brytere og rutere, og på datamaskiner implementeres linklagsfunksjoner ved felles innsats fra nettverkskort og deres drivere /
En datakoblingsprotokoll opererer vanligvis innenfor et nettverk som er en av de bestanddelene i et større, sammenkoblet nettverk, sammenkoblet av nettverkslagsprotokoller. Adressene som linklagsprotokollen fungerer med brukes til å levere rammer kun innenfor dette nettverket, og adressene til det neste nettverkslaget brukes til å flytte pakker mellom nettverk.
I lokale nettverk støtter datalinklaget et veldig kraftig og komplett sett med funksjoner for overføring av meldinger mellom nettverksnoder. I noen tilfeller viser datalinklagsprotokollene til lokale nettverk seg å være selvforsynte kjøretøyer og kan tillate applikasjonslagsprotokoller eller applikasjoner å fungere direkte på toppen av seg selv uten å involvere midlene til nettverket og transportlagene. Likevel, for meldingsoverføring av høy kvalitet i nettverk med en vilkårlig topologi, er ikke funksjonene til lenkelaget nok.
Denne uttalelsen er enda mer sant for wide area-nettverk, der koblingslagsprotokollen implementerer en ganske enkel funksjon for å overføre data mellom nabonoder.
Mer om emnet Linklag:
- NIVÅET AV MENNESKELIGE SYKDOMMER ER NIVÅET PÅ HANS AVVIK FRA KANALEN HANS. MENNESKERS HELSE ER EN INDIKATOR PÅ EN PERSONS PLASSERING
Frekvensdeling av signaler (kanaler)
La oss spore hovedstadiene i dannelsen av et flerkanalssignal med frekvensdelingsmultipleksing (FDM). Først, i samsvar med de overførte meldingene, de primære signalene en i(t) som har energispektra,, ..., modulerer underbærerne til hver kanal. Denne operasjonen utføres av modulatorer,, ..., kanalsendere. Spektrene til kanalsignalene oppnådd ved utgangen av frekvensfiltrene,, ..., okkuperer henholdsvis frekvensbåndene,, ..., (fig. 9.2).
Ris. 9.2. Frekvensdelingsmultipleksing og kanalseparasjon
Vi vil anta at hver av meldingene som skal overføres en i(t) opptar båndbredden til en standard PM-kanal. Under dannelsen av gruppesignalet signalerer hver kanal S i(t) et frekvensbånd som ikke overlapper med spektrene til andre signaler tildeles (fig. 9.3). Deretter det totale frekvensbåndet N-kanalgruppen vil være lik
. (9.8)
Figur 9.3 Konvertering av spektre i et system med FDM
Forutsatt at SSB brukes og hvert kanalsignal opptar en båndbredde
for spekteret til gruppesignalet får vi
. (9.10)
Basisbåndsignalet konverteres til et lineært signal og sendes over en kommunikasjonslinje (overføringsvei). På mottakersiden, etter å ha konvertert det lineære signalet til et gruppesignal, bruker sistnevnte båndpasskanalfiltre F k med båndbredde og demodulatorer konverteres til kanalmeldinger, som sendes til mottakeren.
Kort sagt, i flerkanals FDM-systemer er hver kanal tildelt en viss del av den totale basebåndbredden. Til inngangen til mottakerenheten Jeg kanal signalerer samtidig S i av alle N kanaler. Bruk av frekvensfiltre F i bare de frekvensene som tilhører den gitte Jeg kanal.
På grunn av ufullkomne egenskaper til båndpasskanalfiltre, oppstår gjensidig krysstale mellom kanaler. For å redusere denne interferensen er det nødvendig å innføre beskyttelsesfrekvensintervaller mellom kanalene.
Og dermed
Dette betyr at bare rundt 80 % av overføringsbanens båndbredde brukes effektivt i FDM-systemer. I tillegg er det nødvendig å gi en meget høy grad av linearitet av hele gruppebanen.
Tidsdeling av signaler (kanaler)
Med den midlertidige metoden for kanalseparasjon (TDM), gruppebanen ved hjelp av synkrone brytere på senderen ( Til kjørefelt) og mottaker ( K pr) er vekselvis tilveiebrakt for å sende signalene til hver kanal i flerkanalsystemet. (I moderne utstyr brukes praktisk talt ikke mekaniske brytere. I stedet for dem brukes elektroniske brytere, laget for eksempel på skiftregistre.) I VDK sendes signalet til 1. kanal først, deretter neste osv. . til siste kanal etter nummer N, hvoretter 1. kanal kobles til igjen, og prosessen gjentas med en samplingsfrekvens (Figur 9.4).
Som kanalsignaler i TDM-systemer brukes sekvenser av modulerte pulser som ikke overlapper i tid S i (t); sett med kanalpulser - gruppesignal S G ( t) sendes over kommunikasjonslinjen. Bryter på mottakssiden K pr kan identifiseres med nøkkelen som kobler linjen til mottakeren Jeg-th kanal bare for tidspunktet for passasje av impulser Jeg-th kanal ("tidsfilter" F i). Etter demodulering av meldingen en i(t) gå til Jeg til mottakeren.
For normal drift av et flerkanalsystem med VRK, er synkron drift av brytere på sende- og mottakersiden nødvendig. Ofte for dette er en av kanalene okkupert av overføring av spesielle synkroniseringspulser for koordinert drift i tide. Til kjørefelt og Til pr.
Ris. 9.5. Tidsinndeling
to signaler med AIM
I fig. 9.5 viser tidsdiagrammene for et to-kanalssystem med AIM. Meldingsbæreren her er en sekvens av impulser med punktum
, (9.12)
kommer til pulsmodulatoren (MI) fra klokkepulsgeneratoren (GTI). Gruppesignalet (fig. 9.5, a) går til bryteren. Sistnevnte spiller rollen som "midlertidige" parametriske filtre eller nøkler, hvis overføringsfunksjon . (Figur 9.5, b) endringer synkront (med en periode) og i fase med endringer i overføringsfunksjonen:
(9.13)
Dette betyr at kun den th pulsdetektor ID- er koblet til overføringsveien innenfor hvert tidsintervall. Meldingene som mottas som et resultat av deteksjon går til mottakeren av PS-meldingene.
Operatør, beskriver funksjonen til nøkkelfilteret, kutter ut intervallene som følger med en periode fra signalet og forkaster resten av signalet.
Her, som før, betegner intervallet som signalene til den i-kilden blir overført.
Med tidsdeling skyldes gjensidig interferens hovedsakelig to årsaker. Den første er at lineære forvrengninger som oppstår fra det begrensede frekvensbåndet og ufullkommenhet i amplitude-frekvens- og fase-frekvenskarakteristikkene til ethvert fysisk mulig kommunikasjonssystem bryter med impulsnaturen til signalene. Faktisk, hvis spekteret er begrenset under overføringen av modulerte pulser med begrenset varighet, vil pulsene "spre seg" og i stedet for pulser med begrenset varighet vil vi oppnå prosesser som er uendelig utvidet i tid. Ved tidsdeling av signaler vil dette resultere i at pulser fra en kanal blir lagt over pulser fra andre kanaler. Med andre ord oppstår gjensidig krysstale eller intersymbolinterferens mellom kanaler. I tillegg kan gjensidig interferens oppstå på grunn av ufullkommen timing av klokkepulsene på sender- og mottakersiden.
For å redusere nivået av gjensidig interferens, er det nødvendig å innføre "vakt" tidsintervaller, som tilsvarer en viss spredning av signalspekteret. Så i flerkanals telefonisystemer er båndbredden til de effektivt overførte frekvensene = 3100 Hz; i samsvar med Kotelnikov-teoremet, minimumsverdien = 2 = 6200 Hz. I virkelige systemer velges imidlertid pulsrepetisjonshastigheten med en viss margin: = 8 kHz. For å overføre slike pulser i enkanalsmodus kreves en båndbredde på minst 4 kHz. Med tidsdeling av kanaler okkuperer signalet til hver kanal det samme frekvensbåndet, som bestemmes under ideelle forhold i henhold til Kotelnikov-teoremet fra relasjonen (unntatt synkroniseringskanalen)
, (9.14)
hvor , som er det samme som den totale systembåndbredden i frekvensdeling.
Selv om FDC og FDC teoretisk sett er likeverdige når det gjelder effektiviteten ved bruk av frekvensspekteret, er imidlertid FDC-systemer under reelle forhold merkbart dårligere enn FDC-er i denne indikatoren på grunn av vanskelighetene med å redusere nivået av gjensidig interferens under signalseparasjon . Samtidig er den ubestridelige fordelen med VRC en reduksjon i nivået av ikke-lineær støy på grunn av forskjellen i varigheten av virkningen av pulsene til forskjellige kanaler; i VRK-systemene er toppfaktoren lavere. Det er også viktig at VDK-utstyret er mye enklere enn PRK-utstyret. Den mest utbredte bruken av VRM finnes i digitale systemer med PCM.
9) Ruting: statisk og dynamisk på eksemplet med RIP, OSPF og EIGRP.
10) Oversettelse av nettverksadresser: NAT og PAT.
11) Reservasjonsprotokoller for første hopp: FHRP.
12) Datanettverkssikkerhet og virtuelle private nettverk: VPN.
13) Globale nettverk og protokoller som brukes: PPP, HDLC, Frame Relay.
14) Introduksjon til IPv6, konfigurasjon og ruting.
15) Nettverksadministrasjon og nettverksovervåking.
P.S. Kanskje vil listen bli supplert over tid.
Som du husker, har jeg allerede sagt at i nettverk er det viktig å strengt følge alle reglene for korrekt drift. Nemlig prosessen med innkapsling og de-innkapsling. Derfor, da vi snakket om øvre lags protokoller i forrige artikkel, nevnte jeg tilfeldig noen nedre lags protokoller, da de hele tiden krøp ut og minnet om seg selv. La meg forklare hvorfor. Ta en titt på bildet over nå. Slik fungerer e-post. Ta en titt på de to skallete gutta ovenfor som skrev brevet og stråler av lykke. Men det vil ikke være noen mening i brevet hvis adressaten ikke ser det. For å gjøre dette vil de bruke postvesenet. Brevet deres vil bli mottatt av en postkontoransatt og lagt i en konvolutt. Hun vil signere konvolutten slik at det er tydelig fra hvem og til hvem. Deretter henter budet dette brevet og tar det med til sorteringssenteret. Nedenfor er en bonde med lue og forkle som sjonglerer med bokstaver. Han vet hvor han skal legge brevet slik at det når adressaten. Og helt nederst ligger et tog, som er et transportknutepunkt. Merk at alles rolle er viktig her for vellykket sending og levering av brevet.
I nettverk er alt det samme. Du bestemte deg for å gå til nettstedet og lese nyhetene. Skriv inn nettadressen i nettleserlinjen. Da bør datamaskinen din spørre etter disse sidene. Og da vil lavere protokoller komme til unnsetning, som er et transportknutepunkt. Her kan hvert nivå sammenlignes med de ovenfor beskrevne personlighetene på bildet.
Jeg vil bringe all denne gimmicken til en fellesnevner og dele et eksempel som jeg en gang utledet for meg selv. Du har en nettverksendepunktsenhet. Det spiller ingen rolle en datamaskin, bærbar PC, nettbrett, smarttelefon eller noe annet. Hver av disse enhetene opererer over TCP/IP-stakken. Dette betyr at den overholder reglene.
1) Søknadsnivå. Det er her selve nettverksapplikasjonen fungerer. Det vil si en nettleser som for eksempel startes fra en datamaskin.
2) Transportlag. En applikasjon eller tjeneste må ha en port som den lytter på og som den kan kontaktes over.
3) Nettverkslag. IP-adressen er tilstede her. Det kalles også den logiske adressen til en enhet på nettverket. Ved hjelp av den kan du kontakte datamaskinen som nettopp denne nettleseren kjører på, noe som betyr at du kan nå selve applikasjonen. Med denne adressen er han medlem av nettverket og kan kommunisere med andre deltakere
4) Linklag. Dette er selve nettverkskortet eller antennen. Det vil si en sender og en mottaker. Den har en fysisk adresse for å identifisere dette nettverkskortet. Her hører også kabler, kontakter til. Det er miljøet som kobler datamaskinen til andre deltakere.
La oss starte på det laveste nivået. Dette er datalinken og det fysiske laget, hvis sett fra synspunktet til OSI-modellen, og tilgangslaget, hvis sett fra toppen av TCP/IP-protokollstabelen. Vi bruker TCP / IP, så jeg vil snakke fra hennes synspunkt. Tilgangslaget, som du forsto, kombinerer det fysiske og datalinklaget.
Fysisk lag. Eller som de liker å kalle det «elektrisk nivå». Spesifiserer parameterne til signalet, samt hva slags type og form signalet har. Hvis for eksempel Ethernet brukes (som overfører data ved hjelp av en ledning), hva er da modulasjon, spenning, strøm. Hvis det er Wi-Fi, hvilke radiobølger, frekvens, amplitude som skal brukes. Dette nivået inkluderer nettverkskort, Wi-Fi-antenner, kontakter. På dette nivået introduseres begrepet bits. Det er en måleenhet for overført informasjon.
Linklag. Dette nivået brukes til å formidle ikke bare biter, men meningsfulle sekvenser av disse bitene. Brukes for dataoverføring i én kanalmiljø. Hva dette betyr, skal jeg beskrive litt senere. MAC-adresser, også kalt fysiske adresser, fungerer på dette nivået.
Begrepet "fysiske adresser" ble introdusert av en grunn. Hvert nettverkskort eller antenne har en innebygd adresse, som er tildelt av produsenten. I forrige artikkel nevnte jeg begrepet "protokoller". Bare der var de protokoller på toppnivå, eller mer presist, den anvendte. På datalinknivå fungerer deres egne protokoller og antallet er ikke lite. De mest populære er Ethernet (brukes på lokale nettverk), PPP og HDLC (brukes på wide area-nettverk). Dette er absolutt ikke alt, men Cisco vurderer bare dem i sin CCNA-sertifisering.
Det er vanskelig å forstå alt dette i form av en solid tørr tekst, så jeg skal forklare det på bildet.
Glem IP-adresser, OSI-modellen og TCP/IP-protokollstakken for nå. Du har 4 datamaskiner og en bryter. Ikke vær oppmerksom på bryteren, da det er en vanlig boks for tilkobling av datamaskiner. Hver datamaskin har sin egen MAC-adresse som identifiserer den på nettverket. Det må være unikt. Selv om jeg presenterte dem som 3-sifret, er dette langt fra tilfelle. Nå er dette bildet kun for logisk forståelse, men jeg vil skrive nedenfor hvordan det fungerer i det virkelige liv.
Så. Hvis en av datamaskinene ønsker å sende noe til en annen datamaskin, trenger han bare å vite MAC-adressen til datamaskinen han sender til. Hvis den øvre venstre datamaskinen med en MAC-adresse på 111 ønsker å sende noe til den nedre høyre datamaskinen, vil den sende det uten problemer hvis den vet at mottakeren har en MAC-adresse på 444.
Disse 4 datamaskinene danner et enkelt lokalt nettverk og én kanalmiljø. Derav navnet på nivået. Men for riktig drift av noder i TCP / IP-nettverk er adressering på koblingsnivå ikke nok. Også viktig er adressering på nettverksnivå, som er kjent for alle som IP-adressering.
La oss nå huske på IP-adresser. Og tilordne dem til datamaskinene våre.
Jeg tildelte adressene symbolsk for å forstå på et grunnleggende nivå hvordan de fungerer. Disse to adresseringene (kanal og nettverk) jobber tett sammen og kan ikke fungere hver for seg. La meg forklare hvorfor. I vårt daglige liv jobber vi kun med IP-adresser eller navn, som var et helt kapittel om i forrige artikkel. Vi jobber faktisk ikke med MAC-adresser. Selve datamaskinene jobber med dem. Nå skal jeg simulere situasjonen. Jeg sitter ved øvre venstre datamaskin med IP: 1.1.1.1 og MAC: 111. Jeg ønsket å kontakte den nedre høyre datamaskinen og sjekke om den er i live eller ikke. Jeg kan kontakte ham hvis jeg vet IP-adressen hans. MAC-adressen er ikke interessant for meg. Jeg vet at IP-adressen hans er 1.1.1.4. Og jeg bestemmer meg for å bruke ping-verktøyet (verktøy for å sjekke tilgjengeligheten til en node).
Nå til det viktige. Datamaskinen innser at den ikke kjenner MAC-adressen til datamaskinen som må sjekkes for tilgjengelighet. For å finne ut MAC-adressen ved IP-adressen, kom de opp med ARP-protokollen. Jeg vil skrive om det i detalj senere. Nå vil jeg at du skal forstå avhengighetene mellom MAC-adresse og IP-adresse. Så han begynner å rope til hele nettverket: "Hvem er 1.1.1.4." Dette ropet vil bli hørt av alle nettverksdeltakere, og hvis det er en node som har en gitt IP-adresse, vil den svare. Jeg har en slik datamaskin, og som svar på dette ropet vil han svare: "1.1.1.4 er meg. Min MAC er 444". Datamaskinen min vil motta denne meldingen og vil kunne fortsette det jeg fortalte den.
Deretter må du lære hvordan du skiller ett subnett fra et annet. Og som datamaskinen forstår, er den på samme subnett med en annen node eller i forskjellige. For dette kommer subnettmasken til unnsetning. Det er mange masker og til å begynne med virker det skummelt, men jeg forsikrer deg om at det bare virker slik i begynnelsen. En hel artikkel vil bli viet til henne, og der vil du lære alle hennes hemmeligheter. På dette stadiet skal jeg vise deg hvordan det fungerer.
Hvis du noen gang har kommet inn i innstillingene til nettverkskort eller registrert en statisk adresse som leverandøren fortalte deg, så du feltet "nettverksmaske". Den er skrevet i samme format som IP-adressen, standard gateway og DNS. Dette er fire oktetter atskilt med punktum. Hvis du aldri har sett dette, kan du åpne en ledetekst og skrive ipconfig i den. Du vil se noe lignende.
Dette er et skjermbilde fra kommandolinjen på den bærbare datamaskinen min. Jeg sitter ved et hotspot hjemme, som har en maske på 255.255.255.0. Dette er sannsynligvis den enkleste masken å forklare, og mest sannsynlig har du den nøyaktig den samme. Hva er poenget. De første 3 oktettene (de er faste) viser nettverksadressen, og den 4. oktetten (den er dynamisk) viser vertsadressen. Med andre ord indikerer denne masken at du må sjekke de første 3 oktettene fullstendig, og den fjerde kan være fri fra 0 - 255. Generelt er dette en grov formulering. For med en slik maske vil de være fri fra 1 til 254, hvor 0 vil gå under nettverksadressen, og 255 under kringkastingsadressen. Men i alle fall er dette grensen for ett kanalmiljø. Det vil si at når en node trenger å sende en melding til en annen node, tar den adressen sin og pålegger den en maske, og hvis nettverksadressen (fast del) konvergerer med adressen, så er de i samme kanalmiljø. Jeg vil forklare det ved å bruke eksempelet på det samme bildet.
Jeg sitter ved den øvre venstre datamaskinen og vil sende den til den nedre høyre. Jeg kjenner både IP-adressen og MAC-adressen. Jeg må forstå om vi er i samme kanalmiljø eller ikke. Adressen er 1.1.1.4 og masken er 255.255.255.0. Masken forteller meg at 3 oktetter er faste og ikke bør endres, og den fjerde kan være alt i området fra 1 til 254. Jeg legger en maske på adressen hans og adressen min og ser treff og forskjeller.
Området som har ansvaret for nettverket er markert med rødt. Som du kan se, er det det samme for 2 verter. Dette betyr at de er på samme subnett.
Jeg skal modernisere nettverket og vise deg det litt annerledes.
En rund enhet ble lagt til. Det kalles en ruter eller ruter. Ordet er kjent for alle. Hovedrollen er å koble til nettverk og velge den beste ruten, som vil bli diskutert mer detaljert senere. Og lagt til, til høyre, en bryter, som 2 datamaskiner er koblet til. Masken for alle enheter er ikke endret (255.255.255.0).
Se nøye på adressene til alle enhetene. Du vil kanskje legge merke til at den tredje oktetten er forskjellig for de nye nodene og de gamle. La oss håndtere dette. Jeg sitter også ved en datamaskin med MAC: 111 og IP: 1.1.1.1. Jeg ønsker å sende informasjon til en av de nye nodene. La oss si at dette er datamaskinen øverst til høyre med MAC: 555 og IP: 1.1.2.1. Jeg tar på meg en maske og ser.
Og her er et annet bilde. De 3. oktettene er forskjellige, noe som betyr at nodene er i forskjellige nettverk (mer korrekt, subnett). For å løse slike situasjoner er det en standard gateway i innstillingene til hvert operativsystem. Det kalles også «gateway of last resort». Den brukes akkurat når du trenger å sende informasjon til en node i et annet kanalmiljø. For datamaskinen min er gateway-adressen 1.1.1.254. Og for datamaskinen jeg sender data til 1.1.2.254. Logikken bak dette er enkel. Hvis en node i ett kanalmiljø mottok informasjon direkte, vil banen gå gjennom en ruter for en node i et annet kanalmiljø.
Datamaskinen min vet at gateway-adressen er 1.1.1.254. Han vil rope til hele nettverket: "Svar 1.1.1.254." Denne meldingen vil mottas av alle deltakere i kanalmiljøet, men kun den som sitter bak denne adressen vil svare. Det vil si en ruter. Han vil sende et svar, og først etter det vil datamaskinen min sende dataene til adressen 1.1.2.254. Og vær oppmerksom. På datalinklaget sendes data til MAC: 777, og på nettverksnivå til IP: 1.1.2.1. Dette betyr at MAC-adressen bare overføres i kanalmiljøet, og nettverksadressen endres ikke langs hele banen. Når ruteren mottar informasjonen vil den forstå at den var ment for den på lenkenivå, men når den ser IP-adressen vil den forstå at det er en mellomkobling og må overføres til et annet kanalmiljø. Den andre porten ser til riktig subnett. Det betyr at alt kom til ham riktig. Men han vet ikke destinasjons-MAC-adressen. Han begynner å rope på samme måte til hele nettverket: "Hvem er 1.1.2.1?" Og en datamaskin med en MAC-adresse på 555 svarer på det. Jeg tror logikken i arbeidet er klar.
Gjennom de to foregående artiklene og den nåværende ble begrepet nevnt mange ganger "MAC-adresse"... La oss ta en titt på hva det er.
Som jeg sa før, er dette en unik identifikator for en nettverksenhet. Det er unikt og bør ikke gjentas noe sted. Den består av 48 biter, hvorav de første 24 bitene er en unik identifikator for organisasjonen, som er tildelt av IEEE-komiteen (Institute of Electrical and Electronics Engineers). Og de andre 24 bitene tildeles av maskinvareprodusenten. Det ser slik ut.
De skriver det ned på forskjellige måter. For eksempel:
1) 00-50-56-C0-00-08
2) 00: 50: 56: C0: 00: 08
3) 0050.56С0.0008
Som du kan se, kan samme adresse skrives på forskjellige måter. Likevel er det vanligvis ikke delt, men tatt opp sammen. Det viktigste å vite er at MAC-adressen alltid består av 48 biter og består av 12 bokstaver og/eller tall. Du kan se det på forskjellige måter. For eksempel, på Windows, åpne en ledetekst og skriv inn ipconfig / all. Mange produsenter skriver det fortsatt på esken eller på baksiden av enheten.
Så du kan se på Wi-Fi-hotspotet ditt og se et lignende opptak. Helt i begynnelsen viste jeg MAC-adressene i 3-sifrede tall, noe som ikke stemmer. I den sammenheng brukte jeg dem kun for å forenkle forklaringen, for ikke å forvirre deg med lange uforståelige notater. Nedenfor, når det kommer til praksis, vil du se dem slik de virkelig er.
Når vi har analysert adressen på lenkelaget, er det på tide å demontere protokollen som fungerer på dette laget. Den mest populære protokollen som for tiden brukes i lokale nettverk er Ethernet... IEEE beskrev det med 802.3-standarden. Så alle versjoner som starter med 802.3 refererer til den. For eksempel er 802.3z GigabitEthernet over fiber; 1 Gbps, og 802.3af er Power over Ethernet (PoE).
Jeg nevnte forresten ikke organisasjonen IEEE (Institute of Electrical and Electronics Engineers)... Denne organisasjonen utvikler standarder for alt relatert til elektronikk og elektroteknikk. På nettsiden deres kan du finne mye dokumentasjon på eksisterende teknologier. Dette er hva de gir ut på forespørsel "Ethernet"
La oss ta en titt på hva den består av. Siden selve protokollen er gammel (oppfunnet i 1973), har den blitt modernisert mange ganger og endret format. Du kan finne alle variantene på Internett, men jeg vil gi den som Cisco ga da jeg studerte.
1) Innledning. Feltet som brukes til å indikere starten på rammen. Altså slik at mottakeren kan forstå hvor begynnelsen på den nye rammen er. Tidligere, når en delt busstopologi ble brukt og det var kollisjoner, bidro ingressen til å forhindre kollisjoner.
2) Mottakers MAC-adresse. Feltet hvor mottakerens adresse er skrevet.
3) Avsender MAC-adresse. Følgelig registreres avsenderens adresse her.
4) Type (lengde). Dette feltet angir den overordnede protokollen. For IPv4 er det 0x0800, for ARP er det 0x0806, og for IPv6 er det 0x86DD. I noen tilfeller kan lengden på datafeltet til rammen (det neste feltet i overskriften) skrives her.
5) SNAP / LLC-felt + data. Dette feltet inneholder data mottatt fra høyere nivåer (eller nyttelast).
6) FCS (Frame Check Sequence). Feltet der sjekksummen beregnes. Ut fra det forstår mottakeren om rammen er ødelagt eller ikke.
I løpet av denne skrivingen og påfølgende vil andre koblingslagsprotokoller bli berørt. Så langt er ovenstående nok til å forstå arbeidet.
Vi går over til nettverksnivå, og her møtes vi av den oppsiktsvekkende IP-protokollen. Siden vi snakker om nettverkslaget, betyr det at protokollen som opererer på dette nivået på en eller annen måte må kunne overføre data fra ett kanalmedium til et annet. Men først, la oss se hva slags protokoll det er og hva den består av.
IP (fra den engelske Internett-protokollen). En protokoll fra TCP/IP-familien som ble utviklet på 80-tallet. Som jeg sa tidligere, brukes den til å koble separate datanettverk med hverandre. Også dens viktige funksjon er adressering, som kalles
IP adresse... For øyeblikket er det 2 versjoner av protokollen: IPv4 og IPv6. Noen få ord om dem:
1) IPv4. Bruker 32-biters adresser, som er skrevet i formatet med fire desimaltall (fra 0 til 255), atskilt med prikker. For eksempel er adressen 192.168.0.4. Hvert tall atskilt med prikker kalles en oktett. Dette er den mest populære versjonen til dags dato.
2) IPv6. Bruker 128-biters adresser, som er skrevet i formatet med åtte firesifrede heksadesimale tall (0 til F). For eksempel adresse 2001: 0db8: 11a3: 09d7: 1f34: 8a2e: 07a0: 765d. Hvert tall atskilt med prikker kalles en hektett. Ved begynnelsen av universell databehandling oppsto et problem. IP-adresser begynte å gå tom og det var behov for en ny protokoll som kunne gi flere adresser. Slik dukket IPv6-protokollen ut i 1996. Men takket være NAT-teknologi, som vil bli diskutert senere, ble problemet med mangel på adresser delvis løst, og i denne forbindelse har innføringen av IPv6 blitt forsinket til i dag.
Jeg synes det er klart at begge versjonene er ment for samme formål. Denne artikkelen tar en titt på IPv4-protokollen. Det vil bli skrevet en egen artikkel om IPv6.
Så, IP-protokollen fungerer med en blokk med informasjon, som vanligvis kalles en IP-pakke. La oss vurdere strukturen.
1) Versjon. IPv4- eller IPv6-protokoll.
2) IHL (fra engelsk Internet Header Length - størrelsen på overskriften). Siden mange av feltene som vises på bildet ikke er faste, beregner dette feltet størrelsen på overskriften.
3) Type tjeneste. Betjener størrelsen på QoS (Quality of Service)-køene. Den gjør dette ved å bruke en byte som indikerer et visst sett med kriterier (krav til latens, båndbredde, pålitelighet, etc.)
4) Pakkelengde. Pakkestørrelse. Hvis IHL er kun ansvarlig for størrelsen på feltene i overskriften (overskriften er alle feltene i bildet, bortsett fra datafeltet), da er lengden på pakken ansvarlig for hele pakken som helhet, inkludert brukerdata.
5) Time to Live (TTL- Time To Live). Feltet som brukes for å forhindre at pakken pakkes rundt. Når den passerer gjennom ruteren, synker verdien med én, og når den når null, blir pakken droppet.
6) Protokoll. For hvilken overordnet protokoll denne pakken er beregnet på (TCP, UDP).
7) Overskriftssjekksum. Integriteten til overskriftsfeltene vurderes her. Ikke data! Dataene kontrolleres av det tilsvarende feltet på datalinklaget.
8) Alternativer. Dette feltet brukes til å utvide standard IP-header. Det brukes sjelden i kjente nettverk. Det er her data skrives for noe spesifikt utstyr som leser dette feltet. For eksempel et dørlåskontrollsystem (hvor kommunikasjon med kontrolleren foregår), smarthusteknologi, internettting og så videre. Kjente nettverksenheter som rutere og svitsjer vil ignorere dette feltet.
9) Offset. Angir hvor fragmentet tilhører i den opprinnelige IP-adressen. Denne verdien er alltid et multiplum av åtte byte.
10) Data. Det er her dataene mottatt fra de høyere nivåene finnes. Ovenfor viste jeg at det også er et datafelt i Ethernet-rammen. Og den gitte IP-pakken vil bli inkludert i datafeltet. Det er viktig å huske at den maksimale størrelsen på en Ethernet-ramme er 1500 byte, men størrelsen på en IP-pakke kan være 20 KB. Følgelig vil ikke hele pakken passe inn i datafeltet til Ethernet-rammen. Derfor deles pakken og sendes i deler. Og til dette brukes de 3 feltene nedenfor.
11) Identifikator. Dette er et tall på 4 byte som indikerer at alle deler av den delte pakken er én enkelt helhet.
12) Flagg. Indikerer at dette ikke er en enkelt pakke, men en fragmentert pakke.
13) Fragmentoffset. Offset i forhold til det første fragmentet. Det vil si at dette er en nummerering som vil bidra til å sette sammen IP-pakken.
14) IP-adressen til avsenderen og IP-adressen til mottakeren. Følgelig indikerer disse 2 feltene fra hvem og for hvem pakken er.
Slik ser en IP-pakke ut. Selvfølgelig, for nybegynnere, vil verdiene til mange felt virke ikke helt klare, men i fremtiden vil det passe inn i hodet. For eksempel: "Time to Live (TTL)"-feltet. Arbeidet vil bli tydelig når du forstår hvordan ruting fungerer. Jeg kan gi råd, som jeg selv bruker. Hvis du ser et uforståelig begrep, skriv det ned separat, og hvis du har ledig tid, prøv å finne det ut. Hvis det ikke kommer inn i hodet ditt, så utsett det og gå tilbake til å studere det litt senere. Det viktigste er å ikke kaste det og til slutt gjøre det ferdig.
Det siste laget av TCP/IP-stakken gjenstår. den transportlag... Noen få ord om ham. Den er designet for å levere data til en spesifikk applikasjon, som den identifiserer med portnummeret. Avhengig av protokollen utfører den forskjellige oppgaver. For eksempel filfragmentering, leveringskontroll, multipleksing og håndtering av datastrømmer. De to mest kjente transportlagsprotokollene er UDP og TCP. La oss snakke om hver av dem mer detaljert, og jeg starter med UDP, på grunn av dens enkelhet. Vel, av tradisjon viser jeg hva den består av.
1) Kildeport. Porten som brukes av klienten eller serveren for å identifisere tjenesten. Et svar vil bli sendt til denne porten om nødvendig.
2) Destinasjonshavn. Porten som skal være destinasjonen spesifiseres her. For eksempel, hvis en klient ber om en nettside, vil målporten som standard være 80. (HTTP-protokoll).
3) UDP-lengde. UDP-hodelengde. Størrelsen varierer fra 8 til 65535 byte.
4) UDP-sjekksum. Integritetssjekk. Hvis den brytes, forkaster den den ganske enkelt uten å be om å sende den på nytt.
5) Data. Dataene fra toppnivået er pakket her. For eksempel, når en webserver svarer på en klientforespørsel og sender en nettside, vil den ligge i dette feltet.
Som du kan se, har den ikke så mange felt. Dens oppgave er å nummerere portene og sjekke om rammen er ødelagt eller ikke. Protokollen er enkel og ikke ressurskrevende. Den kan imidlertid ikke gi leveringskontroll og be om ødelagte deler av informasjon på nytt. Velkjente tjenester som fungerer med denne protokollen er DHCP, TFTP. De ble vurdert i artikkelen da toppnivåprotokollene ble behandlet.
Går videre til en mer kompleks protokoll. Vi møter TCP-protokollen. Vi ser på hva den består av og går gjennom hvert felt.
1) Kildeport og destinasjonsport. De utfører de samme rollene som i UDP, nemlig portnummerering.
2) Serienummer. Tallet som brukes slik at det på den andre siden er tydelig hva dette segmentet er på kontoen.
3) Bekreftelsesnummer. Dette feltet brukes når levering venter eller levering er bekreftet. ACK-parameteren brukes til dette.
4) Lengden på toppteksten. Den brukes til å forstå hvilken størrelse TCP-headeren har (dette er alle feltene vist på bildet ovenfor, bortsett fra datafeltet), og hvilken størrelse dataene har.
5) Reservert flagg. Verdien av dette feltet må settes til null. Den er forbeholdt spesielle behov. For eksempel for å rapportere nettverksbelastning.
6) Flagg. Spesielle biter settes i dette feltet for å etablere eller avslutte en økt.
7) Vindusstørrelse. Et felt som angir hvor mange segmenter som skal bekreftes. Sannsynligvis har hver og en av dere sett et slikt bilde. Du laster ned en fil og ser nedlastingshastighet og tid. Og så viser han først at det er 30 minutter igjen, og etter 2-3 sekunder allerede 20 minutter. Etter ytterligere 5 sekunder viser den 10 minutter og så videre. Dette er størrelsen på vinduet. Først er vinduet dimensjonert for å motta flere bekreftelser for hvert segment som sendes. Da går alt bra og nettverket svikter ikke. Vindustørrelsen endres og flere segmenter overføres og krever derfor færre leveringsrapporter. Dermed går nedlastingen raskere. Så snart nettverket svikter kort og et segment kommer slått, vil størrelsen endres igjen og flere leveringsrapporter vil kreves. Dette er essensen av dette feltet.
8) TCP-sjekksum. Kontrollerer integriteten til TCP-segmentet.
9) Betydningsindeks. Dette er forskyvningen av den siste viktige dataoktetten i forhold til SEQ for pakker med URG-flagget satt. I det virkelige liv brukes det når det er nødvendig å kontrollere flyten eller tilstanden til protokollen på øverste nivå fra avsenderagenten (for eksempel hvis mottakeragenten indirekte kan signalisere til avsenderagenten at den ikke kan takle dataene strømme).
10) Alternativer. Brukes for avanserte eller ekstra parametere. For eksempel for tidsstempelparameteren, som er en slags etikett som viser tidspunktet for hendelsen som skjedde.
11) Data. Nesten det samme som i UDP-protokollen. Data fra et høyere nivå er innkapslet her.
Vi så strukturen til TCP-protokollen og avsluttet samtidig samtalen om transportlaget. Det viste seg en så kort teori om protokollene som fungerer på de lavere nivåene. Jeg prøvde å forklare det så enkelt som mulig. Nå skal vi prøve det hele i praksis og avslutte et par spørsmål.
Jeg åpner opp CPT og setter sammen en krets som ligner på et av bildene ovenfor.
Her ser vi det første nettverket, bestående av 4 datamaskiner og en svitsj som forener disse datamaskinene. Og det andre nettverket, bestående av to datamaskiner og en svitsj. En ruter kobler sammen disse 2 nettverkene. La oss gå videre til å sette opp enheter og deretter simulere situasjonen som vi vurderte helt i begynnelsen av bildet.
Jeg åpner PC1 og skriver ned nettverksinnstillingene.
Jeg ble ikke så smart med adressen og brukte den enkleste, som hele tiden er foran øynene våre:
1) IP-adresse - 192.168.1.1
Vi vurderte denne masken ovenfor. La meg minne deg på at nettverksadressen til andre verter på samme lokale nettverk må være 192.168.1, og vertsadressen kan være fra 1 til 254.
Dette er adressen til ruteren som data skal sendes til for verter på et annet lokalt nettverk.
For at det ikke skal være mange bilder av samme type, vil jeg ikke gi skjermbilder av de andre 3 datamaskinene, men bare gi innstillingene deres.
PC2:
1) IP-adresse - 192.168.1.2
.
3) Hovedporten er 192.168.1.254.
PC3:
1) IP-adresse - 192.168.1.3
2) Nettverksmaske - 255.255.255.0.
3) Hovedporten er 192.168.1.254.
PC4:
1) IP-adresse - 192.168.1.4
2) Nettverksmaske - 255.255.255.0.
3) Hovedporten er 192.168.1.254.
La oss stoppe ved denne innstillingen for nå og se hvordan vårt lokale nettverk fungerer. Jeg satte CPT i simuleringsmodus. La oss si at jeg sitter ved PC1 og vil pinge PC4 for tilgjengelighet. Jeg åpner kommandolinjen på PC1.
Så snart jeg trykker ENTER, vises 2 konvolutter på diagrammet.
En av dem er ICMP, som selve ping-kommandoen fungerer med. Jeg åpner den umiddelbart og ser.
Jeg ser IP- og ICMP-data. Det er ikke noe interessant her bortsett fra noen få felt. Nemlig tallet 4 i øvre venstre hjørne av IP-dataene, som indikerer at IPv4-protokollen brukes. Og 2 felt med kilde- og destinasjons-IP-adresse (SRC: 192.168.1.1 og DST: 192.168.1.4).
Men her får ping et problem. Han kjenner ikke destinasjons-MAC-adressen. Det vil si lenkelagets adresse. For å gjøre dette bruker han ARP-protokollen, som kan forhøre nettverksdeltakere og finne ut MAC-adressen. Vi snakket om ham i forbifarten i forrige artikkel. La oss snakke om det mer detaljert. Jeg vil ikke endre tradisjoner. Bilde i studio!
1) Maskinvaretype. Jeg synes det fremgår tydelig av navnet at typen kanallag er angitt her. Så langt har vi kun sett på Ethernet. Betegnelsen i dette feltet er 0x0001.
2) Protokolltype. Her er på samme måte typen nettverkslag angitt. IPv4-koden er 0x0800.
3) Lengden på den fysiske adressen i byte (maskinvarelengde). Hvis det er en MAC-adresse, vil størrelsen være 6 byte (eller 48 biter).
4) Lengden på den logiske adressen i byte (Protokolllengde). Hvis det er en IPv4-adresse, vil størrelsen være 4 byte (eller 32 biter).
5) Driftskode. Avsender op-kode. Hvis dette er en forespørsel, er koden 0001. Ved svar - 0002.
6) Avsender maskinvareadresse. Avsender MAC-adresse.
7) Logisk avsenderadresse (avsenderprotokolladresse). Avsender IP-adresse.
8) Mål maskinvareadresse. Mottakers MAC-adresse. Hvis dette er en forespørsel, er adressen som regel ukjent og dette feltet står tomt.
9) Den logiske adressen til mottakeren (Target protocol address). Mottakers IP-adresse.
Nå som vi vet hva den er laget av, kan vi se på hvordan den fungerer i CPT. Jeg klikker på den andre konvolutten og ser følgende bilde.
Og her er ARP-protokollen i all sin prakt. På 2. nivå fungerer Ethernet-protokollen. La oss stoppe opp og se på feltene.
1) Innledning- her er en bitsekvens som snakker om begynnelsen av rammen.
2) Deretter kommer kilde- og destinasjons-MAC-adressene. Kildeadressen inneholder MAC-adressen til datamaskinen som er initiator, og destinasjonsadressen inneholder kringkastingsadressen FF-FF-FF-FF-FF-FF (det vil si for alle noder i kanalmiljøet).
3) Type - den overordnede protokollen er angitt her. Kode 0x806 betyr at ARP er høyere. For å være ærlig kan jeg ikke si sikkert på hvilket nivå det fungerer. Ulike kilder indikerer det forskjellig. Noen sier det på 2. OSI-nivå, og noen sier det på 3. nivå. Jeg tror det fungerer i mellom. Siden det er adresser som ligger i hvert av nivåene.
Jeg skal ikke snakke mye om dataene og sjekksummen. Dataene er ikke angitt her på noen måte, og sjekksummen er null.
Vi går opp litt høyere og her er protokollen ARP.
1) Maskinvaretype- lenkelagskode. CPT fjernet de ekstra nullene og satte inn 0x1 (samme som 0x0001). Det er Ethernet.
2) Protokolltype- nettverkslagskode. 0x800 er IPv4.
3) HLEN- lengden på den fysiske adressen. 0x6 betyr 6 byte. Det stemmer (MAC-adressen er 6 byte).
4) PLEN- lengden på nettverksadressen. 0x4 betyr 4 byte (IP-adressen er 4 byte).
5) OPCODE- operasjonskode. 0x1 betyr at dette er en forespørsel.
6) Kilde Mac- her er avsenderens MAC-adresse. Du kan sammenligne den med adressen i Ethernet-protokollfeltet og kontrollere at den er riktig.
7) Kilde IP- Avsenderens IP-adresse.
8) Mål MAC- siden dette er en forespørsel og kanaladressen ikke er kjent, er den tom. CPT viste det i nuller, som er det samme.
9) Mål-IP- Mottakerens IP-adresse. Dette er akkurat adressen vi pinger.
ARP spørre alle verter på det lokale nettverket, og bare én svarer på denne forespørselen. Dette er PC4. La oss se hvordan han svarer.
Her spytter han noe ut på bryteren. Jeg åpner den og ser noen endringer, nemlig:
1) Kildefeltet til Ethernet-protokollen inneholder nå MAC-adressen til PC4, og destinasjonsfeltet inneholder MAC-adressen til initiatoren, det vil si PC1.
2) OPCODE-feltet er nå 0x2, det vil si svaret.
3) Feltene for logiske og fysiske adresser i ARP-protokollen er endret. Source MAC og Destination MAC er de samme som i Ethernet. I Kilde-IP-feltet er adressen 192.168.1.4 (PC4), og i Destinasjons-IP-feltet adressen 192.168.1.1 (PC1).
Så snart denne informasjonen når PC1, danner den umiddelbart en ICMP-melding, det vil si ping.
Jeg åpner den og ser. Dette er en datablokk som består av tre protokoller: Ethernet, IP og Ping.
1) Det er ikke noe nytt i Ethernet-protokollen, nemlig kilde-MAC-adressen er PC1, destinasjons-MAC-adressen er PC4, og Type-feltet er 0x800 (IPv4-protokoll)
2) I IP-protokoll er Versjon-feltet 4, som betyr IPv4-protokoll. Senderens IP er PC1 og mottakerens IP er PC4.
3) I ICMP-protokollen, i Type-feltet - kode 0x8 (ekkoforespørsel).
Den sender en ekkoforespørsel, og jeg ser hvordan PC4 reagerer.
Jeg skjevde CPT og måtte starte den på nytt. Bare nå er ikke ICMP-konvolutten lysegrønn, men en blanding av grønn og blå. Men det gjør ingen forskjell. Dette er de samme dataene.
Vel, jeg ser hvordan PC4 reagerte. Kilde- og destinasjonsfeltene i Ethernet og IP er reversert. Og i Type-feltet til ICMP-protokollen endret verdiene seg fra 0x8 til 0x0 (betyr et ekkosvar).
Logisk, så snart dette svaret når PC1, bør en oppføring vises i PC1-konsollen. La oss sjekke.
Og faktisk. Det var en registrering av PC4-tilgjengelighet, datastørrelse (32 byte), tidsforsinkelse (8ms) og TTL eller time-to-live (128). TTL viser hvor mange rutere som har krysset pakken. Pakken min gikk innenfor det lokale nettverket, så dette feltet har ikke endret seg.
Som standard sender ping 4 forespørsler. Derfor vil PC1 danne 3 flere lignende ICMPer. Jeg vil ikke vise banen til hver pakke, men jeg vil gi den endelige konsollutgangen på PC1.
Og som du kan se, er det egentlig 4 svar. Merk at den første kom med en latens på 8ms, og de siste 3 kom med en latens på 4ms. Dette skyldes arbeidet med ARP-protokollen, siden PC1 først ikke visste MAC-adressen til PC4 og ventet på å bli informert. Selv om det i CPT er en situasjon at den første pakken vanligvis går tapt i sanntid. Dette gjelder spesielt når du sjekker tilgjengeligheten til en vert som befinner seg i et annet kanalmiljø.
Vi så hvordan dataoverføring fungerer i ett kanalmiljø. La oss nå se hva som skjer hvis vertene er i forskjellige kanalmiljøer eller undernett. La meg minne deg på at nettverket ikke er fullt konfigurert. Du må nemlig konfigurere ruteren og det andre undernettet. Hva skal vi gjøre nå.
Jeg åpner en datamaskin som heter PC5 og skriver ned nettverksinnstillingene.
Merk at nettverksadresseringen i det første koblingsmiljøet var 192.168.1.X, og i det andre var det 192.168.2.X. Med en maske på 255.255.255.0 betyr dette at de første 3 oktettene er faste, og den 4. oktetten er i området fra 1 til 254. Og siden våre 3. oktetter er forskjellige, er dette forskjellige kanalmiljøer.
Her er PC6-innstillingene:
1) IP-adresse - 192.168.2.2
2) Nettverksmaske - 255.255.255.0
3) Hovedporten - 192.168.2.254
Vertene i 2. kanalmiljøet er satt opp og fungerer fint. For at de skal kunne kommunisere med verter fra 1. kanal, må du konfigurere en ruter som kobler sammen disse miljøene. Ruteren konfigureres via CLI (det vil si i konsollformen) og det vil være lettere å bringe hit ikke skjermbilder, men kommandoer.
1) Ruter> aktiver - overgang til privilegert modus
2) Ruter # konfigurer terminal - bytt til global konfigurasjonsmodus
3) Ruter (config) #interface fastEthernet 0/0 - gå videre til innstilling av port 0/0, som ser på det første kanalmiljøet
4) Ruter (config-if) #ip-adresse 192.168.1.254 255.255.255.0 - vi henger en IP-adresse på denne porten. Siden denne porten vil være hovedporten for 1. kanalmiljøet, indikerer vi IP-en som ble tildelt vertene
5) Ruter (config-if) #ingen avslutning - slå på dette grensesnittet. Som standard er alle porter på cisc-rutere deaktivert
6) Ruter (config-if) #exit - gå ut av fastEthernet 0/0-oppsettmodus
7) Ruter (konfigurasjon) #grensesnitt fastEthernet 0/1 - gå videre til innstilling av port 0/1, som ser på det andre kanalmiljøet
8) Ruter (config-if) #ip-adresse 192.168.2.254 255.255.255.0 - vi henger adressen her, som vil være hovedporten for verter i 2. kanalmiljøet
9) Ruter (config-if) #ingen avslutning - aktivere det på samme måte
10) Ruter (config-if) #end - vi skriver en kommando som vil sette den i privilegert modus
11) Ruter # copy running-config startup-config - lagre innstillingene i ruterens minne
På dette stadiet er konfigurasjonen av ruteren fullført. Jeg skal løpe litt frem og vise den nyttige kommandoen "vis ip-rute". Den viser alle nettverk kjent for ruteren og ruten til dem.
Basert på denne tabellen kan du forsikre deg om at han kjenner til både 1. kanalmiljøet og det 2. kanalmiljøet. Fint. Det eneste som gjenstår er å sjekke tilgjengeligheten til PC5 fra PC1. Jeg prøver. Bytter CPT til simuleringsmodus. Jeg åpner kommandolinjen og pinger 192.168.2.1.
Så snart jeg trykker ENTER, vises 2 konvolutter på en gang: ICMP og ARP. La oss stoppe opp og se nærmere på dem. Nå kan det virke som om overføring mellom ulike kanalmiljøer ikke er forskjellig fra overføring i ett kanalmiljø, men dette er ikke tilfelle. Og nå vil du se det.
La oss først se på ICMP.
Så langt er det i prinsippet ikke noe interessant her. Kildefeltet er IP-adressen til PC1, og destinasjonsfeltet er IP-adressen til PC5.
Hva vil skje videre. PC1 ser at den sjekker tilgjengeligheten til en vert i et annet lenkemiljø (ved å maskere sin egen IP-adresse og destinasjons-IP-adressen). Og bortsett fra IP-adressen vet han ikke noe om mottakeren. Følgelig kan en ICMP-pakke ikke sendes i dette skjemaet. Men han vet at han har en hovedgateway, som mest sannsynlig vet noe om kanalmiljøet PC5 befinner seg i. Men en annen komplikasjon oppstår. Han kjenner IP-adressen til gatewayen (som jeg tilordnet ham i nettverksinnstillingene), men vet ikke MAC-adressen hans. Her kommer ARP-protokollen til unnsetning, som vil avhøre alle deltakere i kanalmiljøet og finne dens MAC-adresse. La oss se hvordan feltene fylles ut.
Ved koblingslaget (Ethernet-protokoll): Kildefeltet er MAC-adressen til PC1, og destinasjonsfeltet er kringkastingsadressen (det vil si til alle deltakere).
Og litt høyere (ARP-protokoll):
1) SOURCE MAC er den samme PC1, og DESTINATION MAC er tom (den må fylles ut av den som denne forespørselen er ment for).
2) SOURCE IP er PC1-adressen, men DESTINASJON IP er standard gateway-adresse.
3 datamaskiner droppet pakken og bare ruteren skjønte at det var for ham. La oss se hvordan han svarer.
Ethernet:
1) Kilde MAC - her setter den inn MAC-adressen sin (nemlig fastEthernet0 / 0 MAC-adressen).
2) Destinasjon MAC - skriver ned MAC-adressen til PC1 (det vil si den som ba om) her.
ARP:
1) Source MAC og Destination MAC ligner på oppføringer i Ethernet-protokollen.
2) Kilde-IP - din IP-adresse.
3) Mål-IP - PC1 IP-adresse.
Så snart ARP når PC1 fra ruteren, sender PC1 umiddelbart en ICMP-melding til ruteren (eller standard gateway). Og her ber jeg deg om å være spesielt oppmerksom. Nemlig til kilde- og destinasjonsfeltene (i både Ethernet og IP).
1) SRC MAC: Dette er MAC-adressen til PC1.
2) DEST MAC: Ruterens MAC-adresse.
3) SRC IP: PC1 IP-adresse.
4) DST IP: PC5 IP-adresse.
Hva betyr det. Adresser på nettverksnivå (det vil si IP-adresser) endres ikke slik at du vet hvem informasjonen er fra og til hvem. Og adressene på lenkelaget (MAC-adresser) kan enkelt endres ved å flytte fra ett lenkemedium til et annet. Det er veldig viktig å forstå og huske!
La oss se hva som skjer. Pakken kommer til ruteren og blir umiddelbart krysset over. Og alt på grunn av det faktum at han ikke kjenner MAC-adressen til PC5. Nå oppretter han en ARP-forespørsel og prøver å finne ut av det. Her er et skjermbilde av denne forespørselen.
Så snart dette svaret når ruteren, vil den kjenne PC5-koblingsadressen. Men her er hva som skjedde. Mens gimmicken med ARP trakk på ruteren og PC5, ble PC1 tidsavbrutt mens han ventet på svar sendt av ICMP. Jeg viser bildet.
Etter at tidsavbruddet utløper, genererer den en andre ICMP, hvis svar allerede vil bli mottatt uten problemer, siden MAC-adressene er kjente. Det vil da danne 3. og 4. ICMP. Her er det endelige resultatet.
Og hvis du ser nøye etter, vil du legge merke til at TTL har redusert med én og er nå lik 127. Dette skjedde på grunn av at pakken passerte én transittseksjon (ruter).
Slik fungerer dataoverføring fra ett kanalmedium til et annet (eller fra et nettverk til et annet). Her spiller det forresten ingen rolle hvor mange kanalmiljøer du må overvinne for å komme til mottakeren. Prinsippet vil fortsatt være slik.
I forrige artikkel, da vi så på protokollene for øvre lag, berørte vi litt transportlaget. Jeg foreslår å huske dette nivået og sikre det.
Jeg starter, som alltid, med en enkel en. Og det er UDP. Som jeg sa ovenfor, brukes den til å overføre data til en spesifikk protokoll på høyere nivå. Den gjør dette ved å bruke porter. En av protokollene som fungerer med UDP er TFTP (Trivial File Transfer Protocol). Vi vurderte denne protokollen i forrige artikkel. Derfor bør det ikke oppstå vanskeligheter. For denne demonstrasjonen må du legge til en TFTP-aktivert server til nettverket ditt.
Serverinnstillingene er som følger:
1) IP-adresse - 192.168.1.5
2) Nettverksmaske - 255.255.255.0
3) Hovedporten - 192.168.1.254
TFTP-tjenesten er aktivert som standard, men det er best å sjekke. Deretter bytter jeg CPT til simuleringsmodus og prøver å lagre ruterkonfigurasjonen til TFTP-serveren:
1) Ruter> aktiver - overgang til privilegert modus.
2) Ruter # copy startup-config tftp: - Jeg skriver kommandoen kopi (det vil si kopiere), deretter startup-config (nøyaktig hva som skal kopieres) og tftp: (hvor skal kopieres).
3) Adresse eller navn på ekstern vert? 192.168.1.5 - en melding kommer ut som ber om adressen eller navnet på serveren, hvor jeg skriver adressen.
4) Destinasjonsfilnavn? - så spør han, under hvilket navn han skal lagre det på serveren og tilbyr et standardnavn. Dette passer meg, og jeg trykker ENTER.
Ruteren danner to konvolutter på en gang. Den ene er krysset over TFTP og den andre er ARP. Jeg tror de gjettet at den ble krysset ut fordi den ikke kjenner MAC-adressen til serveren.
Jeg vil hoppe over øyeblikket med ARP-arbeid, siden vi har sett nok av det.
La oss se nærmere på hva ruteren sender til serveren.
Ethernet:
1) Kilde MAC - ruteradresse.
2) Destinasjon MAC - serveradresse.
3) Type - 0x800 (betyr at IP-protokollen fungerer ovenfor).
IP:
1) Protokoll - 0x11 (betyr at UDP-protokollen fungerer ovenfor).
2) Kilde IP - ruteradresse.
3) Destinasjons-IP - serveradresse.
UDP:
1) Kildeport - dynamisk opprettet port (1025).
2) Destinasjonsport - porten som TFTP-serveren lytter til (reservert port 69).
TFTP:
Det er her selve dataene er.
Slik fungerer UDP. Den etablerer ikke økter, krever ikke bekreftelse på levering, og hvis noe går tapt, spør den ikke igjen. Dens jobb er å spesifisere portnummeret og sende. Han er ikke interessert i hva som vil skje videre. Men det er tilfeller når dette ikke passer deg, og alle disse parametrene er kritisk viktige. Så kommer TCP til unnsetning. La oss vurdere det ved å bruke et eksempel på bruk av en webserver og en webklient. Vi vil ha samme TFTP-server som en webserver. Slå på HTTP-tjenesten og be om en side fra PC1. Ikke glem å bytte CPT til simuleringsmodus!
Jeg skriver inn adressen til webserveren og trykker ENTER.
Før jeg fortsetter, vil jeg snakke om å etablere en TCP-sesjon. Jeg vil prøve å presentere denne prosessen så enkelt som mulig. Denne prosessen kalles et "treveis håndtrykk" eller "håndtrykk". Hva er poenget. Klienten sender et TCP-segment med SYN-flagget. Etter å ha mottatt segmentet, tar serveren en avgjørelse. Hvis han godtar å etablere en forbindelse, sender han et svarsegment med "SYN + ACK"-flagget. Hvis du ikke er enig, sender den segmentet med "RST"-flagget. Deretter ser klienten på responssegmentet. Hvis "SYN + ACK"-flagget er der, sender det som svar et segment med "ACK"-flagget og en forbindelse er etablert. Hvis "RST"-flagget er der, slutter det å prøve å koble til. Etter at den må bryte den etablerte forbindelsen, genererer og sender klienten et TCP-segment med "FIN + ACK"-flagget. Serveren svarer på dette segmentet med det samme "FIN + ACK"-flagget. Til slutt sender klienten det siste TCP-segmentet med "ACK"-flagget. Nå skal du se hvordan dette fungerer i praksis.
Jeg retter oppmerksomheten mot nettverket og ser hvordan PC1 danner et TCP-segment.
Jeg vil ikke vurdere feltene til Ethernet- og IP-protokollene, siden det ikke er noe nytt her, bortsett fra feltet Protokoll i IP-protokollen. Det er en verdi - 0x6. Dette antyder at TCP-protokollen er brukt ovenfor.
Men i TCP er det allerede mer interessant.
1) Kildeport - 1025 (dette er den dynamisk genererte webklientporten).
2) Destinasjonsport - 80 (dette er en reservert HTTP-port).
3) Flagg - SYN (forespørsel om å opprette en økt)
La oss se hvordan webserveren vil reagere.
Den bytter portnumrene og sender segmentet med "SYN + ACK"-flagget.
Så snart klienten mottar dette segmentet, danner han umiddelbart 2 meldinger. En av dem er TCP-segmentet nedenfor, som sendes med "ACK"-flagget.
Og den andre er HTTP, hvor protokollversjonen er angitt, hvilken side og serveradresse.
Arbeidet hans ble presentert i en tidligere artikkel. Derfor vil jeg ikke gjenta meg selv. Nå skal jeg vise deg avslutningen av økten.
Når klienten mottar ønsket side, gir det ikke lenger mening for ham å opprettholde forbindelsen og starter en pause. Sender et segment med FIN + ACK-flagget. Vi ser videre.
Serveren godtar å avslutte forbindelsen og sender som svar et segment med det samme "FIN + ACK"-flagget.
Til slutt genererer klienten det siste TCP-segmentet med "ACK"-flagget og lukker forbindelsen.
Vi så på hvordan TCP-protokollen fungerer, og med den endte vi opp med å se på de nedre lagprotokollene. Her er en lenke for å laste ned dette laboratoriet. Først hadde jeg ideen om å gå standardveien, og skrive en egen artikkel for hvert nivå, men så innså jeg at det var meningsløst å gjøre dette. Siden i skrivende stund den neste artikkelen, er det meste av den forrige glemt.
Vel, artikkelen nærmer seg slutten. Jeg vil uttrykke min takknemlighet til brukeren under kallenavnet remzalp for bildet som er gitt og til andre brukere som legger igjen nyttige kommentarer til artiklene. Det er veldig hyggelig å se hvordan folk er interessert, stiller spørsmål og engasjerer seg i objektive og konstruktive tvister. Jeg skulle ønske at det russisktalende IT-miljøet utviklet mer og mer og økte antall materiell for studier i fri tilgang. Takk for at du leste og se deg neste gang.
Linklag(Data Link Layer) definerer reglene for tilgang til det fysiske mediet og kontrollerer overføringen av informasjon gjennom kanalen, genererer et signal om starten av overføringen og organiserer begynnelsen og faktisk overføring av informasjon med opprettelsen av et signal for slutten av overføringen og påfølgende overføring av kanalen til en passiv tilstand. I overføringsprosessen blir den mottatte informasjonen kontrollert og feil korrigert, kanalen kobles fra i tilfelle funksjonsfeil, samt generering av meldinger om forekomsten av fatale feil for et høyere nivå med gjenoppretting av overføring etter reparasjon av utstyr. I noen tilfeller overvåker dette nivået valutakursen og slutten av informasjonsblokker, og kontrollerer også den fysiske kretsen når den multiplekses.
På det fysiske laget overføres biter ganske enkelt og det tar ikke hensyn til at det fysiske overføringsmediet kan være opptatt. Derfor er en av oppgavene til Data Link-laget å sjekke tilgjengeligheten til overføringsmediet. En annen oppgave for lenkelaget er å implementere feildeteksjons- og korrigeringsmekanismer. For å gjøre dette, ved datalinklaget, blir biter gruppert i sett kalt rammer. Koblingslaget sikrer riktigheten av overføringen av hver ramme ved å plassere en spesiell sekvens av biter i begynnelsen og slutten av hver ramme, for å trekke den ut, og beregner også kontrollsummen, behandler alle bytene i rammen på en bestemt måte, og legger til sjekksummen i rammen. Når en ramme kommer over nettverket, beregner mottakeren sjekksummen av de mottatte dataene igjen og sammenligner resultatet med sjekksummen fra rammen. Hvis de samsvarer, anses rammen som korrekt og akseptert. Hvis kontrollsummene ikke stemmer overens, registreres en feil. Koblingslaget kan ikke bare oppdage feil, men også rette dem ved å sende skadede rammer på nytt. Det skal bemerkes at feilrettingsfunksjonen for koblingslaget ikke er obligatorisk, derfor er den fraværende i noen protokoller for dette laget, for eksempel i Ethernet og rammerelé.
Dermed gir lenkelaget opprettelse, overføring og mottak av informasjonsblokker, konverterer en sekvens av bitstrømmer til sett med biter kalt datarammer, betjener forespørsler fra nettverkslaget og bruker den fysiske lagtjenesten for overføring og mottak av rammer. Opprinnelig ble dette nivået opprettet som et funksjonelt enhetlig nivå som løser følgende oppgaver:
Under overføring - den faktiske overføringen av datarammen fra nettverkslaget til det fysiske laget og sikre feilfri overføring over det fysiske laget av rammer fra ett system til et annet;
Ved mottak - omfordeling av umonterte biter fra det fysiske laget til rammer for høyere lag.
Linklagsfunksjoner er vanligvis implementert i programvare og maskinvare.
Over tid ble det nødvendig å dele datalinklaget inn i to underlag - Laget Logical Link Control (LLC) og Media Access Control (MAC) laget.
MAC-underlaget omhandler fysiske adresser kalt MAC-adresser . På Ethernet- og Token Ring-nettverk er MAC-adresser heksadesimale tall skrevet på NIC-brikken. En Ethernet MAC-adresse (noen ganger referert til som en Ethernet-adresse) er 12 heksadesimale sifre, hvor hvert par er atskilt med et kolon. Disse 12 heksadesimale sifrene representerer et 48 bit (eller 6 byte) binært tall. De tre første bytene inneholder produsentens kode tildelt av IEEE-organisasjonen. De tre siste bytene tildeles av produsenten. MAC-adressen, eller fysisk adresse, blir noen ganger referert til som enhetsadressen. Den skiller seg fra en logisk adresse, dvs. IP-adresser i TCP/IP-nettverket slik at det ikke kan endres. Den logiske adressen tildeles av programvaren og er veldig enkel å endre. Begge adressene brukes til å identifisere en datamaskin på nettverket.
LLC-underlaget definerer den logiske nettverkstopologien. Den samsvarer kanskje ikke med den fysiske topologien. LLC-underlaget er ansvarlig for kommunikasjonen (eller grensesnittet) mellom MAC-underlaget og det høyere nettverkslaget, og konverterer bitene og bytene som mottas fra MAC-laget til formatet som kreves av nettverksenhetene.
I lokale nettverk støttes koblingslagsprotokoller av broer, svitsjer og rutere. På datamaskiner implementeres lenkelagsfunksjoner i fellesskap av nettverkskort og deres drivere. Link-layer-protokollene som brukes i lokale nettverk har en viss struktur av forbindelser mellom datamaskiner og måter å adressere dem på. Selv om lenkelaget sørger for levering av en ramme mellom hvilke som helst to noder i det lokale nettverket, gjør det dette bare i et nettverk med en viss topologi av koblinger, akkurat den topologien det ble designet for. Vanlige buss-, ring- og stjernetopologier støttet av lenkelagsprotokoller i lokale nettverk inkluderer vanlige buss-, ring- og stjernetopologier, så vel som strukturer avledet fra dem ved bruk av broer og svitsjer. I alle disse konfigurasjonene har destinasjonsadressen en lokal betydning for det gitte nettverket og endres ikke når rammen går fra kildenoden til destinasjonsnoden. Muligheten til å overføre data mellom lokale nettverk med forskjellige teknologier skyldes det faktum at disse teknologiene bruker adresser i samme format; dessuten sikrer produsenter av nettverksadaptere unike adresser uavhengig av teknologi. Eksempler på koblingslagsprotokoller er Ethernet, Token Ring, FDDI, 100VG-AnyLAN.
I wide area-nettverk, dvs. I WAN-nettverk, som sjelden har en vanlig topologi, lar datalinklaget ofte meldinger kun utveksles mellom to nabodatamaskiner koblet sammen med en enkelt lenke. Eksempler på punkt-til-punkt-protokoller (som slike protokoller ofte kalles) er de mye brukte link-layer-protokollene PPP og LAP-B, som er ansvarlige for å levere en ramme til en umiddelbar nabo. Adressen i dette tilfellet har ingen grunnleggende betydning, og protokollens evne til å gjenopprette forvrengte og tapte rammer kommer i forgrunnen, siden den dårlige kvaliteten på territorielle kanaler, spesielt oppringte telefoner, ofte krever slike handlinger.
Dersom vilkårene ovenfor ikke er oppfylt, kan for eksempel forholdet mellom segmenter Ethernet har en sløyfe-lignende struktur, eller nettverkene som skal kobles til bruker forskjellige adresseringsmetoder, som i Ethernet og X.25-nettverk, da kan ikke linklagsprotokollen alene takle oppgaven med å overføre en ramme mellom noder og krever hjelp av en nettverkslagsprotokoll. Dette er hvordan X.25-nettverk er organisert. Når det er vanskelig å isolere lenkelagsfunksjoner i sin rene form i WAN-lagnettverk, kombineres de med nettverkslagsfunksjoner i samme protokoll. Eksempler på denne tilnærmingen er ATM- og rammereléprotokoller.
Datalinklaget bruker protokoller som den velkjente ISO High-level DataLink Conrol (HDLC)-protokollen for serielle tilkoblinger, ITU-T Link Access Procedures Balanced (LAPB), Link Access Procedures on the D-channel (LAPD) og Link Tilgang til protokoller. Prosedyrer til Frame Mode Bearer Services (LAPF), IEEE 802.2 LLC-protokoller (Type I og Type II) som gir MAC for 802.X LAN-miljøer, samt Ethernet-, Token-ring-, FDDI-, X.25- og FR-protokoller .
Generelt sett representerer datalinklaget et veldig kraftig og komplett sett med funksjoner for overføring av meldinger mellom nettverksnoder, som i noen tilfeller tillater arbeidet på toppen av det direkte applikasjonslagsprotokoller eller applikasjoner uten å involvere protokollene til nettverket og transport. lag. Ikke desto mindre, for å sikre høykvalitets transport av meldinger i nettverk av enhver topologi og teknologi, er ikke funksjonene til lenkelaget nok. For å gjøre dette, bør følgende to modelllag brukes i OSI-modellen - Nettverk og transportere.
