はじめに
Willow Gamesには2本のネットワークリンクと、小さなスコア更新、大きなリハーサル音声ファイルという2種類の作業があります。両サービスはすでに稼働していますが、応答が最も速いリンクが、大きなファイルも最も速く運べるとは限りません。
通常の送信を試し、同じ対象への遅延とアップロードのスループットを2つの経路で比較し、実験のたびに元の経路を復元します。基本的なターミナル操作と、宛先・ネクストホップ・対象を限定した経路の読み方が必要です。これらは前のルーティングプロジェクト、または同等の練習で学んでいることを想定します。プログラミング、メディアのエンコード、トラフィック整形、iperfの経験は不要です。
すべてのコマンドは Event Client で実行し、受信側の記録は Event Receipts で読みます。各実験は独自の隔離ネットワークを準備し、前のVMの内容は必要ありません。45分は読解と一般的なミスへの対応を含む著者の見積もりであり、初心者による実測時間ではありません。
小さな更新と大きな送信を試す
このステップでは正常に動作しているスコアデスクを使い、実際に2件のデモ送信を行います。Event Client から始めてください。このターミナルは、隔離されたLinuxネットワーク名前空間内の管理者シェルで、すでに /home/labex/project/event-links にいます。受信側は別の名前空間にあり、両者は1台のVMのカーネルを共有します。これらのコマンドにプラットフォームのシェルを使わないでください。タブを開いてもネットワークは再構築されません。
Willow Gamesには素早いスコア操作と、完全なリハーサル音声ファイルが必要です。小さなリクエストではパケットの移動待ちが時間の多くを占め、大きなアップロードでは全バイトを運ぶ十分な転送能力も必要です。レイテンシは移動の遅延、スループットは毎秒届けられる有効なデータ量です。どちらか一方だけですべての作業を説明することはできません。
pwd は作業ディレクトリ、cat はファイルの内容を表示します。ファイルがないと表示されたら、綴りを確認し、以下の完全な cd コマンドで作業場所に戻ってください。入力ミスでVMをリセットする必要はありません。
pwd
cd /home/labex/project/event-links
cat links.tsv
2行には lane1 と lane2、各ネクストホップ、このクライアントの送信元アドレスが記されています。ネクストホップとは、宛先へ向かうパケットを次に受け取る隣接ノードです。スコアの宛先は 10.205.10.10、メディアの宛先は別アドレスの 10.205.10.20 です。どちらもポート 8080 で待ち受けます。リンクの遅延と転送能力はセットアップで準備済みです。整形、アドレス、サービスは変更しないでください。
まず既存の正常なスコアを読みます。curl はHTTPリソースを転送します。--noproxy '*' はすべてのアドレスで環境のプロキシ設定を迂回し、引用符はシェルによるワイルドカード展開を防ぎます。-f はHTTPエラー時に失敗させ、-s は進捗表示を隠し、-S はエラーを引き続き表示します。まとめて -fsS と書きます。--max-time 35 は転送全体を35秒に制限します。URLで実際の宛先、ポート、リソースを指定します。
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
warmup、1–1 のスコア、preserved が表示されるはずです。この正常例を利用可能なまま維持してください。これは今回の新しい送信ではありません。
JSONで表されたデモスコアを読みます。波括弧は名前付きフィールドを囲み、文字列は二重引用符で囲み、2つのスコアは整数です。
cat source/demo.json
試合 demo、ホーム 1、アウェイ 0 が期待値です。-H はHTTPコンテンツタイプを設定します。--data-binary @source/demo.json はこのファイルをそのまま読み、HTTP POSTで送信します。@ はファイルを本文にする指定です。-w は応答の後に簡単な時間結果を表示します。単一引用符で囲まれた文字列内では、\n は改行、%{time_total} は経過秒数を意味します。コマンド全体を1行としてコピーしてください。
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/demo.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
受領記録の match、スコア、peer_ip、local_ip を読みます。受信側が受け付けた内容と、実際の接続元・接続先を識別できます。同じ試合にPOSTを繰り返すとその試合の記録が置き換わり、試合が重複して作られることはありません。
用意された demo.wav は、独自に作成された2秒のサウンドチェック音で、有効なPCM WAV音声です。メディアの作成やエンコードは不要です。-T はファイル本文をHTTP PUTでアップロードします。同名でPUTを繰り返すと、そのメディアタスクが置き換わります。
curl --noproxy '*' -fsS --max-time 35 -T source/demo.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/demo.wav
受領記録にはバイト数と内容のSHA-256ダイジェストが含まれます。ダイジェストはバイト列の要約です。一致は内容が同じことの裏付けになりますが、ファイル名だけでは裏付けになりません。実際の受信ファイルを比較するため、もう一度ダウンロードします。-o は指定パスに応答を保存します。cmp は全バイトを比較し、一致すると何も表示しません。
curl --noproxy '*' -fsS --max-time 35 -o received/demo.wav http://10.205.10.20:8080/media/demo.wav
cmp source/demo.wav received/demo.wav
Event Receipts に切り替え、Refresh receipts を選びます。Existing demonstration receipts を開き、送信した demo スコアと demo.wav を探してください。ページはEvent Client経由で実際の受信側を読み、欠けた記録を元ファイルのフォルダーから補いません。メインカードは次の実験の新しいタスクを待っています。
以下の展開されたデモ欄には、受け付けられた demo のスコアと、demo.wav の識別情報、内容ダイジェスト、実際の接続元が表示されています。この段階ではメインカードが待機しているのが正常です。
curlの終了コードが 7 なら接続できていません。Event Clientへ戻り、アドレス、ポート、次に学ぶ ip route get コマンドを確認します。28 は時間制限の超過で、HTTP拒否ではありません。22 はHTTPエラーです。-f ではcurlはHTTPステータスを報告しますが、エラー応答の本文は省きます。正確なエンドポイントのパスと、提供されたJSON・本文ファイルを照合してください。指定された元ファイルを cat で読み、提供されたファイルを保持してコマンドを修正します。接続に成功しても、違うタスクなら業務上の結果は不正解です。
各経路の遅延を測る
このステップでは同じ宛先への遅延を、各リンクで回数を限定して比較します。Event Client から始めてください。すべてのコマンドは同じクライアントで実行し、メディア宛先の経路だけを変えます。スコア経路、参照経路、デフォルト経路、インターフェース、元ファイル、整形は維持します。
ip route show は現在の経路を一覧表示します。/32 はIPv4の宛先1つだけを選びます。ip route get はカーネルが使う経路と送信元を問い合わせるもので、パケットを送りません。変更する前に現在のメディア経路を読んでください。
ip route show
ip route get 10.205.10.20
via 10.205.1.1 dev lane1 src 10.205.1.2 が期待値です。実験ごとに復元するので、この元の経路を覚えておきましょう。このコースは隔離ネットワーク内の準備済みデフォルト経路を使い、インターネット接続は提供しません。
ip route replace は指定した宛先の経路だけを追加または置き換えます。via はネクストホップ、dev は出力インターフェースを選びます。1つの /32 を置き換えてもデフォルト経路は置き換わりません。まずlane1のテストを明示的に設定します。
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping はICMPエコー要求を送ります。-n は数値アドレスを表示し、-c 4 は4回の要求で停止し、-W 2 は1回の応答を最大2秒待ちます。往復時間（RTT）は往路と応答を含み、片道の遅延でも、アプリケーションのスコア応答時間でもありません。
ping -n -c 4 -W 2 10.205.10.20
4回すべての応答と、最後の min/avg/max/mdev 行を読みます。単位はミリ秒（ms）です。最小値だけでなく平均とばらつきを比較します。準備された場面では、このリンクのRTTは通常約11 msです。初回の近隣探索やVMのスケジューリングでサンプルが遅くなることがあります。
次に、同じ宛先だけをlane2へ切り替えます。
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
測定前の期待値は via 10.205.2.1 dev lane2 src 10.205.2.2 です。
ping -n -c 4 -W 2 10.205.10.20
この経路のRTTは通常約180 msです。差は大きいはずですが、実際の事業者やインターネットに関する保証ではありません。応答がないことは自動的にHTTPサービスの故障を意味しません。ICMPとHTTPは別のプロトコルです。まずこの宛先、ネクストホップ、インターフェースを確認します。値が近い場合は、同じ回数限定の測定を1経路ずつ繰り返し、並列テストを始めないでください。
単一宛先の元の経路を復元し、確認します。
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
リンクの属性を変えずに2種類の移動時間を観察できました。次は、応答が速い経路が大量データも速く運ぶかを確かめます。
必要な方向のスループットを測る
このステップでは同じ2経路のTCPアップロードのスループットを比較します。メディア経路がlane1に復元された Event Client から始めます。用意された受信側では iperf3 サーバーがポート 5201 で稼働しています。クライアントがテストを開始し、サーバーはテストデータを受け取り、到着した内容を報告します。このテスト用バイトはメディアの納品ではありません。
iperf3 -c はサーバーアドレスを選び、-t 5 はデータテストを5秒に制限します。デフォルトのTCPテストはクライアントからサーバーへ送信し、イベントのメディアアップロードと同方向です。方向を反転する -R は使いません。短い準備と結果のやり取りにより、コマンド全体は5秒を少し超える場合があります。
最初のテスト前に経路を確認します。
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
最後の receiver 行を読みます。Bitrate 列は Mbits/sec（Mbps）、つまり毎秒数百万ビットで表示される場合があります。1バイトは8ビットなので、Mbpsを8で割るとおよそのMB/sになります。例えば2 Mbpsは、プロトコルの付加分を考慮する前でも最大で約0.25 MB/sです。転送量の列の MBytes はデータの量で、速度ではありません。lane1の受信側レートは通常1.9 Mbps前後です。
コマンドが終わってから経路を変えてください。同じ宛先をlane2経由で測ります。
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
lane2はRTTが長いにもかかわらず、通常は数十Mbpsを届けます。TCPの立ち上がり、確認応答、プロトコルの付加分、スケジューリング、短い観測期間がレートに影響します。仮想インターフェースの公称速度は測定したスループットではありません。サーバーがテスト実行中と報告したら、現在の時間限定テストの終了を待って1回再試行します。別のサーバーを起動したり、さらにテストを重ねたりしないでください。
元のメディア経路を復元し、確認します。
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
低RTTリンクは小さなやり取りに、高スループットリンクは今回の大量アップロードに向いています。この結論は準備した経路と測定方向に限定されます。Wi-Fi、公共インターネットの通信能力、本番環境の信頼性は測っていません。次の独立した実験では、この観察を使って新しい業務内容を届けます。
まとめ
実際のスコアと再生可能な音声を送信し、同じ宛先への2経路を比較し、RTTとTCP受信側スループットを読み取り、対象を限定した経路を復元しました。測定が表すのは経路と方向です。次のタスクでは観察結果を別々の業務経路に反映します。
