Ottimizzazione TCP per le prestazioni della rete


Questa pagina illustra i metodi per calcolare le impostazioni corrette per diminuire la latenza delle connessioni TCP in Google Cloud e diversi scenari. Questa pagina ti aiuta anche a capire come migliorare la connessione la latenza tra i processi in Google Cloud.

L'architettura moderna dei microservizi sostiene che gli sviluppatori debbano creare piccoli servizi con responsabilità singola. I servizi devono comunicare utilizzando TCP o UDP, in base alle aspettative di affidabilità del sistema. Di conseguenza, è fondamentale per consentire ai sistemi basati su microservizi di comunicare con affidabilità una latenza di pochi millisecondi.

Google Cloud offre affidabilità e bassa latenza fornendo una rete globale, il che significa che anche gli utenti della tua applicazione possono espandersi a livello globale. Avere un piano globale devi creare una rete Virtual Private Cloud (VPC) che copre regioni e zone. Le applicazioni possono connettersi tra loro in regioni e zone diverse senza mai uscire dalla rete Google Cloud.

Applicazioni che sono state scritte per un ambiente di data center tradizionale possono rallentare le prestazioni quando passano a un cloud ibrido ovvero quando alcuni dei componenti dell'applicazione vengono eseguiti in un ambiente e altri data center vengono eseguiti nel cloud. Le prestazioni lente possono essere il risultato di diversi fattori. Questo articolo si concentra sulle latenze di andata e ritorno 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 TCP

TCP utilizza un meccanismo di gestione delle finestre per impedire a un mittente veloce di superare un ricevente lento. Il destinatario pubblicizza la quantità di dati che il mittente deve inviare prima il mittente deve attendere l'aggiornamento della finestra dal destinatario. Di conseguenza, se un l'applicazione ricevente non può ricevere dati sulla connessione, c'è un limite a la 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 di ricezione consuma dati, gli aggiornamenti della finestra vengono inviati al mittente. Il più rapido aggiornamento delle finestre è in un solo andata e ritorno, il che genera la seguente formula per uno dei limiti al trasferimento collettivo prestazioni di una connessione TCP:

Velocità effettiva <= dimensione finestra / tempo di round trip (RTT) latenza

Nella progettazione originale per TCP, questa finestra ha 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 nel TCP dalla sua introduzione

Dall'introduzione del protocollo TCP, alcune funzionalità chiave sono cambiate:

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

Il risultato della prima modifica è che le dimensioni delle finestre TCP originali hanno comportato un uso inefficiente delle risorse di rete. Un mittente invia una finestra di dati alla massima velocità possibile in base alle condizioni di rete, quindi rimane inattivo per un periodo di tempo considerevole in attesa dell'aggiornamento della finestra TCP. La Il risultato della seconda modifica è che mittenti e destinatari possono utilizzare del networking al fine di risolvere il limite esposto dalla prima modifica.

Il seguente diagramma illustra questo snodo.

Il mittente invia solo 64 KB di dati e attende molto tempo dopo l&#39;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. Come larghezza di banda della rete, aumenta, più dati possono rientrare nella pipeline (rete) e man mano che la pipeline diventa più lungo, occorre più tempo per confermare la ricezione dei dati. Questa relazione è nota come prodotto larghezza di banda-ritardo (BDP). Viene calcolato come larghezza di banda moltiplicata per il tempo di round trip (RTT), ottenendo un valore che specifica il numero ottimale di bit da inviare per riempire il canale. La formula è la seguente:

BDP (bit) = larghezza di banda (bit/secondo) * 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 RTT di 30 millisecondi. Per la dimensione della finestra, utilizza il valore della dimensione della finestra TCP originale (65535 byte). Questo valore non si avvicina allo sfruttare e la capacità di larghezza di banda. Le prestazioni TCP massime possibili su questo link sono come segue:

(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

Per dirlo in altro modo, questi valori generano una velocità effettiva leggermente superiore di 17 Mbit al secondo, una piccola frazione della velocità di 10 Gbit/s funzionalità.

La soluzione: scalabilità TCP delle dimensioni della finestra

Risolvere i limiti delle prestazioni imposti dal design originale di TCP della finestra, sono state introdotte estensioni al protocollo TCP che consentono dimensioni della finestra da scalare a valori molto più grandi. Il ridimensionamento delle finestre supporta le finestre fino a 1.073.725.440 byte, o quasi 1 GiB. Questa funzionalità è descritta nel RFC 7323 come opzione di scala della finestra TCP.

Le estensioni per la scalabilità delle finestre espandono la definizione della finestra TCP in modo da utilizzare 30 bit e quindi utilizzare un fattore di scala implicito per portare questo valore a 30 bit nella dell'intestazione TCP. Per verificare se la funzionalità è abilitata su sistemi basati su Linux, utilizza questo comando:

sudo sysctl net.ipv4.tcp_window_scaling

Questa funzionalità è attivata per impostazione predefinita su tutte le macchine virtuali Linux Google Cloud. Se viene restituito un valore 1, significa che l'opzione è abilitata. Se è disabilitata, puoi abilitarla utilizzando il seguente comando:

sudo sysctl -w net.ipv4.tcp_window_scaling=1

Velocità effettiva con finestre di dimensioni maggiori

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 finestra

Se inserisci i numeri di esempio, ottieni quanto segue:

(10 Gbps * 30 ms/1000 sec) / 8 bit/byte = dimensione della finestra
(10.000 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 di Prestazioni del trasferimento collettivo TCP a un valore che si avvicina alle capacità di rete. Naturalmente, molti altri fattori possono limitare il rendimento, tra cui il sovraccarico 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 attenuano notevolmente i limiti imposti dalle dimensioni della finestra limitata precedente.

Impostazione dei tunable Linux per la modifica delle dimensioni della finestra TCP

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

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 secondi due parametri influenzano il TCP dimensioni della finestra per le applicazioni che consentono il funzionamento dell'ottimizzazione automatica di Linux.

Il valore ottimale della dimensione della finestra dipende dalle circostanze specifiche, ma un punto di partenza è il BDP (prodotto di larghezza di banda e tempo di latenza) più grande per il percorso o i percorsi su cui prevedi che il sistema invii i dati. In questo caso, vuoi imposta i tunable seguendo questa procedura:

  1. Assicurati di disporre dei privilegi di root.
  2. Visualizza le impostazioni attuali del buffer. Se vuoi, salva queste impostazioni eseguire il rollback di queste modifiche.

    sudo sysctl -a | grep mem
    
  3. Imposta una variabile di ambiente sulla nuova dimensione della finestra TCP che vuoi usa:

    MaxExpectedPathBDP=8388608
    
  4. 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
    
  5. 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
    
  6. Imposta le impostazioni del buffer della memoria di ricezione TCP (tcp_rmem):

    sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 $MaxExpectedPathBDP"
    

    L'impostazione tcp_rmem assume 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 sostituisce anche la dimensione Valore /proc/sys/net/core/rmem_default utilizzato da altri protocolli. Nell'esempio, il valore è 87380 byte.
    • La dimensione massima del buffer di ricezione che può essere allocata per un socket TCP. Nell'esempio, è impostato il valore impostato in precedenza (8388608 byte).
  7. Imposta 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 assume tre valori:

    • Lo spazio minimo del buffer di invio TCP disponibile per un singolo socket TCP.
    • Lo spazio di buffer predefinito consentito per un singolo socket TCP.
    • Lo spazio massimo del buffer di invio TCP.
  8. Imposta i parametri di configurazione in modo che le connessioni successive utilizzino i valori specificati:

    sudo sysctl -w net.ipv4.route.flush=1
    

Per rendere queste impostazioni persistenti tra i riavvii, aggiungi i comandi che hai impostato in precedenza 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 di RTT con una dimensione della finestra aggiornata

Quando TCP ha una finestra di dimensioni abbastanza grandi per utilizzare il BDP, l'immagine modifiche, come illustrato nel diagramma seguente:

Il mittente invia una grande quantità di dati alla volta e attende pochissimo tempo per l&#39;aggiornamento di una finestra

La dimensione della finestra TCP può sempre essere adattata in base alle risorse disponibili il processo coinvolto e l'algoritmo TCP in uso. Come mostra il diagramma, finestra consente a una connessione di andare ben oltre le dimensioni della finestra di 65 KiB definita specifica TCP originale.

Puoi verificarlo autonomamente. Innanzitutto, assicurati di aver impostato le dimensioni della finestra TCP le modifiche al computer locale e a un computer remoto impostando i tunable su entrambe le macchine. Poi 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. La il secondo comando copia il file dalla tua macchina locale a una macchina remota.

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

Passaggi successivi