...
ウェブホスティングのロゴ

データセンターにおけるサーバーTCPウィンドウのスケーリングとスループットの最適化

サーバーTCP ウィンドウ・スケーリングは、データセンターにおける接続ごとの使用可能なスループットを決定する。受信ウィンドウを計算し、動的にスケーリングし、ターゲット・チューニングを使用してデータセンター間のボトルネックを最小化する方法を紹介します。 ウィンドウサイズ そしてレイテンシー。.

中心点

本稿では、最も重要な記述をあらかじめ要約しておく。ウィンドウ・サイズ、RTT、帯域幅-遅延積、および賢明なシステム・パラメーターに集中する。それぞれの記述は、再現可能なデータスループットという点で、直接的な利益をもたらす。参考のない理論は避け、適用可能なステップを提供します。これにより、診断から チューニング.

  • ウィンドウのスケーリング は64KBの制限を解除し、大きなウィンドウを使えるようにする。.
  • 通信事業者 とウィンドウ・サイズが最大スループット（≒ウィンドウ/RTT）を決定する。.
  • BDP は、リンクをフルに利用するために必要なウィンドウサイズを示している。.
  • バッファ また、OSスタックの自動チューニングにより、実際のパフォーマンスが向上する。.
  • マルチストリーム とプロトコル・パラメーターがデータ転送を増加させる。.

ウィンドウサイズとRTTがスループットを左右する理由

スループット≒接続あたりの上限値という単純な式で計算する。 窓/RTT。64KBのウィンドウと50msのRTTでは、光ファイバーケーブルで1Gビット/秒が可能でも、10Mビット/秒程度になる。この不一致は長距離やWANパスで特に顕著です。待ち時間が長ければ長いほど、ウィンドウが小さいと転送速度が遅くなります。そのため、未使用のままの帯域幅を購入するのではなく、十分に大きな受信ウィンドウサイズを優先しています。このようにして、実際の調整ネジは TCPスタック.

古典的なTCPウィンドウの限界

元の16ビット・ウィンドウでは、値が65,535バイトに制限されるため、以下のハード・リミットが設定される。 スループット が発生します。LAN内ではほとんど気になりませんが、大陸上ではレートが一桁から二桁前半のMビット/秒に激減します。例えば、64KBを100msのRTTで転送した場合、約5Mビット/秒にしかなりません。これではバックアップやレプリケーション、大容量ファイルの転送には不十分です。私は一貫してウィンドウ・スケーリングを適用することでこの制限を解決しています。 アクティブ化 とネゴシエーションをチェックする。.

TCPウィンドウ・スケーリングの仕組み

オプション ウィンドウスケール SYNハンドシェイク中にネゴシエートされる指数（0〜14）を使って論理ウィンドウを拡大する。有効なウィンドウは、Header-Window × 2^Scaleの結果であり、その結果、最大でギガバイトの範囲まで大きくすることができる。両方のエンドポイントがこのオプションを受け入れ、中間コンポーネントがこのオプションをフィルタリングしないことが重要である。私はWiresharkでハンドシェイクをチェックし、SYNとSYN/ACKのオプションに注意を払う。このオプションがない場合、接続は64KBにフォールバックする。 スループット すぐに限定される。.

現行システムにおける動的ウィンドウ・サイズ

最近のLinuxカーネルとWindowsサーバーは、この方式を採用している。 RWIN ダイナミックに動作し、好条件下では数メガバイトに成長する。Linuxでは net.ipv4.tcp_rmem, net.ipv4.tcp_wmem そして net.ipv4.tcp_window_scaling. .Windowsでは、次のようにチェックします。 netsh int tcp show global, 自動チューニングが有効かどうか。最大値で成長が止まってしまわないように、両サイドに十分なバッファがあるようにしている。こうして、自動スケーリングの利点を生かしている。 生産性の高いオペレーション より。

BDPを正しく見積もる窓の大きさは？

帯域幅遅延積(BDP帯域幅×RTT）がTCPウィンドウの目標値を示してくれる。私は、回線を利用するために、受信ウィンドウを少なくともこの値に設定する。十分なバッファがないと、接続は公称帯域幅から大きく遅れたままになる。次の表は、RTTと帯域幅の典型的な組み合わせと、必要なウィンドウ・サイズ、および64KBウィンドウの制限を示している。これによって、小さなウィンドウがどの程度で使用できるかが一目でわかる。 ワン-ディスタンスブレーキ。.

通信事業者 帯域幅 BDP (MBit) 最小ウィンドウ (MB) 64KBでのスループット
20ミリ秒 1Gbit/s 20 ≈ 2,5 ≈ 26 Mbit/s
50ミリ秒 1Gbit/s 50 ≈ 6,25 ≈ 10 Mbit/s
100ミリ秒 1Gbit/s 100 ≈ 12,5 ≈ 5 Mbit/s
50ミリ秒 10Gbit/s 500 ≈ 62,5 ≈ 10 Mbit/s

実践的チューニング：測定からカスタマイズまで

私は採寸から始める： ピング そして トレースルート RTTを提供する、, iperf3 入口と出口のレートを測定し ワイヤーシャーク 交渉成立 スケーリング をハンドシェイクに追加する。トレースのウィンドウが64KBのままなら、フィルターをかけたりオプションを変更したりするデバイスを探す。ファイアウォール、VPNゲートウェイ、ロードバランサーのRFC1323準拠をチェックする。ネゴシエーションが適切であれば、OSのバッファーの上限と自動チューニングの上限をチェックする。また、輻輳制御アルゴリズムの選択も評価します。損失や遅延に対する反応が実際のものと同じだからです。 スループット 詳細は記事にまとめてある。 TCP輻輳制御 一緒にね。

受信バッファと送信バッファを適切に選択する

私はバッファーのサイズを決めるのに、自分の体の大きさを基準にしている。 BDP で、最大値を気前よく、しかしコントロールされた方法で設定する。Linuxでは net.ipv4.tcp_rmem そして net.ipv4.tcp_wmem (それぞれ最小/デフォルト/最大）、長距離用にマージンをとっておく。Windowsでは、オートチューニングのレベルをチェックし、TCPスタックの変化を記録しています。重要: より大きなバッファはRAMを必要とするので、私は高負荷の接続の数とタイプを評価します。正しいバッファーの選択に関する背景や例については、以下の記事で詳しく説明しています。 ソケット・バッファ・チューニング, これは、バッファ、RWIN、レイテンシの関係を具体化するものである。.

並列化：複数のTCPストリームの的を絞った利用

大きなウインドウがあっても、いくつかのウインドウを使った方が、練習の成果が上がることが多い。 ストリーム を並行して実行する。多くのバックアップツール、ダウンローダー、シンクソリューションは、デフォルトですでにこれを実行している。並列化によって、ミドルボックスの接続ごとの制限を回避し、個々のフローの変動をスムーズにすることができる。ファイルやブロックによって転送をセグメント化し、適切な同時実行値を定義します。これによってリスクを分散し、さらにパーセンテージを稼ぐことができる。 帯域幅 アウト。

プロトコルとアプリケーション・レベルの微調整

すべてのソフトウェアが大容量を使用するわけではない。 ウィンドウズ 追加の確認や小さなブロックサイズはデータ転送を遅くするので、効率的です。私はブロックサイズを大きくし、パイプラインを有効にし、アプリケーションがこれを提供するならば、並列リクエストをセットアップします。最新のSMBバージョン、最新のHTTPスタック、最適化されたバックアップ・エンジンは、これによって大きな恩恵を受ける。また、TLSオフロード、MSSクランピング、ジャンボフレームも、チェーン全体が適切にサポートしていればチェックする。これらの調整により、ウィンドウのスケーリングが補完され、実質的な スループット で。

オートチューニングを理解する限界、ヒューリスティック、賢明なデフォルト

オートチューニングは確実に成功するわけではない。Linuxでは tcp_rmem/tcp_wmem とりわけ net.core.rmem_max そして net.core.wmem_max はソケットごとの上限値である。の高いWAN転送には64-256MBのような値を推奨する。 BDP-条件は共通している。私は活動する net.ipv4.tcp_moderate_rcvbuf=1, カーネルが徐々にレシーブ・ウィンドウを起動するようにし、次のようにチェックする。 net.ipv4.tcp_adv_win_scale, これは、空きバッファをどの程度積極的にウィンドウサイズに変換するかを決定する。. tcp_timestamps そして サック 再送信のターゲットになり、大きなウインドウでは欠かせないからだ。.

Windowsでは、次のような動作が見られます。 netsh int tcp show global そして netsh int tcp show heuristics. .私は通常、車のチューニングレベルを 通常 また、„低速リンク “と認識されたパスのウィンドウの成長を不必要に減速させるヒューリスティックを無効にする。どちらの世界でも重要だ：どちらの世界でも重要である。 SO_RCVBUF/SO_SNDBUF は、自動チューニングを効果的に遅らせることができる。そのため私は、サーバープロセス（プロキシや転送デーモンなど）にそのようなオーバーライドがないかチェックし、それに応じて調整するようにしている。.

トレース分析：ハンドシェイクとデータフローでチェックすること

Wiresharkでは、SYN/SYN-ACKの横を検証する。 ウィンドウスケール 併せて サック可, タイムスタンプ そして、その MSS. .データフローでは、„Bytes in flight“、„TCP Window Size value“、„Calculated Window Size “を見る。もし計算されたウィンドウが リーム フラット、ブロック制限、またはアプリケーションが アプリケーション限定. .また、TCPストリームのグラフ（タイムシーケンス、ウィンドウのスケーリング）を使って、ウィンドウが動的に成長するかどうか、再送や順序外のパケットが効果を打ち消すかどうかを確認する。.

MTU、MSS、ジャンボフレーム：それらが本当にもたらすもの

大きなウィンドウが効果を発揮するのは、パイプラインが効率的に満たされている場合だけだ。従って、私はパスに沿って実効MTUをチェックする。以下のように IPリンク そして エスツール 私は地域の限界を認識している。 ping -M do -s Path-MTUをテストする。PMTUDが失敗したら、Linuxでアクティベートする。 net.ipv4.tcp_mtu_probing=1 またはエッジ・デバイスに賢明な MSS クランピングを設定し、フラグメンテーションを回避する。ジャンボ・フレーム（9000）は、均質に構成されたファブリック内では価値があり、CPU負荷を軽減し、次のような効果があります。 グッド・プット. .対照的に、私はヘテロジニアスやWANパスセグメントを経由した生のMTU増加よりも、クリーンなPMTUDと一貫したMSS値を優先する。.

損失、ECN、キュー管理

ウィンドウが大きいと、小さなパケットロス率でも実際のスループットを大幅に低下させるのに十分です。そこで私は、ECNがサポートされているかどうか、パス上でクリアされていないかどうかを積極的にチェックし、エッジ・インターフェース上のAQM（FQ-CoDelなど）と組み合わせている。これにより 待ち行列遅延 そして、ウィンドウを人為的に小さくすることなく、バッファブロートを防ぐことができる。Linuxでは、RACK/TLPのような最新のロスディテクタが、より速くテイルを閉じるのに役立っている。頻繁にバーストが発生する環境では、ペーシングが可能な輻輳制御（バイトキュー制限を持つCUBICやBBRなど）に頼るが、それでも受信ウィンドウが十分に大きいことを確認する。.

サーバーとアプリケーションの表示：ソケットオプションを意識的に使う

多くのサーバープロセスは、バッファサイズをハードに設定し、その結果、成長を制限している。私は、開始値とピーク値を明示的に ss (Linux)を観察する スケム/rcv_space. .アプリケーション・レベルでは、ブロック・サイズとレコード・サイズを調整し、ナグル(TCP_NODELAY)は、スループットよりもメッセージあたりのレイテンシが重要な場合にのみ使用し、より大きな送信ユニットを使用することで遅延ACKの影響を軽減します。ファイル転送には sendfile() またはゼロコピー・メカニズムや非同期I/Oにより、ユーザー空間がボトルネックにならないようにする。.

10/25/40/100Gへのスケーリング：CPU、オフロード、マルチキュー

大きなウィンドウはホストを必要とする。TSO/GSOとGRO/LROがアクティブであることを確認し、システムがラージセグメントを効率的に処理できるようにしている。RSS/Multiqueueを使って複数のコアにフローを分散させ、IRQアフィニティーをNUMAトポロジーに適応させ、SoftIRQの負荷をモニターします。デバイス側では、ホストが割り込みの嵐に遭遇しないように、リングバッファと割り込み合体を調整します。これらすべてにより、CPUの限界によってウィンドウ・スケーリングが失敗することがなく、達成されたレートが再現可能なままであることが保証される。.

ステップバイステップのパス：目標レートからコンフィギュレーションまで

  • 目標の定義：希望するスループットと測定されたRTT（例：40msで5Gbit/s）。.
  • BDP 計算：5Gbit/s×0.04秒＝200Mbit≒25MBのウィンドウ。.
  • Linuxの制限を設定する： sysctl -w net.core.rmem_max=268435456, net.core.wmem_max=268435456, net.ipv4.tcp_rmem="4096 87380 268435456", net.ipv4.tcp_wmem="4096 65536 268435456", net.ipv4.tcp_moderate_rcvbuf=1.
  • ウィンドウズをチェックする： netsh int tcp show global; カー・チューニング 通常, スロットル・ヒューリスティックではない。.
  • ハンドシェイクの検証：Wireshark - Window Scale、MSS、SACK/Timestampsが利用可能。.
  • セキュアMTU/MSS：PMTUD機能またはパスに沿ったMSSキャンプ。.
  • 輻輳制御とAQMを設定：プロファイルに合致するCUBIC/BBR、エッジで有効なECN/AQM。.
  • と一緒に iperf3 を検証する：シングルおよびマルチストリーム(-P)、TLS/アプリケーションの有無にかかわらず。.
  • アプリケーション・バッファのチェック：小さいものはない SO_RCVBUF/SO_SNDBUF セット、ブロックサイズを増やす。.

典型的な落とし穴と簡単なチェック

ファイアウォールやルーターで、次のようなものがよくある。 オプション をTCPヘッダーに含めるか、破棄する。非対称パスは、アウトバウンドパスとリターンパスが異なるポリシーを通るため、問題を悪化させる。アクセスルーターでの積極的なTCP正規化も、正しいネゴシエーションを破壊する。バッファとタイムアウトが厳しすぎると、ロスが発生した場合の回復フェーズが長くなる。私は、分離されたウィンドウで変更をテストし、再送信を観察し、段階的に調整することで、TCPのネゴシエーションが正しく行われるようにしている。 安定性 は保存される。

ホスティングとデータセンターの背景

生産的なセットアップでは、多くのクライアントが同じものを共有する。 インフラストラクチャー, コネクションあたりの効率的な利用が重要です。リーフスパイントポロジ、短い東西パス、十分なアップリンクから恩恵を受けています。最新の輻輳制御アルゴリズム、クリーンなキュー管理、ロバストなQoSルールにより、結果は再現可能です。ピーク時の負荷と並列セッションを考慮して、ウィンドウサイズとバッファを計画しています。これにより、パフォーマンスを一定に保ち、以下の影響を最小限に抑えることができます。 ウィンドウのスケーリング はすべてのサービスに到着する。.

モニタリングと継続的な最適化

で定期的に測定している。 iperf3 ロケーション間のRTT、ジッター、再送信を追跡する。 グッド・プット. .フローデータとsFlow/NetFlowは、トラフィックのパターンを適時に認識するのに役立つ。異常値の場合、私はパケットロスをチェックする。低いレートでもスループットは著しく低下するからだ。 パケット損失の分析 一緒に私は時系列ダッシュボードを操作し、トレンドの切れ目がすぐにわかるようにしている。これは、私のチューニングが効果的であり続け、パスやポリシー、負荷プロファイルの変更が起こる前に対応できることを意味します。 ユーザー それを感じてほしい。.

実践から簡単にまとめると

大きな窓 ウィンドウのスケーリング, 適切なバッファと適切にネゴシエートされたハンドシェイクによって、レバーは適切な場所に置かれる。私はBDPを計算し、実際のRTTを測定し、オートチューニングが成長できるように最大値を設定します。その後、プロトコル・パラメーターをチェックし、必要であれば並列化を使用する。スループットが期待値を下回る場合は、オプションをフィルタリングし、キューの挙動を含む輻輳制御を最適化するミドルボックスを特に探します。これが、私が利用可能な 帯域幅 長旅でも、実際のボトルネックを解決しない高価なハードウェアのアップグレードをしなくて済む。.

現在の記事