TCP מול UDP: אמינות מול מהירות

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

כשאתה בשיחת וידאו, קורה משהו אחר: מחשב אחד פשוט מתחיל לדבר. ללא לחיצת יד. ללא אישור. אם מילים אובדות — הן נעלמות.

אלה הם TCP ו-UDP — שני הפרוטוקולים שנושאים כמעט את כל תעבורת האינטרנט. הם אינם מתחרים. הם תשובות לשאלות שונות.

שתי פילוסופיות של אמון

TCP (פרוטוקול בקרת שידור) שואל: "קיבלת את זה?"

UDP (פרוטוקול נתוני משתמש) אומר: "אני מקווה שקיבלת את זה."

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

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

כיצד TCP מבטיח מסירה

לפני ש-TCP שולח אפילו בייט אחד מהנתונים שלך, הוא מבצע טקס הנקרא לחיצת יד תלת-שלבית:

1. SYN: "אני רוצה לדבר איתך."
2. SYN-ACK: "אני שומע אותך. גם אני רוצה לדבר."
3. ACK: "מצוין. נתחיל."

רק לאחר חילופים אלה מתחילים הנתונים לזרום. וכשהם זורמים — TCP עוקב אחרי הכל באדיקות.

כל נתח נתונים מקבל מספר רצף. הנמען שולח בחזרה אישורים: "קיבלתי בייטים 1–1000. קיבלתי בייטים 1001–2000." אם אישור לא מגיע בתוך חלון הזמן הקצוב — TCP מניח שהנתונים אבדו ושולח אותם שוב.

זה יוצר ערובות שנראות כמעט קסומות:

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

המחיר? תקורה. זמן השהייה. כל אישור הוא הלוך-ושוב. כל מנה שאבדה אומרת המתנה ושידור חוזר. לחיצת היד התלת-שלבית לבדה מוסיפה זמן השהייה לפני שנתון כלשהו זזה.

כיצד UDP משיג מהירות

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

אין הקמת חיבור. אין אישורים. אין שידור חוזר. אין ערובות לסדר. אין בקרת זרימה. יישום שמשתמש ב-UDP יכול פשוט להתחיל לשלוח נתונים מיד.

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

כל דטאגרם UDP הוא עצמאי — שגר ושכח. לשולח אין מושג אם הגיע. לנמען אין מנגנון לבקש נתונים חסרים. אם מנות מגיעות שלא בסדר — זו הבעיה של היישום.

המינימליזם הזה מתורגם ישירות לביצועים:

• אין עיכוב לחיצת יד לפני השליחה
• אין המתנת הלוך-ושוב לאישורים
• אין עיכובי שידור חוזר כשמנות נעלמות
• אין מצב חיבור לתחזוקה

UDP מהיר כמו שהרשת שלך מאפשרת.

מתי צריך TCP

בחר ב-TCP כשהנתונים חייבים להגיע שלמים ובסדר — כשאובדן או שחיתות ישברו משהו.

דפי אינטרנט: בייט חסר בקובץ HTML יכול לשבור את מבנה הדף כולו. כלל CSS שמגיע לפני ה-HTML שהוא מעצב — חסר תועלת.

דואר אלקטרוני: מנה שאבדה פירושה שמשפט נעלם באמצע המחשבה. או פסקה שלמה. או הקובץ המצורף. TCP מבטיח שכל ההודעה מגיעה לפני שלקוח הדואר מציג אותה לך.

הורדת קבצים: כשאתה מוריד תוכנה, אתה צריך כל בייט. קובץ הפעלה פגום לא פועל.

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

בקשות API: יישומים צריכים לדעת בוודאות: האם הבקשה שלי הצליחה או נכשלה?

TCP מטפל בכל אלה אוטומטית. היישום פשוט שולח נתונים ובוטח שהם מגיעים.

מתי צריך UDP

בחר ב-UDP כשמהירות חשובה יותר מהשלמות — כשנתון מיושן גרוע מנתון חסר.

משחקים מקוונים: אם מנה המכילה את מיקום השחקן שלך אבדה, המנה הבאה (שמגיעה אלפיות שניות אחר כך) ממילא מכילה את מיקומך החדש. עצירת המשחק לשידור מחדש של קואורדינטות ישנות תהפוך אותו לבלתי ניתן למשחק. שחקנים סובלים תקלות מדי פעם; הם לא יכולים לסבול עיכוב בקלט.

שיחות וידאו: פריים וידאו שאבד גורם לתקלה קצרה. אבל שידורו מחדש חסר טעם — עד שיגיע, השיחה כבר התקדמה 200 מילישניות קדימה. עדיף לדלג על הפריים הפגום ולשמור על זרימת השיחה.

שידור חי: אותו עיקרון. השמעה חלקה של תוכן עכשווי עדיפה על השמעה מושלמת של תוכן ישן.

שאילתות DNS: כשהמחשב שלך מחפש "google.com", השאילתה והתגובה מתאימות כל אחת למנה אחת. מהירות UDP מאפשרת פתרון שמות מהיר יותר. אם מנה אבדה — פשוט נסה שוב, עדיין מהיר יותר מאשר לחיצת היד של TCP הייתה.

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

הדפוס: UDP מנצח כשהנתון החדש ביותר הוא הנתון היחיד שחשוב.

המציאות ההיברידית

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

שירותי שידור וידאו משתמשים ב-TCP עבור הודעות בקרה ("השהה," "דלג," "שנה איכות") כי פקודות אלה חייבות להגיע. אבל הם משתמשים ב-UDP עבור פריימי הוידאו עצמם, שם השמעה חלקה עדיפה על פריימים מושלמים.

פרוטוקולים מודרניים לעיתים בונים אמינות מותאמת אישית על גבי UDP. QUIC — הפרוטוקול המניע חלק גדול מהאינטרנט המודרני — משתמש ב-UDP כבסיס אבל מוסיף אמינות סלקטיבית ובקרת עומסים מתוחכמת. הוא יכול לבצע אופטימיזציה לדפוסי תעבורת אינטרנט בדרכים שהתנהגותו הקבועה של TCP לא יכולה.

זה מגלה משהו חשוב: TCP מול UDP אינו בינארי. לפעמים התשובה היא "UDP, בתוספת בדיוק תכונות האמינות שאנחנו באמת צריכים."

ביצועים תחת לחץ

ברשת מושלמת — זמן השהייה נמוך, ללא אובדן מנות — TCP ו-UDP מבצעים בדומה. הבדל התקורה זניח.

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

UDP שומר על ביצועים עקביים ללא קשר לתנאי הרשת. הוא לא ממתין. הוא לא מאט. הוא פשוט ממשיך לשלוח.

הצד השני: יישומים המשתמשים ב-UDP חייבים לטפל בעצמם באובדן מנות. זו מורכבות ש-TCP היה סופג. האם הפשרה הזו הגיונית תלוי לחלוטין במה שאתה בונה.

הפשרה המהותית

TCP מחליף מהירות בוודאות. UDP מחליף ודאות במהירות.

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

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

אף אחד אינו טוב יותר. הם תשובות לשאלות שונות.

כשאתה מוריד קובץ, השאלה היא: "האם כל בייט הגיע?" TCP עונה על זה.

כשאתה בשיחת וידאו, השאלה היא: "מה קורה עכשיו?" UDP עונה על זה.

לדעת איזו שאלה היישום שלך באמת שואל — זו כל ההחלטה.

שאלות נפוצות על TCP ו-UDP

האם אוכל להשתמש ב-TCP למשחקים או שיחות וידאו?

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

למה UDP לא פשוט מוסיף אפשרות אמינות?

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

מה קורה כשמנות UDP מגיעות שלא בסדר?

זו הבעיה של היישום לפתור. UDP לא עוקב אחרי מספרי רצף ולא מסדר מחדש. אם היישום שלך צריך סדר, עליך להוסיף מספרי רצף בעצמך ולטפל בסידור מחדש בקוד שלך. יישומי זמן אמת רבים פשוט מעבדים מנות כשהן מגיעות — אם מנה 5 מגיעה לפני מנה 4, הם משתמשים בנתוני מנה 5 כי היא עדכנית יותר ממילא.

האם פרוטוקול אחד מאובטח יותר מהשני?

לא TCP ולא UDP מספקים הצפנה או אימות בפני עצמם — האבטחה מגיעה משכבות הבנויות מעליהם, כמו TLS. עם זאת, אופי TCP המבוסס-חיבור הופך כמה התקפות (כמו זיוף IP) לקצת יותר קשות, מכיוון שלחיצת היד התלת-שלבית דורשת תקשורת דו-כיוונית. אופי UDP הבלתי-מחובר הופך אותו לרגיש יותר לסוגים מסוימים של התקפות החזרה, שבהן תוקפים מזייפים כתובות מקור.