ネットワーク アダプターのパフォーマンス チューニングPerformance Tuning Network Adapters

適用先:Windows Server 2019、Windows Server 2016、Windows Server (半期チャネル)Applies to: Windows Server 2019, Windows Server 2016, Windows Server (Semi-Annual Channel)

このトピックでは、Windows Server 2016 以降のバージョンを実行しているコンピューターのパフォーマンスネットワークアダプターを調整する方法について説明します。Use the information in this topic to tune the performance network adapters for computers that are running Windows Server 2016 and later versions. ネットワークアダプターにチューニングオプションが用意されている場合は、これらのオプションを使用して、ネットワークのスループットとリソースの使用率を最適化できます。If your network adapters provide tuning options, you can use these options to optimize network throughput and resource usage.

ネットワークアダプターの正しいチューニング設定は、次の変数によって異なります。The correct tuning settings for your network adapters depend on the following variables:

  • ネットワーク アダプターとその機能セットThe network adapter and its feature set
  • サーバーが実行するワークロードの種類The type of workload that the server performs
  • サーバーのハードウェアとソフトウェアのリソースThe server hardware and software resources
  • サーバーのパフォーマンス目標Your performance goals for the server

以下のセクションでは、パフォーマンス チューニング オプションの一部について説明します。The following sections describe some of your performance tuning options.

オフロード機能の有効化Enabling offload features

ネットワーク アダプターのオフロード機能の調整には、一般的にメリットがあります。Turning on network adapter offload features is usually beneficial. ただし、ネットワークアダプターは、高スループットでオフロード機能を処理するのに十分ではない可能性があります。However, the network adapter might not be powerful enough to handle the offload capabilities with high throughput.

重要

オフロード機能のIPsec タスクオフロードまたはTCP chimney オフロードを使用しないでください。Do not use the offload features IPsec Task Offload or TCP Chimney Offload. これらのテクノロジは Windows Server 2016 で非推奨とされており、サーバーとネットワークのパフォーマンスに悪影響を及ぼす可能性があります。These technologies are deprecated in Windows Server 2016, and might adversely affect server and networking performance. さらに、これらのテクノロジはマイクロソフトによって今後サポートされない可能性があります。In addition, these technologies might not be supported by Microsoft in the future.

たとえば、ハードウェアリソースが限られているネットワークアダプターを考えてみます。For example, consider a network adapter that has limited hardware resources. この場合、セグメント化オフロード機能を有効にすると、アダプターの維持可能な最大スループットが低下する可能性があります。In that case, enabling segmentation offload features might reduce the maximum sustainable throughput of the adapter. ただし、スループットの低下が許容できる場合は、セグメント化オフロード機能を有効にすることをお勧めします。However, if the reduced throughput is acceptable, you should go ahead an enable the segmentation offload features.

注意

一部のネットワークアダプターでは、送信パスと受信パスに対して個別にオフロード機能を有効にする必要があります。Some network adapters require you to enable offload features independently for the send and receive paths.

Web サーバーの receive side scaling (RSS) の有効化Enabling receive-side scaling (RSS) for web servers

サーバーの論理プロセッサよりもネットワーク アダプター数が少ない場合、RSS で Web のスケーラビリティとパフォーマンスを改善できます。RSS can improve web scalability and performance when there are fewer network adapters than logical processors on the server. すべての web トラフィックが RSS 対応のネットワークアダプターを経由する場合、サーバーは異なる Cpu 間で同時に異なる接続からの受信 web 要求を処理できます。When all the web traffic is going through the RSS-capable network adapters, the server can process incoming web requests from different connections simultaneously across different CPUs.

重要

同じサーバー上で、RSS 以外のネットワークアダプターと RSS 対応のネットワークアダプターの両方を使用することは避けてください。Avoid using both non-RSS network adapters and RSS-capable network adapters on the same server. Rss とハイパーテキスト転送プロトコル (HTTP) の負荷分散ロジックにより、rss 非対応のネットワークアダプターが1つ以上の RSS 対応ネットワークアダプターを持つサーバーで web トラフィックを受け入れる場合、パフォーマンスが著しく低下する可能性があります。Because of the load distribution logic in RSS and Hypertext Transfer Protocol (HTTP), performance might be severely degraded if a non-RSS-capable network adapter accepts web traffic on a server that has one or more RSS-capable network adapters. このような場合、RSS 対応ネットワーク アダプターを使用するか、ネットワーク アダプターのプロパティの [詳細プロパティ] タブで RSS を無効にすることをお勧めします。In this circumstance, you should use RSS-capable network adapters or disable RSS on the network adapter properties Advanced Properties tab.

ネットワーク アダプターが RSS 対応かどうかを判断するには、ネットワーク アダプターのプロパティの [詳細プロパティ] タブの RSS 情報を確認します。To determine whether a network adapter is RSS-capable, you can view the RSS information on the network adapter properties Advanced Properties tab.

RSS プロファイルと RSS キューRSS Profiles and RSS Queues

既定の RSS 定義済みプロファイルはNumastaticです。これは、以前のバージョンの Windows で使用されていた既定とは異なります。The default RSS predefined profile is NUMAStatic, which differs from the default that the previous versions of Windows used. RSS プロファイルの使用を開始する前に、利用可能なプロファイルを確認して、どのような利点があるか、およびネットワーク環境とハードウェアにどのように適用されるかを理解してください。Before you start using RSS profiles, review the available profiles to understand when they are beneficial and how they apply to your network environment and hardware.

たとえば、タスクマネージャーを開き、サーバー上の論理プロセッサを確認し、受信トラフィックに使用率が低いと思われる場合は、RSS キューの数を既定の2からネットワークアダプターでサポートされている最大の数に増やすことができます。For example, if you open Task Manager and review the logical processors on your server, and they seem to be underutilized for receive traffic, you can try increasing the number of RSS queues from the default of two to the maximum that your network adapter supports. ネットワーク アダプターによっては、ドライバーの一部として RSS キュー数を変更するオプションがあります。Your network adapter might have options to change the number of RSS queues as part of the driver.

ネットワークアダプターのリソースを増やすIncreasing network adapter resources

受信バッファーや送信バッファーなどのリソースを手動で構成できるネットワークアダプターの場合は、割り当てられたリソースを増やす必要があります。For network adapters that allow you to manually configure resources such as receive and send buffers, you should increase the allocated resources.

ネットワーク アダプターによっては、受信バッファーを低く設定して、ホストから割り当てられるメモリを節約している場合があります。Some network adapters set their receive buffers low to conserve allocated memory from the host. 値を低くすると、パケットが損失し、パフォーマンスが低下します。The low value results in dropped packets and decreased performance. そのため、受信量が多いシナリオの場合、受信バッファー値を最大値まで増やすことをお勧めします。Therefore, for receive-intensive scenarios, we recommend that you increase the receive buffer value to the maximum.

注意

ネットワークアダプターがリソースの手動構成を公開しない場合、リソースが動的に構成されるか、リソースが変更できない固定値に設定されます。If a network adapter does not expose manual resource configuration, either it dynamically configures the resources, or the resources are set to a fixed value that cannot be changed.

割り込みモデレーションの有効化Enabling interrupt moderation

割り込みモデレーションを制御するために、一部のネットワークアダプターでは、さまざまな割り込みモデレーションレベル、異なるバッファー合体パラメーター (送信バッファーと受信バッファーの場合は別々)、またはその両方が公開されます。To control interrupt moderation, some network adapters expose different interrupt moderation levels, different buffer coalescing parameters (sometimes separately for send and receive buffers), or both.

CPU にバインドされたワークロードでは、割り込みのモデレーションを考慮する必要があります。You should consider interrupt moderation for CPU-bound workloads. 割り込みモデレーションを使用する場合は、割り込みと待機時間の短縮により、ホストの CPU 節約率と待機時間の間のトレードオフについて検討します。When using interrupt moderation, consider the trade-off between the host CPU savings and latency versus the increased host CPU savings because of more interrupts and less latency. ネットワークアダプターが割り込みのモデレーションを実行しないが、バッファーの合体を公開している場合は、結合されたバッファーの数を増やして、送信または受信ごとにより多くのバッファーを許可することで、パフォーマンスを向上させることができます。If the network adapter does not perform interrupt moderation, but it does expose buffer coalescing, you can improve performance by increasing the number of coalesced buffers to allow more buffers per send or receive.

待機時間の短いパケット処理のパフォーマンスチューニングPerformance tuning for low-latency packet processing

多くのネットワーク アダプターには、オペレーティング システムが原因の待機時間を最適化するオプションがあります。Many network adapters provide options to optimize operating system-induced latency. 待機時間は、ネットワーク ドライバーが着信パケットを処理してから、ネットワーク ドライバーがパケットを返送するまでの経過時間です。Latency is the elapsed time between the network driver processing an incoming packet and the network driver sending the packet back. 通常、この時間はマイクロ秒単位で測定されます。This time is usually measured in microseconds. 比較のために、通常、長距離間のパケット送信の送信時間は、ミリ秒単位 (1 桁大きい単位) で測定されます。For comparison, the transmission time for packet transmissions over long distances is usually measured in milliseconds (an order of magnitude larger). この調整によって、パケットの送信にかかる時間は短縮されません。This tuning will not reduce the time a packet spends in transit.

次に、精度がマイクロ秒のネットワークのパフォーマンス チューニングをいくつか提案します。Following are some performance tuning suggestions for microsecond-sensitive networks.

  • コンピューターの BIOS を、C 状態を無効にして High Performance (高パフォーマンス) に設定します。Set the computer BIOS to High Performance, with C-states disabled. この設定はシステムと BIOS によって変わる点に注意してください。一部のシステムは、オペレーティング システムが電源管理を制御している場合に、パフォーマンスが高くなります。However, note that this is system and BIOS dependent, and some systems will provide higher performance if the operating system controls power management. 電源管理設定の確認と調整は、設定から行うことも、 powercfgコマンドを使用して行うこともできます。You can check and adjust your power management settings from Settings or by using the powercfg command. 詳細については、「 Powercfg のコマンドラインオプション」を参照してください。For more information, see Powercfg Command-Line Options.

  • オペレーティング システムの電源管理プロファイルを 高パフォーマンス システムに設定します。Set the operating system power management profile to High Performance System.

    注意

    システム BIOS が電源管理のオペレーティングシステム制御を無効にするように設定されている場合、この設定は正しく機能しません。This setting does not work properly if the system BIOS has been set to disable operating system control of power management.

  • 静的オフロードを有効にします。Enable static offloads. たとえば、UDP チェックサム、TCP チェックサム、および Send Large Offload (LSO) 設定を有効にします。For example, enable the UDP Checksums, TCP Checksums, and Send Large Offload (LSO) settings.

  • 大量のマルチキャストトラフィックを受信するときなど、トラフィックがマルチストリームになっている場合は、RSS を有効にします。If the traffic is multi-streamed, such as when receiving high-volume multicast traffic, enable RSS.

  • 待機時間をできるだけ短くする必要があるネットワーク カード ドライバーの場合、Interrupt Moderation (割り込み節度) を無効にします。Disable the Interrupt Moderation setting for network card drivers that require the lowest possible latency. この構成は、より多くの CPU 時間を使用し、トレードオフを表す可能性があることに注意してください。Remember, this configuration can use more CPU time and it represents a tradeoff.

  • パケットを処理するプログラム (ユーザー スレッド) に使用されているコアと CPU キャッシュを共有しているコア プロセッサで、ネットワーク アダプターの割り込みと DPC を処理します。Handle network adapter interrupts and DPCs on a core processor that shares CPU cache with the core that is being used by the program (user thread) that is handling the packet. CPU アフィニティの調整を使用してプロセスを特定の論理プロセッサに誘導し、RSS の構成と組み合わせて、この処理を実行することができます。CPU affinity tuning can be used to direct a process to certain logical processors in conjunction with RSS configuration to accomplish this. 割り込み、DPC、ユーザー モード スレッドに同じコアを使用すると、コアの使用に関する ISR、DPC、およびスレッドが競合することで負荷が増えるため、パフォーマンスが低下します。Using the same core for the interrupt, DPC, and user mode thread exhibits worse performance as load increases because the ISR, DPC, and thread contend for the use of the core.

システム管理の割り込みSystem management interrupts

多くのハードウェアシステムでは、エラー修正コード (ECC) メモリエラーの報告、レガシ USB 互換性の維持、ファンの制御、BIOS 制御電源設定の管理など、さまざまなメンテナンス機能にシステム管理割り込み (SMI-S) を使用しています。Many hardware systems use System Management Interrupts (SMI) for a variety of maintenance functions, such as reporting error correction code (ECC) memory errors, maintaining legacy USB compatibility, controlling the fan, and managing BIOS-controlled power settings.

SMI-S はシステムの最高優先度の割り込みで、CPU を管理モードにします。The SMI is the highest-priority interrupt on the system, and places the CPU in a management mode. このモードでは、SMI-S は通常 BIOS に含まれる割り込みサービスルーチンを実行している間、他のすべてのアクティビティをプリエンプションします。This mode preempts all other activity while SMI runs an interrupt service routine, typically contained in BIOS.

残念ながら、この動作によって100マイクロ秒以上の待機時間が急増する可能性があります。Unfortunately, this behavior can result in latency spikes of 100 microseconds or more.

待機時間を最小限にする必要がある場合は、SMI を可能な限り低く抑えることができる BIOS バージョンをハードウェア プロバイダーに問い合わせることをお勧めします。If you need to achieve the lowest latency, you should request a BIOS version from your hardware provider that reduces SMIs to the lowest degree possible. これらの BIOS バージョンは、"低待機時間 BIOS" または "SMI-S 無償 BIOS" と呼ばれることがよくあります。These BIOS versions are frequently referred to as "low latency BIOS" or "SMI free BIOS." 場合によっては、SMI アクティビティが重要な機能 (冷却ファンなど) の制御に使用されているため、ハードウェア プラットフォームで SMI アクティビティを排除できない可能性があります。In some cases, it is not possible for a hardware platform to eliminate SMI activity altogether because it is used to control essential functions (for example, cooling fans).

注意

オペレーティングシステムは、論理プロセッサが特別なメンテナンスモードで実行されているため、SMIs を制御できません。これにより、オペレーティングシステムの介入ができなくなります。The operating system cannot control SMIs because the logical processor is running in a special maintenance mode, which prevents operating system intervention.

TCP のパフォーマンスチューニングPerformance tuning TCP

次の項目を使用して、TCP のパフォーマンスを調整できます。You can use the following items to tune TCP performance.

TCP 受信ウィンドウの自動チューニングTCP receive window autotuning

Windows Vista、Windows Server 2008、およびそれ以降のバージョンの Windows では、Windows ネットワークスタックは、tcp 受信ウィンドウの自動チューニングレベルという機能を使用して、tcp 受信ウィンドウサイズをネゴシエートします。In Windows Vista, Windows Server 2008, and later versions of Windows, the Windows network stack uses a feature that is named TCP receive window autotuning level to negotiate the TCP receive window size. この機能は、tcp ハンドシェイク中に TCP 通信ごとに定義された受信ウィンドウサイズをネゴシエートできます。This feature can negotiate a defined receive window size for every TCP communication during the TCP Handshake.

以前のバージョンの Windows では、Windows ネットワークスタックは固定サイズの受信ウィンドウ (65535 バイト) を使用しています。これにより、接続の総スループットが制限されていました。In earlier versions of Windows, the Windows network stack used a fixed-size receive window (65,535 bytes) that limited the overall potential throughput for connections. TCP 接続の達成可能なスループットの合計によって、ネットワークの使用シナリオが制限される可能性があります。The total achievable throughput of TCP connections could limit network usage scenarios. TCP 受信ウィンドウ自動調整では、これらのシナリオでネットワークを完全に使用できます。TCP receive window autotuning enables these scenarios to fully use the network.

特定のサイズの TCP 受信ウィンドウの場合、次の式を使用して、1つの接続の合計スループットを計算できます。For a TCP receive window that has a particular size, you can use the following equation to calculate the total throughput of a single connection.

達成可能スループットの合計 (バイト単位) = TCP 受信ウィンドウサイズ (バイト) *(1/接続の待機時間 (秒))Total achievable throughput in bytes = TCP receive window size in bytes * (1 / connection latency in seconds)

たとえば、待機時間が10ミリ秒の接続の場合、達成可能なスループットの合計は 51 Mbps です。For example, for a connection that has a latency of 10 ms, the total achievable throughput is only 51 Mbps. この値は、大規模な企業ネットワークインフラストラクチャには適しています。This value is reasonable for a large corporate network infrastructure. ただし、自動チューニングを使用して受信ウィンドウを調整することで、接続は 1 Gbps の接続の完全な回線速度を実現できます。However, by using autotuning to adjust the receive window, the connection can achieve the full line rate of a 1-Gbps connection.

一部のアプリケーションでは、TCP 受信ウィンドウのサイズを定義します。Some applications define the size of the TCP receive window. アプリケーションで受信ウィンドウサイズが定義されていない場合、リンク速度は次のようにサイズを決定します。If the application does not define the receive window size, the link speed determines the size as follows:

  • 1メガビット/秒 (Mbps) 以下: 8 キロバイト (KB)Less than 1 megabit per second (Mbps): 8 kilobytes (KB)
  • 1 mbps ~ 100 Mbps:17 KB1 Mbps to 100 Mbps: 17 KB
  • 100 Mbps ~ 10 ギガビット/秒 (Gbps):64 KB100 Mbps to 10 gigabits per second (Gbps): 64 KB
  • 10 Gbps 以上: 128 KB10 Gbps or faster: 128 KB

たとえば、1 Gbps のネットワークアダプターがインストールされているコンピューターでは、ウィンドウのサイズは 64 KB にする必要があります。For example, on a computer that has a 1-Gbps network adapter installed, the window size should be 64 KB.

また、この機能では、ネットワークのパフォーマンスを向上させるために、他の機能もすべて使用できます。This feature also makes full use of other features to improve network performance. これらの機能には、 RFC 1323で定義されている残りの TCP オプションが含まれます。These features include the rest of the TCP options that are defined in RFC 1323. これらの機能を使用することにより、Windows ベースのコンピューターでは、サイズの小さい TCP 受信ウィンドウサイズをネゴシエートできますが、構成によっては定義された値でスケーリングされます。By using these features, Windows-based computers can negotiate TCP receive window sizes that are smaller but are scaled at a defined value, depending on the configuration. この動作により、ネットワークデバイスのサイズがより簡単に処理できるようになります。This behavior the sizes easier to handle for networking devices.

注意

RFC 1323で定義されているように、ネットワークデバイスがTCP ウィンドウスケールオプションに準拠していないという問題が発生する可能性があります。そのため、はスケールファクターをサポートしていません。You may experience an issue in which the network device is not compliant with the TCP window scale option, as defined in RFC 1323 and, therefore, doesn't support the scale factor. このような場合は、この KB 934430 を参照してください。ファイアウォールデバイスの背後で Windows Vista を使用しようとすると、ネットワーク接続が失敗します。または、ネットワークデバイスベンダーのサポートチームに問い合わせてください。In such cases, refer to this KB 934430, Network connectivity fails when you try to use Windows Vista behind a firewall device or contact the Support team for your network device vendor.

TCP 受信ウィンドウの自動チューニングレベルを確認して構成するReview and configure TCP receive window autotuning level

Netsh コマンドまたは Windows PowerShell コマンドレットを使用して、TCP 受信ウィンドウの自動チューニングレベルを確認または変更できます。You can use either netsh commands or Windows PowerShell cmdlets to review or modify the TCP receive window autotuning level.

注意

Windows 10 または Windows Server 2019 より前のバージョンの Windows では、レジストリを使用して TCP 受信ウィンドウサイズを構成することはできません。Unlike in versions of Windows that pre-date Windows 10 or Windows Server 2019, you can no longer use the registry to configure the TCP receive window size. 非推奨の設定の詳細については、「非推奨の TCP パラメーター」を参照してください。For more information about the deprecated settings, see Deprecated TCP parameters.

注意

使用可能な自動チューニングレベルの詳細については、「自動チューニングレベル」を参照してください。For detailed information about the available autotuning levels, see Autotuning levels.

Netsh を使用して自動チューニングレベルを確認または変更するにはTo use netsh to review or modify the autotuning level

現在の設定を確認するには、コマンドプロンプトウィンドウを開き、次のコマンドを実行します。To review the current settings, open a Command Prompt window and run the following command:

netsh interface tcp show global

このコマンドの出力は次のようになります。The output of this command should resemble the following:

Querying active state...

TCP Global Parameters
-----
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off

この設定を変更するには、コマンドプロンプトで次のコマンドを実行します。To modify the setting, run the following command at the command prompt:

netsh interface tcp set global autotuninglevel=<Value>

注意

上記のコマンドで、は <Value> 自動チューニングレベルの新しい値を表します。In the preceding command, <Value> represents the new value for the auto tuning level.

このコマンドの詳細については、「インターフェイス伝送制御プロトコル用の Netsh コマンド」を参照してください。For more information about this command, see Netsh commands for Interface Transmission Control Protocol.

Powershell を使用して自動チューニングレベルを確認または変更するにはTo use Powershell to review or modify the autotuning level

現在の設定を確認するには、PowerShell ウィンドウを開き、次のコマンドレットを実行します。To review the current settings, open a PowerShell window and run the following cmdlet.

Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

このコマンドレットの出力は、次のようになります。The output of this cmdlet should resemble the following.

SettingName           AutoTuningLevelLocal
-----------          --------------------
Automatic
InternetCustom       Normal
DatacenterCustom     Normal
Compat               Normal
Datacenter           Normal
Internet             Normal

設定を変更するには、PowerShell コマンドプロンプトで次のコマンドレットを実行します。To modify the setting, run the following cmdlet at the PowerShell command prompt.

Set-NetTCPSetting -AutoTuningLevelLocal <Value>

注意

上記のコマンドで、は <Value> 自動チューニングレベルの新しい値を表します。In the preceding command, <Value> represents the new value for the auto tuning level.

これらのコマンドレットの詳細については、次の記事を参照してください。For more information about these cmdlets, see the following articles:

自動チューニングレベルAutotuning levels

受信ウィンドウの自動チューニングは、5つのレベルのいずれかに設定できます。You can set receive window autotuning to any of five levels. 既定のレベルはNormalです。The default level is Normal. 次の表では、これらのレベルについて説明します。The following table describes the levels.

LevelLevel 16 進数値Hexadecimal value コメントComments
[標準] (既定)Normal (default) 0x8 (スケールファクターは 8)0x8 (scale factor of 8) ほとんどすべてのシナリオに対応できるように、TCP 受信ウィンドウを拡張するように設定します。Set the TCP receive window to grow to accommodate almost all scenarios.
無効Disabled 使用できるスケールファクターがありませんNo scale factor available TCP 受信ウィンドウを既定値で設定します。Set the TCP receive window at its default value.
制限付きRestricted 0x4 (スケールファクター 4)0x4 (scale factor of 4) TCP 受信ウィンドウを既定値を超えて拡張するように設定しますが、一部のシナリオではこのような増加を制限します。Set the TCP receive window to grow beyond its default value, but limit such growth in some scenarios.
高制限Highly Restricted 0x2 (スケールファクター 2)0x2 (scale factor of 2) TCP 受信ウィンドウを既定値を超えて拡張するように設定しますが、非常に控えめです。Set the TCP receive window to grow beyond its default value, but do so very conservatively.
実験用Experimental 0xE (スケールファクター 14)0xE (scale factor of 14) 極端なシナリオに対応できるように、TCP 受信ウィンドウを拡張するように設定します。Set the TCP receive window to grow to accommodate extreme scenarios.

アプリケーションを使用してネットワークパケットをキャプチャする場合、アプリケーションは、ウィンドウの自動チューニングレベルの設定に応じて、次のようなデータを報告する必要があります。If you use an application to capture network packets, the application should report data that resembles the following for different window autotuning level settings.

  • 自動チューニングレベル:標準 (既定の状態)Autotuning level: Normal (default state)

    Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2667, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240
    SrcPort: 60975
    DstPort: Microsoft-DS(445)
    SequenceNumber: 4075590425 (0xF2EC9319)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x8 Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 8 -----------------------------> Scale factor, defined by AutoTuningLevel
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル:無効Autotuning level: Disabled

    Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2576, Total IP Length = 48
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240
    SrcPort: 60956
    DstPort: Microsoft-DS(445)
    SequenceNumber: 2315885330 (0x8A099B12)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 112 (0x70)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( ) = 64240 ----------------------------------------> TCP Receive Window set as 64K as per NIC Link bitrate. Note there is no Scale Factor defined. In this case, Scale factor is not being sent as a TCP Option, so it will not be used by Windows.
    Checksum: 0x817E, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル:制限付きAutotuning level: Restricted

    Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2319, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240
    SrcPort: 60890
    DstPort: Microsoft-DS(445)
    SequenceNumber: 1966088568 (0x75302178)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x4 Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by AutoTuningLevel.
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル:高い制限Autotuning level: Highly restricted

    Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2388, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240
    SrcPort: 60903
    DstPort: Microsoft-DS(445)
    SequenceNumber: 1463725706 (0x573EAE8A)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x2 Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by AutoTuningLevel
    + NoOption:
    + NoOption:
    + SACKPermitted:
    
  • 自動チューニングレベル:試験段階Autotuning level: Experimental

    Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
    + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2490, Total IP Length = 52
    - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240
    SrcPort: 60933
    DstPort: Microsoft-DS(445)
    SequenceNumber: 2095111365 (0x7CE0DCC5)
    AcknowledgementNumber: 0 (0x0)
    + DataOffset: 128 (0x80)
    + Flags: ......S. ---------------------------------------------------------> SYN Flag set
    Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0xe Scale Factor.
    Checksum: 0x8182, Bad
    UrgentPointer: 0 (0x0)
    - TCPOptions:
    + MaxSegmentSize: 1
    + NoOption:
    + WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by AutoTuningLevel
    + NoOption:
    + NoOption:
    + SACKPermitted:
    

非推奨の TCP パラメーターDeprecated TCP parameters

Windows Server 2003 の次のレジストリ設定はサポートされなくなり、以降のバージョンでは無視されます。The following registry settings from Windows Server 2003 are no longer supported, and are ignored in later versions.

  • TcpWindowSizeTcpWindowSize
  • NumTcbTablePartitionsNumTcbTablePartitions
  • MaxHashTableSizeMaxHashTableSize

これらの設定はすべて、次のレジストリサブキーにありました。All of these settings were located in the following registry subkey:

HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\Tcpip\ParametersHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Windows フィルタリングプラットフォームWindows Filtering Platform

Windows Vista および Windows Server 2008 では、Windows Filtering Platform (WFP) が導入されました。Windows Vista and Windows Server 2008 introduced the Windows Filtering Platform (WFP). WFP は、Microsoft 以外の独立系ソフトウェアベンダー (Isv) に Api を提供して、パケット処理フィルターを作成します。WFP provides APIs to non-Microsoft independent software vendors (ISVs) to create packet processing filters. たとえば、ファイアウォールとウイルス対策ソフトウェアが含まれています。Examples include firewall and antivirus software.

注意

正しく記述されていない WFP フィルターを使用すると、サーバーのネットワークパフォーマンスが大幅に低下する可能性があります。A poorly-written WFP filter can significantly decrease a server's networking performance. 詳細については、Windows デベロッパーセンターの「パケット処理ドライバーとアプリを WFP に移植する」を参照してください。For more information, see Porting Packet-Processing Drivers and Apps to WFP in the Windows Dev Center.

このガイドのすべてのトピックへのリンクについては、「ネットワークサブシステムのパフォーマンスチューニング」を参照してください。For links to all topics in this guide, see Network Subsystem Performance Tuning.