Como os pacotes acham o caminho
Cada roteador diminui o TTL de um pacote em um. Quando chega a 0, o pacote é descartado, então um pacote preso em um laço não pode dar voltas para sempre.
Experimente o simulador antes de ler qualquer outra coisa. Ponha o TTL em 2 e aperte Enviar, depois ponha em 64 e envie de novo. Observe onde os pacotes param da primeira vez.
Arraste para girar. Role ou faça pinça para dar zoom.
O que você acabou de ver: uma contagem regressiva em cada pacote
Com TTL 2, todo pacote morreu no segundo roteador que encontrou e uma mensagem vermelha voltou. Com 64, os pacotes chegaram ao servidor com 60 de sobra depois de quatro roteadores. O cabeçalho IPv4 tem um campo de 8 bits chamado Time to Live (TTL, tempo de vida), então o seu maior valor é 255. A RFC 791 diz que todo roteador deve diminuí-lo em pelo menos um, e muitos computadores começam com 64. Quando chega a 0, o roteador descarta o pacote e envia uma mensagem ICMP "Time Exceeded" (RFC 792) de volta ao remetente. Era essa a mensagem vermelha.
Para que uma contagem regressiva? Um erro nas tabelas de roteamento poderia mandar um pacote dar voltas em círculo, e sem um limite ele ocuparia as ligações para sempre. O nome fala em "tempo", e no papel a RFC 791 o mede em segundos. Mas todo roteador tira pelo menos um, então na prática ele funciona como uma contagem de saltos. O IPv6 deu ao mesmo campo um nome mais simples, Hop Limit (limite de saltos).
O botão traceroute usa essa regra para desenhar um mapa. Ele envia uma sonda com TTL 1: o primeiro roteador a descarta e responde, o que revela o endereço desse roteador. TTL 2 revela o segundo roteador, e assim por diante até o destino responder. Aperte o botão e leia a lista que ele monta. Depois corte a ligação de R1 a R3 e envie de novo para ver os pacotes seguirem outro caminho.
Cada roteador consulta uma linha em uma tabela
Nenhum roteador conhece a rota inteira do seu notebook até um servidor em outro continente. Cada um toma uma única decisão: para este endereço de destino, qual vizinho recebe o pacote em seguida? O pacote avança um salto, e o próximo roteador decide de novo. Uma rota é uma corrente dessas escolhas locais.
A decisão vem de uma tabela de encaminhamento, uma lista de prefixos, cada um com o vizinho a usar. O roteador escolhe a entrada que combina com o destino pelo prefixo mais longo, porque um prefixo mais longo é uma correspondência mais exata. Digamos que a tabela mande 203.0.0.0/16 para o vizinho B e 203.0.113.0/24 para o vizinho A. Um pacote para 203.0.113.9 combina com as duas, o /24 vence, e ele vai para A. Um pacote para 203.0.7.1 combina só com o /16, então vai para B. A maioria das tabelas também tem uma entrada padrão para todo o resto; em um roteador de casa, ela aponta para o provedor.
| Pacote para | Entradas que combinam | Enviado para |
|---|---|---|
| 203.0.113.9 | 203.0.113.0/24 (A), 203.0.0.0/16 (B), padrão (provedor) | A, a mais longa (24 bits) |
| 203.0.7.1 | 203.0.0.0/16 (B), padrão (provedor) | B, a mais longa (16 bits) |
| 8.8.8.8 | padrão 0.0.0.0/0 (provedor) | Provedor |
Quem escreve as tabelas
Dentro de uma mesma empresa, os roteadores informam uns aos outros o que conseguem alcançar usando protocolos de roteamento e calculam novos caminhos quando uma ligação falha. Entre as dezenas de milhares de redes separadas que formam a internet, o Border Gateway Protocol (BGP, RFC 4271) leva anúncios como "consigo alcançar 198.51.100.0/24". Quando um cabo é cortado, as rotas que passavam por ele são retiradas e o tráfego passa para o caminho que sobrou. No simulador, foi isso que aconteceu quando você cortou a ligação de R1 a R3.
A maioria dos pacotes perdidos cai de uma fila cheia
Os roteadores também fazem os pacotes esperarem. Nos momentos de pico, os pacotes chegam mais rápido do que uma ligação de saída consegue levá-los, então cada roteador mantém uma fila na memória. Quando a fila está cheia, o próximo pacote que chega é simplesmente descartado. Ninguém é avisado; o remetente só consegue perceber depois. Essa é a forma mais comum de pacotes sumirem na internet, mais comum do que um cabo cortado. Um sinal de Wi-Fi fraco também pode estragar um quadro, que então precisa ser descartado. O IP em si não promete nada. A RFC 791 diz que ele não oferece um serviço de comunicação confiável, sem confirmações e sem retransmissões. Recuperar os dados perdidos fica a cargo dos computadores nas duas pontas, e esse é o assunto da próxima unidade.
Uma foto de 3 000 000 bytes são 2055 pacotes
As ligações limitam o tamanho de um pacote. Na Ethernet, um quadro leva no máximo 1500 bytes de carga útil (RFC 894). Tire 20 bytes do cabeçalho IPv4 e 20 bytes do cabeçalho TCP, e cerca de 1460 bytes dos seus dados cabem em cada pacote. Uma foto de 3 000 000 bytes precisa, portanto, de 3 000 000 ÷ 1460 ≈ 2054.8, arredondado para cima, 2055 pacotes, e cada um é roteado por conta própria.
- Um pacote sai com TTL 64 e passa por 4 roteadores. Qual é o TTL dele quando chega?
- O TTL é um campo de 8 bits. Qual é o maior valor que ele pode guardar?
- O que um roteador faz quando o TTL de um pacote chega a 0?
- Descarta o pacote e envia ICMP Time Exceeded ao remetente
- Envia o pacote adiante com TTL 64
- Devolve o pacote ao remetente
- Guarda o pacote até a rede ficar tranquila
- Por que o TTL existe?
- Para que um pacote preso em um laço de roteamento não dê voltas para sempre
- Para medir a velocidade da luz
- Para dizer por quanto tempo uma página da web pode ficar em cache
- Para contar os pacotes de um arquivo
- O traceroute envia uma sonda com TTL 1. Quem responde?
- O primeiro roteador do caminho
- O servidor de destino
- O resolvedor DNS
- Ninguém
- Uma tabela tem 203.0.113.0/24 → A e 203.0.0.0/16 → B. Para onde vai um pacote para 203.0.113.9?
- A
- B
- Para os dois
- Para nenhum
- Mesma tabela. Para onde vai um pacote para 203.0.7.1?
- B
- A
- Para os dois
- É descartado
- Cerca de 1460 bytes de dados cabem em um pacote. De quantos pacotes precisa um arquivo de 3 000 000 bytes?
- Qual protocolo leva os anúncios de rotas entre as redes separadas da internet?
- BGP
- DNS
- HTTP
- UDP
- No simulador, você corta a ligação de R5 ao servidor. O que acontece?
- Nada passa: o servidor tem só uma ligação
- Os pacotes dão a volta por R4
- Os pacotes chegam mais rápido
- Só os pacotes UDP passam
- "Cada roteador conhece o caminho inteiro até o servidor." Cada roteador só escolhe o próximo salto pela sua tabela de encaminhamento. A rota é a corrente que essas escolhas isoladas formam, e pacotes da mesma mensagem podem seguir rotas diferentes.
- "O TTL é quantos segundos restam a um pacote." A RFC 791 de fato o descreve em segundos, mas todo roteador precisa tirar pelo menos um, então na prática ele conta saltos. O IPv6 o renomeou Hop Limit. O TTL de um registro DNS é outro valor com o mesmo nome, e esse sim é em segundos.
- "A maioria dos pacotes perdidos vem de cabos quebrados." A maioria é descartada por roteadores ocupados com as filas cheias, e um sinal de Wi-Fi fraco também estraga quadros. Um cabo cortado é mais raro, e muitas vezes os roteadores conseguem desviar o tráfego dele.
- "O IP garante que todo pacote chegue." A RFC 791 diz que o IP não oferece um serviço de comunicação confiável: sem confirmações, sem retransmissões. A recuperação é feita pelos dois computadores das pontas, geralmente com TCP.
- Os roteadores decidem um salto de cada vez usando uma tabela de encaminhamento; o prefixo mais longo que combina vence.
- O BGP espalha anúncios de rotas entre as redes e retira rotas quando ligações falham.
- O TTL (no IPv6, Hop Limit) cai 1 a cada roteador; em 0 o pacote é descartado e o ICMP avisa.
- O traceroute mapeia um caminho enviando TTL 1, 2, 3 e assim por diante.
Fontes deste curso (28)
- (checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
- IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
- RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
- RFC 792 ICMP (Time Exceeded)
- RFC 801 NCP/TCP transition plan (1 January 1983)
- RFC 894 Ethernet (1500-byte payload)
- RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
- RFC 1122 (127.0.0.0/8 loopback)
- RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
- RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
- RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
- RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
- RFC 8446 TLS 1.3 (one round-trip handshake)
- RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
- RFC 9293 TCP (three-way handshake, sequence numbers)
- IANA: ip-parameters registry (recommended default TTL 64)
- IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
- Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
- "What is a URL?", "HTTP response status codes" (developer.mozilla.org)
- Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
- "What is HTTP/3?" (cloudflare.com/learning)
- Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
- Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
- Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
- History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
- historyofinformation.com and Wikipedia ARPANET (Kline)
- Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
- Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)
Data de verificação: 2026-10-17