Pourquoi la création d'une nouvelle connexion TCP est-elle considérée comme coûteuse?

Je ne comprends pas pourquoi la création d'une nouvelle connexion TCP est considérée comme une tâche coûteuse. Fondamentalement, la configuration d'une nouvelle connexion fait référence à la prise de contact à 3 voies de TCP. C'est donc envoyer deux paquets et en recevoir un. Étant donné que des milliers de paquets (de données) suivront, la prise de contact ne peut pas être la partie coûteuse. Peut-il?

Je crois, d'une manière générale, que l'ouverture d'une connexion TCP est considérée comme coûteuse par rapport à la possibilité de réutiliser des connexions déjà ouvertes en la gardant ouverte. Vous avez raison, l'ouverture d'une connexion ne prendra que 3 paquets / tours, mais ce temps - 3 x votre RTT - est bien au-delà du coût de réutilisation d'une connexion déjà ouverte, qui est beaucoup plus proche de 0. La disparité augmente encore plus rapidement si vous ouvrent et ferment les connexions fréquemment.

Vous avez certainement raison cependant, par rapport au nombre de tours que vous allez voir car l'application "fait son truc", ces 3 paquets peuvent sembler assez petits, mais encore une fois, cela dépend de la façon dont vous voulez comparer les options ET comment se comporte votre application / combien de fois vous prévoyez d'ouvrir une connexion.

Modifier Si nous parlons UDP vs TCP si, Cheekaleek ici est 100% correct - les frais généraux de est massive à long terme par rapport aux opérations de UDP sans connexion

C'est certainement plus de frais généraux que d'envoyer un paquet UDP et de ne pas se soucier de ce qui se passe après cela.

TCP est également livré avec plus de données d'en-tête et maintient l'état de connexion, ce qui consommera des ressources.

Donc oui, par rapport à UDP, TCP est plus cher, mais cher est un terme relatif.

"Les connexions TCP sont le meilleur ami d'une fille ???"

Il ne s'agit pas seulement d'envoyer et de recevoir des paquets. De la mémoire supplémentaire doit être allouée et, au minimum, des tables d'état de mise en réseau mises à jour à chaque étape jusqu'à ce que la session soit établie. Sans oublier les contrôles de sécurité supplémentaires qui peuvent être effectués (protection contre l'usurpation d'itinéraire, etc.).

En utilisant simplement quelques exemples de chiffres (car nous ne parlons pas d'un système d'exploitation spécifique) si un paquet pour une session établie a un coût CPU de 1 unité, le coût d'une nouvelle session peut être 10x ou 100x ce coût en nombre de opérations effectuées. La plupart des pare-feu matériels avec lesquels j'ai travaillé peuvent gérer un ordre de grandeur moins de nouvelles connexions par seconde qu'ils ne peuvent gérer les sessions établies.

Ce n'est souvent pas si grave, d'autant plus qu'un SYN-SYN / ACK-ACK se produit en millisecondes, mais pour les grands systèmes avec de nombreux clients, les nouvelles sessions peuvent se transformer en un surcoût important .

La quantité ou le type de trafic importe beaucoup moins que le code associé à l'allocation réelle de la mémoire et au suivi associé des informations d'état. Si vous voulez avoir une idée très approximative de ce que cela implique, jetez un œil à la quantité de code dans le noyau Linux associé à TCP par rapport à celui associé à UDP ou ICMP. Une comparaison incroyablement grossière montre que TCP nécessite quelque chose comme 10 fois le nombre de lignes de code trouvées dans UDP.

Dans les réseaux IP, la quantité de maintenance d'état requise est l'un des déterminants les plus importants de l'évolutivité. Pour TCP noeuds finaux ceci est exprimé non seulement dans SYN / ACK , mais aussi dans l' entretien continu des fenêtres coulissantes, des numéros de séquence, tampon actions de gestion et de qualité de service, etc. Découvrez la complexité des États fédérés de Micronésie pour tcp et considèrent le manque inhérent de même dans UDP ...