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 (!)).