qu'est-ce que la connexion TCP semi-ouverte et la connexion TCP semi-fermée

J'essaie de comprendre quelle est la différence entre une connexion TCP semi-ouverte et une connexion TCP semi-fermée. Quelqu'un peut-il dire exactement de quoi il s'agit?

Ce message se développe sur les connexions à moitié fermées. Pour les connexions semi-ouvertes, voir la description correcte de KContreau.

Que sont les connexions semi-fermées? Ou: Ce n'est pas un bug - c'est une fonctionnalité!

Chaque connexion TCP se compose de deux demi-connexions qui sont fermées indépendamment l'une de l'autre. Donc, si une extrémité envoie un FIN, l'autre extrémité est libre de simplement ACK que FIN (au lieu de FIN + ACK-ing), ce qui signale à l'extrémité d'envoi FIN qu'elle a encore des données à envoyer. Ainsi, les deux extrémités se retrouvent dans un état de transfert de données stable autre que ESTABLISHED - à savoir FIN_WAIT_2 (pour l'extrémité de réception) et CLOSE_WAIT (pour l'extrémité d'envoi). Une telle connexion est censée être à moitié fermée et TCP est en fait conçu pour prendre en charge ces scénarios, donc les connexions à moitié fermées sont une fonctionnalité TCP.

L'histoire de la connexion semi-fermée

Alors que la RFC 793 ne décrit que le mécanisme brut sans même mentionner le terme «semi-fermé», la RFC 1122 développe cette question dans la section 4.2.2.13. Vous vous demandez peut-être qui diable a besoin de cette fonctionnalité. Les concepteurs de TCP ont également implémenté le TCP / IP pour le système Unix et, comme tout utilisateur Unix, ont adoré la redirection d'E / S. Selon W. Stevens (TCP / IP illustré, section 18.5), le désir de rediriger les E / S des flux TCP était la motivation pour introduire la fonctionnalité. Il permet à l'acquéreur FIN de jouer le rôle ou d'être traduit par EOF. Il s'agit donc essentiellement d'une fonctionnalité qui vous permet de créer de manière nonchalante une interaction impomptu de type demande / réponse sur la couche application, où le FIN signale la "fin de la demande".

Lorsque TCP établit une connexion, il est considéré comme garanti car il y a une prise de contact qui a lieu:

1. L'ordinateur initiateur envoie la demande de connexion, envoyant un SYN
2. L'ordinateur répondant accorde la demande, en répondant avec un SYN-ACK
3. L'ordinateur initiateur envoie un accusé de réception, répondant avec un ACK

À ce stade, la connexion est établie et les données commencent à circuler. En revanche, un paquet UDP n'est pas garanti et est simplement envoyé dans l'espoir qu'il y parvienne.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Officiellement, selon les RFC, une connexion TCP semi-ouverte est lorsqu'un côté de la connexion établie s'est écrasé et n'a pas envoyé de notification indiquant que la connexion se terminait. Ce n'est pas l'usage courant aujourd'hui.

Officieusement, si peut se référer à une connexion embryonnaire, qui est une connexion en cours d'établissement.

http://en.wikipedia.org/wiki/Embryonic_connection

Semi-fermé est l'opposé de cette définition officieuse. C'est un état quelque part au milieu où les ordinateurs interrompent la connexion établie.

Les autres gars ont fait un travail assez décent pour décrire ce que sont réellement les connexions semi-ouvertes et semi-fermées , mais l'idée de connexions semi-ouvertes est également souvent recherchée dans le contexte où elles sont un PROBLÈME.

Il existe des arguments sur Internet quant à ce que la terminologie «semi-ouverte» ou «semi-fermée» devrait représenter, mais en ce qui me concerne, la terminologie est juste sémantique. Certains disent que les connexions "semi-ouvertes" sont un "problème", tandis que "semi-fermées" sont une fonctionnalité de conception qui vous permet de fermer votre flux d'envoi en fermant le flux d'envoi avant que le téléchargement de votre fichier ne se termine dans un état semi-fermé ( comme les autres utilisateurs l'ont décrit).

Cependant, concernant l'autre ... le "problème": il faut une prise de contact à 3 voies pour ouvrir une connexion TCP et une prise de contact à 4 voies pour la fermer.

TCP présente une vulnérabilité en ce que le paquet FIN final envoyé à un client peut être potentiellement abandonné par les routeurs / réseaux, ce qui entraîne une connexion semi-ouverte lorsque l'intention réelle était de fermer complètement la connexion. Cette approche et des approches similaires ont été des types populaires d'attaques par déni de service car elles ne nécessitent pas beaucoup de bande passante, mais peuvent consommer des poignées, des sockets et des threads précieux en fonction de la mise en œuvre du serveur, mais elles peuvent également se produire dans le monde réel avec une fréquence croissante grâce à nos opérateurs sans fil de mauvaise qualité.

Les systèmes d'exploitation ont tenté de lutter contre les attaques DDoS semi-ouvertes en limitant le nombre de connexions semi-ouvertes / fermées qui peuvent être présentes dans le système d'exploitation à un moment donné et en introduisant des durées maximales pendant lesquelles les connexions peuvent rester dans un état semi-ouvert / fermé. La dernière fois que j'ai vérifié, personnellement, le délai sur Windows était assez élevé (2 jours, si je me souviens bien).

Cette condition est encore aggravée par la nature facultative des connexions TCP persistantes, qui, si elles étaient pleinement implémentées, étaient conçues comme une solution au niveau du protocole (par opposition au niveau de l'application) pour détecter les connexions mortes / zombies. Mais, lorsque TCP a été conçu, la bande passante était considérablement plus précieuse qu'elle ne l'est actuellement, et il y avait des inquiétudes que les temporisateurs de maintien en vigueur obligatoires pour TCP seraient trop "bavards". Par conséquent, les connexions persistantes sont facultatives, ne sont généralement pas utilisées et ne sont pas garanties d'être transmises par des routeurs selon RFC1122. Donc ... même si vous activez les connexions persistantes au niveau de la couche TCP pour tenter de détecter / gérer le scénario, vous constaterez peut-être que lorsque votre trafic circule dans le monde, certains routeurs abandonnent les paquets persistants ... création potentiellement UN AUTRE scénario rare à tester.

Les connexions semi-ouvertes posent un peu un défi d'ingénierie aux codeurs qui écrivent des serveurs basés sur TCP, en particulier, car elles peuvent apparaître de manière involontaire au hasard, pendant les périodes de forte charge ... et généralement sur les serveurs de production ... et peuvent être difficile à remarquer dans les étapes de test Alpha / Beta. D'après mon expérience, je les ai trouvées se produire dans peut-être 1 sur 40 000 connexions sur des serveurs gérant 2,5 millions de connexions / jour, mais ces chiffres varient en fonction de vos conditions de trafic et des conditions de trafic de chaque segment d'Internet entre votre serveur et le client. .

En tant qu'ingénieur, il peut être difficile de détecter les problèmes qui se produisent rarement et uniquement sur des serveurs déployés en direct, il est donc important d'essayer de simuler cet état de connexion rare lors de l'écriture de code de serveur TCP pour analyser la réaction de votre serveur lorsque face à cette situation. Si votre serveur TCP utilise un nombre statique de threads de travail par exemple, vous pouvez trouver tous ceux-ci consommés par les connexions zombies lors du déploiement en production, par exemple. Si les connexions nécessitent beaucoup de mémoire de travail, le résultat final peut ressembler à une fuite de mémoire. etc.

Sans une solution de maintien en vie 100% viable, TCP laisse à la couche utilisateur le soin de déterminer comment les connexions semi-ouvertes / fermées sont gérées, donc votre code doit avoir un plan / mécanisme pour détecter, expirer et nettoyer- des ressources lorsque cette condition se produit ... c'est-à-dire ... en supposant que c'est un protocole que vous avez inventé et non l'une des nombreuses (mauvaises) normes ouvertes que les programmeurs utilisent généralement. Bien sûr, je fais référence à des protocoles tels que HTTP, qui s'exécutent exclusivement sur TCP. Ces protocoles sont extrêmement surestimés de l'avis de ce programmeur.

Reconnaissant les faiblesses de TCP et sa malheureuse popularité pour la transmission du trafic HTTP / Web, les entreprises intelligentes ont cherché à en remplacer un. Par exemple, Google a expérimenté un protocole appelé QUIC, qui transmet HTTP sur UDP. Il existe également un protocole ouvert appelé TSCP. Cependant, aucun de ces protocoles n'a été largement adopté.

En règle générale, je crée tous mes propres serveurs pour parler exclusivement sur mon propre protocole basé sur UDP. UDP est cependant plus délicat que vous ne le pensez, et j'ai l'impression de toujours le peaufiner pour qu'il soit plus rapide, plus intelligent, à latence plus faible, à encombrement moindre ... mais au moins je n'ai plus à gérer des connexions semi-ouvertes; )

Meilleure explication de la terminaison de connexion TCP

Dans le processus de prise de contact à 3 voies TCP, nous avons étudié comment la connexion s'établit entre le client et le serveur dans le protocole TCP (Transmission Control Protocol) à l'aide de segments de bits SYN. Dans cet article, nous étudierons comment la connexion TCP étroite entre le client et le serveur. Ici, nous devrons également envoyer des segments de bits au serveur dont le bit FIN est défini sur 1.

11

Comment fonctionne le mécanisme dans TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

en savoir plus sur: https://www.geeksforgeeks.org/tcp-connection-termination/

La connexion semi-fermée est un processus qui est établi lorsqu'une extrémité du serveur et du client a l'intention de mettre fin à la connexion. TCP est un processus orienté connexion donc chaque socket est ouvert pour une application particulière. Dans TCP, il n'y a aucune pression pour mettre fin à l'application. Ainsi, le processus orienté connexion prolonge la terminaison avec des signaux d'attente. cela s'appelle à moitié fermé dans TCP (connexion)