[PYTHON][RESEAU] Taille limite des paquets TCP ?

[invite300452fc]

Bonjour à tous,

Je bosse actuellement sur un petit projet perso de messagerie instantanée (en python). Mon but est que cette messagerie soit le plus confidentielle possible, puisque je me suis débrouillé pour que la personne qui possède le serveur ne puisse pas accéder aux messages, via des systèmes de chiffrements symétrique/asymétrique. Bref je ne vais pas poster le code ici, il y a deux mille lignes ça ferai un peu trop (mais si quelqu'un y tiens, je peux le faire...)

Mon problème vient du fait que lors de la création d'un compte sur la messagerie, le client doit envoyer de grandes quantités de données au serveur (notamment les clés RSA, publique en clair et privée chiffrée avec le mot de passe de l'utilisateur) allant jusqu'à plus de sept mille caractères. Lorsque je lance le serveur sur la même machine que le client, tout passe impec et les données sont correctement récupérées. Mais lorsque le serveur s’exécute sur une machine distante, cela ne fonctionne plus. J'ai investigué un peu de mon côté et j'ai fini par voir que le serveur n'avait pas l'air de traiter toute la demande, comme si il tronquait le message que le client lui fait parvenir. Pour savoir si cela venait du client ou du serveur, j'ai lancé Wireshark et là j'ai obtenu ça :



Comme vous pouvez le voir, le gros message de 7 000 caractère n'est pas envoyé par le client, il est décomposé en plusieurs paquets contenant tous 1460 bytes de données. Or le serveur lui, n'analyse que le premier paquet qu'il reçoit, ce qu'il veut dire qu'il ne traite que 1/6 des données. Du coup il plante...

Alors voila ma question : Quelqu'un pourrait-il m'expliquer pourquoi les données sont fragmentées, et quelqu'un aurait-il une solution pour moi, que ce soit du côté serveur ou client, cela me serai d'une grande aide...

Voila merci d'avoir pris le temps de me lire et j'espère que quelqu'un sera en mesure de me répondre,

Victor Josso
-----

[pm42]

Je ne comprends pas : tu fais du TCP donc tu envoies tes données sur un socket ? Dans ce cas, tu peux envoyer la taille que tu veux sans te préoccuper de la taille du paquet sous-jacent. Sinon, la vie des serveurs Web et FTP entre autres serait compliquée.
Tu utilises quoi pour lire sur ton serveur ?

[Spazi]

Erreur courante de croire que recv recevra l'intégralité du message.
Vous devez concaténer les buffers jusqu'à ce qu'il n'y ai plus rien à recevoir
Votre reception doit ressembler à quelque chose comme :

While True
	[Appel à .recv]

	[Tester si on a réussi à recevoir qq chose sinon on sort du while]

	[Concaténer le buffer reçu et continuer la boucle]
EndWhile

Je suis sur qu'une recherche sur Google vous donnera le code correspondant en Python, c'est très très courant comme "problème".

Bonne chance pour la suite

[invite6486d7bd]

Alors voila ma question : Quelqu'un pourrait-il m'expliquer pourquoi les données sont fragmentées, et quelqu'un aurait-il une solution pour moi, que ce soit du côté serveur ou client, cela me serai d'une grande aide...

Ca, c'est normal, un message TCP est fragmenté en paquets de taille "raisonnable". Cette taille maximum, c'est ce qu'on appelle la MTU (Maximum Transmission Unit). La raison, il me semble, en est l'optimisation du temps de transfert, cad pouvoir traiter en parallèle des flux de taille variable, lorsque plusieurs clients font passer leurs paquets par un routeur. Le routeur n'attend pas que le "gros" paquet soit traité pour traiter les suivants. Voir ici : https://fr.wikipedia.org/wiki/Maximum_transmission_unit

[A voir en vidéo sur Futura]

[bisou10]

Ben ta taille c'est le MTU non ? Il devrait être de 1492 octets ou 1500 octets (valeurs courantes) mais peut-être que c'est la charge "utile" et que les octets supplémentaires correspondent aux entêtes.

[polo974]

en tcp, tu ouvres une connexion (en très gros, comme un port série en mode raw). c'est à toi de gérer la paquetage en messages (début de message, n° de message, taille, contenu, fin, checksum... et l’acquittement si besoin)

sinon, tu peux (un poil lourd, mais ça marche), utiliser le websocket, c'est une couche (un mille-feuille de couches) par-dessus tcp qui te permets d'envoyer des messages de façon transparente pour toi (pas besoin que tu fasses l'assemblage des paquets, c'est déjà fait).

un truc de ouf en web, webservice, websocket et autres com (pas seulement socket): tornado (asynchrone et coroutines...)
(on peut aussi gérer en asynchrone des pipes, pty et autres ports série, un truc de ouf, je vous dis (twister en plus cool))

[pm42]

en tcp, tu ouvres une connexion (en très gros, comme un port série en mode raw). c'est à toi de gérer la paquetage en messages (début de message, n° de message, taille, contenu, fin, checksum... et l’acquittement si besoin)

Ah bon ? J'avais l'impression que ça, c'était UDP et que ces services étaient justement fournis par la couche TCP.

[inviteb9f49292]

Je bosse actuellement sur un petit projet perso de messagerie instantanée (en python). Mon but est que cette messagerie soit le plus confidentielle possible, puisque je me suis débrouillé pour que la personne qui possède le serveur ne puisse pas accéder aux messages, via des systèmes de chiffrements symétrique/asymétrique.

OK si c'est à but éducatif. Autrement la première règle en crypto c'est de ne _JAMAIS_ utiliser implémenter soi-même les protocoles crypto. Tu es quasiment sûr de laisser des portes dérobées. Heureusement tu trouves des solutions clefs en main: libsodium par exemple.

en tcp, tu ouvres une connexion (en très gros, comme un port série en mode raw). c'est à toi de gérer la paquetage en messages (début de message, n° de message, taille, contenu, fin, checksum... et l’acquittement si besoin)

Heureusement que non !
Il faudrait que je révise mes couches OSI, mais TCP et UDP se trouvent au même niveau (couche transport ?), au-dessus de IP (couche réseau ?).
Effectivement les paquets (ou datagrammes) TCP/IP ou UDP/IP qui sont trop gros pour entrer dans 1 MTU (1500 en général, mais 9000 existe sur du réseau gigabit)sont découpés puis réassemblé par la couche réseau, ceci dit il y a quand-même une taille max au paquet (ou datagramme) qui est de 65535 puisqu'un entier de 16bits est utilisé dans l'entête pour préciser la taille (attention, pendant un moment il vallait mieux utiliser 32767 car certains systèmes utilisaient un signé).
TCP est connecté, donc chacun de ces "sous-paquets" sont acquittés par la couche réseau, et réémis le cas échéant, donc tout doit bien arriver et dans l'ordre à l'autre bout pour reconstituer le "paquet applicatif", ce n'est pas vrai avec UDP, où c'est du "fire and forget", donc si un "sous-paquet" est perdu, c'est tout le "datagramme applicatif" qui est perdu. C'est donc plus léger mais moins "fiable", mais c'est le seul moyen de faire du broadcast ou du multicast. Ceci-dit l’acquittement TCP n'est pas une panacée non plus, puisqu'il ne se fait pas au niveau applicatif.
Enfin, dernière grosse différence à la réception, TCP c'est du "flux" (stream socket), c'est à dire que il faut lire en boucle pour éventuellement reconstituer les paquets applicatifs, alors qu'UDP une lecture pour un datagramme.

[bisou10]

Ah oui les jumbo frames avec 9000 de MTU

[polo974]

Ah bon ? J'avais l'impression que ça, c'était UDP et que ces services étaient justement fournis par la couche TCP.

Non, en udp, c'est paquet par paquet, et donc limité au mtu, mais au moins quand on reçoit un truc, tu es sûr de tout recevoir d'un coup, sauf que les paquets on le "droit" de se perdre...

En tcp, on ouvre une connexion (un flux), donc c'est à l'utilisateur de s'assurer de la mise en forme de ses message qu'il veut y faire transiter.

[pm42]

En tcp, on ouvre une connexion (un flux), donc c'est à l'utilisateur de s'assurer de la mise en forme de ses message qu'il veut y faire transiter.

Ce qui n'est pas ce que tu as dit : "début de message, n° de message, taille, contenu, fin, checksum... et l’acquittement si besoin".
Toutes choses qui ne sont pas forcément nécessaires en TCP pour plein d'usages... Pourquoi envoyer un n° de message vu qu'ils arrivent dans l'ordre envoyé ? Pourquoi faire un checksum vu que TCP le fait déjà ?
Pour par exemple du transfert de fichier, on n'envoie pas de début ni de fin non plus : on ouvre et on ferme le socket.

Mais bon, vu que le primo-posteur n'est pas revenu, tout cela n'est pas grave.

[inviteb9f49292]

Non, en udp, c'est paquet par paquet, et donc limité au mtu, mais au moins quand on reçoit un truc, tu es sûr de tout recevoir d'un coup, sauf que les paquets on le "droit" de se perdre...

!!! NON !!!
Un datagramme UDP peut faire jusque 65536 octet moins entête IP et entête UDP, c'est bien la couche transport qui va découper ton datagramme en sous paquet de la taille du MTU, et les reconstituer côté réception. C'est donc complètement transparent pour le développeur.

Une remarque néanmoins, sur une application avec un gros débit réseau, tu peux avoir intérêt à dimensionner tes datagrammes pour qu'il soient inférieur au MTU, pour "étaler" les interruptions de la carte réseau côté réception, et limiter le risque de dépassement des tampons de réception de la pile IP, qui entrainerai la perte de datagramme.

En tcp, on ouvre une connexion (un flux), donc c'est à l'utilisateur de s'assurer de la mise en forme de ses message qu'il veut y faire transiter.

Je ne comprends pas ce que tu entends par là ? Comme dit précédemment, tes entêtes IP, et TCP ou UDP sont gérées par les couches réseaux de l'OS. Et pour le contenu de tes messages,
la problématique est quasi identique en TCP et en UDP, il faut que le récepteur comprenne ce qu'a envoyé l'émetteur... donc tu as probablement besoin d'un protocole applicatif.
La différence va se faire essentiellement du fait qu'en TCP tu es en mode connecté, tu peux faire l'économie d'un numéro de séquence(*), mais la lecture doit s'utiliser en "flux continu" alors qu'en UDP 1 recv = 1 datagramme (et je répète que les sous-paquets ont été reconstitués par la pile réseau).

(*) ce n'est pas super clair pour moi, mais je crois que l'acquittement du "sous-paquet" se fait par le 1er routeur sur l'émetteur, puis du 2nd routeur vers le 1er etc... Donc si le sous-paquet se perd _APRES_ le 1er routeur, l'acquittement est parti, pourtant l'applicatif en réception ne recevra jamais le paquet (1 sous-paquet de perdu, tout le paquet est perdu). Si on a besoin de faire des acquittements, il faut donc l'ajouter _AU_NIVEAU_APPLICATIF_, il est dangereux de s'appuyer sur le mécanisme TCP.

[polo974]

je parlais de l'envoi de messages sur un tcp (ce qui correspondait à l'appli), avec une gestion des impondérables genre la connexion tombe au milieu d'un échange (ça arrive toujours, et rarement au bon moment), il faut bien le détecter, rouvrir et reprendre au bon endroit (pas toujours possible de tout recommencer (par exemple si on passe des ordres genre "incrémenter compteur").

un message en udp, soit il arrive en entier, soit il n'arrive pas. ne pas dépasser le mtu réduit le risque de perte, c'est en effet par abus que j'en ai limité la taille. c'est assez pratique, mais les inconvénients (en plus de la perte pure) existent et sont nombreux, genre dépassement possible, etc...

un message envoyé sur tcp peut commencer à arriver et la connexion peut être perdue en route même si la taille ne dépasse pas le mtu, on ne maîtrise pas l’alignement du message sur les paquets.