Como a Usenet serve arquivos sem ter sido criada para isso

Tem uma coisa curiosa na Usenet: ela não nasceu para ser um lugar de download de arquivos. A ideia original era muito mais simples e, de certo modo, mais elegante: distribuir mensagens. Textos. Discussões. Fóruns antes dos fóruns modernos. Gente postando em grupos, servidores trocando mensagens entre si, leitores NNTP baixando artigos e respostas. Era, basicamente, uma grande rede distribuída de conversas.

Só que, como quase sempre acontece na internet, alguém olhou para aquilo e pensou: “e se eu colocar arquivos aqui?”

E foi exatamente isso que aconteceu.

A Usenet não serve arquivos do mesmo jeito que um servidor HTTP, FTP ou um sistema de torrent. Ela não foi desenhada para dizer: “aqui está o arquivo video.mkv, pode baixar”. O que ela faz é armazenar e distribuir artigos. Então a solução encontrada foi transformar arquivos em artigos.

Parece gambiarra, e é. Mas é uma gambiarra muito bem pensada.

O arquivo não vai inteiro para a Usenet

Quando alguém posta um arquivo grande na Usenet, esse arquivo não é enviado como um bloco único. Seria inviável. Em vez disso, ele é dividido em várias partes menores. Cada parte é convertida para um formato que possa ser carregado dentro de uma mensagem NNTP, e essas mensagens são postadas em grupos específicos, normalmente os grupos alt.binaries.*.

Um arquivo poderia virar centenas ou milhares de mensagens.

O caminho, de forma bem simplificada, é este:

arquivo original
→ dividido em partes
→ codificado em texto/binário compatível
→ postado como vários artigos NNTP
→ armazenado por servidores Usenet
→ baixado por um cliente
→ decodificado
→ remontado
→ arquivo final

Ou seja: o servidor Usenet não está “servindo um arquivo” no sentido tradicional. Ele está servindo artigos. O cliente é que entende que aqueles artigos, juntos, formam um arquivo.

Essa diferença é importante.

yEnc: a mágica chata, mas essencial

No começo, era comum usar codificações como uuencode, mas depois o padrão de fato para binários na Usenet passou a ser o yEnc.

A função do yEnc é pegar dados binários e colocá-los em um formato adequado para trafegar dentro de mensagens da Usenet. Ele é mais eficiente que métodos antigos porque gera menos desperdício de espaço. Em redes onde você está lidando com milhões de mensagens e arquivos enormes, essa diferença importa muito.

Então, quando alguém posta um arquivo, ele é dividido em pedaços e cada pedaço é codificado com yEnc. Cada pedaço vira um artigo NNTP com um corpo que, para uma pessoa olhando cru, parece quase lixo. Mas para um cliente de Usenet, aquilo é uma parte perfeitamente válida de um arquivo.

O usuário comum não precisa ver esse processo. O programa de download faz tudo automaticamente.

Os grupos alt.binaries.*

A parte de arquivos da Usenet ficou associada principalmente aos grupos alt.binaries.*.

Alguns exemplos seriam:

alt.binaries.movies
alt.binaries.multimedia
alt.binaries.sounds
alt.binaries.pictures
alt.binaries.ebooks
alt.binaries.software

O nome já entrega a ideia: são grupos voltados para conteúdo binário, não apenas conversa textual.

Tecnicamente, um arquivo poderia ser postado em outros grupos também, desde que o servidor permitisse. Mas, na prática, os binários se concentraram nessas hierarquias. Isso também ajudava os servidores a decidirem o que aceitar, o que rejeitar e por quanto tempo manter cada tipo de conteúdo.

Porque texto é barato. Binário não.

Guardar discussões de texto por anos é relativamente tranquilo. Guardar arquivos grandes por anos exige muito disco, muita banda e muita paciência administrativa.

Por que aparecem tantos arquivos RAR?

Quem já mexeu com Usenet binária provavelmente viu pacotes cheios de arquivos assim:

arquivo.part001.rar
arquivo.part002.rar
arquivo.part003.rar
arquivo.part004.rar
...

Isso não é coincidência. O RAR virou comum porque ajuda a dividir arquivos grandes em volumes menores. Se algo falha, você não precisa necessariamente baixar tudo de novo. Além disso, esses volumes conversam bem com o fluxo da Usenet, onde tudo já está sendo quebrado em várias partes menores.

Então é comum o conteúdo original ser compactado e dividido em múltiplos arquivos RAR antes mesmo de ser codificado e postado como artigos.

No fim, existe uma camada em cima da outra:

arquivo original
→ volumes RAR
→ partes menores
→ artigos yEnc
→ mensagens NNTP

Parece exagerado, mas resolve problemas reais.

PAR2: o seguro contra peças faltando

A Usenet não garante que todos os artigos vão chegar intactos a todos os servidores. Um servidor pode não receber uma parte. Outro pode expirar artigos antigos. Outro pode ter corrupção. Outro pode simplesmente não carregar determinado grupo.

É aí que entram os arquivos PAR2.

Os arquivos .par2 são arquivos de recuperação. Eles usam dados de paridade para reconstruir partes ausentes ou danificadas. Em termos simples: eles são uma reserva matemática para consertar o download.

Você pode ter um conjunto assim:

arquivo.part001.rar
arquivo.part002.rar
arquivo.part003.rar
arquivo.part004.rar
arquivo.vol000+01.par2
arquivo.vol001+02.par2
arquivo.vol003+04.par2

Se uma ou duas partes estiverem faltando, o cliente pode usar os arquivos PAR2 para reparar o conjunto. Claro, isso tem limite. Se faltar coisa demais, não tem milagre.

Mas essa camada de reparo foi uma das razões pelas quais a Usenet continuou funcionando tão bem para arquivos grandes. Sem PAR2, baixar conteúdo grande seria muito mais frustrante.

NZB: o mapa do tesouro

Agora vem uma parte central: o NZB.

Imagine que um arquivo foi dividido em 3.000 artigos NNTP. Como o usuário encontraria todos esses artigos? Manualmente? Impossível.

O arquivo .nzb resolve isso. Ele é basicamente um índice, um manifesto. Ele lista os Message-ID dos artigos que precisam ser baixados para reconstruir determinado conteúdo.

O cliente lê o NZB e pensa:

“Certo, preciso buscar estes 3.000 artigos no servidor NNTP.”

Então ele conecta no servidor e começa a pedir artigo por artigo. Depois junta tudo, decodifica, repara se necessário e entrega o arquivo final.

Em resumo:

NZB = mapa dos artigos
NNTP = protocolo usado para buscar os artigos
servidor Usenet = lugar onde os artigos estão armazenados
cliente = programa que baixa, repara e remonta tudo

O NZB não contém o arquivo em si. Ele contém as instruções para encontrar as partes do arquivo dentro da Usenet.

É muito parecido com a diferença entre um .torrent e os dados reais do torrent. O .torrent não é o filme, o livro ou o programa. Ele só informa onde e como buscar os pedaços. O NZB cumpre um papel parecido, mas no ecossistema da Usenet.

O servidor sabe o que está entregando?

Na maioria das vezes, o servidor não precisa “entender” o arquivo final. Ele só armazena artigos.

Um cliente NNTP pede algo como:

ARTICLE <algum-message-id>

O servidor responde com o artigo correspondente. O corpo do artigo contém um pedaço codificado, geralmente em yEnc. Para o servidor, aquilo é apenas uma mensagem. Para o cliente, aquilo é parte de um arquivo maior.

Essa separação é o truque todo.

A inteligência está muito mais no lado do cliente e dos indexadores do que no servidor individual.

O papel dos provedores comerciais

Hoje, quando se fala em download pela Usenet, geralmente se fala em provedores comerciais. Eles vendem acesso a servidores com muita retenção, alta velocidade, múltiplas conexões e SSL/TLS.

A palavra-chave aqui é retenção.

Retenção é quanto tempo o provedor mantém os artigos disponíveis. Para grupos de texto, manter anos e anos é relativamente barato. Para grupos binários, manter anos de conteúdo exige uma infraestrutura absurda.

Quando um provedor diz que tem milhares de dias de retenção binária, ele está dizendo que mantém artigos antigos por muitos anos. Isso custa caro, porque a quantidade de dados em grupos binários é gigantesca.

É por isso que a Usenet binária moderna não é exatamente um hobby de garagem. Um servidor textual dá para rodar numa VPS pequena. Um servidor binário sério exige armazenamento massivo, banda pesada e política de abuso muito bem definida.

Usenet não é torrent

Muita gente compara Usenet com torrent, mas a lógica é bem diferente.

No BitTorrent, os usuários baixam pedaços uns dos outros. O arquivo existe enquanto houver seeders. Você participa de uma rede de pares.

Na Usenet, você baixa de um servidor. Você não precisa enviar pedaços para outros usuários. A disponibilidade depende da retenção do servidor/provedor, não de seeders.

Então, de forma bem direta:

Torrent:
- usuários compartilham entre si
- depende de seeders
- descentralização está nos peers
- você normalmente também envia dados

Usenet:
- você baixa de servidores NNTP
- depende da retenção do provedor
- descentralização está na federação histórica dos servidores
- você não precisa fazer upload para outros usuários

A Usenet acaba parecendo mais “baixar de um servidor premium”, embora por baixo exista toda essa estrutura antiga de artigos, grupos, propagação e retenção.

Dá para montar um servidor desses?

Tecnicamente, sim.

Na prática, é outra conversa.

Montar um servidor NNTP textual é perfeitamente viável. Você instala algo como INN, cria alguns grupos, controla acesso, configura TLS e usa com um leitor NNTP. Para estudo, comunidades pequenas ou projetos internos, é uma experiência muito legal.

Mas montar um servidor binário público ou federado é pesado. Você precisa lidar com:

muito armazenamento
muita banda
retenção curta ou caríssima
spam
abuso
conteúdo problemático
notificações legais
autenticação
peering
filas
monitoramento constante

Se você aceitar grupos como alt.binaries.*, o crescimento de dados pode ser brutal. Não é o tipo de coisa que se liga em uma VPS barata e esquece rodando.

O caminho inteligente, se a ideia for aprender, seria criar um grupo binário privado e pequeno, por exemplo:

local.binaries.test

Aí você pode postar arquivos pequenos, ver como yEnc funciona, gerar NZBs, baixar com um cliente e entender o fluxo inteiro sem se afogar em terabytes de dados e dor de cabeça jurídica.

O resumo da história

A Usenet serve arquivos sem realmente ter sido feita para servir arquivos.

Ela armazena artigos. O pessoal aprendeu a quebrar arquivos em pedaços, codificar esses pedaços, postar tudo como mensagens NNTP e depois reconstruir o arquivo do outro lado.

O processo completo fica assim:

arquivo original
→ compactação/divisão em RAR
→ codificação yEnc
→ postagem em artigos NNTP
→ armazenamento em servidores Usenet
→ indexação em NZB
→ download pelo cliente
→ reparo com PAR2
→ remontagem do arquivo final

É uma arquitetura velha, estranha e meio subterrânea, mas muito engenhosa. A Web moderna tenta esconder complexidade atrás de botões bonitos. A Usenet, não. Ela mostra as engrenagens. E talvez seja justamente isso que torne tudo tão interessante.