Ottimizzazione TCP per le prestazioni della rete

Questa pagina illustra i metodi per calcolare le impostazioni corrette per ridurre la latenza delle connessioni TCP in Google Cloud e scenari ibridi. Questa pagina ti aiuta anche a capire come migliorare la latenza di connessione tra i processi all'interno di Google Cloud.

Secondo i principi dell'architettura moderna dei microservizi, gli sviluppatori devono creare microservizi con responsabilità singola. I servizi devono comunicare utilizzando TCP o UDP, in base alle aspettative di affidabilità del sistema. È quindi fondamentale che i sistemi basati su microservizi comunichino con affidabilità e bassa latenza.

Google Cloud offre affidabilità e bassa latenza grazie a una rete globale, pertanto anche gli utenti della tua applicazione possono operare a livello globale. Avere una rete globale significa creare una rete Virtual Private Cloud (VPC) che si estenda su più regioni e zone. Le applicazioni possono connettersi tra di loro in regioni e zone diverse senza mai uscire dalla rete Google Cloud .

Le applicazioni sviluppate per un ambiente di data center tradizionale possono avere prestazioni lente quando vengono spostate in un ambiente cloud ibrido, ovvero quando alcuni componenti dell'applicazione vengono eseguiti in un data center aziendale e altri nel cloud. Le prestazioni lente possono essere il risultato di diversi fattori. Questo articolo si concentra sulle latenze di round trip e su come la latenza influisce sulle prestazioni del protocollo TCP nelle applicazioni che spostano una quantità considerevole di dati su qualsiasi parte della rete.

Il problema: latenza e comportamento del protocollo TCP

Il protocollo TCP utilizza un meccanismo di windowing per impedire a un mittente veloce di inviare più dati di quanti il destinatario ne riesca a gestire. Il destinatario indica la quantità di dati che il mittente deve inviare prima di dover attendere un aggiornamento della finestra da parte del destinatario. Di conseguenza, se un'applicazione destinataria non può ricevere dati sulla connessione, esiste un limite alla quantità di dati che possono essere messi in coda in attesa dell'applicazione.

La finestra TCP consente un utilizzo efficiente della memoria sui sistemi di invio e ricezione. Man mano che l'applicazione destinataria consuma dati, gli aggiornamenti della finestra vengono inviati al mittente. Il modo più veloce in cui può avvenire un aggiornamento della finestra TCP è in un singolo round trip che porta alla seguente formula per uno dei limiti alle prestazioni del trasferimento collettivo di una connessione TCP:

Throughput <= dimensione della finestra / latenza del tempo di round trip (RTT)

Nella versione originale per TCP, questa finestra aveva una dimensione massima di 65535 byte (64 KiB - 1). Si tratta della quantità massima di dati che il mittente poteva inviare prima di ricevere un aggiornamento della finestra per consentire l'invio di più dati.

Modifiche al protocollo TCP dalla sua introduzione

Da quando è stato introdotto il protocollo TCP, alcune delle funzionalità principali sono cambiate:

Le velocità di rete tipiche sono aumentate di quattro ordini di grandezza.
La memoria tipica di un sistema è aumentata di quattro ordini di grandezza.

Come risultato della prima modifica, le dimensioni originali della finestra TCP comportavano un uso inefficiente delle risorse di rete. Un mittente inviava una quantità di dati pari alla dimensione della finestra alla massima velocità possibile in base alle condizioni di rete, quindi rimaneva inattivo per un periodo di tempo considerevole in attesa dell'aggiornamento della finestra TCP. Come risultato della seconda modifica, mittenti e destinatari possono utilizzare più memoria per la rete per risolvere la limitazione esposta dalla prima modifica.

Il seguente diagramma illustra questo interscambio.

Il mittente invia solo 64 KB di dati e attende molto tempo dopo l'invio prima di ricevere un aggiornamento della finestra.

Il mittente non può utilizzare completamente la rete perché è in attesa dell'aggiornamento della finestra TCP prima di inviare dati aggiuntivi.

Invio di più dati alla volta

La soluzione è inviare più dati alla volta. Man mano che la larghezza di banda della rete aumenta, più dati possono essere inseriti nella pipeline (rete) e, man mano che la pipeline diventa più lunga, ci vuole più tempo per confermare la ricezione dei dati. Questa relazione è nota come prodotto larghezza di banda-ritardo (BDP). Viene calcolato prendendo la larghezza di banda e moltiplicandola per il tempo di round trip (RTT): si ottiene un valore che specifica il numero ottimale di bit da inviare per riempire la pipeline. La formula è la seguente:

BDP (bit) = larghezza di banda (bit/s) * RTT (secondi)

Il BDP calcolato viene utilizzato come dimensione della finestra TCP per l'ottimizzazione.

Ad esempio, immagina di avere una rete da 10 Gbps con un RTT di 30 millisecondi. Per la dimensione della finestra, utilizza il valore della dimensione della finestra TCP originale (65535 byte). Questo valore non riesce minimamente a sfruttare la capacità della larghezza di banda. Le massime prestazioni TCP possibili su questo link sono indicate di seguito:

(65535 byte * 8 bit/byte) = larghezza di banda * 0,030 secondi
larghezza di banda = (65535 byte * 8 bit/byte) / 0,030 secondi
larghezza di banda = 524280 bit / 0,030 secondi
larghezza di banda = 17476000 bit / secondo

In altre parole, questi valori generano un throughput leggermente superiore a 17 Mbit al secondo, ovvero una piccola frazione della capacità di 10 Gbps della rete.

La soluzione: scalabilità delle dimensioni della finestra TCP

Per superare le limitazioni delle prestazioni imposte dalla versione originale della dimensione della finestra TCP, sono state introdotte estensioni al protocollo TCP che consentono di scalare le dimensioni della finestra a valori molto più grandi. La scalabilità delle finestre supporta finestre fino a 1.073.725.440 byte, ovvero quasi 1 GB. Questa funzionalità è descritta nel RFC 7323 come opzione di scalabilità della finestra TCP.

Le estensioni di scala della finestra espandono la definizione della finestra TCP in modo da utilizzare 30 bit e poi utilizzano un fattore di scalabilità implicito per trasportare questo valore di 30 bit nel campo della finestra di 16 bit dell'intestazione TCP. Per verificare se la funzionalità è abilitata sui sistemi basati su Linux, utilizza il seguente comando:

sudo sysctl net.ipv4.tcp_window_scaling

Tutte le macchine virtuali Linux Google Cloud dispongono di questa funzionalità attivata per impostazione predefinita. Se viene restituito un valore 1, significa che l'opzione è attivata. Se la funzionalità è disattivata, puoi attivarla utilizzando il seguente comando:

sudo sysctl -w net.ipv4.tcp_window_scaling=1

Throughput con una dimensione della finestra più ampia

Puoi utilizzare l'esempio precedente per mostrare il vantaggio della scalabilità della finestra. Come prima, ipotizza una rete da 10 Gbps con una latenza di 30 millisecondi, quindi calcola una nuova dimensione della finestra utilizzando questa formula:

(Velocità di collegamento * latenza) / 8 bit = dimensioni della finestra

Se inserisci i numeri di esempio, ottieni quanto segue:

(10 Gbps * 30 ms/1000 sec) / 8 bit/byte = dimensione finestra
(10000 Mbps * 0,030 secondi) / 8 bit/byte = 37,5 MB

L'aumento della dimensione della finestra TCP a 37 MB può aumentare il limite teorico delle prestazioni del trasferimento collettivo TCP a un valore che si avvicina alla capacità della rete. Naturalmente, molti altri fattori possono limitare le prestazioni, tra cui l'overhead del sistema, le dimensioni medie dei pacchetti e il numero di altri flussi che condividono il link, ma come puoi vedere le dimensioni della finestra riducono notevolmente i limiti imposti dalle dimensioni della finestra limitata precedente.

Impostazione di parametri configurabili di Linux per modificare le dimensioni della finestra TCP

In Linux, la dimensione della finestra TCP è influenzata dai seguenti parametri configurabili sysctl(8):

net.core.rmem_max
net.core.wmem_max
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem

I primi due parametri di configurazione influiscono sulla dimensione massima della finestra TCP per le applicazioni che tentano di controllarla direttamente, limitando la richiesta delle applicazioni a non più di questi valori. I due parametri configurabili successivi influiscono sulle dimensioni della finestra TCP per le applicazioni che fanno eseguire l'attività all'ottimizzazione automatica di Linux.

Il valore ottimale della dimensione della finestra dipende dalle circostanze specifiche, ma un punto di partenza è il BDP (prodotto larghezza di banda-ritardo) più grande per il percorso o i percorsi su cui prevedi che il sistema invii i dati. In questo caso, devi impostare i parametri configurabili seguendo questa procedura:

Assicurati di disporre dei privilegi root.
Apri le impostazioni attuali del buffer. Salva queste impostazioni nel caso in cui tu voglia eseguire il rollback di queste modifiche.
```
sudo sysctl -a | grep mem
```
Imposta una variabile di ambiente con la nuova dimensione della finestra TCP che desideri utilizzare:
```
MaxExpectedPathBDP=8388608
```
Imposta la dimensione massima del buffer di ricezione del sistema operativo per tutti i tipi di connessioni:
```
sudo sysctl -w net.core.rmem_max=$MaxExpectedPathBDP
```
Imposta la dimensione massima del buffer di invio del sistema operativo per tutti i tipi di connessioni:
```
sudo sysctl -w net.core.wmem_max=$MaxExpectedPathBDP
```
Regola le impostazioni del buffer della memoria di ricezione del protocollo TCP (tcp_rmem):
```
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 $MaxExpectedPathBDP"
```
L'impostazione tcp_rmem accetta tre valori:
- La dimensione minima del buffer di ricezione che può essere allocata per un socket TCP. In questo esempio, il valore è 4096 byte.
- La dimensione predefinita del buffer di ricezione, che effettua anche l'override del valore /proc/sys/net/core/rmem_default utilizzato da altri protocolli. Nell'esempio, il valore è 87380 byte.
- La dimensione del buffer di ricezione massima che può essere allocata per una socket TCP. Nell'esempio, è impostato sul valore stabilito in precedenza (8388608 byte).
Regola le impostazioni del buffer di memoria di invio TCP (tcp_wmem):
```
sudo sysctl -w net.ipv4.tcp_wmem="4096 16384 $MaxExpectedPathBDP"
```
L'impostazione tcp_wmem accetta tre valori:
- Lo spazio del buffer di invio TCP minimo disponibile per una singola socket TCP.
- Lo spazio del buffer predefinito consentito per una singola socket TCP.
- Lo spazio massimo del buffer di invio TCP.
Imposta i parametri configurabili in modo che le connessioni successive utilizzino i valori specificati:
```
sudo sysctl -w net.ipv4.route.flush=1
```

Per mantenere queste impostazioni dopo i riavvii, aggiungi i comandi impostati precedentemente al file /etc/sysctl.conf:

sudo bash -c 'cat << EOF >> /etc/sysctl.conf
net.core.rmem_max=8388608
net.core.wmem_max=8388608
net.ipv4.tcp_rmem=4096 87380 8388608
net.ipv4.tcp_wmem=4096 16384 8388608
net.ipv4.route.flush=1
EOF'

Test dell'RTT con una dimensione della finestra aggiornata

Quando il protocollo TCP ha una dimensione della finestra sufficientemente grande da utilizzare il BDP, il quadro cambia, come mostrato nel seguente diagramma:

Il mittente invia una grande quantità di dati alla volta e attende pochissimo tempo per l'aggiornamento di una finestra

Le dimensioni della finestra TCP possono sempre essere adattate in base alle risorse disponibili per il processo interessato e all'algoritmo TCP in uso. Come mostrato nel diagramma, la scalabilità della finestra consente a una connessione di andare ben oltre le dimensioni della finestra di 65 KiB definite nella specifica TCP originale.

Puoi verificarlo direttamente. Innanzitutto, assicurati di aver apportato modifiche alle dimensioni della finestra TCP sul computer locale e su un computer remoto impostando i parametri configurabili su entrambe le macchine. Quindi esegui questi comandi:

dd if=/dev/urandom of=sample.txt bs=1M count=1024 iflag=fullblock
scp sample.txt your_username@remotehost.com:/some/remote/directory

Il primo comando crea un file sample.txt da 1 GB con dati casuali. Il secondo comando copia il file dalla macchina locale a una macchina remota.

Prendi nota dell'output comando scp nella console, che mostra la larghezza di banda in Kbps. Dovresti notare una differenza significativa nei risultati prima e dopo le modifiche alle dimensioni della finestra TCP.

Passaggi successivi

Leggi il blog post 5 steps to better Google Cloud networking performance.
Scopri di più sui prodotti Global Networking.
Scopri di più sui livelli di rete su Google Cloud.
Scopri come eseguire il benchmarking delle prestazioni di rete.

Ottimizzazione TCP per le prestazioni della rete Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.