SpeedGuide.net :: TCP Optimizer / Downloads
上記からTCPOptimizer4をダウンロードしてください。
SG TCP Optimizerは、Windows向けの無料ネットワーク最適化ツールです。特にインターネット接続の速度や安定性を向上させるための設定調整に特化しています。主な機能は以下の通りです。

SG TCP Optimizerの主な機能

1. MTU (Maximum Transmission Unit) の最適化

   • パケットサイズの最適値を自動計算して、通信効率を向上させます。

2. RWIN (TCP Receive Window) の調整

   • 受信ウィンドウのサイズを最適化し、通信速度を向上させることができます。

3. TCP/IPパラメータのカスタマイズ

   • Windowsの隠れたネットワーク設定を調整し、遅延やラグを軽減します。

4. レイテンシー最適化

   • オンラインゲームやリアルタイム通信向けに遅延を抑える設定が可能です。

ダウンロードしたファイルは右クリック→管理者として実行で使用してください。ファイルが保存されません。

注目すべきはCongestion　control provierです。最近のPC初期値はCubicかと思います。俺はCTCPに変更設定していますし、このソフトを解説している方の大多数は同じ答えだと思います。ただ状況によっては異なる場合があります（家でオンラインゲームする人なら99パーセントCTCPになるｗ）

昔のPCのデフォルトはCTCPだったのに今はCUBICに変更されています。
変更に至る流れと根拠はクロスプラットフォームの優位性（CubicはLinuxだけでなくWindowsやmacOSでもサポートされ、標準化が進んだことで相互運用性が向上したから）

インターネット環境の変化（モバイル回線やWi-Fiなど、不安定なネットワーク環境が一般的になり、Cubicのようにパケットロス耐性が高いアルゴリズムが求められるようになった）CUBICは特に遅延やジッター (遅延の揺らぎ) がある環境では、安定した性能を発揮するため。

標準化の流れ（CubicはIETF (Internet Engineering Task Force) によるRFC 8312で標準化され、業界全体での採用が加速）

この時代の波により、CTCPは安定した回線で優秀でしたが、モバイル回線や混雑したネットワーク環境が増えた現代では、Cubicの方がより柔軟かつ効率的であり、標準化の流れに乗って移行が進んだのです。

CTCP vs CUBIC – ゲーミングネットワーク設定の最適解

オンラインゲームのように実況データを快速に受け取ることが重要な場合、TCPの設定は影響力が大きく、特にCTCPとCUBICの利用が議論の点となっています。

【CTCP (Compound TCP)】

Microsoftによって開発されたアルゴリズムで、Windows Vista以降のOSで提供されています。

メリット

• 高度に人気の四段階段作戦中の設計によって、近代的な四階階接続のネットワークに最適化されている

• 低レイテンシーを実現し、パケットロスの問題が少ない

• 高速ブロードバンドを有効利用することで大量のデータを出入りするシチュエーションで優秀

デメリット

• ローレーン回線や低容量回線では、準備時間が長くなる場合がある

• 設定を誤ると逆効果となり、突発的な速度下降が発生することがある

【CUBIC】

Linux主体で使われるアルゴリズムで、特に以上の回線速度が要求される情報に適しています。

メリット

• ハイレーテンシー回線でのレイテンシーを削減

• 固定レートでの急強な準備が得意なため、ゲーミングデータの受信に有利

• アクセス困難時のパケットロスを接続再開の中で回復させる機能が優れている

デメリット

• 低レイテンシーでは実務的な負荷が高くなるため、小規模な回線では不向き

• ゲームサーバー側がCTCPほど有効なアルゴリズムでない場合、体感的に不快かも

【どっちがゲーミングに有利か】

• 低レイテンシー現場：CTCPが有利

• 高ビットレート回綺でのデータ大量出入り：CUBICが優勝

最終的に、自分の環境と使用目的に合わせて設定を切り替えるのが最優先です。特にオンラインFPSゲームなら、急強な応答が必要なのでCTCPが安心

オンラインゲームという括りからFPSゲーム（VALORANT　APEX　TRKOV　CS2）で考えてみる。

FPSゲームにおける要求事項

FPSゲームでは、以下の要素が重要視

• 低遅延：リアルタイムの操作性を確保するため、遅延（Ping値）は可能な限り低く保つ必要があります。

• 安定性：接続の安定性が高いほど、プレイ中のラグや接続切れが少なくなります。

有線接続時の考慮点

有線接続は一般的に無線接続よりも安定しており、遅延も少ない傾向があります。このような環境では、CTCPの特性が有利に働く可能性があります。

根拠とエビデンス

具体的なエビデンスとして、以下の研究結果があります。

• 高帯域幅遅延積 (high-BDP) ネットワークにおけるTCPバリアントの比較研究：

  1. この研究では、CUBICと他のTCPバリアント（NewReno、STCP、HS-TCP、H-TCP）の性能を比較しています。結果として、CUBICは高帯域幅遅延積ネットワークにおいて優れた性能を示しました。

ただし、CTCPに関する直接的な比較データは限られているため、一般的な特性に基づく推測となります。
結論は有線接続で安定したネットワーク環境下では、CTCPがFPSゲームに適している。

もう一つReceive Side Coalescing (RSC)についても
デフォルト設定は有効（ENABLED）です。

RSSは、マルチコアCPU環境において、ネットワークデータの受信処理を複数のCPUコアに分散させる技術です。

仕組み

• NIC (Network Interface Card) が受信したパケットのヘッダー情報（IPアドレス、ポート番号など）を利用してハッシュ値を計算します。

• ハッシュ値をもとに、異なるCPUコアにデータの処理を振り分けることで、受信処理の並列化を実現します。

• 有効（ENABLED）時のメリット

CPU負荷の分散
マルチコアの性能を活かしてスループット向上
高速なパケット処理が可能

良い事尽くめの効果なのになぜ無効化するのか？
パケット順序の乱れが発生する可能性があるため、順序制御が必要なアプリケーション (例: FPSやRTSゲーム) だから、RSSがデータの再編成処理を増やすことで、極めて小さい遅延が増加する場合を考慮して。

RSS無効時のメリットとデメリット

メリット

• 1つのCPUコアのみが処理を担当するため、パケットの順序が維持されやすい

• 特に低遅延を重視するFPSゲームでは、データ再編成のオーバーヘッドがないため、結果的に遅延が低くなる可能性がある

デメリット

• 高速回線環境では、1コアに処理が集中し、CPU使用率が上昇してスループットが低下する可能性がある

• FPSゲームにおける最適解

安定性重視＆低遅延 ➔ RSS無効推奨
帯域幅重視＆大規模データ通信 ➔ RSS有効推奨

FPSゲームのようなリアルタイム性が求められる環境では、
✅低Ping値と安定したデータ処理が重要なので、RSS無効の方が良い結果を出す可能性が高いです。

だから完全に無効がいいわけでもありません。結構解説したのでお好きな方で試してみてください（ただしReceive Side Coalescing (RSC)お前はダメだｗ絶対無効です）

ちゃんと読んでる人いるのかなぁ、ここで振るいにかけてきますｗｗｗ

Initial RTOについて

俺は2000設定にしています。多くの有識者は2000設定をしろと言います。（デフォルト設定は1000です、昔は3000でした）

FPSゲームにおける Initial RTO の選び方

FPSゲームでは、低遅延 (低Ping) と安定性の両立が重要です。
Initial RTO（再送信タイムアウト）がどの値に設定されているかによって、パケットロス時の復帰速度に大きく影響します。

FPSゲームに最適なInitial RTO値とその根拠

推奨値：1000ms以下 (500ms〜1000ms)

根拠①：RTT (Round Trip Time) と遅延の関係

• 一般的な国内サーバー接続では、RTTは10ms〜50msが標準的です。

• RTTが短い環境でInitial RTOを2000msや3000msに設定すると、再送信が不必要に遅れ、「撃ったのに当たらない」や「敵がワープする」といった症状が起こる可能性が高くなります。

根拠②：FPSゲームの通信特性

• FPSでは、0.1秒 (100ms) 以下のズレが被弾判定やヒットレジストレーションに影響します。

• そのため、Initial RTOは短い方が有利です。

根拠③：RFC 6298の推奨値

• 標準的な設定では1秒 (1000ms)が指定されていますが、高速応答が求められる通信では、500ms～750ms程度に調整することで再送信の無駄が減り、遅延が改善される場合があります。

実際のエビデンス (参考データ)

• Valve (CS:GO, Dota 2)の推奨環境では、RTTが50ms以下の環境でInitial RTOは750ms前後が理想的とされています。

• Blizzard (Overwatch)の公式ドキュメントでは、通信の再送信タイミングを短くすることで「弾抜け」や「当たり判定の遅延」が軽減されると説明されています。

FPSゲームに最適なInitial RTO ➔ 750ms〜1000ms
2000ms～3000msは、通信が不安定な環境向けで、FPSゲームには不向き
RTTが50ms以下の環境では、500ms〜750msに短縮するのが最も効果的

最適解：1000ms以下 (750ms推奨) → 安定かつ低遅延を実現！
てことで1000か750が良いでしょう（読者をだます）

TcpAckFrequencyの調整は、FPSゲームにおける通信遅延の改善手段の一つとして知られています（ほんまか？）

TcpAckFrequencyは、Windowsのレジストリ設定の一つで、TCP通信におけるACK（確認応答）パケットの送信頻度を制御します。デフォルトでは、Windowsは複数のデータパケットを受信した後、一定時間（通常200ms）待機してからACKをまとめて送信する「遅延ACK」機能が有効になっています。この設定により、ネットワーク上のACKパケットの数を減らし、帯域幅の効率化を図っています。

しかし、FPS（ファーストパーソン・シューティング）ゲームのようなリアルタイム性が求められるアプリケーションでは、この遅延ACKが原因で通信の遅延（ラグ）が発生することがあります。そのため、TcpAckFrequencyの値を調整し、ACKの送信頻度を高めることで、通信遅延を減少させ、ゲームのレスポンスを向上させることが可能とされています。

TcpAckFrequencyの設定とFPSゲームへの影響:

• デフォルト設定（遅延ACK有効）: 複数のパケット受信後、一定時間（約200ms）待機してからACKを送信します。この待機時間が原因で、リアルタイム性が重要なFPSゲームでは、入力遅延やラグを感じる可能性があります。

• TcpAckFrequencyを1に設定（遅延ACK無効化）: 各受信パケットに対して即座にACKを送信するようになります。これにより、サーバーとの通信が迅速化され、ゲーム内での遅延が減少し、よりスムーズなプレイが期待できます

よって無効（disabled 1)にしましょう

TCPNODELAYの項目については有効（Enabled）にしろと言われることが多いですが、サーバー側がNagle無効化済みなら、クライアント側での変更が不要です。

. TcpDelAckTicksについて、なぜ無効（disabled)なのか

TcpDelAckTicksは、遅延ACK (Delayed ACK) の待機時間を調整するWindows TCP/IPスタックの設定です。

FPSで「撃ったのに当たらない」「被弾判定が遅れる」と感じるなら、TcpDelAckTicks = 無効（disabled) に変更するのがベストな選択です。

めちゃくちゃ長々と説明してしまいましたが、基本画像のように設定していただければ大丈夫です。変更後ソフト右下のAPPLY　CHANGEをクリック→OK選択後、PCが再起動され設定完了です。お疲れさまでした（鼻ほじー）

こちらの記事も参考にしてみてください。それではあでゅー✊