インターネットの速度を測定するゾンドの開発

Habraユーザーの皆様、こんにちは。

私は、Malinka でのさまざまな機能の開発に関する Habré の記事を常に読んでいます。 ここで自分の作品を共有することにしました。

背景

私はケーブル テレビとインターネット アクセス サービスを提供する会社で働いています。 そして、そのような会社ではよくあることですが、料金プランが契約書に記載されている内容と一致しないという苦情も定期的に聞きます。 ユーザーは、「ケーブル経由」の速度が遅いこと、次に特定のサービスの ping が高いこと、さらには XNUMX 日の特定の時間帯にインターネットがまったく利用できないことについて不満を抱きます。 多くの場合、このような苦情は最終的にリクエストのプールとなり、従業員の XNUMX 人が作業用ラップトップを持ってサイトを訪問し、そこですべての測定が行われます。 そして、多くの場合、速度が速ければすべてがうまくいくことがわかります。 そして、低速は実際にはバルコニーでWi-Fi経由で携帯電話で使用されています。 まあ、またはそれに似たもの。

残念ながら、たとえば、加入者の速度が最も低い 21:37 に加入者にアクセスすることはできません。 結局のところ、従業員の労働時間は限られています。 ルーターを交換しても効果がありません。 私たちの国の Wi-Fi の周波数範囲はひどく乱雑です。

記録のために — ベラルーシ共和国の国営プロバイダーは、使用のために提供されたすべてのデバイスで Wi-Fi を強制的にオンにし、各デバイスから ByFly SSID をブロードキャストします。 加入者がインターネット サービスを利用しておらず、自宅の電話しか持っていない場合でも。 これは追加販売のために行われました。 キオスクでこのオペレーターからカードを購入し、ByFly という名前のポイントに接続し、カードのデータを入力することでインターネット サービスを受けることができます。 都市はほぼ 100% カバーされており、民間部門と農村部もかなりカバーされているため、接続ポイントを見つけるのは問題ありません。

外部通信チャネルを観察すると、所定の帯域幅が確保されていることがわかります。 また、加入者はラッシュアワーであっても、利用可能なチャンネルを合計で消費することはありません。 私たちはこれについて非常に真剣に考えています。 さまざまなサービスとさまざまな速度測定サーバーを使用すると、興味深い結果が得られました。 すべてのサービスが同じように役立つわけではないことがわかりました...特に夜はそうです。 そして、それらを絶対に信頼すべきではありません。 同じ Ookla ネットワークの多くのオペレータは、幅広い通信チャネルを持っていないか、連続して作業を行っていません。 これは、夕方には正直な結果を得ることがほとんど不可能であることを意味します。 そうです、高速道路は罪深いものであることが判明しました。 たとえば、日本で速度を測定しようとすると、非常に悲惨な結果が示されます...

一次決定

写真は説明のためのものです。

速度制御サーバーは XNUMX 台導入されました。 一つ目は リブレスピード、 XNUMX番目 - OOKLAのスピードテスト。 両方のサービスのパフォーマンスを比較しました。 結局、オークラに立ち寄ることにしました。 加入者の最大 90% がこのサービスを利用しています。

次に、ユーザーと従業員向けに、ネットワーク内外の速度を測定する方法についての説明が書かれました。 それらの。 テストが開始されると、デフォルトでネットワーク内の速度が測定されます。 サーバーはヘッドエンドに配置されており、Ookla ソリューションはデフォルトで加入者に最も近いサーバーを選択します。 このようにして、独自のデータ伝送ネットワークの動作を確認します。

国内の速度を測定するには (国内のすべての通信事業者と主要なデータセンターを統合する通信事業者用の別のネットワークがあります)、国内のプロバイダーを選択して XNUMX 回目の測定を行う必要があります。 私たちは、一日中いつでも多かれ少なかれ安定した結果をもたらすいくつかのサーバーを経験的に特定し、それらを手順で推奨されているものとしてリストしました。

そうですね、外部通信チャネルでも同様のアクションです。 私たちはスピードテストサーバーで大規模なチャネルを持つ大規模な通信事業者を見つけて、推奨事項に書き込みました (申し訳ありませんが、「モスクワ - ロステレコム」と「リガ - バルトコム」)。しかし、適切な数値を取得するためにこれらのノードをお勧めします。個人的に、私はから最大 ~870 メガビットを受け取りました。これらのサーバーはピーク時に使用されます）。

なぜそのような困難があるのでしょうか? すべてはとてもシンプルです。 私たちは、有能な人であれば、私たちのネットワークに問題があるかどうか、共和党のネットワークに問題があるかどうか、あるいはバックボーンに問題があるかどうかを判断できる非常に便利なツールを受け取りました。 あるサービスからのダウンロード速度が遅いと苦情を言う人がいる場合、加入者のチャンネルの速度を測定し、サービスから得られる速度と比較することができます。 そして、契約で指定されたチャンネルを誠実に割り当てていることを示すのは合理的です。 このような速度の違いについて考えられる理由も説明できます。

二次溶液

夜間や日中の速度低下の問題は未解決のままです。 加入者の自宅にいなくても同じことをするにはどうすればよいでしょうか? ギガビット ネットワークを備えた安価なシングルボード カードを使用して、いわゆるプローブを作成します。 デバイスは、特定の時間間隔でケーブルに沿って速度測定を行う必要があります。 ソリューションは、測定結果を表示するための便利な管理パネルを備えた、できるだけ気取らないオープンソースである必要があります。 デバイスは、簡単に交換でき、不安なく n 日間加入者のもとに置いておけるように、できるだけ安価である必要があります。

具現化

BananaPI (モデル M1) が基礎として採用されました。 実はこの選択には XNUMX つの理由があります。

1. ギガビットポート。
2. それはただナイトスタンドに転がっていました。

次に、Pythonクライアントを使用することにしました スピードテストクリ 速度を測定するためのバックエンドとして、Speedtest by Ookla サービス用に使用されます。 図書館 パイソンピング ping速度を測定します。 さて、管理パネル用の php です。 認識を容易にするために私は使用しました ブートストラップ.

Raspberry のリソースは柔軟ではないため、nginx+php-fpm+sqlite3 の組み合わせが使用されました。 MySQL は重くて冗長なのでやめようと思いました。 Iperf に関する質問が予想されます。 地元以外の方向への使用が不可能なため、断念せざるを得ませんでした。

当初、私はこのサイトで多くの人たちの道をたどりました。 Speedtest-cli クライアントを変更しました。 しかし、少し考えた後、彼はこの考えを放棄しました。 元のクライアントの機能を使用する独自のワーカーを作成しました。

ping を分析するには、単純に別のハンドラーを作成しました。 測定値の平均値をとっております。 ping ツールは、IP アドレスとドメイン名の両方を処理できます。

非同期作業は達成できませんでした。 この場合は特に必要ありません。

結果を評価するための管理パネルは非常に最小限であることが判明しました。

図。 テスト結果が表示されたメイン管理ウィンドウ

図。 テスト設定

図。 Speedtest サーバーのリストを更新する

それだけです。 このアイデアは、自由時間に膝の上で実行されました。 フィールドテストはまだ始まっていません。 しかし、近い将来にプロトタイプを発売する予定です。 プロバイダーとプロバイダーのクライアントの両方が使用できます。 自宅で XNUMX 時間測定するのに煩わされる人はいません。 覚えておくべき唯一のことは、インターネットを頻繁にサーフィンしたり、何かをダウンロードしたりすると、測定値は実際の値よりも低くなるということです。 したがって、理想的には、プローブを唯一のトラフィック コンシューマーとしてネットワーク上に残す必要があります。

PS: コードの品質について私を批判しないでください。 未経験で独学です。 のソースコード GitHubの。 批判は受け付けます。

出所： habr.com