TCP לעומת UDP - אמינות או מהירות

📚 איך מחשבים מדברים - חלק 6 תקשורת #TCP#UDP
תוכן עניינים

TCP לעומת UDP - אמינות או מהירות

אחרי שמידע נשלח כ-Packets, מתגלה בעיה בלתי נמנעת: לא כל Packet מגיע, ולא תמיד בסדר שבו נשלח.

מכאן נולדת שאלה עקרונית, לא טכנית: מה חשוב יותר - לדעת שהכול הגיע, או לקבל תגובה כמה שיותר מהר?

התשובה אינה אחת. ולכן קיימים שני פרוטוקולים שונים.

הבעיה שאין לה פתרון מושלם

ברשת אמיתית:

  • Packets יכולים ללכת לאיבוד
  • להגיע באיחור
  • או להגיע בסדר שונה

אפשר לנסות “לתקן” את זה, ואפשר לבחור להתעלם מחלק מהבעיות.

אבל אי אפשר לעשות את שני הדברים במלואם.

כל ניסיון להבטיח אמינות מלאה גוזל זמן, משאבים, וסבלנות.

TCP: לבחור באמינות

TCP נבנה מתוך הנחה אחת ברורה: עדיף לחכות - מאשר לטעות.

הוא מוסיף לתקשורת מנגנונים שמטרתם:

  • לוודא שכל Packet הגיע
  • לשמור על סדר
  • ולשלוח מחדש מה שנעלם

המשמעות המערכתית היא:

  • יותר תיאום
  • יותר המתנה
  • ופחות הפתעות

TCP אינו מהיר - הוא צפוי.

UDP: לבחור במהירות

UDP מקבל החלטה הפוכה: הוא אינו מנסה לתקן את הרשת.

Packets נשלחים, ומי שמגיע - מגיע.

אין בדיקות, אין אישורים, ואין ניסיון להשלים חסרים.

התוצאה:

  • Latency נמוך
  • התנהגות פשוטה
  • ואפס הבטחות

UDP אינו אמין - אבל הוא עקבי במהירותו.

זו אינה בחירה טכנולוגית - אלא ערכית

ההבדל בין TCP ל-UDP אינו “איזה יותר טוב”. זו שאלה של עדיפות.

יש מצבים שבהם:

Packet חסר הוא אסון

ויש מצבים שבהם:

עיכוב קטן הוא אסון

TCP מתאים למידע שחייב להיות נכון. UDP מתאים למידע שחייב להיות בזמן.

המשל

אפשר לחשוב על משלוח מסמכים.

TCP דומה לדואר רשום: כל מסמך נבדק, נחתם, ומאושר.

UDP דומה להודעה שנזרקת לתיבה: אין אישור, אבל היא מגיעה מהר.

איזו שיטה עדיפה? זה תלוי במה שכתוב במסמך.

הבחירה משפיעה על כל המערכת

ברגע שנבחר TCP או UDP, נכפית צורת חשיבה:

  • איך מתמודדים עם עיכובים
  • איך מתמודדים עם חוסרים
  • ואיפה האחריות לתיקון טעויות

הפרוטוקול אינו רק צינור - הוא קובע מי אחראי למה.

מבט קדימה

ברגע שמכניסים אמינות או מוותרים עליה, עולה מושג נוסף, עמוק יותר: מה זה בעצם “חיבור” בין מחשבים?

בפוסט הבא נעסוק ב-Connection - ולמה הוא מצב לוגי, לא כבל.

תגובות