Flentとは
クイックリンク
- Flentとは
- Flentをインストール
- Ubuntu
- Debian
- アーチ
- ジェンツー
- 他のみんな
- 基本設定
- テストを実行する
- テスト
- ルール
- RTT
- TCP
- UDPフラッド
- おわりに
FlentはFLE xible N etwork T esterの略で、それ自体がプログラムではありません。 代わりに、Flentは複数のネットワークテストアプリケーション（特にNetperf）を1回のまとまりのあるパッケージにバンドルするラッパーであり、テストの実行を簡単にし、テストの実行時にグラフとデータの視覚化を自動的に作成するMatplotlibが含まれています。
Flentは、ネットワークをテストし、単純な非効率性から深刻な接続の問題まですべてを診断するための完全なツールキットです。 さらに別のボーナスとして、無料でオープンソースです。
Flentをインストール
FlentはMacとLinuxでのみ利用可能です。 それは、Windowsを捨ててネットワーク全体をLinuxに変換する必要があるという意味ではありません。 テストのために一時的に実行する方法を見つける必要があります。
Ubuntu
Flent PPAを追加することから始めます。
$ sudo add-apt-repository ppa：tohojo / flent $ sudo apt update
次に、Flentをインストールします。
Debian
Flentは、Stretchで始まる公式のDebianリポジトリで利用可能です。 インストールするだけです。
アーチ
FrentはAURから入手できます。 そのページに移動して、必要なものを取得します。
ジェンツー
Flentを「/etc/portage/package.accept_keywords」に追加します。
net-analyzer / flent〜amd64
次に、それを出現させます。
他のみんな
FlentはPythonパッケージです。 インストールされている場合は、pip Pythonパッケージマネージャーを使用してインストールできます。 ほぼすべてのLinuxディストリビューションとHomebrew for Macで利用できます。
基本設定
Flentがインストールされたので、それを使用していくつかの基本的なテストを実行できます。 Flentには、コマンドラインとグラフィカルバージョンの両方があります。 Flentのコマンドを覚えたくないので、このガイドはGUIを使用して作業します。
Flentが適切に機能するには、テスト対象のサーバーが必要です。 そのサーバーでは、サーバーモードでNetperfを実行する必要があります。最初にセットアップして、すべてのテストを一緒に実行できるようにすることをお勧めします。 Netperfは、ほぼすべてのLinuxディストリビューションのリポジトリで使用できるため、パッケージマネージャーでインストールするだけです。
$ sudo apt install netperf
サーバーにインストールしたら、サーバーモードでNetperfを実行します。
$ sudo netserver&
今のところ、サーバーをそのままにしておくことができます。 バックグラウンドでサーバーモードでNetperfを実行し続けます。 Flentを実行しているクライアントから他のすべてを実行できます。
テストを実行する
これで、Flentからサーバーに対してテストを実行できます。 アプリケーションランチャーからFlent GUIを開くか、ターミナルでflent-guiと入力します。 表示されるウィンドウは、最初からかなり単純です。 左上隅の[ファイル]をクリックし、表示されるメニューで[新しいテストの実行]を選択します。
新しいウィンドウでは、実行するテストを選択できます。 まず、「テスト名」ドロップダウンを使用してテストを選択します。 この最初の場合は、「rrul」を選択します。サーバーとして設定したコンピューターのIPを入力し、テストに名前を付けます。 この名前は、Flentが保存する結果を識別するのに役立ちます。 .gz拡張子を持つ圧縮形式のJSONを使用します。 すべてが正常に表示されたら、ウィンドウの左下にある「テストを実行」ボタンをクリックします。
すべてのテストの実行には少し時間がかかるため、辛抱強く、接続を妨げる可能性のある2台のコンピューターでネットワーク上で何もしないようにしてください。 それはあなたのデータを台無しにします。
テストが完了すると、メインのFlentウィンドウに一連のチャートで表示される関連データを見ることができます。 RRULテストは、アップロード、ダウンロード、pingの合計に関する情報を提供します。 チャートはすべて同じ情報を表示しますが、パターンを認識しやすくするために、構成が異なります。 この例の場合、ガベージルーターは待ち時間の負荷を作成し、かなり壊れた結果を生成しました。
テスト
Flentは、さまざまなテストを提供します。 それぞれが異なる方法でネットワークに負荷をかけることができます。 ただし、それらをすべて記憶する必要はありません。 ほとんどは4つの基本的なカテゴリのいずれかに分類されます。 これらのカテゴリは、さまざまな特定の方法でネットワークをテストします。
ルール
RRULは、Realtime R esponse U nder L oadの略です。 それがまさに測定の目的です。 RRULテストは、実際のネットワーク作業負荷をシミュレートし、その負荷の下でターゲットマシンが応答する方法をキャプチャしようとします。 RRULは、 Bufferbloat.netの人々によって開発され、bufferbloatが診断と修復に役立つネットワーク状態を作成します。
Bufferbloatは、ネットワーキングの一般的な問題です。 大量のデータを転送したりストリーミングしたりするときに、ルーターが大量のデータをバッファリングするときに発生します。 この余分なバッファは、ルーターの重みであり、転送の速度を低下させます。 RRULテストのストレスは、ルーターにかなりの負荷をかけてバッファをトリガーするように設計されています。 ネットワークでバッファの膨張が発生している場合、アップロードとダウンロードの両方の数値が低下し始め、テストの実行中にpingが増加します。
RRULトレントテストを実行してみてください。 急流のダウンロードをシミュレートします。これは明らかに非常に激しいタイプのネットワークアクティビティであり、実際には非常に現実的なシナリオです。
上記の結果は、見たく ない もの、待ち時間の負荷、ドロップされたパケットです。 このテストは、混雑したネットワーク上の2つのワイヤレスデバイス間で実施されました。 サーバーが配線されたときの変更に注意してください。
違いは間違いなく顕著です。 接続は完全ではありませんが、1つのデバイスが配線されると、はるかに安定します。 両方はどうですか？
このテストの変動ははるかに少ないです。 これは、干渉の機会や信号強度の不足がないためです。 これは、以前のテストの災害と同じネットワークであることに注意してください。 明らかに、ワイヤレス接続に問題があります。 最後に、Bufferbloat.netが提供するリモートサーバーでテストしてみてください。
ローカルネットワークほどきれいではありませんが、ワイヤレステストほど厄介ではありません。 これはおそらく、インターネット経由での通常のトレントダウンロードに期待されるようなものです。
RTT
RTT、またはラウンドトリップトランスファーテストは、実際にはRRULテストによく似ています。 ターゲットに負荷がかかっていることに依存しません。 代わりに、UDP要求が回線を完了してクライアントに戻るまでにかかる時間を測定するだけです。 pingも含まれます。
適切なRTTテストを行うには、RTT Fairを実行してみてください。 より現実的でやりがいのある状態をシミュレートするために、すでにRRULを試しました。 なぜもっと理想的な状況ではないのですか？ RTT Fairテストは、より制御された条件下でのラウンドトリップがネットワーク上でどのように見えるかを確認するのに役立ちます。 それはかなり無秩序です。 しかし、それはさらに混chaとしていませんか？ これらは有線サーバーでの結果です。
それはほとんど罪の波です。 もちろん、それは理想的ではありませんが、すっきりしていて、かなり高速です。 両方のマシンを配線すると、さらに良くなります。
これは、最初のテストの40Mb / sとは大きな違いです。 もう一度、テストをネットで受けてください。
以前のWiFiの混乱よりも優れています。 繰り返しますが、これらの結果はこのようなテストにはほぼ正しいように見えますが、安定性を高めることが目標になる可能性があります。
TCP
TCPテストは標準TCPです。 彼らは、あなたがウェブサイトにアクセスしているか、メールをチェックしているような基本的なTCPリクエストを測定します。 これらのテストはネットワークにそれほど負荷をかけない可能性がありますが、通常のトラフィックがどのように見えるかをよりよく把握できる場合があります。
より激しいTCPテストを試してください。 12ストリームのTCPダウンロードは、より強力な直接ダウンロードをシミュレートするのに適しています。 優れたネットワークがない場合、深刻な遅延が発生する可能性が高くなります。 たぶん、有線サーバーはここでも物事を改善できるでしょう。
これは実際には1Gb / sに近づきました。 WiFiの結果を考慮すると、これはかなり驚くべきことです。 最後に、リモートサーバーでどのように実行されるかを見てください。
待ち時間は長くなりますが、速度は依然として非常に優れています。 ああ、これもVPN経由でした。 明らかに、問題はネットワーク内部から発生しています。
UDPフラッド
UDPフラッドテストは実際にはRTTテストですが、ターゲットマシンで大量のUDPパケットを一度に送信します。 トラフィックの流れに応答したり適応したりせず、送信するだけです。 これらは、バグや攻撃に対してターゲットマシンがどのように応答するかをテストするのに役立ちます。
おわりに
ネットワークをテストする場合は、ネットワーク内の異なるポイント間でテストして、問題のある領域を絞り込むのが最善です。 このガイドのテストネットワークには、明らかにWiFiに問題があります。 限られた帯域幅と干渉の両方が関係しています。 また、探している問題の種類を明確に把握しておくことも重要です。 その周りにテストを設計します。
お気づきかもしれませんが、結果が描かれているネットワークはそれほど素晴らしいものではありません。 そうではありません。 実際、見たごみの結果のいくつかは、あなた自身のネットワークで注意する必要があるものです。
