Pular para o conteúdo principal

Domínio principal

Infraestrutura de Internet

Na faceta Domínio principal, Infraestrutura de Internet grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.

O ponto de retomada que não era um número de bytes: como o FTP aprendeu a continuar um arquivo

História

O ponto de retomada que não era um número de bytes: como o FTP aprendeu a continuar um arquivo

O primeiro FTP não perguntava apenas “quanto já passou?”. No meio da transferência, a conexão de controle podia trazer `110 MARK ssss = rrrr`: um estado que o remetente saberia reencontrar emparelhado com outro que o destinatário acabara de tornar durável. O fluxo de dados…

25 de ago. de 2026
A consulta vazia que listava todo mundo: como o Finger transformou presença humana em resposta de rede

História

A consulta vazia que listava todo mundo: como o Finger transformou presença humana em resposta de rede

Uma conexão TCP à porta 79 e uma linha composta apenas por CRLF eram suficientes. No NAME/FINGER de 1977, o vazio queria dizer: mostre todas as pessoas que usam este sistema agora. O texto podia revelar nome, localização do terminal, tempo ocioso e uma mensagem pessoal. A…

25 de ago. de 2026
A segunda conexão perguntou quem possuía a primeira: como o IDENT limitou a autoridade de um nome de usuário

História

A segunda conexão perguntou quem possuía a primeira: como o IDENT limitou a autoridade de um nome de usuário

O serviço remoto podia dizer “foi este usuário”. Também podia esconder o usuário, não encontrá-lo ou encerrar sem resposta. O vocabulário do IDENT já mostrava que a descoberta dependia de um sistema e de uma política fora do controle de quem perguntava. Por isso, a informação…

25 de ago. de 2026
O pacote de tempo que não trazia tempo: como o Kiss-o'-Death tornou a recusa do NTP acionável

História

O pacote de tempo que não trazia tempo: como o Kiss-o'-Death tornou a recusa do NTP acionável

O servidor precisava proteger sua capacidade antes que os clientes percebessem que havia um problema. Derrubar pacotes era possível, mas o silêncio não distinguia perda, política e excesso de consultas. A saída do NTP foi curiosa: responder no formato conhecido e, ao mesmo tempo…

25 de ago. de 2026
O arquivo não veio da porta 69: como o TFTP amarrou cada transferência aos seus pontos

História

O arquivo não veio da porta 69: como o TFTP amarrou cada transferência aos seus pontos

Em uma ROM de inicialização, cada estado custa espaço. O TFTP economizou ao manter apenas um bloco pendente e alguns números, mas esses números precisaram assumir responsabilidades severas: separar o balcão público da conversa aceita, reconhecer progresso e impedir que uma cópia…

25 de ago. de 2026
A pergunta que o SMTP aprendeu a não responder: como VRFY separou o aceite da mensagem da exposição do diretório

História

A pergunta que o SMTP aprendeu a não responder: como VRFY separou o aceite da mensagem da exposição do diretório

Em 1982, uma máquina remota podia perguntar `VRFY Smith` a um servidor SMTP e receber o nome completo de Fred Smith e sua caixa postal. O comando era valioso porque tornava um problema de entrega investigável. Era arriscado pela mesma razão: o serviço de transporte também se…

25 de ago. de 2026
O servidor devolveu o novo identificador: como o UIDPLUS tornou mutações IMAP verificáveis

História

O servidor devolveu o novo identificador: como o UIDPLUS tornou mutações IMAP verificáveis

Um armazenamento antigo conseguia aceitar a mensagem, mas não conseguia prometer que o UID sobreviveria à próxima sessão. Produzir um número mesmo assim seria fácil; fazer o cliente acreditar que ele era durável seria perigoso. O UIDPLUS ganhou força justamente por definir tanto…

25 de ago. de 2026
O comando que entregava a conexão: por que o SMTP substituiu TURN por ETRN

História

O comando que entregava a conexão: por que o SMTP substituiu TURN por ETRN

Um site ligava para o provedor e pedia que a linha se virasse. O servidor podia devolver pela mesma conexão o correio acumulado. A economia escondia uma cessão de autoridade: o interlocutor pronunciara um nome de host, mas não provaria o direito de receber suas mensagens.

25 de ago. de 2026
O prazo que o relé não podia reiniciar: como o SMTP DELIVERBY fez o tempo viajar

História

O prazo que o relé não podia reiniciar: como o SMTP DELIVERBY fez o tempo viajar

Quando o relógio chegava ao limite, a fila precisava escolher entre duas ações incompatíveis: parar definitivamente ou continuar e confessar o atraso. O DELIVERBY existiu para que essa escolha acompanhasse a mensagem.

24 de ago. de 2026
Deixar no servidor transformou o POP3 em um problema de memória: como UIDL atravessou a reconexão

História

Deixar no servidor transformou o POP3 em um problema de memória: como UIDL atravessou a reconexão

O POP3 era simples quando o cliente baixava a mensagem e a removia. A opção “deixar no servidor” preservou uma cópia remota, mas criou uma pergunta para a próxima conexão: quais itens desta lista mutável este cliente já guardou? UIDL respondeu com um identificador limitado ao…

24 de ago. de 2026
O código de erro que pediu ao bloqueador que se identificasse

História

O código de erro que pediu ao bloqueador que se identificasse

O HTTP 451 podia revelar um obstáculo legal e seu executor. Não podia obrigar transparência, validar a ordem nem enxergar bloqueios abaixo do HTTP.

24 de ago. de 2026
A última linha sem compressão: como o IMAP mudou cada byte que veio depois

História

A última linha sem compressão: como o IMAP mudou cada byte que veio depois

A resposta do servidor parecia rotineira: uma etiqueta, `OK`, poucas palavras e CRLF. No entanto, aquela seria a última linha lida pelas regras antigas. Depois da aceitação de COMPRESS, o próximo byte do servidor já pertenceria a um fluxo DEFLATE. Se cliente e servidor…

24 de ago. de 2026
A saudação que precisou ser repetida: como o STARTTLS reiniciou a confiança do SMTP

História

A saudação que precisou ser repetida: como o STARTTLS reiniciou a confiança do SMTP

O cliente já tinha dito seu nome em texto aberto. O servidor também já havia anunciado suas capacidades sem proteção. Colocar TLS no meio da mesma conexão não podia tornar confiável, retroativamente, aquilo que fora ouvido antes. A saída do SMTP foi apagar a memória do diálogo e…

24 de ago. de 2026
A credencial que não podia assinar a mensagem: como o SMTP AUTH delimitou a identidade de submissão

História

A credencial que não podia assinar a mensagem: como o SMTP AUTH delimitou a identidade de submissão

Uma credencial podia abrir o portão de submissão, mas não assinar a carta que passava por ele. O SMTP AUTH ganhou utilidade justamente por preservar essa diferença: o servidor reconhecia quem estabelecera aquela sessão e o que essa conta podia fazer ali, sem se declarar juiz do…

24 de ago. de 2026
Laurent Vanbever e a rede que deve ser testada enquanto muda

Acadêmicos

Laurent Vanbever e a rede que deve ser testada enquanto muda

O trabalho de Laurent Vanbever trata a configuração de redes como software executável, cujas falhas podem surgir antes, durante ou depois da implantação. Da migração segura e síntese de configurações à detecção de BGP em tempo de execução e às operações com eficiência energética…

24 de ago. de 2026
O endereço que não podia ser rebaixado: como o SMTPUTF8 tornou a rota parte do nome

História

O endereço que não podia ser rebaixado: como o SMTPUTF8 tornou a rota parte do nome

Um nome de exibição acentuado atravessava sistemas antigos porque envolvia um endereço ASCII. Um nome de caixa não ASCII era o próprio destino. O SMTPUTF8 obrigou cada retransmissor a provar que podia levar essa identidade sem inventar outra.

24 de ago. de 2026
Katerina Argyraki e a busca por prova no encaminhamento de pacotes

Acadêmicos

Katerina Argyraki e a busca por prova no encaminhamento de pacotes

A pesquisa de Katerina Argyraki acompanha um problema que se torna mais difícil à medida que as redes se tornam mais programáveis: um sistema de processamento de pacotes pode ser rápido e flexível, mas operadores e usuários muitas vezes têm pouca evidência de que ele se comportou…

24 de ago. de 2026
Dave Maltz e a pilha operacional por trás da rede do Azure

Criadores

Dave Maltz e a pilha operacional por trás da rede do Azure

A função de Dave Maltz na Microsoft é mais bem compreendida pela amplitude da organização que ele lidera. A Azure Networking abrange serviços voltados ao cliente, DNS, segurança, controle distribuído, descarregamento no host, software de switches, malhas de data centers, enlaces…

24 de ago. de 2026
O recibo que não podia prometer a entrega

História

O recibo que não podia prometer a entrega

O SMTP DSN transformou a devolução em evidência estruturada sem apagar seu limite: o remetente podia pedir um relatório, mas o relatório não podia garantir além do que o sistema observou.

24 de ago. de 2026
O oitavo bit precisou de permissão em cada salto: como o 8BITMIME mudou o SMTP

História

O oitavo bit precisou de permissão em cada salto: como o 8BITMIME mudou o SMTP

Uma mensagem podia descrever corretamente um caractere acentuado sem que todos os retransmissores soubessem conservar seus octetos. O 8BITMIME trocou essa aposta por uma promessa local: anunciar capacidade e guardar cada bit aceito.

24 de ago. de 2026