Por que os aplicativos de transmissão de áudio e vídeo usam UDP em vez de TCP?

Pré-requisito: modelo TCP / IP , protocolo de datagrama do usuário (UDP)

Nesta era da internet moderna, com entretenimento, educação, jogos e todos os tipos de necessidades transmitindo ao vivo todos os dias, a demanda por um fluxo de vídeo ininterrupto é altamente inflexível. Para mergulhar no tópico de qual protocolo é melhor para streaming de vídeo, é necessário estar familiarizado com os protocolos TCP e UDP .

TCP em pacotes de transmissão:

• TCP é um protocolo que negocia uma sessão formal com seu parceiro. O TCP envia dados e aceita confirmação. 
• O TCP garante a entrega. 
• Ele também ajusta sua taxa de envio de acordo com sua estimativa da capacidade da rede de enviar os dados. Ele estima a largura de banda, a perda e a latência e, se houver deterioração, diminuirá a taxa de fluxo e, se tiverem melhorado, aumentará a taxa de fluxo.  
• Se um pacote de dados for perdido durante a transmissão, ele será retransmitido eventualmente.

Transmissão normal do
TCP : o TCP aumenta gradualmente a quantidade de dados que envia até que o link fique saturado. Primeiro, ele começa devagar e envia mais e mais dados em uma taxa crescente. Na fase de prevenção de congestionamento, para evitar congestionamento, aumenta gradualmente os dados. No estágio final, ele ajusta os dados a uma taxa que o receptor pode processar confortavelmente, conhecida como estado estacionário.

Reação do TCP a pacotes perdidos:
quando um pacote é perdido, seja devido ao buffer da rede estar sobrecarregado ou o receptor recebendo mais dados do que pode, o pacote perdido não será reconhecido, então o TCP assume que enviou os dados muito rapidamente e assim começa o início lento tudo de novo. Quando um segundo pacote é descartado, o fluxo é cortado novamente. Se os descartes forem sucessivos, a taxa cairá tanto que por vez, apenas um único pacote estará sendo enviado.

Podemos observar um cenário que descreve a reação do TCP aos pacotes perdidos abaixo - 

Neste cenário, a fonte A envia 10 pacotes de dados D1 a D10 para o destinatário B e, durante a transmissão, um pacote de dados D6 é perdido. 

• A Fonte A estabelece uma conexão TCP com a Fonte B.
• A envia o pacote de dados D1 e o pacote de dados D2 para a Fonte B.
• B pede o pacote de dados D3.
• A envia D3 junto com os pacotes de dados D4, D5 e D6.
• Mas D6 se perde durante a transmissão, digamos devido ao buffer de B ficar sobrecarregado.
• B então pede o pacote de dados D6.
• Desta vez, envia apenas um pacote, um início lento novamente.
• B pede D6 novamente.
• A continua a enviar pacotes D8 e D9 individualmente, enquanto B continua pedindo D6.
• O receptor não enviou 4 confirmações pedindo D6, o TCP agora assume que o pacote está perdido, caso contrário, a suposição é que ele foi roteado incorretamente na rede. Então, A finalmente retransmite D6.
• B agora pede o pacote de dados D10.
• A envia D10 e, em seguida, o processo de fechamento da conexão é executado.

Observamos que um único pacote descartado causou um processo de início lento e um processo de prevenção de congestionamento para não permitir o aumento do fluxo de tráfego. Ele caiu para um único pacote de cada vez. Assim, com a perda de um único pacote, nossa taxa de transferência chega a 50%.
Chegamos a certas conclusões que -

• O TCP é sensível à perda de pacotes, latência (atraso) e largura de banda disponível.
• O TCP se ajusta a ele usando início lento, prevenção de congestionamento e estimativa da latência do tempo de ida e volta (RTT).

Portanto, se seu cliente estiver exigindo largura de banda mais do que o remetente poderia fornecer e houver perda de dados, a latência será inevitável. Agora, se pensarmos em um streaming de vídeo ao vivo e devido a algumas das causas acima mencionadas, ocorre uma perda de pacote, então o desempenho do streaming ao vivo será fortemente deteriorado porque o protocolo estará ocupado retransmitindo os pacotes perdidos. Isso fará com que o espectador fique para trás em relação ao que realmente está sendo transmitido no vídeo ao vivo. 

UDP:
UDP também é um protocolo da camada de transporte. Não tem ideia se os dados chegam com sucesso ou não. Ele é enviado assim que o aplicativo fornece dados e assim que o sistema operacional diz OK. Essencialmente, não tem conhecimento de recebimento ou falha. UDP faz três coisas -

• Ele identifica o processo de envio e recebimento usando números de porta.
• Ele executa uma verificação de erro no cabeçalho UDP.
• Ele registra uma verificação no cabeçalho UDP.

Portanto, vemos que o UDP não fornece nenhum meio de recuperar os pacotes perdidos. Ele não se importa se cada pacote atingiu seu destino ou não. Se você pensar no streaming de vídeo ao vivo novamente, uma perda em um pacote de dados não atrasará o vídeo para recuperar o pacote perdido. A qualidade do vídeo irá se deteriorar dependendo de quanto foi a perda, variando de um pequeno quadrado no canto da tela sendo distorcido ou a tela inteira, mas o ritmo do vídeo permanecerá alinhado com a transmissão ao vivo real.

Protocolo em tempo real:

• O UDP em si não fornece muitos recursos que o TCP. Mas colocando-o em camadas com outro protocolo, podemos obter alguns recursos iguais ao TCP.
• Na conferência de voz ou vídeo, alguns dos recursos TCP são adicionados inserindo um protocolo chamado Real Time Protocol (RTP). Se colocarmos o cabeçalho RTP com UDP, o RTP adicionará números de sequência, alguns timestamps e um identificador da fonte de áudio ou vídeo e também permitirá que o protocolo denominado RTCP relate a perda.
• Ao usar RTP com UDP, os pacotes de voz são enviados com espaçamento uniforme com base na saída do codec.
  Por exemplo, em voz, eles são enviados a cada 20 ms (1/50 seg). E em vídeo, eles são enviados quando um pacote IP é preenchido.

Portanto, o UDP pode ser muito sensível à perda de voz se vários pacotes sucessivos forem perdidos, o áudio cair momentaneamente e notarmos isso. Mas se você perder um único pacote, é um 50º de um segundo de um som e seu ouvido não é sensível para detectar isso. Mas no caso do vídeo, como tantos pacotes de vídeo são necessários para pintar um único quadro, a qualidade pode ser reduzida e se torna aparente na forma de pequenos quadrados ou pequenos cortes na tela que mudam para uma cor diferente porque os dados não t vêm para pintá-lo corretamente. Em uma transmissão de áudio ou vídeo em tempo real, as redes normalmente não devem apresentar perda> 0,25%.

Portanto, o UDP acoplado a outros protocolos como RTP, WebRTC e RTSP pode fornecer uma experiência de streaming de vídeo melhor do que o TCP.

Por que uma aplicação usaria UDP ao invés de TCP?

Por que o streaming de mídias como áudio e vídeo são realizados utilizando UDP em vez do TCP?

Por que para aplicações em tempo real o protocolo UDP é mais indicado que o TCP?

Por que o UDP e adequado como protocolo de camada de transporte para aplicativos de vídeo?