Quel est l'effet de la définition d'un socket Linux - haute priorité ?

Chaque interface réseau Linux a un soi-disant qdisc (discipline de la file d'attente) qui y est attachée. Et la réponse à vos questions dépend du qdisc utilisé. Certaines disciplines de file d'attente comme pfifo et bfifo, n'ont pas de concept de priorité. Donc, s'ils sont utilisés, la réponse est simple - il n'y aura pas de priorisation

Cependant, avec un gestionnaire de mise en file d'attente prioritaire tel que pfifo_fast (qui est généralement le gestionnaire de mise en file d'attente par défaut sous Linux), la priorité du socket peut avoir un effet.

Cette image décrit ce qui se passe dans un qdisc pfifo_fast :

Nous voyons que les paquets sont placés dans des files d'attente en fonction de leur priorité. Lorsque vient le temps pour l'interface d'envoyer le paquet suivant (frame en fait, mais n'entrons pas dans les détails), il choisira toujours d'envoyer le paquet avec la priorité la plus élevée. Cela signifie que si plusieurs paquets sont en attente, ceux avec la priorité la plus élevée seront envoyés en premier . Notez que cela nécessite que l'interface soit encombrée - si l'interface n'est pas encombrée et que les paquets sont envoyés dès qu'ils arrivent du système d'exploitation, il n'y a pas de file d'attente et donc pas de priorisation.

D'autres qdiscs ont des structures et des politiques différentes. Par exemple un qdisc SFQ :

Dans cet esprit, revenons à vos questions :

1. Selon le qdisc, oui, les paquets de socket_11 peut être envoyé avant les paquets provenant d'autres sockets. Si pfifo_fast est utilisé, et si socket_11 envoie suffisamment de trafic pour saturer l'interface réseau sortante, les paquets provenant des autres sockets peuvent même ne pas être envoyés du tout. Cela est peu probable en pratique car il est généralement difficile de saturer une interface réseau avant de saturer une autre ressource, à moins qu'il ne s'agisse d'une interface sans fil.

2. Le chemin emprunté par les paquets entre l'interface réseau de la machine et le socket est beaucoup plus rapide que le réseau lui-même. Et, comme vous vous en souvenez, pour que la priorisation ait un effet, il doit y avoir une congestion. Dans un scénario typique, les paquets qui ont atteint votre interface réseau ont déjà franchi le goulot d'étranglement de leur voyage à travers le réseau, donc la congestion est peu probable.

   Vous pouvez bien sûr utiliser un qdisc d'entrée ou d'autres mécanismes pour créer artificiellement un goulot d'étranglement et hiérarchiser le trafic entrant. Mais pourquoi le feriez-vous ? Cela n'a de sens que si vous construisez un régulateur de trafic ou un périphérique réseau similaire. De plus, étant donné que ces qdiscs sont un mécanisme de bas niveau qui se produit bien en dessous des sockets de niveau supérieur (même avant le pontage ou le routage), je doute que la priorité du socket puisse avoir un effet sur in.

3. Pas que je sache, mais je serais heureux d'apprendre. Ce module du noyau s'en rapproche, mais il ne semble pas être capable d'afficher les indicateurs de priorité, juste les options de socket habituelles.

Réponses à vos questions :

1. Oui par défaut, l'explication est ci-dessous
2. Aucune priorité ne fonctionne uniquement sur l'envoi, l'explication est également ci-dessous
3. Je ne pense pas car cette option n'est pas visible même via l'interface /proc

Détails sur 1

Quelques mots sur les priorités, les files d'attente réseau et les disciplines des appareils. Tout cela est lié à la qualité de service et particulièrement aux Services Différenciés (DiffServ).

Lorsque le paquet est envoyé, il est placé dans la "file d'attente" de l'interface traitée par le périphérique réseau. Par défaut, la file d'attente n'est pas une vraie file d'attente mais trois vrais fifos qui sont fortement prioritaires. S'il y a un paquet dans fifo0, alors des paquets dans fifo1 attendent. La priorité de socket est mappée à ce fifo en suivant le mappage :

• 0 (meilleur effort) est fifo1
• 1-3 (Filler, Bulk, ...) est fifo2
• 4 est fifo1
• 5 est fifo2
• 6-7 (Interactif, Contrôle) est fifo0
• 8-15 est fifo1

Ainsi la priorité 1 sera distribuée après la priorité 0.

Pour modifier le comportement par défaut, l'utilitaire "contrôle du trafic" (tc) est utilisé. Avec lui, vous pouvez configurer des files d'attente prioritaires sur l'interface réseau. C'est ce qu'on appelle la "discipline de mise en file d'attente des appareils". Vous pouvez définir comment les priorités sont servies par le périphérique réseau particulier (la réponse de Malt a une bonne explication à ce sujet).

Détails sur 2

Socket a des états "prêt pour la lecture"/"pas prêt pour la lecture" et c'est bool. Si des données arrivent sur le socket non prêt, elles changent d'état de "non prêt" à "prêt" et cela est vu par des fonctions comme select/poll ou en revenant d'un appel recv bloqué. Le thread qui sera réveillé ne dépend pas de la priorité du socket mais de la priorité du thread.

Donc, si vous voulez donner la priorité aux sockets dont vous avez besoin

• soit les mettre sur des fils de discussion prioritaires
• ou hiérarchiser par code après sélection/sondage