Бүгүнкү видеосабакты баштаардан мурун менин курсумдун YouTube'да популярдуу болушуна салым кошкондордун баарына ыраазычылык билдиргим келет. Мен аны 8 ай мурун баштаганда мындай ийгиликти күткөн эмесмин – бүгүнкү күндө менин сабактарымды 312724 11208 адам көрдү, менин 7 6 жазылуучум бар. Бул жупуну башталыш мынчалык бийиктикке жетет деп түшүмө да кирген эмес. Бирок убакытты текке кетирбей, түз эле бүгүнкү сабакка өтөлү. Бүгүн биз акыркы 3 видеосабакта орун алган боштуктарды толтурабыз. Бүгүн болгону 3-күн болсо да, XNUMX-күн XNUMX видеосабакка бөлүнгөн, ошондуктан бүгүн сиз сегизинчи видеосабакты көрөсүз.
Бүгүн биз 3 маанилүү теманы карайбыз: DHCP, TCP транспорту жана эң кеңири таралган порт номерлери. Биз буга чейин IP даректер жөнүндө сүйлөштүк жана IP дарек конфигурациясынын эң маанилүү факторлорунун бири DHCP болуп саналат.
DHCP Dynamic Host Configuration Protocol дегенди билдирет жана бул хосттор үчүн 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 сервери 192.168.1.2 сунуштаган 192.168.1.1 IP дарегин кабыл алам" деген DHCP REQUEST сурамын жөнөтөт дегенди билдирет.
Сурам кабыл алынгандан кийин, 192.168.1.1 DHCP сервери "макул, мен муну моюнга алам" деп жооп берет, башкача айтканда, ал сурамды кабыл алат жана бул DHCP ACK кардарга жөнөтөт. Бирок биз башка DHCP сервери кардар үчүн 1.50 IP дарегин сактаганын эсибизде. Кардардын уктуруу өтүнүчүн алгандан кийин, ал бузулганын билет жана башка суроо-талапты алса, аны башка кардарга дайындоо үчүн ошол IP даректи кайра бассейнге салат.
Бул DHCP IP даректерин дайындоодо алмашуучу 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 пакетти гана кабыл ала алат. Мындай учурда ресивер ACK билдирүүсүн жөнөтөт: "Мен 9000 9000 пакет алдым жана азыр 9000 3 пакетти кабыл алууга даярмын". Мындан жөнөтүүчү кабыл алуучу түзүлүштүн буферинин сыйымдуулугу болгону XNUMX деген жыйынтыкка келет, бул мындан ары мен бир убакта XNUMX пакеттен ашык эмес жөнөтөм дегенди билдирет. Бул учурда, жөнөтүүчү XNUMX пакеттердин бөлүктөрү боюнча маалыматтардын калган суммасын өткөрүп берүү үчүн ага кетчү убакытты тез эсептеп, XNUMX мүнөт берет. Бул үч мүнөт чыныгы берүү убактысы болуп саналат. TCP Windowing эмне кылат.
Бул трафикти басаңдатуучу механизмдердин бири, анда жөнөтүүчү аппарат акыры тармактын иш жүзүндөгү сыйымдуулугу эмне экенин түшүнөт. Эмне үчүн алар кабыл алуучу аппараттын кубаттуулугу боюнча алдын ала макулдаша алышпайт деп ойлонуп жатсаңыз керек? Чындыгында, бул техникалык жактан мүмкүн эмес, анткени тармакта ар кандай түзүлүштөр бар. Айталы, сизде iPad бар жана анын маалымат берүү/кабыл алуу ылдамдыгы айфонго караганда башкача, сизде ар кандай телефондор болушу мүмкүн же сизде абдан эски компьютер бар. Ошондуктан, ар ким ар кандай тармак өткөрүү жөндөмдүүлүгүнө ээ.
Мына ошондуктан TCP Windowing технологиясы иштелип чыккан, маалыматтарды берүү төмөнкү ылдамдыкта же пакеттердин минималдуу санын берүү менен башталганда, трафиктин "терезесин" акырындык менен көбөйтөт. Сиз бир пакет, 5 пакет, 10 пакет, 1000 пакет, 10000 XNUMX пакет жөнөтөсүз жана "ачылуу" белгилүү бир убакыт аралыгында жөнөтүлгөн трафиктин максималдуу мүмкүн болгон көлөмүнө жеткенге чейин ошол терезени акырындап ачасыз. Ошентип, Windowing түшүнүгү TCP протоколунун ишинин бир бөлүгү болуп саналат.
Андан кийин биз эң кеңири таралган порт номерлерин карап чыгабыз. Классикалык жагдай - бул сизде 1 негизги сервер, балким, маалымат борбору. Бул файл серверин, веб-серверди, почта серверин жана DHCP серверин камтыйт. Эми, эгерде кардар компьютерлеринин бири сүрөттүн ортосунда жайгашкан маалымат борборуна кайрылса, ал кардардын түзмөктөрүнө файл серверинин трафигин жөнөтө баштайт. Бул трафик кызыл түс менен көрсөтүлөт жана белгилүү бир серверден белгилүү бир тиркеме үчүн белгилүү бир портто өткөрүлөт.
Сервер белгилүү бир трафик кайда кетиши керек экенин кайдан билген? Ал муну көздөгөн порттун номеринен үйрөнөт. Эгер кадрды карасаңыз, ар бир берилиштерди өткөрүүдө көздөгөн порттун номери жана булак портунун номери айтылганын көрөсүз. Сиз көк жана кызыл трафик, ал эми көк трафик веб-сервер трафиги экенин көрө аласыз, экөө тең ар кандай серверлер орнотулган бир эле физикалык серверге барат. Эгер бул маалымат борбору болсо, анда ал виртуалдык серверлерди колдонот. Ошентип, алар кызыл трафик ошол IP дареги менен ошол сол ноутбукка кайтып келиши керек экенин кайдан билишкен? Алар муну порт номерлеринин аркасында билишет. Эгер сиз Wikipediaдагы "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 саны.
Андан кийин, система пакетке көздөгөн портту кошот, бул учурда ал 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 бул Frame Check Sequence, төрт байттык 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.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com