Մինչ այսօրվա վիդեո դասընթացը սկսելը, ես ուզում եմ շնորհակալություն հայտնել բոլորին, ովքեր նպաստել են YouTube-ում իմ դասընթացի հանրաճանաչությանը: Երբ ես սկսեցի այն մոտ 8 ամիս առաջ, չէի սպասում նման հաջողությունների. այսօր իմ դասերը դիտել է 312724 մարդ, ունեմ 11208 բաժանորդ։ Ես երբեք չէի երազել, որ այս համեստ սկիզբը կհասնի նման բարձունքների: Բայց եկեք ժամանակ չկորցնենք և անմիջապես անցնենք այսօրվա դասին: Այսօր մենք կլրացնենք այն բացերը, որոնք առաջացել են վերջին 7 տեսադասերում։ Չնայած այսօր ընդամենը 6-րդ օրն է, 3-րդ օրը բաժանված է 3 տեսադասերի, ուստի այսօր դուք իրականում դիտելու եք ութերորդ վիդեո դասը:
Այսօր մենք կքննարկենք 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 REQUEST հարցում, որը բառացիորեն ասում է.
Հարցումը ստանալուց հետո 192.168.1.1 DHCP սերվերը պատասխանում է «լավ, ես ընդունում եմ դա», այսինքն՝ ընդունում է հարցումը և ուղարկում այս DHCP ACK-ը հաճախորդին: Բայց մենք հիշում ենք, որ մեկ այլ DHCP սերվեր հաճախորդի համար վերապահել է 1.50 IP հասցե: Երբ այն ստանա հաճախորդի հեռարձակման հարցումը, նա կիմանա ձախողման մասին և այդ 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-ն այն վայրն է, որտեղ ես նետում եմ գնդակը, և դա ձեզնից է կախված՝ տեսնելու, թե արդյոք կարող եք բռնել այն: Պատրա՞ստ ես դա անել, թե՞ ոչ, դա իմ խնդիրը չէ, ես պարզապես պատրաստվում եմ թողնել նրան։
TCP-ն ավելի շատ նման է այն բանին, որ դուք խոսում եք տղայի հետ և նախապես զգուշացնում եք նրան, որ գնդակ եք նետելու, այնպես որ դուք կապ եք ստեղծում, իսկ հետո նետում եք գնդակը, որպեսզի ձեր զուգընկերն ավելի հավանական է, որ պատրաստ լինի այն բռնելու: Այսպիսով, TCP-ն իրականում կառուցում է կապը և այնուհետև սկսում է իրական փոխանցումը կատարել:
Եկեք նայենք, թե ինչպես է դա ստեղծում նման կապ: Այս արձանագրությունն օգտագործում է եռակողմ ձեռքսեղմում կապ ստեղծելու համար: Սա այնքան էլ տեխնիկական տերմին չէ, բայց այն վաղուց օգտագործվել է TCP կապը նկարագրելու համար: Եռակողմ ձեռքսեղմումը նախաձեռնվում է ուղարկող սարքի կողմից, երբ հաճախորդը SYN դրոշակով փաթեթ է ուղարկում սերվեր:
Ասենք, որ առաջին պլանում գտնվող աղջիկը, որի դեմքը տեսնում ենք, A սարքն է, իսկ հետին պլանում գտնվող աղջիկը, որի դեմքը չի երևում, B սարքն է: Աղջիկը A-ն ուղարկում է SYN փաթեթ B աղջկան, և նա ասում է. «Հիանալի է, ով- հետո նա ուզում է շփվել ինձ հետ: Այսպիսով, ես պետք է պատասխանեմ, որ պատրաստ եմ շփվել»: Ինչպե՞ս դա անել: Կարելի է պարզապես հետ ուղարկել մեկ այլ SYN փաթեթ, ապա ACK, որը ցույց է տալիս սկզբնական SYN փաթեթի ստացումը: Բայց ACK-ները առանձին ուղարկելու փոխարեն, սերվերը ձևավորում է ընդհանուր փաթեթ, որը պարունակում է SYN և ACK և փոխանցում այն ցանցով:
Այսպիսով, այս պահին A սարքը ուղարկել է SYN փաթեթ և հետ է ստացել SYN/ACK փաթեթ: Այժմ A սարքը պետք է B սարքին ուղարկի ACK փաթեթ, այսինքն՝ հաստատի, որ այն B սարքից համաձայնություն է ստացել կապ հաստատելու համար: Այսպիսով, երկու սարքերն էլ ստացան 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 փաթեթ և որոշ ժամանակ անց ստացող սարքից ստանում է ACK հաստատում, ինչը նշանակում է, որ ստացողը սպասում է հաջորդ՝ 11-րդ փաթեթին։ Ուղարկողը կարծում է. «Հիանալի է, քանի որ ստացողը միանգամից 10 փաթեթ է մշակել, հիմա ես կփորձեմ նրան ուղարկել 100 փաթեթ՝ տասի փոխարեն»: Նա ուղարկում է 100 փաթեթ, և ստացողը պատասխանում է, որ ստացել է դրանք և այժմ սպասում է 101 փաթեթի: Այսպիսով, ժամանակի ընթացքում փոխանցվող փաթեթների թիվը մեծանում է:
Սա է պատճառը, որ դուք տեսնում եք ֆայլի պատճենման ժամանակի արագ նվազում՝ համեմատած սկզբնապես ասվածի հետ. սա պայմանավորված է մեծ քանակությամբ տվյալներ փոխանցելու ունակությամբ: Այնուամենայնիվ, գալիս է մի պահ, երբ փոխանցման ծավալի հետագա աճն անհնար է դառնում: Ենթադրենք, դուք ուղարկել եք 10000 փաթեթ, բայց ստացողի սարքի բուֆերը կարող է ընդունել միայն 9000: Այս դեպքում ստացողը ACK է ուղարկում հաղորդագրությունով. Սրանից ուղարկողը եզրակացնում է, որ ընդունող սարքի բուֆերն ունի ընդամենը 9000 հզորություն, ինչը նշանակում է, որ այսուհետ ես միաժամանակ կուղարկեմ ոչ ավելի, քան 9001 փաթեթ։ Այս դեպքում ուղարկողը արագորեն հաշվարկում է այն ժամանակը, որը նրան կպահանջվի 9000 փաթեթից բաղկացած տվյալների մնացած քանակությունը փոխանցելու համար և տալիս է 9000 րոպե: Այս երեք րոպեները փոխանցման իրական ժամանակն են: Դա այն է, ինչ անում է TCP Windowing-ը:
Սա այն երթևեկության խափանման մեխանիզմներից մեկն է, որտեղ ուղարկող սարքը ի վերջո հասկանում է, թե որն է իրական ցանցի հզորությունը: Կարող եք մտածել, թե ինչու նրանք չեն կարող նախապես պայմանավորվել, թե որքան է ընդունող սարքի հզորությունը: Փաստն այն է, որ դա տեխնիկապես անհնար է, քանի որ ցանցում կան տարբեր տեսակի սարքեր: Ենթադրենք, դուք ունեք iPad, և այն ունի տվյալների փոխանցման/ընդունիչի այլ արագություն, քան iPhone-ը, դուք կարող եք ունենալ տարբեր տեսակի հեռախոսներ, կամ գուցե դուք ունեք շատ հին համակարգիչ: Հետևաբար, յուրաքանչյուրն ունի ցանցի տարբեր թողունակություն:
Այդ իսկ պատճառով մշակվել է TCP Windowing տեխնոլոգիան, երբ տվյալների փոխանցումը սկսվում է ցածր արագությամբ կամ նվազագույն թվով փաթեթների փոխանցմամբ՝ աստիճանաբար մեծացնելով տրաֆիկի «պատուհանը»: Դուք ուղարկում եք մեկ փաթեթ, 5 փաթեթ, 10 փաթեթ, 1000 փաթեթ, 10000 փաթեթ և կամաց-կամաց բացում եք այդ պատուհանը ավելի ու ավելի, մինչև «բացումը» հասնի որոշակի ժամանակահատվածում ուղարկված տրաֆիկի առավելագույն հնարավոր ծավալին: Այսպիսով, պատուհանի հայեցակարգը 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: Այսպիսով, պաշտոնապես TCP 80 նավահանգիստն օգտագործվում է HTTP-ի համար, իսկ ոչ պաշտոնապես UDP պորտը 80-ն օգտագործվում է HTTP-ի համար, բայց այլ HTTP արձանագրության ներքո՝ QUIC:
Հետևաբար, TCP-ում պորտի համարները միշտ չէ, որ նախատեսված են նույն բանն անելու համար, ինչ UDP-ում: Ձեզ հարկավոր չէ անգիր սովորել այս ցուցակը, դա անհնար է հիշել, բայց դուք պետք է իմանաք որոշ հայտնի և ամենատարածված նավահանգիստների համարները: Ինչպես ասացի, այս նավահանգիստներից մի քանիսն ունեն պաշտոնական նպատակ, որը նկարագրված է ստանդարտներում, իսկ որոշները ունեն ոչ պաշտոնական նպատակ, ինչպես դա Chromium-ի դեպքում է:
Այսպիսով, այս աղյուսակը թվարկում է բոլոր սովորական նավահանգիստների համարները, և այդ թվերն օգտագործվում են հատուկ հավելվածներ օգտագործելիս տրաֆիկ ուղարկելու և ստանալու համար:
Հիմա եկեք տեսնենք, թե ինչպես են տվյալները շարժվում ցանցով` հիմնվելով մեր իմացած քիչ տեղեկությունների վրա: Ենթադրենք, որ համակարգիչը 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 է, և ես պետք է կապվեմ 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 հարցում, որը կստանան ցանցի բոլոր սարքերը, բայց միայն 10.1.1.1 IP հասցեով երթուղիչը կարձագանքի դրան:
Երթուղիչը կպատասխանի իր AAAA MAC հասցեով, և այս շրջանակում կտեղադրվեն և՛ սկզբնաղբյուր, և՛ նպատակակետ MAC հասցեները: Երբ շրջանակը պատրաստ է, CRC տվյալների ամբողջականության ստուգում, որը սխալները հայտնաբերելու համար ստուգիչ գումար գտնելու ալգորիթմ է, կկատարվի ցանցից դուրս գալուց առաջ:
Cyclic Redundancy CRC-ն նշանակում է, որ այս ամբողջ շրջանակը՝ SYN-ից մինչև վերջին MAC հասցեն, գործարկվում է հեշավորման ալգորիթմի միջոցով, ասենք MD5, ինչը հանգեցնում է հեշ արժեքի: Հեշ արժեքը կամ MD5 checksum-ը տեղադրվում է շրջանակի սկզբում:
Ես այն պիտակավորեցի FCS/CRC, քանի որ FCS-ը շրջանակների ստուգման հաջորդականություն է, չորս բայթանոց CRC արժեք: Որոշ մարդիկ օգտագործում են FCS նշումը, իսկ ոմանք օգտագործում են CRC նշումը, այնպես որ ես պարզապես ներառեցի երկու նշանակումները: Բայց հիմնականում դա պարզապես հեշ արժեք է: Դա անհրաժեշտ է համոզվելու համար, որ ցանցով ստացված բոլոր տվյալները սխալներ չեն պարունակում: Հետևաբար, երբ այս շրջանակը հասնում է երթուղիչին, առաջին բանը, որ երթուղիչը կանի, ինքնին հաշվարկել է ստուգման գումարը և համեմատել այն FCS կամ CRC արժեքի հետ, որը պարունակում է ստացված շրջանակը: Այս կերպ նա կարող է ստուգել, որ ցանցով ստացված տվյալները սխալներ չեն պարունակում, որից հետո նա կհեռացնի checksum-ը շրջանակից։
Հաջորդը, երթուղիչը կնայի 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 հասցեն, ապա մենք կունենանք 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-ը, կապը կհաստատվի:
Մի բան, որ դուք պետք է իմանաք, այն է, որ այս ամենը տեղի է ունենում մեկ վայրկյանից քիչ ժամանակում: Սա շատ, շատ արագ գործընթաց է, որը ես փորձեցի դանդաղեցնել, որպեսզի ամեն ինչ պարզ լինի ձեզ համար։
Հուսով եմ, որ այս ձեռնարկում ձեր սովորածը օգտակար կլինի: Հարցերի դեպքում գրեք ինձ էլ [էլեկտրոնային փոստով պաշտպանված] կամ հարցեր թողեք այս տեսանյութի տակ:
Հաջորդ դասից սկսած ես կընտրեմ 3 ամենահետաքրքիր հարցերը YouTube-ից, որոնք կվերանայեմ յուրաքանչյուր տեսանյութի վերջում։ Այսուհետ ես կունենամ «Թոփ հարցեր» բաժինը, այնպես որ ձեր անվան հետ մեկտեղ կտեղադրեմ հարց և կպատասխանեմ ուղիղ եթերում: Կարծում եմ՝ սա ձեռնտու կլինի։
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, 30% զեղչ Habr-ի օգտատերերի համար մուտքի մակարդակի սերվերների եզակի անալոգի վրա, որը ստեղծվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ 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-ից: Կարդացեք մասին
Source: www.habr.com