Différence entre les indicateurs push et urgent dans TCP

J’essaie de comprendre la différence entre un segment TCP avec le drapeau PSH et le drapeau URG . J’ai lu la RFC mais je ne pouvais toujours pas l’obtenir, est-ce que l’une d’entre elles met les données en mémoire tampon avant de les envoyer au processus et l’autre pas?

Ce sont deux mécanismes très différents.

PSH et la fonction PUSH

Lorsque vous envoyez des données, votre TCP mémoire tampon. Donc, si vous envoyez un personnage, il ne l’enverra pas immédiatement, mais attendez de voir si vous en avez plus. Mais peut-être voulez-vous que cela soit direct: c’est là que la fonction PUSH entre en jeu. Si vous écrivez des données, votre TCP va immédiatement créer un segment (ou quelques segments) et les pousser .

Mais l’histoire ne s’arrête pas là. Lorsque le TCP homologue reçoit les données, il les mémorisera naturellement, cela ne perturbera pas l’application pour chaque octet . Voici où le drapeau PSH en jeu. Si un TCP récepteur voit l’indicateur PSH, il transmettra immédiatement les données à l’application.

Il n’y a pas d’API pour définir le drapeau PSH . En général, il est défini par le kernel lorsqu’il vide le tampon. À partir de TCP / IP illustré:

Cet indicateur est classiquement utilisé pour indiquer que le tampon côté envoi du paquet a été vidé en même temps que l’envoi du paquet. En d’autres termes, lorsque le paquet contenant l’ensemble de champs de bits PSH a quitté l’expéditeur, l’expéditeur n’avait plus de données à envoyer.

Mais sachez que Stevens dit aussi:

Push (le destinataire devrait transmettre ces données à l’application dès que possible – pas implémenté ou utilisé de manière fiable )

Données URG et OOB

TCP est un protocole orienté stream. Donc, si vous poussez 64 Ko sur un côté, vous finirez par obtenir 64 Ko de l’autre. Alors, imaginez que vous poussez beaucoup de données et que vous ayez un message indiquant: “Hé, vous connaissez toutes les données que je viens d’envoyer? Ouais, jetez-les”. L’essentiel est qu’une fois que vous insérez des données dans une connexion, vous devez attendre que le destinataire les obtienne avant qu’elles n’atteignent les nouvelles données.

C’est là que le drapeau URG en jeu. Lorsque vous envoyez des données urgentes, votre TCP crée un segment spécial dans lequel il définit l’indicateur URG ainsi que le champ du pointeur urgent. Cela fait que le TCP récepteur reçoit les données urgentes sur un canal séparé vers l’application (par exemple, sur Unix, votre processus reçoit un SIGURG ). Cela permet à l’application de traiter les données hors bande¹ .


En outre, il est important de savoir que les données urgentes sont rarement utilisées aujourd’hui et pas très bien implémentées. Il est beaucoup plus facile d’utiliser un canal séparé ou une approche différente.


¹: RFC 6093 n’est pas d’accord avec cette utilisation de “out of band” et déclare:

Le mécanisme TCP urgent n’est PAS un mécanisme pour envoyer des données “hors bande”: les “données urgentes” doivent être transmises “en ligne” à l’utilisateur TCP.

Mais ensuite, il admet:

Par défaut, le dernier octet de “données urgentes” est livré “hors bande” à l’application. En d’autres termes, il n’est pas livré avec le stream de données normal.

Une application doit sortir de son chemin et spécifier par exemple SO_OOBINLINE pour obtenir une sémantique urgente conforme aux normes.

Si tout cela semble compliqué, n’utilisez pas de données urgentes .

Ajout de plus d’informations à celui déjà répondu.

  • Le bit URG , s’il est défini comme prioritaire sur les données, ce qui signifie qu’au lieu d’attendre que l’intégralité du stream d’octets soit transmise en avance sur les données “urgentes”, les données urgentes seront envoyées en urgence stream à transmettre qui est en avance sur lui.

  • Lorsque le bit URG est défini, le pointeur d’urgence est également défini (dans le champ Options de l’en-tête TCP : 16 bits).

  • Le pointeur URG indique combien d’octets de données sont urgents dans le segment arrivé. (Exemple: si la taille des données est de 100 octets et que seuls les 50 premiers octets sont urgents, le pointeur urgent aura la valeur 50).

  • Maintenant, arrive au bit PSH . Le bit PSH sert à indiquer à TCP qu’il n’attend pas que le tampon soit plein et envoie immédiatement les données. De même, lorsque le récepteur reçoit le segment avec un drapeau PSH défini, il doit envoyer les données immédiatement à la couche supérieure sans attendre que le tampon de réception devienne plein. L’exemple pratique de ceci est l’application telnet où l’application envoie des données sous la forme de quelques frappes. Le telnet deviendra inutilisable s’il attend que le tampon devienne plein et transmette ensuite les données au récepteur.

Je n’accepterais pas tout dans une RFC de manière trop rigide, il semble y avoir une certaine ambiguïté concernant la mise en œuvre de ces drapeaux. URG concerne l’envoi de paquets avant le remplissage des tampons, tandis que PSH contrôle les données en mouvement dans la stack à la réception.