Azure VM の TCP/IP パフォーマンス チューニングTCP/IP performance tuning for Azure VMs

この記事では、一般的な TCP/IP のパフォーマンス チューニング技法と、それらを Azure で実行している仮想マシンに使用する場合の考慮事項について説明します。This article discusses common TCP/IP performance tuning techniques and some things to consider when you use them for virtual machines running on Azure. 基本的な手法の概要を示し、チューニングする方法を詳しく説明します。It will provide a basic overview of the techniques and explore how they can be tuned.

一般的な TCP/IP チューニング手法Common TCP/IP tuning techniques

MTU、断片化、Large Send Offload (LSO)MTU, fragmentation, and large send offload

MTUMTU

最大転送単位 (MTU) は、ネットワーク インターフェイスを介して送信できる、バイト単位で指定された最大サイズのフレーム (パケット) です。The maximum transmission unit (MTU) is the largest size frame (packet), specified in bytes, that can be sent over a network interface. MTU は、構成可能な設定です。The MTU is a configurable setting. Azure VM 上で使用される既定の MTU と、ほとんどのネットワーク デバイス上のグローバルな既定の設定は、1,500 バイトです。The default MTU used on Azure VMs, and the default setting on most network devices globally, is 1,500 bytes.

断片化Fragmentation

断片化は、ネットワーク インターフェイスの MTU を超えるパケットが送信されるときに発生します。Fragmentation occurs when a packet is sent that exceeds the MTU of a network interface. TCP/IP スタックにより、パケットは、インターフェイスの MTU に準拠したより小さい部分 (フラグメント) に分割されます。The TCP/IP stack will break the packet into smaller pieces (fragments) that conform to the interface's MTU. 断片化は IP レイヤーで行われ、基になるプロトコル (TCP など) には依存しません。Fragmentation occurs at the IP layer and is independent of the underlying protocol (such as TCP). 2,000 バイトのパケットが、MTU が 1,500 であるネットワーク インターフェイスで送信されると、そのパケットは 1,500 バイトのパケット 1 つと 500 バイトのパケット 1 つに分割されます。When a 2,000-byte packet is sent over a network interface with an MTU of 1,500, the packet will be broken down into one 1,500-byte packet and one 500-byte packet.

ソースと宛先の間のパス上にあるネットワーク デバイスには、MTU を超えるパケットを削除するか、パケットをより小さい部分に断片化することができます。Network devices in the path between a source and destination can either drop packets that exceed the MTU or fragment the packet into smaller pieces.

IP パケット内の断片化禁止ビットThe Don’t Fragment bit in an IP packet

断片化禁止ビット (DF) は、IP プロトコル ヘッダー内のフラグです。The Don’t Fragment (DF) bit is a flag in the IP protocol header. DF ビットは、送信者と受信者の間のパス上にあるネットワーク デバイスでパケットを断片化してはならないことを示します。The DF bit indicates that network devices on the path between the sender and receiver must not fragment the packet. このビットは、多くの理由で設定できます。This bit could be set for many reasons. (1 つの例として、この記事の「パス MTU 検出」セクションを参照してください)。断片化禁止ビットが設定されたパケットがネットワーク デバイスによって受信され、そのパケットがデバイスのインターフェイスの MTU を超えている場合、デバイスの標準的な動作は、パケットを削除することです。(See the "Path MTU Discovery" section of this article for one example.) When a network device receives a packet with the Don’t Fragment bit set, and that packet exceeds the device's interface MTU, the standard behavior is for the device to drop the packet. デバイスは、"ICMP Fragmentation Needed" (ICMP 断片化が必要) メッセージをパケットの送信元に戻します。The device sends an ICMP Fragmentation Needed message back to the original source of the packet.

断片化がパフォーマンスに与える影響Performance implications of fragmentation

断片化は、パフォーマンスに悪影響を与えることがあります。Fragmentation can have negative performance implications. パフォーマンスに与える影響の主な理由の 1 つは、パケットの断片化と再構築が CPU/メモリに与える影響です。One of the main reasons for the effect on performance is the CPU/memory impact of the fragmentation and reassembly of packets. ネットワーク デバイスがパケットの断片化を必要とする場合、断片化を実行するための CPU/メモリ リソースを割り当てる必要があります。When a network device needs to fragment a packet, it will have to allocate CPU/memory resources to perform fragmentation.

パケットの再構築時にも同じことが起きます。The same thing happens when the packet is reassembled. ネットワーク デバイスでは、元のパケットに再構築できるように、すべてのフラグメントが受信されるまでそれらを格納しておく必要があります。The network device has to store all the fragments until they're received so it can reassemble them into the original packet. 断片化と再構築のこのプロセスは、待ち時間も生じさせます。This process of fragmentation and reassembly can also cause latency.

断片化について考えられるパフォーマンスへの他の悪影響は、断片化されたパケットが順不同で到着する可能性があることです。The other possible negative performance implication of fragmentation is that fragmented packets might arrive out of order. パケットが順不同で受信されると、ネットワーク デバイスの種類によってはそれらを削除することがあります。When packets are received out of order, some types of network devices can drop them. これが起きた場合、パケット全体を再送信する必要があります。When that happens, the whole packet has to be retransmitted.

フラグメントは一般的に、ネットワーク ファイアウォールなどのセキュリティ デバイスや、ネットワーク デバイスの受信バッファーが使い果たされた場合に削除されます。Fragments are typically dropped by security devices like network firewalls or when a network device’s receive buffers are exhausted. ネットワーク デバイスの受信バッファーが使い果たされた場合、ネットワーク デバイスは断片化されたパケットの再構築を試みますが、パケットを格納して再び取り出すためのリソースがありません。When a network device's receive buffers are exhausted, a network device is attempting to reassemble a fragmented packet but doesn't have the resources to store and reassume the packet.

断片化は否定的な操作と見られることがありますが、断片化のサポートは、インターネット経由で多様なネットワークに接続する場合に必要です。Fragmentation can be seen as a negative operation, but support for fragmentation is necessary when you're connecting diverse networks over the internet.

MTU の変更の利点と結果Benefits and consequences of modifying the MTU

一般に、MTU を大きくすることで、より効率的なネットワークを作成できます。Generally speaking, you can create a more efficient network by increasing the MTU. 送信されるすべてのパケットには、元のパケットに追加されるヘッダー情報があります。Every packet that's transmitted has header information that's added to the original packet. 断片化により多くのパケットが作成されるときは、さらに多くのヘッダー オーバーヘッドが生じ、それによりネットワークの効率が低下します。When fragmentation creates more packets, there's more header overhead, and that makes the network less efficient.

次に例を示します。Here's an example. イーサネット ヘッダーのサイズは、14 バイトに、フレームの一貫性を確保するための 4 バイトのフレーム チェック シーケンスが加算されます。The Ethernet header size is 14 bytes plus a 4-byte frame check sequence to ensure frame consistency. 2,000 バイトのパケットが 1 つ送信された場合、18 バイトのイーサネット オーバーヘッドがネットワークに追加されます。If one 2,000-byte packet is sent, 18 bytes of Ethernet overhead is added on the network. パケットが 1,500 バイトのパケットと 500 バイトのパケットに断片化されている場合は、各パケットが 18 バイトのイーサネット ヘッダーを持ち、合計で 36 バイトになります。If the packet is fragmented into a 1,500-byte packet and a 500-byte packet, each packet will have 18 bytes of Ethernet header, a total of 36 bytes.

MTU を増やしても、必ずしもより効率的なネットワークが作成されるわけでないことに注意してください。Keep in mind that increasing the MTU won't necessarily create a more efficient network. アプリケーションで 500 バイトのパケットのみを送信する場合、MTU が 1,500 バイトか 9,000 バイトかにかかわらず、同じヘッダー オーバーヘッドが存在するようになります。If an application sends only 500-byte packets, the same header overhead will exist whether the MTU is 1,500 bytes or 9,000 bytes. ネットワークは、MTU の影響を受ける大きなパケット サイズを使用している場合にのみ、より効率的になります。The network will become more efficient only if it uses larger packet sizes that are affected by the MTU.

Azure と VM の MTUAzure and VM MTU

Azure VM の既定の MTU は 1,500 バイトです。The default MTU for Azure VMs is 1,500 bytes. Azure Virtual Network スタックでは、1,400 バイトでのパケットの断片化が試行されます。The Azure Virtual Network stack will attempt to fragment a packet at 1,400 bytes.

VM の MTU が 1,500 であっても、1,400 バイトでパケットを断片化するため、仮想ネットワーク スタックは本質的に非効率ではないことに注意してください。Note that the Virtual Network stack isn't inherently inefficient because it fragments packets at 1,400 bytes even though VMs have an MTU of 1,500. ネットワーク パケットの大部分は 1,400 または 1,500 バイトよりかなり小さくなります。A large percentage of network packets are much smaller than 1,400 or 1,500 bytes.

Azure と断片化Azure and fragmentation

Virtual Network スタックは、"順序が正しくないフラグメント"、つまり元の断片化された順序で到着しない断片化されたパケットを削除するように設定されています。Virtual Network stack is set up to drop "out of order fragments," that is, fragmented packets that don't arrive in their original fragmented order. これらのパケットは主に、2018 年 11 月に発表された FragmentSmack と呼ばれるネットワーク セキュリティの脆弱性が原因で削除されます。These packets are dropped mainly because of a network security vulnerability announced in November 2018 called FragmentSmack.

FragmentSmack は、断片化された IPv4 および IPv6 パケットの再構築が Linux カーネルによって処理される方法の欠陥です。FragmentSmack is a defect in the way the Linux kernel handled reassembly of fragmented IPv4 and IPv6 packets. リモートの攻撃者は、この欠陥を利用して、コストの高いフラグメント再構築操作をトリガーします。これは、ターゲット システム上での CPU 使用の増加やサービス拒否攻撃につながる可能性があります。A remote attacker could use this flaw to trigger expensive fragment reassembly operations, which could lead to increased CPU and a denial of service on the target system.

MTU のチューニングTune the MTU

Azure VM の MTU は、その他の任意のオペレーティング システムの場合と同じように構成できます。You can configure an Azure VM MTU, as you can in any other operating system. ただし、MTU を構成する場合は、上記の、Azure で発生する断片化を考慮する必要があります。But you should consider the fragmentation that occurs in Azure, described above, when you're configuring an MTU.

VM の MTU を増やすことは、お客様にお勧めしていません。We don't encourage customers to increase VM MTUs. この説明は、Azure がどのように MTU を実装し、断片化を実行するかを詳しく説明することが目的です。This discussion is meant to explain the details of how Azure implements MTU and performs fragmentation.

重要

MTU を大きくしてもパフォーマンスの向上は見られず、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。Increasing MTU isn't known to improve performance and could have a negative effect on application performance.

Large Send Offload (LSO)Large send offload

Large Send Offload (LSO) では、パケットのセグメント化をイーサネット アダプターにオフロードすることで、ネットワーク パフォーマンスを向上させることができます。Large send offload (LSO) can improve network performance by offloading the segmentation of packets to the Ethernet adapter. LSO が有効になっている場合、TCP/IP スタックでは大きな TCP パケットが作成され、転送前にセグメント化するためにイーサネット アダプターに送信されます。When LSO is enabled, the TCP/IP stack creates a large TCP packet and sends it to the Ethernet adapter for segmentation before forwarding it. LSO の利点は、MTU に準拠したサイズへのパケットのセグメント化から CPU を解放でき、ハードウェアで実行されているイーサネット インターフェイスにその処理をオフロードできることです。The benefit of LSO is that it can free the CPU from segmenting packets into sizes that conform to the MTU and offload that processing to the Ethernet interface where it's performed in hardware. LSO の特典についての詳細については、Large Send Offload のサポートを参照してください。To learn more about the benefits of LSO, see Supporting large send offload.

LSO が有効になっている場合、Azure のお客様では、パケット キャプチャの実行時に大きなフレーム サイズが見られることがあります。When LSO is enabled, Azure customers might see large frame sizes when they perform packet captures. これらの大きなフレーム サイズにより、一部のお客様は、断片化が起きているとか、大きな MTU が使用されていないのに使用されていると考える可能性があります。These large frame sizes might lead some customers to think fragmentation is occurring or that a large MTU is being used when it’s not. LSO により、イーサネット アダプターは、より大きな最大セグメント サイズ (MSS) を TCP/IP スタックにアドバタイズして、さらに大きな TCP パケットを作成します。With LSO, the Ethernet adapter can advertise a larger maximum segment size (MSS) to the TCP/IP stack to create a larger TCP packet. この非セグメント化フレーム全体がイーサネット アダプターに転送され、VM 上で実行されるパケット キャプチャに表示されます。This entire non-segmented frame is then forwarded to the Ethernet adapter and would be visible in a packet capture performed on the VM. しかし、パケットは、イーサネット アダプターによってイーサネット アダプターの MTU に従って多くの小さなフレームに分割されます。But the packet will be broken down into many smaller frames by the Ethernet adapter, according to the Ethernet adapter’s MTU.

TCP/MSS ウィンドウ スケーリングと PMTUDTCP MSS window scaling and PMTUD

TCP 最大セグメント サイズTCP maximum segment size

TCP 最大セグメント サイズ (MSS) は、TCP セグメントのサイズを制限する設定であり、これにより TCP パケットの断片化を避けます。TCP maximum segment size (MSS) is a setting that limits the size of TCP segments, which avoids fragmentation of TCP packets. オペレーティング システムは、通常はこの数式を使用して、MSS を設定します。Operating systems will typically use this formula to set MSS:

MSS = MTU - (IP header size + TCP header size)

IP ヘッダーと TCP ヘッダーは、それぞれ 20 バイト、つまり合計 40 バイトです。The IP header and the TCP header are 20 bytes each, or 40 bytes total. したがって、1,500 の MTU とのインターフェイスでは MSS が 1,460 になります。So an interface with an MTU of 1,500 will have an MSS of 1,460. ただし、MSS は構成可能です。But the MSS is configurable.

この設定は、TCP セッションがソースと宛先の間に設定されている場合に、TCP 3 ウェイ ハンドシェイクで合意されます。This setting is agreed to in the TCP three-way handshake when a TCP session is set up between a source and a destination. 両方の側が MSS 値を送信し、2 つのうち小さい方が TCP 接続に使用されます。Both sides send an MSS value, and the lower of the two is used for the TCP connection.

ソースと宛先の MTU が、MSS の値を決定する唯一の要素ではないことに留意してください。Keep in mind that the MTUs of the source and destination aren't the only factors that determine the MSS value. Azure VPN Gateway をはじめとする VPN ゲートウェイのような中間ネットワーク デバイスには、最適なネットワーク パフォーマンスを実現するためにソースと宛先に依存せずに MTU を調整する機能があります。Intermediary network devices, like VPN gateways, including Azure VPN Gateway, can adjust the MTU independently of the source and destination to ensure optimal network performance.

パス MTU 検出Path MTU Discovery

MSS がネゴシエートされますが、使用できる実際の MSS を示さない場合があります。MSS is negotiated, but it might not indicate the actual MSS that can be used. これは、ソースと宛先の間のパスにある他のネットワーク デバイスが、ソースと宛先よりも低い MTU 値を持つ可能性があるからです。This is because other network devices in the path between the source and the destination might have a lower MTU value than the source and destination. この場合、パケットよりも MTU が小さいデバイスがパケットを破棄します。In this case, the device whose MTU is smaller than the packet will drop the packet. デバイスは、その MTU を含む ICMP Fragmentation Needed (ICMP 断片化が必要) (タイプ 3、コード 4) メッセージを戻します。The device will send back an ICMP Fragmentation Needed (Type 3, Code 4) message that contains its MTU. この ICMP メッセージにより、ソース ホストはそのパス MTU を適宜縮小できます。This ICMP message allows the source host to reduce its Path MTU appropriately. そのプロセスは、パス MTU 検出 (PMTUD) と呼ばれます。The process is called Path MTU Discovery (PMTUD).

PMTUD プロセスは、効率的でなく、ネットワーク パフォーマンスに影響を与えます。The PMTUD process is inefficient and affects network performance. ネットワーク パスの MTU を超えるパケットが送信された場合、それらのパケットはより小さい MSS で再送信される必要があります。When packets are sent that exceed a network path's MTU, the packets need to be retransmitted with a lower MSS. パス上のネットワーク ファイアウォール (一般に PMTUD ブラックホールと呼ばれます) が原因で送信者が ICMP Fragmentation Needed (ICMP 断片化が必要) メッセージを受信しない場合、送信者は MSS を縮小する必要があることを認識せず、パケットを再送信し続けます。If the sender doesn't receive the ICMP Fragmentation Needed message, maybe because of a network firewall in the path (commonly referred to as a PMTUD blackhole), the sender doesn't know it needs to lower the MSS and will continuously retransmit the packet. このため、Azure VM の MTU を増やすことはお勧めしません。This is why we don’t recommend increasing the Azure VM MTU.

VPN および MTUVPN and MTU

(IPsec VPN などの) カプセル化を実行する VM を使用する場合は、パケット サイズと MTU に関するいくつか追加の考慮事項があります。If you use VMs that perform encapsulation (like IPsec VPNs), there are some additional considerations regarding packet size and MTU. VPN は、さらにヘッダーをパケットに追加しますが、これによりパケット サイズが大きくなり、より小さい MSS が必要になります。VPNs add more headers to packets, which increases the packet size and requires a smaller MSS.

Azure の場合、TCP MSS クランプを 1,350 バイトに設定し、トンネル インターフェイス MTU を 1,400 に設定することをお勧めします。For Azure, we recommend that you set TCP MSS clamping to 1,350 bytes and tunnel interface MTU to 1,400. 詳細については、VPN デバイスと IPSec/IKE パラメーターに関するページを参照してください。For more information, see the VPN devices and IPSec/IKE parameters page.

待ち時間、ラウンドトリップ時間、TCP ウィンドウ スケーリングLatency, round-trip time, and TCP window scaling

待ち時間とラウンドトリップ時間Latency and round-trip time

ネットワーク待ち時間は、光ファイバー ネットワーク上では光の速度に左右されます。Network latency is governed by the speed of light over a fiber optic network. 2 台のネットワーク デバイス間のラウンドトリップ時間 (RTT) により、TCP のネットワーク スループットも事実上制御されます。Network throughput of TCP is also effectively governed by the round-trip time (RTT) between two network devices.

RouteRoute 距離Distance 一方向の時間One-way time RTTRTT
ニューヨークからサンフランシスコへNew York to San Francisco 4,148 km4,148 km 21 ミリ秒21 ms 42 ミリ秒42 ms
ニューヨークからロンドンへNew York to London 5,585 km5,585 km 28 ミリ秒28 ms 56 ミリ秒56 ms
ニューヨークからシドニーへNew York to Sydney 15,993 km15,993 km 80 ミリ秒80 ms 160 ミリ秒160 ms

次の表では、2 つの場所間の直線距離を示します。This table shows the straight-line distance between two locations. ネットワークでは、距離は一般的に直線距離より長くなります。In networks, the distance is typically longer than the straight-line distance. 光速により制御される最小 RTT を計算するための単純な数式を次に示します。Here's a simple formula to calculate minimum RTT as governed by the speed of light:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

伝播の速度には、200 を使用できます。You can use 200 for the speed of propagation. これは、光が 1 ミリ秒に移動する、メートル単位の距離です。This is the distance, in meters, that light travels in 1 millisecond.

例として、ニューヨークからサンフランシスコを取り上げてみましょう。Let's take New York to San Francisco as an example. 直線距離は、4,148 km です。The straight-line distance is 4,148 km. 式に値を代入すると、次の解が得られます。Plugging that value into the equation, we get the following:

Minimum RTT = 2 * (4,148 / 200)

式の出力は、ミリ秒単位です。The output of the equation is in milliseconds.

ネットワーク パフォーマンスを最適化する場合、論理的なオプションは、それらの間が最短距離である宛先を選択することです。If you want to get the best network performance, the logical option is to select destinations with the shortest distance between them. トラフィックのパスを最適化して待ち時間を短縮するように仮想ネットワークを設計する必要もあります。You should also design your virtual network to optimize the path of traffic and reduce latency. 詳細については、この記事の「ネットワーク設計に関する考慮事項」セクションを参照してください。For more information, see the "Network design considerations" section of this article.

TCP に対する待ち時間とラウンドトリップ時間の影響Latency and round-trip time effects on TCP

ラウンド トリップ時間は、TCP の最大スループットに直接影響します。Round-trip time has a direct effect on maximum TCP throughput. TCP プロトコルでは、ウィンドウ サイズは、送信者が受信者から受信確認を受信する前に TCP 接続経由で送信できるトラフィックの最大量です。In TCP protocol, window size is the maximum amount of traffic that can be sent over a TCP connection before the sender needs to receive acknowledgement from the receiver. TCP MSS が 1,460 に設定され、TCP ウィンドウ サイズが 65,535 に設定されている場合、送信者は受信者から受信確認を受信する前に 45 パケットを送信できます。If the TCP MSS is set to 1,460 and the TCP window size is set to 65,535, the sender can send 45 packets before it has to receive acknowledgement from the receiver. 送信者が受信確認を取得しない場合は、データは再送信されます。If the sender doesn't get acknowledgement, it will retransmit the data. 数式は次のとおりです。Here's the formula:

TCP window size / TCP MSS = packets sent

この例では、65,535 / 1,460 は 45 に切り上げられます。In this example, 65,535 / 1,460 is rounded up to 45.

信頼性の高いデータ配信を確実にするメカニズムとしてのこの "受信確認待機中" 状態は、RTT が TCP のスループットに影響を与える原因です。This "waiting for acknowledgement" state, a mechanism to ensure reliable delivery of data, is what causes RTT to affect TCP throughput. 送信者が受信確認を待機する期間が長くなるほど、他のデータを送信する前に待機する必要のある時間も長くなります。The longer the sender waits for acknowledgement, the longer it needs to wait before sending more data.

1 つの TCP 接続の最大スループットを計算する数式は次のとおりです。Here's the formula for calculating the maximum throughput of a single TCP connection:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

この表は、1 つの TCP 接続の最大メガバイト/秒のスループットを示しています。This table shows the maximum megabytes/per second throughput of a single TCP connection. (読みやすくするため、メガバイトを測定単位に使用しています。)(For readability, megabytes is used for the unit of measure.)

TCP ウィンドウ サイズ (バイト単位)TCP window size (bytes) RTT 待ち時間 (ミリ秒)RTT latency (ms) 最大メガバイト/秒のスループットMaximum megabyte/second throughput 最大メガビット/秒のスループットMaximum megabit/second throughput
65,53565,535 11 65.5465.54 524.29524.29
65,53565,535 3030 2.182.18 17.4817.48
65,53565,535 6060 1.091.09 8.748.74
65,53565,535 9090 .73.73 5.835.83
65,53565,535 120120 .55.55 4.374.37

パケットが失われた場合、送信者が既に送信されたデータを再送信するときに、TCP 接続の最大スループットが低下します。If packets are lost, the maximum throughput of a TCP connection will be reduced while the sender retransmits data it has already sent.

TCP ウィンドウ スケーリングTCP window scaling

TCP ウィンドウ スケーリングは、TCP ウィンドウ サイズを動的に増やして、受信確認が必要になる前に送信できるデータ量を増やすという技法です。TCP window scaling is a technique that dynamically increases the TCP window size to allow more data to be sent before an acknowledgement is required. 前の例では、受信確認が必要になる前に 45 パケットが送信されます。In the previous example, 45 packets would be sent before an acknowledgement was required. 受信確認の前に送信するパケット数を増やすと、送信者が受信確認を待機する回数が減るので TCP の最大スループットも向上します。If you increase the number of packets that can be sent before an acknowledgement is needed, you're reducing the number of times a sender is waiting for acknowledgement, which increases the TCP maximum throughput.

この表は、これらの関係を示しています。This table illustrates those relationships:

TCP ウィンドウ サイズ (バイト単位)TCP window size (bytes) RTT 待ち時間 (ミリ秒)RTT latency (ms) 最大メガバイト/秒のスループットMaximum megabyte/second throughput 最大メガビット/秒のスループットMaximum megabit/second throughput
65,53565,535 3030 2.182.18 17.4817.48
131,070131,070 3030 4.374.37 34.9534.95
262,140262,140 3030 8.748.74 69.9169.91
524,280524,280 3030 17.4817.48 139.81139.81

ただし、TCP ウィンドウ サイズの TCP ヘッダー値は 2 バイトの長さなので、受信ウィンドウの最大値は 65,535 になります。But the TCP header value for TCP window size is only 2 bytes long, which means the maximum value for a receive window is 65,535. 最大ウィンドウ サイズを大きくするために、TCP ウィンドウ スケール ファクターが導入されました。To increase the maximum window size, a TCP window scale factor was introduced.

スケール ファクターも、オペレーティング システムで構成できる設定です。The scale factor is also a setting that you can configure in an operating system. スケール ファクターを使用して TCP ウィンドウ サイズを計算する数式は次のとおりです。Here's the formula for calculating the TCP window size by using scale factors:

TCP window size = TCP window size in bytes \* (2^scale factor)

ウィンドウ スケール ファクターの 3 とウィンドウ サイズの 65,535 の計算を次に示します。Here's the calculation for a window scale factor of 3 and a window size of 65,535:

65,535 \* (2^3) = 262,140 bytes

14 のスケール ファクターでは TCP ウィンドウ サイズが 14 (最大オフセットを許可) になります。A scale factor of 14 results in a TCP window size of 14 (the maximum offset allowed). TCP ウィンドウ サイズは 1,073,725,440 バイト (8.5 ギガビット) となります。The TCP window size will be 1,073,725,440 bytes (8.5 gigabits).

TCP ウィンドウ スケーリングのサポートSupport for TCP window scaling

Windows では、異なる接続の種類の異なるスケーリング ファクターを設定できます。Windows can set different scaling factors for different connection types. (接続のクラスには、データセンターやインターネットなどが含まれます)。Get-NetTCPConnection PowerShell コマンドを使用して、ウィンドウ スケーリング接続の種類を表示します。(Classes of connections include datacenter, internet, and so on.) You use the Get-NetTCPConnection PowerShell command to view the window scaling connection type:

Get-NetTCPConnection

Get-NetTCPSetting PowerShell コマンドを使用して、各クラスの値を表示できます。You can use the Get-NetTCPSetting PowerShell command to view the values of each class:

Get-NetTCPSetting

初期の TCP ウィンドウ サイズと TCP スケーリング ファクターは、Windows で Set-NetTCPSetting PowerShell コマンドを使用して設定できます。You can set the initial TCP window size and TCP scaling factor in Windows by using the Set-NetTCPSetting PowerShell command. 詳細については、Set-NetTCPSetting を参照してください。For more information, see Set-NetTCPSetting.

Set-NetTCPSetting

AutoTuningLevel の有効な TCP 設定は、次のとおりです。These are the effective TCP settings for AutoTuningLevel:

AutoTuningLevelAutoTuningLevel スケール ファクターScaling factor スケール乗数Scaling multiplier 最大ウィンドウ サイズを
計算するための数式
Formula to
calculate maximum window size
DisabledDisabled なしNone なしNone ウィンドウ サイズWindow size
制限付きRestricted 44 2^42^4 ウィンドウ サイズ * (2^4)Window size * (2^4)
厳しく制限Highly restricted 22 2^22^2 ウィンドウ サイズ * (2^2)Window size * (2^2)
NormalNormal 88 2^82^8 ウィンドウ サイズ * (2^8)Window size * (2^8)
試験段階Experimental 1414 2^142^14 ウィンドウ サイズ * (2^14)Window size * (2^14)

これらの設定は TCP のパフォーマンスに影響する可能性が最も高いものですが、Azure で制御されないインターネット上の他の多くの要素も TCP のパフォーマンスに影響する可能性があることに留意しておいてください。These settings are the most likely to affect TCP performance, but keep in mind that many other factors across the internet, outside the control of Azure, can also affect TCP performance.

MTU サイズを増やすIncrease MTU size

MTU が大きいほど MSS が大きくなるので、MTU を増やすと TCP のパフォーマンスが向上することを疑問に思う場合があります。Because a larger MTU means a larger MSS, you might wonder whether increasing the MTU can increase TCP performance. 答えはおそらく「いいえ」でしょう。Probably not. パケット サイズには、TCP トラフィック以外にも長所と短所があります。There are pros and cons to packet size beyond just TCP traffic. 前述のように、TCP のスループット パフォーマンスに影響を与える最も重要な要素は、TCP ウィンドウ サイズ、パケット損失、RTT です。As discussed earlier, the most important factors affecting TCP throughput performance are TCP window size, packet loss, and RTT.

重要

Azure のお客様に、仮想マシン上の既定の MTU 値を変更することはお勧めしていません。We don't recommend that Azure customers change the default MTU value on virtual machines.

高速ネットワークと受信側のスケーリングAccelerated networking and receive side scaling

Accelerated NetworkingAccelerated networking

仮想マシンのネットワーク機能は、これまでゲスト VM とハイパーバイザー/ホストの両方で CPU を集中的に使用してきました。Virtual machine network functions have historically been CPU intensive on both the guest VM and the hypervisor/host. ホストを通過するすべてのパケットは、ホストの CPU によってソフトウェア内で処理されます。これには、すべての仮想ネットワークのカプセル化/カプセル化解除が含まれます。Every packet that transits through the host is processed in software by the host CPU, including all virtual network encapsulation and decapsulation. そのため、ホストを通過するトラフィックが増えると、CPU の負荷が高くなります。So the more traffic that goes through the host, the higher the CPU load. また、ホストの CPU が他の操作を実行していてビジー状態の場合は、ネットワークのスループットと待ち時間にも影響します。And if the host CPU is busy with other operations, that will also affect network throughput and latency. Azure は、高速ネットワークでこの問題に対処します。Azure addresses this issue with accelerated networking.

高速ネットワークは、Azure のプログラミング可能な社内ハードウェアと SR-IOV などのテクノロジを使用して、一貫性のある非常に短いネットワーク待ち時間を実現します。Accelerated networking provides consistent ultralow network latency via the in-house programmable hardware of Azure and technologies like SR-IOV. 高速ネットワークでは、多くの Azure ソフトウェア定義ネットワーク スタックが CPU を離れて FPGA ベース SmartNIC に移動します。Accelerated networking moves much of the Azure software-defined networking stack off the CPUs and into FPGA-based SmartNICs. この変更により、エンド ユーザー アプリケーションはコンピューティング サイクルを再利用できます。これにより VM の負荷が減り、待ち時間でのジッターや不整合が減ります。This change enables end-user applications to reclaim compute cycles, which puts less load on the VM, decreasing jitter and inconsistency in latency. つまり、パフォーマンスがより決定論的になります。In other words, performance can be more deterministic.

高速ネットワークは、ゲスト VM がホストをバイパスしてホストの SmartNIC との直接データパスを確立できるようにすることで、パフォーマンスを向上させます。Accelerated networking improves performance by allowing the guest VM to bypass the host and establish a datapath directly with a host’s SmartNIC. 高速ネットワークのいくつかの利点は次のとおりです。Here are some benefits of accelerated networking:

  • 待ち時間の短縮/1 秒あたりのパケット数 (pps) の向上:データパスから仮想スイッチを削除することで、ホストにおけるパケットのポリシー処理に必要な時間がなくなるため、VM 内で処理できるパケット数が増加します。Lower latency / higher packets per second (pps): Removing the virtual switch from the datapath eliminates the time packets spend in the host for policy processing and increases the number of packets that can be processed in the VM.

  • ジッターの削減:仮想スイッチの処理は、適用するポリシーの量と、処理を行う CPU のワークロードによって異なります。Reduced jitter: Virtual switch processing depends on the amount of policy that needs to be applied and the workload of the CPU that's doing the processing. ハードウェアへのポリシーの適用をオフロードすると、パケットが直接 VM に配信され、ホストと VM 間の通信とソフトウェアによる干渉やコンテキスト スイッチがなくなるため、そのばらつきはなくなります。Offloading the policy enforcement to the hardware removes that variability by delivering packets directly to the VM, eliminating the host-to-VM communication and all software interrupts and context switches.

  • CPU 使用率の削減:ホストの仮想スイッチをバイパスすることによって、ネットワーク トラフィックを処理するための CPU 使用率を削減できます。Decreased CPU utilization: Bypassing the virtual switch in the host leads to less CPU utilization for processing network traffic.

高速ネットワークを使用するには、該当する各 VM に明示的に有効にする必要があります。To use accelerated networking, you need to explicitly enable it on each applicable VM. 手順については、「高速ネットワークを使った Linux 仮想マシンの作成」を参照してください。See Create a Linux virtual machine with Accelerated Networking for instructions.

Receive Side ScalingReceive side scaling

Receive Side Scaling (RSS) は、受信処理をマルチプロセッサ システム上の複数の CPU に分散することで、ネットワーク トラフィックの受信をより効率的に分散するネットワーク ドライバー テクノロジです。Receive side scaling (RSS) is a network driver technology that distributes the receiving of network traffic more efficiently by distributing receive processing across multiple CPUs in a multiprocessor system. 簡単に言うと、RSS では、1 つだけではなくすべての使用可能な CPU が使用されるので、システムで処理できる受信トラフィックが増えます。In simple terms, RSS allows a system to process more received traffic because it uses all available CPUs instead of just one. RSS の技術的な詳細については、サイド スケーリングの受け取りの概要を参照してください。For a more technical discussion of RSS, see Introduction to receive side scaling.

VM 上で高速ネットワークが有効になっているときに最大のパフォーマンスを実現するには、RSS を有効にする必要があります。To get the best performance when accelerated networking is enabled on a VM, you need to enable RSS. RSS は、高速ネットワークを使用しない VM 上でも利点があります。RSS can also provide benefits on VMs that don’t use accelerated networking. RSS が有効になっているかどうかを判断する方法と、これを有効にすることについては、「Azure 仮想マシンのネットワーク スループットの最適化」を参照してください。For an overview of how to determine if RSS is enabled and how to enable it, see Optimize network throughput for Azure virtual machines.

TCP TIME_WAIT と TIME_WAIT アセシネーションTCP TIME_WAIT and TIME_WAIT assassination

TCP TIME_WAIT は、ネットワークとアプリケーションのパフォーマンスに影響を与えるもう 1 つの一般的な設定です。TCP TIME_WAIT is another common setting that affects network and application performance. 多くのソケットを開閉しているビジーな VM 上では、クライアントまたはサーバー (ソース IP:送信元ポート + 宛先 IP:送信先ポート) として、TCP の通常の動作中に、特定のソケットが最終的に長時間 TIME_WAIT 状態になることがあります。On busy VMs that are opening and closing many sockets, either as clients or as servers (Source IP:Source Port + Destination IP:Destination Port), during the normal operation of TCP, a given socket can end up in a TIME_WAIT state for a long time. この TIME_WAIT 状態は、ソケットを閉じる前に、そのソケットで他のデータを配信できることを意味します。The TIME_WAIT state is meant to allow any additional data to be delivered on a socket before closing it. そのため、TCP/IP スタックは一般に、クライアントの TCP SYN パケットを自動的に削除することにより、ソケットの再利用を防止します。So TCP/IP stacks generally prevent the reuse of a socket by silently dropping the client's TCP SYN packet.

ソケットが TIME_WAIT である時間は構成できます。The amount of time a socket is in TIME_WAIT is configurable. その範囲は 30 ~ 240 秒です。It could range from 30 seconds to 240 seconds. ソケットは有限のリソースであり、同時に使用できるソケット数は構成可能です。Sockets are a finite resource, and the number of sockets that can be used at any given time is configurable. (一般に、使用可能なソケットの数は約 30,000 です。)使用可能なソケットが使い果たされた場合、またはクライアントとサーバーの TIME_WAIT 設定が一致せず、VM が TIME_WAIT 状態のソケットを再利用しようとした場合、新しい接続は TCP SYN パケットが自動的に削除されるために失敗します。(The number of available sockets is typically about 30,000.) If the available sockets are consumed, or if clients and servers have mismatched TIME_WAIT settings, and a VM tries to reuse a socket in a TIME_WAIT state, new connections will fail as TCP SYN packets are silently dropped.

送信ソケットのポート範囲の値は、オペレーティング システムの TCP/IP スタック内で通常は構成可能です。The value for port range for outbound sockets is usually configurable within the TCP/IP stack of an operating system. 同じことが TCP TIME_WAIT 設定とソケットの再利用に当てはまります。The same thing is true for TCP TIME_WAIT settings and socket reuse. これらの数を変更すると、スケーラビリティが向上する可能性があります。Changing these numbers can potentially improve scalability. ただし、状況によっては、これらの変更により相互運用性の問題が発生する可能性があります。But, depending on the situation, these changes could cause interoperability issues. これらの値を変更する場合は注意する必要があります。You should be careful if you change these values.

TIME_WAIT アセシネーションを使用して、このスケールの制限に対処できます。You can use TIME_WAIT assassination to address this scaling limitation. TIME_WAIT アセシネーションにより、新しい接続の IP パケット内のシーケンス番号が以前の接続の最後のパケットのシーケンス番号を超えたときのような一部の状況で、ソケットを再利用できます。TIME_WAIT assassination allows a socket to be reused in certain situations, like when the sequence number in the IP packet of the new connection exceeds the sequence number of the last packet from the previous connection. この場合、オペレーティング システムにより、新しい接続の確立 (新しい SYN ACK の受け入れ) が許可され、TIME_WAIT 状態だった以前の接続が強制的に終了されます。In this case, the operating system will allow the new connection to be established (it will accept the new SYN/ACK) and force close the previous connection that was in a TIME_WAIT state. この機能は、Azure の Windows VM でサポートされます。This capability is supported on Windows VMs in Azure. 他の VM でのサポートについては、OS ベンダーにお問い合わせください。To learn about support in other VMs, check with the OS vendor.

TCP TIME_WAIT の構成に関するドキュメントについては、「Settings that can be modified to improve network performance (ネットワーク パフォーマンスを向上させるために変更可能な設定)」をご覧ください。To learn about configuring TCP TIME_WAIT settings and source port range, see Settings that can be modified to improve network performance.

パフォーマンスに影響する可能性のある仮想ネットワーク要素Virtual network factors that can affect performance

VM の最大送信スループットVM maximum outbound throughput

Azure の VM には多様なサイズと種類があり、パフォーマンス機能の組み合わせもそれぞれ異なっています。Azure provides a variety of VM sizes and types, each with a different mix of performance capabilities. これらのパフォーマンス機能の 1 つがネットワーク スループット (帯域幅) で、メガビット/秒 (Mbps) で測定されます。One of these capabilities is network throughput (or bandwidth), which is measured in megabits per second (Mbps). 仮想マシンは共有ハードウェアでホストされているため、同じハードウェアを使用する仮想マシン間でネットワーク容量が公平に分配される必要があります。Because virtual machines are hosted on shared hardware, the network capacity needs to be shared fairly among the virtual machines using the same hardware. 大きな仮想マシンには、小さい仮想マシンよりも多くの帯域幅が割り当てられます。Larger virtual machines are allocated more bandwidth than smaller virtual machines.

各仮想マシンに割り当てられたネットワーク帯域幅は、仮想マシンからのエグレス (送信) トラフィックで測定されます。The network bandwidth allocated to each virtual machine is metered on egress (outbound) traffic from the virtual machine. 仮想マシンから送信されるすべてのネットワーク トラフィックは、送信先に関係なく、割り当てられた制限に達するまでカウントされます。All network traffic leaving the virtual machine is counted toward the allocated limit, regardless of destination. たとえば、ある仮想マシンの制限が 1,000 Mbps である場合、送信トラフィックの送信先が同じ仮想ネットワーク内の仮想マシンであっても Azure 外部であっても、この制限が適用されます。For example, if a virtual machine has a 1,000-Mbps limit, that limit applies whether the outbound traffic is destined for another virtual machine in the same virtual network or one outside of Azure.

受信は、直接的には測定も制限もされません。Ingress is not metered or limited directly. ただし、CPU やストレージの制限などの他の要素がある場合、仮想マシンの受信データ処理機能に影響する可能性があります。But there are other factors, like CPU and storage limits, that can affect a virtual machine’s ability to process incoming data.

高速ネットワークは、ネットワーク パフォーマンス (待ち時間、スループット、CPU 使用率など) の向上を目的として設計されています。Accelerated networking is designed to improve network performance, including latency, throughput, and CPU utilization. 高速ネットワークは仮想マシンのスループットを向上させますが、向上できるのは仮想マシンに割り当てられた帯域幅までです。Accelerated networking can improve a virtual machine’s throughput, but it can do that only up to the virtual machine’s allocated bandwidth.

Azure 仮想マシンには常に少なくとも 1 つのネットワーク インターフェイスが接続されている必要があります。Azure virtual machines have at least one network interface attached to them. 複数を接続することができます。They might have several. 仮想マシンに割り当てられる帯域幅は、マシンに接続されているすべてのネットワーク インターフェイス全体の送信トラフィックの合計です。The bandwidth allocated to a virtual machine is the sum of all outbound traffic across all network interfaces attached to the machine. つまり、帯域幅は仮想マシンごとに割り当てられており、マシンに接続されているネットワーク インターフェイスの数は関係ありません。In other words, the bandwidth is allocated on a per-virtual machine basis, regardless of how many network interfaces are attached to the machine.

VM の各サイズでサポートされる予想される送信スループットとサポートされるネットワーク インターフェイスの数については、「Azure での Windows の VM サイズ」で詳しく説明しています。Expected outbound throughput and the number of network interfaces supported by each VM size are detailed in Sizes for Windows virtual machines in Azure. 最大スループットを表示するには、汎用などの種類を選択し、表示されたページにサイズ シリーズに関するセクション (たとえば、「Dv2-series」) を見つけます。To see maximum throughput, select a type, like General purpose, and then find the section about the size series on the resulting page (for example, "Dv2-series"). 各シリーズに、"最大 NIC 数/想定ネットワーク帯域幅 (Mbps)" というタイトルの最終列でネットワーク仕様を提供する表があります。For each series, there's a table that provides networking specifications in the last column, which is titled "Max NICs / Expected network bandwidth (Mbps)."

このスループット制限が仮想マシンに適用されます。The throughput limit applies to the virtual machine. スループットは、次の要因の影響を受けません。Throughput is not affected by these factors:

  • ネットワーク インターフェイスの数:帯域幅の制限は、仮想マシンからのすべての送信トラフィックに適用されます。Number of network interfaces: The bandwidth limit applies to the sum of all outbound traffic from the virtual machine.

  • 高速ネットワーク:この機能は公開されている制限までの達成には役立ちますが、制限を変更することはありません。Accelerated networking: Though this feature can be helpful in achieving the published limit, it doesn't change the limit.

  • トラフィックの送信先:すべての送信先が、送信制限に達するまでカウントされます。Traffic destination: All destinations count toward the outbound limit.

  • プロトコル:すべてのプロトコルに対するすべての送信トラフィックが、制限に達するまでカウントされます。Protocol: All outbound traffic over all protocols counts towards the limit.

詳しくは、「仮想マシンのネットワーク帯域幅」を参照してください。For more information, see Virtual machine network bandwidth.

インターネットのパフォーマンスに関する考慮事項Internet performance considerations

この記事全体を通して説明するように、インターネット上の要素と Azure の制御外の要素がネットワーク パフォーマンスに影響する可能性があります。As discussed throughout this article, factors on the internet and outside the control of Azure can affect network performance. 次のような要素があります。Here are some of those factors:

  • 待ち時間:2 つの宛先の間のラウンドトリップ時間は、中間ネットワーク上の問題、"最短" 距離のパスをとることができないトラフィック、および最適ではないピアリング パスの影響を受ける可能性があります。Latency: The round-trip time between two destinations can be affected by issues on intermediate networks, by traffic that doesn't take the "shortest" distance path, and by suboptimal peering paths.

  • パケット損失:パケット損失は、ネットワークの輻輳、物理パスの問題、およびパフォーマンスが平均を下回るネットワーク デバイスが原因となっている可能性があります。Packet loss: Packet loss can be caused by network congestion, physical path issues, and underperforming network devices.

  • MTU サイズ/断片化:パス上での断片化は、データの到着遅延や正しくない順序でのパケットの到着につながる場合があり、これがパケットの配信に影響する可能性があります。MTU size/Fragmentation: Fragmentation along the path can lead to delays in data arrival or in packets arriving out of order, which can affect the delivery of packets.

Traceroute は、ソース デバイスと宛先デバイス間のすべてのネットワーク パス上でネットワーク パフォーマンスの特性 (パケット損失や待ち時間など) を測定するための優れたツールです。Traceroute is a good tool for measuring network performance characteristics (like packet loss and latency) along every network path between a source device and a destination device.

ネットワーク設計に関する考慮事項Network design considerations

この記事の前のほうで説明した考慮事項とともに、仮想ネットワークのトポロジは、ネットワークのパフォーマンスに影響します。Along with the considerations discussed earlier in this article, the topology of a virtual network can affect the network's performance. たとえば、トラフィックを単一ハブの仮想ネットワークにグローバルにバックホールするハブ アンド スポーク設計では、ネットワーク遅延が生じるので、ネットワークの全体的なパフォーマンスに影響があります。For example, a hub-and-spoke design that backhauls traffic globally to a single-hub virtual network will introduce network latency, which will affect overall network performance.

ネットワーク トラフィックが通過するネットワーク デバイスの数も全体的な待ち時間に影響することがあります。The number of network devices that network traffic passes through can also affect overall latency. たとえば、ハブ アンド スポーク設計では、トラフィックがインターネットに送信される前にスポークのネットワーク仮想アプライアンスとハブの仮想アプライアンスを通過する場合、ネットワーク仮想アプライアンスによって待ち時間が生じる可能性があります。For example, in a hub-and-spoke design, if traffic passes through a spoke network virtual appliance and a hub virtual appliance before transiting to the internet, the network virtual appliances can introduce latency.

Azure リージョン、仮想ネットワーク、待ち時間Azure regions, virtual networks, and latency

Azure リージョンは、一般的な地理的領域内に存在する複数のデータ センターで構成されます。Azure regions are made up of multiple datacenters that exist within a general geographic area. これらのデータセンターは、物理的に並んでいない場合があります。These datacenters might not be physically next to each other. 場合によっては 10 キロメートルほど離れています。In some cases they're separated by as much as 10 kilometers. 仮想ネットワークとは、Azure の物理データセンター ネットワーク上の論理オーバーレイです。The virtual network is a logical overlay on top of the Azure physical datacenter network. 仮想ネットワークは、データセンター内のいずれかの特定のネットワーク トポロジのことを意味しません。A virtual network doesn't imply any specific network topology within the datacenter.

たとえば、2 つの VM が同じ仮想ネットワークとサブネット内にあっても、異なるラック、列、さらにはデータセンターにある可能性があります。For example, two VMs that are in the same virtual network and subnet might be in different racks, rows, or even datacenters. これらを分離している光ファイバー ケーブルの長さは、1 フィートの場合も数 km の場合もあります。They could be separated by feet of fiber optic cable or by kilometers of fiber optic cable. このバリエーションは、異なる VM 間に可変の待ち時間 (数ミリ秒の差異) をもたらす可能性があります。This variation could introduce variable latency (a few milliseconds difference) between different VMs.

VM の地理的な配置および 2 つの VM 間の潜在的な結果の待ち時間は、可用性セットと可用性ゾーンの構成により影響を受ける可能性があります。The geographic placement of VMs, and the potential resulting latency between two VMs, can be influenced by the configuration of availability sets and Availability Zones. しかしリージョン内のデータセンター間の距離はリージョン固有であり、主としてリージョン内のデータセンター トポロジによって影響を受けます。But the distance between datacenters in a region is region-specific and primarily influenced by datacenter topology in the region.

送信元 NAT ポートの不足Source NAT port exhaustion

Azure 内のデプロイでは、パブリック インターネットまたはパブリック IP 空間、あるいはその両方にある、Azure 外部のエンドポイントと通信できます。A deployment in Azure can communicate with endpoints outside of Azure on the public internet and/or in the public IP space. インスタンスが送信接続を開始すると、Azure によってプライベート IP アドレスがパブリック IP アドレスに動的にマッピングされます。When an instance initiates an outbound connection, Azure dynamically maps the private IP address to a public IP address. Azure がこのマッピングを作成すると、この送信フローの戻りトラフィックも、フローの送信元であるプライベート IP アドレスに到達できます。After Azure creates this mapping, return traffic for the outbound originated flow can also reach the private IP address where the flow originated.

送信接続ごとに、このマッピングが Azure Load Balancer によって一定期間維持される必要があります。For every outbound connection, the Azure Load Balancer needs to maintain this mapping for some period of time. Azure のマルチテナントの性質により、すべての VM のすべての送信フローについてこのマッピングを保持すると、大量のリソースが消費される可能性があります。With the multitenant nature of Azure, maintaining this mapping for every outbound flow for every VM can be resource intensive. そのため、Azure Virtual Network の構成に基づいて制限が設定されます。So there are limits that are set and based on the configuration of the Azure Virtual Network. または、より正確に言うと、Azure VM では特定の時点に特定の数の送信接続のみ確立できます。Or, to say that more precisely, an Azure VM can only make a certain number of outbound connections at a given time. これらの制限に達すると、VM はそれ以上発信接続を作成できません。When these limits are reached, the VM won't be able to make more outbound connections.

ただしこの動作は構成できません。But this behavior is configurable. SNAT と SNAT ポートの不足について詳しくは、こちらの記事をご覧ください。For more information about SNAT and SNAT port exhaustion, see this article.

Azure 上でのネットワーク パフォーマンスの測定Measure network performance on Azure

この記事のパフォーマンスの最大値は、2 つの VM 間のネットワーク待ち時間/ラウンドトリップ時間 (RTT) に関連しています。A number of the performance maximums in this article are related to the network latency / round-trip time (RTT) between two VMs. ここでは、待ち時間/RTT をテストする方法と、TCP のパフォーマンスと VM ネットワークのパフォーマンスをテストする方法についての推奨事項を示します。This section provides some suggestions for how to test latency/RTT and how to test TCP performance and VM network performance. このセクションで説明する手法を使用して、前に説明したTCP/IP とネットワークの値のチューニングとパフォーマンステストを行うことができます。You can tune and performance test the TCP/IP and network values discussed earlier by using the techniques described in this section. 待ち時間、MTU、MSS、およびウィンドウ サイズの値を前述の計算に代入し、テスト中に、理論上の最大値と観察された実際の値を比較します。You can plug latency, MTU, MSS, and window size values into the calculations provided earlier and compare theoretical maximums to actual values that you observe during testing.

ラウンドトリップ時間とパケット損失の測定Measure round-trip time and packet loss

TCP のパフォーマンスは、RTT とパケット損失に大きく依存します。TCP performance relies heavily on RTT and packet Loss. Windows と Linux で使用可能な ping ユーティリティは、RTT とパケット損失を測定する最も簡単な方法となります。The PING utility available in Windows and Linux provides the easiest way to measure RTT and packet loss. ping の出力は、ソースと宛先の間の最小/最大/平均待ち時間を示します。The output of PING will show the minimum/maximum/average latency between a source and destination. パケット損失も表示されます。It will also show packet loss. ping では、既定で ICMP プロトコルが使用されます。PING uses the ICMP protocol by default. PsPing を使用して、TCP RTT をテストできます。You can use PsPing to test TCP RTT. 詳細については、「PsPing」を参照してください。For more information, see PsPing.

TCP 接続の実際のスループットの測定Measure actual throughput of a TCP connection

NTttcp は、Linux または Windows VM の TCP パフォーマンスをテストするためのツールです。NTttcp is a tool for testing the TCP performance of a Linux or Windows VM. TCP のさまざまな設定を変更し、NTttcp を使用してその利点をテストできます。You can change various TCP settings and then test the benefits by using NTttcp. 詳細については、次のリソースを参照してください。For more information, see these resources:

仮想マシンの実際の帯域幅の測定Measure actual bandwidth of a virtual machine

各種 VM タイプのパフォーマンスや高速ネットワークなどは、iPerf と呼ばれるツールを使用してテストできます。You can test the performance of different VM types, accelerated networking, and so on, by using a tool called iPerf. iPerf は Linux と Windows でも利用できます。iPerf is also available on Linux and Windows. iPerf では、TCP または UDP を使用してネットワークの全体的なスループットをテストできます。iPerf can use TCP or UDP to test overall network throughput. iPerf TCP のスループット テストは、この記事で説明した要素 (待ち時間や RTT など) の影響を受けます。iPerf TCP throughput tests are influenced by the factors discussed in this article (like latency and RTT). 最大スループットをテストする場合、UDP がより良い結果を生成する可能性があります。So UDP might yield better results if you just want to test maximum throughput.

詳細と例については、次の記事をご覧ください。For more information, see these articles:

非効率的な TCP 動作の検出Detect inefficient TCP behaviors

パケット キャプチャで、Azure のお客様は、ネットワーク パフォーマンスの問題を示している可能性のある TCP フラグ (SACK、DUP ACK、RETRANSMIT、FAST RETRANSMIT) の付いた TCP パケットを見つける場合があります。In packet captures, Azure customers might see TCP packets with TCP flags (SACK, DUP ACK, RETRANSMIT, and FAST RETRANSMIT) that could indicate network performance problems. 具体的には、これらのパケットは、パケット損失の結果であるネットワークの非効率性を示しています。These packets specifically indicate network inefficiencies that result from packet loss. しかし、パケット損失は必ずしも Azure のパフォーマンスの問題によって発生するわけではありません。But packet loss isn't necessarily caused by Azure performance problems. パフォーマンスの問題は、アプリケーションの問題、オペレーティング システムの問題、またはその他の Azure プラットフォームに直接には関連しない問題の結果である可能性があります。Performance problems could be the result of application problems, operating system problems, or other problems that might not be directly related to the Azure platform.

さらに、いくらかの再送信や重複 ACK は、ネットワーク上では普通に見られることに注意してください。Also, keep in mind that some retransmission and duplicate ACKs are normal on a network. TCP プロトコルは信頼できるものとなるように構築されました。TCP protocols were built to be reliable. パケット キャプチャにおけるこれらの TCP パケットの証拠は、過剰でない限り、必ずしもシステム的なネットワークの問題を示していません。Evidence of these TCP packets in a packet capture doesn't necessarily indicate a systemic network problem, unless they're excessive.

ただし、これらのパケットの種類は、TCP のスループットがこの記事の他のセクションで説明した理由により最大パフォーマンスを達成していないことを示します。Still, these packet types are indications that TCP throughput isn't achieving its maximum performance, for reasons discussed in other sections of this article.

次の手順Next steps

これで Azure VM の TCP/IP パフォーマンス チューニングについて学習したので、仮想ネットワークの計画の他の考慮事項について読んだり、仮想ネットワークの接続と構成の詳細について調べたりできます。Now that you've learned about TCP/IP performance tuning for Azure VMs, you might want to read about other considerations for planning virtual networks or learn more about connecting and configuring virtual networks.