נשלח בתאריך: 21 August 2007 בשעה 05:20 | | IP רשוּם
|
|
|
|
לגבי מי משתמש ב-UDP התשובה היא פרוטוקולים בשכבת היישום. דוגמה: פרוטוקול DNS - אחראי לתרגום כתובות ADRESS ל-IP. פרוטוקול SKYPE - טלפוניה ברשת. פרוטוקול MMS - פרוטוקול להצגת וידאו של MICOROSOFT. פרוטוקולים אלה ואחרים משתמשים בפרוטוקול UDP בשכבת התעבורה לרוב בגלל שיקולי מהירות, הסיבה שפרוטוקול זה יותר מהיר היא כי הוא לא אמין בניגוד לפרטוקול ה-TCP. יישומים המשתמשים בפרוטוקול זה הם בדרך כלל יישומי MEDIA שאיבוד מידע עבורן הוא זניח.
השאלה לגבי הפורטים אינה קשורה לסוג הפרוטוקול בשכבת התעבורה. זוהי שיטה לטיפול במס' רב של פניות בעבור יישומים שונים. בכדי להבין את השיטה צריך להבין מהו פורט ולכן צריך להבין מהו SOCKET. SOCKET - בעיברית "שקע" משמש ממשק בין שכבת היישום לשכבת התעבורה, יישום הרוצה לשלוח הודעה מסויימת על גבי שכבת התעבורה חייב יהיה לפתוח סוקט. סוקט מאופיין ע"י 5 ערכים: כתובת IP שלי, מס' פורט של היישום שלי, כתובת IP של השרת, מס' פורט של היישום שאליו פונים בשרת, פרוטוקול שכבת התעבורה (TCP /UDP).
יפה, לאחר שהבנו מהו סוקט נבין למה צריך מס' פורט שונים. נניח ששרת מסויים יודע להריץ שני יישומיים שונים יישום WEB רגיל ויישום דואר. כעת מקבל השרת פניה מסויימת. כיצד ידעו היישומים למי מבינהם מיועדת הפניה? (או יותר נכון כיצד תדע מערכת ההפעלה למי לייעד את הפניה?). התשובה היא לפי מס' הפורט. כלומר כל יישום בשרת יש מס' פורט מסויים. נגיד שיישום דואר של קליינט מסויים רוצה לשלוח הודעה ליישום המתאים בשרת אז עליו: 1. לפתוח סוקט. 2. לדעת את כתובת ב-IP של השרת (לא ניכנס פה לאיך הוא יודע). 3. לדעת את מס' הפורט של יישום הדואר בשרת. איך??? התשובה ע"י מוסכמה ידועה לכל. ליישומים מיוחדים יש מס' פורט ידוע מראש WELL KNOWN PORT או בקיצור WKP מס' פורט זה הוא בטווח של 0-1023. לדוגמה: יישום בשרת שאחראי לטפל בבקשות HTTP מס' הפורט שלו הוא 80.
יפה, לאחר שהבנו מהו סוקט ומהו פורט (בערך 0.00001% מהחומר בקורס תקשורת מחשבים) נוכל לנסות להבין מה קורה כאשר השרת מקבל בקשה מסויימת. תרחיש: בקשת HTTP לשרת WEB שמחזיק את דף הבית של UNDERWAR.CO.IL. איך זה נעשה? - אצל הקליינט: יישום הדפדפן פותח SOCKET חדש ע"י בקשה ממערכת ההפעלה, הוא מציין שמס' הפורט של היישום אליו הוא רוצה לפנות בשרת הוא 80.( יש לציין שמס' הפורט של יישום הדפדפן אצל הקליינט הוא בד"כ אקראי). כעת הדפדפן מנסח בקשת TCP מיוחדת הנקראת בקשת SYN שתפקידה ליידע את היישום בשרת שברצוננו לדבר איתו ושולח אותה לשרת. צד השרת: מקבל את הבקשה, היישום שמאזין לפורט 80 יטפל בבקשה הזו ויענה בהתאם. כעת אם היישום ירצה "לדבר" הוא יחזיר תשובה לפי מספר הסוקט וכתובת ה-IP שצויינו בהודעה והעברת המידע בין היישומים יתבצעו על גבי פורטים אלה.
כאן נוצרת בעיה הרי אמרנו שכולם מכירים את היישום לפי ה-WKP שלו וזה תפוס כרגע בהעברת מידע לקליינט ספציפי, כלומר לא ניתן יהיה לפנות ליישום בשרת עד אשר יתפנה מלדבר עם יישום הקליינט. אז מה עושים? פתרון אחד הוא פשוט מחכים, כלומר מנהלים איזשהו תור בו מחכים קליינטים אחרים לטיפול. פתרון יותר רציני - לפני שהיישום בשרת מאשר את "ההידברות" הוא מבקש ממערכת ההפעלה לשכפל את עצמו ולתת לשיכפול מס' פורט אקראי שונה מ-80 בתחום 49152 - 65535. כעת קיימים שני יישומים בשרת בעלי אותו תפקיד אחד היישום בעל פורט 80 שיחזור להאזין לבקשות מקליינטים אחרים, והשני עם פורט שונה מ-80 שישרת את הקליינט הספציפי למשך ההידברות בינהם, ובסופה יוחזר הפורט למערכת ההפעלה.
לאחר שהבנו את השיטה אפשר להסיק כי ניתן לפתוח כמות גדולה של יישומים בשרת שיטפלו במס' גדול מאד של קליינטים בו זמנית (תלוי כמובן במשאבי מערכת כגון זיכרון מעבדים וכו'...). מכאן שכמות הפורטים השונים האקראים בשרת הם כמס' היישומים שנפתחו. התנהגות זו אינה ייחודית לשרתים היא מתרחשת גם כאשר פותחים כמה דפדפנים שונים במחשב. כל דפדפן שנפתח במקביל מקבל מס' פורט שונה ממערכת ההפעלה ויכול לתקשר באופן בלתי תלוי עם שרתים שונים.
ארוך טיפה אבל מקווה שעזרתי...
הודעה נשלחה למנהל האתר.
|