Innan vi börjar dagens videohandledning vill jag tacka alla som bidragit till att min kurs blivit populär på YouTube. När jag startade det för cirka 8 månader sedan förväntade jag mig inte en sådan framgång - idag har mina lektioner setts av 312724 11208 personer, jag har 7 6 prenumeranter. Jag hade aldrig drömt om att denna ödmjuka början skulle nå sådana höjder. Men låt oss inte slösa tid och gå direkt till dagens lektion. Idag ska vi fylla i luckorna som uppstod under de senaste 3 videolektionerna. Även om idag bara är dag 3, delades dag XNUMX upp i XNUMX videolektioner, så idag kommer du faktiskt att titta på den åttonde videolektionen.
Idag kommer vi att ta upp tre viktiga ämnen: DHCP, TCP-transport och de vanligaste portnumren. Vi har redan pratat om IP-adresser, och en av de viktigaste faktorerna för IP-adresskonfiguration är DHCP.
DHCP står för Dynamic Host Configuration Protocol och det är ett protokoll som hjälper till att dynamiskt konfigurera IP-adresser för värdar. Så vi har alla sett det här fönstret. När du klickar på alternativet "Erhåll en IP-adress automatiskt" letar datorn efter en DHCP-server som är konfigurerad på samma subnät och skickar olika paket och förfrågningar om IP-adressen. DHCP-protokollet har 6 meddelanden, varav 4 är kritiska för att tilldela en IP-adress.
Det första meddelandet är ett DHCP DISCOVERY-meddelande. DHCP-upptäcktsmeddelandet liknar ett hälsningsmeddelande. När en ny enhet ansluter sig till nätverket frågar den om det finns en DHCP-server på nätverket.
Det du ser på bilden ser ut som en sändningsförfrågan där enheten kontaktar alla enheter i nätverket och letar efter en DHCP-server. Det här är som sagt en sändningsförfrågan, så alla enheter i nätverket kan höra den.
Om det finns en DHCP-server på nätverket skickar den ett paket - ett DHCP-ERBJUDANDE. Förslag innebär att DHCP-servern, som svar på en upptäcktsbegäran, skickar en konfiguration till klienten och ber klienten att acceptera en specifik IP-adress.
DHCP-servern reserverar en IP-adress, i det här fallet 192.168.1.2, tillhandahåller den inte, utan reserverar istället denna adress för enheten. Samtidigt innehåller erbjudandepaketet en egen IP-adress till DHCP-servern.
Om det finns mer än en DHCP-server på detta nätverk, kommer en annan DHCP-server, när den tar emot klientens sändningsförfrågan, också att erbjuda den sin IP-adress, till exempel 192.168.1.50. Det är inte vanligt att ha två olika DHCP-servrar konfigurerade på samma nätverk, men ibland händer det. Så när ett DHCP-erbjudande skickas till en klient får den 2 DHCP-erbjudanden och måste nu bestämma vilket DHCP-erbjudande den vill acceptera.
Låt oss anta att kunden accepterar den första ansökan. Detta innebär att klienten skickar en begäran om DHCP-BEGÖRANDE som bokstavligen säger "Jag accepterar IP-adressen 192.168.1.2 som erbjuds av DHCP-servern 192.168.1.1."
När 192.168.1.1 DHCP-servern tar emot begäran svarar "okej, jag erkänner det", det vill säga den bekräftar begäran och skickar denna DHCP ACK till klienten. Men vi kommer ihåg att en annan DHCP-server har reserverat en IP-adress på 1.50 för klienten. När den väl tar emot en klients sändningsbegäran kommer den att veta om felet och sätta tillbaka den IP-adressen i poolen så att den kan tilldela den till en annan klient om den får en annan begäran.
Det här är de fyra viktiga meddelandena som DHCP utbyter vid tilldelning av IP-adresser. Därefter har DHCP ytterligare två informationsmeddelanden. Ett informationsmeddelande utfärdas av klienten om den kräver mer information än den fick i DHCP OFFER-klausulen i det andra steget. Om servern inte gav tillräckligt med information i DHCP-erbjudandet, eller om klienten behöver mer information än vad som fanns i erbjudandepaketet, begär den ytterligare DHCP-information. Det finns ytterligare ett meddelande som klienten skickar till servern - detta är DHCP RELEASE. Den informerar dig om att klienten vill släppa sin befintliga IP-adress.
Det som dock oftast händer är att användaren kopplar från nätverket innan klienten hinner skicka en DHCP RELEASE till servern. Detta händer när du stänger av datorn, vilket vi gör. I det här fallet har nätverksklienten, eller datorn, helt enkelt inte tid att informera servern att släppa den använda adressen, så DHCP RELEASE är inte ett obligatoriskt steg. De nödvändiga stegen för att erhålla en IP-adress är: DHCP-upptäckt, DHCP-erbjudande, DHCP-begäran och DHCP-handskakning.
I en av de följande lektionerna kommer jag att berätta hur vi konfigurerar en DHCP-server när vi skapar en DNCP-pool. Med pooling menar vi att du säger åt servern att tilldela IP-adresser i intervallet 192.168.1.1 till 192.168.1.254. Således kommer DHCP-servern att skapa en pool, placera 254 IP-adresser i den och kommer att kunna tilldela adresser till klienter i nätverket endast från denna pool. Så det här är ungefär en administrativ inställning som användaren kan göra.
Låt oss nu titta på TCP-överföring. Jag vet inte om du är bekant med "telefonen" på bilden, men när vi var barn brukade vi använda dessa plåtburkar förbundna med ett snöre för att prata med varandra.
Tyvärr har dagens generation inte råd med sådan "lyx". Jag menar idag är barn framför tv:n från ett års ålder, de spelar PSP och det kanske är diskutabelt men jag tror att vi hade den bästa barndomen, vi gick faktiskt ut och spelade spel och dagens barn kan inte dras bort från soffan .
Min son är bara ett år och jag kan redan se att han är beroende av iPad, jag menar att han fortfarande är väldigt ung men jag tror att dagens barn redan föds och vet hur man hanterar elektroniska prylar. Så jag ville säga att vi som barn, när vi lekte, gjorde hål i plåtburkar, och när vi band dem med ett snöre och sa något i en burk, då kunde personen i andra änden höra vad som sades. till honom, helt enkelt genom att sätta burken mot hans öra. Så det är väldigt likt en nätverksanslutning.
Idag måste även TCP-överföringar ha en anslutning som måste upprättas innan själva dataöverföringen påbörjas. Som vi diskuterade i tidigare lektioner är TCP anslutningsorienterad överföring medan UDP är anslutningsorienterad överföring. Man kan säga att UDP är där jag kastar bollen och det är upp till dig att se om du kan fånga den. Om du är redo att göra det eller inte är inte mitt problem, jag ska bara lämna honom.
TCP är mer som att du pratar med en kille och varnar honom i förväg att du ska kasta en boll, så att du bildar ett band, och sedan kastar du bollen så att din partner är mer sannolikt att vara redo att fånga den. Så TCP bygger faktiskt anslutningen och börjar sedan göra själva överföringen.
Låt oss titta på hur det skapar en sådan anslutning. Detta protokoll använder en 3-vägs handskakning för att skapa en anslutning. Detta är inte en mycket teknisk term, men den har länge använts för att beskriva en TCP-anslutning. En 3-vägs handskakning initieras av den sändande enheten, där klienten skickar ett paket med en SYN-flagga till servern.
Låt oss säga att flickan i förgrunden, vars ansikte vi kan se, är enhet A, och flickan i bakgrunden, vars ansikte inte är synlig, är enhet B. Tjej A skickar ett SYN-paket till flicka B och hon säger: ”bra, vem- då vill han kommunicera med mig. Så jag måste svara att jag är redo att kommunicera!” Hur man gör det? Man skulle helt enkelt kunna skicka tillbaka ett annat SYN-paket och sedan ett ACK som indikerar mottagandet av det ursprungliga SYN-paketet. Men istället för att skicka ACK separat, bildar servern ett gemensamt paket som innehåller SYN och ACK och sänder det över nätverket.
Så vid denna tidpunkt har enhet A skickat ett SYN-paket och fått tillbaka ett SYN/ACK-paket. Nu måste enhet A skicka enhet B ett ACK-paket, det vill säga bekräfta att den har fått medgivande från enhet B för att upprätta kommunikation. Således fick båda enheterna SYN- och ACK-paket, och nu kan vi säga att anslutningen har upprättats, det vill säga en 3-stegs handskakning har slutförts med TCP-protokollet.
Därefter kommer vi att titta på TCP Windowing-teknik. Enkelt uttryckt är det en metod som används i TCP/IP för att förhandla om sändarens och mottagarens möjligheter.
Låt oss säga att vi i Windows försöker överföra en stor fil, säg 2 GB i storlek, från en enhet till en annan. Allra i början av överföringen kommer systemet att informera oss om att filöverföringen kommer att ta cirka 1 år. Men några sekunder senare kommer systemet att korrigera sig själv och säga: "åh, vänta lite, jag tror att det kommer att ta ungefär 6 månader, inte ett år." Lite mer tid kommer att gå och Windows kommer att säga: "Jag tror att jag kanske kan överföra filen om 1 månad." Detta kommer att följas av meddelandet "1 dag", "6 timmar", "3 timmar", "1 timme", "20 minuter", "10 minuter", "3 minuter". Faktum är att hela filöverföringsprocessen bara tar 3 minuter. Hur hände det här? Inledningsvis, när din enhet försöker kommunicera med en annan enhet, skickar den ett paket och väntar på bekräftelse. Om enheten väntar länge på bekräftelse tänker den: "om jag måste överföra 2 GB data med den här hastigheten kommer det att ta ungefär 2 år." Efter en tid tar din enhet emot ett ACK och tänker, "okej, jag skickade ett paket och fick ett ACK, därför kan mottagaren ta emot 1 paket. Nu ska jag försöka skicka honom 10 paket istället för ett." Avsändaren skickar 10 paket och får efter en tid en ACK-bekräftelse från den mottagande enheten, vilket innebär att mottagaren väntar på nästa, 11:e paket. Avsändaren tänker: "bra, eftersom mottagaren hanterade 10 paket på en gång, nu ska jag försöka skicka honom 100 paket istället för tio." Han skickar 100 paket, och mottagaren svarar att han tagit emot dem och nu väntar på 101 paket. Med tiden ökar således antalet överförda paket.
Det är därför du ser en snabb minskning av filkopieringstiden jämfört med vad som ursprungligen angavs - detta beror på den ökade förmågan att överföra stora mängder data. Men det kommer en punkt när ytterligare ökningar av överföringsvolymen blir omöjliga. Låt oss säga att du skickade 10000 9000 paket, men mottagarens enhetsbuffert kan bara acceptera 9000 9001. I det här fallet skickar mottagaren ett ACK med meddelandet: "Jag har tagit emot 9000 9000 paket och är nu redo att ta emot 9000 3." Av detta drar avsändaren slutsatsen att den mottagande enhetens buffert har en kapacitet på endast XNUMX, vilket innebär att jag från och med nu inte kommer att skicka mer än XNUMX paket åt gången. I det här fallet beräknar avsändaren snabbt den tid det kommer att ta honom att överföra den återstående mängden data i delar av XNUMX paket, och ger XNUMX minuter. Dessa tre minuter är den faktiska sändningstiden. Det är vad TCP Windowing gör.
Detta är en av de trafikbegränsningsmekanismer där den sändande enheten så småningom förstår vad den faktiska nätverkskapaciteten är. Du kanske undrar varför de inte kan komma överens i förväg om vilken kapacitet den mottagande enheten har? Faktum är att detta är tekniskt omöjligt eftersom det finns olika typer av enheter på nätverket. Låt oss säga att du har en iPad och den har en annan dataöverförings-/mottagarhastighet än en iPhone, du kanske har olika typer av telefoner, eller så har du en väldigt gammal dator. Därför har alla olika nätverksbandbredd.
Det är därför som TCP Windowing-teknologin utvecklades, när dataöverföringen börjar med låg hastighet eller med överföringen av ett minsta antal paket, vilket gradvis ökar trafikens "fönster". Du skickar ett paket, 5 paket, 10 paket, 1000 paket, 10000 XNUMX paket och öppnar långsamt det fönstret mer och mer tills "öppningen" når den maximala möjliga trafikvolymen som skickas under en viss tidsperiod. Konceptet med Windowing är alltså en del av driften av TCP-protokollet.
Därefter ska vi titta på de vanligaste portnumren. Den klassiska situationen är när du har 1 huvudserver, kanske ett datacenter. Den innehåller en filserver, webbserver, e-postserver och DHCP-server. Om nu en av klientdatorerna kontaktar datacentret, som finns i mitten av bilden, kommer den att börja skicka filservertrafik till klientenheter. Denna trafik visas i rött och kommer att överföras på en specifik port för en specifik applikation från en specifik server.
Hur visste servern var viss trafik skulle gå? Han lär sig detta från destinationsportnumret. Om du tittar på ramen kommer du att se att det i varje dataöverföring finns ett omnämnande av destinationsportnumret och källportnumret. Du kan se att den blå och röda trafiken, och den blå trafiken är webbservertrafik, båda går till samma fysiska server, som har olika servrar installerade. Om detta är ett datacenter använder det virtuella servrar. Så hur visste de att den röda trafiken skulle gå tillbaka till den vänstra bärbara datorn med den IP-adressen? De vet detta tack vare portnummer. Om du hänvisar till Wikipedia-artikeln "Lista över TCP- och UDP-portar", kommer du att se att den listar alla standardportnummer.
Om du scrollar ner på den här sidan kan du se hur stor den här listan är. Den innehåller cirka 61 000 nummer. Portnummer från 1 till 1024 är kända som de vanligaste portnumren. Till exempel är port 21/TCP avsedd för att skicka ftp-kommandon, port 22 för ssh, port 23 för Telnet, det vill säga för att skicka okrypterade meddelanden. Den mycket populära porten 80 används för att överföra data med HTTP-protokollet, medan port 443 används för att överföra krypterad data med HTTPS-protokollet, som liknar den säkra versionen av HTTP.
Vissa portar är dedikerade till både TCP och UDP, och vissa utför olika uppgifter beroende på om anslutningen är TCP eller UDP. Så, officiellt används TCP-port 80 för HTTP, och inofficiellt används UDP-port 80 för HTTP, men under ett annat HTTP-protokoll - QUIC.
Därför är portnummer i TCP inte alltid avsedda att göra samma sak som i UDP. Du behöver inte lära dig den här listan utantill, den är omöjlig att komma ihåg, men du måste kunna några populära och vanligaste portnummer. Vissa av dessa portar har som sagt ett officiellt syfte, vilket beskrivs i standarderna, och några har ett inofficiellt syfte, som är fallet med Chromium.
Så den här tabellen listar alla vanliga portnummer, och dessa nummer används för att skicka och ta emot trafik när du använder specifika applikationer.
Låt oss nu titta på hur data rör sig över nätverket baserat på den lilla information vi känner till. Låt oss säga att dator 10.1.1.10 vill kontakta den här datorn, eller den här servern, som har adressen 30.1.1.10. Under IP-adressen för varje enhet finns dess MAC-adress. Jag ger exemplet med en MAC-adress med bara de sista 4 tecknen, men i praktiken är det ett 48-bitars hexadecimalt tal med 12 tecken. Eftersom vart och ett av dessa nummer består av 4 bitar representerar 12 hexadecimala siffror ett 48-bitars tal.
Som vi vet, om den här enheten vill kontakta den här servern, måste det första steget av 3-vägs handskakning göras först, det vill säga att skicka ett SYN-paket. När denna begäran görs kommer dator 10.1.1.10 att ange källportnumret, som Windows skapar dynamiskt. Windows väljer slumpmässigt ett portnummer mellan 1 och 65,000 1. Men eftersom startnummer i intervallet 1024 till 25000 är allmänt kända, kommer systemet i det här fallet att överväga nummer större än 25113 XNUMX och skapa en slumpmässig källport, till exempel nummer XNUMX.
Därefter kommer systemet att lägga till en destinationsport till paketet, i det här fallet är det port 21, eftersom applikationen som försöker ansluta till denna FTP-server vet att den ska skicka FTP-trafik.
Därefter säger vår dator: "Okej, min IP-adress är 10.1.1.10, och jag måste kontakta IP-adressen 30.1.1.10." Båda dessa adresser ingår också i paketet för att bilda en SYN-begäran, och detta paket kommer inte att ändras förrän i slutet av anslutningen.
Jag vill att du ska förstå från den här videon hur data rör sig över nätverket. När vår dator som skickar förfrågan ser käll-IP-adressen och destinations-IP-adressen, förstår den att destinationsadressen inte finns i det lokala nätverket. Jag glömde att säga att alla dessa är /24 IP-adresser. Så om du tittar på /24 IP-adresserna kommer du att inse att datorerna 10.1.1.10 och 30.1.1.10 inte är på samma nätverk. Således förstår datorn som skickar begäran att för att lämna detta nätverk måste den kontakta 10.1.1.1-gatewayen, som är konfigurerad på ett av routerns gränssnitt. Den vet att den ska gå till 10.1.1.1 och känner till sin MAC-adress 1111, men känner inte till MAC-adressen för gatewayen 10.1.1.1. Vad gör han? Den skickar en broadcast ARP-förfrågan som alla enheter i nätverket kommer att ta emot, men bara routern med IP-adress 10.1.1.1 kommer att svara på den.
Routern kommer att svara med sin AAAA MAC-adress, och både käll- och destinations-MAC-adresser kommer också att placeras i denna ram. När ramen är klar kommer en CRC-dataintegritetskontroll, som är en algoritm för att hitta en kontrollsumma för att upptäcka fel, att utföras innan nätverket lämnas.
Cyklisk redundans CRC innebär att hela denna ram, från SYN till den sista MAC-adressen, körs genom en hashalgoritm, säg MD5, vilket resulterar i ett hashvärde. Hashvärdet, eller MD5-kontrollsumman, placeras sedan i början av ramen.
Jag märkte det FCS/CRC eftersom FCS är en Frame Check Sequence, ett fyra-byte CRC-värde. Vissa använder beteckningen FCS och vissa använder beteckningen CRC, så jag tog bara med båda beteckningarna. Men i grunden är det bara ett hashvärde. Det behövs för att säkerställa att all data som tas emot över nätverket inte innehåller fel. Därför, när denna ram når routern, är det första som routern kommer att göra att beräkna själva kontrollsumman och jämföra den med FCS- eller CRC-värdet som den mottagna ramen innehåller. På så sätt kan han kontrollera att data som tas emot över nätverket inte innehåller fel, varefter han tar bort kontrollsumman från ramen.
Därefter kommer routern att titta på MAC-adressen och säga, "Okej, MAC-adress AAAA betyder att ramen är adresserad till mig" och raderar den del av ramen som innehåller MAC-adresserna.
När han tittar på destinations-IP-adressen 30.1.1.10 kommer han att förstå att detta paket inte är adresserat till honom och måste gå vidare genom routern.
Nu "tänker" routern att den behöver se var nätverket med adressen 30.1.1.10 finns. Vi har inte täckt hela konceptet för routing än, men vi vet att routrar har en routingtabell. Den här tabellen har en post för nätverket med adress 30.1.1.0. Som du kommer ihåg är detta inte värd-IP-adressen, utan nätverksidentifieraren. Routern kommer att "tro" att den kan nå adressen 30.1.1.0/24 genom att gå via router 20.1.1.2.
Du kanske frågar, hur vet han detta? Tänk bara på att den kommer att veta detta antingen från routingprotokollen eller från dina inställningar om du som administratör har konfigurerat en statisk rutt. Men i alla fall innehåller den här routerns routingtabell den korrekta posten, så den vet att den ska skicka detta paket till 20.1.1.2. Förutsatt att routern redan känner till destinationens MAC-adress, fortsätter vi helt enkelt att vidarebefordra paketet. Om han inte känner till den här adressen kommer han att starta ARP igen, ta emot routerns MAC-adress 20.1.1.2 och processen att skicka ramen kommer att fortsätta igen.
Så vi antar att den redan känner till MAC-adressen, då kommer vi att ha BBB-källans MAC-adress och CCC-destinations-MAC-adressen. Routern beräknar återigen FCS/CRC och placerar den i början av bilden.
Den skickar sedan denna ram över nätverket, ramen når router 20.1.12, den kontrollerar kontrollsumman, ser till att data inte är skadad och raderar FCS/CRC. Den "trunkerar" sedan MAC-adresserna, tittar på destinationen och ser att den är 30.1.1.10. Han vet att den här adressen är kopplad till hans gränssnitt. Samma rambildningsprocess upprepas, routern lägger till källan och destinationens MAC-adressvärden, gör hashningen, fäster hashen till ramen och skickar den över nätverket.
Vår server, efter att äntligen ha fått SYN-begäran adresserad till den, kontrollerar hash-checksumman, och om paketet inte innehåller fel, tar den bort hashen. Sedan tar han bort MAC-adresserna, tittar på IP-adressen och inser att detta paket är adresserat till honom.
Efter det trunkerar den IP-adresserna relaterade till det tredje lagret av OSI-modellen och tittar på portnumren.
Han ser port 21, vilket betyder FTP-trafik, ser SYN och förstår därför att någon försöker kommunicera med honom.
Nu, baserat på vad vi lärde oss om handskakningen, kommer server 30.1.1.10 att skapa ett SYN/ACK-paket och skicka tillbaka det till datorn 10.1.1.10. Vid mottagande av detta paket kommer enheten 10.1.1.10 att skapa ett ACK, skicka det genom nätverket på samma sätt som ett SYN-paket, och efter att servern tagit emot ACK kommer anslutningen att upprättas.
En sak du bör veta är att allt detta händer på mindre än en sekund. Det här är en väldigt, väldigt snabb process, som jag försökte bromsa så att allt är klart för dig.
Jag hoppas att du har nytta av det du lärde dig i denna handledning. Om du har några frågor, skriv till mig på [e-postskyddad] eller lämna frågor under den här videon.
Från och med nästa lektion kommer jag att välja ut de 3 mest intressanta frågorna från YouTube, som jag kommer att granska i slutet av varje video. Från och med nu kommer jag att ha en "Toppfrågor"-sektion så jag kommer att posta en fråga tillsammans med ditt namn och svara på den live. Jag tror att detta kommer att vara fördelaktigt.
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, 30 % rabatt för Habr-användare på en unik analog av nybörjarservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 kärnor) 10GB DDR4 240GB SSD 1Gbps gratis till sommaren vid betalning för en period av sex månader kan du beställa .
Dell R730xd 2 gånger billigare? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com