הרשת איטית.
שום דבר לא עמוס.
המשתמשים מתלוננים, אף לינק לא מתקרב לסף, וכל דשבורד ירוק. זה לא סתירה — זו פשוט עדות לכך שהדבר שנמדד אינו הדבר שכואב.
רשת יכולה להיות איטית בזמן שהעומס נמוך מפני שמדידת עומס סופרת כמות, ואיטיות היא עניין של זמן. שידורים חוזרים, מיקרו-ברסטים שממלאים תור לרגע, אי-התאמת דופלקס, סופות ברודקאסט, אי-התאמת MTU וניתוב אסימטרי — כולם מוסיפים המתנה בלי להוסיף תעבורה שתופיע בגרף. שש הסיבות האלה מכסות את הרוב המוחלט של המקרים, וכולן נראות בהקלטת PACKETS בזמן שאף מונה לא זז.
רשת איטית שאינה עמוסה.
לפי סדר השכיחות בפועל. בכל אחת — מה קורה, ומה בדיוק לחפש כדי לאשר או לפסול אותה.
שידורים חוזרים (TCP retransmissions)
PACKET אובדת, ה-TCP משדר אותה שוב, והאפליקציה ממתינה. אחוז אחד של שידורים חוזרים כבר מורגש; שניים מרגישים כמו רשת שבורה. מונה הבתים לא זז — הרי הבתים כן עברו, פשוט פעמיים.
מה מחפשים: יחס שידורים חוזרים לכיוון, לא רק סך הכול. אם הוא חד-כיווני, הבעיה בדרך כלל בקטע ספציפי ולא בשרת.
מיקרו-ברסטים (microbursts)
פרץ של 50 מילישניות ממלא את התור בסוויץ׳ ומפיל PACKETS. בגרף של חמש דקות זה נראה כמו עומס של 8%. הממוצע לא משקר — הוא פשוט מודד את הדבר הלא נכון.
מה מחפשים: מונה discards/drops על הפורט שגדל בזמן שהעומס נמוך. זה כמעט תמיד פרץ.
אי-התאמת דופלקס
צד אחד full-duplex, השני half. הלינק עולה, עובר תעבורה, ונראה בריא לחלוטין — עד שהעומס עולה ומתחילות התנגשויות ושגיאות CRC. תקלה עתיקה שעדיין מופיעה בכל רשת שיש בה ציוד ישן או ממיר מדיה.
מה מחפשים: שגיאות FCS/CRC ו-late collisions על פורט מסוים, בלי שום עומס שמצדיק אותן.
סופת ברודקאסט (broadcast storm)
לולאה, כרטיס פגום או פרוטוקול שמתנהג רע מציפים את ה-VLAN בשידורים. כל מעבד בכל תחנה ברשת מעבד כל PACKET כזו. הקו לא עמוס — אבל כולם עסוקים.
מה מחפשים: אחוז broadcast/multicast מסך התעבודה ב-VLAN, ואיזו כתובת MAC מייצרת אותו.
אי-התאמת MTU ופיצול
מנהרה, VPN או מעבר בין ציוד מכניסים MTU קטן יותר, וה-PACKETS מתפצלות. אם ה-ICMP חסום, ה-Path MTU Discovery נשבר בשקט וסשנים נתקעים באמצע — בעיקר בהעברת קבצים גדולים, בזמן שגלישה רגילה עובדת מצוין.
מה מחפשים: PACKETS מפוצלות, או סשן שנפתח כרגיל ומת מיד כשמתחילה העברה גדולה.
ניתוב אסימטרי
התעבורה יוצאת בדרך אחת וחוזרת באחרת. פיירוול מצבי (stateful) שרואה רק חצי מהשיחה מפיל אותה, ומדידת זמן הלוך-חזור (RTT) מפסיקה להיות מהימנה. זה שכיח במיוחד אחרי הוספת קו WAN שני.
מה מחפשים: handshake שרואים רק בכיוון אחד בהקלטה. זו הוכחה חד-משמעית.
על אותו ציר זמן.
גררו את הציר. העומס על הקו נשאר שטוח ונוח לאורך כל האירוע ולא נוגע בסף ההתראה, בזמן שהחוויה מתפרקת. שני הקווים מתארים את אותה דקה בדיוק.
Net-Monitor למד מה החלק הזה ברשת עושה בדרך כלל בשעה הזו ביום. התעבורה נוחה, הקו נקי, ואין למה להתריע.
- עומס על הקו
- 39%
- זמן תגובה
- 24ms
- שגיאות ב-PACKETS
- 0.2%
- ציון סיכון
- 2/100
העומס נוח והקו נקי.
צריך להסתכל על התעבורה, לא על הסכומים.
כל שש הסיבות למעלה חולקות תכונה אחת: הן נראות ב-PACKETS ולא נראות במונים. זה לא במקרה — מונה הוא סיכום, והסיכום כבר החליק את הראיה.
- להקליט לפני שצריך. תקלה לסירוגין לא תיתפס בהקלטה שמתחילים אחריה. אצלנו הסניפר כבר מקליט.
- למדוד זמן, לא רק כמות. זמן הלוך-חזור (RTT), זמן תגובת שרת ואחוז שידורים חוזרים — שלושת המספרים שמסבירים "איטי".
- להשוות לנורמה של הרשת שלכם. 60 מילישניות זה מצוין באתר אחד ותקלה באחר. סף קבוע לא יודע את ההבדל; קו בסיס נלמד כן.
תשובות קצרות.
למה הרשת איטית כשהעומס נמוך?
כי מדידת עומס סופרת כמות, והאיטיות היא בדרך כלל עניין של זמן. שידור חוזר, תור שהתמלא לרגע או handshake שנכשל מוסיפים המתנה בלי להוסיף כמעט תעבורה. קו שנמצא ב-10% יכול לספק חוויה גרועה בהרבה מקו שנמצא ב-70% ועובד נקי.
זו הרשת או האפליקציה?
ההקלטה עונה על זה בוודאות. אם הבקשה יצאה, התגובה חזרה מהר, והזמן התבזבז בין השתיים — זה השרת. אם התגובה נדדה, שודרה שוב או הגיעה מפוצלת — זו הרשת. בלי לראות את ה-PACKETS, שני הצדדים יכולים רק להאשים זה את זה, וזה בדרך כלל מה שקורה.
למה גרף של חמש דקות מפספס את זה?
כי הוא ממוצע. פרץ של 200 מילישניות שממלא תור נבלע בתוך 300 שניות של דגימה ויוצא כשינוי של אחוזים בודדים. כדי לראות פרץ צריך רזולוציה בסדר גודל של הפרץ עצמו — או פשוט להסתכל על ה-PACKETS.
איך מוכיחים שזו לא הרשת?
עם הקלטה מאותו חלון זמן. PACKETS הן ראיה עובדתית ולא פרשנות: הן מראות מתי יצאה כל בקשה, מתי חזרה כל תגובה, ומי מבין הצדדים החזיק את השעון. זה סוגר את הדיון גם מול ספק חיצוני.
התקלה קורית פעם ביומיים. מה עושים?
מקליטים ברציפות. תקלה שלא ניתן לשחזר לא נפתרת בהקלטה שמתחילים אחריה — עד שמישהו מתחבר, האירוע כבר נגמר. הדרך היחידה היא שהראיות יהיו קיימות עוד לפני שידעתם שיש בעיה.
עדיין לא מצליחים להסביר?
תביאו לנו את הרשת שאיטית בלי סיבה שמישהו מצליח למצוא. נכוון אליה את Net-Monitor ונראה לכם מה הוא רואה.