Mielőtt elkezdenénk a mai videós bemutatót, szeretnék köszönetet mondani mindenkinek, aki hozzájárult kurzusom YouTube-on való népszerűségéhez. Amikor körülbelül 8 hónappal ezelőtt elkezdtem, nem számítottam ekkora sikerre - ma már 312724 11208-en nézték meg az óráimat, 7 6 feliratkozóm van. Álmomban sem gondoltam volna, hogy ez a szerény kezdet ilyen magasságokat ér el. De ne vesztegessük az időt, és térjünk közvetlenül a mai leckére. Ma pótolni fogjuk azokat a hiányosságokat, amelyek az elmúlt 3 videó leckében előfordultak. Bár ma még csak a 3. nap van, a XNUMX. nap XNUMX videóleckére volt lebontva, így ma valójában a nyolcadik videóleckét nézi meg.
Ma 3 fontos témával foglalkozunk: DHCP, TCP szállítás és a leggyakoribb portszámok. Az IP-címekről már beszéltünk, és az IP-címek beállításának egyik legfontosabb tényezője a DHCP.
A DHCP a Dynamic Host Configuration Protocol rövidítése, és ez egy olyan protokoll, amely segít a gazdagépek IP-címeinek dinamikus konfigurálásában. Tehát mindannyian láttuk ezt az ablakot. Amikor az „IP-cím automatikus beszerzése” lehetőségre kattint, a számítógép egy DHCP-kiszolgálót keres, amely ugyanazon az alhálózaton van konfigurálva, és különféle csomagokat és kéréseket küld az IP-címre. A DHCP protokoll 6 üzenettel rendelkezik, amelyek közül 4 kritikus az IP-cím hozzárendeléséhez.
Az első üzenet egy DHCP DISCOVERY üzenet. A DHCP-felderítési üzenet hasonló az üdvözlő üzenethez. Amikor egy új eszköz csatlakozik a hálózathoz, megkérdezi, hogy van-e DHCP-kiszolgáló a hálózaton.
A dián látható egy üzenetszórási kérelemnek tűnik, ahol az eszköz felveszi a kapcsolatot a hálózat összes eszközével, DHCP-kiszolgálót keresve. Mint mondtam, ez egy broadcast kérés, tehát a hálózaton lévő összes eszköz hallja.
Ha van DHCP szerver a hálózaton, akkor csomagot küld - DHCP OFFER ajánlatot. A javaslat azt jelenti, hogy a DHCP-szerver egy felderítési kérésre válaszul konfigurációt küld a kliensnek, és arra kéri a klienst, hogy fogadjon el egy adott IP-címet.
A DHCP-szerver lefoglal egy IP-címet, jelen esetben a 192.168.1.2-t, nem adja meg, hanem lefoglalja ezt a címet az eszköz számára. Az ajánlatcsomag ugyanakkor tartalmazza a DHCP szerver saját IP címét is.
Ha egynél több DHCP-szerver van ezen a hálózaton, egy másik DHCP-szerver a kliens üzenetszórási kérésének fogadásakor szintén felajánlja neki az IP-címét, például 192.168.1.50. Nem gyakori, hogy ugyanazon a hálózaton két különböző DHCP-kiszolgáló van konfigurálva, de néha előfordul. Tehát amikor egy DHCP-ajánlatot küldenek egy kliensnek, az 2 DHCP-ajánlatot kap, és most el kell döntenie, hogy melyik DHCP-ajánlatot kívánja elfogadni.
Tegyük fel, hogy az ügyfél elfogadja az első kérelmet. Ez azt jelenti, hogy a kliens egy DHCP REQUEST kérést küld, amely szó szerint azt mondja: "Elfogadom a 192.168.1.2 DHCP szerver által felajánlott 192.168.1.1 IP-címet."
A kérés beérkezésekor a 192.168.1.1 DHCP szerver „oké, elismerem”, azaz nyugtázza a kérést, és elküldi ezt a DHCP ACK-t a kliensnek. De emlékszünk arra, hogy egy másik DHCP-kiszolgáló 1.50-es IP-címet foglalt le a kliens számára. Miután megkapta egy ügyfél üzenetszórási kérését, tudni fogja a hibáról, és visszahelyezi az IP-címet a készletbe, hogy egy másik ügyfélhez rendelhesse, ha újabb kérést kap.
Ez az a 4 kritikus üzenet, amelyet a DHCP IP-címek hozzárendelésekor kicserél. Ezután a DHCP-nek 2 további információs üzenete van. A kliens információs üzenetet ad ki, ha több információt igényel, mint amennyit a második lépésben a DHCP OFFER záradékban kapott. Ha a szerver nem adott meg elegendő információt a DHCP-ajánlatban, vagy ha a kliensnek több információra van szüksége, mint amit az ajánlati csomag tartalmazott, akkor további DHCP-információkat kér. Van még egy üzenet, amit a kliens küld a szervernek – ez a DHCP RELEASE. Értesíti, hogy az ügyfél fel akarja adni a meglévő IP-címét.
Leggyakrabban azonban az történik, hogy a felhasználó lekapcsolja a hálózatot, mielőtt a kliensnek ideje lenne DHCP RELEASE üzenetet küldeni a szervernek. Ez akkor történik, amikor kikapcsolja a számítógépet, amit mi meg is teszünk. Ebben az esetben a hálózati kliensnek vagy számítógépnek egyszerűen nincs ideje tájékoztatni a szervert a használt cím kiadásáról, így a DHCP RELEASE nem kötelező lépés. Az IP-cím megszerzéséhez szükséges lépések a következők: DHCP-felderítés, DHCP-ajánlat, DHCP-kérés és DHCP-kézfogás.
A következő leckék egyikében elmondom, hogyan konfiguráljuk a DHCP-kiszolgálót DNCP-készlet létrehozásakor. A pooling alatt azt értjük, hogy Ön megmondja a szervernek, hogy rendeljen hozzá IP-címeket a 192.168.1.1 és 192.168.1.254 közötti tartományban. Így a DHCP szerver létrehoz egy készletet, 254 IP-címet helyez el benne, és csak ebből a készletből tud majd címeket rendelni a hálózaton lévő kliensekhez. Tehát ez olyan, mint egy adminisztrációs beállítás, amelyet a felhasználó tehet meg.
Most nézzük a TCP átvitelt. Nem tudom, ismeri-e a képen látható "telefont", de gyerekkorunkban ezeket a zsinórral összekötött bádogdobozokat használtuk, hogy beszélgessünk egymással.
Sajnos a mai generáció nem engedhet meg magának ekkora „luxust”. Úgy értem, ma a gyerekek egy éves koruktól a tévé előtt állnak, PSP-vel játszanak, és ez talán vitatható, de szerintem a legjobb gyerekkorunk volt, valójában kimentünk a szabadba játszani, és a mai gyerekeket nem lehet elrángatni a kanapétól. .
A fiam még csak egy éves, és már látom, hogy iPad rabja, vagyis még nagyon kicsi, de szerintem a mai gyerekek már úgy születnek, hogy tudják, hogyan kell kezelni az elektronikus kütyüket. Szóval azt akartam mondani, hogy gyerekként, amikor játszottunk, lyukakat csináltunk a bádogdobozokon, és amikor madzaggal megkötöttük és belemondtunk valamit az egyik dobozba, akkor a másik végén az ember hallotta, mit mondanak. neki egyszerűen úgy, hogy a dobozt a füléhez teszi. Tehát nagyon hasonlít a hálózati kapcsolathoz.
Manapság még a TCP-átviteleknek is rendelkezniük kell olyan kapcsolattal, amelyet a tényleges adatátvitel megkezdése előtt létre kell hozni. Amint azt az előző leckékben tárgyaltuk, a TCP kapcsolat-orientált átvitel, míg az UDP kapcsolat-orientált átvitel. Mondhatnánk, hogy az UDP az a hely, ahol eldobom a labdát, és rajtad múlik, hogy meg tudod-e fogni. Akár készen állsz rá, akár nem, az nem az én problémám, egyszerűen elhagyom őt.
A TCP inkább olyan, mint amikor beszélsz egy sráccal, és előre figyelmezteted, hogy labdát fogsz dobni, így kötelék alakul ki, majd úgy dobod a labdát, hogy a partnered nagyobb valószínűséggel készen álljon elkapni. Tehát a TCP ténylegesen felépíti a kapcsolatot, majd megkezdi a tényleges átvitelt.
Nézzük meg, hogyan hoz létre egy ilyen kapcsolatot. Ez a protokoll háromirányú kézfogást használ a kapcsolat létrehozásához. Ez nem túl technikai kifejezés, de régóta használják a TCP kapcsolat leírására. A küldő eszköz háromirányú kézfogást kezdeményez, a kliens SYN jelzővel ellátott csomagot küld a szervernek.
Tegyük fel, hogy az előtérben lévő lány, akinek az arcát látjuk, az A eszköz, a háttérben lévő lány, akinek az arca nem látható, a B eszköz. A lány SYN csomagot küld B lánynak, és ő azt mondja: „Nagyszerű, ki- akkor kommunikálni akar velem. Tehát azt kell válaszolnom, hogy készen állok a kommunikációra!” Hogyan kell csinálni? Egyszerűen visszaküldhet egy másik SYN-csomagot, majd egy ACK-t, amely jelzi az eredeti SYN-csomag fogadását. De ahelyett, hogy külön küldené az ACK-t, a szerver közös csomagot alkot, amely tartalmazza a SYN-t és az ACK-t, és továbbítja azt a hálózaton.
Tehát ezen a ponton az A eszköz SYN csomagot küldött és SYN/ACK csomagot kapott vissza. Most az A eszköznek ACK csomagot kell küldenie a B eszköznek, azaz meg kell erősítenie, hogy megkapta a B eszköztől a kommunikáció létrehozásához szükséges hozzájárulást. Így mindkét eszköz SYN és ACK csomagokat kapott, és most már elmondhatjuk, hogy a kapcsolat létrejött, vagyis egy 3 fokozatú kézfogás TCP protokoll segítségével történt.
Ezután a TCP Windowing technológiával fogunk foglalkozni. Egyszerűen fogalmazva, ez a TCP/IP-ben használt módszer a küldő és a fogadó képességeinek egyeztetésére.
Tegyük fel, hogy a Windows rendszerben egy nagy, mondjuk 2 GB méretű fájlt próbálunk átvinni egyik meghajtóról a másikra. Az átvitel legelején a rendszer értesít bennünket, hogy a fájlátvitel körülbelül 1 évig tart. De néhány másodperccel később a rendszer kijavítja magát, és azt mondja: "Ó, várj egy percet, azt hiszem, ez körülbelül 6 hónapot vesz igénybe, nem egy évet." Eltelik még egy kis idő, és a Windows azt mondja: „Azt hiszem, 1 hónapon belül át tudom vinni a fájlt.” Ezt követi az „1 nap”, „6 óra”, „3 óra”, „1 óra”, „20 perc”, „10 perc”, „3 perc” üzenet. Valójában a teljes fájlátviteli folyamat mindössze 3 percet vesz igénybe. Hogy történt ez? Kezdetben, amikor az eszköz megpróbál kommunikálni egy másik eszközzel, egy csomagot küld, és megerősítésre vár. Ha a készülék sokáig vár a megerősítésre, azt gondolja: „ha 2 GB adatot kell ilyen sebességgel átvinnem, az körülbelül 2 évig tart.” Egy idő után a készülék ACK-t kap, és azt gondolja: „Rendben, küldtem egy csomagot, és kaptam egy ACK-t, így a címzett 1 csomagot fogadhat. Most megpróbálok 10 csomagot küldeni neki egy helyett." A küldő 10 csomagot küld, majd egy idő után ACK visszaigazolást kap a fogadó készüléktől, ami azt jelenti, hogy a címzett a következő, 11. csomagra vár. A feladó így gondolja: „nagyszerű, mivel a címzett egyszerre 10 csomagot kezelt, most megpróbálok neki tíz helyett 100-at küldeni.” 100 csomagot küld, és a címzett azt válaszolja, hogy megkapta, és most 101 csomagra vár. Így az idő múlásával a továbbított csomagok száma növekszik.
Ez az oka annak, hogy a fájlmásolási idő gyorsan csökken az eredetileg közölthez képest – ez a nagy mennyiségű adat átvitelének megnövekedett képességének köszönhető. Eljön azonban az a pont, amikor az átviteli mennyiség további növelése lehetetlenné válik. Tegyük fel, hogy 10000 9000 csomagot küldött, de a vevő eszköz puffere csak 9000 9001-et tud fogadni. Ebben az esetben a vevő ACK-t küld a következő üzenettel: "9000 csomagot kaptam, és készen állok 9000 fogadására." Ebből a küldő arra következtet, hogy a fogadó eszköz pufferének kapacitása mindössze 9000, vagyis mostantól legfeljebb 3 csomagot küldök egyszerre. Ebben az esetben a küldő gyorsan kiszámítja, hogy mennyi időbe telik a fennmaradó adatmennyiség XNUMX csomagos részletekben történő átviteléhez, és XNUMX percet ad. Ez a három perc a tényleges adásidő. Ezt teszi a TCP Windowing.
Ez azon forgalomszabályozási mechanizmusok egyike, ahol a küldő eszköz végül megérti, hogy mi a tényleges hálózati kapacitás. Felmerülhet benned a kérdés, hogy miért nem tudnak előre megegyezni, hogy mekkora a fogadó készülék kapacitása? Az a tény, hogy ez technikailag lehetetlen, mert különböző típusú eszközök vannak a hálózaton. Tegyük fel, hogy iPad-ed van, és más az adatátviteli/fogadási sebessége, mint egy iPhone-nak, lehet, hogy más típusú telefonjaid vannak, vagy esetleg nagyon régi számítógéped van. Ezért mindenkinek más a hálózati sávszélessége.
Ezért fejlesztették ki a TCP Windowing technológiát, amikor az adatátvitel alacsony sebességgel vagy minimális számú csomag átvitelével kezdődik, fokozatosan növelve a forgalmi „ablakát”. Elküld egy csomagot, 5 csomagot, 10 csomagot, 1000 csomagot, 10000 XNUMX csomagot, és lassan kinyitja azt az ablakot, amíg a „nyitás” el nem éri az adott időszakban küldött forgalom maximális mennyiségét. Így a Windowing fogalma a TCP protokoll működésének része.
Ezután a leggyakoribb portszámokat nézzük meg. A klasszikus helyzet az, amikor van 1 fő szervere, esetleg egy adatközpontja. Tartalmaz egy fájlszervert, webszervert, levelezőszervert és DHCP-szervert. Most, ha az egyik ügyfélszámítógép kapcsolatba lép a kép közepén található adatközponttal, elkezdi a fájlszerver-forgalmat küldeni az ügyféleszközöknek. Ez a forgalom piros színnel jelenik meg, és egy adott alkalmazáshoz egy adott porton továbbítódik egy adott szerverről.
Honnan tudta a szerver, hogy bizonyos forgalomnak hova kell mennie? Ezt a cél port számából tudja meg. Ha megnézi a keretet, látni fogja, hogy minden adatátvitelnél szerepel a cél port száma és a forrás port száma. Látható, hogy a kék és a piros forgalom, valamint a kék forgalom webszerver forgalom, mindkettő ugyanarra a fizikai szerverre megy, amelyre különböző szerverek vannak telepítve. Ha ez egy adatközpont, akkor virtuális szervereket használ. Szóval honnan tudták, hogy a piros forgalomnak vissza kellett mennie arra a bal oldali laptopra, amelyen az IP-címe van? Ezt a portszámoknak köszönhetően tudják. Ha a Wikipédia „TCP- és UDP-portok listája” című cikkére hivatkozik, látni fogja, hogy az összes szabványos portszámot felsorolja.
Ha lefelé görgetsz ezen az oldalon, láthatod, mekkora ez a lista. Körülbelül 61 000 számot tartalmaz. Az 1 és 1024 közötti portszámok a leggyakoribb portszámok. Például a 21-es/TCP port az ftp-parancsok küldésére szolgál, a 22-es az ssh-t, a 23-as port a Telnet-et, vagyis a titkosítatlan üzenetek küldését. A nagyon népszerű 80-as port HTTP-n keresztül szállít adatokat, míg a 443-as port titkosított adatokat hordoz HTTPS-en keresztül, ami hasonló a HTTP biztonságos verziójához.
Egyes portok TCP-nek és UDP-nek is vannak dedikálva, mások pedig különböző feladatokat látnak el attól függően, hogy a kapcsolat TCP vagy UDP. Tehát hivatalosan a 80-as TCP-portot használják a HTTP-hez, és nem hivatalosan a 80-as UDP-portot a HTTP-hez, de egy másik HTTP-protokoll - QUIC - alatt.
Ezért a TCP-ben a portszámok nem mindig ugyanazt a célt szolgálják, mint az UDP-ben. Ezt a listát nem kell fejből megtanulni, lehetetlen megjegyezni, de tudnia kell néhány népszerű és leggyakoribb portszámot. Mint mondtam, ezeknek a portoknak némelyikének hivatalos célja van, ami a szabványokban le van írva, és néhánynak nem hivatalos célja van, mint a Chromium esetében.
Tehát ez a táblázat felsorolja az összes gyakori portszámot, és ezek a számok a forgalom küldésére és fogadására szolgálnak bizonyos alkalmazások használatakor.
Most nézzük meg, hogy az általunk ismert kevés információ alapján hogyan mozognak az adatok a hálózaton. Tegyük fel, hogy a 10.1.1.10-es számítógép kapcsolatba akar lépni ezzel a számítógéppel vagy a 30.1.1.10-es címmel rendelkező szerverrel. Az egyes eszközök IP-címe alatt a MAC-címük található. Példát adok egy olyan MAC-címre, amely csak az utolsó 4 karakterből áll, de a gyakorlatban ez egy 48 bites hexadecimális szám, amely 12 karakterből áll. Mivel ezek a számok mindegyike 4 bitből áll, 12 hexadecimális számjegy 48 bites számot jelent.
Mint tudjuk, ha ez az eszköz fel akar lépni ezzel a szerverrel, akkor először a 3-utas kézfogás első lépését kell megtenni, vagyis egy SYN csomagot küldeni. A kérés elküldésekor a 10.1.1.10 számítógép megadja a forrásport számát, amelyet a Windows dinamikusan hoz létre. A Windows véletlenszerűen választ ki egy portszámot 1 és 65,000 1 között. Mivel azonban az 1024-től 25000-ig terjedő kezdőszámok széles körben ismertek, ebben az esetben a rendszer figyelembe veszi a 25113 XNUMX-nél nagyobb számokat, és véletlenszerű forrásportot hoz létre, például a XNUMX-as számot.
Ezután a rendszer hozzáad egy célportot a csomaghoz, jelen esetben ez a 21-es port, mivel az ehhez az FTP-kiszolgálóhoz kapcsolódni próbáló alkalmazás tudja, hogy FTP-forgalmat kell küldenie.
Ezután a számítógépünk azt mondja: „Rendben, az IP-címem 10.1.1.10, és fel kell vennem a kapcsolatot a 30.1.1.10-es IP-címmel.” Mindkét cím benne van a csomagban, hogy SYN kérést hozzon létre, és ez a csomag a kapcsolat végéig nem változik.
Szeretném, ha ebből a videóból megértené, hogyan mozognak az adatok a hálózaton. Amikor a kérést küldő számítógépünk látja a forrás IP-címét és a cél IP-címét, akkor megérti, hogy a célcím nem az adott helyi hálózaton található. Elfelejtettem mondani, hogy ezek mind /24 IP-címek. Tehát ha megnézi a /24 IP-címeket, rájön, hogy a 10.1.1.10 és a 30.1.1.10 számítógépek nem ugyanazon a hálózaton vannak. Így a kérést küldő számítógép megérti, hogy a hálózat elhagyásához kapcsolatba kell lépnie a 10.1.1.1 átjáróval, amely az útválasztó interfészeinek egyikén van konfigurálva. Tudja, hogy a 10.1.1.1-re kell mennie, és tudja a 1111-es MAC-címét, de nem ismeri a 10.1.1.1-es átjáró MAC-címét. Mit csinál? Egy broadcast ARP kérést küld, amit a hálózaton lévő összes eszköz fogad, de csak a 10.1.1.1 IP-című router válaszol rá.
Az útválasztó az AAAA MAC-címével válaszol, és a forrás és a cél MAC-címe is ebbe a keretbe kerül. Ha a keret készen áll, a hálózat elhagyása előtt egy CRC adatintegritás-ellenőrzést hajtanak végre, amely egy algoritmus egy ellenőrző összeg megtalálására a hibák észleléséhez.
A ciklikus redundancia CRC azt jelenti, hogy ezt a teljes keretet, a SYN-től az utolsó MAC-címig, egy hash-algoritmuson, mondjuk az MD5-ön keresztül futtatják, ami egy hash értéket eredményez. A hash értéke vagy az MD5 ellenőrző összeg ezután a keret elejére kerül.
FCS/CRC-nek neveztem el, mert az FCS egy Frame Check Sequence, egy négybájtos CRC-érték. Vannak, akik az FCS elnevezést használják, és vannak, akik a CRC megjelölést, ezért csak mindkét elnevezést feltüntettem. De alapvetően ez csak egy hash érték. Meg kell győződni arról, hogy a hálózaton keresztül kapott összes adat nem tartalmaz hibát. Ezért, amikor ez a keret eléri az útválasztót, az első dolga az útválasztó magának az ellenőrző összegnek a kiszámítása és összehasonlítása a fogadott keretben található FCS vagy CRC értékkel. Így ellenőrizheti, hogy a hálózaton keresztül kapott adatok nem tartalmaznak-e hibákat, majd eltávolítja az ellenőrző összeget a keretből.
Ezután az útválasztó megnézi a MAC-címet, és azt mondja: „Rendben, az AAAA MAC-cím azt jelenti, hogy a keret nekem van címezve”, és törli a keretnek a MAC-címeket tartalmazó részét.
Ha megnézi a 30.1.1.10 cél IP-címet, megérti, hogy ez a csomag nem neki szól, és tovább kell haladnia az útválasztón.
Most a router „gondolja”, hogy látnia kell, hol található a 30.1.1.10 címû hálózat. Még nem foglalkoztunk az útválasztás teljes fogalmával, de tudjuk, hogy az útválasztóknak van útválasztási táblázatuk. Ez a táblázat egy bejegyzést tartalmaz a 30.1.1.0 címû hálózathoz. Mint emlékszel, ez nem a gazdagép IP-címe, hanem a hálózati azonosító. A router „gondolni fogja”, hogy a 30.1.1.0/24 címet elérheti a 20.1.1.2 routeren keresztül.
Megkérdezheti, honnan tudja ezt? Ne feledje, hogy ezt vagy az útválasztási protokollokból, vagy a beállításokból fogja tudni, ha Ön rendszergazdaként statikus útvonalat állított be. De mindenesetre ennek a routernek az útválasztási táblázata tartalmazza a helyes bejegyzést, tehát tudja, hogy el kell küldenie ezt a csomagot a 20.1.1.2-nek. Feltéve, hogy az útválasztó már ismeri a cél MAC-címét, egyszerűen folytatjuk a csomag továbbítását. Ha nem ismeri ezt a címet, újra elindítja az ARP-t, megkapja az útválasztó 20.1.1.2-es MAC-címét, és a keret küldésének folyamata újra folytatódik.
Tehát feltételezzük, hogy már ismeri a MAC-címet, akkor meglesz a BBB forrás MAC-címe és a CCC-cél MAC-címe. A router ismét kiszámítja az FCS/CRC-t, és a keret elejére helyezi.
Ezután ezt a keretet elküldi a hálózaton, a keret eléri a 20.1.12-es útválasztót, ellenőrzi az ellenőrző összeget, megbizonyosodik arról, hogy az adatok nem sérültek-e, és törli az FCS/CRC-t. Ezután "csonkolja" a MAC-címeket, megnézi a célt és látja, hogy az 30.1.1.10. Tudja, hogy ez a cím kapcsolódik az interfészéhez. Ugyanez a keretképzési folyamat megismétlődik, az útválasztó hozzáadja a forrás és a cél MAC-cím értékeit, elvégzi a kivonatolást, csatolja a hash-t a kerethez, és elküldi a hálózaton.
Szerverünk, miután végre megkapta a neki címzett SYN kérést, ellenőrzi a hash ellenőrző összeget, és ha a csomag nem tartalmaz hibát, törli a hash-t. Aztán eltávolítja a MAC-címeket, megnézi az IP-címet, és rájön, hogy ez a csomag neki szól.
Ezt követően csonkolja az OSI modell harmadik rétegéhez kapcsolódó IP-címeket, és megnézi a portszámokat.
Látja a 21-es portot, ami FTP-forgalmat jelent, látja a SYN-t, és ezért megérti, hogy valaki kommunikálni próbál vele.
Most a kézfogásról tanultak alapján a 30.1.1.10 szerver létrehoz egy SYN/ACK csomagot, és visszaküldi a 10.1.1.10 számítógépre. A csomag fogadásakor a 10.1.1.10-es eszköz létrehoz egy ACK-t, amelyet ugyanúgy továbbít a hálózaton, mint egy SYN-csomagot, és miután a szerver megkapta az ACK-t, a kapcsolat létrejön.
Egy dolgot tudnod kell, hogy mindez kevesebb, mint egy másodperc alatt megtörténik. Ez egy nagyon-nagyon gyors folyamat, amit igyekeztem lassítani, hogy minden világos legyen számodra.
Remélem, hasznosnak találja az oktatóanyagban tanultakat. Ha bármilyen kérdése van, írjon nekem a címre [e-mail védett] vagy hagyjon kérdéseket a videó alatt.
A következő leckétől kezdve kiválasztom a 3 legérdekesebb kérdést a YouTube-ról, amelyeket minden videó végén áttekintek. Mostantól lesz egy "Legnépszerűbb kérdések" rovatom, így felteszek egy kérdést a neveddel együtt, és élőben válaszolok rá. Szerintem ez előnyös lesz.
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, 30% kedvezmény a Habr felhasználóknak a belépő szintű szerverek egyedülálló analógjára, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
VPS (KVM) E5-2650 v4 (6 mag) 10 GB DDR4 240 GB SSD 1 Gbps nyárig ingyenes ha fizet egy hat hónapos időszakra, akkor rendelhet .
Dell R730xd kétszer olcsóbb? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com