Cisco Training 200-125 CCNA v3.0. יום 6: מילוי החסר (DHCP, TCP, לחיצת יד, מספרי יציאה נפוצים)

לפני שנתחיל את סרטון ההדרכה של היום, אני רוצה להודות לכל מי שתרם לפופולריות של הקורס שלי ביוטיוב. כשהתחלתי אותו לפני כ-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 הזו למאגר כך שהוא יוכל להקצות אותה ללקוח אחר אם יקבל בקשה נוספת.

אלו הן 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 למעשה בונה את החיבור ואז מתחיל לבצע את השידור בפועל.

בואו נסתכל איך זה יוצר חיבור כזה. פרוטוקול זה משתמש בלחיצת יד תלת כיוונית כדי ליצור חיבור. זה לא מונח טכני במיוחד, אבל הוא שימש כבר זמן רב לתיאור חיבור TCP. לחיצת יד תלת כיוונית מתבצעת על ידי המכשיר השולח, כאשר הלקוח שולח חבילה עם דגל SYN לשרת.

נניח שהילדה בחזית, שאת פניה אנחנו יכולים לראות, היא מכשיר א', והילדה ברקע, שפניה לא נראים, היא מכשיר ב'. ילדה א' שולחת חבילת SYN לילדה ב', והיא אומרת: "נהדר, מי- אז הוא רוצה לתקשר איתי. אז אני צריך לענות שאני מוכן לתקשר!" איך לעשות את זה? אפשר פשוט לשלוח חזרה חבילת SYN נוספת ולאחר מכן ACK המציין קבלה של חבילת SYN המקורית. אבל במקום לשלוח ACKs בנפרד, השרת יוצר מנה משותפת המכילה את ה-SYN וה-ACK ומשדר אותה דרך הרשת.

אז בשלב זה, מכשיר A שלח חבילת SYN וקיבל חזרה חבילת SYN/ACK. כעת על מכשיר A לשלוח למכשיר B חבילת ACK, כלומר לאשר שקיבל הסכמה ממכשיר B ליצירת תקשורת. לפיכך, שני המכשירים קיבלו מנות SYN ו-ACK, וכעת אנו יכולים לומר שהחיבור נוצר, כלומר, הושלמה לחיצת יד בת 3 שלבים באמצעות פרוטוקול TCP.

בשלב הבא נסתכל על טכנולוגיית TCP Windowing. במילים פשוטות, זוהי שיטה המשמשת ב-TCP/IP כדי לנהל משא ומתן על היכולות של השולח והמקבל.

נניח שבווינדוס אנחנו מנסים להעביר קובץ גדול, נניח בגודל 2 ג'יגה-בייט, מכונן אחד למשנהו. כבר בתחילת ההעברה, המערכת תודיע לנו שהעברת הקבצים תימשך כשנה. אבל כמה שניות לאחר מכן המערכת תתקן את עצמה ותאמר: "אוי, חכה רגע, אני חושב שזה ייקח בערך 1 חודשים, לא שנה." יעבור עוד קצת זמן ו-Windows יגיד: "אני חושב שאולי אוכל להעביר את הקובץ בעוד חודש." לאחר מכן תופיע ההודעה "יום אחד", "6 שעות", "1 שעות", "שעה", "1 דקות", "6 דקות", "3 דקות". למעשה, כל תהליך העברת הקבצים ייקח רק 1 דקות. איך זה קרה? בתחילה, כאשר המכשיר שלך מנסה לתקשר עם מכשיר אחר, הוא שולח חבילה אחת ומחכה לאישור. אם המכשיר ממתין זמן רב לאישור, הוא חושב: "אם אני צריך להעביר 20 GB של נתונים במהירות זו, זה ייקח בערך שנתיים." לאחר זמן מה, המכשיר שלך מקבל ACK וחושב, "בסדר, שלחתי חבילה אחת וקיבלתי ACK, ומכאן שהנמען יכול לקבל חבילה אחת. עכשיו אנסה לשלוח לו 10 חבילות במקום אחת". השולח שולח 3 מנות ולאחר זמן מה מקבל אישור ACK מהמכשיר המקבל, כלומר הנמען ממתין לחבילה הבאה, ה-3. השולח חושב: "מצוין, מכיוון שהנמען טיפל ב-2 מנות בבת אחת, עכשיו אני אנסה לשלוח לו 2 מנות במקום עשר". הוא שולח 1 מנות, והנמען משיב שקיבל אותן וכעת הוא ממתין ל-10 מנות. כך, עם הזמן, מספר החבילות המועברות גדל.

זו הסיבה שאתה רואה ירידה מהירה בזמן העתקת הקבצים בהשוואה למה שנאמר במקור - זה נובע מהיכולת המוגברת להעביר כמויות גדולות של נתונים. עם זאת, מגיע שלב שבו עליות נוספות בנפח השידור הופכות לבלתי אפשריות. נניח ששלחת 10000 מנות, אבל מאגר המכשיר של המקלט יכול לקבל רק 9000. במקרה זה, המקלט שולח ACK עם ההודעה: "קיבלתי 9000 מנות וכעת אני מוכן לקבל 9001". מכאן מסיק השולח כי לחוצץ של המכשיר המקבל יש קיבולת של 9000 בלבד, כלומר מעתה ואילך אשלח לא יותר מ-9000 מנות בכל פעם. במקרה זה, השולח מחשב במהירות את הזמן שייקח לו להעביר את כמות הנתונים שנותרה במנות של 9000 מנות, ונותן 3 דקות. שלוש הדקות הללו הן זמן השידור בפועל. זה מה ש-TCP Windowing עושה.

זהו אחד מאותם מנגנוני גז תנועה שבהם המכשיר השולח מבין בסופו של דבר מהי קיבולת הרשת בפועל. אולי אתם תוהים למה הם לא יכולים להסכים מראש מהי הקיבולת של המכשיר הקולט? העובדה היא שזה בלתי אפשרי מבחינה טכנית מכיוון שיש סוגים שונים של מכשירים ברשת. נניח שיש לך אייפד ויש לו מהירות העברת/מקלט נתונים שונה מאשר לאייפון, אולי יש לך סוגים שונים של טלפונים, או אולי יש לך מחשב ישן מאוד. לכן, לכל אחד יש רוחב פס שונה של הרשת.

לכן פותחה טכנולוגיית TCP Windowing, כאשר העברת הנתונים מתחילה במהירות נמוכה או עם שידור של מספר מינימלי של מנות, ומגדילה בהדרגה את "חלון" התעבורה. אתה שולח חבילה אחת, 5 מנות, 10 מנות, 1000 חבילות, 10000 חבילות ולאט לאט פותח את החלון הזה עוד ועוד עד ש"הפתיחה" מגיעה לנפח התנועה המקסימלי האפשרי שנשלח בפרק זמן מסוים. לפיכך, הרעיון של Windowing הוא חלק מהפעולה של פרוטוקול TCP.

בשלב הבא נבחן את מספרי היציאות הנפוצים ביותר. המצב הקלאסי הוא כאשר יש לך שרת ראשי אחד, אולי מרכז נתונים. הוא כולל שרת קבצים, שרת אינטרנט, שרת דואר ושרת 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 סיביות.

כידוע, אם המכשיר הזה רוצה ליצור קשר עם השרת הזה, יש לבצע תחילה את השלב הראשון של לחיצת היד התלת-כיוונית, כלומר לשלוח חבילת SYN. כאשר תוגש בקשה זו, מחשב 3 יציין את מספר יציאת המקור, ש-Windows יוצר באופן דינמי. Windows בוחר באקראי מספר יציאה בין 10.1.1.10 ל-1. אבל מכיוון שמספרים התחלתיים בטווח 65,000 עד 1 ידועים ברבים, במקרה זה המערכת תשקול מספרים גדולים מ-1024 ותיצור יציאת מקור אקראית, למשל, מספר 25000.

לאחר מכן, המערכת תוסיף יציאת יעד לחבילה, במקרה זה היא יציאה 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 ויודע את כתובת ה-MAC שלו 1111, אבל לא יודע את כתובת ה-MAC של השער 10.1.1.1. מה הוא עושה? הוא שולח בקשת שידור ARP שכל המכשירים ברשת יקבלו, אך רק הנתב עם כתובת ה-IP 10.1.1.1 יגיב לה.

הנתב יגיב עם כתובת ה-MAC AAAA שלו, וגם כתובות MAC של מקור וגם כתובות יעד יוצבו במסגרת זו. לאחר שהמסגרת מוכנה, בדיקת שלמות נתונים של CRC, שהוא אלגוריתם למציאת סכום בדיקה לאיתור שגיאות, תתבצע לפני היציאה מהרשת.
Cyclic Redundancy CRC פירושו שכל המסגרת הזו, מה-SYN ועד כתובת ה-MAC האחרונה, מופעלת באמצעות אלגוריתם גיבוב, למשל MD5, וכתוצאה מכך נוצר ערך גיבוב. ערך ה-hash, או MD5 checksum, ממוקם אז בתחילת המסגרת.

סימנתי אותו FCS/CRC כי FCS הוא רצף בדיקת מסגרת, ערך CRC של ארבעה בתים. יש אנשים שמשתמשים בכינוי FCS וחלק משתמשים בכינוי CRC, אז פשוט כללתי את שני הייעודים. אבל בעצם זה רק ערך גיבוב. יש צורך לוודא שכל הנתונים המתקבלים ברשת אינם מכילים שגיאות. לכן, כאשר המסגרת הזו מגיעה לנתב, הדבר הראשון שהנתב יעשה הוא לחשב את ה-checksum עצמו ולהשוות אותו לערך 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, אז תהיה לנו כתובת ה-MAC מקור BBB וכתובת ה-MAC של יעד ה-CCC. הנתב שוב מחשב את ה-FCS/CRC ומציב אותו בתחילת הפריים.

לאחר מכן הוא שולח את המסגרת הזו דרך הרשת, המסגרת מגיעה לנתב 20.1.12, היא בודקת את סכום הבדיקה, מוודאת שהנתונים לא פגומים ומוחקת את ה-FCS/CRC. לאחר מכן הוא "חותך" את כתובות ה-MAC, מסתכל על היעד ורואה שהוא 30.1.1.10. הוא יודע שהכתובת הזו מחוברת לממשק שלו. אותו תהליך יצירת מסגרת חוזר על עצמו, הנתב מוסיף את ערכי המקור והיעד של כתובת ה-MAC, עושה את ה-hashing, מצרף את ה-hash למסגרת ושולח אותו ברחבי הרשת.

השרת שלנו, לאחר שלבסוף קיבל את בקשת ה-SYN שהופנתה אליו, בודק את ה-hash checksum, ואם החבילה אינה מכילה שגיאות, הוא מוחק את ה-hash. ואז הוא מסיר את כתובות ה-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 על אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2650 v4 (6 ליבות) 10GB DDR4 240GB SSD 1Gbps החל מ-$20 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB 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 TV החל מ-$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