Cisco Training 200-125 CCNA v3.0. დღე 6: ცარიელი ადგილების შევსება (DHCP, TCP, ხელის ჩამორთმევა, საერთო პორტის ნომრები)

სანამ დღევანდელ ვიდეო გაკვეთილს დავიწყებდეთ, მინდა მადლობა გადავუხადო ყველას, ვინც წვლილი შეიტანა ჩემი კურსის პოპულარობაში 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 მოთხოვნას, რომელიც სიტყვასიტყვით ამბობს: "მე ვიღებ IP მისამართს 192.168.1.2, რომელსაც გთავაზობთ DHCP სერვერი 192.168.1.1."

მოთხოვნის მიღებისთანავე, 192.168.1.1 DHCP სერვერი პასუხობს „კარგი, ვაღიარებ“, ანუ ის ადასტურებს მოთხოვნას და უგზავნის ამ DHCP ACK-ს კლიენტს. მაგრამ ჩვენ გვახსოვს, რომ სხვა 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-ს და შეიძლება ეს საკამათოა, მაგრამ ვფიქრობ, რომ საუკეთესო ბავშვობა გვქონდა, რეალურად გამოვედით გარეთ და ვითამაშეთ და დღევანდელ ბავშვებს დივანს ვერ აშორებენ. .

ჩემი შვილი მხოლოდ ერთი წლისაა და უკვე ვხედავ, რომ ის აიპადზეა დამოკიდებული, ვგულისხმობ, რომ ჯერ კიდევ ძალიან პატარაა, მაგრამ ვფიქრობ, რომ დღევანდელი ბავშვები უკვე იბადებიან, იციან როგორ მართონ ელექტრონული გაჯეტები. ამიტომ, მინდოდა მეთქვა, რომ ბავშვობაში, როცა ვთამაშობდით, თუნუქის ქილებს ვაკეთებდით ნახვრეტებს და როცა მათ ძაფს ვაკრავდით და ერთ ქილაში რაღაცას ვამბობდით, მეორე კიდეზე ადამიანი ესმოდა სათქმელს. მას, უბრალოდ ქილა ყურთან მიტანით. ასე რომ, ეს ძალიან ჰგავს ქსელურ კავშირს.

დღეს, TCP გადარიცხვებსაც კი უნდა ჰქონდეს კავშირი, რომელიც უნდა დამყარდეს მონაცემთა გადაცემის დაწყებამდე. როგორც წინა გაკვეთილებში განვიხილეთ, TCP არის კავშირზე ორიენტირებული გადაცემა, ხოლო UDP არის კავშირზე ორიენტირებული გადაცემა. შეიძლება ითქვას, რომ UDP არის ადგილი, სადაც მე ვესროლე ბურთს და თქვენი გადასაწყვეტია დაინახოთ, შეძლებთ თუ არა მის დაჭერას. მზად ხარ ამის გასაკეთებლად თუ არა, ჩემი პრობლემა არ არის, მე უბრალოდ ვაპირებ მის მიტოვებას.

TCP უფრო ჰგავს ბიჭს ესაუბრებით და წინასწარ აფრთხილებთ მას, რომ ბურთის სროლას აპირებთ, ასე რომ თქვენ ქმნით კავშირს და შემდეგ ისვრით ბურთს ისე, რომ თქვენი პარტნიორი უფრო მეტად მზად იყოს მის დასაჭერად. ასე რომ, TCP რეალურად აშენებს კავშირს და შემდეგ იწყებს ფაქტობრივ გადაცემას.

ვნახოთ, როგორ ქმნის ის ასეთ კავშირს. ეს პროტოკოლი იყენებს 3-მხრივ ხელის ჩამორთმევას კავშირის შესაქმნელად. ეს არ არის ძალიან ტექნიკური ტერმინი, მაგრამ ის დიდი ხანია გამოიყენება TCP კავშირის აღსაწერად. 3-მხრივი ხელის ჩამორთმევა ინიცირებულია გამგზავნი მოწყობილობის მიერ, კლიენტი აგზავნის პაკეტს 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-ში გამგზავნისა და მიმღების შესაძლებლობებზე მოსალაპარაკებლად.

ვთქვათ, ვინდოუსში ვცდილობთ გადავიტანოთ დიდი ფაილი, ვთქვათ 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 პაკეტს. ამ შემთხვევაში გამგზავნი სწრაფად ითვლის იმ დროს, რაც მას დასჭირდება 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. ასე რომ, ოფიციალურად 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 და უნდა დავუკავშირდე IP მისამართს 30.1.1.10“. ორივე ეს მისამართი ასევე შედის პაკეტში SYN მოთხოვნის შესაქმნელად და ეს პაკეტი არ შეიცვლება კავშირის დასრულებამდე.

მინდა ამ ვიდეოდან გაიგოთ, როგორ მოძრაობს მონაცემები ქსელში. როდესაც ჩვენი კომპიუტერი, რომელიც აგზავნის მოთხოვნას, ხედავს წყაროს IP მისამართს და დანიშნულების IP მისამართს, ესმის, რომ დანიშნულების მისამართი არ არის ამ ლოკალურ ქსელში. დამავიწყდა მეთქვა, რომ ეს ყველაფერი /24 IP მისამართია. ასე რომ, თუ დააკვირდებით /24 IP მისამართებს, მიხვდებით, რომ კომპიუტერები 10.1.1.10 და 30.1.1.10 არ არიან ერთსა და იმავე ქსელში. ამრიგად, მოთხოვნის გამომგზავნი კომპიუტერს ესმის, რომ ამ ქსელიდან გასასვლელად, უნდა დაუკავშირდეს 10.1.1.1 კარიბჭეს, რომელიც კონფიგურირებულია როუტერის ერთ-ერთ ინტერფეისზე. მან იცის, რომ უნდა გადავიდეს 10.1.1.1-ზე და იცის მისი MAC მისამართი 1111, მაგრამ არ იცის 10.1.1.1 კარიბჭის MAC მისამართი. Რას აკეთებს? ის აგზავნის სამაუწყებლო ARP მოთხოვნას, რომელსაც ქსელში არსებული ყველა მოწყობილობა მიიღებს, მაგრამ მხოლოდ როუტერი IP მისამართით 10.1.1.1 უპასუხებს მას.

როუტერი უპასუხებს თავისი AAAA MAC მისამართით და ორივე წყაროს და დანიშნულების MAC მისამართები ასევე განთავსდება ამ ჩარჩოში. მას შემდეგ, რაც ჩარჩო მზად იქნება, CRC მონაცემთა მთლიანობის შემოწმება, რომელიც არის ალგორითმი შეცდომების აღმოსაჩენად საკონტროლო ჯამის მოსაძებნად, შესრულდება ქსელიდან გასვლამდე.
Cyclic Redundancy CRC ნიშნავს, რომ მთელი ეს ჩარჩო, SYN-დან ბოლო MAC მისამართამდე, გაშვებულია ჰეშირების ალგორითმის მეშვეობით, ვთქვათ MD5, რაც იწვევს ჰეშის მნიშვნელობას. ჰეშის მნიშვნელობა, ან MD5 checksum, შემდეგ მოთავსებულია ჩარჩოს დასაწყისში.

მე დავარქვით მას 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 მისამართი, შემდეგ გვექნება BBB წყაროს MAC მისამართი და CCC დანიშნულების MAC მისამართი. როუტერი კვლავ ითვლის 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-ს, კავშირი დამყარდება.

ერთი რამ უნდა იცოდეთ, რომ ეს ყველაფერი წამზე ნაკლებ დროში ხდება. ეს არის ძალიან, ძალიან სწრაფი პროცესი, რომლის შენელებაც ვცდილობდი, რომ ყველაფერი გასაგები იყოს თქვენთვის.
ვიმედოვნებ, რომ თქვენთვის სასარგებლო იქნება ის, რაც ისწავლეთ ამ გაკვეთილზე. თუ თქვენ გაქვთ რაიმე შეკითხვები, გთხოვთ მომწეროთ ნომერზე [ელ.ფოსტით დაცულია] ან დატოვეთ შეკითხვები ამ ვიდეოს ქვეშ.

შემდეგი გაკვეთილიდან დაწყებული YouTube-დან გამოვარჩევ 3 ყველაზე საინტერესო კითხვას, რომლებსაც განვიხილავ ყოველი ვიდეოს ბოლოს. ამიერიდან მექნება განყოფილება "ტოპ კითხვები", ასე რომ დავდებ კითხვას თქვენს სახელთან ერთად და პირდაპირ ვპასუხობ. ვფიქრობ, ეს მომგებიანი იქნება.

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, 30% ფასდაკლება Habr-ის მომხმარებლებისთვის საწყისი დონის სერვერების უნიკალურ ანალოგზე, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps 20$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

VPS (KVM) E5-2650 v4 (6 ბირთვი) 10GB DDR4 240GB SSD 1Gbps უფასო ზაფხულამდე ექვსი თვის ვადით გადახდისას შეგიძლიათ შეუკვეთოთ აქ.

Dell R730xd 2-ჯერ იაფია? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com