Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

Problèmes de conception – envoi de petits segments de données via TCP avec Winsock

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 214397
Résumé
Lorsque vous avez besoin d'envoyer des paquets de données de petite taille sur TCP, la conception de votre application Winsock est particulièrement important. Une conception qui ne prend pas en compte l'interaction d'accusé de réception retardé l'algorithme Nagle et mise en mémoire tampon Winsock affecte considérablement la performance. Cet article décrit ces problèmes à l'aide de deux études de cas et une série de recommandations pour l'envoi de paquets de données de petite taille efficace à partir d'une application Winsock est dérivée.
Plus d'informations

Arrière-plan

Lorsqu'une pile TCP Microsoft reçoit un paquet de données, un temporisateur de retard à 200-ms s'éteint. Lorsqu'un accusé de réception est envoyé par la suite, le minuteur de délai est réinitialisé et lancera un autre délai de 200-ms lors de la réception du paquet de données suivant.Pour augmenter l'efficacité dans les applications intranet et Internet, pile TCP de Microsoft utilise les critères suivants pour décider d'envoyer un accusé de réception des paquets de données reçues :
  • Si le deuxième paquet de données est reçu avant l'expiration de la minuterie du délai, l'accusé de réception est envoyé.
  • S'il existe des données à envoyer dans la même direction que celle de l'accusé de réception avant que le deuxième paquet de données est reçu et que le minuteur de délai arrive à expiration, l'accusé de réception est notification superposable avec le segment de données et envoyé immédiatement.
  • Lorsque la minuterie du délai expire, l'accusé de réception est envoyé.
Pour éviter que les paquets de données de petite taille à congest du réseau, pile TCP de Microsoft permet à l'algorithme de Nagle par défaut, qui associe une mémoire tampon de données provenant de plusieurs appels d'envoi et les délais d'envoi qu'il jusqu'à l'envoi d'un accusé de réception pour le paquet de données précédent est reçue de l'hôte distant. Deux exceptions à l'algorithme de Nagle sont les suivantes :
  • Si la pile a fusionné une mémoire tampon plus grand que l'unité de Transmission maximale (MTU), un paquet de taille normale est envoyé immédiatement, sans attendre l'accusé de réception à partir de l'hôte distant. Sur un réseau Ethernet, la MTU pour TCP/IP est 1460octets.
  • L'option de socket TCP_NODELAY est appliquée pour désactiver l'algorithme Nagle afin que les paquets de données de petite taille sont remis à l'hôte distant sans délai.
Pour optimiser les performances au niveau de la couche application, Winsock copies des tampons de données à partir d'application envoient des appels vers un tampon de noyau Winsock. Ensuite, la pile utilise ses propres heuristiques (par exemple, l'algorithme de Nagle) pour déterminer quand placer le paquet sur le réseau. Vous pouvez modifier la quantité de mémoire de tampon de noyau Winsock allouée au socket à l'aide de l'option SO_SNDBUF (il est 8 Ko par défaut). Si nécessaire, Winsock peut mettre en mémoire tampon nettement supérieure à la taille du tampon du SO_SNDBUF. Dans la plupart des cas, l'achèvement d'envoi dans l'application n'indique que la mémoire tampon de données dans une application envoyer d'appel est copié dans le tampon de noyau Winsock et n'indique pas que les données a atteint le support réseau. La seule exception est lorsque vous désactivez le Winsock mise en mémoire tampon en définissant SO_SNDBUF à 0.

Winsock utilise les règles suivantes pour indiquer la fin de l'envoi à l'application (en fonction de la façon dont l'envoi est appelé, la notification de fin peut être la fonction de renvoi d'un appel de blocage, un événement de signalisation ou en appelant une fonction de notification et ainsi de suite) :
  • Si le socket est toujours du quota SO_SNDBUF, Winsock copie les données de l'application d'envoi et indique la fin de l'envoi à l'application.
  • Si le socket est au-delà de quota SO_SNDBUF et il n'existe qu'un seul envoi précédemment mis en mémoire tampon toujours dans la mémoire tampon de pile du noyau, Winsock copie les données de l'application d'envoi et indique la fin de l'envoi à l'application.
  • Si le socket est au-delà de quota SO_SNDBUF et il existe plus d'une mise en mémoire tampon précédemment envoie dans la mémoire tampon de pile du noyau, Winsock copie les données à partir de l'application d'envoi. Winsock n'indique pas la fin de l'envoi à l'application jusqu'à ce que la pile termine assez envoie à la place le socket dans quota SO_SNDBUF ou qu'une seule condition d'envoi en attente.

Étude de cas 1

Vue d'ensemble :

Un client TCP Winsock doit envoyer des enregistrements de 10000 à un serveur TCP Winsock pour stocker dans une base de données. La taille des enregistrements varie de 20 octets à 100 octets de long. Pour simplifier la logique d'application, la conception est la suivante :
  • Le client n'envoyer blocage uniquement. Le serveur effectue un blocage recv uniquement.
  • Le socket client affecte le SO_SNDBUF 0 afin que chaque enregistrement s'éteint dans un segment de données unique.
  • Le serveur appelle recv dans une boucle. La mémoire tampon validée dans recv est 200 octets afin que chaque enregistrement peut être reçu dans un recevoir appel.

Performances :

Pendant le test, le développeur détecte que le client peut envoyer uniquement cinq enregistrements par seconde au serveur. Les enregistrements de 10000 total, 976K octets de données maximum (10000 * 100 / 1024), prend plus d'une demi-heure à envoyer au serveur.

Analyse :

Dans la mesure où le client ne définit pas l'option TCP_NODELAY, l'algorithme de Nagle force la pile TCP pour attendre un accusé de réception avant qu'il puisse envoyer un autre paquet sur le réseau. Toutefois, le client a désactivé le Winsock mise en mémoire tampon en définissant l'option SO_SNDBUF à 0. Par conséquent, le 10000 envoie les appels doivent être envoyés et ACK'ed individuellement. Chaque accusé de réception est différées 200-ms dans la mesure où il se produit sur la pile TCP du serveur :
  • Lorsque le serveur reçoit un paquet, son temporisateur de retard à 200-ms s'éteint.
  • Le serveur n'a pas besoin d'envoyer quoi que ce soit, afin que l'accusé de réception ne peut pas être notification superposable.
  • Le client n'envoie pas un autre paquet, à moins que le paquet précédent est confirmé.
  • Expiration de la minuterie du délai sur le serveur et l'accusé de réception est renvoyé.

Comment améliorer :

Il existe deux problèmes avec cette conception. Tout d'abord, il est le problème de minuteur de délai. Le client doit être en mesure d'envoyer deux paquets au serveur dans 200-Mme parce que le client utilise l'algorithme Nagle par défaut, elle doit simplement utiliser le tampon Winsock par défaut et pas SO_SNDBUF sur 0. Une fois la pile TCP a fusionné une mémoire tampon plus grande que l'unité de Transmission maximale (MTU), un paquet de taille normale est envoyé immédiatement, sans attendre l'accusé de réception à partir de l'hôte distant.

D'autre part, cette conception appelle unique envoi pour chaque enregistrement de cette petite taille. Envoyer cette petite d'une taille n'est pas très efficace. Dans ce cas, le développeur peut décider remplir chaque enregistrement à 100 octets et envoyer envoient l'appel 80 enregistrements à la fois à partir d'un client. Pour informer le serveur sera envoyé le nombre d'enregistrements total, le client souhaiterez démarrer la communication avec un en-tête fix-taille contenant le nombre d'enregistrements à suivre.

Étude de cas 2

Vue d'ensemble :

Une application de client TCP Winsock ouvre deux connexions avec une application de serveur TCP Winsock fournir un service de cotations boursières. La première connexion est utilisée comme un canal de commande à envoyer au serveur le symbole de cotation. La deuxième connexion est utilisée comme un canal de données pour recevoir la cotation boursière. Une fois les deux connexions ont été établies, le client envoie un symbole boursier au serveur via le canal de commande et attend la cotation boursière revenir via le canal de données. Il envoie la demande de symbole de cotation suivante au serveur uniquement après que la première cotation a été reçue. Le client et le serveur ne définissez pas l'option SO_SNDBUF et TCP_NODELAY.

Performances :

Pendant le test, le développeur détecte que le client pourrait obtenir uniquement les cinq actions par seconde.

Analyse :

Cette conception permet uniquement une seule demande de cotation boursière en attente à la fois. Le premier symbole de cotation est envoyé au serveur via le canal de commande (connexion) et une réponse est envoyée immédiatement à partir du serveur au client via le canal de données (connexion). Ensuite, le client envoie immédiatement la deuxième demande de symbole de cotation et l'envoyer retourne immédiatement lors de la copie de la mémoire tampon de demande dans l'appel d'envoi dans le tampon de noyau Winsock. Toutefois, la pile TCP du client ne peut pas envoyer la demande à partir de sa mémoire tampon noyau immédiatement, car la première envoyer via le canal de commande n'est pas encore acceptée. Une fois que les ms-200 retarder l'horloge au canal de commande serveur expire, l'accusé de réception pour la première demande de symbole est renvoyée au client. Ensuite, la deuxième demande de devis a été envoyée au serveur après le retard de 200-Mme que le devis pour le deuxième symbole de cotation revient immédiatement via le canal de données car, à ce stade, le minuteur de délai au niveau du canal de données client a expiré. Un accusé de réception de la réponse de devis précédente est reçue par le serveur. (N'oubliez pas que le client peut envoyer pas une deuxième demande de cotation boursière pour 200-ms, ce qui donne aux temps de la minuterie du délai sur le client pour la date d'expiration et d'envoyer un accusé de réception au serveur). Par conséquent, le client obtient la deuxième réponse de devis et peut émettre une autre demande de devis, qui entraîne le même cycle.

Comment améliorer :

La conception de la connexion de deux (canal) n'est pas nécessaire ici. Si vous utilisez une seule connexion pour la demande de cotation boursière et la réponse, l'accusé de réception de la demande de devis peut être notification superposable sur la réponse de devis et revenez immédiatement. Pour améliorer les performances, le client pourrait « multiplex » plusieurs demandes de cotation boursière dans un seul appel d'envoi vers le serveur et le serveur peut également « multiplex » plusieurs réponses de devis dans un seul appel d'envoyer au client. Si la conception de deux canaux unidirectionnels est vraiment nécessaire pour une raison quelconque, les deux côtés doivent définir l'option TCP_NODELAY afin que les petits paquets peuvent être envoyés immédiatement sans avoir à attendre un accusé de réception pour le paquet précédent.

Recommandations :

Bien que ces deux études de cas sont fabriqués, elles aident à illustrer certains pire des cas. Lorsque vous concevez une application qui implique le segment de données de petite taille complète envoie et recvs, vous devez envisager les indications suivantes :
  • Si les données sont des segments de temps non critique, l'application doit les fusionner dans un bloc de données plus grand pour passer à un appel d'envoi. Dans la mesure où la mémoire tampon d'envoi est susceptible d'être copiées dans le tampon de noyau Winsock, la mémoire tampon ne doit pas être trop grand. Un peu moins de 8 Ko est généralement efficace. Dans la mesure où le noyau Winsock Obtient un bloc plus grand que la taille MTU, il envoie plusieurs paquets de taille standard et un dernier paquet avec tout ce qui est à gauche. Le côté envoi, sauf le dernier paquet, n'est pas atteints par le minuteur de délai de 200-ms. Le dernier paquet, si elle se trouve être un paquet portant un numéro impair, est toujours l'objet de l'algorithme d'accusé de réception retardée. Si la pile de fin envoi Obtient un autre bloc dépasse la valeur MTU, il peut toujours contourner l'algorithme Nagle.
  • Dans la mesure du possible, éviter les connexions de socket avec un flux unidirectionnel de données. Les communications via les sockets unidirectionnels sont et plus facilement affectés par la Nagle retardée d'algorithmes d'accusé de réception. Si la communication suit une demande et un flux de réponse, vous devez utiliser un seul socket à faire envoie et recvs afin que l'accusé de réception peut être notification superposable sur la réponse.
  • Si tous les segments de données de petite taille doivent être envoyées immédiatement, définissez l'option TCP_NODELAY à l'émission.
  • Sauf si vous souhaitez garantir le qu'envoi d'un paquet sur le réseau lors de l'achèvement d'envoi est indiqué par Winsock, vous ne devez pas définir le SO_SNDBUF à zéro. En fait, la mémoire tampon de 8 Ko par défaut a été déterminée heuristique satisfaisante pour la plupart des cas et vous ne devez pas modifier, sauf si vous avez testé que votre nouveau paramètre de mémoire tampon Winsock vous offre des performances supérieures à la valeur par défaut. Également, la définition SO_SNDBUF à zéro est principalement utile pour les applications qui la majeure le transfert de données. Même alors, pour une efficacité maximale à utiliser en conjonction avec la double mise en mémoire tampon (plus d'un envoi en attente à un moment donné) et chevauchement des e/s.
  • Si la livraison de données n'a pas à être garanti, utilisent le protocole UDP.
Références
Pour plus d'informations sur l'accusé de réception retardée et l'algorithme de Nagle, consultez les éléments suivants :

Braden, R. [1989], RFC 1122, configuration requise pour Internet Hosts – Communication Layers, Internet Engineering Task Force.

Avertissement : cet article a été traduit automatiquement

Propriétés

ID d'article : 214397 - Dernière mise à jour : 03/14/2015 06:33:00 - Révision : 4.0

  • kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock kbmt KB214397 KbMtfr
Commentaires