UDP vs TCP, quão mais rápido é?[fechado]

Question

Para troca geral de mensagens de protocolo, que pode tolerar alguma perda de pacotes.Quão mais eficiente é o UDP sobre o TCP?

Answer 1

O UDP é mais rápido que o TCP, e a simples razão é porque seu pacote de reconhecimento (ACK) inexistente permite um fluxo contínuo de pacotes, em vez do TCP que reconhece um conjunto de pacotes, calculado usando o tamanho da janela TCP e o tempo de ida e volta (RTT). ).

Para mais informações recomendo o simples, mas muito compreensível Explicação da Skullbox (TCP vs.UDP)

Answer 2

As pessoas dizem que a principal coisa que o TCP oferece é confiabilidade.Mas isso não é verdade.A coisa mais importante que o TCP oferece é o controle de congestionamento:você pode executar 100 conexões TCP em um link DSL, todas na velocidade máxima, e todas as 100 conexões serão produtivas, porque todas "sentem" a largura de banda disponível.Experimente isso com 100 aplicativos UDP diferentes, todos enviando pacotes o mais rápido possível, e veja como as coisas funcionam para você.

Em uma escala maior, esse comportamento do TCP é o que evita que a Internet fique presa em um “colapso de congestionamento”.

Coisas que tendem a empurrar os aplicativos para o UDP:

• Semântica de entrega de grupo:é possível fazer uma entrega confiável para um grupo de pessoas com muito mais eficiência do que o reconhecimento ponto a ponto do TCP.

• Entrega fora de ordem:em muitos aplicativos, desde que você obtenha todos os dados, não importa a ordem em que eles chegam;você pode reduzir a latência no nível do aplicativo aceitando um bloqueio fora de ordem.

• Hostilidade:em uma LAN party, você pode não se importar se o seu navegador funciona bem, desde que você esteja enviando atualizações para a rede o mais rápido possível.

Mas mesmo que você se preocupe com o desempenho, provavelmente não vai querer usar o UDP:

• Você está precisando de confiabilidade agora, e muitas das coisas que você pode fazer para implementar a confiabilidade podem acabar sendo mais lentas do que o que o TCP já faz.

• Agora você não é amigável à rede, o que pode causar problemas em ambientes compartilhados.

• Mais importante ainda, os firewalls irão bloquear você.

Você pode potencialmente superar alguns problemas de desempenho e latência do TCP "entroncando" várias conexões TCP juntas;O iSCSI faz isso para contornar o controle de congestionamento em redes locais, mas você também pode fazer isso para criar um canal de mensagens "urgentes" de baixa latência (o comportamento "URGENTE" do TCP está totalmente quebrado).

Answer 3

Em algumas aplicações, o TCP é mais rápido (melhor rendimento) que o UDP.

Este é o caso ao fazer muitas gravações pequenas em relação ao tamanho da MTU.Por exemplo, li um experimento no qual um fluxo de pacotes de 300 bytes estava sendo enviado pela Ethernet (MTU de 1.500 bytes) e TCP foi 50% mais rápido que UDP.

A razão é porque o TCP tentará armazenar os dados em buffer e preencher um segmento de rede completo, fazendo assim um uso mais eficiente da largura de banda disponível.

O UDP, por outro lado, coloca o pacote na rede imediatamente, congestionando assim a rede com muitos pacotes pequenos.

Você provavelmente não deveria usar o UDP, a menos que tenha um motivo muito específico para fazê-lo.Especialmente porque você pode dar ao TCP o mesmo tipo de latência que o UDP desabilitando o Algoritmo de Nagle (por exemplo, se você estiver transmitindo dados de sensores em tempo real e não estiver preocupado em congestionar a rede com muitos pacotes pequenos).

Answer 4

com tolerância a perdas

Você quer dizer "com tolerância a perdas"?

Basicamente, o UDP não é "tolerante a perdas".Você pode enviar 100 pacotes para alguém, e essa pessoa pode receber apenas 95 desses pacotes, e alguns podem estar na ordem errada.

Para coisas como streaming de vídeo e jogos multijogador, onde é melhor perder um pacote do que atrasar todos os outros pacotes atrás dele, esta é a escolha óbvia

Para a maioria das outras coisas, porém, um pacote ausente ou “reorganizado” é crítico.Você teria que escrever algum código extra para ser executado no UDP para tentar novamente se alguma coisa fosse perdida e impor a ordem correta.Isso adicionaria um pouco de sobrecarga em determinados lugares.

Felizmente, algumas pessoas muito inteligentes fizeram isso e chamaram isso de TCP.

Pense desta forma:Se um pacote desaparecer, você prefere obter o próximo pacote o mais rápido possível e continuar (use UDP) ou você realmente precisa dos dados ausentes (use TCP).A sobrecarga não importará, a menos que você esteja em um cenário realmente extremo.

Answer 5

Qual protocolo tem melhor desempenho (em termos de rendimento) - UDP ou TCP - realmente depende das características da rede e do tráfego da rede.Roberto S.Barnes, por exemplo, aponta um cenário onde o TCP tem melhor desempenho (gravações de pequeno porte).Agora, considere um cenário em que a rede está congestionada e possui tráfego TCP e UDP.Os remetentes na rede que usam TCP sentirão o 'congestionamento' e reduzirão suas taxas de envio.No entanto, o UDP não possui nenhum mecanismo para evitar ou controlar congestionamentos, e os remetentes que usam o UDP continuariam a bombear dados na mesma taxa.Gradualmente, os remetentes TCP reduziriam suas taxas de envio ao mínimo e, se os remetentes UDP tivessem dados suficientes para serem enviados pela rede, eles consumiriam a maior parte da largura de banda disponível.Portanto, nesse caso, os remetentes UDP terão maior rendimento, pois obtêm a maior fatia da largura de banda da rede.Na verdade, este é um tópico de pesquisa ativo – Como melhorar o rendimento do TCP na presença de tráfego UDP.Uma maneira, que eu saiba, de usar os aplicativos TCP para melhorar o rendimento é abrindo várias conexões TCP.Dessa forma, mesmo que o rendimento de cada conexão TCP possa ser limitado, a soma total do rendimento de todas as conexões TCP pode ser maior que o rendimento de um aplicativo que usa UDP.

Answer 6

Cada conexão TCP requer um handshake inicial antes que os dados sejam transmitidos.Além disso, o cabeçalho TCP contém muita sobrecarga destinada a diferentes sinais e detecção de entrega de mensagens.Para uma troca de mensagens, o UDP provavelmente será suficiente se uma pequena chance de falha for aceitável.Se o recebimento precisar ser verificado, o TCP é sua melhor opção.

Answer 7

@André, Eu peço desculpa mas não concordo.O UDP é a escolha em alguns tipos de aplicação devido aos requisitos de desempenho.Um exemplo clássico é a videoconferência.Este tipo de aplicação não responde bem ao controle TCP.

Outro aspecto a levar em consideração é se você precisará de multicast.Nesse caso, use UDP.

Answer 8

Quando se fala em “o que é mais rápido” – há pelo menos dois aspectos muito diferentes:rendimento e latência.

Se falar sobre Taxa de transferência - O controle de fluxo do TCP (conforme mencionado em outras respostas) é extremamente importante e fazer algo comparável ao UDP, embora certamente possível, seria uma grande dor de cabeça (tm).Como resultado - usando UDP quando precisar Taxa de transferência, raramente se qualifica como uma boa ideia (a menos que você queira obter uma vantagem injusta sobre o TCP).

Contudo, se falarmos sobre latências - a coisa toda é completamente diferente.Embora na ausência de perda de pacotes o TCP e o UDP se comportem de forma extremamente semelhante (quaisquer diferenças, se houver, são marginais) - depois que o pacote é perdido, todo o padrão muda drasticamente.

Após qualquer perda de pacote, o TCP aguardará a retransmissão por pelo menos 200 ms (1 segundo de acordo com o parágrafo 2.4 da RFC6298, mas as implementações práticas modernas tendem a reduzi-la para 200 ms).Além disso, com o TCP, mesmo os pacotes que chegaram ao host de destino - não serão entregues ao seu aplicativo até que o pacote ausente seja recebido (ou seja, toda a comunicação é atrasada em ~ 200 ms) - aliás, esse efeito, conhecido como Head-of -Bloqueio de linha, é inerente a todos os fluxos ordenados confiáveis, sejam eles TCP ou UDP confiável+ordenado.Para piorar ainda mais as coisas - se o pacote retransmitido também for perdido, estaremos falando sobre um atraso de ~600ms (devido ao chamado backoff exponencial, a primeira retransmissão é de 200ms e a segunda é de 200*2=400ms).Se nosso canal tiver 1% de perda de pacotes (o que não é ruim para os padrões atuais) e tivermos um jogo com 20 atualizações por segundo, esses atrasos de 600 ms ocorrerão em média a cada 8 minutos.E como 600ms são mais que suficientes para te matar num jogo de ritmo acelerado – bem, é bastante mau para a jogabilidade.Esses efeitos são exatamente os motivos pelos quais os desenvolvedores de jogos geralmente preferem o UDP ao TCP.

No entanto, ao usar o UDP para reduzir latências - é importante perceber que apenas "usar o UDP" não é suficiente para obter uma melhoria substancial na latência, é tudo uma questão de COMO você está usando o UDP.Em particular, embora as bibliotecas RUDP geralmente evitem aquela "retirada exponencial" e usem tempos de retransmissão mais curtos - se forem usadas como um fluxo "ordenado confiável", elas ainda terão que sofrer de bloqueio de cabeçalho de linha (portanto, no caso de um fluxo duplo perda de pacotes, em vez desses 600ms obteremos cerca de 1,5*2*RTT - ou para um RTT de 80ms muito bom, é um atraso de aproximadamente 250ms, o que é uma melhoria, mas ainda é possível fazer melhor).Por outro lado, se usar técnicas discutidas em http://gafferongames.com/networked-physics/snapshot-compression/ e/ou http://ithare.com/udp-from-mog-perspective/#low-latency-compression , É possível eliminar totalmente o bloqueio Head-of-Line (portanto, para uma perda dupla de pacotes para um jogo com 20 atualizações/segundo, o atraso será de 100 ms, independentemente do RTT).

E como uma observação lateral - se acontecer de você ter acesso apenas ao TCP, mas não ao UDP (como no navegador, ou se o seu cliente estiver atrás de um dos 6-9% dos firewalls feios que bloqueiam o UDP) - há parece para ser uma forma de implementar UDP sobre TCP sem incorrer em muitas latências, veja aqui: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (certifique-se de ler os comentários também (!)).

Answer 9

Se você precisar enviar rapidamente uma mensagem pela rede entre dois IPs que ainda nem conversaram, um UDP chegará pelo menos 3 vezes mais rápido, geralmente 5 vezes mais rápido.

Answer 10

O UDP é um pouco mais rápido na minha experiência, mas não muito.A escolha não deve ser feita no desempenho, mas no conteúdo da mensagem e nas técnicas de compressão.

Se for um protocolo com mensagem intercâmbio, eu sugiro que o leve impacto no desempenho que você sofre com o TCP vale a pena.Você recebe uma conexão entre dois pontos finais que fornecerá tudo o que você precisa.Não tente fabricar seu próprio protocolo bidirecional confiável em cima do UDP, a menos que você esteja realmente confiante no que está realizando.

Answer 11

Lembre-se de que o TCP geralmente mantém várias mensagens conectadas.Se você quiser implementar isso no UDP, terá muito trabalho se quiser fazê-lo de maneira confiável.Sua solução será menos confiável, menos rápida ou terá uma quantidade incrível de trabalho.Existem aplicações válidas de UDP, mas se você está fazendo essa pergunta, provavelmente a sua não é.

Answer 12

Vou apenas deixar as coisas claras. TCP/UDP são dois carros que estão sendo conduzidos na estrada.suponha que os sinais e obstáculos de trânsito sejam erros TCP cuida da sinalização de trânsito, respeita tudo ao seu redor.Condução lenta porque algo pode acontecer com o carro.Enquanto UDP apenas sai dirigindo, a toda velocidade, sem respeitar as placas de rua.Nada, um motorista maluco. UDP não possui recuperação de erros. Se houver um obstáculo, ele apenas colidirá com ele e continuará.Enquanto TCP garante que todos os pacotes sejam enviados e recebidos perfeitamente, sem erros, portanto, o carro apenas passa por obstáculos sem colidir.Espero que este seja um bom exemplo para você entender, por que UDP é preferido em jogos.Os jogos precisam de velocidade. TCP é preferido em downloads ou os arquivos baixados podem estar corrompidos.

Answer 13

Algum trabalho foi feito para permitir que o programador tenha os benefícios dos dois mundos.

SCTP

É um protocolo de camada de transporte independente, mas pode ser usado como uma biblioteca que fornece uma camada adicional sobre UDP.A unidade básica de comunicação é uma mensagem (mapeada para um ou mais pacotes UDP).Há controle de congestionamento integrado.O protocolo possui botões e botões para ligar

• em ordem de entrega de mensagens
• retransmissão automática de mensagens perdidas, com parâmetros definidos pelo usuário

se algo disso for necessário para sua aplicação específica.

Um problema com isto é que o estabelecimento da conexão é um processo complicado (e, portanto, lento)

Outras coisas semelhantes

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

Mais uma coisa experimental proprietária semelhante

• https://en.wikipedia.org/wiki/QUIC

Isso também tenta melhorar o handshake triplo do TCP e alterar o controle de congestionamento para lidar melhor com linhas rápidas.

Answer 14

Não faz sentido falar sobre TCP ou UDP sem levar em conta a condição da rede.Se a rede entre os dois pontos tiver uma qualidade muito alta, o UDP é absolutamente mais rápido que o TCP, mas em algum outro caso, como a rede GPRS, o TCP pode ser mais rápido e confiável que o UDP.

Answer 15

A configuração da rede é crucial para qualquer medição.Faz uma enorme diferença se você está se comunicando através de soquetes em sua máquina local ou com o outro lado do mundo.

Três coisas que quero acrescentar à discussão:

1. Você pode encontrar aqui um artigo muito bom sobre TCP vs.UDP no contexto do desenvolvimento de jogos.
2. Adicionalmente, perfeito (jperf aprimorar o iPerf com uma GUI) é uma ferramenta muito boa para responder à sua pergunta medindo.
3. Implementei um benchmark em Python (veja esta pergunta SO).Em média de 10 ^ 6 iterações, a diferença para o envio de 8 bytes é de cerca de 1-2 microssegundos para UDP.