Auteur Sujet: flag TCP PUSH (Lu 17367 fois)

vivien · « **le:** 14 avril 2016 à 20:06:39 »

flag TCP PSH (push)

TCP possède de nombreux indicateurs (flags) et notamment un qui s’appelle PSH ou Push qui permet de dire qu'il ne faut pas buffuriser les données et les envoyer tout de suite.

L'en-tête de TCP :

Je me pose des questions car je vois que certains paquets (par exemple de Lafibre.info) sont émis avec le flag PUSH, mais font plus de 1514 octets : ce sont donc deux paquets sur le réseau qui ont été assemblés par la carte réseau avant d'être envoyés au système d'exploitation, ce n'est pas ce que PUSH est censé éviter ?

La grande majorités de paquets envoyés par le forum n'ont pas le flag PUSH => quelle est la règle ?

Inversement, certains paquets envoyés par le navigateur (les requêtes GET par exemple) ont le flag PUSH.
D'autres paquets envoyés par le navigateur, comme un POST pour une pièce jointe que 'on rajoute dans le message, n'ont pas le flag PSUH.

Voici, des exemples, extraits d'une même connexion TCP sur le forum LaFibre.info (client: Firefox sous Linux)
- Paquet Serveur => Client avec push activé
- Paquet Serveur => Client avec push désactivé
- Paquet Client => Serveur avec push activé
- Paquet Client => Serveur avec push désactivé

vivien · « **Réponse #1 le:** 14 avril 2016 à 20:11:25 »

Je cherche à faire des tests de débit avec le flag PUSH activé, pour voir si cela change quelque chose, quand je mélange des flux avec flag PUSH activé et des flux avec flag PSUH désactivé. (il y aurait une priorisation sur la Freebox des paquets PUSH, en cas de congestion upload sur le lien DSL à 1 Mb/s ?)

Une émission de paquets avec curl (curl -o /dev/null -F "filecontent=@1Mo.dat" http://1.testdebit.info ) ne positionne pas le flag PUSH. Comment faire pour que curl envoie les paquets avec PUSH ?

kgersen · « **Réponse #2 le:** 14 avril 2016 à 20:12:48 »

De ce que j'avais compris de PUSH c'est en reception uniquement: ca signale au récepteur de ne pas attendre de remplir le buffer pour signaler a la couche au dessus (généralement l’application).

jack · « **Réponse #3 le:** 14 avril 2016 à 21:14:10 »

Pour moi, le push est aussi en émission : il parait que c'est utilisé par telnet, par exemple

Citation de: vivien

Je me pose des questions car je vois que certains paquets (par exemple de Lafibre.info) sont émis avec le flag PUSH, mais font plu de 1514 octets : ce sont donc deux paquets sur le réseau qui ont été assemblés par la carte réseau avant d'être envoyé au système d'exploitation, ce n'est pas ce que PUSH est censé éviter ?

Non
Le flag push interdit la bufferisation, c'est à dire l'attente de données supplèmentaires

kgersen · « **Réponse #4 le:** 14 avril 2016 à 21:42:12 »

En pratique je crois que les stack tcp/ip ne permettent pas de manipuler directement ce flag.
Toutefois avec TCP_NODELAY ca devrait fonctionner. C'est qu'on utilise pour envoyer des messages courts qui doivent être reçus a l'autre bout sans attendre la bufferisation. C'est sans doute mis en oeuvre avec ce flag.

Apres il me semble que la RFC sur TCP n'impose rien a ce niveau, le but de TCP c'est de fonctionner au mieux et pas a l'application d'imposer des trucs.

corrector · « **Réponse #5 le:** 14 avril 2016 à 23:17:58 »

Citation de: kgersen le 14 avril 2016 à 20:12:48

De ce que j'avais compris de PUSH c'est en reception uniquement: ca signale au récepteur de ne pas attendre de remplir le buffer pour signaler a la couche au dessus (généralement l’application).

Dans quel cas le récepteur attends pour signaler à la couche au dessus?

vivien · « **Réponse #6 le:** 14 avril 2016 à 23:27:20 »

Les cartes réseau avec TSO/GSO vont diminuer la charge CPU en agrégeant différents paquets de 1500 octets d'une connexion TCP et un seul paquet plus important.

C'est le cas présent ici avec un paquet vu par l'OS comme un seul paquet de 1644 octets alors que ce sont deux paquets distincts qui ont circulé sur le réseau : (et ici le flag TCP PUSH est "set")

kgersen · « **Réponse #7 le:** 15 avril 2016 à 00:13:10 »

L'explication de PUSH et quelques éclaircissements sont précisés dans ces 2 documents:

RFC 793 : https://tools.ietf.org/html/rfc793#section-2.8
RFC 1122: https://tools.ietf.org/html/rfc1122#page-82

Maintenant ca c'est la recommendation et la spec.
En pratique (programmation) on utilise des sockets 'universels' donc pas spécifiques a IP et encore moins a TCP.
Le 'send' (send(2)) des sockets et le SEND de la spec de TCP ne sont donc pas 100% equivalents.
send(2) n'a pas d'options ou de flags PUSH.

Sur Linux (et POSIX en fait) et Windows, la seule option qui s'en rapproche est TCP_NODELAY qu'on utilise avec setsockopt(2) et pas avec send(2).

corrector · « **Réponse #8 le:** 15 avril 2016 à 02:23:49 »

ssize_t send(int sockfd, const void *buf, size_t len, int flags);

Citer

MSG_MORE (Since Linux 2.4.4)
The caller has more data to send. This flag is used with TCP sockets to obtain the same effect as the TCP_CORK socket option (see tcp(7)), with the difference that this flag can be set on a per-call basis.

corrector · « **Réponse #9 le:** 15 avril 2016 à 02:58:35 »

Citation de: kgersen le 14 avril 2016 à 20:12:48

De ce que j'avais compris de PUSH c'est en reception uniquement: ca signale au récepteur de ne pas attendre de remplir le buffer pour signaler a la couche au dessus (généralement l’application).

Sur unixoïde tu n'as aucun appel système opérant sur socket qui demande :

"remplis ce buffer et retourne une fois qu'il est plein ou bien EOF est rencontré ou bien si une erreur se produit".

Tu n'as que read, qui renvoie le plus d'octets jusqu'à la taille du tampon, et renvoie au moins un octet, ou bien un signal EOF, ou bien une erreur de lecture, ou bien une indication de blocage si la socket est non-bloquante.

Electrocut · « **Réponse #10 le:** 15 avril 2016 à 10:28:42 »

Citation de: corrector le 14 avril 2016 à 23:37:48

Si la carte réseau réassemble les paquets, pourquoi Wireshark est capable de voir les paquets non réassemblés? Ce que tu postules n'a aucun sens. La carte réseau n'a rien réassemblé du tout.

La capture montre un unique segment TCP de 1578 octets (Entête Ethernet 14 + Entête IP 20 + Entête TCP 32 + Données 1578 = 1644 octets capturés).
Le taille du paquet IP capturé par Wireshark est donc de 1630 octets, ce qui est supérieur au MTU (1500).

On ne voit pas les segments TCP d'origine qui ont abouti à ce segment de 1578 octets.

-> La carte réseau a effectivement dû assembler plusieurs segments TCP.

BadMax · « **Réponse #11 le:** 15 avril 2016 à 22:17:16 »