Mac の Finder で WebDAV が遅い本当の理由と、効く対策

Synology や QNAP の NAS の WebDAV を Finder にマウントして、ファイルが数百個入ったフォルダを開く。そこで延々と待たされた経験がある人は多いはずです。

たいていの場合、遅いのはサーバーではありません。Finder の WebDAV クライアントが異常におしゃべりで、その往復を待っているだけです。

フォルダ 1 つ表示するのに何が起きているか

1 つのディレクトリを表示するために、おおよそこれだけの通信が発生します。

• Depth 1 の PROPFIND が 1 回。フォルダ内の項目を列挙します。ここまでは何も問題ありません。
• 続けて PROPFIND の連打。個々の項目を調べ直し、すでに受け取った属性を確認し、マウスが通り過ぎただけのサブフォルダまで覗きにいきます。
• フォルダに入るたびに .DS_Store を読み、出るときに書き込みます。表示設定を保存するためです。
• ほぼすべてのファイルについて AppleDouble の相方を探しにいきます。report.pdf があれば ._report.pdf も探す、という動きです。Mac を相手にしたことのないサーバーではこれが全部 404 になりますが、404 の往復コストは 200 とまったく同じです。
• マウント時のロック確認。Finder はサーバーが WebDAV class 2 かどうかを気にします。LOCK を名乗らないサーバーは、はっきりしたエラーも出ないまま読み取り専用でマウントされることがあります。
• レスポンスには Content-Length が欲しい。チャンク転送は Finder のクライアントが苦手とする部分で、サーバー側が余計なバッファリングを強いられます。

ここで簡単な計算をしてみます。ファイル 300 個、1 項目あたり 3〜4 リクエスト、サーバーまでの往復が 40 ms。ファイルの中身を 1 バイトも受け取らないうちに、待ち時間だけで 40 秒前後です。帯域は一切関係ありません。遅延にリクエスト数を掛けた値がそのまま体感になります。

コマンドラインから叩くと十分速いサーバーが、Finder 経由だと別物に感じる理由はここにあります。

WebDAV 高速化に実際に効く設定

まず、ネットワークボリュームへの .DS_Store 書き込みを止めます。

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

反映にはログアウトして入り直す必要があります。代償も先に書いておきます。これはユーザー単位の設定で、SMB を含むすべてのネットワークボリュームに効きます。その代わり、そうしたボリュームでは表示設定が保存されなくなります。すでに作られた .DS_Store が消えるわけでもありません。

残りはどれもリクエスト数を減らすための工夫です。

• アイコンプレビューを切る。表示メニューから表示オプションを開き、アイコンプレビューのチェックを外します。サムネイルを描くためだけに Finder がファイルの中身を読みにいくのを防げます。
• 自分で構成を決められるなら、1 階層のファイル数は数百までに抑える。リクエスト数は項目数に比例します。
• 大きなフォルダで作業するときはリスト表示にする。アイコン表示やギャラリー表示は不利です。
• 大量転送はマウント経由でやらない。専用の WebDAV クライアント、あるいは AnyStorage 自体で転送すれば、Finder に交通整理をさせずに済みます。

どれも 1 回の往復を速くするものではなく、往復の回数を減らしているだけだという点に注目してください。式のもう半分は遅延です。

往復をループバックに移す

リクエスト数が削れないなら、遅延のほうを削ります。

AnyStorage はその発想で作られています。WebDAV サーバーがインターネットの向こう側ではなく、手元のマシンで動きます。サイドバーの「サービス」から WebDAV タブを開き、開始を押すだけです。既定のエンドポイントは http://127.0.0.1:3211 で、ポートは 1〜65535 の範囲で変更できます。HTTP Basic 認証は常に有効で、ユーザー名の既定値は anystorage、パスワードは初回に 24 文字がランダム生成されます。どちらも編集可能で、コピーボタンも付いています。あとは Finder の「移動」から「サーバへ接続」、または Cmd+K で http://127.0.0.1:3211 を貼り付け、登録ユーザーとしてその認証情報でログインします。

Finder の振る舞いは何も改善しません。PROPFIND の嵐も ._ の探索もそのままです。違うのは、それらがすべてループバックを通り、1 往復が 1 ミリ秒に満たないという点だけ。数百回掛けても小さいままです。

アプリ内で現在接続されているストレージは、接続名のフォルダとしてこのルート直下に並びます。S3、Cloudflare R2、Google ドライブ、Dropbox、SFTP、WebDAV、ローカルフォルダなど、対応する接続タイプは 20 種類。NAS も SFTP か WebDAV の接続として登録すれば、同じルートの下に並びます。実際にネットワークを越えるのはファイルの中身だけで、読み取りは HTTP Range に対応したストリーミングなので、QuickTime でシークしても必要な範囲だけを取りにいきます。

これで直らないこと

Finder は Finder のままですし、ローカルのエンドポイントがクラウド側の速度を作り出すわけでもありません。

• 5 万オブジェクトが並ぶプレフィックスの一覧は依然として遅い。バックエンドの列挙が遅いからです。ループバックが消せるのは Finder のオーバーヘッドであって、その下の API 呼び出しではありません。
• 無料版の WebDAV サーバーは読み取り専用です。読み書きは Pro の機能で、Pro でも意図的に読み取り専用のままにできます。
• 現行バージョンに TLS はありません。URL は平文の http で、Basic 認証の資格情報も平文です。既定で 127.0.0.1 のみを listen しているのはそのためです。LAN アクセスを有効にすると 0.0.0.0 にバインドされ、アプリが明確な警告を出します。
• 本当のファイルロックはありません。複数のマシンから同じファイルを編集しても何も保護されません。チーム共有の基盤として扱わないでください。
• アプリを再起動した後は、一度アプリ内でその接続を開くまで WebDAV のルートには現れません。接続は遅延して確立されるためです。新しく追加した接続はサーバーを再起動しなくても表示されます。

ここまでやっても Finder にうんざりするなら、普段の閲覧はアプリ側で済ませ、マウントは実パスを要求してくるソフト用に取っておく、という割り切りが現実的です。

よくある質問