TCP & UDP

[guyto]

TCP & UDP

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

תודה, גיא

 

[guyto]

לו=לא

 

[Rשף]

1/2 תשובה

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

 

[נמס בגשם]

UDP

1. connectionless - פחות משאבי מערכת, לא צריך להחזיק connections 2. עדיפות לRT ואפליקציות דומות- אפשר לשלוח כל packet עם היווצרותו ללא צורך לחכות בתור. ע"ע window בtcp.... 3. ניצול רוחב פס פיזי טוב יותר - יש פחות overhead על הtraffic 4.

 

[0rib]

בדרך כלל, משתמשים ב- UDP בטעות

כפי שציינת, UDP שימושי בעיקר במצבים שאם Packet לא הגיע בזמן, כבר לא משנה אם הוא יגיע בכלל - בשידור וידאו או סאונד חי, לדוגמא; בפרוטוקול NTP שתכליתו סינכרון שעונים; ובערך זהו. יתרון נוסף שיש ל- UDP היא יכולת Multicast / Broadcast - כלומר, יכולת משלוח בו זמנית למספר רב של נמענים (בין השאר, כאלה שאפילו לא ידועים לשולח). לדוגמא, חלונות משתמש ב- UDP Broadcast כדי לגלות איזה עוד תחנות יש מסביבו ברשת (יש לו עוד דרכים, ויתכן שבסביבה ספציפית הוא לא משתמש בשיטה זאת, אבל בתור ברירת מחדל הוא מנסה). מי שצריך משלוח _אמין_, כלומר, שיגיע ליעדו פעם אחת בדיוק (ואם לא, תתקבל אינדיקציה לכך), מומלץ שישתמש ב- TCP כי -- למעט במקרים מיוחדים -- מה שהוא יצטרך לעשות ב- UDP זה למעשה לממש את כל שכבת ה- TCP מחדש -- ומאוד קשה לעשות את זה טוב יותר ממערכות ההפעלה הבוגרות של היום. ןמכיוון שזה פורום QA - חשוב לציין שהרבה יותר קשה לבצע בקרת איכות על מערכת UDP. חבילת UDP שנשלחת יכולה ללכת לאיבוד, להגיע פעם אחת, להגיע עשרים פעם, והיא לא חייבת להגיע לפי סדר השליחה (כלומר, יכול להיות ששלחתי חבילות לפי הסדר 123456 וקיבלתי 21112456222, כשכל ספרה מציינת חבילה. שימו לב - חבילה 3 לא הגיעה כלל, וחבילה 2 הגיעה 5 פעמים (וגם הסדר לא מי יודע מה נשמר). הדבר הזה לא יקרה במעבדה, שבה רשת ה- Lan בדרך כלל אמינה ויציבה, לא מאבדת, משכפלת או מסדרת מחדש חבילות. נכון שגם בעולם הרחב התופעות האלה לא נורא נפוצות (למעט איבוד חבילות) - אבל, לדוגמא, סדר אקראי של חבילות עלול לחשוף באג שלא יתגלה בבדיקות המקדימות, ואם אין Log מסודר, גם לא ישתחזר במעבדה אם יקרה בשטח. מי שבודק מערכות שמשתמשות ב- UDP צריך ציוד בדיקה משוכלל הרבה יותר ממי שמשתמש ב- TCP בלבד. כשהייתי צריך לבדוק דברים מהסוג הזה, הקמתי בעצמי תחנת Linux ובעזרת NetFilter=IPTables המובנה ו- simuwan (לינק מצורף לעמוד של הכותב), הוספתי delay ו- drop. הוספתי בזמנו גם משכפל פאקטים, אבל לא מסדר מחדש (לצערי, אין לי גישה לתוספות שלי לקוד הזה יותר). הציעו לי באותו זמן מכשיר בעלות של עשרות אלפי דולרים שיכול לסמלץ באופן יותר אמין, אבל בסוף הסתפקתי (משיקולי תקציב וזמינות) במערכת שתוארה פה. יצא לי לפגוש הרבה פרויקטים שהשתמשו ב- UDP, ומעט מאוד מהם עשו זאת מסיבה מוצדקת. YMMV

 

[Rשף]

יש מכשירים מסחריים לדמוי רשת

הם מגיעים לקצבים של רשת 1G ומאפשרים קינפוג פרמטרים רבים ל fault-ים, מאחר והחברה שלי עוסקת כמעט אך ורק ב IP יש לנו כמה כאלה בשימוש יומיומי. אגב שכפול ו reordering די נדירים ויקרו כשמחליפים נתיב routing ולכן אפשר למנוע אותם מראש.

 

[0rib]

אי אפשר למנוע מראש

שכפול הוא אכן מאוד נדיר באופן כללי - ברוב הרשתות הוא לא יתכן אפילו. אבל ברשת שזה כן יתכן בה, שמשכפלת פאקטים מראש כדי להקטין Latency במקרה של Retransmit, דבר שעושים לעיתים אפילו על TCP אם יש לך Bandwidth פנוי, זה קורה כל הזמן. פגשתי רק אחת כזאת, ורוב מי שאני מכיר לא פגש בכלל, ולכן אולי מוצדק להתעלם מהן בבדיקות. אבל צריך להיות מודע לאפשרות ש_אולי_ תתממש. במיוחד כאשר אתה מנסה לשחזר באג שהופיע אצל לקוח במעבדת ה- QA, ולא מצליח. לו הייתי מתכנן High Availability Router עם ריבוי קווים למטרות fault-tolerance, הייתי גורם לו - לפני החלפה יזומה של נתיב - לשלוח בשני הנתיבים למשך כמה שניות (4 ורבע דקות, אם אפשר, חידה בשבילכם - למה?). אין לי מושג אם כך זה מתבצע בפועל - ואם אכן כך, אז -- כפי שאמרת -- אפשר למנוע מראש (בתנאי שכולם מודעים למצב, מה שלא קורה אצל לקוחות בדרך כלל). לגבי reordering, אי אפשר למנוע, וזה קורה לעיתים לא ממש נדירות בהרבה רשתות שמבצעות load balancing. יכול להיות שפאקט שנשלח מאוחר יותר יגיע לתור פחות עמוס ויצא ליעד מוקדם יותר. בסופו של דבר, הדבר הקריטי היחידי הוא שמערכת לא תקרוס במקרה של שכפול או Reordering - ואת זה אפשר לבדוק עם מכשירים משוכללים או ע"י כלים פשוטים כמו netcat וחבר מרעיו, וקצת סקריטפולוגיה. וזה מזכיר לי שאלה שאפרסם עוד מעט בתור נושא חדש, בנושא הנחות סמויות.