قبل از شروع آموزش ویدیویی امروز، می‌خواهم از همه کسانی که در محبوبیت دوره من در 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، آن را ارائه نمی دهد، بلکه این آدرس را برای دستگاه رزرو می کند. در همان زمان، بسته پیشنهادی حاوی آدرس 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 دیگری یک آدرس IP 1.50 را برای مشتری رزرو کرده است. هنگامی که درخواست پخش یک کلاینت را دریافت کرد، از خرابی مطلع می شود و آن آدرس IP را دوباره در pool قرار می دهد تا در صورت دریافت درخواست دیگری، بتواند آن را به مشتری دیگری اختصاص دهد.
اینها 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 یک Pool ایجاد می‌کند، 254 آدرس IP را در آن قرار می‌دهد و تنها از این Pool می‌تواند آدرس‌هایی را به کلاینت‌های شبکه اختصاص دهد. بنابراین این چیزی شبیه یک تنظیمات اداری است که کاربر می تواند انجام دهد.
حالا بیایید به انتقال TCP نگاه کنیم. نمی‌دانم با «تلفن» تصویر آشنا هستید یا نه، اما وقتی بچه بودیم از این قوطی‌های حلبی که با یک رشته متصل بودند برای صحبت با یکدیگر استفاده می‌کردیم.
متأسفانه، نسل امروزی نمی تواند چنین «تجمل» را بپذیرد. منظورم این است که امروز بچه ها از یک سالگی جلوی تلویزیون هستند، PSP بازی می کنند و شاید این موضوع قابل بحث باشد، اما فکر می کنم ما بهترین دوران کودکی را سپری کردیم، در واقع بیرون رفتیم و بازی کردیم و بچه های امروزی را نمی توان از مبل دور کرد. .
پسر من فقط یک سال دارد و می توانم متوجه شوم که او به آی پد معتاد است، منظورم این است که او هنوز خیلی جوان است، اما فکر می کنم که بچه های امروزی با دانستن نحوه کار با وسایل الکترونیکی متولد شده اند. بنابراین، می خواستم بگویم که در کودکی، وقتی بازی می کردیم، روی قوطی های حلبی سوراخ می کردیم، و وقتی آنها را با یک نخ می بستیم و در یک قوطی چیزی می گفتیم، از طرف دیگر شخص می توانست حرف های گفته شده را بشنود. به او، به سادگی با گذاشتن قوطی کنار گوشش. بنابراین بسیار شبیه به اتصال شبکه است.
امروزه حتی انتقال‌های TCP باید اتصالی داشته باشند که باید قبل از شروع انتقال واقعی داده برقرار شود. همانطور که در درس های قبلی بحث کردیم، TCP انتقال اتصال گرا است در حالی که UDP انتقال اتصال گرا است. می توانید بگویید که UDP جایی است که من توپ را پرتاب می کنم و این به شما بستگی دارد که ببینید آیا می توانید آن را بگیرید. این که آیا شما آماده انجام آن هستید یا نه مشکل من نیست، من فقط او را ترک می کنم.
TCP بیشتر شبیه این است که شما با یک پسر صحبت می کنید و از قبل به او هشدار می دهید که قرار است یک توپ را پرتاب کنید، بنابراین یک پیوند ایجاد می کنید، و سپس توپ را پرتاب می کنید تا همسرتان برای گرفتن آن آماده باشد. بنابراین TCP در واقع اتصال را ایجاد می کند و سپس شروع به انجام انتقال واقعی می کند.
بیایید ببینیم که چگونه چنین ارتباطی را ایجاد می کند. این پروتکل از یک دست دادن سه طرفه برای ایجاد یک اتصال استفاده می کند. این یک اصطلاح فنی نیست، اما مدتهاست که برای توصیف اتصال TCP استفاده می شود. یک دست دادن سه طرفه توسط دستگاه فرستنده آغاز می شود و مشتری بسته ای را با یک پرچم SYN به سرور ارسال می کند.
فرض کنید دختری که در پیش‌زمینه است و صورتش را می‌بینیم، دستگاه A است و دختری که در پس‌زمینه که صورتش قابل مشاهده نیست، دستگاه B است. دختر A یک بسته SYN برای دختر B ارسال می‌کند و او می‌گوید: "عالی است، پس او می خواهد با من ارتباط برقرار کند. بنابراین، من باید پاسخ دهم که برای برقراری ارتباط آماده هستم!» چگونه انجامش بدهیم؟ به سادگی می توان یک بسته SYN دیگر و سپس یک ACK که نشان دهنده دریافت بسته SYN اصلی است، پس فرستاد. اما به جای ارسال ACK ها به طور جداگانه، سرور یک بسته مشترک شامل SYN و ACK تشکیل می دهد و آن را از طریق شبکه ارسال می کند.
بنابراین در این مرحله، دستگاه A یک بسته SYN ارسال کرده و یک بسته SYN/ACK را پس گرفته است. اکنون دستگاه A باید یک بسته ACK به دستگاه B ارسال کند، یعنی تأیید کند که رضایت دستگاه B را برای برقراری ارتباط دریافت کرده است. بنابراین، هر دو دستگاه بسته های SYN و ACK را دریافت کردند و اکنون می توان گفت که اتصال برقرار شده است، یعنی با استفاده از پروتکل TCP، یک دست دادن 3 مرحله ای انجام شده است.
در ادامه به فناوری TCP Windowing خواهیم پرداخت. به زبان ساده، این روشی است که در TCP/IP برای مذاکره در مورد قابلیت‌های فرستنده و گیرنده استفاده می‌شود.
فرض کنید در ویندوز ما سعی می کنیم یک فایل بزرگ مثلاً 2 گیگابایتی را از یک درایو به درایو دیگر منتقل کنیم. در همان ابتدای انتقال، سیستم به ما اطلاع می دهد که انتقال پرونده تقریباً 1 سال طول می کشد. اما چند ثانیه بعد سیستم خود را اصلاح می کند و می گوید: "اوه، یک دقیقه صبر کنید، فکر می کنم حدود 6 ماه طول بکشد، نه یک سال." کمی بیشتر می گذرد و ویندوز می گوید: "فکر می کنم ممکن است بتوانم فایل را در عرض 1 ماه انتقال دهم." پس از آن پیام «1 روز»، «6 ساعت»، «3 ساعت»، «1 ساعت»، «20 دقیقه»، «10 دقیقه»، «3 دقیقه» وجود دارد. در واقع کل فرآیند انتقال فایل تنها 3 دقیقه طول خواهد کشید. چگونه این اتفاق افتاد؟ در ابتدا، هنگامی که دستگاه شما سعی می کند با دستگاه دیگری ارتباط برقرار کند، یک بسته ارسال می کند و منتظر تایید می ماند. اگر دستگاه مدت زیادی برای تایید صبر کند، فکر می کند: "اگر مجبور باشم 2 گیگابایت داده را با این سرعت انتقال دهم، حدود 2 سال طول می کشد." پس از مدتی، دستگاه شما یک ACK دریافت می‌کند و فکر می‌کند، "خوب، من یک بسته ارسال کردم و یک ACK دریافت کردم، بنابراین گیرنده می‌تواند 1 بسته را دریافت کند. اکنون سعی می کنم به جای یک بسته، 10 بسته برای او بفرستم. فرستنده 10 بسته ارسال می کند و پس از مدتی تأییدیه ACK را از دستگاه دریافت کننده دریافت می کند که به این معنی است که گیرنده منتظر بسته بعدی و یازدهم است. فرستنده فکر می کند: "عالی است، از آنجایی که گیرنده 11 بسته را به طور همزمان مدیریت می کند، اکنون سعی می کنم به جای ده بسته، 10 بسته برای او ارسال کنم." او 100 بسته ارسال می کند و گیرنده پاسخ می دهد که آنها را دریافت کرده است و اکنون منتظر 100 بسته است. بنابراین، با گذشت زمان، تعداد بسته های ارسالی افزایش می یابد.
به همین دلیل است که شما شاهد کاهش سریع زمان کپی فایل در مقایسه با آنچه در ابتدا گفته شد - این به دلیل افزایش توانایی انتقال مقادیر زیادی داده است. با این حال، زمانی فرا می رسد که افزایش بیشتر در حجم انتقال غیرممکن می شود. فرض کنید شما 10000 بسته ارسال کرده اید، اما بافر دستگاه گیرنده تنها می تواند 9000 بسته را بپذیرد. در این حالت گیرنده یک ACK با این پیام ارسال می کند: "من 9000 بسته دریافت کرده ام و اکنون آماده دریافت 9001 هستم." از این جا، فرستنده نتیجه می گیرد که بافر دستگاه گیرنده فقط 9000 ظرفیت دارد، به این معنی که از این به بعد من بیش از 9000 بسته را در یک زمان ارسال نخواهم کرد. در این حالت، فرستنده به سرعت زمان انتقال داده های باقی مانده را در بخش های 9000 بسته محاسبه می کند و 3 دقیقه زمان می دهد. این سه دقیقه زمان واقعی ارسال است. این کاری است که TCP Windowing انجام می دهد.
این یکی از آن مکانیسم های کاهش ترافیک است که در آن دستگاه فرستنده در نهایت ظرفیت واقعی شبکه را درک می کند. شاید از خود بپرسید که چرا نمی توانند از قبل در مورد ظرفیت دستگاه گیرنده به توافق برسند؟ واقعیت این است که این امر از نظر فنی غیرممکن است زیرا انواع مختلفی از دستگاه ها در شبکه وجود دارد. فرض کنید شما یک آیپد دارید و سرعت انتقال/دریافت اطلاعات آن متفاوت از آیفون است، ممکن است انواع مختلفی از تلفن ها داشته باشید، یا شاید یک کامپیوتر بسیار قدیمی داشته باشید. بنابراین، هرکسی پهنای باند شبکه متفاوتی دارد.
به همین دلیل است که فناوری 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 در نظر گرفته نشده است. نیازی نیست که این لیست را از روی قلب یاد بگیرید، به خاطر سپردن آن غیرممکن است، اما باید تعدادی از محبوب ترین و رایج ترین شماره های پورت را بدانید. همانطور که گفتم برخی از این پورت ها دارای هدف رسمی هستند که در استانداردها توضیح داده شده است و برخی نیز مانند کرومیوم دارای هدف غیر رسمی هستند.
بنابراین، این جدول تمام شماره پورت های رایج را فهرست می کند و از این اعداد برای ارسال و دریافت ترافیک هنگام استفاده از برنامه های خاص استفاده می شود.
حال بیایید ببینیم که چگونه داده ها بر اساس اطلاعات کمی که می دانیم در سراسر شبکه حرکت می کنند. فرض کنید کامپیوتر 10.1.1.10 می خواهد با این کامپیوتر یا این سرور که آدرس 30.1.1.10 دارد تماس بگیرد. در زیر آدرس IP هر دستگاه آدرس MAC آن وجود دارد. من یک آدرس MAC را با 4 کاراکتر آخر مثال می زنم، اما در عمل یک عدد هگزادسیمال 48 بیتی با 12 کاراکتر است. از آنجایی که هر یک از این اعداد از 4 بیت تشکیل شده است، 12 رقم هگزادسیمال یک عدد 48 بیتی را نشان می دهد.
همانطور که می دانیم اگر این دستگاه بخواهد با این سرور تماس بگیرد، ابتدا باید اولین مرحله از دست دادن 3 طرفه یعنی ارسال بسته SYN انجام شود. هنگامی که این درخواست انجام می شود، کامپیوتر 10.1.1.10 شماره پورت منبع را که ویندوز به صورت پویا ایجاد می کند، مشخص می کند. ویندوز به طور تصادفی یک عدد پورت را بین 1 تا 65,000 انتخاب می کند. اما از آنجایی که اعداد شروع در محدوده 1 تا 1024 به طور گسترده ای شناخته شده اند، در این حالت سیستم اعداد بزرگتر از 25000 را در نظر می گیرد و یک پورت منبع تصادفی برای مثال شماره 25113 ایجاد می کند.
در مرحله بعد، سیستم یک پورت مقصد را به بسته اضافه می کند، در این مورد پورت 21 است، زیرا برنامه ای که می خواهد به این سرور FTP متصل شود، می داند که باید ترافیک FTP را ارسال کند.
بعد، کامپیوتر ما می گوید، "خوب، آدرس IP من 10.1.1.10 است و باید با آدرس IP 30.1.1.10 تماس بگیرم." هر دوی این آدرس ها نیز برای تشکیل یک درخواست SYN در بسته گنجانده شده است و این بسته تا پایان اتصال تغییر نخواهد کرد.
من می خواهم از این ویدیو بفهمید که چگونه داده ها در سراسر شبکه حرکت می کنند. وقتی کامپیوتر ما که درخواست را ارسال می کند آدرس IP مبدا و آدرس IP مقصد را می بیند، متوجه می شود که آدرس مقصد در آن شبکه محلی نیست. یادم رفت بگم که اینها همه آدرس های IP /24 هستند. بنابراین اگر به آدرس های IP /24 نگاه کنید، متوجه می شوید که کامپیوترهای 10.1.1.10 و 30.1.1.10 در یک شبکه نیستند. بنابراین، رایانه ارسال کننده درخواست متوجه می شود که برای خروج از این شبکه، باید با دروازه 10.1.1.1 که روی یکی از رابط های روتر پیکربندی شده است، تماس بگیرد. می داند که باید به 10.1.1.1 برود و مک آدرس 1111 خود را می داند، اما مک آدرس دروازه 10.1.1.1 را نمی داند. داره چیکار میکنه؟ یک درخواست پخش ARP را ارسال می کند که همه دستگاه های موجود در شبکه دریافت خواهند کرد، اما فقط روتر با آدرس IP 10.1.1.1 به آن پاسخ می دهد.
روتر با آدرس MAC AAAA خود پاسخ می دهد و آدرس مک مبدا و مقصد نیز در این قاب قرار می گیرد. پس از آماده شدن فریم، بررسی یکپارچگی داده های CRC، که الگوریتمی برای یافتن جمع کنترلی برای تشخیص خطاها است، قبل از خروج از شبکه انجام می شود.
Cyclic Redundancy CRC به این معنی است که کل این فریم، از SYN تا آخرین آدرس MAC، از طریق یک الگوریتم درهم‌سازی، مثلاً MD5، اجرا می‌شود و در نتیجه یک مقدار هش ایجاد می‌شود. سپس مقدار هش یا MD5 checksum در ابتدای قاب قرار می گیرد.
من آن را برچسب FCS/CRC گذاشتم زیرا FCS یک Frame Check Sequence است، یک مقدار CRC چهار بایتی. برخی از افراد از نام FCS و برخی از نام CRC استفاده می کنند، بنابراین من هر دو نام را وارد کردم. اما اساساً فقط یک مقدار هش است. برای اطمینان از اینکه تمام داده های دریافتی از طریق شبکه حاوی خطا نیستند، لازم است. بنابراین، هنگامی که این فریم به روتر می رسد، اولین کاری که روتر انجام می دهد این است که خود checksum را محاسبه کرده و آن را با مقدار 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 سوال جالب را از یوتیوب انتخاب می کنم که در پایان هر ویدیو بررسی می کنم. از این به بعد یک بخش "سوالات برتر" خواهم داشت، بنابراین یک سوال همراه با نام شما ارسال می کنم و به آن پاسخ می دهم. من فکر می کنم این مفید خواهد بود.
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید 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 دلار! در مورد بخوانید
منبع: www.habr.com