今回は、Windows 11 のネットワークを最適化して有線LAN の通信速度を改善する方法を紹介します。
Windows 11 の既定設定は多くの環境で問題なく利用できますが、ネットワーク環境やネットワーク アダプターによっては、設定を調整することで通信性能が改善する場合があります。
このページで紹介するのは、筆者が検証して効果のあった方法です。
Windows 11 のネットワークを最適化することで、以下の点が改善される可能性があります。設定を行う際は、注意事項をよくお読みください。
- WEBページの読み込み速度の向上
- ファイルのダウンロード速度の向上
- ファイルのアップロード速度の向上
- オンラインゲームのラグ(遅延)の軽減
Windows 11 のネットワークを最適化する方法と注意事項
ネットワーク設定とインターネット設定
DNSサーバーの変更
デフォルトの設定では、ご自分が契約しているプロバイダーの DNSサーバーアドレスが自動的に割り当てられています。
DNSサーバーとは、ドメイン名を IPアドレスに変換する役割を担っています。
わかりやすく説明すると、
- あなたが WEBサイト「google.com(ドメイン名)」を見たくてアクセスしたとします。
- すると、コンピューターは DNSサーバーに「google.com の住所はどこですか?」と聞きます。
- DNSサーバーは「google.com の住所は 172.217.161.206(IPアドレス) だよ」と教えてくれます。
- コンピューターはその住所を使って、google.com の WEBサイトを表示します。
プロバイダーの DNSサーバーのまま使用することに問題はありませんが、プロバイダーによってはドメイン名を IPアドレスに変換する処理速度が遅い場合があります。
プロバイダーの処理速度が遅い場合、 ドメイン名が IPアドレスに変換されるまでに時間がかかり、結果的に WEBサイトの表示が遅くなります。
そこでおすすめなのが、高速なDNSサーバーに変更することです。
高速なDNSサーバーに変更することで、ドメイン名が IPアドレスに変換されるまでの時間が短縮され、WEBサイトの表示が速くなる可能性があります。
筆者がおすすめするのは、世界的に有名な無料のパブリックDNSサーバー「Cloudflare Public DNS」です。
DNSサーバーを「Cloudflare Public DNS」に変更するには、
1.タスクトレイ(通知領域)のネットワークのアイコンを右クリック>「ネットワーク設定とインターネット設定」をクリックします。
2.「ネットワークとインターネット」が開きますので、「プロパティ」をクリックします。
3.「DNS サーバーの割り当て」の右側にある「編集」をクリックします。
4.「DNS 設定の編集」が表示されますので、「自動(DHCP)」をクリックして「手動」を選択してください。
5.「IPv4」が「オフ」となっていますので、「オン」に変更してください。※「IPv6」を利用している環境では「IPv6」側も設定してください。
6.すると、各項目が表示され入力できるようになりますので、「優先 DNS」に「優先DNSサーバー」「代替え DNS」に「代替DNSサーバー」のアドレスを入力してください。
| Cloudflare Public DNS | 優先DNSサーバー | 代替DNSサーバー |
| IPv4 のアドレス | 1.1.1.1 | 1.0.0.1 |
| IPv6 のアドレス | 2606:4700:4700::1111 | 2606:4700:4700::1001 |
7.「IPv4」「IPv6」両方入力出来たら「保存」をクリックします。
すると、下の画像のように変更が反映されますので確認してみてください。
※DNSサーバーの変更は既に反映されていますので、パソコンを再起動する必要はありません。
ネットワークドライバーの設定
※ネットワークドライバーは最新のバージョンをインストールしておきましょう。
受信バッファと送信バッファ
受信バッファと送信バッファは、ネットワーク アダプターが送受信するデータを処理するために使用する領域です。
これらの値を大きくすると、高速通信や通信量が多い環境でパケット処理に余裕が生まれ、ネットワーク性能が向上する場合があります。
ただし、値を大きくすれば必ず通信速度が上がるわけではありません。ネットワーク アダプターやドライバー、通信環境によって適切な値は異なります。
受信バッファ(Receive / RX Buffers)→ 主に受信処理に影響
- 役割: ネットワーク アダプターが受信したデータを、ドライバーや OS が処理するまで一時的に保持するために使用されます。
- 値が小さすぎる場合: 高速で大量のデータを受信した際に処理が追いつかず、パケットを取りこぼして受信性能が低下する場合があります。
- 値を大きくした場合: 多くの受信データを処理できるようになるため、高負荷時の受信性能が改善する場合があります。ただし、その分システム メモリーを使用します。
送信バッファ(Transmit / TX Buffers)→ 主に送信処理に影響
- 役割: ネットワーク アダプターが送信するパケットを管理するために使用されます。
- 値が小さすぎる場合: 大量のデータを送信する環境では、送信処理が追いつかずパフォーマンスが低下する場合があります。
- 値を大きくした場合: 多くの送信パケットを管理できるため、高負荷時の送信性能が改善する場合があります。ただし、その分システム メモリーを使用します。
設定できる値はネットワーク アダプターやドライバーによって異なります。
たとえば Intel の一部の Ethernet アダプターでは、Receive Buffers は 128 ~ 4096 の範囲で設定できます。ここで表示される 4096 は 4096MB や 4GB という意味ではなく、バッファ数を示す値です。Intel の Receive Buffers では、1 バッファあたり約 2KB のメモリーを使用すると説明されています。
ネットワークに特に問題がない場合は、無理に最大値へ変更せず、既定値のまま使用することをおすすめします。高速回線で受信・送信性能に問題がある場合は、現在の値を記録したうえで段階的に増やし、通信速度や安定性に変化があるか確認してみてください。
受信バッファと送信バッファの値を大きくし過ぎる副作用
バッファを大きくしすぎると環境によって遅延が増えることがあります。これは広い意味では、通信経路上のキューにデータが滞留して遅延が増える Bufferbloat と似た現象につながる場合があります。その結果、WEBページの表示やオンラインゲームの反応が遅く感じられる現象が起こり得ます。
なぜ「Webページの読み込み」が遅くなるのか?
理由は、WEBブラウジングとファイルダウンロードでは、求められる通信の性質が違うからです。
- ファイルダウンロード(スループット重視):
- 大きなデータをドバっと流し込む作業です。
- バッファが大きいと、パケットを取りこぼさずに一度に大量に処理できるため、速度が出やすくなります。
- WEBページの閲覧(レイテンシ重視):
- WEBページを表示する際は、「DNSへの問い合わせ」「サーバーとの握手(接続確立)」「画像や CSS など多数の小さなファイルの取得」といった、細かいやり取り(往復)が大量に発生します。
- バッファが大き過ぎると: パケットがバッファ(待機列)の中に溜まりすぎてしまい、「処理されるまでの待ち時間」が増えてしまいます。
- 結果として、ボタンを押してから反応するまでの時間(Ping/RTT)が伸び、体感的な「サクサク感」が失われます。
例え話:レジの行列
- バッファ小: 行列が短い。店員(CPU)はすぐに対応してくれるが、混雑すると客(パケット)を追い返す(パケットロス)ことになる。
- バッファ大: 行列を長くできます。混雑時に客を追い返しにくくなりますが、最後尾に並んだ客はレジに到達するまで長く待たされます。
WEBページの読み込みは、この「レジに到達するまでの待ち時間」に敏感なため、バッファを大きくしすぎると逆効果になることがあるのです。
筆者の環境(Marvell AQtion 10Gbit Network Adapter)での設定例:
下記は筆者の環境での設定例です。
1.スタートボタンを右クリック>「デバイスマネージャー」をクリックします。
2.デバイスマネージャーが開いたら、「ネットワークアダプター」の項目を展開し、お使いのネットワークアダプター名(筆者の場合は Marvell AQtion 10Gbit Network Adapter)の上で右クリック>「プロパティ」をクリックします。
3.「詳細設定」タブを開き、各項目を選択して値を変更します。
- Receive Buffers(受信バッファ)= 4096(最大値)
- Transmit Buffers(送信バッファ)= 8184(最大値)
※2025/11/28:長期間最大値に設定して様子を見ていましたが、大き過ぎると WEBページの表示等に影響が出るので、現在筆者はどちらも「2048」に設定しています。
MTU値の設定
MTU値とは
MTU値とは、インターネットでデータを送るときの、1回で送れるデータ(パケット)の最大の大きさのことです。
一般的な Ethernet 接続では MTU は 1500 に設定されていることが多く、通常は変更する必要はありません。
しかし、契約しているプロバイダーにより MTU値が 1500 以下に制限されている場合があります。
その場合、デフォルトの 1500 では大きすぎるということになりますね。
MTU値が大きすぎると、ネットワーク上でパケットが分割(断片化)されることがあります。
簡単に言うと、例えば MTU値が 1454 に制限されていたとします。
1454 を道幅(1454cm)と例えると、幅 1500cm のデータは大きすぎて 1454cm の道を通ることができません。
この大きなデータを小さなデータに分けることにより、狭い道を通ってデータをスムーズに送ることができるようになります。
そして、データの送り先で小さく分割されたパケットを元に戻します。これを「フラグメント化や断片化」と呼んでいます。
パケットを分割したり元に戻す処理にはある程度の時間がかかりますので、頻繁に断片化が発生すると通信速度の低下につながることがあります。
そのため、断片化が起きないように明確な MTU値を Windows に教えておくことで、通信速度の低下を防ぐことができます。
MTU値の確認と変更方法
MTU値が制限されているかを確認するには、次のサイトがおすすめです。
speedguide.net – SG TCP/IP Analyzer
ページを開くと、「MTU = 1460」のように表示されますので確認してみてください。
MTU値が「1500」と表示されていれば設定を変更する必要はありません。
MTU の変更は、PPPoE、VPN などで適切な MTU が明確に分かっている場合や、断片化・接続不良を確認した場合に行ってください。
1.スタートボタンを右クリックし、「ターミナル(管理者)」を開きます。
2.次のコマンドを入力して Enter を押します。
Get-NetIPInterface
すると、ネットワークインターフェイスの一覧が表示されます。
3.ここで確認するのは、現在接続しているネットワークインターフェイス(ネットワークアダプター)の名前の左側にあるインデックス番号です。
「設定」>「ネットワークとインターネット」を開くと確認できます。
4.次のコマンドを入力して Enter を押し、MTU値を変更します。
Set-NetIPInterface -InterfaceIndex インデックス番号 -NlMtuBytes MTU値
例えば、インデックス番号が「12」で MTU値を「1460」に設定したい場合は
Set-NetIPInterface -InterfaceIndex 12 -NlMtuBytes 1460
となります。
5.変更された MTU値を確認するため、もう一度次のコマンドを入力して Enter を押してみましょう。
Get-NetIPInterface
ネットワークインターフェイス(ネットワークアダプター)の名前の右側の MTU値が変更されましたね?
これで MTU値の設定は完了しましたので、Windows PowerShell はそのまま閉じず、グローバル TCP パラメーターの設定に進んでください。
TCP パラメーターの設定
TCP パラメーターの設定は一般的に変更する必要はありませんが、筆者の環境で検証した結果、冒頭でも述べたように以下の点が改善されました。
- WEBページの読み込み速度の向上
- ファイルのダウンロード速度の向上
- ファイルのアップロード速度の向上
- オンラインゲームのラグ(遅延)の軽減
TCP パラメーターは通常、Windows の既定値のままで問題ありません。ただし、ネットワーク環境によっては一部の設定を変更すると通信特性が変化する場合があります。
TCP パラメーターの変更後、通常は PC の再起動は必要ありません。ただし、すでに確立している TCP 接続には変更が反映されない場合があるため、速度を比較する際はブラウザーや対象アプリを再起動してから測定してください。
グローバル TCP パラメーターの設定
まず現在の設定を確認するために次のコマンドを入力して Enter を押してください。
netsh int tcp show global
すると、現在のグローバル TCP パラメーターの一覧が表示されます。
筆者の Windows 11 24H2 環境で確認したグローバル TCP パラメーター
筆者の環境で確認をしてみると、Windows 11 バージョン 24H2 のグローバル TCP パラメーターは次のように設定されていました。
| 名前 | 状態(筆者の環境で確認した値) |
|---|---|
| Receive-Side Scaling 状態 | enabled |
| 受信ウィンドウ自動チューニング レベル | normal |
| アドオン輻輳制御プロバイダー | default |
| ECN 機能 | disabled |
| RFC 1323 タイムスタンプ | enabled |
| 初期 RTO | 1000 |
| Receive Segment Coalescing 状態 | enabled |
| 非 Sack の Rtt 回復性 | disabled |
| SYN の最大再送信数 | 4 |
| Fast Open | enabled |
| Fast Open フォールバック | enabled |
| HyStart | enabled |
| Proportional Rate Reduction | enabled |
| ペーシング プロファイル | off |
各グローバル TCP パラメーターの詳細
| 名前 | 詳細 |
|---|---|
| Receive-Side Scaling 状態 | 受信側スケーリング (RSS): RSS は、ネットワーク データの受信時に複数のプロセッサ コアが並列処理を実行し、ネットワーク スループットを向上させるネットワーク パフォーマンス最適化テクノロジです。このテクノロジーは、着信データ パケットを異なるプロセッサ コアに分散し、単一のプロセッサ コアの負担を軽減して処理効率を向上させます。これは、マルチコア プロセッサ システムで特に効果的です。 |
| 受信ウィンドウ自動チューニング レベル | 受信ウィンドウの自動調整 (Autotuninglevel): Autotuninglevel は、受信バッファのサイズを自動的に調整するための TCP プロトコルの設定です。受信ウィンドウのサイズによって、送信者が確認応答せずに残すことができるデータの最大量が決まります。バッファ サイズを自動的に調整することで、特に高遅延および高帯域幅のネットワーク環境でパフォーマンスを最適化できます。ネットワークの状況に応じて、システムは受信ウィンドウのサイズを動的に調整し、データ転送の効率を向上させます。 |
| アドオン輻輳制御プロバイダー | アドオン輻輳制御プロバイダー: アドオン輻輳制御プロバイダーは、ネットワークの輻輳を効率的に管理し、パフォーマンスを向上させるための重要な機能です。適切なプロバイダーを選択することで、より快適なネットワーク環境を実現できます。 ※Windows 11 では、補足テンプレートに基づく TCP パラメーターにて変更可能。 ※輻輳とはネットワークの混雑を意味します。 |
| ECN 機能 | 明示的輻輳通知 (ECN): ECNは、ネットワーク輻輳が発生したときに、単にパケットをドロップするのではなく、ネットワーク デバイス (ルーターなど) がデータ送信者に明示的に通知できるようにするネットワーク輻輳制御メカニズムです。このメカニズムは、パケット損失による再送信を回避し、ネットワーク遅延を削減するのに役立ちます。 ECN は、IP ヘッダーのフラグ ビットで情報を渡すことにより、TCP 送信者が送信速度を下げ、輻輳を緩和するのに役立ちます。 |
| RFC 1323 タイムスタンプ | TCP タイムスタンプ: TCP タイムスタンプは、伝送効率と遅延測定を改善するために使用される TCP プロトコルの機能です。各 TCP パケットにタイムスタンプを追加することで、受信側はパケットの往復時間 (RTT) を測定し、これに基づいて再送信タイムアウト (RTO) と送信戦略を調整できます。タイムスタンプを有効にすると、ネットワークの状態が変化した場合のパフォーマンスを最適化できます。 |
| 初期 RTO | TCP 再送制御 (InitialRTO): InitialRTO は、TCP プロトコルの初期再送タイムアウト (RTO、再送タイムアウト) を設定するために使用される値です。この値は、TCP 再送信メカニズムの初期待機時間を決定します。指定された時間内にデータ パケットが確認されない場合、送信者はデータ パケットを再送信します。この値は通常デフォルト値に設定されており、ネットワーク上でパケット損失が発生した場合の再送信動作を効果的に制御できます。 |
| Receive Segment Coalescing 状態 | 受信セグメント結合 (RSC): RSC は、データ パケットの処理回数を減らすために使用されるネットワーク最適化テクノロジーです。ネットワークの受信側では、複数の小さなセグメントが受信されると、RSC はこれらのセグメントを 1 つの大きなセグメントにマージします。これにより、処理回数とメモリ アクセス回数が削減され、特に高速ネットワークでのネットワーク受信効率が向上します。 |
| 非 Sack の Rtt 回復性 | 非 SACK クライアント RTT リカバリ (NonsackRTTResiliency): 非 SACK RTT リカバリとは、TCP プロトコルにおいて、クライアントが SACK (選択的確認応答) をサポートしていない場合、従来の確認方法を使用してデータ パケットを確認し、RTT (ラウンドトリップ時間) を測定することを意味します。この場合、TCP プロトコルは従来の ACK メカニズムに基づいて RTT 計算を再開します。 |
| SYN の最大再送信数 | SYN 再試行回数 (MaxSYNRetransmissions): MaxSYNRetransmissions はTCP プロトコルで指定されます。これは、接続確立プロセス中に送信者が SYN (同期) パケットを再試行できる最大回数です。受信側が指定された時間内に SYN パケットに応答しない場合、送信側は SYN パケットの送信を再試行します。この値は、接続確立の信頼性を確保するための再試行の最大回数を指定します。 |
| Fast Open | TCP Fast Open (FastOpen): TCP Fast Open (TFO)は、3 ウェイ ハンドシェイクが完了するのを待たずに、接続確立プロセス中にクライアントがサーバーにデータを送信できるようにする最適化テクノロジです。 TCP Fast Open は、ハンドシェイク プロセスの時間を短縮することで、特に高遅延ネットワークでの接続確立の遅延を削減できます。3 ウェイ ハンドシェイクとは: インターネットで2つのコンピュータが通信を始めるとき、最初に「こんにちは」のあいさつを3回やり取りします。これを3ウェイハンドシェイクといいます。 最初の「こんにちは」: コンピュータAがコンピュータBに「通信したいです!」と伝えます。 2回目の「こんにちは」: コンピュータBがコンピュータAに「通信OKですよ!」と伝えます。 3回目の「こんにちは」: コンピュータAがコンピュータBに「ありがとう!通信を始めましょう!」と伝えます。 この3回のあいさつが終わって、初めてコンピュータAとコンピュータBは、データをやり取りできるようになります。 |
| Fast Open フォールバック | TCP 高速オープン フォールバック: FastOpenFallbackは、ターゲット サーバーが TCP 高速オープン (TFO) をサポートしていない場合のフォールバック メカニズムです。ターゲット サーバーが TFO をサポートしていない場合、クライアントは従来の 3 ウェイ ハンドシェイク プロセスにフォールバックします。このメカニズムにより、TFO をサポートしていない環境でも接続が正常に確立されることが保証されます。 |
| HyStart | スロー スタート アルゴリズム (HyStart): HyStart は、スロー スタート フェーズ中に輻輳ウィンドウの増加をより慎重に制御することでネットワーク輻輳を軽減する TCP スロー スタート アルゴリズムです。従来のスロー スタート アルゴリズムではパケット損失が発生する可能性がありますが、HyStart はネットワーク負荷の変化を予測することでウィンドウの過度の増加を回避し、TCP 接続のスループットと安定性を最適化します。 ※アルゴリズムとは、簡単に言うと「問題を解決するための手順」のことです。 |
| Proportional Rate Reduction | 比例レート削減 (PRR): 比例レート削減 (PRR)は、ネットワーク輻輳が発生したときに送信レートを制御するために使用される TCP プロトコルのアルゴリズムです。スムーズなレート調整により、ネットワークの輻輳による高速再送信を回避し、輻輳によるパフォーマンスの変動を軽減します。 PRR アルゴリズムは、データ パケットが失われた場合にレート調整プロセスを遅くし、より安定したネットワーク伝送を実現します。 ※送信レートとは、簡単に言うと「1秒間にどれくらいのデータを送れるか」を表すものです。 |
| ペーシング プロファイル | ペーシング プロファイル: ペーシング プロファイルは、TCP フロー制御に使用されるメカニズムです。パケットの送信レートを制御して、ネットワーク内の過度のトラフィック集中や輻輳を防ぎます。通常、ネットワークの実際の状況に応じてデータ パケットを送信する間隔を調整し、データ フローの円滑性を確保して、ネットワーク全体の使用率とパフォーマンスを向上させます。 |
グローバル TCP パラメーターの設定方法
グローバル TCP パラメーターの設定を変更するには、次のコマンドを入力して Enter を押します。
netsh int tcp set global タグ=値
例えば、Receive-Side Scaling 状態を有効にする場合は
netsh int tcp set global rss=enabled
となります。
グローバル TCP パラメーターのおすすめ設定
- enabled = 有効
- disabled/off = 無効
- default = 既定
筆者の Windows 11 環境では、現在のグローバル TCP パラメーターの多くがすでに推奨状態になっていました。そのため、すべての項目を変更する必要はありません。現在の値を確認し、異なっている項目がある場合のみ変更してください。
| 名前 | タグ | おすすめの設定(値) | 備考 |
|---|---|---|---|
| Receive-Side Scaling 状態 | rss | enabled | マルチコア プロセッサをご使用の場合は、有効にすることを推奨します。 現在一般家庭で使用しているほとんどのパソコンでは、マルチコア プロセッサ(CPU)が使用されています。例えば、パソコンを購入する際に「CPUコア 8コア/16スレッド」のように表示されていますね。この「8コア」をマルチコア(1つ以上のコア)と呼びます。 |
| 受信ウィンドウ自動チューニング レベル | autotuninglevel | normal | 受信ウィンドウ自動チューニング レベルには、5つのレベルが存在しますが、デフォルトの Normal を推奨します。 |
| アドオン輻輳制御プロバイダー | default | この設定は補足テンプレートに基づく TCP パラメーターで変更します。※変更後も表示は変わりません。 | |
| ECN 機能 | ecncapability | 既定値 | ECN 機能を有効にすると、ネットワークの遅延が改軽減される可能性があります。通常は既定値のまま。対応環境で検証する場合は enabled。 |
| RFC 1323 タイムスタンプ | timestamps | 既定値 | TCP タイムスタンプは RTT の測定や再送制御などに利用されます。Windows のバージョンや環境によって既定状態が異なる場合があるため、通常は既定値のまま使用することをおすすめします。 |
| 初期 RTO | initialrto | 既定値 | 値を小さくすると、応答が遅れているだけでも早めに SYN を再送する可能性があります。逆に値を大きくすると、SYN が失われた場合に再送開始が遅くなります。通常は既定値のまま使用することをおすすめします。筆者の環境では 2秒(2000)に設定することでパフォーマンスが上がりました。※筆者環境での検証結果であり、一般的な推奨値ではありません。 |
| Receive Segment Coalescing 状態 | rsc | enabled | ネットワークの受信効率が向上しますので、有効にすることを推奨します。 |
| 非 Sack の Rtt 回復性 | nonsackrttresiliency | disabled | SACK に対応していない相手との通信時に RTT の回復性を高めるための機能です。一般的なインターネット環境では変更する必要はありません。 |
| SYN の最大再送信数 | maxsynretransmissions | 既定値 | 接続時に SYN パケットへ応答がない場合、何回まで再送するかを指定します。値を小さくすると接続不能を早く判断できますが、一時的なパケットロスで接続に失敗しやすくなります。値を大きくすると不安定な環境で接続成立を待ちやすくなりますが、接続不能時に諦めるまでの時間が長くなります。 |
| Fast Open | fastopen | enabled | 対応環境で接続確立時の遅延を短縮できる機能。有効にすることを推奨します。 |
| Fast Open フォールバック | fastopenfallback | enabled | TCP 高速オープン (TFO) をサポートしていない環境でも接続が正常に確立されることが保証されます。有効にすることを推奨します。 |
| HyStart | hystart | enabled | ネットワーク負荷を回避し、ネットワーク接続の安定性を最適化しますので、有効にすることを推奨します。 |
| Proportional Rate Reduction | prr | enabled | 安定したネットワークを実現します。有効にすることを推奨します。 |
| ペーシング プロファイル | pacingprofile | off | 通常は無効のままで問題ありません。 大容量のデータを頻繁に送受信する場合、リアルタイム通信やビデオストリーミングなどのアプリケーションを使用している場合は、有効にするとパフォーマンスが上がる場合があります。 |
おすすめ設定のコマンド
netsh int tcp set global rss=enabled
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global ecncapability=default
netsh int tcp set global timestamps=enabled
netsh int tcp set global nonsackrttresiliency=disabled
netsh int tcp set global maxsynretransmissions=4
netsh int tcp set global initialrto=1000
netsh int tcp set global rsc=enabled
netsh int tcp set global fastopen=default
netsh int tcp set global fastopenfallback=default
netsh int tcp set global hystart=enabled
netsh int tcp set global prr=enabled
netsh int tcp set global pacingprofile=off
デフォルトの設定に戻すコマンド
netsh int tcp set global rss=default
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global ecncapability=default
netsh int tcp set global timestamps=enabled
netsh int tcp set global nonsackrttresiliency=default
netsh int tcp set global maxsynretransmissions=4
netsh int tcp set global initialrto=1000
netsh int tcp set global rsc=enabled
netsh int tcp set global hystart=default
netsh int tcp set global prr=default
netsh int tcp set global pacingprofile=default
ペーシング プロファイルについて
| 値 | 説明 |
|---|---|
| off または default | ページングしません。 |
| initialwindow | 初期輻輳ウィンドウをペーシングします。 |
| slowstart | 低速開始の間だけペーシングします。 |
| always | 常にペーシングします。 |
一般的な家庭用ネットワークや小規模なオフィスネットワークでは特に有効にする必要はありません。
※遅延やパケットロスがほとんど発生しない環境では、有効にするメリットは少ないです。
受信ウィンドウ自動チューニング レベルについて
| 受信ウィンドウ自動チューニング レベル | 説明 |
|---|---|
| Normal (デフォルト) | ほぼすべてのシナリオに対応できるように、TCP 受信ウィンドウを拡大するように設定します。 |
| Disabled | TCP 受信ウィンドウをデフォルト値に設定します。 |
| Restricted | TCP 受信ウィンドウをデフォルト値を超えて拡大するように設定しますが、一部のシナリオではそのような拡大を制限します。 |
| Highly Restricted | TCP 受信ウィンドウをデフォルト値よりも大きく設定しますが、非常に慎重に設定してください。 |
| Experimental | 極端なシナリオに対応するために、TCP 受信ウィンドウを拡大するように設定します。 |
受信ウィンドウ自動チューニング レベルについては何度も検証しましたが、デフォルト以外に設定すると通信速度が低下します。
そのため、デフォルトの Normal を推奨します。Normal の場合、必要な場合に受信ウィンドウは自動的に拡大されるようになり、多くの一般的な環境に対応します。
補足テンプレートに基づく TCP パラメーターの設定
ここでは現在使用している輻輳制御プロバイダーを変更します。
Windows 11 のデフォルトの設定では、輻輳制御プロバイダーは「CUBIC」に設定されており、
| プロバイダー名(アルゴリズム名) | 説明 |
|---|---|
| CTCP | CTCPは、Microsoftが開発したTCP輻輳制御アルゴリズムです。特に、高帯域幅で遅延が大きいネットワーク(長距離ネットワークなど)において、高いスループットを実現するように設計されています。CTCP は、高帯域幅ネットワークでの利用を最大化するように設計されており、よりアグレッシブなアルゴリズムです。 |
| DCTCP | DCTCPは、主にデータセンター内のネットワークで利用されることを想定しています。 |
| NewReno | パケット損失を検知すると、送信速度を段階的に減少させ、輻輳を回避します。 |
| BBR | Googleが開発したアルゴリズムです。BBR (ボトルネック帯域幅と RTT) は効率的な輻輳制御アルゴリズムであり、特に高帯域幅、低遅延のネットワークに適しており、遅延を削減します。 |
| CUBIC | 大規模ネットワーク、特に高帯域幅と高レイテンシのネットワークの場合にパフォーマンスを発揮します。CUBIC は、様々なネットワーク環境で安定した性能を発揮するように設計されており、より穏やかなアルゴリズムです。 高レイテンシとは、インターネットの回線が混んでいたり、遠くのサーバーと通信した際に、データが届くまでの時間が長くなることをいいます。 |
Windows クライアントでは CUBIC が既定です。通常は CUBIC のままで問題ありません。CTCP は、高帯域幅かつ高遅延の一部の環境で CUBIC より高いスループットが得られる場合があります。筆者の環境では CTCP でも検証していますが、すべての環境で CTCP の方が高速になるわけではありません。
高いスループットのメリット:
- 動画をスムーズに見たり、大きなファイルを早くダウンロードしたりできる。
- たくさんの人が同時にインターネットを使っても、快適に使える。
輻輳制御プロバイダーを「BBR」に設定するとダウンロード速度およびアップロード速度が向上する場合がありますが、一部の環境で不具合が発生する場合があります。
例えば、プロキシサーバー経由でインターネット接続ができなくなったり、Hyper-V を使用している環境では仮想マシンが起動できなくなります。(検証済み)
現在の輻輳制御プロバイダーを確認する
現在のWindows PowerShellを確認するには、次のコマンドを入力して Enter を押します。
Get-NetTCPSetting | Select SettingName, CongestionProvider
すると、輻輳制御プロバイダーの一覧が表示されますので、「Internet」の右側を確認してください。
輻輳制御プロバイダーを変更する
輻輳制御プロバイダーを変更するには、次のコマンドを入力して Enter を押します。
netsh int tcp set supplemental Template=Internet CongestionProvider=プロバイダー名
例えば、「CTCP」に変更したい場合は
netsh int tcp set supplemental Template=Internet CongestionProvider=ctcp
となります。
変更後、もう一度現在の輻輳制御プロバイダーを確認してみてください。
デフォルトに戻したい場合は、次のコマンドを入力して Enter を押します。
netsh int tcp set supplemental Template=Internet CongestionProvider=default
これで Windows 11 のネットワーク最適化は完了しました。変更前と変更後の違いを確認してみてください。
高遅延環境かどうかを確認する方法
高遅延環境かどうかは、ping コマンドを使用して RTT(Round Trip Time / 往復遅延時間)を確認できます。
RTT は、PC から送信したデータが接続先へ到達し、応答が戻ってくるまでにかかった時間です。単位は ms(ミリ秒)で、値が小さいほど遅延が少ないことを表します。
おおよその目安は次のとおりです。
| RTT | 遅延の目安 |
|---|---|
| 20ms 以下 | 低遅延 |
| 20 ~ 50ms | 比較的低遅延 |
| 50 ~ 100ms | やや高遅延 |
| 100ms 以上 | 高遅延 |
| 200ms 以上 | 非常に高遅延 |
※これはあくまで目安です。接続先までの距離、ネットワーク経路、混雑状況などによって RTT は変化します。
Ping で RTT を確認する
Windows + Rキーを押します。- 「ファイル名を指定して実行」が表示されたら、次のように入力して
Enterキーを押します。
cmd
- コマンド プロンプトが開いたら、次のコマンドを入力して
Enterキーを押します。
まずは Cloudflare の DNS サーバーで確認してみましょう。
ping 1.1.1.1
Cloudflare
https://www.cloudflare.com/
Google Public DNS でも確認できます。
ping 8.8.8.8
Google
https://www.google.com/
Microsoft の WEB サイトを確認する場合は、
ping www.microsoft.com
Microsoft
https://www.microsoft.com/
GitHub などでも確認できます。
ping github.com
GitHub
https://github.com/
Ping の結果を見る
例えば、次のように表示されたとします。
ラウンド トリップの概算時間 (ミリ秒): 最小 = 8ms、最大 = 9ms、平均 = 8ms
確認するのは 「平均」です。
この場合は平均 8ms なので、かなり低遅延な環境です。
一方、
最小 = 94ms、最大 = 95ms、平均 = 94ms
のように表示された場合は、やや高遅延な通信と判断できます。
複数の接続先で確認する
1つの接続先だけで高遅延環境かどうかを判断しないようにしてください。
同じインターネット回線を使用していても、
- Cloudflare:8ms
- Microsoft:7ms
- 海外サーバー:90ms
のように、接続先によって RTT が大きく変わることがあります。
これは、接続先までの物理的な距離だけでなく、通信経路や CDN、ネットワークの混雑状況などが異なるためです。
特に Google、Microsoft、Cloudflare などの大規模サービスでは、利用者に近い CDN やエッジ サーバーへ接続される場合があるため、海外企業の WEB サイトでも RTT が低くなることがあります。
そのため、高遅延環境かどうかを確認する場合は、複数の接続先で ping を実行してください。
CTCP を検討する場合
CTCP は、高帯域幅かつ高遅延の一部のネットワーク環境で、CUBIC より高いスループットが得られる場合があります。
ただし、Ping の結果が 10ms 前後のような低遅延環境では、CTCP に変更しても大きな効果が得られない場合があります。
そのため、まずは Windows クライアントの既定である CUBIC のまま通信速度を測定し、高遅延の接続先を頻繁に利用する場合に CTCP と比較してみることをおすすめします。
インターネットの速度計測について
インターネットの速度計測結果は、利用するサイトや測定する時間帯によって大きく変動するため、結果は参考値として捉えてください。
筆者が速度測定で利用するサイトは下記の 2つです。
- インターネット速度テスト(Google)
https://www.google.com/search?q=speedtest - ブロードバンドスピードテスト(回線速度・通信速度測定診断サイト)
https://www.bspeedtest.jp




















コメント