Voordat ons vandag se video-tutoriaal begin, wil ek almal bedank wat bygedra het tot die gewildheid van my kursus op YouTube. Toe ek dit so 8 maande gelede begin het, het ek nie so 'n sukses verwag nie - vandag het 312724 mense my lesse bekyk, ek het 11208 intekenare. Ek het nooit gedroom dat hierdie beskeie onderneming sulke hoogtes sou bereik nie. Maar laat ons nie tyd mors nie en gaan dadelik aan na vandag se les. Vandag sal ons die leemtes wat in die laaste 7 video-tutoriale plaasgevind het, aanvul. Alhoewel vandag net dag 6 is, is dag 3 in 3 videolesse opgedeel, so jy sal eintlik vandag na die agtste videoles kyk.
Vandag gaan ons oor 3 belangrike onderwerpe handel: DHCP, TCP-aanstuur en die poortnommers wat die meeste gebruik word. Ons het reeds oor IP-adresse gepraat, en een van die belangrikste faktore in IP-adreskonfigurasie is DHCP.
DHCP staan vir "Dynamic Host Configuration Protocol" en is 'n protokol wat help om IP-adresse vir gashere dinamies op te stel. So, ons het almal hierdie venster gesien. Wanneer jy op die opsie "kry outomaties 'n IP-adres" klik, soek die rekenaar na 'n DHCP-bediener wat op dieselfde subnet opgestel is en stuur verskeie pakkies en versoeke vir die IP-adres. Die DHCP-protokol het 6 boodskappe, waarvan 4 van kritieke belang is vir die toewysing van 'n IP-adres.
Die eerste boodskap is 'n DHCP DISCOVERY-boodskap. Die DHCP-ontdekkingsboodskap is soortgelyk aan 'n hallo. Wanneer 'n nuwe toestel by die netwerk aansluit, vra dit of daar 'n DHCP-bediener op die netwerk is.
Wat jy op die skyfie sien, lyk soos 'n uitsaaiversoek, wanneer die toestel alle toestelle op die netwerk kontak op soek na 'n DHCP-bediener. Soos ek gesê het, is dit 'n uitsaaiversoek, so alle toestelle op die netwerk hoor dit.
As daar 'n DHCP-bediener op die netwerk is, stuur dit 'n pakkie - 'n DHCP-AANBOD. 'n Aanbod beteken dat die DHCP-bediener, in reaksie op 'n ontdekkingsversoek, 'n konfigurasie aan die kliënt stuur, wat die kliënt vra om 'n spesifieke IP-adres te aanvaar.
Die DHCP-bediener behou 'n IP-adres, in hierdie geval 192.168.1.2, verskaf nie, maar behou eerder hierdie adres vir die toestel. Daarbenewens bevat die aanbodpakket die DHCP-bediener se eie IP-adres.
As daar meer as een DHCP-bediener op hierdie netwerk is, sal 'n ander DHCP-bediener, by ontvangs van die kliënt se uitsaaiversoek, ook sy eie IP-adres aanbied, byvoorbeeld 192.168.1.50. Gewoonlik is twee verskillende DHCP-bedieners nie op dieselfde netwerk gekonfigureer nie, maar soms gebeur dit wel. So wanneer 'n DHCP-aanbod aan 'n kliënt gestuur word, ontvang dit 2 DHCP-aanbiedinge en moet nou besluit watter DHCP-aanbod hy wil aanvaar.
Kom ons neem aan dat die kliënt die eerste aansoek aanvaar. Dit beteken dat die kliënt 'n DHCP-VERSOEK uitstuur wat letterlik sê "Ek aanvaar die IP-adres 192.168.1.2 wat deur die DHCP-bediener 192.168.1.1 aangebied word".
By ontvangs van die versoek, antwoord die DHCP-bediener 192.168.1.1 "OK, ek sal dit erken", d.w.s. erken die versoek en stuur hierdie DHCP ACK aan die kliënt. Maar ons onthou dat 'n ander DHCP-bediener DHCP IP-adres 1.50 vir die kliënt gereserveer het. By ontvangs van die kliënt se uitsaaiversoek, sal dit bewus word van die verwerping en daardie IP-adres terug in die poel plaas sodat dit dit aan 'n ander kliënt kan toewys as dit nog 'n versoek ontvang.
Dit is die 4 kritieke boodskappe wat deur DHCP uitgeruil word aan die begin van die IP-adrestoewysing. Verder het DHCP nog 2 inligtingsboodskappe. 'n Inligtingsboodskap word deur die kliënt uitgereik as dit meer inligting benodig as wat dit in die DHCP-AANBOD in die tweede stap ontvang het. As die DHCP-bediener onvoldoende inligting in die DHCP-aanbod verskaf het, of as die kliënt meer inligting benodig as wat in die aanbodpakket vervat is, versoek dit bykomende DHCP-inligting. Daar is nog een boodskap wat die kliënt na die bediener stuur - dit is 'n DHCP-VRYSTELLING. Dit sê dat die kliënt die IP-adres wat hy het wil vrystel.
Dit gebeur egter meestal dat die gebruiker van die netwerk ontkoppel word voordat die kliënt tyd het om 'n DHCP-VRYSTELLING na die bediener te stuur. Dit gebeur wanneer jy die rekenaar afskakel, wat ons saam met jou doen. In hierdie geval het die netwerkkliënt, of rekenaar, eenvoudig nie tyd om die bediener te vertel om die gebruikte adres vry te stel nie, dus is DHCP RELEASE nie 'n verpligte stap nie. Die verpligte stappe om 'n IP-adres te verkry is: DHCP-ontdekking, DHCP-aanbod, DHCP-versoek en DHCP-handdruk.
In een van die volgende lesse sal ek verduidelik hoe ons die DHCP-bediener instel wanneer ons 'n DNCP-poel skep. Pooling beteken dat jy die bediener sê om IP-adresse toe te ken in die reeks 192.168.1.1 tot 192.168.1.254. Dus, die DHCP-bediener sal 'n poel skep, 254 IP-adresse daarin plaas, en sal adresse slegs vanaf hierdie poel aan netwerkkliënte kan toewys. Dit is dus iets soos 'n administratiewe instelling wat die gebruiker kan maak.
Kom ons kyk nou na TCP-oordrag. Ek weet nie of jy vertroud is met die "telefoon" in die prentjie nie, maar toe ons kinders was, het ons hierdie blikkies wat met tou verbind is, gebruik om met mekaar te praat.
Ongelukkig kan vandag se generasie nie so 'n "luuksheid" bekostig nie. Ek bedoel vandag is kinders voor die TV van die ouderdom van een af, hulle speel PSP en miskien is dit 'n twispunt, maar ek dink ons het die beste kinderjare gehad, ons het regtig uitgegaan en speletjies gespeel, uh vandag se kinders kan nie afgeskeur word nie die rusbank.
My seuntjie is maar net 'n jaar oud en ek kan al sien hy is verslaaf aan die iPad, ek bedoel hy is nog baie jonk, maar dit lyk vir my of vandag se kinders reeds gebore word met die kennis van hoe om elektroniese gadgets te hanteer. So, ek wou sê dat ons in die kinderjare, toe ons gespeel het, gate in blikkies gemaak het, en as ons dit met 'n tou vasgemaak en iets in een blikkie sê, dan kon 'n persoon aan die ander kant hoor wat hulle vir hom, bloot deur die blikkie by sy oor te sit. Dit is dus baie soortgelyk aan 'n netwerkverbinding.
Vandag, selfs vir TCP-oordrag, moet daar 'n verbinding wees wat tot stand gebring moet word voordat die werklike data-oordrag kan begin. Soos ons in vorige lesse bespreek het, is TCP 'n netwerkverbinding-georiënteerde transmissie, terwyl UDP 'n verbindinglose transmissie is. Jy kan sê UDP is wanneer ek die bal gooi en dit is aan jou of jy dit kan vang. Of jy bereid is om dit te doen of nie, dit is nie my probleem nie, ek gaan net ophou.
TCP is meer soos om met 'n ou te praat en hom vooraf te waarsku dat jy die bal gaan gooi, wat beteken dat jy bind voor jy die bal gooi, so jou maat is meer geneig om gereed te wees om dit te vang. So TCP bou eintlik die verbinding en begin dan die werklike transmissie.
Kom ons kyk hoe dit so 'n verbinding skep. Hierdie protokol gebruik 'n 3-rigting handdruk om 'n verbinding te skep. Dit is nie 'n baie tegniese term nie, maar dit is lank reeds gebruik om 'n TCP-verbinding te beskryf. Die 3-rigting-handdruk word deur die stuurtoestel geïnisieer, met die kliënt wat 'n pakkie met die SYN-vlag na die bediener stuur.
Gestel die meisie op die voorgrond, wie se gesig ons kan sien, is toestel A, en die meisie in die agtergrond, wie se gesig nie sigbaar is nie, is toestel B. Meisie A stuur 'n SYN-pakkie na meisie B, en sy sê: “okay , iemand wat hy met my wil kommunikeer. So, ek moet antwoord dat ek gereed is om te kommunikeer!” Hoe om dit te doen? Mens kan eenvoudig nog 'n SYN pakkie terugstuur en dan 'n ACK wat ontvangs van die oorspronklike SYN pakkie aandui. Maar in plaas daarvan om ACK's afsonderlik te stuur, vorm die bediener 'n gemeenskaplike pakkie wat SYN en ACK bevat en stuur dit oor die netwerk.
Dus, op hierdie stadium het toestel A 'n SYN-pakkie gestuur en 'n SYN/ACK-pakkie terug ontvang. Nou moet toestel A 'n ACK-pakkie na toestel B stuur, dit wil sê, bevestig dat dit toestel B se toestemming ontvang het om kommunikasie te bewerkstellig. Beide toestelle het dus SYN- en ACK-pakkies ontvang, en nou kan ons sê dat die verbinding tot stand gebring is, dit wil sê, 'n 3-rigting-handdruk is uitgevoer met behulp van die TCP-protokol.
Vervolgens sal ons kyk na TCP Windowing-tegnologie. Eenvoudig gestel, dit is 'n tegniek wat in TCP/IP gebruik word om die vermoëns van 'n sender en 'n ontvanger te onderhandel.
Kom ons sê dat ons in Windows probeer om 'n groot lêer, sê 2 GB groot, van een skyf na 'n ander oor te dra. Heel aan die begin van die oordrag sal die stelsel ons inlig dat die oordrag van die lêer ongeveer 1 jaar sal neem. Maar 'n paar sekondes later sal die stelsel homself regstel en sê, "ag wag 'n bietjie, ek dink dit sal nie 'n jaar neem nie, maar omtrent 6 maande." Nog 'n bietjie tyd sal verbygaan, en Windows sal sê: "Ek dink ek kan waarskynlik die lêer oor 1 maand oordra." Dan sal die boodskap "1 dag", "6 uur", "3 uur", "1 uur", "20 minute", "10 minute", "3 minute" volg. Trouens, die hele lêeroordragproses sal slegs 3 minute neem. Hoe het dit gebeur? Aanvanklik, toe jou toestel probeer het om met 'n ander toestel te kommunikeer, stuur dit een pakkie en wag vir 'n erkenning. As die toestel lank vir bevestiging wag, dink dit: "as ek 2 GB data teen hierdie spoed moet oordra, sal dit ongeveer 2 jaar neem." Na 'n rukkie ontvang jou toestel 'n ACK en dink, "OK, ek het een pakkie gestuur en 'n ACK ontvang, so die ontvanger kan 1 pakkie ontvang. Nou sal ek probeer om vir hom 10 pakkies te stuur in plaas van een.” Die sender stuur 10 pakkies en ontvang na 'n geruime tyd 'n ACK terug vanaf die ontvanger toestel, wat beteken dat die ontvanger wag vir die volgende, 11de pakkie. Die sender dink: "Goed, aangesien die ontvanger 10 pakkies op een slag klaargemaak het, sal ek nou probeer om vir hom 100 pakkies te stuur in plaas van tien." Dit stuur 100 pakkies en die ontvanger antwoord dat hy dit ontvang het en wag nou vir 101 pakkies. So, met verloop van tyd, neem die aantal gestuurde pakkies toe.
Dit is hoekom jy 'n dramatiese afname in lêerkopietyd sien in vergelyking met wat oorspronklik beweer is - dit is as gevolg van die toename in die vermoë om groot hoeveelhede data oor te dra. Daar kom egter 'n punt wanneer verdere toename in transmissievolume onmoontlik word. Gestel jy het 10000 9000 pakkies gestuur, maar die ontvanger se toestelbuffer kan net 9000 9001 ontvang. In hierdie geval stuur die ontvanger 'n ACK met die boodskap: "Ek het 9000 pakkies ontvang en is nou gereed om 9000 te ontvang." Hieruit lei die sender af dat die buffer van die ontvangstoestel 'n kapasiteit van slegs 9000 het, wat beteken dat ek voortaan nie meer as 3 pakkies op 'n slag sal stuur nie. Terselfdertyd bereken die sender vinnig die tyd wat dit hom sal neem om die oorblywende hoeveelheid data in gedeeltes van XNUMX pakkies te versend, en reik XNUMX minute uit. Hierdie drie minute is die werklike transmissietyd. Dit is wat TCP Windowing doen.
Dit is een van daardie verkeersbeperkingsmeganismes waar die oordragtoestel mettertyd leer wat die werklike netwerkdeurset is. Jy wonder dalk hoekom hulle nie vooraf kan saamstem oor wat die kapasiteit van die ontvangstoestel is nie? Die feit is dat dit tegnies onmoontlik is, want daar is verskillende soorte toestelle op die netwerk. Kom ons sê jy het 'n iPad en dit het 'n ander op-/aflaaispoed as 'n iPhone, jy het dalk verskillende soorte fone, of dalk het jy 'n baie ou rekenaar. Daarom het almal 'n ander netwerkbandwydte.
Daarom is die TCP Windowing-tegnologie ontwikkel wanneer data-oordrag teen 'n lae spoed begin of met die oordrag van 'n minimum aantal pakkies, wat die verkeersvenster geleidelik verhoog. Jy stuur een pakkie, 5 pakkies, 10 pakkies, 1000 pakkies, 10000 pakkies en maak hierdie venster stadig meer en meer oop totdat die "opening" die maksimum moontlike hoeveelheid verkeer wat in 'n spesifieke tydperk gestuur word, bereik. Die konsep van Windowing is dus deel van hoe die TCP-protokol werk.
Vervolgens sal ons kyk na die mees algemene poortnommers. Die klassieke situasie is wanneer u 1 hoofbediener het, miskien 'n datasentrum. Dit bevat 'n lêerbediener, 'n webbediener, 'n posbediener en 'n DHCP-bediener. Nou, as een van die kliëntrekenaars die datasentrum, wat in die middel van die prentjie geleë is, kontak, sal dit lêerbedienerverkeer na kliënttoestelle begin stuur. Hierdie verkeer word in rooi gewys en sal 'n spesifieke poort vir 'n spesifieke toepassing vanaf 'n spesifieke bediener gebruik.
Hoe weet die bediener waarheen sekere verkeer moet gaan? Dit leer daaroor uit die bestemmingspoortnommer. As jy na die raam kyk, sal jy sien dat daar in elke data-oordrag 'n melding is van die bestemmingspoortnommer en die bronpoortnommer. U kan sien dat die blou en rooi verkeer, en die blou verkeer webbedienerverkeer is, albei na dieselfde fisiese bediener gaan wat verskillende bedieners geïnstalleer het. As dit 'n datasentrum is, gebruik dit virtuele bedieners. So, hoe het hulle geweet dat die rooi verkeer veronderstel was om terug te gaan na daardie linker skootrekenaar met daardie IP-adres? Hulle weet dit as gevolg van die poortnommers. As jy na die Wikipedia-artikel "Lys van TCP- en UDP-poorte" verwys, sal jy sien dat dit al die standaardpoortnommers lys.
As jy hierdie bladsy blaai, kan jy sien hoe groot hierdie lys is. Dit bevat ongeveer 61 000 nommers. Poortnommers van 1 tot 1024 staan bekend as die mees algemene poortnommers. Byvoorbeeld, poort 21/TCP is vir die stuur van ftp-opdragte, poort 22 vir ssh, poort 23 vir Telnet, dit wil sê vir die stuur van ongeënkripteerde boodskappe. Die baie gewilde poort 80 is vir HTTP-kommunikasie, terwyl poort 443 vir geënkripteerde kommunikasie met HTTPS is, wat soortgelyk is aan die veilige weergawe van HTTP.
Sommige poorte is vir beide TCP en UDP, en sommige verrig verskillende take, afhangende van of die verbinding TCP of UDP is. Dus, amptelik, word TCP-poort 80 vir HTTP gebruik, en nie-amptelik word UDP-poort 80 vir HTTP gebruik, maar met 'n ander HTTP-protokol - QUIC.
Daarom is poortnommers in TCP nie altyd bedoel om dieselfde te wees as dié in UDP nie. Jy hoef nie hierdie lys te memoriseer nie, dit is onmoontlik om te onthou, maar 'n paar gewilde en mees algemene poortnommers moet bekend wees. Soos ek gesê het, het sommige van hierdie poorte 'n amptelike doel, wat in die standaarde beskryf word, en sommige het 'n nie-amptelike doel, soos die geval is met Chromium.
Dus, hierdie tabel lys alle algemene poortnommers, en hierdie nommers word gebruik om verkeer te stuur en te ontvang wanneer spesifieke toepassings gebruik word.
Kom ons kyk nou na hoe data op die web beweeg op grond van die min inligting wat ons ken. Gestel rekenaar 10.1.1.10 wil hierdie rekenaar kontak, of hierdie bediener, wat die adres 30.1.1.10 het. Onder die IP-adres van elke toestel is sy MAC-adres. Ek gee 'n voorbeeld MAC-adres met net die laaste 4 syfers, maar in die praktyk is dit 'n 48-bis heksadesimale getal met 12 syfers. Aangesien elk van hierdie getalle uit 4 bisse bestaan, is 12 heksadesimale syfers 'n 48-bis getal.
Soos ons weet, as hierdie toestel hierdie bediener wil kontak, moet die eerste stap van die 3-rigting handdruk eers gedoen word, dit wil sê, 'n SYN-pakkie word gestuur. Wanneer hierdie versoek gedoen word, sal die 10.1.1.10-rekenaar die bronpoortnommer spesifiseer wat Windows dinamies skep. Windows kies willekeurig 'n poortnommer van 1 tot 65,000 1. Maar aangesien begingetalle in die reeks 1024 tot 25000 algemeen bekend is, sal die stelsel in hierdie geval getalle groter as 25113 oorweeg en 'n ewekansige bronpoort genereer, byvoorbeeld nommer XNUMX.
Vervolgens sal die stelsel die bestemmingspoort by die pakkie voeg, in hierdie geval poort 21, want die toepassing wat probeer om aan hierdie FTP-bediener te koppel, weet dat dit FTP-verkeer moet stuur.
Volgende, ons rekenaar sê: "Ok, my IP-adres is 10.1.1.10, en ek moet die IP-adres 30.1.1.10 kontak." Albei hierdie adresse is ook by die pakkie ingesluit, wat 'n SYN-versoek vorm, en hierdie pakkie sal nie verander tot die einde van die verbinding nie.
Ek wil hê jy moet uit hierdie video verstaan hoe data oor die netwerk beweeg. Wanneer ons versoekende rekenaar die bron-IP en die bestemming-IP sien, verstaan dit dat die bestemmingsadres nie op hierdie plaaslike netwerk is nie. Ek het vergeet om te sê dat dit almal /24 IP-adresse is. As jy dus na die /24 IP-adresse kyk, sal jy besef dat rekenaars 10.1.1.10 en 30.1.1.10 nie op dieselfde netwerk is nie. Dus, die versoekende rekenaar verstaan dat om hierdie netwerk te verlaat, dit die poort 10.1.1.1 moet kontak, wat op een van die roeteerder se koppelvlakke opgestel is. Dit weet dat dit na 10.1.1.1 behoort te gaan en ken sy MAC-adres 1111, maar ken nie die MAC-adres van die poort 10.1.1.1 nie. Wat doen hy? Dit stuur 'n ARP-uitsaaiversoek uit wat alle toestelle op die netwerk sal ontvang, maar slegs die router met IP-adres 10.1.1.1 sal daarop reageer.
Die router sal reageer met sy AAAA MAC-adres, en beide bron- en bestemmings-MAC-adresse sal ook in hierdie raam geplaas word. Sodra die raam gereed is, sal 'n CRC-data-integriteitkontrole, wat 'n kontrolesomalgoritme is om foute op te spoor, uitgevoer word voordat die netwerk verlaat word.
CRC beteken dat hierdie hele raam, van SYN tot die laaste MAC-adres, deur 'n hash-algoritme uitgevoer word, sê MD5, wat 'n hash-waarde tot gevolg het. Die hash-waarde, of MD5-kontrolesom, word dan aan die begin van die raam geplaas.
Ek het dit FCS/CRC genoem omdat FCS 'n raamkontrolevolgorde is, 'n CRC-waarde van vier grepe. Sommige mense gebruik die FCS-benaming en sommige gebruik die CRC-benaming, so ek het net albei benamings gelys. Maar basies is dit net 'n hash-waarde. Dit is nodig om seker te maak dat alle data wat oor die netwerk kom, nie foute bevat nie. Daarom, wanneer hierdie raam die router bereik, is die eerste ding wat die router sal doen, om die kontrolesom self te bereken en dit te vergelyk met die FCS- of CRC-waarde wat die ontvangde raam bevat. Hy sal dus kan kontroleer dat die data wat oor die netwerk ontvang word nie foute bevat nie, waarna hy die kontrolesom van die raam sal verwyder.
Vervolgens sal die router na die MAC-adres kyk en sê "OK, MAC-adres AAAA beteken die raam is vir my" en verwyder die MAC-deel van die raam.
As hy na die bestemmings-IP-adres 30.1.1.10 kyk, sal hy verstaan dat hierdie pakkie nie aan hom gerig is nie en verder deur die router moet gaan.
Nou "dink" die router oor hoe hy moet sien waar die netwerk met die adres 30.1.1.10 geleë is. Ons het nog nie na die volledige konsep van roetering gekyk nie, maar ons weet wel dat roeteerders 'n roetetabel het. Hierdie tabel het 'n inskrywing vir die netwerk met die adres 30.1.1.0. Soos u onthou, is dit nie 'n gasheer-IP-adres nie, maar 'n netwerk-ID. Die router sal “dink” dat dit moontlik is om die adres 30.1.1.0/24 te bereik deur deur die router 20.1.1.2 te gaan.
Hoe weet hy dit, vra jy dalk? Hou net in gedagte dat dit óf van die roeteprotokolle óf van jou instellings daarvan sal weet as jy 'n statiese roete as 'n administrateur opgestel het. Maar in elk geval, hierdie router se roetetabel bevat die korrekte inskrywing, so dit weet dit moet hierdie pakkie na 20.1.1.2 stuur. As ons aanvaar dat die router reeds die bestemmings-MAC-adres ken, sal ons net voortgaan om die pakkie aan te stuur. As hy nie hierdie adres ken nie, sal hy weer ARP begin, die MAC-adres van die router 20.1.1.2 kry, en die proses om die raam te stuur, sal weer voortgaan.
Dus, ons neem aan dat dit reeds die MAC-adres ken, dan sal ons die bron-MAC-adres van BBB en die bestemmings-MAC-adres van CCC hê. Die router bereken weer die FCS/CRC en plaas dit aan die begin van die raam.
Dit stuur dan hierdie raam oor die netwerk, die raam bereik die router 20.1.12, wat die kontrolesom nagaan, seker maak dat die data nie korrup is nie, en die FCS/CRC verwyder. Dit "afkort" dan die MAC-adresse, kyk na die bestemming en sien dat dit 30.1.1.10 is. Dit weet dat hierdie adres aan sy koppelvlak gekoppel is. Dieselfde raamproses word herhaal, die router voeg die bron- en bestemming MAC-adreswaardes by, doen die hash, heg die hash aan die raam en stuur dit oor die netwerk.
Ons bediener, nadat ons uiteindelik 'n SYN-versoek ontvang het wat daaraan gerig is, gaan die hash-kontrolesom na, en as die pakkie nie foute bevat nie, vee dit die hash uit. Dit verwyder dan die MAC-adresse, kyk na die IP-adres en besef dat hierdie pakkie daaraan gerig is.
Daarna kap dit die IP-adresse af wat verband hou met die derde vlak van die OSI-model en kyk na die poortnommers.
Dit sien poort 21, wat FTP-verkeer beteken, sien SYN, en verstaan dus dat iemand daarmee probeer kommunikeer.
Nou, gebaseer op wat ons oor die handdruk geleer het, skep bediener 30.1.1.10 'n SYN/ACK-pakkie en stuur dit terug na rekenaar 10.1.1.10. By ontvangs van hierdie pakkie sal toestel 10.1.1.10 'n ACK skep, dit deur die netwerk stuur op dieselfde manier as 'n SYN pakkie, en by ontvangs van die ACK deur die bediener, sal die verbinding tot stand gebring word.
Een ding wat jy moet weet, is dat dit alles in minder as 'n sekonde gebeur. Dit is 'n baie, baie vinnige proses wat ek probeer vertraag het sodat jy alles kan verstaan.
Ek hoop jy vind wat jy uit hierdie tutoriaal geleer het nuttig. As jy enige vrae het, skryf asseblief vir my by [e-pos beskerm] of laat vrae onder hierdie video.
Vanaf die volgende les sal ek 3 van die interessantste vrae van YouTube kies, wat ek aan die einde van elke video sal oorweeg. Van nou af sal ek 'n "Beste Vrae"-afdeling hê, so ek sal 'n vraag saam met jou naam plaas en dit regstreeks beantwoord. Ek dink dit sal voordelig wees.
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, 30% afslag vir Habr-gebruikers op 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps gratis tot die somer wanneer jy vir 'n tydperk van ses maande betaal, kan jy bestel .
Dell R730xd 2 keer goedkoper? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com