ソケットバッファとゼロコピー送受信

ソケットバッファはカーネル内のキューである

アプリが send() を呼んでもデータが即座に回線へ出るわけではありません。データはまずカーネル内の 送信ソケットバッファ（send buffer） にコピーされ、send() はそこで返ります。実際の送出はTCPの輻輳制御・フロー制御に従ってカーネルが行います。受信側も対称で、NICが受け取ったデータは 受信ソケットバッファ（receive buffer） に積まれ、アプリが recv() で読み出すまでそこに滞留します。

この2つのバッファはソケットごとに独立して存在し、アプリの送出ペースと回線の送出ペースを decouple（分離） する緩衝材です。ソケットそのものの概念は ソケットとポート番号 を前提にします。

• 送信バッファ: アプリの書き込み速度 ＞ 回線速度のときに溢れを吸収する。さらに 未ACKデータの再送用コピーを保持 する役割も持つ。
• 受信バッファ: 回線の到着速度 ＞ アプリの読み出し速度のときに溢れを吸収する。空き容量がそのまま広告ウィンドウになる。

受信バッファと広告ウィンドウは直結している

ここが原理の核心です。受信バッファの 空き容量 が、ACKで相手に通知される広告ウィンドウ（rwnd）そのものになります。アプリが recv() で読み出すと空きが増え、rwndが拡大します。逆にアプリの処理が詰まって読み出しが遅れると、受信バッファが埋まり、rwndが縮み、ついには0（ゼロウィンドウ）になって送信側が止まります。

広告ウィンドウ(rwnd) ≒ 受信バッファサイズ − 未読データ量

したがって 受信バッファサイズの上限が、その方向で取れるrwndの上限 を決めます。送信側がいくら送れても、受信バッファが小さければrwndで頭打ちになる。フロー制御の全体像とゼロウィンドウの挙動は TCPのフロー制御とウィンドウスケーリング を参照してください。

BDPに基づくバッファサイズ設計

「ではバッファをいくつにすべきか」を決める唯一の正しい基準が 帯域遅延積（BDP, Bandwidth-Delay Product） です。

BDP = 帯域 × RTT
例: 1Gbps × 80ms = 約10MB

BDPは「ACKが返ってくる前に回線上を飛んでいられるデータ量」、すなわち回線を埋め尽くすために必要なin-flight量です。回線を100%使い切るには、送信側は最低でもBDP分を未ACKのまま流し続けられなければなりません。これは送信バッファ・受信バッファ・rwnd・cwndのいずれもがBDP以上である必要を意味します。帯域とRTTがスループットを規定する関係は 帯域・レイテンシ・スループット の通りです。

小さすぎる害は明白です。BDPが10MBの経路でバッファが64KBなら、64KB送るたびにACKを待って停止し、回線の1%も使えません。一方、大きすぎても害がある のがポイントです。送信側がBDPを大きく超える量を流し込むと、経路上のキューに長く滞留し、遅延（とジッタ）が膨らむ。これが バッファブロートと AQM（CoDel・FQ-CoDel・PIE） で扱うbufferbloatです。バッファは「BDPを満たす最小限」が理想で、無限に大きくすればよいものではありません。

ゼロコピーがスループットを上げる原理

バッファサイズが「窓を開ける」話なら、ゼロコピーは「同じCPUでより多く流す」話です。両者は別の軸の最適化です。

ファイルをそのままソケットへ送る典型的な処理 read() + send() を考えます。カーネルはディスクのデータを一度カーネル空間のページキャッシュに読み込み、それを ユーザー空間のバッファへコピー、アプリが send() を呼ぶとそれを 再びカーネルの送信バッファへコピー します。データはユーザー空間を素通りするだけなのに、CPUは無駄に2回コピーし、read/send で都度ユーザー・カーネル間の コンテキストスイッチ を起こします。

read()+send() の流れ（簡略）:
  ディスク → ページキャッシュ → ユーザーバッファ → ソケット送信バッファ → NIC
              （DMA）        （CPUコピー）     （CPUコピー）      （DMA）
  コンテキストスイッチ: read で2回, send で2回 = 計4回

ゼロコピー は、このユーザー空間への往復を丸ごと省きます。

sendfile と splice

sendfile() は「ファイルディスクリプタからソケットへ」をカーネル内だけで完結させるシステムコールです。データはユーザー空間に一切現れません。

// out_fd（ソケット）へ in_fd（ファイル）の中身を直接転送
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

さらにNICがスキャッタギャザDMA（SG-DMA）に対応していれば、ページキャッシュからソケット送信バッファへのCPUコピーすら省け、NICがページキャッシュを直接読み出します。splice() はより汎用で、パイプを介して2つのfd間をカーネル内で繋ぎます。いずれも本質は「データに触れずに参照（ページ）だけを受け渡す」ことです。

効果は CPUとメモリ帯域の節約 です。10Gbps級の転送ではコピー自体がCPUとメモリバスを飽和させ、ここがスループットの上限になります。コピーを削れば同じCPUでより多くの接続・帯域をさばける。Webサーバーの静的ファイル配信やプロキシ、tee/cat 的なストリーミングが典型的な適用先です。

まとめ

ソケットバッファはアプリと回線のペース差を吸収するカーネル内キューで、送信バッファは未ACKデータの再送用保持を兼ね、受信バッファの空きはそのまま広告ウィンドウになります。だから高BDP路で帯域を使い切るにはバッファをBDP以上に取る必要があり、小さすぎればrwndで頭打ち、大きすぎればbufferbloatで遅延が膨らむ——最適は「BDPを満たす最小限」で、通常は自動調整に委ねます。そしてゼロコピー（sendfile/splice）はユーザー空間への往復コピーとコンテキストスイッチを削り、CPU律速のスループットを引き上げますが、データを加工しない素通し転送にのみ効きます。バッファ設計が「窓の広さ」を、ゼロコピーが「CPUあたりの送出量」を決める、と分けて捉えるのが要点です。