Qu'est-ce que TCP Half Open Connection et TCP à demi-connexion fermée?

Cette publication se développe sur des connexions à moitié fermées. Pour les connexions à demi ouvertes, consultez la description correcte de KContreau.

Qu'est-ce que les connexions à demi fermé? 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, alors l'autre extrémité est libre de simplement ACK que FIN (au lieu de FIN + ACK-ing it), ce qui signale à la fin de l'envoi FIN qu'il 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 la réception) et CLOSE_WAIT (pour l'envoi final). Une telle connexion est dite à moitié fermée et TCP est réellement conçu pour supporter ces scénarios, donc les connexions à moitié fermées sont une fonctionnalité TCP.

L'histoire de la connexion à moitié fermée

Alors que la RFC 793 ne décrit que le mécanisme brut sans même mentionner le terme "à moitié fermé", la RFC 1122 élabore à ce sujet la section 4.2.2.13. Vous vous demandez peut-être qui a besoin de cette fonctionnalité. Les concepteurs de TCP ont également implémenté TCP / IP pour le système Unix et, comme tout utilisateur de Unix, a aimé la redirection des E / S. Selon W. Stevens (TCP / IP illustré, section 18.5), le désir de redirection des flux TCP / E / O a été la motivation pour présenter la fonctionnalité. Il permet au FIN ack 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 occasionnellement une interaction Impulptu / Response-Style sur la couche d'application, où le FIN signale la "fin de la demande".

Les autres gars ont fait un travail assez décent pour décrire les connexions à moitié ouvertes et à moitié fermées, mais l'idée de connexions à moitié ouvertes est également souvent recherchée dans le contexte d'un PROBLÈME.

Il existe des arguments sur Internet quant à savoir ce que la terminologie "à moitié ouvert" ou "à demi fermé" devrait représenter, mais pour ma part, la terminologie est juste sémantique. Certains disent que les connexions «à demi ouvertes» sont un «problème», tandis que «à moitié fermé» sont une fonction 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 soit terminé à moitié ( Comme les autres utilisateurs l'ont décrit).

Cependant, en ce qui concerne l'autre … le «problème»: il faut une poignée de main à 3 voies pour ouvrir une connexion TCP et une poignée de main à 4 voies pour la fermer.

TCP a une vulnérabilité dans la mesure où le paquet FIN final envoyé à un client peut être potentiellement supprimé par des routeurs / réseaux, ce qui entraîne une connexion à demi ouvert 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 de déni de service, car elles ne nécessitent pas beaucoup de bande passante, mais potentiellement mangent des poignées, des sockets et des threads précieuses en fonction de la mise en œuvre du serveur, mais elles peuvent également se produire dans le monde réel Avec une fréquence accrue grâce à nos transporteurs sans fil de mauvaise qualité.

Les systèmes d'exploitation ont tenté de lutter contre les attaques DDoS à demi 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 longueurs maximales de temps que les connexions peuvent rester dans un État semi-ouvert / fermé. Enfin, j'ai vérifié, personnellement, que la limite de temps sur Windows était assez élevée (2 jours, si je me rappelle).

Cette condition est encore aggravée par la nature facultative de TCP keep-alives, qui, si elles étaient entièrement mises en œuvre, étaient destinées à être une solution de niveau de protocole (par opposition à niveau d'application) pour détecter les connexions mort / zombie. Mais, lorsque le protocole TCP a été conçu, la bande passante était considérablement plus précieuse qu'elle ne l'est maintenant, et il y avait des inquiétudes quant au fait que les temporisateurs conservateurs pour TCP soient trop "bavard". Par conséquent, keep-alives est facultatif, n'est généralement pas utilisé et ne doit pas être transmis par des routeurs selon RFC1122. Donc … même si vous permettez de garder à l'écart de la couche TCP pour tenter de détecter / gérer le scénario, vous pouvez constater que lorsque votre trafic parcourt le monde entier, certains routeurs abandonnent les paquets keep-alive … en créant Potentiellement un autre scénario rare à tester.

Les connexions à mi-ouvert posent un défi d'ingénierie aux codeurs qui écrivent des serveurs basés sur TCP, notamment parce qu'ils peuvent apparaître involontairement au hasard, en période de chargement élevé … et généralement sur les serveurs de production … et peut être Difficile à noter dans les étapes de test Alpha / Beta. Dans mon expérience, je les ai trouvés dans peut-être 1 sur 40 000 connexions sur les serveurs qui gèrent 2,5 millions de connexions par jour, mais ces chiffres varieront en fonction de vos conditions de trafic et des conditions de trafic de chaque étape de l'Internet entre votre serveur et le client .

En tant qu'ingénieur, il peut être difficile de retrouver des problèmes qui se produisent peu fréquemment et uniquement sur des serveurs déployés en direct, il est donc important d'essayer de simuler cette connexion rare lors de l'écriture du code du serveur TCP pour analyser comment votre serveur réagira lorsque Face à cette situation. Si votre serveur TCP utilise un nombre statique de threads de travail par exemple, vous pouvez les trouver tous consommés par des connexions zombies lorsque vous déployez sur la production, par exemple. Si les connexions exigent beaucoup de mémoire de travail, le résultat final pourrait apparaître comme une fuite de mémoire. etc.

Sans une solution 100% viable, keep-alive, TCP laisse à la couche utilisateur pour déterminer comment les connexions à demi ouvertes / fermées sont traitées, de sorte que votre code doit avoir un plan / mécanisme pour détecter, éteindre et nettoyer, Jusqu'à ce que cette condition se produise … c'est-à-dire … en supposant qu'il s'agit d'un protocole que vous avez inventé et non pas l'un des nombreux (mauvais) standards ouverts que les programmeurs utilisent généralement. Bien sûr, je me réfère à des protocoles tels que HTTP, qui se déroulent exclusivement sur TCP. Ces protocoles sont extrêmement surévalués dans l'opinion de ce programmeur.

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

En règle générale, je crée tous mes propres serveurs pour parler exclusivement de mon propre protocole basé sur UDP. UDP est plus difficile que vous ne le pensez, et j'ai l'impression que je le modifie toujours pour être plus rapide, plus intelligente, plus basse, moins encombrante … mais au moins je n'ai plus à traiter les connexions à moitié ouvertes; )

Lorsque TCP établit une connexion, il est considéré comme garanti puisqu'il existe une poignée de main qui se déroule:

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

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

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 que la connexion se terminait. Ce n'est pas l'usage courant aujourd'hui.

De manière non officielle, si on peut se référer à une connexion embryonnaire, qui est une connexion dans le processus d'établissement.

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

Demi-fermé est le contraire de cette définition non officielle. C'est un état quelque part au milieu où les ordinateurs détruisent la connexion établie.

La connexion à moitié fermée est un processus qui est établi lorsqu'une extrémité du serveur et un client ont l'intention de terminer la connexion. TCP est un processus de connexion orientée, chaque socket étant 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. Ceci est appelé à moitié fermé dans TCP (connexion)