פיתוח אזור למדידת מהירות אינטרנט

צהריים טובים לכל משתמשי החברה.

אני כל הזמן קורא מאמרים על Habré על פיתוח פונקציונליות כזו או אחרת ב- Malinka. החלטתי לשתף כאן את עבודתי.

פרהיסטוריה

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

למרבה הצער, לא ניתן להגיע למנוי, למשל, בשעה 21:37, כאשר יש לו את המהירויות הנמוכות ביותר. הרי שעות העבודה של העובדים מוגבלות. להחלפת הנתב אין השפעה, כי... טווח התדרים ל-wi-fi בארצנו עמוס למרבה הצער.

למען הפרוטוקול - ספק המדינה ברפובליקה של בלארוס מפעיל בכוח Wi-Fi בכל המכשירים שסופקו לשימוש ומשדר את ByFly SSID מכל מכשיר. גם אם למנוי אין שירות אינטרנט, אלא רק טלפון ביתי. זה נעשה עבור מכירות נוספות. ניתן לקנות כרטיס ממפעיל זה בקיוסק, להתחבר לכל נקודה בשם ByFly ובאמצעות הזנת הנתונים מהכרטיס לקבל שירותי אינטרנט. בהינתן כמעט 100% כיסוי ערים וכיסוי משמעותי של המגזר הפרטי והאזורים הכפריים, מציאת נקודת חיבור אינה בעיה.

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

החלטה ראשית

התמונה היא המחשה

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

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

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

ובכן, פעולות דומות עבור ערוצי תקשורת חיצוניים. מצאנו מפעילים גדולים עם ערוצים גדולים בשרתי speedtest וכתבנו אותם בהמלצות (סליחה "Moskva - Rostelecom" ו-"Riga - Baltcom", אבל אני אמליץ על הצמתים האלה כדי לקבל מספרים נאותים. באופן אישי, קיבלתי עד ~870 מגה-ביט מ- שרתים אלה בשעות השיא).

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

פתרון משני

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

Реализация

BananaPI (דגם M1) נלקח כבסיס. יש למעשה שתי סיבות לבחירה הזו.

1. יציאת גיגה-ביט.
2. זה פשוט שכב על שידת הלילה.

לאחר מכן, הוחלט להשתמש בלקוח python speedtest-cli עבור שירות Speedtest מאת Ookla כקצה אחורי למדידת מהירות. סִפְרִיָה פייתונפינג כדי למדוד את מהירות הפינג. ובכן, ו-php לפאנל הניהול. כדי להקל על התפיסה השתמשתי אֹזֶן הַנַעַל.

בשל העובדה שהמשאבים של Raspberry אינם גמישים, נעשה שימוש בשילוב nginx+php-fpm+sqlite3. רציתי לוותר על MySQL בגלל הכבדות והיתירות שלו. אני צופה שאלה לגבי Iperf. היה צריך לנטוש אותו בגלל חוסר האפשרות להשתמש בו בכיוונים שאינם מקומיים.

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

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

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

פאנל הניהול להערכת התוצאות התברר כמינימליסטי למדי.

איור. חלון ניהול ראשי עם תוצאות בדיקה

איור. הגדרות בדיקה

איור. עדכן את רשימת שרתי Speedtest

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

נ.ב: בבקשה אל תבקר אותי על איכות הקוד. אני אוטודידקט ללא ניסיון. קוד מקור עבור GitHub. ביקורת מתקבלת.

מקור: www.habr.com