VPN 経由のファイル共有が遅く感じる理由：帯域ではなく往復回数

VPN 越しに共有フォルダを開き、ディレクトリ一覧が這うように進むのを待つのはよくある体験で、最初に疑うのは帯域です。たいていリンクはほとんど遊んでいます。プロトコルは返信を待つことに時間を使い、その待ちのたびに LAN では決して請求されなかった往復が丸ごと一回かかります。作業の形を直せば、共有はまた使えるようになります。

遠隔の作業コピーは形が間違っている

SMB はファイルを開き、メタデータを読み、多くの小さなやり取りで確認を返します。マップしたドライブ上のバージョン管理の作業コピーは、ローカルファイルシステムの遅延を前提に、多数の小さなファイルを読みます。デスクトップデータベースはユーザーが作業する間にページを引きます。どれも、やり取りの回数に比例してコストが増えるため、遅延を倍率に変え、そのため 40 ms のトンネルは数百の操作を数秒に変えます。その算術ではペイロードの大きさはほとんど無関係です。

暗号化の負荷はそのごく一部にすぎず、損失のほうが悪く、再送一回と潰れた輻輳ウィンドウは、関与するバイト数よりはるかに高くつきます。

メガバイトより先に往復回数を数える

容量を買う前に遅延を測ります。ping 一回で、やり取りごとに何を払うかが分かります。

ping -c 10 fileserver.example.net

要約は最小・平均・最大の往復時間を示し、ばらつきは平均と同じくらい重要です。平均にディレクトリ一覧が行うやり取りの回数を掛け、実際に観測した時間と比べます。大きなファイル一つは速く転送されるのに閲覧が遅いなら、制約は遅延とリクエスト数です。決して飽和しないリンクに十倍の容量を足しても、何も変わりません。

バイトではなく仕事を動かす

太い管に払う代わりに、仕事が起きる場所を変えます。リポジトリはマウントせずに配信し、差分だけを送る道具でまとめてコピーします。

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

リポジトリを配信すると（hgweb やリモート Git がそうするように）、クライアントはローカルのクローンで作業でき、ファイルシステムの呼び出しがトンネルを越えません。rsync は両側を走査して変更ブロックだけを送るので、素朴なコピーが払うやり取りの大半を省けます。デスクトップデータベースはサーバー側エンジンに置き、クライアントは前面の画面だけにするか、クライアント全体を社内ホストで動かします。どの選択も、プロトコルがどれだけ遅延にさらされるかを変えるところが要点です。

同じ大きさのあたりで固まるのは MTU の症状

ping や小さなページは動くのに、大きな転送がほぼ同じデータ量で止まるなら、帯域ではなくパケットサイズを示しています。

ping -M do -s 1400 -c 3 fileserver.example.net

ICMP と IP のヘッダーが 28 バイトを加えるため、試験が成功すれば 1428 バイトの IP パケットが分割されずに経路を通ります。分割禁止フラグ付きで失敗するなら、トンネルの使用可能な MTU がサーバーの想定より小さいということです。9000 バイトのバッファーを 1500 バイトの経路に送るサーバーは分割か破棄を強い、ICMP が濾過されると経路 MTU の探索は静かに失敗します。トンネルの MTU を下げるか、OpenVPN で mssfix を有効にするか、サーバーのバッファーを小さくしてから、同じ転送をもう一度実行して確認します。

意味のある差を測る

方針が許す場所で、ローカル・トンネル経由・直接のインターネット経路という三通りに同じ操作を実行します。それぞれについて往復時間、大きなストリーム一本の速度、ディレクトリ一覧やアプリ起動にかかる時間を記録します。ローカルの実行とトンネル経由の実行を比べれば、どのコストが支配的か分かります。遅く終わるコピーは速度か遅延の問題を示し、一定の点で死ぬコピーはパケットサイズか経路上の状態を持つ機器を示します。

最初の数メガバイトだけが引きずるなら認証とメタデータを見ますが、すべてが這うなら容量と損失を見ます。当たった原因を直し、WAN リンクが LAN ケーブルのように振る舞うと期待するのをやめましょう。