ホームNASリンクのプロトコルオーバーヘッドはどれくらいの実効スループットを消費しますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Much Usable Throughput Does Protocol Overhead Take From a Home NAS Link? - Zima Store Online

プロトコルオーバーヘッドは通常、SMBやアプリケーションの動作を考慮する前に、よく満たされた有線NASリンクの数パーセントを削減します。標準的な1500バイトMTUでは、IPv4上のTCPは各IPパケット内に1460バイトのアプリケーションペイロードを運びますが、イーサネットのフレーミング、プリアンブル、およびフレーム間ギャップは追加の物理層時間を消費します。

この計算は大きくてクリーンな転送に対する理論上の効率上限に過ぎません。小さなファイル、部分パケット、確認応答、SMBメッセージ、暗号化、遅延、再送、ストレージ待ち、クライアントの動作は実際のグッドプットをさらに大きく減少させる可能性があります。

ラインレートとグッドプットの違いは何ですか？

ラインレートはインターフェースがビットを信号化する速度を示し、グッドプットは実際に届けられたアプリケーションデータのみをカウントします。ヘッダー、確認応答、再送、制御メッセージは実際のトラフィックですが、完了したユーザーファイルに追加されるバイトではありません。

したがって、1GbEポートはファイルペイロードを125 MB/sで無限に送信できるわけではありません。この数値は、1秒あたり10億ビットの信号をバイトに変換したもので、フレーミングやプロトコル処理は差し引かれていません。

グッドプットは転送完了後のアプリケーションで測定すべきです。インターフェースカウンターはより広範なトラフィックを測定し、再送やアプリケーションがまだ確定していないデータを含むことがあります。

イーサネット、IP、およびTCPヘッダーはどれだけ削減するのか？

オプションなしの標準的なIPv4上のTCPの場合、TCPおよびIPヘッダーはペイロード効率を低下させます。40バイトのTCP/IPオーバーヘッドは、イーサネットの物理層オーバーヘッドを含まないIP MTUの約2.7％に相当します。

イーサネットの物理層レベルでは、フルサイズのフレームは14バイトのヘッダー、4バイトのFCS、8バイトのプリアンブルとスタートデリミタ、12バイトのフレーム間ギャップも使用します。したがって、1460バイトのTCPペイロードは、単純なタグなしイーサネット経路で約1538バイトタイムを占有します。

その比率は約94.9％のペイロード効率です。したがって、SMB、ストレージ、確認応答、および実装の制限を考慮する前の理論上の上限は、1GbEで約949 Mbps、2.5GbEで2.37 Gbps、10GbEで9.49 Gbpsとなります。

なぜペイロードサイズが損失率に影響するのか？

ほとんどのヘッダーはパケットごとに固定サイズなので、大きなペイロードは固定フレームオーバーヘッドを分散します。完全な1500バイトのパケットは、数百バイトしか運ばないパケットよりもはるかに効率的です。

したがって、小さな同期リクエストはフレーミング、リクエスト、レスポンス、確認応答にワイヤー時間の大きな割合を費やすことがあります。ファイル数とアプリケーションの往復回数は、総ペイロードバイト数が控えめでも重要です。

ジャンボフレームは比率をさらに改善しますが、最大の数学的利得は多くのストレージボトルネックよりも小さいです。また、経路上のすべてのデバイスと仮想レイヤーで一貫したMTUサポートが必要です。

SMBはTCPの上でどのような追加作業を行うのでしょうか？

SMBはメッセージヘッダー、リクエストとレスポンスの意味論、クレジット、認証状態、署名や暗号化、ファイル操作の往復を追加します。小さなファイルはアプリケーションとプロトコルのセットアップを繰り返します。

大きなパイプライン化された読み書きでは、SMBのオーバーヘッドはかなりのペイロードと複数の未処理リクエストに分散されます。小さなファイルやメタデータ操作では、オープン、クエリ、権限、クローズ、ディレクトリメッセージが経過時間の大きな割合を占めます。

署名や暗号化もCPUとメモリ帯域を消費しますが、必ずしも多くのワイヤーバイトを追加するわけではありません。したがって、プロトコルのオーバーヘッドにはヘッダーサイズだけでなく処理コストも含まれます。

なぜ実際の転送はヘッダー計算よりも多くの損失を出すのでしょうか？

ヘッダーの計算は、完全なペイロード、損失なし、十分なウィンドウ、およびパケットを十分に速く処理するエンドポイントを前提としています。レイテンシと損失はヘッダーバイトを超えたコストを生み出します。

パケットロスは再送信や輻輳制御の減少を引き起こします。レイテンシは送信者がフィードバックを受け取る速さを制限します。小さなTCPウィンドウ、十分に埋まっていないキュー、ストレージの一時停止、または1つの忙しいCPUコアがあると、理論上のフレーミング効率が高くても回線がアイドル状態になることがあります。

ファイルマネージャーはバッファリングされた単一ストリームのコピーを実行することもありますが、ベンチマークは複数のワーカーやメモリバッファを使用します。これらのツールの違いはプロトコルヘッダーだけでなく、アプリケーションの動作にあります。

家庭用NASは実際のスループットをどのように見積もるべきですか？

ジャンボフレームは検証済みの経路でのみオーバーヘッドを削減します。標準MTUのワイヤー効率上限から始め、普遍的な割合を適用するのではなく、測定したエンドポイントとワークロードの制限を差し引いてください。

ネットワークのみのテストでTCPグッドプットを確立し、その後大きなファイルのNASコピー、小さなファイルのワークロード、実際のアプリケーションを実行してください。ラインレート、アプリケーションバイト数、CPU、ストレージ遅延、再送、パケットサイズ、署名や暗号化の有無を記録します。

リンクレートの10～15％程度の計画余裕は大きな転送のスケジューリングに合理的ですが、プロトコルの定数ではありません。適切に調整された健全なLANはワイヤー効率の上限に近づくことがありますが、小さなファイルや制約のあるエンドポイントでははるかに多く失うことがあります。

レイヤーまたは条件	消費するもの	グッドプットへの影響
イーサネット + IP + TCP	ヘッダー、プリアンブル、FCS、フレーム間ギャップ	標準フレーム全体で数パーセント
SMB	コマンド、クレジット、認証、署名、暗号化	大きなパイプラインI/Oでは小さく、メタデータが多い作業では大きい
小さいまたは部分的なペイロード	固定オーバーヘッドが少ないバイト数に繰り返される	パケットおよびファイルごとの効率低下
損失、遅延、エンドポイントの停止	再送、待機、送信速度の低下、アイドルワイヤー時間	ヘッダーのみの損失を大幅に超えることがある

よくある質問

1GbEの理論上のTCPペイロード上限は何ですか？

1500バイトのTCP/IPv4パケットと単純なイーサネットのワイヤー計算では、SMBやエンドポイントの制限前で約949Mbpsです。

SMBは常に10％または15％のコストがかかりますか？

いいえ。影響はリクエストサイズ、ファイル数、署名、暗号化、同時実行数、CPU、ストレージ、クライアントの実装に依存します。

ジャンボフレームで全てのプロトコルオーバーヘッドは回復しますか？

いいえ。パケットごとのフレーミングと処理頻度は減らせますが、SMBの操作、確認応答、ストレージ待機、アプリケーションの動作は除去できません。

なぜ10GbE NASのコピー速度が9.49Gbpsを下回ることがあるのですか？

ストレージアレイ、クライアントディスク、CPU、PCIe経路、SMB設定、キュー深度、パケット損失、コピー用ツールが、ワイヤー効率より先に制限要因になることがあります。

最終的な結論

プロトコルのオーバーヘッドにより、固定イーサネット、IP、TCP、SMBの処理がラインレートを低いグッドプットに変換します。標準フレーム全体では、ワイヤーレートの約95％をTCPペイロードとして保持できますが、実際のNAS転送ではファイル操作、セキュリティ、フィードバック、損失、遅延、エンドポイントの停止も負担します。まずヘッダーの上限を計算し、次にワークロード固有のギャップを測定してください。