Problèmes de conception - envoi des segments de données de petite taille via TCP avec Winsock

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 de d'accusé de réception différé, l'algorithme Nagle et mise en mémoire tampon de Winsock affecte considérablement la performance. Cet article aborde ces problèmes, à l'aide de deux études de cas et dérive une série de recommandations pour l'envoi de paquets de données de petite taille efficacement à partir d'une application Winsock.

Arrière-plan

Lorsque la pile Microsoft TCP reçoit un paquet de données, un minuteur de délai de 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 lorsque le paquet de données suivant est reçu. Pour accroître l'efficacité dans Internet et les applications intranet, pile Microsoft TCP utilise les critères suivants pour décider à quel moment envoyer un accusé de réception sur les paquets de données reçues :

• Si le deuxième paquet de données est reçu avant l'expiration du minuteur de délai, l'accusé de réception est envoyé.
• S'il y a des données à envoyer dans la même direction que celle de l'accusé de réception avant la réception du deuxième paquet de données et l'expiration du minuteur de délai, l'accusé de réception est piggybacked avec le segment de données et envoyé immédiatement.
• Lorsque le minuteur de délai expire, l'accusé de réception est envoyé.

Pour éviter d'avoir des paquets de données de petite taille congest le réseau, pile TCP de Microsoft permet l'algorithme Nagle par défaut, ce qui associe un tampon de données petit à partir de plusieurs appels d'envoi et retards envoi elle jusqu'à ce qu'un ACK pour le paquet de données précédente envoyé est reçu ordinateur hôte distant. Deux exceptions à l'algorithme Nagle sont les suivantes :

• Si la pile a fusionné une mémoire tampon plus grand que le MTU (maximum transmission unit), un paquet en taille réelle est envoyé immédiatement sans attendre l'accusé de réception à partir d'ordinateur 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 arrivent dans ordinateur hôte distant sans délai.

Pour optimiser les performances au niveau de la couche application, tampons de données de copies de Winsock à partir d'application envoient des appels à une mémoire tampon du noyau Winsock. Ensuite, la pile utilise ses propres heuristiques (par exemple, l'algorithme Nagle) pour déterminer quand la mettent réellement le paquet sur le réseau. Vous pouvez modifier la quantité de mémoire 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 considérablement plus de taille de la mémoire tampon la SO_SNDBUF. Dans la plupart des cas, l'achèvement d'envoi dans l'application indique uniquement la mémoire tampon de données d'une application pour envoyer l'appel est copié dans la mémoire tampon du noyau Winsock et n'indique pas que les données a atteint le support réseau. La seule exception est lorsque vous désactivez la mise en tampon Winsock en définissant SO_SNDBUF à 0.

Winsock utilise les règles suivantes pour indiquer un achèvement d'envoi à l'application (selon la façon dont l'envoi est appelé, la notification de fin peut être la fonction de renvoi d'un appel bloquant, 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 l'achèvement d'envoi à l'application.
• Si le socket n'est pas SO_SNDBUF contingent et qu'il y a qu'un seul envoi précédemment mis en mémoire tampon de la mémoire tampon du noyau de pile, Winsock copie les données de l'application d'envoi et indique l'achèvement d'envoi à l'application.
• Si le socket n'est pas SO_SNDBUF contingent et qu'il y a plus d'une précédemment mis en mémoire tampon envoyer dans la mémoire tampon de pile du noyau, Winsock copie les données à partir de l'application d'envoi. Winsock n'indique pas l'achèvement d'envoi à l'application jusqu'à ce que la pile termine suffisamment envoie pour placer le support arrière dans SO_SNDBUF quota ou qu'une condition en attente d'envoi.

Etude de cas 1

Vue d'ensemble :

Un client Winsock TCP doit envoyer des 10000 enregistrements à un serveur de ports 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 ne blocage envoi uniquement. Le serveur effectue recv blocage uniquement.
• Le socket client affecte la SO_SNDBUF 0 afin que chaque enregistrement est transmis 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 recv appel.

Performances :

Au cours des tests, le développeur trouve que le client peut envoyer seulement cinq enregistrements par seconde au serveur. Les enregistrements de 10 000 total, maximum K 976 octets de données (10000 * 100 / 1 024), prend plus d'une demi-heure à envoyer au serveur.

Analyse :

Étant donné que le client ne définit pas l'option TCP_NODELAY, l'algorithme 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é la mise en tampon Winsock en définissant l'option SO_SNDBUF à 0. Par conséquent, le 10000 envoi appelle doit être envoyé et ACK'ed individuellement. Chaque ACK est 200-ms différées car les événements suivants se produisent sur la pile TCP du serveur :

• Lorsque le serveur reçoit un paquet, son compteur de retard de 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 piggybacked.
• Le client n'enverra pas un autre paquet, à moins que le paquet précédent est reconnu.
• L'expiration du minuteur de délai sur le serveur et l'accusé de réception est envoyé en retour.

Comment faire pour améliorer :

Il existe deux problèmes grâce à 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 au sein de ms. 200 dans la mesure où le client utilise l'algorithme Nagle par défaut, il doit simplement utiliser le Winsock par défaut mise en mémoire tampon et pas la valeur 0 SO_SNDBUF. Une fois la pile TCP a fusionné une mémoire tampon plus grande que le MTU (maximum transmission unit), un paquet en taille réelle est envoyé immédiatement sans attendre l'accusé de réception à partir d'ordinateur hôte distant.

Deuxièmement, cette conception appelle unique envoi pour chaque enregistrement de cette petite taille. Envoi de cette petite d'une taille n'est pas très efficace. Dans ce cas, le développeur pourriez chaque enregistrement à 100 octets du pavé et envoyer des 80 enregistrements à la fois à partir d'un client envoient l'appel. Pour laisser le serveur à savoir le nombre d'enregistrements sera envoyé au total, le client souhaiterez débutent la communication avec un en-tête en taille réelle correctif contenant le nombre d'enregistrements à suivre.

Etude de cas 2

Vue d'ensemble :

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

Performances :

Au cours des tests, le développeur trouve que le client peut obtenir uniquement les cinq Cotations par seconde.

Analyse :

Cette conception permet uniquement une seule demande de cotation boursière en suspens à 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 sur le canal de données (connexion). Ensuite, le client envoie immédiatement la deuxième demande symbole boursier et l'envoi immédiat que le tampon de demande dans l'appel d'envoi est copié dans la mémoire tampon du noyau Winsock. Toutefois, la pile TCP client ne peut pas envoyer la demande à partir de sa mémoire tampon du noyau immédiatement, car la première envoyer via le canal de commande is not acknowledged encore. Après que 200-ms 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 est correctement envoyée au serveur après être retardée pour 200-ms. 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é. Réception d'un ACK pour la réponse de devis précédente par le serveur. (N'oubliez pas que le client pourrait ne pas envoyer une deuxième demande de cotation boursière pour 200-ms, donc ce qui laisse le temps pour le minuteur de délai sur le client pour expirer et à 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 est soumise à une même cycle.

Comment faire pour améliorer :

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

Recommandations :

Ces deux études de cas sont fabriqués, mais elles permettent de montrer certains scénarios pires. Lorsque vous concevez une application qui implique de nombreuses données petit segment envoie et recvs, vous devez prendre en compte les instructions suivantes :

• Si les données sont des segments de temps non critiques, l'application doit les fusionner dans un bloc de données plus grand pour passer à un appel d'envoi. Étant donné que la mémoire tampon d'envoi est susceptible d'être copiés dans le buffer de noyau Winsock, la mémoire tampon ne doit pas être trop volumineux. Un peu moins de 8 Ko est généralement efficace. Dans la mesure où le noyau Winsock Obtient un bloc plus grand que le MTU, il envoie plusieurs paquets de taille standard et un dernier paquet avec tout ce qui n'est pas. Le côté envoi, sauf le dernier paquet ne sera pas atteint par l'horloge de délai de 200 ms. Le dernier paquet, si elle est un paquet impaires, est toujours soumis à l'algorithme d'accusé de réception retardés. Si la pile de fin envoi Obtient un autre bloc supérieure à la MTU, il peut toujours contourner l'algorithme Nagle.
• Si possible, évitez de connexions de socket au flux de données unidirectionnel. Communications par sockets unidirectionnels sont plus facilement affectés par la Nagle et retardée algorithmes d'accusé de réception. Si la communication suit une demande et un flux de réponse, vous devez utiliser un seul socket pour effectuer des émissions et recvs de sorte que l'accusé de réception peut être piggybacked sur la réponse.
• Si tous les segments de données de petite taille pas à envoyer immédiatement, définissez option TCP_NODELAY sur la fin d'envoi.
• Sauf si vous souhaitez garantir qu'un paquet est envoyé sur le réseau lorsqu'un état de l'envoi est indiqué par Winsock, vous ne devez pas définir la SO_SNDBUF à zéro. En fait, le tampon de 8 Ko par défaut a été déterminé heuristique fonctionne bien pour la plupart des situations et vous ne devez pas modifier il sauf si vous avez testé que votre nouveau paramètre de mémoire tampon de Winsock offre vous de meilleures performances que la valeur par défaut. En outre, si vous définissez SO_SNDBUF zéro est principalement bénéfique pour les applications qui par transfert de données bloc. Même alors, pour une efficacité maximale doivent l'utiliser conjointement avec double mise en mémoire tampon (plusieurs envoyer exceptionnel à un moment donné) et chevauchement des e/S.
• Si la livraison de données ne dispose pas de garantir, utilisez UDP.

Pour plus d'informations sur les retenues différées d'accusé de réception et l'algorithme Nagle, veuillez consulter le texte suivant :

Braden, r. [1989], RFC 1122, Requirements for Internet Hosts--Communication Layers, Internet Engineering Task Force.