Introdução ao Protocolo Internet - IP

Esse artigo é uma introdução (detalhada!) do protocolo IP - Internet Protocol. Necessário para o bom entendimento do funcionamento de uma rede.

[ Hits: 142.963 ]

Por: Perfil removido em 02/06/2008


O cabeçalho IPv4



O datagrama IP é formado por um cabeçalho, seguido de um corpo de dados. O cabeçalho é formado por uma parte fixa e outra variável. O tamanho da parte fixa é de 20 bytes. Um datagrama que não tiver pelo menos estes 20 bytes é considerado mal formado e será descartado.

A parte variável do cabeçalho pode ter um tamanho máximo de 40 bytes. O tamanho máximo da parte variável é definido em função do campo IHL - Internet Header Length - que é 4 bits.

O campo IHL representa o número de palavras de 32 bits encontradas no cabeçalho. Uma palavra de 32 bits é formada por 4 octetos. Com 4 bits é possível representar no máximo 15 unidades maiores que zero. Em função disto, o tamanho total do cabeçalho fica limitado a 60 bytes. Como 20 bytes já são usados pela parte fixa, sobram 40 bytes para a parte variável.

O cabeçalho IP segue uma ordem de representação de bits denominada "Big Endian". Nesta notação o bit de mais alta ordem está à esquerda do octeto. A Figura a seguir ilustra o cabeçalho IP e seus campos.



Version - Um campo com 4 bits (nibble - Nome dado a ½ byte) e representa a versão do protocolo IP. Esse formato de cabeçalho pertence a versão quatro do protocolo IP, chamada de IPv4. Atualmente a versão mais usada do protocolo. O valor constante nesse campo será sempre o número 4 em binário (0100). Em uma rede heterogênea, com a presença de tráfego IPv6, esse campo pode ser usado por um roteador para escolha da rota mais adequada ao pacote.

IHL - Internet Header Length - Um campo de 4 bits (nibble) usado para representar o tamanho do cabeçalho Internet em palavras de 32 bits. O maior valor positivo representado é 15 (60 bytes) o menor é 5 (20 bytes) já que este é o tamanho mínimo do datagrama IP.

Type of Service - Este é um dos poucos campos do protocolo IP que tiveram sua utilização levemente modificada. Ele foi e ainda é usado para diferenciar classes de serviços, mas o modo como isso é feito foi modificado. Os roteadores mais antigos ignoravam completamente os parâmetros definidos neste campo. A RFC 1349 atualiza a utilização deste campo. Para compreender os conceitos de ToS - Type of Service - é necessário entender alguns conceitos básicos sobre transmissão de dados explicados no título QoS - Qualidade do Serviço.

Total Length - Esse campo representa o comprimento total do datagrama, medido em quantidade de octetos. O tamanho total inclui tanto o cabeçalho quanto os dados. O tamanho do campo é de 16 bits (representando 216) o que permitiria que o tamanho total do datagrama fosse de até 65.536 bytes ou 64 KB. Todavia, este tamanho de pacote é impraticável para a maioria das redes conectadas à Internet. Por definição, o tamanho obrigatório de datagrama IP que um host deve tratar é de 576 bytes (sendo este um datagrama inteiro ou um fragmento). Um host somente pode enviar pacotes maiores que 576 bytes caso tenha certeza que estes pacotes poderão ser encaminhados pela inter-rede.

Identification - Este campo é um rótulo de identificação para o datagrama. Todos os fragmentos de um datagrama possuem o mesmo valor de identificação. O tamanho do campo de identificação é de 16 bits.

Flags - Os três próximos bits são sinalizadores binários (flags). Um bit reservado (configurado como zero), um bit para o sinalizador de negação de fragmentação (DF - Don't Fragment) e outro bit para o indicador de fragmentação (MF - More Fragment).



O bit DF informa ao roteador que ele não poderá fragmentar o pacote em nenhuma hipótese, pois o host de destino não saberá remontá-lo. Em algumas situações isso significa que o pacote deve contornar essa rede que não pode encaminhar pacotes sem fragmentação. Caso não possa contornar essa rede de "pacotes pequenos", então o pacote será descartado. O descarte de pacotes acontece sempre que o encaminhamento não é viável sem que ocorra fragmentação. Quando este sinalizador (DF) está desativado, e caso haja necessidade, o pacote poderá ser fragmentado na origem ou pela inter-rede.

O bit MF quando ativo, indica que o pacote é um fragmento e que existem outros, de uma série de fragmentos, para chegar. O último fragmento de uma série dever ter este sinalizador desativado (configurado em zero) indicando que não existem mais fragmentos para chegar.

Fragment Offset - Esse campo funciona como um índice, indicando ao protocolo IP a seqüência de remontagem dos fragmentos. Este campo é medido em unidades de 8 bytes (64 bits), todos os pacotes fragmentados terão o campo Fragment Offset com um valor múltiplo de 8. Exceto o último pacote que poderá ter um valor maior ou menor que o múltiplo padrão. O primeiro fragmento de uma série, sempre têm Fragment Offset com valor zero.

Time to Live - Esse campo de 8 bits representa teoricamente o tempo em segundos que um datagrama poderia existir na inter-rede. Esse valor seria de 255 segundos ou 4,25 minutos. Entretanto, na prática, o campo representa o número de saltos (hops) que o pacote poderá realizar antes de ser descartado. Um salto ocorre sempre que o datagrama atravessa um roteador. Desta maneira, a cada salto o valor deste campo será subtraído de uma unidade. Este campo evita que datagramas, que não possam ser entregues, fiquem vagando pela rede. Quando o valor do TTL chega a zero o datagrama é descartado e uma mensagem de controle ICMP é enviada para o host emissor do pacote. O valor padrão sugerido atualmente para o campo TTL é 64.

Protocol - Este campo indica qual o protocolo, acima do IP na pilha TCP/IP, receberá os dados incluídos no datagrama IP. O tamanho deste campo é de 8 bits. Os números dos protocolos são atribuídos pela IANA. Os valores mais comuns são: 6 para TCP, 1 para ICMP e 17 para UDP.

Header Checksum - Este é um campo de 16 bits que armazena um somatório de checagens da integridade do próprio cabeçalho. Uma vez que o valor de alguns campos do cabeçalho são modificados a cada salto em um roteador (o campo TTL, por exemplo) o campo Header Checksum é recalculado e verificado a cada um destes saltos. O algoritmo de checagem é definido na RFC 791 do seguinte modo:

Inicialmente se supõe que o valor do campo Header Checksum seja zero. O objetivo do algoritmo é somar as meias palavras (cada 16 bits) no momento em que chegam, usando aritmética de "complemento de um". Após todas as meias palavras terem chegado é calculado o "complemento de um" de todas os resultados das meias palavras. Este será o valor armazenado no campo Header Checksum.

Source Address - Indica o endereço IP de 32 bits do host origem.

Destination Address - Indica o endereço IP de 32 bits do host destino.

Options - As opções são campos utilizados para superar possíveis deficiências do protocolo ou implementar campos que não são padrão para todas as redes. Opções são raramente utilizadas. As principais finalidades são as passagens de parâmetros como: nível de segurança da informação em tráfego, depuração e testes de algoritmos de roteamento e escolha arbitrária de rotas para o datagrama seguir. Consulte a RFC 791 para detalhes sobre opções. O campo opção pode ou não aparecer em um datagrama IP, todavia, na implementação do protocolo todas as opções devem estar presentes e disponíveis para uso.

Padding - (opcional) - Os campos no cabeçalho IP são definidos em função do tamanho da palavra de 32 bits. Havendo uma opção que não utilize alguns bits de menor ordem, esses campos livres devem ser preenchidos com zeros. Padding significa preenchimento.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução ao Protocolo Internet - IP
   2. Endereçamento IP
   3. Endereços IP especiais
   4. Criação de subredes IP
   5. Máscara de subrede
   6. CIDR - Classless InterDomain Routing
   7. Endereços IP privativos
   8. O cabeçalho IPv4
   9. Fragmentação
   10. QoS - Qualidade do Serviço
   11. ToS - Type of Service no protocolo IP
   12. Referências e conclusões
Outros artigos deste autor

Formatando o bash com cores e efeitos

Configurando corretamente para o Horário de Verão

Placas PCI x ISA-PNP

Instalação de um servidor de mensagens instantâneas Openfire na sua rede com clientes Microsoft Windows e cliente Jabber Exodus

Calculando máscara de sub-rede e broadcast

Leitura recomendada

Desenvolvimento de aplicações web

A importância do GNU

Software livre e a liberdade de contribuir

Comentário Infeliz

ROI em TI

  
Comentários
[1] Comentário enviado por roberto_espreto em 02/06/2008 - 12:37h

Cara, muito legal seu artigo! Ainda não tive tempo de ler adequadamente, mas assim que possível irei!
Tanembaum é de tirar o chapéu!
Um autor que gosto muito tbm é o Kurose e o Douglas Comer!
Continue com seus artigos assim!



®

[2] Comentário enviado por eduardo em 02/06/2008 - 13:57h

Parece ser bem interessante e completo.

Favoritei para ler depois ;)

[3] Comentário enviado por albertguedes em 02/06/2008 - 14:47h

Eita trabalhera hein ? Esse é um dos artigos mais completos que já li aqui no VOL, tenho que parabenizar pela esforço, valeu mesmo Unasi.

[4] Comentário enviado por maykonhammer em 02/06/2008 - 23:23h

parabéns pelo artigo..
flw

[5] Comentário enviado por elgio em 03/06/2008 - 10:55h

Muito bom!
Parabéns mesmo pelo excelente e completo artigo!

Em tempo: o task force Ipv6 elegeu 2008 como o "ano da virada". Será? hehehehe

[6] Comentário enviado por removido em 03/06/2008 - 11:59h

Excelente artigo!

[7] Comentário enviado por eng_ividal em 03/06/2008 - 18:07h

muito bom mesmo o artigo!!!

[8] Comentário enviado por stephannie em 04/06/2008 - 20:27h

Parabéns, muito bom!

[9] Comentário enviado por DavidNS em 28/08/2008 - 13:44h

valeu me ajudo a entender um pouco mais!!!

[10] Comentário enviado por leoh em 16/02/2010 - 23:54h

Texto de altíssima qualidade. Você tem talento para escrever. Parabéns.

[11] Comentário enviado por IanVilar em 01/11/2012 - 17:49h

Esse foi um dos artigos mais completos e bem explicados que já vi. Parabéns ao autor e que continue fazendo esse excelente trabalho!


Contribuir com comentário