O TCP fornece confiabilidade na camada de transporte, enquanto o UDP não. Então, o UDP é rápido. Porém, um protocolo na camada de aplicação pode implementar um mecanismo confiável ao usar o UDP.
Nesse sentido, por que o UDP com confiabilidade (implementado na camada de aplicativos) não substitui o TCP no caso em que o UDP é mais rápido que o TCP enquanto precisamos de confiabilidade?
Respostas:
O TCP é o mais rápido que você pode fazer com suas propriedades de confiabilidade. Se você precisar apenas, digamos, de seqüenciamento e detecção de erros, o UDP pode ser criado para servir perfeitamente bem. Essa é a base para a maioria dos protocolos em tempo real, como voz, streaming de vídeo, etc., onde lag e jitter são mais importantes que a correção de erros "absoluta".
Fundamentalmente, o TCP diz que seus fluxos podem ser invocados eventualmente. A rapidez com que depende depende dos vários temporizadores, velocidades, etc. O tempo necessário para resolver erros pode ser imprevisível, mas as operações básicas são tão rápidas quanto possível quando não há erros. Se um sistema souber algo sobre os tipos de erros prováveis, poderá fazer algo que não é possível com o TCP. Por exemplo, se erros de bit único são especialmente prováveis, você pode usar a codificação de correção de erros para esses erros de bit: no entanto, isso é muito melhor implementado na camada de link. Como outro exemplo, se pequenas rajadas de perda de pacotes inteiros são comuns, você pode resolver isso com transmissão múltipla sem esperar pela perda, mas obviamente isso é caro em largura de banda. Ou então, diminua a velocidade até que a probabilidade de erro seja insignificante: também é caro em largura de banda. No final,
Em termos de implementação, você descobriria que os séculos de programadores investidos no TCP o tornarão mais rápido do que qualquer coisa geral que você possa se dar ao luxo de fazer, além de mais confiável nos casos extremos obscuros.
O TCP fornece: um método onipresente de conexão (essencial onde os sistemas de comunicação não têm controle comum), fornecendo um fluxo de bytes confiável, ordenado (e deduplicado), bidirecional, com janelas e janelas, com controle de congestionamento em redes multip hop de distância arbitrária.
Se um aplicativo não exige onipresença (seu software é executado nos dois lados) ou não precisa de todos os recursos do TCP, muitas pessoas usam com vantagem outros protocolos, geralmente sobre o UDP. Os exemplos incluem TFTP (minimalista, com tratamento de erros realmente ineficiente, QUIC, que é projetado para reduzir as despesas gerais (ainda marcadas como experimental)) e bibliotecas como lidgren, que possui controle refinado sobre exatamente quais recursos de confiabilidade são necessários. ]
fonte
UDP com confiabilidade pode realmente ser um substituto para o TCP. Já temos um exemplo disso: chama-se QUIC .
Da Wikipedia:
A vantagem de usar o UDP em vez de criar um novo protocolo de camada de transporte é que os roteadores e outros dispositivos de rede já o entendem.
fonte
Você pode usar o UDP para implementar a funcionalidade TCP na camada de aplicativo (confiabilidade, adaptabilidade). Você também pode usar o TCP em primeiro lugar, a menos que algo que seu aplicativo realmente precise não possa ser feito com o TCP. Se você implementar essas funções, provavelmente terminará muito pior do que com o TCP. A sobrecarga adicionada também diminui a eficiência geral.
O TCP não é lento - apenas requer um aperto de mão antes de transmitir e a janela de transmissão para se adaptar ao canal. Pode muito bem moldar sua taxa de transferência para o canal de transmissão em questão e se adaptar às mudanças durante o fluxo, o que o UDP não pode fazer (por si só).
No entanto, os protocolos acima da camada de transporte não são abordados aqui.
fonte
Em uma rede limpa, eles são bastante equivalentes. Há casos em que o TCP fica paralisado por períodos (alguém já viu uma tela HTTP congelar no carregamento?), Mas ele não entrega lixo ou mistura pacotes e raramente desiste completamente.
O UDP pode dar à camada de aplicativos mais controle sobre o tráfego à custa de uma enorme quantidade de trabalho.
A resposta para sua pergunta é que, às vezes, é feita dessa maneira. Jogos que exigem baixa latência costumam fazer exatamente isso. É muito mais trabalho, mas vale a pena a capacidade de controlar exatamente quantos pacotes pendentes você pode ter e com que frequência eles são tentados novamente.
Portanto, a diferença geral é que o TCP é uma implementação de uso geral muito boa, mas há objetivos específicos que o UDP pode fazer que o TCP seja muito ruim ou não exista - por exemplo:
Mas, em geral, não vale a pena, o TCP é bastante ideal; então, por que fazer todo o trabalho extra e adicionar uma (grande) chance de adicionar bugs e falhas de segurança?
fonte
O UDP não é rápido porque é UDP. O TCP não é lento porque é TCP.
Ambos os protocolos são projetados com certas garantias e o TCP bruto tem mais garantias que o UDP bruto.
E a regra geral é: o preço das garantias é o desempenho .
Não há nada que o proíba de implementar garantias TCP sobre UDP. Mas, então, você recebe mais garantias e precisa pagar o preço. Portanto, você reduz o desempenho para TCP ou pior (devido à sobrecarga UDP). A menos que você conheça melhor a implementação do TCP, o que é improvável. E se você o fizer (espero), você o revela e tornamos o TCP padrão mais rápido. E estamos de volta onde começamos. :)
Você pode jogar com essas garantias também. Modifique levemente isso, modifique levemente isso. E então você acaba com um protocolo como o QUIC, que é sobre o UDP e é muito semelhante ao TCP + TLS. Em muitos casos, é mais rápido que o TCP (embora, de acordo com este artigo, latência de até 5% e buffer de até 15%, o que a IMO não seja grande coisa), mas em alguns cenários (por exemplo, rede confiável ou sem necessidade de criptografia), na verdade é mais lento (veja uma explicação aqui ).
Você também pode enfraquecer essas garantias e isso faz mais sentido. Por exemplo, digamos que você esteja transmitindo e os pacotes antigos não sejam interessantes. Somente o mais recente. Mas o congestionamento ainda é importante. Então você recebe algumas garantias do TCP, mas não todas. E sim, as pessoas realmente fazem isso (por exemplo, jogos em tempo real). Isso oferece um melhor desempenho ao custo de algumas garantias.
fonte
Sua ideia seria boa no espaço profundo.
A resposta correta é "depende" e "porque isso danificaria a rede como um todo". O TCP / IP é muito gentil com as redes e se ajusta automaticamente à velocidade certa para ser rápido, mas não gerar toneladas de pacotes de retorno ICMP.
Quando um roteador com RAM insuficiente recebe subitamente qualquer tipo de pacote - digamos, do Tsunami, Bittorrent ou FDT - ele o solta e dispara de volta para o remetente um pequeno pacote de desrespeito à falha. Agora seu servidor UDP precisa rastrear e retransmitir essa parte manualmente. Alguns roteadores ISP moldam tanto o Bittorrent que isso machuca o tsunami?
O protocolo Tsunami usa UDP com um canal de controle no TCP. http://tsunami-udp.sourceforge.net/ Encontrei um estudo que mostra que é mais lento do que uma coisa chamada FDT.
O lendário protocolo Fast Data Transfer (FDT) do CERN é capaz de saturar qualquer rede usando vários fluxos TCP. Provavelmente é mais rápido, porque causa menos retransmissões do que o Tsunami, que inunda a rede com tanto UDP, que parte dele não é totalmente transmitido.
O UDP é usado por aplicativos não confiáveis: streaming de áudio, entrada / atualização de jogo IO, "ping" é realmente ICMP, mas não é garantido, Bittorrent, mosh ssh é incrivelmente responsivo, telefonia VOIP, multicast, DNS é enviado pelo UDP AFAIK. Qualquer coisa que não se importe com o estranho pacote ausente e possa "recuperar" instantaneamente.
O TCP / IP foi realmente a invenção mais importante que permitiu aos desenvolvedores de aplicativos, basta definir e esquecer. Um soquete é um par de endereços IP e portas e foi projetado para poder ser configurado e permanecer por horas, dias e até semanas sem se reconectar. E-mail, web, IRC e literalmente todos os aplicativos matadores usam TCP. Mas você pode obter pausas estranhas no download que de repente aumentam mais rapidamente ... e no espaço profundo as conexões podem esgotar o tempo, tornando as transferências no estilo Tsunami melhores para transferências interestelares de arquivos - você pode encontrar algo lá !!
A prova está nas considerações finais deste extrato de estudo científico, que mencionam a distância cada vez maior sobre o assunto: espaço profundo De: https://uscholar.univie.ac.at/get/o:300623.pdf
Então, novamente ... na verdade, existe um protocolo espacial muito parecido com o e-mail, que seria melhor para o espaço. Os aplicativos não devem se importar com valores de tempo limite, como para sempre.
fonte
TCP! = UDP + Confiabilidade
O TCP não é simplesmente UDP com confiabilidade adicional. O TCP oferece mais recursos do que apenas confiabilidade. Você pode ler sobre eles em muitos dos RFCs.
Qualquer um desses recursos "poderia" ser implementado na camada de aplicação. Eventualmente, torna-se um ponto em que você começa a reinventar a roda.
Para citar alguns recursos que o TCP possui ...
Criação e terminação de conexões: realiza handshakes e fechamentos de conexão
Controle de fluxo: garante que o remetente e o receptor transmitam a taxas em que ambos podem lidar com a taxa de dados.
Controle de congestionamento de ponta a ponta: permite que os nós finais acelerem sua taxa de transferência com base em perdas. Leia sobre início lento, prevenção de congestionamentos e recuperação rápida.
Na minha experiência, o UDP é usado quando a velocidade é uma preocupação com a confiabilidade. Você pode adicionar algum nível de confiabilidade no nível do aplicativo que não seja 100% tão confiável quanto o TCP. Por exemplo, se você ainda deseja um desempenho rápido, pode implementar a correção de erro direta (FEC) em que transmite os dados mais de uma vez. Você ainda obtém um bom desempenho e algum nível de confiabilidade (observe bastante a confiabilidade do TCP) sem todo o bate-papo de vaivém para obter pacotes perdidos. O objetivo é aumentar a utilização da rede, mas pode ser adequado para aplicativos em tempo real, como jogos ou streaming.
fonte