Como a internet funciona

(Leitura de 23 minutos)

O texto a seguir foi traduzido do original por César Rodriguez. Original disponível em https://thesquareplanet.com/blog/how-the-internet-works/ (consulta em 21/09/2019).

Não estranhe se alguma parte da página ainda estiver em inglês (certamente é a que está sendo trabalhada no momento), ou se os links forem para páginas em inglês (se forem os artigos centrais, serão traduzidos no futuro).

Originalmente postado em 12/10/2015 — compartilhado por Hacker NewsTwitter.

A internet se tornou um ponto de convergência para quase todos os setores da nossa sociedade — ela proporciona informação, comunicação e entretenimento a bilhões de pessoas todos os dias, e permite a colaboração coordenada entre pessoas e negócios por todo o globo. Infelizmente, essa peça crucial de infraestrutura é muito mal compreendida pela imensa maioria da população: a miríade de tecnologias (hardware e software) que permitem ao seu notebook conectar-se com o seu banco, ou com a janela do Skype de sua mãe, podem tranquilamente passar por mágica aos olhos de uma pessoa normal escolhida aleatoriamente na rua.

Para muitas outras tecnologias vitais do mundo contemporâneo, isso não é problema. A maioria das pessoas não sabe como consertar um carro ou construir uma casa, e pouca gente reclama disso. Porém, com a Internet é diferente. A despeito do que possa parecer, ela ainda está na infância, e há muitos debates sobre como ela deveria funcionar — e, mais importante —, como deveria ser regulada. Esse é um assunto importante a se discutir, mas para tomar decisões sensatas sobre isso, é preciso que todos os participantes do debate estejam bastante informados sobre os tópicos em discussão. Até agora, nós presenciamos muitos exemplos em que esse não era o caso, e isso pode ser diretamente prejudicial ao futuro da Internet como nós a conhecemos.

Esta postagem busca ajudar a informar e guiar aqueles que pretendem (ou deveriam pretender) expandir seus conhecimentos sobre esse canal de comunicação extraordinário, de uma forma acessível a quem não tenha conhecimento prévio de Ciência da Computação. Como a Internet é uma fera consideravelmente complexa, nós precisaremos percorrer muitos assuntos em pouco tempo — portanto, a profundidade da exposição naturalmente terá suas limitações. Deixarei links para materiais de leitura mais profundos em cada tópico, para que o leitor interessado possa continuar sua jornada pelo caminho das pedras.

Como a Internet é um sistema muito profundo e abrangente, é difícil decidir exatamente onde começar. A maioria dos componentes se interliga — frequentemente de formas muito sutis. Tendo em vista facilitar a compreensão, vamos começar por uma visão geral, de nível mais ou menos simples, e então aprofundar em cada componente individual enquanto prosseguimos. Nossa jornada começa com uma usuária chamada Alice. Alice tem um notebook e quer mandar um e-mail para uma pessoa chamada Bob. Bob usa o Gmail, e lerá o e-mail de Alice visitando a página gmail.com em seu Navegador Web. Ao final deste artigo, meu anseio é que você consiga entender todos os passos dados pelas partes da “linha” da internet (uma linha é simplesmente uma combinação de tecnologias) desde quando Alice aperta “Enviar” em seu cliente de e-mail até Bob conseguir ler o e-mail dela.

Quando Alice clica em “Enviar”, a primeira tarefa do notebook dela é descobrir como chegar até Bob. Para tornar o nosso exemplo mais concreto, digamos que o e-mail dele seja bob@gmail.com. Este endereço diz ao computador de Alice que “bob” é o nome de usuário de Bob, e que sua conta é gerenciada pelo servidor gmail.com. Um servidor é tão-somente uma máquina em algum lugar, conectada à Internet, que fornece algum serviço (no nosso caso, e-mail) a usuários remotos. Dada essa informação, o programa de e-mail de Alice agora precisa começar a falar de alguma forma com o servidor gmail.com, para entregar a ele o e-mail de Alice para Bob.

O primeiro passo na jornada da máquina de Alice é encontrar o endereço do Protocolo de Internet (Internet Protocol) do gmail.com, ou endereço IP, para simplificar. Usando uma analogia do mundo físico, imagine que você quer mandar uma encomenda para o Google. Você poderia dizer que o destinatário é a “Sede do Google”, mas no espaço do destinatário, no pacote, você teria que indicar uma informação endereçável, algo como “1600 Am­phithe­atre Pkwy, Moun­tain View, CA 94043, USA”. “Sede do Google” é um atalho útil, assim como gmail.com, mas para realmente fazer algo chegar até lá, você precisa dar o endereço completo, de forma que quem quer que esteja carregando sua encomenda possa encontrar o destino correto.

Endereços (IPs) na In­ter­net são sequências de números, seja na forma 192.168.1.102 (IP versão 4), ou na forma 2001:418:1425:28b::255e (IP versão 6). O primeiro está sendo abandonado aos poucos em prol do segundo, pois o segundo permite muito mais endereços únicos (IPv4 é composto de apenas quatro números de 0 até 255 — portanto, chega a aproximadamente 4 bilhões, enquanto o IPv6 tem muito mais combinações). Nós voltaremos para entender como esses números são usados para direcionar o e-mail de Alice, mas, por ora, concentremo-nos no problema de como Alice consegue descobrir o endereço de gmail.com.

gmail.com é conhecido como um nome de domínio na in­ter­net. Você provavelmente já viu muitos desses, pois eles são a informação que você usa para acessar a maioria dos websites (i.e., a parte que vai entre http:// e a primeira / em seu navegador da internet). A tradução de um nome de domínio em um endereço é feita usando os chamados Sistemas de Nome de Domínio (Do­main Name Sys­tems), ou DNS. Para descobrir o endereço associado a um nome de domínio específico, sua máquina contatará um servidor de DNS e perguntará a ele: “qual é o endereço de gmail.com?”, e ele, em resposta, dirá o endereço (se souber). Neste momento, o leitor mais atento pode ter percebido que há um potencial para um loop infinito — como você saberia o endereço dos servidores DNS? Nós retornaremos a essa questão quando falarmos sobre DHCP abaixo, mas, por ora, imagine que toda e qualquer máquina já sabe o endereço de pelo menos um servidor DNS, e por isso não precisa procurar por um.

DNS é um tópico extenso por si só, e muitas das discussões sobre censura e controle de acesso na in­ter­net são fortemente baseadas em DNS. Infelizmente, muitos dos que discutem esses assuntos não entendem as bases do DNS, o que complica consideravelmente a discussão. Em particular, muitos dos mal-entendidos derivam da crença de que recusar a pesquisa de um domínio espcífico o tornará inacessível na Internet. Nós não nos aprofundaremos em DNS nessa postagem, mas se o assunto for relevante para você, leia este artigo detalhado na web­host­inggeeks.com, bem como a página 3 e a página 4 do artigo sobre DNS da How­Stuff­Works.

Enfim o computador de Alice descobriu o endereço do servidor responsável pelo e-mail de Bob. E agora? Bem, a primeira coisa a ressaltar é que a máquina de Alice também tem um endereço IP. Toda máquina conetada à Internet é acessível de alguma forma através de um (ou mais) endereço(s) IP. Quando você se conecta a uma rede, sua máquina (geralmente) roda um protocolo conhecido como o Protocolo de Configuração de Hospedagem Dinâmica (Dy­namic Host Con­fig­u­ra­tion Pro­to­col), ou DHCP.

O DHCP determina que quando uma máquina se conecta a uma rede (e ainda não tem um endereço IP), ela deve enviar algumas transmissões num formato especial, informando que gostaria de receber um endereço. Se houver um servidor DHCP na mesma rede — geralmente é o modem que você recebeu de seu Provedor de Acesso à Internet, ou o roteador wireless (a caixa com antenas) que você tem em algum lugar em seu escritório ou em casa), — ele ouvirá essa transmissão, pegará um endereço IP vago e transmitirá de volta. Quando sua máquina ouvir essa resposta, ela adotará o endereço IP recebido. A máquina DHCP geralmente também incluirá, além do endereço IP, o endereço de outro ponto da rede capaz de falar com a internete (geralmente o dela própria), e os endereços IP de alguns servidores de DNS.

A caixa conectada à Internet na sua rede é conhecida como um gate­way, e sempre que sua máquina queira falar com uma máquina remota, ela transmite suas informações através do gate­way. Você pode pensar nele como sua agência de correio local. Qualquer máquina com a qual sua máquina queira falar tem uma configuração similar, com seu próprio gate­way, ou “agência de correio local”. Por ora, vamos assumir que os gateways conseguem se comunicar diretamente uns com os outros, como se eles estivessem conectados fisicamente por um cabo.

Mais a fundo, a Internet é um tipo de rede conhecido como de comutação de pacotes (packet-switched). Isso significa que as mensagens são enviadas em pacotes de tamanho limitado, e as mensagens que forem maiores que aquele limite serão divididas em múltiplos pacotes, que terão que ser reunificados no destino. Cada um desses pacotes menores é direcionado individualmente pela In­ter­net, em seu caminho até o destino final (no nosso exemplo, gmail.com).

Para enviar uma mensagem para gmail.com, primeiro a máquina de Alice precisa estabelecer uma conexão com a máquina que está no endereço gmail.com. Isso é feito utilizando o Protocolo de Controle de Transmissão (no original, Trans­mis­sion Con­trol Pro­to­col), ou TCP. O TCP é do tipo confiável e ordenado: em outras palavras, o que entra em uma ponta sairá igual na outra. É necessário um protocolo para essa comunicação (ao invés de simplesmente enviar todos os pacotes entulhados) porque a Internet é um lugar perigoso e imprevisível: se você enviar pacotes despreocupadamente de uma ponta à outra, apenas alguns conseguiriam chegar intactos, e mesmo estes frequentemente se embaralhariam no caminho e chegariam fora de ordem. O TCP abrange uma série de mecanismos para reunificar a mensagem original, inclusive pedindo partes que estejam faltando e reordenando-as corretamente. Existem outros protocolos, como o Protocolo de Datagrama do Usuário (no original, User Data­gram Pro­to­col), ou UDP — que normalmente é utilizado em jogos ou videoconferências —, para os quais a velocidade é mais importante que a confiabilidade. O UDP simplesmente transmite os pacotes um de cada vez, sem reunificação ou retransmissão na ponta do destinatário. Nós não falaremos mais sobre UDP nessa postagem.

Estabelecida a conexão, a máquina de Alice pode começar a enviar a mensagem para gmail.com. Entretanto, assim como acontece com correspondências físicas, ela precisa colocar a mensagem num envelope que contenha o nome do destinatário, o endereço do remetente, a linha de assunto, etc. (o endereço do destinatário é automaticamente adicionado com a “camada” do IP). Para isso, nós temos um padrão chamado Formato de Mensagem da Internet (em inglês, In­ter­net Mes­sage For­mat), ou IMF. Ele estabelece que um e-mail deve ser precedido de alguns pares de chave/valor, no formato Chave: Valor, e define alguns desses pares como padrão; por exemplo From:  (remetente), Subject: (assunto) e To: (destinatário). Por isso, a mensagem de e-mail de Alice ficará mais ou menos assim:

To: bob@gmail.com
From: alice@fastmail.com
Subject: Olá!

E aí, Bob, como vai?
- Alice

Ok, agora definitivamente estamos prontos para enviar nossa mensagem para gmail.com, não é? Bem… na verdade, há mais uma coisa que precisamos cobrir. A Internet não entende coisas tão sofisticadas quanto letras (ou “caracteres”, numa terminologia mais técnica); ela só entende bits (0s e 1s) e bytes (uma sequência de oito 0s e 1s). Por isso, nós temos que arranjar um jeito de converter nossa mensagem de texto em bytes, de uma forma que gmail.com possa reconectar o texto na outra ponta. Há diversos padrões com esse objetivo, mas nós vamos ficar no básico e usar um padrão amplamente adotado, chamado Código Padrão Americano para Intercâmbio de Informações (no original, Amer­i­can Stan­dard Code for In­for­ma­tion In­ter­change), ou ASCII. Essencialmente, o ASCII é uma tabela na qual podemos pesquisar um valor numérico que corresponde a determinada letra ou símbolo. Este valor numérico está no intervalo de 0 a 127, e por isso cabe em um único byte.

Como o ASCII só consegue representar 128 letras e símbolos, sua utilidade está restrita principalmente à correspondência dos Estados Unidos. Já foram criadas algumas variações com 256 caracteres mapeados (e que, portanto, também cabem em um único byte), para incluir mais letras e símbolos europeus, como æøå. Esses são conhecidos como a família de padrões ISO 8859. Sistemas mais modernos têm migrado para um padrão chamado Uni­code, especificamente o esquema de codificação UTF-8, que consegue representar praticamente todas as letras e símbolos em uso na Terra — gastando, para isso, mais de um byte por caractere.

Finalmente, agora nós podemos enviar o e-mail para gmail.com. Peguemos o e-mail codificado de Alice e despachemos ele por nossa conexão com gmail.com. Tecnicamente, será usado outro pequeno protocolo, que estabelece a forma de comunicação com um servidor de e-mail, chamado Protocolo de Transferência de Mensagens Simples (em inglês, Sim­ple Mail Trans­fer Pro­to­col), ou SMTP, mas ele não é relevante pra gente agora.

Nesse momento, gmail.com recebeu o e-mail de Alice, e ele fará as ações de sua rotina — escanear em busca de vírus, verificar se não é spam e coisas desse tipo que estiver programado para fazer —, até finalmente armazená-lo na caixa de e-mails de Bob. gmail.com provavelmente enviará a Bob uma notificação, avisando do recebimento de um novo e-mail, para que Bob vá ler a mensagem. Embora haja muitas formas de fazê-lo (os leitores interessados devem ler Qual é a diferença entre POP3, IMAP e Ex­change?, e os muito interessados devem dar uma olhada em IMAP e POP), vamos presumir que Bob lerá seu e-mail abrindo um Navegador Web, como o Chrome, Sa­fari, Fire­fox ou In­ter­net Ex­plorer, visitando o site http://gmail.com e fazendo o login.

Quando Bob digita o endereço do site na barra de endereços de seu navegador e aperta Enter, várias coisas acontecem muito rapidamente. Primeiro, é realizada uma pesquisa DNS pelo nome de domínio gmail.com. Segundo, é estabelecida uma conexão agmail.com usando TCP. Terceiro, o navegador envia uma requisição, através dessa conexão, usando o Protocolo de Transferência de Hipertexto (em inglês, Hy­per­text Trans­fer Pro­to­col) ou HTTP. “Mas espere!”, eu ouço você perguntar, “acabamos de ver isso! Essa conexão não vai dar no servidor de e-mail que está rodando em gmail.com?”.

Para responder a essa questão, To nós precisamos falar um pouco mais sobre TCP. Além de fornecer conexões confiáveis, o TCP também proporciona algo chamado multiplexação de aplicações (em inglês, ap­pli­ca­tion mul­ti­plex­ing). Isso quer dizer que múltiplos servidores podem rodar em uma só máquina, e clientes remotos podem escolher a qual desejam se conectar especificando uma porta. Muitos desses números de porta são conhecidos por seguirem padrões: por exemplo, o número de porta para enviar e-mails é 25, e a porta para acessar sites na web é a 80. Alguns de vocês já devem ter visto isso na barra de endereços de seu navegador: quando o nome de domínio é seguido de dois pontos e um número (http://gmail.com:81/...), isso diz ao navegador para usar a porta informada em vez da porta padrão (que é 80 para HTTP).

O navegador de Bob agora estabeleceu uma conexão com o servidor web rodando em gmail.com, e está pronto para requisitar a página de login. Para isso, ele usa HTTP, que tem um formato parecido com o IMF, que nós utilizamos para o e-mail de Alice. O HTTP é constituído por três partes: uma linha com a “ação” (e.g. GET /login), várias linhas com pares de chave/valor (e.g. User-Agent: Mozilla/Firefox, Host: gmail.com) e então quaisquer dados que Bob queira enviar para o servidor web (e.g. suas informações de login).

Eis a primeira requisição de Bob para http://gmail.com/login:

GET /login HTTP/1.1
Host: gmail.com

Em resposta, o servidor web em gmail.com responderá com um doc­u­mento HTML. HTML (ou Linguagem de Marcação de Hipertexto, em inglês Hy­per­Text Markup Lan­guage) é algo parecido com uma linguagem de programação, e permite que os desenvolvedores de páginas web construam páginas que são mais do que texto puro. A HTML permite que um desenvolvedor inclua imagens, links e vídeos, bem como adicione estilo ao conteúdo das páginas, mudando cores, tamanhos de fonte, etc. Sites modernos em HTML também usam outras ferramentas mais sofisticadas para aplicar estilos e alterar suas páginas quando já carregadas. Por exemplo, você já deve ter visto que, em muitos sites, clicar em um link ou fazer uma pesquisa não recarregará a página — em vez disso, o resultados aparecem de forma amigável (e rápida), geralmente com alguma animação, na página que já está carregada na sua tela. Isso é feito utilizando uma linguagem de programação para web chamda JavaScript.

Recebido o documento HTML de resposta (junto com quaisquer arquivos de estilo ou scripts), o navegador renderizará a página de login para Bob, exibindo um formulário de login para ele. Quando Bob “enviar” (em inglês, submit) esse formulário, será enviada outra requisição HTTP:

POST /login HTTP/1.1
Host: gmail.com

username=bob@gmail.com&password=bob_eh_muito_legal!

Perceba que a requisição não é mais do tipo GET, e sim POST, o que alerta ao servidor que Bob está enviando dados que ele deverá analisar. Neste caso, os dados na requisição são o nome de usuário e a senha de Bob, que o servidor web utilizará para autenticar o acesso de Bob. Se as credenciais de Bob forem válidas, o servidor responderá com outro documento HTML, dessa vez mostrando a Bob sua caixa de entrada. Ele também incluirá uma informação chamada cookie. Um cookie é um identificador que o navegador web de Bob passará em suas requisições HTTP subsequentes, para provar para o gmail.com que ainda é Bob se comunicando. Por exemplo, se Bob posteriormente acessar de novo http://gmail.com/inbox, seu navegador enviará alguma coisa como:

GET /inbox HTTP/1.1
Host: gmail.com
Cookie: token=2f0030c535193fc164e4e2b5689d9aba6533e6ddea82

O servidor web reconhecerá esse marcador e permitirá a Bob acesso a sua caixa de entrada sem obrigá-lo a fazer um novo login. O leitor astuto pode ter percebido que este cookie também permite ao site web “rastrear” Bob em sua navegação pelo site. Isso pode não ser um problema neste caso, já que Bob de fato quer ser associado com o gmail.com, mas se torna um problema quanto a sites de anúncios de terceiros. Já que o navegador de Bob sempre incluirá o cookie que ele tem para um nome de domínio particular, se dois sites utilizarem o mesmo provedor de anúncios (digamos, ads.com), então o ads.com pode ver que Bob visitou ambos sites. O mesmo acontece com os botões de curtir do Facebook que estão distribuídos pelos sites da web hoje em dia: eles todos são carregados do facebook.com, por isso o Face­book tem conhecimento de todos os sites que você visita que têm um botão de curtir do Facebook. Muitos navegadores hoje em dia tentam bloquear o vazamento desta informação, e essa foi a motivação da infame “Lei dos Cookies” dos Estados Unidos, mas é difícil resolver esse problema totalmente sem quebrar muitas páginas da web que contam com esse comportamento.

Quando o navegador web de Bob mostra para ele sua caixa de entrada, ele pode ler o e-mail de Alice de forma simples: basta enviar outra requisição HTTP para isso. O servidor, de forma completamente invisível para Bob, abrir o envelope IMF e formatar o e-mail de forma legal usando HTML, antes de mandá-lo de volta para o navegador. Finalmente, Bob pode ler o e-mail de Alice. Oba!

Então, agora acabou, não é? Bem… Não exatamente. Ainda há algumas pontas soltas. Primeiro, você pode ter se perguntado como uma única máquina pode ser responsável por todos os e-mails do gmail.com, e sua dúvida seria totalmente fundamentada. Na prática, o DNS geralmente retorna diversos endereços quando um domínio específico é pesquisado, e o navegador web simplesmente escolhe um deles aleatoriamente. Além disso, há outros computadores, conhecidos como balanceadores de carga (em inglês, load-bal­ancers), que recebem todo o tráfego de entrada de um endereço específico e distribuem esse tráfego para diversos servidores, pelos quais ele é responsável. O gmail.com usa ambos artifícios para garantir que seu serviço quase nunca esteja indisponível para os usuários. Um servidor individual pode também ter múltiplos nomes de domínio associados a ele (e.g., o endereço IP 74.125.226.86 poderia receber as requisições tanto de gmail.com quanto de googlemail.com), e é por isso que muitos protocolos (como HTTP) incluem um campo Host para identificar com qual nome de domínio o cliente pretende se comunicar.

Outra observação que você pode ter feito é que endereços na web têm cada vez mais o prefixo https://, e não só http://. O s significa “Seguro”, e implica que um protocolo conhecido como Segurança de Camada de Transporte (em inglês, Trans­port Layer Se­cu­rity), ou TLS está sendo utilizado. O TLS visa autenticar uma ou ambas as pontas de uma conexão de rede (i.e., garantir que Bob saiba que está se comunicando com o gmail.com “de verdade”), além de esconder a informação que está sendo trocada de tentativas de snoop­ing (“bisbilhotagem” da informação no caminho). O TLS é quase invisível para os usuários, pois o navegador roda ele automaticamente logo abaixo do HTTP, de onde ele silenciosamente criptografa todo o texto antes de enviar pela rede o servidor e o cliente (e vice-versa). De fato, o TLS é tão invisível e versátil que também pode ser utilizado para o protocolo de troca de e-mails que nós vimos acima, quando Alice estava enviando seu e-mail para gmail.com. Uma discussão sobre TLS está fora do escopo desta postagem, mas basta dizer que usar TLS corretamente é muito difícil, e que ele se apoia na confiança em organizações de segurança de porte considerável.

A última peça do quebra-cabeça é o que realmente acontece no envio de pacotes do gateway de uma máquina para o de outra. É evidente que todos os pares de gateways não podem estar fisicamente conectados por um cabo, como assumidos acima, portanto com certeza está acontecendo alguma coisa mais complexa. De fato, o cerne da In­ter­net é tão complexto que não poderia ser explicado em uma postagem como essa. Em vez disso, nós faremos um resumo simplificado. Se você quiser mergulhar mais a fundo nesse assunto, você deve começar aprendendo mais sobre redes de Nível 1 (em inglês Tier 1), o básico de roteamento (em inglês, routing) e pareamento (em inglês, peering) na In­ter­net e, se você ousar, o Bor­der Gate­way Pro­to­col).

O cerne da In­ter­net tem muitas camadas, ou níveis (em inglês, tiers). Provedores de acesso à Internet de menor porte geralmente estão no menor nível, o Tier 3. Provedores de Tier 3 conectam apenas uma pequena quantidade de usuários, e não conseguem prover conectividade a nenhuma máquina que não esteja na sua rede. Para conectar seus usuários à Internet, os provedores de Tier 3 fecham contrato com um provedor de Tier 2 para arrendar deles acesso à Internet. Quando um provedor de Tier 3 recebe um tráfego de dados que não é destinado a nenhum de seus usuários, ele simplesmente encaminha a seu provedor de nível 2.

Os provedores de Tier 2 costumam ser maiores e ter acordos de peering (pareamento) com outros provedores de Tier 2. Por exemplo, muitos provedores de Tier 2 quererão parear com a rede que hospeda a Netflix, para poder prover melhor conectividade para seus usuários. Peer­ing (o pareamento) significa apenas que alguns valores são pagos e se estabelece um link de rede dedicado entre dois provedores de Tier 2. Contudo, um provedor de Tier 2 também não tem conectividade direta a todas as máquinas na Internet; provedores de Tier 2 geralmente são restritos a regiões — por exemplo, têm clientes na parte continental dos Estados Unidos. Assim como os provedores de Tier 3 providers, todo o tráfego de um provedor de Tier 2 que não for destinado a um de seus próprios usuários precisar subir nessa cadeia. Como você já deve ter adivinhado, esse tráfego vai para um provedor de Tier 1, ao qual o de Tier 2 paga para acessar o resto da Internet.

Provedores de Tier 1 são entidades in­ter­na­cionais que proporcionam conectividade entre países e continentes, e estão conectados a um número de usuários (ou de provedores de Tier 2) muito grande. Todavia, mesmo os provedores de Tier 1 não têm conexões para com todas as máquinas que queiram estar disponíveis na In­ter­net. Ao invés disso, os provedores de Tier 1 estão todos pareados uns com os outros — e frequentemente fazem isso sem qualquer pagamento. Em termos de mercado, isso funciona porque todos os provedores de Tier 1 trazem a tiracolo um grande número de usuários e tráfego, e todos eles têm a pretensão de oferecer conectividade global — portanto, essa cooperação é do interesse de todos. Apesar disso, já ocorreram episódios de “guerras de pareamento”, nos quais os provedores de Tier 1 não conseguem entrar em acordo, e o resultado é quebrar a conexão entre diferentes partes da Internet. Quando isso acontece, multidões de usuários perdem a capacidade de se conectar a certas partes da In­ter­net.

Então, como isso se encaixa no e-mail de Alice para Bob? É que, quando os pacotes destinados ao gmail.com chegarem no gateway de Alice, ele os encaminhará para o provedor de acesso à Internet dela. Por sua vez, o provedor verificará se gmail.com é um consumidor do mesmo provedor de acesso: se for, ele encaminhará o pacote diretamente para o gateway de gmail.com (que foi o que nós assumimos no início). Porém, se gmail.com não for um assinante do mesmo provedor de acesso à Internet, os pacotes são encaminhados para o provedor de acesso Tier 2 do provedor de Alice. O provedor Tier 2 também vai conferir todas as suas redes clientes e redes pareadas, para verificar se gmail.com está a seu alcance, e se estiver, encaminhará os pacotes para lá. Se o gmail.com não estiver em nenhuma dessas redes, os pacotes são encaminhados mais para cima na rede, para um provedor de acesso de Tier 1. O provedor Tier 1, por sua vez, vai conferir qual de suas redes de Tier 1 pareadas é responsável pelo gmail.com, e encaminhará este pacote para lá. De lá, os pacotes vão descendo a pirâmide até chegarem ao provedor de acesso à Internet de gmail.com, o qual finalmente encaminhará os pacotes para o gateway de gmail.com.

Agora sim, nós cobrimos a maioria das tecnologias que permitem a comunicação na Internet. Embora tenhamos sido rápidos e coberto os assuntos em um nível superficial, espero que essa postagem tenha te dado uma percepção de quão vasta e complexa a Internet é, bem como de alguns dos problemas enfrentados por aqueles que trabalham para mantê-la saudável. Mais especificamente, espero que estas informações ajudem nos debates em curso e por vir sobre o futuro da Internet, para que possam ser tomadas decisões razoáveis, levando em consideração as tecnologias subjacentes.

Para saber o que há de errado nessa postagem, veja a discussão na Hacker News aqui.