Пре него што започнемо данашњи видео туторијал, желим да се захвалим свима који су допринели популарности мог курса на Јутјубу. Када сам га започео пре око 8 месеци, нисам очекивао такав успех - данас је моје лекције погледало 312724 људи, имам 11208 претплатника. Нисам ни сањао да ће овај скромни почетак достићи такве висине. Али хајде да не губимо време и пређимо одмах на данашњу лекцију. Данас ћемо попунити празнине које су настале у последњих 7 видео лекција. Иако је данас само 6. дан, дан 3 је подељен на 3 видео лекције, тако да ћете данас заправо гледати осму видео лекцију.
Данас ћемо покрити 3 важне теме: ДХЦП, ТЦП транспорт и најчешћи бројеви портова. Већ смо говорили о ИП адресама, а један од најважнијих фактора у конфигурацији ИП адресе је ДХЦП.
ДХЦП је скраћеница за Динамиц Хост Цонфигуратион Протоцол и то је протокол који помаже у динамичком конфигурисању ИП адреса за хостове. Дакле, сви смо видели овај прозор. Када кликнете на опцију „Аутоматски добиј ИП адресу“, рачунар тражи ДХЦП сервер који је конфигурисан на истој подмрежи и шаље разне пакете и захтеве за ИП адресу. ДХЦП протокол има 6 порука, од којих су 4 критичне за додељивање ИП адресе.
Прва порука је ДХЦП ДИСЦОВЕРИ порука. Порука откривања ДХЦП-а је слична поздравној поруци. Када се нови уређај придружи мрежи, пита да ли постоји ДХЦП сервер на мрежи.
Оно што видите на слајду изгледа као захтев за емитовање где уређај контактира све уређаје на мрежи тражећи ДХЦП сервер. Као што сам рекао, ово је захтев за емитовање, тако да сви уређаји на мрежи могу да га чују.
Ако постоји ДХЦП сервер на мрежи, он шаље пакет - понуду ДХЦП ОФФЕР. Предлог значи да ДХЦП сервер, као одговор на захтев за откривање, шаље конфигурацију клијенту, тражећи од клијента да прихвати одређену ИП адресу.
ДХЦП сервер резервише ИП адресу, у овом случају 192.168.1.2, не даје је, већ резервише ову адресу за уређај. Истовремено, пакет понуде садржи сопствену ИП адресу ДХЦП сервера.
Ако на овој мрежи постоји више од једног ДХЦП сервера, други ДХЦП сервер би му по пријему захтева за емитовање такође понудио своју ИП адресу, на пример 192.168.1.50. Није уобичајено имати два различита ДХЦП сервера конфигурисана на истој мрежи, али понекад се то дешава. Дакле, када се ДХЦП понуда пошаље клијенту, он прима 2 ДХЦП понуде и сада мора да одлучи коју ДХЦП понуду жели да прихвати.
Претпоставимо да клијент прихвата прву апликацију. То значи да клијент шаље ДХЦП РЕКУЕСТ захтев који дословно каже „Прихватам ИП адресу 192.168.1.2 коју нуди ДХЦП сервер 192.168.1.1.“
По пријему захтева, ДХЦП сервер 192.168.1.1 одговара „у реду, признајем“, то јест, потврђује захтев и шаље овај ДХЦП АЦК клијенту. Али сећамо се да је други ДХЦП сервер резервисао ИП адресу од 1.50 за клијента. Када прими захтев за емитовање клијента, знаће за грешку и вратиће ту ИП адресу у скуп тако да може да је додели другом клијенту ако прими други захтев.
Ово су 4 критичне поруке које ДХЦП размењује приликом додељивања ИП адреса. Затим, ДХЦП има још 2 информативне поруке. Информациону поруку клијент издаје ако захтева више информација него што је примио у ДХЦП ОФФЕР клаузули у другом кораку. Ако сервер није дао довољно информација у ДХЦП понуди, или ако је клијенту потребно више информација од онога што је садржано у пакету понуде, он захтева додатне ДХЦП информације. Постоји још једна порука коју клијент шаље серверу - ово је ДХЦП РЕЛЕАСЕ. Обавештава вас да клијент жели да ослободи своју постојећу ИП адресу.
Међутим, оно што се најчешће дешава је да се корисник искључи са мреже пре него што клијент има времена да пошаље ДХЦП РЕЛЕАСЕ серверу. Ово се дешава када искључите рачунар, што ми радимо. У овом случају, мрежни клијент, или рачунар, једноставно нема времена да обавести сервер да ослободи коришћену адресу, тако да ДХЦП РЕЛЕАСЕ није обавезан корак. Потребни кораци за добијање ИП адресе су: ДХЦП откривање, ДХЦП понуда, ДХЦП захтев и ДХЦП руковање.
У једној од наредних лекција рећи ћу вам како конфигуришемо ДХЦП сервер приликом креирања ДНЦП базена. Под обједињавањем подразумевамо да кажете серверу да додели ИП адресе у опсегу од 192.168.1.1 до 192.168.1.254. Тако ће ДХЦП сервер креирати базен, у њега поставити 254 ИП адресе и моћи ће да додељује адресе клијентима на мрежи само из овог базена. Дакле, ово је нешто попут административног подешавања које корисник може да уради.
Погледајмо сада ТЦП пренос. Не знам да ли вам је познат "телефон" на слици, али када смо били деца користили смо ове лимене лименке повезане канапом да разговарамо једни са другима.
Нажалост, данашња генерација не може себи да приушти такав „луксуз“. Мислим данас су деца испред ТВ-а од једне године, играју ПСП и можда је ово дискутабилно, али мислим да смо имали најлепше детињство, заправо смо излазили напоље и играли игрице и данашња деца се не могу одвојити од софе .
Мој син има само годину дана и већ видим да је зависник од иПад-а, мислим да је још веома мали, али мислим да су данашња деца већ рођена да знају да рукују електронским уређајима. Дакле, хтео сам да кажем да смо као деца, када смо се играли, правили рупе у лименкама, а када смо их везали канапом и рекли нешто у једну конзерву, онда је на другом крају човек могао да чује шта се прича њему, једноставним приношењем конзерве његовом уху. Дакле, веома је слично мрежној вези.
Данас чак и ТЦП трансфери морају имати везу која се мора успоставити пре него што стварни пренос података почне. Као што смо расправљали у претходним лекцијама, ТЦП је пренос оријентисан на везу, док је УДП пренос оријентисан на везу. Могло би се рећи да је УДП место где ја бацам лопту и на вама је да видите да ли можете да је ухватите. Да ли сте спремни да то урадите или не, није мој проблем, само ћу га оставити.
ТЦП је више као да разговарате са типом и унапред га упозоравате да ћете бацити лопту, тако да формирате везу, а затим баците лопту тако да је већа вероватноћа да ће ваш партнер бити спреман да је ухвати. Дакле, ТЦП заправо гради везу и онда почиње да обавља стварни пренос.
Погледајмо како то ствара такву везу. Овај протокол користи 3-смерно руковање за стварање везе. Ово није баш технички термин, али се дуго користи за описивање ТЦП везе. Уређај за слање иницира тросмерно руковање, при чему клијент шаље серверу пакет са СИН заставицом.
Рецимо да је девојка у првом плану, чије лице можемо да видимо, уређај А, а девојка у позадини, чије се лице не види, је уређај Б. Девојка А шаље СИН пакет девојчици Б, а она каже: „Супер, ко- онда жели да комуницира са мном. Дакле, морам да одговорим да сам спреман да комуницирам!“ Како се то ради? Може се једноставно послати назад још један СИН пакет, а затим АЦК који указује на пријем оригиналног СИН пакета. Али уместо да засебно шаље АЦК-ове, сервер формира заједнички пакет који садржи СИН и АЦК и преноси га преко мреже.
Дакле, у овом тренутку, уређај А је послао СИН пакет и примио назад СИН/АЦК пакет. Сада уређај А мора да пошаље уређају Б АЦК пакет, односно потврди да је од уређаја Б добио сагласност за успостављање комуникације. Дакле, оба уређаја су примила СИН и АЦК пакете и сада можемо рећи да је веза успостављена, односно да је завршено 3-степено руковање помоћу ТЦП протокола.
Затим ћемо погледати ТЦП Виндовинг технологију. Једноставно речено, то је метода која се користи у ТЦП/ИП-у за преговарање о могућностима пошиљаоца и примаоца.
Рецимо да у Виндовс-у покушавамо да пренесемо велику датотеку, рецимо величине 2 ГБ, са једног диска на други. На самом почетку преноса, систем ће нас обавестити да ће пренос датотеке трајати отприлике годину дана. Али неколико секунди касније систем ће се исправити и рећи: „Ох, сачекај мало, мислим да ће требати око 1 месеци, а не годину дана“. Проћи ће још мало времена и Виндовс ће рећи: „Мислим да бих могао да пренесем датотеку за месец дана.“ Ово ће бити праћено поруком „6 дан“, „1 сати“, „1 сата“, „6 сат“, „3 минута“, „1 минута“, „20 минута“. У ствари, цео процес преноса датотека ће трајати само 10 минута. Како се то догодило? У почетку, када ваш уређај покуша да комуницира са другим уређајем, он шаље један пакет и чека потврду. Ако уређај дуго чека на потврду, он мисли: „ако морам да пренесем 3 ГБ података овом брзином, биће потребно око 3 године.“ Након неког времена, ваш уређај прима АЦК и мисли: „У реду, послао сам један пакет и добио АЦК, тако да прималац може да прими 2 пакет. Сада ћу покушати да му пошаљем 2 пакета уместо једног.” Пошиљалац шаље 1 пакета и након неког времена добија АЦК потврду од пријемног уређаја, што значи да прималац чека на следећи, 10. пакет. Пошиљалац мисли: „одлично, пошто је прималац обрадио 10 пакета одједном, сада ћу покушати да му пошаљем 11 пакета уместо десет. Он пошаље 10 пакета, а прималац одговара да их је примио и сада чека 100 пакет. Тако се временом повећава број пренетих пакета.
Због тога видите брзо смањење времена копирања датотеке у односу на оно што је првобитно наведено - то је због повећане могућности преноса великих количина података. Међутим, долази до тачке када даље повећање обима преноса постаје немогуће. Рецимо да сте послали 10000 пакета, али бафер уређаја примаоца може да прихвати само 9000. У овом случају, прималац шаље АЦК са поруком: "Примио сам 9000 пакета и сада сам спреман да примим 9001." Из овога пошиљалац закључује да бафер пријемног уређаја има капацитет од само 9000, што значи да од сада нећу слати више од 9000 пакета одједном. У овом случају, пошиљалац брзо израчунава време које ће му требати да пренесе преосталу количину података у порцијама од 9000 пакета и даје 3 минута. Ова три минута су стварно време преноса. То је оно што ТЦП Виндовинг ради.
Ово је један од оних механизама за смањење саобраћаја где уређај за слање на крају разуме колики је стварни капацитет мреже. Можда се питате зашто не могу унапред да се договоре колики је капацитет пријемног уређаја? Чињеница је да је то технички немогуће јер на мрежи постоје различите врсте уређаја. Рецимо да имате иПад и он има другачију брзину преноса/пријема података од иПхоне-а, можда имате различите типове телефона или можда имате веома стар рачунар. Дакле, сви имају различиту пропусност мреже.
Због тога је развијена ТЦП Виндовинг технологија, када пренос података почиње малом брзином или са преносом минималног броја пакета, постепено повећавајући „прозор“ саобраћаја. Шаљете један пакет, 5 пакета, 10 пакета, 1000 пакета, 10000 пакета и полако отварате тај прозор све више и више док „отварање“ не достигне највећи могући обим саобраћаја послатог у одређеном временском периоду. Дакле, концепт Виндовинг-а је део рада ТЦП протокола.
Затим ћемо погледати најчешће бројеве портова. Класична ситуација је када имате 1 главни сервер, можда центар података. Укључује сервер датотека, веб сервер, сервер поште и ДХЦП сервер. Сада, ако један од клијентских рачунара контактира центар података, који се налази у средини слике, он ће почети да шаље саобраћај сервера датотека клијентским уређајима. Овај саобраћај је приказан црвеном бојом и биће пренет на одређени порт за одређену апликацију са одређеног сервера.
Како је сервер знао где одређени саобраћај треба да иде? Он то сазнаје из броја одредишног порта. Ако погледате оквир, видећете да се у сваком преносу података помиње број одредишног порта и број изворног порта. Можете видети да плави и црвени саобраћај, а плави саобраћај је саобраћај веб сервера, оба иду на исти физички сервер, који има инсталиране различите сервере. Ако је ово центар података, онда користи виртуелне сервере. Па како су знали да је црвени саобраћај требало да се врати на онај леви лаптоп са том ИП адресом? Они то знају захваљујући бројевима портова. Ако погледате чланак Википедије „Листа ТЦП и УДП портова“, видећете да су наведени сви стандардни бројеви портова.
Ако скролујете надоле ову страницу, можете видети колика је ова листа. Садржи око 61 бројева. Бројеви портова од 000 до 1 познати су као најчешћи бројеви портова. На пример, порт 1024/ТЦП је намењен за слање фтп команди, порт 21 за ссх, порт 22 за Телнет, односно за слање нешифрованих порука. Веома популаран порт 23 се користи за пренос података помоћу ХТТП протокола, док се порт 80 користи за пренос шифрованих података користећи ХТТПС протокол, који је сличан безбедној верзији ХТТП-а.
Неки портови су посвећени и ТЦП и УДП, а неки обављају различите задатке у зависности од тога да ли је веза ТЦП или УДП. Дакле, званично се ТЦП порт 80 користи за ХТТП, а незванично УДП порт 80 се користи за ХТТП, али под другим ХТТП протоколом - КУИЦ.
Према томе, бројеви портова у ТЦП-у нису увек намењени да раде исту ствар као у УДП-у. Не морате да научите ову листу напамет, немогуће је запамтити, али морате знати неке популарне и најчешће бројеве портова. Као што сам рекао, неки од ових портова имају званичну намену, што је описано у стандардима, а неки имају незваничну, као што је случај са Цхромиум-ом.
Дакле, ова табела наводи све уобичајене бројеве портова, а ти бројеви се користе за слање и примање саобраћаја када се користе одређене апликације.
Сада погледајмо како се подаци крећу широм мреже на основу оно мало информација које знамо. Рецимо да рачунар 10.1.1.10 жели да контактира овај рачунар, или овај сервер, који има адресу 30.1.1.10. Испод ИП адресе сваког уређаја налази се његова МАЦ адреса. Дајем пример МАЦ адресе са само последња 4 знака, али у пракси је то 48-битни хексадецимални број са 12 карактера. Пошто се сваки од ових бројева састоји од 4 бита, 12 хексадецималних цифара представљају 48-битни број.
Као што знамо, ако овај уређај жели да контактира овај сервер, прво мора да се уради први корак 3-смерног руковања, односно слање СИН пакета. Када се овај захтев упути, рачунар 10.1.1.10 ће навести број изворног порта, који Виндовс креира динамички. Виндовс насумично бира број порта између 1 и 65,000. Али пошто су почетни бројеви у опсегу од 1 до 1024 нашироко познати, у овом случају систем ће узети у обзир бројеве веће од 25000 и креирати насумични изворни порт, на пример, број 25113.
Затим ће систем пакету додати одредишни порт, у овом случају то је порт 21, јер апликација која покушава да се повеже са овим ФТП сервером зна да треба да шаље ФТП саобраћај.
Затим наш рачунар каже: „У реду, моја ИП адреса је 10.1.1.10 и морам да контактирам ИП адресу 30.1.1.10.“ Обе ове адресе су такође укључене у пакет да би се формирао СИН захтев, и овај пакет се неће променити до краја везе.
Желим да из овог видеа разумете како се подаци крећу широм мреже. Када наш рачунар који шаље захтев види изворну ИП адресу и одредишну ИП адресу, разуме да одредишна адреса није на тој локалној мрежи. Заборавио сам да кажем да су ово све /24 ИП адресе. Дакле, ако погледате /24 ИП адресе, схватићете да рачунари 10.1.1.10 и 30.1.1.10 нису на истој мрежи. Дакле, рачунар који шаље захтев разуме да да би напустио ову мрежу, мора да контактира 10.1.1.1 гатеваи, који је конфигурисан на једном од интерфејса рутера. Зна да треба да иде на 10.1.1.1 и зна своју МАЦ адресу 1111, али не зна МАЦ адресу мрежног пролаза 10.1.1.1. Шта он то ради? Шаље емитовани АРП захтев који ће примити сви уређаји на мрежи, али ће само рутер са ИП адресом 10.1.1.1 одговорити на њега.
Рутер ће одговорити својом АААА МАЦ адресом, а и изворна и одредишна МАЦ адреса ће такође бити смештене у овај оквир. Када је оквир спреман, ЦРЦ провера интегритета података, што је алгоритам за проналажење контролне суме за откривање грешака, биће извршена пре напуштања мреже.
ЦРЦ цикличне редундансе значи да цео овај оквир, од СИН до последње МАЦ адресе, пролази кроз алгоритам хеширања, рецимо МД5, што резултира хеш вредношћу. Хеш вредност или МД5 контролни збир се затим поставља на почетак оквира.
Означио сам га ФЦС/ЦРЦ јер је ФЦС секвенца за проверу оквира, четворобајтна ЦРЦ вредност. Неки људи користе ознаку ФЦС, а неки користе ознаку ЦРЦ, тако да сам управо укључио обе ознаке. Али у суштини то је само хеш вредност. Потребно је осигурати да сви подаци примљени преко мреже не садрже грешке. Стога, када овај оквир стигне до рутера, прва ствар коју ће рутер урадити је да израчуна сам контролни збир и упореди га са ФЦС или ЦРЦ вредношћу коју примљени оквир садржи. На овај начин он може да провери да ли подаци примљени преко мреже не садрже грешке, након чега ће уклонити контролни збир из оквира.
Затим, рутер ће погледати МАЦ адресу и рећи: „У реду, МАЦ адреса АААА значи да је оквир адресиран на мене“, и избрисати део оквира који садржи МАЦ адресе.
Гледајући ИП адресу одредишта 30.1.1.10, схватиће да овај пакет није адресиран на њега и да мора да иде даље кроз рутер.
Сада рутер „мисли“ да треба да види где се налази мрежа са адресом 30.1.1.10. Још увек нисмо покрили цео концепт рутирања, али знамо да рутери имају табелу рутирања. Ова табела има унос за мрежу са адресом 30.1.1.0. Као што се сећате, ово није ИП адреса домаћина, већ идентификатор мреже. Рутер ће „мислити“ да може доћи до адресе 30.1.1.0/24 пролазећи кроз рутер 20.1.1.2.
Можете питати, како он то зна? Само имајте на уму да ће то знати или из протокола за рутирање или из ваших подешавања ако сте ви као администратор конфигурисали статичку руту. Али у сваком случају, табела рутера овог рутера садржи тачан унос, тако да зна да треба да пошаље овај пакет на 20.1.1.2. Под претпоставком да рутер већ зна одредишну МАЦ адресу, једноставно ћемо наставити да прослеђујемо пакет. Ако не зна ову адресу, поново ће покренути АРП, примити МАЦ адресу рутера 20.1.1.2 и процес слања оквира ће се поново наставити.
Дакле, претпостављамо да већ зна МАЦ адресу, тада ћемо имати БББ изворну МАЦ адресу и ЦЦЦ одредишну МАЦ адресу. Рутер поново израчунава ФЦС/ЦРЦ и поставља га на почетак оквира.
Затим шаље овај оквир преко мреже, оквир стиже до рутера 20.1.12, проверава контролни збир, уверава се да подаци нису оштећени и брише ФЦС/ЦРЦ. Затим „скрати“ МАЦ адресе, погледа одредиште и види да је 30.1.1.10. Он зна да је ова адреса повезана са његовим интерфејсом. Исти процес формирања оквира се понавља, рутер додаје вредности изворне и одредишне МАЦ адресе, врши хеширање, прикачује хеш оквиру и шаље га преко мреже.
Наш сервер, након што је коначно примио СИН захтев упућен њему, проверава хеш контролни збир, и ако пакет не садржи грешке, брише хеш. Затим уклања МАЦ адресе, гледа ИП адресу и схвата да је овај пакет адресиран на њега.
Након тога скраћује ИП адресе везане за трећи слој ОСИ модела и гледа бројеве портова.
Он види порт 21, што значи ФТП саобраћај, види СИН и стога разуме да неко покушава да комуницира са њим.
Сада, на основу онога што смо сазнали о руковању, сервер 30.1.1.10 ће креирати СИН/АЦК пакет и послати га назад на рачунар 10.1.1.10. По пријему овог пакета, уређај 10.1.1.10 ће креирати АЦК, проследити га кроз мрежу на исти начин као и СИН пакет, а након што сервер прими АЦК, веза ће бити успостављена.
Једна ствар коју треба да знате је да се све ово дешава за мање од секунде. Ово је веома, веома брз процес, који сам покушао да успорим да вам све буде јасно.
Надам се да ће вам оно што сте научили у овом водичу бити корисно. Ако имате питања, пишите ми на [емаил заштићен] или оставите питања испод овог видеа.
Почевши од следеће лекције, изабраћу 3 најзанимљивија питања са Јутјуба, која ћу прегледати на крају сваког видеа. Од сада ћу имати одељак „Најважнија питања“ тако да ћу поставити питање заједно са вашим именом и одговорити уживо. Мислим да ће ово бити од користи.
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, 30% попуста за кориснике Хабра на јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
ВПС (КВМ) Е5-2650 в4 (6 језгара) 10ГБ ДДР4 240ГБ ССД 1Гбпс бесплатно до лета при плаћању за период од шест месеци или више, можете наручити .
Делл Р730кд 2 пута јефтинији? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом