TCP מול UDP - מה ההבדל, ולמה זה לא רק פרט טכני משעמם¶

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

TCP - האמין, אבל האטי יחסית¶

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

איך הוא עושה את זה בפועל:

לחיצת יד לפני הכל - three-way handshake. לפני שמתחילים לשלוח מידע בכלל, שני הצדדים "לוחצים יד" - שולחים כמה חבילות קטנות כדי לוודא ששניהם מוכנים ומסונכרנים.
אישורי קבלה - acknowledgments. כל חבילה שנשלחת מצפה לאישור קבלה. אם האישור לא מגיע תוך זמן סביר, החבילה נשלחת שוב.
סדר נכון. אם חבילות מגיעות שלא בסדר (וזה קורה כל הזמן ברשת אמיתית), TCP מסדר אותן מחדש לפני שהוא מעביר את המידע הלאה לאפליקציה.
בקרת עומס - congestion control. TCP מתאים את קצב השליחה שלו לפי מצב הרשת, כדי לא להציף רשת עמוסה בעוד יותר חבילות.

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

UDP - מהיר, בלי הבטחות¶

UDP, ראשי תיבות של User Datagram Protocol, הולך בגישה ההפוכה לגמרי. הוא שולח חבילות מידע (datagrams) בלי לחיצת יד מקדימה, בלי אישורי קבלה, ובלי ערבות שהחבילה בכלל תגיע. הוא פשוט שולח, ומקווה לטוב.

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

דוגמאות מהחיים האמיתיים¶

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

איך לזכור את זה בלי להתבלבל¶

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

למה זה שיקול תכנוני, לא רק פרט טכני¶

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

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

קורס הרשתות המלא נמצא כאן, חינם ובעברית, כולל תרגול מעשי עם שני הפרוטוקולים ותעבורה אמיתית ב-Wireshark.

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

הצטרפו לקהילה בדיסקורד

לסיכום¶

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