ゼロコピーI/Oの技法（sendfile・splice・mmap）

ゼロコピーが解く問題

「ディスク上のファイルをそのままソケットへ送る」——Webサーバーやプロキシが毎秒繰り返すこの動作は、素朴に書くとデータを何度もコピーします。ゼロコピーI/Oとは、この意味のないコピーとモード切替を削る技法の総称です。まず削る対象を正確に数えましょう。

read(file_fd, buf, len);      // ファイル → ユーザーバッファ
write(sock_fd, buf, len);     // ユーザーバッファ → ソケット

このコードが払うコストは2種類あります。データコピーと**コンテキストスイッチ（モード切替）**です。

つまりコピー4回（うちCPUが手を動かすのは2回）とモード切替4回。問題は中央2つのCPUコピーです。データはユーザー空間で何も変換されずに素通りするのに、ページキャッシュ→ユーザーバッファ→ソケットバッファと往復している。この往復はCPUサイクルとメモリ帯域を浪費し、L1/L2キャッシュも汚します。ゼロコピーの本質は、ユーザー空間を経由しないでカーネル内でデータを直結することにあります。前提となるシステムコールとカーネルのモード切替コストと、ページキャッシュとライトバックの仕組みを押さえておくと以降が腑に落ちます。

sendfile：fd間の直結

sendfile(out_fd, in_fd, offset, count) は、入力fd（通常はファイル）から出力fdへカーネル内だけでデータを渡すシステムコールです。ユーザーバッファを一切使いません。

sendfile(sock_fd, file_fd, &offset, len);  // これ1本

これでモード切替は往復1回（syscall発行と復帰）に減り、ユーザー空間への/からのCPUコピー2回が消えます。さらにNICがScatter-GatherDMAに対応していれば、ページキャッシュのページをソケットバッファへコピーせず、ソケットバッファには「このページを送れ」というディスクリプタ（ページ参照＋オフセット＋長さ）だけを置き、NICがページキャッシュから直接DMA読み出しします。この場合、CPUによるデータコピーは完全にゼロになり、残るDMAは2回ともCPU非関与です。これが「真のゼロコピー」と呼ばれる状態です。

splice と vmsplice：パイプバッファをハブにする

sendfile は「ファイル風fd→ソケット」に特化していました。これを任意のfd間へ一般化したのが splice です。鍵はパイプを中継器として使う点にあります。

Linuxのパイプは内部的にページ参照の配列（パイプバッファ）です。splice はデータ本体を動かさず、ソースのページをこのパイプバッファに参照として繋ぎ、もう一方の splice でその参照を宛先fdへ繋ぎ替えます。

// file → pipe → socket をページ参照の付け替えだけで実現
splice(file_fd, NULL, pipe_w, NULL, len, SPLICE_F_MOVE);
splice(pipe_r, NULL, sock_fd, NULL, len, SPLICE_F_MOVE);

ページの実体はページキャッシュに居たまま、パイプバッファのスロットがそれを指すだけ。だから「pipeを経由する」と言ってもメモリコピーは発生しません。パイプを必ず挟むのは、異種fdを繋ぐ共通の中間表現としてパイプバッファ（ページ参照のリングバッファ）が機能するからです。

vmsplice はその仲間で、ユーザー空間のメモリ領域（iovec）をパイプバッファへ参照として注入します。memcpy せず、ユーザーページをそのままパイプのスロットに指させるので、アプリが生成したデータをゼロコピーで送出経路へ載せられます。

mmap：写像でコピーを1回畳む

mmap は別系統のアプローチです。ファイルをユーザーのアドレス空間へメモリ写像し、ページキャッシュのページをそのまま仮想アドレスに見せます。

char *p = mmap(NULL, len, PROT_READ, MAP_SHARED, file_fd, 0);
write(sock_fd, p, len);   // p はページキャッシュを直接指す

read と違い、ページキャッシュ→ユーザーバッファのコピーが起きません。アプリが触る p はページキャッシュそのものを指すからです。ただし write 側ではページキャッシュ→ソケットバッファのCPUコピーが1回残るため、sendfile ほど削れません。mmap の利点はむしろデータをCPUで読み書きしながらコピーを節約できる点で、加工が必要な場合に効きます。仕組みの詳細はメモリマップトファイル（mmap）に譲ります。

MSG_ZEROCOPY：送信ペイロードを直接DMA

ここまでは主に「ファイル→ソケット」でした。アプリが自分で生成したデータをゼロコピー送信したい場合の仕組みが MSG_ZEROCOPY です。send(fd, buf, len, MSG_ZEROCOPY) と指定すると、カーネルは buf のユーザーページをソケットバッファへコピーせず、そのページをピン留めしてNICへ直接DMAします。

問題は完了の通知です。通常の send は「カーネルにコピーし終えたら戻る」ので、戻った瞬間にバッファを再利用できます。ところが MSG_ZEROCOPY はコピーしないため、send が戻ってもまだページは送信中かもしれません。そこでカーネルは送信完了をエラーキュー経由の非同期通知で返します。

send(..., MSG_ZEROCOPY) → すぐ戻る（ページはまだ送信中）
   … 実際の送出 …
recvmsg(MSG_ERRQUEUE) → 通知到着。連番でどの送信が完了したか分かる
   → ここで初めて buf を安全に再利用できる

この非同期完了モデルゆえに、MSG_ZEROCOPY は大きなバッファを送るときにだけ得をします。小さい送信ではコピーの方が安く、ページのピン留め・通知処理・エラーキュー読み取りのオーバーヘッドが上回ります。カーネルは「ゼロコピーが割に合わない」と判断すると、黙って通常コピーへフォールバックすることもあり、通知フラグでそれを見分けられます。

技法の選び分け

選択の軸は3つです。第一にデータを加工するか。加工が要るなら sendfile/splice は使えず、mmap か MSG_ZEROCOPY が候補。第二にデータの出所がファイルかアプリ生成か。第三に送るサイズ——ゼロコピーは固定費（ページ管理・非同期通知）を払うので、小さな転送ではコピーの方が速い場合が多いことです。

まとめ