Problemi specifici di TCP/IP
Alcune tecniche di programmazione si verificano in problemi di prestazioni collegati all'implementazione di TCP/IP. Tali problemi di prestazioni non suggeriscono che TCP/IP è inefficiente o un collo di bottiglia delle prestazioni; questi problemi vengono invece visualizzati quando le operazioni TCP/IP non sono comprese.
I problemi seguenti identificano gli scenari comuni in cui la combinazione di operazioni TCP/IP e scelte di sviluppo di applicazioni di rete comporta prestazioni scarse.
Applicazioni con un numero elevato di connessioni.
Alcune applicazioni creano un'istanza di una nuova connessione TCP per ogni transazione. La creazione di connessioni TCP richiede tempo, contribuisce a rtt aggiuntivi ed è soggetta a un rallentamento dell'avvio. Inoltre, le connessioni chiuse sono soggette a TIME-WAIT, che utilizza le risorse di sistema.
Le applicazioni con connessione intensa sono in gran parte comuni perché sono facili da creare; la verifica e la gestione degli errori è molto semplice. Il rilevamento di errori in una connessione persistente può richiedere un notevole lavoro e codice, pertanto talvolta non viene completato.
Risolvere questa situazione riutilizzando la connessione TCP. Ciò può causare la serializzazione sulla connessione TCP, a meno che le transazioni non vengano multiplexing su più connessioni. Se questo approccio viene adottato, il numero di connessioni deve essere limitato a due e sono necessari frame a livello di applicazione e gestione avanzata degli errori.
Buffer di trasmissione di lunghezza zero e invii di blocco.
La disattivazione del buffering tramite la funzione setsockopt per impostare il buffer di invio (SO_SNDBUF) su zero è simile alla disattivazione della memorizzazione nella cache del disco. Quando si imposta il buffer di invio su zero e l'emissione di invii di blocco, un'applicazione ha una probabilità del 50% di raggiungere un riconoscimento ritardato di 200 millisecondi.
Non disattivare l'invio del buffering a meno che non si sia considerato l'impatto in tutti gli ambienti di rete. Un'eccezione: i dati di streaming che usano operazioni di I/O sovrapposte devono impostare il buffer di invio su zero.
Modello di programmazione Send-Send-Receive.
La strutturazione di un'applicazione per l'esecuzione di send-send-receive aumenta le probabilità di incontrare l'algoritmo Nagle, causando un ritardo di RTT+200 ms. L'algoritmo Nagle può essere rilevato se l'ultimo invio è minore della dimensione massima del segmento TCP (MSS, i dati massimi in un singolo datagramma). MSS può essere un valore molto grande (64K in IPv4 e persino più grande in IPv6), quindi non contare su un mss di dimensioni generalmente ridotte. Un'opzione migliore consiste nel combinare i due invii in un singolo invio usando la funzione WSASend o memcpy .
Numero elevato di connessioni simultanee.
Le connessioni simultanee non devono superare due, ad eccezione delle applicazioni per scopi speciali. Il superamento di due connessioni simultanee comporta uno spreco di risorse. Una buona regola consiste nell'avere fino a quattro connessioni di breve durata o due connessioni permanenti per ogni destinazione.
Argomenti correlati