短い答え遅延は配信時間、損失は期待されたメッセージが届かないことです。それらを個別にチェックし、同じ条件を維持してケーブルに沿って測定を繰り返します。

どのような症状をチェックする必要がありますか?

音声が断片的に途切れ、ゲームのアクションがロールバックし、ビデオ通話が一時的にフリーズします。このような症状は損失と一致しますが、それを証明するものではありません。過負荷のコンピュータ、アプリケーション、およびそのサーバーでも同様の動作が発生します。

通常の HTTP リクエストは、より低いレベルでの再配信を待つ場合があります。したがって、失敗した HTTP プローブ数を単に「損失パケットの割合」という名前に変更することはできません。このチェックでは、メッセージを再配信せずに別の WebRTC チャネルを使用します。

パケットロステスト

無料

小切手を読み込んでいます...

調整の仕組み

ブラウザは番号付きのメッセージを送信します。サーバーは受信したメッセージの数を保存し、エコーを送信します。最後に、クライアントは HTTP 経由でサーバー ログを受信し、送信されたリスト、サーバーによって受信されたリスト、ブラウザに返されたリストの 3 つのリストを比較します。

「損失アップ」は、送信されたメッセージの数に基づいて計算されます。 「エコーロス」は、サーバーが実際に受信したメッセージの数に基づいています。両方のインジケーターを 1 つの初期値で割ると、方向が混乱しやすくなります。レポートには結果を確認できるように数量が保存されます。

ブラウザを介したアプリケーションベースの測定です。 WebRTC メッセージと IP パケットは交換可能な単位ではなく、アプリケーションの負荷も配信に影響を与える可能性があります。このサービスは、この結果をラインの実験室分析として提示するものではありません。

接続が開かない場合

WebRTC の障害は 100% の損失を意味するわけではありません。 UDP 制限、ブラウザ ポリシー、VPN、企業ネットワーク、または測定ノード設定エラーの可能性があります。この場合、テストでは接続エラーが示されますが、インターネット品質がゼロではありません。

開く HTTPの安定性チェック、ネットワークで許可されている場合は VPN を使用せずに再試行し、別の接続を試してください。テストのために企業の保護を無効にしないでください。結果を管理者に渡します。

損失を発見した後に行うべきこと

  1. 条件を変えずに短い走行を 2 ~ 3 回繰り返します。単一の短い測定では、大きなランダム誤差が生じます。
  2. ケーブルで接続し、チェックしているコンピューターの Wi-Fi をオフにします。
  3. 同じネットワーク上の別のデバイスを確認してください。最初の 1 つだけで問題が解決しない場合は、そのアダプタとプログラムに検索を絞り込みます。
  4. 静かなネットワークとアクティブな送信の瞬間を比較してください。負荷に応じて便利 バッファ膨張テスト.
  5. 時間、条件、メッセージ数を記載したサポート ログを送信します。

0% は保証とみなされますか?

いいえ。ゼロは、選択した間隔で特定のノードに未配信のテスト メッセージがないことを意味します。頻度の低い障害、さまざまなルート、およびさまざまなメッセージ サイズは依然として観察できません。良好な結果は役に立ちますが、その範囲は数値とともに保存する必要があります。

情報源と方法論

Calcomera編集部このメソッドのテスト、説明、および未解決の制限。 編集者について