Før vi starter dagens videoopplæring, vil jeg takke alle som har bidratt til populariteten til kurset mitt på YouTube. Da jeg startet det for omtrent 8 måneder siden, forventet jeg ikke en slik suksess - i dag har leksjonene mine blitt sett av 312724 11208 personer, jeg har 7 6 abonnenter. Jeg hadde aldri drømt om at denne ydmyke begynnelsen skulle nå slike høyder. Men la oss ikke kaste bort tid og gå rett til dagens leksjon. I dag skal vi fylle hullene som oppsto i de siste 3 videoleksjonene. Selv om i dag bare er dag 3, ble dag XNUMX delt opp i XNUMX videotimer, så i dag vil du faktisk se den åttende videoleksjonen.
I dag skal vi dekke 3 viktige emner: DHCP, TCP-transport og de vanligste portnumrene. Vi har allerede snakket om IP-adresser, og en av de viktigste faktorene i IP-adressekonfigurasjon er DHCP.
DHCP står for Dynamic Host Configuration Protocol og det er en protokoll som bidrar til dynamisk konfigurering av IP-adresser for verter. Så vi har alle sett dette vinduet. Når du klikker på alternativet "Få en IP-adresse automatisk", ser datamaskinen etter en DHCP-server som er konfigurert på samme subnett og sender forskjellige pakker og forespørsler om IP-adressen. DHCP-protokollen har 6 meldinger, hvorav 4 er kritiske for å tildele en IP-adresse.
Den første meldingen er en DHCP DISCOVERY-melding. DHCP-oppdagingsmeldingen ligner på en hilsen. Når en ny enhet kobles til nettverket, spør den om det er en DHCP-server på nettverket.
Det du ser i lysbildet ser ut som en kringkastingsforespørsel der enheten kontakter alle enheter på nettverket på jakt etter en DHCP-server. Som sagt er dette en kringkastingsforespørsel, så alle enheter på nettverket kan høre den.
Hvis det er en DHCP-server på nettverket, sender den en pakke - et DHCP-TILBUD. Forslag betyr at DHCP-serveren, som svar på en oppdagelsesforespørsel, sender en konfigurasjon til klienten, og ber klienten om å godta en spesifikk IP-adresse.
DHCP-serveren reserverer en IP-adresse, i dette tilfellet 192.168.1.2, gir den ikke, men reserverer heller denne adressen for enheten. Samtidig inneholder tilbudspakken sin egen IP-adresse til DHCP-serveren.
Hvis det er mer enn én DHCP-server på dette nettverket, vil en annen DHCP-server, ved mottak av klientens kringkastingsforespørsel, også tilby den sin IP-adresse, for eksempel 192.168.1.50. Det er ikke vanlig å ha to forskjellige DHCP-servere konfigurert på samme nettverk, men noen ganger skjer det. Så når et DHCP-tilbud sendes til en klient, mottar den 2 DHCP-tilbud og må nå bestemme hvilket DHCP-tilbud den vil akseptere.
La oss anta at klienten godtar den første søknaden. Dette betyr at klienten sender en DHCP-REQUEST-forespørsel som bokstavelig talt sier "Jeg godtar IP-adressen 192.168.1.2 som tilbys av DHCP-serveren 192.168.1.1."
Etter å ha mottatt forespørselen, svarer 192.168.1.1 DHCP-serveren "ok, jeg innrømmer det," det vil si at den bekrefter forespørselen og sender denne DHCP ACK til klienten. Men vi husker at en annen DHCP-server har reservert en IP-adresse på 1.50 for klienten. Når den mottar en klients kringkastingsforespørsel, vil den vite om feilen og vil sette den IP-adressen tilbake i bassenget slik at den kan tilordne den til en annen klient hvis den mottar en ny forespørsel.
Dette er de 4 kritiske meldingene som DHCP utveksler ved tildeling av IP-adresser. Deretter har DHCP 2 flere informasjonsmeldinger. En informasjonsmelding utstedes av klienten hvis den krever mer informasjon enn den mottok i DHCP OFFER klausulen i andre trinn. Hvis serveren ikke ga nok informasjon i DHCP-tilbudet, eller hvis klienten trenger mer informasjon enn det som var inneholdt i tilbudspakken, ber den om ytterligere DHCP-informasjon. Det er en melding til som klienten sender til serveren - dette er DHCP RELEASE. Den informerer deg om at klienten ønsker å frigi sin eksisterende IP-adresse.
Det som imidlertid oftest skjer er at brukeren kobler seg fra nettverket før klienten rekker å sende en DHCP RELEASE til serveren. Dette skjer når du slår av datamaskinen, noe vi gjør. I dette tilfellet har nettverksklienten, eller datamaskinen, ganske enkelt ikke tid til å informere serveren om å frigi den brukte adressen, så DHCP RELEASE er ikke et nødvendig trinn. De nødvendige trinnene for å få en IP-adresse er: DHCP-oppdagelse, DHCP-tilbud, DHCP-forespørsel og DHCP-håndtrykk.
I en av de neste leksjonene vil jeg fortelle deg hvordan vi konfigurerer en DHCP-server når vi oppretter en DNCP-pool. Med pooling mener vi at du ber serveren om å tildele IP-adresser i området 192.168.1.1 til 192.168.1.254. Dermed vil DHCP-serveren opprette en pool, plassere 254 IP-adresser i den, og vil kun kunne tildele adresser til klienter på nettverket fra dette bassenget. Så dette er noe sånt som en administrativ innstilling som brukeren kan gjøre.
La oss nå se på TCP-overføring. Jeg vet ikke om du er kjent med "telefonen" som er avbildet på bildet, men da vi var barn brukte vi disse blikkboksene forbundet med en snor for å snakke med hverandre.
Dessverre har ikke dagens generasjon råd til slik "luksus". Jeg mener i dag er barn foran TV-en fra de er ett år, de spiller PSP og kanskje dette kan diskuteres, men jeg tror vi hadde den beste barndommen, vi gikk faktisk ut og spilte spill og dagens barn kan ikke trekkes vekk fra sofaen .
Sønnen min er bare ett år gammel og jeg kan allerede se at han er avhengig av iPad, jeg mener han er fortsatt veldig ung, men jeg tror at dagens barn allerede er født og vet hvordan de skal håndtere elektroniske dingser. Så jeg ville si at som barn, når vi lekte, ville vi lage hull i blikkbokser, og når vi bandt dem med en snor og sa noe i en boks, så kunne personen i den andre enden høre hva som ble sagt til ham, ganske enkelt ved å sette boksen mot øret hans. Så det er veldig likt en nettverkstilkobling.
I dag må selv TCP-overføringer ha en forbindelse som må etableres før selve dataoverføringen starter. Som vi diskuterte i tidligere leksjoner, er TCP tilkoblingsorientert overføring mens UDP er tilkoblingsorientert overføring. Du kan si at UDP er der jeg kaster ballen, og det er opp til deg å se om du kan fange den. Om du er klar til å gjøre det eller ikke er ikke mitt problem, jeg kommer bare til å forlate ham.
TCP er mer som at du snakker med en fyr og advarer ham på forhånd om at du skal kaste en ball, slik at du danner et bånd, og så kaster du ballen slik at partneren din er mer sannsynlig å være klar til å fange den. Så TCP bygger faktisk forbindelsen og begynner deretter å utføre selve overføringen.
La oss se på hvordan det skaper en slik forbindelse. Denne protokollen bruker et 3-veis håndtrykk for å opprette en forbindelse. Dette er ikke et veldig teknisk begrep, men det har lenge vært brukt for å beskrive en TCP-forbindelse. Et 3-veis håndtrykk initieres av avsenderenheten, hvor klienten sender en pakke med et SYN-flagg til serveren.
La oss si at jenta i forgrunnen, hvis ansikt vi kan se, er enhet A, og jenta i bakgrunnen, hvis ansikt ikke er synlig, er enhet B. Jente A sender en SYN-pakke til jente B, og hun sier: «flott, hvem- så vil han kommunisere med meg. Så jeg må svare at jeg er klar til å kommunisere!» Hvordan gjøre det? Man kan ganske enkelt sende tilbake en annen SYN-pakke og deretter en ACK som indikerer mottak av den originale SYN-pakken. Men i stedet for å sende ACK-er separat, danner serveren en felles pakke som inneholder SYN og ACK og overfører den over nettverket.
Så på dette tidspunktet har enhet A sendt en SYN-pakke og mottatt tilbake en SYN/ACK-pakke. Nå må enhet A sende enhet B en ACK-pakke, det vil si bekrefte at den har mottatt samtykke fra enhet B for å etablere kommunikasjon. Dermed mottok begge enhetene SYN- og ACK-pakker, og nå kan vi si at forbindelsen er etablert, det vil si at et 3-trinns håndtrykk er fullført ved bruk av TCP-protokollen.
Deretter skal vi se på TCP Windowing-teknologi. Enkelt sagt er det en metode som brukes i TCP/IP for å forhandle om egenskapene til avsender og mottaker.
La oss si at i Windows prøver vi å overføre en stor fil, for eksempel 2 GB i størrelse, fra en stasjon til en annen. Helt i begynnelsen av overføringen vil systemet informere oss om at filoverføringen vil ta ca. 1 år. Men noen sekunder senere vil systemet korrigere seg selv og si: "å, vent litt, jeg tror det vil ta omtrent 6 måneder, ikke et år." Litt mer tid vil gå og Windows vil si: "Jeg tror jeg kan være i stand til å overføre filen om 1 måned." Dette vil bli fulgt av meldingen "1 dag", "6 timer", "3 timer", "1 time", "20 minutter", "10 minutter", "3 minutter". Faktisk vil hele filoverføringsprosessen bare ta 3 minutter. Hvordan skjedde dette? Til å begynne med, når enheten prøver å kommunisere med en annen enhet, sender den én pakke og venter på bekreftelse. Hvis enheten venter lenge på bekreftelse, tenker den: "hvis jeg må overføre 2 GB data med denne hastigheten, vil det ta omtrent 2 år." Etter en tid mottar enheten din en ACK og tenker: "ok, jeg sendte en pakke og mottok en ACK, derfor kan mottakeren motta 1 pakke. Nå skal jeg prøve å sende ham 10 pakker i stedet for én.» Avsenderen sender 10 pakker og mottar etter en tid en ACK-bekreftelse fra mottakerenheten, som betyr at mottakeren venter på neste, 11. pakke. Avsenderen tenker: "bra, siden mottakeren håndterte 10 pakker på en gang, nå skal jeg prøve å sende ham 100 pakker i stedet for ti." Han sender 100 pakker, og mottakeren svarer at han har mottatt dem og venter nå på 101 pakker. Dermed øker antallet overførte pakker over tid.
Dette er grunnen til at du ser en rask nedgang i filkopieringstid sammenlignet med det som opprinnelig ble oppgitt - dette skyldes økt evne til å overføre store datamengder. Det kommer imidlertid et punkt når ytterligere økninger i overføringsvolumet blir umulig. La oss si at du sendte 10000 9000 pakker, men mottakerens enhetsbuffer kan bare akseptere 9000 9001. I dette tilfellet sender mottakeren en ACK med meldingen: "Jeg har mottatt 9000 9000 pakker og er nå klar til å motta 9000 3." Fra dette konkluderer avsenderen at mottakerenhetens buffer har en kapasitet på kun XNUMX, noe som betyr at jeg fra nå av ikke vil sende mer enn XNUMX pakker om gangen. I dette tilfellet beregner avsenderen raskt tiden det vil ta ham å overføre den gjenværende datamengden i deler av XNUMX pakker, og gir XNUMX minutter. Disse tre minuttene er den faktiske sendetiden. Det er det TCP Windowing gjør.
Dette er en av disse trafikkreguleringsmekanismene der senderenheten til slutt forstår hva den faktiske nettverkskapasiteten er. Du lurer kanskje på hvorfor de ikke kan bli enige på forhånd om hva kapasiteten til mottaksenheten er? Faktum er at dette er teknisk umulig fordi det er forskjellige typer enheter på nettverket. La oss si at du har en iPad og den har en annen dataoverførings-/mottakerhastighet enn en iPhone, du kan ha andre typer telefoner, eller kanskje du har en veldig gammel datamaskin. Derfor har alle forskjellig nettverksbåndbredde.
Det er grunnen til at TCP Windowing-teknologien ble utviklet, når dataoverføring begynner med lav hastighet eller med overføring av et minimum antall pakker, noe som gradvis øker trafikk-"vinduet". Du sender en pakke, 5 pakker, 10 pakker, 1000 pakker, 10000 XNUMX pakker og åpner sakte vinduet mer og mer til "åpningen" når maksimalt mulig trafikkvolumet sendt i løpet av en bestemt tidsperiode. Dermed er konseptet Windowing en del av driften av TCP-protokollen.
Deretter skal vi se på de vanligste portnumrene. Den klassiske situasjonen er når du har 1 hovedserver, kanskje et datasenter. Den inkluderer en filserver, webserver, e-postserver og DHCP-server. Nå, hvis en av klientdatamaskinene kontakter datasenteret, som er plassert i midten av bildet, vil det begynne å sende filservertrafikk til klientenheter. Denne trafikken vises i rødt og vil bli overført på en bestemt port for en spesifikk applikasjon fra en bestemt server.
Hvordan visste serveren hvor viss trafikk skulle gå? Han lærer dette fra destinasjonsportnummeret. Hvis du ser på rammen, vil du se at det i hver dataoverføring er en omtale av destinasjonsportnummeret og kildeportnummeret. Du kan se at den blå og røde trafikken, og den blå trafikken er webservertrafikk, begge går til samme fysiske server, som har forskjellige servere installert. Hvis dette er et datasenter, bruker det virtuelle servere. Så hvordan visste de at den røde trafikken skulle gå tilbake til den venstre bærbare datamaskinen med den IP-adressen? De vet dette takket være portnumre. Hvis du refererer til Wikipedia-artikkelen "Liste over TCP- og UDP-porter", vil du se at den viser alle standard portnumre.
Hvis du scroller ned på denne siden kan du se hvor stor denne listen er. Den inneholder omtrent 61 000 numre. Portnumre fra 1 til 1024 er kjent som de vanligste portnumrene. For eksempel er port 21/TCP for å sende ftp-kommandoer, port 22 er for ssh, port 23 er for Telnet, det vil si for å sende ukrypterte meldinger. Den svært populære port 80 fører data over HTTP, mens port 443 fører krypterte data over HTTPS, som ligner på den sikre versjonen av HTTP.
Noen porter er dedikert til både TCP og UDP, og noen utfører forskjellige oppgaver avhengig av om tilkoblingen er TCP eller UDP. Så offisielt brukes TCP-port 80 for HTTP, og uoffisielt brukes UDP-port 80 for HTTP, men under en annen HTTP-protokoll - QUIC.
Derfor er ikke portnumre i TCP alltid ment å gjøre det samme som i UDP. Du trenger ikke å lære denne listen utenat, den er umulig å huske, men du må kunne noen populære og vanligste portnumre. Som sagt har noen av disse portene et offisielt formål, som er beskrevet i standardene, og noen har et uoffisielt formål, slik tilfellet er med Chromium.
Så denne tabellen viser alle de vanlige portnumrene, og disse numrene brukes til å sende og motta trafikk når du bruker spesifikke applikasjoner.
La oss nå se på hvordan data beveger seg over nettverket basert på den lille informasjonen vi vet. La oss si at datamaskinen 10.1.1.10 ønsker å kontakte denne datamaskinen, eller denne serveren, som har adressen 30.1.1.10. Under IP-adressen til hver enhet er dens MAC-adresse. Jeg gir eksemplet med en MAC-adresse med bare de siste 4 tegnene, men i praksis er det et 48-bits heksadesimalt tall med 12 tegn. Siden hvert av disse tallene består av 4 biter, representerer 12 heksadesimale sifre et 48-bits tall.
Som vi vet, hvis denne enheten ønsker å kontakte denne serveren, må det første trinnet av 3-veis håndtrykk gjøres først, det vil si å sende en SYN-pakke. Når denne forespørselen er gjort, vil datamaskin 10.1.1.10 spesifisere kildeportnummeret, som Windows oppretter dynamisk. Windows velger tilfeldig et portnummer mellom 1 og 65,000 1. Men siden startnummer i området 1024 til 25000 er allment kjent, vil systemet i dette tilfellet vurdere tall som er større enn 25113 og opprette en tilfeldig kildeport, for eksempel nummer XNUMX.
Deretter vil systemet legge til en destinasjonsport til pakken, i dette tilfellet er det port 21, fordi applikasjonen som prøver å koble til denne FTP-serveren vet at den skal sende FTP-trafikk.
Deretter sier datamaskinen vår: "Ok, IP-adressen min er 10.1.1.10, og jeg må kontakte IP-adressen 30.1.1.10." Begge disse adressene er også inkludert i pakken for å danne en SYN-forespørsel, og denne pakken vil ikke endres før slutten av forbindelsen.
Jeg vil at du skal forstå fra denne videoen hvordan data beveger seg over nettverket. Når datamaskinen vår som sender forespørselen ser kilde-IP-adressen og destinasjons-IP-adressen, forstår den at destinasjonsadressen ikke er på det lokale nettverket. Jeg glemte å si at dette er alle /24 IP-adresser. Så hvis du ser på /24 IP-adressene, vil du innse at datamaskiner 10.1.1.10 og 30.1.1.10 ikke er på samme nettverk. Dermed forstår datamaskinen som sender forespørselen at for å forlate dette nettverket, må den kontakte 10.1.1.1-gatewayen, som er konfigurert på et av rutergrensesnittene. Den vet at den skal gå til 10.1.1.1 og kjenner MAC-adressen 1111, men kjenner ikke MAC-adressen til gatewayen 10.1.1.1. Hva er det han gjør? Den sender en kringkastings-ARP-forespørsel som alle enheter på nettverket vil motta, men bare ruteren med IP-adressen 10.1.1.1 vil svare på den.
Ruteren vil svare med sin AAAA MAC-adresse, og både kilde- og destinasjons-MAC-adresser vil også bli plassert i denne rammen. Når rammen er klar, vil en CRC-dataintegritetssjekk, som er en algoritme for å finne en kontrollsum for å oppdage feil, utføres før nettverket forlates.
Syklisk redundans CRC betyr at hele denne rammen, fra SYN til siste MAC-adresse, kjøres gjennom en hash-algoritme, for eksempel MD5, som resulterer i en hash-verdi. Hash-verdien, eller MD5-sjekksum, plasseres deretter i begynnelsen av rammen.
Jeg merket det FCS/CRC fordi FCS er en Frame Check Sequence, en fire-byte CRC-verdi. Noen bruker betegnelsen FCS og noen bruker betegnelsen CRC, så jeg tok bare med begge betegnelsene. Men i bunn og grunn er det bare en hashverdi. Det er nødvendig for å sikre at alle data som mottas over nettverket ikke inneholder feil. Derfor, når denne rammen når ruteren, er det første ruteren vil gjøre å beregne selve sjekksummen og sammenligne den med FCS- eller CRC-verdien som den mottatte rammen inneholder. På denne måten kan han kontrollere at dataene som mottas over nettverket ikke inneholder feil, hvoretter han vil fjerne sjekksummen fra rammen.
Deretter vil ruteren se på MAC-adressen og si: "Ok, MAC-adressen AAAA betyr at rammen er adressert til meg," og slette den delen av rammen som inneholder MAC-adressene.
Når han ser på destinasjons-IP-adressen 30.1.1.10, vil han forstå at denne pakken ikke er adressert til ham og må gå videre gjennom ruteren.
Nå "tenker" ruteren at den må se hvor nettverket med adressen 30.1.1.10 befinner seg. Vi har ikke dekket hele konseptet med ruting ennå, men vi vet at rutere har en rutingtabell. Denne tabellen har en oppføring for nettverket med adresse 30.1.1.0. Som du husker, er dette ikke vertens IP-adresse, men nettverksidentifikatoren. Ruteren vil "tro" at den kan nå adressen 30.1.1.0/24 ved å gå gjennom ruter 20.1.1.2.
Du kan spørre, hvordan vet han dette? Bare husk at den vil vite dette enten fra rutingprotokollene eller fra innstillingene dine hvis du som administrator har konfigurert en statisk rute. Men i alle fall inneholder denne ruterens rutetabell den riktige oppføringen, så den vet at den skal sende denne pakken til 20.1.1.2. Forutsatt at ruteren allerede vet destinasjons-MAC-adressen, vil vi ganske enkelt fortsette å videresende pakken. Hvis han ikke kjenner denne adressen, vil han starte ARP igjen, motta ruterens MAC-adresse 20.1.1.2, og prosessen med å sende rammen vil fortsette igjen.
Så vi antar at den allerede kjenner MAC-adressen, da vil vi ha BBB-kilde-MAC-adressen og CCC-destinasjons-MAC-adressen. Ruteren beregner igjen FCS/CRC og plasserer den i begynnelsen av bildet.
Den sender deretter denne rammen over nettverket, rammen når ruter 20.1.12, den sjekker sjekksummen, sørger for at dataene ikke er ødelagt, og sletter FCS/CRC. Den "trunkerer" så MAC-adressene, ser på destinasjonen og ser at den er 30.1.1.10. Han vet at denne adressen er koblet til grensesnittet hans. Den samme rammedannelsesprosessen gjentas, ruteren legger til kilde- og destinasjons-MAC-adresseverdiene, utfører hashen, fester hashen til rammen og sender den over nettverket.
Serveren vår, etter å ha mottatt SYN-forespørselen adressert til den, sjekker hash-sjekksummen, og hvis pakken ikke inneholder feil, sletter den hashen. Så fjerner han MAC-adressene, ser på IP-adressen og skjønner at denne pakken er adressert til ham.
Etter det avkorter den IP-adressene relatert til det tredje laget av OSI-modellen og ser på portnumrene.
Han ser port 21, som betyr FTP-trafikk, ser SYN og forstår derfor at noen prøver å kommunisere med ham.
Nå, basert på det vi lærte om håndtrykket, vil server 30.1.1.10 opprette en SYN/ACK-pakke og sende den tilbake til datamaskinen 10.1.1.10. Ved mottak av denne pakken vil enhet 10.1.1.10 opprette en ACK, sende den gjennom nettverket på samme måte som en SYN-pakke, og etter at serveren mottar ACK, vil forbindelsen bli etablert.
En ting du bør vite er at alt dette skjer på mindre enn et sekund. Dette er en veldig, veldig rask prosess, som jeg prøvde å bremse slik at alt er klart for deg.
Jeg håper du finner det du har lært i denne opplæringen nyttig. Hvis du har spørsmål, vennligst skriv til meg på [e-postbeskyttet] eller legg igjen spørsmål under denne videoen.
Fra og med neste leksjon vil jeg velge de 3 mest interessante spørsmålene fra YouTube, som jeg vil se på slutten av hver video. Fra nå av vil jeg ha en "Toppspørsmål"-seksjon, så jeg vil legge ut et spørsmål sammen med navnet ditt og svare på det live. Jeg tror dette vil være gunstig.
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, 30 % rabatt for Habr-brukere på en unik analog av inngangsnivåservere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 kjerner) 10 GB DDR4 240 GB SSD 1 Gbps gratis til sommeren når du betaler for en periode på seks måneder, kan du bestille .
Dell R730xd 2 ganger billigere? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com