TCP vs UDP na transmissão de vídeo

Acabei de voltar do meu exame de programação de rede e uma das perguntas que eles nos fizeram foi "Se você fosse fazer streaming de vídeo, usaria TCP ou UDP? Dê uma explicação para os vídeos armazenados e ao vivo" . Para essa pergunta, eles simplesmente esperavam uma resposta curta de TCP para vídeo armazenado e UDP para vídeo ao vivo, mas pensei sobre isso no caminho para casa, e é necessariamente melhor usar UDP para streaming de vídeo ao vivo? Quer dizer, se você tem largura de banda para isso e diz que está transmitindo uma partida de futebol ou um show, você realmente precisa usar o UDP?

Vamos dizer que enquanto você está transmitindo este show ou qualquer outra coisa usando TCP você começa a perder pacotes (algo ruim aconteceu em alguma rede entre você e o remetente), e por um minuto inteiro você não recebe nenhum pacote. O stream de vídeo será pausado e, depois de decorrido um minuto, os pacotes começarão a passar novamente (o IP encontrou uma nova rota para você). O que aconteceria então é que o TCP retransmitiria no minuto em que você perdesse e continuaria enviando a transmissão ao vivo. Assumindo que a largura de banda é maior do que a taxa de bits no stream, e o ping não é muito alto, então, em um curto período de tempo, o minuto que você perdeu agirá como um buffer para o stream para você, dessa forma , se a perda de pacotes ocorrer novamente, você não notará.

Agora, posso pensar em alguns aparelhos onde isso não seria uma boa ideia, como, por exemplo, videoconferências, onde você precisa estar sempre no final do stream, porque atrasar um vídeo-chat é horrível, mas durante uma partida de futebol ou um show, o que importa se você está um minuto atrás do fluxo? Além disso, você tem a garantia de obter todos os dados e seria melhor salvá-los para visualização posterior, quando eles chegarem sem erros.

Então isso me leva à minha pergunta. Há alguma desvantagem que eu não conheça sobre o uso do TCP para streaming ao vivo? Ou deveria mesmo ser, se você tem largura de banda para isso, deveria optar pelo TCP, já que é "mais agradável" para a rede (controle de fluxo)?

Desvantagens de usar TCP para vídeo ao vivo:

1. Normalmente, os dispositivos de streaming de vídeo ao vivo não são projetados com o streaming de TCP em mente. Se você usar TCP, o sistema operacional deve armazenar em buffer os segmentos não confirmados para cada cliente. Isso é indesejável, principalmente no caso de eventos ao vivo; presumivelmente, sua lista de clientes simultâneos é longa devido à singularidade do evento. Vídeo-casts pré-gravados normalmente não têm tanto problema com isso porque os espectadores escalonam sua atividade de reprodução; portanto, o TCP é mais apropriado para reproduzir um vídeo sob demanda.
2. O multicast de IP reduz significativamente os requisitos de largura de banda de vídeo para grandes públicos; O TCP impede o uso de multicast IP, mas o UDP é adequado para multicast IP.
3. O vídeo ao vivo é normalmente um fluxo de largura de banda constante gravado em uma câmera; streams de vídeo pré-gravados saem de um disco. A dinâmica de perda de recuo do TCP torna mais difícil servir vídeo ao vivo quando os fluxos de origem estão em uma largura de banda constante (como aconteceria em um evento ao vivo). Se você fizer o buffer para o disco de uma câmera, certifique-se de ter buffer suficiente para eventos de rede imprevisíveis e taxas de envio / retirada de TCP variáveis. O UDP oferece muito mais controle para esse aplicativo, pois o UDP não se preocupa com quedas da camada de transporte de rede.

Para sua informação, por favor, não use a palavra "pacotes" ao descrever redes. As redes enviam "pacotes".

mas durante uma partida de futebol ou um show, o que importa se você está um minuto atrás do fluxo?

Para alguns fãs de futebol, um pouco. Foi observado que atrasos de até mesmo alguns segundos presentes em streams de vídeo digital devido à codificação (ou qualquer outra coisa) podem ser muito irritantes quando, durante eventos de alto perfil como partidas da copa do mundo, você pode ouvir gritos e gritos dos caras na porta ao lado (que está assistindo a um programa analógico indevido) antes de conseguir ver os movimentos do jogo que os causaram.

Acho que para alguém que se preocupa muito com esportes (e esse é o maior grupo de clientes pagantes da TV digital, pelo menos aqui na Alemanha), estar um minuto atrasado em uma transmissão de vídeo ao vivo seria completamente inaceitável (como em, eles ' d mude para o seu concorrente onde isso não acontecer).

Normalmente, um fluxo de vídeo é tolerante a falhas. Portanto, se alguns pacotes forem perdidos (devido a algum roteador estar sobrecarregado ao longo do caminho, por exemplo), ele ainda poderá exibir o conteúdo, mas com qualidade reduzida.

Se sua transmissão ao vivo estava usando TCP / IP, ela seria forçada a esperar por esses pacotes descartados antes de continuar processando dados mais novos.

Isso é duplamente ruim:

• dados antigos sejam retransmitidos (provavelmente para um quadro que já foi exibido e, portanto, sem valor) e
• novos dados não podem chegar até depois que os dados antigos foram retransmitidos

Se o seu objetivo é exibir as informações mais atualizadas possível (e para uma transmissão ao vivo você geralmente deseja estar atualizado, mesmo que seus quadros pareçam um pouco piores), então o TCP funcionará contra você.

Para um stream gravado, a situação é um pouco diferente: você provavelmente armazenará em buffer muito mais (possivelmente vários minutos!) E prefere ter os dados retransmitidos a ter alguns artefatos devido a pacotes perdidos. Nesse caso, o TCP é uma boa combinação (isso ainda poderia ser implementado em UDP, é claro, mas o TCP não tem tantas desvantagens quanto no caso de transmissão ao vivo).

Existem alguns casos de uso adequados para transporte UDP e outros adequados para transporte TCP.

O caso de uso também determina as configurações de codificação do vídeo. Ao transmitir uma partida de futebol, o foco está na qualidade e, na videoconferência, o foco está na latência.

Ao usar multicast para fornecer vídeo aos seus clientes, o UDP é usado.

O requisito para multicast é um hardware de rede caro entre o servidor de transmissão e o cliente. Na prática, isso significa que se sua empresa possui infraestrutura de rede, você pode usar UDP e multicast para streaming de vídeo ao vivo. Mesmo assim, a qualidade de serviço também é implementada para marcar pacotes de vídeo e priorizá-los para que não ocorra perda de pacotes.

O multicast simplificará o software de transmissão porque o hardware de rede cuidará da distribuição de pacotes aos clientes. Os clientes assinam canais multicast e a rede será reconfigurada para rotear pacotes para novos assinantes. Por padrão, todos os canais estão disponíveis para todos os clientes e podem ser roteados de maneira ideal.

Esse fluxo de trabalho dificulta o processo de autorização. O hardware de rede não diferencia os usuários inscritos de outros usuários. A solução para a autorização é criptografar o conteúdo do vídeo e habilitar a descriptografia no software do reprodutor quando a assinatura é válida.

O fluxo de trabalho Unicast (TCP) permite que o servidor verifique as credenciais do cliente e permite apenas assinaturas válidas. Até permite apenas um certo número de conexões simultâneas.

O multicast não está habilitado pela Internet.

Para entrega de vídeo pela Internet, deve ser usado TCP. Quando o UDP é usado, os desenvolvedores acabam reimplementando a retransmissão de pacotes, por exemplo. Protocolo ao vivo p2p do Bittorrent.

“Se você usar TCP, o SO deve armazenar em buffer os segmentos não reconhecidos para cada cliente. Isso é indesejável, principalmente no caso de eventos ao vivo”.

Este buffer deve existir de alguma forma. O mesmo é verdadeiro para o buffer de jitter no lado do jogador. É chamado de "buffer de soquete" e o software do servidor pode saber quando esse buffer está cheio e descartar os quadros de vídeo adequados para as transmissões ao vivo. É melhor usar o método unicast / TCP porque o software do servidor pode implementar a lógica de eliminação de quadros adequada. Pacotes ausentes aleatórios no caso de UDP apenas criarão uma experiência ruim para o usuário. como neste vídeo: http://tinypic.com/r/2qn89xz/9

"O multicast IP reduz significativamente os requisitos de largura de banda de vídeo para grandes públicos"

Isso é verdade para redes privadas, o Multicast não é habilitado pela Internet.

"Observe que se o TCP perder muitos pacotes, a conexão será interrompida; portanto, o UDP oferece muito mais controle para este aplicativo, já que o UDP não se preocupa com quedas na camada de transporte de rede."

O UDP também não se preocupa em descartar quadros inteiros ou grupo de quadros, portanto, não oferece mais controle sobre a experiência do usuário.

"Normalmente, um stream de vídeo é tolerante a falhas"

O vídeo codificado não é tolerante a falhas. Quando transmitido por transporte não confiável, a correção de erro de encaminhamento é adicionada ao contêiner de vídeo. Um bom exemplo é o contêiner MPEG-TS usado na transmissão de vídeo por satélite que transporta vários fluxos de áudio, vídeo, EPG, etc. Isso é necessário porque o link de satélite não é uma comunicação duplex, o que significa que o receptor não pode solicitar a retransmissão de pacotes perdidos.

Quando você tem comunicação duplex disponível, é sempre melhor retransmitir dados apenas para clientes com perda de pacote do que incluir sobrecarga de correção de erro de encaminhamento no fluxo enviado para todos os clientes.

Em qualquer caso, os pacotes perdidos são inaceitáveis. Quadros perdidos são permitidos em casos excepcionais quando a largura de banda é prejudicada.

O resultado da falta de pacotes são artefatos como este:

Alguns decodificadores podem quebrar em fluxos de pacotes ausentes em locais críticos.

Eu recomendo que você dê uma olhada no novo protocolo p2p live Bittorent Live .

Quanto ao streaming é melhor usar UDP, primeiro porque diminui a carga nos servidores, mas principalmente porque você pode enviar pacotes com multicast, é mais simples do que enviar para cada cliente conectado.

Depende. Quão crítico é o conteúdo que você está transmitindo? Se for crítico, use TCP. Isso pode causar problemas na largura de banda, na qualidade do vídeo (pode ser necessário usar uma qualidade inferior para lidar com a latência) e na latência. Mas se você precisa do conteúdo para chegar lá, use-o.

Caso contrário, o UDP deve estar bem se o fluxo não for crítico e seria preferido porque o UDP tende a ter menos sobrecarga.

Um dos maiores problemas com a entrega de eventos ao vivo na Internet é 'escala', e o TCP não escala bem. Por exemplo, quando você está transmitindo uma partida de futebol ao vivo - ao contrário de uma reprodução de filme sob demanda - o número de pessoas assistindo pode facilmente ser 1000 vezes mais. Em tal cenário, usar o TCP é uma sentença de morte para os CDNs (redes de entrega de conteúdo).

Existem alguns motivos principais pelos quais o TCP não se adapta bem:

1. Uma das maiores desvantagens do TCP é a variabilidade da taxa de transferência alcançável entre o emissor e o receptor. Ao fazer streaming de vídeo pela Internet, os pacotes de vídeo devem passar por vários roteadores pela Internet, cada um desses roteadores está conectado com conexões de velocidade diferente. O algoritmo TCP começa com a janela TCP pequena, depois cresce até que a perda de pacotes seja detectada, a perda de pacotes é considerada um sinal de congestionamento e o TCP responde a isso reduzindo drasticamente o tamanho da janela para evitar congestionamento. Assim, por sua vez, reduz o rendimento efetivo imediatamente. Agora imagine uma rede com transmissão TCP usando 6-7 saltos de roteador para o cliente (um cenário muito normal), se algum dos roteadores intermediários perder algum pacote, o TCP desse link reduzirá a taxa de transmissão. Na verdade, o fluxo de tráfego entre os roteadores segue o formato de uma ampulheta; sempre vá para cima e para baixo entre um dos roteadores intermediários. Renderizando a taxa de transferência efetiva muito menor em comparação com o UDP de melhor esforço.

2. Como você já deve saber, o TCP é um protocolo baseado em confirmação. Digamos, por exemplo, que um remetente está a 50ms de distância (ou seja, latência entre dois pontos). Isso significaria que o tempo que leva para um pacote ser enviado a um receptor e o receptor para enviar uma confirmação seria de 100 ms; assim, o rendimento máximo possível em comparação com a transmissão baseada em UDP já foi reduzido à metade.

3. O TCP não suporta multicast ou o novo padrão emergente de multicast AMT. O que significa que os CDNs não têm a oportunidade de reduzir o tráfego de rede replicando os pacotes - quando muitos clientes estão assistindo ao mesmo conteúdo. Essa é uma razão grande o suficiente para que os CDNs (como Akamai ou Level3) não combinem com o TCP para transmissões ao vivo.

Ao ler o debate TCP UDP, percebi uma falha lógica. Uma perda de pacote TCP causando um atraso de um minuto que é convertido em um buffer de um minuto não pode ser correlacionada ao UDP cair um minuto inteiro enquanto experimenta a mesma perda. Uma comparação mais justa é a seguinte.

O TCP experimenta uma perda de pacotes. O vídeo é interrompido enquanto o TCP reenvia os pacotes em uma tentativa de transmitir pacotes matematicamente perfeitos. O vídeo é atrasado por um minuto e continua de onde parou depois que o pacote perdido chega ao seu destino. Todos nós esperamos, mas sabemos que não perderemos um único pixel.

UDP experimenta uma perda de pacotes. Por um segundo, durante a transmissão de vídeo, um canto da tela fica um pouco embaçado. Ninguém percebe e o show continua sem procurar os pacotes perdidos.

Qualquer coisa que transmita obtém mais benefícios do UDP. A perda de pacotes que causa um atraso de um minuto no TCP não causaria um atraso de um minuto no UDP. Considerando que a maioria dos sistemas usa vários fluxos de resolução, fazendo com que as coisas fiquem bloqueadas quando há falta de pacotes, faz ainda mais sentido usar UDP.

UDP FTW durante a transmissão.

Se a largura de banda for muito maior do que a taxa de bits, eu recomendaria o TCP para streaming de vídeo ao vivo unicast.

Caso 1: Pacotes consecutivos são perdidos por vários segundos. => o vídeo ao vivo irá parar no lado do cliente, seja qual for a camada de transporte (TCP ou UDP). Quando a rede se recupera: - se TCP for usado, o reprodutor de vídeo do cliente pode escolher reiniciar o fluxo no primeiro pacote perdido (timeshift) OU descartar todos os pacotes atrasados ​​e reiniciar o fluxo de vídeo sem timeshift. - se UDP for usado, não há escolha do lado do cliente, reinicie o vídeo ao vivo sem qualquer mudança de tempo. => TCP igual ou melhor.

Caso 2: alguns pacotes são aleatoriamente e muitas vezes perdidos na rede. - se TCP for usado, esses pacotes serão imediatamente retransmitidos e com um buffer de jitter correto, não haverá impacto na qualidade / latência do stream de vídeo. - se UDP for usado, a qualidade do vídeo será ruim. => TCP muito melhor

Para streaming de vídeo, a largura de banda é provavelmente a restrição do sistema. Usando multicast, você pode reduzir significativamente a quantidade de largura de banda upstream usada. Com UDP, você pode facilmente fazer o multicast de seus pacotes para todos os terminais conectados. Você também pode usar um protocolo multicast confiável, um é chamado Pragmatic General Multicast (PGM), não sei nada sobre ele e acho que não é muito difundido em seu uso.

Além de todas as outras razões, o UDP pode usar multicast. Oferecer suporte a milhares de usuários TCP, todos transmitindo os mesmos dados, desperdiça largura de banda. No entanto, há outra razão importante para usar o TCP.

O TCP pode passar por firewalls e NATs com muito mais facilidade. Dependendo do seu NAT e da operadora, você pode não conseguir receber um fluxo UDP devido a problemas com a perfuração do UDP.

Todas as respostas de 'usar UDP' pressupõem uma abordagem de rede aberta e 'empurre-a o máximo que puder'. Bom para redes de áudio / vídeo dedicadas de jardim fechado de estilo antigo, que são do tipo que está desaparecendo.

No mundo real, sua transmissão passará por firewalls (que eliminam o multicast e às vezes o udp), a rede é compartilhada com outros aplicativos mais importantes ($$$), então você deseja punir os abusadores com dimensionamento de janela.

Essa é a questão, é mais uma questão de conteúdo do que de tempo. O protocolo TCP exige que um pacote que não foi entregue seja verificado, verificado e reenviado. O UDP não usa esse requisito. Portanto, se você enviou um arquivo que contém milhões de pacotes usando UDP, como um vídeo, se alguns dos pacotes estiverem faltando no momento da entrega, eles provavelmente não serão perdidos.