Invio di segmenti di dati di piccole dimensioni su TCP con Winsock problematiche di progettazione

Traduzione articoli Traduzione articoli
Identificativo articolo: 214397 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Quando è necessario inviare pacchetti di dati di piccole dimensioni su TCP, la progettazione dell'applicazione Winsock è particolarmente importante. Una struttura che non accetta in considerazione l'interazione di riconoscimento ritardata, algoritmo Nagle e memorizzazione nel buffer del Winsock drasticamente può influire sulle prestazioni. In questo articolo vengono discussi questi problemi, utilizzando un paio di studi di casi e deriva una serie di raccomandazioni per l'invio in modo efficiente i pacchetti di piccole dimensioni dati da un'applicazione Winsock.

Informazioni

Sfondo

Quando uno stack Microsoft TCP riceve un pacchetto di dati, un timer di ritardo-200 ms si spegne. Quando infine viene inviato un ACK, il timer di intervallo viene reimpostato e avvierà un altro ritardo-200 ms quando viene ricevuto il pacchetto di dati successivo. Per aumentare l'efficienza in Internet e le applicazioni intranet, stack Microsoft TCP utilizza i seguenti criteri per decidere quando inviare un ACK sui pacchetti di dati ricevuti:
  • Se viene ricevuto il secondo pacchetto di dati prima della scadenza del timer ritardo, viene inviato l'ACK.
  • Se non vi sono dati da inviare nella stessa direzione come l'ACK prima viene ricevuto il secondo pacchetto di dati e della scadenza del timer ritardo, è è che l'ACK Piggyback con segmento di dati e inviato immediatamente.
  • Quando il timer di intervallo scade, viene inviato l'ACK.
Per evitare di pacchetti di dati piccolo congest della rete, stack Microsoft TCP consente l'algoritmo Nagle per impostazione predefinita, che assegna un buffer di piccole dimensioni dati da più chiamate di invio e ritardi invio che finché non inviato un ACK per il pacchetto di dati precedente viene ricevuto dall'host remoto. Di seguito sono due eccezioni all'algoritmo Nagle:
  • Se lo stack è coalesced un buffer di dati più grande di MTU (Maximum Transmission Unit), un pacchetto di ingrandita viene inviato immediatamente senza attendere l'ACK dall'host remoto. In una rete Ethernet, il valore MTU per TCP/IP è 1460 Byte.
  • L'opzione di socket TCP_NODELAY viene applicata per disabilitare la l'algoritmo Nagle, in modo che l'host remoto senza ritardo vengono recapitati i pacchetti di dati di piccole dimensioni.
Per ottimizzare le prestazioni a livello di applicazione, Winsock copie buffer di dati dall'applicazione inviare chiamate a un buffer del kernel di Winsock. Quindi, lo stack utilizza proprio euristica (ad esempio l'algoritmo Nagle) per determinare quando inserire effettivamente il pacchetto sul cavo. È possibile modificare la quantità di buffer del kernel di Winsock allocato al socket utilizzando l'opzione SO_SNDBUF (è 8 K per impostazione predefinita). Se necessario, Winsock può buffer notevolmente più la dimensione del buffer di SO_SNDBUF. Nella maggior parte dei casi, il completamento di invio nell'applicazione indica solo il buffer di dati in un'applicazione invia la chiamata viene copiato nel buffer del kernel di Winsock e non indica che i dati sono raggiunto il supporto di rete. L'unica eccezione è quando si disattiva il buffer del Winsock impostando SO_SNDBUF su 0.

Winsock utilizza le regole seguenti per indicare un completamento invio all'applicazione (a seconda della modalità di invio viene richiamato, la notifica del completamento potrebbe sia la funzione restituisce da una chiamata di blocco, segnalazione di un evento o la chiamata una funzione di notifica e così via):
  • Se il socket è ancora in SO_SNDBUF quota, Winsock copia i dati dall'invio di applicazione e indica il completamento invio all'applicazione.
  • Se il socket è oltre la quota SO_SNDBUF ed è presente un solo invio in precedenza nel buffer ancora il buffer di stack del kernel, Winsock copia i dati dall'invio di applicazione e indica il completamento dell'invio all'applicazione.
  • Se il socket è oltre la quota SO_SNDBUF ed è presente più di un buffer in precedenza inviare il buffer di stack del kernel, Winsock copia i dati dall'invio di applicazione. Winsock non indica il completamento di invio per l'applicazione fino lo stack al completamento sufficiente Invia per inserire il socket nuovamente all'interno di SO_SNDBUF quota o solo una condizione di invio in sospeso.

Case study 1

Cenni preliminari:

Un client Winsock TCP deve inviare 10000 record un server Winsock TCP per archiviare in un database. Le dimensioni dei record variano da byte 20 a 100 byte. Per semplificare la logica dell'applicazione, la struttura è come indicato di seguito:
  • Il client non solo invia blocco. Il server non solo recv blocco.
  • Il socket client imposta il SO_SNDBUF su 0 in modo che ogni record si spengono in un segmento dati singola.
  • Il server chiama recv in un ciclo. Il buffer registrato in recv è 200 byte, in modo che ogni record possono essere ricevuti in una recv chiamata.

Prestazioni:

Durante la fase di verifica, lo sviluppatore rileva che il client può solo inviare cinque record al secondo al server. Totale 10000 record, massimo 976 K byte di dati (10000 * 100 / 1024), richiede più della metà di un'ora inviare al server.

Analisi:

Poiché il client non impostata l'opzione TCP_NODELAY, l'algoritmo Nagle impone lo stack TCP di attesa per un ACK prima di poter inviare un altro pacchetto sulla rete. Tuttavia, il client ha disattivato il buffer del Winsock impostando l'opzione di SO_SNDBUF su 0. Di conseguenza, il 10000 invia chiama sono per l'invio e ACK'ed singolarmente. Ogni ACK è ms-200 ritardata poiché si verifica quanto segue nello stack TCP del server:
  • Quando il server riceve un pacchetto, il timer di ritardo-200 ms si spegne.
  • Il server non è necessario inviare qualsiasi elemento, in modo che non può essere piggyback l'ACK.
  • Il client non invia un altro pacchetto, a meno che non viene riconosciuto il pacchetto precedente.
  • È invia l'ACK e della scadenza del timer ritardo sul server.

Come migliorare:

Esistono due problemi in questa progettazione. Innanzitutto, è il problema del timer di ritardo. Il client deve poter inviare due pacchetti al server all'interno di-200 ms poiché il client utilizza l'algoritmo Nagle per impostazione predefinita, deve utilizzare il buffering di Winsock predefinito e non SO_SNDBUF viene impostato su 0. Una volta che lo stack TCP è coalesced un buffer di dimensioni maggiore rispetto a MTU (Maximum Transmission Unit), un pacchetto ingrandita viene inviato immediatamente senza attendere l'ACK dall'host remoto.

In secondo luogo, questo tipo di progetto chiama una trasmissione per ogni record di tali dimensioni ridotte. Invio di questo piccolo di una dimensione non è molto efficiente. In questo caso, è possibile che lo sviluppatore desideri ogni record a 100 byte di pad e inviare 80 record alla volta da un client invia la chiamata. Per consentire al server di conoscere il numero di record che verrà inviato in totale, il client desideri iniziare la comunicazione con un'intestazione di dimensioni per la correzione che contiene il numero di record da seguire.

Case study 2

Cenni preliminari:

Un'applicazione client di Winsock TCP apre due connessioni con un'applicazione di Winsock TCP server forniscono il servizio Quotazioni. La prima connessione viene utilizzata come un canale di comando per inviare al server il simbolo. La seconda connessione viene utilizzata come un canale di dati per ricevere le quotazioni di borsa. Dopo che le due connessioni sono state stabilite, il client invia al server attraverso il canale di comando un simbolo azionario e attende la quotazione ritorno attraverso il canale dati. Invia la richiesta di simbolo successiva il server solo dopo il primo quotazioni sono stata ricevuta. Il client e il server non impostare l'opzione SO_SNDBUF e TCP_NODELAY.

Prestazioni:

Durante la fase di verifica, lo sviluppatore rileva che il client potrebbe ricevere solo cinque offerte al secondo.

Analisi:

Questa progettazione consente solo di una richiesta di quotazioni in sospeso alla volta. Il primo simbolo viene inviato al server attraverso il canale di comando (connessione) e viene inviata una risposta immediatamente dal server al client tramite il canale dati (connessione). Il client invia immediatamente la seconda richiesta simbolo, quindi INVIO restituisce immediatamente come buffer delle richieste nella chiamata di invio viene copiato nel buffer del kernel di Winsock. Tuttavia, lo stack TCP di client non può inviare la richiesta dal buffer del kernel immediatamente perché il primo invio tramite canale dei comandi non viene riconosciuto ancora. Dopo il ms-200 ritardare timer al canale dei comandi server scade, l'ACK per la prima richiesta simbolo ritorna al client. Quindi, la seconda richiesta offerta venga correttamente inviata al server dopo viene ritardato per l'offerta per il simbolo secondo torna immediatamente attraverso il canale dati poiché, in questa fase, è scaduto il timer ritardo sul canale di dati client di MS 200. Un ACK per la risposta offerta precedente viene ricevuto dal server. (Ricordare che il client potrebbe non inviare una seconda richiesta quotazioni di Borsa per ms-200, in cui il tempo per il timer ritardo sul client di scadenza e inviare un ACK al server). Di conseguenza, il client ottiene la seconda risposta offerta e può eseguire un'altra richiesta di offerta, è soggette a stesso ciclo.

Come migliorare:

La progettazione di connessione di due (canale) è qui non necessaria. Se si utilizza solo una connessione per la richiesta di quotazione e la risposta, è possibile piggyback sulla risposta offerta e tornare immediatamente l'ACK per la richiesta di offerta. Per migliorare ulteriormente le prestazioni, il client potrebbe "multiplex" più richieste di quotazioni di borsa in una chiamata di invio al server e il server potrebbe inoltre "multiplex" risposte offerta multiple in una chiamata di invio al client. Se la struttura di due canali unidirezionali è effettivamente necessaria per qualche motivo, il entrambi i lati è in consigliabile di impostare l'opzione TCP_NODELAY in modo che i pacchetti di piccole dimensioni possono essere inviati immediatamente senza attendere un ACK per il pacchetto precedente.

Consigli:

Sebbene questi due case study vengono creato, contribuiscono a illustrare alcuni scenari casi peggiore. Quando si progetta un'applicazione che riguarda il segmento di dati estesi di piccole dimensioni Invia e recvs, è opportuno le linee guida riportate di seguito:
  • Se i dati sono segmenti di tempo non critico, l'applicazione deve coalesce loro in un più grande blocco di dati per passare a una chiamata di invio. Poiché il buffer di invio è probabilmente essere copiati nel buffer del kernel di Winsock, il buffer non deve essere troppo grande. Un po' meno di 8 KB è in genere efficace. Purché il kernel di Winsock Ottiene un blocco maggiore il valore MTU, invia più pacchetti ingrandita e un ultimo pacchetto con qualsiasi viene lasciato. Il lato di invio, ad eccezione dell'ultimo pacchetto, non verrà raggiunto dal timer ritardo-200 ms. L'ultimo pacchetto caso da un pacchetto con numero dispari, è ancora soggetto all'algoritmo di riconoscimento ritardata. Se lo stack di fine invio ottiene maggiore il valore MTU un altro blocco, comunque possibile ignorare l'algoritmo Nagle.
  • Se possibile, evitare le connessioni socket con flusso di dati unidirezionale. Comunicazioni su socket unidirezionali sono più facilmente interessate dal Nagle e ritardata di algoritmi di riconoscimento. Se la comunicazione è seguito da una richiesta e un flusso di risposta, è necessario utilizzare un unico socket per eseguire sia recvs che invia in modo che l'ACK può essere piggyback sulla risposta.
  • In caso di tutti i segmenti pochi dati vengano inviati immediatamente, è necessario impostare TCP_NODELAY opzione lato del mittente.
  • Se non si desidera garantire che un pacchetto viene inviato in rete quando un completamento di invio è indicato da Winsock, non occorre impostare il SO_SNDBUF a zero. Infatti, il buffer di 8 K predefinito è stato modo euristico determinato funziona anche per la maggior parte dei casi è e non modificare, a meno che non sono verificate che la nuova impostazione buffer del Winsock fornisce prestazioni migliori il valore predefinito. Inoltre, principalmente è utile per le applicazioni che consente di operazioni di massa trasferimento dei dati impostando SO_SNDBUF su zero. Quindi anche per migliorare l'efficienza massima è consigliabile utilizzare in combinazione con il doppio buffering (più di un invio in sospeso in qualsiasi momento) e operazioni di I/O sovrapposte.
  • Se il recapito di dati non necessario garantita, utilizzare UDP.

Riferimenti

Per ulteriori informazioni su Ritardo riconoscimento e l'algoritmo Nagle, vedere le seguenti operazioni:

Braden, r. [1989] RFC 1122, requisiti per gli host Internet, livelli di comunicazione Internet Engineering Task Force.

Proprietà

Identificativo articolo: 214397 - Ultima modifica: lunedì 11 luglio 2005 - Revisione: 3.1
Le informazioni in questo articolo si applicano a:
  • Microsoft Platform Software Development Kit-edizione gennaio 2000
Chiavi: 
kbmt kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock KB214397 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 214397
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com