TCP MSS minimal sous Linux

Le TCP MSS sous Linux doit être d'au moins 88 (inclure / net / tcp.h):

/* Minimal accepted MSS. It is (60+60+8) - (20+20). */
#define TCP_MIN_MSS             88U

Ma question est: où ont-ils trouvé "60 + 60 + 8" et pourquoi? J'obtiens que 20 + 20 vient de l'en-tête IP + en-tête TCP.

EDIT: Après avoir regardé de plus près les en-têtes, la formule me ressemble comme ceci:

(MAX_IP_HDR + MAX_TCP_HDR + MIN_IP_FRAG) - (MIN_IP_HDR + MIN_TCP_HDR)

La question se pose toujours: pourquoi ? Pourquoi le noyau Linux utilise-t-il cette formule, interdisant ainsi (un flux forcé) des segments TCP de, disons, 20 octets? Pensez iperf ici.

EDIT2: Voici mon cas d'utilisation. En forçant un MSS bas sur socket / connexion, tous les paquets envoyés par la pile auront une petite taille. Je veux définir un MSS bas lorsque je travaille avec iperf pour les tests de paquets / seconde. Je ne peux pas obtenir de paquets IP inférieurs à 128 octets (trames Ethernet de 142 octets) sur le fil en raison de cette limite inférieure pour le MSS! Je voudrais me rapprocher d'une taille de trame Ethernet de 64 octets selon RFC 2544. Théoriquement, cela devrait être possible: 18 + 20 + 20 <64.

— Mircea Gherzan
source

Comment cela interdit-il les segments TCP de 20 octets?

— David Schwartz

MSS signifie Maximum Segment Size, c'est la limite supérieure (pas inférieure) pour la taille de segment dans une connexion particulière. TCP_MIN_MSS spécifie la limite inférieure de cette limite. Ainsi, il n'interdit en aucune façon les segments de moins de 88 octets, il indique simplement que MSS pour toute connexion doit être> = 88 octets.

— gelraen

Bien sûr! Désolé de ne pas avoir été assez clair. Veuillez consulter la dernière modification.

— Mircea Gherzan

Pourquoi avez-vous laissé la prime expirer? La réponse de David clarifie les choses à ma satisfaction au moins. La différence entre sa réponse et la mienne est que nous parlons de minima différents. Pour ce que ça vaut, il y a un troisième minimum, soit 41 ou 20 + 20 + 1 octet de données TCP. La taille minimale des paquets dépend donc de la raison pour laquelle vous posez la question. Je m'attends à ce que 68 soit la bonne réponse dans les cas où le noyau l'utilise TCP_MIN_MSS.

— Warren Young

Je ne suis toujours pas satisfait de la réponse. Je ne vois toujours pas la raison pour laquelle le noyau ne me laisse pas imposer un petit MSS arbitraire à une application. J'adorerais avoir (un flux constant de paquets TCP chargés) IP de 41 octets, mais je ne peux pas, à cause du TCP_MIN_MSS. Pourquoi ne peut-il pas être 1? Quel RFC casserait-il? Quel problème théorique ou pratique cela causerait-il? Êtes-vous sûr que c'est "en dehors des spécifications"? "Différents minima"? Il n'y a qu'un minimum d'intérêt ici: le plus petit MSS autorisé par le noyau.

— Mircea Gherzan

Réponses:

Une implémentation est requise pour prendre en charge les en-têtes TCP et IP de taille maximale, qui sont chacun de 60 octets.

Une implémentation doit prendre en charge des datagrammes de 576 octets, ce qui, même avec des en-têtes maximum, signifie plus de 8 octets de données dans le datagramme. Pour envoyer des datagrammes avec plus de 8 octets de données, la fragmentation IP doit mettre au moins 8 octets de données dans au moins un des paquets qui représentent les fragments du datagramme. Ainsi, une implémentation doit prendre en charge au moins 8 octets de données dans un paquet.

Ensemble, une implémentation doit prendre en charge les paquets 60 + 60 + 8 octets.

Lorsque nous envoyons des paquets qui font partie d'un flux TCP, ils ont un en-tête IP de 20 octets (plus d'options) et un en-tête TCP de 20 octets (plus d'options). Cela laisse un minimum de (60 + 60 + 8) - (20 + 20) octets restants pour les données et les options. Par conséquent, c'est le maximum que nous pouvons supposer en toute sécurité TCP MSS d'une implémentation.

— David Schwartz
source

Le MSS n'inclut cependant pas l'en-tête (c'est juste la charge utile), et le 60montre deux fois

— Michael Mrozek

Une implémentation doit pouvoir prendre en charge un paquet avec un en-tête de taille maximale, mais nous n'envoyons pas d'en-tête de taille maximale. La différence entre le maximum et ce que nous envoyons réellement est donc disponible pour les données et devrait être ajoutée au MSS.

— David Schwartz

OK, vous avez donc expliqué les 8 octets. Je ne sais pas ce que vous entendez par en-tête "TCP / IP". Je connais un en-tête IP et un en-tête TCP. Et, comme Michael l'a souligné, 60 se présentent deux fois. Et la RFC ne traite que du «MSS efficace» et non d'un minimum.

— Mircea Gherzan

60 s'affiche deux fois, une fois pour l'en-tête IP et une fois pour l'en-tête TCP.

— David Schwartz

68 ne concerne que la fragmentation. "60 + 60 + 8" pourrait se fragmenter, alors pourquoi se soucier de la fragmentation alors? Même "68 + 20" pourrait être fragmenté. Et pourquoi "doit" l'autre côté "accepter" "60 + 60 + 8"? "Accepter" comme dans "sans fragmentation"? Conclusion: pourquoi ne suis-je pas autorisé à envoyer "20 + 20" + 10 octets de données?

— Mircea Gherzan

Je ne sais pas d'où vient ce chiffre, mais je peux vous dire qu'il est en dehors des spécifications. La MTU minimale prise en charge pour les réseaux IP est de 576 octets, soit 512 octets de données plus jusqu'à 64 octets pour les en-têtes IP + TCP et les options TCP. Cette valeur a été choisie pour donner des frais généraux décemment bas dans le cas typique.

Ma lecture de bits de code du noyau suggère que la valeur que vous affichez n'est pas arbitraire. Il y avait une ancienne pratique pour utiliser simplement la constante brute 64 à la place de TCP_MIN_MSS. Par conséquent, je suppose qu'il y a un étrange réseau IP sur Foo que les développeurs du noyau ont rencontré qui leur a fait décider qu'ils pourraient augmenter la valeur de ce que vous voyez comment.

Ce que ce type de réseau non standard est, cependant, je ne peux pas dire.

— Warren Young
source

576 est le MTU pour les datagrammes . Dans ce cas, ce sont les limites de paquets qui importent, pas les limites de datagramme car les paquets TCP définissent le bit DF.

— David Schwartz

MTU minimum défini pour les datagrammes IP et les paquets TCP sont également des datagrammes IP.

— gelraen

Oui, mais cette limitation TCP concerne les paquets, pas les datagrammes, car les datagrammes TCP ne se fragmentent jamais (normalement). Le seul sens dans lequel la règle de datagramme de 576 octets est importante est qu'elle signifie que l'implémentation doit être capable de prendre en charge au moins 8 octets de données dans un paquet (d'où le 8 dans la formule). Sinon, il serait impossible de fragmenter un datagramme de 576 octets.

— David Schwartz