Por que minha taxa de transferência TCP é muito maior que a taxa de transferência UDP?


15

Não fiz nada de incomum nas configurações de meu hardware ou kernel (todas as configurações padrão, nova instalação do SO, pilha TCP / IP do kernel 3.11 do Linux) e estou com uma média de 3,83 milhões de mensagens por segundo através do TCP, enquanto estou com apenas 0,75 milhões de mensagens por segundo através do UDP. Isso parece desafiar completamente o que eu espero dos dois protocolos.

Qual é a causa mais provável da diferença drástica e como posso diagnosticá-la no Ubuntu 13.10?

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

Para este teste, tenho dois servidores de teste que são idênticos e conectados diretamente através de um cabo cruzado 10G. As NICs usadas neste caso são as Intel X520 com configurações prontas para uso e conectadas a um slot PCIe 3.0 x8 na placa-mãe, que se comunica com a CPU por meio de um controlador NUMA.


Como você fez os benchmarks? Contra o que você enviou esses pacotes?
Braiam

Usei netperfpara os testes de benchmark, UDP_STREAM e TCP_STREAM, corrigidos para a mesma CPU e tamanhos de mensagem de 64 bytes.
22413 elleciel

1
Isso não responde à pergunta de @ Braiam. A topologia de rede é e um método de teste detalhado é importante aqui.
Pavel Šimerda 30/03

1
@ PavelŠimerda Desculpe, eu pensei que ele estava apenas pedindo a metodologia de teste. Em relação à topologia de rede, os dois servidores de teste são idênticos e conectados diretamente através de um cabo cruzado 10G. As NICs usadas neste caso são as Intel X520 com configurações prontas para uso e conectadas a um slot PCIe 3.0 x8 na placa-mãe, que se comunica com a CPU por meio de um controlador NUMA. Isso responde sua pergunta?
31414 elleciel

1
Sim, @elleciel, definitivamente responde à minha pergunta. Embora neste caso eu não tenha a experiência necessária para fornecer a resposta para máquinas conectadas diretamente. Vejo que você alterou a pergunta em si, o que é ótimo. Vai levantar a questão como agora também estou interessado.
Pavel Šimerda 30/03

Respostas:


29

Além de não obter informações detalhadas sobre a configuração do teste, o principal problema parece ser o fato de você usar um tamanho de mensagem de 64 bytes. Isso está muito longe do MTU usual de 1500 bytes e torna o UDP altamente ineficiente: enquanto o TCP mescla vários envios em um único pacote na conexão (exceto se TCP_NODELAY estiver configurado) para fazer uso eficiente do link, cada mensagem UDP resultará em um pacote separado. Em números: cerca de 23 mensagens de tamanho 64 bytes serão combinadas em um único pacote TCP de tamanho MTU, enquanto serão necessários 23 pacotes únicos para UDP para a mesma quantidade de dados. Cada um desses pacotes significa sobrecarga com o envio do host, a transmissão no fio e a recepção pelo ponto. E, como visto no seu caso, cerca de 80% dos pacotes UDP se perdem porque seu hardware não é rápido o suficiente para transmitir e receber todos esses pacotes.

Então, o que você pode aprender com esse benchmark é:

  • O UDP não é confiável (80% de perda de pacotes)
  • O UDP é ineficiente se usado com tamanhos de pacote muito abaixo da MTU
  • O TCP é altamente otimizado para fazer o melhor uso do link

Quanto à sua expectativa, que o UDP deveria ser melhor: você já se perguntou por que todas as principais transferências de arquivos (ftp, http, ...) são feitas com protocolos baseados em TCP? A referência mostra o motivo.

Então, por que as pessoas usam o UDP?

  • Com dados em tempo real (por exemplo, voz sobre IP), você não se importa com mensagens antigas, portanto, não deseja que o remetente combine mensagens em pacotes maiores para fazer uso efetivo do link. E você prefere aceitar que um pacote seja perdido do que chegar tarde demais.
  • Com links de alta latência (como em satélites), o comportamento padrão do TCP não é ideal para fazer uso efetivo do link. Portanto, algumas pessoas mudam para o UDP nesse caso e reimplementam a camada de confiabilidade do TCP e a otimizam para links de alta latência, enquanto outras ajustam a pilha TCP existente para fazer melhor uso do link.
  • "jogar fora" os dados: às vezes é mais importante enviar os dados para longe e não se importa com a perda de pacotes, como nas mensagens de log (syslog)
  • Interações curtas: com o TCP, você precisa estabelecer uma conexão e manter um estado, que custa tempo e recursos no cliente e no servidor. Para interações curtas (como solicitação e resposta breves), isso pode ser muito caro. Por esse motivo, o DNS geralmente é feito com o UDP, mas criou novas tentativas sobre o UDP.

2
Você também deve dar uma olhada na sua perda de pacotes de 80% com o UDP. Parece que seu hardware não é rápido o suficiente para processar os pacotes na mesma velocidade que eles são enviados. Enquanto o TCP se adapta a esse tipo de perda de pacotes com lentidão, o UDP envia apenas na mesma velocidade e continua a perder pacotes. Mas, no final, não é relevante a rapidez com que você pode enviar, mas o que você recebe.
Steffen Ullrich 30/03

1
Outra coisa que pode ser um fator é a aceleração / descarregamento do TCP na placa de rede (se houver suporte).
cpugeniusmv

1
O envio de pacotes pode ser mais eficiente do que o recebimento, especialmente se o último for acionado por interrupção.
Steffen Ullrich 30/03

1
pessoas também usam UDP para um dispositivo embutido para transmitir os dados que está coletando ao longo de um fio e não se preocupar com o estabelecimento da conexão
aberração catraca

3
É provável que você esteja com E / S vinculado pelo barramento PCI Express. As placas de rede terão a descarga do segmento TCP ativada, provavelmente. Isso significa que as transferências TCP serão enviadas para o cartão como um grande bloco; depois, o cartão as divide e as divide em pacotes e as coloca no fio. Não há equivalente para UDP, portanto, o resultado é uma transação PCIe (e todas as despesas gerais associadas) para cada pacote.
alex.forencich
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.