Mudanças entre as edições de "SMU29009: QoS e a Camada de Transporte"
(→UDP) |
|||
| Linha 65: | Linha 65: | ||
* [https://hpbn.co/building-blocks-of-udp/ Livro online: análise dos mecanismos do UDP] | * [https://hpbn.co/building-blocks-of-udp/ Livro online: análise dos mecanismos do UDP] | ||
| + | |||
| + | O protocolo UDP nada mais faz do que implementar um serviço orientado a datagramas e com multiplexação baseado em ports sobre o protocolo IP. Assim, pode-se listar o que o UDP NÃO faz (comparando-o com TCP): | ||
| + | * Sem garantia de entrega de mensagem | ||
| + | * Sem garantia de entrega ordenada | ||
| + | * Sem conexão | ||
| + | * Sem controle de congestionamento | ||
| + | |||
| + | == UDP e NAT == | ||
| + | |||
| + | Na Internet em que ainda predomina o uso de IPv4, ou sua presença é ainda relevante, o uso de NAT continua necessário. Como UDP é um protocolo sem estado, os tradutores NAT precisam memorizar os endereços IP e ports de cada datagrama UDP sainte, para permitir a entrada de datagramas UDP em sentido contrário que tenham as mesmas características. Se a comunicação ficar ociosa mais tempo do que o tempo de memorização do tradutor NAT, datagramas UDP entrantes não conseguem mais atravessar o tradutor NAT. Uma aplicação precisa então transmitir com uma frequência suficiente para que o tradutor NAT mantenha em memória as informações sobre o fluxo UDP. | ||
| + | |||
| + | Outro problema relacionado com NAT se dá com comunicações UDP com aplicações que estão atrás de um tradutor NAT, as quais usam ports UDP randômicos e cujos endereços IP são variáveis (ex: telefones IP, Google Talk). Nesse caso, para que a comunicação ocorra é necessário primeiro que a aplicação identifique o endereço IP externo apresentado pelo tradutor NAT, para então oferecê-lo como endereço de contato para aplicações fora de sua rede. Para situações assim se criaram serviços como [https://hpbn.co/building-blocks-of-udp/#udp-and-network-address-translators STUN, TURN e ICE]. | ||
== DCCP == | == DCCP == | ||
Edição das 11h19min de 3 de setembro de 2018
Uma aplicação multimidia
A concepção de uma aplicação multimidia:
- Serviço a ser oferecido
- Requisitos funcionais
- Requisitos não-funcionais
Ex:
- compartilhamento de video um-para-muitos (P2P)
Camada de transporte
Uma aplicação multimidia distribuída se comunica usando serviços da camada de transporte. Nessa camada há protocolos que implementam um serviço de comunicação fim-a-fim entre processos e através de uma rede não-confiável. As características dos protocolos de transporte influenciam o desempenho da aplicação multimidia, e por isso faz-se necessária uma revisão sobre os principais protocolos.
TCP
Negociação em três vias
O estabelecimento de conexão TCP envolve o intercâmbio de três mensagens entre o iniciador (cliente) e o atendente da conexão (servidor).
Intercâmbio de mensagens para estabelecimento de conexão
Para o desempenho de uma aplicação, a principal consequência é a percepção de uma latência para iniciar a comunicação de fato. Para aplicações que transmitem frequentemente pequenas quantidades de dados, o estabelecimento de nova conexão para cada transmissão reduz a taxa efetiva de dados obtida (além da latência). Uma proposta para atenuar o problema se chama TCP Fast Open, aplicável em situações em que ocorrem múltiplas conexões sucessivas entre um mesmo par cliente-servidor. Essa melhoria possibilita que, a partir da segunda conexão, o lado servidor comece a transmitir dados imediatamente após a recepção da mensagem SYN.
Controle e prevenção de congestionamento
O controle de congestionamento é um importante serviço do TCP, o qual evita sobrecarga de tráfego em uma rede e seu consequente colapso devido a congestionamento. Fazem parte dele o controle de fluxo, a partida lenta, e a prevenção de congestionamento.
As consequências para o desempenho de uma aplicação são:
- Baixa taxa efetiva de dados para pequenas transferências de dados (e sensível ao atraso fim-a-fim)
- Variações abruptas na taxa de dados caso qualquer erro ocorra (necessidade de retransmissão)
Produto da largura de banda pelo atraso
O produto da largura de banda pelo atraso corresponde à quantidade de dados em trânsito e ainda não confirmados. Ele se define pelo produto da capacidade dos links pelo atraso fim-a-fim. Esse produto tem implicação importante nos tamanhos das janelas de recepção tanto do cliente quanto do servidor. A janela de recepção deve ser ajustada em função do RTT e da taxa de dados estimada. Se as janelas de recepção forem inferiores a esse produto, um transmissor deve pausar a transmissão para esperar confirmações (devido ao controle de fluxo), quando poderia transmitir mais dados. Isso tem impacto negativo no desempenho de uma aplicação.
Apesar de o tamanho da janela de receção se ajustar automaticamente com as condições da comunicação, há que cuidar para que seu limite superior não se torne um gargalo. Para uma aplicação que precise de maior desempenho, deve-se conferir se a opção de multiplicação da janela (Window Scaling Option) está ativada no sistema operacional.
Head-of-line blocking
O bloqueio da frente da fila no TCP se deve ao seu mecanismo de garantia de entrega ordenada. Se uma mensagem se perde, o transmissor a retransmite, porém todas as mensagens subsequentes já recebidas no lado servidor ficam bloqueadas à espera da recepção da mensagem perdida. A aplicação que espera receber esses dados fica bloqueada até que a sequência bufferizada se complete, e possa ter acesso aos dados. Como consequência, isso causa uma variação imprevisível nos intervalos entre dados recebidos, chamado de jitter.
Ainda que uma aplicação não precise de entrega ordenada, ela está sujeita a essa penalidade. Por exemplo, uma aplicação que transmite mensagens individuais não precisa necessariamente que elas sejam entregues em ordem. Outro exemplo é uma aplicação em que novas mensagens substituem mensagens anteriores completamente (ex: mensagens de atualização de status de sensores): nesse caso, a entrega confiável se torna desnecessária. Em ambos casos, o protocolo TCP pode causar uma redução de desempenho, uma vez que não é possível desativar esses serviços. Para uma aplicação em que essas questões sejam críticas, pode ser mais adequado outro protocolo de transporte (ex: UDP ou DCCP).
Otimização para uso do TCP
UDP
O protocolo UDP nada mais faz do que implementar um serviço orientado a datagramas e com multiplexação baseado em ports sobre o protocolo IP. Assim, pode-se listar o que o UDP NÃO faz (comparando-o com TCP):
- Sem garantia de entrega de mensagem
- Sem garantia de entrega ordenada
- Sem conexão
- Sem controle de congestionamento
UDP e NAT
Na Internet em que ainda predomina o uso de IPv4, ou sua presença é ainda relevante, o uso de NAT continua necessário. Como UDP é um protocolo sem estado, os tradutores NAT precisam memorizar os endereços IP e ports de cada datagrama UDP sainte, para permitir a entrada de datagramas UDP em sentido contrário que tenham as mesmas características. Se a comunicação ficar ociosa mais tempo do que o tempo de memorização do tradutor NAT, datagramas UDP entrantes não conseguem mais atravessar o tradutor NAT. Uma aplicação precisa então transmitir com uma frequência suficiente para que o tradutor NAT mantenha em memória as informações sobre o fluxo UDP.
Outro problema relacionado com NAT se dá com comunicações UDP com aplicações que estão atrás de um tradutor NAT, as quais usam ports UDP randômicos e cujos endereços IP são variáveis (ex: telefones IP, Google Talk). Nesse caso, para que a comunicação ocorra é necessário primeiro que a aplicação identifique o endereço IP externo apresentado pelo tradutor NAT, para então oferecê-lo como endereço de contato para aplicações fora de sua rede. Para situações assim se criaram serviços como STUN, TURN e ICE.
DCCP