Was bewirkt das Setzen eines Linux-Sockets - hohe Priorität?

Jede Linux-Netzwerkschnittstelle hat eine sogenannte qdisc (Warteschlangendisziplin) angebracht. Und die Antwort auf Ihre Fragen hängt von der verwendeten qdisc ab. Einige Warteschlangendisziplinen wie pfifo und bfifo haben kein Prioritätskonzept. Wenn sie also verwendet werden, ist die Antwort einfach:Es gibt keine Priorisierung

Bei einer priorisierenden qdisc wie pfifo_fast (was normalerweise die Standard-qdisc unter Linux ist) kann sich die Socket-Priorität jedoch auswirken.

Dieses Bild beschreibt, was in einer pfifo_fast qdisc vor sich geht:

Wir sehen, dass Pakete abhängig von ihrer Priorität in Warteschlangen gestellt werden. Wenn die Zeit gekommen ist, dass die Schnittstelle das nächste Paket (frame eigentlich, aber lassen Sie uns darauf nicht eingehen), wird es immer wählen, das Paket mit der höchsten Priorität zu senden. Das bedeutet, wenn mehrere Pakete warten, werden die mit der höchsten Priorität zuerst gesendet . Beachten Sie, dass die Schnittstelle dafür überlastet sein muss - wenn die Schnittstelle nicht überlastet ist und Pakete gesendet werden, sobald sie vom Betriebssystem ankommen, dann gibt es keine Warteschlange und daher keine Priorisierung.

Andere qdiscs haben andere Strukturen und Richtlinien. Zum Beispiel eine SFQ-qdisc:

Lassen Sie uns in diesem Sinne auf Ihre Fragen zurückkommen:

1. Abhängig von der qdisc, ja, Pakete von socket_11 möglicherweise vor Paketen von anderen Sockets gesendet werden. Wenn pfifo_fast verwendet wird, und wenn socket_11 genug Datenverkehr sendet, um die ausgehende Netzwerkschnittstelle zu sättigen, dann werden die Pakete von den anderen Sockets möglicherweise überhaupt nicht gesendet. Dies ist in der Praxis unwahrscheinlich, da es normalerweise schwierig ist, eine Netzwerkschnittstelle zu sättigen, bevor eine andere Ressource ausgelastet wird, es sei denn, es handelt sich um eine drahtlose Schnittstelle.

2. Der Pfad, den Pakete von der Netzwerkschnittstelle der Maschine zum Socket nehmen, ist viel schneller als das Netzwerk selbst. Und wie Sie sich erinnern, muss es Staus geben, damit die Priorisierung Wirkung zeigt. In einem typischen Szenario haben Pakete, die Ihre Netzwerkschnittstelle erreicht haben, bereits den Engpass auf ihrer Reise durch das Netzwerk passiert, sodass eine Überlastung unwahrscheinlich ist.

   Sie können natürlich eine Ingress-QDisc oder andere Mechanismen verwenden, um künstlich einen Engpass zu erzeugen und eingehenden Datenverkehr zu priorisieren. Aber warum sollten Sie? Das macht nur Sinn, wenn Sie einen Traffic Shaper oder ein ähnliches Netzwerkgerät bauen. Da diese qdiscs ein Low-Level-Mechanismus sind, der weit unter den Sockets der höheren Ebene abläuft (sogar vor Bridging oder Routing), bezweifle ich, dass die Priorität des Sockets irgendeine Auswirkung auf in haben könnte.

3. Nicht, dass ich wüsste, aber ich würde es gerne lernen. Dieses Kernel-Modul kommt dem nahe, scheint aber keine Prioritäts-Flags anzeigen zu können, sondern nur reguläre Socket-Optionen.

Antworten auf Ihre Fragen:

1. Standardmäßig ja, Erklärung unten
2. Keine Prioritäten funktionieren nur beim Senden, Erklärung ist auch unten
3. Ich glaube nicht, weil diese Option nicht einmal über die /proc-Schnittstelle gesehen wird

Details zu 1

Einige Worte zu Prioritäten, Netzwerkwarteschlangen und Gerätedisziplinen. All diese Dinge beziehen sich auf die Servicequalität und insbesondere auf Differentiated Services (DiffServ).

Wenn das Paket gesendet wird, wird es in die "Warteschlange" der Schnittstelle gestellt, die vom Netzwerkgerät verarbeitet wird. Standardmäßig ist die Warteschlange keine echte Warteschlange, sondern drei echte Fifos, die stark priorisiert sind. Wenn es ein Paket in fifo0 gibt, warten Pakete in fifo1. Die Socket-Priorität wird diesem Fifo durch folgende Zuordnung zugeordnet:

• 0 (Best Effort) ist fifo1
• 1-3 (Filler, Bulk, ...) ist fifo2
• 4 ist fifo1
• 5 ist fifo2
• 6-7 (Interaktiv, Steuerung) ist fifo0
• 8-15 ist fifo1

Priorität 1 wird also nach Priorität 0 versendet.

Zum Ändern des Standardverhaltens wird das Dienstprogramm "traffic control" (tc) verwendet. Damit können Sie Prioritätswarteschlangen auf der Netzwerkschnittstelle konfigurieren. Dies wird als "Geräte-Warteschlangen-Disziplin" bezeichnet. Sie können definieren, wie Prioritäten von dem jeweiligen Netzwerkgerät bedient werden (Antwort von Malt hat eine gute Erklärung dafür).

Details zu 2

Socket hat Zustände "ready for read"/"not ready for read" und dies ist bool. Wenn irgendwelche Daten an einem nicht bereiten Socket ankommen, ändert es den Zustand von "nicht bereit" zu "bereit", und dies wird durch Funktionen wie Auswählen/Abfragen oder durch Zurückkehren von einem blockierten Empfangsaufruf gesehen. Welcher Thread geweckt wird, hängt nicht von der Socket-Priorität, sondern von der Thread-Priorität ab.

Wenn Sie also Sockets priorisieren möchten, benötigen Sie

• Stellen Sie sie entweder auf priorisierte Threads
• oder nach Code nach Auswahl/Abfrage priorisieren