Ottimizzazione delle prestazioni TCP/IP per le macchine virtuali di Azure

2025-04-21

Questo articolo illustra le tecniche comuni di ottimizzazione delle prestazioni TCP/IP e alcuni aspetti da considerare quando vengono usati per le macchine virtuali in esecuzione in Azure. Offre una panoramica di base delle tecniche ed è stato esaminato il modo in cui è possibile ottimizzare le macchine virtuali.

Tecniche comuni di ottimizzazione TCP/IP

Unità massima di trasmissione, frammentazione e offload di invio di grandi dimensioni

MTU

L'unità di trasmissione massima (MTU) è il frame di dimensioni più grande (pacchetti e intestazioni di accesso alla rete) specificato in byte che possono essere inviati tramite un'interfaccia di rete. L'MTU è un'impostazione configurabile. L'MTU predefinito usato nelle VM di Azure e l'impostazione predefinita nella maggior parte dei dispositivi di rete a livello globale è di 1.500 byte.

Frammentazione

La frammentazione si verifica quando viene inviato un pacchetto che supera l'MTU di un'interfaccia di rete. Lo stack TCP/IP suddivide il pacchetto in parti più piccole (frammenti) conformi all'MTU dell'interfaccia. La frammentazione si verifica a livello IP ed è indipendente dal protocollo sottostante ,ad esempio TCP. Quando un pacchetto da 2.000 byte viene inviato tramite un'interfaccia di rete con un MTU di 1.500, il pacchetto viene suddiviso in un pacchetto da 1.500 byte e un pacchetto da 500 byte.

I dispositivi di rete nel percorso tra un'origine e una destinazione possono eliminare pacchetti che superano l'MTU o frammentare il pacchetto in parti più piccole.

Il bit "Don't Fragment" in un pacchetto IP

Il bit Don't Fragment (DF) è un flag nell'intestazione del protocollo IP. Il bit DF indica che i dispositivi di rete nel percorso tra il mittente e il ricevitore non devono frammentare il pacchetto. Questo bit può essere impostato per svariate ragioni. Per un esempio, vedere la sezione "Scoperta dell'MTU del percorso" di questo articolo. Quando un dispositivo di rete riceve un pacchetto con il bit 'Non frammentare' impostato, e tale pacchetto supera l'MTU dell'interfaccia del dispositivo, il comportamento standard è che il dispositivo scarti il pacchetto. Il dispositivo invia un messaggio ICMP Frammentazione necessaria all'origine originale del pacchetto.

Implicazioni sulle prestazioni della frammentazione

La frammentazione può avere implicazioni negative sulle prestazioni. Uno dei motivi principali per l'effetto sulle prestazioni è l'effetto cpu/memoria della frammentazione e riassemblazione dei pacchetti. Quando un dispositivo di rete deve frammentare un pacchetto, deve allocare risorse CPU/memoria per eseguire la frammentazione.

La stessa cosa accade quando il pacchetto viene riassemblato. Il dispositivo di rete deve archiviare tutti i frammenti fino a quando non vengono ricevuti in modo che possa riassemblarli nel pacchetto originale.

Azure e frammentazione

Azure non elabora pacchetti frammentati con rete accelerata. Quando una macchina virtuale riceve un pacchetto frammentato, il percorso nonaccelerato lo elabora. Di conseguenza, i pacchetti frammentati non offrono i vantaggi della rete accelerata, ad esempio una latenza inferiore, un jitter ridotto e pacchetti più elevati al secondo. Per questo motivo, è consigliabile evitare la frammentazione, se possibile.

Azure, per impostazione predefinita, elimina i pacchetti frammentati che arrivano alla macchina virtuale non in ordine, ovvero i pacchetti non corrispondono alla sequenza di trasmissione dall'endpoint di origine. Questo problema può verificarsi quando i pacchetti viaggiano su Internet o su altri WAN di grandi dimensioni.

Ottimizzare l'unità massima di trasmissione

È possibile migliorare la velocità effettiva della rete virtuale interna aumentando l'MTU per il traffico della macchina virtuale. Tuttavia, se la macchina virtuale comunica con destinazioni esterne alla rete virtuale con una MTU diversa, la frammentazione potrebbe verificarsi e ridurre le prestazioni.

Per altre informazioni sull'impostazione di MTU nelle macchine virtuali di Azure, vedere Configurare l'unità di trasmissione massima (MTU) per le macchine virtuali in Azure.

Offload di invio di grandi dimensioni

LSO (Large Send Offload) può migliorare le prestazioni di rete eseguendo l'offload della segmentazione dei pacchetti alla scheda Ethernet. Quando LSO è abilitato, lo stack TCP/IP crea un pacchetto TCP di grandi dimensioni e lo invia alla scheda Ethernet per la segmentazione prima di inoltrarla. Il vantaggio di LSO libera la CPU dalla segmentazione dei pacchetti in dimensioni conformi all'MTU e dall'offload dell'elaborazione nell'hardware dell'interfaccia Ethernet. Per ulteriori informazioni sui vantaggi di LSO, vedere Supporto per l'invio di dati di grandi dimensioni.

Quando LSO è abilitato, i clienti di Azure potrebbero notare frame di grandi dimensioni durante le acquisizioni di pacchetti. Queste dimensioni di fotogrammi grandi potrebbero indurre alcuni clienti a pensare che si stia verificando una frammentazione o che venga utilizzata una MTU elevata quando non è così. Con LSO, la scheda Ethernet può annunciare una dimensione massima del segmento maggiore (MSS) allo stack TCP/IP per creare un pacchetto TCP più grande. La scheda Ethernet suddivide quindi l'intero frame non segmentato in molti frame più piccoli in base alla propria MTU, che sono visibili in un'acquisizione di pacchetti effettuata nella VM.

Ridimensionamento della finestra MSS TCP e PMTUD

Dimensioni massime del segmento TCP

La dimensione massima del segmento TCP (MSS) è un'impostazione che limita le dimensioni dei segmenti TCP, evitando così la frammentazione dei pacchetti TCP. I sistemi operativi usano in genere questa formula per impostare MSS:

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

L'intestazione IP e l'intestazione TCP sono 20 byte ciascuno o 40 byte totali. Un'interfaccia con un MTU di 1.500 ha un MSS pari a 1.460. Mss è configurabile.

Questa impostazione viene accettata nell'handshake a tre vie TCP quando viene configurata una sessione TCP tra un'origine e una destinazione. Entrambi i lati inviano un valore MSS e il valore inferiore dei due viene usato per la connessione TCP.

Tenere presente che le MTU dell'origine e della destinazione non sono gli unici fattori che determinano il valore MSS. I dispositivi di rete intermedi, ad esempio i gateway VPN, tra cui Azure Gateway VPN, possono regolare L'MTU indipendentemente dall'origine e dalla destinazione per garantire prestazioni di rete ottimali.

Individuazione dell'unità massima di trasmissione del percorso

Il MSS viene negoziato, ma potrebbe non indicare il servizio gestito effettivo che può essere usato. Altri dispositivi di rete nel percorso tra l'origine e la destinazione potrebbero avere un valore MTU inferiore rispetto all'origine e alla destinazione. In questo caso, il dispositivo il cui MTU è minore del pacchetto elimina il pacchetto. Il dispositivo invia un messaggio ICMP Frammentazione necessaria (tipo 3, codice 4) che contiene la relativa unità massima di trasmissione. Questo messaggio ICMP consente all'host di origine di ridurre il percorso MTU in modo appropriato. Il processo è denominato Individuazione unità massima di trasmissione percorso (PMTUD).

Il processo PMTUD riduce le prestazioni di rete a causa dell'inefficienza. Quando viene superata la MTU di un percorso di rete, i pacchetti devono essere ritrasmessi con un mss inferiore. Se un firewall di rete blocca il messaggio ICMP Frammentazione richiesta, il mittente non si rende conto della necessità di abbassare il MSS e ritrasmette ripetutamente il pacchetto. Per questo motivo, sconsigliamo di aumentare l'MTU della macchina virtuale di Azure.

VPN e MTU

Se si usano macchine virtuali che eseguono incapsulamento (ad esempio VPN IPsec), esistono altre considerazioni relative alle dimensioni dei pacchetti e all'MTU. I VPN aggiungono altre intestazioni ai pacchetti. Le intestazioni aggiunte aumentano le dimensioni del pacchetto e richiedono un MSS più piccolo.

Per Azure, è consigliabile impostare il blocco TCP MSS su 1.350 byte e l'interfaccia del tunnel MTU su 1.400. Per altre informazioni, vedere la pagina dei dispositivi VPN e dei parametri IPsec/IKE.

Latenza, tempo di round trip e ridimensionamento delle finestre TCP

Latenza e tempo di andata e ritorno

La velocità della luce determina la latenza di rete su una rete in fibra ottica. Il tempo di round trip (RTT) tra due dispositivi di rete regola la velocità effettiva della rete TCP.

Itinerario	Distanza	Ora unidirezionale	Scrittura in tempo reale
Da New York a San Francisco	4.148 km	21 ms	42 ms
New York a Londra	5.585 km	28 ms	56 ms
Da New York a Sydney	15.993 km	80 ms	160 ms

Questa tabella mostra la distanza di linea retta tra due posizioni. Nelle reti, la distanza è in genere più lunga della distanza lineare. Ecco una semplice formula per calcolare il valore RTT minimo in base alla velocità della luce:

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

È possibile usare 200 per la velocità di propagazione. La velocità di propagazione è la distanza, in chilometri, che la luce viaggia in 1 millisecondo.

Prendiamo New York a San Francisco come esempio. La distanza di linea retta è di 4.148 km. Se si immette tale valore nell'equazione, si ottiene l'equazione seguente:

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

L'output dell'equazione è espresso in millisecondi.

Se si desidera ottenere le migliori prestazioni di rete, l'opzione logica consiste nel selezionare le destinazioni con la distanza più breve tra di esse. È anche necessario progettare la rete virtuale per ottimizzare il percorso del traffico e ridurre la latenza. Per altre informazioni, vedere la sezione "Considerazioni sulla progettazione della rete" di questo articolo.

Effetti sulla latenza e sul tempo di round trip su TCP

Il tempo di round trip ha un effetto diretto sulla velocità effettiva TCP massima. Nel protocollo TCP le dimensioni della finestra sono la quantità massima di traffico che può essere inviata tramite una connessione TCP prima che il mittente debba ricevere il riconoscimento dal ricevitore. Se TCP MSS è impostato su 1.460 e le dimensioni della finestra TCP sono impostate su 65.535, il mittente può inviare 45 pacchetti prima del riconoscimento dal ricevitore. Se il mittente non riceve il riconoscimento, ritrasmette i dati. La formula è:

TCP window size / TCP MSS = packets sent

In questo esempio, 65.535 / 1.460 viene arrotondato fino a 45.

Questo stato di "attesa di riconoscimento", un meccanismo per garantire la distribuzione affidabile dei dati, è ciò che fa sì che RTT influisca sulla velocità effettiva TCP. Più a lungo il mittente attende il riconoscimento, più tempo è necessario attendere prima di inviare altri dati.

Ecco la formula per calcolare la velocità effettiva massima di una singola connessione TCP:

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

Questa tabella mostra la velocità effettiva massima di megabyte al secondo di una singola connessione TCP. Per la leggibilità, i megabyte vengono usati per l'unità di misura.

Dimensioni della finestra TCP (byte)	Latenza RTT (ms)	Larghezza di banda massima in megabyte/secondo	Velocità effettiva massima megabit/secondo
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

Se i pacchetti vengono persi, la velocità effettiva massima di una connessione TCP viene ridotta mentre il mittente ritrasmette i dati inviati.

Ridimensionamento delle finestre TCP

Il ridimensionamento delle finestre TCP è una tecnica che aumenta dinamicamente le dimensioni della finestra TCP per consentire l'invio di più dati prima che venga richiesto un riconoscimento. Nell'esempio precedente, 45 pacchetti verrebbero inviati prima che fosse necessario un riconoscimento. Se si aumenta il numero di pacchetti che è possibile inviare prima che sia necessario un riconoscimento, si riduce il numero di volte in cui un mittente è in attesa di conferma.

Questa tabella illustra le relazioni seguenti:

Dimensioni della finestra TCP (byte)	Latenza RTT (ms)	Larghezza di banda massima in megabyte/secondo	Velocità effettiva massima megabit/secondo
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

Ma il valore dell'intestazione TCP per le dimensioni della finestra TCP è di soli 2 byte, ovvero il valore massimo per una finestra di ricezione è 65.535. Per aumentare le dimensioni massime della finestra, è stato introdotto un fattore di scala della finestra TCP.

Il fattore di scala è anche un'impostazione che è possibile configurare in un sistema operativo. Ecco la formula per calcolare le dimensioni della finestra TCP usando i fattori di scala:

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

Ecco il calcolo per un fattore di scala della finestra pari a 3 e una dimensione della finestra pari a 65.535:

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

Un fattore di scala pari a 14 determina una dimensione della finestra TCP pari a 14 (offset massimo consentito). Le dimensioni della finestra TCP sono pari a 1.073.725.440 byte (8,5 gigabit).

Supporto per il ridimensionamento delle finestre TCP

Windows può impostare fattori di ridimensionamento diversi per tipi di connessione diversi. Le classi di connessioni includono data center, Internet e così via. Usare il Get-NetTCPConnection comando di PowerShell per visualizzare il tipo di connessione di ridimensionamento della finestra:

Get-NetTCPConnection

È possibile usare il Get-NetTCPSetting comando di PowerShell per visualizzare i valori di ogni classe:

Get-NetTCPSetting

È possibile impostare le dimensioni iniziali della finestra TCP e il fattore di ridimensionamento TCP in Windows usando il Set-NetTCPSetting comando PowerShell. Per altre informazioni, vedere Set-NetTCPSetting.

Set-NetTCPSetting

I valori seguenti sono le impostazioni TCP valide per AutoTuningLevel:

Livello di Auto-Regolazione	Fattore di ridimensionamento	Moltiplicatore di scalabilità	Formula a calcolare le dimensioni massime della finestra
Disabilitata	Nessuno	Nessuno	Dimensioni finestra
Con restrizioni	4	2^4	Dimensioni finestra * (2^4)
Con restrizioni molto limitate	2	2^2	Dimensioni finestra * (2^2)
Normale	8	2^8	Dimensioni finestra * (2^8)
Sperimentale	14	2^14	Dimensioni finestra * (2^14)

Queste impostazioni hanno maggiori probabilità di influire sulle prestazioni TCP, ma tenere presente che molti altri fattori in Internet, al di fuori del controllo di Azure, possono influire anche sulle prestazioni TCP.

Rete accelerata e ricezione del ridimensionamento laterale

Rete accelerata

Le funzioni di rete delle macchine virtuali hanno storicamente un uso intensivo della CPU sia nella macchina virtuale guest che nell'hypervisor/host. La CPU host elabora nel software tutti i pacchetti che transitino attraverso l'host, inclusi l'incapsulamento e la decapsulamento della rete virtuale. Maggiore è il traffico che attraversa l'host, maggiore è il carico della CPU. Se la CPU host è occupata con altre operazioni che influiscono sulla velocità effettiva e latenza di rete. Azure risolve questo problema con la rete accelerata.

La rete accelerata offre una latenza di rete ultra-bassa coerente tramite l'hardware programmabile interno di Azure e tecnologie come SR-IOV. La rete accelerata sposta gran parte dello stack di Software-Defined Networking di Azure dalle CPU e nelle smartNIC basate su FPGA. Questa modifica consente alle applicazioni dell'utente finale di recuperare cicli di calcolo che comportano una riduzione del carico nella macchina virtuale riducendo l'instabilità e l'incoerenza nella latenza. In altre parole, le prestazioni possono essere più deterministiche.

La rete accelerata migliora le prestazioni consentendo alla macchina virtuale guest di ignorare l'host e stabilire un percorso dati direttamente con smartNIC di un host. Ecco alcuni vantaggi della rete accelerata:

Minore latenza / pacchetti per secondo più elevati (pps): la rimozione del commutatore virtuale dal percorso dati riduce il tempo in cui i pacchetti rimangono nell'host per l'elaborazione dei criteri e aumenta il numero di pacchetti che possono essere elaborati nella macchina virtuale.
Jitter ridotto: l'elaborazione del commutatore virtuale dipende dalla quantità di criteri da applicare e dal carico di lavoro della CPU che esegue l'elaborazione. Eseguendo l'offload dell'applicazione dei criteri all'hardware, si rimuove tale variabilità recapitando pacchetti direttamente alla macchina virtuale, eliminando la comunicazione da host a macchina virtuale e tutte le interruzioni software e cambi di contesto.
Utilizzo ridotto della CPU: ignorando il commutatore virtuale nell'host si ottiene un minore utilizzo della CPU per l'elaborazione del traffico di rete.

Per usare la rete accelerata, è necessario abilitarla in modo esplicito in ogni macchina virtuale applicabile. Per istruzioni, vedere Creare una macchina virtuale Linux con rete accelerata.

Ricevere il ridimensionamento laterale

Receive side scaling (RSS) è una tecnologia driver di rete che distribuisce la ricezione del traffico di rete in modo più efficiente distribuendo l'elaborazione di ricezione tra più CPU in un sistema multiprocessore. In termini semplici, RSS consente a un sistema di elaborare più traffico ricevuto perché usa tutte le CPU disponibili invece di una sola. Per una discussione più tecnica su RSS, vedere Introduzione alla ricezione del ridimensionamento laterale.

Per ottenere prestazioni ottimali quando la rete accelerata è abilitata in una macchina virtuale, è necessario abilitare RSS. RSS può anche offrire vantaggi sulle macchine virtuali che non usano la rete accelerata. Per una panoramica su come determinare se RSS è abilitato e come abilitarlo, vedere Ottimizzare la velocità effettiva di rete per le macchine virtuali di Azure.

TCP TIME_WAIT TCP e interruzione forzata di TIME_WAIT

TCP TIME_WAIT è un'altra impostazione comune che influisce sulle prestazioni della rete e dell'applicazione. Macchine virtuali molto attive aprono e chiudono frequentemente molti socket, sia come client che come server. Durante le normali operazioni TCP, un socket entra spesso nello stato TIME_WAIT e rimane lì per un lungo periodo. Questo stato garantisce la trasmissione di qualsiasi dato rimanente sul socket prima della chiusura. Di conseguenza, gli stack TCP/IP impediscono in genere il riutilizzo del socket eliminando automaticamente il pacchetto TCP SYN del client.

È possibile configurare per quanto tempo un socket rimane nello stato TIME_WAIT. La durata può variare da 30 secondi a 240 secondi. I socket sono una risorsa limitata e la loro disponibilità è configurabile. In genere, circa 30.000 socket sono disponibili per l'uso in qualsiasi momento. Se il sistema utilizza tutti i socket disponibili o se i client e i server usano impostazioni di TIME_WAIT non corrispondenti, la macchina virtuale potrebbe tentare di riutilizzare un socket ancora nello stato TIME_WAIT. In questi casi, le nuove connessioni hanno esito negativo perché i pacchetti TCP SYN vengono eliminati automaticamente.

Il valore per l'intervallo di porte per i socket in uscita è configurabile all'interno dello stack TCP/IP di un sistema operativo. Lo stesso vale per le impostazioni di TIME_WAIT TCP e il riutilizzo del socket. La modifica di questi numeri può potenzialmente migliorare la scalabilità. Tuttavia, a seconda della situazione, queste modifiche potrebbero causare problemi di interoperabilità. È consigliabile prestare attenzione se si modificano questi valori.

È possibile usare l'interruzione forzata di TIME_WAIT per risolvere questa limitazione del ridimensionamento. L'interruzione forzata di TIME_WAIT consente di riutilizzare un socket in determinate situazioni, ad esempio quando il numero di sequenza nel pacchetto IP della nuova connessione supera il numero di sequenza dell'ultimo pacchetto della connessione precedente. In questo caso, il sistema operativo consente di stabilire la nuova connessione (accetta il nuovo SYN/ACK) e forzare la chiusura della connessione precedente in uno stato TIME_WAIT. Questa funzionalità è supportata nelle macchine virtuali Windows in Azure. Per informazioni sul supporto in altre macchine virtuali, rivolgersi al fornitore del sistema operativo.

Per informazioni sulla configurazione delle impostazioni TIME_WAIT TCP e dell'intervallo di porte di origine, vedere Impostazioni che possono essere modificate per migliorare le prestazioni di rete.

Fattori di rete virtuale che possono influire sulle prestazioni

Velocità effettiva in uscita massima della macchina virtuale

Azure offre diverse dimensioni e tipi di macchine virtuali, ognuno con una combinazione diversa di funzionalità di prestazioni. Una di queste funzionalità è la velocità effettiva di rete (o la larghezza di banda), misurata in megabit al secondo (Mbps). Poiché le macchine virtuali sono ospitate in hardware condiviso, la capacità di rete deve essere condivisa equamente tra le macchine virtuali che usano lo stesso hardware. Le macchine virtuali di dimensioni maggiori vengono allocate più larghezza di banda rispetto alle macchine virtuali più piccole.

La larghezza di banda di rete allocata a ogni macchina virtuale viene misurata in base al traffico in uscita (in uscita) dalla macchina virtuale. Tutto il traffico di rete che esce dalla macchina virtuale viene conteggiato per il limite allocato, indipendentemente dalla destinazione. Se una macchina virtuale ha un limite di 1.000 Mbps, tale limite si applica se il traffico in uscita è destinato a un'altra macchina virtuale nella stessa rete virtuale o a una all'esterno di Azure.

L'ingresso non viene misurato o limitato direttamente. Esistono tuttavia altri fattori, come i limiti di CPU e archiviazione, che possono influire sulla capacità di una macchina virtuale di elaborare i dati in ingresso.

La rete accelerata è progettata per migliorare le prestazioni di rete, tra cui latenza, velocità effettiva e utilizzo della CPU. La rete accelerata può migliorare la velocità effettiva di una macchina virtuale, ma può farlo solo fino alla larghezza di banda allocata della macchina virtuale.

Le macchine virtuali di Azure dispongono di almeno un'interfaccia di rete collegata. Potrebbero avere diversi. La larghezza di banda allocata a una macchina virtuale è la somma di tutto il traffico in uscita in tutte le interfacce di rete collegate al computer. In altre parole, la larghezza di banda viene allocata per ogni macchina virtuale, indipendentemente dal numero di interfacce di rete collegate al computer.

La velocità effettiva in uscita prevista e il numero di interfacce di rete supportate da ogni dimensione di macchina virtuale sono descritti in dettaglio in Dimensioni per le macchine virtuali Windows in Azure. Per visualizzare la velocità effettiva massima, selezionare un tipo, come Generale, e quindi trovare la sezione relativa alla serie di dimensioni nella pagina risultante (ad esempio, "Serie Dv2"). Per ogni serie è disponibile una tabella che fornisce le specifiche di rete nell'ultima colonna, denominata "Max NICs/Expected network bandwidth (Mbps).

Il limite di velocità effettiva si applica alla macchina virtuale. La velocità effettiva non è influenzata da questi fattori:

Numero di interfacce di rete: il limite di larghezza di banda si applica alla somma di tutto il traffico in uscita dalla macchina virtuale.
Rete accelerata: anche se questa funzionalità può essere utile per raggiungere il limite pubblicato, non modifica il limite.
Destinazione del traffico: tutte le destinazioni contano per il limite in uscita.
Protocollo: tutto il traffico in uscita su tutti i protocolli rientra nel limite.

Per altre informazioni, vedere Larghezza di banda di rete delle macchine virtuali.

Ottimizzazione delle macchine virtuali Linux

I kernel Linux moderni hanno funzionalità che consentono di ottenere coerenza e prestazioni, a volte richieste da determinati carichi di lavoro.

Per altre informazioni, vedere Ottimizzare la larghezza di banda di rete nelle macchine virtuali di Azure

Considerazioni sulle prestazioni internet

Come descritto in questo articolo, i fattori su Internet e al di fuori del controllo di Azure possono influire sulle prestazioni di rete. Ecco alcuni di questi fattori:

Latenza: il tempo di round trip tra due endpoint è interessato da problemi nelle reti intermedie, dal traffico che non accetta il percorso di distanza "più breve" e da percorsi di peering non ottimali.
Perdita di pacchetti: la perdita di pacchetti è causata dalla congestione della rete, dai problemi di percorso fisico e dalla sottoperformazione dei dispositivi di rete.
Dimensioni MTU/Frammentazione: la frammentazione lungo il percorso può causare ritardi nell'arrivo dei dati o nei pacchetti in arrivo fuori ordine, che possono influire sulla consegna dei pacchetti.

Traceroute è uno strumento valido per misurare le caratteristiche delle prestazioni di rete (ad esempio perdita di pacchetti e latenza) lungo ogni percorso di rete tra un dispositivo di origine e un dispositivo di destinazione.

Considerazioni sulla progettazione della rete

Oltre alle considerazioni descritte in precedenza in questo articolo, la topologia di una rete virtuale può influire sulle prestazioni della rete. Ad esempio, una progettazione hub-spoke che esegue il backhauling del traffico a livello globale verso una rete virtuale a hub singolo introduce la latenza di rete, che influisce sulle prestazioni complessive della rete.

Il numero di dispositivi di rete che il traffico di rete passa attraverso può influire anche sulla latenza complessiva. In una progettazione a hub e spoke, se il traffico passa attraverso un'appliance virtuale di rete a spoke e un'appliance virtuale di hub prima di passare a Internet, le appliance virtuali di rete introducono una certa latenza.

Aree di Azure, reti virtuali e latenza

Le aree di Azure sono costituite da più data center presenti all'interno di un'area geografica generale. Questi data center potrebbero non essere fisicamente accanto agli altri. In alcuni casi, sono separati da fino a 10 chilometri. La rete virtuale è una sovrimpressione logica nella rete del data center fisico di Azure. Una rete virtuale non implica una topologia di rete specifica all'interno del data center.

Ad esempio, due macchine virtuali che si trovano nella stessa rete virtuale e subnet potrebbero trovarsi in rack, righe o persino data center diversi. Possono essere separati da piedi di cavo in fibra ottica o da chilometri di cavo in fibra ottica. Questa variante potrebbe introdurre una latenza variabile (qualche millisecondo di differenza) tra macchine virtuali diverse.

La posizione geografica delle macchine virtuali e la potenziale latenza risultante tra due macchine virtuali è influenzata dalla configurazione di set di disponibilità, gruppi di posizionamento di prossimità e zone di disponibilità. Tuttavia, la distanza tra i data center in un'area è specifica dell'area e principalmente influenzata dalla topologia del data center nell'area.

Esaurimento delle porte NAT di origine

Una distribuzione in Azure può comunicare con gli endpoint all'esterno di Azure sulla rete Internet pubblica e/o nello spazio IP pubblico. Quando un'istanza avvia una connessione in uscita, Azure esegue il mapping dinamico dell'indirizzo IP privato a un indirizzo IP pubblico. Dopo aver creato questo mapping, il traffico restituito per il flusso originato in uscita può raggiungere anche l'indirizzo IP privato in cui ha avuto origine il flusso.

Per ogni connessione in uscita, Azure Load Balancer deve gestire questo mapping per un certo periodo di tempo. Con la natura multi-tenant di Azure, la gestione di questo mapping per ogni flusso in uscita per ogni macchina virtuale può richiedere un uso intensivo delle risorse. Sono quindi previsti limiti impostati e basati sulla configurazione dell'Rete virtuale di Azure. In alternativa, per dire che più precisamente, una macchina virtuale di Azure può effettuare solo alcune connessioni in uscita in un determinato momento. Quando vengono raggiunti questi limiti, la macchina virtuale non effettuerà più connessioni in uscita.

Ma questo comportamento è configurabile. Per ulteriori informazioni sul SNAT e sull'esaurimento delle porte SNAT, vedere questo articolo.

Misurare le prestazioni di rete in Azure

Molti dei massimi di prestazioni in questo articolo sono correlati alla latenza di rete/tempo di round trip (RTT) tra due macchine virtuali. Questa sezione fornisce alcuni suggerimenti su come testare latenza/RTT e come testare le prestazioni tcp e le prestazioni di rete delle macchine virtuali. È possibile ottimizzare e testare le prestazioni dei valori TCP/IP e di rete illustrati in precedenza usando le tecniche descritte in questa sezione. Immettere i valori di latenza, MTU, MSS e dimensioni della finestra nei calcoli forniti in precedenza e confrontare i valori teorici massimi con i valori effettivi osservati durante i test.

Misurare il tempo di round trip e la perdita di pacchetti

Le prestazioni TCP si basano principalmente su RTT e perdita di pacchetti. L'utilità PING disponibile in Windows e Linux offre il modo più semplice per misurare la perdita di pacchetti e RTT. L'output di PING mostra la latenza minima/massima/media tra un'origine e una destinazione. Mostra la perdita di pacchetti. PING usa il protocollo ICMP per impostazione predefinita. È possibile usare PsPing per testare TCP RTT. Per altre informazioni, vedere PsPing.

I ping ICMP e TCP non misurano il percorso dati di rete accelerato. Per misurare il percorso dati, leggere su Latte e SockPerf in questo articolo.

Misurare la larghezza di banda effettiva di una macchina virtuale

Per misurare accuratamente la larghezza di banda delle macchine virtuali di Azure, seguire queste indicazioni.

Per altre informazioni sul test di altri scenari, vedere gli articoli seguenti:

Rilevare comportamenti TCP inefficienti

Nelle acquisizioni di pacchetti, i clienti di Azure potrebbero visualizzare pacchetti TCP con flag TCP (SACK, DUP ACK, RETRANSMIT e FAST RETRANSMIT) che potrebbero indicare problemi di prestazioni di rete. Questi pacchetti indicano in modo specifico l'inefficienze di rete che derivano dalla perdita di pacchetti. Ma la perdita di pacchetti non è necessariamente causata da problemi di prestazioni di Azure. I problemi di prestazioni possono essere il risultato di applicazioni, sistemi operativi o altri problemi che potrebbero non essere direttamente correlati alla piattaforma Azure.

Tenere inoltre presente che la ritrasmissione e gli ACK duplicati sono normali in una rete. I protocolli TCP sono stati creati per essere affidabili. L'evidenza di questi pacchetti TCP in un'acquisizione di pacchetti non indica necessariamente un problema di rete sistemico, a meno che non siano eccessivi.

Tuttavia, questi tipi di pacchetti indicano che la velocità effettiva TCP non raggiunge le prestazioni massime, per motivi illustrati in altre sezioni di questo articolo.

Passaggi successivi

Dopo aver appreso le informazioni sull'ottimizzazione delle prestazioni TCP/IP per le macchine virtuali di Azure, prendere in considerazione l'esplorazione di altri fattori per la pianificazione delle reti virtuali. È anche possibile ottenere altre informazioni sulla connessione e la configurazione di reti virtuali.

Condividi tramite