איך למדוד את השיהוי ברשת: מדריך מעשי למפתחים

להתלכלך עם כלים למדידת שיהוי בשורת הפקודה

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

הכלי הקלאסי והנפוץ הוא ping. זה פשוט בצורה מדהימה: הוא שולח חבילת נתונים קטנה (בקשת הדהוד ICMP) לשרת וממתין שהיא תחזור. אותו סיבוב פשוט הוא הבסיס לחישוב זמן סיבוב (RTT) ומספק לכם בדיקת בריאות מיידית על החיבור.

בדיקת השיהוי הראשונה שלכם עם Ping

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

ברירת המחדל, ping ימשיך לנוע לנצח ב-macOS וב-Linux, בעוד ש-Windows שולח רק ארבע חבילות ועוצר. עבור כל ניתוח אמיתי, תרצו לשלוט בזה. שליחת עשר או עשרים חבילות נותנת לכם תמונה הרבה יותר אמינה על יציבות החיבור מאשר רק כמה.

ברגע שזה יסתיים, תקבלו סיכום מסודר עם המספרים הקריטיים:

• חבילות שנשלחו/נתקבלו: זה אומר לכם אם נתונים אבדו בדרך. אפילו כמות קטנה של אובדן חבילות היא דגל אדום גדול לבעיות ברשת.
• זמן חזרה מינימלי/ממוצע/מקסימלי/סטיית תקן: אלו הסטטיסטיקות המרכזיות של השיהוי שלך. אתה מקבל את הזמן הטוב ביותר (min), את הממוצע (avg), ואת הזמן הגרוע ביותר (max). הmdev (סטיית תקן ממוצעת) הוא המדד שלך לג'יטר—כמה השיהוי משתנה בין מנות נתונים.

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

טעות נפוצה היא רק להציץ בממוצע ה-RTT. ממוצע של 50ms עשוי להיראות בסדר, אבל אם המינימום שלך הוא 20ms והמקסימום הוא 250ms, חוויית המשתמש תרגיש קופצנית ולא אמינה. תמיד הסתכלו על הטווח המלא כדי להבין את הג'יטר.

מעקב אחרי השביל עם Traceroute ו-MTR

אז, מה לעשות כאשר ping חושף שיהוי גבוה או אובדן מנות? המשימה הבאה שלך היא להבין איפה הבעיה. זה מה שtraceroute (או tracert ב-Windows) מיועד לו. הוא ממפה את כל הדרך שהמנות שלך עוברות, ומראה לך כל "קפיצה"—כל ראוטר—בין המחשב שלך ליעד הסופי.

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

אבל traceroute הוא צילום חד-פעמי. כדי לקבל מבט יותר דינמי, רוב אנשי הרשת שאני מכיר נשבעים בMTR (My Traceroute). MTR הוא כמו כלי מואץ שמשלב ping וtraceroute. הוא שולח באופן קבוע מנות לכל קפיצה בדרך, ומספק לך תצוגה חיה ומעודכנת של שיהוי ואובדן מנות בכל נקודה. זה עושה אותו מאוד יעיל בלכידת בעיות מזדמנות שtraceroute בודד עשוי לפספס.

למה הבחירה שלך בכלי חשובה

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

זה למעשה די מפתיע כמה המספרים יכולים להיות שונים. בניסוי מפורט שנערך על ידי Google Cloud, בדיקת ping סטנדרטית דיווחה על ממוצע RTT של 146 מיקרו-שניות. אבל כאשר הם השתמשו בכלי אחר ששולח עסקאות אחת אחרי השנייה ללא הפסקה, ה-RTT ירד ל66.59 מיקרו-שניות—יותר מכפליים מהמהירות!

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

מציאת מהירות החיבור שלך עם iperf

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

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

כדי להשתמש בiperf, תצטרך שני מחשבים:

1. על מחשב אחד, אתה מריץ את iperf במצב שרת. הוא פשוט יישב שם ויקשיב לחיבור.
2. על המחשב השני, אתה מריץ את iperf במצב לקוח, מכוון אותו לכתובת של השרת.

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

מדידת שיהוי מנקודת מבט של משתמש

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

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

צלילה לכלים של מפתחי דפדפן

כל דפדפן מרכזי—Chrome, Firefox, Edge, Safari—מצויד בחבילת כלים למפתחים. הלשונית "Network" בתוך הכלים הללו היא מרכז הפיקוד שלך להבנת איך האתר שלך נטען. היא מציגה הכל בגרף מפל, שהוא פיצול חזותי של כל בקשה שהדפדפן עושה כדי להציג דף.

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

• חיפוש DNS: הזמן שלוקח לפתור שם דומיין לכתובת IP.
• חיבור ראשוני: הזמן המושקע בהקמת חיבור TCP עם השרת.
• לחיצת SSL/TLS: העומס הנדרש להקמת חיבור מאובטח.
• זמן לבייט הראשון (TTFB): זהו אחד החשובים. הוא מודד כמה זמן הדפדפן חיכה לפני שקיבל את הבייט הראשון של נתונים מהשרת.
• הורדת תוכן: הזמן המושקע בהורדת המשאב עצמו.

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

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

מדידה פרוגרמטית עם APIs של זמן

למדידות אוטומטיות ומדויקות יותר, אתה יכול לנצל את ה-APIs המובנים של JavaScript בדפדפן. הNavigation Timing API והResource Timing API נותנים לך גישה פרוגרמטית לאותן נתוני ביצועים מפורטים שאתה רואה בכלים למפתחים. זה מושלם לאיסוף נתוני ניטור משתמשים אמיתיים (RUM) כדי להבין איך האתר שלך מתפקד עבור מבקרים אמיתיים ברחבי העולם.

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

מהנתונים הללו, אתה יכול לחשב מדדים חיוניים:

• זמן חיפוש DNS: domainLookupEnd - domainLookupStart
• זמן לחיצת TCP: connectEnd - connectStart
• זמן לבייט הראשון (TTFB): responseStart - requestStart
• זמן טעינת דף כולל: loadEventEnd - startTime

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

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

הבנת המספרים (ומה להימנע ממנו)

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

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

פיענוח ג'יטר ואובדן מנות

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

אם התוצאות שלך מראות ממוצע RTT של 40ms, אבל המינימום היה 10ms והמקסימום היה 150ms, החיבור שלך לא יציב. השונות הגדולה הזו היא בדיוק מה שגורם להפרעות מעצבנות בשיחות וידאו ולעליות שיהוי מעצבנות במשחקים מקוונים.

אובדן מנות הוא דגל אדום אפילו יותר גדול. אפילו 1% אובדן מנות יכול לשתק לחלוטין יישומים מבוססי TCP, forcing them to constantly resend data and slowing everything to a crawl. When you look at your test results, any real difference between packets sent and packets received needs to be investigated immediately.

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

כדי להקדים בעיות, כדאי לבדוק כלים ייעודיים ל<а href="https://www.constructive-it.co.uk/post/network-performance-monitoring-improve-uk-office-networks">ניטור ביצועי רשת. זה משנה את הגישה שלך מתיקון דברים בעצבנות כאשר הם נשברים לשמירה פרואקטיבית על בריאות הרשת שלך.

הטעויות הנפוצות ביותר במדידה

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

• בדיקות על Wi-Fi: ברצינות, פשוט אל תעשה את זה. חיבורים אלחוטיים ידועים כלא יציבים, נוטים להפרעות מכל דבר, ממיקרוגלים ועד לנתב של השכן שלך. עבור כל בדיקות שיהוי רציניות, חבר עם כבל Ethernet. זו הדרך היחידה לקבל בסיס יציב ומהימן.
• שכחת עלויות VPN: VPNs מצוינים לאבטחה, אבל הם מוסיפים עצירה נוספת והצפנה למסע התנועה שלך. זה תמיד יגביר את השיהוי. אם אתה מנסה לאבחן חיבור איטי של משתמש, אחת השאלות הראשונות שלך צריכה להיות, "האם אתה על ה-VPN?" בדיקה עם וללא זה תראה לך בדיוק כמה עיכוב זה מוסיף.
• התעלמות מעומס רשת מקומי: תוצאות הבדיקה שלך יהיו מעוותות אם מישהו אחר ברשת שלך תופס את כל רוחב הפס. אם קולגה זורם וידאו ב-4K או מוריד קבצים עצומים בזמן שאתה בודק, מספרי השיהוי שלך יהיו מנופחים, ותסיים לרדוף אחרי בעיה שאינה קיימת.

גורם נוסף עדין אך קריטי הוא הכלי שאתה בוחר. כפי שכיסינו, כלים שונים מודדים שיהוי בדרכים שונות. תמיד תהיה עקבי עם הכלים שאתה משתמש בהם להשוואה, ודא שאתה מבין מה כל אחד מהם באמת מודד—אם זה הדהוד ICMP פשוט או בקשה מורכבת ברמת היישום. וזכור, ביצועים יכולים להיות מושפעים מהרבה שכבות; למשל, אם אתה חוקר ביצועי אינטרנט, המדריך שלנו על תוסף Cookie Editor Chrome יכול להראות איך אלמנטים בצד הלקוח משחקים תפקיד.

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

שאלות נפוצות על שיהוי רשת

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

מהו בעצם מספר שיהוי "טוב"?

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

• גלישה באינטרנט מזדמנת: עבור רובנו, כל דבר מתחת ל100ms RTT ירגיש בסדר גמור. הדפים נטענים במהירות, ולא תשים לב לשום שיהוי אמיתי.
• משחקים תחרותיים מקוונים: כאן כל מילישנייה חשובה. גיימרים רציניים וסוחרי תדירות גבוהה מחפשים שיהוי הרבה מתחת ל20ms. זו ההבדל בין לנצח ולהפסיד.
• שיחות וידאו ו-VoIP: כאן, עקביות היא המלכה. אתה צריך שיהוי יציב מתחת ל150ms וג'יטר נמוך (פחות מ-30ms) כדי להימנע מהתחושה הקופצנית והלא מסונכרנת הזו או, גרוע מכך, משיחות שנופלות.

ככלל אצבע, רוב אנשי הרשת שאני מכיר ידרגו כל דבר מתחת ל50ms כשיהוי נמוך. מ50-150ms הוא מתון, וברגע שאתה עובר את 150ms, תתחיל להרגיש את העיכוב ברוב היישומים האינטראקטיביים.

למה תוצאות ה-Ping שלי ובדיקת מהירות הדפדפן שלי אף פעם לא תואמות?

זו שאלה מצוינת ונקודת בלבול מאוד נפוצה. זה קורה כי ping בשורת הפקודה ובדיקת מהירות מבוססת דפדפן הם כלים fundamentally שונים המודדים דברים שונים.

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

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

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

איך אני יכול באמת להוריד את השיהוי ברשת שלי?

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

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

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

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

ראיתי ש-VPNs של חברות מוסיפים עד 70ms לזמן החזרה. זה יכול להפוך חיבור מצוין לאחד איטי ומfrustrating. תמיד בדוק עם וללא ה-VPN שלך כדי לראות איזה סוג של פגיעה בביצועים אתה באמת חווה.

מה ההבדל האמיתי בין שיהוי לרוחב פס?

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

הנה האנלוגיה שאני תמיד משתמש בה: תחשוב על זה כמו על כביש מהיר.

• רוחב פס הוא כמה נתיבים יש לכביש המהיר. יותר נתיבים משמעותם שיותר מכוניות (נתונים) יכולות לנסוע באותו הזמן.
• שיהוי הוא מגבלת מהירות. זה קובע כמה מהר מכונית אחת (חבילת נתונים) יכולה להגיע מ-A ל-B.

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

מוכן להפוך את בדיקות הביצועים לחלק חלק מהעבודה היומית שלך? חבילת ShiftShift Extensions מציבה כלי בדיקת מהירות עוצמתי, מעצב JSON ועשרות כלים נוספים למפתחים ממש בתוך הדפדפן שלך, נגישים עם פקודה אחת. הפסיק ל juggling tabs והתחל לעבוד בצורה חכמה יותר. הורד את ShiftShift Extensions בחינם והגבר את הפרודוקטיביות שלך היום.