¿Cuál es el efecto de configurar un socket de Linux:alta prioridad?

Cada interfaz de red de Linux tiene un llamado qdisc (disciplina de hacer fila) adjunta. Y la respuesta a sus preguntas depende del qdisc en uso. Algunas disciplinas de colas como pfifo y bfifo no tienen concepto de prioridad. Entonces, si se usan, la respuesta es simple:no habrá priorización

Sin embargo, con un qdisc de priorización como pfifo_fast (que normalmente es el qdisc predeterminado en Linux), la prioridad del socket puede tener un efecto.

Esta imagen describe lo que sucede en una qdisc pfifo_fast:

Vemos que los paquetes se colocan en colas según su prioridad. Cuando llegue el momento de que la interfaz envíe el siguiente paquete (marco en realidad, pero no entremos en eso), siempre elegirá enviar el paquete con la prioridad más alta. Eso significa que si hay varios paquetes en espera, los de mayor prioridad se enviarán primero . Tenga en cuenta que esto requiere que la interfaz esté congestionada:si la interfaz no está congestionada y los paquetes se envían tan pronto como llegan desde el sistema operativo, entonces no hay colas y, por lo tanto, no hay priorización.

Otras qdisc tienen estructuras y políticas diferentes. Por ejemplo, una qdisc SFQ:

Con eso en mente, volvamos a sus preguntas:

1. Dependiendo de la qdisc, sí, paquetes de socket_11 puede enviarse antes que los paquetes de otros sockets. Si pfifo_fast se utiliza, y si socket_11 envía suficiente tráfico para saturar la interfaz de red de salida, es posible que los paquetes de los otros sockets ni siquiera se envíen. Esto es poco probable en la práctica, ya que normalmente es difícil saturar una interfaz de red antes de saturar algún otro recurso, a menos que sea una interfaz inalámbrica.

2. La ruta que toman los paquetes desde la interfaz de red de la máquina hasta el socket es mucho más rápida que la propia red. Y, como recordará, para que la priorización tenga algún efecto, tiene que haber congestión. En un escenario típico, los paquetes que llegan tan lejos como su interfaz de red ya han superado el cuello de botella de su viaje a través de la red, por lo que es poco probable que haya congestión.

   Por supuesto, puede usar un qdisc de ingreso u otros mecanismos para crear un cuello de botella artificialmente y priorizar el tráfico entrante. Pero ¿por qué lo harías? Eso solo tiene sentido si está creando un modelador de tráfico o un dispositivo de red similar. Además, dado que estos qdiscs son un mecanismo de bajo nivel que ocurre muy por debajo de los sockets de nivel superior (incluso antes de puentear o enrutar), dudo que la prioridad del socket pueda tener algún efecto en in.

3. No que yo sepa, pero me encantaría aprender. Este módulo del kernel se acerca, pero no parece poder mostrar banderas de prioridad, solo opciones de socket normales.

Respuestas a sus preguntas:

1. Sí por defecto, la explicación está debajo
2. Ninguna prioridad funciona solo en el envío, la explicación también se encuentra a continuación
3. No lo creo porque estas opciones no se ven ni siquiera a través de la interfaz /proc

Detalles sobre 1

Algunas palabras sobre prioridades, colas de red y disciplinas de dispositivos. Todo esto está relacionado con la calidad del servicio y en particular con los Servicios Diferenciados (DiffServ).

Cuando se envía el paquete, se coloca en la "cola" de la interfaz que procesa el dispositivo de red. Por defecto, la cola no es una cola real, sino tres fifos reales que tienen una fuerte prioridad. Si hay un paquete en fifo0 que paquetes en fifo1 esperando. La prioridad del socket se asigna a este fifo mediante el siguiente mapeo:

• 0 (mejor esfuerzo) es fifo1
• 1-3 (relleno, a granel, ...) es fifo2
• 4 es fifo1
• 5 es fifo2
• 6-7 (Interactivo, Control) es fifo0
• 8-15 es fifo1

Por lo tanto, la prioridad 1 se enviará después de la prioridad 0.

Para cambiar el comportamiento predeterminado se utiliza la utilidad "control de tráfico" (tc). Con él puedes configurar colas de prioridad en la interfaz de red. Esto se conoce como "disciplina de colas de dispositivos". Puede definir cómo las prioridades son atendidas por el dispositivo de red en particular (la respuesta de Malt tiene una buena explicación de esto).

Detalles sobre 2

Socket tiene estados "listo para leer"/"no listo para leer" y esto es bool. Si llega algún dato al socket no listo, cambia de estado de "no listo" a "listo" y esto se ve mediante funciones como seleccionar/sondear o al regresar de una llamada de recepción bloqueada. El subproceso que se activará no depende de la prioridad del socket sino de la prioridad del subproceso.

Entonces, si desea priorizar los enchufes, necesita

• ponerlos en hilos prioritarios
• o priorizar por código después de seleccionar/sondear