it-swarm.dev

Quando é apropriado usar o UDP em vez do TCP?

Desde TCP garante a entrega de pacotes e, portanto, pode ser considerado "confiável", enquanto o UDP não garante nada e os pacotes podem ser perdidos. Qual seria a vantagem de transmitir dados usando o UDP em um aplicativo em vez de um fluxo TCP? Em que tipo de situações o UDP seria a melhor escolha e por quê?

Estou assumindo que o UDP é mais rápido, já que não tem a sobrecarga de criar e manter um fluxo, mas isso não seria irrelevante se alguns dados nunca chegassem ao seu destino?

280
Jeff L

Esta é uma das minhas perguntas favoritas. O UDP é tão mal entendido.

Em situações em que você realmente deseja obter uma resposta simples para outro servidor rapidamente, o UDP funciona melhor. Em geral, você deseja que a resposta esteja em um pacote de resposta e está preparado para implementar seu próprio protocolo para confiabilidade ou para reenviar. O DNS é a descrição perfeita desse caso de uso. Os custos das configurações de conexão são altos demais (no entanto, o DNS também suporta um modo TCP).

Outro caso é quando você está entregando dados que podem ser perdidos porque os dados mais novos que chegam substituirão os dados/estados anteriores. Dados meteorológicos, streaming de vídeo, um serviço de cotação de ações (não usado para negociação real) ou dados de jogos vêm à mente.

Outro caso é quando você está gerenciando uma enorme quantidade de estado e deseja evitar o uso de TCP porque o SO não pode lidar com tantas sessões. Este é um caso raro hoje. Na verdade, agora há pilhas de usuário TCP que podem ser usadas para que o gravador de aplicativos possa ter um controle mais preciso sobre os recursos necessários para esse estado TCP. Antes de 2003, o UDP era realmente o único jogo da cidade.

Um outro caso é para o tráfego multicast. O UDP pode ser multicast para vários hosts, enquanto TCP não pode fazer isso.

326
drudru

Se um pacote TCP for perdido, será reenviado. Isso não é útil para aplicativos que dependem de dados sendo manipulados em uma ordem específica em tempo real.

Exemplos incluem streaming de vídeo e especialmente VoIP (por exemplo, Skype ). Nesses casos, no entanto, um pacote descartado não é tão importante: nossos sentidos não são perfeitos, então podemos nem notar. É por isso que esses tipos de aplicativos usam UDP em vez de TCP.

61
Stephan202

A "falta de confiabilidade" do UDP é um formalismo. A transmissão não é absolutamente garantida. Na prática, eles quase sempre passam. Eles simplesmente não são reconhecidos e repetidos após um tempo limite.

A sobrecarga na negociação de um socket TCP e handshaking dos pacotes TCP é enorme. Realmente enorme. Não há sobrecarga UDP significativa.

O mais importante é que você pode facilmente complementar o UDP com alguma mão confiável de entrega que tenha menos sobrecarga do que o TCP. Leia isto: http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

O UDP é útil para transmitir informações em um tipo de aplicativo de publicação/assinatura. IIRC, TIBCO faz uso pesado de UDP para notificação de mudança de estado.

Qualquer outro tipo de atividade "evento significativo" ou "registro" unidirecional pode ser tratado com facilidade com pacotes UDP. Você deseja enviar uma notificação sem construir um soquete inteiro. Você não espera nenhuma resposta dos vários ouvintes.

As mensagens "heartbeat" ou "I'm alive" do sistema também são uma boa escolha. A falta de uma não é uma crise. Faltando meia dúzia (em linha) é.

56
S.Lott

Eu trabalho em um produto que suporta tanto a comunicação UDP (IP) e TCP/IP entre cliente e servidor. Começou com o IPX há mais de 15 anos com suporte IP adicionado há 13 anos. Adicionamos suporte ao TCP/IP há 3 ou 4 anos. Sugestão inesperada: A relação de código UDP para TCP é provavelmente de 80/20. O produto é um servidor de banco de dados, portanto, a confiabilidade é crítica. Temos que lidar com todas as questões impostas pelo UDP (perda de pacotes, duplicação de pacotes, ordem de pacotes, etc.) já mencionadas em outras respostas. Raramente existem problemas, mas às vezes ocorrem e devem ser tratados. O benefício de suportar o UDP é que podemos personalizá-lo um pouco para nosso próprio uso e ajustar um pouco mais o desempenho dele.

Cada rede será diferente, mas o protocolo de comunicação UDP é geralmente um pouco mais rápido para nós. O leitor cético irá questionar corretamente se implementamos tudo corretamente. Além disso, o que você pode esperar de um cara com um representante de 2 dígitos? No entanto, acabei de fazer um teste por curiosidade. O teste leu 1 milhão de registros (selecione * de algum tipo). Eu configurei o número de registros para retornar com cada solicitação de cliente individual para 1, 10 e, em seguida, 100 (três execuções de teste com cada protocolo). O servidor tinha apenas dois lúpulos em uma LAN de 100 Mbits. Os números pareciam concordar com o que os outros descobriram no passado (o UDP é cerca de 5% mais rápido na maioria das situações). O total de tempos em milissegundos foi o seguinte para este teste específico:

  1. 1 registro
    • IP: 390.760 ms
    • TCP: 416,903 ms
  2. 10 registros
    • IP: 91,707 ms
    • TCP: 95,662 ms
  3. 100 registros
    • IP: 29,664 ms
    • TCP: 30,968 ms

O total de dados transmitidos foi praticamente o mesmo para IP e TCP. Temos uma sobrecarga extra com as comunicações UDP porque temos algumas das mesmas coisas que você obtém para "liberar" com TCP/IP (somas de verificação, números de sequência, etc.). Por exemplo, o Wireshark mostrou que uma solicitação para o próximo conjunto de registros era de 80 bytes com UDP e 84 bytes com TCP.

29
Mark Wilkins

O UDP é um protocolo sem conexão e usado em aplicativos como SNMP (Simple Network Management Protocol), DNS (Domain Name System) onde os pacotes de dados chegam fora de ordem, não confiáveis ​​e não preocupam e enviam imediatamente os pacotes de dados.

Como o UDP não envolve o estabelecimento de conexões, portanto, aplicações como o DNS, onde os atrasos de estabelecimento de conexão precisam ser evitados, o UDP é preferível ao TCP.

Usado no SNMP, uma vez que o gerenciamento da rede deve ser feito frequentemente quando a rede está em tensão, ou seja, quando é difícil obter uma transferência de dados confiável e controlada por congestionamento.

felicidades

15
Arnkrishn

Já existem muitas boas respostas aqui, mas eu gostaria de adicionar um muito fator importante que, assim como um resumo. O UDP pode atingir uma taxa de transferência muito maior com o ajuste correto porque ele não emprega controle de congestionamento . O Controle de Congestionamento em TCP é muito, muito importante. Ele controla a taxa e a taxa de transferência da conexão para minimizar o congestionamento da rede tentando estimar a capacidade atual da conexão. Mesmo quando os pacotes são enviados através de links muito confiáveis, como na rede principal, os roteadores têm buffers de tamanho limitado. Esses buffers preenchem a capacidade e os pacotes são descartados, e TCP percebe essa queda por meio da falta de uma confirmação recebida e reduz a velocidade da conexão para a estimativa da capacidade. TCP também emprega algo chamado início lento , mas a taxa de transferência (na verdade, a janela de congestionamento ) é aumentado lentamente até que os pacotes sejam descartados e, em seguida, abaixados e aumentados lentamente até que os pacotes sejam descartados, etc. Isso faz com que a taxa de transferência TCP flutue. Você pode ver isso claramente quando você faz o download de um arquivo grande.

Como o UDP não está usando o controle de congestionamento, ele pode ser mais rápido e ter menor atraso porque não busca maximizar os buffers até o ponto de interrupção, ou seja, os pacotes UDP gastam menos tempo em buffers e chegam mais rápido com menor atraso. Como o UDP não emprega controle de congestionamento, mas TCP, ele pode eliminar a capacidade de TCP que resulta em fluxos UDP.

O UDP ainda é vulnerável a congestionamentos e quedas de pacotes, portanto, seu aplicativo precisa estar preparado para lidar com essas perdas menores de alguma forma, provavelmente usando códigos de retransmissão ou correção de erros.

O resultado é que o UDP pode:

  • Obtenha uma taxa de transferência maior que TCP, desde que a taxa de queda da rede esteja dentro dos limites que o aplicativo pode manipular.
  • Entregar pacotes com mais rapidez que TCP com menos atraso.
  • Configure as conexões mais rapidamente, pois não há um handshake inicial para configurar a conexão
  • Transmitir pacotes multicast, enquanto TCP tem que usar várias conexões.
  • Transmitir pacotes de tamanho fixo, enquanto TCP transmite dados em segmentos. Se você transferir um pacote UDP de 300 bytes, você receberá 300 bytes na outra extremidade. Com o TCP, você pode alimentar o soquete de envio de 300 bytes, mas o receptor só lê 100 bytes e você tem que descobrir de alguma forma que há mais 200 bytes no caminho. Isso é importante se o aplicativo transmitir mensagens de tamanho fixo, em vez de um fluxo de bytes.

Em resumo, o UDP pode ser usado para todo tipo de aplicativo que TCP pode, contanto que você também implemente um mecanismo de retransmissão apropriado. O UDP pode ser muito rápido, com pouco atraso, não é afetado pelo congestionamento em uma base de conexão, transmite datagramas de tamanho fixo e pode ser usado para multicast.

14
Andy

O UDP tem menos sobrecarga e é bom para fazer coisas como transmitir dados em tempo real, como áudio ou vídeo, ou, em qualquer caso, onde está tudo bem se os dados são perdidos.

13
Dana Holt

O UDP tem uma sobrecarga menor, como já foi dito para transmitir coisas como vídeo e áudio, onde é melhor perder um pacote e depois tentar reenviá-lo e atualizá-lo.

Não há garantias sobre a entrega TCP, você deve simplesmente ser informado se o soquete foi desconectado ou basicamente se os dados não chegarão. Caso contrário, chega lá quando chega lá.

Uma grande coisa que as pessoas esquecem é que o udp é baseado em pacotes, e o tcp é bytestream based, não há garantia de que o "tcp packet" que você enviou é o pacote que aparece na outra ponta, ele pode ser dissecado em quantos pacotes como os roteadores e pilhas desejam. Portanto, seu software tem a sobrecarga adicional de analisar bytes novamente em partes úteis de dados, o que pode exigir uma boa quantidade de sobrecarga. O UDP pode estar fora de ordem, então você tem que numerar seus pacotes ou usar algum outro mecanismo para reordená-los se quiser. Mas se você obtiver o pacote udp, ele chegará com todos os mesmos bytes na mesma ordem em que foi deixado, sem alterações. Portanto, o termo pacote udp faz sentido, mas o pacote tcp não necessariamente. TCP tem seu próprio mecanismo de repetição e pedido que está oculto em seu aplicativo, você pode reinventar isso com o UDP para adaptá-lo às suas necessidades.

O UDP é muito mais fácil de escrever código nos dois lados, basicamente porque você não precisa fazer nem manter as conexões ponto a ponto. Minha pergunta é normalmente onde estão as situações em que você deseja a sobrecarga TCP? E se você tomar atalhos como assumir que um "pacote" tcp recebido é o pacote completo que foi enviado, você está melhor? (é provável que você jogue fora dois pacotes se se incomodar em verificar o comprimento/conteúdo)

8
old_timer

A transmissão de vídeo é um exemplo perfeito do uso do UDP.

7
Daniel A. White

A comunicação em rede para videogames é quase sempre feita em UDP.

A velocidade é de extrema importância e não importa se as atualizações são perdidas, pois cada atualização contém o estado atual completo do que o jogador pode ver.

5
17 of 26

Em alguns casos, que outros destacaram, a chegada garantida de pacotes não é importante e, portanto, o uso do UDP é bom. Existem outros casos em que o UDP é preferível ao TCP.

Um caso único em que você gostaria de usar o UDP em vez de TCP é onde você está tunelando TCP sobre outro protocolo (por exemplo, túneis, redes virtuais, etc.). Se você encapsular TCP sobre TCP, os controles de congestionamento de cada um interferirão entre si. Por isso, geralmente prefere-se fazer o túnel TCP sobre o UDP (ou algum outro protocolo sem estado). Veja o artigo da TechRepublic: Entendendo TCP Sobre TCP: Efeitos de TCP Tunelamento em Taxa de Transferência e Latência de Ponta a Ponta .

3
Brian M. Hunt

A questão chave estava relacionada com "que tipo de situações o UDP seria a melhor escolha [over tcp]"

Há muitas ótimas respostas acima, mas o que falta é qualquer avaliação formal e objetiva do impacto da incerteza de transporte no desempenhoTCP.

Com o crescimento maciço de aplicativos móveis e os paradigmas "ocasionalmente conectados" ou "ocasionalmente desconectados" que os acompanham, há certamente situações em que a sobrecarga das tentativas do TCP de manter uma conexão quando as conexões são difíceis de obter leva a uma forte caso para UDP e sua natureza "orientada para mensagens".

Agora eu não tenho a matemática/pesquisa/números sobre isso, mas eu produzi aplicativos que trabalharam de forma mais confiável usando ACK/NAK e numeração de mensagens em UDP do que poderia ser obtido com TCP quando a conectividade era geralmente pobre e pobre velho TCP apenas passou o tempo e dinheiro do meu cliente apenas tentando se conectar. Você obtém isso em áreas regionais e rurais de muitos países ocidentais ....

3
Rob Von Nesselrode

Nem sempre é claro. No entanto, se você precisar de entrega garantida de pacotes sem perda e na seqüência correta, então TCP é provavelmente o que você deseja.

Por outro lado, o UDP é apropriado para transmitir pacotes curtos de informação onde a sequência da informação é menos importante ou onde os dados podem caber em um único pacote.

Também é apropriado quando você deseja transmitir as mesmas informações para muitos usuários.

Outras vezes, é apropriado quando você está enviando dados sequenciados, mas se algum deles falha, você não está muito preocupado (por exemplo, um aplicativo VOIP).

Alguns protocolos são mais complexos porque o que é necessário são alguns (mas não todos) os recursos do TCP, mas mais do que o que o UDP oferece. É aí que a camada de aplicação tem que implementar a funcionalidade adicional. Nesses casos, o UDP também é apropriado (por exemplo, rádio da Internet, a ordem é importante, mas nem todo pacote precisa passar).

Exemplos de onde é/poderia ser usado 1) Um servidor de horário transmitindo a hora correta para um grupo de máquinas em uma LAN. 2) Protocolos VOIP 3) Pesquisas de DNS 4) Solicitando serviços de LAN, por ex. Onde está voce? 5) Internet radio 6) e muitos outros ...

No unix você pode digitar grep udp/etc/services para obter uma lista de protocolos UDP implementados hoje ... existem centenas.

2
Matt

UDP quando a velocidade é necessária e a precisão se os pacotes não são, e TCP quando você precisa de precisão.

UDP é frequentemente mais difícil porque você deve escrever seu programa de maneira que não dependa da precisão dos pacotes.

2
bgw

O UDP pode ser usado quando um aplicativo se preocupa mais com dados "em tempo real" do que com a replicação de dados exata. Por exemplo, o VOIP pode usar o UDP e o aplicativo se preocupará em reordenar os pacotes, mas no final o VOIP não precisa de todos os pacotes, mas o mais importante é que precisa de um fluxo contínuo de muitos deles. Talvez você aqui uma "falha" na qualidade de voz, mas o principal objetivo é que você receba a mensagem e não que é recriado perfeitamente do outro lado. O UDP também é usado em situações em que a despesa de criar uma conexão e sincronização com TCP supera a carga útil. Consultas DNS são um exemplo perfeito. Um pacote fora, um pacote de volta, por consulta. Se usando TCP isto seria muito mais intensivo. Se você não receber a resposta do DNS, tente novamente.

2
RC.

Sabemos que o UDP é um protocolo sem conexão, então é

  1. adequado para processos que requerem comunicação simples de solicitação-resposta.
  2. adequado para processo com fluxo interno, controle de erro
  3. adequado para fundição ampla e multicasting

Exemplos específicos:

  • usado no SNMP
  • usado para alguns protocolos de atualização de rotas, como o RIP
2
vikki

Veja a seção 22.4 de Steven --- Programação de Rede Unix , "Quando Usar UDP ao invés de TCP".

Além disso, veja este outro SO resposta sobre o equívoco que o UDP é sempre mais rápido que o TCP .

O que Steven diz pode ser resumido da seguinte forma:

  • Use UDP para broadcast e multicast, já que esta é sua única opção (use multicast para qualquer novo aplicativo)
  • Você pode usar o UDP para aplicativos simples de solicitação/resposta, mas precisará criar seus próprios acks, tempos limite e retransmissões
  • Não use o UDP para transferência de dados em massa.
2
Robert S. Barnes

Comparando TCP com UDP, protocolos sem conexão, como UDP, asseguram velocidade, mas não confiabilidade de transmissão de pacotes. Por exemplo, os videogames normalmente não precisam de uma rede confiável, mas a velocidade é a mais importante e o uso de UDP para jogos tem a vantagem de reduzir o atraso da rede.

enter image description here

2
Elenasys

Temos serviço web que possui milhares de clientes winforms em tantos PCs. Os PCs não têm conexão com o backend DB, todo o acesso é via web service. Por isso, decidimos desenvolver um servidor de log central que escuta em uma porta UDP e todos os clientes enviam um pacote de log de erros xml (usando o logender UDP log4net) que é despejado em uma tabela de banco de dados quando é recebido. Como não nos importamos se alguns logs de erro são perdidos e com milhares de clientes, é rápido, com um serviço de log dedicado não carregando o serviço web principal.

1
softveda

Você deseja usar o UDP sobre TCP nos casos em que perder alguns dados ao longo do caminho não arruinará completamente os dados que estão sendo transmitidos. Muitos de seus usos estão em aplicações em tempo real, como jogos (ou seja, FPS, onde você nem sempre precisa saber onde cada jogador está em um determinado momento, e se você perder alguns pacotes ao longo do caminho, novos os dados informarão corretamente onde os jogadores estão, e o streaming de vídeo em tempo real (um quadro corrompido não estragará a experiência de visualização).

1
Zachary Murray

Estou um pouco relutante em sugerir UDP quando TCP poderia funcionar. O problema é que se TCP não estiver funcionando por algum motivo, porque a conexão está muito lenta ou congestionada, é improvável que a alteração do aplicativo para usar o UDP ajude. Uma conexão ruim é ruim para o UDP também. TCP já faz um trabalho muito bom de minimizar o congestionamento.

O único caso em que posso pensar em onde o UDP é necessário é para protocolos de transmissão. Nos casos em que um aplicativo envolve dois hosts conhecidos, o UDP provavelmente oferecerá apenas benefícios marginais de desempenho para custos substancialmente maiores de complexidade de código.

0
SingleNegationElimination