Différence entre les indicateurs Push et urgent dans TCP
J'essaie de comprendre la différence entre un segment TCP avec l'indicateur PSH et l'indicateur URG. J'ai lu le RFC mais je n'ai toujours pas pu l'obtenir, l'un d'eux met-il en mémoire tampon les données avant de les envoyer au processus et l'autre non?
Ce sont deux mécanismes très différents.
PSH et la fonction Push
Lorsque vous envoyez des données, votre TCP les met en 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 que vous voulez qu'il aille directement sur le fil: c'est là que la fonction Push entre en jeu. Si vous poussez des données, votre TCP créera immédiatement un segment (ou quelques segments) et Push eux.
Mais l'histoire ne s'arrête pas là. Lorsque l'homologue TCP reçoit les données, il les tamponnera naturellement cela ne dérangera pas l'application pour chaque octet . C'est là que le drapeau PSH entre en jeu. Si un récepteur TCP voit le drapeau PSH, il va immédiatement - Poussez les données vers le application.
Il n'y a pas d'API pour définir l'indicateur PSH. En règle générale, il est défini par le noyau lorsqu'il vide le tampon. Depuis TCP/IP illustré:
Ce drapeau est classiquement utilisé pour indiquer que le tampon du côté envoyant le paquet a été vidé en même temps que l'envoi du paquet. En d'autres termes, lorsque le paquet avec le champ 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 récepteur doit transmettre ces données à l'application dès que possible - non implémenté ou utilisé de manière fiable )
Données URG et OOB
TCP est un protocole orienté flux. Donc, si vous poussez 64 Ko d'octets d'un côté, vous obtiendrez finalement 64 Ko d'octets de l'autre. Imaginez donc que vous poussiez beaucoup de données et que vous ayez un message qui dit "Hé, vous savez toutes ces données que je viens d'envoyer? Ouais, jetez-les". L'essentiel de la question est qu'une fois que vous avez poussé des données sur une connexion, vous devez attendre que le récepteur les obtienne avant d'arriver aux nouvelles données.
C'est là que le drapeau URG entre en jeu. Lorsque vous envoyez des données urgentes, votre TCP crée un segment spécial dans lequel il définit le drapeau URG et également le champ du pointeur urgent. provoque la réception TCP pour transmettre les données urgentes sur un canal séparé à l'application (par exemple sur Unix, votre processus obtient un SIGURG). Cela permet à l'application de traiter les données hors bande¹ .
Par ailleurs, il est important de savoir que les données urgentes sont rarement utilisées aujourd'hui et pas très bien mises en œuvre. Il est beaucoup plus facile d'utiliser un canal séparé ou une approche complètement différente.
¹: RFC 609 n'est pas d'accord avec cette utilisation de "hors bande" et déclare:
Le mécanisme TCP urgent n'est PAS un mécanisme d'envoi de données "hors bande": les soi-disant "données urgentes" doivent être livrées "en ligne" au TCP utilisateur.
Mais ensuite, il admet:
Par défaut, le dernier octet de "données urgentes" est délivré "hors bande" à l'application. Autrement dit, il n'est pas fourni dans le cadre du flux 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é, juste n'utilisez pas de données urgentes .
Ajout d'un peu plus d'informations à celui déjà répondu.
Le bit
URG, s'il est défini, donne la priorité aux données, ce qui signifie qu'au lieu d'attendre la transmission du flux d'octets entier qui est en avance sur les données "urgentes", les données urgentes seront envoyées d'urgence et ne seront pas attendez la transmission du flux d'octets entier qui le précède.Lorsque le bit
URGest défini, le pointeur urgent est également défini (dans le champ Options d'en-têteTCP: 16 bits).Le pointeur
URGindique combien d'octets de données sont urgents dans le segment qui est 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 une valeur de 50).Venons-en maintenant au bit
PSH. Le bitPSHa pour fonction d'indiquer TCP qui n'attendent pas que le tampon soit plein et envoient les données immédiatement. De même lorsque le récepteur reçoit le segment avecPSHflag set, devrait envoyer les données immédiatement à la couche supérieure sans attendre que le tampon de réception soit plein. L'exemple pratique est l'application telnet où l'application envoie des données sous forme de quelques touches. Le telnet devenir inutilisable s'il attend que le tampon soit plein, puis transmet les données au récepteur.
Je n'accepterais pas tout dans un RFC de manière trop rigide, il semble qu'il y ait une ambiguïté sur la mise en œuvre de ces drapeaux. URG concerne l'envoi de paquets avant de remplir les tampons tandis que PSH contrôle le déplacement des données p la pile à la réception.