NAS転送中のUDPパケットロス：原因の切り分けと対処方法

NAS転送中のUDPパケットロスを調べるには、まず問題のファイル転送が実際にUDPを使っているか確認し、同じ時間帯の送信側と受信側の証拠を比較します。コピーの停止、インターフェースのカウンター増加、キャプチャにないパケットは、それぞれ原因が異なる場合があります。

確認したいのは、物理リンク、受信ホスト、キャプチャツール、転送アプリのどこで処理が止まったかです。その区別によって、ケーブル、受信側の負荷、キャプチャの品質、アプリのどれを調べるべきかが決まります。

ロスを数える前に対象の通信を確認する

アプリ、転送方向、両端のアドレス、関連ポートを特定します。別の監視アラートに出たプロトコルをすべてのNASコピーに当てはめず、アプリの資料と実際の接続を確認してください。TCPを使う転送なら、UDP専用のバッファー調整から始めるのは適切ではありません。

UDPの基本仕様は到達や重複防止を保証しません。アプリはUDPの上に回復機能を追加できます。QUICはUDPの上に信頼性のあるストリームを提供します。そのため、データグラムの欠落だけで保存したファイルの破損は確定しません。

アプリの完了状態とエラーは、ネットワークの観測とは別に記録します。pingは到達性の確認に役立ちますが、ICMPのプローブではアプリのUDP配送は測れません。

累積値ではなくカウンターの変化を読む

問題の転送の直前と直後に値を保存し、開始・終了時刻、方向、インターフェース、経路、アプリのバージョンを記録します。起動後の大きな累積値は、今回の転送での欠落を示しません。今回増えた値にも、同じインターフェース上の別の通信が含まれ得ます。

対応ツールのあるLinuxホストでは、次の読み取り専用コマンドでインターフェースと詳細な統計を確認できます。

ip -s -s link show

転送に使うインターフェースを確認してください。NASのシェル、ドライバー、監視画面は機種によって異なります。統計が取得できなければ、その機器がサポートする資料に従います。この例を再現するためだけにツールを追加したり、システム設定を変えたりする必要はありません。

Linuxのインターフェース統計の資料は次のカウンターを区別しています。変化は調査の手掛かりとして扱います。

これらの値には重複があり得ます。Linuxの古い/proc/net/dev表示は一部の項目をまとめ、ドロップ総数には取りこぼしも含めます。表示された値を独立したロスとして足し合わせないでください。インターフェースの合計には複数のアプリも含まれます。

キャプチャの欠落とネットワークのロスを分ける

許可があり実施可能なら、両端で対象通信をキャプチャします。時間帯、方向、フローをそろえ、識別できるデータグラムや、利用可能なアプリのシーケンス情報を比較します。送信側にあり受信側にないデータグラムが調査範囲を絞るのは、両方のキャプチャを信頼できる場合です。特定のスイッチまでは特定できません。

Wireshark自身のドロップ数はキャプチャの欠落を測ります。Wireshark側の説明では、パケットがホストに到達しても、記録するプロセスに渡らない場合が示されています。記録の欠落はネットワークのロスに見えることがあります。ツールが欠落情報を報告しない場合は、ゼロと見なさず不明として記録します。

受信アプリのログや取得可能なソケットバッファー統計とも照合します。受信バッファーの逼迫とケーブル不良は別の問題です。一般的なインターフェースのドロップ数だけでは、特定のUDPソケットのオーバーフローは証明できません。

iperf3は条件を管理した経路確認に使う

両端が対応し、共有ネットワークでの実施が許可されていれば、iperf3のUDPテストが役立ちます。ESnetのiperf3資料では、-uがUDP、-bが目標ビットレート、-Rが方向の反転です。制御接続にはTCPを使うため、接続失敗だけではUDPデータが遮断されたとは言えません。

合意した低いレートから始め、利用可能な容量と作業時間帯の範囲内でのみ増やします。レート、データグラムのサイズ、時間、方向、両端のツールのバージョンを記録してください。無制限のUDP送信はテスト自体が混雑を作るため避けます。受信側のロス報告と、同じ時間帯のエンドポイントのカウンターを比較します。

結果が示すのは、そのテストプロセスと条件での挙動です。ファイルアプリのデータ欠落を証明するものでも、別の負荷で同じ結果を保証するものでもありません。ストレージとネットワーク全体の切り分けには、あらゆる原因をこのテストに盛り込まず、長距離転送の診断ガイドを使ってください。

証拠に合わせて一つだけ変更する

一つのリンクでCRCエラーが増えるなら、その接続を確認し、正常なケーブルやポートで比較します。受信側の負荷を示す証拠があるなら競合する処理を減らし、アプリとNASベンダーのバッファー資料を確認します。バッファーを増やしても、物理エラーは修復できず、恒常的に過負荷の受信側が無期限に処理し続けられるようにはなりません。

方向でロスが変わるなら、受信側の役割を追います。コンピューターからNASへのコピーではNASが受信し、逆方向ではコンピューターが受信します。有線と無線、または許可された別経路の比較で範囲を絞れますが、負荷やエンドポイントの変更も記録が必要です。

元の設定を保存し、一度に一つの条件を変えて、同等の条件で再確認します。管理されたスイッチやファイアウォールの変更は管理者と調整してください。証拠なしにMTU、VLAN、永続的なシステムバッファー設定を一括変更するのは避けます。

最後に、速度とは独立してファイルの結果を検証します。アプリの整合性検証を使うか、両端の同じ変更されていないファイル版で暗号学的ハッシュを比較します。完了、整合性、カウンターの変化をまとめて記録してください。速くなっただけでは、疑っていたロスの解消は証明できません。

WarpDirectは意図したエンドポイント間転送を、WarpSyncは選択フォルダーの同期を担当します。どちらも診断の代わりにはなりません。コンピューターとNASを継続的に使うなら、問題の経路を特定した後で共有アクセスとローカル同期コピーを選ぶか、WarpSendのNASワークフローを確認してください。

よくある質問

pingでNAS転送中のUDPパケットロスを証明できますか？

できません。pingはICMPを使い、転送アプリのUDPフローは測定しません。応答があってもUDPの欠落は起こり得ますし、応答がない原因はICMPのフィルタリングかもしれません。転送のプロトコルを確認し、同じ時間帯の通信とカウンターを照合してください。

NASのUDP受信バッファーを増やすべきですか？

受信側の関連する証拠がある場合に限って検討します。インターフェースのドロップ、キャプチャの欠落、ソケットのバッファーエラーは別の指標です。NASの機種とソフトウェアの資料を確認し、元の値を記録して一度に一つの設定を変更してください。

パケットロスがあると転送したファイルは破損していますか？

必ずしもそうではありません。UDP自体は欠落したデータグラムを回復しませんが、アプリが再送や修復、完成ファイルの検証を行う場合があります。アプリの整合性検証結果、または変更されていない送信元と宛先のファイルの暗号学的ハッシュを比較してください。速度やロスのカウンターだけでは整合性は分かりません。