Бүгінгі бейне оқулықты бастамас бұрын, YouTube сайтында менің курсымның танымал болуына үлес қосқандардың барлығына алғыс айтқым келеді. Мен оны шамамен 8 ай бұрын бастағанда, мен мұндай жетістікті күтпеген едім - бүгін менің сабақтарымды 312724 11208 адам қарады, менің 7 6 жазылушым бар. Бұл кішіпейіл бастаманың мұндай биікке жетеді деп армандаған емеспін. Бірақ уақытты босқа өткізбей, тура бүгінгі сабаққа көшейік. Бүгін біз соңғы 3 бейне сабақта орын алған олқылықтарды толтырамыз. Бүгін 3-шы күн болса да, XNUMX-ші күн XNUMX бейне сабаққа бөлінген, сондықтан бүгін сіз сегізінші бейнесабақты көресіз.
Бүгін біз 3 маңызды тақырыпты қарастырамыз: DHCP, TCP транспорты және ең көп таралған порт нөмірлері. Біз IP мекенжайлары туралы жоғарыда айттық және IP мекенжай конфигурациясының маңызды факторларының бірі DHCP болып табылады.
DHCP хосттың динамикалық конфигурация протоколы дегенді білдіреді және ол хосттар үшін IP мекенжайларын динамикалық конфигурациялауға көмектесетін протокол. Сондықтан бәріміз бұл терезені көрдік. «IP мекенжайын автоматты түрде алу» опциясын басқан кезде, компьютер бір ішкі желіде конфигурацияланған DHCP серверін іздейді және IP мекенжайына әртүрлі пакеттер мен сұрауларды жібереді. DHCP протоколында 6 хабарлама бар, оның 4-і IP мекенжайын тағайындау үшін маңызды.
Бірінші хабар - DHCP DISCOVERY хабары. DHCP табу хабары сәлемдесу хабарына ұқсас. Жаңа құрылғы желіге қосылғанда, ол желіде DHCP серверінің бар-жоғын сұрайды.
Слайдта көргеніңіз құрылғы DHCP серверін іздеп желідегі барлық құрылғылармен байланысатын тарату сұрауына ұқсайды. Мен айтқанымдай, бұл хабар тарату сұрауы, сондықтан оны желідегі барлық құрылғылар ести алады.
Егер желіде DHCP сервері болса, ол пакетті жібереді - DHCP OFFER ұсынысы. Ұсыныс DHCP сервері табу сұрауына жауап ретінде клиентке нақты IP мекенжайын қабылдауды сұрайтын конфигурацияны жіберетінін білдіреді.
DHCP сервері IP мекенжайын сақтайды, бұл жағдайда 192.168.1.2 оны қамтамасыз етпейді, керісінше құрылғы үшін осы мекенжайды сақтайды. Бұл ретте ұсыныс пакетінде DHCP серверінің жеке IP мекенжайы бар.
Бұл желіде бірнеше DHCP сервері болса, басқа DHCP сервері клиенттің хабар тарату сұрауын алған кезде оған өзінің IP мекенжайын ұсынады, мысалы, 192.168.1.50. Бір желіде конфигурацияланған екі түрлі DHCP серверінің болуы әдеттегідей емес, бірақ кейде бұл орын алады. Осылайша, DHCP ұсынысы клиентке жіберілгенде, ол 2 DHCP ұсынысын алады және енді қай DHCP ұсынысын қабылдағысы келетінін шешуі керек.
Клиент бірінші өтінімді қабылдайды делік. Бұл клиент DHCP СҰРАНЫСЫ сұрауын жіберетінін білдіреді, ол сөзбе-сөз «Мен DHCP сервері 192.168.1.2 ұсынған 192.168.1.1 IP мекенжайын қабылдаймын».
Сұрауды алғаннан кейін 192.168.1.1 DHCP сервері «жарайды, мен оны мойындаймын» деп жауап береді, яғни ол сұрауды мойындап, клиентке осы DHCP ACK жібереді. Бірақ басқа DHCP сервері клиент үшін 1.50 IP мекенжайын сақтағанын есте ұстаймыз. Клиенттің хабар тарату сұрауын алғаннан кейін, ол сәтсіздік туралы біледі және басқа сұрауды алған жағдайда оны басқа клиентке тағайындай алатындай IP мекенжайын пулға қайтарады.
Бұл IP мекенжайларын тағайындау кезінде DHCP алмасатын 4 маңызды хабарлама. Содан кейін DHCP-де тағы 2 ақпараттық хабар бар. Ақпараттық хабарды клиент екінші қадамдағы DHCP OFFER тармағында алынғаннан көбірек ақпаратты қажет етсе шығарады. Егер сервер DHCP ұсынысында жеткілікті ақпаратты бермесе немесе клиентке ұсыныс пакетіндегіден көбірек ақпарат қажет болса, ол қосымша DHCP ақпаратын сұрайды. Клиент серверге жіберетін тағы бір хабарлама бар - бұл DHCP RELEASE. Ол сізге клиенттің бар IP мекенжайын шығарғысы келетінін хабарлайды.
Дегенмен, көбінесе клиент серверге DHCP RELEASE жіберуге үлгермей тұрып, пайдаланушы желіден ажыратылады. Бұл компьютерді өшірген кезде болады, біз мұны істейміз. Бұл жағдайда желілік клиенттің немесе компьютердің серверге пайдаланылған мекенжайды босату туралы хабарлауға уақыты жоқ, сондықтан DHCP RELEASE міндетті қадам емес. IP мекенжайын алу үшін қажетті қадамдар: DHCP табу, DHCP ұсынысы, DHCP сұрауы және DHCP қол алысу.
Келесі сабақтардың бірінде мен DNCP пулын құру кезінде DHCP серверін қалай конфигурациялайтынымызды айтамын. Біріктіру арқылы сіз серверге 192.168.1.1 мен 192.168.1.254 аралығындағы IP мекенжайларын тағайындауды айтасыз. Осылайша, DHCP сервері пул жасайды, оған 254 IP мекенжайын орналастырады және желідегі клиенттерге мекенжайларды тек осы пулдан тағайындай алады. Демек, бұл пайдаланушы жасай алатын әкімшілік параметр сияқты нәрсе.
Енді TCP жіберуді қарастырайық. Сіз суреттегі «телефонмен» таныссыз ба, білмеймін, бірақ бала кезімізде бір-бірімізбен сөйлесу үшін жіппен жалғанған мына қаңылтыр банкаларды пайдаланатынбыз.
Өкінішке орай, бүгінгі ұрпақ мұндай «сән-салтанатты» көтере алмайды. Айтайын дегенім, бүгін балалар теледидар алдында бір жастан бастап ойнайды, олар PSP ойнайды, мүмкін бұл даулы шығар, бірақ менің ойымша, бізде ең жақсы балалық шақ өтті, біз шынымен далаға шығып, ойын ойнадық, ал қазіргі балаларды диваннан тартып алу мүмкін емес. .
Менің ұлым бар болғаны бір жаста, мен оның iPad-қа тәуелді екенін қазірдің өзінде көріп тұрмын, ол әлі өте кішкентай, бірақ менің ойымша, қазіргі балалар электронды гаджеттерді қалай басқаруды біледі. Ендеше, бала кезімізде ойнағанда қаңылтыр қаңылтырларды тесетін едік, оларды жіппен байлап, банкаға бірдеңе айтсақ, екінші жағынан адам не айтып жатқанын еститінін айтқым келді. оған банканы құлағына қою арқылы ғана. Сондықтан ол желілік қосылымға өте ұқсас.
Бүгінгі күні, тіпті TCP трансферттерінде нақты деректерді беру басталғанға дейін орнатылуы керек қосылым болуы керек. Өткен сабақтарда талқылағанымыздай, TCP қосылымға бағытталған, ал UDP қосылымға бағытталған. Сіз UDP допты лақтыратын жер деп айта аласыз және оны ұстап алатыныңызды білу сізге байланысты. Сіз мұны істеуге дайынсыз ба, жоқ па, бұл менің мәселе емес, мен оны тастап кетемін.
TCP сіздің жігітпен сөйлесіп, оған допты лақтыратыныңызды алдын ала ескерткеніңізге ұқсайды, осылайша сіз байланыс жасайсыз, содан кейін серіктесіңіз оны ұстауға дайын болуы үшін допты лақтырасыз. Осылайша, TCP шын мәнінде қосылымды жасайды, содан кейін нақты жіберуді бастайды.
Оның мұндай байланысты қалай жасайтынын қарастырайық. Бұл протокол қосылым жасау үшін 3 жақты қол алысуды пайдаланады. Бұл өте техникалық термин емес, бірақ ол TCP қосылымын сипаттау үшін бұрыннан қолданылған. 3 жақты қол алысу жіберуші құрылғымен басталады, клиент SYN жалаушасы бар пакетті серверге жібереді.
Алдыңғы пландағы, бетін көріп тұрған қыз — А құрылғысы, ал артқы жағындағы, беті көрінбейтін қыз — В құрылғысы делік.А қызы В қызға SYN пакетін жібереді, ол: «Тамаша, ол менімен сөйлескісі келеді. Сондықтан мен сөйлесуге дайынмын деп жауап беруім керек!» Бұны қалай істейді? Басқа SYN пакетін, содан кейін бастапқы SYN пакетін алғанын көрсететін ACK жіберуге болады. Бірақ ACK кодтарын бөлек жіберудің орнына сервер SYN және ACK бар ортақ пакетті құрайды және оны желі арқылы жібереді.
Осы кезде А құрылғысы SYN пакетін жіберіп, SYN/ACK пакетін қайтарып алды. Енді А құрылғысы В құрылғысына ACK пакетін жіберуі керек, яғни байланыс орнату үшін В құрылғысынан келісім алғанын растауы керек. Осылайша, екі құрылғы да SYN және ACK пакеттерін алды, енді байланыс орнатылды деп айта аламыз, яғни TCP протоколы арқылы 3 сатылы қол алысу аяқталды.
Әрі қарай TCP Windowing технологиясын қарастырамыз. Қарапайым тілмен айтқанда, бұл жіберуші мен қабылдаушының мүмкіндіктерін келісу үшін TCP/IP-те қолданылатын әдіс.
Windows жүйесінде біз үлкен файлды, айталық 2 ГБ өлшемін бір дискіден екіншісіне тасымалдауға тырысамыз делік. Тасымалдаудың ең басында жүйе файлды тасымалдау шамамен 1 жылға созылатынын хабарлайды. Бірақ бірнеше секундтан кейін жүйе өзін түзетеді және: «О, сәл күте тұрыңыз, менің ойымша, бұл бір жыл емес, шамамен 6 айға созылады». Тағы біраз уақыт өтеді және Windows: «Менің ойымша, мен файлды 1 айда тасымалдай аламын» дейді. Одан кейін «1 күн», «6 сағат», «3 сағат», «1 сағат», «20 минут», «10 минут», «3 минут» хабарлары келеді. Шын мәнінде, бүкіл файлды тасымалдау процесі небәрі 3 минутты алады. Бұл қалай болды? Бастапқыда құрылғы басқа құрылғымен байланысуға әрекеттенгенде, ол бір пакетті жібереді және растауды күтеді. Егер құрылғы растауды ұзақ күтсе, ол: «Егер мен 2 ГБ деректерді осы жылдамдықпен тасымалдауым керек болса, шамамен 2 жыл қажет болады» деп ойлайды. Біраз уақыттан кейін құрылғыңыз ACK алады және «жарайды, мен бір пакетті жібердім және ACK алдым, сондықтан алушы 1 пакетті ала алады. Енді мен оған бір емес, 10 пакет жіберуге тырысамын ». Жіберуші 10 пакетті жібереді және біраз уақыттан кейін қабылдаушы құрылғыдан ACK растауын алады, бұл алушы келесі, 11-ші пакетті күтіп тұрғанын білдіреді. Жіберуші: «Тамаша, алушы бірден 10 пакетті өңдегендіктен, мен оған он емес, 100 пакет жіберуге тырысамын» деп ойлайды. Ол 100 пакетті жібереді, ал алушы оларды алдым және қазір 101 пакетті күтемін деп жауап береді. Осылайша, уақыт өте келе жіберілетін пакеттер саны артады.
Міне, сондықтан сіз файлды көшіру уақытының бастапқыда айтылғанмен салыстырғанда жылдам азайғанын байқайсыз - бұл деректердің үлкен көлемін тасымалдау мүмкіндігінің артуына байланысты. Дегенмен, беру көлемін одан әрі арттыру мүмкін болмайтын сәт келеді. Сіз 10000 9000 пакет жібердіңіз делік, бірақ ресивер құрылғысының буфері тек 9000 9001 пакетті қабылдай алады. Бұл жағдайда ресивер «Мен 9000 9000 пакет алдым және қазір 9000 3 пакетті қабылдауға дайынмын» деген хабарламамен ACK жібереді. Бұдан жөнелтуші қабылдаушы құрылғының буферінің сыйымдылығы небәрі XNUMX деген қорытынды жасайды, яғни бұдан былай мен бір мезетте XNUMX пакеттен артық емес жіберемін. Бұл жағдайда жіберуші XNUMX пакеттік бөліктерде деректердің қалған көлемін тасымалдауға кететін уақытты жылдам есептеп, XNUMX минут береді. Бұл үш минут нақты жіберу уақыты. TCP Windowing осылай жасайды.
Бұл жіберу құрылғысы ақырында нақты желі сыйымдылығының не екенін түсінетін трафикті азайту механизмдерінің бірі. Неліктен олар қабылдаушы құрылғының сыйымдылығы туралы алдын ала келісе алмайды деп ойлайтын шығарсыз? Бұл техникалық тұрғыдан мүмкін емес, өйткені желіде әртүрлі құрылғылар бар. Сізде iPad бар делік және оның iPhone-ға қарағанда деректерді беру/қабылдау жылдамдығы басқаша, сізде әртүрлі телефондар болуы мүмкін немесе сізде өте ескі компьютер болуы мүмкін. Сондықтан әркімнің желі өткізу қабілеті әртүрлі.
Сондықтан TCP Windowing технологиясы деректерді беру төмен жылдамдықта немесе пакеттердің ең аз санын беруден басталатын кезде, трафиктің «терезесін» біртіндеп арттыра отырып әзірленді. Сіз бір пакетті, 5 пакетті, 10 пакетті, 1000 пакетті, 10000 XNUMX пакетті жібересіз және «ашылу» белгілі бір уақыт аралығында жіберілетін трафиктің максималды мүмкін көлеміне жеткенше сол терезені баяу ашасыз. Осылайша, Windowing концепциясы TCP протоколының жұмысының бөлігі болып табылады.
Әрі қарай біз ең көп таралған порт нөмірлерін қарастырамыз. Классикалық жағдай - сізде 1 негізгі сервер, мүмкін деректер орталығы болған кезде. Ол файлдық серверді, веб-серверді, пошта серверін және DHCP серверін қамтиды. Енді клиенттік компьютерлердің бірі суреттің ортасында орналасқан деректер орталығына хабарласса, ол клиенттік құрылғыларға файлдық сервер трафигін жібере бастайды. Бұл трафик қызыл түспен көрсетіледі және белгілі бір серверден белгілі бір қолданба үшін арнайы портта жіберіледі.
Сервер белгілі бір трафиктің қайда кетуі керектігін қайдан білді? Ол мұны тағайындалған порт нөмірінен біледі. Егер кадрға қарасаңыз, әрбір деректерді тасымалдауда тағайындалған порт нөмірі мен бастапқы порт нөмірі туралы айтылғанын көресіз. Көк және қызыл трафик, ал көк трафик веб-сервер трафигі екенін көре аласыз, екеуі де әртүрлі серверлер орнатылған бір физикалық серверге өтеді. Егер бұл деректер орталығы болса, онда ол виртуалды серверлерді пайдаланады. Сонымен, олар қызыл трафик осы IP мекенжайы бар сол жақ ноутбукке оралуы керек екенін қайдан білді? Олар мұны порт нөмірлерінің арқасында біледі. Википедиядағы «TCP және UDP порттарының тізімі» мақаласына жүгінсеңіз, онда барлық стандартты порт нөмірлерінің тізімі берілгенін көресіз.
Егер сіз осы бетті төмен айналдырсаңыз, бұл тізімнің қаншалықты үлкен екенін көре аласыз. Онда шамамен 61 000 нөмір бар. 1-ден 1024-ке дейінгі порт нөмірлері ең көп таралған порт нөмірлері ретінде белгілі. Мысалы, 21/TCP порты ftp пәрмендерін жіберуге арналған, 22 порт ssh үшін, 23 порт Telnet үшін, яғни шифрланбаған хабарламаларды жіберуге арналған. Өте танымал 80 порты деректерді HTTP арқылы тасымалдайды, ал 443 порты HTTPS арқылы шифрланған деректерді тасымалдайды, бұл HTTP қауіпсіз нұсқасына ұқсас.
Кейбір порттар TCP және UDP екеуіне де арналған, ал кейбіреулері қосылымның TCP немесе UDP болуына байланысты әртүрлі тапсырмаларды орындайды. Сонымен, ресми түрде TCP 80 порты HTTP үшін пайдаланылады, ал бейресми UDP порты 80 HTTP үшін пайдаланылады, бірақ басқа HTTP протоколы бойынша - QUIC.
Сондықтан TCP-дегі порт нөмірлері әрқашан UDP-дегідей әрекетті орындауға арналмаған. Бұл тізімді есте сақтаудың қажеті жоқ, оны есте сақтау мүмкін емес, бірақ сіз кейбір танымал және ең көп таралған порт нөмірлерін білуіңіз керек. Мен айтқанымдай, бұл порттардың кейбіреулері стандарттарда сипатталған ресми мақсатқа ие, ал кейбіреулері Chromium сияқты бейресми мақсатқа ие.
Сонымен, бұл кестеде барлық жалпы порт нөмірлері берілген және бұл сандар белгілі бір қолданбаларды пайдалану кезінде трафикті жіберу және қабылдау үшін пайдаланылады.
Енді біз білетін аз ақпарат негізінде деректер желі бойынша қалай қозғалатынын қарастырайық. 10.1.1.10 компьютері осы компьютермен немесе 30.1.1.10 мекенжайы бар сервермен байланысқысы келеді делік. Әрбір құрылғының IP мекенжайының астында оның MAC мекенжайы орналасқан. Мен тек соңғы 4 таңбадан тұратын MAC мекенжайының мысалын келтіремін, бірақ іс жүзінде бұл 48 таңбадан тұратын 12 биттік он алтылық сан. Бұл сандардың әрқайсысы 4 биттен тұратындықтан, 12 он алтылық цифр 48 биттік санды білдіреді.
Біз білетіндей, егер бұл құрылғы осы сервермен байланысқысы келсе, алдымен 3 жақты қол алысудың бірінші қадамы жасалуы керек, яғни SYN пакетін жіберу. Бұл сұрау жасалғанда, компьютер 10.1.1.10 Windows динамикалық түрде жасайтын бастапқы порт нөмірін көрсетеді. Windows 1 мен 65,000 1 арасындағы порт нөмірін кездейсоқ таңдайды. Бірақ 1024-ден 25000-ке дейінгі диапазондағы бастапқы сандар кеңінен белгілі болғандықтан, бұл жағдайда жүйе 25113-нан жоғары сандарды қарастырады және кездейсоқ бастапқы портты жасайды, мысалы, XNUMX нөмірі.
Әрі қарай, жүйе пакетке тағайындалған портты қосады, бұл жағдайда ол 21-порт болып табылады, өйткені осы FTP серверіне қосылуға әрекеттеніп жатқан қолданба FTP трафигін жіберу керек екенін біледі.
Содан кейін біздің компьютер: «Жарайды, менің IP мекенжайым 10.1.1.10, мен 30.1.1.10 IP мекенжайына хабарласуым керек» дейді. Бұл мекенжайлардың екеуі де SYN сұрауын қалыптастыру үшін пакетке кіреді және бұл пакет қосылым соңына дейін өзгермейді.
Бұл бейнеден деректердің желіде қалай қозғалатынын түсінгеніңізді қалаймын. Сұрауды жіберетін компьютеріміз бастапқы IP мекенжайын және тағайындалған IP мекенжайын көргенде, ол тағайындалған мекенжай сол жергілікті желіде емес екенін түсінеді. Мен мұның барлығы /24 IP мекенжайлары екенін айтуды ұмытып кеттім. Сондықтан /24 IP мекенжайларын қарасаңыз, 10.1.1.10 және 30.1.1.10 компьютерлері бір желіде емес екенін түсінесіз. Осылайша, сұрауды жіберетін компьютер бұл желіден шығу үшін маршрутизатор интерфейстерінің бірінде конфигурацияланған 10.1.1.1 шлюзімен байланысуы керек екенін түсінеді. Ол 10.1.1.1 нұсқасына өту керектігін біледі және өзінің 1111 MAC мекенжайын біледі, бірақ 10.1.1.1 шлюзінің MAC мекенжайын білмейді. Ол не істеп жатыр? Ол желідегі барлық құрылғылар қабылдайтын таратылатын ARP сұрауын жібереді, бірақ оған IP мекенжайы 10.1.1.1 маршрутизатор ғана жауап береді.
Маршрутизатор өзінің AAAA MAC мекенжайымен жауап береді және бастапқы және тағайындалған MAC мекенжайлары да осы кадрға орналастырылады. Фрейм дайын болғаннан кейін желіден шығу алдында қателерді анықтау үшін бақылау сомасын табу алгоритмі болып табылатын CRC деректерінің тұтастығын тексеру орындалады.
Циклдік резервтік CRC бұл бүкіл кадр SYN-дан соңғы MAC мекенжайына дейін хэштеу алгоритмі арқылы іске қосылатынын білдіреді, мысалы, MD5, нәтижесінде хэш мәні болады. Содан кейін хэш мәні немесе MD5 бақылау сомасы кадрдың басына қойылады.
Мен оны FCS/CRC деп белгіледім, себебі FCS кадрды тексеру реті, төрт байт CRC мәні. Кейбір адамдар FCS белгісін, ал кейбіреулері CRC белгілеуін пайдаланады, сондықтан мен екі белгілеуді де қостым. Бірақ негізінен бұл тек хэш мәні. Бұл желі арқылы алынған барлық деректерде қателер жоқ екеніне көз жеткізу үшін қажет. Сондықтан, бұл кадр маршрутизаторға жеткенде, маршрутизатор жасайтын бірінші нәрсе бақылау сомасын өзі есептеп, оны қабылданған кадр құрамындағы FCS немесе CRC мәнімен салыстырады. Осылайша ол желі арқылы алынған деректерде қателер жоқтығын тексере алады, содан кейін ол бақылау сомасын кадрдан алып тастайды.
Содан кейін маршрутизатор MAC мекенжайын қарап, «Жарайды, MAC мекенжайы AAAA кадрдың маған бағытталғанын білдіреді» деп айтады және MAC мекенжайлары бар кадрдың бөлігін жояды.
30.1.1.10 тағайындалған IP мекенжайына қарап, ол бұл пакеттің оған арналмағанын және маршрутизатор арқылы әрі қарай өту керектігін түсінеді.
Енді маршрутизатор 30.1.1.10 мекенжайы бар желінің қай жерде орналасқанын көру керек деп «ойлайды». Біз әлі маршрутизацияның толық тұжырымдамасын қарастырған жоқпыз, бірақ маршрутизаторларда маршруттау кестесі бар екенін білеміз. Бұл кестеде 30.1.1.0 мекенжайы бар желіге арналған жазба бар. Естеріңізде болса, бұл хосттың IP мекенжайы емес, желі идентификаторы. Маршрутизатор 30.1.1.0 маршрутизаторы арқылы өту арқылы 24/20.1.1.2 мекенжайына жете алатынын «ойлайды».
Сіз мұны қайдан біледі деп сұрауыңыз мүмкін. Егер сіз әкімші ретінде статикалық маршрутты теңшеген болсаңыз, ол мұны маршруттау протоколдарынан немесе параметрлеріңізден білетінін есте сақтаңыз. Бірақ кез келген жағдайда, бұл маршрутизатордың маршруттау кестесінде дұрыс жазба бар, сондықтан ол бұл пакетті 20.1.1.2-ге жіберу керек екенін біледі. Маршрутизатор тағайындалған MAC мекенжайын біледі деп есептесек, біз жай ғана пакетті қайта жіберуді жалғастырамыз. Егер ол бұл мекенжайды білмесе, ол ARP-ті қайта бастайды, маршрутизатордың 20.1.1.2 MAC мекенжайын алады және кадрды жіберу процесі қайтадан жалғасады.
Сондықтан біз ол MAC мекенжайын біледі деп есептейміз, содан кейін бізде BBB бастапқы MAC мекенжайы және CCC тағайындалған MAC мекенжайы болады. Маршрутизатор қайтадан FCS/CRC есептеп, оны кадрдың басына орналастырады.
Содан кейін ол осы кадрды желі арқылы жібереді, кадр 20.1.12 маршрутизаторына жетеді, бақылау сомасын тексереді, деректердің бүлінбегеніне көз жеткізеді және FCS/CRC жояды. Содан кейін ол MAC мекенжайларын «қысқартады», тағайындалған жерге қарайды және оның 30.1.1.10 екенін көреді. Ол бұл адрестің интерфейсіне қосылғанын біледі. Бірдей кадрды қалыптастыру процесі қайталанады, маршрутизатор бастапқы және тағайындалған MAC мекенжай мәндерін қосады, хэштеуді жасайды, хэшті кадрға тіркейді және оны желі арқылы жібереді.
Біздің сервер ақырында оған жіберілген SYN сұрауын алып, хэш бақылау сомасын тексереді, ал пакетте қателер болмаса, ол хэшті жояды. Содан кейін ол MAC мекенжайларын алып тастап, IP мекенжайына қарап, бұл пакеттің өзіне бағытталғанын түсінеді.
Осыдан кейін ол OSI үлгісінің үшінші деңгейіне қатысты IP мекенжайларын қысқартады және порт нөмірлеріне қарайды.
Ол 21 портты көреді, бұл FTP трафигін білдіреді, SYN-ді көреді және сондықтан біреу онымен байланысуға тырысып жатқанын түсінеді.
Енді қол алысу туралы білгендеріміздің негізінде 30.1.1.10 сервері SYN/ACK пакетін жасайды және оны 10.1.1.10 компьютеріне қайта жібереді. Осы пакетті алғаннан кейін 10.1.1.10 құрылғысы ACK жасайды, оны SYN пакеті сияқты желі арқылы өткізеді және сервер ACK қабылдағаннан кейін байланыс орнатылады.
Бір білуіңіз керек, мұның бәрі бір секундтан аз уақыт ішінде болады. Бұл өте жылдам процесс, мен сізге бәрі түсінікті болуы үшін оны баяулатуға тырыстым.
Осы оқулықта білгендеріңіз пайдалы болады деп үміттенемін. Егер сізде сұрақтар болса, маған жазыңыз [электрондық пошта қорғалған] немесе сұрақтарыңызды осы видеоның астына қалдырыңыз.
Келесі сабақтан бастап мен YouTube сайтынан ең қызықты 3 сұрақты таңдаймын, соларды әр видеоның соңында қарастырамын. Енді менде «Ең көп қойылатын сұрақтар» бөлімі болады, сондықтан мен сіздің атыңызбен бірге сұрақты жариялап, оған тікелей эфирде жауап беремін. Бұл пайдалы болады деп ойлаймын.
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, Habr пайдаланушылары үшін біз сіз үшін ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогына 30% жеңілдік: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
VPS (KVM) E5-2650 v4 (6 ядро) 10 ГБ DDR4 240 ГБ SSD 1 Гбит/с жазға дейін тегін алты ай мерзімге төлеген кезде тапсырыс беруге болады .
Dell R730xd 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com