トンネルリレーがスループットを制限している警告サインは何ですか？

リレーは、接続がリレー経由のままであり、両端点が十分に使用されていない状態で直接またはより近い経路に切り替えるとスループットが急激に改善する場合に、スループットを制限している可能性があります。

オーバーレイVPNやアウトバウンドトンネルは、NATトラバーサルがピアツーピア経路を形成できない場合に、共有またはセルフホスト型のリレーにフォールバックすることがよくあります。リレーは接続性を維持しますが、別のネットワーク区間、キュー、TCPまたはTLSレイヤー、地理的迂回、公平性制限、処理ポイントを追加します。信頼できる診断では、暗号化やNASの遅いファイルコピーだけを原因とせず、リレーの状態、遅延、ジッター、方向、端末CPU、直接経路のコントロールを比較します。

データ経路が実際にリレー経由であることを確認する

トンネルクライアントのピアステータスをトラフィックがアクティブな間に確認します。経路が直接、リレー、プロキシ、またはモード間で切り替わっているかどうか、さらに選択されたリレーの地域やホストを記録します。

Tailscaleの問題では、セルラークライアントがDERPに留まり、遅延が200～900ミリ秒に及ぶ事例が報告されています。したがって、接続済みステータスは到達可能性を示すものであり、効率的なデータ経路を保証するものではありません。

クライアントが遅いテスト中ずっと直接接続を報告している場合は、リレーを原因と判断しないでください。端末CPU、トンネルのオフロード、MTU、ISPのアップロード速度、Wi-Fi、ストレージのテストを続けてください。

同じ端末間でリレー経路と直接経路を比較する

同じクライアントとホームサーバー間でリレー経由のネットワークのみのスループットテストを実施し、その後直接ピア経路または一時的なポート到達可能なテストネットワークを確立して再度テストします。プロトコル、方向、端末ハードウェアは変更しないでください。

公開されたピアリレーの事例では、リレーのトポロジーを変更しただけで遅延が大幅に減少し、12.5倍のスループット向上が測定されました。

リレーを除去または移動した後に大きくかつ再現可能な改善が見られれば、それは強い証拠です。小さな変化しかない場合は、ホームのアップロード速度やリモートのWi-Fiが既に低い上限を設定している可能性があり、リレーが主なボトルネックでないことを示します。

高遅延、ジッター、地理的迂回に注意する

ピアおよびリレー地域への最小、中央値、高パーセンタイルの遅延を測定します。アイドル時および持続的な転送中のジッターとパケットロスも記録します。

独立した診断レポートでは、平均遅延が400msを超え、かなりのジッターと測定可能なパケットロスを伴うリレー経路が記録されており、この組み合わせはトンネルが確立されたままでもTCPファイル転送やインタラクティブアクセスを崩壊させる可能性があります。

リレーが両端点から地理的に遠い場合や負荷時に遅延が大きく変動する場合は、より近い地域、セルフホスト型リレー、またはピアリレーをテストしてください。安定して低いリレー遅延でスループットが悪い場合は、容量、公平性、CPU、またはトランスポートの挙動に問題がある可能性が高いです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

リレーに一貫したスループット上限があるか確認する

異なる時間帯と両方向で複数の大容量転送を実行します。リレーの制限は、端末のインターネット速度、NASストレージ、クライアントのWi-Fiが改善しても上昇しない安定したプラトーとして現れることが多いです。

リレー実装に関するベンチマーク作業では、転送容量、CPU効率、同時負荷がトンネルスループットに大きく影響することが示されています。現在のDERP互換プロジェクトは、CPUサイズとトラフィックレベルにわたるマルチロードリレーベンチマークを公開しています。

1つのストリームがプラトーに達した場合は、2つ目の制御されたストリームを追加して合計スループットを観察します。固定された共有上限はリレーまたは経路の容量を示唆し、リレーCPUがアイドル状態でスループットが低いままなら、RTT、損失、輻輳制御、または端末の制約が原因です。

リレーの制限を端末CPUやISPアップロード速度と区別する

両端点とセルフホスト型リレーのCPU、ソフト割り込み、暗号化処理使用率、NIC利用率、ディスク活動を監視します。遅い方向をホーム接続の測定済みアップロードおよびダウンロード容量と比較します。

リレーは最も遅い入出力区間の速度でしか転送できません。低スペックVPS、遠隔地域、制限されたコンテナ、共有ホームアップリンクでリレーを実行すると、管理されたリレーの制限と同様の症状が再現されることがあります。

端末またはリレーのCPUが飽和状態に達している場合は、リレーの地理的変更を行う前にそのノードの調整やアップグレードを行ってください。CPUが低くても一方のISP方向が満杯の場合、リレーはアクセスリンクの制限を露呈しているだけで作り出しているわけではありません。

停止境界でリレー設計を変更する

通常トラフィックでリレー経路が選択されたままであり、許容できない遅延やジッターを生み、作業負荷要件を下回る持続スループット制限があり、直接またはより近いリレー制御で残りの経路がより良く動作することが証明された場合は、リレー経路を置き換えます。

ZimaSpaceのCGNATリモートアクセスの代替手段ガイドでは、リレーが最速経路でなくても必要になる理由を説明しています。

唯一到達可能な経路を無効にして代替がない状態にするのではなく、より近いピアリレー、より良い位置のVPS、改善されたNATトラバーサル、または低帯域幅のワークフローを選択してください。新しい設計は短いpingだけでなく、元のリモートファイル、メディア、同期の作業負荷で検証してください。