Antaŭ ol ni komencas la hodiaŭan videolerniilon, mi volas danki ĉiujn, kiuj kontribuis al la populareco de mia kurso ĉe Jutubo. Kiam mi komencis ĝin antaŭ ĉirkaŭ 8 monatoj, mi ne atendis tian sukceson - hodiaŭ miajn lecionojn rigardis 312724 11208 homoj, mi havas 7 6 abonantojn. Mi neniam sonĝis, ke ĉi tiu humila komenco atingos tiajn altojn. Sed ni ne perdu tempon kaj ni iru rekte al la hodiaŭa leciono. Hodiaŭ ni plenigos la mankojn, kiuj okazis en la lastaj 3 videolecionoj. Kvankam hodiaŭ estas nur tago 3, tago XNUMX estis dividita en XNUMX videolecionoj, do hodiaŭ vi efektive spektos la okan videolecionon.
Hodiaŭ ni kovros 3 gravajn temojn: DHCP, TCP-transporto, kaj la plej oftaj havenaj nombroj. Ni jam parolis pri IP-adresoj, kaj unu el la plej gravaj faktoroj en IP-adresa agordo estas DHCP.
DHCP signifas Dynamic Host Configuration Protocol kaj ĝi estas protokolo kiu helpas dinamike agordi IP-adresojn por gastigantoj. Do ni ĉiuj vidis ĉi tiun fenestron. Kiam vi alklakas la opcion "Akiri IP-adreson aŭtomate", la komputilo serĉas DHCP-servilon kiu estas agordita en la sama subreto kaj sendas diversajn pakaĵojn kaj petojn por la IP-adreso. La DHCP-protokolo havas 6 mesaĝojn, el kiuj 4 estas kritikaj por atribui IP-adreson.
La unua mesaĝo estas DHCP DISCOVERY-mesaĝo. La DHCP-malkovra mesaĝo similas al salutmesaĝo. Kiam nova aparato aliĝas al la reto, ĝi demandas ĉu estas DHCP-servilo en la reto.
Kion vi vidas en la diapozitivo aspektas kiel elsenda peto, kie la aparato kontaktas ĉiujn aparatojn en la reto serĉante DHCP-servilon. Kiel mi diris, ĉi tio estas elsenda peto, do ĉiuj aparatoj en la reto povas aŭdi ĝin.
Se estas DHCP-servilo en la reto, ĝi sendas paketon - oferto de DHCP. Propono signifas, ke la DHCP-servilo, responde al malkovra peto, sendas agordon al la kliento, petante al la kliento akcepti specifan IP-adreson.
La DHCP-servilo rezervas IP-adreson, ĉi-kaze 192.168.1.2, ne provizas ĝin, sed prefere rezervas ĉi tiun adreson por la aparato. Samtempe, la ofertpakaĵo enhavas sian propran IP-adreson de la DHCP-servilo.
Se estas pli ol unu DHCP-servilo en ĉi tiu reto, alia DHCP-servilo, ricevinte la elsendopeton de la kliento, ankaŭ proponus al ĝi ĝian IP-adreson, ekzemple, 192.168.1.50. Ne kutimas havi du malsamajn DHCP-servilojn agordita sur la sama reto, sed foje ĝi okazas. Do kiam DHCP-oferto estas sendita al kliento, ĝi ricevas 2 DHCP-ofertojn kaj nun devas decidi kiun DHCP-oferton ĝi volas akcepti.
Ni supozu, ke la kliento akceptas la unuan aplikaĵon. Ĉi tio signifas, ke la kliento sendas peton pri DHCP, kiu laŭvorte diras "Mi akceptas la IP-adreson 192.168.1.2 ofertitan de la DHCP-servilo 192.168.1.1."
Ricevinte la peton, la 192.168.1.1 DHCP-servilo respondas "bone, mi konfesas ĝin", tio estas, ĝi agnoskas la peton kaj sendas ĉi tiun DHCP-ACK al la kliento. Sed ni memoras, ke alia DHCP-servilo rezervis IP-adreson de 1.50 por la kliento. Post kiam ĝi ricevas la elsendopeton de kliento, ĝi scios pri la fiasko kaj remetos tiun IP-adreson en la naĝejon por ke ĝi povu asigni ĝin al alia kliento se ĝi ricevas alian peton.
Ĉi tiuj estas la 4 kritikaj mesaĝoj, kiujn DHCP interŝanĝas dum asignado de IP-adresoj. Poste, DHCP havas 2 pliajn informmesaĝojn. Informmesaĝo estas elsendita de la kliento se ĝi postulas pli da informoj ol ĝi ricevis en la DHCP OFFER-paragrafo en la dua paŝo. Se la servilo ne disponigis sufiĉajn informojn en la DHCP-oferto, aŭ se la kliento bezonas pli da informoj ol kio estis enhavita en la ofertpako, ĝi petas pliajn DHCP-informojn. Estas unu plia mesaĝo, kiun la kliento sendas al la servilo - ĉi tio estas la DHCP-ELIBRO. Ĝi informas vin, ke la kliento volas liberigi sian ekzistantan IP-adreson.
Tamen, kio plej ofte okazas estas, ke la uzanto malkonektas de la reto antaŭ ol la kliento havas tempon sendi DHCP-ELIBON al la servilo. Ĉi tio okazas kiam vi malŝaltas la komputilon, kion ni faras. En ĉi tiu kazo, la retkliento, aŭ komputilo, simple ne havas tempon informi la servilon liberigi la uzitan adreson, do DHCP RELEASE ne estas bezonata paŝo. La necesaj paŝoj por akiri IP-adreson estas: DHCP-malkovro, DHCP-oferto, DHCP-peto kaj DHCP-manpremo.
En unu el la sekvaj lecionoj mi rakontos al vi kiel ni agordas DHCP-servilon dum kreado de DNCP-poolo. Kunigante ni volas diri, ke vi diras al la servilo atribui IP-adresojn en la intervalo 192.168.1.1 ĝis 192.168.1.254. Tiel, la DHCP-servilo kreos naĝejon, metos 254 IP-adresojn en ĝi, kaj povos asigni adresojn al klientoj en la reto nur de ĉi tiu naĝejo. Do ĉi tio estas io kiel administra agordo, kiun la uzanto povas fari.
Nun ni rigardu TCP-transdonon. Mi ne scias, ĉu vi konas la "telefonon" bildigita en la bildo, sed kiam ni estis infanoj, ni uzis ĉi tiujn ladskatolojn ligitajn per ŝnuro por paroli unu kun la alia.
Bedaŭrinde, la hodiaŭa generacio ne povas pagi tian "lukson". Mi volas diri, ke hodiaŭ infanoj estas antaŭ la televido ekde la aĝo de unu jaro, ili ludas PSP kaj eble ĉi tio estas diskutebla sed mi pensas, ke ni havis la plej bonan infanaĝon, ni fakte iris eksteren kaj ludis ludojn kaj la hodiaŭaj infanoj ne povas esti forigitaj de la sofo. .
Mia filo havas nur unu jaron kaj mi jam vidas, ke li estas toksomaniulo al la iPad, mi volas diri, ke li estas ankoraŭ tre juna sed mi pensas, ke la hodiaŭaj infanoj jam naskiĝas sciante pritrakti elektronikajn aparatojn. Do, mi volis diri, ke kiel infanoj, kiam ni ludis, ni farus truojn en ladskatoloj, kaj kiam ni ligis ilin per ŝnuro kaj diris ion en unu ladskatolon, tiam ĉe la alia fino la persono povis aŭdi tion, kio estas dirita. al li, simple metante la ladskatolon al lia orelo. Do ĝi estas tre simila al retkonekto.
Hodiaŭ, eĉ TCP-translokigoj devas havi konekton kiu devas esti establita antaŭ ol la fakta transdono de datumoj komenciĝas. Kiel ni diskutis en antaŭaj lecionoj, TCP estas konekt-orientita dissendo dum UDP estas konekt-orientita dissendo. Vi povus diri, ke UDP estas kie mi ĵetas la pilkon kaj dependas de vi vidi ĉu vi povas kapti ĝin. Ĉu vi pretas fari ĝin aŭ ne, ne estas mia problemo, mi nur forlasos lin.
TCP pli similas al vi parolanta kun ulo kaj avertante lin anticipe, ke vi ĵetos pilkon, do vi formas ligon, kaj tiam vi ĵetas la pilkon por ke via kunulo pli verŝajne pretas ĝin kapti. Do TCP efektive konstruas la konekton kaj poste komencas fari la realan transdonon.
Ni rigardu kiel ĝi kreas tian konekton. Ĉi tiu protokolo uzas 3-direktan manpremon por krei konekton. Ĉi tio ne estas tre teknika termino, sed ĝi estas delonge uzata por priskribi TCP-konekton. 3-direkta manpremo estas iniciatita per la senda aparato, kie la kliento sendas pakaĵeton kun SYN-flago al la servilo.
Ni diru, ke la knabino en la malfono, kies vizaĝon ni povas vidi, estas aparato A, kaj la knabino en la fono, kies vizaĝo ne estas videbla, estas aparato B. Knabino A sendas SYN-pakaĵon al knabino B, kaj ŝi diras: “bonege, kiu- do li volas komuniki kun mi. Do, mi devas respondi, ke mi estas preta komuniki!" Kiel fari ĝin? Oni povus simple resendi alian SYN-pakon kaj tiam ACK indikantan kvitancon de la origina SYN-pako. Sed anstataŭ sendi ACK-ojn aparte, la servilo formas oftan pakaĵeton enhavantan la SYN kaj ACK kaj elsendas ĝin tra la reto.
Do ĉe ĉi tiu punkto, aparato A sendis SYN-pakaĵon kaj ricevis reen SYN/ACK-pakaĵon. Nun aparato A devas sendi al aparato B ACK-pakaĵon, tio estas konfirmi, ke ĝi ricevis konsenton de aparato B por establi komunikadon. Tiel, ambaŭ aparatoj ricevis SYN kaj ACK-pakaĵojn, kaj nun ni povas diri, ke la konekto estis establita, tio estas, 3-etapa manpremo estis kompletigita per la TCP-protokolo.
Poste ni rigardos TCP Windowing-teknologion. Simple dirite, ĝi estas metodo uzata en TCP/IP por negoci la kapablojn de la sendinto kaj ricevilo.
Ni diru, ke en Vindozo ni provas translokigi grandan dosieron, ekzemple 2 GB en grandeco, de unu disko al alia. Je la komenco de la translokigo, la sistemo informos nin, ke la dosiera translokigo daŭros proksimume 1 jaro. Sed kelkajn sekundojn poste la sistemo korektos sin kaj diros: "Ho, atendu minuton, mi pensas, ke ĝi daŭros ĉirkaŭ 6 monatojn, ne unu jaron." Pasos iom pli da tempo kaj Vindozo diros: "Mi pensas, ke mi eble povos translokigi la dosieron en 1 monato." Ĉi tio estos sekvata de la mesaĝo "1 tago", "6 horoj", "3 horoj", "1 horo", "20 minutoj", "10 minutoj", "3 minutoj". Fakte, la tuta dosiera translokiga procezo daŭros nur 3 minutojn. Kiel ĉi tio okazis? Komence, kiam via aparato provas komuniki kun alia aparato, ĝi sendas unu paketon kaj atendas konfirmon. Se la aparato atendas longan tempon por konfirmo, ĝi pensas: "se mi devas transdoni 2 GB da datumoj kun ĉi tiu rapideco, ĝi daŭros ĉirkaŭ 2 jarojn." Post iom da tempo, via aparato ricevas ACK kaj pensas, "bone, mi sendis unu paketon kaj ricevis ACK, tial la ricevanto povas ricevi 1 paketon. Nun mi provos sendi al li 10 pakaĵojn anstataŭ unu." La sendinto sendas 10 pakaĵojn kaj post iom da tempo ricevas ACK-konfirmon de la ricevanta aparato, kio signifas, ke la ricevanto atendas la sekvan, 11-an pakaĵon. La sendinto opinias: "bonege, ĉar la ricevanto manipulis 10 paketojn samtempe, nun mi provos sendi al li 100 paketojn anstataŭ dek." Li sendas 100 pakaĵetojn, kaj la ricevanto respondas, ke li ricevis ilin kaj nun atendas 101 pakaĵetojn. Tiel, kun la tempo, la nombro da elsenditaj pakaĵetoj pliiĝas.
Tial vi vidas rapidan malkreskon en la dosierkopia tempo kompare kun tio, kio estis origine deklarita - tio estas pro la pliigita kapablo transdoni grandajn kvantojn da datumoj. Tamen, venas punkto, kiam pliaj pliiĝoj en dissenda volumo fariĝas neeblaj. Ni diru, ke vi sendis 10000 9000 pakaĵojn, sed la aparato-bufro de la ricevilo povas akcepti nur 9000 9001. En ĉi tiu kazo, la ricevilo sendas ACK kun la mesaĝo: "Mi ricevis 9000 9000 pakaĵojn kaj nun pretas ricevi 9000 3." El tio, la sendinto konkludas, ke la bufro de la riceva aparato havas kapablon de nur XNUMX, kio signifas, ke ekde nun mi sendos ne pli ol XNUMX paketojn samtempe. En ĉi tiu kazo, la sendinto rapide kalkulas la tempon, kiun ĝi bezonos por li transdoni la restantan kvanton da datumoj en partoj de XNUMX pakoj, kaj donas XNUMX minutojn. Ĉi tiuj tri minutoj estas la reala transdona tempo. Tion faras TCP Windowing.
Ĉi tiu estas unu el tiuj trafikaj streĉaj mekanismoj, kie la senda aparato fine komprenas, kio estas la fakta retokapacito. Vi eble demandas, kial ili ne povas anticipe interkonsenti pri kio estas la kapacito de la riceva aparato? La fakto estas, ke ĉi tio estas teknike neebla ĉar ekzistas malsamaj specoj de aparatoj en la reto. Ni diru, ke vi havas iPad kaj ĝi havas malsaman transdonon/ricevilon de datumoj ol iPhone, vi eble havas malsamajn tipojn de telefonoj aŭ eble vi havas tre malnovan komputilon. Tial ĉiuj havas malsaman retan bendolarĝon.
Tial TCP Windowing-teknologio estis evoluigita, kiam transdono de datumoj komenciĝas je malalta rapideco aŭ kun transdono de minimuma nombro da pakoj, iom post iom pliigante la trafikan "fenestron". Vi sendas unu paketon, 5 paketojn, 10 paketojn, 1000 paketojn, 10000 paketojn kaj malrapide malfermas tiun fenestron pli kaj pli, ĝis la "malfermo" atingas la maksimuman eblan volumon de trafiko sendita en specifa tempodaŭro. Tiel, la koncepto de Windowing estas parto de la operacio de la TCP-protokolo.
Poste ni rigardos la plej oftajn havennumerojn. La klasika situacio estas kiam vi havas 1 ĉefa servilo, eble datumcentro. Ĝi inkluzivas dosierservilon, retservilon, poŝtservilon kaj DHCP-servilon. Nun, se unu el la klientkomputiloj kontaktas la datumcentron, kiu situas en la mezo de la bildo, ĝi komencos sendi dosierservilan trafikon al klientaj aparatoj. Ĉi tiu trafiko estas montrita en ruĝa kaj estos elsendita sur specifa haveno por specifa aplikaĵo de specifa servilo.
Kiel la servilo sciis kien certa trafiko devus iri? Li lernas tion de la celhavennumero. Se vi rigardas la kadron, vi vidos, ke en ĉiu transdono de datumoj estas mencio de la celhavennombro kaj la fonta havenonumero. Vi povas vidi, ke la blua kaj ruĝa trafiko, kaj la blua trafiko estas retservila trafiko, ambaŭ iras al la sama fizika servilo, kiu havas malsamajn servilojn instalitajn. Se ĉi tio estas datumcentro, tiam ĝi uzas virtualajn servilojn. Do kiel ili sciis, ke la ruĝa trafiko devis reiri al tiu maldekstra tekkomputilo kun tiu IP-adreso? Ili scias tion danke al havenaj nombroj. Se vi referencas al la Vikipedio-artikolo "Listo de TCP kaj UDP-Havenoj", vi vidos, ke ĝi listigas ĉiujn normajn havennumerojn.
Se vi rulumas malsupren ĉi tiun paĝon, vi povas vidi kiom granda estas ĉi tiu listo. Ĝi enhavas proksimume 61 nombrojn. Havenombroj de 000 ĝis 1 estas konataj kiel la plej oftaj havennombroj. Ekzemple, haveno 1024/TCP estas por sendi ftp-komandojn, haveno 21 estas por ssh, haveno 22 estas por Telnet, tio estas, por sendi neĉifritajn mesaĝojn. La tre populara haveno 23 portas datumojn per HTTP, dum la haveno 80 portas ĉifritajn datumojn per HTTPS, kiu estas simila al la sekura versio de HTTP.
Kelkaj havenoj estas dediĉitaj al kaj TCP kaj UDP, kaj kelkaj plenumas malsamajn taskojn depende ĉu la ligo estas TCP aŭ UDP. Do, oficiale TCP-haveno 80 estas uzata por HTTP, kaj neoficiale UDP-haveno 80 estas uzata por HTTP, sed sub malsama HTTP-protokolo - QUIC.
Tial, havenaj nombroj en TCP ne ĉiam intencas fari la samon kiel en UDP. Vi ne bezonas parkere lerni ĉi tiun liston, ne eblas memori, sed vi devas scii kelkajn popularajn kaj plej oftajn havennumerojn. Kiel mi diris, iuj el ĉi tiuj havenoj havas oficialan celon, kiu estas priskribita en la normoj, kaj iuj havas neoficialan celon, kiel estas la kazo de Chromium.
Do, ĉi tiu tabelo listigas ĉiujn komunajn havennumerojn, kaj ĉi tiuj nombroj estas uzataj por sendi kaj ricevi trafikon kiam oni uzas specifajn aplikojn.
Nun ni rigardu kiel datumoj moviĝas tra la reto surbaze de kiaj malmulte da informoj ni scias. Ni diru, ke komputilo 10.1.1.10 volas kontakti ĉi tiun komputilon, aŭ ĉi tiun servilon, kiu havas la adreson 30.1.1.10. Sub la IP-adreso de ĉiu aparato estas ĝia MAC-adreso. Mi donas la ekzemplon de MAC-adreso kun nur la lastaj 4 signoj, sed praktike ĝi estas 48-bita deksesuma nombro kun 12 signoj. Ĉar ĉiu el ĉi tiuj nombroj konsistas el 4 bitoj, 12 deksesuma ciferoj reprezentas 48-bitan nombron.
Kiel ni scias, se ĉi tiu aparato volas kontakti ĉi tiun servilon, la unua paŝo de la 3-voja manpremo devas esti farita unue, tio estas, sendi SYN-pakon. Kiam ĉi tiu peto estas farita, komputilo 10.1.1.10 specifos la fontan havenon, kiun Vindozo kreas dinamike. Vindozo hazarde elektas pordan numeron inter 1 kaj 65,000. Sed ĉar komencaj nombroj en la gamo 1 ĝis 1024 estas vaste konataj, ĉi-kaze la sistemo konsideros nombrojn pli grandajn ol 25000 kaj kreos hazardan fontan havenon, ekzemple numeron 25113.
Poste, la sistemo aldonos celhavenon al la pako, ĉi-kaze ĝi estas pordo 21, ĉar la aplikaĵo, kiu provas konektiĝi al ĉi tiu FTP-servilo, scias, ke ĝi devus sendi FTP-trafikon.
Poste, nia komputilo diras, "Bone, mia IP-adreso estas 10.1.1.10, kaj mi devas kontakti la IP-adreson 30.1.1.10." Ambaŭ ĉi tiuj adresoj ankaŭ estas inkluditaj en la pakaĵeto por formi SYN-peton, kaj ĉi tiu pako ne ŝanĝiĝos ĝis la fino de la konekto.
Mi volas, ke vi komprenu el ĉi tiu video kiel datumoj moviĝas tra la reto. Kiam nia komputilo sendanta la peton vidas la fontan IP-adreson kaj la celan IP-adreson, ĝi komprenas, ke la destina adreso ne estas en tiu loka reto. Mi forgesis diri, ke ĉi tiuj estas ĉiuj /24 IP-adresoj. Do se vi rigardas la /24 IP-adresojn, vi rimarkos, ke komputiloj 10.1.1.10 kaj 30.1.1.10 ne estas en la sama reto. Tiel, la komputilo sendanta la peton komprenas, ke por forlasi ĉi tiun reton, ĝi devas kontakti la 10.1.1.1-pordejon, kiu estas agordita sur unu el la enkursigilo-interfacoj. Ĝi scias, ke ĝi devus iri al 10.1.1.1 kaj konas sian MAC-adreson 1111, sed ne scias la MAC-adreson de la enirejo 10.1.1.1. Kion li faras? Ĝi sendas elsendan ARP-peton, kiun ĉiuj aparatoj en la reto ricevos, sed nur la enkursigilo kun IP-adreso 10.1.1.1 respondos al ĝi.
La enkursigilo respondos per sia AAAA MAC-adreso, kaj ambaŭ fontaj kaj celaj MAC-adresoj ankaŭ estos metitaj en ĉi tiun kadron. Post kiam la kadro estas preta, kontrolo de integreco de datumoj de CRC, kiu estas algoritmo por trovi ĉeksumon por detekti erarojn, estos farita antaŭ ol forlasado de la reto.
Cyclic Redundancy CRC signifas ke ĉi tiu tuta kadro, de la SYN ĝis la lasta MAC-adreso, estas prizorgita tra haŝalgoritmo, diru MD5, rezultigante hashvaloron. La hashvaloro, aŭ MD5-kontrolsumo, tiam estas metita komence de la kadro.
Mi etikedis ĝin FCS/CRC ĉar FCS estas Frame Check Sequence, kvar-bajta CRC-valoro. Iuj homoj uzas la nomon FCS kaj iuj uzas la nomon CRC, do mi nur inkludis ambaŭ nomojn. Sed esence ĝi estas nur haŝvaloro. Necesas certigi, ke ĉiuj datumoj ricevitaj tra la reto ne enhavas erarojn. Tial, kiam ĉi tiu kadro atingas la enkursigilon, la unua afero, kiun la enkursigilo faros, estas kalkuli la kontrolsumon mem kaj kompari ĝin kun la FCS aŭ CRC-valoro kiun la ricevita kadro enhavas. Tiel li povas kontroli, ke la datumoj ricevitaj tra la reto ne enhavas erarojn, post kio li forigos la kontrolsumon de la kadro.
Poste, la enkursigilo rigardos la MAC-adreson kaj diros: "Bone, MAC-adreso AAAA signifas, ke la kadro estas adresita al mi", kaj forigos la parton de la kadro enhavanta la MAC-adresojn.
Rigardante la celan IP-adreson 30.1.1.10, li komprenos, ke ĉi tiu pako ne estas adresita al li kaj devas iri plu tra la enkursigilo.
Nun la enkursigilo "pensas", ke ĝi bezonas vidi, kie troviĝas la reto kun la adreso 30.1.1.10. Ni ankoraŭ ne kovris la plenan koncepton pri vojigo, sed ni scias, ke enkursigiloj havas vojtablon. Ĉi tiu tabelo havas eniron por la reto kun adreso 30.1.1.0. Kiel vi memoras, ĉi tio ne estas la gastiganta IP-adreso, sed la retidentigilo. La enkursigilo "pensos" ke ĝi povas atingi la adreson 30.1.1.0/24 trairante la enkursigilon 20.1.1.2.
Vi eble demandos, kiel li scias ĉi tion? Nur memoru, ke ĝi scios tion aŭ de la enrutaj protokoloj aŭ de viaj agordoj se vi kiel administranto agordis statikan itineron. Sed ĉiukaze, la vojtabelo de ĉi tiu enkursigilo enhavas la ĝustan eniron, do ĝi scias, ke ĝi devus sendi ĉi tiun pakaĵon al 20.1.1.2. Supozante, ke la enkursigilo jam scias la celan MAC-adreson, ni simple daŭrigos plusendi la pakaĵon. Se li ne konas ĉi tiun adreson, li rekomencos ARP, ricevos la MAC-adreson de la router 20.1.1.2, kaj la procezo de sendado de la kadro daŭros denove.
Do ni supozas, ke ĝi jam konas la MAC-adreson, tiam ni havos la BBB-fontan MAC-adreson kaj la CCC-celan MAC-adreson. La enkursigilo denove kalkulas la FCS/CRC kaj metas ĝin komence de la kadro.
Ĝi tiam sendas ĉi tiun kadron tra la reto, la kadro atingas enkursigilon 20.1.12, ĝi kontrolas la kontrolsumon, certigas, ke la datumoj ne estas koruptitaj, kaj forigas la FCS/CRC. Ĝi tiam "tranĉas" la MAC-adresojn, rigardas la celon kaj vidas, ke ĝi estas 30.1.1.10. Li scias, ke ĉi tiu adreso estas konektita al lia interfaco. La sama procezo de formado de kadro estas ripetita, la enkursigilo aldonas la valorojn de MAC-adreso fonto kaj celloko, faras la haŝon, ligas la haŝon al la kadro kaj sendas ĝin tra la reto.
Nia servilo, finfine ricevinte la SYN-peton adresitan al ĝi, kontrolas la hash-kontrolsumon, kaj se la pako ne enhavas erarojn, ĝi forigas la hash. Poste li forigas la MAC-adresojn, rigardas la IP-adreson kaj rimarkas, ke ĉi tiu pako estas adresita al li.
Post tio, ĝi detranĉas la IP-adresojn rilatajn al la tria tavolo de la OSI-modelo kaj rigardas la havennumerojn.
Li vidas la havenon 21, kio signifas FTP-trafikon, vidas la SYN kaj tial komprenas, ke iu provas komuniki kun li.
Nun, surbaze de tio, kion ni lernis pri la manpremo, servilo 30.1.1.10 kreos SYN/ACK-pakaĵon kaj sendos ĝin reen al komputilo 10.1.1.10. Ricevinte ĉi tiun pakon, aparato 10.1.1.10 kreos ACK, pasigos ĝin tra la reto same kiel SYN-pako, kaj post kiam la servilo ricevos la ACK, la konekto estos establita.
Unu afero, kiun vi devus scii, estas, ke ĉio ĉi okazas en malpli ol sekundo. Ĉi tio estas tre, tre rapida procezo, kiun mi provis malrapidigi por ke ĉio estu klara al vi.
Mi esperas, ke vi trovos utila tion, kion vi lernis en ĉi tiu lernilo. Se vi havas demandojn, bonvolu skribi al mi ĉe [retpoŝte protektita] aŭ lasu demandojn sub ĉi tiu video.
Komencante de la sekva leciono, mi elektos la 3 plej interesajn demandojn el Jutubo, kiujn mi recenzos fine de ĉiu video. Ekde nun mi havos sekcion "Pliaj Demandoj" do mi afiŝos demandon kune kun via nomo kaj respondos ĝin rekte. Mi pensas, ke ĉi tio estos utila.
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, 30% rabato por uzantoj de Habr sur unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Kernoj) 10GB DDR4 240GB SSD 1Gbps senpaga ĝis somero pagante por periodo de ses monatoj, vi povas mendi .
Dell R730xd 2 fojojn pli malmultekosta? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com