Comment fixer le plafond Maximum d'un Segment TCP de Taille sur Linux?

Sous Linux, comment pouvez-vous définir la taille de segment maximale autorisée sur une connexion TCP? J'ai besoin de cela pour une application que je n'écris pas (donc je ne peut pas utiliser setsockopt de le faire). J'ai besoin de mettre au-DESSUS de la mtu dans la pile réseau.

J'ai deux ruisseaux partage la même connexion réseau. On envoie des petits paquets périodiquement, ce qui nécessité absolue de latence minimale. L'autre envoie des tonnes de données--je suis à l'aide de SCP pour simuler ce lien.

J'ai de l'installation de contrôle de la circulation (tc) pour avoir le minimum de latence de trafic de haute priorité. Le problème, je suis en cours d'exécution, cependant, c'est que les paquets TCP qui sont à venir vers le bas à partir de la SCP à la fin avec des tailles allant jusqu'à 64 ko. Oui, ceux-ci sont brisés en petits paquets en fonction de mtu, mais ce qui malheureusement se produit APRÈS tc accorde la priorité aux paquets. Donc, mon faible temps de latence des paquets est coincé derrière jusqu'à 64 ko de SCP trafic.

Cet article indique que sur Windows, vous pouvez définir cette valeur.

Est-il quelque chose sur Linux, je peux mettre? J'ai essayé de routage ip et iptables, mais ceux-ci sont appliqués trop bas dans la pile réseau. J'ai besoin de limiter le paquet TCP de taille avant de tc, de sorte qu'il peut donner la priorité à la grande priorité des paquets de façon appropriée.

J'ai du mal à croire que les paquets jusqu'à la fin avec 64 ko dans le ct de la file d'attente, tc ne fonctionne pas sur le niveau TCP, il se soucie de paquets, pas de segments TCP
Je suis d'accord. De ma lecture de segments TCP doit être cassé avant de tc. Cependant, ce n'est pas ce que je vois (à la fois en termes de latence et dans tcpdump). Quand un grand segment TCP sort, il retarde la grande priorité de canal jusqu'à ce que tous (jusqu'à 64 k octets) de la grande segment sont envoyés.

OriginalL'auteur Eric | 2010-10-04

  1. 7

    Êtes-vous à l'aide de tcp segmentation offload à la carte? (Vous pouvez utiliser "ethtool -k $your_network_device" pour voir les paramètres de déchargement.) C'est la seule façon pour autant que je sais que vous verriez 64 ko de paquets tcp avec un appareil MTU de 1500. Non pas que cela répond à la question, mais il pourrait aider à éviter des erreurs de diagnostic.

    OriginalL'auteur CitizenB

  2. 3

    La limite supérieure de la annoncé TCP MSS est le MTU de la première hop route. Si vous voyez des segments de 64 ko, ce qui tend à indiquer que le premier saut route MTU est trop grande, êtes - vous à l'aide de bouclage ou de quelque chose pour les essais?

    Nope. Le premier saut MTU est de 1500. Je vois les gros paquets dans un tcpdump sortie (sur le côté émission). Si je gère aussi un tcpdump du côté de la réception, je vois le gros paquets cassés dans de nombreux 1500 octets des paquets.

    OriginalL'auteur caf

  3. 2

    ip route de commande avec l'option advmss aide à définir MSS valeur.

    ip route add 192.168.1.0/24 dev eth0 advmss 1500

    OriginalL'auteur rashok

  4. 0

    Vous êtes certainement mauvais diagnostic du problème; comme quelqu'un d'autre l'a souligné, tc ne voit pas les paquets TCP, il voit des paquets IP, et qu'ils avaient déjà en morceaux.

    Vous êtes probablement juste éprouver bufferbloat: vous êtes à la surcharge de votre file d'attente sortante totalement séparée de l'appareil (probablement un modem DSL ou modem câble). La seule solution est-à-dire de tc à la limite de la bande passante sortante à moins que le modem de la bande passante, par exemple. à l'aide de TBF.

    OriginalL'auteur apenwarr

  5. 0

    MSS = MTU – 40bytes (TCP/IP standard surcharge de 40 octets [20+20])

    Si le MTU est de 1500 octets, alors le MSS 1460 octets.

    OriginalL'auteur LinconFive