Problèmes spécifiques à TCP/IP

Certaines techniques de programmation rencontrent des problèmes de performances liés à l’implémentation de TCP/IP. Ces problèmes de performances ne suggèrent pas que TCP/IP soit inefficace ou qu’il s’agit d’un goulot d’étranglement des performances ; Ces problèmes sont plutôt rencontrés lorsque les opérations TCP/IP ne sont pas comprises.

Les problèmes suivants identifient des scénarios courants dans lesquels la combinaison d’opérations TCP/IP et de choix de développement d’applications réseau entraîne des performances médiocres.

• Connecter des applications lourdes.

  Certaines applications instancient une nouvelle connexion TCP pour chaque transaction. L’établissement d’une connexion TCP prend du temps, contribue à des RTT supplémentaires et est soumis à un démarrage lent. En outre, les connexions fermées sont soumises à TIME-WAIT, qui consomme des ressources système.

  Les applications gourmandes en connexion sont courantes en grande partie parce qu’elles sont faciles à créer ; le test et la gestion des erreurs sont très simples. La détection d’erreurs sur une connexion persistante peut prendre beaucoup de code et d’efforts, et n’est donc parfois pas terminée.

  Pour remédier à cette situation, réutiliser la connexion TCP. Cela peut entraîner la sérialisation sur la connexion TCP, sauf si les transactions sont multiplexées sur plusieurs connexions. Si cette approche est adoptée, le nombre de connexions doit être limité à deux, et l’encadrement de la couche application et la gestion avancée des erreurs sont requis.

• Mémoires tampons d’envoi de longueur nulle et blocage des envois.

  La désactivation de la mise en mémoire tampon à l’aide de la fonction setsockopt pour définir la mémoire tampon d’envoi (SO_SNDBUF) sur zéro revient à désactiver la mise en cache du disque. Lors de la définition de la mémoire tampon d’envoi sur zéro et de l’émission d’envois de blocage, une application a cinquante pour cent de chances d’atteindre un accusé de réception différé de 200 millisecondes.

  Ne désactivez pas la mise en mémoire tampon d’envoi, sauf si vous avez pris en compte l’impact dans tous les environnements réseau. Une exception : la diffusion en continu de données utilisant des E/S qui se chevauchent doit définir la mémoire tampon d’envoi sur zéro.

• Modèle de programmation Send-Send-Receive.

  La structuration d’une application pour effectuer l’envoi-envoi-réception augmente vos chances de rencontrer l’algorithme Nagle, ce qui entraîne un délai de RTT+200 ms. L’algorithme Nagle peut être rencontré si le dernier envoi est inférieur à la taille maximale du segment TCP (MSS, le nombre maximal de données d’un seul datagramme). MSS peut être une valeur très importante (64 Ko en IPv4, et encore plus dans IPv6), donc ne comptez pas sur un MSS généralement petit. Une meilleure option consiste à combiner les deux envois en un seul envoi à l’aide de la fonction WSASend ou memcpy .

• Grand nombre de connexions simultanées.

  Les connexions simultanées ne doivent pas dépasser deux, sauf dans les applications à usage spécial. Le dépassement de deux connexions simultanées entraîne un gaspillage de ressources. Une bonne règle consiste à avoir jusqu’à quatre connexions de courte durée, ou deux connexions persistantes par destination.

Rubriques connexes

Comportement de l’application

Applications Windows Sockets hautes performances

Algorithme Nagle