בטח שמעתם את הביטוי TCP או UDP או המילה Port וביטויים כאלו או אחרים הקשורים בתקשורת אבל לא לגמרי הבנתם או רציתם להבין במה מדובר….
אז הנה הסבר קצר למי שכן רוצה להבין :
יסודות התקשורת
ביסודה התקשורת אמורה להביא מידע ממקום אחד למקום אחר וכמובן שכולנו היינו רוצים שהמידע יגיע שלם ותקין. אם נדמה זאת למשלוח חבילות – היינו רוצים שכל החבילות שלנו תגענה ליעדן תקינות, ללא חוסרים ורצוי מאוד שגם בסדר הנכון. אז גם בעולם התקשורת ליחידות המידע קוראים באמת "חבילות" (Packets) וכששולחים מידע כמו למשל תמונה שגודלה 5MB עושים זאת על ידי פירוקה להמון יחידות קטנות בגודל 0.5-1.5KB ושליחת חבילות אלו ליעדן. בהגיען ליעד מרכיב המקבל את כל הפאזל הזה לכדי יחידה אחת שבסיומה יש בידיו את אותה תמונה !
מילת הקסם בעולם התקשורת היא פרוטוקול. פרוטוקול הוא לא רק תקציר משעמם של ישיבת הנהלה אלא גם מונח המשמש להגדרת דרך מוסכמת על שני צדדים כיצד לתקשר זה עם זה. כששני הצדדים מקיימים פרוטוקול מסויים – הם בעצם מסכימים על אופן התקשרות ויודעים לדבר זה עם זה. לכן כשתשמעו את המילה "פרוטוקול תקשורת" הכוונה להגדרה טכנית כיצד שני צדדים צריכים לדבר זה עם זה – החל מברכת השלום )למשל HELO בפרוטוקול SMTP או EHLO בגרסא המתקדמת יותר( ועד ברכת הפרידה (BYE, END, וכיוב').
ואיך כל ארגון חבילות המידע הזה מתבצע בעצם ? באמצעות פרוטוקול TCP !
Transmission Control Protocol (TCP)
פרוטוקול בקרת השידור (TCP) הוא פרוטוקול תקשורת המגדיר כיצד שני צדדים יכולים לפרק מידע ולהעבירו מצד לצד בצורה אמינה. כל תפקידו של הפרוטוקול הוא להגדיר כיצד דואגים שכל מה שיצא יגיע לידעו וכן לטפל בהרכבה של הפאזל לכדי התמונה הגדולה. מה שעושה מנגנון ה-TCP זה לפרק את המידע לחבילות קטנות, למספר אותן ולשלוח אותן לצד המקבל. תפקידו של הצד המקבל ראשית כל לענות לצד השולח "קיבלתי" עבור כל חבילה שקיבל! וכן להרכיב את חבילות המידע לפי מספורן חזרה לגוש המידע המקורי שכן הן עשויות להגיע לפי סדר לאו דווקא עוקב. כך – הצד השולח שולח חבילות שמספרן 1,2,3,4,5 והצד המקבל מקבל אותן לפי סדר כלשהו 4,2,3,1,5 ותפקידו לסדר את הפאזל מחדש לגוש המידע המקורי בעוד שהוא משדר חזרה חבילות מידע בשם ACK (קיצור ל-Acknowledge שזה אישור קבלה) שתפקידן לאשר קבלה – כך שהוא שולח ACK4, ACK2, ACK3, ACK1, ACK5 חזרה לצד השולח.
עד כאן הכל טוב אבל… מה קורה אם אובד מידע? מה קורה אם חבילה מספר 4 הלכה לאיבוד כמו שקורה לכולנו בדואר ישראל? במקרה הזה, הצד השולח מחכה ומחכה ורואה שהוא קיבל ACK עבור כל החבילות למעט 4 ובחלוף זמן המתנה מסויים (חלון זמן מוגדר) – הוא מבין שעליו לשדר את החבילה מחדש שכן קודמתה הלכה כנראה לאיבוד בגלל הפרעות בקו, שגיאות ניתוב או כל סיבה אחרת. וכך חבילה 4 משודרת מחדש, הצד השני ממתין לה וכאשר הוא מקבל אותה הוא משדר ACK4 וברגע שהצד השולח מקבל את האישור תם השידור. לא קיבל? משדר שוב !
עד כאן התהליך יפה אך בכדי לא לשלוח בכל פעם חבילה אחת ולהמתין לאישור לפני משלוח השניה – מה שקורה בפועל זה שהצד השולח לא ממתין לקבלת אישור ומשדר ללא הרף את החבילות, בעודו ממתין לאישורים שיגיעו מהצד השני. כך אנו מקבלים מצב שבו אין זמן בטל והצדדים משדרים ברצף כאשר השלמות מתבצעות תוך כדי תנועה ומבלי לעכב את יתר השידור.
זה הכל !
כמעט….
אבל מה עושים עם שידור וידאו למשל שבו אין היגיון להמתנה לחבילות שאבדו שכן הסרט מתקדם קדימה ????
הכירו את פרוטוקול UDP !
User Datagram Protocol (UDP)
פרוטוקול UDP עובד אחרת ויוצא מתוך הנחה שחלב שנשפך אין בוכין עליו. הפרוטוקול מבוסס על שידור חבילות מידע מהשולח למקבל ללא הרף ומבלי לקבל אישור על חבילות שנשלחו – בין אם הגיעו ליעדן ובין אם לאו.
מה ההיגיון ?
בשידור סרטים או בהזרמת מדיה ואודיו – מדובר ברצף גרפיקה וצלילים שמתקדם קדימה ואין היגיון בשידור מחדש של חלק מצליל או תמונה שכבר עבר זמנו וחלף. לא זאת בלבד אלא שהשידור דורש רצף מהיר ככל שניתן של נתונים בכמויות גדולות ואם כל חבילה תדרוש אישור – הערוץ יוצף בהרבה רעש ועומס מיותר וחסר כל טעם או תועלת.
אז למה לא לעבוד רק עם זה?
בגלל המחיר שמשלמים על חבילות אבודות (להבדיל מדואר ישראל – שם האבדן חינם). כשמשדרים מידע כמו קובץ טקסט או בסיס נתונים – אין סובלין פה מידע אבוד באותו האופן שאפשר לספוג כמה פיקסלים חסרים או גליץ' קטן בשידור רדיו אינטרנטי. פרוטוקול UDP מתאים אך ורק למקומות שבהם אבדן מסויים נסבל ולא נדרשת אמינות של 100%.
ובכל זאת ? בכל זאת יש פרוטוקולים שמיישמים מן רמה של אמינות מעל UDP תוך יצירת ערוץ דו-כיווני מעל UDP שמיישם את העקרונות של TCP אמין עם אישור קבלה מעל הערוץ הלא אמין של ה-UDP. זה קצת עקום אך יש לכך מספר יתרונות שלא נעמיק בהם – אחד מהם הוא העובדה שזה נוח להסתרת שירותים שונים בפני פורצים שכן פרוטוקול הבסיס UDP אינו משיב כל אישור על חבילות מידע שנשלחות אליו ולכן פורץ שמחפש טרף לא יכול לדעת שמישהו מאזין בצד השני מבלי לשלוח פרטי הזדהות ראשוניים שעליהם יקבל תגובה רק אם ישלח את הפרטים הנכונים…
ואיך כל זה מתקשר למילה Port ?
המילה פורט מתארת 'ערוץ' מסויים מתוך כל מרחב התקשורת של מחשב שעליו 'מאזינה' תוכנה מסויימת. הדבר דומה לתאי דואר בתוך בניין רב קומות שהרי כשאתם רוצים לשלוח הודעה למשפחת פרידנזון אתם שולחים את ההודעה לבניין מספר 3, ברחוב אשכנזי ולתיבת דואר או דירה מספר 24. אז בעולם המחשוב, כתובת ה-IP (כתובת הרשת) של מחשב היא הרחוב ומספר הבניין ואילו הפורט הוא 'מספר הדירה' או 'תא הדואר' שעליו מאזינה תוכנה מסויימת. כך אנו מאפשרים למספר תוכנות לנצל את קו התקשורת מבלי להפריע זו לזו שכן כל חבילת מידע ממוענת לפורט מסויים עליו מאזינה תוכנה מסויימת.
למשל – פורט 80 או פורט 443 אלו פורטים סטנדרטיים של שרתי WEB המגישים דפים לדפדפנים. כשאתם גולשים לכתובת ynet.co.il הדפדפן שלכם בעצם פונה לאחד השרתים של YNET לפורט 80 או לפורט 443 ומבקש ממנו שירות. לעומת זאת, כשאתם שולחים דוא"ל, תוכנת האאוטלוק שלכם מדברת עם פורט 587 בשרת הדואר Exchange והוא מוציא את הדואר לפורט 25 המשמש שרתי דואר לקבל ומשלוח דואר ביניהם. טלפוניית VoIP למשל משתמשת בין היתר בפורט 5060 שמוכר כפורט הרשמי לפרוטוקול תקשורת SIP שרץ מעל UDP לרוב ומיישם את מה שנדרש לגרום לטלפונים ולמרכזיות לדבר זו עם זה.
באופן כללי – המושג נכון גם ל-UDP וגם ל-TCP ולכן תשמעו את המונחים UDP Port או TCP Port כשהכוונה למספר הערוץ שעליו מאזינה תוכנה בפרוטוקול הרלוונטי או UDP או TCP.
