• Nenhum resultado encontrado

Multiplexação e Demultiplexação do UDP

Protocolos Pertinentes a Tecnologia VoIP

3.2.3 Multiplexação e Demultiplexação do UDP

Cada aplicativo obtém do sistema operacional uma porta para envio de pacotes UDP, que portarão os números das respectivas portas, dentro do campo source port. Ao transmitir mensagens, o UDP aceita datagramas de diversos aplicativos e transmite-os à camada IP, propriedade denominada multiplexação, ilustrada na Figura 3.7.

Já ao receber mensagens, o UDP aceita datagramas oriundos da camada IP e os repassa aos aplicativos de destino por meio da destination port, endereçadas em cada pacote, o que consiste na propriedade de demultiplexação, também ilustrada na Figura 3.7 [12].

Figura 3.7 – Multiplexação e Demultiplexação UDP.

Compreende-se pela análise da Figura 3.7, que aplicações multicast, a exemplo de conferências multimídia, somente são possíveis em decorrência da multiplexação, pelo fato de basear-se em porta e não em conexões.

Embora dotado de avanços, o protocolo UDP ainda persiste com problemas, pois como o pacote IP, não é orientado à conexão, bem como não possui mecanismo de confirmação de recebimento, pelo que o transmissor não toma conhecimento quanto à entrega de um pacote enviado. A fim de suprir tais dificuldades, foi desenvolvido o TCP, tratado a seguir.

3.3 TCP

O protocolo TCP (Transmission Control Protocol), da camada de transporte, é definido pela RFC 793 e seus pacotes também devem ser encapsulados dentro de um pacote IP. Possui a peculiaridade de ser orientado a conexão, o que significa que os pacotes não são interpretados isoladamente e que fornece um serviço confiável de transferência de dados fim-a-fim [50].

Para troca de dados entre dois computadores via protocolo TCP, de início realiza-se o procedimento denominado Three-Way Handshake (cumprimento de três vias), que sincroniza ambos os lados. isso ocasiona a manutenção dos pacotes, ainda que cheguem diversamente ao envio.

Ainda envia um pacote de confirmação ACK (Acknowledge - reconhecimento) para cada pacote de dados recebido, bem como outro de keep-alive “mantenha vivo” periódico, para informá-lo da manutenção da conexão entre ambos. Para o término da comunicação, é enviado por um dos lados e confirmado pelo outro um pacote de finalização e, com isso, fecha-se o canal.

O TCP está localizado na camada de transporte, acima do IP, ou seja, na quarta camada do modelo OSI e tem como função básica assegurar que todos os pacotes sejam entregues às aplicações de destino em sequência, sem perdas, erros ou duplicações. Como o IP é um protocolo do tipo best-effort, ou seja, não garante que todos os pacotes serão entregues ao destino, o TCP tem a função de compensar esta falta de confiabilidade do IP por meio de uma confirmação fim-a-fim do recebimento de cada pacote.

origem, não sobrecarregue uma aplicação mais lenta no destino, com o envio de uma quantidade maior de pacotes do que ela pode tratar, além de um controle de congestionamento [11].

O TCP cria um canal bi-direcional, ou seja, full-duplex, e o seu cabeçalho contém as adições necessárias à implementação das peculiares funcionalidades, como pode ser observado na Figura 3.8 [35].

Figura 3.8 – Formato de um Pacote TCP.

Como comprovado pela Figura 3.8, integram o pacote TCP os campos abaixo descritos segundo [52]:

x Portas de origem e destino: identificam os pontos nos quais os processos de origem e de destino da camada superior recebem serviços TCP;

x número de sequência: geralmente especifíca o número associado ao primeiro

byte de dados da mensagem atual. Dadas certas circunstâncias, também pode ser

usado para identificar um número de sequência inicial a ser usado na transmissão que está iniciando;

x número de reconhecimento: contém o número de sequência do próximo byte de dados que o emissor do pacote espera receber;

x HLEN (Header Length - comprimento do cabeçalho): indica o número de palavras de 32 bits que constituem o cabeçalho do segmento;

x reservado: deve conter zeros e poderá ser usado em implementações futuras; x flags: transportam uma série de informações de controle;

x janela de recepção: especifica o tamanho da janela de recepção do emissor, isto é, o espaço disponível para dados ingressando;

x checksum: indica quando o cabeçalho e dados foram danificados em trânsito; x ponteiro para dados urgentes: aponta para o primeiro byte de dados urgentes no

pacote;

x opções: especificam várias opções TCP;

x dados: contém informações da camada superior.

A transmissão confiável não é apropriada para dados sensíveis a atrasos como áudio e vídeo em tempo real, pois, o TCP sempre tentará reenviar pacotes perdidos, causando atrasos e esperas por parte do usuário. Além de não ser multicast, ou seja, não viabilizar conferência e seu controle de congestionamento diminuir a janela de congestionamento assim que detectar perda de pacotes, diminuindo o fluxo de pacotes recebidos. Com isso, pacotes perdidos causariam graves problemas com áudio e vídeo, pois necessitam de fluxo contínuo de dados.

Quando se deseja transportar voz sobre IP, utiliza-se o UDP como protocolo de transporte, apesar de ele não ser confiável. Em uma conversação, a perda ocasional de até 5% dos pacotes de voz, embora não seja desejável, não prejudica de forma grave a transmissão [12].

Por outro lado, o tráfego de voz é altamente sensível ao atraso, e a rotina de estabelecimento e confirmação de mensagens do TCP introduz atrasos, bem como no caso de perda de pacotes, haveria ainda mais retardo na transmissão, devido à retransmissão. Assim, a tolerância pela perda de alguns pacotes é mais uma estratégia adequada do que introdução de atrasos na transmissão de voz [11].

O protocolo UDP, entretanto, não foi originalmente criado para o transporte de voz, apesar de afigurar-se melhor alternativa ao TCP no referido âmbito. Todavia para a utilização do UDP no tráfego de voz, necessita recorrer a outros protocolos, a exemplo do RTP, objeto da próxima seção.