.. タイトル: システム バッファーのチューニング - TCP とネットワーク パフォーマンスの最適化
.. スラッグ: システムバッファチューニング
.. 日付: 2026-02-02 10:00:00 UTC
.. タグ: ネットワーキング、パフォーマンス、チューニング、TCP、バッファ
.. カテゴリ: 記事
..リンク:
.. 説明: ネットワークの問題として誤診されることが多い TCP パフォーマンスの問題を解決するためのシステム バッファーの理解と最適化
.. タイプ: テキスト
<style>
.buffer-table {
    width: 100%;
    border-collapse: collapse;
    margin: 20px 0;
}
.buffer-table th, .buffer-table td {
    border: 1px solid #ddd;
    padding: 12px;
    text-align: left;
}
.buffer-table th {
    background-color: #4CAF50;
    color: white;
}
.buffer-table tr:nth-child(even) {
    background-color: #f2f2f2;
}
.os-section {
    margin: 30px 0;
    padding: 20px;
    border-left: 4px solid #4CAF50;
    background-color: #f9f9f9;
}
.warning-box {
    background-color: #fff3cd;
    border-left: 4px solid #ffc107;
    padding: 15px;
    margin: 20px 0;
}
.diagnostic-box {
    background-color: #e7f3ff;
    border-left: 4px solid #2196F3;
    padding: 15px;
    margin: 20px 0;
}
code {
    background-color: #f4f4f4;
    padding: 2px 6px;
    border-radius: 3px;
    font-family: 'Courier New', monospace;
}
pre {
    background-color: #f4f4f4;
    padding: 15px;
    border-radius: 5px;
    overflow-x: auto;
}
</style>
<h1>システムバッファのチューニング: 「ネットワークの問題」の背後に隠れた犯人</h1>
<h2>エグゼクティブサマリー</h2>
<p>ネットワーク エンジニアは、TCP ウィンドウ処理やアプリケーションのパフォーマンスがネットワーク インフラストラクチャに起因する状況に頻繁に遭遇します。広範なパケット キャプチャ、tcpdump、およびネットワーク分析を実行した後、多くの場合、真のボトルネック、つまりクライアントまたはサーバー システム上の枯渇した NIC (ネットワーク インターフェイス カード) または OS レベルのバッファが発見されます。</p>
<p>この記事では、Linux、Windows、および macOS の従来の (2009 年頃) と現在 (2025 ～ 2026 年) のバッファ構成の両方を提供し、バッファ枯渇が重大な問題になる前に特定するための診断テクニックも提供します。</p>
<div class="diagnostic-box">
<h3>バッファ枯渇の一般的な症状</h3>
<ul>
<li>パケット キャプチャ内の TCP ゼロ ウィンドウ イベント</li>
<li>ネットワーク遅延が低いにもかかわらず、再送信率が高い</li>
<li>アプリケーションのスループットが利用可能な帯域幅を大幅に下回ります</li>
<li>負荷がかかるとパフォーマンスが低下しますが、負荷が減少するとパフォーマンスが向上します</li>
<li>同様のハードウェア構成間でパフォーマンスが一貫していない</li>
<li>ソケット エラーまたは「リソースが一時的に利用できません」メッセージ</li>
</ul>
</div>
<h2>問題を理解する</h2>
<h3>TCP ウィンドウ スケーリング メカニズム</h3>
<p>TCP は、受信側が受け入れることができるデータ量を示す「ウィンドウ サイズ」を通知するフロー制御メカニズムを使用します。システム バッファがいっぱいになると、このウィンドウはゼロまで縮小し、送信者は待機する必要があります。これはネットワークの問題のように見えますが、実際にはホスト リソースの問題です。</p>
<h3>バッファが重要な場所</h3>
<ul>
<li><strong>ソケット バッファ (SO_SNDBUF/SO_RCVBUF):</strong>ソケットごとの送信および受信バッファー</li>
<li><strong>TCPウィンドウバッファ:</strong>接続の最大 TCP ウィンドウ サイズ</li>
<li><strong>ネットワークデバイスのバッファ:</strong>パケットキューイング用のNICリングバッファ</li>
<li><strong>システム全体のメモリ:</strong>ネットワーク用に割り当てられた全体的なメモリ</li>
</ul>
<h2>診断コマンド</h2>
<div class="diagnostic-box">
<h3>Linux 診断</h3>
<pre>
# Check current TCP buffer settings
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.core.rmem_max
sysctl net.core.wmem_max

# Check NIC ring buffer sizes
ethtool -g eth0

# Monitor socket buffer usage
ss -tm

# Check for TCP zero window events
tcpdump -i any 'tcp[tcpflags] &amp; tcp-push != 0' -vv

# Check network statistics for buffer issues
netstat -s | grep -i "buffer\|queue\|drop"
</pre>
<h3>Windows 診断</h3>
<pre>
# Check TCP parameters
netsh interface tcp show global

# View network adapter buffer settings
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object {$_.DisplayName -like "*buffer*"}

# Monitor TCP statistics
netstat -s -p tcp

# Check receive window auto-tuning
netsh interface tcp show global | findstr "Receive Window"
</pre>
<h3>macOS 診断</h3>
<pre>
# Check current buffer settings
sysctl kern.ipc.maxsockbuf
sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace

# View network statistics
netstat -s -p tcp

# Monitor socket buffers
netstat -an -p tcp
</pre>
</div>
<h2>Linuxのバッファチューニング</h2>
<div class="os-section">
<h3>レガシー Linux 設定 (2009 年頃)</h3>
<table class="buffer-table">
<tr>
<th>パラメータ</th>
<th>レガシーバリュー (2009)</th>
<th>説明</th>
</tr>
<tr>
<td>net.core.rmem_default</td>
<td>124928 (122KB)</td>
<td>デフォルトの受信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.core.rmem_max</td>
<td>131071 (128KB)</td>
<td>最大受信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.core.wmem_default</td>
<td>124928 (122KB)</td>
<td>デフォルトの送信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.core.wmem_max</td>
<td>131071 (128KB)</td>
<td>最大送信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.ipv4.tcp_rmem</td>
<td>4096 87380 174760</td>
<td>TCP 受信バッファ: 最小、デフォルト、最大 (バイト単位)</td>
</tr>
<tr>
<td>net.ipv4.tcp_wmem</td>
<td>4096 16384 131072</td>
<td>TCP 送信バッファ: 最小、デフォルト、最大 (バイト単位)</td>
</tr>
<tr>
<td>net.ipv4.tcp_mem</td>
<td>196608 262144 393216</td>
<td>TCP メモリ ページ: 低、圧力、高</td>
</tr>
<tr>
<td>net.core.netdev_max_backlog</td>
<td>1000</td>
<td>入力キュー内の最大パケット数</td>
</tr>
<tr>
<td>net.core.optmem_max</td>
<td>10240 (10KB)</td>
<td>ソケットあたりの最大補助バッファ サイズ</td>
</tr>
</table>
<h3>現在の Linux 設定 (2025-2026)</h3>
<table class="buffer-table">
<tr>
<th>パラメータ</th>
<th>現在の推奨値</th>
<th>説明</th>
</tr>
<tr>
<td>net.core.rmem_default</td>
<td>16777216 (16MB)</td>
<td>デフォルトの受信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.core.rmem_max</td>
<td>134217728 (128MB)</td>
<td>最大受信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.core.wmem_default</td>
<td>16777216 (16MB)</td>
<td>デフォルトの送信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.core.wmem_max</td>
<td>134217728 (128MB)</td>
<td>最大送信ソケットバッファサイズ</td>
</tr>
<tr>
<td>net.ipv4.tcp_rmem</td>
<td>4096 87380 134217728</td>
<td>TCP 受信バッファ: 最小、デフォルト、最大 (最大 128MB)</td>
</tr>
<tr>
<td>net.ipv4.tcp_wmem</td>
<td>4096 65536 134217728</td>
<td>TCP 送信バッファ: 最小、デフォルト、最大 (最大 128MB)</td>
</tr>
<tr>
<td>net.ipv4.tcp_mem</td>
<td>8388608 12582912 16777216</td>
<td>TCP メモリ ページ: 低、プレッシャー、高 (64GB システム)</td>
</tr>
<tr>
<td>net.core.netdev_max_backlog</td>
<td>250000</td>
<td>入力キュー内の最大パケット数 (10GbE+)</td>
</tr>
<tr>
<td>net.core.optmem_max</td>
<td>65536 (64KB)</td>
<td>ソケットあたりの最大補助バッファ サイズ</td>
</tr>
<tr>
<td>net.ipv4.tcp_congestion_control</td>
<td>ああ</td>
<td>BBR 輻輳制御 (Google のアルゴリズム) を使用する</td>
</tr>
<tr>
<td>net.ipv4.tcp_window_scaling</td>
<td>1</td>
<td>TCP ウィンドウ スケーリングを有効にする (RFC 1323)</td>
</tr>
<tr>
<td>net.ipv4.tcp_timestamps</td>
<td>1</td>
<td>RTT 推定を改善するために TCP タイムスタンプを有効にする</td>
</tr>
<tr>
<td>net.ipv4.tcp_sack</td>
<td>1</td>
<td>選択的確認応答を有効にする</td>
</tr>
<tr>
<td>net.ipv4.tcp_no_metrics_save</td>
<td>1</td>
<td>TCP メトリクスのキャッシュを無効にする</td>
</tr>
</table>
<h3>Linux 構成アプリケーション</h3>
<p>これらの設定を<code>/etc/sysctl.conf</code>または新しいファイルを作成します<code>/etc/sysctl.d/99-network-tuning.conf</code>:</p>
<pre>
# Network Buffer Tuning for High-Performance Applications
# Optimized for 10GbE+ networks with RTT up to 300ms

# Core socket buffer settings
net.core.rmem_default = 16777216
net.core.rmem_max = 134217728
net.core.wmem_default = 16777216
net.core.wmem_max = 134217728

# TCP buffer settings
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_mem = 8388608 12582912 16777216

# Device buffer settings
net.core.netdev_max_backlog = 250000
net.core.netdev_budget = 50000
net.core.netdev_budget_usecs = 5000
net.core.optmem_max = 65536

# TCP optimizations
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1

# Apply with: sysctl -p /etc/sysctl.d/99-network-tuning.conf
</pre>
<h3>NICリングバッファのチューニング</h3>
<pre>
# Check current ring buffer sizes
ethtool -g eth0

# Set maximum ring buffer sizes (adjust based on NIC capabilities)
ethtool -G eth0 rx 4096 tx 4096

# Make persistent by adding to /etc/network/interfaces or systemd service
</pre>
<div class="warning-box">
<strong>重大な警告 - メモリ消費量:</strong>tcp_mem 値はメモリ ページ (通常は 4KB) 内にあります。バッファ サイズが大きいと、深刻なメモリ負荷が発生する可能性があります。<ul>
<li><strong>接続ごとのメモリ:</strong>各接続は最大 rmem_max + wmem_max (128MB バッファで 256MB) を使用できます。</li>
<li><strong>システム全体への影響:</strong>1,000 接続 × 256MB = 256GB の潜在的な使用量</li>
<li><strong>安全な推定:</strong>最大同時接続数 × 256MB はシステム RAM の 50% を超えてはなりません</li>
<li><strong>例：</strong>64GB サーバーでは、最大接続数を 128MB バッファーを使用した最大 125 の同時高スループット接続に制限する必要があります。</li>
<li><strong>RAM が 16GB 未満のサーバーの推奨事項:</strong>バッファを最大 16 ～ 32MB に減らし、それに比例して tcp_mem を調整します</li>
</ul>
</div>
</div>
<h2>Windowsのバッファチューニング</h2>
<div class="os-section">
<h3>従来の Windows 設定 (2009 年頃 - Windows Vista/7/Server 2008)</h3>
<table class="buffer-table">
<tr>
<th>パラメータ</th>
<th>レガシーバリュー (2009)</th>
<th>位置</th>
</tr>
<tr>
<td>Tcpウィンドウサイズ</td>
<td>65535 (64KB)</td>
<td>レジストリ: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters</td>
</tr>
<tr>
<td>Tcp1323オプト</td>
<td>0 (無効)</td>
<td>ウィンドウのスケーリングはデフォルトで無効になっています</td>
</tr>
<tr>
<td>デフォルト受信ウィンドウ</td>
<td>8192 (8KB)</td>
<td>デフォルトの受信ウィンドウ</td>
</tr>
<tr>
<td>デフォルトの送信ウィンドウ</td>
<td>8192 (8KB)</td>
<td>デフォルトの送信ウィンドウ</td>
</tr>
<tr>
<td>GlobalMaxTcpWindowSize</td>
<td>65535 (64KB)</td>
<td>最大 TCP ウィンドウ サイズ</td>
</tr>
<tr>
<td>TcpNumConnections</td>
<td>16777214</td>
<td>最大TCP接続数</td>
</tr>
</table>
<h3>現在の Windows 設定 (Windows 10/11/Server 2019-2025)</h3>
<p>最新の Windows では、<strong>受信ウィンドウの自動調整</strong>ネットワークの状況に基づいて受信バッファを動的に調整する機能。</p>
<table class="buffer-table">
<tr>
<th>特徴</th>
<th>現在の推奨設定</th>
<th>説明</th>
</tr>
<tr>
<td>オートチューニングレベル</td>
<td>通常 (または 10GbE+ については非常に実験的)</td>
<td>動的受信ウィンドウ調整</td>
</tr>
<tr>
<td>受信側スケーリング (RSS)</td>
<td>有効化</td>
<td>ネットワーク処理を CPU 全体に分散する</td>
</tr>
<tr>
<td>煙突のオフロード</td>
<td>自動 (または最新の NIC では無効)</td>
<td>NIC ハードウェアへの TCP オフロード</td>
</tr>
<tr>
<td>NetDMA</td>
<td>無効</td>
<td>ダイレクト メモリ アクセス (非推奨)</td>
</tr>
<tr>
<td>TCP グローバルパラメータ</td>
<td>以下のコマンドを参照してください</td>
<td>システム全体の TCP 設定</td>
</tr>
<tr>
<td>輻輳プロバイダー</td>
<td>CUBIC (または NewReno フォールバック)</td>
<td>TCP輻輳制御アルゴリズム</td>
</tr>
</table>
<h3>Windows 設定コマンド</h3>
<pre>
# Check current auto-tuning level
netsh interface tcp show global

# Enable auto-tuning (normal mode - default for most scenarios)
netsh interface tcp set global autotuninglevel=normal

# For high-bandwidth, high-latency networks (10GbE+, data center environments)
netsh interface tcp set global autotuninglevel=experimental

# For conservative tuning (if experimental causes issues)
netsh interface tcp set global autotuninglevel=restricted

# For very conservative tuning (not recommended for high-performance networks)
netsh interface tcp set global autotuninglevel=highlyrestricted

# Enable CUBIC congestion provider (Windows Server 2022/Windows 11+ only)
netsh interface tcp set supplemental template=Internet congestionprovider=cubic

# Note: Windows 10 and Server 2019 use Compound TCP or NewReno by default
# CUBIC is not available on these older versions

# Enable Receive-Side Scaling (RSS)
netsh interface tcp set global rss=enabled

# Set chimney offload (automatic is recommended)
netsh interface tcp set global chimney=automatic

# Disable NetDMA (recommended for modern systems)
netsh interface tcp set global netdma=disabled

# Enable Direct Cache Access (if supported)
netsh interface tcp set global dca=enabled

# Enable ECN (Explicit Congestion Notification)
netsh interface tcp set global ecncapability=enabled

# Set initial congestion window to 10 (RFC 6928)
netsh interface tcp set global initialRto=3000
</pre>
<h3>高度な NIC バッファ設定 (デバイス マネージャーまたは PowerShell 経由)</h3>
<pre>
# View current adapter settings
Get-NetAdapterAdvancedProperty -Name "Ethernet"

# Increase receive buffers (adjust based on NIC)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue 2048

# Increase transmit buffers
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue 2048

# Enable Jumbo Frames (if network supports it)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Jumbo Packet" -DisplayValue 9014

# Enable Large Send Offload (LSO)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue Enabled
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv6)" -DisplayValue Enabled
</pre>
<h3>レジストリの調整 (上級 - 慎重に使用してください)</h3>
<pre>
# These settings are typically NOT needed on Windows 10/11 due to auto-tuning
# Only modify if auto-tuning is disabled or problematic

# Registry path: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

# Maximum TCP window size (if auto-tuning disabled)
# TcpWindowSize = 16777216 (16MB) - REG_DWORD

# Enable window scaling (enabled by default on modern Windows)
# Tcp1323Opts = 3 - REG_DWORD

# Number of TCP Timed Wait Delay
# TcpTimedWaitDelay = 30 - REG_DWORD (default 240)
</pre>
<div class="warning-box">
<strong>警告：</strong>最新の Windows (10/11/Server 2019 以降) では、自動チューニングによって問題が発生しない限り、レジストリを手動で変更しないでください。一般に、自動調整アルゴリズムは静的設定よりも優れています。</div>
</div>
<h2>macOSのバッファチューニング</h2>
<div class="os-section">
<h3>従来の macOS 設定 (2009 年頃 - Mac OS X 10.5/10.6)</h3>
<table class="buffer-table">
<tr>
<th>パラメータ</th>
<th>レガシーバリュー (2009)</th>
<th>説明</th>
</tr>
<tr>
<td>kern.ipc.maxsockbuf</td>
<td>262144 (256KB)</td>
<td>ソケットバッファの最大サイズ</td>
</tr>
<tr>
<td>net.inet.tcp.sendspace</td>
<td>32768 (32KB)</td>
<td>デフォルトの TCP 送信バッファ</td>
</tr>
<tr>
<td>net.inet.tcp.recvspace</td>
<td>32768 (32KB)</td>
<td>デフォルトのTCP受信バッファ</td>
</tr>
<tr>
<td>net.inet.tcp.autorcvbufmax</td>
<td>131072 (128KB)</td>
<td>自動調整された最大受信バッファー</td>
</tr>
<tr>
<td>net.inet.tcp.autosndbufmax</td>
<td>131072 (128KB)</td>
<td>自動調整された最大送信バッファー</td>
</tr>
<tr>
<td>net.inet.tcp.rfc1323</td>
<td>0 (無効)</td>
<td>TCPウィンドウスケーリング</td>
</tr>
</table>
<h3>現在の macOS 設定 (macOS 12-15 モントレーからセコイアまで)</h3>
<table class="buffer-table">
<tr>
<th>パラメータ</th>
<th>現在の推奨値</th>
<th>説明</th>
</tr>
<tr>
<td>kern.ipc.maxsockbuf</td>
<td>8388608 (8MB)</td>
<td>ソケットバッファの最大サイズ</td>
</tr>
<tr>
<td>net.inet.tcp.sendspace</td>
<td>131072 (128KB)</td>
<td>デフォルトの TCP 送信バッファ</td>
</tr>
<tr>
<td>net.inet.tcp.recvspace</td>
<td>131072 (128KB)</td>
<td>デフォルトのTCP受信バッファ</td>
</tr>
<tr>
<td>net.inet.tcp.autorcvbufmax</td>
<td>16777216 (16MB)</td>
<td>自動調整された最大受信バッファー</td>
</tr>
<tr>
<td>net.inet.tcp.autosndbufmax</td>
<td>16777216 (16MB)</td>
<td>自動調整された最大送信バッファー</td>
</tr>
<tr>
<td>net.inet.tcp.rfc1323</td>
<td>1 (有効)</td>
<td>TCP ウィンドウ スケーリングを有効にする</td>
</tr>
<tr>
<td>net.inet.tcp.sack</td>
<td>1 (有効)</td>
<td>選択的確認応答を有効にする</td>
</tr>
<tr>
<td>net.inet.tcp.mssdflt</td>
<td>1440</td>
<td>デフォルトの TCP 最大セグメント サイズ</td>
</tr>
<tr>
<td>net.inet.tcp.layed_ack</td>
<td>3</td>
<td>遅延 ACK 動作</td>
</tr>
</table>
<h3>macOS 設定アプリケーション</h3>
<pre>
# Check current settings
sysctl kern.ipc.maxsockbuf
sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace
sysctl net.inet.tcp.autorcvbufmax
sysctl net.inet.tcp.autosndbufmax

# Apply settings temporarily (until reboot)
sudo sysctl -w kern.ipc.maxsockbuf=8388608
sudo sysctl -w net.inet.tcp.sendspace=131072
sudo sysctl -w net.inet.tcp.recvspace=131072
sudo sysctl -w net.inet.tcp.autorcvbufmax=16777216
sudo sysctl -w net.inet.tcp.autosndbufmax=16777216
sudo sysctl -w net.inet.tcp.rfc1323=1
sudo sysctl -w net.inet.tcp.sack=1

# Make settings persistent (create /etc/sysctl.conf)
sudo tee /etc/sysctl.conf &lt;&lt;EOF
kern.ipc.maxsockbuf=8388608
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.inet.tcp.autorcvbufmax=16777216
net.inet.tcp.autosndbufmax=16777216
net.inet.tcp.rfc1323=1
net.inet.tcp.sack=1
net.inet.tcp.mssdflt=1440
net.inet.tcp.delayed_ack=3
EOF

# Note: On recent macOS versions, /etc/sysctl.conf may not be read automatically
# Use a LaunchDaemon to apply settings at boot
</pre>
<h3>永続的な設定のための LaunchDaemon の作成</h3>
<pre>
# Create /Library/LaunchDaemons/com.local.sysctl.plist
sudo tee /Library/LaunchDaemons/com.local.sysctl.plist &lt;&lt;EOF
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
    &lt;key&gt;Label&lt;/key&gt;
    &lt;string&gt;com.local.sysctl&lt;/string&gt;
    &lt;key&gt;ProgramArguments&lt;/key&gt;
    &lt;array&gt;
        &lt;string&gt;/usr/sbin/sysctl&lt;/string&gt;
        &lt;string&gt;-w&lt;/string&gt;
        &lt;string&gt;kern.ipc.maxsockbuf=8388608&lt;/string&gt;
    &lt;/array&gt;
    &lt;key&gt;RunAtLoad&lt;/key&gt;
    &lt;true/&gt;
&lt;/dict&gt;
&lt;/plist&gt;
EOF

sudo chmod 644 /Library/LaunchDaemons/com.local.sysctl.plist
sudo launchctl load /Library/LaunchDaemons/com.local.sysctl.plist
</pre>
<div class="warning-box">
<strong>警告：</strong>macOS Ventura (13) 以降には、システム整合性保護 (SIP) の制限があります。一部のカーネルパラメータは、sudo を使用しても変更できない場合があります。特定の環境で設定をテストします。</div>
</div>
<h2>パフォーマンスのテストと検証</h2>
<h3>バッファのパフォーマンスをテストするためのツール</h3>
<div class="diagnostic-box">
<h4>iperf3 - ネットワークパフォーマンステスト</h4>
<pre>
# Server side
iperf3 -s

# Client side - test TCP throughput
iperf3 -c server_ip -t 60 -i 5 -w 16M

# Test with multiple parallel streams
iperf3 -c server_ip -P 10 -t 60

# Test UDP performance
iperf3 -c server_ip -u -b 1000M -t 60
</pre>
<h4>tcpdump - TCP ウィンドウ サイズのキャプチャ</h4>
<pre>
# Capture and display TCP window sizes
tcpdump -i any -n 'tcp' -vv | grep -i window

# Save capture for Wireshark analysis
tcpdump -i any -w /tmp/capture.pcap 'tcp port 443'
</pre>
<h4>Wireshark 分析</h4>
<p>バッファの問題を示す次の指標を探してください。</p>
<ul>
<li>TCP ゼロ ウィンドウ メッセージ</li>
<li>TCPウィンドウアップデートパケット</li>
<li>TCP ウィンドウの完全な通知</li>
<li>低い RTT での高い再送信率</li>
</ul>
<h4>システム監視</h4>
<pre>
# Linux - Monitor network buffer statistics
watch -n 1 'cat /proc/net/sockstat'
watch -n 1 'ss -tm | grep -i mem'

# Check for drops
netstat -s | grep -i drop

# Windows - Monitor TCP statistics
netstat -e 1

# macOS - Monitor network statistics
netstat -s -p tcp
</pre>
</div>
<h2>帯域幅遅延積 (BDP) の計算</h2>
<p>ネットワークに最適なバッファ サイズを決定するには、帯域幅と遅延の積を計算します。</p>
<pre>
BDP = Bandwidth (bits/sec) × RTT (seconds)

Example for 10 Gigabit Ethernet with 50ms RTT:
BDP = 10,000,000,000 × 0.050 = 500,000,000 bits = 62.5 MB

Buffer Size = BDP × 2 (for bidirectional traffic and headroom)
Buffer Size = 62.5 MB × 2 = 125 MB

This is why modern settings recommend 128MB maximum buffers.
</pre>
<h2>ワークロード固有の推奨事項</h2>
<table class="buffer-table">
<tr>
<th>ワークロードの種類</th>
<th>推奨されるバッファサイズ</th>
<th>主要なパラメータ</th>
</tr>
<tr>
<td>Web サーバー (低遅延)</td>
<td>4～16MB</td>
<td>バッファが少なく、接続数が多く、応答が速い</td>
</tr>
<tr>
<td>データベースサーバー</td>
<td>16～32MB</td>
<td>適度なバッファー、安定したスループット</td>
</tr>
<tr>
<td>ファイル転送・バックアップ</td>
<td>64～128MB</td>
<td>最大バッファー、高スループット優先</td>
</tr>
<tr>
<td>ビデオストリーミング</td>
<td>32～64MB</td>
<td>大規模なバッファ、安定した配信速度</td>
</tr>
<tr>
<td>HPC / データセンター</td>
<td>128～256MB</td>
<td>最大バッファ、特殊な輻輳制御</td>
</tr>
<tr>
<td>ワイヤレス / モバイル</td>
<td>2～8MB</td>
<td>保守的なバッファ、可変レイテンシの処理</td>
</tr>
</table>
<h2>よくある間違いと落とし穴</h2>
<div class="warning-box">
<h3>避けるべき間違い</h3>
<ul>
<li><strong>オーバーバッファリング:</strong>バッファーが大きすぎるとバッファーの肥大化が発生し、レイテンシが増加する可能性があります</li>
<li><strong>メモリ制約を無視する:</strong>バッファが大きいと接続数が増加します。 10,000 の接続と 128MB のバッファを持つサーバーには 1.25TB の RAM が必要です</li>
<li><strong>理由なく自動チューニングを無効にする:</strong>最新の OS の自動チューニングは通常、静的な設定よりも優れています</li>
<li><strong>変更後にテストを行わない:</strong>実際のワークロードでパフォーマンスの向上を常に検証する</li>
<li><strong>NIC バッファを忘れる:</strong>リングバッファの枯渇はソケットバッファとは独立して発生する可能性があります</li>
<li><strong>一貫性のない設定:</strong>クライアントとサーバーには互換性のあるバッファ構成が必要です</li>
<li><strong>輻輳制御を無視する:</strong>BBR と CUBIC は古いアルゴリズムよりも大幅に優れています</li>
</ul>
</div>
<h2>トラブルシューティングのワークフロー</h2>
<ol>
<li><strong>ベースラインを確立する:</strong>iperf3 または同様のツールを使用して現在のパフォーマンスを測定する</li>
<li><strong>パケットをキャプチャします。</strong>tcpdump/Wireshark を使用して TCP ウィンドウの動作を識別する</li>
<li><strong>システム統計を確認します。</strong>ドロップ、バッファの枯渇、再送信を探す</li>
<li><strong>BDP を計算します。</strong>理論的に最適なバッファ サイズを決定する</li>
<li><strong>増分変更を適用します。</strong>一度にすべてを変更しないでください</li>
<li><strong>テストと検証:</strong>実際のパフォーマンスの向上を測定する</li>
<li><strong>経時的に監視します:</strong>負荷が変動しても設定が最適に保たれるようにする</li>
</ol>
<h2>参考文献と詳細情報</h2>
<ul>
<li>RFC 1323 - 高性能のための TCP 拡張機能 (ウィンドウ スケーリング)</li>
<li>RFC 2018 - TCP 選択的確認応答オプション</li>
<li>RFC 6928 - TCP の初期ウィンドウの増加</li>
<li>RFC 8312 - CUBIC 輻輳制御アルゴリズム</li>
<li>BBR 輻輳制御 (Google) - https://research.google/pubs/pub45646/</li>
<li>Linux カーネルのドキュメント - networking/ip-sysctl.txt</li>
<li>Windows TCP/IP パフォーマンス チューニング ガイド (Microsoft)</li>
<li>ESnet ネットワーク チューニング ガイド - https://fasterdata.es.net/</li>
</ul>
<h2>結論</h2>
<p>バッファの枯渇は、ネットワーク関連と思われるパフォーマンスの問題の一般的な根本原因です。 2009 年の 128KB の制限から今日の 128MB の容量までのバッファ サイズの進化を理解することで、ネットワーク エンジニアはこれらの問題を迅速に特定して解決できます。</p>
<p>重要なポイント:</p>
<ul>
<li>最新のシステムには、従来の (2009 年) 構成よりも大幅に大きなバッファが必要です</li>
<li>特定のネットワーク条件に応じて BDP を常に計算します</li>
<li>利用可能な場合は OS 自動チューニング機能を使用します (Windows、最新の Linux)</li>
<li>変更を検証するための監視とテスト</li>
<li>チューニング時にワークロード固有の要件を考慮する</li>
</ul>
<p>覚えておいてください: TCP ゼロ ウィンドウを示すパケット分析によって明らかになった「ネットワークの問題」は、実際にはホスト システムのリソースの問題です。バッファを適切に調整すると、これらの誤った診断を排除し、最適なパフォーマンスを達成できます。</p>
<hr/>
<p><em>最終更新日: 2026 年 2 月 2 日</em></p>
<p><em>著者: Baud9600 技術チーム</em></p>