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.