linux - servidor - sockets pdf

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

Question

Desde la página de manual de socket de Linux:

SO_PRIORITY
Establezca la prioridad definida por el protocolo para todos los paquetes que se enviarán en este socket. Linux usa este valor para ordenar las colas de la red: los paquetes con una prioridad más alta se pueden procesar primero según la disciplina de colas del dispositivo seleccionado.

Y esto se establece usando:

int optval=7 // valid values are in the range [1,7]
// 1- low priority, 7 - high priority
setsockopt(socket, SOL_SOCKET, SO_PRIORITY, &optval, optlen)

Y digamos, el proceso tiene:
a. 10 zócalos de baja prioridad (prioridad = 4) de socket_1 - socket_10 ,
segundo. 1 toma de alta prioridad (prioridad = 7) - socket_11

Qué sucederá en los siguientes escenarios:

1. send() : el proceso envía múltiples mensajes en socket_1 - socket_10 y en socket_11 , los mensajes de IMO en el socket_11 tendrán preferencia sobre los mensajes que se envían a través de socket_1 - socket_10 .

2. recv() : si se reciben mensajes mutilple en todos los sockets descritos anteriormente, ¿ socket_11 tiene mayor prioridad al leer los mensajes en socket_1 - socket_10 ?

3. ¿Hay alguna forma de medir la prioridad del socket desde la línea de comandos usando herramientas como lsof , netstat , etc.?

Answer 1

Respuestas a tus preguntas:

1. Sí, por defecto, la explicación está debajo
2. Ninguna prioridad funciona solo en el envío, la explicación también está debajo
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 dispositivo. Todo esto está relacionado con la calidad del servicio y particularmente con los Servicios diferenciados (DiffServ).

Cuando se envía el paquete, se pone en interfaz con la "cola" procesada por 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 de socket se asigna a esta fifo siguiendo la asignación:

• 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

Entonces, 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 puede configurar colas de prioridad en la interfaz de red. Esto se denomina "disciplina de cola de dispositivo". Puede definir cómo el dispositivo de red particular sirve las prioridades (la respuesta de Malt tiene una buena explicación de esto).

Detalles sobre 2

Socket tiene estados "listos para leer" / "no listos para leer" y esto es bool. Si se llega a algún dato al socket no listo, cambia el estado de "no listo" a "listo" y esto es visto por funciones como select / poll o al regresar de la llamada a la red bloqueada. El hilo que se despertará no depende de la prioridad del socket, sino de la prioridad del hilo.

Entonces, si quieres priorizar tomas que necesitas

• ya sea ponerlos en hilos priorizados
• o priorizar por código después de seleccionar / encuesta

Answer 2

Cada interfaz de red Linux tiene un qdisc (disciplina de colas) adjunto. Y la respuesta a sus preguntas depende del qdisc configurado en la interfaz de red relevante. Algunos, como pfifo y bfifo , no tienen ningún concepto de prioridad, por lo que si se utilizan, la respuesta es simple: nada sucederá (bueno, nada interesante al menos).

Sin embargo, si se usa con un qdisc apropiado, como pfifo_fast, que es el qdisc predeterminado en cada máquina Linux que vi, la prioridad podría tener un efecto.

Esta imagen describe lo que está sucediendo en un qdisc pfifo_fast:

Vemos que los paquetes se colocan en colas según su prioridad. Cuando llega el momento de que la interfaz envíe el siguiente paquete (en realidad, el marco , pero no nos metamos en eso), siempre elegiremos enviar el paquete con la mayor prioridad entre los que esperan en las colas. Otros qdiscs tienen diferentes estructuras y políticas. Por ejemplo, un SFQ qdisc:

Con eso en mente, volvamos a sus preguntas:

1. Dependiendo de la qdisc, sí, los paquetes de socket_11 pueden enviarse antes que los paquetes de otros sockets. Si se usa pfifo_fast , y si socket_11 envía grandes cantidades de tráfico que saturan la interfaz de red saliente, los paquetes de los otros sockets incluso podrían no enviarse en absoluto. Sin embargo, prácticamente esto es poco probable. Normalmente es difícil saturar una interfaz de red antes de saturar algún otro recurso (como la velocidad de su conexión a Internet o su propia CPU) a menos que, por supuesto, estemos hablando de un enlace inalámbrico. Si la interfaz de red no está cerca de su punto de saturación y siempre está disponible para enviar paquetes, las colas estarán (casi) siempre vacías, por lo que no se establecerá ninguna priorización. ¡Debe haber contienda para que la priorización se active !

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 red misma. Y, como recuerda, para que la priorización tenga algún efecto, tiene que haber una disputa. En un escenario típico, los paquetes que llegaron hasta su interfaz de red ya pasaron el cuello de botella de su viaje a través de la red. Por supuesto, puede utilizar una qdisc de ingreso u otros mecanismos para crear artificialmente un cuello de botella y priorizar el tráfico entrante, pero ¿por qué lo haría? Eso solo tiene sentido si está creando un modelador de tráfico o un dispositivo de red similar. Además, dado que esta puesta en cola es un mecanismo de bajo nivel que ocurre muy por debajo de los sockets de nivel superior (incluso antes de puenteo o enrutamiento), dudo que la prioridad del zócalo pueda tener algún efecto sobre.

3. No es que yo sepa, pero estaría feliz de aprender. Este módulo kernel se acerca, pero parece que no puede mostrar indicadores de prioridad, solo opciones de socket regulares.