Redes de computadores/Protocolo UDP
Introdução
[editar | editar código-fonte]O protocolo de transporte UDP foi referenciado pela RFC 768 em 28 de agosto de 1980. O UDP, ao contrário do que muitos crêem, 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 percebia as limitações do protocolo para certas aplicações, as especificações foram mudando. Na versão 3(1978) do TCP/IP já haviam 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/IP e UDP
[editar | editar código-fonte]Melhor controle no nível da aplicação
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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 | 24 - 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Source address | |||||||||||||||||||||||||||||||
| 32 | Destination address | |||||||||||||||||||||||||||||||
| 64 | Zeros | Protocol | UDP length | |||||||||||||||||||||||||||||
| 96 | Source Port | Destination Port | ||||||||||||||||||||||||||||||
| 128 | Length | Checksum | ||||||||||||||||||||||||||||||
| 160 | Data | |||||||||||||||||||||||||||||||
Checksum
[editar | editar código-fonte]
Checksum é um campo de 16bts 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
[editar | editar código-fonte]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
[editar | editar código-fonte]Alguns algorítmos mais sofisticados com verificação reduntante, incluindo 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
[editar | editar código-fonte]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
[editar | editar código-fonte]- 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
[editar | editar código-fonte]- Youtube, e outros serviços de streaming, tanto de áudio, quando de vídeo;
- P2P;
- Skype, e inúmeros serviços de VOIP.