# WebRTCネットワーク診断ガイド（パケットロス調査） ## 概要デジタルヒューマンを表示する端末でアニメーションコマ落ち問題が発生している場合に、原因を特定する方法をご案内いたします。 **対象環境** * ホストスペック: 要件を満たしている * 表示端末は [デジタルヒューマンを快適に利用するための端末要件](/users/faq/digitalhumans-system-requirements.md) をご覧下さい。 * MiniPrem（デジタルヒューマン配信サーバー）は [環境準備](/dev/miniprem/miniprem-prerequisites.md) をご覧下さい。 * ファイアウォール: 設定なし（FWやプロキシが問題になっている場合はネットワーク管理者に許可してもらうことで解決します。 [\*\*ファイアウォール・\*\*ネットワーキングとWebRTC + TURN](/dev/overview/firewall-requirements.md) を参照してください。） ## 用語解説このガイドで使用する用語を説明します。 | 用語 | 説明 | | ------------- | ------------------------------------------------------------------------------------------- | | **配信サーバー** | デジタルヒューマンを配信しているサーバーのIPアドレス（例: `192.168.0.100`）またはドメイン名（例: `render-host.digitalhumans.jp`）。 | | **RTT** | Round Trip Time（往復遅延時間）。データが送信されてから返答が戻ってくるまでの時間。 | | **パケットロス** | ネットワーク上でデータが失われる割合。1%未満が理想的。 | | **ジッター** | 遅延時間の揺らぎ。値が大きいと映像がカクつきます。 | | **WebRTC** | ブラウザでリアルタイム通信を行うための技術。デジタルヒューマンの映像配信に使用。 | | **TURN/STUN** | ファイアウォールやNATを越えて通信するための中継サーバー。 | | **P2P** | Peer to Peer。端末同士が直接通信する方式。 | | **バッファ** | データを一時的に蓄えるメモリ領域。受信データを先読みして保持することで、ネットワーク変動を吸収する。 | | **バッファリング** |

データを事前に受信してバッファに蓄える処理。遅延と引き換えに安定性を得る。
例：YouTube（数秒先まで蓄える）、WebRTC（数十ms、最小限）。

| | **UDP** | User Datagram Protocol。データを高速送信するプロトコル。再送なし。WebRTCで使用。 | | **ICMP** | Internet Control Message Protocol。pingコマンドで使用。診断用プロトコル。 | | **MTU** | Maximum Transmission Unit。1回で送信できる最大パケットサイズ（通常1500バイト）。 | ## 通信経路の確認デジタルヒューマンとの通信には2つのパターンがあり、それぞれ診断基準が異なります。 ### **どちらの経路か確認する方法:** 1. Chromeで `chrome://webrtc-internals/` を開く（URLに入れる） 2. 接続中のセッションを選択 3. `candidateType` を確認 * `host` または `srflx`: P2P直接通信（ケース1に該当） * `relay`: TURN経由（ケース2に該当） ### ケース1: P2P直接通信（NAT/ファイアウォールなし） MiniPremを使用する場合 ``` 表示端末（MiniPrem） ←→ デジタルヒューマン配信サーバー(MiniPrem) # 同一端末内表示端末（あなたの端末） ←→ VPNやプライベートネットワーク/LAN ←→ デジタルヒューマン配信サーバー(MiniPrem) # 同一ネットワーク内の別端末 ``` **特徴:** * 最も高速・低遅延 * ファイアウォールやNATがない環境（同一ネットワーク上に`表示端末（あなたの端末）` と `デジタルヒューマン配信サーバー`が存在する場合） * RTT基準値: <150ms推奨、<300ms許容 ### ケース2: TURN/STUN経由（NAT/ファイアウォールあり）通常のクラウドレンダリングサービスを使用する場合 ``` 表示端末（あなたの端末） ←→ (NAT/ファイアウォール) ←→ インターネット ←→ TURNサーバー ←→ デジタルヒューマン配信サーバー(通常サービス) ``` **特徴:** * 社外や公開ページなど、ネットワーク構成を気にせず利用できる * 中継サーバー経由のため遅延増加 * 企業ネットワークやファイアウォール環境で使用 * RTT基準値: <250ms推奨、<400ms許容（中継分を考慮） ### シーケンスダイアグラム [シーケンスダイアグラム](https://gitlab.digitalhumans.jp/docs/docs-digitalhumansjp/-/blob/main/development/README.md#シーケンスダイアグラム)を参照してください。 ## WebRTC vs 動画配信・VoIPのパケット特性比較「動画が見られる」「IP電話ができる」「インターネットが速い」環境でも、デジタルヒューマンでコマ落ちが発生する可能性があります。 **重要な違い：** * **YouTube等の動画配信**: 数秒〜数十秒先までバッファリング → 一時的なネットワーク遅延に強い * **WebRTC（デジタルヒューマンやオンラインミーティング）**: リアルタイム性重視でバッファリングなし → **パケットロスが即座にコマ落ちにつながる** **よくある誤解：**❌ 「100Mbpsの回線だから大丈夫」と言われますが、実際には**帯域よりもパケットロス率が重要です**。100Mbpsあっても、WebRTC Videoはリアルタイムに表示するためにバッファを多く確保できないので、パケットロス1〜3%程度でコマ落ちが発生します。 | 項目 | 動画配信 (YouTube等) | IP電話 (VoIP) | デジタルヒューマン (WebRTC Video) | | ------------ | --------------- | ------------ | ----------------------------- | | パケットサイズ | 可変 | 270バイト | 1200-1500バイト | | パケット間隔 | 可変 | 20ms (50pps) | 33ms (30fps) または 16ms (60fps) | | プロトコル | TCP (HTTP) | UDP/RTP | UDP/SRTP | | ビットレート | 可変 (1-50Mbps) | 64kbps | 2-10Mbps | | **バッファリング** | **数秒〜数十秒** | **数十ms** | **最小限** | | **パケットロス耐性** | **強い（再送可能）** | **中程度** | **極めて弱い（再送なし）** | | **遅延許容度** | 数秒OK | <150ms | <150ms（P2P） <250ms（TURN） | **WebRTCの特性:** 1. **リアルタイム性最優先**: 遅延を最小限にするため、バッファリングをほとんど使わない 2. **再送信なし**: パケットが失われても再送信せず、そのフレームは欠落 → コマ落ち 3. **パケットロスの影響**: たった1%のパケットロスでも、30fpsの場合は1秒間に約10フレームが失われる ## 診断フローチャート（簡易版） ### ステップ1: 通信経路の確認 ChromeでURLにアクセス `chrome://webrtc-internals/` ``` chrome://webrtc-internals/ → candidateType を確認 ├─ host / srflx → P2P直接通信（RTT基準: <300ms） └─ relay → TURN経由（RTT基準: <400ms） ``` ### ステップ2: 基本レイテンシー確認 **Windows:** ```powershell # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください ping -n 100 192.168.0.100 ``` **Linux/Mac:** ```bash # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください ping -c 100 192.168.0.100 ``` **判定基準**: * ✅ 平均RTT <100ms: 良好 * ⚠️ 平均RTT 100-300ms（TURN: 100-400ms）: 許容範囲 * ❌ 平均RTT >300ms（TURN: >400ms）: WebRTC通信に支障 * ❌ パケットロス >1%: 要調査 ### ステップ3: WebRTC相当のping（Linux/Macのみ） ```bash # 30fps、1200バイト # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100 ``` **判定**: * ✅ パケットロス 0%、RTT安定: OK * ⚠️ パケットロス 1-3%: コマ落ちの可能性 * ❌ パケットロス >3%: コマ落ち確実 ### ステップ4: UDP帯域・ジッターテスト（iperf3必須） **Windows:** ```powershell # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください iperf3.exe -c 192.168.0.100 -u -b 5M -t 30 ``` **Linux/Mac:** ```bash # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください iperf3 -c 192.168.0.100 -u -b 5M -t 30 ``` **判定**: * ✅ Jitter <30ms、Loss <1%: 良好 * ⚠️ Jitter 30-50ms、Loss 1-3%: コマ落ちの可能性 * ❌ Jitter >50ms、Loss >3%: コマ落ち確実 ### ステップ5: 経路診断（Linux/Macのみ） ```bash # mtrで問題箇所特定 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください mtr -r -c 100 192.168.0.100 ``` どのホップでパケットロスが発生しているか確認 ### ステップ6: 実WebRTC統計（最終確認） `chrome://webrtc-internals/` で実際の通信状況を確認（最も正確） ## OS別診断方法お使いのOSに応じた診断手順を説明します。 ### Windows の場合 Windowsでは一部のLinux/Macコマンドが使えないため、以下の方法を推奨します。 **方法1: WSL2を使用（推奨）** Windows 10/11ではWSL2（Windows Subsystem for Linux）を使うことで、Linux向けコマンドがそのまま使えます。 **WSL2のインストール:** ```powershell # PowerShellを管理者権限で実行 wsl --install # 再起動後、Ubuntuを起動 ``` インストール後は「**Linux/Mac編**」の手順をそのまま実行できます。 **方法2: Windowsネイティブツール** WSL2が使えない場合、以下のツールで代替できます。 **基本ping（標準コマンド）:** ```powershell # PowerShell またはコマンドプロンプト # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください ping -n 100 192.168.0.100 ``` **判定基準:** * 平均RTT <100ms: 良好 * 平均RTT 100-300ms（TURN経由は100-400ms）: 許容範囲 * パケットロス <1%: 良好 **iperf3のインストール（UDP帯域テスト用）:** 1. [iperf3 Windows版](https://iperf.fr/iperf-download.php#windows)をダウンロード 2. 解凍して `iperf3.exe` を任意のフォルダに配置 3. PowerShellでそのフォルダに移動 ```powershell # UDP帯域テスト # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください iperf3.exe -c 192.168.0.100 -u -b 5M -t 30 ``` **PsPing（Microsoft製ツール）:** より詳細な診断が必要な場合、Microsoftの[PsPing](https://learn.microsoft.com/ja-jp/sysinternals/downloads/psping)が便利です。 ```powershell # インストール後 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください psping -n 100 192.168.0.100:80 ``` ### Linux/Mac の場合以下のコマンドがそのまま使用できます。 **コマンド例の注意事項:** * 以下のコマンドの `192.168.0.100` や `render-host.digitalhumans.jp` は例です * 実際のIPアドレスまたはドメイン名に置き換えてください **1. WebRTC 30fps相当のping（標準品質）** **なぜ必要？** デジタルヒューマンの実際の通信パターン（1200バイト、30fps）を模擬してネットワーク品質を確認します。 ```bash # パケットサイズ1200バイト、33ms間隔（30fps相当） # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100 ``` **実行時間**: 約33秒（1000パケット） **確認項目**: * **P2P直接通信**: 平均RTT <150ms推奨、<300ms許容 * **TURN経由**: 平均RTT <250ms推奨、<400ms許容 * パケットロス: <1%推奨、<3%許容 **2. WebRTC 60fps相当のping（高品質）** ```bash # より高フレームレート（60fps = 16.67ms間隔） # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください sudo ping -i 0.016 -s 1200 -c 2000 192.168.0.100 ``` **実行時間**: 約33秒（2000パケット） **3. MTU上限テスト（1500バイト）** **な**ネットワーク経路でパケット分割が発生していないか確認します。分割が起きるとパフォーマンスが低下します。 ```bash # MTUサイズでのテスト（フラグメンテーション確認） # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください sudo ping -M do -s 1472 -c 100 192.168.0.100 #Linux sudo ping -D -s 1472 -c 100 192.168.0.100 #macOS ``` **説明**: * `M do` `-D`: パケット分割禁止（Path MTU Discovery） * `1472` = 1500 (Ethernet MTU) - 28 (IP+ICMP header) * エラーが出る場合、MTU問題あり ## より正確な診断ツール ### iperf3による帯域・ジッター・パケットロス測定 ping（ICMP）は優先度が低く扱われることがあります。iperf3はWebRTCと同じUDPプロトコルで、より正確な診断が可能です。 ### MiniPrem側（デジタルヒューマン配信サーバー） ```bash # iperf3サーバー起動 iperf3 -s -p 5201 ``` ### クライアント側（表示端末（あなたの端末）） **テスト1: UDP帯域テスト（WebRTC相当）** ```bash # 5Mbps UDPストリーム、30秒間 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください iperf3 -c 192.168.0.100 -u -b 5M -t 30 -i 1 ``` **オプション説明**: * `u`: UDPモード（WebRTCと同じ） * `b 5M`: 5Mbps帯域（標準ビットレート） * `t 30`: 30秒間 * `i 1`: 1秒ごとに統計表示 **確認項目**: * Jitter（ジッター）: <30ms推奨 * Lost/Total Datagrams: パケットロス率 <1% * Transfer: 実際の転送量 **テスト2: 双方向テスト** ```bash # 双方向同時テスト（WebRTCは双方向通信） # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください iperf3 -c 192.168.0.100 -u -b 5M -t 30 --bidir ``` **テスト3: 段階的帯域増加テスト** ```bash # 2Mbpsから開始 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください iperf3 -c 192.168.0.100 -u -b 2M -t 10 # 5Mbps（標準） iperf3 -c 192.168.0.100 -u -b 5M -t 10 # 10Mbps（高品質） iperf3 -c 192.168.0.100 -u -b 10M -t 10 ``` ### mtrによる経路全体の診断 mtrコマンドを使用すると、どの中継地点（ルーター）で問題が発生しているか特定できます。特にNATを超えるパターンの場合はプロバイダーのパケットロスなども検討がつきます。 **tracerouteとmtrの違い** | 機能 | tracert や traceroute | mtr (\*\*Linux/Mac/\*\*WSL2) | | ---------- | -------------------- | ---------------------------- | | プロトコル | ICMP のみ | ICMP / **UDP** | | パケットロス率 | ❌ 表示なし | ✅ Loss% | | ジッター | ❌ 表示なし | ✅ StDev | | 統計精度 | ★☆☆ | ★★★ | | WebRTC診断精度 | ★☆☆（参考程度） | ★★★（最適） | ### Windowsでのmtrインストール WSL2を使えば、Linux/Macと同じmtrコマンドが使えます（推奨）。 **WSL2のメリット:** * **UDP診断が可能**：WebRTC相当の正確な診断ができる * **詳細な統計**：tracertよりも多くの情報（Loss%, StDev等）が得られる * **inux/Macと同じコマンド**：本ドキュメントの全てのmtrコマンドがそのまま使える **WSL2セットアップ（初回のみ）**: 1. PowerShell（管理者権限）で以下を実行： ```powershell wsl --install -d Ubuntu ``` 1. 再起動後、Ubuntuを起動してユーザー名・パスワードを設定 2. mtrをインストール： ```bash # WSL2 Ubuntu内で実行 sudo apt update sudo apt install -y mtr ``` ### macOSでのmtrインストール ```bash # Homebrewでインストール（初回のみ。Homebrewは別途インストールしてください） brew install mtr # インストール確認 mtr --version ``` [Homebrew](https://brew.sh/ja/) ### mtrで経路全体の診断を行う実際のWebRTC映像パケットに最も近い条件でテストします。 ```bash # 経路上の全ホップのパケットロス・レイテンシーを可視化 # WebRTC相当（1200バイト、33ms間隔、約33秒） # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100　# レポートモード sudo mtr -s 1200 -i 0.033 192.168.200.1　# rオプションなしでリアルタイムモード ``` **オプション説明**: * `u`: UDPプロトコル（WebRTCはUDP/RTPを使用） * `s 1200`: パケットサイズ1200バイト（WebRTC映像RTPパケット相当） * `i 0.033`: 33ms間隔（30fps = 1000ms ÷ 30） * `-r`: レポートモード（統計を1回表示して終了、オプションなしはリアルタイム表示） * `c 1000`: 1000パケット送信（約33秒のテスト） **なぜこのパラメータなのか**: * WebRTCの映像ストリームは、1200バイト前後のRTPパケットを30fps（約33msごと）で送信します * UDPは再送なし・優先度制御なしのため、実際のネットワーク品質が如実に現れます * ICMPは優先制御されることがあり、実際のUDPパフォーマンスと異なる場合があります **モードの違い**: | モード | コマンド例 | 動作 | 用途 | | ----------- | --------------------------- | ------------------------------ | ------------ | | リアルタイムモード | mtr 192.168.0.100 | ncurses画面でリアルタイム更新、`Ctrl+C`で停止 | 対話的な診断、変動の観察 | | レポートモード（-r） | mtr -r -c 100 192.168.0.100 | 指定パケット数送信後、統計を表示して自動終了 | スクリプト実行、ログ取得 | **出力例**: ``` Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 100 1.2 1.3 1.0 2.5 0.2 2. isp-gateway 0.0% 100 8.5 9.1 7.2 15.3 1.8 3. 192.168.0.100 2.0% 100 45.2 48.3 42.1 85.7 8.5 ``` **問題箇所の特定**: * 特定のホップでLoss%が高い → そのネットワーク区間に問題 * StDev（標準偏差）が高い → ジッター（遅延の揺らぎ）が大きい **各フィールドの意味**: | フィールド | 意味 | 読み方 | 判定基準 | | --------- | ------- | -------------------- | ------------------------------------------------------------------- | | **Loss%** | パケットロス率 | このホップで失われたパケットの割合 |

✅ 0%
⚠️ 0.1-3%
❌ >3%

最重要
✅ <100ms
⚠️ 100-300ms
❌ >300ms

ジッター指標
✅ <10ms
⚠️ 10-30ms
❌ >30ms

| **実践的な読み方**: **例1: 良好な接続** ``` Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 100 1.2 1.3 1.0 2.5 0.2 2. isp-gateway 0.0% 100 8.5 9.1 7.2 15.3 1.8 3. 192.168.0.100 0.0% 100 45.2 48.3 42.1 55.0 3.2 ``` * ✅ Loss% = 0%: パケットロスなし（理想的） * ✅ Avg = 48.3ms: 平均遅延が良好 * ✅ StDev = 3.2ms: ジッターが小さい（安定） * **結論**: 接続品質良好、コマ落ちの心配なし **例2: パケットロスあり（問題）** ``` Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 100 1.2 1.3 1.0 2.5 0.2 2. isp-gateway 0.0% 100 8.5 9.1 7.2 15.3 1.8 3. 192.168.0.100 5.0% 100 45.2 48.3 42.1 85.7 8.5 ← ★問題 ``` * ❌ Loss% = 5.0%: 問題あり（3%超） * ⚠️ StDev = 8.5ms: ジッターもやや高め * **結論**: 最終ホップ（配信サーバー）でパケットロス → コマ落ち確実 **例3: 中間ホップでパケットロス** ``` Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 100 1.2 1.3 1.0 2.5 0.2 2. isp-gateway 3.0% 100 8.5 9.1 7.2 15.3 1.8 ← ★問題箇所 3. 192.168.0.100 0.0% 100 45.2 48.3 42.1 55.0 3.2 ``` * ❌ ホップ2でLoss% = 3.0%: ISPゲートウェイで問題 * **結論**: ISP側の問題、ISPに連絡または回線変更を検討 **例4: 高ジッター（不安定）** ``` Host Loss% Snt Last Avg Best Wrst StDev 1. router 0.0% 100 1.2 1.3 1.0 2.5 0.2 2. isp-gateway 0.0% 100 8.5 9.1 7.2 15.3 1.8 3. 192.168.0.100 0.0% 100 45.2 48.3 42.1 150.0 35.5 ← ★高ジッター ``` * ✅ Loss% = 0.0%: パケットロスなし * ❌ StDev = 35.5ms: ジッターが高い（不安定） * ❌ Wrst = 150.0ms: 瞬間的に150msまで遅延 * **結論**: コマ落ちやカクつきが発生する可能性高、ネットワーク不安定 **重要な指標の優先順位**: 1. **Loss%（パケットロス率）**: 0%が理想、1%未満を目指す、3%超で即コマ落ち 2. **StDev（標準偏差 = ジッター）**: 10ms未満が理想、30ms超でカクつき 3. **Avg（平均RTT）**: P2P <150ms推奨、TURN <250ms推奨 ## TURN/STUN経由の追加診断 TURN/STUN経由で通信している場合、以下の追加診断が有効です。 **1. TURNサーバーへの接続診断** ```bash # TURNサーバーのIPアドレス/ドメインを確認 # chrome://webrtc-internals/ の relay candidate から取得 # TURNサーバーへのping # ※ turn.example.com は実際のTURNサーバーアドレスに置き換えてください ping -c 100 turn.example.com ``` **判定基準**: * RTT <50ms: 良好（TURNサーバーは近い方が有利） * RTT 50-100ms: 許容範囲 * RTT >100ms: TURN経由の遅延が大きくなる原因 **2. TURN経由の総合RTT確認** ```bash # TURNサーバー経由でデジタルヒューマン配信サーバーへping # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください ping -c 100 192.168.0.100 ``` **判定基準（TURN経由）**: * RTT <250ms: 良好 * RTT 250-400ms: 許容範囲 * RTT >400ms: コマ落ちの可能性高 **計算例:** ``` あなた → TURNサーバー: 30ms TURNサーバー → 配信サーバー: 80ms 総RTT = (30 + 80) × 2 = 220ms （許容範囲） ``` ## Chrome WebRTC統計（最も正確） **なぜ最も正確？** 実際のWebRTC通信の内部データを直接確認できるため、推測ではなく事実がわかります。 **手順**: 1. Chromeでデジタルヒューマンに接続 2. 別タブで `chrome://webrtc-internals/` を開く 3. 「Stats graphs for」セクションで接続を選択 4. 以下の項目を確認 **重要な統計項目**: | 項目 | 説明 | 推奨値 | | --------------------- | ----------- | ------------------------------- | | googFrameRateReceived | 受信フレームレート | 30fps | | googFrameRateDecoded | デコードフレームレート | 30fps | | packetsLost | パケットロス数 | 最小 | | googJitterBufferMs | ジッターバッファ | <100ms | | googCurrentDelayMs | 現在の遅延 | P2P: <150ms / TURN: <250ms | | bytesReceived | 受信バイト数 | ビットレート計算用 | | candidateType | 接続タイプ | host/srflx (P2P) / relay (TURN) | ## コマ落ちの原因別対策 **パターンA: パケットロス > 3%** **原因**: ネットワーク輻輳、機器の問題 **対策**: **Linux/Mac:** ```bash # 1. 経路上の問題箇所特定 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください mtr -r -c 200 192.168.0.100 # 2. ルーターのQoS設定を確認 # 3. 有線接続を確認（Wi-Fi→有線） # 4. ネットワークスイッチの負荷確認 ``` **Windows:** * ルーターの設定画面でQoS（Quality of Service）を確認 * Wi-Fi → 有線LANに切り替え * ネットワークアダプターのドライバー更新 **パターンB: ジッター > 50ms** **原因**: ネットワークの不安定性 **対策**: **Linux/Mac:** ```bash # 1. 長期間のジッター監視 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください ping -D -i 0.033 -s 1200 192.168.0.100 > ping_log.txt & # -D: タイムスタンプ付き # バックグラウンドで継続実行し、数時間後に解析 ``` **パターン分析**: * ジッターが周期的 → 他のトラフィックの影響 * ジッターが不規則 → 機器の問題 **Windows:** * タスクマネージャーでネットワーク使用状況を確認 * 他のアプリケーション（OneDrive、Windows Update等）が帯域を使用していないか確認 **パターンC: レイテンシー > 300ms（TURN: >400ms）** **原因**: 物理的距離、ルーティングの問題、TURN経由の遅延 **対策**: **Linux/Mac:** ```bash # 1. tracerouteで経路確認 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください traceroute 192.168.0.100 # 2. 不要な中継を経由していないか確認 # 3. CDN/エッジノードの利用検討 ``` **Windows:** ```powershell # tracertで経路確認 # ※ 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください tracert 192.168.0.100 ``` **TURN経由の場合:** * TURNサーバーの位置を確認（近い方が有利） * 可能であれば、ファイアウォール設定を見直してP2P直接通信を試みる **パターンD: 帯域不足** **原因**: 他のトラフィックとの競合 **対策**: **全OS共通:** 1. 実効帯域の確認（iperf3） 2. QoS（Quality of Service）設定 * ルーターでWebRTC（UDP 22000-23000）を優先 3. 同一ネットワーク上の他トラフィック確認 * Zoom、Teams、ダウンロードなどが同時実行されていないか **Windows:** ```powershell # ネットワーク使用状況の確認 Get-NetAdapter | Get-NetAdapterStatistics ``` ## 実践的な診断手順（推奨） ### クライアント側（表示端末（あなたの端末））で実行 **Windows（PowerShell）:** ```powershell # ※ 以下のコマンドの 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください # 1. 基本疎通確認（10秒） ping -n 100 192.168.0.100 # 2. iperf3でUDP帯域テスト（30秒、要iperf3サーバー） iperf3.exe -c 192.168.0.100 -u -b 5M -t 30 # 3. 経路確認 tracert 192.168.0.100 # 4. 実際のWebRTC統計確認 # chrome://webrtc-internals/ で接続中の統計を確認 ``` **Linux/Mac（Bash/Zsh）:** ```bash # ※ 以下のコマンドの 192.168.0.100 は実際のIPアドレスまたはドメイン名に置き換えてください # 1. 基本疎通確認（10秒） ping -c 100 192.168.0.100 # 2. WebRTC相当のping（30秒） sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100 # 3. 経路診断（1分） mtr -r -c 100 192.168.0.100 # 4. UDP帯域テスト（30秒、要iperf3サーバー） iperf3 -c 192.168.0.100 -u -b 5M -t 30 # 5. 実際のWebRTC統計確認 # chrome://webrtc-internals/ で接続中の統計を確認 ``` ## クイックリファレンス ### 判定基準早見表 | 指標 | 良好 | 許容（P2P） | 許容（TURN） | 要対策 | | ------- | ------ | --------- | --------- | -------------------------- | | RTT | <100ms | 100-300ms | 100-400ms | P2P: >300ms / TURN: >400ms | | パケットロス | <1% | 1-3% | 1-3% | >3% | | ジッター | <30ms | 30-50ms | 30-50ms | >50ms | | フレームレート | 30fps | 25-30fps | 25-30fps | <25fps | ### コマンド早見表（Linux/Mac） **注意**: `192.168.0.100` は実際のIPアドレスまたはドメイン名に置き換えてください。 | 目的 | コマンド | | ------------------- | ------------------------------------------------------- | | 基本ping | `ping -c 100 192.168.0.100` | | WebRTC ping (30fps) | `sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100` | | 経路診断（簡易/ICMP） | `mtr -r -c 100 192.168.0.100` | | 経路診断（WebRTC/UDP）★推奨 | `sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100` | | UDP帯域テスト | `iperf3 -c 192.168.0.100 -u -b 5M -t 30` | | MTUテスト (Linux) | `sudo ping -M do -s 1472 -c 100 192.168.0.100` | | MTUテスト (macOS) | `ping -D -s 1472 -c 100 192.168.0.100` | ### コマンド早見表（Windows） **注意**: `192.168.0.100` は実際のIPアドレスまたはドメイン名に置き換えてください。 | 目的 | コマンド | | -------------------- | ------------------------------------------------------- | | 基本ping | `ping -n 100 192.168.0.100` | | 経路診断（tracert/標準） | `tracert 192.168.0.100` | | 経路診断（WSL2/簡易） | `mtr -r -c 100 192.168.0.100` | | 経路診断（WSL2/WebRTC）★推奨 | `sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100` | | UDP帯域テスト（PowerShell） | `iperf3.exe -c 192.168.0.100 -u -b 5M -t 30` | | UDP帯域テスト（WSL2） | `iperf3 -c 192.168.0.100 -u -b 5M -t 30` | ## よくある質問（FAQ） ### Q1: P2PとTURN経由、どちらが使われているかわからない **A:** `chrome://webrtc-internals/` を開いて、接続中のセッションで `candidateType` を確認してください。 * `host` または `srflx`: P2P直接通信 * `relay`: TURN経由 ### Q2: Windowsで `sudo` コマンドが使えない **A:** 2つの方法があります： **1. ネイティブWindows（sudo不要）**: PowerShellまたはコマンドプロンプトでは `sudo` は不要です。直接コマンドを実行してください： ```powershell ping -n 100 192.168.0.100 tracert 192.168.0.100 ``` **2. WSL2（推奨）**: WSL2をインストールすれば、Linux/Macと同じ `sudo` コマンドが使えます： ```bash sudo ping -i 0.033 -s 1200 -c 1000 192.168.0.100 sudo mtr -u -s 1200 -i 0.033 -r -c 1000 192.168.0.100 ``` ### Q3: iperf3サーバーが起動できない **A:** デジタルヒューマン配信サーバー側でiperf3サーバーを起動する必要があります。サーバー管理者に依頼してください。 ### Q4: TURN経由でRTTが400ms以上になる **A:** 以下を確認してください： 1. TURNサーバーの位置が遠すぎないか 2. ファイアウォール設定を見直してP2P直接通信が可能か 3. ネットワーク管理者にWebRTC用ポート（UDP 22000-23000）の開放を依頼 ### Q5: パケットロスが3%以上発生している **A:** 以下の順序で対策してください： 1. Wi-Fi → 有線LANに切り替え 2. `mtr` コマンド（Linux/Mac）または `tracert`（Windows）でどこでパケットロスが発生しているか特定 3. ルーターのQoS設定を確認 4. ネットワーク管理者に相談 ### Q6: コマンドの `192.168.0.100` は何に置き換えればいい？ **A:** デジタルヒューマンを配信しているサーバーのIPアドレスまたはドメイン名に置き換えてください。 * IPアドレスの例: `192.168.0.100`、`10.0.0.50` * ドメイン名の例: `render-host.digitalhumans.jp`、`dh-server.company.local` 不明な場合は、システム管理者またはサポート窓口にお問い合わせください。 ## **診断結果をサポートに送っていただく際の情報** 以下の情報を含めると、より迅速なサポートが可能です： 1. OS情報（Windows/Mac/Linux、バージョン） 2. 通信経路（P2P/TURN経由） 3. 配信サーバーのIPアドレスまたはドメイン名 4. `chrome://webrtc-internals/` のスクリーンショット 5. pingまたはiperf3の実行結果 6. mtr/tracertの実行結果（可能であれば） --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.digitalhumans.jp/ops/troubleshooting/webrtc-network-diagnostics.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.