Introdução às Redes de Computadores/Protocolo UDP

Introdução

O protocolo de transporte UDP foi referenciado pela RFC 768 em 28 de agosto de 1980. O UDP, ao contrário do que muitos creem, não é um protocolo anterior ao TCP. Inicialmente, não havia uma separação entre a camada de rede e de transporte. Os protocolos TCP e IP eram referenciados como um único protocolo. Entretanto, à medida que se percebiam as limitações do protocolo para certas aplicações, as especificações foram mudando. Na versão 3(1978) do TCP/IP já havia indícios de separação entre os protocolos, e na versão 4 (1980) há a separação total entre eles. Por isso o protocolo IP começa na versão 4.

O UDP nasce então para servir como uma interface entre o IP e a camada de aplicação. Sua RFC possui apenas três páginas e sua meta é ser um protocolo simples e rápido. Nela também é definido que o UDP assume que está rodando sobre o protocolo IP.

Em relação ao IP, adere poucos serviços, entre eles a verificação de erros (Checksum), suporte à multiplexação e demultiplexação e suporte a broadcast e multicast. Demais serviços, como entrega confiável de dados e controle de congestionamento, podem ser implementados pela camada de aplicação, se o programador achar necessário.

Comparação entre TCP e UDP

Melhor controle no nível da aplicação

Quando um processo passa dados, o UDP empacota e repassa para a camada de rede. No caso do TCP, o remetente é limitado pelo controle de congestionamento. Além disso, o TCP reenvia os segmentos até a recepção ser conhecida.

Não há estabelecimento de conexão

O TCP usa a apresentação de três vias antes de transferir dados. O UDP simplesmente os envia, garantindo maior velocidade. Por esse motivo o DNS roda sobre UDP. Já no caso do HTTP, para maior precisão na apresentação de páginas de texto, por exemplo, é usado o TCP.

Não há estados de conexão

O TCP mantém o estado da conexão: buffers de envio e recebimento, parâmetros de controle de congestionamento, parâmetros numéricos de seqüência e de reconhecimento. O UDP não mantém estado, dessa forma, suporta mais clientes ativos.

Pequena sobrecarga de cabeçalho

Além dos dados de cada segmento, apresentam as seguintes sobrecargas de cabeçalho de pacote: TCP = 20 bytes, UDP = 8 bytes.

Estrutura do Segmento UDP

O segmento UDP contém quatro campos de cabeçalho com 16bts cada, como mostrado no figura abaixo. A porta da fonte é um campo opcional que permite ao destinatário identificar o processo no remetente (demultiplexação) e a porta de destino identifica o processo de destino do segmento UDP. O campo da mensagem contém os dados da aplicação que está usando o segmento. Vamos observar mais detalhadamente o campo Checksum.

+	Bits 0 - 7	8 - 15	16 - 23
0	Source address
32	Destination address
64	Zeros	Protocol	UDP length
96	Source Port		Destination Port
128	Length		Checksum
160	Data

Checksum

Effect of a typical checksum function (the Unix cksum utility).

O Checksum é um campo de 16bits utilizado na detecção de erros fim-a-fim em UDP. Embora o UDP forneça verificação de erros, ele não recupera esse erro. Algumas implementações de UDP simplesmente descartam o segmento danificado, outras passam o segmento errado à aplicação acompanhado de algum aviso.

O principio de funcionamento do Checksum é muito simples. Do lado de remetente os dados são organizados em pequenos blocos de 16bits. Realiza-se a soma desses blocos e sobre o resultado é feito o complemento de um que é então armazenado no campo do Checksum do segmento UDP. No lado do destinatário o refaz-se o calculo feito no remetente e o resultado é então somado ao Checksum. Se o resultado for zero então considera-se que não houve erros no segmento

Vale lembrar que o Checksum é um campo opcional. Sendo assim, entende-se do lado do destinatário que se o Checksum estiver em zero, significa que a verificação não ocorrerá. Contudo, é possível no lado do remetente que o resultado do complemento de um da soma dos bits enviados pode ser zero. Neste caso, se a aplicação estiver usando Checksum então todos os 16bts serão marcados em um.

Checksums Simples

Os algorítmos mais simples de checksum quebram os dados em "palavras" com um número fixo de bits, e depois conta o bit do "exclusive or" de todas essas palavras. O resultado muda quando um único bit dos dados está ao contrário, e também quando dois ou mais bits em posições diferentes da palavra, estão trocados. Porém, esse algorítimo de checksum não é muito sensível a erros comuns como:

Mudar a ordem das palavras de dados;
Inserir ou deletar palavras com todos os bits zerados;
Trocar um número ímpar de bits na mesma posição da palavra.

Checksums Avançados

Alguns algorítmos mais sofisticados com verificação reduntante, icluindo os algorítimos como:Fletcher's checksum, Adler-32, and cyclic redundancy checks (CRCs), e eles são construídos para endereçar essas fraquezas através da consideração nao só o valor de cada byte, mas também a sua posição.O custo dessa habilidade de detectar mais tipos de erros é uma maior complexidade computacional ao fazer a verificação redundante de valores.

O Objetivo dos algorítimos de checksum é detectar modifiações acidentais como corrompimento de dados gravados ou erros de comunicação de canais Eles não são construídos para detectar corrompimentos intencionais por agentes maliciosos. Por isso, muitos algorítimos de checksum pode ser facilmente invertidos, no sentido de que alguém pode facilmente modificar os dados para preservar o seu checksum Para se proteger de modificações maliciosas, pode-se usar um hash de criptografia.

Um exemplo de Algorítimos de Checksum

Um exemplo de Checksum Simples:

Dados 4 bytes de dados: 0x25, 0x62, 0x3F, 0x52 (qualquer outra quantidade de bytes também é válida).
Passo 1: Adicionando-se todos os bytes juntos temos 0x118.
Passo 2: Retira-se o carry nibble para obter 0x18.
Passo 3: Calcule o complemento de doisde 0x18 e teremos 0xE8. Esse é o byte de checksum.
Passo 4: Para testar o byte checksum simplesmente o adicione ao grupo original de bytes. O resultado deverá ser 0x100.
Passo 5: Retire o carry nibble novamente resultando em 0x00. O resultado 0x00 (0 em decimal), indica que não houve erro (todavia um erro indetectável pode ter ocorrido).

Quando Utilizar o Protocolo UDP

Fluxo de dados em tempo real:
Multicasting:
Broadcasting;
E no geral, serviços que admitem certa perda de dados.

Exemplos de Serviços que usam UDP

Youtube, e outros serviços de streaming, tanto de áudio, quando de vídeo;
P2P;
Skype, e inúmeros serviços de VOIP.

Links

RFC 768: http://tools.ietf.org/html/rfc768