Перш чым мы пачнем сённяшні відэаўрок, хачу падзякаваць усім, хто спрыяў папулярнасці майго курса на YouTube. Калі я пачаў яго каля 8 месяцаў таму, то не чакаў такога поспеху - на сёння мае ўрокі прагледзелі 312724 чалавекі, у мяне 11208 падпісчыкаў. Мне і не снілася, што гэтае сціплае пачынанне дасягне такіх вышынь. Але не будзем губляць час і адразу пяройдзем да сённяшняга занятку. Сёння мы папоўнім прабелы, якія мелі месца ў апошніх 7 відэаўроках. Хоць сёння толькі 6 дзень, дзень 3 быў разбіты на 3 відэаўрок, так што фактычна сёння вы паглядзіце восьмы відэаўрок.
Сёння мы будзем займацца 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, не падае, а менавіта рэзервуе за прыладай дадзены адрас. Разам з гэтым у пакеце прапановы змяшчаецца ўласны IP-адрас DHCP-сервера.
Калі ў гэтай сетцы маецца больш аднаго DHCP-сервера, іншы DHCP-сервер, атрымаўшы шырокавяшчальны запыт кліента, таксама прапанаваў бы яму свой IP-адрас, напрыклад, 192.168.1.50. Звычайна ў адной і той жа сетцы не наладжваюцца два розных DHCP-сервера, але часам такое ўсё ж здараецца. Такім чынам, калі прапанова DHCP адпраўляецца кліенту, ён атрымлівае 2 прапановы DHCP і зараз павінен вырашыць, якая прапанова DHCP ён хоча прыняць.
Давайце выкажам здагадку, што кліент прымае першае прыкладанне. Гэта азначае, што кліент адсылае запыт DHCP REQUEST, у якім літаральна гаворыцца: "я прымаю IP-адрас 192.168.1.2, прапанаваны DHCP-серверам 192.168.1.1".
Атрымаўшы запыт, DHCP-сервер 192.168.1.1 адказвае: "добра, я гэта прызнаю", гэта значыць пацвярджае запыт і накіроўвае гэтае пацверджанне DHCP ACK кліенту. Але мы памятаем, што іншы DHCP-сервер DHCP зарэзерваваў для кліента IP-адрас 1.50. Атрымаўшы шырокавяшчальны запыт кліента, ён пазнае аб адмове і змесціць гэты IP-адрас зваротна ў пул, каб ён мог прызначыць яго іншаму кліенту, калі атрымае іншы запыт.
Такія 4 крытычных паведамлення, якімі абменьваецца DHCP а пачатку прызначэння IP-адрасоў. Далей у DHCP маюцца яшчэ 2 інфармацыйных паведамлення. Інфармацыйнае паведамленне выдаецца кліентам, калі яму патрабуецца больш інфармацыі, чым ён атрымаў у сказе DHCP OFFER на другім кроку. Калі ў сказе DHCP сервер падаў недастаткова інфармацыі або калі кліенту трэба больш інфармацыі, чым тая, што змяшчалася ў пакеце прапановы, ён запытвае дадатковую DHCP-інфармацыю. Ёсць яшчэ адно паведамленне, якое кліент адсылае серверу - гэта вызваленне DHCP RELEASE. У ім паведамляецца, што кліент жадае вызваліць наяўны ў яго IP-адрас.
Аднак часцей за ўсё здараецца так, што карыстач адключаецца ад сеткі раней, чым кліент паспявае паслаць на сервер DHCP RELEASE. Так адбываецца пры выключэнні кампутара, якое здзяйсняем мы з вамі. Пры гэтым сеткавы кліент, ці кампутар, проста не мае часу на тое, каб паведаміць серверу аб вызваленні які выкарыстоўваўся адрасы, таму DHCP RELEASE не з'яўляецца абавязковым крокам. Абавязковымі крокамі для атрымання IP-адрасы з'яўляюцца: выяўленне DHCP, прапанова DHCP, запыт DHCP і пацвярджэнне DHCP.
У адным з наступных урокаў я распавяду, як мы наладжваем DHCP-сервер пры стварэнні DNCP-пула. Пад пулам маецца на ўвазе, што вы паведамляеце серверу аб прызначэнні IP-адрасоў у дыяпазоне ад 192.168.1.1 да 192.168.1.254. Такім чынам, DHCP-сервер створыць пул, змесціць у яго 254 IP-адрасы і зможа прызначаць кліентам сеткі адрасы толькі з гэтага пула. Дык гэта нешта накшталт адміністрацыйнай наладкі, якую можа ажыццявіць карыстальнік.
Цяпер разгледзім перадачу TCP. Не ведаю, ці знаёмыя вы з намаляваным на малюнку «тэлефонам», але ў дзяцінстве мы выкарыстоўвалі такія кансервавыя слоікі, злучаныя шнурком, каб размаўляць сябар з сябрам.
Нажаль, сённяшняе пакаленне не можа дазволіць сабе такой "раскошы". Я маю на ўвазе, што сёння дзеці знаходзяцца перад тэлевізарам з падгадаванага ўзросту, яны гуляюць у PSP, і, магчыма, гэта спрэчнае пытанне, але я думаю, што ў нас было лепшае дзяцінства, мы сапраўды выходзілі на вуліцу і гулялі ў гульні, а сённяшніх дзяцей не адарвеш ад канапы.
Майму сыну ўсяго год, і я ўжо бачу, што ён заахвоціўся да iPad, я маю на ўвазе, што ён яшчэ вельмі маленькі, але мне здаецца, што сённяшнія дзеці ўжо нараджаюцца са ведамі, як звяртацца з электроннымі гаджэтамі. Такім чынам, я жадаў сказаць, што ў дзяцінстве, калі мы гулялі, мы дзіравілі кансервавыя слоікі, і калі звязвалі іх струной і прамаўлялі нешта ў адзін слоік, то на іншым канцы чалавек мог пачуць, што яму кажуць, проста прыклаўшы слоік да вуха . Так што гэта вельмі падобна на сеткавае злучэнне.
Сёння нават для перадачы TCP павінна ёсць злучэнне, якое неабходна ўсталяваць да таго, як пачнецца рэальная перадача дадзеных. Як мы абмяркоўвалі ў папярэдніх уроках, TCP – гэта перадача, арыентаваная на папярэдняе ўсталяванне злучэння з сеткай, у той час як UDP – гэта перадача без неабходнасці ўстаноўкі злучэння. Можна сказаць, што UDP - гэта калі я кідаю мяч, і ад вас залежыць, ці зможаце вы яго злавіць. Гатовы вы гэта зрабіць ці не, гэта не мая праблема, я проста збіраюся яго кінуць.
ТСP больш падобна на тое, што вы размаўляеце з хлопцам і загадзя папярэджваеце яго аб тым, што збіраецеся кінуць мяч, гэта значыць паміж вамі завязваецца сувязь, і толькі затым вы кідаеце мяч, так што з вялікай верагоднасцю ваш партнёр будзе готаў яго злавіць. Такім чынам, TCP фактычна будуе злучэнне, а затым пачынае здзяйсняць рэальную перадачу.
Разгледзім, як ён стварае такое злучэнне. Для стварэння злучэння гэты пратакол выкарыстоўвае 3-х этапны поціск рукі. Гэта не занадта тэхнічны тэрмін, але ён даўно выкарыстоўваецца для апісання TCP-злучэнні. 3-х этапны поціск рукі ініцыюецца якая адпраўляе прыладай, пры гэтым кліент адпраўляе серверу пакет з SYN-сцягам.
Выкажам здагадку, што дзяўчынка на пярэднім плане, чыю асобу мы можам бачыць - гэта прылада А, а дзяўчынка на заднім плане, асобы якой не відаць - прылада В. Дзяўчынка А пасылае SYN-пакет дзяўчынцы В, і тая кажа: «выдатна, хто- то хоча са мной размаўляць. Значыць, мне трэба адказаць, што я гатова да зносін!» Як гэта зрабіць? Можна было б проста адправіць назад яшчэ адзін SYN-пакет і затым пацверджанне ACK, якое паказвае на атрыманне зыходнага SYN-пакета. Але замест таго, каб адпраўляць ACK асобна, сервер фармуе агульны пакет, у якім утрымоўваецца SYN і ACK, і перадае яго па сетцы.
Такім чынам, на дадзены момант прылада А адправіла SYN-пакет і атрымала зваротна пакет SYN/ACK. Зараз прылада А павінна адправіць прыладзе Ў пакет ACK, гэта значыць пацвердзіць тое, што яно атрымала згоду прылады Ў на ўсталяванне сувязі. Такім чынам, абедзве прылады атрымалі пакеты SYN і ACK, і зараз можна сказаць, што злучэнне ўсталявана, гэта значыць ажыццёўлена 3-х этапны поціск рукі па пратаколе TCP.
Далей мы разгледзім тэхналогію 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 пакетаў і праз нейкі час атрымлівае зваротна ад прымаючага прылады пацверджанне АСК, якое азначае, што атрымальнік чакае наступны, 11-й пакет. Адпраўнік думае: "выдатна, раз атрымальнік зладзіўся адразу з 10-ю пакетамі, зараз я паспрабую паслаць яму 100 пакетаў замест дзесяці". Ён пасылае 100 пакетаў, і атрымальнік адказвае, што атрымаў іх і зараз чакае 101 пакет. Такім чынам, з цягам часу колькасць перадаюцца пакетаў павялічваецца.
Вось чаму вы бачыце імклівае памяншэнне часу капіявання файла ў параўнанні з заяўленым першапачаткова - гэта звязана з павелічэннем магчымасці перадачы вялікага аб'ёму дадзеных. Аднак надыходзіць момант, калі далейшае павелічэнне аб'ёму перадачы становіцца немагчымым. Выкажам здагадку, вы перадалі 10000 пакетаў, але буфер прылады атрымальніка здольны прыняць усяго 9000. У гэтым выпадку атрымальнік адпраўляе ACK з паведамленнем: "я прыняў 9000 пакетаў і зараз гатовы прыняць 9001". З гэтага адпраўнік робіць выснову, што буфер прымаючага прылады мае ёмістасць усяго 9000, значыць, з гэтага моманту я буду пасылаць за раз не больш за 9000 пакетаў. Пры гэтым адпраўнік хутка падлічвае час, які спатрэбіцца яму на перадачу пакінутага аб'ёму дадзеных порцыямі па 9000 пакетаў, і выдае 3 хвіліны. Гэтыя тры хвіліны і з'яўляюцца фактычным часам перадачы. Вось што робіць TCP Windowing.
Гэта адзін з тых механізмаў рэгулявання трафіку, дзе якая перадае прылада з часам разумее, якая фактычная прапускная здольнасць сеткі. У вас можа ўзнікнуць пытанне, чаму яны не могуць дамовіцца загадзя аб тым, якая ёмістасць прымаючага прылады? Справа ў тым, што тэхнічна гэта немагчыма, таму што ў сетцы маюцца розныя тыпы прылад. Выкажам здагадку, у вас ёсць iPad, і ў яго хуткасць прыёму/перадачы дадзеных адрозніваецца ад iPhone, у вас могуць быць розныя тыпы тэлефонаў, ці, можа быць, у вас вельмі стары кампутар. Таму ва ўсіх розная прапускная здольнасць сеткі.
Таму і была распрацавана тэхналогія TCP Windowing, калі перадача дадзеных пачынаецца на невялікай хуткасці ці з перадачы мінімальнай колькасці пакетаў, паступова павялічваючы "акно" трафіку. Вы адпраўляеце адзін пакет, 5 пакетаў, 10 пакетаў, 1000 пакетаў, 10000 пакетаў і павольна прыадчыняеце гэтае акно ўсё больш і больш, пакуль «расчыненне» не дасягне максімальнага магчымага значэння адпраўкі аб'ёму трафіку ў пэўны прамежак часу. Такім чынам, канцэпцыя Windowing з'яўляецца часткай працы пратаколу TCP.
Далей мы разгледзім найболей распаўсюджаныя нумары портаў. Класічнай з'яўляецца сітуацыя, пры якой у вас есць 1 галоўны сервер, магчыма, гэта дата-цэнтр. Ён уключае ў сябе файлавы сервер, вэб-сервер, паштовы сервер і DHCP-сервер. Зараз, калі адзін з кліенцкіх кампутараў звяжацца з дата-цэнтрам, які размешчаны ў сярэдзіне карцінкі, той пачне рассылаць кліенцкім прыладам трафік файлавага сервера. Гэты трафік паказаны чырвоным колерам, і для яго перадачы будзе выкарыстоўвацца пэўны порт для вызначанага прыкладання ад вызначанага сервера.
Якім чынам сервер даведаўся, куды павінен ісці пэўны трафік? Ён даведаецца пра гэта з нумара порта прызначэння. Калі вы паглядзіце на фрэйм, то ўбачыце, што ў кожнай перадачы дадзеных маецца згадванне нумара порта прызначэння і порта крыніцы. Вы бачыце, што сіні і чырвоны трафік, а сіні трафік - гэта трафік вэб-сервера, абодва паступаюць на адзін і той жа фізічны сервер, у якім устаноўлены розныя серверы. Калі гэта дата-цэнтр, ён выкарыстоўвае віртуальныя серверы. Дык як жа яны даведаліся, што чырвоны трафік павінен быў вярнуцца да гэтага левага наўтбука з гэтым IP-адрасам? Яны ведаюць гэта дзякуючы нумарам партоў. Калі вы звернецеся да артыкула Вікіпедыі «Спіс партоў TCP і UDP», то ўбачыце, што ў ім пералічаны ўсе стандартныя нумары партоў.
Калі пракруціць гэтую старонку, то можна ўбачыць, наколькі вялікі гэты спіс. Ён змяшчае прыкладна 61 нумароў. Нумары партоў ад 000 да 1 вядомы як найбольш распаўсюджаныя нумары партоў. Напрыклад, порт 1024/TCP прызначаны для перадачы каманд ftp, порт 21 для ssh, порт 22 - для Telnet, гэта значыць для перадачы незашыфраваных паведамленняў. Вельмі папулярны порт 23 служыць для перадачы дадзеных па пратаколе HTTP, а порт 80 служыць для перадачы зашыфраваных дадзеных па пратаколе HTTPS, які падобны на бяспечную версію HTTP.
Некаторыя парты прызначаны адначасова для TCP і UDP, а некаторыя выконваюць розныя задачы ў залежнасці ад таго, якое злучэнне выкарыстоўваецца - TCP або UDP. Так, афіцыйна порт 80 TCP выкарыстоўваецца для HTTP, а неафіцыйна порт 80 UDP выкарыстоўваецца для HTTP, але па іншым пратаколе HTTP - QUIC.
Таму нумары партоў у TCP не заўсёды прызначаны для таго ж, што і ў UDP. Вам не трэба вучыць гэты спіс на памяць, яго немагчыма запомніць, але некаторыя папулярныя і найбольш распаўсюджаны нумары партоў трэба ведаць. Як я сказаў, некаторыя з гэтых партоў маюць афіцыйнае прызначэнне, якое апісана ў стандартах, а некаторыя - неафіцыйнае прызначэнне, як у выпадку з Сhromium.
Такім чынам, у гэтай табліцы пералічаны ўсе распаўсюджаныя нумары портаў, і гэтыя нумары служаць для адпраўкі і атрыманні трафіку пры выкарыстанні пэўных прыкладанняў.
Цяпер давайце разгледзім, як дадзеныя перамяшчаюцца ў сетцы, грунтуючыся на той невялікай інфармацыі, якую ведаем. Выкажам здагадку, што кампутар 10.1.1.10 жадае звязацца з гэтым кампутарам, ці гэтым серверам, які мае адрас 30.1.1.10. Пад IP-адрасам кожнай з прылад размешчаны яго MAC-адрас. Я прыводжу ў прыклад MAC-адрас толькі з апошнімі 4 знакамі, але на практыцы гэты 48-бітны шаснаццатковы лік з 12 знакамі. Так як кожны з гэтых лікаў складаецца з 4-х біт, 12 шаснаццатковых лічбаў уяўляюць сабой 48-бітны лік.
Як мы ведаем, калі гэтая прылада жадае звязацца з гэтым серверам, спачатку павінен быць зроблены першы крок 3-этапнага поціску рукі, гэта значыць адпраўлены SYN-пакет. Пры стварэнні гэтага запыту кампутар 10.1.1.10 пакажа нумар порта крыніцы, які Windows стварае дынамічна. Windows выпадковым чынам выбірае нумар порта ў дыяпазоне ад 1 да 65,000. Але паколькі пачатковыя нумары ў дыяпазоне ад 1 да 1024 з'яўляюцца шырока вядомымі, у дадзеным выпадку сістэма будзе разглядаць нумары больш за 25000 і створыць выпадковы порт крыніцы, напрыклад, пад нумарам 25113.
Далей сістэма дадасць у пакет порт прызначэння, у дадзеным выпадку гэта порт 21, таму што прыкладанне, якое спрабуе далучыцца да гэтага FTP-серверу, ведае, што яно павінна адправіць FTP-трафік.
Далей наш кампутар кажа: "Добра, мой IP-адрас 10.1.1.10, а мне трэба звязацца з IP-адрасам 30.1.1.10". Абодва гэтыя адрасы таксама ўключаюцца ў пакет, фармуючы SYN-запыт, і гэты пакет не будзе змяняцца да канца ўсталявання злучэння.
Я хачу, каб вы зразумелі з гэтага відэа, як дадзеныя перамяшчаюцца па сетцы. Калі наш кампутар, які адпраўляе запыт, бачыць IP-адрас крыніцы і IP-адрас прызначэння, ён разумее, што адрас прызначэння не знаходзіцца ў гэтай лакальнай сетцы. Я забыўся сказаць, што гэта ўсё /24 IP-адрасы. Так што, калі вы паглядзіце на IP-адрасы /24, то зразумееце, што кампутары 10.1.1.10 і 30.1.1.10 не знаходзяцца ў адной сетцы. Такім чынам, кампутар-адпраўнік запыту разумее, што для таго, каб выйсці з гэтай сеткі, ён павінен звярнуцца да шлюза 10.1.1.1, які наладжаны на адным з інтэрфейсаў маршрутызатара. Ён ведае, што ён павінен перайсці да 10.1.1.1, і ведае свой MAC-адрас 1111, але не ведае MAC-адрас шлюза 10.1.1.1. Што ж ён робіць? Ён пасылае шырокавяшчальны ARP-запыт, які атрымаюць усе прылады ў сетцы, але адкажа на яго толькі маршрутызатар з IP-адрасам 10.1.1.1.
Маршрутызатар адкажа яму сваім MAC-адрасам АААА, і абодва MAC-адрасы - крыніцы і прызначэнні - таксама будуць змешчаныя ў гэты фрэйм. Як толькі фрэйм будзе готаў, перад тым, як пакінуць сетку, будзе ажыццёўлена праверка цэласнасці дадзеных CRC, уяўлялая сабой алгарытм знаходжання кантрольнай сумы з мэтай выяўлення памылак.
Цыклічны залішні код CRC азначае, што ўвесь гэты фрэйм, ад SYN да апошняга MAC-адрасы, праганяецца праз алгарытм хэшавання, скажам, MD5, у выніку чаго атрымліваецца значэнне хеша. Затым значэнне хеша, ці кантрольная сума MD5, змяшчаецца ў пачатак фрэйма.
Я пазначыў яе FCS/CRC, таму што FCS - гэта паслядоўнасць праверкі кадраў, чатырохбайтавае значэнне CRC. Некаторыя людзі ўжываюць абазначэнне FCS, а некаторыя - CRC, таму я проста паказаў абодва абазначэння. Але ў прынцыпе гэта ўсяго толькі значэнне хеша. Яно трэба для таго, каб пераканацца, што ўсе дадзеныя, якія паступаюць па сетцы, не ўтрымоўваюць памылак. Таму, калі гэты фрэйм дасягае маршрутызатара, першае, што зробіць маршрутызатар, гэта вылічыць кантрольную суму самастойна і параўнае яе са значэннем FCS або CRC, якое ўтрымоўвае атрыманы фрэйм. Такім чынам ён зможа праверыць, што дадзеныя, якія паступілі па сетцы, не ўтрымоўваюць памылак, пасля чаго выдаліць кантрольную суму з фрэйма.
Далей роўтэр паглядзіць на MAC-адрас і скажа: "Добра, MAC-адрас AAAA азначае, што фрэйм адрасаваны мне", і выдаліць частку фрэйма, якая змяшчае MAC-адрасы.
Паглядзеўшы на IP-адрас прызначэння 30.1.1.10, ён зразумее, што гэты пакет адрасаваны не яму і павінен мінуць праз маршрутызатар далей.
Цяпер роўтэр "думае" аб тым, яму трэба ўбачыць, дзе знаходзіцца сетка з адрасам 30.1.1.10. Мы яшчэ не разглядалі поўную канцэпцыю маршрутызацыі, але ведаем, што роўтэры маюць табліцу маршрутызацыі. У гэтай табліцы ёсць запіс для сеткі з адрасам 30.1.1.0. Як вы падушыце, гэта не IP-адрас хаста, а ідэнтыфікатар сеткі. Роўтар "падумае" аб тым, што можна дасягнуць адрасы 30.1.1.0/24, прайшоўшы праз маршрутызатар 20.1.1.2.
Вы можаце спытаць, адкуль ён гэта ведае? Проста ўлічыце, што ён даведаецца пра гэта альбо з пратаколаў маршрутызацыі, альбо з вашых настроек, калі вы як адміністратар наладзілі статычны маршрут. Але ў любым выпадку, табліца маршрутызацыі гэтага роўтара ўтрымоўвае патрэбны запіс, таму ён ведае, што павінен адправіць гэты пакет у 20.1.1.2. Мяркуючы, што роўтэр ужо ведае MAC-адрас прызначэння, мы проста працягнем перасыланне пакета. Калі ж ён не ведае гэтага адраса, то зноў запусціць ARP, атрымае MAC-адрас роўтара 20.1.1.2, і працэс адпраўкі фрэйма зноў працягнецца.
Такім чынам, мы мяркуем, што ён ужо ведае MAC-адрас, тады ў нас з'явіцца зыходны MAC-адрас BBB і MAC-адрас прызначэння CCC. Роўтар зноў вылічае FCS/CRC і змяшчае яго ў пачатак фрэйма.
Затым ён адпраўляе гэты фрэйм па сетцы, фрэйм даходзіць да маршрутызатара 20.1.12, той правярае кантрольную суму, пераконваецца, што дадзеныя не пашкоджаны, і выдаляе FCS/CRC. Затым ён "абразае" MAC-адрасы, глядзіць на пункт прызначэння і бачыць, што гэта адрас 30.1.1.10. Ён ведае, што гэты адрас падлучаны да яго інтэрфейсу. Той жа працэс фармавання фрэйма паўтараецца, роўтар дадае значэнні MAC-адрасоў крыніцы і прызначэнні, робіць хэшаванне, прымацоўвае хэш да фрэйма і адпраўляе яго па сетцы.
Наш сервер, атрымаўшы адрасаваны яму SYN-запыт, правярае кантрольную суму хеша, і калі ў пакеце не ўтрымоўвае памылак, выдаляе хэш. Затым ён выдаляе MAC-адрасы, глядзіць на IP-адрас і разумее, што гэты пакет адрасаваны менавіта яму.
Пасля гэтага ён абразае IP-адрасы, якія адносяцца да трэцяга ўзроўню мадэлі OSI, і глядзіць на нумары партоў.
Ён бачыць порт 21, які азначае FTP-трафік, бачыць SYN і таму разумее, што нехта спрабуе ўсталяваць з ім сувязь.
Зараз, у адпаведнасць з тым, што мы пазналі пра поціск рукі, сервер 30.1.1.10 стварае пакет SYN/ACK і адправіць яго зваротна кампутару 10.1.1.10. Атрымаўшы дадзены пакет, прылада 10.1.1.10 створыць ACK, прапусціць яго праз сетку такой жа выявай, як пакет SYN, і пасля атрымання ACK серверам злучэнне будзе ўсталявана.
Адна рэч, якую вы павінны ведаць - усё гэта адбываецца менш чым за секунду. Гэта вельмі і вельмі хуткі працэс, які я пастараўся запаволіць, каб вам было ўсё зразумела.
Я спадзяюся, вам спатрэбіцца тое, што вы даведаліся з гэтага ўрока. Калі ў вас ёсць пытанні, пішыце мне на адрас [электронная пошта абаронена] ці пакідайце пытанні пад гэтым відэа.
Пачынаючы з наступнага ўрока, я буду адбіраць па 3 самых цікавых пытання з YouTube, якія я буду разглядаць у канцы кожнага відэа. З гэтага моманту ў мяне будзе раздзел "Лепшыя пытанні", так што я буду размяшчаць пытанне разам з вашым імем і адказваць на яго ў прамым эфіры. Думаю, гэта пайдзе на карысць.
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас аформіўшы замову або парэкамендаваўшы знаёмым, 30% зніжка для карыстальнікаў Хабра на ўнікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps да лета бясплатна пры аплаце на тэрмін ад паўгода, замовіць можна .
Dell R730xd у 2 разы танней? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com