por que o / proc / net / udp está exibindo o tamanho incorreto do rx_queue no servidor CentOS?

Question

Eu tenho um aplicativo de servidor java.

    while(true)
    {
        serverSocket.receive(receivePacket);
        process(receivePacket);
        serverSocket.send(sendPacket);
        try {
            Thread.sleep(10000);  // sleep for 10s
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

Ele recebe e processa 1 pacote UDP / 10 s.

Se eu enviar 10 pacotes UDP para o servidor processa 1 pacote e, em seguida, entra em suspensão por 10s. então eu recebo a resposta do 10º pacote depois dos 100.

Se eu fizer isso é server1 com o lançamento do CentOS 6.4 (Final).

Server 1: cat /proc/net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
 110: 00000000:10AE 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 85635445 2 ffff880836e6d100 0       
 111: 00000000:10AF 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 85635446 2 ffff88083913a1c0 0       
 115: 00000000:15B3 00000000:0000 07 00000000:00004FC8 00:00000000 00000000     0        0 390649369 2 ffff880434ae7440 0      
 117: 02FE6341:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 353480394 2 ffff8808367f9040 0  

Se eu fizer a mesma coisa no servidor 2:

Server 2: cat /proc/net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
   4: FCA9C11F:C36F 8C719AC6:0035 01 00000000:00000000 00:00000000 00000000     0        0 2983494501 2 ffff880169aff4c0 0     
   5: FCA9C11F:D3F0 8C719AC6:0035 01 00000000:00000000 00:00000000 00000000     0        0 2983494485 2 ffff8801b9bbedc0 0     
  16: 7A52BB59:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000    38        0 2438608536 2 ffff8807656764c0 0     
  16: A2EE0D55:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000    38        0 2438608045 2 ffff88077ccdd7c0 0     
  16: A58F466D:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000    38        0 2438607809 2 ffff8801129f6240 0 

Eles são ambos servidores centos e, como podemos ver, o buffer rx_queue do servidor1 está aumentando, pois o aplicativo está processando pacotes mais lentamente do que os dados que chegam ao servidor.

Eu fiz exatamente isso no server2, mas no server2 o rx_queue não está aumentando. o que estou fazendo / entendendo errado?

    

Answer 1

Estou vendo um problema semelhante no Ubuntu 18.04 LTS (kernel 4.15.0-38). Mas isso não acontece na minha caixa Debian 9.5 (kernel 4.9.110-3). Parece ser um bug em novos kernels?

Uma maneira simples de reproduzir o problema é com o netcat. cliente e servidor podem ser locais ou em caixas diferentes.

1. Execute o servidor netcat em um terminal: nc -u -l 1234
2. Execute o cliente netcat em outro terminal: nc -u 127.0.0.1 1234
3. digite uma mensagem curta "a" no cliente e pressione Enter.
4. em um terceiro terminal, verifique os comprimentos de recv-q: netstat -plan | grep 1234

No Ubuntu, o socket de recepção do udp terá um recv-q não vazio (768 bytes para uma mensagem de 2 bytes) mesmo que o netcat tenha lido a mensagem do socket e a tenha impresso. Eu tenho que o recv-q continua crescendo até cerca de 52k, então ele volta a zero.

No Debian, o recv-q é sempre zero, desde que o soquete do udp seja drenado mais rápido que os pacotes recebidos.

Também encontrei este relatório de bug do kernel: cálculo incorreto do UDP rx_queue em / proc / net / udp