サーバーと仮想マシン

TCP Small Queues：Linuxネットワークにおける遅延を的確に低減する

TCP Small Queues は、TCP フローごとに Linux の送信パスにおける保留中のバイト数を制限し、それによって レイテンシー バッファブロートも含めて、意図的に低減します。この仕組みが Linux ネットワーク Stackは、私がどのように合理的な制限を設定しているか、また、ペーシング、QDisc、および輻輳制御とどのような相互作用が生じるかを明らかにする。.

中心点

パー・フロー・リミット: TSQ は、TCP ソケットごとに未送信のバイト数を制限します。.
バッファブロートの軽減: 待ち行列が短くなると、RTTが低下します。.
背圧: 制限が適用されると、アプリケーションの書き込み速度が低下します。.
公平性: 単一のフローがキュー全体を占有することはありません。.
適応型 制御：リミットはレートとセグメントサイズに基づいて決定されます。.

TCP Small Queuesの仕組み

TSQは、TCPセグメントが QDisc およびドライバに渡されます。ソケットにデータを書き込む際、カーネルはエンキューを行うたびに、そのフローに対してすでに割り当てられているバイト数を確認します。フローが制限に達すると、ロジックはソケットを「スロットリング中」とマークし、それ以上のエンキューを停止します。ネットワークカードがバッファを解放して初めて、ソケットは再び送信が可能になり、私は再びデータをスタックにプッシュできるようになります。この厳格なバックプレッシャーによって、 キュー 簡潔であり、応答時間を予測しやすくする。.

長い待ち行列が応答時間を悪化させる理由

大規模なドライバ・キューおよびQDiscキューを作成する バッファブロート, 、特にTSO/GSOや送信量が多い場合です。大容量のダウンロードが行われると、送信キューが埋まってしまい、SSH、API呼び出し、VoIPなどの対話型フローが後回しにされてしまいます。その結果、膨れ上がったキューが 通信事業者 実際のリンク時間ではなく。ACKの到着が遅れるため、輻輳制御の反応は鈍くなり、cwndの決定精度が低下する。TSQは、フローごとにプリバッファされるバイト数を制限することで、サイズが小さく時間的制約のあるパケットが迅速に回線に送信されるようにする。.

内部を覗いてみよう：カーネルが果たす役割

内部的には、カーネルは「パケット」ではなくバイト、より正確には、ソケットによってすでにキューに入れられているメモリバイトをカウントします。重要なのは、スタックが保持するskbuff構造体と、それに付随する truesize 割り当て済みであり、まだNICによって処理されていないもの。TSQはこれに スロットル／スロットル解除-パス：ソケットがクレジットに達すると、スタックはスロットリングフラグを設定し、TXが完了（NAPI/IRQ）するまで呼び出しを再開しない write_space() アプリケーションが再送信できるようにするためです。このフィードバックは、輻輳制御による純粋な損失ベースの信号よりも高速であり、QDiscよりも先に作用します。TSO/GSOでは、制限が曩にセグメンテーションに基づくバイト予算を適用する：大きなスーパーフレームは、十分なクレジットが残っている場合にのみQDiscに受け入れられ、これによりバーストが抑制される。.

動的リミットとペーシング

TSQの恩恵を受けているのは、制限が単に固定されたままではなく、 レート およびセグメントサイズに注意を払います。目標は、100 Mbit、1 Gbit、10 Gbitのいずれの場合でも、フローごとの送信経路におけるデータ処理時間を約1ミリ秒に抑えることです。回線速度が速い場合は許容バイトクレジットが増加し、遅い場合は減少します。TCPペーシングと組み合わせることで、バーストは小さく抑えられ、ACKの返信も早くなります。これにより、顕著な低遅延を実現できます。 遅延ピーク, 、スループットを不必要に低下させることなく。.

ソケットごとのやり取りとアプリとの連携

TSQは、アプリケーション側でも背圧を感じられる場合にのみその効果を発揮します。そのため、私は次のような設定を考慮しています。 SO_SNDBUF, TCP_NOTSENT_LOWAT およびオートコーキング。送信バッファウィンドウが大きすぎると、一時的に大量のバイトがスタックに押し込まれることがある。TSQは速度を落とすものの、アプリがそれに気づくのは、 send() ブロックされるか、EAGAIN が返される。 TCP_NOTSENT_LOWAT ユーザーランドで「未送信」の分を取り出し、それを使ってカーネル側のTSQを補完します。オートコーキング（あるいは明示的に TCP_CORK/MSG_MORE) は、レイテンシの急上昇を引き起こすことなく、小さな書き込みをまとめて処理するのに役立ちます。ソケットごとのペーシング制限（例： SO_MAX_PACING_RATE) は TSQ と調和しています。レートは時間軸上で平滑化され、バイト制限は空間軸上で制限を設けます。重要： TCP_NODELAY Nagleを無効化することでインタラクティブ性を高めることができますが、TSQがないとバーストリスクが高まります。TSQを使えば、その両方をうまくコントロールできます。.

実践ガイド：適切なTSQ値

全体的な枠組みについては、次のように定めています。 net.ipv4.tcp_limit_output_bytes (Sysctl)。一般的なデフォルト値は、フローあたり128～262 KB程度です。多くのWebおよびAPIワークロードでは、対話型の応答がスムーズになるよう、より低い値を設定しています。バックアップやレプリケーションの場合は、RTTが安定している限り、この制限値を適度に引き上げます。キューに関する詳細を知りたい方は、以下の基本情報をご覧ください。サーバー内のパケットキュー, 、分類の参考になるものです。.

シナリオ	リンクレート	tcp_limit_output_bytes の目安	ゴール
API/HTTP 非常にインタラクティブ	100 Mbit – 1 Gbit	64～128 KB	低い通信事業者, 短いスパイク
Webとダウンロードの混合トラフィック	1～10 Gbit	128～256 KB	バランスをオフにするスループットおよびレイテンシ
レプリケーション／バックアップ	1～10 Gbit	256～512 KB	一定のバルク流量、許容範囲内のレイテンシー
RTTの長いWAN	10～100 Mbit	96～192 KB	より短いバースト、より公平なキュー

QDiscと輻輳制御の連携

TSQは、入口で QDisc, 、一方、fq_codel のようなアルゴリズムが回線の輻輳を管理します。これらが連携して待ち行列を短縮し、公平な帯域幅の割り当てを維持します。 TCP BBR さらに、より現実的なRTT測定値により、ペーシングやcwnd制御が改善されるというメリットもあります。また、過度なキューイング時間を排除すると、CUBICの動作もよりスムーズになります。こうして、スループットは有機的に向上し、一方で 応答時間 制御下に留まる。.

仮想化とクラウド・スタック

VM内では、ゲストQDisc、virtio/vhostキュー、ホストQDisc、そして物理NICといった複数のバッファ段階が重なり合っています。私はゲスト側でTSQを有効にし、ホスト側に大きなバーストが流入しないよう、そこで控えめな制限値を設定しています。ハイパーバイザー側では、フェアなQDisc、適度なTXリング、そして適切なIRQピンニングによって、レイテンシチェーンを短くしています。SR-IOVはレイテンシを低減できますが、その責任をゲストに移すことになります。ゲスト側でTSQを有効にしないと、VFキューが長くなる恐れがあります。コンテナ内では、TSQは1つにつき NetNS いつものように、cgroupのペーシングとCPUリミットを設定することで、騒がしい隣人が間接的にレイテンシを上昇させるのを防いでいます。また、virtioパスにおけるコアリセシングとオフロードにも注目することが重要です。過度な束ねはACKの送信時間を延長し、束ねが少なすぎると効率が低下します。私は、教条的にではなく、レイテンシの目標値に合わせて調整を行っています。.

Wi-Fiと組み込みシステム：特殊なケースへの適切な対応

Wi-Fi接続では、重要なのは アグリゲーション MAC層において。送信パスに割り当てるバイト数が少なすぎると、ドライバが束ねられるフレーム数が減り、効率が低下します。このような設定では、制限値を慎重に増やし、集約度を確認します。また、OpenWrt や組み込みプラットフォームでは、ドライバ内のパスをスリム化し、アトミック操作を最小限に抑えることで、さらなるメリットが得られます。私は、各調整について、実際の無線負荷下でテストを行った上で、 プロフィール 広く展開する。.

本当に重要なモニタリングと測定基準

を観察する。 通信事業者ソケットごとの分布を確認し、平均値だけでなく外れ値にも注目する。ss、tc、およびエクスポーターを使用して、キューの長さ、再送信回数、pacing_rateを読み取る。eBPFプログラムは、ソケットがスロットリングされたり、再び解放されたりした際にイベントを送信してくれる。 Time-to-First-Byteおよび95パーセンタイル、99パーセンタイルは、TSQが効果を発揮しているかどうかを示します。測定値がなければ、いかなる 最適化 目隠し飛行。.

信頼性の高いA/Bテストおよび負荷テスト

TSQの影響を再現性を持って測定しています。まず変更を加えないベースラインを測定し、次に個別のパラメータスイープ（例：64、96、128、192 KB）を行います。混合ワークロードについては、並列ストリーム（バルク＋多数の短いリクエスト）を実行し、レイテンシの中央値だけでなく、95パーセンタイルおよび99パーセンタイルを比較しています。テスト実行を明確に区切っても（ウォームアップ、測定ウィンドウ、クールダウン）、アーティファクトは認識可能です。定数（同じペイロードパターン、同一のルート／MTU、同一のサーバーおよびクライアントのCPU周波数）に注意を払っています。 WAN回線では、遅延・ジッター・パケットロスを以下のようにシミュレートします。 tc netem, 、BDPが高い場合にTSQリミットが早すぎる段階で上限に達していないかを確認するためです。パーセンタイルの幅が狭まり、再送信やパケットロスが安定してから初めて、その値を本番環境に反映します。.

ハードウェアのチューニングとドライバの詳細

TSO/GSOの設定、NICのリングバッファ、およびIRQ制御を確認し、次のことを確実にするために TSQ 適切に機能する。TXリングが大きすぎるとデバイスでの待ち行列が長くなり、小さすぎると利用率が低下する。割り込みの束ね方が粗すぎるとACKの遅延が生じ、きめ細かく束ねすぎるとCPU負荷が増加する。実務に即して調整を行い、入門編として以下を参照する。割り込み合体. 目標は、信頼性の高い レイテンシー 十分な処理能力を確保しつつ。.

NUMA、RSS、およびCPUアフィニティ

パッケージが絶えずNUMA境界を越えて移動している状況では、待ち行列が短くてもあまり意味がありません。私はRSS/irqbalanceを使用して、RX/TXキューを、アプリケーションが実行されているのと同じNUMAドメイン内のコアにバインドしています。 XPS/RPS を使用して、どの CPU が TX 処理を担当するかを制御し、クロスソケットホッパーを回避します。キャッシュミスやロック競合の減少は、間接的に TSQ に寄与します。完了通知がより早く戻り、ソケットの「スロットリング」が早期に解除され、レイテンシの急上昇も発生しなくなります。ホストあたりのフロー数が非常に多い場合は、十分な数のキューを確保し、複数の高負荷なフローが同じTXリング上で競合することを回避します。.

ステップバイステップ：TSQの動作確認

私はまず、次のように考えている。 Sysctl: sysctl net.ipv4.tcp_limit_output_bytes を実行すると、現在の制限値が表示されます。その後、個々のソケットについて ss -tin を実行し、send-q と rtt に注目しながら、制限値の調整前後の負荷状態を比較します。 iperf3 を使用してバックグラウンド負荷を生成し、並行して API の応答時間を測定することで、優先順位を可視化します。tc -s qdisc を実行すると、送信ディシプリンのパケット数とドロップ数が得られます。95パーセンタイルと99パーセンタイルの差が狭く、かつ CPU‑フレーム内の負荷に応じて、制限値の選択を調整します。.

よくある誤解とアンチパターン

„「バッファが大きければ大きいほどパフォーマンスが向上する」：これは、レイテンシの目標値が設定されていないスループットテストでは当てはまりますが、インタラクティブなサービスでは通用しません。TSQは、過剰に大きなキューの代わりに、フローごとの需要に応じたクレジットを採用しています。.
„「TSQはスループットを犠牲にする」：正しく設定すれば、TSQはバーストを制限し、平均レートは制限しません。バルクワークロードでは、制限値を適度に高く設定し、ピークMBit/sだけでなくパーセンタイルも測定しています。.
„「ペーシングだけで十分」：時間的な平滑化は重要だが、バイト上限を設定しなければ、大きなGSOフレームがQDiscに滑り込んでしまう。TSQとペーシングは互いに補完し合う。.
„「すべてに共通の値」：ワークロード、リンク、NICはそれぞれ異なります。私は範囲値を用いて、環境ごとに検証を行っています。.
„「TCPのみが対象」：焦点はTCPですが、システム内には他にも調整可能な要素（UDP負荷など）が存在します。私は、並行するプロトコルが制御不能な状態で同じキューを詰まらせるのを防ぎます。.

結論：レイテンシーを的確に制御

TSQは、ドライバ・キューの制御を ソケット これにより、輻輳をその発生源で直接軽減します。フローごとにプリバッファされるバイト数を制限することで、迅速なACK応答、RTTの短縮、そしてキューの公平な割り当てを実現します。fq_codelや最新の輻輳制御と組み合わせることで、負荷がかかっている状況下でも応答時間は安定して維持されます。 Wi-Fiや組み込みシステムといった特殊なケースについては、実環境下でのテストを通じて、それぞれに適した制限値を設定しています。主要指標を監視し、制限値を段階的に調整することで、 レイテンシー 一貫して低水準を維持しつつ、不必要なスループットを犠牲にすることなく。.