UDP vs TCP, quanto mais rápido é? [fechadas]

194

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

Cidadão líquido
fonte
Você também pode adicionar a tag "tcp", pois a pergunta também é sobre TCP.
Cristian Ciupitu 17/09/08
5
O que significa "troca geral de mensagens de protocolo"? A questão precisa esclarecer o que é a eficiência. Queremos menos latência para uma pequena mensagem? Ou queremos uma taxa de transferência mais alta para um fluxo contínuo de dados?
Johan Boulé
O TCP tem mais recursos melhores que o UDP, exceto a Velocidade.
RAJKUMAR NAGARETHINAM
3
A questão da velocidade TCP vs. UDP é discutível. A pergunta em seu título, na verdade, não corresponde ao corpo da pergunta. Os pacotes TCP e UDP viajam exatamente na mesma velocidade no mesmo meio.
Ron Maupin

Respostas:

86

O UDP é mais rápido que o TCP e o motivo simples é que seu ACK (pacote de reconhecimento 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 viagem de ida e volta (RTT).

Para obter mais informações, recomendo a explicação simples, mas muito compreensível do Skullbox (TCP vs. UDP)

Fernando Barrocal
fonte
19
Na verdade, existem muitos casos em que o TCP é realmente mais rápido que o UDP. Veja minha resposta abaixo.
Robert S. Barnes
2
O que é mais rápido depende inteiramente das características do tráfego.
4
Embora a resposta possa estar correta, ela não responde à pergunta e repete o conhecimento mencionado em outros lugares repetidamente. Também não menciona que os métodos UDP confiáveis ​​com ACK podem ser notavelmente mais rápidos que o TCP.
Elliot madeiras
268

As pessoas dizem que a principal coisa que o TCP oferece é a 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 "detectam" a largura de banda disponível. Experimente isso com 100 aplicativos UDP diferentes, todos os pacotes com a maior rapidez possível e veja como as coisas funcionam bem para você.

Em uma escala maior, esse comportamento TCP é o que impede a Internet de travar no "colapso do congestionamento".

Coisas que tendem a empurrar aplicativos para o UDP:

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

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

  • Não amigável: em uma festa na LAN, você pode não se importar se o seu navegador da web funciona bem desde que você esteja atualizando as atualizações da rede o mais rápido possível.

Mas mesmo se você se preocupa com o desempenho, provavelmente não deseja usar o UDP:

  • Você está pronto para a confiabilidade agora, e muitas das coisas que você pode fazer para implementar a confiabilidade podem acabar sendo mais lentas do 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 o bloquearão.

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

tqbf
fonte
18
Boa resposta, eu diria ainda mais geral, "controle de fluxo" (em oposição ao controle de congestionamento, que é um subconjunto de controle de fluxo). Não apenas várias conexões TCP podem compartilhar um link, mas também impediriam que o remetente transbordasse o buffer do receptor se eles parassem de processar os dados recebidos por qualquer motivo.
Alex B
1
@AaronLS: a perda de pacotes e o aumento do RTT (tempo de ida e volta) (que podem ser vistos como um proxy para o atraso na fila ) são / podem ser (por exemplo: redes WiFi podem perder pacotes sem congestionamento real, enganando alguns algoritmos de controle de congestionamento TCP para evitar congestionamentos) indicadores de congestionamento.
Ninjalj 31/03
2
UDP é um bastardo para lidar com ... Já estou cansado disso. Não importa o que eu faça, não consigo encontrar um equilíbrio entre desempenho, latência, taxa de transferência e confiabilidade. Ótimo para coisas em tempo real, como temporizadores ... mas estou trabalhando em uma substituição de TCP usando UDP e Forward Error Correction e isso é muito mais difícil do que eu pensava que seria. Controle de congestão. Um sistema universal que funciona em redes de 1 GB e redes sem fio é uma obra de arte. Sinto que estou tentando remontar pacotes que foram carregados em uma espingarda.
Jason Nelson
1
Outro ponto a favor do TCP é que ele é inerentemente orientado à conexão, o que simplifica bastante a lógica de manipulação de clientes de aplicativos ( listen-> accept-> o estado do cliente é naturalmente independente de outros clientes). O tratamento de várias conexões de um único cliente, em particular, torna-se complicado com o UDP. E um ponto a favor do UDP é que as pilhas de UDP são realmente fáceis de implementar, o que é uma enorme vantagem em sistemas embarcados (microcontroladores, FPGAs etc.). Em particular, uma implementação de TCP para um FPGA é geralmente algo que você deseja comprar de outra pessoa. e não pensar).
Jason C #
1
Isso tudo pressupõe apenas que estamos interessados ​​em fornecer dados consideráveis ​​(sem nos preocuparmos muito com a latência). Em alguns aplicativos (jogos / VoIP), a situação é drasticamente diferente: temos uma quantidade muito pequena de dados, mas nos preocupamos com latências MUITO; é essa coisa simples que responde por 99% dos usos legítimos do UDP. E alguns detalhes: (a) a entrega em grupo NÃO funciona pela Internet (e provavelmente nunca funcionará), portanto é o domínio somente da Intranet; (b) pelo Google, apenas 8-9% da população da Internet tem problemas com o UDP; (c) "rede hostil" não se aplica a fluxo de taxa fixa
No-Bugs Hare
93

Em alguns aplicativos, o TCP é mais rápido (melhor taxa de transferência) que o UDP.

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

O motivo é que o TCP tentará armazenar em buffer os dados e preencher um segmento de rede completo, tornando mais eficiente o uso da largura de banda disponível.

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

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

Robert S. Barnes
fonte
3
Na verdade, eu fiz benchmarks para esse efeito. Eu estava enviando pacotes tão grandes quanto o UDP suportaria sem gerar exceções (em Java) e o TCP era muito mais rápido. Eu acho que muitas otimizações de SO, driver e hardware também fazem parte disso.
Charlie
14
@ Myforwik: Primeiro, isso não é uma implementação definida, faz parte do protocolo TCP. É chamado de algoritmo Nagle. Ajuda a prevenir o que é comumente conhecido como Síndrome da Janela Parada. Procure os dois termos. Segundo, não há conceito de pacotes do ponto de vista do TCP. Por fim, o livro "Programação TCP / IP eficaz" dedica um capítulo inteiro a esse assunto e vários outros capítulos ao assunto relacionado de saber quando usar o TCP versus o UDP. Eu trago essa situação (que na verdade é bastante comum) porque o OP fez uma pergunta geral e essa é uma das muitas respostas possíveis.
Robert S. Barnes
46
@Myforwik. Ao sugerir moronismo em outros, tente perceber que todos temos lacunas em nosso conhecimento - você incluiu. O SO é, afinal, um fórum para compartilhamento de conhecimento. Praticamente todos os atiradores em primeira pessoa usam UDP, e é raro eles enviarem pacotes em tamanhos próximos a tão grandes quanto o MTU. Se você gostaria de sugerir a John Carmack que idiota ele era por ter adotado essa abordagem, eu o encorajaria a se educar a esse respeito primeiro. 15 anos e o código de rede de alto desempenho de uma indústria não se repousa e morre porque você acha isso "imbecil".
Engenheiro
2
" Li uma experiência em que um fluxo de pacotes de 300 bytes estava sendo enviado por Ethernet (1500 bytes MTU) e o TCP era 50% mais rápido que o UDP. " - você poderia vincular essa experiência?
Leviathan
3
@ Leviathan Está no livro Programação Efetiva de TCP / IP.
Robert S. Barnes
31

com tolerante 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 eles podem receber apenas 95 desses pacotes e alguns podem estar na ordem errada.

Para coisas como streaming de vídeo e jogos com vários jogadores, onde é melhor perder um pacote do que atrasar todos os outros pacotes por trá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 um código extra para executar no UDP para tentar novamente se as coisas falhassem e impor a ordem correta. Isso adicionaria um pouco de sobrecarga em determinados lugares.

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

Pense da seguinte maneira: se um pacote desaparecer, você gostaria de obter o próximo pacote o mais rápido possível e continuar (use UDP), ou você realmente precisa desses dados ausentes (use TCP). A sobrecarga não importará, a menos que você esteja em um cenário realmente crítico.

Orion Edwards
fonte
1
5 pacotes de 100? É bastante. Eu acho que é apenas um exemplo. Pergunta: na situação real, quantos pacotes podem ser perdidos? Porque se for, por exemplo, 2 de 10000 (mais menos 1), não me preocuparia com isso.
31
1
@ Freakish, sim, era apenas um exemplo. A quantidade real de perda de pacotes depende da sua conexão, redes upstream, etc. Eu costumava jogar muitos jogos on-line e achava que, se fosse apenas eu usando a conexão à Internet, não haveria perda de pacotes, mas assim que eu lançasse um download em segundo plano, começaria a receber alguns (talvez 10% a 20%). Isso aconteceu cerca de 5 anos atrás, e conexões mais rápidas à Internet podem ajudar.
Orion Edwards
2
Roteadores de Internet cair udp antes tcp
user1496062
19

Qual protocolo tem melhor desempenho (em termos de taxa de transferência) - UDP ou TCP - depende realmente das características da rede e do tráfego da rede. Robert S. Barnes, por exemplo, aponta um cenário em que o TCP tem melhor desempenho (gravações de tamanho pequeno). Agora, considere um cenário em que a rede está congestionada e possui tráfego TCP e UDP. Os remetentes na rede que estão usando o TCP sentirão o 'congestionamento' e reduzirão suas taxas de envio. No entanto, o UDP não possui mecanismos de controle ou prevenção de congestionamentos, e os remetentes que usam o UDP continuariam a enviar dados na mesma taxa. Gradualmente, os remetentes TCP reduziriam suas taxas de envio ao mínimo e, se os remetentes UDP tiverem dados suficientes para serem enviados pela rede, eles consumiriam a maior parte da largura de banda disponível. Então, nesse caso, Os remetentes UDP terão maior taxa de transferência, à medida que obtiverem a maior fatia da largura de banda da rede. De fato, este é um tópico de pesquisa ativo - Como melhorar a taxa de transferência TCP na presença de tráfego UDP. Uma maneira, pelo que sei, usar quais aplicativos TCP podem melhorar a taxa de transferência é abrir várias conexões TCP. Dessa forma, mesmo que a taxa de transferência de cada conexão TCP possa ser limitada, a soma total da taxa de transferência de todas as conexões TCP pode ser maior que a taxa de transferência de um aplicativo usando UDP.

gjain
fonte
2
Isso não está correto Os roteadores descartarão o UDP antes do TCP. Em uma conexão compartilhada, você pode se afogar com o UDP, mas o que provavelmente acontecerá em uma situação de excesso de oferta depende da tecnologia, mas é muito fácil para o UDP se degradar a ponto de enviar muito pouco apenas colisões.
User1496062
Gosto da sua explicação, mas não entendo um ponto. Se as conexões UDP puderem obter todo o tráfego (se a largura de banda estiver baixa ou os dados estiverem altos), nesse caso, seu aplicativo, se estiver usando o TCP, é refém basicamente daqueles que usam o UDP. Se todos os aplicativos estiverem usando TCP, eles "se sairão bem" um com o outro. Então, por que permitir o UDP no invasor em primeiro lugar?
Igor Čordaš
@PSIXO: Bem, TCP e UDP atendem a diferentes requisitos de aplicativos, portanto, ambos são usados ​​por aplicativos. A implicação de sua sugestão é que devemos ter uma infraestrutura de rede diferente para o tráfego TCP e UDP - uma proposta cara e certamente não algo que possamos fazer agora, especialmente com todo o investimento já feito. É por isso que os pesquisadores estão ocupados descobrindo maneiras alternativas de equilibrar o conflito em 'software'.
Gjáin
Bem, basicamente sim, ter duas infra-estruturas seria uma solução perfeita, mas infelizmente não é plausível. O que eu queria dizer com o meu comentário foi que você está exagerando o hit do UDP para o TCP porque, se fosse um fator tão alto, as pessoas simplesmente desativariam o UDP no roteador (como costumam fazer nas empresas) se precisarem do TCP para funcionar rapidamente. Lembre-se também de que os pacotes UDP têm maior chance de serem caídos do que o TCP. Sobre o restante dos fatos em sua resposta, concordo plenamente e acho bastante útil, mas acho que você está superestimando certos efeitos.
Igor Čordaš
18

Quando se fala em "o que é mais rápido" - há pelo menos dois aspectos muito diferentes: taxa de transferência e latência.

Se falar sobre taxa de transferência - o controle de fluxo do TCP (como 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 você precisar de taxa de transferência , raramente se qualifica como uma boa idéia (a menos que você queira obter uma vantagem injusta sobre o TCP).

No entanto, se falar de latências - tudo é completamente diferente. Enquanto na ausência de perda de pacotes, o TCP e o UDP se comportam extremamente semelhantes (quaisquer diferenças, se houver, são marginais) - após a perda do pacote, todo o padrão muda drasticamente.

Após qualquer perda de pacote, o TCP aguardará a retransmissão por pelo menos 200ms (1seg pelo parágrafo 2.4 da RFC6298, mas implementações práticas práticas tendem a reduzi-la para 200ms). 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 ~ 200ms) - BTW, esse efeito, conhecido como Head-of O bloqueio de linha é inerente a todos os fluxos ordenados confiáveis, seja TCP ou UDP confiável + ordenado. Para piorar ainda mais as coisas - se o pacote retransmitido também for perdido, falaremos sobre um atraso de ~ 600ms (devido ao chamado backoff exponencial, a primeira retransmissão é 200ms e a segunda é 200 * 2 = 400ms). Se nosso canal tiver 1% de perda de pacotes (o que não é ruim para os padrões atuais), e temos um jogo com 20 atualizações por segundo - esses atrasos de 600ms ocorrerão em média a cada 8 minutos. E como 600ms é mais que suficiente para você ser morto em um jogo em ritmo acelerado - bem, é muito ruim para a jogabilidade. Esses efeitos são exatamente o motivo pelo qual gamedevs prefere UDP sobre 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 da latência, é tudo sobre COMO você está usando o UDP. Em particular, embora as bibliotecas RUDP geralmente evitem esse "recuo exponencial" e usem tempos de retransmissão mais curtos - se forem usados ​​como um fluxo "ordenado confiável", eles ainda terão que sofrer bloqueio de cabeçalho de linha (por isso, no caso de um duplo perda de pacotes, em vez dos 600ms, obteremos 1,5 * 2 * RTT - ou, para um bom RT de 80ms, é um atraso de ~ 250ms, o que é uma melhoria, mas ainda é possível fazer melhor). Por outro lado, se estiver usando as técnicas discutidas em http://gafferongames.com/networked-physics/snapshot-compression/ e / ou http: // ithare. , é possível eliminar completamente o bloqueio do cabeçalho de linha (para uma perda de pacotes duplos para um jogo com 20 atualizações / segundo, o atraso será de 100 ms, independentemente do RTT).

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

Lebre sem erros
fonte
13

Cada conexão TCP requer um handshake inicial antes da transmissão dos dados. 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.

Kyle Cronin
fonte
Pequena chance de falha e um limite no tamanho do pacote.
11

@Andrew , eu imploro para diferir. O UDP é a escolha em alguns tipos de aplicativos devido a requisitos de desempenho. Um exemplo clássico é a videoconferência. Esse tipo de aplicativo não responde bem ao controle TCP.

Outro aspecto a considerar é se você precisará de multicast. Se sim, use UDP.

Marcio Aguiar
fonte
8
O UDP também é usado porque, se você perder um ou dois pacotes, provavelmente será tarde demais de qualquer maneira, e provavelmente é melhor ignorá-lo e seguir em frente para continuar assistindo. Um pequeno toque no vídeo por causa de alguns pacotes descartados é muito melhor do que ter toneladas de congestionamento.
22410 Kibbee
1
Correto - a transmissão múltipla de rede é muito rara e a maioria dos roteadores a bloqueia.
User1496062
8

Se você precisar enviar rapidamente uma mensagem pela rede entre dois IPs que ainda não falaram, um UDP chegará pelo menos três vezes mais rápido, geralmente 5 vezes mais rápido.

Myforwik
fonte
1
Alguma referencia?
Gerard
8

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

Ahmed I. Elsayed
fonte
7

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 compactação.

Se for um protocolo com troca de mensagens , sugiro que o desempenho muito leve que você recebe com o TCP valha a pena. Você tem uma conexão entre dois pontos finais que fornecerão tudo o que você precisa. Não tente fabricar seu próprio protocolo bidirecional confiável sobre o UDP, a menos que você esteja realmente confiante no que está realizando.

Andrew
fonte
5

Lembre-se de que o TCP geralmente mantém várias mensagens ligadas. Se você deseja 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 uma quantidade incrível de trabalho. Existem aplicativos válidos do UDP, mas se você está fazendo essa pergunta, provavelmente a sua não é.

Leon Timmermans
fonte
5

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

SCTP

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

  • na 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 o seu aplicativo em particular.

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

Outras coisas semelhantes

Mais uma coisa experimental proprietária semelhante

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

user7610
fonte
3

Não faz sentido falar sobre TCP ou UDP sem levar em consideração 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 outros casos, como a rede GPRS, o TCP poderá ser mais rápido e mais confiável que o UDP.

zhanglongpan
fonte
1

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

Quero acrescentar três coisas à discussão:

  1. Você pode encontrar aqui um artigo muito bom sobre TCP vs. UDP no contexto do desenvolvimento de jogos.
  2. Além disso, o iperf ( jperf enhancement iperf with a GUI) é uma ferramenta muito boa para responder sua pergunta medindo.
  3. Eu implementei uma referência em Python (consulte esta pergunta do 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 o UDP.
Michael Dorner
fonte
1
Para tornar o benchmark relevante para a Internet do mundo real, você precisa executá-lo novamente com um simulador de perda de pacotes como o netem. Se estiver fazendo certo (e com o RTT simulado de, digamos, 100 ms e a perda de pacotes simulada de 1%), os resultados serão diferentes drasticamente. Em resumo - enquanto as latências TCP e UDP são realmente as mesmas para perda zero de pacotes - elas começam a diferir MUITO para cada pacote perdido.
No-Bugs Hare,