Optimierung der TCP/IP-Leistung für Azure-VMs

2025-06-16

In diesem Artikel werden gängige Techniken zur TCP/IP-Leistungsoptimierung sowie einige Punkte beschrieben, die zu beachten sind, wenn Sie diese Techniken für virtuelle Computer verwenden, die unter Azure ausgeführt werden. Es bietet eine grundlegende Übersicht über die Techniken und untersucht, wie virtuelle Computer abgestimmt werden können.

Allgemeine Techniken zur TCP/IP-Leistungsoptimierung

Maximale Übertragungseinheit (MTU), Fragmentierung und Large Send Offload

MTU

Die maximale Übertragungseinheit (MTU) ist der größte Frame (Paket plus Netzwerkzugriffsheader), der in Bytes angegeben ist, die über eine Netzwerkschnittstelle gesendet werden können. Die MTU ist eine konfigurierbare Einstellung. Die Standard-MTU, die auf Azure-VMs verwendet wird, und die Standardeinstellung auf den meisten Netzwerkgeräten weltweit, beträgt 1.500 Bytes.

Fragmentierung

Fragmentierung tritt auf, wenn ein Paket gesendet wird, dessen Größe die MTU einer Netzwerkschnittstelle überschreitet. Der TCP/IP-Stapel unterbricht das Paket in kleinere Teile (Fragmente), die der MTU der Schnittstelle entsprechen. Die Fragmentierung erfolgt auf der IP-Ebene und ist unabhängig vom zugrunde liegenden Protokoll (z.B. TCP). Wenn ein 2.000-Byte-Paket über eine Netzwerkschnittstelle mit einer MTU von 1.500 gesendet wird, wird das Paket in ein 1.500-Byte-Paket und ein 500-Byte-Paket aufgeteilt.

Netzwerkgeräte im Pfad zwischen Quelle und Ziel können Pakete, die die MTU überschreiten, entweder verwerfen oder in kleinere Teile zerlegen.

Das „Don‘t Fragment“-Bit in einem IP-Paket

Das „Don‘t Fragment“-Bit (DF-Bit) ist ein Flag im IP-Protokollheader. Das DF-Bit kennzeichnet, dass Netzwerkgeräte auf dem Weg zwischen dem Sender und dem Empfänger das Paket nicht fragmentieren dürfen. Dieses Bit kann aus vielen Gründen festgelegt sein. (Ein Beispiel finden Sie in diesem Artikel im Abschnitt „Path MTU Discovery“.) Wenn ein Netzwerkgerät ein Paket mit gesetztem „Don‘t Fragment“-Bit empfängt und dieses Paket die MTU der Geräteschnittstelle überschreitet, besteht das Standardverhalten des Geräts darin, das Paket zu verwerfen. Das Gerät sendet eine „ICMP Fragmentation Needed“-Nachricht zurück an die ursprüngliche Quelle des Pakets.

Leistungsauswirkungen der Fragmentierung

Eine Fragmentierung kann sich negativ auf die Leistung auswirken. Einer der Hauptgründe für die Auswirkung auf die Leistung ist der CPU-/Speichereffekt der Fragmentierung und erneutes Zusammenbauen von Paketen. Wenn ein Netzwerkgerät ein Paket fragmentieren muss, muss es CPU-/Arbeitsspeicherressourcen zuweisen, um Fragmentierung durchzuführen.

Das Gleiche passiert, wenn das Paket wieder zusammengesetzt wird. Das Netzwerkgerät muss alle Fragmente bis zum Empfang speichern, damit es sie wieder zum ursprünglichen Paket zusammensetzen kann.

Azure und Fragmentierung

Azure verarbeitet keine fragmentierten Pakete mit beschleunigtem Netzwerk. Wenn ein virtueller Computer ein fragmentiertes Paket empfängt, verarbeitet der nicht entschleunigte Pfad es. Daher verpassen fragmentierte Pakete die Vorteile des beschleunigten Netzwerks, z. B. geringere Latenz, reduzierte Jitter und höhere Pakete pro Sekunde. Aus diesem Grund wird empfohlen, die Fragmentierung nach Möglichkeit zu vermeiden.

Azure verwirft standardmäßig fragmentierte Pakete, die nicht in der richtigen Reihenfolge auf der virtuellen Maschine ankommen, was bedeutet, dass die Pakete nicht mit ihrer Übertragungssequenz vom Quellendpunkt übereinstimmen. Dieses Problem kann auftreten, wenn Pakete über das Internet oder andere große WANs übertragen werden.

Anpassen der MTU

Sie können den internen Virtuellen Netzwerkdurchsatz verbessern, indem Sie die MTU für den Datenverkehr Ihres virtuellen Computers erhöhen. Wenn die VM jedoch mit Zielen außerhalb des virtuellen Netzwerks kommuniziert, die eine andere MTU aufweisen, kann die Fragmentierung auftreten und die Leistung verringern.

Weitere Informationen zum Festlegen der MTU auf Azure-VMs finden Sie unter Configure Maximum Transmission Unit (MTU) für virtuelle Computer in Azure.

Large Send Offload

Großes Sende-Offload (LSO) kann die Netzwerkleistung verbessern, indem es die Segmentierung von Paketen an den Ethernet-Adapter überträgt. Wenn LSO aktiviert ist, erstellt der TCP/IP-Stapel ein großes TCP-Paket und sendet es zur Segmentierung an den Ethernet-Adapter, bevor er weitergeleitet wird. Der Vorteil von LSO besteht darin, die CPU von der Aufgabe zu befreien, Pakete in Größen zu segmentieren, die der MTU entsprechen, und diese Verarbeitung an die Ethernet-Schnittstellenhardware zu übergeben. Weitere Informationen zu den Vorteilen von LSO finden Sie unter Unterstützung von Large Send Offload.

Wenn LSO aktiviert ist, bemerken Azure-Kunden möglicherweise große Framegrößen während der Paketerfassung. Diese großen Framegrößen können dazu führen, dass einige Kunden davon ausgehen, dass eine Fragmentierung auftritt oder eine große MTU verwendet wird, obwohl dies nicht der Fall ist. Mit LSO kann der Ethernet-Adapter eine größere maximale Segmentgröße (MSS) für den TCP/IP-Stapel ankündigen, um ein größeres TCP-Paket zu erstellen. Der Ethernet-Adapter bricht dann diesen gesamten nicht segmentierten Frame entsprechend seiner MTU in viele kleinere Frames auf, die in einer auf der VM ausgeführten Paketerfassung sichtbar sind.

TCP-MSS-Fensterskalierung und PMTUD

Maximale TCP-Segmentgröße

Die maximale TCP-Segmentgröße (Maximum Segment Size, MSS) ist eine Einstellung, die die Größe von TCP-Segmenten beschränkt, wodurch Fragmentierung der TCP-Pakete vermieden wird. Bei Betriebssystemen wird in der Regel diese Formel zum Festlegen von MSS verwendet:

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

Der IP-Header und der TCP-Header haben jeweils 20 Bytes, zusammen also 40 Bytes. Eine Schnittstelle mit einer MTU von 1.500 hat einen MSS von 1.460. MsS kann konfiguriert werden.

Diese Einstellung wird im TCP-Drei-Wege-Handschlag vereinbart, wenn eine TCP-Sitzung zwischen einer Quelle und einem Ziel eingerichtet wird. Beide Seiten senden einen MSS-Wert, und der niedrigere der beiden wird für die TCP-Verbindung verwendet.

Bedenken Sie, dass die MTUs der Quelle und des Ziels nicht die einzigen Faktoren sind, die den MSS-Wert bestimmen. Zwischengeschaltete Netzwerkgeräte, etwa VPN-Gateways, so auch Azure VPN Gateway, können die MTU unabhängig von Quelle und Ziel anpassen, um eine optimale Netzwerkleistung zu gewährleisten.

Path MTU Discovery

MSS wird ausgehandelt, aber diese kennzeichnet möglicherweise nicht die tatsächliche MSS, die verwendet werden kann. Andere Netzwerkgeräte im Pfad zwischen der Quelle und dem Ziel haben möglicherweise einen niedrigeren MTU-Wert als die Quelle und das Ziel. In diesem Fall verwirft das Gerät, dessen MTU kleiner ist als das Paket, das Paket. Das Gerät sendet eine ICMP Fragmentation Needed-Nachricht (Typ 3, Code 4) zurück, die die MTU des Geräts enthält. Diese ICMP-Nachricht ermöglicht es dem Quellhost, seine Path-MTU entsprechend zu reduzieren. Der Prozess wird als „Path MTU Discovery“ (PMTUD) bezeichnet.

Der PMTUD-Prozess reduziert die Netzwerkleistung aufgrund seiner Ineffizienz. Wenn die MTU eines Netzwerkpfads überschritten wird, müssen Pakete mit einem niedrigeren MSS erneut übertragen werden. Wenn eine Netzwerkfirewall die ICMP-Fragmentierungsanforderungsnachricht blockiert, ist dem Absender nicht bewusst, dass die MSS verringert und das Paket wiederholt erneut übertragen werden muss. Aus diesem Grund raten wir davon ab, die Azure VM MTU zu erhöhen.

VPN und MTU

Wenn Sie VMs verwenden, die Kapselung (z. B. IPsec VPNs) durchführen, gibt es einige weitere Überlegungen zu Paketgröße und MTU. VPNs fügen paketen weitere Header hinzu. Die hinzugefügten Header erhöhen die Paketgröße und erfordern ein kleineres MSS.

Für Azure lautet die Empfehlung, TCP-MSS-Clamping auf 1.350 Bytes und die MTU der Tunnelschnittstelle auf 1.400 festzulegen. Weitere Informationen finden Sie auf der Seite VPN-Geräte und IPsec-/IKE-Parameter.

Latenz, Paketumlaufzeit und TCP-Fensterskalierung

Latenz und Paketumlaufzeit

Die Lichtgeschwindigkeit bestimmt die Netzwerklatenz über ein Glasfasernetz. Die RTT (Roundtrip Time) zwischen zwei Netzwerkgeräten stimmt den TCP-Netzwerkdurchsatz ab.

Route	Entfernung	Unidirektionale Zeit	RTT
New York nach San Francisco	4.148 km	21 ms	42 ms
New York nach London	5.585 km	28 ms	56 ms
New York nach Sydney	15.993 km	80 ms	160 ms

Diese Tabelle zeigt die Entfernung in Luftlinie zwischen zwei Orten. In Netzwerken ist die Entfernung in der Regel länger als die gerade Strecke. Dies ist eine einfache Formel zur Berechnung der minimalen RTT, die von der Lichtgeschwindigkeit bestimmt wird:

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

Sie können 200 für die Ausbreitungsgeschwindigkeit (speed of propagation) verwenden. Die Geschwindigkeit der Ausbreitung ist die Entfernung in Kilometern, die licht in 1 Millisekunden reist.

Nehmen Sie die Strecke New York nach San Francisco als Beispiel. Die Luftlinie beträgt 4.148 km. Die Eingabe dieses Werts in die Formel führt zu der folgenden Formel:

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

Das Ergebnis der Gleichung ist in Millisekunden.

Wenn Sie die beste Netzwerkleistung erreichen möchten, besteht die logische Option darin, Ziele auszuwählen, zu denen die kürzesten Abstände vorliegen. Sie sollten auch Ihr virtuelles Netzwerk so gestalten, dass der Pfad des Datenverkehrs optimiert und die Wartezeit (Latenz) verringert ist. Weitere Informationen finden Sie im Abschnitt „Überlegungen zum Netzwerkentwurf“ in diesem Artikel.

Auswirkungen von Latenz und Paketumlaufzeit auf TCP

Die Paketumlaufzeit hat direkte Auswirkung auf den maximalen TCP-Durchsatz. Im TCP-Protokoll ist die Fenstergröße die maximale Menge an Datenverkehr, die über eine TCP-Verbindung gesendet werden kann, bevor der Absender die Bestätigung vom Empfänger empfangen muss. Wenn der TCP MSS auf 1.460 festgelegt ist und die TCP-Fenstergröße auf 65.535 festgelegt ist, kann der Absender 45 Pakete senden, bevor er vom Empfänger bestätigt wird. Wenn der Absender keine Bestätigung erhält, werden die Daten erneut gesendet. Die zugehörige Formel sieht so aus:

TCP window size / TCP MSS = packets sent

In diesem Beispiel wird 65.535/1.460 auf 45 aufgerundet.

Dieser Status "Warten auf Bestätigung" ist ein Mechanismus, um eine zuverlässige Übermittlung von Daten sicherzustellen, was dazu führt, dass RTT den TCP-Durchsatz beeinflusst. Je länger der Absender auf die Bestätigung wartet, desto länger muss er warten, bevor weitere Daten gesendet werden.

Die Formel zur Berechnung des maximalen Durchsatzes einer einzelnen TCP-Verbindung sieht wie folgt aus:

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

In dieser Tabelle ist der maximale Durchsatz einer einzelnen TCP-Verbindung in Megabytes pro Sekunde (MB/s) aufgeführt. (Zur besseren Lesbarkeit wird MB als Maßeinheit verwendet.)

TCP-Fenstergröße (Byte)	RTT-Latenz (ms)	Maximaler Durchsatz in MB/s	Maximaler Durchsatz in MBit/s
65.535	1	65,54	524,29
65.535	30	2,18	17,48
65.535	60	1,09	8,74
65.535	90	0.73	5,83
65.535	120	0.55	4.37

Wenn Pakete verloren gehen, wird der maximale Durchsatz einer TCP-Verbindung reduziert, während der Absender die gesendeten Daten erneut übergibt.

TCP-Fensterskalierung

Die TCP-Fensterskalierung ist eine Technik, mit der die TCP-Fenstergröße dynamisch erhöht wird, damit mehr Daten gesendet werden können, bevor eine Bestätigung erforderlich ist. Im vorherigen Beispiel würden 45 Pakete gesendet, bevor eine Bestätigung erforderlich war. Wenn Sie die Anzahl der Pakete erhöhen, die gesendet werden können, bevor eine Bestätigung erforderlich ist, verringern Sie die Häufigkeit, mit der ein Absender auf die Bestätigung wartet.

In der folgenden Tabelle sind diese Beziehungen veranschaulicht:

TCP-Fenstergröße (Byte)	RTT-Latenz (ms)	Maximaler Durchsatz in MB/s	Maximaler Durchsatz in MBit/s
65.535	30	2,18	17,48
131.070	30	4.37	34,95
262.140	30	8,74	69,91
524.280	30	17,48	139,81

Der TCP-Headerwert für die TCP Window Size (Fenstergröße) ist jedoch nur 2 Bytes lang, was bedeutet, dass der Maximalwert für ein Empfangsfenster 65.535 beträgt. Um die maximale Fenstergröße zu erhöhen, wurde ein TCP Window Scale-Faktor (Fensterskalierungsfaktor) eingeführt.

Der Skalierungsfaktor ist ebenfalls eine Einstellung, die in einem Betriebssystem konfiguriert werden kann. Die Formel zur Berechnung der TCP-Fenstergröße durch Verwenden von Skalierungsfaktoren lautet wie folgt:

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

Die Berechnung für einen Skalierungsfaktor von 3 und eine Fenstergröße von 65.535 sieht wie folgt aus:

65,535 * (2^3) = 524,280 bytes

Ein Skalierungsfaktor von 14 ergibt eine TCP-Fenstergröße von 14 (der maximal zulässige Offset). Die TCP-Fenstergröße beträgt 1.073.725.440 Bytes (8,5 Gigabyte).

Unterstützung für TCP-Fensterskalierung

In Windows können unterschiedliche Skalierungsfaktoren für unterschiedliche Verbindungstypen festgelegt werden. (Die Klassen von Verbindungen umfassen Rechenzentrum, Internet usw.) Sie verwenden den PowerShell-Befehl Get-NetTCPConnection, um den Verbindungstyp der Fensterskalierung anzuzeigen:

Get-NetTCPConnection

Sie können den PowerShell-Befehl Get-NetTCPSetting verwenden, um die Werte von jeder Klasse anzuzeigen:

Get-NetTCPSetting

Mit dem PowerShell-Befehl Set-NetTCPSetting können Sie in Windows die anfängliche TCP-Fenstergröße und den anfänglichen TCP-Skalierungsfaktor festlegen. Weitere Informationen finden Sie unter Set-NetTCPSetting.

Set-NetTCPSetting

Die folgenden Werte sind die effektiven TCP-Einstellungen für AutoTuningLevel:

AutoTuningLevel	Skalierungsfaktor	Skalierungsmultiplikator	Formel zum Berechnen der maximalen Fenstergröße
Deaktiviert	Keine	Keine	Fenstergröße
Eingeschränkt	4	2^4	Fenstergröße * (2^4)
Stark eingeschränkt	2	2^2	Fenstergröße * (2^2)
Normal	8	2^8	Fenstergröße * (2^8)
Experimentell	14	2^14	Fenstergröße * (2^14)

Diese Einstellungen wirken sich am wahrscheinlichsten auf die TCP-Leistung aus, es gibt aber viele andere Faktoren im Internet, die außerhalb der Kontrolle von Azure liegen und sich ebenfalls auf die TCP-Leistung auswirken können.

Beschleunigter Netzwerkbetrieb und empfangsseitige Skalierung

Beschleunigte Netzwerke

Netzwerkfunktionen virtueller Computer sind in der Vergangenheit sowohl auf der Gast-VM als auch auf dem Hypervisor/Host CPU-Intensiv. Die Host-CPU verarbeitet in Software alle Pakete, die über den Host übertragen werden, einschließlich aller Kapselung und Entkapselung des virtuellen Netzwerks. Je mehr Datenverkehr den Host durchläuft, desto höher ist die CPU-Auslastung. Wenn die Host-CPU mit anderen Vorgängen beschäftigt ist, die sich auf den Netzwerkdurchsatz und die Latenz auswirken. Azure löst dieses Problem mit beschleunigtem Netzwerkbetrieb.

Der beschleunigte Netzwerkbetrieb bietet eine durchgängig extrem niedrige Netzwerklatenz über die firmeneigene programmierbare Hardware von Azure und Technologien wie SR-IOV. Der beschleunigte Netzwerkbetrieb verschiebt einen Großteil des softwaredefinierten Azure-Netzwerkstapels von den CPUs in die FPGA-basierten SmartNICs. Diese Änderung ermöglicht es Endbenutzeranwendungen, Rechenzyklen zurückzugewinnen, die die Auslastung der virtuellen Maschine verringern und für weniger Verzögerungsschwankungen und Latenzinkonsistenzen sorgen. Mit anderen Worten, die Leistung kann deterministischer sein.

Der beschleunigte Netzwerkbetrieb verbessert die Leistung, indem er es der Gast-VM ermöglicht, den Host zu umgehen und einen Datenpfad direkt mit dem SmartNIC eines Hosts einzurichten. Dies sind einige der Vorteile des beschleunigten Netzwerkbetriebs:

Niedrigere Latenz/mehr Pakete pro Sekunde (pps) : Durch das Entfernen des virtuellen Switch aus dem Datenpfad wird die Zeit gespart, die Pakete auf dem Host auf die Verarbeitung von Richtlinien warten müssen, und wird die Anzahl von Paketen erhöht, die im virtuellen Computer (VM) verarbeitet werden können.
Reduzierte Jitter: Die Verarbeitung im virtuellen Switch hängt vom Umfang der anzuwendenden Richtlinien und von der Workload der CPU ab, die die Verarbeitung durchführt. Das Auslagern der Richtlinienerzwingung auf die Hardware entfernt diese Variabilität, indem die Pakete direkt an die VM gesendet werden. Dadurch entfallen die Host-zu-VM-Kommunikation und alle Softwareinterrupts und Kontextwechsel.
Verringerte CPU-Auslastung: Das Umgehen des virtuellen Switch auf dem Host führt zu weniger CPU-Auslastung für die Verarbeitung des Netzwerkdatenverkehrs.

Um beschleunigten Netzwerkbetrieb verwenden zu können, müssen Sie diesen explizit auf jedem entsprechenden virtuellen Computer aktivieren. Anweisungen hierzu finden Sie unter Erstellen eines virtuellen Linux-Computers mit beschleunigtem Netzwerkbetrieb.

Empfangsseitige Skalierung

Die empfangsseitige Skalierung ist eine Netzwerktreibertechnologie, die den Empfang von Netzwerkverkehr effizienter verteilt, indem sie die Empfangsverarbeitung auf mehrere CPUs in einem Multiprozessorsystem verteilt. Einfach ausgedrückt ermöglicht empfangsseitige Skalierung es einem System, mehr empfangenen Datenverkehr zu verarbeiten, da es alle verfügbaren CPUs anstelle von nur einer verwendet. Eine technischere Beschreibung der empfangsseitigen Skalierung finden Sie unter Introduction to Receive Side Scaling (Einführung in die empfangsseitige Skalierung).

Um die beste Leistung zu erzielen, wenn der beschleunigte Netzwerkbetrieb auf einem virtuellen Computer aktiviert ist, müssen Sie die empfangsseitige Skalierung aktivieren. RSS kann auch auf virtuellen Maschinen Vorteile bieten, die kein beschleunigtes Netzwerk verwenden. Eine Übersicht darüber, wie Sie feststellen können, ob RSS aktiviert ist und wie Sie es aktivieren, finden Sie unter Optimieren des Netzwerkdurchsatzes für virtuelle Azure-Computer.

TCP TIME_WAIT und TIME_WAIT Assassination

TCP-TIME_WAIT ist eine weitere gängige Einstellung, die sich auf die Netzwerk- und Anwendungsleistung auswirkt. Aktive VMs öffnen und schließen häufig viele Sockets, entweder als Clients oder Server. Bei normalen TCP-Vorgängen wechselt ein Socket häufig in den TIME_WAIT Zustand und verbleibt für einen längeren Zeitraum dort. Dieser Zustand stellt die Übermittlung aller verbleibenden Daten im Socket sicher, bevor sie geschlossen wird. Daher verhindern TCP/IP-Stapel in der Regel die Wiederverwendung des Sockets, indem das TCP SYN-Paket des Clients im Hintergrund gelöscht wird.

Sie können konfigurieren, wie lange ein Socket im TIME_WAIT Zustand verbleibt. Die Dauer kann zwischen 30 Sekunden und 240 Sekunden liegen. Sockets sind eine endliche Ressource, und ihre Verfügbarkeit kann konfiguriert werden. In der Regel stehen ca. 30.000 Sockets jederzeit zur Verfügung. Wenn das System alle verfügbaren Sockets nutzt oder Wenn Clients und Server falsche TIME_WAIT Einstellungen verwenden, versucht der virtuelle Computer möglicherweise, einen Socket noch im TIME_WAIT Zustand wiederzuverwenden. In solchen Fällen schlagen neue Verbindungen fehl, da die TCP SYN-Pakete im Hintergrund verworfen werden.

Der Wert für den Portbereich für ausgehende Sockets kann innerhalb des TCP/IP-Stapels eines Betriebssystems konfiguriert werden. Dasselbe gilt auch für TCP TIME_WAIT-Einstellungen und Socketwiederverwendung. Ein Ändern dieser Werte kann die Skalierbarkeit verbessern. Aber je nach Situation können diese Änderungen Interoperabilitätsprobleme verursachen. Sie sollten vorsichtig sein, wenn Sie diese Werte ändern.

Sie können TIME_WAIT Assassination verwenden, um diese Skalierungsbeschränkung zu umgehen. TIME_WAIT Assassination ermöglicht die Wiederverwendung eines Sockets in bestimmten Situationen, etwa wenn die Sequenznummer im IP-Paket der neuen Verbindung die Sequenznummer des letzten Pakets der vorherigen Verbindung überschreitet. In diesem Fall ermöglicht das Betriebssystem das Herstellen der neuen Verbindung (es akzeptiert die neue SYN/ACK) und erzwingt das Schließen der vorherigen Verbindung, die sich in einem TIME_WAIT-Zustand befand. Diese Funktionalität wird auf Windows-VMs in Azure unterstützt. Um mehr über die Unterstützung in anderen VMs zu erfahren, wenden Sie sich an den Betriebssystemanbieter.

Informationen über das Konfigurieren von TCP TIME_WAIT-Einstellungen und des Quellportbereichs finden Sie unter Einstellungen, die zur Verbesserung der Netzwerkleistung geändert werden können.

Faktoren eines virtuellen Netzwerks, die sich auf die Leistung auswirken können

Maximaler ausgehender VM-Durchsatz

Azure bietet verschiedene VM-Größen und -Typen, die jeweils eine andere Mischung aus Leistungsfunktionen bieten. Eines dieser Merkmale ist der Netzwerkdurchsatz (oder die Bandbreite), der in Megabits pro Sekunde (MBit/s) gemessen wird. Da virtuelle Computer auf gemeinsam genutzter Hardware gehostet werden, muss die Netzwerkkapazität zwischen den virtuellen Computern, die dieselbe Hardware verwenden, gerecht aufgeteilt werden. Größeren virtuellen Computern wird mehr Bandbreite als kleineren virtuellen Computern zugeordnet.

Die zugewiesene Netzwerkbandbreite jeder virtuellen Maschine wird am ausgehenden Datenverkehr von der virtuellen Maschine gemessen. Der gesamte Netzwerkdatenverkehr, der vom virtuellen Computer ausgeht, wird unabhängig vom Ziel auf den zugewiesenen Grenzwert angerechnet. Wenn ein virtueller Computer einen Grenzwert von 1.000 MBit/s aufweist, gilt dieser Grenzwert, ob der ausgehende Datenverkehr für einen anderen virtuellen Computer im selben virtuellen Netzwerk oder außerhalb von Azure bestimmt ist.

Der eingehende Datenverkehr wird nicht gemessen oder direkt beschränkt. Es gibt jedoch weitere Faktoren, z. B. CPU- und Speicherbegrenzungen, die sich darauf auswirken können, wie ein virtueller Computer eingehende Daten verarbeitet.

Der beschleunigte Netzwerkbetrieb ist dazu ausgelegt, die Netzwerkleistung, einschließlich Latenz, Durchsatz und CPU-Auslastung, zu verbessern. Durch den beschleunigten Netzwerkbetrieb kann der Durchsatz eines virtuellen Computers erhöht werden, dies kann jedoch nur bis zu der Bandbreite erfolgen, die dem virtuellen Computer zugewiesen ist.

Jedem virtuellen Azure-Computer ist mindestens eine Netzwerkschnittstelle zugeordnet. Es können aber auch mehrere zugeordnet sein. Die einem virtuellen Computer zugeordnete Bandbreite ist die Summe des gesamten ausgehenden Datenverkehrs über alle Netzwerkschnittstellen, die dem Computer zugeordnet sind. Mit anderen Worten, die Bandbreite wird pro virtuellem Computer zugeordnet, unabhängig davon, wie viele Netzwerkschnittstellen dem Computer zugeordnet sind.

Der erwartete ausgehende Durchsatz und die Anzahl der Netzwerkschnittstellen, die von der jeweiligen Größe eines virtuellen Computers unterstützt werden, sind unter Größen für virtuelle Windows-Computer in Azure ausführlich beschrieben. Um den maximalen Durchsatz zu sehen, wählen Sie einen Typ aus, etwa Allgemeiner Zweck, und suchen Sie dann auf der angezeigten Seite nach dem Abschnitt über die Größenserie (z. B. „Dv2-Serie“). Für jede Serie gibt es eine Tabelle, in der in der letzten Spalte, die mit „Maximale Anzahl NICs/Erwartete Netzwerkbandbreite (MBit/s)“ überschrieben ist, Netzwerkspezifikationen enthalten sind.

Die Durchsatzbegrenzung gilt für den virtuellen Computer. Der Durchsatz wird von diesen Faktoren nicht beeinflusst:

Anzahl der Netzwerkschnittstellen: Der Bandbreitengrenzwert bezieht sich auf die Summe des gesamten ausgehenden Datenverkehrs vom virtuellen Computer.
Beschleunigter Netzwerkbetrieb: Obwohl dieses Feature beim Erreichen des veröffentlichten Grenzwerts hilfreich sein kann, nimmt es keine Änderung am Grenzwert vor.
Datenverkehrsziel: Alle Ziele werden auf den Grenzwert für ausgehenden Datenverkehr angerechnet.
Protokoll: Der gesamte ausgehende Datenverkehr über alle Protokolle wird auf den Grenzwert angerechnet.

Weitere Informationen finden Sie unter Netzwerkdurchsatz virtueller Computer.

Optimierung virtueller Linux-Computer (VMs)

Moderne Linux-Kernel verfügen über Funktionen, die dazu beitragen können, Konsistenz und Leistung sicherzustellen, was manchmal von bestimmten Workloads erfordert wird.

Weitere Informationen finden Sie unter Optimieren der Netzwerkbandbreite auf Azure-VMs

Überlegungen zur Internetleistung

Wie in diesem Artikel erläutert, können Faktoren im Internet und außerhalb der Kontrolle von Azure die Netzwerkleistung beeinträchtigen. Einige dieser Faktoren sind:

Latenz: Die Rundreisezeit zwischen zwei Endpunkten wird durch Probleme in Zwischennetzwerken, durch Datenverkehr, der nicht den "kürzesten" Entfernungspfad nutzt, und durch die Verwendung suboptimaler Peering-Pfade beeinflusst.
Paketverlust: Paketverlust wird durch Netzwerküberlastung, physische Pfadprobleme und unterperformierende Netzwerkgeräte verursacht.
MTU-Größe/Fragmentierung: Fragmentierung entlang des Pfads kann zu Verzögerungen bei der Datenankunft oder zu Paketen führen, die in der falschen Reihenfolge eintreffen, was die Übermittlung von Paketen beeinträchtigen kann.

Traceroute ist ein gutes Tool, um die Leistungsmerkmale eines Netzwerks (etwa Paketverlust und Latenz) entlang jedes Netzwerkpfads zwischen einem Quell- und einem Zielgerät zu messen.

Überlegungen zum Netzwerkentwurf

Über die weiter oben in diesem Artikel beschriebenen Aspekte hinaus kann sich die Topologie eines virtuellen Netzwerks auf die Leistung des Netzwerks auswirken. Beispielsweise führt ein Hub-and-Spoke-Design, das den Datenverkehr global zu einem virtuellen Single-Hub-Netzwerk zurückgibt, eine Netzwerklatenz ein, die sich auf die Gesamtleistung des Netzwerks auswirkt.

Die Anzahl der Netzwerkgeräte, die der Netzwerkdatenverkehr durchläuft, kann sich ebenfalls auf die Gesamtlatenz auswirken. Wenn der Datenverkehr in einem Hub-and-Spoke-Design über eine virtuelle Speichennetzwerk-Appliance und eine virtuelle Hub-Appliance vor der Übertragung in das Internet durchläuft, führen die virtuellen Netzwerkgeräte eine gewisse Latenz ein.

Azure-Regionen, virtuelle Netzwerke und Latenz

Azure-Regionen bestehen aus mehreren Rechenzentren (Datencenter), die sich in einem allgemeinen geografischen Gebiet befinden. Diese Datencenter sind physisch möglicherweise nicht nebeneinander. In einigen Fällen sind sie mehr als 10 Kilometer voneinander entfernt. Ein virtuelles Netzwerk ist eine logische Überlagerung auf dem physischen Azure-Datacenternetzwerk. Ein virtuelles Netzwerk erfordert keine spezielle Netzwerktopologie im Datencenter.

Zum Beispiel können sich zwei virtuelle Computer, die zum selben virtuellen Netzwerk und Subnetz gehören, in verschiedenen Racks, Reihen oder sogar Datencentern befinden. Zwischen ihnen können meter- oder kilometerlange Glasfaserkabel liegen. Diese Abweichung kann zu variablen Latenzen (einige Millisekunden Differenz) zwischen verschiedenen virtuellen Computern führen.

Die geografische Platzierung von virtuellen Computern und die mögliche resultierende Latenz zwischen zwei virtuellen Computern wird durch die Konfiguration von Verfügbarkeitssätzen, Näherungsplatzierungsgruppen und Verfügbarkeitszonen beeinflusst. Aber der Abstand zwischen den Datencentern in einer Region ist regionsspezifisch und hauptsächlich der Datencentertopologie in der Region geschuldet.

Quell-NAT-Portauslastung

Eine Bereitstellung in Azure kann mit Endpunkten außerhalb von Azure im öffentlichen Internet und/oder im öffentlichen IP-Adressraum kommunizieren. Wenn eine Instanz eine ausgehende Verbindung initiiert, ordnet Azure die private IP-Adresse dynamisch einer öffentlichen IP-Adresse zu. Nachdem Azure diese Zuordnung erstellt hat, kann der Antwortdatenverkehr für den ausgehenden ursprünglichen Datenfluss auch die private IP-Adresse erreichen, von der der Datenfluss stammte.

Für jede ausgehende Verbindung muss der Azure Load Balancer diese Zuordnung für einige Zeit aufrechterhalten. Aufgrund der Mehrmandantenfähigkeit von Azure kann die Aufrechterhaltung dieser Zuordnung für jeden ausgehenden Datenverkehr für jede VM ressourcenintensiv sein. Daher gibt es Einschränkungen, die entsprechend der Konfiguration des virtuellen Azure-Netzwerks festgelegt werden. Oder, genauer gesagt, eine Azure-VM kann nur zu einem bestimmten Zeitpunkt einige ausgehende Verbindungen herstellen. Wenn diese Grenzwerte erreicht sind, macht der virtuelle Computer keine eingehenderen Verbindungen.

Dieses Verhalten ist aber konfigurierbar. Weitere Informationen zu SNAT und SNAT-Portauslastung finden Sie in diesem Artikel.

Messen der Netzwerkleistung in Azure

Viele der Leistungshöchstwerte in diesem Artikel beziehen sich auf die Netzwerklatenz / Roundtripzeit (Roundtrip Time, RTT) zwischen zwei virtuellen Computern. Dieser Abschnitt enthält einige Vorschläge, wie Latenz/RTT und wie die TCP-Leistung und die VM-Netzwerkleistung getestet werden können. Sie können die früher diskutierten TCP/IP- und Netzwerkwerte optimieren und hinsichtlich der Leistung testen, indem Sie die in diesem Abschnitt beschriebenen Techniken verwenden. Geben Sie Latenz-, MTU-, MSS- und Fenstergrößenwerte in die zuvor bereitgestellten Berechnungen ein, und vergleichen Sie theoretische Höchstwerte mit tatsächlichen Werten, die beim Testen beobachtet wurden.

Messen von Paketumlaufzeit (RTT) und Paketverlust

Die TCP-Leistung hängt stark von RTT und Paketverlust ab. Das in Windows und Linux verfügbaren PING-Hilfsprogramm bietet die einfachste Möglichkeit, RTT und Paketverlust zu messen. Die Ausgabe von PING zeigt die minimale/maximale/durchschnittliche Latenz zwischen Einer Quelle und einem Ziel an. Es zeigt Paketverlust an. PING verwendet standardmäßig das ICMP-Protokoll. Sie können PsPing verwenden, um TCP RTT zu testen. Weitere Informationen hierzu finden Sie unter PsPing.

ICMP- und TCP-Pings messen nicht den beschleunigten Netzwerkdatenpfad. Informationen zum Messen des Datenpfads finden Sie in diesem Artikel zu Latte und SockPerf.

Messen der tatsächlichen Bandbreite eines virtuellen Computers

Um die Bandbreite von Azure-VMs genau zu messen, befolgen Sie diese Anleitung.

Weitere Informationen zum Testen anderer Szenarien finden Sie in den folgenden Artikeln:

Erkennen von ineffizientem TCP-Verhalten

In Paketerfassungen sehen Azure-Kunden möglicherweise TCP-Pakete mit TCP-Flags (SACK, DUP ACK, RETRANSMIT und FAST RETRANSMIT), die auf Probleme mit der Netzwerkleistung hinweisen können. Diese Pakete weisen insbesondere auf Netzwerkineffizienzen hin, die aus Paketverlust resultieren. Paketverlust muss jedoch nicht notwendigerweise durch Azure Leistungsprobleme verursacht sein. Leistungsprobleme können auch auf Problemen bei Anwendungen oder Betriebssystem zurückzuführen sein oder durch andere Probleme verursacht werden, die nicht direkt mit der Azure-Plattform zusammenhängen.

Beachten Sie auch, dass einige Neuübertragungen und doppelte ACKs in einem Netzwerk normal sind. TCP-Protokolle wurden entwickelt, um zuverlässig zu sein. Das Vorhandensein dieser TCP-Pakete in einer Paketerfassung deutet nicht unbedingt auf ein systemisches Netzwerkproblem hin, es sei denn, ihre Anzahl ist sehr hoch.

Trotzdem sind diese Pakettypen weiterhin Hinweise darauf, dass der TCP-Durchsatz nicht seine maximale Leistung erreicht. Die Gründe dafür sind in anderen Abschnitten dieses Artikels erläutert.

Nächste Schritte

Nachdem Sie nun über die TCP/IP-Leistungsoptimierung für Azure-VMs gelernt haben, sollten Sie andere Faktoren für die Planung virtueller Netzwerke untersuchen. Weitere Informationen zum Verbinden und Konfigurieren virtueller Netzwerke finden Sie auch.