Protocol (TCP/UDP/ICMP)

No cabeçalho do datagrama IPv4, o campo Protocol (Protocolo) é um identificador de 8 bits (1 byte) localizado logo após o campo Header Checksum e antes do Source Address. Sua função é fundamental para o processo de desmultiplexação (demultiplexing) da Camada de Rede: ele informa ao sistema operacional receptor qual protocolo da camada superior ou qual protocolo auxiliar está encapsulado na carga útil (payload) do datagrama IP.

1. Posicionamento e Formato do Campo

O campo Protocol ocupa exatamente 1 byte (8 bits) na posição de offset 9 dentro do cabeçalho IPv4 (considerando o byte 0 como o primeiro). Sua localização é fixa — diferentemente das opções IP, que são variáveis — o que permite leitura rápida por parte do roteador.

Offset:  0    1    2    3    4    5    6    7    8    9   10   ...
Campo:  Ver  IHL  TOS  Total Length | Identification | Flags/Fragment | TTL | Protocol | Header Checksum | Src Addr | Dst Addr | Options

Como tem 8 bits, comporta 256 valores possíveis (0 a 255), dos quais a IANA mantém o registro oficial chamado "Assigned Protocol Numbers".

2. O Registro IANA e os Valores Comuns

A IANA mantém um registro oficial chamado "Protocol Numbers". Os valores mais relevantes para a operação da internet moderna são:

3. TCP (Protocol = 6) - Transmission Control Protocol

O TCP é o protocolo de camada 4 mais utilizado na internet. Quando o campo Protocol carrega o valor 6, o payload do datagrama IP é um segmento TCP com a seguinte estrutura mínima:

| Source Port (16) | Dest Port (16) |
| Sequence Number (32)              |
| Acknowledgment Number (32)        |
| Data Offset | Flags | Window (16)  |
| Checksum (16) | Urgent Ptr (16)    |
| Options (variável)                 |
| Data (payload da aplicação)        |

Características do Tráfego TCP

• Orientado a conexão: exige handshake de três vias (SYN, SYN-ACK, ACK).
• Confiável: retransmite segmentos perdidos, valida checksum.
• Ordenado: usa números de sequência por byte.
• Aplicações típicas: HTTP/HTTPS (80/443), SMTP (25), FTP (21), SSH (22), DNS em modo TCP (53).

Captura Prática

Em um dump de pacote IPv4 carregando TCP, o Wireshark exibe:

Internet Protocol Version 4, Src: 192.168.1.10, Dst: 93.184.216.34
    Protocol: TCP (6)
Transmission Control Protocol, Src Port: 54321, Dst Port: 443

4. UDP (Protocol = 17) - User Datagram Protocol

O UDP é o protocolo de transporte enxuto, com cabeçalho de apenas 8 bytes. Quando o campo Protocol vale 17, o receptor sabe que o payload é um datagrama UDP:

| Source Port (16) | Dest Port (16) |
| Length (16)      | Checksum (16)  |
| Data                              |

Características do Tráfego UDP

• Sem conexão: sem handshake, sem estado mantido no kernel.
• Não confiável: sem retransmissão, sem reconhecimento.
• Sem ordem: datagramas podem chegar fora de ordem.
• Multicast e broadcast: suportados nativamente.
• Aplicações típicas: DNS (53), DHCP (67/68), SNMP (161), VoIP (RTP), jogos online, streaming ao vivo.

Vantagens em Cenários de Tempo Real

O UDP brilha quando a latência é mais crítica que a perda: uma chamada VoIP tolera a perda de 1% dos pacotes sem degradação perceptível, mas um atraso de 200 ms por retransmissão tornaria a conversa ininteligível. Por isso, RTP (Real-time Transport Protocol) é construído sobre UDP.

5. ICMP (Protocol = 1) - Internet Control Message Protocol

Quando o campo Protocol carrega o valor 1, o payload é uma mensagem ICMP. Diferentemente de TCP e UDP, o ICMP não transporta dados de aplicação — ele é um protocolo auxiliar da própria Camada de Rede, usado para sinalização de erros e diagnósticos.

Estrutura do Cabeçalho ICMP

| Type (8)    | Code (8)    | Checksum (16) |
| Rest of Header (32, dependente do Type)        |
| Data                                            |

Tipos Comuns de Mensagens ICMP

6. O Mecanismo de Desmultiplexação

O campo Protocol atua como um rótulo de roteamento interno dentro do próprio host. Como a Camada de Rede (IP) serve de transporte para múltiplos protocolos sobrepostos, ela precisa de um mecanismo para separar os fluxos de dados.

O processo funciona da seguinte maneira:

1. Recebimento: A placa de rede recebe o quadro (frame) da Camada de Enlace e o passa para a Camada de Rede.
2. Validação do IP: O kernel verifica o Header Checksum do IP e confirma se o endereço de destino corresponde à máquina (ou se é um broadcast).
3. Leitura do Campo Protocol: O kernel lê o byte do campo Protocol.
4. Decisão de Entrega (Dispatching):
   • Se o valor for 6, o payload é entregue ao módulo TCP.
   • Se o valor for 17, o payload é entregue ao módulo UDP.
   • Se o valor for 1, o payload é entregue ao módulo ICMP.
5. Processamento: O módulo correspondente lê seu próprio cabeçalho (TCP: portas e seq; UDP: portas; ICMP: type e code) para determinar a ação apropriada.

7. Estrutura Visual do Datagrama com Diferentes Protocolos

Estrutura com Protocol = 6 (TCP):

+-------------------------+
| Cabeçalho IPv4          |
| (Source/Dest Addr)      |
| Protocol = 6            |
+-------------------------+
| Cabeçalho TCP           |
| (Portas, Seq, Flags)    |
+-------------------------+
| Dados da Aplicação      |
+-------------------------+

Estrutura com Protocol = 17 (UDP):

+-------------------------+
| Cabeçalho IPv4          |
| Protocol = 17           |
+-------------------------+
| Cabeçalho UDP (8 bytes) |
| (Portas, Length, Check) |
+-------------------------+
| Dados da Aplicação      |
+-------------------------+

Estrutura com Protocol = 1 (ICMP):

+-------------------------+
| Cabeçalho IPv4          |
| Protocol = 1            |
+-------------------------+
| Cabeçalho ICMP          |
| (Type, Code, Checksum)  |
+-------------------------+
| Dados ICMP (Payload)    |
+-------------------------+

Sem esse campo de identificação, a máquina receptora receberia dados binários e não saberia como interpretá-los, resultando em descarte silencioso ou corrupção de dados.

8. Diferença no IPv6 (Next Header)

Embora este tópico esteja dentro da estrutura da Camada de Rede e geralmente focado no IPv4, é importante notar a evolução deste conceito no IPv6:

• No IPv4, este é um campo fixo chamado Protocol.
• No IPv6, o conceito foi expandido e renomeado para Next Header.
• No IPv6, o valor 1 (ICMPv4) foi substituído pelo valor 58, que identifica o ICMPv6. O TCP (6) e o UDP (17) permanecem com os mesmos números tanto no IPv4 quanto no IPv6.
• O campo Next Header do IPv6 também permite o encadeamento de cabeçalhos de extensão (Hop-by-Hop, Routing, Fragment, ESP, AH), formando uma lista ligada antes de chegar ao protocolo final.

9. Conclusão

O campo Protocol é a "porta de entrada" para a operação, manutenção e sinalização de erros da própria infraestrutura da Internet. Embora pequeno em tamanho (apenas 1 byte), seu impacto é enorme: sem ele, a pilha TCP/IP não conseguiria diferenciar um segmento HTTP de uma mensagem de erro ICMP ou de um datagrama DNS. Para analistas de rede, o campo Protocol é frequentemente usado em filtros de captura (ip.proto == 6 para TCP, ip.proto == 17 para UDP, ip.proto == 1 para ICMP), em regras de firewall e em políticas de QoS (Quality of Service) para priorizar tráfego sensível à latência.