Início / unix / Perguntas / 784656
Accepted
SmallClanger
Asked: 2024-10-07 16:37:12 +0800 CST

O buffer de transmissão do soquete UDP unicast é preenchido aguardando ARP

  • 772

Tenho uma pergunta de 'entendimento', mas ela tem um caso do mundo real que eu simplifiquei. Considere esta rede de exemplo (com IPs simplificados): Diagrama de fluxo UDP de amostra Da esquerda para a direita:

  • Três hosts S1-S3 (IPs, executando três programas R1-R3 respectivamente; Um switch com 3 VLANS e uma porta trunk conectada à eth0 de um quarto host S4. Todos são Ubuntu 20.04 LTS, mas isso provavelmente é irrelevante.
  • O S4 está executando o P1 que se vincula a três soquetes UDP, um em cada uma das três interfaces VLAN nas respectivas redes S1,2,3
  • P1 Envia mensagens UDP unicast e multicast para várias portas em cada um desses sockets a taxas de 10-100Hz. Há uma OUTPUTcadeia netfilter controlando esses fluxos.

Cada uma das áreas vermelhas representa algo que pode estar 'inativo'. Em todos esses casos, exceto um, os datagramas UDP são imediatamente descartados:

  • Interface virtual V10está com link inativo; processo R2não está em execução; ou OUTPUTencadeia DROPo fluxo - Em cada caso, os pacotes são descartados silenciosamente por S2 ou um erro é relatado de volta para P1 e o pacote descartado. Todos os outros mcast continuam a fluir.
  • No caso do S3, após a remoção do OUTPUTbloco, o txbuffer do soquete v12rapidamente se enche com pacotes unicast destinados 12.1e isso bloqueia qualquer gravação futura de unicast e multicast.

Neste estado, um straceon P1pode se parecer com isto (aparado):

15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:27 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = -1 EAGAIN (Resource temporarily unavailable)
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = 31674
15:38:30 sendto(9, ... {sa_family=AF_INET, sin_port=htons(2347), sin_addr=inet_addr("12.1")}, 16) = -1 EAGAIN (Resource temporarily unavailable)

E ssmostra o problema:

State    Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process
UNCONN   0       148992   0.0.0.0:51047        0.0.0.0:*          users:(("task",pid=381888,fd=9))
     skmem:(r0,rb212992,t148992,tb131070,f0,w0,o0,bl0,d0)

Então temos 4 * ~30kb de gravações no buffer de socket (padrão 120kb) com o 4º reportando EAGAINquando o buffer está cheio. O buffer está enchendo repetidamente enquanto o SO está esperando por uma ARPresposta S3que nunca virá.

Duas perguntas depois de tudo isso:

  1. UDP não é confiável por natureza. Nossa aplicação fica muito feliz que pacotes sejam descartados de outra forma, então por que seriam txenfileirados dessa forma enquanto o kernel tenta resolver ARP? (Considere o caso em que o S3 pode estar conectado apenas ocasionalmente, mas outros hosts v12ainda podem ser alcançáveis.)
  2. O buffer parece ser esvaziado (e então rapidamente preenchido com novas gravações) a cada 3 segundos. Um dos resultados é que qualquer multicast que entra na mesma txfila sai em pequenas rajadas em vez de na taxa de envio constante. Claro que podemos abrir mais soquetes de envio, mas onde esse valor é definido e esse comportamento é ajustável sysctl?
networking

1 respostas

  1. Best Answer

    UDP não é confiável por natureza. Nosso aplicativo fica muito feliz que os pacotes sejam descartados de outra forma, então por que tx seria enfileirado dessa forma enquanto o kernel está tentando resolver ARP? (Considere o caso em que o S3 pode ser conectado apenas ocasionalmente, mas outros hosts no v12 ainda podem ser alcançáveis.)

    Seu aplicativo pode ser, mas a maioria dos outros aplicativos não fica muito feliz quando os pacotes são descartados. Eles geralmente têm timeouts e retransmissões, mas esses geralmente são muito mais longos do que o necessário para uma consulta ARP ter sucesso.

    Por exemplo, se o kernel fosse descartar um TCP SYN (em vez de enfileirar) porque ele tem que emitir uma consulta ARP para o gateway, levaria 3 segundos para a retransmissão, contra ~0,003 segundos para a resposta ARP. O mesmo vale para consultas DNS baseadas em UDP e a maioria dos outros protocolos. (Sem mencionar aqueles que não têm retransmissão – Syslog sobre UDP não tem, e perderia a maioria das mensagens se elas não fossem frequentes o suficiente para manter a entrada do cache ARP ativa.)

    O buffer parece ser esvaziado (e então rapidamente preenchido com novas gravações) a cada 3 segundos. Um dos resultados é que qualquer multicast que entra na mesma fila tx sai em pequenas rajadas em vez de na taxa de envio constante. Claro que podemos abrir mais soquetes de envio, mas onde esse valor é definido e esse comportamento é ajustável no sysctl?

    net.ipv4.neigh.*.unres_qlen_bytesparece ser o sysctl (assim como o obsoleto .unres_qlen) que controla a quantidade de dados que podem ser enfileirados para um vizinho não resolvido.

    .mcast_solicitOs sysctls × adjacentes .retrans_time_mscontrolam quantas vezes (e em quais intervalos) uma solicitação de multicast ou consulta ARP de transmissão será repetida antes que a entrada vizinha entre no estado 'FALHOU' e todos os seus pacotes na fila sejam descartados.

    (Quando isso acontece, o próximo pacote acionará uma nova série de tentativas de descoberta de vizinhos enquanto novos pacotes são enfileirados novamente, resultando no ciclo de 3 segundos nas configurações padrão.)

    Se você estiver tentando encontrar isso nas fontes do Linux, use grep QUEUE_LEN_BYTESe procure especificamente por __neigh_event_send()em net/core/neighbour.c. Parece que as filas estão anexadas às mesmas entradas vizinhas que você vê em ip [-s] neigh, embora não mostre o tamanho da fila por vizinho.

    • 3

relate perguntas