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

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

השאלה שלי היא למה בעצם הנתב צריך להתמודד עם זה? הרי החיבורים נוצרים בשכבת ה-TCP/UDP, והאחריות על ניהול חיבורים קיימים היא של תחנות הקצה בלבד (המחשבים שמריצים את תוכנת השיתוף). הנתב אמור לעשות ניתוב ברמת IP + פורט בלבד, ולצורך זה לא אמור לעניין אותו דבר מלבד פורט ה-TCP/UDP וכתובת המחשב שאליו הוא אמור לקדם את הפאקט לפי ה-PORT FORWARDING שהוגדר לו. הוא לא צריך להחזיק שום טבלאות ולא צריך לנהל תקשורת TCP מול PEERים רבים. לכן, מבחינתו, שהמחשב יפתח מיליון חיבורים למיליון לקוחות במקביל - מבחינת הנתב מדובר בתעבורת IP רגילה.

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

אז למה זה קורה? איזה פרט חשוב בכל מנגנון ה-TCP/UDP/IP אני מפספס?

הנתב צריך לשמור טבלה הממפה רביעיה של IP+PORT של המחשב המרוחק ו-IP+PORT של תחנת הקצה.

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

כשהמחשב שלך שולח את החבילה הראשונה הוא מייצר אותה עם ה-Local IP (ברשת הפנימית), הפורט שהוא הקצה וה-IP+PORT של מחשב הקצה.

הראוטר מקבל את החבילה הנ"ל וממיר את ה-Local IP ל-Internet IP, בדרך הוא גם צריך לזכור את הקישור בין המחשב המקומי למחשב המרוחק.

הנתב צריך לדאוג שכל חבילה המגיע מה-IP+Port של המחשב המרוחק המיודעת ל-Internet IP והפורט ממקודם תגיע למחשב הנכון.

במקרה הנ"ל טבלת ה-Port forwarding לא משחקת בכלל תפקיד.

בגדול טבלת ה-Port forwarding אחראית רק על TCP Connections נכנסים (כלומר שהמחשב המרוחק יוזם) ולא על TCP Connections יוצאים.

לגבי UDP הראוטר לא צריך לשמור שום דבר כיוון ש-UDP הוא Stateless ואין צורך לזכור מידע על חיבור קיים.

גם ראוטרים עיסקיים של CISCO נחנקים ומקבלים חום משיתוף קבצים ,

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

אימיול מסוגל לגרום ל50-300 תקשורות בשניה,זה מעבר ליכולות הרבה ראוטרים.

ראוטר שומר טבלת NAT שהוא מנהל והטבלה הזאת גדולה מאוד ברגע שיש כך הרבה חיבורים,

על כל פעולה שנעשית ברמה של TCP הראוטר עושה לפחות פעולה אחת (בדרך כלל יותר) וזו הטעות הלוגית שלך לדעתי,

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

לפתוח HEADER של כל PACKET,לנהל טבלאות לנהל תקשורת ברמת IP וכוליי,

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

TCP ו UDP לא מעניינות אותו ,הוא עובד ברמת IP ומנהל את כל העבודה שלו באותה צורה עם המשאבים שלו.

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

עכשיו תחשבו מה עשרות ומאות משתמשים עושים לראוטר שעולה 10000$ כשאר לפניי כן הוא היה מסוגל לטפל בפי 100 משתמשים בו זמנית ועכשיו מספר קטן בסך הכל של מחוברים מסוגלים ליצור משהו שדומה ל DOS ATTACK

כשהמחשב שלך שולח את החבילה הראשונה הוא מייצר אותה עם ה-Local IP (ברשת הפנימית), הפורט שהוא הקצה וה-IP+PORT של מחשב הקצה.

הראוטר מקבל את החבילה הנ"ל וממיר את ה-Local IP ל-Internet IP, בדרך הוא גם צריך לזכור את הקישור בין המחשב המקומי למחשב המרוחק.

הנתב צריך לדאוג שכל חבילה המגיע מה-IP+Port של המחשב המרוחק המיודעת ל-Internet IP והפורט ממקודם תגיע למחשב הנכון.

במקרה הנ"ל טבלת ה-Port forwarding לא משחקת בכלל תפקיד.

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

גם ראוטרים עיסקיים של CISCO נחנקים ומקבלים חום משיתוף קבצים ,

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

אימיול מסוגל לגרום ל50-300 תקשורות בשניה,זה מעבר ליכולות הרבה ראוטרים.

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

ראוטר שומר טבלת NAT שהוא מנהל והטבלה הזאת גדולה מאוד ברגע שיש כך הרבה חיבורים,

על כל פעולה שנעשית ברמה של TCP הראוטר עושה לפחות פעולה אחת (בדרך כלל יותר) וזו הטעות הלוגית שלך לדעתי,

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

לפתוח HEADER של כל PACKET,לנהל טבלאות לנהל תקשורת ברמת IP וכוליי,

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

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

TCP ו UDP לא מעניינות אותו ,הוא עובד ברמת IP ומנהל את כל העבודה שלו באותה צורה עם המשאבים שלו.

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

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

המון תודה לשניכם על ההסברים.

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

"לגבי UDP הראוטר לא צריך לשמור שום דבר כיוון ש-UDP הוא Stateless ואין צורך לזכור מידע על חיבור קיים."

לא נכון.

מחשב רגיל עם 64 מגה זיכרון בלינוקס יכול להחזיק בו-זמנית 4096 חיבורים בשביל NAT.

יש נתבים שהם מסוגלים ומומלצים לP2P

כגון ה COMPEX NP27G שגם מוציין שהוא בעל יכולת טובה בתקשורות הP2P כלומר שיתוף קבצים אימיול ביטורנט וכדומה

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

יש נתבים שהם מסוגלים ומומלצים לP2P

כגון ה COMPEX NP27G שגם מוציין שהוא בעל יכולת טובה בתקשורות הP2P כלומר שיתוף קבצים אימיול ביטורנט וכדומה

השאלה היא מה זה אומר.

עד כה לא ראיתי שום ניסיון להשוואה אמיתית של ביצועי נתבים תחת עומס של תוכנות שיתוף (לא שיש בכלל ביקורות רבות על נתבים).

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

הנסיון הכי קרוב היה של SmallNetBuilder שהשתמשו בכלי IxChariot פשוט כדי לבדוק כמה חיבורים סימולטניים נתבים יכולים ליצור בלי לקרוס:

http://www.smallnetbuilder.com/component/option,com_chart/Itemid,189/chart,124/

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

ואוו, הנתונים זוועתיים, רק 200 חיבורים ?

מניסיון שנוצר לי בנושא,(בכל משרד יש מישהו עם אימיול )

ראוטרים קטנים קורסים גם אם אין NAT ,יש פשוט יכולת מקסימלית של ראוטר לנהל מספר רב של CONNECTIONS בו זמנית

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

בקריסה אני מתכוון שמתחיל להיות PACKET LOST והכל מתחיל להתנהג לא יציב (הכוונה לא לריסט של הראוטר ,לראוטרים של CISCO יש UPTIME כמו בלינוקס - שנה )

אם ה CPU מתחיל להיות גבוהה כל הזמן זה אומר שמתחילות בעיות.

לגביי ה UDP כפרוטוקול , שוב - זה לא נוגע לראוטר אלה לאפליקציה שמנהלת את התקשורת UDP,

מבחינת הראוטר זו תקשורת IP שצורכת משאבים.

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

"לגבי UDP הראוטר לא צריך לשמור שום דבר כיוון ש-UDP הוא Stateless ואין צורך לזכור מידע על חיבור קיים."

לא נכון.

בטח שזה נכון

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

אתה טועה ומטעה. נכון ש udp הוא stateless מה שאולי יותר מקשה על המעקב אחריו, אבל חייבים לעקוב אחריו, כדי לנתב את המידע בדיוק כמו שעושים ל TCP. גם פה משתמשים בטבלה דומה עם 2 זוגות של כתובות ופורט. רק שפה, במקום להחליט על סגירת החיבור ע"י הודעות מפורשות, משתמשים ב timeout מהפעם אחרונה שקיבלו מידע.

ראוטרים קטנים קורסים גם אם אין NAT ,יש פשוט יכולת מקסימלית של ראוטר לנהל מספר רב של CONNECTIONS בו זמנית

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

בקריסה אני מתכוון שמתחיל להיות PACKET LOST והכל מתחיל להתנהג לא יציב

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

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

רק כאשר מדובר ב-NAT, אם אני מבין נכון.

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

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

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

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

רק כאשר מדובר ב-NAT, אם אני מבין נכון.

לא ,תפקידו העיקרי של הראוטר זה ROUTING וזה רוב העבודה שלו ("רק להעביר פאקטים" זה מה שמבלבל אותך),

טבלת NAT בהחלט מעמיסה על ה CPU ועל הזכרון המועט שיש אבל רוב העבודה היא לא הטבלה הזאת .

חיבור FTP לא יוצר הרבה חיבורים במקביל ,אלה ברצף ,יש חיבור אחד במקביל.

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

אובדן פאקטים יכול לקרות משניי מצבים(שקשורים כאן),

תקלה ברמת הקו בגלל העומס או בגלל שהראוטר לא מסוגל לטפל בכל הפניות והBUFFER כבר מלא אז הוא לא מטפל בחלק.

הדוגמא הכי טובה שאתה יכול לחשוב עליה היא DOS ATTACK ,זה לא קשור לNAT כי אפשר להפנות את ההתקפה ל IP הראשי,

זה אותו רעיון בדיוק ,יותר מידי תעבורה יחסית למה שהראוטר מסוגל לטפל,גורם ל CPU לעמוד על 100% ,לקו לקרוס לפעמים ולראוטר להתקע לפעמים.

exercise - שכחת מה זה ROUTING לרגע

אפשר לתת כתובות אמיתיות לתחנות הפנימיות ולא יהיה צורך ב NAT.