Este artigo é a resposta: um guia prático, do mais fácil ao mais complicado, pra você manter seus canais de comunicação de pé conforme o cerco for fechando. Porque o cerco está fechando, e convém entender o ritmo dele antes de escolher suas ferramentas.

O histórico: nada disso é novo

Quem se surpreendeu com o caso do Discord não estava prestando atenção. O Judiciário brasileiro bloqueia serviços de comunicação há mais de uma década, sempre por cima de milhões de usuários inocentes pra atingir meia dúzia de investigados:

• WhatsApp, 2015 e 2016: bloqueado três vezes por juízes de primeira instância, sempre porque a empresa não entregava conversas que, por desenho, ela não consegue ler.
• Telegram, 2022 e 2023: suspenso por dois dias por ordem de Moraes em março de 2022, e de novo por um juiz federal em 2023. O Migalhas tem a linha do tempo completa.
• X/Twitter, 2024: o marco. Suspensão nacional de 30 de agosto a 8 de outubro, 40 dias, por ordem monocrática. E aqui vem o detalhe que importa pra este guia: a decisão incluía multa de R$ 50 mil por dia pra qualquer pessoa física que acessasse o X por VPN, ordem pras lojas de app removerem aplicativos de VPN (recuou horas depois), e PF e Anatel produzindo relatórios sobre quem burlou o bloqueio pra subsidiar as multas.

Repare no que aconteceu ali: pela primeira vez, usar uma ferramenta neutra de privacidade virou, por si só, conduta punível no Brasil. Ninguém foi multado no fim das contas, mas a infraestrutura pra multar foi montada, testada e documentada. E em 2026 o Congresso votou e o presidente sancionou a majorante de pena pra crimes cometidos com VPN. O precedente do X deixou de ser exceção e virou repertório.

Pra guardar: no caso do X, o Estado brasileiro já tratou usuário de VPN como infrator, já tentou tirar VPN da loja de apps e já pediu relatório de quem burlou. Tudo documentado, em decisão judicial e relatório público.

O destino final: o modelo chinês

Não me resta dúvida de que gente muito bem posicionada no governo olha pra Grande Muralha da China com inveja, não com horror. E vale entender o que ela é, porque ela define o limite do jogo.

A Muralha vai muito além de bloquear sites. É inspeção profunda de pacotes (DPI) em escala nacional, rodando na espinha dorsal da internet do país: todo tráfego é classificado em tempo real, protocolos de VPN conhecidos são identificados pelo formato do aperto de mão e derrubados, o Tor é bloqueado por padrão, e só VPNs homologadas pelo Estado (ou seja, com porta dos fundos) operam legalmente. Cidadão comum pego usando VPN não autorizada toma multa. E mesmo quando o tráfego não pode ser lido, os metadados entregam o jogo: quem fala com quem, quando, por quanto tempo.

Por isso a resposta honesta pra pergunta “dá pra burlar uma Muralha dessas sem ser notado?” é: não, não pra um cidadão comum. Contra um firewall estatal desse nível, nenhuma ferramenta doméstica te torna invisível. No máximo te torna caro demais pra valer a pena perseguir em massa. Quem te vender invisibilidade total está mentindo.

A boa notícia é que o Brasil não está nem perto desse ponto. Censura raramente chega de uma vez: vem em degraus, e cada degrau tem uma defesa correspondente. O resto deste guia é essa escada, degrau por degrau. A lógica de tudo que vem a seguir é uma só: censura é uma questão de custo. Nosso trabalho é deixar o bloqueio caro, tecnicamente e politicamente, até que massificar ele seja impraticável.

Pra guardar: contra um firewall estatal completo, nenhuma ferramenta te torna invisível, só caro demais pra perseguir em massa. O jogo é subir a sua escada antes que o censor suba a dele.

Fase 1: VPN comercial, o mínimo que todo mundo deveria ter

Comece pelo óbvio. Uma VPN (rede privada virtual) cria um túnel criptografado entre o seu dispositivo e um servidor do provedor. Seu provedor de internet passa a ver só um fluxo cifrado indo pra um endereço só; os sites que você acessa veem o IP da VPN, não o seu. Eu explico a fundo, com a teoria de redes por baixo, no Akitando 126.

O que uma VPN faz: esconde seu tráfego do provedor de internet, troca seu IP de saída, te tira de bloqueios geográficos e de bloqueios judiciais por DNS/IP. O que ela não faz:

• Não te torna anônimo. O provedor da VPN vê todo o seu tráfego no lugar do seu ISP. Você não eliminou o vigia, só trocou de vigia.
• Não esconde sua identidade se você pagou com cartão. Assinatura com cartão de crédito amarra a conta de VPN ao seu CPF. Se a autoridade chegar com ordem judicial no provedor, seu nome está lá.
• Não protege o conteúdo depois do túnel. Da saída da VPN até o site final vale a criptografia normal da web (HTTPS). A VPN é um trecho do caminho, não o caminho inteiro.

Dito isso, pras fases iniciais do cerco ela resolve. Minhas recomendações, em ordem:

• ProtonVPN: Suíça, fora da jurisdição fácil, código aberto e auditado, política de não guardar registros testada em tribunal, tem plano gratuito decente e aceita pagamento até em dinheiro pelo correio.
• Mullvad: Suécia, a mais paranoica do mercado: não pede nem e-mail, sua conta é um número aleatório. Preço fixo de €5/mês, aceita dinheiro vivo num envelope e criptomoeda. É o mais próximo de “VPN sem identidade” que existe em produto comercial.
• NordVPN e similares funcionam tecnicamente, mas o dinheiro delas vai mais pra marketing do que pra postura de privacidade. Entre as grandes, fico com as duas acima.

O limite dessa fase é conhecido: os IPs de saída das VPNs famosas são públicos e catalogados. Uma ordem da ANPD ou da Anatel pros provedores nacionais bloquearem esses ranges é tecnicamente trivial, e o caso do X mostrou que remover o app da loja também está no cardápio. Quando (não se) isso acontecer, a VPN comercial morre em um dia. Por isso existe a Fase 2.

Pra guardar: VPN comercial é o cinto de segurança: use sempre, mas saiba que ela depende de três coisas fora do seu controle. O app continuar na loja, os IPs continuarem desbloqueados e o provedor continuar honesto.

Fase 2: VPN auto-hospedada, seu próprio túnel

A jogada aqui muda de figura: em vez de assinar um serviço com milhões de usuários e IPs catalogados, você aluga um servidorzinho barato fora do Brasil e monta a sua VPN pessoal. Não existe lista pública do seu IP pra censura baixar. Você é um usuário de um IP desconhecido, indistinguível de qualquer outro tráfego até ser analisado de perto.

Escolha do provedor (e por que não AWS, Azure ou Google Cloud). As nuvens grandes têm faixas de IP (ASNs) enormes, públicas e mapeadas. Bloquear elas inteiras é uma linha numa tabela de roteamento; o freio é só o dano colateral (muita empresa brasileira legítima está lá), e outros países já pagaram esse preço em situações de crise. Provedores menores diluem esse alvo. Opções que eu consideraria, do médio pro pequeno:

Uma máquina de US$ 3 a 5 por mês, com 1 GB de RAM, sobra pra uma VPN pessoal. Ressalva importante: pagar VPS com cartão deixa rastro igual à VPN comercial: seu nome está no cadastro do provedor, e o provedor pode ser compelido judicialmente. Alguns aceitam criptomoeda, o que reduz (não elimina) o rastro. Pra maioria das pessoas, nesta fase, o risco de cadastro é aceitável: você não está se escondendo de uma investigação, está saindo da mira de um bloqueio em massa.

Passo a passo: WireGuard com wg-easy

Vou usar o wg-easy, que empacota o WireGuard (o protocolo de VPN moderno, rápido e auditável) num container Docker com painel web e QR code pra configurar o celular em segundos.

1. Alugue o VPS. Ubuntu 24.04, a menor máquina disponível, região fora do Brasil (Amsterdã, Frankfurt e Helsinque são escolhas clássicas por jurisdição e latência aceitável).

2. Acesse e atualize:

ssh root@SEU_IP
apt update && apt upgrade -y

3. Instale o Docker:

curl -fsSL https://get.docker.com | sh

4. Gere o hash da senha do painel (o wg-easy não aceita senha em texto puro; anote a senha que você escolher):

docker run --rm -it ghcr.io/wg-easy/wg-easy wgpw 'SuaSenhaForteAqui'
# a saída é algo como: PASSWORD_HASH=$2b$12$abc...
# no comando abaixo, duplique cada cifrão: $ vira $$

5. Suba o container:

docker run -d \
  --name=wg-easy \
  -e WG_HOST=SEU_IP \
  -e PASSWORD_HASH='$$2b$$12$$abc...' \
  -v ~/.wg-easy:/etc/wireguard \
  -p 51820:51820/udp \
  -p 51821:51821/tcp \
  --cap-add=NET_ADMIN \
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
  --sysctl="net.ipv4.ip_forward=1" \
  --restart unless-stopped \
  ghcr.io/wg-easy/wg-easy

6. Libere o firewall. A porta 51820/UDP é o túnel em si. A 51821/TCP é o painel: não deixe o painel exposto pra internet. O jeito certo é abri-lo só via túnel SSH (ssh -L 51821:localhost:51821 root@SEU_IP e acessar localhost:51821 no navegador), ou liberar 51821 só pra criar seus clientes e fechar em seguida.

7. Crie os clientes. No painel, um clique gera um cliente com QR code. Aponte a câmera do app oficial do WireGuard (Android/iOS) e está pronto. No notebook, baixe o arquivo de configuração e importe no cliente WireGuard.

Pronto: todo o tráfego do seu dispositivo sai pelo seu servidor europeu. Seu provedor brasileiro vê apenas um fluxo cifrado pra um IP qualquer da Alemanha.

E na sua máquina, como usa?

O servidor é metade da história. No seu dispositivo, o ritual é esse:

No celular (Android/iOS): instale o app oficial do WireGuard pela loja (ou pelo F-Droid, no Android). Toque no "+", escolha “Escanear QR code” e aponte pro código que o painel do wg-easy mostrou. Aparece um “túnel” novo na lista: um toque no interruptor e você está dentro. No iOS, ative o “On-Demand” nas configurações do túnel pra ele religar sozinho quando trocar de rede (Wi-Fi pro 4G, por exemplo).

No notebook (Windows/macOS): baixe o cliente oficial do WireGuard pro seu sistema, clique em “Importar túnel de arquivo” e selecione o .conf que você baixou do painel. Um clique em “Ativar” e pronto. Detalhe importante: o cliente oficial tem a opção “Bloquear tráfego fora do túnel” (o kill switch): ligue ela. Se o túnel cair, sua internet para em vez de vazar pelo IP real.

No Linux: copie o .conf pra /etc/wireguard/wg0.conf e suba com sudo wg-quick up wg0 (e sudo systemctl enable wg-quick@wg0 pra subir no boot). Ou importe o arquivo direto no NetworkManager pela interface gráfica, se preferir clicar em vez de digitar.

Um .conf de cliente completo, pra referência, é assim:

[Interface]
PrivateKey = <chave privada DESTE dispositivo>
Address = 10.10.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <chave pública do servidor>
Endpoint = IP_DO_SERVIDOR:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Dois detalhes que valem ouro aqui. O PersistentKeepalive = 25 mantém o túnel vivo quando você está atrás de NAT (rede doméstica, 4G), evitando que a conexão morra em silêncio. E o AllowedIPs = 0.0.0.0/0 é o que faz todo o tráfego entrar no túnel; sem ele, só o tráfego pros IPs da própria VPN sai criptografado. (A linha DNS = funciona bem no Windows, macOS e celular; no Linux com systemd-resolved ela pode atrapalhar, como explico nos erros comuns mais abaixo.)

Conferindo se funcionou: com o túnel ativado, rode curl ifconfig.me no terminal (ou abra ipleak.net no navegador). Tem que aparecer o IP da sua VPS, não o da sua casa. Se a sua rede tiver IPv6, confira separadamente com curl -4 ifconfig.me e curl -6 ifconfig.me: os dois precisam mostrar o servidor. E visite dnsleaktest.com: o DNS também tem que sair pelo túnel. Se aparecer o servidor de DNS do seu provedor de internet, tem vazamento pra corrigir.

Manutenção mínima: ative unattended-upgrades pro sistema se atualizar sozinho, use chave SSH em vez de senha, e não instale mais nada nessa máquina. Superfície pequena, risco pequeno.

O jeito 2026 de fazer isso: deixe a IA configurar

Se você travou em algum passo, lembre que estamos em 2026: você não precisa mais dominar cada comando desse guia. Eu mesmo fui por esse caminho. Aluguei a VPS, entreguei o acesso SSH pro agente de IA e pedi a configuração completa; do outro lado, na minha máquina, ele importou o .conf, subiu o wg-quick, ativou no boot e conferiu vazamento no final. Hoje meu servidor é um playbook Ansible reproduzível (derrubou a VPS, sobe outra e roda um comando) e a config do meu notebook segue o mesmo padrão. Tudo em repositórios privados, e privados de propósito: configuração de VPN não é o tipo de coisa que eu quero que estranhos fiquem espiando.

O meu, rodando no meu Gitea: privado, versionado, e o servidor inteiro sobe de novo com um comando.

E se for pedir pra IA configurar, pula o “me instala uma VPN” genérico e entrega os requisitos de verdade. Algo assim:

Transforme esta VPS Ubuntu 24.04 limpa em um servidor WireGuard robusto,
de preferência via playbook Ansible idempotente (quero poder destruir a
VPS e recriar tudo rodando um comando). Requisitos:

- WireGuard gerenciado por wg-quick@wg0, chave do servidor gerada no
  próprio servidor (permissão 0600), sem painel web exposto
- Túnel dual-stack: IPv4 e IPv6 (subnet ULA fd00::/64 com NAT66), pra
  nenhum tráfego vazar por fora em redes com IPv6 nativo
- ufw negando tudo, exceto SSH e a porta UDP do WireGuard
- sshd somente com chave (sem senha), fail2ban no sshd,
  unattended-upgrades sem reboot automático
- Peers declarados como dados num arquivo de configuração: adicionar
  cliente = adicionar uma entrada e rodar o playbook de novo
- Gere os .conf dos clientes com PersistentKeepalive=25, AllowedIPs em
  full-tunnel e QR code via qrencode
- Ao final, imprima os comandos de verificação (curl -4/-6 ifconfig.me,
  wg show)

No fim, me entregue um README curto de operação: como adicionar cliente,
como atualizar, quando reiniciar.

A diferença entre um servidor “funcionando” e um servidor sólido está inteirinha nesses requisitos: dual-stack, firewall fechado, sshd sem senha, peers como dados, reprodutibilidade. A barreira técnica desse artigo inteiro, na prática, virou uma conversa.

Erros comuns (e como evitar)

Vejo sempre os mesmos tropeços quando alguém monta a primeira VPN própria. Todos evitáveis:

• Expor o painel do wg-easy pra internet. O erro clássico número um. O painel é a chave do cofre: aberto na 51821, qualquer scan de botnet acha em horas. Túnel SSH sempre, porta aberta nunca.
• Senha fraca ou reciclada no painel e no SSH. A VPN inteira protegida por 123mudar é pior que não ter VPN. E desligue o login SSH por senha de vez (PasswordAuthentication no no sshd_config) depois de configurar sua chave.
• Achar que está anônimo porque o IP é “seu”. A VPS está no seu nome, paga com o seu cartão. Ela te protege de bloqueio em massa, não de investigação com o seu nome nela. Nível de paranoia errado gera falsa sensação de segurança, que é pior que nenhuma.
• VPS no Brasil ou de empresa brasileira. Já vi gente montar “VPN de privacidade” em provedor nacional. Se a ordem judicial chega no mesmo país, você não saiu do alcance, só mudou de prateleira. Servidor fora, jurisdição fora.
• Distribuir acesso pra meio mundo. Cada pessoa extra é um dispositivo a mais, um padrão de uso a mais, uma boca a mais. Família próxima, ok; grupo de 40 contatos, não. Quanto mais gente no mesmo IP, mais rápido ele entra em alguma lista.
• Usar a mesma máquina pra outras coisas. Blog pessoal, bot de Telegram, seedbox: tudo isso aumenta a superfície de ataque e amarra identidades que você queria separadas. VPS da VPN é só da VPN.
• Confiar sem testar vazamento. Depois de configurar, teste: ipleak.net ou dnsleaktest.com com a VPN ligada. Se aparecer seu IP real ou o DNS do seu provedor, algo está errado, e você só descobre assim.
• Esquecer o IPv6. Esse pegou até eu: túnel só IPv4 numa rede com IPv6 nativo, e todo o tráfego v6 passa por fora da VPN, às claras, sem você perceber. Ou o túnel é dual-stack, ou metade do seu tráfego vaza. Teste com curl -6 ifconfig.me.
• A linha DNS = quebrando o cliente Linux. Em sistemas com systemd-resolved (Ubuntu, Fedora e afins), o wg-quick chama o openresolv pra escrever o DNS, o openresolv se recusa a mexer no /etc/resolv.conf que pertence ao systemd-resolved (erro de “signature mismatch”) e a interface inteira falha ao subir. Se o DNS do seu sistema já funciona bem, simplesmente remova a linha: as consultas vão pelo túnel de qualquer jeito.
• Perder a impressora, o NAS e a rede local. Com AllowedIPs = 0.0.0.0/0, até o tráfego pra dentro da sua própria casa tenta ir pelo túnel. A correção é uma regra de policy routing avaliada antes das regras do próprio WireGuard: PostUp = ip rule add to 192.168.0.0/16 lookup main priority 1000 (e o PostDown correspondente pra desfazer ao desligar).
• Encadear wg-quick down && up. O down retorna erro quando a interface já está desligada, e com && o up nunca executa. Rode o up sozinho.
• Instalar e abandonar. Servidor sem atualização por um ano é servidor com vulnerabilidade conhecida. E teste a conexão de tempos em tempos: o que funciona hoje pode estar fingerprintado amanhã.
• Não ter backup da configuração. O diretório ~/.wg-easy guarda tudo (chaves, clientes). Guarde uma cópia criptografada local. Se a VPS morrer ou for desligada pelo provedor, você sobe outra em dez minutos em vez de recomeçar do zero.

Pra guardar: uma VPS de US$ 5 fora do Brasil com WireGuard te tira de qualquer bloqueio em massa por IP catalogado. O preço é o cadastro no provedor: aceitável contra bloqueio, insuficiente contra investigação nominada.

O inimigo invisível: DPI

Até aqui, assumi que o censor bloqueia endereços. O próximo nível dele é bloquear formatos, e é aí que mora a inspeção profunda de pacotes (DPI).

Mesmo criptografado, um túnel de VPN tem assinatura. O aperto de mão inicial do WireGuard e do OpenVPN tem tamanhos de pacote, sequências e tempos característicos. O conteúdo é ilegível, mas o formato grita “eu sou uma VPN”. A China faz exatamente isso em escala nacional: não precisa ler seu tráfego, basta reconhecer o protocolo e derrubar a conexão.

Pra guardar: o censor não precisa ler o seu tráfego pra te bloquear. Basta reconhecer o formato do túnel. É por isso que a ofuscação existe.

A resposta técnica é ofuscação: fazer o túnel parecer outra coisa.

• AmneziaWG: um fork do WireGuard que injeta pacotes de lixo e embaralha os cabeçalhos até a assinatura sumir. Mesma base auditada do WireGuard, app gratuito pra todas as plataformas, e aponta pro mesmo tipo de VPS da Fase 2. Se você montou wg-easy, migrar pra Amnezia é o passo natural quando o DPI chegar.
• udp2raw: enfia o tráfego UDP do WireGuard dentro de pacotes TCP falsos, que parecem uma conexão comum.
• Shadowsocks: nasceu na China exatamente pra isso, um proxy criptografado desenhado pra não ter assinatura reconhecível.

Repare que ainda estamos falando de ferramentas gratuitas e de uma VPS de US$ 5. O custo sobe pro censor muito mais rápido do que pra você.

Fase 3: quando nem a sua VPS basta

Se o cenário degradar ao ponto de DPI nacional com bloqueio de protocolos, o jogo vira camuflagem pesada e redundância. As opções reais, em ordem de esforço:

Protocolos que se disfarçam de HTTPS comum. O estado da arte hoje é o VLESS com Reality (do projeto Xray-core): seu tráfego se apresenta como uma conexão TLS 1.3 legítima pra um site real e inocente, com certificado, aperto de mão e padrão de pacotes indistinguíveis de um acesso normal. Pra bloquear você, o censor teria que bloquear o site inocente junto, e o dano colateral é a defesa. Trojan-Go segue filosofia parecida. O Outline, da Jigsaw (Google), empacota Shadowsocks com um gerenciador amigável se você quiser distribuir acessos pra família e amigos.

Tor com pontes (bridges). O Tor puro é bloqueado por padrão nos países censurados, mas as pontes obfs4 e o Snowflake foram feitos sob medida pra esse cenário: Snowflake mascara sua entrada na rede Tor como uma videochamada comum de WebRTC. É lento, esquece streaming, mas é a rede mais difícil de extinguir que existe, mantida justamente pra jornalista e ativista em país hostil.

Redundância e rotação. Duas ou três VPS baratas em provedores diferentes, com failover automático. Se uma cair numa lista negra, você troca em minutos: instância nova, IP novo. Seu custo: mais US$ 5. O custo do censor: descobrir e bloquear de novo, toda vez.

Acessos alternativos. Starlink e outros links via satélite saem completamente da infraestrutura terrestre nacional. Enquanto não forem também regulados, são o último recurso físico. E pros casos extremos, a sneakernet de sempre: pendrive, disco externo, cópia física.

Higiene do lado do cliente, que vale em todas as fases:

• Kill switch ligado: se o túnel cai, o dispositivo corta a internet em vez de vazar pelo IP real.
• Proteção contra vazamento de DNS: suas consultas de DNS têm que ir pelo túnel, senão seu provedor continua vendo cada site que você visita.
• WebRTC desligado no navegador (ou use extensão): ele vaza seu IP real mesmo com VPN ativa.
• VPN ligada quando necessário, não sempre: padrão de uso 24/7 vira ele mesmo uma assinatura comportamental.

E as notas honestas de sempre: rodar seu próprio servidor pra uso pessoal é legal; usá-lo pra cometer crime, não. E a partir de 2026, com a nova majorante, “usando VPN” pesa na pena de qualquer crime que você cometeria de qualquer forma. Mantenha a superfície pequena, teste sua conectividade de dentro do Brasil com regularidade (o que funciona hoje pode ser fingerprint amanhã), tenha plano B (uma segunda VPS, um perfil de Tor com pontes) e mantenha cópias offline de tudo que for crítico.

Avaliação realista: nenhuma solução é permanente contra um censor determinado e bem financiado. O objetivo aqui é outro: encarecer o bloqueio em massa até ele virar mau negócio, técnica e politicamente. Um país que precisa derrubar metade da internet legítima pra calar meia dúzia de vozes tem um problema de relações públicas, não de tecnologia. É nesse custo que a gente aposta.

Pra guardar: a escada é VPN comercial, depois VPN própria, depois protocolo ofuscado, depois Tor com pontes, depois satélite. Cada degrau sobe pouco o seu custo e muito o do censor. Comece a subir antes de precisar.

Conclusão

O padrão brasileiro é o que eu chamei de censura por acumulado: nenhum degrau isolado parece o fim do mundo, e cada um vem com sua plaquinha de boa intenção. Mas a infraestrutura de bloqueio, uma vez montada, não tem dono moral: serve pro governo de hoje e pro de amanhã, contra o alvo de hoje e contra você.

A infraestrutura de comunicação livre funciona igualzinho: também se constrói por acumulado, também tijolo por tijolo. Uma VPN comercial configurada hoje. Uma VPS sua amanhã. Um protocolo ofuscado na gaveta pra quando precisar. Nada disso é paranoia. Funciona como backup: você não espera o disco falhar pra começar.

E se você quer acompanhar essa fronteira de perto, uma recomendação pessoal: siga o Ayub. É hoje a melhor fonte em português sobre infraestrutura de internet e censura estatal no Brasil. Foi ele quem soou o alarme sobre a criminalização de VPNs no PL 3066/2025 meses antes de virar lei. E nos últimos dias ele está cobrindo duas coisas que a grande imprensa mal tocou: a entrega de mais de R$ 100 bilhões em redes públicas, dutos e imóveis da União pras operadoras e pro BTG Pactual, e o aparato técnico da nova regulamentação do Marco Civil, que segundo ele deu à Anatel acesso remoto aos roteadores de borda dos provedores. Leitura obrigatória pra entender por onde vem o próximo degrau da escada.

A melhor hora de montar o seu túnel era antes de precisar dele. A segunda melhor é agora.

O Ayub comentou no X que há todos os indícios típicos de bloqueio nacional determinado pela Anatel contra api.github.com. No mesmo contexto, o tweet citado por ele mostrava api.github.com resolvendo para 4.228.31.149, mas sem rota funcionando. O autor dizia ter testado por VIVO, Claro e Oracle, e que só funcionava via VPN de Miami. Ou seja: não parece “meu Wi-Fi caiu”. Parece bloqueio no caminho.

Segundo o Ayub, esse tipo de coisa costuma acontecer em ondas de bloqueios, muitas vezes em reuniões de quarta-feira com grandes operadoras, dentro desse mecanismo brasileiro de bloquear endereços sob pretexto de combater pirataria. O problema é o efeito colateral: em vez de derrubar só o alvo, derruba pedaço legítimo de infraestrutura. Hoje foi a API do GitHub. Amanhã pode ser qualquer outra coisa que seu trabalho depende.

E sim, eu confirmei daqui.

Como saber se você foi afetado

Primeiro, teste se o site principal abre:

curl -4 -I --connect-timeout 8 --max-time 12 https://github.com/

Aqui funcionou. Depois teste a API:

curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Aqui deu:

curl: (28) Connection timed out after 8002 milliseconds

Agora veja pra qual IP seu sistema está resolvendo:

getent ahostsv4 api.github.com

No meu caso:

4.228.31.149    STREAM api.github.com
4.228.31.149    DGRAM
4.228.31.149    RAW

E o gh também depende dessa API. Então comandos como estes podem travar:

gh api rate_limit
gh pr list
gh issue list

Se você é desenvolvedor e de repente gh parou, seus scripts de release pararam, seu bot que lista PRs parou, ou aquele CLI que consulta issues começou a ficar pendurado, pode ser isso. Não é bug seu. É a sua rota até api.github.com sendo jogada no buraco.

Primeiro tente DNS 9.9.9.9

Algumas pessoas comentaram que trocar o DNS para Quad9, 9.9.9.9, poderia contornar. Faz sentido testar, porque alguns bloqueios são feitos via DNS: o provedor responde um IP errado, NXDOMAIN, ou manda para um buraco. Se o problema for só o DNS do seu provedor, trocar de DNS resolve.

Teste sem mudar nada no sistema:

dig @9.9.9.9 +short api.github.com A

No meu caso, não resolveu. O Quad9 também retornou:

4.228.31.149

E forçar esse IP no curl continuou dando timeout:

curl -4 -I --connect-timeout 8 --max-time 12 \
  --resolve api.github.com:443:4.228.31.149 \
  https://api.github.com/

Resultado:

curl: (28) Connection timed out after 8002 milliseconds

Então, no meu link, 9.9.9.9 não resolveu. Mas teste no seu. Se o seu provedor está apenas envenenando DNS, pode funcionar.

No Arch com NetworkManager, seria algo assim:

sudo pacman -S bind-tools curl

nmcli con show --active
sudo nmcli con mod "NOME DA SUA CONEXÃO" \
  ipv4.ignore-auto-dns yes \
  ipv4.dns "9.9.9.9 149.112.112.112"
sudo nmcli con down "NOME DA SUA CONEXÃO"
sudo nmcli con up "NOME DA SUA CONEXÃO"

No Ubuntu, a ideia é a mesma. Instale as ferramentas e ajuste pelo NetworkManager:

sudo apt install dnsutils curl
nmcli con show --active

Ou use a tela de rede do GNOME/KDE e coloque DNS manual 9.9.9.9 e 149.112.112.112 na conexão. Depois desconecte e conecte de novo.

Teste de novo:

dig +short api.github.com A
curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Se funcionar, ótimo. Você terminou aqui.

Se continuar dando timeout, o bloqueio não está só no DNS. Aí precisa rotear a conexão por outro caminho.

Por que eu não gosto da gambiarra de IP fixo

Outra sugestão que vi foi colocar IPs manualmente no DNS local, tipo Pi-hole, Unbound, /etc/hosts, dnsmasq, essas coisas. Exemplo: “resolve api.github.com pra tal IP que funciona”.

Isso pode funcionar por algumas horas. Eu não gosto.

GitHub é infraestrutura grande. IP muda. Rota muda. Balanceamento muda. Região muda. O IP que funciona pra uma pessoa em Miami pode ser ruim pra você em São Paulo. O IP que funciona hoje pode cair amanhã. E se o bloqueio for por rota blackhole no provedor, trocar DNS para outro IP pode só trocar um buraco por outro.

Pi-hole é ótimo pra rede doméstica. Unbound é ótimo. /etc/hosts salva em emergência. Mas fixar IP de serviço grande como GitHub é pedir pra esquecer uma gambiarra invisível e perder duas horas daqui a um mês tentando entender por que só a sua máquina não funciona.

Use DNS alternativo como teste. Use IP fixo só como curativo temporário e documente onde mexeu.

Fallback: proxy SOCKS só para ferramentas do GitHub

Minha solução foi fazer o mínimo invasivo: um wrapper que sobe um SOCKS local via Tor e executa só o comando que eu quero por ele. Não roteia o sistema inteiro. Não mexe no navegador. Não altera pacote, Steam, banco, nada. Só gh, ou qualquer ferramenta que eu chamar explicitamente.

No meu caso, o wrapper está em ~/.config/zsh/bin/github-proxy e o alias em ~/.config/zsh/aliases faz:

alias gh='$HOME/.config/zsh/bin/github-proxy gh'

O wrapper é este:

#!/bin/bash
set -euo pipefail

proxy_host="127.0.0.1"
proxy_port="9050"
tor_dir="${XDG_RUNTIME_DIR:-/tmp}/github-proxy-tor"
tor_rc="$tor_dir/torrc"
tor_log="$tor_dir/tor.log"

if [[ $# -eq 0 ]]; then
  echo "usage: github-proxy <command> [args...]" >&2
  exit 2
fi

if ! ss -ltn "sport = :$proxy_port" | grep -q "$proxy_host:$proxy_port"; then
  mkdir -p "$tor_dir"
  : >"$tor_rc"
  tor -f "$tor_rc" --SocksPort "$proxy_host:$proxy_port" --DataDirectory "$tor_dir/data" >"$tor_log" 2>&1 &

  for _ in {1..60}; do
    if grep -q 'Bootstrapped 100%' "$tor_log"; then
      break
    fi
    if ! kill -0 "$!" 2>/dev/null; then
      echo "github-proxy: tor exited before bootstrap; see $tor_log" >&2
      exit 1
    fi
    sleep 1
  done

  if ! grep -q 'Bootstrapped 100%' "$tor_log"; then
    echo "github-proxy: timed out waiting for tor bootstrap; see $tor_log" >&2
    exit 1
  fi
fi

export HTTPS_PROXY="socks5h://$proxy_host:$proxy_port"
export HTTP_PROXY="socks5h://$proxy_host:$proxy_port"
export ALL_PROXY="socks5h://$proxy_host:$proxy_port"

exec "$@"

Repare no socks5h. Esse h importa. Ele faz a resolução DNS pelo proxy, não pela sua rede local. Se você usa socks5:// normal, dependendo da biblioteca, o DNS ainda pode acontecer localmente antes de passar pelo proxy. Com socks5h://, a ideia é: “leva o hostname até o outro lado e resolve lá”.

Instalando no Arch

No Arch:

sudo pacman -S tor github-cli iproute2
mkdir -p ~/.local/bin

Crie o script:

nano ~/.local/bin/github-proxy

Cole o wrapper acima e dê permissão:

chmod +x ~/.local/bin/github-proxy

Teste direto:

~/.local/bin/github-proxy gh api rate_limit --jq .resources.core.limit

Conta autenticada normalmente retorna:

5000

Foi o que aconteceu aqui. Direto dava timeout. Pelo wrapper, gh api rate_limit --jq .resources.core.limit retornou 5000.

Agora adicione um alias no seu shell.

ZSH:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.zshrc
source ~/.zshrc

Bash:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.bashrc
source ~/.bashrc

Teste:

gh api rate_limit --jq .resources.core.limit
gh pr list

Ubuntu

No Ubuntu, o pacote do Tor é fácil:

sudo apt update
sudo apt install tor iproute2 curl

Para o GitHub CLI, se o pacote gh estiver disponível na sua versão:

sudo apt install gh

Se não estiver, siga a instalação oficial do GitHub CLI para Ubuntu/Debian. O resto é igual: crie ~/.local/bin/github-proxy, dê chmod +x, e coloque o alias no .bashrc ou .zshrc.

Alternativas melhores que Tor

Tor funcionou e é conveniente, mas não é a única opção. Às vezes é lento. Às vezes algum serviço encrenca com saída Tor. Para gh api e listar PR, tudo bem. Para uso pesado, talvez você queira algo mais previsível.

Opções razoáveis:

• VPN normal: Proton, Mullvad, IVPN, WireGuard próprio. Roteia tudo ou usa split tunneling se você souber configurar.
• Tailscale com exit node fora do Brasil: limpo, se você tiver uma máquina confiável fora ou uma VPS.
• SSH SOCKS para uma VPS: ssh -N -D 127.0.0.1:9050 usuario@seu-vps. Depois use o mesmo HTTPS_PROXY=socks5h://127.0.0.1:9050.
• Proxy corporativo: se sua empresa tem saída fora do Brasil, configure só as ferramentas que precisam.

O cuidado aqui é não sair mexendo em tudo ao mesmo tempo. Primeiro prove que api.github.com direto falha. Depois prove que via outro caminho funciona. Só então automatize.

Ajustando ferramentas próprias: ghpending

Esse bloqueio me pegou também num utilitário meu: ghpending. Eu já falei dele no post “Criei um CLI pra Checar Pendências no Meu GitHub: ghpending”. Ele lista issues e pull requests abertos nos meus repositórios, pra eu saber onde tem gente esperando resposta.

O problema é óbvio: ele usa a API do GitHub. Se api.github.com cai no buraco, ele cai junto.

Então adicionei fallback de proxy. O ghpending agora lê GITHUB_TOKEN como antes, mas também tenta usar proxy SOCKS nesta ordem:

1. GHPENDING_GITHUB_PROXY, se você quiser forçar um proxy específico.
2. HTTPS_PROXY, https_proxy, ALL_PROXY ou all_proxy, se forem socks5:// ou socks5h://.
3. Um SOCKS local em 127.0.0.1:9050, se estiver escutando.
4. Se nada disso existir, tenta direto.

No README ficou assim:

GITHUB_TOKEN=$(gh auth token) ghpending

E, para proxy:

GHPENDING_GITHUB_PROXY=socks5h://127.0.0.1:9050 ghpending

Ou simplesmente rode pelo wrapper:

~/.local/bin/github-proxy ghpending

Meu wrapper sobe Tor em 127.0.0.1:9050; o ghpending detecta esse proxy e usa para chamadas à API. Se você não está bloqueado, ele continua funcionando direto. Se você está bloqueado, ele tem um caminho de fuga.

Isso é o tipo de fallback que agora todo dev brasileiro deveria considerar para ferramenta que depende de API estrangeira. Não porque é bonito. Porque a internet brasileira está ficando imprevisível.

O problema político

No fim da thread, o Ayub lembrou que, por causa desses bloqueios colaterais sigilosos, já haveria cerca de 250 milhões de endereços bloqueados na internet brasileira. Ele também linkou uma apresentação sobre o panorama dos bloqueios no Brasil. Em outro tweet do mesmo fio, ele diz que autoridades defendem sigilo como única alternativa para combater crimes.

Eu não compro essa desculpa.

Bloqueio sigiloso de infraestrutura crítica, sem transparência, sem contraditório público, sem lista auditável, sem explicação de escopo, é censura operacional. Na minha leitura, é ilegal justamente por fugir do rito público e auditável que deveria existir quando o Estado manda quebrar acesso à internet. Pode ter começado com pirataria de TV box. Pode ter discurso bonito. Mas o mecanismo está aí: alguém aperta botão, operadoras aplicam bloqueio, usuários legítimos descobrem só quando ferramenta de trabalho para.

Hoje, o efeito colateral bateu em desenvolvedor honesto tentando trabalhar com GitHub. Amanhã bate em pacote de Linux, registry de container, CDN, API de pagamento, serviço de autenticação. Aí todo mundo corre pra VPN, Tor, proxy, DNS alternativo, /etc/hosts, Pi-hole. Parabéns: estamos recriando, aos poucos, o manual de sobrevivência de uma internet censurada.

Não precisa exagerar na metáfora. Ainda não somos a China. Mas o cheiro é o mesmo: bloqueio centralizado, opaco, com dano colateral, e usuário comum tendo que aprender bypass pra trabalhar.

Se você foi afetado, documente. Rode os comandos. Salve outputs. Abra issue no seu provedor. Reclame com dados. Compartilhe workaround, mas não normalize. Bypass é curativo. O problema real é um Estado que se dá o poder de quebrar pedaços da internet em silêncio.

E se você só queria rodar gh pr list pra revisar um pull request: bem-vindo à infraestrutura brasileira de 2026.

Eu tenho um bom Synology DS1821+ que também tem suporte pra rodar Docker, mas eu prefiro deixar o NAS somente pra funções de NAS e não arriscar comprometer meus dados com outras coisas rodando nele. Não é um “problema” ter um servidor só que faz tudo, mas já que eu posso, prefiro separar as coisas.

Esse Intel NUC roda um Ubuntu Server LTS headless (sem desktop manager), que eu uso só acessando via SSH (como expliquei no post anterior sobre SSH). Nele rodo coisas como Portainer, Plex, Sonarr, Bazarr, qBitTorrent e muito mais.

Da forma como está eu só adicionei uma entrada no /etc/hosts do meu desktop assim:

192.168.0.100 synology.lan
192.168.0.200 plex.lan

A partir de agora todos os meus domínios e endereços IPs vão ser falsos, obviamente.

Enfim, dessa forma eu posso abrir meu navegador e entrar em http://plex.lan:32400 pra acessar meu Plex, por exemplo. Mas isso tem três desvantagens:

1. Só no meu desktop consigo usar esses hostnames, do meu notebook precisaria editar o arquivo hosts também. Além disso preciso saber as portas pra cada container.
2. Não tenho SSL pra nada, então toda autenticação vai em texto aberto. Não é um problema muito grande porque o tráfego é somente interno na minha LAN local. Não tenho acessado de fora de casa.
3. Se por acaso eu quiser acessar de fora, nada disso funciona.

Existem dezenas de formas de resolver esse problema, soluções que envolvem WireGuard, ou soluções comerciais como TailScale ou coisas assim. Mas tem uma solução razoavelmente simples que resolve todos os problemas de uma só vez: Cloudflare Tunnels.

A idéia é criar túneis seguros via Cloudflare, pra ter acesso aos meus serviços na minha LAN interna SEM precisar expor portas pra fora do meu roteador ou coisas assim. Minha rede permanece isolada e inalterada.

1. Registrando Domínio

A primeira recomendação é registrar um domínio de verdade. Fazendo isso é possível ter certificados SSL de verdade que a própria Cloudflare gerencia e renova automaticamente.

Eu tenho alguns domínios registrados e não vou revelar qual uso pro meu Home Server. Vou usar esse vazio fabioakita.dev como exemplo só pra este post.

Domínios são baratos, faixa de USD 12 por ano, dependendo do nome que escolher. Escolha um curto e fácil de digitar.

2. Instalando Cloudflared

Com o domínio criado, agora precisamos instalar o serviço cloudflared no Home Server. Ele é quem vai se conectar aos servidores da Cloudflare a abrir o túnel pra dentro do meu servidor local. Clique no link pra instruções de como instalar, mas num Ubuntu Server 22.04 é assim:

# Add cloudflare gpg key
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

# Add this repo to your apt repositories
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared jammy main' | sudo tee /etc/apt/sources.list.d/cloudflared.list

# install cloudflared
sudo apt-get update && sudo apt-get install cloudflared

Agora precisamos fazer login:

# login
sudo cloudflared tunnel login

# adicione tunel homelab
sudo cloudflared tunnel create homelab

# crie diretório pra configurações
sudo mkdir -p /etc/cloudflared

Use as mesmas credenciais que usa pra logar no website da Cloudflare. Se tudo der certo, no final ele vai criar um arquivo em /root/.cloudflared/xxxxx-yyyy-zzzz...json, são suas credenciais, assim como uma chave privada SSH, não jogue num pendrive ou num drive de cloud da vida. Guarde muito bem. Vamos mover:

sudo mv /root/.cloudflared/*.json /etc/cloudflared
sudo chmod 600 /etc/cloudflared/*.json

Finalmente, precisamos criar um arquivo de configurações /etc/cloudflared/config.yml com todos os hostnames que queremos pra cada um dos containers, apontando pras portas corretas. Vou dar um trecho de exemplo da minha config, modificado com IPs falsos e o domínio falso:

# /etc/cloudflared/config.yml
tunnel: homelab
credentials-file: /etc/cloudflared/xxxx-yyyy-....json
ingress:
  ...
  - hostname: plex.fabioakita.dev
    service: http://192.168.0.254:32400
    originRequest:
      httpHostHeader: plex.fabioakita.dev
  - hostname: immich.fabioakita.dev
    service: http://192.168.0.200:2283
    originRequest:
      httpHostHeader: immich.fabioakita.dev
  - hostname: overseer.fabioakita.dev
    service: http://192.168.0.200:5055
    originRequest:
      httpHostHeader: overseer.fabioakita.dev
  - hostname: syncthing.fabioakita.dev
    service: http://192.168.0.200:8384
    originRequest:
      httpHostHeader: qbittorrent.fabioakita.dev
  - hostname: radarr.fabioakita.dev
    service: http://192.168.0.200:7878
    originRequest:
      httpHostHeader: radarr.fabioakita.dev
  - hostname: sonarr.fabioakita.dev
    service: http://192.168.0.200:8989
    originRequest:
      httpHostHeader: sonarr.fabioakita.dev
  - hostname: bazarr.fabioakita.dev
    service: http://192.168.0.200:6767
    originRequest:
      httpHostHeader: bazarr.fabioakita.dev
  - hostname: prowlarr.fabioakita.dev
    service: http://192.168.0.200:9696
    originRequest:
      httpHostHeader: prowlarr.fabioakita.dev
  - hostname: portainer.fabioakita.dev
    service: http://192.168.0.200:9000
    originRequest:
      httpHostHeader: portainer.fabioakita.dev
  - hostname: grafana.fabioakita.dev
    service: http://192.168.0.200:3001
    originRequest:
      httpHostHeader: grafana.fabioakita.dev
  - service: http_status:404 # this has to be the LAST ONE

Como podem ver, é um arquivo extremamente simples. Acho que qualquer um consegue entender o que isso faz. Modifique pras suas próprias necessidades.

Depois de salvar o arquivo e voltar pra linha de comando, precisa manualmente rodar este comando pra cada hostname:

sudo cloudflared tunnel route dns homelab plex.fabioakita.dev

Mas isso é muito trabalhoso, com esse tanto de hostname, achei mais fácil criar um script /etc/cloudflared/add.sh assim:

# run only once
TUN=homelab
CONF=/etc/cloudflared/config.yml
grep -E '^[[:space:]]*-[[:space:]]*hostname:' "$CONF" \
| awk '{print $3}' | tr -d '"' | tr -d "'" \
| while read -r h; do
    echo "adding $h"
    sudo cloudflared tunnel route dns "$TUN" "$h"
  done

Agora é só rodar: sudo sh /etc/cloudflared/add.sh, só uma vez! Então garanta que seu arquivo de config está correto antes!

Finalmente, podemos configurar o serviço pra reiniciar sozinho em todo boot:

sudo cloudflared --config /etc/cloudflared/config.yml service install

sudo systemctl enable --now cloudflared

3. Acessando seus serviços via túnel

Se nada deu errado, já acabou! Já pode ir direto pro seu navegador e testar:

Olha só que beleza. Note na barra de URL que digitei https://immich.fabioakita.dev e acessou normalmente. Aliás, se não conhecia o Immich funciona idêntico a um Google Photos, só que sob seu total controle! Tem app pra smartphone e sincroniza bonitinho.

Mais importante, note que está com HTTPS que foi provido pelo Cloudflare pro meu domínio inteiro. Quando fizer login, vai ser via túnel encriptado. E mais do que isso: mesmo se eu estiver via 5G, fora de casa, no meu celular, vou poder acessar minhas fotos usando esse endereço!

Do meu celular vai abrir um túnel seguro pra Cloudflare, e aquele serviço cloudflared no meu home server está também com um túnel seguro aberto pra Cloudflare, daí ele faz uma ponte entre os dois túneis e pronto! Tenho acesso remoto sem abrir meu servidor direto pra internet! O melhor dos dois mundos!

Não se esqueça de configurar todos os seus serviços com senhas fortes (eu gero elas via Bitwarden, mas qualquer um server 1Password, o que for):

4. Bridge pra vlans

Eu não lembro exatamente o motivo, mas só meu container de Plex deu mais trabalho. Isso porque ele usa uma VLAN diferente das demais. Novamente, não lembro porque fiz isso na época, mas está assim:

  plex:
    #image: plexinc/pms-docker:latest
    image: linuxserver/plex:latest
    restart: unless-stopped
    environment:
      - TZ=America/Sao_Paulo
      - PUID=1026
      - PGID=1026
      - VA_DRIVER=IHD
      - PLEX_HW_TRANS_MAX=16
      - PLEX_MEDIA_SERVER_OPTS=--network-host
    volumes:
      - /config:/config
      - /data:/data
      - /transcode:/transcode
      - /Videos:/media
    devices:
      - /dev/dri:/dev/dri
      - /dev/bus/usb:/dev/bus/usb
    healthcheck:
      test: curl --connect-timeout 15 --silent --show-error --fail http://localhost:32400/identity
      interval: 1m00s
      timeout: 15s
      retries: 3
      start_period: 1m00s
    mem_limit: 4g
    cpus: 5.0
    networks:
      plex_macvlan:
        ipv4_address: 192.168.0.254
        mac_address: "xx:xx:xx:xx:xx:xx"

networks:
  plex_macvlan:
    external: true
    name: plex_macvlan

Por causa disso o cloudflared não consegue rotear pra esse container. A forma de consertar isso é criando uma ponte dessa vlan pra minha ethernet.

sudo ip link add macvlan0 link enp3s0 type macvlan mode bridge
sudo ip addr add 192.168.0.200/24 dev macvlan0   # free IP in your LAN
sudo ip link set macvlan0 up

Obviamente, trocar enp3s0 pelo nome correto da sua ethernet. Cheque com ip addr ou ip link por exemplo. Só de rodar os comandos acima, se eu for no navegador e digitar https://plex.fabioakita.dev já deve conseguir acessar. Pra tornar isso permanente, precisamos do systemd:

# /etc/systemd/network/80-macvlan0.netdev
[NetDev]
Name=macvlan0
Kind=macvlan

[MACVLAN]
Mode=bridge

# /etc/systemd/network/80-macvlan0.network
[Match]
Name=macvlan0

[Network]
Address=192.168.0.200/24
Gateway=192.168.0.1
DNS=192.168.0.1

E agora, só reiniciar os serviços:

sudo systemctl restart systemd-networkd
ip addr show macvlan0

O “correto” seria meu Plex estar configurado com network_mode: hostmas, de novo, não lembro porque não estava e não estava a fim de desconfigurar tudo pra descobrir. Caso alguém tenha configurações similares, é assim que bypassa.

Falando em Plex, eu já tinha ouvido falar que tem que tomar cuidado com streaming via cloudflared, não sei se tem limites ou custos extras. Achei este artigo que fala mais sobre isso mas não parei pra ver a fundo. A única coisa que fiz extra, no dashboard da Cloudflare, foi adicionar uma regra pra não fazer CACHING do subdomínio plex, pra evitar custos adicionais.

Conclusão

Como podem ver, é extremamente fácil ter um home server, isolar tudo com Docker e depois expor seus containers via túnel seguro pra acessar remotamente. Nada disso significa segurança instantânea. Garanta que seus containers sempre estejam atualizados usando serviços como Watchtower, garanta que cada serviço tenha senhas fortes aleatórias e únicas - não use a mesma senha pra tudo. Garanta que seu firewall esteja bem configurado e ativo, mesmo numa LAN.

Muitos routers de Wi-Fi modernos permitem criar uma VLAN separada pra Wi-Fi pra visitas. Assim eles podem usar seu Wi-Fi mas não enxergam seus computadores, que vão estar logicamente isoladas em outra VLAN. Cheque a documentação do seu roteador. Eu uso uma TP-Link BE1900 Tri-Band Wi-Fi 7, mas pra maioria das pessoas ela é cara demais e excessiva demais. Pesquise bem. E não adianta ficar me perguntando de outros modelos: eu não testei todos pra saber as diferenças.

Se você viu nomes como Radarr, Sonarr e não sabe o que isso significa, leia o Wiki do Servarr que consolida todas as documentações desses serviços num único lugar. É a infraestrutura que permite você ter sua própria “Netflix Particular”.

Também não perguntem porque eu uso Plex e não Jellyfin. É escolha pessoal, escolha o que é melhor pra você. Eu gosto de Plex, já usei Jellyfin, e não pretendo mudar.

Eu odeio a idéia de pagar assinaturas pra tudo e não ter propriedade de nada. Acho dinheiro jogado fora. Eu prefiro TER as minhas próprias coisas sob MEU CONTROLE. É mais caro, é mais trabalhoso. Conveniência demais significa que você não tem controle de nada e sempre depende dos outros.

Eu odeio depender dos outros.

Todos que me acompanham, em particular no Instagram, sabem da minha saga com NAS. Em particular meu novo Synology DS1821+ com mais de 100TB (4 HDs de 12TB e 4 HDs de 20TB e já tenho 4 outros HDs de 20TB pra atualizar no futuro quando precisar). Uso pra muita coisa, em particular meu Netflix Pessoal que expliquei nesse outro post como eu configurei com Docker.

Nos destaques e post sobre isso no Insta já discuti detalhes desse NAS mas resumindo:

• prefiro Synology porque no fundo ele é um Linux com filesystem BTRFS (que eu gosto), que é quase tão flexível mas mais fácil de usar do que ZFS. E sim, eu sei que existe unraid, TrueNAS e outros. Mas eu acho que o Synology DSM é bem competente (tem versão open source se quiserem), e ele faz tudo que eu preciso.
• prefiro Plex do que Emby ou Jellyfin. Já testei eles, mas o suporte do Plex a apps de TV e celular eu acho muito melhor, acho o player mais estável, também acho que as funcionalidades de organização dele são mais robustas.
• porque não usar só Cloud? Primeiro porque é lento. Minha fibra é só 1Gbps e upload é metade disso. Segundo porque minha rede interna é ultra veloz (10Gbps) e muito melhor. Terceiro porque nada no “Cloud” tem garantia de nada, podem te bloquear, podem te invadir, podem apagar por engano. Quarto, tudo que é meu, eu gosto sendo realmente meu, no meu alcance, no meu total controle, sem ninguém pra fazer m&rda com minha propriedade. Custa mais caro, é uma escolha. Eu literalmente tenho mais filmes e séries melhores que a Netflix com conteúdo que você não vai mais achar fácil em nenhum streaming, por exemplo.

Na verdade, eu confio tão pouco em “cloud” que eu uso mas faço uma cópia de tudo no meu NAS local usando o app Cloud Sync que tem na loja da Synology:

“Ah, mas e se der pau irreversível no seu NAS e você perder TUDO!!??”

Nenhum backup é completo se não segue o Mantra 3-2-1, lembram??

• 3 cópias, 2 mídias, 1 off-site

Eu tenho algumas coisas gravadas em Millenial Discs (mdiscs, que são como Blu-Rays mas de material inorgânico que nunca estraga). E eu faço cópias das coisas mais importantes do meu NAS pra Amazon Glacier usando o app “Glacier Backup” que também tem na loja da Synology.

Glacier é como S3 só que bem mais barato porque ele não tem acesso fácil nem transferência rápida. É feito pra backups mesmo, que você grava uma vez e quase nunca acessa de novo. ENCRIPTADO, lógico.

Notem como eu confio tão pouco em cloud, como dropbox, que eu faço uma cópia no meu NAS e mando pra outro cloud. Tem coisas com múltiplas cópias mesmo. Eu não confio no serviço de ninguém, sempre algum humano vai cometer um erro catastrófico algum dia, é só questão de tempo.

Ah sim, e eu baixo mesmo muita coisa de torrent e eu me considero Power User e sei o que é malware/virus do que não é e sei como funcionam. Mas eu também sou humano então todos os meus Windows tem no mínimo o Windows Defender ativo, Malwarebytes que eu gosto também e mesmo assim eu ainda rodo mais um antivirus no NAS também, que também tem na loja da Synology. Eu não confio em nada sem redundância de tudo, sob meu total controle.

Mais importante e porque escolho BTRFS tanto no NAS quanto no meu PC: snapshots. Ele faz snapshots de tudo periodicamente. Assim, se alguma hora eu rodar um rm -Rf da vida errado, eu não perco nada, basta voltar pro snapshot anterior e vai estar tudo lá, bonitinho. Snapshots são inteligentes, eles quase não ocupam espaço, porque no BTRFS o mesmo binário do arquivos iguais, apontam pro mesmo lugar físico. Não é como um rsync que realmente duplica tudo e duplica espaço ocupado.

No seu PC/notebook Linux, com BTRFS, instale o programa Timeshift pra fazer a mesma coisa. A melhor coisa: se uma hora você atualizar seu sistema e ele não bootar ou alguma coisa quebrar depois de update, é fácil: só rebootar e no GRUB escolher o snapshot anterior e pronto, vai voltar exatamente igual antes do update. No Arch/Manjaro ele é inteligente e já faz snapshots automaticamente toda vez antes do pacman rodar:

Enfim, outro dos usos é pra projetinhos pessoais de código mesmo no meu Linux. No mini-PC que uso na TV pra media center, eu rodo Windows 11 mesmo. Porque uso ligado a outra eGPU com uma RTX 4060 e eu uso Steam pra games. Sim, muitos jogos de Steam rodam em Linux, tem Bazzite, etc. Mas tem coisas que só rodam no Windows e eu preferi comodidade mesmo. Só uso pra games e media então ph0da-se, funciona plug and play.

Meu outro home server mini-PC é onde rodam meus Docker pro media center, torrent, plex server e tudo mais. É um Ubuntu LTS headless. Além dos meus handhelds como o Rog Ally X que roda Windows. Todos eles tem acesso ao meu NAS da Synology, onde exponho pastas compartilhadas com SMB e é isso. Plug and play.

Eu fazia a mesma coisa no meu Manjaro Linux: montava as pastas com SMB. Mas isso tem um problema se eu quero codar alguma coisa e quero usar Git: em SMB não existem atributos de chmod (como flag +x pra script executável) e toda vez que faço git push, zoa todas as permissões de tudo. É um enorme saco. Quem já usou Git no Windows sabe disso.

Eu não consigo deixar scripts executáveis nesse diretório compartilhado. Então dificulta minha vida no Linux. Então resolvi consertar isso de uma vez e fazer a coisa certa: parar de usar SMB e passar a usar NFS que é a forma nativa de Linux pra acessar pastas compartilhadas na rede de um outro servidor Linux (se o servidor fosse Windows, aí tinha que ser SMB mesmo, mas ninguém em sã consciência monta um NAS com Windows Server).

No SMB, o serviço ignora ownership e permissões do filesystem. Eu crio usuários e atribuo ao serviço, e não aos arquivos. Basta logar com esse usuário e ele vai ter acesso aos arquivos. Então não tem como fazer chown e mudar ownership e nem fazer chmod e mudar permissões individualmente nos arquivos, é tudo normalizado.

Em NFS, o serviço expõe exatamente o ownership e permissões no filesystem direto, sem um intermediário de ACL pra checar permissões por fora. Então eu tenho o mesmo nível de acesso pra esses atributos que eu tenho nos arquivos locais do meu Linux, que é o que eu quero.

Mas a Synology faz uma coisa irritante não sei porque. Em qualquer Linux, o primeiro usuário e o primeiro grupo criados costumam ser UID: 1000 e GID: 1000. Faça o teste, vai no seu terminal e faça id [seu usuário]:

❯ id akitaonrails
uid=1000(akitaonrails) gid=1000(akitaonrails) groups=1000(akitaonrails),998(wheel),996(audio),994(input),...

Então tanto faz fazer chown akitaonrails:akitaonrails foo.txt ou chown 1000:1000 foo.txt. Na prática é o número identificador que é importante e não o nome.

Com NFS, se no lado da Synology tem um usuário com mesmo número de UID e GID, eu automaticamente tenho permissão. Mas quando se cria usuários na Synology, não sei porque cargas d’água, ele começa criando com IDs acima de 1020 em vez de 1000. Então eu tenho um usuário “akitaonrails” no Synology com UID 1026 em vez de 1000.

Mesmo conseguindo montar a pasta compartilhada com NFS, se tento usar Git, por exemplo, ele detecta que meu UID local é 1000 e os arquivos estão com ownership do UID 1026:

git st fatal: detected dubious ownership in repository at '/mnt/gigachad/Projects/dotfiles' To add an exception for this directory, call: 

	git config --global --add safe.directory /mnt/gigachad/Projects/dotfiles

Não dá pra ficar usando com UIDs misturados, vira uma zona tão ruim quanto SMB. Mas tem formas de mapear e outras gambiarras, mas só tem duas soluções mais “limpas”:

• mudar meu UID/GID do meu Linux pra ser 1026 também
• criar um novo usuário no Synology, mudar o ID dele pra 1000 e fazer chown em todos os arquivos pra esse novo usuário.

Escolhi a segunda opção. Primeira coisa é habilitar acesso a SSH no NAS (o ideal é deixar coisas assim desligadas, por segurança, mas estou numa rede local privada então o risco é mínimo):

No mínimo eu sempre troco a porta padrão do SSH, costume, mas tanto faz. Precisa saber usar SSH, não ensinar aqui, tem ChatGPT pra isso.

Agora, criar um novo usuário padrão:

Vamos garantir que o serviço de NFS está ligado também, já que vou passar a usar ele (por padrão vem desligado, só SMB ligado porque maioria dos clientes são PCs Windows mesmo):

Agora é logar com SSH no NAS e editar o UID e GID, primeiro editando /etc/passwd e achando uma linha como:

akitaonrails-nfs:x:10xx:10xx:...

E trocando pra:

akitaonrails-nfs:x:1000:1000:...

Agora editando /etc/group e mesma coisa, trocando o grupo akitaonrails-nfs recém criado pra 1000 também. Pronto, agora eu tenho um usuário com UID 1000 e GID 1000 criado. O nome não é o mesmo do meu PC mas isso não importa, só os números.

Na GUI da Synology DSM, não esquecer de adicionar permissões pra cada pasta compartilhada, pra NFS:

Ainda via SSH, tem que alterar o ownership e consertar as permissões de TODOS OS ARQUIVOS e no meu caso, com terabytes, levou BASTANTE tempo, só deixar lá rodando:

sudo chown -R 1000:1000 /volume1/GIGACHAD
sudo chmod -R 0755 /volume1/GIGACHAD

Se eu quiser desconectar do SSH e deixar lá rodando (já que vai levar um tempão), basta rodar desconectado da sessão SSH com nohup:

nohup chown -R 1000:1000 /volume1/GIGACHAD > /tmp/chown.log 2>&1 &

Um cuidado que precisa tomar é não fazer algo como chmod -R -x em tudo. Primeiro: diretórios precisam ter o bit de execução e se remover, não vai mais conseguir navegar por diretórios, então tem que separar correção de diretórios e arquivos. Segundo: é bom passar esse conserto em diretórios pra garantir que não ficou arquivos com bit executável (o que pode gerar problemas de segurança, imagine arquivos aleatórios de diretórios de Node modules). Terceiro: diretórios como “#snapshot” são pra controle do filesystem e são read-only, tentar mexer neles só vai comer MUITO tempo, então é melhor filtrar e não mexer neles.

Ou fazer um script com isso e rodar com nohub pra poder sair do SSH enquanto espera ele rodar (no meu caso, com terabytes, leva horas):

nohup /tmp/fix-terachad-perms.sh > /dev/null 2>&1 &

Tem alguns probleminhas escondidos ainda. Ainda no SSH da Synology tem que mudar o /etc/exports que o NFS usa porque ele ainda mapeia por default pro usuário UID 1026 e 100, tem que mudar os dois pra 1000:

# antigo
sudo cat /etc/exports
Password:

/volume1/GIGACHAD       192.168.0.0/24(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)
/volume1/TERACHAD       192.168.0.0/24(rw,async,no_wdelay,crossmnt,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100

Problema de mexer em arquivos de sistema como esse é que não se sabe se mexer na GUI de permissões do NFS, ou se vier updates, vai voltar como era antes. Se alguém souber de alguma solução mais permanente, avisem.

E pronto, com tudo isso, basta desconfigurar a configuração de CIFS/SMB que eu tinha e substituir por NFS. Eu prefiro usar o AutoFS pra fazer isso. Eu tinha um auto.cifs antes, que agora posso deletar. E criar um novo /etc/autofs/auto.nfs assim:

gigachad  -fstype=nfs4,rw,nosuid,noatime 192.168.0.xx:/volume1/GIGACHAD
terachad  -fstype=nfs4,rw,nosuid,noatime 192.168.0.xx:/volume1/TERACHAD

E trocar a linha de auto.cifs em /etc/autofs/auto.master por isso:

/mnt  /etc/autofs/auto.nfs --timeout=60 --ghost --browse

Agora é reiniciar o serviço:

sudo systemctl daemon-reexec
sudo systemctl restart autofs

E pronto, tudo montado com NFS e agora eu tenho suporte completo a ownership e permissions nativas de Linux, sem o overhead e incompatibilidades da porcaria de SMB. Deu um “medinho” ficar fazendo chown e chmod em massa, mas é um NAS com BTRFS. Tem RAID pra aguentar corrupção de dados, tem snapshots se precisar reverter alguma coisa. Essa é a vantagem de ter sistemas de segurança: dá pra fazer as coisas sabendo que se algo der errado, tem como reverter. Essa paz de espírito não tem preço.

Hoje vamos fechar a minissérie de Introdução a Redes. Meu objetivo todo foi poder falar sobre minha nova solução de armazenamento e edição de videos com NAS e na sequência, como criei uma rede segura pra conseguir acessar coisas como meu Media Server, mesmo estando do meu celular numa rede insegura fora de casa, que é a mesma solução que empresas tem usado pra conseguir dar infraestrutura pra funcionários remotos. Hoje vamos entender como VPNs funcionam.

Conteúdo

• 00:00 - Intro
• 00:44 - Cap 1. Meu Primeiro NAS de backup
• 04:38 - Cap 2. Meu Setup Novo de Gravação
• 07:24 - Cap 3. O Novo NAS
• 14:17 - Cap 4. DNS Privado com Pi-Hole
• 18:31 - Cap 5. Meu “Netflix” Particular
• 21:56 - Cap 6. Recapitulando Redes e dispositivos virtuais
• 27:49 - Cap 7. Redes Seguras com Zero Tier
• 36:57 - Cap 8. Como funciona uma VPN?
• 43:51 - Conclusão
• 45:59 - Bloopers

Links

• WHAT HAPPENED TO GEEKBRIEF TV? (https://www.thegeekpub.com/4173/what-happened-to-geekbrief-tv/)
• Pi-Hole cloudflared (DoH) (https://docs.pi-hole.net/guides/dns/cloudflared/)
• Media Server Setup Pt. 3b: Prowlarr/Sonarr/Radarr (https://morrismotel.com/servarr-pt3b-prowlarr-sonarr-radarr/)
• Jellyfin (https://jellyfin.org/)
• Plex Media Server (https://www.plex.tv/media-server-downloads/)
• Getting Started with Software-Defined Networking and Creating a VPN with ZeroTier One (https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one)
• Docker Networking Overview (https://docs.docker.com/network/)
• Hamachi VPN (https://www.vpn.net/)

SCRIPT

Olá pessoal, Fabio Akita

Finalmente, hoje vou voltar a falar do meu novo NAS e na segunda metade dar mais um tópico sobre redes que me interessa, como acessar meu NAS fora de casa, sem comprometer a segurança da minha rede de casa. Na verdade, eu acho que o objetivo todo dessa mini-série de redes que ando fazendo foi justamente pra chegar no episódio de hoje pra falar do meu NAS novo. De volta aos meus videos sobre armazenamento, lá explico tudo sobre como HDs funcionam e como eu posso configurar vários HDs num único volume pra ter redundância e mais segurança. Se não assistiram, recomendo ver depois. Entender arquivos e entender redes é o mínimo do mínimo que um programador precisa saber.

(…)

Foi lá por 2009 que eu comprei meu primeiro NAS caseiro. Naquela época eu usava Mac e nos primórdios de podcast e webcast eu assistia uma reviewer de tech chamada Cali Lewis, que fez propaganda de uma nova marca muito da hora chamada Drobo. Desde aquela época eles faziam um lance mais inteligente do que RAID normal. Um RAID clássico precisa de HDs de mesma capacidade pra montar o array. Significa que se eu colocar um HD diferente maior, o espaço que sobra ele desperdiça. Mas o Drobo usava um sistema proprietário que conseguia usar o máximo de discos de tamanho diferente. Foi o que me chamou a atenção.

Por quase 10 anos eu usei esse Drobo, primeiro acho que foram uns 4 HDs de 512 GB ou 1 TB cada. Com o tempo eu ia trocando pra HDs maiores um de cada vez. Mas acho que nunca usei nada maior que uns 4 TB por HD. E durante essa quase uma década eu já tive problema de HD realmente falhar e graças ao Drobo eu conseguia só trocar esse HD falhando e ele conseguia se reconstruir sem perder nada. Porém a interface dele acho que era USB 2, com seus meros 480 megabits, o que não dá muito mais que 60 megabytes por segundo.

Mas como era mais pra backup, e não pra acessar o tempo todo, eu deixava fazendo backup a noite, aí não importava tanto se era muito lento. Eu tive uma pane no Drobo inteiro uma vez que ele não ligava mais. Comprei outro Drobo, a versão 5N, que já era USB 3. Só tirei os HDs do primeiro que quebrou, coloquei no novo na mesma ordem, e tudo voltou a funcionar. E com a vantagem que com USB 3 já era até 10 vezes mais rápido que o USB 2. Chegava perto dos 100 megabytes por segundo. Que continua sendo 2 a 3 vezes mais lento que um bom HD mecânico, e pelo menos 4 ou 5 vezes mais lento que um SSD SATA.

Durante a pandemia resolvi experimentar com um novo NAS e peguei um Synology DS420j, de tamanho similar ao Drobo. Depois de mais de 10 anos, o Drobo meio que parou no tempo. O software dele é super limitado e não oferece nada além do básico. Diversas outras marcas como QNap, Synology e mesmo opções open source como TrueNAS pra você montar seu próprio NAS num gabinete de PC evoluíram e deixaram o Drobo no chinelo. Resolvi ver o que os concorrentes estavam fazendo. E o Synology eu achei bacana porque é basicamente um Linux, com Linux Raid rodando mdadm por baixo e suportando filesystems open source como ext4 ou btrfs.

Ele não é tão sofisticado quanto um TrueNAS, que tem ZFS e consegue facilmente suportar armazenamento em nível de data center, com arrays de dezenas de HDs e petabytes de dados. Mas TrueNAS não é pra amadores. Não basta só seguir um tutorial na internet e fazer funcionar da primeira vez. Se você nunca precisou recuperar um TrueNAS com problemas, seus dados vão estar inseguros quando você mais precisar. Não adianta nada um software sofisticado que você vai cometer erros de amador e potencialmente corromper seus dados no meio do caminho. E não adianta só fazer funcionar da primeira vez. O teste de fogo é quando alguma coisa der pane e você realmente precisa recuperar dados. Se nunca passou por isso, considere que vai fazer errado da primeira vez.

Como eu não quero virar administrador de sistemas nem trabalhar em data center, eu queria uma solução que usasse componentes open source que eu confio como Linux Raid, mas com suporte comercial decente e softwares maduros que me ajude a não cometer erros de amador. E a Synology oferece tudo isso. Sim, é mais caro que montar um do zero com TrueNAS, mas é mais confiável, e pra isso eu pago mais caro. Valor é relativo. Não adianta nada ser barato pra montar mas na hora de recuperar dados, você cometer um erro e perder tudo. Aí saiu super caro. Todo amador comete esse erro de só considerar o valor inicial das coisas.

O DS420j foi bacana, mas ele tinha o mesmo problema do Drobo, interfaces lentas. Ele tinha ou USB 3 ou conexão de ethernet 1 gigabit. Como eu disse no primeiro episódio desta série de redes, 1 gigabit é ok. Pra maioria dos casos é velocidade suficiente. Mas por causa do canal, mais e mais eu estava lidando com arquivos de centenas de gigabytes. Eu gravo meus videos em 4K com codec de edição DNxHR, isso dá uma média de quase 100 gigabytes por hora de gravacão. Alguns episódios eu preciso ficar umas 2 horas ou mais gravando, então toda vez da 200 gigas ou mais. E não, se deu vontade de comentar “ah, porque você não grava de jeito X ou jeito Y”, obrigado pelo palpite, mas se eu gravo nesta configuração é porque eu já sei que é a melhor. E isso nem é considerado muito. Estúdios profissionais que gravam em 8K estão acostumados a lidar com terabytes por projeto.

Agora pensa, transferir 200 gigas a uma velocidade de uns 120 megabytes por segundo significa quase meia hora pra transferir tudo pro Synology. 120 megabytes por segundo é quase saturar a conexão ethernet de 1 gigabit. É o máximo que meu Synology conseguia ir. E no Drobo era mais lento ainda. E isso só pra fazer backup. Eu precisava ter terabytes de SSD no meu PC pra editar isso. Pra editar video 4K desse tamanho, HD mecânico é muito lento. E assistindo videos de outros youtubers como Linus Tech Tips, MKBHD e outros eu sabia que todos editam videos direto dos NAS deles, usando redes acima de 2.5 gigabits.

Em 2021 eu atualizei meu equipamento de gravação. Antes minha câmera Sony A7III gravava em SD cards. Mas ele tem aquela maldita limitação de parar de gravar automaticamente depois de 30 minutos. Toda câmera fotográfica faz isso por causa de mais uma maldita lei da Europa. Europeu é campeão de criar leis imbecis. De qualquer forma SD cards não são confiáveis e um dia tive problema de corromper meus arquivos e perdi um episódio. Cansado dessas limitações eu comprei um Atomos Ninja V. Agora ligo a saída HDMI da minha câmera nesse Atomos, que por sua vez tem um SSD SATA e ele grava direto do HDMI em arquivo no SSD, sem limitações. Isso resolveu o problema de video. De novo, se tava indo comentar “porque não grava direto no PC”, novamente, pra mim não era uma boa solução. Obrigado pelo palpite.

Daí um belo dia meu gravador de áudio, que era uma Tascan velha, comecou a dar pau e mastigar os arquivos de áudio. Cansei dele e comprei um gravador novo, um Zoom H5. Agora ele grava tanto em SD card, mas eu ligo a saída de áudio na entrada do Atomos, então o Atomos grava tanto o video da câmera quanto o áudio do gravador tudo junto e eu ainda tenho uma segunda cópia no gravador, via SD Card. Daí resolvi o audio também.

Agora eu queria resolver a edição e backup dos videos originais. E sim, eu guardo e sempre vou guardar os originais. Novamente, não precisa ir nos comentários dizer pra apagar os originais pra economizar espaço. Um profissional nunca joga fora originais. E pra isso eu queria transferir os arquivos do SSD do Atomos direto pro meu NAS em rede 10 gigabit. 10 gigabit seria um pico de mais de 1 gigabyte por segundo. E esse meu Synology DS420j que é um modelo caseiro, não oferece upgrade de hardware, tipo colocar placa de 10 gigabits. Então resolvi que era hora de investir num NAS profissional, o modelo DS1821+. A série que termina com “j” acho que é de entrada, é bom pra quem tá começando. A série 21 plus é profissional. Tem modelos ainda maiores, mas pra mim esse seria suficiente.

Pra começar, esse modelo tem 8 baias de HDs. Então decidi ir all in e comprar nada menos que 6 HDs Seagate IronWolf de 12 Terabytes. IronWolf são HDs feitos pra NAS, eles tem mais durabilidade, aguentam mais vibrações, tem cache maior. É como um HD caseiro, tipo modelo Barracuda, mas muito mais resistente, e obviamente mais caros. Liguei os 6 no novo Synology, e montei um volume com 5 deles em modo SHR que é Synology Hybrid RAID. Em vez de um RAID normal que exige HDs de tamanho igual, ele consegue aproveitar o espaço de HDs diferentes melhor de um jeito proprietário dele. Lembra o que eu falei que o Drobo fazia? Hoje em dia outros fabricantes já superaram. No meu caso, isso virou um volume de 42 terabytes, e o 6o HD fica desligado como hot spare. Se um dos 5 HDs falhar, o NAS automaticamente desliga o que falhou, liga o hot spare no lugar e começa a reconstruir o volume sem perder nada.

E como é pra ir all in, resolvi fazer todos os upgrades que esse modelo permite. Coloquei 2 NVMEs de 1 terabyte cada dedicados só pra ser cache. Assim arquivos mais acessados ficam no NVME, em vez de ter que ir nos HDs mecânicos. E nem é muito que precisava porque apesar de serem HDs mecânicos e muita gente ficar me perguntando se um RAID feito com SSDs não seria mais rápido. A resposta deveria ser óbvia: não, o custo simplesmente não compensa. Mas na cabeça de vocês, se imagina que porque estou lidando com HDs mecânicos, vai ser mais lento que um SSD. E é aí que estão errados. Em IOPS talvez, mas em velocidade não. Cada HD desses é capaz sozinho de mais de 200 megabytes por segundo.

Lembra da explicação de dispositivos de bloco e como arquivos são divididos em blocos e como esses blocos são dividos nos vários HDs de um RAID? Cada HD no RAID contribui com mais ou menos metade da velocidade pra leitura e escrita. Então cada um contribui com pelo menos 100 megabytes por segundo pra velocidade total, indo pra mais de 500 megabytes por segundo. Pra dar perspectiva isso é mais de 4000 gigabits. E eu estou arredondando por baixo, em benchmarks eu estou conseguindo ir até 6000 ou 7000 gigabits. Sua rede cabeada de casa é só 1 gigabit, mas na minha que é 10 gigabits, consigo suportar isso.

Pra conseguir essas velocidades na rede eu comprei a placa de rede 10 gigabits e comprei cabos de rede cat 6a com conectores blindados. Não adianta nada placa de rede boa com cabos que não aguentam a velocidade. Se eu falei que consigo ir na faixa acima de 7000 gigabits por segundo, às vezes 8000, significa que estou usando a maior parte do que minha rede consegue. E pra tudo falar nessa velocidade, também comprei uma placa de 10 gigabits pro meu PC e um pequeno switch TP-Link que suporta 10 gigabits em todas as portas.

Aliás, cuidado com switches com marketing duvidoso. Eu vi caixas de switches baratos dizendo que suportam 5 gigabits, e tem 5 portas, aí você pensa que cada porta suporta 5 gigabits, mas não, em letras miúdas eles falam que o aparelho suporta até o máximo de 5 gigabits ou seja, cada porta é só 1 gigabit. No meu caso são 5 portas de 10 gigabits cada, então o aparelho todo suporta 50 gigabits. E isso é importante, porque lembra todo o processamento de checagem de erros, roteamento e tudo mais que um switch precisa fazer? Tudo isso exige CPU que consiga processar o tráfego de 50 gigabits por segundo. Ele fica bem quente quando tá ligado trabalhando.

Finalmente, o último upgrade desse all in foi trocar os 4 gigabytes de RAM que o DS1821 vem e colocar 16 giga de RAM ECC, que tem correção de erros, pra evitar single event upset de raios cósmicos, por exemplo, como expliquei no segundo video da série, de correção de erros. Minha memória ECC provavelmente tá rodando Hamming Code, pra recuperar qualquer bit flip acidental. Tudo isso pra garantir que nenhum dado nessa caixa seja corrompida de jeito nenhum.

E agora sim, eu consigo gravar os videos crus depois da gravação direto pro NAS em velocidade máxima e consigo usar o DaVinci Resolve pra editar videos direto do NAS, sem precisar ter nada em SSD local. Vou te falar que a qualidade de vida é incrível, meu fluxo de trabalho fica bem mais fácil. Isso tudo já é equipamento que um pequeno estúdio de gravação teria, pra ter 2 ou 3 editores de video trabalhando direto do NAS. Pra estúdio maior, eles teriam racks de HDs, cada uma com mais de uma porta de 10 gigabits, talvez numa rede de 100 gigabits por segundo. Nos videos do Linus ele tem o projeto petabyte, onde montam rack com TrueNAS e dezenas de HDs ou SSDs com ZFS que suportaria uma dúzia de editores de video tudo trabalhando por rede 2.5 gigabit, lidando com videos 8K de terabytes de tamanho. O que eu montei é a versão junior disso.

Dá pra ir muito longe. Mas isso foi só pra solucionar meu fluxo de trabalho de video que, honestamente nem é tão pesado assim. Eu sou o único editor e faço tudo sozinho. Portanto sim, esse investimento foi bem mais do que eu precisaria. Só pra ter uma idéia, o NAS, os HDs, os upgrades de SSD, rede e RAM, deram um total de bem mais que 30 mil reais. Se fosse lá fora teria custo fácil mais de 3 mil dólares. Em dólar nem parece tão caro. Um computador moderno como um Mac Studio custa mais que isso. Mas falando em reais, sim, é um terço de um carro popular. Qualidade é proporcional ao preço.

Mas, eu não ia usar só pra videos. A vantagem desse NAS é que ele vem com um bom processador, um AMD Ryzen quad-core de 2.2 Ghz cada. Não chega nem aos pés dos 16 core que meu Ryzen 9 5850 do meu PC tem, mas pra um NAS tá sobrando. Um NAS é nada mais, nada menos, que um PC com Linux. Na teoria você não deveria, mas pode rodar qualquer outro software dentro dele.

Não deveria porque a função de um NAS é ser dedicado a lidar com arquivos. Num ambiente onde outras pessoas estivessem trabalhando e puxando arquivos o tempo todo pra editar, a CPU ia ficar trabalhando só pra entregar os blocos o mais rápido possível. Fora que você não quer que, por acidente, um aplicativo com bug acabe corrompendo seus dados. Então nunca rode nada diferente num NAS de trabalho. Mas como é meu NAS caseiro onde eu sou a única pessoa com acesso, quis aproveitar o processamento sobrando pra mais coisas.

O software da Synology já suporta Docker nativamente, com interface gráfica facinha de usar e acesso a terminal via ssh se eu quiser rodar manualmente. Então comecei a fuçar coisas pra rodar nele. Em outro episódio vou finalmente explicar mais detalhes sobre Docker e containers, mas por hoje entenda Docker como uma forma fácil, controlada e isolada de instalar software no meu NAS sem grandes riscos.

Vamos recapitular o básico de redes. Toda vez que eu navego em sites, normalmente não me preocupo porque todos oferecem HTTPS, então tudo que trafega entre meu navegador e o site é criptografado. Mas isso é depois que já sei o endereço IP do site. Pra saber o endereço IP baseado no domínio como google.com ou apple.com, alguém precisa me dizer que apple.com é o IP x.y.z. E quem sabe disso é um DNS, lembram?

No terceiro episódio da série eu disse que meu PC ganha endereço IP privado atrás de um NAT graças ao serviço de DHCP do meu roteador, que funciona como um síndico do prédio. Eu ligo meu PC e ele pergunta pro síndico, “ow, que endereço ip tem sobrando pra mim”, e o DHCP responde “tem esse 192.168.1.200, beleza?” e aí o PC assume esse endereço. Junto com o endereço vem outras configurações, como o endereço de DNS, que eu disse pra mudar pra ser 1.1.1.1 da CloudFlare ou 8.8.8.8 do Google e evitar usar o DNS que o provedor já pré-configurou pra você caso se preocupe com privacidade, porque DNS de provedor não oferece DoH, que é DNS over HTTPS.

O navegador abre conexão encriptada via TLS com o site depois que sabe o endereço ip do site, mas a requisição pro DNS, perguntando “qual ip que é apple.com” vai em texto puro, aberto, sem criptografar. E se você deixou o DNS do provedor, ele sabe que sites você navegou, que horas, a partir de qual lugar. Não chega a ser nenhuma informação tão crucial assim, mas pra quem se importa com privacidade, é mais uma informação sobre você que está vazando. Tem gente que diz “foda-se” e tudo bem, não precisa comentar isso, seu palpite é irrelevante. Estou falando com quem se importa.

Não só isso. A gente usa plugins de adblock pra bloquear propagandas em sites, mas eles não conseguem pegar tudo sempre. Toda ajuda a mais é bem vinda. Por tudo isso resolvi que o primeiro container que queria instalar no NAS seria do aplicativo Pi-Hole. Ele se chama assim porque foi originalmente feito pra instalar num raspberry-pi, que é como eu usava antes. Mas ele é levinho e mover pro NAS significa um equipamento a menos que preciso dar manutenção.

O Pi-Hole é um servidor de DNS e que oferece uma aplicação web pra dar um monitoramento gráfico pra gente. O que eu faço é configurar pra usar o DNS da CloudFlare 1.1.1.1 e ele faz cache de tudo. E ele também se sincroniza com alguns bancos de dados mantidos pela comunidade de domínios reconhecidos como sites de propaganda ou mesmo de malwares. Daí se algum site onde navego pede alguma coisa desses domínios, o Pi-Hole rejeita e não me deixa navegar pra lá.

Daí o que eu faço é colocar o endereço IP do NAS como DNS no DHCP do meu roteador. Daí todos os equipamentos de casa, meu PC, minhas TVs, meus consoles de video game, meu celular, até minhas lâmpadas inteligentes, recebem a mesma configuração e passam a usar o Pi-Hole como servidor de DNS. A outra vantagem é que ele consegue fazer requisições de DoH ou DNS over HTTPS. Lembram que eu falei que toda requisição de pergunta pra DNS vai em texto aberto? Com DNS over HTTPS ele primeiro abre uma conexão segura via HTTPS e manda a pergunta criptografada. Agora tudo é criptografado, dificultando alguém saber meu padrão de navegação na web.

Pra isso precisei de um segundo container de Docker, oferecido pela própria Cloudflare, que é o serviço cloudflared. Lembrando que “d” no final é de daemon. Não vou entrar em detalhes porque a documentação diz tudo que precisa saber mas o container em si já vem pré-configurado apontando pros servidores de DNS que suportam HTTPS da Cloudflare. Daí eu aponto meu Pi-Hole pra esse daemon e pronto, meu navegador pergunta pro Pi-Hole, que abre uma conexão segura com a Cloudflare e resolve o domínio via HTTPS e nesse percurso, ninguém no meio do caminho, incluindo meu provedor, conseguem saber em quais sites estou navegando. Se gostaram da solução, vou deixar links pro que falei na descrição do video abaixo.

O próximo container eu falei um bocado nas stories do meu Instagram então quem acompanhou sabe. Faz décadas que venho baixando animes, série e filmes. Tem coisas que eu assistia nos anos 80 e 90 e que não existem mais em nenhuma plataforma de streaming de hoje, em particular animes antigos. Tem outros que existem no Japão, mas nunca vieram pro Ocidente. Enfim, tem milhares de conteúdos que se você só assiste Netflix, nunca ficou sabendo que existe. Aliás, a seleção do Netflix é bem ruim e incompleta. Sinto pena de quem só conhece o que tem lá.

Sim, tecnicamente é pirataria. Não estou incentivando mas eu também acho que quem quer piratear vai piratear independente. Avisar que não pode nunca fez nenhum efeito. É que nem foto de câncer em pulmão em caixa de cigarro. Isso nunca funcionou, como ex-fumante eu sempre ignorei completamente aquilo. Cada um é adulto e lide com as consequências. Quer fumar, fume. Só não incomode os outros. Quer piratear, pelo menos pirateia direito.

Que atire a primeira pedra quem nunca baixou nada via bittorrent. Em outro episódio falo sobre ele, mas por hoje, todo mundo pelo menos sabe que é o melhor jeito de piratear. Eu sou da época do LimeWire, eDonkey, Kazaa, Napster e outros, mas bittorrent é animal. E existem softwares open source como Jellyfin, Radarr, Sonarr e Prowlarr que fazem o seguinte.

Jellyfin é um projeto em cima de outro conhecido, o Emby, é basicamente um software que organiza sua mídia, videos, música e tudo mais numa interface parecida com da Netflix, com tocador e tudo mais. Vale a pena pesquisar. Ele vasculha suas pastas de mídia e faz índice, baixa capas dos filmes, notas do Rottentomato, informações de elenco num IMDB e organiza bonitinho pra você.

Mas você ainda tem que ficar baixando as coisas manualmente, renomeando, colocando nas pastas certas. E se desse pra ser tudo automático? É pra isso que servem o Radarr, Sonarr e Prowlarr. Você pode assinar o RSS de bittorrent de séries que ainda estão saindo e o povo de fansub ainda tá legendando, e quando ficam disponíveis, baixa sozinho pra você, renomeia, baixa capa e tudo mais e quando você liga a TV, já está organizado no seu Jellyfin. Dependendo da série que tá acompanhando, se for muito famosa, no mesmo dia que saiu na Amazon Prime, algumas horas depois já aparece no seu Jellyfin. É literalmente como se você tivesse seu próprio Netflix particular, só que melhor.

Hoje não vou mostrar como configura tudo isso mesmo porque eu sou das antigas e uso mais pra baixar coisas que não se encontra fácil. Séries novas eu prefiro assistir direto dum Crunchyroll da vida. Eu assino todos os serviços de qualquer forma. Mesmo filmes que gosto muito compro em Blu-Ray, então quando baixo, normalmente já tinha comprado, só baixo porque é mais fácil pra assistir. E em vez de Jellyfin, prefiro usar o Plex. Ele é meio chatinho com planos pagos e tudo mais, mas é o que tem a interface mais bem feita, melhores apps pra celular e TV, e realmente funciona igual uma Netflix. Dêem uma olhada. Eu tenho séries de anime, ele organiza as temporadas, episódios que já assisti, posso começar a assistir no PC e continuar na TV, perfeito.

O único problema é que ele só funciona dentro de casa, na minha rede local. O Plex é o concorrente do Jellyfin, Emby, Kodi e outros, tem planos pagos se eu quiser acessar de fora, mas digamos que prefira continuar usando só os recursos gratuitos, como faço pra poder assistir meus animes quando estiver viajando, na casa dos meus pais ou em qualquer lugar fora de casa?

E agora vem a última coisa que queria explicar de redes pra vocês. Por causa da pandemia, muita gente ganhou a opção de trabalhar remotamente de casa e aqui o problema é oposto. Como você faz pra poder ter acesso a servidores da empresa por exemplo? É aqui que entra a solução de uma VPN, Virtual Private Network ou redes virtuais privadas.

VPN existem diversos tipos e de novo,não sou especialista em redes então quero compartilhar com vocês só o básico. Até aqui a gente sempre assume que redes funcionam com dispositivos de hardware como placas de rede, que fisicamente tem um buraco pra espetar um cabo ethernet com conector RJ-45. Ou uma placa Wifi que você conecta num ponto de acesso. Mas em ambos os casos se trata de dispositivos físicos de hardware.

Pro sistema operacional falar com esses e outros dispositivos eles precisam de um pedaço de software chamado driver. Esses drivers normalmente são carregados juntos com a kernel do seu sistema operacional, seja Linux, Windows, Mac, Android, iOS, não importa. Se tem um hardware, a kernel precisa de um driver. Num Windows você enxerga os dispositivos no gerenciador de dispositivos e pode ver detalhes, tentar atualizar os drivers por lá e tudo mais. Em Linux pode usar comandos como lspci pra listar os dispositivos ligados no bus ou barramento de PCI. Enfim, o importante é a kernel conseguir enxergar todos eles.

Mas tecnicamente pro sistema operacional, meio que não importa se o hardware existe de verdade, contanto que exista um driver que diz que existe. Presta atenção. Um driver pode mentir pro sistema. É o que acontece quando se instala uma máquina virtual com um VirtualBox da vida. Dentro dela manda instalar o Windows e ela vai instalar drivers que dizem pra esse Windows que tem uma placa gráfica, embora não tenha hardware disso. O driver está emulando um hardware e desenhando na janela do VirtualBox. O Windows virtualizado acha que é uma placa de verdade. Ele não tem como saber a diferença, ele tá dentro da Matrix. E isso acontece com todos os dispositivos. Dentro da máquina virtual os drivers dizem que tudo existe, mas na prática os drivers conversam com o VirtualBox do lado de fora e assim possibilita compartilhar meu teclado de verdade, mouse, som e tudo mais.

E se fosse possível eu ter placas de redes virtuais? E aqui entra os conceitos de TUN e TAP. Lembra a idéia que pacotes de rede são divididos em camadas? No modelo OSI temos camada 1 que é física, camada 2 que é data link, que é o que ethernet se preocupa, tem a camada 3 que é network que é onde a parte IP de TCP/IP se preocupa. Na prática TUN é um dispositivo de rede virtual que atua na camada 3 de rede e TAP cria um dispositivo de rede virtual que atua na camada 2. Isso é uma tecnicalidade que pra gente não importa muito, mas só pra saber. Nos diversos componentes de uma infraestrutura de rede, cada um lida com pacotes em camadas diferentes. A gente que é programador acaba só lidando com camada de aplicação, mas coisas como placas de rede ou switches atual da camada 3 pra baixo, não se importando com as camadas superiores.

Numa máquina virtual, se instala um driver de rede, pra simular que existe rede, e o Windows virtualizado fala com uma placa que não existe, um TAP, que por baixo cria um bridge, ou ponte, entre essa placa virtual e a placa real do PC que é host. Graças a essa placa virtual, dentro da máquina virtual ele ganha um IP tipo 172 ponto alguma coisa. E tudo que é roteado por essa placa, chega na placa real e é roteado pra internet. Na prática é como se existisse uma nova sub-rede privada dentro da rede interna.

Eu uso VMWare na minha máquina, e se abrir as configurações avançadas de rede, olha só o que eu acho, várias placas de rede. Quase todas virtuais. Essa Ethernet aqui é a minha placa de 10 gigabits de verdade que falei antes. Essa outra é a de 2.5 gigabit que vem embutida na placa mãe. Só essas são as de verdade. Mas essas outras aqui são placas virtuais pra coisas como minhas máquinas virtuais. Mesmo num Docker você pode subir container em dois modos de rede, host ou bridge. Se for host, vai subir como se fosse qualquer outro programa no seu PC, usando as mesmas configurações de rede local. Mas se escolher bridge, o container vai falar com uma placa de rede virtual TAP, que vai criar uma sub-rede separada, e rotear os pacotes por essa ponte até meu PC host.

A vantagem de usar bridge é o seguinte. Digamos que eu suba dois containers de web, que internamente vai carregar um programa servidor web que quer se conectar na porta 80. Ambos estão em modo host. O primeiro vai carregar e se pendurar na porta 80 do meu PC. Mas o segundo container vai falhar, porque vai tentar se conectar na porta 80, mas já tá ocupado, então o sistema operacional recusa e rejeita o pedido do container. Agora, se rodar ambos em modo bridge, eles ganham uma rede vazia com outro range de endereços IP estilo 172 alguma coisa que do lado de fora ninguém enxerga. É como sua rede 192.168 local que do lado de fora ninguém enxerga por causa do NAT.

Cada container, nessa rede 172 privada, consegue se ligar na porta 80 interna do container, porque é como se estivessem numa máquina vazia com uma placa de rede só pra eles. Mas do lado de fora podemos mapear a porta 80 de dentro do container com a porta 8080 de fora do meu PC, e o segundo container sube na porta 80 interna e podemos mapear pra porta 8081 do mesmo PC. Ambos os programas acreditam que estão sozinhos, conseguem ligar em portas 80 virtuais, mas do lado de fora estamos remapeando as portas virtuais pra outras portas livres de verdade. Máquinas virtuais e containers são formas de eu mentir pros programas acharem que estão rodando numa máquina sozinhos. E do lado de fora eu controlo o que quero expor pra elas. De novo, containers de Docker estão na Matrix e não sabem disso.

Não são só tecnologias de virtualização e containers que usufruem de placas de rede virtuais. E agora entra os TUN que significa tunel. A parte que eu falei em outros episódios que não queria explicar é roteamento e agora vou mostrar só o mínimo pra vocês entenderem onde quero chegar. Eu mostrei já no episódio 3 desse mini-série como pacotes conseguem sair da minha rede pelo roteador do provedor e ir pra internet. E mostrei rapidamente uma tabela de rotas. Todo sistema operacional com TCP/IP mantém uma tabela de rotas.

Ela que diz pra mandar todo tráfego pro roteador, que costuma ter o endereço IP mais baixo da sub-rede interna como 192.168.1.1 ou 10.0.0.1 ou algo assim. No meu caso é esse TP-Link que deixo do lado do modem. Ele recebe os pacotes e também tem uma tabela de rotas como essa só que no caso dele a saída padrão é mandar pro modem, e o modem por sua vez passa pra frente pra outros servidores na internet. Essa é a tarefa de um default gateway, a porta padrão de saída.

Lembra no episódio anterior onde mostrei o exemplo onde estou numa rede de empresa rígida que restringe uso da internet e fecha quase todas as portas e nem deixa eu navegar em todos os sites? E como usando um servidor da Digital Ocean eu furei um buraco no firewall e abri um túnel seguro encriptado usando SSH? Uma VPN é um programa diferente de SSH mas em conceito funciona parecido, furando buraco em firewall ou no meu caso no CGNAT da Vivo, se conectando num servidor de fora e abrindo um túnel.

Mas em vez de eu abrir o túnel manualmente com o comando SSH uma VPN costuma instalar uma placa de rede virtual TUN. No caso de Linux cria um dispositivo como /dev/tun. Esse dispositivo ganha um endereço IP inválido de internet como 172 alguma coisa. E o software de VPN faz mais uma coisa, cria entradas nessa tabela de roteamento que falei.

Dá pra configurar de varias formas. Por exemplo, posso adicionar na tabela que toda vez que do meu PC de casa eu tentar acessar um IP que só existe na rede da empresa, os pacotes são direcionados não pra minha placa de rede de verdade, mas sim pra esse dispositivo virtual TUN que na realidade é um tunel criptografado ligado no servidor de VPN da empresa.

Vamos dar um exemplo. Como já falei existem dezenas de formas diferentes de VPN. Existe OpenVPN, existe Microtik, soluções baseadas em Wireguard como Tail Scale, mas eu escolhi usar a Zero Tier, que achei simples, fácil de usar, e resolve o meu problema de expor meu Plex de anime fora de casa. Pra começar crio uma conta lá e uma nova rede. Essa rede tem um código identificador que, obviamente estou escondendo uma parte. Ela começa com a84.

Agora vou no meu NAS e instalo o docker da ZeroTier, que é um programa cliente que vai se conectar no servidor deles. Seja no meu NAS, seja num PC com Linux, primeiro preciso carregar o driver pra criar o tal dispositivo virtual de TUN. Eu me conecto no NAS via SSH e, como root, crio o seguinte script:

echo -e '#!/bin/sh -e \ninsmod /lib/modules/tun.ko' > /usr/local/etc/rc.d/tun.sh chmod a+x /usr/local/etc/rc.d/tun.sh /usr/local/etc/rc.d/tun.sh ls /dev/net/tun /dev/net/tun

Estou só escrevendo um arquivo com o comando insmod e o caminho pro módullo de tun pra kernel carregar. Na sequência estou dando permissão pra esse script executar. Eu falei nos videos de Ubuntu pra estudar chmod e permissões lembram? Daí rodo da primeira vez manualmente, no próximo boot já vai carregar sozinho. No final checo se o dispositivo virtual apareceu com o comando ls pra listar e de fato, tá lá. Agora tenho o equivalente a uma placa de rede virtual, de mentira.

Ainda do terminal, agora baixo e rodo o container da zerotier que é um programa cliente que vai se conectar no servidor deles, furando um buraco em firewall e CGNAT. Relembrando, o conceito de furar é porque do lado de fora, meu PC é inacessível por conta de firewall ou NAT do provedor. O servidor da ZeroTire não tem como abrir uma conexão comigo. Mas eu consigo me conectar com o servidor deles. Pra entrar está bloqueado, mas pra sair está liberado. Agora que eu abri a conexão, o servidor da ZeroTier consegue falar de volta comigo por essa mesma conexão. Isso que significa “furar”.

docker run -d \ --name zt \ --restart=always \ --device=/dev/net/tun \ --net=host \ --cap-add=NET_ADMIN \ --cap-add=SYS_ADMIN \ -v /var/lib/zerotier-one:/var/lib/zerotier-one zerotier/zerotier-synology:latest

Nessa configuração eu faço esse container enxergar o dispositivo TUN que acabamos de criar, configuro rede pra ser host, ou seja, sem ser ponte, configuro um volume externo pra configuração que é onde o container vai gravar coisas que ele precisa e que não podem desaparecer se o container bootar. E é isso. Quando terminar de subir vai se conectar e vai ganhar um número identificador da zero tier.

Ainda pelo terminal, posso mandar comandos pra esse container e o que preciso fazer é mandar se conectar naquela rede da ZeroTier que criei que começa com a84 lembra? É um numerozão. Se você se registrar no site e criar uma nova rede, obviamente o número vai ser diferente. Então vamos conectar esse cliente que instalei via Docker com minha rede privada no servidor da ZeroTire.

docker exec -it zt zerotier-cli join e5cd7a9e1cae134f

Pronto. Do lado do NAS é só isso. Agora vou no meu celular e no meu PC e baixo o aplicativo da ZeroTier e instalo nos dois. É o equivalente ao docker que instalei no NAS, um aplicativo cliente da ZeroTire. No meu celular abre esse aplicativo feioso aqui. Mesma coisa, eu clico em Add Network e cadastro a mesma rede que começa com a84 e já posso conectar nela. No meu PC depois que instalei e rodei, aparece aqui embaixo na barra de tarefas. Mesma coisa, me junto na mesma rede. Note que em cada dispositivo diferente ele tem um outro número identificador. No meu celular lá embaixo tem esse outro número que eu escondi que começa com eeb, é o identificador do meu celular. E no app do PC mesma coisa, ele tem esse “My Address” que começa com 3d7.

Pronto, todo mundo configurado e conectado na mesma rede da minha conta na Zero Tire. Último passo, volto pro site, abro a configuração da rede a84 e lá embaixo vai ter uma lista de dispositivos que se conectaram. E olha só, meu PC que começa com 3d7 apareceu, meu NAS que começa com d46 aparece e meu celular que começa com eeb apareceu. Agora só preciso autorizar todos com esses checks do lado e pronto. Tá todo mundo conectado na mesma rede privada. Nessa nova sub-rede todo mundo tem endereços 172.22 ponto alguma coisa. Por exemplo, meu NAS ganhou o endereço 172.22.61.42, o mesmo vale pra todos os dispositivos, cada um com um endereço IP. Esses endereços não são válidos na internet, só dentro dessa rede privada.

Agora vamos entrar no meu celular com o ZeroTier desligado. Se eu abro o app do Plex, que não pago a assinatura, olha que tristeza. Vazio. Vamos fechar, abrir o ZeroTier e conectar na rede dele. Agora abro o app do Plex de novo e voilá!! Olha aqui minhas bibliotecas, e todos os meus animes bonitinho aparecendo! Estou via 4G, fora do Wifi de casa. Estou conseguindo falar com o docker de Plex no meu NAS porque estamos conectados na mesma sub-rede privada da ZeroTier via VPN.

Mesma coisa no meu notebook. Se estivesse fora de casa, em vez de usar o endereço IP da minha rede que é 192.168 ponto alguma coisa, ligo o ZeroTier e no navegador digito aquele endereço 172.22 porta 32400 e olha só, estou navegando no Plex de dentro do NAS, mesmo estando fora da minha rede. Mas como isso é possível? E aí vem o truque que a ZeroTier e outros softwares de VPN fazem. Vamos abrir o terminal do Windows.

Digitando route print -4 pra mostrar rotas de ipv4, tenho rotas pra todo endereço 192.168 interno da minha rede. É com essa tabela que ele sabe pra onde mandar pacotes. Mas depois que habilito o ZeroTier, podemos rodar o comando de route de novo e vemos que adiciona novas entradas nessa tabela. Olha só, ele passa a reconhecer endereços 172 ponto alguma coisa e o default gateway é esse dispositivo 172.22.121.226. Vamos de volta na janela de configurações avançadas de rede do Windows, onde lista dispositivos de rede e olha aqui o dispositivo virtual TUN da ZeroTier. É como se fosse uma placa de rede normal, mas ela não existe, é o driver mentindo pro Windows, ela é virtual.

Botão direito e propriedades. Vamos ver que configurações de IPV4 ele tem e olha o endereço, 172.22.121.226, que é o default gateway que registrou na tabela de roteamento. Por isso que toda vez que tento navegar, por exemplo, pro meu Plex, com o endereço 172.22.61.142, o sistema pega os pacotes, manda pro dispositivo virtual, que por sua vez é só um software cliente que tá conectado no servidor da ZeroTier. Ele faz forward desses pacotes, ou seja, redireciona pra fora, pra ZeroTier. E no mesmo servidor está conectado o cliente de docker que instalei no NAS, que recebe os pacotes por essa conexão.

O que eu tinha mostrado de abrir túnel SSH no episódio anterior é o modelo que se chama de client to site ou acesso remoto. Mas nesse caso eu tenho dois clientes atrás de uma rede privada conversando como se estivessem na mesma rede, ambos com clientes conectados num servidor de VPN, é o modelo site to site ou gateway to gateway. Depois estudem esses termos. Mas na prática, essa solução da ZeroTier cria um túnel criptografado entre meu celular ou meu notebook com o NAS usando um serviço no meio que permite burlar as restrições de cada uma das redes, seja firewalls, seja CGNATs.

Isso que mostrei da ZeroTier é uma solução boa quando você precisa acessar um servidor específico na sua casa ou na empresa, dentro de uma rede privada virtual. Mas isso deve soar um pouco diferente do que você já deve ter ouvido falar de VPN. Se eu tentar navegar na Web, esse tráfego não vai pra ZeroTier. Só endereços 172.22 que vão ser enviados pelo túnel, todo o resto é roteado normalmente pela sua rede local, sem mudar nada.

O que você conhece de VPN é o contrário, que todo tráfego Web passa pelo túnel da VPN e sai pelos servidores deles. Muita gente que vê propaganda de VPN pensa neles como uma forma de burlar o filtro de região de sites como Netflix ou Amazon Prime pra conseguir assistir séries que não passam no Brasil. Ou o uso mais correto que é conseguir navegar com segurança mesmo quando estiver em redes não-confiáveis como o Wifi do Starbucks.

Falando sobre redes públicas, obviamente, nunca, jamais, digite sua senha de qualquer coisa enquanto estiver conectado em rede da faculdade, do aeroporto, do starbucks ou o que for. Lembra no terceiro episódio da minissérie quando falei sobre o problema de hubs, modo promíscuo e tudo mais? Você não sabe quem está escutando seus pacotes numa rede aberta. Sempre que estiver numa rede pública, use uma VPN pra acessar coisas como seu banco. Assim você garante que vai estar tudo criptografado e mesmo se tiver alguém fuçando seus pacotes de rede, não vai conseguir ler nada. Se usa um celular android da Samsung, eles já tem embutido um serviço de VPN barato que ativa automaticamente quando se conecta em Wifi público. Recomendo testar se puder, mas qualquer um serve. NordVPN, ExpressVPN, qualquer um.

O que acontece quando você usa um cliente de VPN? Por acaso eu uso o NordVPN. Ele oferece opção de se conectar em servidores que eles mantém pelo mundo todo. Então vou me conectar num dos Estados Unidos. E pronto, conectado. Agora navego na web normalmente e parece que nada mudou. Vamos praquele site que mostra qual é meu ip, what is my ip. E olha só, fala que o endereço que ele enxerga de mim é um endereço nos Estados Unidos. Justamente porque todos os pacotes da minha máquina estão sendo tunelados pra um servidor da NordVPN nos Estados Unidos e de lá indo pros sites que quero navegar. Do ponto de vista dos sites, é um computador nos Estados Unidos que tá conectado.

Foi isso que fizemos com SSH no episódio anterior, lembra? Local Forwarding? É a mesma coisa, só que mais fácil de usar em vez de ter que digitar aquele comando grande no terminal. Mas o que de fato tá acontecendo? Pra isso vamos abrir a tabela de rotas de novo na linha de comando com route print. Veja a primeira linha e a última linha. Estou simplificando mas ele basicamente diz pra qualquer endereço IP que quero acessar de 0 até 255, pra mandar pro default gateway 192.168.1.1 que é meu roteador como mostrei no terceiro episódio. Mas agora vamos ver quando estou conectado na NordVPN.

Olha o que apareceu. Logo no começo e lá no final da tabela de rotas, agora tem novas entradas apontando pra interface 10.5.0.2. E quem diabos é isso? Ainda na linha de comando digitamos ipconfig /all no Windows pra ver todos os dispositivos de rede e olha só. Tem um dispositivo NordLynx Tunnel. Um dispositivo virtual de rede. O Windows acha que é uma placa de rede, mas não tem hardware por baixo. Ele cria um túnel e roteia os pacotes pela minha placa de rede de verdade, só que criptografado e sempre pro servidor que eu conectei na rede da Nord.

Como que o sistema operacional decide se deve mandar pacotes pra rota anterior do meu roteador 192.168 ou mandar pra rota nova da VPN em 10.5? É por causa desse número de métrica aqui no fim, que é um número de prioridade. Ele vai mandar pro menor número. E de curiosidade, esse “on-link” significa que são endereços que podem ser resolvidos localmente, sem precisar rotear pra fora. Claro, são dispositivos virtuais locais, estão na mesma máquina. Tem um tanto de outras rotas aqui mas é porque meu PC tem máquinas virtuais instaladas, e elas também tem placas de rede virtuais que precisam ser roteadas. Na sua máquina, vai ser uma tabela diferente, mas o princípio é o mesmo, a primeira coisa que vai ter é a rota pro seu roteador. É assim que os pacotes saem da sua máquina e sabem pra onde ir.

Toda vez que você aperta o botão pra conectar na VPN, o que acontece por baixo dos panos é que ele adiciona essas novas entradas na tabela de roteamento. Quando desconecta, apaga essas linhas, aí seus pacotes voltam a trafegar pelo seu roteador como sempre. É isso que um cliente de VPN faz, cria um dispositivo virtual e reconfigura sua tabela de rotas pra desviar os pacotes por esse dispositivo virtual.

Mas voltando pra conversa da ZeroTier e meu servidor de anime. Sem uma solução de VPN, todos esses dispositivos não conseguiriam se conectar através da internet, só seriam acessíveis na mesma rede local, no caso, dentro da minha casa. Mas agora meu NAS fica sempre conectado na rede da ZeroTier, esperando pacotes virem de lá até a placa de rede virtual TUN que criamos, e a partir daí, pro resto do sistema e aplicações, é como se fosse uma conexão local na mesma rede. E é assim que muitas empresas conseguiram ter funcionários trabalhando de casa, em redes restritas atrás de CGNAT, abrindo conexão em servidores que estão nas empresas, de forma segura, porque todas as soluções de VPN são criptografadas.

Por muito tempo se usou protocolos como PPTP que é Point to Point Tunneling Protocol, pra criar túneis ponto a ponto seguros, mas se não estou muito errado ninguém mais usa PPTP, já é obsoleto e acho que considerado inseguro. Se esbarrar num tutorial com PPTP pode pular porque deve ser velho. Muita gente ainda usa soluções derivadas de OpenVPN, que é um software complexo, escrito em cima de outro software complexo e controverso que é o OpenSSL. Mas no mundo Linux pelo menos, acho que povo tá migrando pro Wireguard, com código mais moderno e mais leve, que agora vem direto na kernel do Linux. Eu mesmo não sei muitos detalhes, mas se o assunto de redes e segurança te atrai, definitivamente estude Wireguard.

Como disse antes, a ZeroTier usa alguma solução proprietária que parece que é criptograficamente um pouco menos seguro que Wireguard, mas não significa que seja inseguro. Se quiser um serviço equivalente que use Wireguard por baixo, tem a Tail Scale, que funciona mais ou menos do mesmo jeito que mostrei. E no caso de soluções pra empresas, acho que muitos usam os produtos da Microtik. Só lembrando que nada disso sai de graça, e não digo no custo de assinatura dos serviços. Pacotes tendo que passar por outras máquinas intermediárias no meio do caminho, em túnel criptografado, adiciona tempo de processamento e tempo de rota, por isso seus pacotes vão chegar no destino levando mais tempo e por isso conexões atrás de VPN tem velocidade menor e latência maior. O que varia nos diversos serviços por aí é a oferta de servidores próximos de você que podem ajudar a diminuir essa latência. Pra navegar na web não faz diferença mas pra coisas como gamers, latência é importante.

Enfim, no frigir dos ovos consegui fazer o que queria. Configurei um NAS super rápido, o suficiente pra conseguir editar video pesado direto dele em rede de 10 gigabits local e consigo acessar coisas do meu NAS como meu Plex, mesmo estando fora de casa, usando uma VPN da ZeroTier. Tudo isso foi super simples de configurar porque já estou mais que familiarizado com VPNs, túneis e tudo mais. Do momento que decidi usar o ZeroTier, já estava com tudo configurado em todos os dispositivos em uns 15 minutos.

Mesmo você não sendo alguém de infraestrutura, é importante saber esses conceitos porque em pouquíssimo tempo dá pra criar soluções pra problemas simples como o meu, que era expor meu NAS na internet de forma segura. Eu falo como é impressionante o quanto se aprende quando brinca de pirataria. Mesmo gamers já tiveram que lidar com esse tipo de tecnologia. Quem aqui nunca arrancou os cabelos tentando fazer o Hamachi funcionar? Pra quem não sabe Hamachi é que nem o NordVPN, um serviço de VPN da LogMeIn. Por alguma razão gamers tendem a usar Hamachi.

Eu poderia ter criado tudo na mão, um servidor particular numa Amazon ou Digital Ocean, um túnel local forwarding com SSH ou mesmo uma VPN com Wireguard, tudo configurado via linha de comando no terminal, na mão. E é uma boa opção pra quem quer aprender. Mas eu queria algo plug and play. Como exercício deixo de lição de casa pra vocês que tem um PC em casa e um notebook, criar uma VPN usando Wireguard ou SSH, sem usar um software mais fácil como ZeroTier ou NordVPN. Acho que só o tanto de documentação pra ler e tentativa e erro que vão ter que fazer vai valer mais que muito curso de redes que tem por aí.

E com isso finalmente consegui concluir a mini-série de redes. Em seis episódios mostrei só o básico do básico do que considero introdução ao assunto de redes e internet. Ainda tem bem mais coisas e muito mais detalhes, como VLANs. Mas vou deixar pra falar sobre essas coisas mais pra frente. Por agora cansei de falar de redes. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Ainda não é um episódio “de segurança” mas vou começar mostrando como é fácil injetar um bug de segurança tendo a melhor das intenções e depois como manipular tunelamento de SSH pra abrir buracos em firewalls e bypassar proxies. Coisas que podem ser muito úteis na vida real.

Conteúdo

• 00:00 - Intro
• 00:57 - todo programa é como uma função
• 02:52 - CAP 1 - fazendo um site com injection
• 06:34 - One Liners
• 08:25 - Sanitização
• 09:57 - CAP 2 - furando firewall
• 13:47 - criando um droplet na DigitalOcean
• 15:41 - reconfigurando sshd
• 18:06 - ssh remote forwarding
• 21:26 - CAP 3 - furando proxies
• 26:25 - ssh local forwarding
• 30:45 - CAP 4 - consertando a vaca
• 33:17 - conclusão
• 34:27 - bloopers

SCRIPT

Olá pessoal, Fabio Akita

Finalmente, agora que posso assumir que assistiram meus últimos quatro videos sobre introdução a redes e internet, posso começar a falar de coisas mais interessantes. Vocês já sabem como informação trafega na rede, como processos se ligam a portas, sockets e tudo mais. Então vamos falar rapidinho sobre alguns conceitos de segurança em rede. Só pra esclarecer, o tema de hoje não é o geral de segurança, só algumas brincadeiras que eu acho interessante saber.

A primeira parte da história vai envolver um pouco de programação web e um dos buracos de segurança mais comum. E na segunda parte vou mostrar alguns truques que dá pra fazer com SSH em alguns cenários. A idéia não é ser um video completo sobre segurança, só mencionar dois aspectos que podem ser úteis. Eu já fiz um video inicial de segurança e em episódios futuros talvez eu entre em mais detalhes. Mas por hoje são coisas que programadores iniciantes ainda nem sabem que dá pra fazer.

(…)

Pense assim, um programa é como se fosse uma função. Ele pode receber algum input seu, do usuário, processar alguma coisa dentro, e cuspir alguma resposta. Sempre são essas três grandes partes, input, processamento e output. Mesmo no design de um chip de CPU temos as três grandes partes de fetch, decode e execute. Se for um programa long lived, que persiste e fica rodando em background, como expliquei no episódio passado, é um Big Loop esperando algum input seu na forma de coisas que digita ou que clica na tela. Daí processa alguma coisa, e cospe alguma coisa na sua tela. Em resumo, programas mastigam seu input e cospem um output. Também podemos pensar em programas como alguma coisa que transforma o input em um output. Por exemplo, um Spotify transforma os cliques de mouse na interface em música, que é seu output.

Antes de internet e antes de redes, você era a única pessoa que entregava algum input pro programa que ia rodar na própria máquina. E a maioria de nós não tem interesse em digitar comandos que destruam a própria máquina. Ninguém vai digitar sudo rm -Rf / e dar a senha. Esse meme é antigo mas deve ter gente que ainda não sabe o que é isso. Sério, se você não sabe vai assistir meu episódio de Ubuntu. Tudo que você manda sua máquina fazer é responsabilidade sua saber o que vai acontecer. Se não sabe, Google tá aí pra isso.

Eu gosto de pensar nas minhas máquinas como extensões de mim. Da mesma forma que seu corpo vai estragar se só consomir um monte de refrigerante, doces e pizza, sua máquina também vai estragar se só sair dando copy e paste de comandos e rodando no terminal. Fast food é fast food. Mas o ponto que quero chegar é que partindo da premissa que quem vai executar alguma coisa sabe o que tá fazendo, os programas antigamente eram bem mais ingênuos. Até porque não tinha tanto poder de processamento pra fazer coisas consideradas supérfluas, então o código sempre era o mais simples possível.

Vamos pegar o exemplo de hello world de node.js que mostrei no episódio anterior e adicionar algumas coisas. Acho que foi no episódio de aprendizado na beira do caos que mencionei de um programinha besta que tem em Linux chamado cowsay lembram? Você instala e no terminal executa assim cowsay hello e ele cospe uma vaquinha desenhada com caracteres ASCII mais a sua mensagem. Aí nos primórdios da Web, alguém poderia pensar, “ulha, seria legal eu ter esse cowsay na web”.

E por que não? Meu hello world do episódio passado é muito chato. Só imprime a mesma mensagem. Eu quero que o usuário consiga fazer a vaca dizer qualquer mensagem. Todo mundo precisa ver a carinha da vaca pra alegrar o dia. Eu quero poder digitar no navegador http://localhost:3000?message=bom+dia e ver a vaca me dar bom dia. Todo mundo precisa de um bom dia da vaca pra começar bem o dia.

A primeira coisa é conseguir pegar esse parâmetro de mensagem que vai na URL depois da interrogação. Em HTTP a URL não serve só pra passar o endereço do servidor, mas podem ir mais informações, como pares de chave e valor separado por & comercial depois de uma interrogação. Todo mundo já deve ter visto isso, especialmente se já copiou e colou links de produtos em ecommerces como a Amazon, que notoriamente tem uns links sujos pra cacete. Pra pegar esses parâmetros, primeiro vou importar a biblioteca url pra processar a URL. E lá embaixo, na função que recebe a estrutura de request, faço o parsing da URL pra me devolver um objeto de query strings.

Pronto. Com isso tenho acesso àquele parâmetro que chamei de “message” no exemplo da URL. Agora quero conseguir executar o comando cowsay que instalei no meu Linux. Pra isso todas as linguagens tem a capacidade de instanciar um novo processo filho, literalmente conseguem rodar outro programa. No caso do Node carrego a biblioteca child_process e pego o comando exec dele. Já expliquei sobre forks, processos e coisas assim nos episódios de concorrência e paralelismo e no video de Ubuntu.

Agora vem o principal. Eu chamo a função exec com a query string “message” que tirei da URL e monto a string do comando de cowsay como fiz no terminal, usando interpolacão de strings. Toda linguagem tem o equivalente a interpolação de strings, se não sabem nem isso, estudem mais. Essa função exec vai executar o comando cowsay, e quando terminar chama essa outra função anônima que passei. Ela vai preencher pra mim o que o programa retornou, separado em objetos de erro, standard output ou stdout e standard error ou stderr.

Como é um exemplo besta, nem vou me preocupar com os casos de erro e ignorar completamente. Obviamente isso não é uma boa prática, mas é só pra simplificar neste exemplo. Quero só pegar o que o programa cuspiu no standard output e preencher a estrutura de response com ela. Pronto, agora salvo, volto pro terminal e executo o programa com o Node. Ele vai dar bind e ficar escutando na porta 3000 como antes. Podemos voltar pro navegador e digitar aquela URL que mostrei antes, localhost 3000 message igual bom dia.

E boom, olha que bonitinho, mostrou a vaquinha no meu navegador como eu queria. E era assim que muitos sites nos primórdios da Web faziam. Delegavam alguma coisa pra algum programa já instalado no seu sistema, pegavam o que cuspia no stdout, e devolvia no meio de um HTML pro usuário. No meu exemplo besta, nem me preocupei com HTML, só cuspi um texto puro mesmo. Iniciantes podem achar que acabou, mas agora que começam os problemas. Se você não viu nenhum problema no que eu fiz, sabemos que realmente ainda é um iniciante. Não se preocupe, vamos abrir seus olhos.

Vamos voltar pro terminal no Linux. Se não sabia disso, um shell como Bash ou ZSH ou todos eu acho, permite digitar múltiplos comandos numa mesma linha, um atrás do outro, basta separar por ponto e vírgula. Vamos tentar? Deixa eu digitar cowsay hello; ls -la e olha o que acontece. Ele executa o cowsay e printa na tela, mas logo em seguida executa o ls -la e printa embaixo. É um jeito de você fazer one-liners, que são programinhas que cabem numa única linha antes de dar enter. Pra scripts isso é muito útil. Todo mundo que mexe com Linux sabe disso.

Não precisa ser muito astuto pra pensar. “Hmm, será que eu consigo fazer isso do navegador?” Vamos tentar. Depois da mensagem posso digitar ponto e vírgula e algum comando. E olha só o que voltou!! O meu programa em Node executou o comando seguinte ao cowsay. E agora, eu consigo navegar por todos os arquivos do servidor e executar comandos arbitrários!!! E você pode pensar “ah, mas só dá pra listar coisas, por que isso seria um problema?”. Ok, vamos fazer outro exemplo http://localhost:3000?message=fodeu;cat ~/.ssh/id_rsa.

Sabe o que eu fiz? Acabei de pegar a chave privada de SSH desse usuário, que é um arquivo que jamais deveria poder ser exposto fora desse diretório, por motivos de segurança. Com ela consigo invadir conta de GitHub, Amazon e tudo mais que essa chave conseguir usar. Eu posso até baixar arquivos binários, basta passar pelo comando base64 pra transformar num texto, vai aparecer no navegador, copio e colo com Notepad em algum lugar e faço decode do base64 de volta pra string. Expliquei isso no video de detecção e correção de erros. Consigo imaginar várias coisas que dá pra fazer só com isso. Se dá pra executar qualquer comando, eu já tenho controle sobre essa máquina inteira. Eu ownei essa máquina. É game over.

Esse meu programa é exatamente o que um programador amador poderia pensar em fazer: o mínimo de código pra fazer a idéia funcionar. E de fato funcionou, a vaquinha aparece como deveria. E normamente esse mínimo nunca assume que alguém teria a idéia de tentar coisas que o programa não foi desenhado pra fazer. Mas é assim que pensa todo hacker: como eu posso explorar os programas de formas que o autor não previu? E um programador minimamente mais experiente já sabe: eu deveria ter sanitizado o que veio como query string.

Hoje não é o dia de falar sobre vulnerabilidades, mas isso que acabei de fazer se chama injection, ou injeção, porque estou injetando comandos arbitrários num parâmetro que não foi devidamente tratado, ou sanitizado. Sanitizar significa considerar que tudo que vem do mundo externo de um usuário, por definição, é podre, sujo, e precisamos sanitizar, antes de usar. Sanitizar significa remover caracteres especiais, como esse ponto e vírgula, ou escapar esses caracteres pra serem tratados como string e não como comandos. Existem dezenas de bibliotecas que fazem isso.

Frameworks como o Express, que é feito em cima do Node, justamente adiciona coisas como sanitização já sabendo que a maioria dos programadores não se preocupa com isso. Mas o objetivo desse exemplo besta foi só pra demonstrar como nós fazemos programas ingênuos quando somos iniciantes, e se for só pra nós mesmos, pra usar no nosso próprio computador, tudo bem. Mas numa aplicação web que vai pra produção e vai ter gente de verdade usando, todo cuidado é pouco.

Mas o ponto é que programas podem ser usados de formas pras quais eles não foram desenhados. No final vou voltar nesse código, mas esta próxima parte é voltando pros conceitos de rede que vim explicando nos últimos episódios. Em particular a idéia de sockets e portas. Como disse, antigamente a gente era bem mais ingênuo e não parava pra pensar que existiam pessoas maliciosas ou simplesmente só curiosas. É o oposto do que se aprende em cursos e tutoriais.

Agora imagina. Povo tá empolgado com o nascimento da internet e começa a colocar programinhas ingênuos como o que eu fiz aberto em portas de servidores com endereço IP público válido, como nas universidades da época. Servidores que agora qualquer pessoa poderia acessar. E no meio deles tá esse site de vaquinha. O objetivo nem era deixar público, só queria mostrar pros colegas da faculdade, mas sem querer agora deixei um buraco de segurança enorme aberto. Por isso que nunca um código de junior pode ir pra produção sem ter passado pela revisão de um ou mais sêniors, no mínimo.

Existem várias formas de um administrador de sistemas bloquear essas tentativas de ataque mesmo sem a colaboração do autor da vaquinha. Uma delas e a mais comum é criar políticas como, pra estar na porta 80 ou 443, precisa ser um site feito por alguém de confiança da faculdade ou instituição. Sites feitos alunos ou outras pessoas, até podem rodar internamente em portas diferentes, dentro do servidor do departamento, mas não vão ser expostos na internet pública. Todo mundo pode subir sites nesse servidor hipotetico, em portas como a 3000 que eu usei ou qualquer outra como 4000 ou 8080.

O site oficial roda na porta 80 desse servidor. Todas as outras portas deveriam estar fechadas pro público. E assim nasce o conceito de firewalls. Firewall é um programa, como qualquer outro, que roda com privilégios de administrador ou root do sistema. Isso porque ele precisa interceptar todos os pacotes que chegam ou saem pela placa de rede e filtrar pra saber se podem ou não prosseguir. Sem entrar em detalhes, existem dois tipos básicos de regras, uma pra permitir coisas e outra pra rejeitar coisas, allow ou deny.

Sem nenhum firewall é como se tivesse um firewall com nenhuma regra de deny e allow asterisco, ou seja, aceita tudo. Segurança completa é deny tudo e nenhum allow, mas aí o servidor seria meio inútil. No caso do servidor dessa faculdade de exemplo, a regra poderia ser deny tudo mas allow in, ou entrada, na porta 80. Assim, eu poderia ter meu site de vaquinha interno na porta 3000, mas se alguém de fora, da internet pública, tentasse acessar a porta 3000, a regra do firewall diz que é pra rejeitar, então rejeita todos os pacotes endereçados pra 3000 e nunca chega no meu sitezinho.

Mesmo numa rede interna de faculdade ou empresa, isso ainda não é suficiente. Porque em segurança a gente suspeita de tudo e de todos, incluindo pessoas internas. De novo, não é porque eu acho que todo mundo tem más intenções, mas porque justamente as pessoas de boa intenção, que não enxergam mau nos outros, são os mais fáceis de enganar com coisas como malwares. Você nunca sabe se um aluno instalou um malware que veio por email sem querer e agora no notebook dele tem um malware pendurado numa porta qualquer e vasculhando por portas abertas.

Por isso os firewalls também bloqueiam que um notebook numa rede consiga tentar se conectar numa porta de outro notebook na mesma rede. Ele dá deny de todas as portas acima de 1024, por exemplo. Assim, mesmo se eu subir a vaquinha na porta 3000 da minha máquina, outro usuário na mesma rede não vai conseguir acessar, mesmo sabendo meu endereco IP. O firewall vai bloquear. E é assim mesmo até hoje em muito ambiente corporativo. As regras costumam ser as mais fechadas possível pra justamente evitar o acidente de alguém largar uma vaquinha dando bandeira e alguém malicioso se aproveitar disso.

Agora faz de conta, sou um aluno dessa faculdade. Eu fiz lá a vaquinha e subi no servidor na porta 3000 e sei que tá bloqueada do lado de fora. Mas eu queria porque queria poder mostrar isso pros meus amigos lá fora. Só que o administrador da rede nunca que vai deixar eu pendurar meu site publicamente do servidor da faculdade. Por acaso eu tenho uma máquina virtual de grátis que ganhei pra testar da DigitalOcean, que é um serviço de VPS ou servidores virtuais de aluguel. Eu poderia instalar lá, mas sabe? Tô com preguiça, porque já tá funcionando aqui no servidor da faculdade e só depois descobri que as portas tavam fechadas. O que eu posso fazer? Tá tudo bloqueado, mas ao mesmo tempo eu sei que consigo navegar na web. Então nem tudo tá bloqueado, no mínimo portas 80 e 443 tão abertas pra sair. Eu posso usar isso a meu favor.

De novo vou repetir, portas são só números. Por convenção 80 é pra HTTP e 22 é pra SSH. Vamos rapidinho criar uma nova máquina na DigitalOcean. Vou escolher um Ubuntu numa máquina fraquinha, no data center dos Estados Unidos. Espero terminar. E copio o endereço IP público valido que ele me dá. Depois de ter criado uma máquina numa DigitalOcean da vida, consigo logar usando o comando ssh root@ip da máquina e como não indiquei nenhuma porta, o ssh vai tentar na porta 22 padrão. Coloco minha senha, e pronto, entrei na máquina remota. Estou mostrando o endereço IP de verdade porque depois de hoje vou destruir essa máquina, então não vai mais funcionar se você tentar conectar agora.

A DigitalOcean fornece endereços válidos na internet pra máquina que eu alugo. Numa máquina baratinha ele fica mudando o endereço pra outro. Se eu quiser ter sempre o mesmo, posso pagar a mais pra reservar pra mim. Lembra minha explicação que não existem endereços IPv4 pra todo mundo? É por isso. Pra ter um válido, precisa pagar mais caro. Mas o ponto é que qualquer um na internet consegue enxergar, ou seja, rotear pacotes pra essa máquina.

Enfim, o programa em si que tá rodando no servidor pendurado na porta 22 se chama sshd ou ssh daemon. Daemon é todo programa que o sistema operacional gerencia, ele inicializa depois do boot e fica checando se ele crashear, daí tem regras se tenta carregar de novo e assim por diante. Estude sobre systemd, OpenRC ou runit, que são gerenciadores de daemons que a maioria das distros Linux roda. Mas enfim, saiba que eles que são responsáveis por garantir que programas como o SSH carreguem sozinhos após cada boot. Graças a esse programa daemon aberto e pendurado na porta 22 que do meu notebook consigo executar o programa ssh apontando pro endereço de lá e abrir uma conexão segura de terminal remoto.

Agora vai ter alguns detalhezinhos mas não é importante decorar, só acompanhar o raciocínio. O que eu vou fazer é o seguinte, de dentro dessa máquina remota, vou editar o arquivo /etc/ssh/sshd_config e habilitar essas opções comentadas de Allow Tcp Forwarding e Gateway Ports pra yes, e lá embaixo vou mudar a porta de 22 pra 80. Viu, eu posso pendurar programas em qualquer porta e eu escolhi mudar o daemon de SSH pra porta 80. Agora salvo e uso o comando do systemd systemctl restart sshd pra reinicializar o daemon e carregar as novas configurações, agora posso sair do ssh com exit.

Se eu tentar o mesmo comando ssh pra conectar no servidor, vai falhar, porque como eu disse, vai tentar por padrão na porta 22. Só que mudei pra porta 80. E agora? Como faz? Normalmente esses programas de rede sempre tem uma opção pra manualmente escrever a porta, só colocar -p 80 no final e bingo, olha só, conectou direitinho. Agora que a brincadeira começa.

Aquela minha vaquinha tá rodando localmente no tal servidor hipotético da faculdade na porta 3000. Faz de conta que meu PC aqui de desenvolvimento é esse servidor da faculdade. Por isso vou no navegador e digito 127.0.0.1 ou localhost, que são os endereços locais da minha máquina.

Não adianta eu passar esse endereço pra ninguém, porque significa “minha máquina” como expliquei no episódio anterior. Na máquina do seu vizinho, se ele digitar a mesma coisa, não vai carregar nada porque não tem nada pendurado na porta 3000 da máquina dele. Mas eu quero que meus amigos de fora consigam ver a vaquinha. Pra isso preciso de um endereço IP público válido e que tenha portas abertas sem bloqueio de um firewall.

Pra isso vou usar um dos super poderes do SSH, o recurso chamado Remote Forwarding. No terminal do servidor da faculdade, eu digito ssh -R pra remote forwarding e agora fica complicadinho ip do servidor:7000 depois 127.0.0.1:3000. Estou falando o seguinte, toda vez que alguém tentar se conectar no endereço do meu servidorzinho na DigitalOcean, nessa porta 7000, faça forwarding, redirecione o tráfego, pra minha máquina local 127.0.0.1 porta 3000, que é onde tá rodando a vaquinha.

Daí termino com as mesmas informações de antes pro login, usuario root arroba endereço e -p pra porta 80 que é onde o sshd tá ouvindo. Eu sei, ficou um comandão enorme, mas depois revejam com calma e entendam cada parâmetro. O que esse comando diz é: conecte no meu programa de sshd na porta 80 do servidor da DigitalOcean e se pendure na porta 7000 de lá e fique escutando. Toda vez que vier alguma requisição por lá, faça forwarding, redirecione todo o trafego, pra porta 3000 da minha máquina local.

ssh

Explicando fica complicado. Então vamos mostrar na prática. Deixa eu abrir aqui meu celular que tá conectado via 4G, ou seja, ele não teria acesso ao tal servidor hipotético da faculdade. Vamos digitar o endereco IP público do servidor da Digital Ocean, válido na internet e colocar dois pontos 7000. E voilá, olha a vaquinha aqui, aparecendo em público! Como pode isso? O firewall não tava travando? O que aconteceu?

Vou repetir. No navegador do celular eu acessei um endereço IP válido da Digital Ocean. Essa máquina virtual tá vazia. É um Ubuntu recém instalado. A única modificação que eu fiz foi configurar o programa de sshd pra se pendurar na porta 80 em vez da 22 que seria padrão. Dessa forma, eu, pobre aluno da faculdade que está atrás de um firewall bem rígido que bloqueia portas como 22, consigo acessar via a porta 80, que está aberta porque a faculdade pelo menos permite as pessoas navegar na web. E pra isso, obrigatoriamente o firewall é obrigado a deixar passar saída na porta 80. Entenderam? O firewall bloqueia qualquer coisa de entrar na rede, mas precisa permitir pacotes saírem pras pessoas conseguirem navegar na Web, e pra isso no mínimo saída pela porta 80 estava aberta. Portanto, havia esse buraco que poderia ser explorado.

O firewall deixa pacotes sair, mas não deixa nada entrar de jeito nenhum, então mesmo o servidor da faculdade tendo um endereço IP valido, o firewall não deixaria ninguém se conectar na minha porta 3000. O que eu fiz com SSH é o que se chama de poking a hole, ou literalmente fazer um buraco no firewall, é assim que se fura um firewall do lado de dentro. O grande lance é que do servidor da DigitalOcean ele não consegue me achar na internet e se conectar em mim, mas eu consigo achar e me conectar nele, via a única porta aberta de saída, a 80. E uma vez aberta a conexão, daí meu servidor de fora consegue falar comigo via essa conexão que eu estabeleci com o programa SSH.

Se pra você isso é novidade, respire um segundo e reveja. O servidor da DigitalOcean bem como qualquer outra pessoa na internet não tem como se conectar no servidor porque o firewall bloqueia, mas se a conexão se inicia do lado de dentro, desse servidor, uma vez estabelecida a conexão pra fora, agora ambas as pontas conseguem se comunicar.

Esse é um truque que eu já usei inúmeras vezes ao longo dos anos. A primeira vez que aprendi a fazer isso acho que nem existia SSH. A gente usava um programinha chamado HTTP Tunnel, que faz o oposto do que acabamos de fazer, o recurso de Local Forwarding do SSH. Deixa eu dar um outro exemplo. Acontece que só fechar todas as portas mas manter a porta 80 e 443 de Web abertas, continua sendo um enorme risco de segurança, porque vai saber quem dentro da empresa que não tá entrando em site pornô, site de pirataria e uma hora esbarrando em sites com malwares. Pra evitar isso acho que até hoje tem empresas que obrigam todo mundo a usar um proxy.

Se você abrir um navegador recém instalado numa empresa mais segura, não vai conseguir navegar pra lugar nenhum. O administrador da rede da empresa vai te instruir a abrir a configuração de proxy do seu sistema operacional e colocar um endereço IP e uma porta que aponta pro programa de proxy. Isso pode ser no nível do sistema operacional ou nas configurações do navegador.

Lembra no episódio passado que fiz um exemplo de conectar num servidor web local usando telnet e digitando manualmente o cabeçalho de requisicão HTTP? Lembra? Comando GET seguido de barra e o nome da pagina html que quiser, terminando com HTTP 1.0? Um cabeçalho mais completo, que um navegador enviaria, seria parecido com isso aqui.

GET / HTTP/1.1 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 DNT: 1 Accept-Encoding: gzip, deflate, sdch Accept-Language: pt-BR,en;q=0.8

Ele dá bem mais detalhes pro servidor, como se apresentar dizendo que navegador que é, dizendo que línguas que aceita e coisas assim. É uma das formas de como serviços como Google Analytics conseguem saber coisas como qual navegador mais acessa seu site. Enfim. Se tiver um proxy configurado, o navegador não vai mais se conectar direto com o site que você quer, em vez disso sempre vai mandar todas as requisições pro servidor de proxy. E o pacote vai ser um pouquinho diferente. Assim.

GET http://www.mega.io/ HTTP/1.1 Host: www.mega.io Proxy-Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 DNT: 1 Accept-Encoding: gzip, deflate, sdch Accept-Language: pt-BR,en;q=0.8`

Olha só, no comando GET vai a URL inteira, com o domínio, uma nova linha dizendo que host estamos querendo nos conectar e uma configuração específica de Proxy. O Proxy vai receber essa requisição e modificar pra ficar igual à original sem os detalhes de proxy. E é proxy quem vai se conectar com o servidor do Mega, no caso. O site do Mega vai gerar um HTML, o pacote de response e devolver pro Proxy. Daí o proxy redireciona a resposta de volta pro meu navegador. Um proxy atua como um intermediário entre eu e os sites que quero navegar. Do ponto de vista do usuário, estou navegando normamente. Mas do ponto de vista dos sites que estou acessando, ele só enxerga o proxy como usuário.

Mais ou menos o efeito é parecido com o que eu expliquei de NAT e CGNAT no terceiro episódio da mini-serie. Internamente temos um endereço IP 192.168 que não é válido na internet. Todo pacote passa pelo roteador do provedor e é convertido num endereço válido, que é o que os sites enxergam. Mas todo mundo atrás do NAT vai ser visto com o mesmo endereço IP. Pros sites, é difícil dizer quem são os usuários só baseado nisso.

Mesma coisa com proxy, só que restrito ao tráfego de Web. Em vez de NAT os pacotes passam pelo Proxy, e os sites só enxergam um endereço IP público da empresa, sem saber com certeza os usuarios atrás. A gente rastreia usuários com outros dados, como o cookie do navegador, que tem o login de cada usuário. Outra hora explico sobre cookies, mas foi só pra dizer que em termos de conceito, NAT e Proxy tem resultados semelhantes do ponto de vista dos sites.

A vantagem disso pra empresa é óbvia. Proxies tem filtros com whitelists e blacklists. Meio como um firewall ele pode dizer o seguinte: ninguém pode navegar em nenhum site da internet, com exceção dos domínios que o administrador configurar na whitelist. Assim ele pode restringir em quais sites os funcionários podem navegar. Sites pornô e de entretenimento provavelmente estão na blacklist da empresa. E adivinha, se o administrador não tiver colocado stackoverflow.com, você se fodeu.

Mais do que isso, ele pode monitorar o conteúdo de tudo que tá passando e registrar. Isso é mais difícil hoje porque usamos HTTPS e aí ele tem mais dificuldades de vigiar o conteúdo do que você tá navegando porque vai tudo criptografado. Mas como expliquei antes, na requisição fica aberto que site você tá tentando acessar, e o Proxy consegue registrar isso. Só de restringir onde pode navegar já é um pé no saco. É compreensível, muita empresa não gosta de ver os funcionários perdendo tempo em redes sociais, então bloqueiam coisas como YouTube ou Facebook. É um pensamento super retrógrado, que era comum no começo dos anos 2000 e eu sei que tem empresas que pensam assim até hoje, infelizmente.

Pois bem. No exemplo da faculdade eu dei um cenário hipotético onde o administrador fez um firewall que bloqueia a saída de pacotes pra 100% das portas com exceção das de web. Mas na prática acho que quase ninguém faz isso. Seria muito pouco produtivo. Você acabaria bloqueando portas úteis como as acima de 49 mil até 65 mil que servem pra coisas como Zoom e outros software de reunião online ou mesmo portas como 25, 193 que são pra clientes de email. Mas as portas de web ficam fechadas e te obrigam a configurar proxy. Então dessa vez não temos portaa 80 de saída pra trabalhar.

Não vou mostrar na prática, mas a solução é simples. Com o mesmo servidor na Digital Ocean que eu tenho, posso configurar aquele daemon sshd não pra porta 80 mas sim pra uma porta como 50000. Uma porta alta que provavelmente não vai estar bloqueado nos firewalls. O remote forwarding que eu fiz, com aquela opção ssh -R, permite alguém de fora acessar um site meu rodando numa máquina privada dentro da rede. Mas o oposto também é possível. Eu posso rodar o seguinte comando, um pouco mais complicadinho: ssh -D 1337 -q -C -N root@ip do servidor de ssh -p 50000

Opções como -q é quiet mode, pra não ficar imprimindo nada no meu terminal, -Cmaiúsculo é pra comprimir o conteúdo que passar por esse programa. -N é pra não abrir uma linha de comando pro servidor. Mas o mais importante é esse -D 1337. Isso vai pendurar esse programa, fazer bind, nessa porta 1337 na minha máquina local. Poderia ser qualquer outro número de porta. O resto é a mesma coisa pra conectar no sshd apontando pra porta 50000 do servidor, o que provavelmente vai conseguir furar o firewall.

Agora, no meu sistema operacional ou direto no navegador, eu procuro a configuração de proxy de novo, mas em vez de colocar o endereço do proxy da empresa, coloco localhost e porta 1337. E pronto, agora posso navegar normalmente por qualquer site que quiser, mesmo se a empresa achar que está me bloqueando. O que fiz foi criar um túnel via SSH, que fica exporto como um serviço SOCKS5, que é o protocolo de um Proxy Web, e pendurado na porta local 1337 da minha máquina. Eu fiz um proxy pessoal, que recebe pacotes HTTP normalmente, como um servidor web, só que ele dá forward, redireciona o tráfego, pro meu servidor da Digital Ocean via esse túnel criptografado via ssh.

O serviço sshd de lá recebe os pacotes que vieram pelo túnel e navega usando a internet da Digital Ocean, que tá toda aberta. O site que eu quis navegar devolve a resposta HTTP pro servidor, e o ssd redireciona o pacote de volta pra mim pelo mesmo túnel. E assim eu burlo toda tentativa de me restringir de navegar. Posso navegar onde quiser. Mesmo a saída da porta 80 na empresa estando fechada por firewall, mesmo sendo instruído a usar o servidor de proxy da empresa, eu criei o meu próprio servidor de proxy saindo por uma porta alta que provavelmente tá aberta no firewall e passei a navegar sem restrição nenhuma. Isso é um exemplo do que se chama de tunelamento.

Mais uma curiosidade. Antes, se eu fosse num site como what is my ip, ia mostrar o endereço IP do proxy da empresa. É a mesma coisa como no caso de CGNAT de provedor. Meu computador tem um endereço privado tipo 192.168 da vida, que não é válido pra rotear na internet. Então todo mundo da rede da empresa vai ter o mesmo endereço IP público, seja por causa de NAT, seja por causa de Proxy. Agora, se navego via o túnel pro servidor da Digital Ocean, o que o site what is my ip vai ser é o endereço IP do servidor. Não só isso, se ele tentar encontrar a posição geográfica desse IP vai ver que está em Nova Iorque, porque eu escolhi montar meu servidor no data center de Nova Iorque. Como programador é importante entender isso: os dados de usuário que sua aplicação web recebe normalmente não representa o computador do usuário, porque a maioria está escondido em redes privadas de NAT ou atrás de Proxy de empresas.

De qualquer forma, com esse truque de tunelamento de SSH, significa que não só burlei as restrições da tal empresa hipotética, como agora posso assistir Netflix como se estivesse nos Estados Unidos, tendo acesso a conteúdo que não tem no Brasil. Então eu burlei também a restrição de região do Netflix. E se o que eu acabei de falar pareceu com aquelas propagandas sobre VPN, é porque tem a ver.

Esse é só um exemplo de coisas que conseguimos fazer quando sabemos um pouco sobre redes. No próximo episódio vou falar um pouquinho de VPN. Por hoje queria mostrar um pouco mais de que tipo de coisas você está perdendo quando se recusa a entender um pouco mais sobre redes. A pessoa hipotética que fez o site de vaquinha e conseguiu disponibilizar na internet com túnel de SSH eu poderia dizer que é o oposto da maioria dos programadores: um péssimo programador, que fez um site cheio de buracos de segurança, mas um bom cara de redes que soube ultrapassar as restrições de firewall e abrir buracos no bloqueio.

Mas no geral ele ganha nota negativa, porque alguém colocar um site que não entende que é inseguro, à força na internet o torna um péssimo profissional. Eu sou o tipo que gosta de quebrar as regras e sempre fiz isso, mas quando faço eu sei os riscos que estou correndo. Não seja esse cara irresponsável, aprenda de tudo um pouco e saiba onde pode ou não pode usar cada coisa. Por exemplo, lá no começo eu disse que faltou sanitizar a mensagem do usuário pra impedir ele de tentar injetar comandos arbitrários pra rodar no servidor. Como que faz isso? Antes de terminar o episódio vamos pelo menos fazer isso.

Existem dezenas de bibliotecas e frameworks como Express já vem preparado pra isso. Mas nesse exemplo besta, vamos fazer nossa própria função. Veja esta função sanitize, ela recebe uma mensagem e passar por uma expressão regular, uma regex. Se não conhecem regex, precisa estudar, é obrigatório saber. Essa expressão procura na mensagem tudo que não é letra minúscula, letra maiúscula ou números e com a função replace ele vai trocar por uma string vazia. Ou seja, coisas com o ponto e vírgula vai ser substituída por string vazia. Agora lá embaixo eu passo a mensagem que peguei da URL por essa função e só depois concateno com o comando cowsay.

Vamos no terminal, rodar essa nova versão do programa e voltar pro navegador. Chamamos http localhost interrogação mensagem com ponto e virgula e um comando como ls e olha só, ele não executa mais o comando, porque eu quebrei a sintaxe. Se alguém achar esse site no ar e tentar executar comandos, não vai mais conseguir, porque só com letras e números, não tem como concatenar outros comandos pra executar e com isso bloqueamos todas as tentativas de injeção. Essa função não é a melhor, porque ela apaga todo caracter especial, então não consigo usar pontuação nas mensagens. Isso é só um exemplo, tem jeitos melhores de fazer isso, mas foi só pra mostrar como é o jeito mais simples e mais drástico de sanitizar.

O recado é simples: tudo que um usuário manda, seja como parâmetros na URL, seja como campos num formulário, tudo deve ser sempre considerado suspeito e deve passar por sanitização. Todo usuário é mau e malicioso até prova em contrário, é assim que devemos considerar todo mundo que acessa seu site. Todo mundo que vai usar seu programa vai tentar quebrar ele. Como programador você tem que estar ciente disso. E é simples: em algum lugar no seu programa você permite o usuário enviar alguma informação? Essa informação é material radioativo, trate ele como tal.

Não tem a ver com o episódio, mas já que falei isso vale outro aviso. Tem gente que fica paranóico demais e faz programação defensiva em excesso e sai colocando tratamento de parâmetros em todas as funções que faz. E está errado. Toda função que é usada internamente não precisa sanitizar tudo toda hora. Só funções que explicitamente recebem dados vindos diretamente de um usuário que precisam disso. Cuidado pra não sair dando copy e paste de sanitização em todo lugar que não precisa e ficar redundante. Ter cuidado não significa atirar pra todo lado. Um bom programador usa sniper, mira e atira com precisão só um tiro e acerta o alvo. Quem atira pra todo lado é claramente amador.

Eu quis fazer esse episódio porque muita gente usa SSH pra se conectar em servidor mas não sabe o que o SSH realmente consegue fazer. Espero que isso tenha servido pra mostrar que você usa ferramentas sem saber pra que elas realmente servem. Interesse-se mais em explorar o que você usa no seu dia a dia. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais!

Agora que todo mudno sabe como funciona o básico de rede, vamos ver como funciona o básico de aplicações de rede, o que são sockets, pra que eles servem, como disso chegamos em protocolos como HTTP ou FTP e os vários detalhezinhos que complicam a cabeça de um iniciante em programação Web.

Conteúdo

• 00:00 - Intro
• 01:36 - Noção de Sockets
• 02:26 - Entendendo Comunicação Entre Processos
• 03:18 - Memória Protegida/Isolada Impede Comunicação
• 05:30 - Comunicação via Pipes
• 07:18 - Comunicação via Arquivos
• 09:56 - BSD Sockets
• 12:43 - Fluxo de conexão
• 16:54 - Portas
• 19:55 - Recapitulando navegador/DNS
• 21:15 - Exemplo de server web com Node
• 22:17 - localhost é diferente de 0.0.0.0
• 23:43 - Continuando Exemplo de Node
• 24:19 - Portas Efêmeras
• 25:47 - Continuando Exemplo de Node
• 29:00 - Debugando com Telnet e Developer Tools
• 31:57 - Camadas de Segurança
• 34:07 - Big Loop
• 37:24 - OSI, TCP, HTTP
• 39:28 - Mostrando FTP
• 42:25 - De redes distribuídas a “walled gardens”
• 45:06 - Bloopers

SCRIPT

Olá pessoal, Fabio Akita

No começo dessa mini-série eu ia só até o episódio passado, mas depois que escrevi, resolvi estender mais três episódios. Estou pulando toda uma parte sobre rede física, MLPS, OLDM, Wimax, 802.11. Vale estudar o livro de redes do Tanenbaum pra esses detalhes, o objetivo é focar mais em assuntos que ajudem programadores e não quem está interessado em seguir na carreira de infraestrutura, por isso eu sei que pra quem é de telecom ou infra tem bastante coisa simplificada. Agora quero ir direto pra camada de transporte e aplicação e nos próximos episódios falar assuntos que o Tanenbaum não chega a explicar no livro.

Só antes de continuar, tem uma errata que esqueci de falar nos videos anteriores, sobre o primeiro video de redes. Lá eu tava tentando simplificar com metáforas pra falar que ondas como de rádio e internet wireless se parecem com ondas na água, mas do jeito que falei ficou parecendo que wireless precisa de um meio como ar pra se propagar, mas claro que não, ondas na água são diferentes de ondas eletromagnéticas, que se propagam no vácuo, diferente de som. Por isso que no espaço não tem barulho, mas satélites conseguem se comunicar. Já tá na errata do episódio mas achei melhor esclarecer.

Todo programador vai ter que lidar com coisas como endereços IP, que já expliquei, e também com as tais portas. Toda vez que você roda um npm start da vida, sobe uma aplicação web nas tais portas 3000 ou 4000. Todo tutorial só menciona isso: magicamente funciona. Mas não explica o que está acontecendo de verdade. É hora de entender a mágica. O episódio de hoje é sobre sockets.

(…)

Em resumo bem resumido, pense em sockets literalmente como tomada da sua casa. Diferentes portas tendo diferentes padrões de buracos, como o padrão brasileiro sendo uma porta, padrão europeu sendo outra, padrão americano outra e assim vai. E só plugues corretos encaixam em determinadas tomadas. Por isso seu notebook importado não encaixa na porcaria da tomada do Brasil. +

Na prática o conjunto de endereço IP e porta de saída, digamos, do seu navegador conectando num site, e o endereço IP e porta de entrada do tal site, essas quatro informações é o mínimo pra definir um socket. É o plug e a tomada conectada. Não se atenha tanto ao nome mas a esse conjunto de informações, é o que se precisa pra formar uma conexão de rede entre dois processos, que é o caminho que os pacotes que falamos antes vão trafegar.

Sockets, na verdade, é uma forma de comunicação entre processos. Todo sistema operacional existe pra gerenciar processos. Expliquei isso nos videos de Programação pra Iniciantes, em particular nos de concorrência e paralelismo e gerenciamento de memória. Processo é todo programa que tem rodando no seu computador, seja seu spotify ou banco de dados. No nível mais básico, um processo é representado por um número, um process ID ou PID que o sistema operacional dá pro seu programa. Quando do terminal de um Linux se digita ps -ax dá pra ver os processos e seus PIDs. O sistema operacional aloca uma certa quantidade de memória e internamente, seu processo acha que tem acesso a toda memória teórica de 64-bits, mas na realidade o sistema operacional é quem intermedia o acesso à RAM ou Swap de disco.

Isso é importante. Um processo é como uma criança rica mimada gastando cartão de crédito dos pais. Ele não tem noção que tem limite, e só vai gastando, e os pais, que é o sistema operacional, vai sempre só pagando, então essa criança tem a ilusão que tem dinheiro infinito. É mais ou menos assim. Seu PC tem só 8 giga de RAM real, mas seu processo acha que tem do endereço 0 até 2 elevado a 64 de memória, que seria o máximo teórico de 16 exabytes. Nenhum computador de verdade tem exabytes de RAM ainda. Isso é importante de entender então vou insistir com outra metáfora.

Cada processo rodando na máquina enxerga uma memória virtual, de 0 até 16 exabytes. Quando falamos que se consegue endereçar memória, na realidade pense assim: Imagine um livro com uma parte de índice no começo. O índice tem espaço pra 16 exabytes de linhas, mas o livro em si não tem 16 exabytes de páginas, saca? Todos os processos estão compartilhando a mesma memória física de 8 gigabytes reais, mas ele só enxerga o índice.

O sistema operacional intermedia e garante que um processo não consiga acessar a memória real inteira, as páginas do livro, de outro processo. Por isso falamos que rodam isolados, sem um sobrescrever a memória do outro. Eu explico sobre isso nos episódios sobre gerenciamento de memória. Mas a parte importante é entender que um processo não enxerga nunca a memória de outro processo. Ele acha que está sozinho na máquina.

Antigamente, nos primeiros computadores sem isolamento de memória, um processo poderia escrever num endereço de memoria real e um outro processo poderia ler essa informação diretamente desse endereço. Um livros sem índices. Na época dos computadores de 8 e 16 bits era mais ou menos assim. Até a Intel inventar memória protegida. Todo processo enxergava todas as páginas e poderia escrever em qualquer lugar. Endereçar memória diretamente era mais rápido mas levava a dezenas de bugs de um processo escrevendo em cima de endereços que outro processo tava usando, levando desde a comportamento não-determinístico até a crashes. Isso era menos ruim quando a gente só rodada um programa de cada vez, na era do MS-DOS. Mas nos primeiros Windows isso já era um problemão.

Desde que passamos a isolar os processos e demos endereços virtuais em vez de reais, pelo menos essa categoria de bugs foi extinta, já na época do Windows 3.1 e foi melhorando a cada nova versão. Também significa que se um processo quiser se comunicar com outro processo, não tem como, porque não tem como gravar algo na memória que outro processo possa ler diretamente. As únicas duas formas de dois processos se comunicarem ou é via pipes ou via arquivos. Vamos entender.

Pipes de Linux é simplesmente ligar a saída padrão de um programa na entrada padrão de outro programa, o stdout ligado ao stdin via um pipe, ou cano. Que nem quando fazemos cat algum_arquivo pipe grep alguma coisa. Expliquei um pouco disso no episódio de Ubuntu se quiser relembrar. Isso significa que um programa roda primeiro, cospe algum resultado no stdout, e esse resultado é passado pro stdin, pra entrada, do próximo programa. É uma forma de dois programas diferentes se comunicar, mas é uma forma serial: um programa precisa rodar primeiro até o fim, terminar, e só depois começa o outro.

Portanto é mais complicado se eu quero os dois programas rodando em paralelo, sem um esperar o outro terminar. A única outra solução é um programa ficar cuspindo coisas num arquivo e o outro programa ficar lendo desse arquivo. Esse arquivo serve de ponte, de stream de entrada e saída pra ambos, criando um tipo de conexão. Isso resolve o problema deles conseguirem rodar em paralelo, ao mesmo tempo. Como exemplo, pense num programa que vai gravando coisas num arquivo de log e pense outro programa como o Prometheus, que vai lendo esse log e organizando a informação. Arquivos é uma área compartilhada que dois processos podem usar pra se comunicar, já que memória é isolada.

Todo iniciante precisa se acostumar a lidar com arquivos. Sem entrar em detalhes, na maioria das linguagens, você manda abrir um arquivo a partir de um path ou caminho, que é a sequência de diretórios e sub-diretórios separados por uma barra e o nome do arquivo com extensão. Isso abre o que chamamos de um stream, pense como se fosse um cano de bits bidirecional, um rio onde flui bits. Agora podemos ou ler ou escrever nesse stream.

Podemos ler bit a bit, ou pedir pra ir enchendo tipo um balde antes, um buffer, um acumulador, pra pegar linha a linha de cada vez, por exemplo. Mesma coisa pra escrever, podemos jogar bit a bit nesse stream, ou preencher um buffer antes e mandar vários bits de uma só vez, como uma linha inteira. Podemos programar pra deixar encher esse balde, e quando tiver uma certa quantidade de bits ou quando vier algum caracter especial como uma quebra de linha, pedir pra notificar o programa pra fazer alguma coisa com o que veio. De novo, a maioria das bibliotecas de linguagens modernas já cuidam disso e você como programador só lida com coisas como linha a linha. Mas por baixo existem coisas como buffers.

Vale lembrar que se você programar numa linguagem um pouco mais baixo nível, tipo C, Rust ou até Java, vai lidar mais com esses conceitos de buffers. Java tem classes como Buffered Stream, por exemplo. Numa linguagem mais alto nível como Javascript, ele cuida disso pra gente por baixo dos panos, e você só fala “vai lendo de linha a linha e vai me dando”. Bibliotecas de linguagens de alto nível foram feitas pra oferecer produtividade ao custo de dar menos controle. Por outro lado é o velho 80/20, pra 80% das coisas que precisa, o 20% que oferece por padrão costuma ser suficiente. Pros outros 20%, aí precisa descer pra um C da vida.

Só pra ter de referência aqui, como que em Javascript com Node dá pra escrever e ler de um arquivo? Primeiro carrega a biblioteca “fs” de filesystem e ele tem várias funções como esse writeFile onde passo o nome do arquivo e o conteúdo como String. Se não der nenhum erro, podemos usar readFile pra ler o conteúdo que acabamos de escrever e mostrar na tela com o bom e velho console.log. Mas o principal é entender que a semântica são funções como essas, read alguma coisa, write alguma coisa.

`var fs = require(“fs”); fs.writeFile(‘hello.txt’, ‘Hello World’, function(err) { if (err) { return console.error(err); }

fs.readFile(‘hello.txt’, function (err, data) { if (err) { return console.error(err); } console.log(“read: " + data.toString()); }); });`

Enfim. Com pipes e arquivos, você tem o mínimo suficiente pra fazer dois processos comunicarem entre si mesmo sem compartilhar memória RAM. Esse tipo de técnica fica embaixo de um guarda chuva de assuntos que chamamos de IPC ou inter process communication. Existem outras formas de comunicação como sinais, mas só isso é suficiente pra hoje. Se você só tem um computador, isso é suficiente. Mas aí lá nos anos 60 inventaram um troço que fodeu esse esquema. Essa tal de rede.

Com redes, temos mais de um computador rodando em paralelo e seria bacana se um processo rodando em um computador pudesse falar com um processo rodando em outro computador. E seria mais legal ainda se pudéssemos usar uma semântica parecida com lidar com arquivos, sem de fato usar arquivos. Ter comandos parecidos como “read” ou “write”, ler ou escrever num stream de bits. Pensando assim que em 1983 surge a implementação de Berkeley Sockets no UNIX original BSD versão 4.2.

Por isso são chamados de BSD sockets, de Berkeley Software Distribution ou POSIX sockets. POSIX que é o conjunto de APIs e protocolos que define o que é um UNIX. Pra entender um pouco mais sobre UNIX e Linux e licenças de software livre, não deixe de assistir o episódio de Apple e GPL que fiz faz tempo. BSD Sockets se tornou meio que o padrão de como lidamos com comunicação entre processos de forma mais geral.

Já vimos nos episódios anteriores dessa mini-série de redes, como que informação é fragmentada em pacotes, e como esses pacotes são transferidos numa rede de um computador até outro, seja numa rede local ou seja na internet em geral. Vamos assumir que tudo isso funciona e que os sistemas operacionais sabem como produzir pacotes e enviar na rede e consumir pacotes que chegam da rede, seja via fibra ótica, cabo de cobre ou rede sem fio.

Não por acaso venho me repetindo bastante sobre sistemas de armazenamento: como HDs são dispositivos de blocos e não dispositivos de arquivos. No baixo nível do hardware, sistemas operacionais lidam com blocos de bits num HD ou blocos de bits em pacotes de rede. Tudo são blocos, toda informação é fragmentada e transferida num stream. Podemos fazer buffers de blocos. Se blocos de bits forem arquivos num HD, podemos pensar em blocos de bits que vem pela rede meio como arquivos também. As abstrações são parecidas embora no meio físico sejam diferentes. No fim do dia você está lendo bits de algum lugar e escrevendo bits em algum lugar, esse é o conceito principal.

Não é a definição exata mas a grosso modo poderíamos pensar em sockets como uma generalização das primitivas de arquivos. Um Linux entrega um file descriptor ou file handle pro seu programa, tanto se for um arquivo local no seu HD ou um socket de rede. Pense em um handle ou descriptor como uma caixa preta que representa um arquivo, um intermediário pra quem você pede pra receber bits ou enviar bits. E essa caixa preta poderia ser um arquivo em disco, mas poderia ser uma conexão remota em rede. Tem uma preparação extra que precisa fazer pra se comunicar na rede e em toda linguagem de programação vai ser parecido. O protocolo que os Berkeley Sockets definiram funciona mais ou menos assim.

`const http = require(‘http’);

const hostname = ‘127.0.0.1’; const port = 3000;

const prepareResponse = (req, res) => { res.statusCode = 200; res.setHeader(‘Content-Type’, ’text/plain’); res.end(‘Hello World\n’); }

const server = http.createServer(prepareResponse);

server.listen(port, hostname, () => { console.log(Server running at http://${hostname}:${port}/); });`

Primeiro seu programa pede um bind pro sistema operacional. Bind é literalmente ligação, a ligação de um endereço IP com um outro número de 16 bits que chamamos de porta. Bind é um pedido de registro. Funciona assim. Todo processo quando inicia, o sistema operacional oferece um número de identificação, o tal PID. Só que esse PID muda o tempo todo. Hoje seu Spotify inicia com PID 10. Mas amanhã pode já ter outro programa com PID 10, então o sistema atribui PID 11 ou qualquer outro número. PIDs identificam programas rodando naquele momento, mas não servem pra identificar um programa individualmente a qualquer momento. Então precisamos de outro número que seja fixo que o programa possa pedir pra se registrar.

Digamos que seu programa peça pro sistema registrar ele com o número 3000. O sistema operacional mantém uma tabela em memória e poderia associar o PID atual do seu programa, digamos que seja 11, com esse número 3000, que ele chama de porta, ligados ou bound num endereço IP. Porta é um número que identifica um processo que o sistema operacional mantém numa tabela de controle na memória dele. Se ninguém antes pediu pra registrar essa porta, o sistema te associa nela e nenhum outro programa pode pedir pra se ligar na mesma porta. Porta é só isso, um identificador do programa rodando ligado ao endereço IP do computador.

Quando o sistema consegue te associar nessa porta 3000, devolve um ok pro programa e devolve o equivalente a um stream de bits, o cano aberto, como se tivesse acabado de conseguir abrir um arquivo. E agora seu programa pode entrar em modo de escuta, ou listen. Nesse momento ele fica bloqueado esperando o sistema te mandar alguma coisa por esse cano e não precisa fazer mais nada enquanto isso. Normalmente isso fica numa thread bloqueada ou é usado I/O assíncrono, que não é escopo explicar hoje. Só entenda que depois do bind, seu programa ficaria parado esperando e escutando o que vier através dessa porta 3000. O processo de bind e listen de sockets é similar ao processo de dar open e abrir um arquivo.

Daí alguém na rede resolve mandar alguma informação, pro endereço IP do computador onde ele tá rodando, e mandando junto que quer falar com seja lá quem está ligado nessa porta 3000. O sistema operacional recebe isso e vê, “hum, quem tá escutando na porta 3000, vamos ver na tabela, ah é o processo de PID 11, vou mandar no cano aberto dele”. Agora seu programa, que estava só escutando, começa a receber bits. Nesse momento ele pode escolher aceitar ou rejeitar, normalmente só se aceita, isso é o passo de accept.

E é no accept que fecha o que se chama de conexão entre este computador e o outro que pediu a conexão. O socket serve pra estabelecer essa conexão, esse stream de bits, entre dois programas rodando, mesmo se for em máquinas diferentes. E agora os dois programas precisam enviar comandos que ambos entendam. Se seu programa receber bits que formam um comando válido, pode começar ou a receber ou a enviar bits de volta pela mesma conexão. Aqui é a metáfora das tomadas de padrão diferente.

Pra comunicação acontecer, ambos precisam concordar que comandos aceitam trocar. Esse acordo entre as duas pontas é o tal de protocolo. Pense em protocolo como sendo os pinos nas posições corretas que encaixam certo nos buracos da tomada. Mesmo tendo um processo pendurado numa porta, se ele não for um servidor web, não adianta um navegador web tentar se comunicar nele, eles não vão se entender e só vai dar erro. Por exemplo, se um navegador web tentar se conectar com um servidor de banco de dados, só vai dar erro, porque o banco de dados não entende comandos de HTTP que o navegador manda.

Falando bem resumido, esse é o básico do básico do básico de programação distribuída em rede. Toda linguagem vai te dar bibliotecas e funções que tem nomes parecidos com esses passos, bind, listen, accept, send. Apesar da sintaxe de cada linguagem ser diferente, podem ver que em todas é o mesmo processo, porque as primitivas no sistema operacional são as mesmas e as tecnologias de rede são as mesmas. Independe da linguagem, o jeito de falar em rede é sempre a mesma. Eu sempre falo que é mais importante saber a fundação do que uma linguagem só, porque se você aprendeu isso em C, facilmente vai conseguir fazer a mesma coisa em Java ou Python.

Do lado do sistema operacional, entenda que portas é só uma tabelona com identificadores numéricos de 16-bits, onde é possível associar 2 elevado a 16 portas no total, de 0 até 65 mil 536. Por isso você nunca viu número de portas acima disso. Essa tabelona diz que se receber bits endereçados pra um IP e porta, ele sabe pra qual cano de qual processo rodando enviar. Agora vamos entender isso a partir do programa mais comum pra se comunicar em rede hoje, seu navegador web, como Chrome ou Firefox.

Seu navegador é um exemplo desse tal programa que pede uma conexão, um cliente. Ele não precisa fazer bind, porque não precisa que ninguém se conecte nele. Ele só quer se conectar na porta dos outros, de um servidor web. E é isso que diferencia um cliente de um servidor. Um servidor faz bind e listen numa porta e fica esperando, escutando. Um cliente envia pacotes pro endereço IP do servidor e pede pra se conectar num programa rodando lá que está escutando numa determinada porta. Pra isso funcionar, o cliente precisa saber não só o endereço IP como em qual porta o servidor está escutando. E por isso se estabeleceu que certas portas são exclusivas pra um determinado uso.

Mas não se enganem, portas são só números numa tabela que o sistema operacional gerencia. Os usos de cada número de porta são completamente arbitrários, determinados por consenso, e pro programa em si não faz nenhuma diferença se ligar numa porta 80 ou 3000 ou 8080. Não existe nenhum tratamento especial diferente. Portas são só números. E por isso você sobe uma aplicação web feita em Node numa porta 3000 e ela funciona igual quando subimos na porta 80 num servidor na Amazon.

Por convenção, estabeleceu-se que as primeiras 1024 portas, de 0 até 1023 são portas de sistema, e num Linux precisa ter permissão de root pra fazer um programa se registrar numa delas. Essa distinção existe porque vários usuários podem abrir sessões num mesmo servidor UNIX ou Windows Server, mas só o administrador pode subir processos em portas abaixo de 1024. Usuários nesse servidor podem subir processos em outras portas menos nessas. É nesse intervalo que se encontram as duas portas mais famosas de todas, a 80 de HTTP e 443 de HTTPS. Temos outras famosas, como porta 21 de FTP, porta 22 de SSH, porta 25 de SMTP pra envio de emails, porta 37 que usamos pra sincronia de horário via NTP, porta 53 que é DNS, porta 194 é de IRC, 993 pra IMAP de cliente de email e assim por diante.

Existe uma organização que registra o uso dessas portas baixas, a IANA ou Internet Assigned Number Authority. Dá pra ligar qualquer programa numa porta baixa, mas normalmente essas portas costumam ter serviços específicos como servidor web ou DNS. Por isso que num navegador quando digitamos endereço, podemos omitir a porta, porque o navegador preenche a porta pra gente usando essas convenções. Quando digitamos http://www.google.com primeiro ele precisa resolver esse nome de domínio, pra isso resolve esse nome num endereço IP e pra isso precisa de um name server ou DNS.

Já mostrei no episódio anterior como seu sistema operacional pergunta quem é esse nome pra um DNS, como o 1.1.1.1 da CloudFlare ou 8.8.8.8 do Google. O DNS vai te devolver um grupo de endereços IP e seu computador escolhe um deles. A partir desse ponto faz um cache disso localmente. Se no navegador pedir de novo o <www.google.com>, nem precisa pedir pro DNS, porque já tem gravado num cache local. Toda resposta de DNS tem uma coisa chamada TTL ou time to live, que é tipo uma expiração. Quando expirar, aí sim seu computador vai no DNS e pergunta de novo qual é o endereço do nome <www.google.com>. Em outro video vou explicar DNS com um pouco mais de detalhe mas se acostumem com esse conceito primeiro.

Enfim, graças ao DNS ou o cache local de DNS, seu navegador agora tem um endereço IP. Ele pode começar a se conectar. Mas como disse antes, precisa saber em que porta nesse endereço vai estar o programa que vai te devolver os HTMLs. Esse programa chamamos de servidor web, e como falei antes, por convenção, vai estar escutando nas portas 80 ou 443. Se no navegador você digitou http:// significa que quer conectar na porta 80. Se digitar https:// quer dizer que quer conectar na porta 443. O que vem antes dos dois pontos é com qual protocolo quer se comunicar com esse servidor, no caso HTTP ou HTTP com TLS.

Protocolos é quem definem os tais comandos e valores que ambos o navegador e o programa servidor web conseguem entender, os pinos certos pros buracos certos da tomada. No protocolo HTTP temos comandos em texto como GET ou POST pra pedir ou enviar coisas do navegador pro servidor. Vamos fazer um exemplo simples só pra consolidar o conceito. Vou fazer rapidinho um servidor web em Node.js estilo hello world, só pra ter um programa escutando numa porta. Isso você encontra quinhentos tutoriais na internet não vou detalhar muito.

Olha esse do tutorial do próprio site oficial do Node.js. Primeiro ele carrega a biblioteca “http”. Em seguida declara duas variaveis, uma pra guardar o endereco 127.0.0.1. Esse é o endereço que chamamos de loopback, ele representa o endereço local de rede do seu computador. Todo pacote enviado pra esse endereço não vai sair do seu computador, ele vai devolver pra ele mesmo. Por isso chamamos de loopback. Vale entender isso porque muita gente acha que 127.0.0.1 é a mesma coisa que outro endereço, o 0.0.0.0 e não sabe a diferença.

Normalmente um endereço IP é associado com uma placa de rede instalado na sua máquina, mas 127.0.0.1 é como se fosse uma placa de rede virtual, de mentira. Ele recebe pacotes e devolve pra ele mesmo. 127.0.0.1 é a mesma coisa que localhost. Quando damos bind de um processo nesse endereço, dá pra abrir o navegador e conectar por ele com http://localhost. Mas se alguém de fora tentar se conectar no mesmo serviço, na mesma porta, não vai conseguir, porque na placa de rede de verdade não tem bind nessa porta. Localhost só é acessível de dentro do próprio computador, não de fora.

Tem também o endereço 0.0.0.0 que significa “qualquer placa de rede do computador”. Quando queremos pendurar um servidor que vai receber bits independente de por qual placa de rede do seu computador vier, penduramos ele no 0.0.0.0. E no navegador podemos digitar localhost porque 127.0.0.1 é um desses “qualquer placa de rede”, mas também um navegador em outro computador na rede, vai conseguir se conectar no seu programa. Todo computador responde nesses endereços locais. Muita gente pensa que são a mesma coisa, mas só localhost e 127.0.0.1 são a mesma coisa. Pra desenvolvimento a gente usa localhost, porque normalmente não queremos outra pessoa na mesma rede acessando enquanto estamos no meio do desenvolvimento. Mas num servidor de verdade queremos dar bind em 0.0.0.0 pra deixar o programa acessível a qualquer pessoa.

A segunda variável define que quer se ligar na porta 3000. Eu expliquei que portas de 0 até 1023 são reservados e o sistema operacional exige permissão de administrador pra ligar um programa nessas portas baixas. Por isso que em máquina de desenvolvimento, preferimos usar portas de 1025 até 49 mil 151. Porque com suas permissões de usuário normal, pode pedir pro sistema ligar seu programa numa porta, sem privilégios especiais, sem precisar ficar usando o comando sudo toda hora. Por isso que pra subir uma aplicação de Node.js ou Django ou Laravel, numa porta como 3000 ou 4000, não precisa executar com sudo.

Pra complementar, de 49 mil 152 até 65 mil 535 são o que chamamos de portas dinâmicas ou privadas. Em particular 49 mil 152, que é um número difícil de decorar em decimal, mas é a mesma coisa que 2 elevado a 15 menos 2 elevado a 14, que é mais fácil de lembrar. Também são chamadas de portas efêmeras. Você até pode mas normalmente não se registra nenhum programa servidor que vai ficar rodando permanentemente nesse segmento. Essas são as portas usadas, por exemplo, por comunicadores como o Zoom ou Skype pra abrir conexão com outra pessoa na internet. Pode ser usado por games pra sessões multiplayer. São portas temporárias. Programas de comunicação tentam diversas dessas portas e usam a primeira livre que acharem. Não é regra, mas eu acho que programas que usam UDP em vez de TCP usam mais essas portas.

Por isso que nós programadores web, quando fazemos uma aplicação usando Node.js ou Spring ou Laravel ou qualquer coisa assim usamos portas como 3000, 4000, 8000, 8080 como era o Tomcat de Java e assim por diante. Qualquer uma depois de 1024 e antes daqueles 49 mil e tanto servem. Sem interferir com calls de Zoom e sem precisar de privilégios de administrador e ter que ficar digitando sudo. De novo, portas são só números. Se você achava que porta 8080 ou 3000 tinha algum significado, não tem, foram escolhidas arbitrariamente por alguém e todo mundo só usa a mesma porta por convenção.

Enfim, agora é específico de cada linguagem e framework, mas no caso do Node criamos uma instância do que ele chama de “server”. Eu modifiquei um pouco o exemplo do tutorial porque quando criamos o servidor já registramos como queremos que ele responda quando vier algum comando de HTTP. Já volto nisso. Na sequência, fazemos essa instância de server pausar e ficar escutando, esperando alguma coisa, que o sistema operacional vai mandar pra gente no cano dessa porta 3000. Se ninguém mais estava pendurado na porta 3000, e ele conseguir se ligar com sucesso, daí escreve essa mensagem de servidor rodando. E pronto, agora está escutando na porta 3000 desse computador.

Vamos voltar pro navegador. Lá no campo de endereço escrevo que quero usar o protocolo “http”, dois pontos, barra, barra, localhost que é outra forma de dizer “127.0.0.1”, dois pontos, porta 3000. Se eu não colocasse explicitamente esse dois pontos 3000, ele ia assumir que seria porta 80. Tenta aí, em qualquer site como google.com, digita no final dois pontos 80. Vai ver que dá no mesmo.

E pronto, veio uma resposta Hello World. Vamos voltar pro código do servidor. Lembra que quando criei a instância de server registrei uma função de resposta? O framework do Node esconde os detalhes. O Linux recebeu os pacotes de bits do navegador endereçados pra porta 3000, viu que tinha meu programa pendurado nele e começou a reenviar os pacotes pro cano da porta 3000.

O meu programa em Node começa a receber pacote e dá accept. E aí vê o que fazer com esses pacotes. Daí tinha essa minha função registrada no server. Ele encapsula esses pacotes numa estrutura chamada Request, ou HTTP Request. É isso que faz essa biblioteca “http” que estamos usando. Ele se encarrega de receber os bits e organizar tudo bonitinho nesse objeto de Request pra gente. A partir desse ponto eu posso fazer lógica de código pra fazer coisas diferentes dependendo do que vier nessa request, como carregar um arquivo HTML. No caso, como é um exemplo besta, eu só mando responder a mensagem de Hello.

Mas não é só a mensagem. Isso é um protocolo, tem algumas regrinhas. O mínimo do mínimo que se espera de resposta é montar uma segunda estrutura chamada HTTP Response. Nesse response registro um status code 200, que é o código do protocolo HTTP pra dizer que tá tudo ok, daí por boa etiqueta, registro também um cabeçalho com um mime type, no caso pra indicar que não vou responder um HTML e sim só um texto puro. É com esse mime type que o navegador sabe se é pra interpretar como HTML ou se é um binário e é pra fazer download, por exemplo. E finalmente, posso escrever minha mensagem de hello no response como um simples string.

O Node vai pegar esse pacote de response que preenchi e mandar pro sistema operacional devolver pela rede pro navegador pela mesma conexão. E o sistema operacional por baixo vai fazer tudo que já expliquei antes, vai quebrar esse response em datagrams, vai encontrar a rota pra enviar, etc. E no final o navegador vai receber o pacote de resposta e interpretar isso visualmente na tela, desenhando o hello na tela pro usuário. Esse é o fluxo mais básico de web. Se não entender nem isso, não vai entender nada mais complicado, então garanta que esse fluxo está super claro na sua cabeça.

Tem outra forma de ver como isso funciona. Antigamente todo sistema operacional vinha com um programa de internet bem simples chamado telnet. É um programa que se conecta em qualquer porta que tenha algum outro programa escutando e com ele posso manualmente digitar comandos pra enviar, caso eles aceitem comandos em texto em vez de binário. No caso do Arch Linux hoje ele fica no pacote opcional chamado de inetutils. Em nenhuma distro se instala mais por padrão porque acho que é considerado um risco de segurança. São ferramentas que precedem o conceito de encriptação. Em vez de telnet hoje se usa SSH pra abrir conexões encriptadas, mas como não quero ter que lidar com criptografia neste episódio, deixa eu mostrar o bom e velho telnet.

Aquele meu programa de hello de Node continua rodando. Ele tá pendurado na porta 3000 e mesmo quando processa a requisição de algum navegador, continua aceitando novas requisições de outros navegadores. Por isso que um servidor web consegue atender várias pessoas ao mesmo tempo. Vamos abrir um outro terminal e conectar direto nele usando telnet, passando o endereço e a porta.

Pronto, estou conectado. Agora posso enviar uma requisição HTTP manualmente. O protocolo HTTP diz que posso digitar o comando GET seguido de uma URI que é o barra alguma coisa e no final escrever HTTP/1.0 denotando a versão do protocolo que estou querendo usar. Isso é tudo texto. Nas linhas seguintes posso mandar outros detalhes desse comando, mas se der dois enters, duas quebras de linha, isso indica pro servidor que terminei minha requisição.

E olha só, quando dei dois enters, o Node entendeu que podia começar a responder, e essa é a resposta que ele envia. Olha só o que tinha mandado ele preencher na tal estrutura de resposta. O status code 200 veio na primeira linha, seguido do content type que é texto puro, mais uma data e horário que o framework preencheu pra mim e o fechamento da conexão seguido do corpo da resposta que é o string da mensagem hello.

Claro, hoje em dia não preciso de telnet pra ver isso. Todo navegador agora tem o tal Developer Tools, que se acessa com o atalho control shift J no Windows ou control option J no Mac. Ele tem essa aba Network ou rede, onde podemos ver os pacotes de request e response e os cabeçalhos. Mesma coisa que fizemos no telnet, olha como no request ele mostra que o navegador fez um comando GET e embaixo temos a mesma resposta que recebemos via telnet, status code 200, content type text plain, a data e horário. Antes de existir Dev Tools a gente usava coisas como Telnet pra debugar.

Em linhas gerais é assim que um navegador, um cliente de APIs e tudo mais que fazemos na web funciona. Com o navegador conectando na porta 80 ou 443 ou numa porta de usuário como a 3000 do meu Node.js. O navegador monta uma estrutura em texto chamada request, um servidor feito em qualquer framework como Node da vida recebe, decide o que fazer baseado no que foi pedido, monta uma outra estrutura chamada response e devolve. Esse é o básico do básico de web.

A porta 443 e TLS é uma camada a parte. É um processo que acontece entre seu navegador e o servidor web, independente da aplicação por baixo. Esse meu hello em Node não precisa estar ciente que a conexão estava ou não criptografada. O navegador pede um handshake, um aperto de mão, com o servidor que, se estiver devidamente configurado com certificados SSL, vão abrir uma conexão segura usando chaves assimétrica, trocar uma chave simétrica, e a partir daí todo pacote que o servidor web envia vai criptografado e o navegador consegue descriptografar e vice versa. Eu explico isso na parte 2 dos meus videos sobre criptografia.

Mas eu digo que tanto faz porque o programa Node por baixo vai receber a request já descriptografado direitinho, como se nada tivesse acontecido. E em redes existe isso de cada camada na arquitetura trabalhar os pacotes trafegando e as camadas de cima, como minha aplicação, não precisar estar cientes e funcionar normalmente. Se não sabia o que é uma boa arquitetura, a arquitetura OSI de camadas de rede é uma boa inspiração, onde cada camada tem sua responsabiilidade, cada camada não precisa estar ciente se uma camada embaixo foi adicionada ou trocada, contanto que realizem as mesmas tarefas. Programação de software pra rede costuma ter essa metáfora de camadas de uma cebola. Quem já brincou de Tor e coisas assim já deve ter ouvido falar de Onion, por isso. Outro dia falo de coisas como Tor.

Um navegador web como Chrome é um dos softwares mais complexos que você tem instalado no seu computador depois do próprio sistema operacional, especialmente pra renderizar a parte gráfica corretamente. Mas pra se conectar num servidor web e mandar comandos simples de GET, um mero telnet como mostrei já serve. Vários outros programas simulam um navegador simples como os programas wget ou curl de Linux, que a gente usa mais pra fazer download, mas tecnicamente ele se comporta como um navegador web. Ou bibliotecas que usamos pra fazer clientes pra APIs como o Axios de Javascript, ou a classe HttpClient de Java ou C#, ou a classe http.client de Python e assim por diante. São todos mini navegadores, sem a parte gráfica.

Se nunca pensou assim, um servidor é todo programa que pede um bind de uma porta pro sistema operacional e fica em modo listen de escuta, esperando pra dar accept e abrir uma conexão com outro computador remoto. Aliás, vale outro conceito básico. Eu categorizo programas em dois tipos, short lived e long lived. Ou em bom português, programas de tiro curto e programas persistentes. Programa de tiro curto são muitos dos que você roda via linha de comando, comandos como o grep, sed, ou awk de Linux, programas que recebem um input, processam alguma coisa, cospem um resultado e saem fora. Servidores ou programas persistentes são loops.

Vamos desconsiderar por um segundo que existem threads, I/O assincrono, e que tudo seja como era antigamente, quando só dava pra rodar um comando bloqueante e síncrono por vez. Se eu fosse escrever numa pseudo-linguagem, ou seja, uma linguagem que não existe, a estrutura mais básica de um servidor de rede seria assim:

`while(true) { listen(:3000)

stream = accept() while(not stream.eof) { request += stream.read_line } response = processa_alguma_coisa(request) send(response) }`

Todo servidor fica num loop infinito até receber sinal do sistema operacional pra morrer, o tal SIGTERM ou sinal de término, que se você já usou Linux, já enviou com o comando kill. Ou no Windows via powershell com o comando taskkill. Enfim, entenda que se executar um programa e ele tiver o comportamento de esperar um evento, reagir, e voltar a esperar, normalmente é um loop, equivalente a um while true.

Dentro desse while, ele manda comando pro sistema operacional, o listen, pra pedir pra ficar esperando o que vier numa porta, como 3000. Nesse ponto que eu falei pra ignorar que existe threads e concorrência. Faz de conta que quando ele dá listen, fica parado nessa linha até receber alguma coisa. Uma hora alguém conecta e começa a enviar bits. Daí sai dessa linha e cai no accept onde recebe o stream de bits, o tal cano de bits. Agora eu fiz um pseudo código arbitrário que é ficar lendo linha a linha até sinalizar eof que, se nunca viu, costuma ser sigla pra end of file, que terminou o envio ou acabou o arquivo.

Agora, o programa faz alguma coisa com esses bits que vieram, que chamei de request, e monta alguma resposta, que é a estrutura de response. No final envia de volta ou dá send desse response, pedindo pro sistema operacional devolver, pela mesma conexão fechada no accept, e o loop reinicia esperando outra requisição. Volta pro estado de listen, até aparecer mais bits. No mundo real existem threads e na realidade uma das coisas que pode acontecer dependendo da linguagem é o accept abrir uma nova thread pra processar o request e response enquanto o loop de listen continua ativo esperando mais conexões. Possibilitando lidar com dezenas ou centenas de conexões simultaneamente.

Aproveitando o conceito. Todo programa gráfico é um grande loop também. Ele fica esperando você digitar alguma coisa ou clicar alguma coisa com o mouse, é parecido com esse listen. E fica no loop infinito até receber um sinal pra fechar como o menu de Quit ou alt-f4 no Windows. Um game também é um grande loop, esperando seus comandos e reagindo. Essa é a fundação pro que muitos chamam de programação orientada a eventos original. O programa reage a eventos, como input de mouse e teclado ou algo assim. Não vou entrar em paradigmas, mas só pra lembrar que esse é um dos patterns mais comuns em programação, o que eu pessoalmemnte chamo de Big Loop.

Normalmente, em web, a gente fica muito preso ao protocolo HTTP, onde as duas peças principais são a tal estrutura texto de HTTP Request e HTTP Response e comandos básicos como GET, POST ou PUT. Todo tutorial de web começa direto neles. E por causa disso muita gente faz o que não devia, tentando embutir tudo que pode dentro dessas estruturas. Mas a internet não é feita só de HTTP, ela só é a mais popular. Muitos falam “internet” pensando em redes, roteadores, pontos de acesso. E chama o resto de Web. Mas Web, que é o nome mais curto pra World Wide Web, que se refere à capacidade de hipertexto de páginas HTML. A idéia que uma página pode ter links pra outras páginas formando uma teia, ou Web.

Mas internet na realidade é um conjunto de tecnologias, que envolve coisas como ethernet, wifi, fibra, o TCP/IP e todos os outros protocolos de aplicação, incluindo o HTTP de Web. E chamamos assim porque como expliquei antes, o modelo OSI de internet define sete camadas. A camada física que foi o episódio que expliquei sobre ondas, cabos de cobre e wireless. A camada de data link responsavel entre outras coisas como checar erros, como eu expliquei sobre Hamming Code e tudo mais. A terceira camada, de rede é que lida com coisas como roteamento, endereços IP e tudo mais.

Eu pulei as camadas seguintes, a camada 4 de transporte, a camada 5 de sessão, a camada 6 de apresentação e a camada 7 de aplicação. Isso porque em TCP/IP as funções da camadas acima da 5 acabam sendo acumuladas na camada de aplicação, que é onde mora protocolos como HTTP de Web.

Em OSI existe uma camada pra lidar com sessões, mas em Web controlamos sessão direto no HTTP usando cabeçalhos como de cookies. Sessões servem pra literalmente identificar uma sessão individual de cada usuário e no modelo OSI esse controle ficaria na camada 5, mas a gente acaba achando mais fácil acumular isso direto na camada de aplicação. Por isso em vez de ter um jeito único de lidar com sessões, protocolos como HTTP, FTP, IMAP e tudo mais, cada um controla sessões do seu jeito. Tem vantagens e desvantagens de se fazer isso.

Exemplo de outro protocolo era o antigo FTP ou File Transfer Protocol que hoje em dia ninguém mais usa pelo mesmo motivo que não se usa Telnet, ambos precedem conceitos mais modernos de segurança. Muitos antigos servidores de FTP estão expostos atrás de um servidor web, como o FTP da Unicamp que eu usava muito na faculdade e hoje hospeda espelhos de arquivos de Linux. Se digitar ftp.unicamp.br no seu navegador, vai ver que ele coloca http:// na frente, indicando que não está usando o protocolo FTP.

Num terminal Linux, se instalar o antigo pacote inetutils, além do telnet, vai ganhar o programa ftp. Basta digitar ftp ftp.unicamp.br no terminal. Ele vai pedir um usuário. Como antigamente, muitos servidores públicos aceitavam o usuário anonymous. E felizmente esse ainda aceita. A senha pode ser qualquer coisa ou vazia. E pronto, abriu uma conexão de FTP onde ele passa a esperar comandos que são parecidos com os comandos pra navegar no seu HD via terminal como cd pra mudar de diretórios ou ls pra listar o conteúdo do diretório. Se digitar help mostra os comandos que o protocolo FTP suporta. Lembra que HTTP suporta comandos como GET? Em FTP ele suporta comandos diferente. Get em FTP é pra fazer download de algum arquivo.

Eu até consigo mudar de diretório fazendo cd /pub pra ir pro diretório público, mas não sei porque, comandos como ls não devolvem nada e dão timeout. HTTP versão 1.0 era ótimo pra baixar páginas HTML e até mesmo fazer download de arquivos, como agora. Mas era chatinho enviar arquivos pro servidor. Hoje em dia é fácil, mas nos primórdios, a gente ainda não entendia tudo que dava pra fazer, nem lembro se HTML 1.0 tinha form multipart. Pra enviar arquivos pra um servidor, o certo era usar FTP.

Acumulamos um monte de funções em cima de HTTP que antes eram de outros protocolos. Hoje em dia é muito normal abrir um Gmail e anexar um arquivo. Ou abrir um Dropbox e subir um arquivo. E mesmo se quisermos transferir arquivos num equivalente FTP, não se usa FTP pelo mesmo motivo que hoje usamos HTTPS em vez de HTTP, por segurança. HTTPS é HTTP mais encriptação com certificado TLS. O equivalente seria FTPS. Assim como em vez de Telnet hoje usamos SSH. E SSH é mais versátil porque permite não só abrir um terminal remoto seguro, como também trafegar arquivos, via SFTP que é FTP sobre SSH. Vou falar mais de SSH no próximo episódio.

Outro protocolo que até existe ainda mas num nicho muito pequeno é o que falei 2 episódios atrás quando expliquei correção de erros e parchives. O protocolo NNTP de rede Usenet. A idéia era ter um servidor de artigos de texto, como fóruns e sincronizar diferentes servidores usando esse protocolo NNTP. De novo, acumulamos essas funções dentro de HTTP e o equivalente seria sites como StackOverflow, HackerNews, Reddit.

No começo da internet não usávamos navegador web pra tudo. Usávamos programas separados como FTP pra transferir arquivos. News pra ler notícias e discussões da Usenet, literalmente newsgroups. Telnet pra abrir sessões remotas de terminal. E Gopher, que eu quase nunca usei porque meio que tinha o mesmo propósito de HTTP e perdeu espaço quando a Web ficou mais popular. Mas todos são exemplos dos primeiros protocolos de aplicação no começo da internet comercial. Na prática, Usenet ainda é usado até hoje pra facilitar pirataria, algumas coisas que talvez seja mais difícil em BitTorrent ainda se acha na Usenet.

Todos foram substituídos. HTTPS se tornou o protocolo mais popular. SSH é a única boa alternativa tanto pra telnet quanto ftp. E protocolos específicos como NNTP, IRC de chat, Gopher e outros, tiveram suas funções acumuladas em HTTPS. E o S de segurança se tornou importante nos primórdios do comércio eletrônico, onde encriptação se tornou essencial pra permitir trafegar coisas como número de cartão de crédito. Sem isso seria impossível ter comércio online.

Tivemos primeiro o SSL da Netscape, e hoje é o TLS ou Transport Layer Security. Isso possibilitou escalar a economia na Web mas também dificultou pra hobistas e amadores que queriam só fuçar a rede com comandos simples no terminal, porque agora temos que lidar com uma camada de encriptação no meio.. Antigamente era só plugar telnet em qualquer porta que já dava pra fuçar, hoje já não é tão simples e como isso torna as coisas mais indiretas e abstratas, imagino que deve dificultar o aprendizado de muita gente.

Sem contar que se eu quisesse contribuir na rede e participar de sub-redes como servidores de chat IRC, era só montar meu próprio servidor IRC e plugar na internet. Ou se quisesse ter meu próprio servidor de newsgroups era só montar um servidor de NNTP e plugar na Usenet e assim a gente podia fazer parte do mesmo serviço distribuído na rede. No momento onde centralizamos tudo em HTTP, também perdemos a característica de serviços distribuídos e entramos na era de walled gardens ou jardins emparedados. Acho que os únicos exemplos de rede verdadeiramente distribuída onde qualquer um pode entrar e participar é BitTorrent e Bitcoin da vida. Sim, eu sei, como falei antes Usenet e IRC ainda existem, mas são nichos bem pequenos e desconhecidos. Tem muito mais gente usando Discord do que IRC.

E falando nisso, eu acho que preciso explicar um pouquinho sobre segurança de rede e vou deixar isso pro próximo episódio. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

Vamos mais na prática como a internet da sua casa funciona. O que vem depois do modem. Como seu PC, seu celular, sua TV, conseguem se comunicar e acessar a internet? E se no ipv4 dizem que já acabou os possíveis endereços de IP, como continuamos usando internet sem migrar pro tal ipv6? Aliás, o que é ipv6? Vamos tirar essas coisas básicas do caminho.

Conteúdo:

• 00:00 - Introdução
• 00:47 - Tanenbaum
• 01:43 - OSI Model
• 04:39 - Configurando roteador
• 06:22 - Endereço ipv4
• 07:36 - Máscara de Rede
• 09:23 - Telefones e ramais
• 11:28 - NAT
• 14:25 - ARP
• 16:40 - Default Gateway
• 17:56 - DHCP
• 19:39 - Hubs e Switches
• 21:58 - DNS
• 26:30 - Pi-Hole (DoH)
• 27:57 - Roteamento
• 30:20 - CGNAT
• 33:20 - IPv6
• 40:23 - Conclusão
• 40:53 - Bloopers

Links:

• Computer Networks (5th Edition PDF) (https://www.mbit.edu.in/wp-content/uploads/2020/05/Computer-Networks-5th-Edition.pdf)
• What is a DNS record? (https://www.cloudflare.com/learning/dns/dns-records/)
• MAC spoofing (https://en.wikipedia.org/wiki/MAC_spoofing)
• What is Carrier-grade NAT (CGN/CGNAT)? (https://www.a10networks.com/glossary/what-is-carrier-grade-nat-cgn-cgnat/)
• What is IPv6, and why is adoption taking so long? (https://www.networkworld.com/article/3254575/what-is-ipv6-and-why-aren-t-we-there-yet.html)

SCRIPT

Olá pessoal, Fabio Akita

Finalmente vou poder falar um pouquinho mais sobre a parte que mais interessa pra programadores iniciantes, que é o básico do básico de uma rede caseira. Eu resolvi falar disso porque recentemente estava justamente fuçando minha própria rede de casa, configurando meu NAS novo, e pareceu uma boa hora pra introduzir alguns conceitos de rede. Muito do que quero falar em episódios futuros depende de todo mundo saber pelo menos esse básico.

Hoje pulamos do modem pro roteador e o vocabulário mais básico sobre endereços IP, rotas, e tudo mais. Pra maioria das pessoas tudo isso é invisível. Você já conecta no seu Wifi e tudo funciona. Mas programadores precisam entender porquê essas coisas funcionam. Então vamos lá.

(…)

Sem vocês saberem nos últimos dois episódios eu toquei em dois tópicos específicos de redes. O que se chama de camada física e a camada de dados, physical layer e data link layer. Claro, eu só toquei em pouquíssimos tópicos desses assuntos, se quiserem saber o assunto completo, como sempre, eu recomendo que estudem o famoso livro de redes do professor Tanenbaum. Quem fez ciências da computação provavelmente teve que estudar esse livro, e na minha época da faculdade também era ele.

Se conseguiram chegar até aqui, espero que já consigam enxergar dados não como arquivos e sim como conjuntos de blocos de bits, ou o que chamamos de pacotes. E espero que já tenham começado a entender a idéia de protocolos como o formato como preenchemos os metadados do cabeçalho desses pacotes. A metáfora de e-commerce onde o produto é o dado e o pacote de fora onde se preenche endereços é o protocolo. Esses pacotes tem coisas como o número deles pra depois a gente receber e montar na ordem certa.

O hello world do estudo de redes é o modelo de referência OSI, que tecnicamente não é mais usado hoje em dia. A gente tá mais familiarizado direto com o protocolo TCP/IP que se usa na internet. O Tanenbaum diz que os protocolos associados ao modelo OSI não são mais usados, mas o modelo em si é bem útil e geral e ainda válido. Já no TCP/IP é o contrário, o modelo em si não é muito útil mas os protocolos são muito utilizados. Por isso na prática a gente usa TCP/IP mas aprende o modelo OSI.

O modelo OSI é dividido em 7 camadas e eu disse que já mencionei parte das duas mais baixas, a camada física 1 e a camada de data link 2. A idéia das camadas é que elas poderiam ser substituídas sem alterar as camadas de cima. Por exemplo, posso trocar a camada física de cabos ethernet por wifi e o resto funciona igual. A camada física é isso, a camada responsável por transportar bits por algum canal de comunicação.

A camada de data layer é responsável por cuidar de coisas como checagens de erros. Checksums e o algoritmo Internet 16-bits que mencionei no episódio anterior. A idéia de detectar um erro e pedir pra repetir o pacote caso tenha erro. Depois vem a camada que não falei, a camada de rede propriamente dita, é quem cuida das rotas e pra onde enviar os pacotes.

No caso de TCP/IP as camadas física e data link são uma camada só, a camada chamada só de link. E a camada de rede é a responsabilidade do protocolo IP. Quando falamos em IP pensamos em endereço IP, mas IP em si é Internet Protocol, que é a camada de Internet junto com outro protocolo, o ICMP ou Internet Control Message Protocol, que a gente usa quando fazemos ping por exemplo.

Acima disso, no modelo OSI temos camada de transporte, sessão, apresentação e de aplicação. Tecnicamente a camada de transporte em si é o TCP que é Transport Control Protocol, ou protocolo de controle de transporte. Portanto TCP/IP é justamente protocolo de controle de transporte de pacotes na internet. TCP tem como característica controlar conexão entre duas pontas de forma confiável. Em paralelo temos UDP ou User Datagram Protocol, que é um protocolo que não fecha conexão e não usa o sistema de sequenciamento de pacotes do TCP. Ele tem menos metadados e é mais leve, mas é menos confiável e feito pra situações onde perder um pacote não é um problema. Streaming de audio e video é um exemplo onde UDP pode ser útil.

A camada de aplicação é onde encapsulamos outros protocolos dentro. É onde nós programadores mais trabalhamos com coisas como HTTP pra web, SMTP pra email, DNS pra domínio e assim por diante. A maioria dos protocolos que usamos no dia a dia de programação são empacotados nessa última camada de aplicação. Pras camadas embaixo, não importa o que foi encapsulado, porque vamos fragmentar tudo em frames e eles só se importam em entregar esses frames de uma máquina pra outra. É como um entregador do mercado livre. Pra ele não interessa o que tem dentro do pacote, ele vai entregar do mesmo jeito seja lá o que tiver lá dentro.

Mas entregar, precisamos saber pra quem entregar. Eu disse no episódio de modem que a responsabilidade dele é modular e demodular entre sinal digital e sinal analógico. Mas essas caixinhas de uma Vivo ou Claro da vida fazem mais, são também roteador e ponto de acesso. É como um negócio pequeno familiar como a padaria do pai que é padeiro, a mãe recebe pedidos, manda o filho ir entregar e vai funcionando assim. Essa é a beleza dos protocolos de internet, você pode entuchar tudo num PCzinho fraco que vai funcionar ou dividir responsabilidades com PCs mais fortes pra escalar. Pra maioria das pessoas, com 1 TV, 3 ou 4 celulares, 1 ou 2 PCs, usar essa caixinha tá mais que bom e vai funcionar bem o suficiente que poucos vão notar a perda de performance e possível falta de segurança.

Eu mesmo não tenho usos muitos drásticos, mas talvez por ser mais old school, eu prefiro desligar a função de ponto de acesso e deixar ele conversar só com um dispositivo, o meu router separado. Não é um router robusto nem nada disso, é só um TP-Link Archer C6 normal. Eu uso um cabo cat5e que suporta até 1 gigabit. Como meu plano é de 300 megabits só, mais do que isso sobra. O roteador registra o gateway de saída padrão como sendo o IP do modem que é 192.168.15.1. E o roteador como sendo o dispositivo 192.168.15.2.

Hoje vamos falar desse tal de endereço IP, esse número de quatro blocos divididos por pontos que todo mundo já viu pelo menos uma vez na vida. Infelizmente pra realmente explicar isso eu precisaria tocar no assunto de roteamento, classless interdomain routing ou CIDR, e eu realmente não tenho nenhuma vontade de explicar isso. Então, de novo, recomendo o livro do Tanenbaum e o capítulo sobre a camada de rede pra estudar. Dessa vez só vou dizer o que é, mas não porque é assim.

Mesmo cortando o grosso, ainda assim explicar endereços é um saco. Vamos por partes. Um endereço IP é basicamente um número de 32-bits que escolhemos dividir em 4 blocos de 8 bits. Assim como em decimal, quando temos um número grande como 1 milhão, a gente costuma separar por ponto a cada três números pra ficar mais fácil de ler. Sendo blocos de 8 bits, se você é de front-end já tá acostumado com cores RGB sendo 3 blocos de 8 bits cada, indo de 0 até 255. Mesma coisa. Os endereços IP podem ir de 0.0.0.0 até 255.255.255.255.

Aqui vale falar outra coisa, eu venho falando em blocos ou pacotes ou frames, mas existem várias nomenclaturas usadas de formas confusas e no mundo de IP fala-se em datagrams, é a mesma coisa, pacotes de bits com um cabeçalho de metadados. Assim como antigamente tinha telegrama no mundo analógico, em digital temos datagramas. Mas no fundo é tudo pacote de bits, não se perca nas diferentes nomenclaturas. A parte importante são os campos de metadados definidos pelo protocolo, que descrevem pros diversos componentes da rede, como switches e seus dispositivos o que fazer com esse pacote, pra onde mandar e tudo mais. Mas realmente não tenho nenhuma vontade de detalhar esses campos, novamente, leia Tanenbaum.

Mas voltando, endereços IP versão 4 ou IPv4 como chamamos são números de 32-bits. Mas só esse número não quer dizer muita coisa sozinho. A gente sempre precisa de uma máscara de sub-rede, subnet mask, que é aquele número 255.255.255.0 ou similar que você também já deve ter visto e como o próprio nome diz é uma máscara pra ser aplicada no endereço IP pra saber qual parte define a sub-rede e qual define o host. Isso é uma coisa que todo programador tem obrigação de saber que são operações bitwise.

Se nunca viu operação bitwise, vamos ver como que funciona. Vamos pegar o endereço que o modem deu pro roteador, 192.168.15.2 e escrever o número em binário aqui na tela, 32 bits. Eu quero saber qual é o prefixo que identifica a sub-rede. Pra isso usamos a máscara. Lembra, 255 significa tudo 1, então 3 blocos de 8 bits 1 e o resto é zero. Agora fazemos operação bitwise AND, ou seja, fazemos AND bit a bit. 1 and 1 é 1, 1 and 0 é 0, 0 and 0 é 0. Eu expliquei isso no guia mais hardcore de introdução a computadores.

Fazendo isso, o que sobra no final é o prefixo de rede. 192.168.15.0. A máscara arranca fora o sufixo que identifica o dispositivo individual na rede. Essa máscara na prática me diz que os primeiros 24 bits representam a rede, por isso outra forma de representar isso é escrever 192.168.15.255/24. Isso denota uma rede onde é possível ter até 256 dispositivos. Se fosse 192.168.255.255/16 ou máscara 255.255.0.0 significa que poderíamos ter 2 elevado a 16 ou seja, mais de 65 mil dispositivos. É uma rede grande demais, por isso você não vê rede barra 16 por aí. Num roteador caseiro, uma rede barra 24 é mais que suficiente, porque ninguém tem mais de 200 dispositivos em casa precisando de endereços.

Por que precisa ter isso? Um roteador é responsável por rotear pacotes na rede interna e também ligar com outro roteador numa rede externa, tipo a rede da Vivo. Se não tivesse essa hierarquia de rede e hosts, todo roteador precisaria ter uma tabela com cada endereço de cada dispositivo dizendo pra onde o pacote de cada um deles precisaria ir. Em vez disso o roteador só precisa saber, se da rede internet vier um pacote cujo prefixo do endereço seja 192.168.15.x ele precisa mandar pra rede externa do modem. Não importa se veio de 192.168.15.2 ou 192.168.15.3. Então o roteador só precisa manter uma linha em memória pra essa rede em vez de uma tabela com todos os endereços dessa rede.

É mais ou menos como telefones. Se todo mundo tivesse um número de telefone de 11 números aleatórios, toda central em todo estado precisaria ter uma tabelona com 100% de todos os números pra saber pra onde mandar. Mas a gente usa o tal de DDD, os dois primeiros números representam uma região, mais ou menos uma cidade ou conjunto de cidades. Na Grande São Paulo o DDD é 11, Rio de Janeiro, o DDD é 21, em Natal o DDD é 84 e assim por diante. Então se a Central de São Paulo faz uma ligação pra um número com prefixo 84, ele sabe que precisa rotear a chamada pra Central da Natal. A Central de São Paulo não precisa ter o banco de dados com os números de Natal, só mandar pra outra central que vai ter esse sub-conjunto de números de Natal, que é a Central de Natal.

Endereços IP é a mesma coisa, só que mais simples, ele representa a sub-rede e o host, ou identificador do dispositivo nessa rede. Mas tem mais detalhes pra quem quer estudar redes de verdade que é entender CIDR ou Classless InterDomain Routing, como se usa máscaras pra definir sub-redes independentes dentro de uma mesma organização, por exemplo, blocos de IPs diferentes pra cada departamento. E a forma antiga que se usava até 1993 de classful addressing, onde provedores tinham que lidar com classes A até E. Como falei antes, isso tudo tem a ver sobre como roteadores sabem como rotear quais pacotes pra quais redes. Isso é o capítulo de camada de rede do Tanenbaum.

O que mais interessa é o problema que vocês já devem ter ouvido falar. Especialmente depois da explosão da internet no fim dos anos 90, seguido da explosão de smartphones nos anos 2010, a gente literalmente tem ordens de grandeza mais dispositivos conectados na internet do que existem endereços disponíveis num número de 32-bits como definido pelo IPv4. É mais ou menos o mesmo problema que expliquei no episódio dos 640 kilobytes de RAM quando se achava que isso era o máximo de RAM que uma pessoa normal jamais ia precisar, e nos anos 90 se provou que isso era muito pouco. 32-bits que dá um máximo de 4 gigabytes também é pouco e hoje estamos em 64-bits.

IPv4 sendo 32-bits significa que o máximo teórico de endereços seria pouco mais de 4 bilhões. Só de smartphones já temos mais de 3 bilhões. Some a isso todo PC, todo servidor em todo data center. Some a isso um tanto de IPs que já foram desperdiçados também. A gente já passou de 4 bilhões de endereços muitos anos atrás. Mas porque tudo continua funcionando? E pra entender isso eu acho importante todo mundo saber o que é um NAT ou Network Address Translator.

O conceito é muito simples. Todo provedor como Vivo ou Claro tem muito menos blocos de endereços IP reais do que clientes. Por isso é impossível dar um endereço real pra cada cliente e de fato ninguém faz isso. Em vez disso eles implementam o que chamamos de um CGNAT ou Carrier Grade NAT, ou seja, um NAT tamanho industrial. O grande lance é que podemos ter o intervalo inteiro de IPv4 dentro de cada sub-rede isolada e traduzir o endereço quando ela sai de uma rede e vai pra outra.

Em redes embaixo de NAT existem 3 blocos de endereços reservados só pra isso. Os com prefixo 10 barra 8, que é um intervalo de 24 bits de mais de 16 milhões de endereços possíveis. Ou com prefixo 172.16 que é barra 12, uma rede de 20 bits ou mais de 1 milhão de endereços e finalmente com prefixo 192.168 que é barra 16 que é uma rede de 16-bits ou mais de 65 mil hosts. Por isso que normalmente seus dispositivos na sua rede local de casa ou do escritório costumam ser 192.168 alguma coisa ou 172 ponto alguma coisa ou 10 ponto alguma coisa. São intervalos reservados pra redes locais embaixo de NAT.

Meu PC tem endereço 192.168.1.200. Eu quero assistir alguma coisa do YouTube. Faz de conta que o endereço de destino é 142.250.219.14 porta 443 que é a porta de HTTPS. Outro dia explico portas. Então meu PC monta pacotes onde a origem é meu endereço 192.168 com destino 142.250 bla bla porta 443 pedindo a página de video e manda isso na rede local aqui de casa.

Antes de chegar em NAT vou aproveitar pra adicionar mais detalhes desse processo. Dentro de uma rede local os pacotes não são roteados pelo endereço IP. No protocolo de rede, estamos na camada de rede, mas na rede local o que importa é a camada de data link, da ethernet. E ethernet não entende endereços IP.

Essa tangente vale a pena fazer. Segura o exemplo do YouTube. Digamos que eu queira falar com um dispositivo aqui dentro na minha rede local. No caso o meu NAS. Eu que configurei então sei que tá com endereço local 192.168.1.161. Posso abrir aqui o command prompt do Windows e dar um ping pra ele. Todo mundo já fez ping pra medir latência e tempo de resposta, ele manda um pacote ICMP e mede o tempo. De novo, como meu PC sabe mandar pacote exatamente pra esse dispositivo e não confunde com, digamos, minha smart TV que tá na mesma rede?

O jeito mais simples seria toda vez eu ficar mandando pacotes pra todo mundo na rede perguntando “ow, quem aí é IP final 161”, daí o NAS responde “sou eu! manda pra cá”. E ficar fazendo isso toooooda vez, pra todo pacote. Mas conseguem enxergar como isso seria um desperdício? Eu ia ficar toda hora incomodando os vizinhos gritando no corredor. Minha TV ia receber pacotes que não precisa. Meu smartphone conectado via Wifi ia ficar recebendo. Toda vez que preciso enviar pacotes, ia ter que ficar gritando no corredor. Seria um saco.

Por isso existe um outro tipo de pacote chamado ARP ou Address Resolution Protocol. No command prompt mesmo eu posso digitar arp -a e vai aparecer uma tabela, que é um cache aqui no meu PC. Quando eu fiz o ping pro meu NAS, na realidade ele pediu pro ARP gritar no corredor “ow, quem aí é o NAS!?”. Aí o NAS respondeu “sou eu, caralho!” e incomodou todo mundo na rede. Mas aí o ARP que não é burro nem nada, registrou a posição do apartamento no andar. É pra isso que serve o tal MAC address. Toda placa de rede, seja ethernet, seja wifi, tem um endereço único de 48 bits que vem de fábrica. 2 elevado a 48 são mais de 281 trilhões de endereços. É endereço suficiente pra todas placas de rede já fabricadas e em operação.

Olha a tabela que o comando arp -a me mostra agora. Tem um registro dizendo que 192.168.1.161 é esse MAC address que eu escondi uma parte. O endereço IP é relevante pra roteador de internet, mas na camada de baixo da rede física, IP não quer dizer nada. Ethernet encontra coisas baseado em MAC address. Mas com isso meu PC já sabe que se quiser falar com o NAS de novo, não precisa mais gritar no corredor. É só mandar direto pra placa de rede que responde nesse MAC address.

Mas isso funciona pra endereços da rede local. Se for endereço IP 192.168 o ARP vai ficar gritando aqui no corredor. Mas e se for o endereço do YouTube, que é no prédio ali na esquina? Agora não adianta ficar gritando no corredor. E é pra isso que serve o tal do default gateway que você também costuma ver na configuração de rede do seu roteador. É como se fosse o porteiro do seu prédio. Todo endereço que não faz parte deste prédio você manda pro default gateway, que por convenção é o endereço IP mais baixo, como 192.168.1.1. E agora pede pra ele ir no outro prédio, pedir pro porteiro de lá, o roteador de lá, gritar no corredor de lá. Rede é mais ou menos isso mesmo, todo mundo gritando pra lá e pra cá e uma correria de entrega de pacotes.

Mas tudo isso pressupõe que todo apartamento tem um endereço IP único dentro do prédio. Mas digamos que se mudou um vizinho pentelho, e só pra foder, ele resolveu colocar o mesmo número de apartamento do vizinho. O ARP vai gritar no corredor “ow. quem aí é endereço final 161” e dois apartamentos gritam “sou eu!!” e agora? Agora eu não posso entregar o pacote pra nenhum dos dois, porque não sei dizer quem tá dizendo a verdade. Então o pacote é dropado, jogado fora, e nenhum dos dois recebem. Um deles precisa colocar um endereço IP que nenhum outro esteja usando. Essa é a regra de conduta do prédio.

Pensa, seria uma zona se toda vez que você se muda pra um prédio, você mesmo precisasse definir qual é o número do seu apartamento. O prédio é progressista, ele deixa você escolher o número que mais te agrada. Só que aí metade escolhe número 13, a outra metade escolhe 22. E o ARP ia ficar o dia inteiro gritando nos corredores e não ia poder entregar nada pra ninguém. O prédio seria uma zona. Ainda bem que na vida real, todo apartamento já tem números pré determinados e você não escolhe. Hoje em dia, numa rede local, é a mesma coisa.

Pra isso serve essa outra coisa que você já deve ter visto no seu roteador chamado DHCP ou Dynamic Host Configuration Protocol. Toda vez que um novo dispositivo se conecta na rede, ele pergunta pro servidor de DHCP, que em cenário caseiro, fica no seu modem ou no seu roteador separado. Em empresas um servidor DHCP pode ser um servidor separado e independente. Mas o funcionamento é o mesmo. O DHCP é o síndico do prédio. O meu PC conecta na rede e checa “ow, tem um síndico ativo por aí?” e o DHCP responde “opa. tem eu aqui! o que manda?”. Aí o PC pergunta “ow, que endereço tem sobrando aí pra mim?” e o DHCP mantém uma tabela parecida com aquela do ARP, e fala “opa, tem final 200, firmeza?” e o PC responde “valeu irmão, vou usar esse então”.

E quando o NAS conecta, ou a TV ou seu smartphone, todos perguntam pro DHCP qual endereço tá sobrando e ele manda um certinho, de tal forma que ninguém tem um IP colidindo com de outro dispositivo. E assim o ARP funciona e os pacotes são entregues pros lugares certos. No DHCP eu posso também configurar dizendo que um certo MAC address sempre receba o mesmo endereço de IP. É útil pra coisas como meu NAS porque eu monto um drive nele do meu PC e seria um saco se toda hora o DHCP desse um endereço diferente pra ele.

Tudo parece encaixar bonitinho, mas tem alguns problemas que eram mais graves no começo da internet e foram sendo tratados ao longo do tempo. Por exemplo, antigamente a gente usava hubs em redes, pra compartilhar um cabo entre vários computadores. Lembra antigamente quando tinha extensões de telefone na sua casa? Aí seu namorado liga e toca nos dois telefones, a menina no quarto atende e a mãe na cozinha atende também. Daí a mãe se toca “opa, é o namorado da minha filha, vou desligar pra não ouvir a conversa”. E sendo uma mãe honesta, ela desliga. Mas isso pressupõe que todo participante nessa rede seja honesto.

É o que placas de rede legítimas numa rede em hub fazem. Se vem pacotes que não é pro MAC address dele, ele dropa, ou rejeita esses pacotes e não fica escutando. Porém, a placa de rede tá aqui fisicamente na minha máquina, eu posso hackear ela. E isso se chama colocar essa placa em modo promíscuo. Quem já brincou com softwares como Wireshark sabe disso. A gente podia ficar vendo todos os pacotes trafegando na rede, mesmo os que não são pra mim. Por isso que hoje em dia se usa switches. Um switch estabelece uma conexão direta entre o dispositivo e o roteador e os outros canais do switch não vêem pacotes que não sejam direto pro MAC address dele. Por isso que hubs são baratinhos, porque eles enviam os pacotes pra todo mundo conectado, sem processar nada.

Mas ainda tem outro problema. De novo, MAC address é um endereço que vem de fábrica na placa de rede. Mas eu posso modificar essa placa e fazer ele responder qualquer outro MAC address. Daí o switch é obrigado a mandar pacotes pra mim que não eram pra mim. Não só isso, mesmo meu endereço IP mudando por causa do DHCP, meu MAC address é sempre o mesmo, então o provedor consegue saber o tempo todo com quem estou me conectando e registrar isso. Por isso empresas como a Apple vem planejando gerar MAC address aleatórios em iPhones por exemplo, pra dificultar saber quem é quem.

Na prática, se você compartilha a internet numa casa, dormitório ou sei lá, com outras pessoas, não use hubs, use switches. Não importa se você confia nas pessoas da sua casa, você não sabe se ela sem querer instalou um malware que colocou o PC dela em modo promíscuo e tá escutando os pacotes da sua rede. Em computação você não deve nunca confiar em ninguém, sob nenhuma hipótese, essa é a regra número um. Nada nunca é 100% confiável, então assuma sempre 100% suspeito.

Enfim, com esses componentes básicos você já deve entender que seus dispositivos conseguem endereços IP usando um servidor de DHCP e por isso muitos de vocês nunca precisaram configurar endereços na mão. Também já sabem que tem esse ARP que descobre qual dispositivo na rede responde pra qual endereço e mantém um cache que faz o de-para de endereço IP pra MAC address. Sabe que todo mundo está conectado no roteador seja diretamente via cabo de rede, via wifi, e se for cabo e tiver múltiplos dispositivos, coloca um switch pra conectar todo mundo de forma mais segura.

E sabe que internamente os pacotes são roteados pelo MAC address, mas se eu quiser acessar servidores fora da minha rede, peço pro default gateway, que é tipo o porteiro do prédio, pra ir falar com o porteiro do outro prédio. E esse é o básico do básico de redes que você precisa saber.

Mas vamos voltar pro exemplo de acessar o YouTube, acho que dá tempo de explicar como de fato me comunico com o mundo externo, fora do meu prédio. Eu falei que meu PC tem o endereço IP interno de 192.168.1.200 e quero assistir um video no youtube. Eu magicamente falei que ele pode se conectar talvez no prédio vizinho cujo endereço é 142.250.219.14.

Deixa eu explicar como essa mágica funciona e ela começa na configuração do seu servidor de DHCP no roteador, onde configurei esse tal de endereço DNS. Isso é um servidor externo e normalmente vem o endereço do servidor de DNS do seu provedor, como da Vivo. Eu recomendo como primeira coisa mudar isso ou pro servidor do Google que é 8.8.8.8 ou da CloudFlare que é 1.1.1.1.

Explicando de forma mais simples, um servidor DNS tem como única função traduzir um endereço em forma de texto como www.youtube.com em um endereço IP. A rede não entende nomes humanos, só entende endereços. Quando seu PC pediu um endereço IP pro DHCP ele ganhou também essa configuração de DNS. Quando no seu PC você digitou www.youtube.com no navegador, o PC checa pra qual DNS deve perguntar e vai ser pro endereço que recebeu do seu DHCP. Todos os outros dispositivos da sua casa vão ter essa mesma configuração, seja seu smartphone, seja sua smart TV.

Se eu abrir um terminal de Linux temos o comando dig e eu posso fazer dig www.youtube.com e volta essa tabela aqui. O que interessa pra gente é esse “Answer Section”. E eu vejo que a primeira linha é o www.youtube.com que eu pedi. E ele aponta pra um registro CNAME ou canonical name. Um registro CNAME diz pro DNS fazer uma nova pesquisa pra esse nome youtube-ui.l.google.com. Daí volta o resto da tabela que diz que esse domínio aponta pra múltiplos registros A com vários endereços. Registro A é um endereço IPv4, registro AAAA seria endereço IPv6 e já falo disso. Mas e agora, o que eu faço com esse tanto de IPs?

Toda vez que você perguntar pro DNS sobe o youtube, ele vai devolver conjuntos de endereços IP diferentes. Essa é uma estratégia do Google. Ele nunca te dá 100% de todos os registros, porque eles tem literalmente centenas de máquinas pro YouTube, em dezenas de data centers espalhados pelo mundo. Ele vai te devolver alguns endereços de máquinas do data center que é geograficamente mais próximo de você. Daí seu PC recebe esse conjunto e faz um round-robin load balancing. Traduzindo, ele faz balanceamento de carga. Ou seja, numa aba ele vai usar o primeiro endereço. Numa segunda aba, ele talvez vai usar o segundo endereço e assim por diante. Assim você vai sempre caindo em servidores diferentes, pra balancear sua carga.

Cada servidor recebe no pacote algumas informações sobre você, como os cookies do seu navegador. Daí ele sabe que você já tinha feito login num outro servidor e te mantém logado no servidor seguinte. Pra você, é como se estivesse sempre no mesmo lugar, sem saber que por baixo seu PC tá te mandando toda hora pra um desses outros servidores da lista. Um DNS é isso, um serviço que contém uma tabelona apontando um nome de servidor pra um ou mais endereços IP.

Lembram quando falei sobre modo promíscuo que alguém pode estar escutando seus pacotes na rede? Então, um provedor sempre está, entre aspas, em modo promíscuo, porque ele recebe os pacotes de todos os clientes assinantes pra poder mandar pra internet. Então ele é obrigado a receber todos os pacotes pra passar pra frente. Claro, se ele for honesto, assim como sua mãe na extensão, deveria só passar pra frente e não escutar a conversa. Mas, seguro morreu de velho e o certo é assumir que não só eles estão escutando, mas registrando e até revendendo esses dados. Você não tem como saber.

Por isso se fala pra nunca acessar sites que não sejam HTTPS, ou seja, cuja conexão é encriptada. Daí mesmo se alguém no meio escutar seus pacotes não tem como saber o que tá sendo transmitido. Porém, DNS normalmente não é criptografado e antes do HTTPS ativar, o navegador precisa converter www.youtube.com pra um dos endereços IP do Google. E essa pergunta pro DNS é feita em forma não encriptada. Claro, o provedor ou qualquer um no meio do caminho pode só ver o endereço IP e deduzir que é endereço do Google. Mas eu já estou dando a informação que é www.youtube.com de mão beijada. E por isso existem novas tecnologias como DNS over HTTPS ou DNS over TLS que, como o nome diz é o equivalente HTTPS pra DNS.

Isso é simples de ativar, basta colocar na configuração do seu router e seu celular o endereço de um servidor de DNS que suporte DNS over HTTPS, no caso o mais famoso é o 1.1.1.1 do CloudFlare. Mesmo assim, o CloudFlare é outra entidade, o Google também. Eu estaria confiando que eles não estão fazendo nada de errado, o que também é impossível de saber. Mas entre confiar na Vivo ou na Claro, hoje em dia nossa escolha é escolher o menor de dois maus. É por isso que eu pessoalmente uso um DNS caseiro, o Pi-Hole. Como ele cacheia a resolução de endereços, mesmo o CloudFlare pra onde ele conecta não sabe exatamente quando eu pedi esses endereços. Mas isso é tema pra outro dia. Só entenda que estamos meio expostos no setor de DNS ainda.

Enfim, eu fiz uma longa tangente só pra voltar pro assunto de NAT. Agora meu PC tem um endereço IP local graças ao DHCP do meu roteador e eu tenho o endereço IP do youtube, graças a algum DNS como do CloudFlare. Pronto, agora eu posso fazer um pacote com origem sendo 192.168.1.200 e destino sendo 142.250.218.14. Mando o pacote pro default gateway do meu roteador TP-Link. Ele por sua vez roteia o pacote pro Modem na rede 192.168.15.1. E o Modem manda esse pacote pra rede da Vivo.

A rede da Vivo vai enviar pra Internet e aqui vem a parte de roteamento na internet que eu não estou a fim de explicar. Mas pelo menos posso mostrar. No Linux costuma ter um comando chamado traceroute e no Windows tem o comando tracert. Eu chamo então tracert 142.250.218.14

e ele vai me mostrar o caminho do pacote da minha máquina até a máquina do Google. Olha só, na primeira linha, como falei, vai pro roteador que é 192.168.1.1. Dele vai pro modem 192.168.15.1 que ele chamou de meuvivofibra.

Lá dentro da rede da Vivo ele passa por outras sub-redes como esse da telesp. Pra quem não sabe a Vivo lá por 2002 ou 2003 foi criada como a junção de várias telecoms pelo Brasil. Em São Paulo, a empresa original era a Telesp. Enfim, dessa rede ele passa pra outra chamada vivozap. E aí vai passando por outros hops até no final chegar no destino. Existem vários serviços com tabelas que associam endereços IP com coordenadas geográficas de latitude e longitude. É uma estimativa. Dá pra chegar perto, mas eu posso mudar o endereço IP de uma máquina numa região pra de outra região. Ainda mais do tamanho do Google que eles podem remanejar grandes grupos de endereços de um data center nos Estados Unidos pro Brasil, por exemplo.

Mas segundo o serviço IP2Location ele diz que esse IP 142.250.218.14

que eu tentei acessar está em Mountain View, na Califórnia, sede do Google. Mas se eu usar outro serviço como o IPapi.co, ele parece ser um pouco mais atualizado e me diz que esse endereço na realidade está em São Paulo. E isso faz mais sentido. O DNS do Google me mandou pra um endereço mais próximo geograficamente de mim, pra ter menos hops ao longo da rota. Quanto mais perto, menor a latência, maior a velocidade. Por isso grandes serviços como Google tem servidores espalhados ao redor do mundo pra garantir que a maioria das pessoas tenham a melhor velocidade possível.

Tá ótimo. Mas e agora? Como que o Google sabe pra quem devolver os pacotes de video? Ué, é só devolver pra origem que tá registrado no pacote, não? Só que lembra? Meu pacote tá com origem 192.168.1.200.

Dentro da rede da Vivo não tem só você. Todo cliente da Vivo vai ter IPs como 192.168 alguma coisa. Vira aquela situação que eu falei do vizinho pentelho que copiou o mesmo número do seu apartamento.

O Google não tem como devolver a resposta pra pessoa certa só com isso. E ele nem precisa, porque ele nunca recebeu esse endereço 192.168.1.200.

E finalmente eu volto pro assunto do tal NAT e como não temos endereços IPv4 suficientes pra todos os dispositivos do mundo. Pra visualizar é a mesma coisa que um número de telefone comercial e ramais. Já pensou que dificuldade que ia ser se uma grande empresa tivesse um número de telefone diferente pra cada pessoa que trabalha lá? Uma empresa com 10 mil funcionários precisando ter 10 mil números de telefone diferentes? Eles não tem. Na realidade normalmente tem um número de telefone comercial que liga num PBX. Esse PBX roteia pra mesa da pessoa certa baseada num número de ramal.

É parecido na Vivo, o NAT é o PBX. Ela tem alguns poucos IPv4 de verdade. Mas internamente dá tipo ramais pra cada cliente. É isso que um NAT faz, no caso um CGNAT, carrier grade, porque é um NAT gigante. Faz um teste, vai no Google e pesquise por “what is my ip”, qual é meu ip. Qualquer primeiro link serve. No meu caso vai aparecer esse aqui que estou escondendo os últimos dígitos. Esse é o endereço IP da Vivo de saída e é esse endereço que ele carimbou por cima do meu pacote antes de enviar pro Google, e é pra esse endereço que o Google vai devolver os pacotes de video.

Daí o CGNAT da Vivo mantém uma tabelona que mapeia que quando voltar resposta do Google, é pra devolver pro modem certo que fez o pedido. E é por isso que você consegue conectar na internet e se comunicar mesmo não tendo um endereço IPv4 válido na internet. O CGNAT faz o trabalho de enviar e devolver os pacotes pras sub-redes corretas. Literalmente Network Address Translator ou tradutor de endereço de redes. O problema disso é que você consegue se conectar nos outros, mas outros de fora não conseguem achar você diretamente. Pra alguém de fora se conectar em você, primeiro você precisa se conectar nele pra abrir uma conexão.

Vou deixar como lição de casa. No mundo de hoje que fazemos chamadas de Zoom, ligação via Whatsapp e outras formas de Voz sobre IP ou VoIP, o requerimento é que duas pontas só conseguem se conectar diretamente se ambos os lados conseguem se encontrar na internet. Mas normalmente você e a pessoa que quer falar estão escondidas numa sub-rede privada atrás de um NAT de provedor. Portanto nenhum dos dois lados está acessível. Como que se cria uma conexão ponto a ponto, sem precisar de intermediários? Pra isso existem formas como ICE que é STUN/TURN e protocolos como RTP. Dêem uns googles aí de como isso funciona. Não vou tentar explicar hoje.

Voltando ao problema de endereços IP serem 32-bits e permitirem no máximo 4 bilhões de endereços. A essa altura já era pra ter acabado esses endereços. Se uma Vivo tiver, sei lá, 100 milhões de clientes, ia precisar de 100 milhões de endereços IPv4, pelo menos, sem contar que cada cliente tem hoje um PC, uma smart TV, alguns smartphones, então fácil ia precisar de meio bilhão de endereços. Mas graças ao CGNAT, faz de conta, com 1 único endereço IPv4 ela pode manter esse meio bilhão de dispositivos em redes privadas escondidas com endereços 192.168 ou 10 ponto da vida por trás. E é assim que a gente evitou acabar os IPv4. Mas isso é um paliativo.

NAT ajudou a evitar o colapso da internet por falta de endereços mas ao mesmo tempo dificultou e complicou muita coisa, como o que falei de Voz sobre IP e todo tipo de conexão ponto a ponto, como você conseguir jogar online com seus amigos. Como na prática todo mundo tá escondido em redes privadas atrás dos provedores, estamos à mercê da boa vontade deles pra muita coisa. Esse problema não é novo, já se falava do problema de acabar endereços desde o fim dos anos 80. Desde o começo dos anos 90 já se começou pesquisas sobre como resolver esse problema. E já temos a solução na forma do IPv6 desde 1998.

Você já deve ter visto IPv6. É um número de 128 bits. Eu venho dizendo que 64 bits é um número absurdo. Computadores modernos de 64 bits não tem barramentos de 64 bits ainda, o máximo acho que é 48 bits, que já é endereço de memória como se não houvesse amanhã mesmo pra um supercomputador. Pra ter uma idéia, a maioria das pessoas hoje já acha 128 gigabytes de RAM algo absurdo. Pra endereçar 128 giga um barramento de 37 bits seria suficiente.

2 elevado a 128 é um número tão absurdo que um ser humano normal não consegue imaginar. Imagina a superfície inteira do planeta Terra, incluindo a superfície dos oceanos, inteiramente coberta por PCs. Eu poderia ter 7 x 10 elevado a 23 endereços IP por metro quadrado. Conseguem entender? 10 seguido de 23 zeros de quantidade de PCs, por metro quadrado. Estudantes de química vão notar que esse número é maior que o número de Avogadro. Literalmente seria possível dar um endereço IP pra cada molécula da superfície da Terra e sobrar. É astronomicamente grande.

Na prática isso significa que todo dispositivo em existência hoje, todo PC, todo servidor, cada smartphone, cada dispositivo inteligente da sua casa como sua TV ou sua geladeira, cada uma poderia ter um endereço IP único com facilidade, por gerações a fio. E fazendo isso não precisaríamos mais estar atrás de um CGNAT. Todo mundo poderia estar diretamente na internet sem intermediários, o que facilitaria muito todo tipo de serviço ponto a ponto como voz sobre IP, e nunca teríamos que nos preocupar de novo com acabar endereços e ter que fazer gambiarras como NAT.

O problema é que o sucesso da internet evitou que pudéssemos migrar pra melhor solução a tempo. IPv6 surgiu no calor da febre da bolha da Internet do fim dos anos 90. Pra maioria da população, nem se sabia se essa tal de internet ia mesmo dar certo. Muita gente achava que era só um troço passageiro que ia morrer logo. Coisa de hipster. Usar internet no fim dos anos 90 era opcional, e muita gente não tava interessada. Pra dar certo, investiu-se tudo no que já existia e se sabia que funcionava, que era IPv4. Por que a gente ia se preocupar em acabar endereços se ninguém nem sabia se ia entrar gente suficiente pra acabar os endereços? Migrar naquele momento pra IPv6 parecia uma otimização prematura.

E pra piorar, tivemos o crash da bolha da internet em 2001. Aí sim, ninguém ia investir milhões de dólares pra migrar toda a infraestrutura de tudo pra IPv6. Pra tudo funcionar perfeito, o certo, seria o mundo inteiro migrar quase que tudo de uma vez pra IPv6. Senão como alguém com IPv4 vai conectar num servidor IPv6? Pra isso foram sendo inventadas formas de migração menos agressivas como NAT de IPv6 pra IPv4. Temos NAT64 por exemplo, que permite que PCs que já usem endereço IPv6 consigam conectar em servidores que ainda são IPv4. Mas a moral da história foi essa: o inimigo do IPv6 foi o sucesso do IPv4.

E vocês sabem, se alguma é opcional, a maioria sempre vai esperar até a última hora. Por que eu vou gastar meu tempo pra ter todo esse trabalho se todo mundo ainda vai estar usando o esquema antigo? Vou ficar no antigo também. É a lei do menor esforço. Migração pra IPv6 só vai acontecer o dia que for mandatório, tipo os governos decidirem que ninguém mais acessa nenhum serviço do governo se não for IPv6. Mas governos normalmente são os últimos a adotar qualquer coisa nova. Eu não esperaria muito deles. Enquanto isso a gente vive num mundo em eterna transição entre IPv4 e IPv6. Alguns provedores já suportam nativamente, alguns você pode ligar e pedir pra habilitar roteamento por IPv6, mas não tem um padrão. Cada caso é um caso.

Tem uma questão de privacidade também. Se todo dispositivo tiver um IPv6 estático, seria como um MAC address que nunca muda. Hoje em dia ninguém do lado de fora pode dizer com 100% de certeza quem é você porque só enxerga o IP público do provedor e não seu IP privado da rede atrás do NAT. Mas se for direto com IPv6 dá pra dizer com certeza que veio do seu dispositivo. Por isso sistemas operacionais como Windows usam números IPv6 temporários pra se comunicar e garantir algum nível de privacidade. Não recomendo desligar isso. Mas veja, se eu der o comando ipconfig no meu Windows eu vejo que eu tenho um IPv6 estático na minha placa de rede, que obviamente estou obfuscando uma parte, e embaixo tenho o IPv6 temporário, que é o que um servidor iria ver se eu conectar direto nele sem NAT.

De qualquer forma, se IPv4 até dava pra você decorar. IPv6 é mais difícil. Primeiro o número é longo, então a notação pra ficar menos difícil digitar foi separar oito blocos de 16 bits por dois pontos. Mas diferente de IPv4 onde escrevemos cada bloco no formato decimal mesmo, de 0 até 255, 16 bits é um número que vai até mais de 65 mil então ficaria longo. Por isso escrevemos em hexadecimal, onde cada dígito vai de 0 até F, assim o bloco precisa de no máximo 4 dígitos hexadecimais. São 8 blocos de 4 dígitos hexadecimais separados por dois pontos.

Se escolher direito, pelo menos no começo, vai ter muito endereço com vários blocos de zero no meio. Pra facilitar, o protocolo permite omitir esses blocos. E finalmente, endereços IPv4 podem ser escritos como IPv6 colocando dois dois pontos antes do endereço escrito no mesmo formato de antes. Enfim, pra maioria tudo isso é automático, porque o modem do provedor vem com servidor de DHCP e ponto de acesso wifi, então ele automaticamente te dá endereço IP, configura seu DNS, e basta você se conectar no Wifi que já tá navegando. Mas programadores precisam saber que esses detalhes existem. Em breve muitos de vocês vão precisar lidar com esse problemas, como conectar pessoas num app de comunicação ponto a ponto tendo que furar NAT ou implementar IPv6.

E com isso terminamos essa parte da mini-série sobre o básico de redes. Isso resume, super resumido, os capítulos de camada física, camada de data link, camada de rede e um pouco da camada de transporte do modelo OSI, com um pezinho na camada de aplicação que é a parte mais prática de verdade e que devo tentar falar mais em outros episódios. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

Apesar de ser Parte 2 da mini-série de redes, vou falar pouco sobre redes propriamente ditas e focar em um aspecto que tem a ver com mais coisas que só rede: detecção e correção de erros.

Já se fez essa pergunta? Dados são transmitidos como ondas eletromagnéticas por cabos de cobre ou sem fio. Bits são gravados magneticamente em mídias como HDs ou Blu-Rays. Como que nenhum bit nunca é gravado ou transmitido errado? E se é, como poderíamos saber se 1 único bit é entendido errado?

Mas não se preocupem, apesar de não ser diretamente “redes” é importante saber o episódio de hoje, mas no próximo episódio vou realmente mostrar mais de “redes”.

Conteúdo

• 00:00 - Intro
• 01:20 - Recapitulando RAID-0 e RAID-1
• 05:37 - Bit Rot, Bit Flip e Raios Cósmicos
• 10:37 - Hamming Code
• 15:11 - Hamming e Cartões Perfurados
• 15:53 - Eficiência de bits de paridade
• 19:37 - Checagem de erros em rede
• 20:51 - Usernet e Par2
• 24:23 - M-Discs
• 27:27 - Data Scrubbing
• 28:40 - Conclusão
• 29:43 - Bloopers

Links

• WHAT CONNECTS AN INCIDENT IN 2003 WITH SPACE, ASSEMBLY ELECTIONS, INTEL, AEROSPACE AND ELECTRIC CARS? (https://www.linkedin.com/pulse/what-connects-incident-2003-space-assembly-elections-intel-jogani/)
• How An Ionizing Particle From Outer Space Helped A Mario Speedrunner Save Time (https://www.thegamer.com/how-ionizing-particle-outer-space-helped-super-mario-64-speedrunner-save-time/)
• COSMIC RAY FLIPS BIT, ASSISTS MARIO 64 SPEEDRUNNER (https://hackaday.com/2021/02/17/cosmic-ray-flips-bit-assists-mario-64-speedrunner/)
• Bit Rot: What It Is and How To Stop It From Destroying Your Data (https://getprostorage.com/blog/bit-rot-stop-destroying-your-data/)
• How to send a self-correcting message (Hamming codes) (https://www.youtube.com/watch?v=X8jsijhllIA)
• Hamming codes part 2, the elegance of it all (https://www.youtube.com/watch?v=b3NxrZOu_CE)
• What is error correction? Hamming codes in hardware (https://www.youtube.com/watch?v=h0jloehRKas)
• Reed–Solomon error correction (https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction)

SCRIPT

Olá pessoal, Fabio Akita

No episódio anterior eu quis trazer algumas noções de como dados trafegam por redes cabeadas ou wireless. Isso porque ultimamente andei brincando com coisas como meu novo NAS. Mas antes de poder falar dele e coisas que andei prometendo como Docker, achei que finalmente chegou a hora de falar um pouquinho sobre redes. Como já tinha falado antes, estou longe de ser especialista de redes, então quero explicar as coisas do ponto de vista mais de alguém que é programador e usa a rede mais do que monta redes.

No episódio de hoje quero explorar o motivo de porque eu montei um NAS: evitar perder dados. A maioria das pessoas hoje tá acostumado a um mundo plug and play, sempre conectado, serviços de cloud e tudo mais e tem muito menos preocupação com seus dados. Na real, a maioria não tem dados tão importantes que se perder vai ser um grande problema mesmo. Por isso acho que não tem problema. Se perder, perdeu. Se doeu, deveria ter se precavido. Mas programadores eu acho que deveriam ter um pouco mais de cuidado, especialmente porque lidam com dados dos outros.

Sobre isso tem dezenas de assuntos que poderíamos falar, como segurança de dados, mas hoje quero falar só sobre os blocos mais básicos de como erros podem acontecer e como a ciência da computação vem resolvendo esses problemas desde pelo menos os anos 60.

(…)

Veja meu NAS. Ele está construído numa configuração RAID-6. Mas vamos falar de novo do formato mais simples, só 2 HDs. Se ainda não assistiu minha playlist de armazenamento, vou resumir só essa parte de novo. Com dois HDs eu posso fazer 2 coisas: escolher segurança ou escolher performance. Se eu for um gamer que posso baixar tudo de novo da Steam caso perca os HDs, talvez faça sentido colocar em modo RAID-0. Nesse modo o sistema operacional vai enxergar os dois HDs num único volume lógico. Se os HDs tem 1 terabyte cada, em RAID-0 o volume lógico, o meu “C:” no Windows, vai ter 2 terabytes inteiros e vou ter quase o dobro de performance, porque posso escrever nos dois ao mesmo tempo.

Lembram o que já expliquei antes sobre arquivos e transmissão de dados em geral? A maioria das pessoas olha um Windows Explorer e assume que a menor unidade são arquivos. Os sistemas operacionais escondem os detalhes e mesmo programadores só lidam no máximo com arquivos na maior parte do tempo. Mas isso é ineficiente. HDs não são dispositivos de arquivos, são dispositivos de blocos. Por isso o serviço da Amazon onde posso instalar um HD virtual na minha máquina virtual do EC2 se chama EBS ou Elastic Block Store. Ele nos dá um dispositivo de blocos. Eu explico isso nos videos sobre armazenamento, assistam lá depois.

No episódio passado eu falei que comunicação de redes usa hoje em dia comutação de pacotes. Pacotes são essencialmente blocos de bits. Por isso tenha na cabeça que tanto arquivos no seu sistema como transfência desses arquivos pela rede, acontecem de forma fragmentada, um pacote de cada vez e não um arquivo inteiro de uma vez. Por isso tenho o dobro de performance num RAID-0. Se o sistema só enxergasse arquivos, quando fosse gravar, gravaria o arquivo inteiro só em um HD, daí a velocidade máxima seria só desse HD.

Mas como na realidade a partição é uma tabela que tem um registro dizendo “arquivo hello.mp3 tem 2000 blocos de 4 kilobytes cada, e os blocos de ID 1 até 1000 estão no HD 1 e os blocos de 1001 até 2000 estão no HD 2”, daí ele pode mandar gravar os blocos nos dois HDs ao mesmo tempo, e por isso eu tenho mais velocidade tanto pra ler quanto pra gravar, porque o arquivo pode ser segmentado nos dois HDs. Mas também por isso esse sistema de RAID-0 tem um grande calcanhar de aquiles: e se um dos HDs sofrer um defeito e morrer?

Se um HD morrer, você perdeu tudo dos dois HDs. Entenderam? Por que alguns blocos dos arquivos no HD que está vivo estavam no HD que morreu, então você ficou com um monte de arquivos quebrados que não servem pra nada. Por isso que você nunca deve usar RAID-0 se os dados que tiver sejam importantes. Se era só pra games que você pode recuperar tudo depois, beleza. Compra outro HD, remonta o RAID-0, formata tudo, reinstala o Windows do zero e baixa tudo de novo da Steam. A importância aqui era a performance e os dados tinha backup fora, então ok.

Mas se vai misturar com trabalho, e coisas que se perder vão te dar prejuízo, e só puder comprar dois HDs, então coloque eles em RAID-1. Esse é o sistema de espelhamento. O seu sistema operacional vai enxergar os dois HDs de 1 terabyte como se fosse um único HD de 1 terabyte. Toda vez que mandar gravar um arquivo, o sistema vai mandar todos os blocos pros dois HDs e fazer uma cópia idêntica, bloco a bloco. Então a performance vai ser a de 1 único HD, um pouco menos até porque agora vai ter o trabalho de gravar no outro HD também. Quando ler, não vai ter quase diferença. Em termos de performance, vai perder um pouco, então, qual a vantagem?

A vantagem é que se um dos HDs morrer, o sistema automaticamente elege o outro como HD primário e na prática você nem vai notar. Seu sistema não vai crashear e vai poder continuar usando tudo como antes. Zero perda de dados. Agora é só comprar outro HD, substituir o que falhou, e no próximo boot o sistema vai copiar tudo do HD que sobrou pro HD novo, criando outra cópia espelho. Aqui trocamos um pouco de performance e metade do espaço por segurança.

Pra entender os outros níveis de RAID com mais HDs, de novo, veja minha playlist sobre armazenamento pra entender mais sobre isso de blocos e redundância de HDs, mas pra hoje eu precisava que vocês tivessem na cabeça esse modelo de tradeoff de performance, segurança e redundância. Isso porque poderia parecer que um RAID-1 é perfeito e vai deixar seu sistema protegido. Isso é verdade até certo ponto. É muito raro de se ver, mas um evento que acontece é bit rot ou degradação de bit ou simplesmente bit flip.

Entenda, qualquer sistema de armazenamento, seja um HD mecânico, seja um SSD que usa chips NAND flash como também SD cards ou pendrives, seja memória RAM, tudo está sujeito a uma hora sofrer algum tipo de degradação. O melhor é quando a falha é bem aparente e ele pára de funcionar totalmente. O problema é quando ele continua funcionando mas os bits armazenados não são mais confiáveis. Tudo é gravado magneticamente. Informação é um linguição de bits. Bits são cargas eletromagnéticas, armazenadas ou transportadas num fio de cobre ou em ondas pelo ar. Qualquer tipo de interferência eletromagnética poderia flipar bits aleatoriamente.

Por isso existe blindagem e todo um processo de fabricação pra evitar ao máximo qualquer tipo de interferência externa, mas nada é perfeito. Escrevendo sobre isso me lembrou de duas historinhas que seria legal vocês saberem. Em 18 de maio de 2003 aconteceu a primeira eleição com voto eletrônico da cidade de Schaerbeek em Bruxelas. Milhões votaram eletronicamente pela primeira vez. Tudo correu conforme esperado até o dia de contar e checar os votos.

Aí a comissão da eleição notou duas coisas fora do comum. Primeiro porque uma candidata razoavelmente desconhecida ganhou milhares de votos a mais do que seria esperado. Mas a segunda coisa que foi mais absurda é que o total de votos foi maior do que o total de pessoas que votaram! Claramente isso é um problema e obviamente vocês imaginam o tanto de gente apontando o dedo um pro outro atrás de fraude. Teve diversas investigações pra entender o que aconteceu, se foi um bug ou manipulação, mas uma coisa chama a atenção. O excesso de votos contados dava exatamente 4096 votos.

Pra todo mundo, 4096 é só um número, mas pra gente de computação, 4096 é um número muito específico. Se vocês não sentiram alguma coisa quando ouviram o número, precisam praticar mais, porque é exatamente 2 elevado a 12. Lembra quando eu falo que vocês precisam se acostumar a converter números decimais e pensar em binário? Um número é uma cadeia de bits, digamos de 32 bits. Se você flipar o bit na posição 13, vai dar esses 4096 a mais se lá estivesse zero. Não quer dizer que não houve fraude, mas é muita coincidência alguém que fosse fraudar pensar num número exatamente assim.

O objetivo não é detalhar o caso, então depois Googlem pra saber como foram as investigações, de fato encontraram bugs de segurança e coisas assim no software. Todo software de votação, ainda mais na primeira vez, ainda mais se não foi visto e revisto, testado e retestado e auditado por diferentes grupos de programadores independentes, certamente tem bugs importantes. Não é talvez, é certeza absoluta. Mas mesmo assim, nenhum dos bugs encontrados conseguia explicar esse acidente em particular. E uma hipótese que não dá pra provar, mas tem chances de acontecer, é que esse bit foi flipado por raios cósmicos.

Pois é, caso você não saiba, estamos o tempo todo sendo bombardeados por milhares de partículas subatômicas que vieram de explosões de Supernovas, que caem na Terra como raios cósmicos. Muitos experimentos delicados são feitos abaixo da terra, com muita blindagem, pra tentar minimizar o efeito desses raios, onde qualquer mínima variação da ordem de um elétron, pode mudar os resultados. Dependendo do estudo que achar pode encontrar que é possível ter 1 bit flip por gigabyte de memória por ano. Sabe aquela tela azul de Windows que só aconteceu uma vez e nunca mais e não teve motivo nenhum? Talvez tenha sido um bit flip de raios cósmicos.

Tem muito mais histórias do que essa das eleições e só mais uma que eu achei interessante porque é um assunto que eu gosto, foi num speedrun de 2013 de Super Mario 64, do usuário DOTA_Teabag. Speedrun pra quem não sabe é competição pra ver quem consegue acabar um jogo no menor tempo possível. Durante esse speedrun, ele esbarrou num glitch considerado impossível sem manipular o jogo. Num determinado pedaço da fase, ele tava simplesmente pousando numa plataforma e fez um warp pra cima do teto sem nenhuma razão.

Todo mundo da comunidade tentou replicar isso, usando emuladores, replicando exatamente os passos do Teabag frame a frame com scripts, mas ninguém conseguiu replicar esse efeito. Isso porque pra realizar esse warp requer o que se chama de um single event upset que é fora do controle do jogador. A única forma de replicar o warp é fazendo um bit flip no número que representa o peso do Mario. Se você flipar 1 bit mudando de C5 pra C4 hexadecimal isso dá o peso exato pra fazer o warp pra cima naquele exato momento.

De novo, é impossível dizer que foi isso, mas a hipótese de novo é que raios cósmicos fliparam esse 1 bit naquela hora, causando o warp. Mas o ponto é que bit flips acontecem, e raios cósmicos é só mais um fator numa enorme lista de fatores que podem levar à corrupção de dados. Em particular quando usamos mídias magnéticas pra armazenar e transportar dados. E se tudo isso ainda não te convenceu, não precisa ir muito longe: quantos de vocês lembram da época de CDs piratas de games e como vocês gostavam de esfregar o disco na camiseta e mesmo o disco tendo vários riscos, ele ainda funcionava. Como pode essas coisas?

Isso é tudo pra vocês entenderem que erros e corrupção de dados são inevitáveis e se vocês nunca notaram isso é um testamento de como a ciência da computação já conseguiu resolver a grande maioria desses problemas e pra todo mundo, tudo simplesmente só funciona. Vamos recapitular. Imagine um arquivo de imagens como esse gato. Obviamente é sempre um gato. Mas o que a gente vê é a representação visual de um linguição de bits. Eu expliquei isso no episódio sobre compressão. Só por conveniência pra mostrar aqui na tela posso representar essa linha contínua de bits quebrando em várias linhas, digamos, em linhas de 11 bits. E eu posso organizar mais ainda cada linha de 11 bits como um bloco.

Em particular, vou organizar os 11 bits da primeira linha num bloco de 16 posições, numerado de zero a quinze. As posições 0, 1, 2, 4, e 8 vamos reservar e eu preencho as 11 posições seguintes com meus bits de dados. Agora vamos olhar metade dos bits e checar o que chamamos de paridade. Paridade é literalmente se temos um número par ou número ímpar de bits 1. Nesse caso temos 2 bits 1, então é par. E assim preenchemos o bit de paridade na posição 1 com zero.

Agora olhamos o próximo grupo e checamos a paridade. Temos 3 bits 1, é ímpar então na posição 2 preenchemos esse outro bit de paridade com 1. Agora que vimos os grupos de colunas na vertical, vamos checar grupos na horizontal. Esse próximo grupo também tem número ímpar de bits 1. Portanto no bit de paridade da posição 4 preenchemos com 1. E finalmente checamos o último grupo, que também tem número ímpar de bits 1, portanto preenchemos o bit de paridade da posição 8 com 1.

Finalmente, checamos a paridade do bloco inteiro. Temos 8 bits 1, é par, então o bit de paridade da posição 0 vai ser zero. Pode parecer complicado mas aguentem até o final do exemplo pra eu explicar o que estamos montando aqui. Nesse momento criamos um bloco de 16 bits pra carregar 11 bits de dados e 5 bits de checagem de paridade. Agora faz de conta que estamos transmitindo esse bloco pela internet, sujeito a todo tipo de interferência eletromagnética, erros de burst, degradação do material do fio e tudo mais, e um ou mais bits desse bloco vai ser flipado no meio do caminho. Mas na outra ponta a gente não sabe disso.

Agora a outra ponta recebeu esse bloco. Duvido que vocês lembrem de cabeça como era o bloco original, então vamos checar a paridade. Checamos o primeiro grupo e vemos número par de bits 1, então o bit de paridade na posição 1 está correto com zero e sabemos que a 2a e 4a colunas parecem ok. O próximo grupo tem um número par de bits 1 mas no bit de paridade na posição 2 está 1, o que é um problema. Sabemos que tem um erro em algum lugar nessas últimas duas colunas. Mas como já sabemos que a quarta coluna tava ok, o problema tá em algum lugar na 3a coluna.

Checando o próximo grupo, temos um número ímpar de bits 1 então o bit de paridade na posição 4 está correto sendo 1, portanto sabemos que a 2a e 4a linha estão ok. E no último grupo temos um número par de bits 1 mas o bit de paridade na posição 8 está 1 em vez de zero. Então temos algum problema nessa duas últimas linhas. Mas já sabemos que a 4a linha tava ok pela checagem anterior, portanto o erro tem que estar na 3a linha. E como já sabemos que tem algum erro na 3a coluna, cruzando as duas sabemos que deve ter um erro na posição 10. Esse bit foi flipado.

Mais do que isso, olhando o bloco inteiro, vemos que a paridade é impar, então no bit de paridade do bloco deveria estar 1 em vez de zero. Isso nos dá confiança de saber que só houve 1 bit flip e não dois, portanto só o bit da posição 10 foi flipado. E se mudarmos de 1 pra zero, jogarmos fora os 5 bits de checagem, temos o bloco correto original de 11 bits que foi enviado.

O que fizemos aqui foram duas coisas: nós tivemos a capacidade de checar a existência de um bit flip, e ainda tivemos a capacidade de recuperar o bit que foi danificado e recuperar o bloco inteiro. O que vocês acabaram de ver foi o algoritmo de correção de erros Hamming Code, nomeado depois de seu criador Richard Hamming. E essa é uma das formas que temos hoje pra correção de erros.

Essas animações devem ser familiares, porque peguei emprestado do excelente canal 3Blue1Brown, que fez dois videos excelentes dois anos atrás explicando exatamente como funciona o Hamming Code. E ele fez isso em conjunto com outro canal que vocês já viram eu mostrar aqui, o do Ben Eater, que implementou Hamming Code em protoboards, em hardware, pra demonstrar como é possível colocar correção de erros em hardware. Eu altamente recomendo que assistam os videos deles pra saberem em detalhes como que isso funciona. Eu assisti esses videos dois anos atrás e tava esperando uma oportunidade pra encaixar eles nos meus videos. Quem seguiu minha recomendação de seguir os canais deles já deve ter visto.

Richard Hamming é um pesquisador da época que se programava em cartões perfurados. Imagina você levar dias escrevendo um programa nesses cartões daí leva pra uma máquina mecânica que vai ler esses cartões através dos furos. Mas vira a mexe ele erra um furo e registra a informação errada. Se até hoje aquelas porcarias de máquinas de refrigerante não conseguem identificar seu dinheiro, imagina uma máquina mecânica velha que tem que ler centenas de cartões sem errar nenhum furo. Isso acontecia tanto que deixou o Hamming putaço. E não existe melhor forma de invenção do que não se acostumar com problemas e sim coçar a própria coceira. E assim ele fez, e inventou todo esse sistema de paridade do Hamming Code pra checar e corrigir erros.

A gente usa Hamming Code até hoje em coisas como memória ECC ou Error Correction Code em RAM de workstations e datacenters. A memória que você tem no seu PC provavelmente não é ECC, mas o servidor de cloud que armazena seus dados certamente tem ECC. E é por isso que coisas como raios cósmicos não são aparentes no nosso dia a dia. Outra forma de correção de erros é o Reed-Solomon Code, que é usado em CDs e Blu-Rays e é por isso que mesmo você riscando o disco, esfregando na sua camiseta, ainda é possível ler os dados.

Mas o mais astuto entre vocês assistindo poderia pensar. Peraí, você tá me dizendo que pra um bloco de 11 bits eu precisei reservar mais 5 bits pra redundância. Ou seja, 45% do espaço e banda de transferência foi desperdiçado pra isso? Então num Blu-Ray de 40 gigabytes eu precisaria ter quase 20 gigabytes a mais só pra redundância?

Mas o mais astuto do mais astudo entre vocês talvez tenha notado que eu fui fazendo checagens naquele bloco de metade em metade. Toda vez que em ciência da computação você vê procuras feitas de metades de metades deveria vir à cabeça procura binária. Lembra os episódios onde falei de árvores e porque árvores são uma das coisas mais importantes que todo programador deveria ter em mente?

Checamos 2 paridades de 2 grupos de colunas verticais, depois 2 paridades de 2 grupos de linhas horizontais. Num bloco pequeno de 16 bits precisamos fazer 4 perguntas de paridade pra localizar e corrigir o bit flipado. Mas e num bloco bem maior, de 256 bits? Vamos precisar fazer só 8 perguntas de colunas e linhas, e pra isso precisamos reservar só 8 bits de redundância. Ou seja, só 3% do tamanho dos dados e não 45% como era no bloco de 16 bits. Quanto maior for o bloco, menor vai sendo a quantidade de bits de redundância necessário. Esse é o poder da procura binária. E eis porque vocês precisam estudar algoritmos e estruturas de dados.

Estamos usando blocos de 16-bits só porque é mais fácil de colocar aqui na tela ou pra você ver no seu celular. Mas um bloco de sistema de arquivos costuma ter pelo menos uns 4 kilobytes de dados. Um bloco de rede costuma ter pelo menos 1500 bits. Mas em rede não se usa nem Hamming e nem Reed Solomon. Só pra coisas como programa espacial da Nasa, onde o Voyager por exemplo usa Reed Solomon Code pras transmissões. Hoje em dia se usa variações de Reed Solomon pra fitas magnéticas, CDs, Blu-rays e toda mídia de armazenamento, incluindo HDs. Você nem sabe disso, mas toda vez que um bloco de dados é gravado no disco, o sistema calcula esses bits de redundância e grava no lugar apropriado no HD.

Então tá resolvido tudo então? Só usar Hamming ou Reed Solomon em tudo que tá tudo certo? Mais ou menos. Por mais que eles sejam altamente eficientes e não gastem tantos bits assim, ainda assim são bits extras, pra cada bloco de bits. A indústria de HDs por exemplo vem pesquisando outras formas que sejam quase tão eficientes quanto Reed Solomon, mas perdem em 0.1% dos casos, como o LDPC code. Reed Solomon tem complexidade O(n^2) o que significa que pra discos gigantes de dezenas de terabytes leva muito tempo pra corrigir erros. Particularmente ruim em data centers que tem arrays com centenas de HDs. Um LDPC atinge 99.9% de recuperação comparado com Reed Solomon mas com complexidade O(n). É uma área ainda com pesquisas ativas.

Recuperar erros não só gasta bits extras de armazenamento como exige processamento pra fazer essa correção. Imaginem agora switches de rede em escala de internet. Por isso eu acho que em rede não se fala tanto em correção de erros e sim em checagem de erro. É muito menos trabalho identificar que tem um erro, mas não recuperar esse erro. Se você tá fazendo aquele download longo e vê a velocidade cair porque a internet da sua região é bem instável, não é tentativa de correção de erros que tá acontecendo e sim repetição de pacotes.

Em rede, funciona mais ou menos assim. Seu arquivão de download é quebrado em vários pacotes, enviados um atrás do outro. Seu PC vai recebendo esses pacotes e remontando o arquivo. Mas ele faz uma checagem antes. Essa checagem é parecida com a checagem de bits de paridade do Hamming Code, mas um pouquinho só mais sofisticado. No caso de internet falamos de checksum, em particular, Internet 16-bits. Esse checksum é uma soma dos bits do bloco dividido por palavras de 16-bits. Existem formas melhores como Fletcher’s checksum ou CRC, que é Cyclic Redundancy Check. Mas eu acho que ainda se usa Internet 16-bits mesmo.

De qualquer forma, entenda que existe essa checagem via checksum pra cada pacote. Se for detectado que houve um bit flip ou coisas como burst, que é comum, o pacote é rejeitado e seu PC manda aviso de volta pro servidor, “olha, o pacote ID xpto veio cagado, manda de novo”. Esse é NAK que falei antes. Daí o servidor manda o mesmo pacote outra vez. É um dos motivos de porque você vê a velocidade de download caindo e flutuando. No caso de rede é mais barato pedir o pacote de novo do que tentar corrigir ele. Correção é mais importante quando você não tem pra quem pedir uma cópia original, como arquivos no seu HD, que só você tem.

No começo da internet a gente usava um serviço chamado Usenet, que usava o protocolo NNTP. Pensa tipo um sistema de fóruns. Assim como o protocolo SMTP de email ou HTTP de web, era outro protocolo baseado em texto puro de 8 bits. Ele foi feito pra transmissão de texto e não arquivos binários. Pense em usenet como Wordpress que povo tenta entuchar mais coisa do que ele foi planejado pra fazer. Usenet foi feito pra sincronizar artigos de texto entre diferentes servidores Usenet. Mas obviamente, a gente achou jeitos de entuchar arquivos binários pra fazer pirataria. Estamos falando de uma era anos antes de bittorrent.

Eu mesmo fiz muito isso na faculdade. A gente baixava imagens, software e tudo mais da Usenet. O problema é que por diversas razões, os arquivos podiam acabar corrompidos. Erros de conversão. Erros nos discos rudimentares dos servidores da época e tudo mais. Mas o problema é que invariavelmente eles acabavam corrompidos. Primeiro, a gente precisa resolver o problema de trafegar arquivos binários num protocolo de textos.

Os mais astutos já tem a resposta na ponta da língua. Base64. É uma forma de transformar binários em textos de 7-bits. Base64 não é encriptação de jeito nenhum. O problema é que se você tentar abrir um arquivo binário num notepad, não tem como dar copy e paste em outro notepad e salvar o arquivo, vai corromper tudo, porque um editor de textos não reconhece todos os símbolos binários. A solução é converter o binário num sub-conjunto de ASCII que um editor de textos entenda e depois converter de volta num binário. O custo disso é gastar um pouco mais de espaço.

Cada dígito de Base64 representa exatamente 6 bits de dados. Então 3 bytes de 8 bits cada do arquivo, ou seja, 3 x 8 ou 24 bits, podem ser representados por 4 dígitos de 6 bits, que dá 24 bits também. Isso significa que a versão Base64 do arquivo vai ser 133% maior do que o original. Um arquivo binário de 100 megabytes vai virar 133 megabytes em Base64.

Como arquivos podem ter tamanhos variados, como um filme longo por exemplo, ou o instalador do Photoshop ou coisas assim, pra Usenet não reclamar, a gente quebrava esse binários primeiro em múltiplos binários usando o bom e velho formato rar ou WinRar, porque assim como Zip ele compactava o arquivo, mas diferente de zip, ele permitia quebrar em múltiplos arquivos com final .rar2, .rar3 e assim por diante. E depois que baixava todos os rars, o WinRar conseguia remontar e descompactar o original.

Então o processo era simples: faz vários arquivos rar, converte em texto Base64, na época usando a ferramenta uuencode do UNIX, que significa unix to unix encode. Postava cada pedaço em um artigo da Usenet. Do outro lado a gente baixava o base64 de cada pedaço, usava uudecode pra conseguir os binários de volta, e usava um equivalente WinRar pra descompatar os arquivos originais. Era assim que a gente fazia antes de Google Drive, Mega ou BitTorrent.

Como disse antes, a Usenet não foi feita pra transportar arquivos, e por inúmeras razões, incluindo defeitos nesse monte de passos que a gente tinha que fazer, alguns bits acabavam corrompidos. Então a gente precisava de uma forma de garantir que dava pra recuperar de alguma forma após o download, caso notássemos que o arquivo veio corrompido. E aí surgiu a idéia do Parchive ou arquivos .par ou a versão melhor que foi o Par2. Agora você podia baixar os arquivos rar e também os arquivos par2, que era bem menores. E se o rar estivesse corrompido na hora de descompactar, podia experimentar recuperar usando os arquivos .par2.

E o que é Par2? É basicamente aqueles bits de redundância como no exemplo do Hamming Code, só que são os bits pra Reed Solomon Code, como eu disse que funciona pra CDs. Os primórdios da Internet era muito legal porque a gente era obrigado a aprender essas coisas se quisesse baixar pirataria. Eu me lembrei disso porque recentemente decidi fazer backup dos videos originais aqui do canal em M-Discs ou Millennial Disc, a evolução dos discos Blu-Ray. É tecnologia nova, de 2010 pra cá. E me perguntaram se não era bom eu fazer parchives pra gravar junto, eu até fiz, mas acho que não precisava.

De curiosidade pra quem não sabia, CDs, DVDs e Blu-rays comerciais comuns, vem com uma camada de proteção pra proteger contra riscos leves, aquela esfregada leve na camiseta. Porém, essa camadinha é feita de material orgânico que reage com oxigênio e umidade do ar. Significa que mesmo que você guarde com todo cuidado possível, eventualmente essa camada vai degradar e você pode acabar com um disco que não dá mais pra ser lido. Pode demorar 10 anos, demorar um pouco mais, mas é questão de tempo. Sua coleção de CDs não vai durar pra sempre a menos que esteja numa câmara a vácuo com zero umidade e temperatura controlada. E mesmo com os bits de redundância de Reed Solomon, você vai perder dados se essa camada danificar o suficiente.

Por isso escolhi M-Discs. Eles são basicamente Blu-rays só que a camada de proteção é feita de material inorgânico, não reagente, não oxidante. Só pra ter uma imagem, pensa uma camada de proteção feita de pedra. Em testes de mais de 250 horas sob temperaturas de 90 graus Celsius, 85% de umidade, mesmo assim os discos permanecem intactos. Por isso se chamam millennial discs, são discos feitos pra durar mil anos, sob condições adversas. Perfeitos pros meus backups. Alguns vieram sugerir fitas magnéticas, mas nesse mesmo nível de durabilidade, custam ordens de grandeza mais caro por gigabyte.

E eu disse que não precisava ter manualmente criado arquivos par2 com os bits de Reed Solomon Code porque um Blu-ray por padrão já tem esses bits. Hoje em dia tem poucos motivos pra se preocupar com bits de redundância porque a maioria dos sistemas de armazenamento modernos tem esse cuidado, incluindo seu SSD e seu HD. Só sua RAM que ainda não porque memória ECC é bem mais cara. Mas como no mundo caseiro a gente dá refresh nessa RAM porque bootamos toda hora, a chance de um bit flip causar problemas é muito baixa. De vez em quando, uma tela azul de Windows sem motivo nenhum, é a rara consequência que você vai encontrar.

Hoje em dia não precisamos baixar arquivos par pra recuperar downloads corrompidos, mas muitos sites de downloads você já deve ter visto um código md5 ou sha1 junto pra checar a integridade do binário. Eu já expliquei sobre isso no episódio de criptografia, mas um sha1 é um algoritmo de hashing, um tipo de checksum. Se baixarmos a ISO de uma distro de Linux, e tiver sequer um bit flip, passando por sha1 o hash resultante vai ser completamente diferente do hash original que deveria ser. Por isso é um mecanismo importante pra sabermos se não houve bit rot ou mesmo manipulação no meio do caminho. Sha1 é muito superior a uma mera checagem de paridade, mas também custa mais caro pra processar.

Menciono isso porque já que comecei falando de NAS, em sistemas de RAID como o Linux Raid ou sistemas de arquivos realmente modernos como Btrfs ou ZFS que expliquei no último episódio da série de armazenamento, eles oferecem proteção contra erros e exigem rodar uma tarefa em background com alguma periodicidade chamada Data Scrubbing. No ZFS tem um comando justamente chamado scrub pra isso, detectar e corrigir data rot.

No meu NAS também tem essa opção de agendar um data scrubbing a cada 3 meses ou o período que eu quiser. Não precisa rodar sempre. Mesmo o HD tendo suporte a Reed Solomon Code, nem isso garante que vai estar tudo ok. Checar e corrigir erros é uma tarefa que custa processamento e tempo, por isso não se roda toda hora. Ele vai usar coisas como checksum de cada arquivo, equivalente ao que falei de checar o hash depois de um download, pra ver se o arquivo está intacto. Isso exige ler e calcular em cima de todos os bits do arquivo.

Por isso custa processamento. Se coisas como o checksum ou paridade não baterem, ele usa a cópia redundante do RAID pra reconstruir o pedaço com danificado. E vai fazendo isso arquivo a arquivo. Se tiver poucos erros é fácil de consertar, mas se deixar acumular por chegar num estado que é impossível recuperar, por isso se roda data scrubbing periodicamente.

Como disse antes, pra maioria de vocês, tudo isso é invisível. Se um pacote na rede é corrompido, seu sistema pede pro servidor reenviar os pacotes. Se um arquivo é levemente corrompido na hora de gravar no seu HD, ele tem sistemas pra se auto corrigir. Com exceção de desastres graves, você raramente tem problemas de ver corrupção de dados. Seu streaming sempre funciona, as páginas que carrega sempre vem inteiros, e tudo isso porque pesquisadores como Hamming, Reed, Solomon, Shannon e muitos outros criaram as bases pra que tudo isso funcione. Mas de qualquer forma é bom saber porque as coisas funcionam num ambiente hostil onde corrupção de dados deveria ser o normal.

O objetivo desse episódio era complementar o que falei nos episódios de armazenamento, no episódio sobre compressão, e o anterior onde comecei a falar sobre transmissão de dados e redes. Viemos muito longe desde um simples telefone de copinho e barbante e agora você sabe porque. Se ficaram com dúvidas mandem nos comentários abaixo. Se curtiram o video deixem um joinha, assinem o canal e compartilhem o video pra ajudar o canal. A gente se vê, até mais.

DESCRIÇÃO

Finalmente vou começar a explicar o básico do básico de redes pra programadores iniciantes finalmente entender como de fato a Internet funciona, pra no futuro poder explicar melhor como aplicações web são arquitetados e como coisas como Docker conseguem funcionar.

Esta é a Parte 1 de uma mini-série inicial de 3 episódios. Assinem o canal pra não perder o resto!

Conteúdo

• 00:00 - Intro
• 00:53 - Modem da Vivo
• 01:52 - Bits vs Bytes
• 02:59 - Primórdios da Internet discada
• 05:10 - Fibra ótica e cabo de cobre
• 08:04 - Wifi
• 10:11 - 5G
• 14:31 - Preciso de quanta velocidade?
• 16:24 - Primórdios da comunicação: telefone de copinho
• 19:19 - Telecom e computadores
• 22:27 - teclados de novo??
• 23:18 - Par trançado, multiplexing e modulação
• 27:10 - Modem discado e ADSL
• 31:23 - Datagramas
• 33:08 - De comutação de circuito a pacote
• 36:30 - Conclusão

Links

• Cheat sheet: which 4G LTE bands do AT&T, Verizon, T-Mobile and Sprint use in the USA? (https://www.phonearena.com/news/Cheat-sheet-which-4G-LTE-bands-do-AT-T-Verizon-T-Mobile-and-Sprint-use-in-the-USA_id77933)
• What are the differences between 2G, 3G, 4G LTE, and 5G networks? (https://rantcell.com/comparison-of-2g-3g-4g-5g.html)
• How DSL Works (https://computer.howstuffworks.com/dsl.htm)
• Why are Wires Twisted in Twisted Pair Cables? (https://www.systoncable.com/why-are-wires-twisted-in-twisted-pair-cables/)
• Ethernet cable speed categories explained (https://www.allconnect.com/blog/what-ethernet-cord-do-you-need)
• Coaxial vs Ethernet cable - What’s the Difference? (https://www.truecable.com/blogs/cable-academy/coaxial-vs-ethernet-cable-whats-the-difference)
• [Akitando #79] Teclados Mecânicos Exóticos | Minha coleção - Parte 2 (https://www.akitaonrails.com/2020/05/12/akitando-79-teclados-mecanicos-exoticos-minha-colecao-parte-2)
• V.90 Dial-up Modem Handshake - Transactional Analysis (https://www.youtube.com/watch?v=VaWpi9o_hHI)

SCRIPT

Olá pessoal, Fabio Akita

Quem me acompanha no instagram viu minha saga atualizando meu armazenamento pra um NAS maior e mais rápido, inclusive os problemas que tive e como resolvi. Mas durante as semanas que postei stories, recebi dezenas de mensagens diretas com dúvidas elementares. Mesmo programadores tem buracos de conhecimentos importantes quando se fala de redes.

Eu não sou nenhum especialista em redes, bem longe disso, e é um dos motivos de porque evitei falar do assunto por tanto tempo. Minha intenção não é falar sobre tudo que existe do assunto, precisaria de um canal inteiro pra isso. O que quero falar neste e nos próximos dois episódios são só alguns conceitos que podem ser úteis pra iniciantes. Sem entender nem o que vou explicar nesta mini-série, não tem como entender coisas como Docker, que eu quero falar no futuro.

(…)

Vamos começar com coisas que todo mundo tem em casa. Esse aqui é meu modem da Vivo, estou com um plano de fibra ótica de 300 megabits por segundo. Olha aqui, esse fininho é a fibra ótica. Vamos checar? Só digitar “speedtest” no Google e você pode usar esse aqui do próprio Google, ou esse aqui embaixo da Ookla que é bem famoso, ou o Fast do Netflix, que por alguma razão dá números um pouco mais inflados. Cada um vai dar medidas um pouco diferentes mas no geral é próximo da velocidade de verdade. Vamos ver os três rodando um pouco.

Olhem só como é diferente, mas uma coisa é certa, o download tá ok dentro do plano de 300 megabits por segundo. Nos três fica até um pouco acima disso, mas o upload é sempre lá pela metade dessa velocidade. Provedores sempre fazem isso porque você nota mais lentidão em download do que upload. Mas tudo bem, um episódio aqui do canal fica na faixa de 10 a 15 gigabytes. Nessa velocidade eu consigo subir pro YouTube em aproximadamente 15 minutos. Não é ruim. Agora, você consegue saber como chega nessa estimativa?

Muita gente vê os planos escritos 100 mega, 300 mega, e assume que é 100 megabytes ou 300 megabytes, mas não, são megabits. E isso faz muita diferença. Lembram? 1 byte são 8 bits. Portanto 300 megabits você divide por 8 pra ter em megabytes. 300 dividido por 8 é 37 megabytes por segundo, esse é o máximo que vai conseguir em downloads. Se for um plano de 100 megabits, divide por 8, não é muito mais que 12 megabytes por segundo de download. Essa é a velocidade que interessa.

Quando se fala em velocidades de rede, por alguma razão se fala em bits em vez de bytes. Eu acho que tem o lance de pro marketing parecer melhor pra colocar números grandes em propagandas, mas acho que tem a ver com o histórico de que antigamente, estou falando de década de 60, transmitir 300 bits por segundo era considerado bastante. Eu mesmo cheguei a usar modem de linha discada de 9600 bits por segundo. Em 1991, a velocidade média era de 14 kilobits por segundo. Se dividir por 8 pra ter em bytes, é nada menos que 1.75 kilobytes por segundo. Pouco mais de mil e setecentas letras de 1 byte cada, por segundo.

No fim dos anos 90, começo dos anos 2000, a maioria das pessoas estava em modems de 56 kilobits por segundo. Só quando começamos a ter ADSL com serviços como o Speedy, que chegamos perto do elusivo 1 megabit por segundo, que ainda assim, dividido por 8 são só 128 kilobytes por segundo. Lembro quando eu vi um demo da Ajato lá por 1993, e download de 1 megabit parecia a coisa mais rápida do mundo.

Deixou o eu no colegial daquela época realmente imaginando que chegamos no futuro. Agora pensa, um arquivo de música mp3 de qualidade média é alguma coisa na faixa de 5 a 10 megabytes. Digamos que seja 10 megabytes. Quanto tempo leva pra baixar esse arquivo com um modem do fim dos anos 90 de 56 kilobits por segundo?

A conta é 10 megabytes vezes 1024 pra ter em kilobytes. 1024 porque estamos falando em binário e isso é 2 elevado a 10. Tem toda uma controvérsia de usar múltiplos de 1000, mas isso é só marketing. O certo é sempre potências de 2. Daí divide isso por 56 kilobits, dividido por 8 pra ser bytes. E isso vai dar uns 1462 segundos, dividido por 60 e vai dar nada menos que 24 minutos.

Quase meia hora pra baixar uma música que não tem muito mais que 5 minutos de duração. Essa é a era antes do streaming ser possível. Lembram do episódio que expliquei compressão? Pra streaming de áudio ser possível, eu precisaria no mínimo ser capaz de baixar essa música nos mesmos 5 minutos de duração. Por isso que não existia streaming nos anos 90 e começo dos anos 2000.

A velocidade mínima seria esses 10 megabytes do mp3 divido por 5 minutos, ou seja, 2 megabytes por minuto. Isso vai dar 40 kilobytes por segundo, ou 320 kilobits por segundo. Nem é muita coisa, mas o modem da época de 56 kilobits era 6 vezes mais devagar. Os anos 2000 não foram fáceis não, por isso a gente deixava um monte de downloads enfileirados a noite inteira pra conseguir baixar um álbum de música. Em pouco mais de 20 anos fomos de 1 megabit pros 300 megabits que tenho em casa agora. 300 vezes mais rápido, e isso nem é o máximo que dá pra chegar. Nos Estados Unidos, Canadá, Japão e outros lugares existem alguns planos de 1 gigabit por segundo.

Quando falamos em velocidades assim, pensamos em fibra ótica, que é o que tem nesse meu modem. Pense numa fibra ótica como um tubinho muito fino de fibra de vidro por onde passa luz. Literalmente se eu acender luz numa ponta, vai acender na outra ponta. Vocês já devem ter visto em algumas baladas.

Se não me engano um bom cabo de fibra ótica, e tem tipos diferentes, tem capacidade de transmitir até 10 gigabits por segundo por uma faixa de 5 a 10 quilômetros. Isso é máximo teórico. Distância afeta banda, porque mesmo numa fibra ótica existe perda de sinal. Em todo cabo, quanto maior a distância, menor a velocidade porque maior vai ser a perda de sinal e interferência no meio do caminho.

Abaixo de fibra ótica estão cabos de rede como este, cabos ethernet, com conector RJ-45. Eles são divididos em categorias. Na prática à medida que conseguimos ir melhorando os processos de fabricação e os processadores de switches e roteadores, fomos subindo de categoria. E a gente classifica esses cabos pela categoria ou cat. Esse na minha mão acho que é o mais comum, Cat 5e. Na dúvida hoje em dia, assuma que deve ser cat 5e ou até cat 6.

Cat 1 até 3 acho não se usa mais, não lembro se teve cat 4. Era pra redes inferiores a 10Base-T, ou seja, menos que 10 megabits por segundo pra baixo. Lembra que nos anos 2000 a gente male male tava falando de 1 megabit pra internet? 10 megabits era 10 vezes isso, tava ótimo pra época. Um CD-ROM ocupava 650 megabytes, seria menos de 10 minutos pra transferir numa rede de 10 megabits. No cat 5 subimos pra rede de 100 megabits. Alguns lugares com cabeamento antigo ainda devem ser cat 5. Mas tudo isso já é considerado obsoleto.

Com cat 5e fomos pra rede de 1000 megabits ou 1 gigabit por segundo. Eu acho que a maioria dos computadores, pelo menos dos últimos 10 anos pra cá, se tem placa de rede, é 1 gigabit. A maioria das placas mãe de boas marcas como Gigabyte ou MSI já tem com porta de ethernet 1 gigabit. A minha placa mãe mais moderna que é o X570s vem com porta de 2.5 gigabits. Cabos mais modernos são categoria 6 e 7, que tem especificações de construção mais exigentes e conseguem suportar sinais na faixa dos 500 Mhz e conseguem ir até os 10 gigabits por segundo de redes modernas. Mas até pra redes 1 gigabit vão ser melhores que cat 5e. Na dúvida, só compre cabos cat 6. Cat 7 e cat 8 a maioria não vai precisar.

1 gigabit por segundo numa rede local tá ótimo. A internet que a maioria das pessoas tem em casa é 10 vezes mais lento que isso. Então dá e sobra pra conectar múltiplos dispositivos na rede, compartilhar a internet e ainda sobra banda pra transferir arquivos localmente e tudo mais. Pra fazer streaming de video, na prática, acima de 3 megabits já é possível. Ou seja, a maioria das pessoas não lida com nada muito maior que 10 megabits. Rede 1 gigabit é 100 vezes isso.

Considere também as redes sem fio como do seu celular. Se estiver numa boa região metropolitana com 4G LTE pelo menos, as velocidades são mais ou menos. No meu celular eu consigo a faixa de 60 a 70 megabits por segundo pra download e menos de 5 megabits pra upload. Eu pessoalmente acho horrível, mas pra média da população isso é rápido o suficiente. De novo, acima de 3 megabits dá pra fazer streaming, receber mensagem de áudio e tudo mais, então tá ótimo.

Falando nisso, saiu faz pouco tempo o novo padrão Wifi 6 que promete ser umas 3x mais rápido que Wifi 5, que é o que todo mundo tem. Mas Wifi 5 não é grande coisa também. Vamos fazer outro teste rápido. Esse é o Librespeed, uma versão open source do Speedtest do Google que mostrei lá no começo. É um teste de download e upload do meu PC pro meu NAS usando rede cabeada. Tá ótimo, faixa de 6 gigabits de download e de upload.

Minha rede é de 10 gigabits, mas depois falo disso. Agora vamos ver meu smartphone conectado via wifi na mesma rede acessando o mesmo serviço. É essa coisa ridícula aqui de faixa de 200 megabits por segundo. Wifi é umas 3x mais lento que uma rede 1 gigabit que todo mundo tem. Mas é mais rápido que a internet do seu provedor então, de novo, tá ótimo.

Wifi e outras formas de comunicação sem fio usam o ar como o meio de transporte das ondas em vez de cabos de cobre. Mesmo com paredes no meio do caminho, a onda consegue passar e continuar em frente, embora perdendo força. Você sabe disso porque se gritar de um quarto, sua mãe vai te xingar lá da cozinha. A onda da sua voz atravessa paredes e chega até lá. Tudo que oferece resistência vai diminuir o sinal e introduzir barulho. Por isso que você não consegue ir tão longe do seu roteador sem notar que a velocidade caiu bastante.

Sua voz tem baixa frequência, por isso atravessa paredes fácil. Quanto maior a frequência, mais difícil é atravessar paredes, por isso que o Wifi mais comum é o que opera na faixa de 2.4Ghz e você consegue ir até uns 100 metros de distância e ainda navega, mesmo que mais lento. Mas na rede mais rápida de 5Ghz, uma ou duas paredes e você já nota que fica bem ruim de usar.

Isso é outro assunto que daria uma tangente enorme, mas basta saber que essas bandas de frequência são convenções definidas por política. Várias organizações estabeleceram quais bandas podem ser usadas pra quais coisas. A faixa de 900 Mhz e 2.4 Ghz, por exemplo, são chamadas de ISM ou Industrial, Scientific, Medical, que são bandas não licenciadas que podem ser livremente usadas sem interferir com aplicações militares, por exemplo. Mas por isso também os canais dessas bandas costumam ser super congestionadas porque coisas como seu telefone sem fio, controle remoto de garagem e tudo mais operam nas mesmas bandas que seu Wifi e tudo isso causa interferências.

Por causa disso, a partir de 2001 a organização FCC abriu a faixa de 5Ghz até 64Ghz pro público. É nela que trafega coisas como TV aberta em alta definição, que sua TV capta por antena. É na parte mais baixa dessa banda, nos 5Ghz que opera a maioria dos pontos de acesso de Wifi. Na prática, quanto maior a frequência, maior a velocidade, mas menos área o sinal cobre e mais dificuldade tem de passar obstáculos, como paredes. É o problema do 5G, que tem várias versões. Se você não sabia, 5G não é só uma coisa, são diferentes bandas de frequência.

No começo dos anos 2000 a gente experimentou redes sem fio 2G, que ainda era comutação de circuito e velocidades de pico na faixa de 64 kilobytes por segundo. E cuidado que wireless a gente fala em velocidade de pico, que é em situação ideal, com sinal limpo, pouca ou nenhuma interferência. Na vida real a velocidade vai ser menor e variar bastante dependendo de onde você está. Mas em seguida tivemos 3G, na época do iPhone 3G lá por 2008. Agora já era packet switch indo até uns 2 megabits por segundo, e uma revisão que veio depois, o 3G HSPA+ que podia ir de uns 8 megabits até 21 megabits por segundos, usando a banda de de 15 a 20 megahertz.

Eu tô simplificando bastante porque 3G, 4G, 5G são famílias de tecnologias. Cada uma usa diversas bandas diferentes de frequências. Por isso o 4G de um provedor pode ser diferente do 4G de outro provedor. Por exemplo, nos Estados Unidos a T-Mobile usava bandas de 800 Mhz até 1900 megahertz. Mas a Sprint usava banda de 850 até 2500 megahertz. Velocidade máxima teórica de 4G seria equivalente a uma rede de 1 gigabit, mas na prática não ia muito mais que 50 megabits por segundo.

A gente sempre operou wireless em faixas abaixo de 2 gigahertz. A tal quinta geração ou 5G entra numa categoria de ondas chamado Extreme High Frequency, literalmente frequências extremamente altas, que vai de 30 até 300 gigahertz. Isso é o que se chama de millimiter wave. Pra comparação, o que a gente chama de microondas ou microwaves é de 3 a 30 gigahertz. Millimiter wave começa nos 30 gigahertz. Eu posso estar falando bobagem, mas acho que o que se chama de 5G comercial hoje em dia é bem abaixo disso, um pouco mais que a faixa de 4G LTE. É mais rápido, mas não tanto quanto se espera.

Millimiter wave é muito mais rápido, subindo do máximo teórico de 4G de 1 gigabit e indo direto até 10 gigabits. De novo, teórico, porque apesar da alta velocidade, a altíssima frequência significa que tem alcance muito menor, muito mais direcional, e é muito fácil de interferir, por isso tem dificuldade de atravessar obstáculos como prédios entre o celular e as antenas. Logo, precisa de muito mais antenas pra cobertura e por isso demora tanto pra ter em todo lugar. Não espere ver essa banda perto de você tão cedo.

Na prática é só entender que transmitimos dados como ondas usando o ar como meio. Existem várias faixas de frequências úteis que vão de 3 kilohertz até o topo de 300 gigahertz. Politicamente várias dessas faixas foram reservadas pra usos específicos, por exemplo, rádio AM dentro da banda que vai de 300 kilohertz até 3 megahertz, rádio FM dentro da banda que vai de 30 megahertz até 300 megahertz, 4G que tá banda seguinte até 3 gigahertz.

E agora explorando millimiter wave que começa em 30 gigahertz e antes era usado mais pra comunicação via satélite, astronomia e coisas assim. Tudo isso porque aprendemos a modular e demodular sinal digital em analógico, e graças a pesquisadores como Claude Shannon sabemos como lidar com interferência e garantir que os pacotes que recebemos estão intactos.

Estou dando todos esses números pra vocês terem um pouco de ordem de grandeza das coisas. No mundo de data centers, os engenheiros estão lidando com redes acima de 10 gigabits, Fibra ótica e tudo mais. No mundo caseiro, a média da população ainda tá na era da rede 100 megabits, tecnologia de uns 20 anos atrás. Mas como eu disse, a média da população não lida com petabytes de dados. A maioria dos HDs de vocês male male tem meio terabyte, um quarto de terabyte. O maior volume de transferência é streaming de video. Realmente não precisa de mais que 100 megabits. 1 gigabit já tem muita sobra.

Eu acho 300 mbps de download e 150 mbps de upload da Vivo muito lento. Mas por outro lado, eu também não uso mais que isso no dia a dia, só de vez em quando queria ter internet gigabit. Mas o custo não compensa, por isso aguento com velocidades baixas assim. Um exemplo de eventos raros onde isso faz diferença. Estou fazendo backup do meu backup no serviço AWS Glacier. É tipo um S3 mas feito pra backups e coisas que não se acessa o tempo todo, então é mais barato pra armazenar. Estou transferindo uns 15 terabytes de dados pra lá. Quanto tempo acha que leva, nesse plano da Vivo de meros 150 megabits de upload?

Vamos fazer as contas. 150 megabits, dividido por 8, é menos de 19 megabytes por segundo. 15 terabytes, multiplicado por 1024 dá 15.360 gigabytes, multiplicado de novo por 1024, dá mais de 15 milhões de megabytes. Agora dividindo pela velocidade de 19 megabytes por segundo, vai dar mais de 800 mil segundos.

Dividido por 3600 dá mais de 229 horas, dividido por 24 horas, dá pouco mais de 9 dias. Isso sem contar horas do dia que a velocidade fica instável ou cai. Fácil isso vai dar mais de 10 dias pra eu conseguir transferir tudo pra lá. Por isso eu disse que é uma velocidade horrendamente baixa. Só que só retardados como eu faz uploads de 15 terabytes de coisas. Não é o normal.

Já que estamos falando de modem, eu queria fazer uma tangente pra dar outra noção que muitos não devem ter. Como que os dados são transportados na fibra ou em cabos como coaxial ou ethernet? Pra explicar isso precisaria de mais física do que estou confortável pra explicar então vou usar um exemplo beeeem simplificado só pra ter uma imagem na cabeça. Lembra quando vocês eram criança e brincavam de telefone de copinho? Como que fazia? Prendia cada ponta de um fio bem longo no fundo de dois copos e ia longe até esticar o cabo sem arrebentar.

Quando você gera voz, tá empurrando o ar com uma certa frequência e amplitude pra cada fonema. Já viram como a voz é representada num programa de edição como esse aqui? Tudo que eu vou falando é representado como ondas. Olha só, aaaaa …. bbbbb …. ccccc …. No mundo físico isso são minhas cordas vocais vibrando e empurrando o ar. Isso vai bater no fundo do copo e vibrar o fio conectado nele.

Se o fio estiver tensionado o suficiente, ele vai transferir essas ondas até a outra ponta. E o copo no final vai servir pra amplificar um pouquinho o que recebeu e empurrar o ar até seus ouvidos. Na real “empurrar” não é o termo adequado porque não está movendo nada, é como numa bacia de água em repouso quando vc toca numa ponta, gera uma onda, que vai até outra ponta, mas se tiver algo boiando no meio, ela continua no mesmo lugar. A água, o ar, ou o fio, servem de meio por onde as ondas vão trafegando. E a voz e outros sons são formados pelas diferenças em amplitude e frequência dessas ondas.

É mais ou menos assim mesmo que os telefones antigos também funcionavam, com materiais um pouco menos rudimentares que copinhos de plástico e barbante. Mas nesse modelo, só dá pra ligar uma pessoa até outra pessoa. E se eu quisesse falar com pessoas diferentes? Já viram filmes antigos que tinha telefonistas? Você estava sempre conectado com uma central onde atendia uma telefonista. Daí dizia pra ela, “me conecta com fulano de tal” e aí ela pegava um fio e ligava num painel. Era ela ligando o fio do seu telefone, via esse painel, com o fio do outro telefone, fechando um circuito.

Isso é no começo da telefonia comercial, um século atrás quase, claro, depois eliminou-se essa posição de pessoa ligando cabos e passou a se usar sistemas que conectavam números de telefone automaticamente, os switches. Nem eu antigamente nunca falei com uma telefonista, era só discar o número e esperar a outra ponta atender. Mas imagine que é o mesmo cenário, onde se faz switching, ou comutação, e fecha um circuito entre as duas pontas, como no telefone de copinhos.

Isso se chama circuit switching ou comutação de circuito. E nesse caso a linha entre eu e a outra pessoa fica dedicada a essa sessão até uma das pontas desconectar. Por muitos anos foi assim que funcionou, toda casa tinha uma linha telefônica ligada numa central, e a gente pagava por minuto que a sessão ficava aberta entre dois telefones. O sistema automático que substituiu a telefonista fazia o switching e a bilhetagem. E foi assim que o mundo se conectava.

Em paralelo, estamos falando dos anos 60 a 70, no mundo empresarial estavam experimentando com esse tal de computador, que como todo mundo já viu em fotos antigas, eram equipamentos gigantes que ocupavam um quarto inteiro. Super quentes, e pros padrões de hoje, extremamente fracos. Se falarmos de começo dos anos 70, um PDP-11 tinha CPU de 16-bits e poderosos 15 megahertz e na faixa de pouco mais de 2 kilobytes de RAM, acho que podia ir até 32 kilobytes.

Se você não consegue entender essa ordem de grandeza pense no seu celular onde está assistindo esse video, ou seu notebook. Ele tem uma CPU de múltiplos cores onde cada um roda na faixa de 2 gigaherz ou mais. Giga é mil vezes mais que mega. Estamos na ordem de processamento de mais de mil vezes um processador dos anos 70. E você tem mais de 1, talvez uns 8, rodando em paralelo. No PDP-11 era um só de 15 megahertz.

Memória então, nem se fala. Seu celular talvez tenha o quê, uns 4 gigabytes? Gigabyte é 1024 vezes megabyte que é 1024 vezes kilobyte. Você está numa ordem de grandeza de um milhão de vezes mais memória que se tinha nos anos 70. Não é dobro, não é 100 vezes, é um milhão de vezes.

Até aproveitando, muita gente me pergunta qual computador é ideal pra aprender a programar e a resposta é óbvia: qualquer um que você conseguir comprar. Não existe “computador melhor pra aprender”. O computador mais furreca que você comprar hoje é mil vezes melhor do que eu tinha pra aprender nos anos 80. Se eu aprendi a programador num PC na faixa de 6 megahertz com 1 mega de RAM, não vejo porque você não possa aprender a programar num Raspberry Pi de 1 gigahert com 1 gigabyte de RAM. Quem realmente quer aprender, aprende com qualquer equipamento que tiver acesso e aprende a espremer o máximo dele. Se você não consegue extrair o máximo de um computador fraco, um computador mais forte é um desperdício pra você.

Só que nos anos 70, 15 megahertz de processamento e 2 kilobytes de RAM era bastante coisa e super caro. Coisa da faixa de 150 mil dólares, em dólares dos anos 70. Ajustado pela inflação seria mais de 1 milhão de dólares de 2022. É um puta investimento. E custando caro assim, obviamente eram recursos que precisavam ser divididos por mais pesquisadores e engenheiros ao mesmo tempo. Desses esforços que surge coisas como o sistema operacional UNIX cuja função era não só facilitar escrever aplicativos, mas compartilhar a máquina com mais de um usuário. É o conceito de time sharing, ou compartilhamento de tempo.

Pra conseguir ter várias pessoas usando o mesmo computador ao mesmo tempo, primeiro o sistema operacional precisava dividir o tempo de processamento e a memória pra vários aplicativos rodando em paralelo. Eu fiz dois vídeos explicando como se faz isso, mas em resumo ele deixa um aplicativo rodar por um tempo, daí pausa ele, e dá tempo pra outro aplicativo de outra pessoa rodar um pouco. Daí pausa esse, e resume o anterior que tava pausado. No total cada um vai levar mais tempo pra rodar, mas pelo menos os dois puderam iniciar os trabalhos ao mesmo tempo e não ter que ficar esperando na fila de braços cruzados esperando o outro acabar.

Quando esse tipo de sistema começou a ficar possível, agora seria mais conveniente que cada pessoa tivesse seu próprio monitor e teclado, pra realmente trabalhar simultaneamente no mesmo computador. E assim começou a surgir os tais terminais burros. Na parte 2 dos meus videos de teclado eu explico um pouco como isso funcionava. E parte das tecnologias do mundo de telecomunicações passaram a entrar nos computadores.

Como um exemplo pequeno, eu tenho aqui esse teclado IBM Model M dos anos 80 e ele não tem um cabo USB, óbvio, mas também não é o conector PS2 que se tinha nos anos 90. É um cabo telefônico de par trançado com conector RJ-11, que é o mesmo cabo e conector que se usava em telefones nos anos 80. Eu não cheguei a usar esses terminais, mas acho que eles literalmente “discavam” pro computador pra se conectar, mais ou menos como se fazia com modems discados.

Na época já existia cabos coaxiais, que é parecido com da sua TV a cabo ou cabo de áudio, aquele mais grosso, que tem um canal físico no meio insulado por uma camada que é uma blindagem. A camada do meio transporta o sinal e é envolto por outro canal físico que é criado pelo plástico. O canal de fora é o ground, ou terra. São bons cabos mas caros.

A alternativa surge com o que chamamos de twisted pair ou par trançado, que contém literalmente um par de fios de cobre, normalmente com cores diferentes, trançados um no outro. Lembram das aulas de física elétrica no colegial? Se você tem um cabo por onde passa uma corrente, o que acontece? Ele gera um campo eletromagnético. Se fez cursinho até deve lembrar do truque do dedão, onde colocamos o dedão na direção da corrente e os outros dedos representam o campo eletromagnético.

O problema de cabos não trançados é que quando eles são expostos a um campo magnético, formam um loop e indução de voltagem. Os circuitos no final do cabo ficam mais suscetíveis a barulho induzido se não estiverem trançados. Um circuito é formado por dois cabinhos, daqueles coloridos, com voltagens opostas. Se um fio carrega voltagem positiva, a outra é igual mas negativa. A voltagem das duas é a mesma mas com polaridades opostas. Sem entrar em detalhes, ao ter dois cabos passando a mesma amplitude e frequencia mas de polaridades opostas trançados entre si, isso cancela a interferência eletromagnética, garantindo uma taxa de sinal melhor e menos barulho.

Agora começa a parte importante. Você pode carregar múltiplos canais num mesmo meio físico, como os fios de cobre. Isso se chama multiplexing e é um tópico beeeem complicado. Na prática pense em várias conversas de voz que podem ser combinadas num único sinal, esse é o processo de multiplexing ou mux e tem vários jeitos de fazer isso. Lembrem voz, música é tudo onda, frequências e amplitudes que são transmitidos como sinais elétricos.

Mux pode ser feito com divisão de espaço ou de frequência ou de tempo ou polarização e por aí vai. O importante é saber que é possível combinar múltiplos canas num único sinal e transferir tudo junto num mesmo meio físico, no caso os cabos. E do outro lado, na central, é possível fazer demultiplexing ou demux e separar os canais. É assim que rede telefônica funciona e esse processo não é novo, foi inventado no fim do século 19.

Quando falamos do termo bandwidth ou banda, estamos falando do máximo teórico de faixas de frequência que o meio físico permite passar. Isso determina quantos canais podem passar pelo mesmo cabo. Muito abaixo ou muito acima da frequência que o meio aguenta e o sinal é degradado. Daí você cai em coisas como cálculo de capacidade de canal de Shannon-Hartley. Claude Shannon, que todo mundo de ciências da computação, conhece como o pai da Teoria da Informação, que justamente criou a matemática pra calcular esse tipo de coisa.

Enfim, tem muita matemática e física envolvida em telecomunicações e eu só passei muito rápido por cima, mas eu queria chegar no ponto do telefone de copinho de novo. Com tudo isso, no final o que temos é um modelo mais sofisticado pro mesmo conceito de telefone de copinho. Onde uma vez estabelecido uma sessão entre dois participantes, você trava o canal de comunicação de ponta a ponta só pra vocês. Por isso o modelo de negócio era tarifar por minuto onde esse canal ficava preso. Isso é comutação de circuito.

Agora, ondas são super versáteis. Não é só conversa de voz ou música. Podemos converter dados binários em ondas. E de novo, é um tanto de física e matemática, mas falando de forma super simplificada, podemos usar a amplitude pra representar quando é bit 1 ou bit 0 e a frequência pra determinar quantos bits podem trafegar por segundo. O processo de transformar bits digitais em ondas é o que se chama de modulação, e o processo inverso pra recuperar esses bits é a demodulação e por isso os equipamentos que fazem isso são chamados de “modem”.

Com os primeiros modems comerciais, a gente conectava a linha telefônica de casa num modem e discava pra um provedor. No provedor ele ia ter dezenas de linhas telefônicas com modems também. Quando discava pra lá um modem atendia e travava tanto minha linha telefônica quanto a do provedor, fechando o circuito.

Imagina como isso era caro. Antes da privatização das telecomunicações, ter uma linha telefônica era caríssimo, se bobear mais caro que um carro, era literalmente um investimento. Acho que foi logo depois que privatizaram e linhas telefônicas começaram a ficar acessíveis que possibilitou ter provedores com dezenas ou centenas de linhas pra atender as pessoas, mas mesmo assim, se quisesse ter 100 pessoas simultaneamente conectadas precisava ter 100 linhas, era bem difícil de escalar e era super comum ligar pro provedor e dar ocupado.

Sem contar que era inconveniente pras pessoas. Toda vez que discava e conectava a linha ficava ocupada, então não dava pra receber chamadas nem ligar pra ninguém. Um dos motivos de porque a gente só entrava na internet de noite e de madrugada. Fora que tinha aquele esquema acho que era da noite de sábado e domingo só cobrava um pulso então não saia tão caro. Pois é, era difícil isso de acessar a internet nos anos 90. Você tinha que se planejar. Mas felizmente a tecnologia avançou rápido.

Uma característica da voz falada humana é que a gente não usa todas as frequências que um cabo de telefone suporta. A gente pensa em cabos e fala em bits por segundo. Mas simplificando, lembra que bits são modulados em ondas por um modem. O cabo na verdade tem uma capacidade de frequências e por isso falamos em cabos digamos de 1.5 megahertz e male male arredondamos pra 1.5 megabits. A conversão não é direta assim, mas pra hoje pensa que é relacionado. Enfim, digamos que o cabo telefônico tenha uma banda de 1.5 megahertz. A voz humana não precisa de uma faixa muito maior que de 0 até 4 kilohertz, então poderíamos reservar só essa faixa pra voz e vai sobrar muitos outros canais até 1.5 megahertz.

Significa que quando travamos o circuito pra uma ligação, estamos desperdiçando toda essa banda numa conversa. Daí nasce a era dos modems ADSL como da Speedy que funcionava na mesma rede telefônica e permitia deixar o canal de voz livre pra ligações e conectar na internet com o mesmo cabo. No antigo sistema CAP, de 0 até 4 kilohertz era reservado pro canal de voz, daí de 25 a 160 kilohertz era o canal de upstream, pra upload de dados. O canal downstream pra download começava em 240 kilohertz e ia até a banda máxima do cabo que podia ser 1.5 kilohertz. Tem um espaço vazio de frequências entre cada canal pra diminuir interferência.

O sistema CAP mudou rápido pra DMT que é discrete multitone e em resumo ela divide as frequências em vários pequenos canais de 4 kilohertz, um total de 247 canais separados. Lembra quando falei que antes um provedor precisava ter uma linha telefônica pra atender cada um usuário? Pensa agora uma única linha podendo atender um máximo de 247 canais na mesma linha. Se um canal estivesse com muito ruído, o switch mudava pra outro canal. Não quero entrar em detalhes nisso porque eu nunca trabalhei numa telecom nessa área então vai ter muito detalhe que não vou saber. Mas imagina que isso evoluiu pro modem da TV a cabo ou da fibra ótica da Vivo que eu uso.

Mais importante é que mudamos do conceito de circuit switching pra packet switching. Agora vocês precisam entender pelo menos o conceito de frames e protocolos. O jeito antigo é o que podemos chamar de ponto a ponto, inclusive o protocolo de provedor discado era usando um protocolo chamado PPP que é Point to Point Protocol, tinha um outro mais antigo chamado SLIP. Quem usou internet no começo dos anos 90 vai lembrar disso.

O modem faz o handshake, aquele barulhinho nostálgico que povo da minha idade conhece, o aperto de mão com o outro modem do outro lado e eles abrem uma conexão stateful, uma sessão exclusiva fechada. A partir daí está aberto um stream de dados, que pode ser half duplex ou full duplex. Uma via de mão única ou uma via com duas faixas, uma pra download e outra pra upload.

Uma vez aberto um stream, se está fazendo download, inicia o recebimento e espera até acabar tudo e não faz mais nada enquanto isso. Se está enviando, começa a enviar, e espera até acabar. Que nem numa chamada de voz se não tem tráfego nenhum, mesmo assim a sessão fica aberta e sendo desperdiçada até um dos lados desligar. Mas isso é um desperdício. Em vez disso podemos pegar qualquer informação, seja um email, seja um arquivo, seja um comando ou o que for e fracionar essa informação em blocos de tamanhos fixo. Lembra o linguição de bits que eu expliquei em outros episódios, e lembra o conceito de que a menor unidade na partição do seu HD não são arquivos e sim blocos? É parecido.

Muita gente que só usou interface gráfica em sistema operacional tem a noção que a menor unidade é sempre um arquivo. E que uma partição é basicamente como o “C:” que você vê no Explorer. Por isso fiz uma playlist inteira pra explicar sobre armazenamento e como dados são realmente organizados num disco. Todo HD ou pendrive é o que chamamos de dispositivos de bloco. E em telecomunicações é parecido, mas a menor unidade chamamos de pacote ou datagram. E datagram pra não esquecer é só pensar que no mundo analógico temos telegrams ou telegramas. Datagram é o telegrama de sinais digitais.

Se tava achando complicado, a partir daqui que realmente vai complicar. Então antes de continuar eu realmente preciso que vocês tenham na cabeça essa idéia de fragmentar informação em pacotes. Pensa assim. Todo dado, seja um arquivo ou um email, é um linguição de bits. Expliquei bastante sobre isso no episódio sobre a diferença de arquivo texto e binário. Se temos aquele arquivo mp3 de 10 megabytes, são 80 megabits ou mais ou menos 80 milhões de zeros de uns um atrás do outro que formam o conteúdo desse arquivo.

Na mesma analogia do telefone de copinho, se formos transferir esse arquivo tudo de uma só vez, os dois lados precisam esperar essa operação acabar pra conseguir enviar ou receber outros arquivos. E no modelo de circuito fechado, se vocês ficarem conectados o dia todo, mesmo se não estiver passando nenhum dado, a conexão vai ser desperdiçada. Por isso os sistemas de telecomunicação mudaram do modelo de circuit switch pra packet switch e de sessões stateful pra stateless. É isso que permite a escalabilidade que temos agora. Estou resumindo de forma bem grosseira, mas vamos entender o que muda.

A partir de agora cada canal não fica mais travado entre dois pontos. Está todo mundo conectado sem travar uma sessão, por isso chamamos de stateless, sem estado. Agora eu quero fazer download daquele mp3, eu mando o comando pra algum servidor na outra ponta e ele vai começar a me mandar esse arquivo. Só que não vai mandar tudo de uma só vez. Em vez disso ele vai quebrar esse arquivo em pacotes. Digamos, pedaços de tamanho fixo de 1500 bytes. Isso vai dar um total de mais ou menos 7 mil pedaços. Mas não é só isso.

Imagine um sistema de correios ou DHL e esses pedaços precisam ser entregues. Como faz? Você coloca cada pedaço de informação numa caixa e preenche os dados do destinatário. No caso da internet vamos dizer que é o endereço de IP da pessoa que pediu. Além disso o servidor coloca outros metadados no pacote, como o número do pedaço, porque quando eu for recebendo, vou precisar remontar o arquivo pedaço a pedaço mas precisa ser na ordem certa, senão o arquivo seria corrompido.

Agora o servidor começa a enviar esses pacotes, um a um. Toda vez que eu receber, eu devolvo uma resposta, um acknowledgement ou ACK, dizendo “beleza, manda o próximo”. Se durante a transmissão teve alguma interferência no cabo ou algo assim, e o pacote for danificado, quando eu recebo consigo checar. Existe toda uma forma de reconhecimento de erros que vou explicar no próximo episódio, só assuma que eu sei como reconhecer se o pacote veio amassado e aí eu jogo fora e respondo “não veio direito, pode mandar outro”, esse é o NAK, o oposto de ACK, daí o servidor repete o mesmo pacote e envia, e vai fazendo isso pacote a pacote.

Agora digamos que um segundo usuário aqui em casa na mesma rede resolva assistir episódio novo de série na Disney+. Se fosse que nem antigamente, não ia conseguir, ia precisar esperar eu terminar meu download. Mas o lance é que no intervalo entre um pacote e outro do meu mp3, ela pode mandar outros pacotes pra outros lugares no mesmo canal. O grande lance é que um cabo de comunicação era uma rodovia de várias faixas, ou canais como a gente chama, que só transitava um carro de cada vez. Quando fechava o circuito eu tava fechando e monopolizando essa rodovia inteira só pra mim. Mas agora a rodovia fica aberta e a gente vai usando as faixas que estão livres pra transitar mais carros.

De novo, é uma explicação grosseira, mas o conceito é que em vez de monopolizar um circuito, agora a gente compartilha, fragmentando a carga em vários pedaços. Daí mesmo que todas as faixas estejam ocupadas, na mesma faixa pode ir vários pedaços de vários arquivos. Como pacotes sendo enviados pelo Mercado Livre, cada pacote com seu endereço e destinatário pra não misturar e cada um recebendo seu pacote no final direitinho. É como se eu quisesse comprar um PC na Amazon. Eu compro cada componente separado. Eles são entregues fora de ordem, mas com o manual correto, eu consigo remontar o PC direitinho no final. E cada pacote veio de um lugar diferente por rotas diferentes até. A internet funciona mais ou menos assim.

Mas eu estou me adiantando. Até aqui eu quis descrever em linhas gerais pra que serve esse cabo de fibra ótica ou o cabo de TV a cabo que chega até meu modem e porque é possível ter várias pessoas no meu prédio usando o mesmo cabo, em diferentes canais. Esse é o papel do modem, modular e demodular o sinal digital em sinal elétrico, e trafegar em canais de frequência por cabos de cobre ou fibra até o switch de alguma central, no caso do provedor, e de lá ir pra internet. Agora que começa a parte interessante.

Por acaso, esse modem da Vivo, assim como modems de outros provedores como a Claro, tem múltiplas funções. É ao mesmo tempo um modem, mas acumula funções de um roteador e ponto de acesso Wifi. E eles costumam ser ruins em todos eles. Pra poucos dispositivos e pouco uso, realmente não faz nenhuma diferença usar. Mas no meu caso eu prefiro desligar essas funções e conectar num roteador separado, no caso esse meu TP-Link aqui do lado.

Mas acho que por hoje já é suficiente e vou pausar a história por aqui. No próximo episódio quero resumir pra que serve um roteador e como ele distribui a conexão pro meu PC, TV, e tudo mais. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais.

DESCRIÇÃO

É dia de falar tudo que você sempre quis saber sobre todas as sopas de letrinhas do mundo de dispositivos de armazenamento, desde MBR, GPT, EFI/UEFI, RAID, DAS, NAS, SAN, SSD, NVME, USB, Thunderbolt e muito mais!

Conteúdo

• 00:00 - Intro
• 01:01 - Master Boot Record
• 03:32 - GPT
• 06:39 - EFI/UEFI
• 09:27 - processo de boot
• 10:41 - Secure Boot
• 13:40 - HDs como Livros
• 16:02 - Partições e Volumes
• 17:08 - RAID 0
• 17:51 - RAID 1
• 19:03 - RAID 1+0
• 19:43 - RAID 5
• 19:59 - DAS
• 20:42 - Entendendo SSD
• 21:57 - Protocolos USB
• 22:53 - NVME
• 23:50 - Conectores USB
• 24:50 - Thunderbolt
• 25:17 - HDMI
• 26:22 - Tipos de SSD
• 28:43 - Cabos Ethernet
• 30:31 - NAS
• 31:59 - Video ocupa MUITO espaço
• 34:30 - SAN e Cloud
• 36:20 - Character vs Block Device e BSD
• 39:33 - Conclusão

SCRIPT

Olá pessoal, Fabio Akita

No episódio anterior eu contei um pouco sobre meus servidores de arquivos, o Drobo e o Synology, algumas noções sobre RAID, e desci um pouco no detalhe sobre fdisk, sistema de coordenadas CHS e LBA. Hoje vou continuar essa saga falando sobre boot. Como um computador entende seus HDs.

No episódio anterior eu parei a instalação daquele RedHat de 1997 explicando sobre cilindros e como do sistema de coordenadas de cilindro-cabeça-setor chegamos no LBA que é um endereçamento linear. Acho que o mais importante era entender que num HD ou pendrive ou qualquer dispositivo de armazenamento a gente não lê e escreve dados bit a bit ou byte a byte e sim em blocos, no caso em setores, que normalmente são blocos de 512 bytes. Mas beleza, particionamos o HD com fdisk e agora, como o computador boota minha máquina?

(…)

No nível do sistema operacional você ainda tem as opções de escolha de como particionar o disco. Falando rapidamente, antigamente e até em algumas máquinas não atualizadas de hoje, o sistema mais usado era MBR ou Master Boot Record. É um setor especial no primeiro cilindro reservado como setor de boot. Os primeiros 512 bytes.

Quando o computador boota, precisa iniciar algum programa, uma primeira instrução. Essa vai ser a BIOS, um firmware que hoje é atualizável. É um chip persistente que independe do seu sistema operacional. A BIOS vai detectar o hardware, configurar sua máquina e deixar disponível pra uso. No final desse programa vai ter uma instrução de JUMP pra um endereço fixo no primeiro HD que ele encontrar. No caso o endereço com segmento 0000 e offset 7C00.

Parêntese, se você assistiu o episódio da CPU montada em protoboard do Ben Eater que expliquei no Guia Mais hardware de Introdução à computação e um dos mais recentes que foi explicando sobre os 640 kilobytes de RAM, você entendeu 100% do que acabei de falar. Instrucões, jump, segmentos. Se não entendeu, recomendo assistir esses episódios depois.

Depois ele vai checar o cabeçalho da estrutura até achar 55 AA. Essa sequência identifica um MBR. Daí vai encontrar uma estrutura, literalmente como uma struct de structs de C. A estrutura do MBR permite registrar até no máximo 4 partições.

Era o que cabia no espaço que foi definido e pra época provavelmente acharam que era suficiente. E as configurações nessa struct tem tamanho fixo. Por isso que não dá pra plugar qualquer HD moderno num computador antigo e por isso que no fdisk antigo você vê que ele só deixa cadastrar 4 partições.

O máximo que dá pra ter é 2 elevado a 32 vezes o tamanho padrão do setor que são quinhentos e doze bytes. Isso dá 2 terabytes. Então máquinas antigas com MBR não conseguem ter partições maiores.

Ah sim, falei 2 elevado a 32. Lembram do tal LBA que falei no episódio anterior? É uma lista de 32-bits. Então só vai ter endereços pra 2 elevado a 32 setores. A distinção aqui é importante. Em outros episódios eu falava de listas ou arrays onde cada endereço apontava pra um byte.

Mas a gente pode apontar qualquer coisa e um LBA é uma lista onde cada elemento aponta pra um setor. E cada setor tem X bytes. Quanto maior o setor maior a partição que daria pra usar. Acho que MBR não suportava setores de 4 kilobytes por exemplo. Então o máximo vai ser esse mesmo.

Tem jeito de gambiarrar isso um pouco com partições extendidas. Mas é gambiarra, nem vou explicar, mesmo porque hoje em dia ninguém mais usa MBR em computadores e laptops, o normal é usar GPT ou GUID Partition Table que, como o nome diz, vai usar GUIDs pra identificar as partições.

Se ficou confuso, no MBR você identificava as partições com 4 números, de 1 a 4. Mas no GPT você vai identificar a partição com um numerozão de 128-bits. Não só partição, mas tipo de partição também. Se você assistiu meu episódio sobre criptografia, eu explico GUIDs lá. Mas em resumo, quando a gente quer dar um número que tem alta probabilidade de ser único, usamos ou UUID ou GUID, no caso GUID é a versão da Microsoft do conceito de Universally Unique Identifier, GUID é Globally Unique Identifier. Quase mesma coisa.

Usar números inteiros sequenciais pequenos é garantido que alguém já vai estar usando. É que nem quando você tenta cadastrar seu apelido numa plataforma qualquer. Certeza que já tem um joão cadastrado e você é obrigado a cadastrar tipo um joão99123 e até isso já deve existir. Por isso muitas plataformas pegam seu apelido e concatenam um número aleatório no final, como o Discord.

Não usar números sequenciais é uma boa prática e outro dia eu falo sobre isso em particular, mas o ponto é que suas partições são identificadas com um GUID. O GUID é um número binário de 128-bits. E ele é representado em 5 blocos legíveis em hexadecimal. Por convenção a gente separa esses blocos com hífen pra ficar mais fácil se precisar digitar manualmente.

Vamos recapitular porque foi muita letrinha de uma vez só. Toda a explicação sobre cilindros e cabeças foi só pra relembrar como era antigamente, mas hoje é LBA, uma lista linear de endereços de 32-bits em máquinas antigas com MBR e 64-bits em máquinas modernas com GPT. Elas representam o mapeamento de setores no seu HD. Com 32-bits e setores de 512 bytes daria pra no máximo endereçar 2 terabytes de HD. Mas com 64-bits a gente tem capacidade pra ir até um HD de vários Zetabytes. Um zetabyte é tão grande que se você pegar todo o conteúdo da Internet, não ia chegar perto disso.

A gente quer conseguir endereçar tamanhos absurdos porque mesmo não tendo um único HD de mais do que terabytes, você sabe que existem recursos como stripe ou RAID-0. Nada impede alguém de tentar ir ligando vários HDs gigantes num único volume.

No fim da vida de MBR a gente tava limitado no tamanho do HD porque não tinha endereços suficientes, mesmo problema dos 640 kilobytes de RAM, mas depois que migramos pra LBA e GPT agora temos endereços sobrando e quantidade de partições sobrando.

MBR ou GPT são estruturas de dados, como structs de C, que tem campos de tamanho fixo pra armazenar a configuração do seu HD e das partições. O HD é dividido em partições e as partições são divididas em setores. Daí os primeiros setores do primeiro cilindro são ocupados com essas estruturas. Na verdade você começa a partição propriamente dita mais pra frente na lista LBA. Mas é tudo o mesmo linguição de bytes no HD, é tudo uma questão de quantos setores você quer perder pra guardar esses metadados.

No caso de GPT, ele precisa de uma partição ESP que é EFI system partition. Aí fodeu, que GPT existe mais uma sigla junto que é EFI e UEFI. Em resumo é o seguinte, o esquema BIOS e MBR ficou velho muito rápido na virada do século daí surgiu Extensible Firmware Interface ou EFI da Intel que define uma nova interface pro sistema operacional conseguir falar com o firmware.

Mas em 2005 o EFI foi atualizado pra virar UEFI. No mundo open source, quando você boota um virt-manager da vida, pra rodar uma máquina virtual vai ver que o logo que aparece é da TianoCore que desenvolve uma implementação de UEFI aberta chamada EDK2. Se você é das antigas, o que a gente chama de firmware hoje é o que antigamente era mais conhecido como BIOS. Na prática é o primeiro código que qualquer computador executa.

No caso de HD, o primeiro setor é o boot sector ocupado pela estrutura MBR. E continua sendo assim por motivos de compatibilidade. Vai ter a estrutura de dados antiga, mas se você tentar rodar ferramentas velhas tipo o fdisk de 1997, ele ainda vai encontrar o MBR lá, mas as partições de verdade não estão mais lá, vão estar em setores mais pra frente. Acho que são uns 32 setores pelo menos, com 512 bytes cada, significa que os primeiros 16 megabytes do seu HD você já não tem, porque é lá que ficam as informações pro resto.

A idéia do GPT é facilitar fabricantes e desenvolvedores de extender os metadados. Digamos que o Windows precisasse identificar uma partição como sendo de Windows, que número ele usa? Se escolher 1, e se agora a Apple também quiser usar 1 pro tipo dele? Daí que usar GUID é mais prático. Eles podem escolher um GUID qualquer e a chance de alguém já ter escolhido o mesmo é muito baixa. Em qualquer documentação sobre GPT você vai achar tabelas como essa que listam os GUIDs pra tipos de partição por exemplo.

E em sistemas UEFI tem essa partição especial pequena que se chama EFI system partition ou ESP. Se você é de linux já deve ter visto um /boot fora da sua partição principal. Pra ser universal ela costuma ser formatada em FAT, normalmente VFAT ou FAT32. E quando o UEFI termina de bootar, ela aponta pra essa partição e carrega o que tiver lá, que no caso do Linux é onde vai ter o bootloader e a kernel mais drivers.

No caso de Mac ele força que essa partição seja em HFS+ que é o filesystem antigo deles, e no caso do Windows em vez de ser /boot costuma ser /EFI/Microsoft/Boot, mas é a mesma coisa. Essa partição especial costuma ficar escondida, mas sabendo que ela existe você pode montar ela num diretório usando comandos como mount. Inclusive num Linux, quando você baixa e instala uma kernel mais nova, ao rodar comandos como update-grub da vida, ele vai atualizar a imagem vmlinuz que contém a kernel e drivers, nessa partição.

Quando a UEFI termina o que tinha pra fazer, no final do procedimento de POST que é sigla pra Power-on self-test, daí vai lá nos primeiros setores do primeiro disco e acha a tabela de partições. E dentro procura se tem uma partição com um tipo especial de GUID que começa com C12A e termina em C93B. Em todo computador com sistema operacional instalado vai ter ela, que é o ESP ou partição de boot.

Encontrado essa partição então consegue montar e ler os arquivos dentro. Se você tiver mais de um sistema operacional na mesma máquina, vai ter mais de uma configuração de bootloaders ali. Encontrado o bootloader, também acha a imagem do sistema operacional. No caso do Linux acho que cria uma ramdisk ou initial ramdisk, onde vai carregar um filesystem mínimo e continuar o processo de boot.

É o mínimo do mínimo que precisa carregar pra continuar lendo as outras partições que estão na tabela e montar com os filesystems adequados, como ext4 no caso de Linux ou NTFS no caso de Windows. Agora ele consegue abrir a partição principal, montar a raíz e ler as configurações num diretório como /etc ou o Registry no caso do Windows e segue subindo serviços, daemons, e tudo mais pra completar o boot do sistema até chegar na tela de login.

Aliás, se você tá prestando atenção deveria estar se perguntando, mas se no processo de boot ele vai pegar seja lá que bootloader e seja lá que imagem estiver nessa partição aberta de FAT, não é perigoso? Alguém malicioso ou algum virus não poderia modificar essa imagem e fazer ele carregar alguma coisa ruim?

Este não é um episódio sobre segurança então detalhes ficam pra outro dia. Mas sim, isso inclusive acontece de verdade e quando um virus ou programa carrega antes da sua kernel, ela consegue se injetar e ter privilégios de kernel. É isso que faz um rootkit. Se conseguir se injetar na kernel antes do boot, seu sistema operacional não vai conseguir detectar e ele teria a capacidade de enganar os antivirus que carregam depois, ou até comprometer os executáveis dos antivirus. Quando um programa malicioso se carrega no espaço privilegiado da kernel, ele tem acesso a basicamente tudo, é game over.

Na prática você precisou ser bem imprudente com o que instala na própria máquina. Nesse caso, rootkit ou não você tá inseguro de qualquer jeito já. Ou, você já deixa sua máquina desprotegida, qualquer um pode usar, e aí também é inseguro. Se alguém tem acesso a sua partição de boot, sua máquina tá escancarada por definição. Se você faz trabalho importante não deveria deixar aberto.

Tem gente que não sabe disso, mas conexão Thunderbolt e USB tem defeitos e bugs, e um pendrive preparado com software malicioso, só de plugar na sua máquina vai conseguir injetar malwares ou no mínimo causar um monte de problemas. Por isso em corporações tem até políticas pra proibir espetar um pendrive no notebook. Além disso UEFIs mais novas tem uma coisa chamada Secure Boot.

Resumindo, na instalação do sistema operacional, ela permite registrar um certificado digital numa área segura e assinar os binários que precisam carregar no boot como kernel e drivers. Daí em todo boot a UEFI vai checar se o binário foi modificado ou não. Se algum rootkit da vida ou alguém manualmente tentou trocar os binários então a checagem da UEFI vai falhar e ele não vai deixar bootar. Procure saber sobre isso.

Aliás, se você é gamer de jogos da Riot por exemplo, já teve que desligar o Secure Boot da sua máquina porque o sistema de anti-cheats ou anti-trapaça deles funciona como um rootkit, um driver que carrega junto com a kernel, alterando seu boot justamente pra você não ser capaz de desligar o anti-trapaça. E não é só a Riot que faz isso. Foi uma controvérsia boa porque desligar o secure boot é desligar segurança da sua máquina e isso é super intrusivo. Não sei se ainda funciona assim, mas isso é bem tosco, pra dizer o mínimo.

Parece complicado, mas ainda estamos só começando. Durante a primeira década dos anos 2000 a gente tava em transição da arquitetura de 32-bits pra 64-bits, e ao mesmo tempo fazendo a transição da BIOS com MBR antigo pra GPT e EFI e depois UEFI. Foi uma bela de uma zona pelo que me lembro, mas hoje em dia tá mais normalizado e estável. Depois de ter passado todas essas transições, eu diria que a era de 64-bits finalmente parece bem mais com o conceito de “plug and play” que vinham prometendo pra gente desde os anos 90.

Voltando pro HD, deixa eu tentar ilustrar o conceito. Os primeiros setores dessa fita é como se fossem o índice de um livro, dizendo de qual página até qual página fica cada capítulo, que seria a partição. Faz de conta que meu livro tem um índice que diz que da página 1 até a página 50 é o primeiro capítulo e da página 51 até a página 100 é o segundo capítulo.

Pra apagar o segundo capítulo, basta apagar do índice que esse capítulo existe. As páginas em si continuam no livro, mas ela só não é mais identificada. Eu não sei se da página 51 até o fim é uma partição só, ou se antes tinha dois capítulos de 25 páginas cada por exemplo. Mas o que tinha escrito nas páginas continua lá. Quando a gente apaga alguma coisa, não é que o HD foi nessas páginas e apagou tudo que tava escrito. Ela só tirou do índice.

Por isso que é possível reparticionar um disco sem perder dados. Voltando no exemplo dos dois capítulos, digamos que eu quero aumentar a segunda partição. Pra isso eu poderia ir no índice e escrever que o primeiro capítulo é só da página 1 até a 25 e da 26 até o 100 é o novo segundo capítulo.

Se as páginas estavam todas em branco, não vai fazer nenhuma diferença. Mas e se já tinha coisa do primeiro capítulo escrito lá pela página 40? A diferença de HD pra livros é que a gente não vai escrevendo necessariamente em ordem sequencial, tipo preenche toda a página 1, depois vai pra página 2 e assim por diante. A gente cria arquivos, apaga arquivos, atualiza, então vai ficando fragmentado. Pode ter metade da página 1 usada, página 2 em branco, página 3 cheia e assim vai. Portanto toda página, em média, vai ter espaço sobrando se o HD não estiver totalmente cheio.

Então eu vejo o que tem na página 26 até a 50 e se o que tem escrito lá couber nas páginas anteriores, posso copiar tudo pra lá e agora sim, reescrever o índice pro capítulo 1 ser da página 1 até a 25 e o capítulo 2 ser da página 26 até a 100. E é assim que se redimensiona partições. Só não vai dar pra reparticionar se o primeiro capítulo já tava quase cheio, daí não tem como.

No MBR antigo, nosso livro só podia ter até 2 terabytes, e só podia ter 4 capítulos ou partições. Com GPT, agora podemos ter milhares de partições e cada uma com praticamente quanto espaço a gente quiser, porque o hardware ainda não chegou nos limites estabelecidos no GPT. Lembra? zetabytes. Agora, o sistema operacional, sabendo onde começa e onde termina cada partição, quantos setores tem, toma conta e se encarrega de formatar a partição.

Vou falar de filesystems no próximo episódio. Mas a história de partições não acaba aqui. Se você presta atenção a nomenclaturas já deve ter visto a palavra “partição” mas também a palavra “volume”. Como a gente já viu, uma partição é uma divisão lógica de um HD ou qualquer outro dispositivo de armazenamento, como um pen drive. Um pen drive também pode ter mais de uma partição.

Já um volume é uma abstração do sistema operacional. No caso mais comum a gente pode ter uma partição de boot EFI, uma partição principal do sistema operacional e todos os seus programas e dados, e talvez uma terceira partição pra swap no caso de um Linux. Aliás, essa terceira partição hoje em dia é opcional porque é mais comum um swap ser só um arquivão na partição principal mesmo.

Então a gente tá acostumado a ter só uma partição que por sua vez é um único volume. Num Windows cada volume costuma ser uma letra, tipo C:, D:, e assim por diante. Quando você espeta um pen drive no seu computador, vai aparecer um novo volume montado como um E:. No caso do Linux volumes são montados como diretórios e podem aparecer como em /run/media/pendrive por exemplo.

Mas lembrem-se do caso que eu expliquei lá no começo do video, sobre RAID, e o caso mais simples como o RAID-0 que é stripe. Você instala dois HDs de 1 terabyte no seu computador. No caso normal, vai formatar um como volume C: e o outro como volume D:. Mas digamos que você não queira um segundo volume e na verdade quer que os dois HDs sejam combinados. Dá pra fazer isso, você cria um volume lógico que é a combinação dos dois HDs.

Pro Windows, mais espeficificamente pro sistema de arquivos NTFS, vai ser um único volume de 2 terabytes. O volume é uma forma de organizar partições no mesmo HD ou até em HDs diferentes como um único armazém de dados. Lógico, você já entendeu que nunca deve fazer isso porque se der pau num dos HDs você perde o volume inteiro.

O segundo jeito que eu ainda não falei é RAID-1, que é como alguns sistemas caseiros de backup com 2 HDs podem vir configurados. Mesmo exemplo, imagina os dois HDs de 1 tera cada. Podemos configurar um pra ser backup quente do outro. Ambos ficam ativos mas pra você só aparece um volume C: de 1 terabyte.

Por baixo seja um hardware de RAID na sua placa mãe ou um módulo de software RAID que seu sistema operacional carrega no boot vai identificar os dois HDs mas organizar como um único volume. Diferente do RAID-0 que você ia enxergar como um único volume com a soma do espaço dos dois HDs, no RAID-1 você enxerga só como se um dos HDs estivesse ligado e o outro não. Metade do espaço total.

Parece desperdício, mas essa é a redundância mais simples. Toda vez que você escreve um arquivo, por baixo vai escrever igual nos dois. Um vai ser uma cópia exata do outro e por isso RAID-1 é chamado de mirroring, ou espelhamento. Digamos que daqui alguns meses um dos HDs resolve dar pau. O sistema de RAID vai identificar o problema e você não vai perder nada porque o outro HD ainda tá intacto e com 100% dos seus dados. Basta trocar o HD defeituoso e o sistema de RAID vai reconstruir esse novo HD fazendo uma cópia do outro.

A gente pode combinar o espelhamento do RAID 1 com o stripping do RAID 0. Se eu tiver agora quatro HDs de 1 tera cada, ou seja, total de 4 tera, eu posso organizar como dois conjuntos de stripe: dois HDs de 1 tera viram um volume de 2 teras. E agora eu pego esses dois volumes maiores e mando um espelhar no outro. Eu continuo perdendo metade do espaço pra backup, mas também tenho a vantagem de mais performance de ter HDs em stripe. É tipo juntar o melhor dos dois esquemas: redundância e performance.

Você vai ver esse arranjo sendo chamado de RAID 10, mas não é número 10 e sim 1 mais 0 porque é Raid 1 combinado com Raid 0. Em qualquer dos casos estou perdendo bastante espaço pra backup. E existe um jeito mais inteligente, e aí voltamos pro RAID-5 do meu Drobo e do Synology e da maioria dos bons servidores de armazenamento. Aliás, no mundo de storages ou armazenamento, existem 3 siglas que você precisa saber: DAS, NAS e SAN.

Direct Attached Storage é o mais simples. Um pendrive ou HD externo é um DAS, que é storage anexado direto no seu computador, seja via USB ou Thunderbolt hoje em dia. Aliás, USB é outro ninho de siglas que confundem. Fazendo uma pequena tangente, tudo que é USB antigo de uns 10 anos pra trás é USB 2.0 que tem velocidade máxima de uns 480 megabits por segundo ou 60 megabytes por segundo.

Quando você só tem HDs mecânicos, um USB 2.0 tá mais que bom. Mas desde 2008 existe USB 3.0 que opera na faixa de 400 megaBytes por segundo, bem mais que o melhor HD mecânico. E isso é necessário porque nesse ponto a gente já tava começando a adotar mais SSDs.

Acho que todo mundo pelo menos tem idéia do que é um Solid State Drive. SSD é uma placa com chips de NAND Flash. Modelos mais sofisticados tem chips de RAM também pra operar com cache e melhorar os piores casos. Como eles foram feitos pra conectar na interface Serial ATA ou SATA 3, que tem velocidade teórica máxima de 750 megabytes por segundo, não espere um SSD comum ser muito melhor que isso.

Na prática um bom SSD vai operar na faixa de 500 megabytes por segundo, que já é pelo menos 10 vezes melhor que a velocidade média de um HD mecânico. Se for lidar com milhares de arquivos pequenos então, o HD mecânico pode cair pra velocidades ridículas de 3 ou 2 megabytes por segundo. Num SSD o tempo de procura é muito mais rápido porque é que nem um chip de memória, não tem que lidar com um motor e ficar reposicionando cabeças em cima de discos.

Se a gente judiar do SSD a velocidade dele pode cair pela metade, mas mesmo assim ainda estamos falando da faixa de 200 megabytes por segundo. Notebooks não tão velhos já devem pelo menos ter um SSD numa caixinha de 2.5 polegadas igual um HD mecânico de notebook mais antigo. Tanto que é fácil trocar um pelo outro e você vai ganhar 10 vezes mais performance. Nenhum upgrade num notebook velho vale mais a pena do que colocar um SSD.

De qualquer forma, um USB 2.0 agora é porcaria, daí pulamos pra série 3. Toda vez que você vê um conector USB que é azul é porque é da série 3. E eu falo série porque desde 2008 ele virou 3.1 e 3.2. Na prática quando se fala USB 3, quer dizer pelo menos 3.2 Gen 1. E são quatro tipos, a Gen 1 que é de 5 gigabits por segundo, gen 2 é 10 gigabits, gen 1 x 2 é 10 gigabits, gen 2 x 2 é 20 gigabits. A nomenclatura de USB é uma droga assim mesmo.

5 gigabits que é o USB 3.2 gen 1, é 5 dividido por 8 que dá na faixa máxima de 600 megabytes por segundo. Que é próximo da velocidade máxima de um SSD SATA-3 de qualidade. E 20 gigabits do USB 3.2 gen 2 por 2 é 2.5 gigabytes por segundo. E pra que tudo isso? Porque o mundo de HDs não é só mecânico e SSD. Hoje em dia o melhor são os NVME.

NVME é Non-volatile Memory Express. Assim como SSDs eles continuam usando chips NAND flash, mas em vez de ser limitado pelo barramento SATA-3, o NVME usa lanes de PCI Express. Pensa assim, a série ATA e SATA de interfaces foi pensada pra HDs mecânicos. Então os SSDs mais comuns que usam SATA-3 tem uma série de obstáculos de tecnologia legada. PCI Express é o mesmo barramento onde você liga coisas como sua placa gráfica. Trocando SATA-3 por PCIe, a gente ganha menos overhead e menos obstáculos.

Se um bom HD mecânico faz na faixa de 50 megabytes por segundo, se um bom SSD SATA-3 faz na faixa de 500 a 600 megabytes por segundo. Um bom NVME que usa PCIe e se conecta em slots que chamamos de M.2, faz na faixa de 2 a 3 gigabytes por segundo que, por acaso, é a faixa de velocidade do USB 3.2 Gen 2 por 2 que eu falei antes.

O que todo mundo fica confuso é não saber que USB 3 é um protocolo e que tem várias gerações que variam bastante de velocidade. Aí tem a gente confunde o protocolo USB 3 com o conector USB Type C. Isso é outro problemão porque agora estamos falando de conector e cabos.

O conector mais comum sempre foi o USB type A que é aquele retângulo maior. Tem o Type-B que é menor e mais quadrado que liga em impressora e que existe pra você não inverter os lados do cabo. Cabo USB transmite energia só pra um lado. Normalmente do Type-A sai energia e no Type-B recebe. Se fosse tudo Type A você podia acabar invertendo o cabo e queimar alguma coisa.

Enfim, Type C é novo conector que saiu uns 3 ou 4 anos atrás pra justamente arrumar um pouco essa zona. Todo mundo só pensa que com o Type-C não tem jeito certo pra encaixar. Mas não só isso, você pode ter cabo com as duas pontas sendo Type-C, porque ele é multi-direcional pra energia e o protocolo vai garantir que você não vai queimar nada se inverter o cabo.

O cabo Type-C, junto com o protocolo 3.2 Gen 2 x 2 tem capacidade máxima de 20 Gigabits por segundo, que são os mais de 2 gigabytes por segundo de velocidade. Mas tem acima disso. Computadores Intel e Mac, ou seja, menos a AMD, tem Thunderbolt 3, com velocidade máxima de 40 gigabits por segundo ou 5 gigaBytes por segundo. E aí você pode pensar, mas ué, o NVME mais rápido é na faixa de 2 a 3 gigabytes, pra que precisa do dobro?

Porque Thunderbolt não é feito só pra dispositivos de armazenamento, mas pra tudo, incluindo monitores. Um cabo HDMI 2.0 que é o mais comum e que você deve ter na sua TV, sozinho, tem banda de 18 gigabits, perto do máximo de uma USB Type C. Você consegue transmitir no máximo 4K a 60 quadros por segundo.

Sem entrar muito no assunto de video, mas só pra complementar, pra jogar Playstation 5 ou Xbox Series X em 4K a 120 hertz em HDR, precisa de cabo HDMI 2.1 que tem banda de 48 gigabits por segundo. Então, num USB 3.2 Gen 2 x 2 não dá pra ligar mais de um monitor 4K e ainda ter boa velocidade pra copiar arquivos pra um SSD externo. Thunderbolt serve pra isso.

E isso porque estamos pra receber já já USB 4 e Thunderbolt 4. Só mencionei porque tanto USB 3.2 quanto Thunderbolt usam cabos com o mesmo conector Type-C. Por isso é uma zona. Quando a entrada Type-C suporta Thunderbolt, costuma ter um ícone de raio do lado. Mundo Mac tá mais acostumado com tudo Thunderbolt, no mundo PC a gente tá um pouco mais atrasado na adoção.

Voltando a falar de SSDs e NVMEs, laptops e placas mãe modernas já vem com pelo menos um slot M.2 que dá pra colocar um NVME. E se não tiver, no mínimo você deveria jogar fora o HD mecânico e colocar um SSD SATA-3. Qualquer coisa vai ser no mínimo 10 vezes melhor que um HD mecânico. No caso de NVME vai ser quase 100 vezes melhor.

Agora, SSDs e NVMEs não são todos iguais. NAND Flash tem em diversas variedades. Você tem chips que suportam 1 bit de dados que é single-level cell ou SLC. Você pode ter um chip que suporta 2 bits, que é multi-level cell ou MLC. Entendeu? O próximo tipo suporta 3 bits e se chama triple-level cell ou TLC e o último suporta 4 bits ou quad-level cell ou QLC. Então SLC, MLC, TLC e QLC. Quanto mais bits melhor? Na realidade não, o melhor é o single level cell, SLC.

Quanto mais bits você entuchar numa célula, menos espaço ocupa. Então tem drives com maior capacidade no mesmo espaço. Porém, quanto mais bits ele tem, mais lento ele fica e, pior, menos tempo ele dura. Chips NAND tem capacidade máxima de escrita. Todo SSD tem uma quantidade máxima de vezes que dá pra usar antes das células pifarem.

Chips SLC, de 1 bit por célula, vão durar na faixa de 50 a 100 mil ciclos de program e erase ou PE que é a unidade que se usa. Um chip QLC vai suportar 100 vezes menos, talvez uns 1000 ciclos de PE. Então, no mesmo preço, ou você escolhe um SSD de menor capacidade mas que vai durar muito tempo ou um de maior capacidade que vai durar menos tempo. Mais um trade-off.

Nenhum SSD vai durar pra sempre. Apesar de não ter peças móveis ele também deteriora com o uso. A vantagem é que não vai estragar antes do tempo porque você derrubou e estragou o motor ou riscou o disco. E justamente porque a gente sabe que tanto HDs, quanto SSDs ou NVMEs uma hora vão todos morrer, que você precisa de tempos em tempos garantir que tem backup.

A tangente toda começou porque eu comecei falando de DAS. Um HD externo mecânico ligado via USB 2 é um DAS porque tá anexado direto no seu PC. Se usar um SSD externo, provavelmente vai ser via USB 3. Se usar um NVME externo vai ter conexão Thunderbolt. E mesmo soluções de RAID com múltiplos drives também pode ser de SSDs, e se for você pode conectar via Thunderbolt também.

Mas não é sempre prático ter uma caixona grande com múltiplos drives na sua mesa. Às vezes você pode preferir colocar esse servidor em algum lugar mais escondido. Dentro do seu closet, no porão ou algo assim. E aí tem uma desvantagem de cabos como USB ou Thunderbolt. Eles não foram feitos pra serem longos assim.

Mas existem cabos que foram feitos pra ser bem longos, são cabos Ethernet de rede. E indo direto ao assunto, adivinhem, só porque um cabo é azul ou amarelo, e tem o mesmo conector RJ-45 de rede, não quer dizer que são iguais. Mesma coisa que eu falei dos diferentes tipos de USB 3.2. Cabos ethernet são divididos em categorias. Hoje não é episódio sobre redes, mas deixa eu só explicar os cabos.

Existem categorias como cat5E, cat6, cat6A, cat7, cat8. De cat5 a cat6 é velocidade máxima de 1000 megabits por segundo, que é uns 125 megabytes. Isso é o dobro de USB 2.0 mas é 5 vezes mais lento que USB 3.2 Gen 1.

Cat6A e Cat7 é categoria dos 10 gigabits por segundo. Agora igualamos com USB 3 Gen 1. Se o comprimento for menos de 50 metros, ainda pode subir pra 100 gigabits e aí já ficou melhor que Thunderbolt. Um cabo cat8 já entra em território de velocidade de fibra ótica. Além de velocidade varia a construção do cabo, resistência, blindagem. Acho que Cat 6 ou 7 são mais comuns, eu nunca vi um Cat8, vai ser mais em data center.

Quem lembra de física elétrica básica do colégio lembra que num fio que passa eletricidade gera um campo magnético ao seu redor, por todo o comprimento. Se colocar vários fios em paralelo um do lado do outro, eles vão dar interferência entre eles. Um cabo Ethernet é um conjunto de vários cabos mais finos dentro, organizados em twisted pair, ou par trançado. Se você já clipou um cabo de rede já deve ter visto isso.

Normalmente esses cabos conseguem atingir distâncias de até 100 metros e se precisar mais longo existem extensores pra isso. Mas o ponto é que você pode tranquilamente puxar cabos de dezenas de metro pela sua casa sem problemas. É o que eu faço: em vez de usar um DAS conectado direto no meu PC eu tenho um NAS, um network attached storage do lado do meu roteador e do meu PC sai um cabo ethernet cat7 que vai até o roteador.

Meu Synology DS420j é um NAS de entrada. Tá configurado com 4 HDs mecânicos de 4 terabytes cada, reservando uns 5 giga espalhado pelos drives. É uma porção de cada drive reservado pra redundância. Um NAS é só um nome mais bonitinho pra um PC pequeno com Linux. Ele tem uma CPU Celeron antiga, uns 1 giga de RAM e só.

Um NAS mais sofisticado vai ter um processador melhor, muito mais RAM e até opção de colocar um SSD, normalmente formato mSATA ou talvez até M.2. Você mesmo pode montar um NAS caseiro num PC velho que tiver sobrando com placa de rede ou até Wifi. Como a gente acaba usando HDs mecânicos, velocidade de Wifi acaba sendo suficiente.

Eu ainda não coloquei um NAS melhor porque não preciso editar arquivos grandes direto dele, só uso como backup mesmo. Mas existem casos que você precisa trabalhar direto do NAS. Exemplo disso são estúdios que editam videos profissionais. Aí você tem vários editores trabalhando de computadores bons mas todos precisam acessar os mesmos arquivos ou os arquivos são tão grandes que não é prático ter na máquina de cada um.

Se você não tem noção, video ocupa muito espaço. Mesmo na minha produção caseira, um video de 30 minutos em 4K ocupa nada menos que 3 gigabytes e meio. Um dos meus últimos videos longos, antes de editar, foram 4 arquivos que dá quase 2h de gravação e ocupa quase 40 gigabytes no total. Pra um video de YouTube! Tudo bem que é um video que editado deu uns 45 minutos, mas mesmo assim. 10 episódios nesse formato já seria quase meio terabyte. Menos de 20 videos e acabou um terabyte. Lembrem que meu canal já tem 100 videos.

Numa produção profissional bem mais cara, usando uma câmera RED Monstro, gravando no formato Redcode com compressão de 8 pra 1 e video de 8K custaria nada menos que 1 terabyte pra cada 30 minutos. Ouviram? Se eu tivesse gravado as mesmas duas horas que eu falei nesse formato ia me custar mais de 3 terabytes. Num único video! Imagina 100!

Ah, mas depois de editar o video final é só jogar fora os originais. Não, isso é pensamento de amador. A gente NUNCA joga fora originais de nada. Você nunca sabe quando precisa voltar nos originais pra re-editar, ajustar, talvez fazer um remaster amanhã. Profissionais guardam tudo em servidores.

Por isso você vai num canal como Linus Tech Tips e ele fala tanto em servidores de armazenamento como esse aqui dele montando 1 petabyte num servidor com 60 HDs, 256 Giga de RAM controlado por uma CPU AMD Epic Threadripper acho que de 24 cores. E eles tem mais de um desses servidores.

Nossos computadores domésticos e laptops costumam vir no máximo com um plug Ethernet de 1 gigabit, que é suficiente pra no máximo 128 megabytes por segundo de transferência. Pra navegar na Web e copiar arquivos pequenos pela rede tá mais que bom. Quase nenhum plano de Internet doméstico que você achar vai saturar isso, nem perto, especialmente se for uma porcaria como NET da vida. Meu NAS Synology e o Drobo não fazem muito mais que 25 megabytes por segundo. Mas pra conseguir editar video de 8K em tempo real, direto num drive montado na rede, precisa ser Ethernet 10 gigabit, pra ter velocidades de mais de 1 gigabyte por segundo.

Um servidor desses, aliás, provavelmente vai ter múltiplas saídas de ethernet 10 gigabit pra conseguir lidar com múltiplos computadores editando video ao mesmo tempo. Aí a brincadeira começa a fica interessante. Recomendo procurar por videos dos bastidores do Linus Tech Tips que ele detalha bastante disso. O ponto importante é que a gente imagina computador como sendo só o HD interno e no máximo um HD externo via USB. Mas tem muito mais opção que isso.

Falando em opção a última coisa que eu queria comentar é sobre storage em cloud. Seja seu Dropbox ou AWS da vida. Num container virtual você não tem nenhum controle sobre os HDs por baixo. Quando você cria uma instância tipo um AWS EC2 da vida e monta um volume de EBS, provavelmente por baixo é um SAN ou Storage Area Network, que é o terceiro tipo que faltava falar mesmo.

NAS você já entendeu, é um servidor com HDs, em alguma configuração de RAID. O servidor de 60 HDs do Linus por exemplo, provavelmente tá configurado com filesystem ZFS e uns 8 HDs são reservados pra paridade. Parece bastante mas 8 de 60 é uma perda de pouco mais de 10% comparado aos 20% que eu perco no meu RAID-5, é bem justo. Significa que ele pode ter até 8 HDs crasheando ao mesmo tempo sem perder nenhum bit de dados. Nos próximos episódios vou falar de ZFS mas só entenda pra hoje que é o melhor filesystem pra configurações assim de múltiplos HDs.

Um SAN é uma infraestrutura mais complexa. Num NAS a gente cria um volume virtual em cima dos 4 HDs ativos e enxergamos tudo como se fosse um único drivezão em vez de enxergar. Um SAN é um volume virtual bem maior, que pode agrupar o equivalente a vários NAS por baixo. A grosso modo pense num SAN como um conjunto de NAS, um rackzão de data center com vários servidores ainda maiores que o do Linus. É em cima de hardware assim que funciona um Dropbox ou Google Drive.

E se você não conhecia, EBS é o serviço da Amazon Web Services pra criar volumes virtuais, que você pode montar na sua máquina virtual Linux como se fosse um drive. Máquinas da Amazon EC2 são voláteis. Quando desliga a máquina, tudo que tinha dentro se perde. Pra persistir dados, você monta um volume do EBS e vai gravando lá. Quando desligar a instância, os dados no volume do EBS continuam lá até você remontar em outra instância.

Outra hora eu explico mais sobre porque a AWS funciona dessa forma. Mas a curiosidade é o nome. EBS é Elastic Block Storage. Existem dois tipos de dispostivos, character devices e block devices. Character devices quando você conecta ele vai imediatamente transmitindo byte a byte individualmente pro seu software. Block devices recebem ou enviam bytes literalmente em blocos. Por exemplo, setor a setor de uma partição ou melhor, clusters de vários setores ao mesmo tempo.

Um character device ou também chamado de raw device, “raw” de crú, onde a gente recebe e envia byte a byte imediamente. Um block device tem uma espera, porque a kernel do sistema operacional vai manter um cache em memória. Blocos é mais eficiente quando o dispositivo é lento. Lembra do trabalho que é o motor mover as cabeças por um disco que fica em rotação? Por outro lado, coisas como teclado, mouse, você não quer que demore, pelo contrário, você quer a menor latência possível. Por isso tem dois tipos.

Em Linux pelo menos, a distinção deve ter motivos históricos, quando o normal era ter que lidar com HDs bem lentos, ou mesmo os antigos disquetes e CDs. Ao contrário de Linux a família de UNIX BSD não trata HDs como block devices e sim como raw devices, hoje em dia. Isso porque o fato do cache existir pra tentar melhorar a performance do HD trás uma desvantagem que usuários domésticos como a gente não vai notar. Mas num servidor com muito uso pode ser fatal.

Tudo que tá num cache é volátil. Memória RAM depende de energia e se a energia caiu, perdeu o que tinha lá. Você quer RAM porque acelera a transmissão, mas quanto mais demorar lá, maiores as chances de perder. O BSD quer partir da premissa que ele não vai interferir, e seu aplicativo pode implementar cache por cima e gerenciar o risco que está disposto a assumir em vez de tentar melhorar performance ao custo de um risco escondido.

Essa situação é raro de acontecer, mas não impossível. Quantas vezes no ano caiu energia bem quando você acabou de mandar salvar alguma coisa? É raro, mas comigo mesmo ao longo dos anos aconteceu algumas vezes. Mas o ganho de performance graças aos caches automáticos do sistema operacional tem mais validade pra mim do que talvez perder um arquivo uma vez por década.

Num servidor a história é outra. Lembra o servidor do Linus com 60 HDs? Pensa servidores muito maiores, centenas de servidores, com milhares de HDs. Num data center vai ser bem mais comum ter problemas, provavelmente até múltiplas vezes por dia. Num conjunto de dezenas de milhares de HDs, certamente alguns HDs vão dar pau. Algum servidor pode dar pane de algum tipo. E se seus dados estiverem num cache na memória, você pode perder arquivos importantes de algum cliente.

Talvez por isso os BSDs, cujo maior uso é em aplicações de servidor e muito menos como desktop, não suportam mais block devices, todos são character devices ou raw devices. Não quer dizer que block devices são ruins. Num laptop, que tem bateria, você corre muito menos risco de perder alguma coisa por conta de uma falta de energia aleatória. Por outro lado, a performance extra por ter o cache vai faciltar seu dia a dia.

Mas servidores é diferente, eles ficam ligados 24 horas por dia, 7 dias por semana, com milhares de pessoas realmente lendo e gravando dados sem parar. E você não pode perder um byte, ou já já vai ter usuários muito bravos com você.

Tem muito mais que isso pra se falar sobre dispositivos de armazenamento, mas eu acho que com o que falei hoje já deve cobrir a maioria dos casos de uso que um programador médio vai precisar. Você precisa entender o que está usando e não confiar numa abstração.

Eu lembro que antigamente a gente sabia que o programa tava funcionando e lendo ou gravando porque a gente colocava a orelha no gabinete e ouvia o som do motor e das cabeças trabalhando. Pra diferenciar se um programa tava travado ou só demorando pra acabar, era só ouvir o HD. Se estivesse em silêncio e o programa ainda pausado, é porque travou. Se desse pra ouvir o HD trabalhando, então tinha que esperar mais um pouco.

Hoje em dia, especialmente se você tá conectado numa máquina virtual em cloud, não tem mais esse contato com a máquina. Então é mais importante ainda saber como essas coisas estão estruturadas, pra saber em que parte pode estar com problema: na sua aplicação, no sistema operacional, num dos caches, na camada de rede se for um NAS, e assim diagnosticar o lugar certo.

A pior coisa que um programador pode fazer é acreditar em superstições porque não entende como as coisas funcionam. Daí quando realmente precisa resolver um problema difícil vai ficar achando receitas homeopáticas e ficar tacando tudo na parede pra ver se algum gruda. Não precisa ser programador pra fazer as coisas às cegas assim.

Espero que tenha dado pra aumentar o interesse de vocês em estudar mais sobre o hardware. No próximo episódio vou falar sobre o que vai dentro dos volumes: o sistema de arquivos. Cada sistema operacional usa um diferente e eles tem vantagens e desvantagens. Se ficaram com dúvida mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, clique no sininho e compartilhem o video com seus amigos. A gente se vê, até mais.

No fim das contas, ataques como esse provavelmente vão acontecer de novo, cada vez com mais frequência. Quanto mais dispositivos online mal administrados (IoT) a gente pluga na rede, quanto mais servidores de DNS recursivos abertos espalhados por aí, e quanto mais blackhats percebem como é fácil rodar ataques desse tipo, pior a coisa fica.

Então, como mitigar esse tipo de problema?

O que eu vou sugerir agora está longe de ser a solução definitiva. Como disclaimer, eu não sou whitehat hacker nem administrador de sistemas totalmente experiente. Se você é, por favor me avise nos comentários abaixo se o que eu estou falando é furada completa ou se realmente funciona do jeito que estou descrevendo.

Eu tenho uma pequena empresa onde trabalham até umas 100 pessoas todo dia, seja como desenvolvedores de software ou no back-office administrativo. A gente precisa acessar uma série de serviços como GitHub, CodeClimate, Google Apps, Dropbox, e vários serviços internos como GitLab, Mattermost e assim por diante.

Quando aconteceu o ataque na DynDNS, tivemos alguns problemas por algumas horas. Mas a gente não apagou totalmente, felizmente.

Alguns dos serviços internos que usamos não foram afetados porque o DNS autoritativo não era a DynDNS. Então nosso chat interno, o Mattermost, por exemplo, continuou respondendo e online. O mesmo vale pro GitLab. Então não paramos todas as nossas atividades de trabalho. Mas alguns dos nossos projetos no GitHub e deploys no Heroku ficaram comprometidos.

Então esse é o plano de mitigação que estou testando: instalar meu próprio servidor de DNS recursivo/forwarder. Eu quero encaminhar todas as queries de DNS para algum DNS recursivo público como o do Google (8.8.8.8) ou o OpenDNS (208.69.38.170) e cachear os resultados por mais tempo do que o TTL que volta da query.

Caso você não saiba, toda vez que você faz um lookup de DNS, ele retorna o endereço de IP para um determinado nome (por exemplo, 50.19.85.154, 50.19.85.156, e 50.19.85.132 para heroku.com) e um Time To Live (por exemplo, 28 segundos quando rodei dig contra heroku.com).

Isso significa que, dentro daquela janela de 28 segundos, qualquer outro lookup de DNS pode confiar nos endereços de IP fornecidos sem precisar rodar as queries contra os servidores de DNS de novo (caching).

Depois que o TTL expira, eu devo consultar de novo para ver se os endereços de IP mudaram. TTLs normalmente são pequenos para que os administradores dos serviços possam livremente mover e descomissionar servidores ao menos depois de uma certa pequena janela (TTL) e ter certeza que quase todo mundo vai ver os novos endereços de IP quando o TTL expirar. Por outro lado, quanto menor o TTL, mais tráfego de DNS todo mundo precisa gerar ficando re-consultando endereços o tempo todo.

Na prática eu acredito que a maioria dos serviços é estável o bastante para não ficar trocando de servidor o tempo todo. Eles fazem isso eventualmente, por manutenção ou até por questões de escalabilidade, mas acredito que seja “raro”.

Na verdade, eu acredito que se eu tivesse meu próprio servidor de DNS, cacheando os resultados de DNS e sobrescrevendo os TTLs de 60 segundos/15 minutos para algo bem maior (digamos, 1 dia inteiro) antes de expirar e exigir uma nova query, a gente teria atravessado aquele episódio de DDoS sem nem perceber.

Aliás, eu manualmente coloquei o endereço web do GitHub no meu arquivo local /etc/hosts e consegui navegar no GitHub no meio dos ataques de DDoS.

Para a maioria das pessoas, aquele episódio apocalíptico todo pareceu que “a internet caiu”, mas na verdade só os servidores autoritativos da DynDNS caíram e todos os outros DNS recursivos, obedecendo aos TTLs, também falharam em conseguir respostas.

O efeito em cascata é que a gente simplesmente ficou sem conseguir traduzir queries de nomes de domínio como spotify.com ou heroku.com para os seus endereços IP estáticos. Mas se a gente tivesse esses endereços nos caches locais, nem teríamos sentido, porque os servidores do Spotify, do ZenDesk, do Heroku estavam todos online e bem.

É diferente de quando o data center da AWS em Sydney sofreu uma queda. Isso é bem mais raro e eu vi acontecer apenas uma vez a cada par de anos.

Unbound

Eu ia instalar o BIND9 numa máquina EC2 t2.micro da AWS. Mas li que provavelmente é exagero se eu não estou interessado em montar um servidor autoritativo. Além disso, eu não consigo setar um TTL mínimo no BIND se não me engano.

Então a outra opção mais simples é o Unbound. Está a um simples apt-get install unbound de distância.

A configuração também é super fácil, eu só adicionei isto:

server:
  interface: 0.0.0.0
  do-ip4: yes
  do-ip6: yes
  do-udp: yes
  do-tcp: yes
  do-daemonize: yes
  # access-control: 0.0.0.0/0 allow
  access-control: <seu IP público>/8 allow
  access-control: <seu IP público>/8 allow

  # Usar todas as threads (mais ou menos o mesmo número de cores disponíveis)
  num-threads: 4

  # 2^{number_of_threads}
  msg-cache-slabs: 16
  rrset-cache-slabs: 16
  infra-cache-slabs: 16
  key-cache-slabs: 16

  # Mais memória de cache (isso é por thread, se não me engano)
  rrset-cache-size: 150m
  msg-cache-size: 75m

  # Mais conexões de saída
  # Depende do número de threads
  outgoing-range: 206 # <(1024/threads)-50>
  num-queries-per-thread: 128 # <(1024/threads)/2>

  # Buffer de socket maior
  so-rcvbuf: 4m
  so-sndbuf: 4m

  # UDP mais rápido com multithreading (só no Linux)
  so-reuseport: yes

  # cache por pelo menos 1 dia
  cache-min-ttl: 172800

  # cache por no máximo 1.5 dia
  cache-max-ttl: 259200

  # segurança
  hide-identity: yes
  hide-version: yes
  harden-short-bufsize: yes
  harden-large-queries: yes
  harden-glue: yes
  harden-dnssec-stripped: yes
  harden-below-nxdomain: yes
  harden-referral-path: yes
  use-caps-for-id: yes

  use-syslog: yes

  python:
    remote-control:
            control-enable: no

  forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 8.8.4.4

Troque o <seu IP público> pelo que aparecer quando você pesquisar “what’s my IP” no Google, é melhor fazer whitelist de cada IP que você quer habilitar para consultar esse servidor.

O Unbound já vem pré-configurado para DNSSEC e parece funcionar out of the box (ou pelo menos é isso que esse teste diz).

Na minha conta de ISP “enterprise” eu tenho um endereço IP estático e consigo setar o meu Airport Extreme e adicionar o IP do meu novo servidor de DNS e todos os clientes que conectam lá recebem o novo DNS automaticamente.

Na minha conta de ISP barata de backup (o tipico serviço de DSL ou Cable), não tem IP estático então tenho que usar o DHCP e NAT do ISP e habilitar o “Bridge Mode” no roteador. Nesse caso eu não consigo deixar um DHCP secundário ligado para setar o DNS automaticamente nos clientes, então tenho que adicionar manualmente na configuração de rede do meu notebook.

De qualquer forma, uma vantagem imediata de montar meu próprio servidor de DNS é que os tempos de resposta ficam muito mais rápidos já que escolhi um data center bem próximo de mim, geograficamente. Então ao invés dos usuais 60ms do DNS do Google eu tenho menos de 30ms em média agora (não é uma melhora dramática, mas dá pra notar um pouco navegando na web).

A desvantagem é que um DNS recursivo deveria obedecer ao protocolo e usar o TTL autoritativo, sem sobrescrever nunca. Mas como estou usando apenas para IPs em whitelist dentro da minha própria organização, acredito que com um flush manual ocasional, eu devo estar ok na maior parte do tempo.

Isso não é uma garantia 100% de que a gente não vai sofrer nada no caso de outro episódio de DDoS como tivemos, porque nem todos os nomes de domínio vão estar cacheados nesse DNS local. Mas os que a gente mais usa provavelmente vão estar, particularmente serviços essenciais como acesso ao GitHub ou Heroku ou ZenDesk.

Com esse novo sistema de “caching” de DNS todas as minhas queries vão retornar e ser cacheadas com um TTL maior, por exemplo:

$ dig heroku.com

; <<>> DiG 9.8.3-P1 <<>> heroku.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34732
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;heroku.com.      IN  A

;; ANSWER SECTION:
heroku.com.   172800  IN  A 50.19.85.156
heroku.com.   172800  IN  A 50.19.85.132
heroku.com.   172800  IN  A 50.19.85.154

;; Query time: 357 msec
;; SERVER: xx.xx.xx.xx#53(xx.xx.xx.xx)
;; WHEN: Mon Oct 31 15:07:37 2016
;; MSG SIZE  rcvd: 76

Estou ofuscando o IP do meu DNS, claro. O importante é que dá pra ver que meu DNS está retornando um TTL de 172800 segundos agora. O cache local do meu notebook também deveria manter isso por esse tempo todo.

E agora minha organização deveria (possivelmente) estar protegida contra mais um ataque DDoS de DNS como tivemos com a Dyn DNS. A Zerigo já passou por isso. A SimpleDNS já passou por isso. Quem sabe qual vai sofrer em seguida, talvez todas elas de novo.

Como eu disse antes, eu não tenho 100% de certeza que essa é uma boa mitigação. Vamos ver se funciona no próximo ataque do Mirai. E um GRANDE DISCLAIMER final:

TODO servidor de DNS recursivo TEM que obedecer ao TTL autoritativo!! TTLs existem por várias razões importantes, então se você administra um servidor de DNS publicamente disponível, você NÃO PODE sobrescrever o TTL com um tempo mínimo de cache como eu fiz. Tenha certeza do que você está fazendo!

Você é um whitehat hacker experiente? Me avise se tem algo mais fácil/mais seguro. O objetivo não é consertar a internet, é só proteger a produtividade da minha pequena organização.

Vou publicar o texto na íntegra e fazer alguns comentários. Muita gente opina sobre esse Marco Civil, e meu palpite é que 99% sequer leram a lei antes de dar palpite. Então recomendo a leitura. Tirei o texto deste PDF; se estiver defasado, me avisem.

Não deixem de comentar.

SUBEMENDA SUBSTITUTIVA GLOBAL ÀS EMENDAS DE PLENÁRIO AO PROJETO DE LEI No 2.126, DE 2011

Estabelece princípios, garantias, direitos e deveres para o uso da Internet no Brasil.

O Congresso Nacional decreta:

CAPÍTULO I

DISPOSIÇÕES PRELIMINARES

Art. 1o Esta Lei estabelece princípios, garantias, direitos e deveres para o uso da Internet no Brasil e determina as diretrizes para atuação da União, dos Estados, do Distrito Federal e dos Municípios em relação à matéria.

Art. 2o A disciplina do uso da Internet no Brasil tem como fundamento o respeito à liberdade de expressão, bem como:

I – o reconhecimento da escala mundial da rede;

II – os direitos humanos, o desenvolvimento da personalidade e o exercício da cidadania em meios digitais;

III – a pluralidade e a diversidade;

IV – a abertura e a colaboração;

V – a livre iniciativa, a livre concorrência e a defesa do consumidor; e

VI – a finalidade social da rede.

Não tem como garantir “a finalidade social da rede”. A finalidade não se define por decreto, ela é o que os usuários fizerem dela. Garantir uma “finalidade social” exige manipulação restritiva, e a Internet só é o que é justamente pela ausência de finalidade imposta. Cada um faz o que bem entende e o livre mercado ajusta sozinho.

A Internet é um meio de transporte de dados, todos pagam por ela e seu uso decorre desse livre acesso. Ao definir um objetivo, por melhores que sejam as intenções, você cria restrições. Toda restrição precisa ser regulamentada, e toda regulamentação precisa de alguém para auditar.

Art. 3o A disciplina do uso da Internet no Brasil tem os seguintes princípios:

I – garantia da liberdade de expressão, comunicação e manifestação de pensamento, nos termos da Constituição;

II – proteção da privacidade;

III – proteção aos dados pessoais, na forma da lei;

IV – preservação e garantia da neutralidade de rede;

V – preservação da estabilidade, segurança e funcionalidade da rede, por meio de medidas técnicas compatíveis com os padrões internacionais e pelo estímulo ao uso de boas práticas;

VI – responsabilização dos agentes de acordo com suas atividades, nos termos da lei; VII – preservação da natureza participativa da rede;

VIII - a liberdade dos modelos de negócios promovidos na Internet, desde que não conflitem com os demais princípios estabelecidos nesta Lei.

Parágrafo único. Os princípios expressos nesta Lei não excluem outros previstos no ordenamento jurídico pátrio relacionados à matéria, ou nos tratados internacionais em que a República Federativa do Brasil seja parte.

Os parágrafos II e III são redundantes, e o III na verdade restringe o II: o primeiro define privacidade, o segundo a quebra e entrega o monopólio dessa quebra ao governo.

O V deveria ser irrelevante. Seguir qualquer padrão por decreto não funciona, e fica a pergunta: quem define o que são “técnicas compatíveis com os padrões internacionais” ou “uso de boas práticas”? Na prática, algum órgão do governo vai deter o monopólio dessa regulamentação.

O VII também não tem como ser definido. Quem determina o que é “natureza participativa”? Esses trechos garantem mais um cabide de empregos burocrático, uma Anatel ou similar, para “garantir” esses “direitos”. Todo “direito” não fundamental exige um órgão regulador, e todo órgão regulador é prejudicial.

Art. 4o A disciplina do uso da Internet no Brasil tem os seguintes objetivos:

I – promover o direito de acesso à Internet a todos;

II – promover o acesso à informação, ao conhecimento e à participação na vida cultural e na condução dos assuntos públicos;

III – promover a inovação e fomentar a ampla difusão de novas tecnologias e modelos de uso e acesso; e

IV – promover a adesão a padrões tecnológicos abertos que permitam a comunicação, a acessibilidade e a interoperabilidade entre aplicações e bases de dados.

Este artigo inteiro é ruim. Não dá para “garantir” acesso à Internet a todos, assim como não dá para garantir comida ou educação a ninguém. No momento em que se define o direito de alguém, decreta-se a subserviência de outro, porque o governo não tem os meios para garantir isso, nós cidadãos temos. E ao dizer que alguém tem direito a algo que é nosso, infringe-se também os nossos direitos.

Sinto muito, Internet não é de graça. Nem eletricidade, água e saneamento básico são de graça, alguém paga. Coloque um órgão regulador governamental e teremos o mesmo nível de serviço da Sabesp e da Eletropaulo: falta de água, blackouts e queda de luz quando chove. Por que sofremos isso? Regulamentação governamental.

Fomentar “inovação” não é nem deveria ser atribuição do governo. Inovação é consequência natural da livre concorrência e do livre mercado. Colocá-la como tarefa estatal dá permissão para gastar nosso dinheiro de impostos e jogar fora. E, de novo, quem define o que é “inovação”? Outro órgão regulador, outro cabide de burocratas.

Até aqui, a única coisa que os artigos garantem é a criação de órgãos reguladores.

Art. 5o Para os efeitos desta Lei, considera-se:

I – Internet: o sistema constituído de conjunto de protocolos lógicos, estruturado em escala mundial para uso público e irrestrito, com a finalidade de possibilitar a comunicação de dados entre terminais por meio de diferentes redes;

II – terminal: computador ou qualquer dispositivo que se conecte à Internet;

III – administrador de sistema autônomo: pessoa física ou jurídica que administra blocos de endereço Internet Protocol – IP específicos e o respectivo sistema autônomo de roteamento, devidamente cadastrada no ente nacional responsável pelo registro e distribuição de endereços IP geograficamente referentes ao País;

IV – endereço IP: código atribuído a um terminal de uma rede para permitir sua identificação, definido segundo parâmetros internacionais;

V – conexão à Internet: habilitação de um terminal para envio e recebimento de pacotes de dados pela Internet, mediante a atribuição ou autenticação de um endereço IP;

VI – registro de conexão: conjunto de informações referentes à data e hora de início e término de uma conexão à Internet, sua duração e o endereço IP utilizado pelo terminal para o envio e recebimento de pacotes de dados;

VII – aplicações de Internet: conjunto de funcionalidades que podem ser acessadas por meio de um terminal conectado à Internet; e

VIII – registros de acesso a aplicações de Internet: conjunto de informações referentes à data e hora de uso de uma determinada aplicação de Internet a partir de um determinado endereço de IP.

Ao menos mostra que alguns políticos não são totalmente analfabetos. São apenas definições técnicas, bem cruas, mas que servem para os efeitos do documento. Chama atenção o “endereço IP”, como se ele garantisse a identificação de alguém. Faltou dizer que endereço IP não pode ser usado como base para identificar ninguém.

Art. 6o Na interpretação desta Lei serão levados em conta, além dos fundamentos, princípios e objetivos previstos, a natureza da Internet, seus usos e costumes particulares e sua importância para a promoção do desenvolvimento humano, econômico, social e cultural.

CAPÍTULO II

DOS DIREITOS E GARANTIAS DOS USUÁRIOS

Art. 7o O acesso à Internet é essencial ao exercício da cidadania e ao usuário são assegurados os seguintes direitos:

I – à inviolabilidade da intimidade e da vida privada, assegurado o direito à sua proteção e à indenização pelo dano material ou moral decorrente de sua violação;

II – à inviolabilidade e ao sigilo do fluxo de suas comunicações pela Internet, salvo por ordem judicial, na forma da lei;

III – à inviolabilidade e ao sigilo de suas comunicações privadas armazenadas, salvo por ordem judicial; IV– à não suspensão da conexão à Internet, salvo por débito diretamente decorrente de sua utilização;

Traduzindo “inviolabilidade”: o provedor de acesso não deve violar, a menos que o Judiciário obrigue.

V – à manutenção da qualidade contratada da conexão à Internet;

A manutenção da qualidade contratada deveria ser foro dos Direitos do Consumidor.

VI – a informações claras e completas constantes dos contratos de prestação de serviços, com detalhamento sobre o regime de proteção aos registros de conexão e aos registros de acesso a aplicações de Internet, bem como sobre práticas de gerenciamento da rede que possam afetar sua qualidade; e

VII – ao não fornecimento a terceiros de seus dados pessoais, inclusive registros de conexão, e de acesso a aplicações de Internet, salvo mediante consentimento livre, expresso e informado ou nas hipóteses previstas em lei;

VIII – a informações claras e completas sobre a coleta, uso, armazenamento, tratamento e proteção de seus dados pessoais, que somente poderão ser utilizados para finalidades que:

a) justificaram sua coleta;

b) não sejam vedadas pela legislação; e

c) estejam especificadas nos contratos de prestação de serviços ou em termos de uso de aplicações de Internet.

IX – ao consentimento expresso sobre a coleta, uso, armazenamento e tratamento de dados pessoais, que deverá ocorrer de forma destacada das demais cláusulas contratuais;

X – à exclusão definitiva dos dados pessoais que tiver fornecido a determinada aplicação de Internet, a seu requerimento, ao término da relação entre as partes, ressalvadas as hipóteses de guarda obrigatória de registros previstas nesta Lei;

XI – à publicidade e clareza de eventuais políticas de uso dos provedores de conexão à Internet e de aplicações de Internet;

XII - à acessibilidade, consideradas as características físico-motoras, perceptivas, sensoriais, intelectuais e mentais do usuário, nos termos da Lei; e

XIII - à aplicação das normas de proteção e defesa do consumidor nas relações de consumo realizadas na Internet.

Os parágrafos desse artigo são todos redundantes. Em resumo: o provedor deve declarar o uso dos dados que coleta e, quando isso não fica claro, o governo detém o monopólio de acessá-los, já que cada parágrafo termina com “salvo por ordem judicial, na forma da lei”. Todo mundo já faz isso. Temos os “Termos de Serviço” que ninguém lê e todo mundo aceita, mas que tecnicamente estão lá.

Não chega a ser um artigo totalmente ruim: ele ratifica comportamentos que já são padrão em qualquer bom serviço. Mas todos sabemos que, por ordem judicial, qualquer um obtém qualquer coisa neste país, porque não existe limitação de privacidade para o governo. E se o governo acessa tudo, qualquer um acessa também. Não há garantia de privacidade em lugar nenhum deste documento.

Art. 8o A garantia do direito à privacidade e à liberdade de expressão nas comunicações é condição para o pleno exercício do direito de acesso à Internet.

Parágrafo único. São nulas de pleno direito as cláusulas contratuais que violem o disposto no caput, tais como aquelas que:

I - impliquem ofensa à inviolabilidade e ao sigilo das comunicações privadas pela Internet; ou

II – em contrato de adesão, não ofereçam como alternativa ao contratante a adoção do foro brasileiro para solução de controvérsias decorrentes de serviços prestados no Brasil.

CAPÍTULO III

DA PROVISÃO DE CONEXÃO E DE APLICAÇÕES DE INTERNET

Seção I

Da Neutralidade de Rede

Art. 9o O responsável pela transmissão, comutação ou roteamento tem o dever de tratar de forma isonômica quaisquer pacotes de dados, sem distinção por conteúdo, origem e destino, serviço, terminal ou aplicação.

§ 1o A discriminação ou degradação do tráfego será regulamentada nos termos das atribuições privativas do Presidente da República previstas no inciso IV do art. 84 da Constituição Federal, para a fiel execução desta Lei, ouvidos o Comitê Gestor da Internet e a Agência Nacional de Telecomunicações, e somente poderá decorrer de:

I – requisitos técnicos indispensáveis à prestação adequada dos serviços e aplicações; e

II – priorização a serviços de emergência.

§ 2o Na hipótese de discriminação ou degradação do tráfego prevista no § 1o, o responsável mencionado no caput deve:

I – abster-se de causar dano aos usuários, na forma do art. 927 do Código Civil;

II – agir com proporcionalidade, transparência e isonomia;

III – informar previamente de modo transparente, claro e suficientemente descritivo aos seus usuários sobre as práticas de gerenciamento e mitigação de tráfego adotadas, inclusive as relacionadas à segurança da rede; e

IV– oferecer serviços em condições comerciais não discriminatórias e abster-se de praticar condutas anticoncorrenciais.

§ 3o Na provisão de conexão à Internet, onerosa ou gratuita, bem como na transmissão, comutação ou roteamento, é vedado bloquear, monitorar, filtrar ou analisar o conteúdo dos pacotes de dados, respeitado o disposto neste artigo.

Em resumo, este é o artigo que deve impedir um provedor de criar um plano “Facebook”, em que o tráfego para o Facebook teria alta prioridade e o acesso ao resto ficaria mais lento ou inexistente. Também barra o “traffic shaping” silencioso, em que o provedor monitora seu tráfego e torna o acesso a certos lugares, como o Pirate Bay, mais lento.

O princípio é até válido. Acho que ninguém em sã consciência seria contra uma “neutralidade” ou isonomia.

Só que isso levanta uma pergunta. Temos internet comercial no Brasil há quase 20 anos, e antes deste documento nada disso era ilegal. Então por que você não vê uma Claro ou uma Net vendendo planos “YouTube”?

Faça essa pergunta a si mesmo. A resposta não é simples, e você vai começar a se perguntar qual é o objetivo real deste artigo.

Seção II

Da Proteção aos Registros, Dados Pessoais e Comunicações Privadas

Art. 10. A guarda e a disponibilização dos registros de conexão e de acesso a aplicações de Internet de que trata esta Lei, bem como de dados pessoais e do conteúdo de comunicações privadas, devem atender à preservação da intimidade, vida privada, honra e imagem das partes direta ou indiretamente envolvidas.

§ 1o O provedor responsável pela guarda somente será obrigado a disponibilizar os registros mencionados no caput, de forma autônoma ou associados a dados pessoais ou outras informações que possam contribuir para a identificação do usuário ou do terminal, mediante ordem judicial, na forma do disposto na Seção IV deste Capítulo, respeitado o disposto no artigo 7o.

§ 2o O conteúdo das comunicações privadas somente poderá ser disponibilizado mediante ordem judicial, nas hipóteses e na forma que a lei estabelecer, respeitado o disposto nos incisos II e III do art. 7o.

§ 3o O disposto no caput não impede o acesso, pelas autoridades administrativas que detenham competência legal para a sua requisição, aos dados cadastrais que informem qualificação pessoal, filiação e endereço, na forma da lei.

§ 4o As medidas e procedimentos de segurança e sigilo devem ser informados pelo responsável pela provisão de serviços de forma clara e atender a padrões definidos em regulamento, respeitado seu direito de confidencialidade quanto a segredos empresariais.

Esse artigo deixa explícito que todo dado fica à disposição do Judiciário. A privacidade está quebrada por lei, e o governo detém o monopólio dessa quebra. Isso abre todo tipo de corrupção. Se só o governo pode abrir as informações de alguém, a espionagem corporativa fica mais fácil: basta molhar a mão de um juiz, emitir um mandado e quem puder pagar terá acesso a qualquer coisa.

Art. 11. Em qualquer operação de coleta, armazenamento, guarda e tratamento de registros, dados pessoais ou de comunicações por provedores de conexão e de aplicações de Internet em que pelo menos um desses atos ocorram em território nacional, deverá ser obrigatoriamente respeitada a legislação brasileira, os direitos à privacidade, à proteção dos dados pessoais e ao sigilo das comunicações privadas e dos registros.

§1o O disposto no caput se aplica aos dados coletados em território nacional e ao conteúdo das comunicações, nos quais pelo menos um dos terminais esteja localizado no Brasil.

§2o O disposto no caput se aplica mesmo que as atividades sejam realizadas por pessoa jurídica sediada no exterior, desde que oferte serviço ao público brasileiro ou pelo menos uma integrante do mesmo grupo econômico possua estabelecimento no Brasil.

§3o Os provedores de conexão e de aplicações de Internet deverão prestar, na forma da regulamentação, informações que permitam a verificação quanto ao cumprimento da legislação brasileira referente à coleta, guarda, armazenamento ou tratamento de dados, bem como quanto ao respeito à privacidade e ao sigilo de comunicações.

Mais um mecanismo que garante a criação de um órgão regulador, e aqui está escrito “na forma da regulamentação”. Quem vai “verificar o cumprimento da legislação brasileira referente à coleta, guarda e armazenamento”? Isso sempre foi desnecessário e continua sendo, mas agora vamos pagar algum auditor vagabundo para não fazer nada e ainda intimidar serviços menores, restringindo a livre concorrência. Quer atrapalhar o negócio de alguém? Chame essa “polícia” dizendo que a empresa X não cumpre este parágrafo.

§4o Decreto regulamentará o procedimento para apuração de infrações ao disposto neste artigo.

Art. 12. Sem prejuízo das demais sanções cíveis, criminais ou administrativas, as infrações às normas previstas nos artigos 10 e 11 ficam sujeitas, conforme o caso, às seguintes sanções, aplicadas de forma isolada ou cumulativa:

I – advertência, com indicação de prazo para adoção de medidas corretivas;

II – multa de até dez por cento do faturamento do grupo econômico no Brasil no seu último exercício, excluídos os tributos, considerados a condição econômica do infrator e o princípio da proporcionalidade entre a gravidade da falta e a intensidade da sanção;

III – suspensão temporária das atividades que envolvam os atos previstos no artigo 11; ou IV – proibição de exercício das atividades que envolvam os atos previstos no artigo 11. Parágrafo único. Tratando-se de empresa estrangeira, responde solidariamente pelo pagamento da multa de que trata o caput sua filial, sucursal, escritório ou estabelecimento situado no País.

Subseção I

Da Guarda de Registros de Conexão

Art. 13. Na provisão de conexão à Internet, cabe ao administrador de sistema autônomo respectivo o dever de manter os registros de conexão, sob sigilo, em ambiente controlado e de segurança, pelo prazo de um ano, nos termos do regulamento.

§ 1o A responsabilidade pela manutenção dos registros de conexão não poderá ser transferida a terceiros.

§ 2o A autoridade policial ou administrativa ou o Ministério Público poderá requerer cautelarmente que os registros de conexão sejam guardados por prazo superior ao previsto no caput.

§ 3o Na hipótese do § 2o, a autoridade requerente terá o prazo de sessenta dias, contados a partir do requerimento, para ingressar com o pedido de autorização judicial de acesso aos registros previstos no caput.

§ 4o O provedor responsável pela guarda dos registros deverá manter sigilo em relação ao requerimento previsto no § 2o, que perderá sua eficácia caso o pedido de autorização judicial seja indeferido ou não tenha sido protocolado no prazo previsto no § 3o.

§ 5o Em qualquer hipótese, a disponibilização ao requerente, dos registros de que trata este artigo, deverá ser precedida de autorização judicial, conforme disposto na Seção IV deste Capítulo.

§ 6o Na aplicação de sanções pelo descumprimento ao disposto neste artigo, serão considerados a natureza e a gravidade da infração, os danos dela resultantes, eventual vantagem auferida pelo infrator, as circunstâncias agravantes, os antecedentes do infrator e a reincidência.

Entendo que este artigo se refere apenas aos provedores de acesso. É só uma justificativa para aumentar custos e, de novo, quebrar a privacidade.

Subseção II

Da Guarda de Registros de Acesso a Aplicações de Internet na Provisão de Conexão

Art. 14. Na provisão de conexão, onerosa ou gratuita, é vedado guardar os registros de acesso a aplicações de Internet.

Subseção III

Da Guarda de Registros de Acesso a Aplicações de Internet na Provisão de Aplicações

Art 15. O provedor de aplicações de Internet constituído na forma de pessoa jurídica, que exerça essa atividade de forma organizada, profissionalmente e com fins econômicos, deverá manter os respectivos registros de acesso a aplicações de internet, sob sigilo, em ambiente controlado e de segurança, pelo prazo de seis meses, nos termos do regulamento.

§ 1o Ordem judicial poderá obrigar, por tempo certo, os provedores de aplicações de Internet que não estão sujeitos ao disposto no caput a guardarem registros de acesso a aplicações de Internet, desde que se tratem de registros relativos a fatos específicos em período determinado.

§ 2o A autoridade policial ou administrativa ou o Ministério Público poderão requerer cautelarmente a qualquer provedor de aplicações de Internet que os registros de acesso a aplicações de Internet sejam guardados, inclusive por prazo superior ao previsto no caput, observado o disposto nos §§ 3o e 4o do art. 13.

§ 3o Em qualquer hipótese, a disponibilização ao requerente, dos registros de que trata este artigo, deverá ser precedida de autorização judicial, conforme disposto na Seção IV deste Capítulo.

§ 4o Na aplicação de sanções pelo descumprimento ao disposto neste artigo, serão considerados a natureza e a gravidade da infração, os danos dela resultantes, eventual vantagem auferida pelo infrator, as circunstâncias agravantes, os antecedentes do infrator e a reincidência.

Este é ainda mais orwelliano. Ele permite que o governo obrigue um provedor a rastrear mais informações, por período indeterminado e de forma indiscriminada. O governo já conseguia isso antes, por influência da Anatel e de outros lobbies, mas agora fica assegurado por lei.

Art. 16. Na provisão de aplicações de Internet, onerosa ou gratuita, é vedada a guarda:

I - dos registros de acesso a outras aplicações de Internet sem que o titular dos dados tenha consentido previamente, respeitado o disposto no art. 7o; ou

II – de dados pessoais que sejam excessivos em relação à finalidade para a qual foi dado consentimento pelo seu titular.

Art. 17. Ressalvadas as hipóteses previstas nesta Lei, a opção por não guardar os registros de acesso a aplicações de Internet não implica responsabilidade sobre danos decorrentes do uso desses serviços por terceiros.

Seção III

Da Responsabilidade por Danos Decorrentes de Conteúdo Gerado por Terceiros

Art. 18. O provedor de conexão à Internet não será responsabilizado civilmente por danos decorrentes de conteúdo gerado por terceiros.

Art. 19. Com o intuito de assegurar a liberdade de expressão e impedir a censura, o provedor de aplicações de Internet somente poderá ser responsabilizado civilmente por danos decorrentes de conteúdo gerado por terceiros se, após ordem judicial específica, não tomar as providências para, no âmbito e nos limites técnicos do seu serviço e dentro do prazo assinalado, tornar indisponível o conteúdo apontado como infringente, ressalvadas as disposições legais em contrário.

§ 1o A ordem judicial de que trata o caput deverá conter, sob pena de nulidade, identificação clara e específica do conteúdo apontado como infringente, que permita a localização inequívoca do material.

§ 2o A aplicação do disposto neste artigo para infrações a direitos de autor ou a diretos conexos depende de previsão legal específica, que deverá respeitar a liberdade de expressão e demais garantias previstas no art. 5o da Constituição Federal.

§ 3o As causas que versem sobre ressarcimento por danos decorrentes de conteúdos disponibilizados na Internet relacionados à honra, à reputação ou a direitos de personalidade bem como sobre a indisponibilização desses conteúdos por provedores de aplicações de Internet poderão ser apresentadas perante os juizados especiais.

§ 4o O Juiz, inclusive no procedimento previsto no § 3o, poderá antecipar, total ou parcialmente, os efeitos da tutela pretendida no pedido inicial, existindo prova inequívoca do fato e considerado o interesse da coletividade na disponibilização do conteúdo na Internet, desde que presentes os requisitos de verossimilhança da alegação do autor e de fundado receio de dano irreparável ou de difícil reparação.

Isso não parece totalmente ruim, já acontece hoje, mas ficou mais confuso. Na prática, se um usuário do seu site faz um comentário ofensivo e o ofendido consegue uma ordem judicial, o site não responde criminalmente pelo conteúdo desde que o retire quando for ordenado.

Quem mais usa esse recurso são os imbecis candidatos a cargos públicos, que soltam ordens judiciais o tempo todo contra qualquer site com conteúdo político. O problema é que ofender um político é contra a lei. A nossa Constituição, em si, virou um problema hoje em dia.

Art. 20. Sempre que tiver informações de contato do usuário diretamente responsável pelo conteúdo a que se refere o art. 19, caberá ao provedor de aplicações de Internet comunicar-lhe os motivos e informações relativos à indisponibilização de conteúdo, com informações que permitam o contraditório e a ampla defesa em juízo, salvo expressa previsão legal ou salvo expressa determinação judicial fundamentada em contrário.

Parágrafo único. Quando solicitado pelo usuário que disponibilizou o conteúdo tornado indisponível, o provedor de aplicações de Internet que exerce essa atividade de forma organizada, profissionalmente e com fins econômicos, substituirá o conteúdo tornado indisponível, pela motivação ou pela ordem judicial que deu fundamento à indisponibilização.

Art. 21. O provedor de aplicações de Internet que disponibilize conteúdo gerado por terceiros será responsabilizado subsidiariamente pela violação da intimidade decorrente da divulgação, sem autorização de seus participantes, de imagens, vídeos ou outros materiais contendo cenas de nudez ou de atos sexuais de caráter privado quando, após o recebimento de notificação pelo participante ou seu representante legal, deixar de promover, de forma diligente, no âmbito e nos limites técnicos do seu serviço, a indisponibilização desse conteúdo.

Parágrafo único. A notificação prevista no caput deverá conter, sob pena de nulidade, elementos que permitam a identificação específica do material apontado como violador da intimidade do participante e a verificação da legitimidade para apresentação do pedido.

Seção IV

Da Requisição Judicial de Registros

Art. 22. A parte interessada poderá, com o propósito de formar conjunto probatório em processo judicial cível ou penal, em caráter incidental ou autônomo, requerer ao juiz que ordene ao responsável pela guarda o fornecimento de registros de conexão ou de registros de acesso a aplicações de Internet.

Parágrafo único. Sem prejuízo dos demais requisitos legais, o requerimento deverá conter, sob pena de inadmissibilidade:

I – fundados indícios da ocorrência do ilícito;

II – justificativa motivada da utilidade dos registros solicitados para fins de investigação ou instrução probatória; e

III – período ao qual se referem os registros.

Esse artigo estende o que os anteriores já definiram: o acesso irrestrito e indiscriminado a dados que deveriam ter “privacidade” garantida.

Art. 23. Cabe ao juiz tomar as providências necessárias à garantia do sigilo das informações recebidas e à preservação da intimidade, vida privada, honra e imagem do usuário, podendo determinar segredo de justiça, inclusive quanto aos pedidos de guarda de registro.

“Cabe ao juiz”, ou seja, esqueça sua privacidade. Juízes podem ser, e são, comprados. É um mercado.

CAPÍTULO IV

DA ATUAÇÃO DO PODER PÚBLICO

Art. 24. Constituem diretrizes para a atuação da União, dos Estados, do Distrito Federal e dos Municípios no desenvolvimento da Internet no Brasil:

I – estabelecimento de mecanismos de governança multiparticipativa, transparente, colaborativa e democrática, com a participação do governo, do setor empresarial, da sociedade civil e da comunidade acadêmica;

II – promoção da racionalização da gestão, expansão e uso da Internet, com participação do Comitê Gestor da Internet no Brasil;

III – promoção da racionalização e da interoperabilidade tecnológica dos serviços de governo eletrônico, entre os diferentes Poderes e níveis da federação, para permitir o intercâmbio de informações e a celeridade de procedimentos;

IV – promoção da interoperabilidade entre sistemas e terminais diversos, inclusive entre os diferentes níveis federativos e diversos setores da sociedade;

V – adoção preferencial de tecnologias, padrões e formatos abertos e livres;

VI – publicidade e disseminação de dados e informações públicos, de forma aberta e estruturada;

VII – otimização da infraestrutura das redes e estímulo à implantação de centros de armazenamento, gerenciamento e disseminação de dados no país, promovendo a qualidade técnica, a inovação e a difusão das aplicações de Internet, sem prejuízo à abertura, à neutralidade e à natureza participativa;

VIII – desenvolvimento de ações e programas de capacitação para uso da Internet; IX – promoção da cultura e da cidadania; e

X – prestação de serviços públicos de atendimento ao cidadão de forma integrada, eficiente, simplificada e por múltiplos canais de acesso, inclusive remotos.

Este artigo sanciona a parte orwelliana: a criação de órgãos reguladores, a “Thought Police”. Esse órgão seria responsável por “garantir” o que está nos parágrafos: estabelecer mecanismos de governança, racionalizar a gestão, promover a interoperabilidade e por aí vai. Você sancionou por lei a criação de uma máquina de corrupção, reserva de mercado, quebra da livre concorrência e sucateamento do mercado de Internet.

Entenda: não há como definir “governança multiparticipativa”, “colaborativa” ou “racionalização”. Quem decide o que é colaborativo, interoperável ou eficiente? Alguém precisa interpretar, e tudo que fica aberto à interpretação só beneficia quem tem poder para impor a sua leitura. Por definição, é um texto ruim.

Art. 25. As aplicações de Internet de entes do Poder Público devem buscar:

I – compatibilidade dos serviços de governo eletrônico com diversos terminais, sistemas operacionais e aplicativos para seu acesso;

II – acessibilidade a todos os interessados, independentemente de suas capacidades físico- motoras, perceptivas, sensoriais, intelectuais, mentais, culturais e sociais, resguardados os aspectos de sigilo e restrições administrativas e legais;

III – compatibilidade tanto com a leitura humana quanto com o tratamento automatizado das informações;

IV – facilidade de uso dos serviços de governo eletrônico; e

V – fortalecimento da participação social nas políticas públicas.

Isso não deveria estar aqui. São cláusulas técnicas de licitação de projetos de software, que já existem, e não vejo utilidade nelas. Em alguns casos os itens são dispensáveis e criam mais uma restrição desnecessária.

Art. 26. O cumprimento do dever constitucional do Estado na prestação da educação, em todos os níveis de ensino, inclui a capacitação, integrada a outras práticas educacionais, para o uso seguro, consciente e responsável da Internet como ferramenta para o exercício da cidadania, a promoção de cultura e o desenvolvimento tecnológico.

Não é dever do estado garantir isso.

Art. 27. As iniciativas públicas de fomento à cultura digital e de promoção da Internet como ferramenta social devem:

I – promover a inclusão digital;

II – buscar reduzir as desigualdades, sobretudo entre as diferentes regiões do País, no acesso às tecnologias da informação e comunicação e no seu uso; e

III – fomentar a produção e circulação de conteúdo nacional.

Art. 28. O Estado deve, periodicamente, formular e fomentar estudos, bem como fixar metas, estratégias, planos e cronogramas referentes ao uso e desenvolvimento da Internet no País.

De novo, não é dever do Estado. Este capítulo inteiro é restritivo e não deveria existir, porque libera o uso irrestrito do nosso dinheiro em programas de governo. Como contribuinte, sou contra qualquer programa que gaste meu dinheiro assim. É o direito de um quebrando o direito do outro, e por definição isso não pode ser um direito garantido.

CAPÍTULO V

DISPOSIÇÕES FINAIS

Art. 29. O usuário terá a opção de livre escolha na utilização de programa de computador em seu terminal para exercício do controle parental de conteúdo, entendido por ele como impróprio a seus filhos menores, desde que respeitados os princípios desta Lei e da Lei no 8.069 de 13 de julho de 1990.

Parágrafo único. Cabe ao Poder Público, em conjunto com os provedores de conexão e de aplicações de Internet e a sociedade civil, promover a educação e fornecer informações sobre o uso dos programas de computador previstos no caput, bem como para a definição de boas práticas para a inclusão digital de crianças e adolescentes.

Art. 30. A defesa dos interesses e direitos estabelecidos nesta Lei poderá ser exercida em juízo, individual ou coletivamente, na forma da lei.

Art. 31. Até a entrada em vigor da lei específica prevista no § 2o do art. 19, a responsabilidade do provedor de aplicações de Internet por danos decorrentes de conteúdo gerado por terceiros, quando se tratar de infração a direitos de autor ou a direitos conexos, continuará a ser disciplinada pela legislação autoral em vigor aplicável na data da entrada em vigor desta Lei.

Art. 32. Esta Lei entrará em vigor sessenta dias após a data de sua publicação.

Deputado ALESSANDRO MOLON. Relator

Sinceramente, não vejo vantagem nesse texto. A parte relevante, a neutralidade, deveria ser regulada pelos Direitos do Consumidor. Todo o resto sanciona a legalidade da quebra de privacidade e entrega o monopólio dessa quebra ao governo. E ainda cria “direitos” que vão exigir mais gasto público e mais aparelhamento do Estado, às nossas custas e sem benefício aparente. No fundo é um documento de propaganda para fazer o governo parecer bom, às minhas custas e às suas. Parabéns.

Forewords

A verdadeira Guerra Fria, nos anos 60, não estava sendo travada em campo, com soldados e aviões, e sim nos laboratórios de pesquisa, financiados pelo governo e universidades já estavam equipadas com os melhores recursos computacionais disponíveis. Achava-se que a habilidade de criar e manter vantagens tecnológicas sobre o adversário determinaria o vencedor do conflito.

A idéia de conectar esses centros, objetivando a troca de informações, começou a ser desenvolvida. Porém, foi atribuído um fator determinante na escolha da tecnologia de rede que viria a viabilizar a conexão dos centros estratégicos: a informação deveria continuar a fluir, mesmo sob as piores condições, tal como um ataque nuclear.

Foi delegada à **ARPA **( Advanced Research Projects Agency ) e ao DoD ( Department of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para **DARPA **( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do **INWG **( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o **IP **( Internet Protocol ) e o **TCP **( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Números

Para entender a importância da Internet em todos os sentidos : sociais, políticos e financeiros, é preciso ver quem navega pela Internet. Vamos nos basear nas pesquisas de John Quarterman, um provedor de acesso, consultor e publisher de Austin, Texas, que pesquisa a composição da população da Internet na sua Internet Demographic Survey.

Uma das coisas que Quarterman tem feito é definir várias Internets de acordo com os tipos de aplicações que rodam nos servidores e as atividades dos usuários. O “núcleo da Internet” é constituído por computadores que oferecem serviços interativos como FTP, Telnet ou aplicações WWW. A “Internet de consumo” inclui pessoas que usam os serviços interativos oferecidos pelo núcleo - por exemplo, usuários que navegam no World Wide Web. O total do ciberespaço, que rotula como a “matriz”, são todos os usuários que trocam e-mail com outros usuários. Essas categorias se encaixam uma na outra: a matriz inclui a Internet de consumo, que inclui a Internet Núcleo.

Um dos problemas que Quarterman tem que enfrentar envolve hosts virtuais. Um provedor de acesso à Internet tem que registrar os nomes de domínio para os usuários, mas os endereços, na verdade, residem nas máquinas do provedor. Isso pode levar a equívocos, fazendo parecer que as pessoas têm máquinas conectadas à Internet. Esse grupo pertence à categoria de Internet de consumo, e todo o correio que Quarterman envia para os postmasters em vários endereços é no final englobado por um host.

“O problema dos hosts virtuais cresceu enormemente no ano passado ( 1995 )”, disse Quarterman. “Você pode acessar um site Web, realmente existe informação lá, e realmente corresponde à organização. Está de fato em um computador na Internet, mas pode ser o mesmo computador de outros domínios.”

A pesquisa mais recente, para 1995, foi publicada em janeiro de 1996. Do universo de 45.091 domínios, **2,9% ( 1.293 ) **responderam. No mundo da estatística, mais de 1.000 respostas é um número grande de dados e essas respostas representam organizações inteiras, e não usuários apenas. Nessa pesquisa, Quarterman estima que havia **16,9 milhões de usuários da Internet nuclear **( mais do que o dobro do ano passado ) e **26,4 milhões de usuários da Internet de consumo **( novamente o dobro ); **39 milhões de usuários **( um aumento de 50% ) já dispunham de e-mail. Quarterman atribui o aumento aos usuários de Internet nas redes de consumo ( America Online, Compuserve, Prodigy, e outras ).

Na pesquisa de 1995, Quarterman contou 45 mil máquinas conectadas à Internet. O número real de domínios registrados excedeu este número porque nem todos os domínios registrados são usados e alguns são domínios em outras redes, como a UUCP, onde você pode enviar correio, mas não pode usar serviços Internet interativos.

O Web é quente, mas o FTP ainda supera a navegação. Quarterman também percebe que o uso do sistema operacional Windows está caindo e que os Macintoshes ( apesar do uso do Internet Protocol e não do MacOS ) e as máquinas Unix estão aumentando sua fatia no controle de domínios.

Os resultados são anunciados e veiculados no site Web da **MIDS **( que publica as revistas mensais **Matrix News **e Matrix Maps Quarterly, ambas em papel e on-line, e vende mapas e outras informações sobre hosts Internet, sobre usuários e outros dados demográficos ) em http://www.mids.org. “O que disponibilizamos aos que responderam aos questionários, e à Internet como um todo há quase um mês, é um resultado das respostas para cada questão. Também conseguimos traçar níveis de detalhes entre as respostas individuais ( que nunca são reveladas ) e os resumos. É com isso que conseguimos alguma renda”.

Falando sobre o Brasil, o secretário de Política de Informática e Automação do Ministério da Ciência e Tecnologia, Ivan Moura Campos, diz que o Brasil ostenta um dos crescimentos mais espantosos rumo ao _cyberspace _- estamos crescendo 50% ao mês. Com isso chegamos à uma população de **260 mil cibernautas **no início do mês de maio deste ano. Para se ter uma idéia, se a taxa de adesão continuasse nessa velocidade, até o final do ano o número de cibernautas brasileiros seria de 16 milhões. Mas as previsões do Secretário, mais realistas, estimam **um milhão de usuários **na virada do ano.

Publicidade

Depois da revolução dos microcomputadores na década de 80 e da disseminação da informática com “um micro em cada mesa e em cada casa”, tivemos uma das maiores evoluções já vistas na história onde a humanidade evoluiu em 10 anos o que não conseguiu evoluir desde a Idade Média, entrando na Era da Informação.

Com os microcomputadores e a Internet as fronteiras físicas foram apagadas, num lugar onde “países” e “oceanos” não têm mais significado e onde as distâncias físicas não fazem mais sentido. A **virtualização **evoluiu a tal ponto que uma pessoa que mora num país como o Brasil já pode conhecer e fazer amizade com pessoas de qualquer parte do mundo, como da Austrália, por exemplo. Ferramentas como o **CoolTalk **da Netscape Inc. ( **http://www.netscape.com **) que substitui o telefone ou o TimedVideo Grabber ( **http://www.avernus.com/~allan **) que possibilita a transmissão de imagens em _real-time _com o uso de câmera, tornam possível pessoas se conhecerem sem nunca precisarem realmente se encontrarem em “carne-e-osso”.

E falando em evolução, depois de 500 anos de reinado absoluto das mídias impressas como difusor de informação, esta está sendo rapidamente substituída por publicações digitais na World Wide Web, a parte da Internet que mais chama a atenção atualmente.

Com trabalhos pioneiros como a **Enciclopédia Britannica **( **http://www.eb.com **), que foi absolutamente abalada depois que as enciclopédias impressas caíram em total desuso depois do surgimento das enciclopédias digitais como a **Encarta **da **Microsoft **( **http://www.microsoft.com **), e também de serviços de procura do tipo “páginas amarelas” como as oferecidas por sites como o **Yahoo! **( **http://www.yahoo.com **) ou **Lycos **( **http://www.lycos.com **), tornaram a Internet também o maior repositório de dados já feito, o melhor lugar para pesquisas que se pode encontrar.

Revistas mundialmente famosas como a **PC Magazine **( **http://www.pcmag.com **) da **Ziff Davis Publishing **( **http://www.ziff.com **) ou a **Playboy **( **http://www.playboy.com **) já têm suas publicações exibidas e atualizadas periodicamente na WWW.

A World Wide Web ou WWW foi concebida para dar uma “cara” à Internet, possibilitando a edição de sites gráficos ao contrário da até então interface baseada em texto ( algo semelhante à passagem do DOS para o Windows, por exemplo ). Uma nova linguagem de script foi criada, a **HTML **( Hyper Text Mark-Up Language ) e um protocolo específico, a **HTTP **( Hyper Text Transfer Protocol ). E para a navegação por essas pages foram criados os browsers, programas feitos para interpretar o HTML. Logo de início, duas se sobressaíram, a Netscape com seu **Netscape Navigator **e a **SpyGlass **com seu Mosaic. A Netscape se tornou mais difundida e a SpyGlass vendeu os direitos do Mosaic para a Microsoft que hoje distribui o maior concorrente da Netscape, o Internet Explorer, numa das maiores campanhas de distribuição de softwares já vistas.

A possibilidade de se editar praticamente tudo que existe em mídias impressas, rapidamente chamou a atenção do mundo para a Internet. Novos conceitos começaram a surgir como o de publishing on-line. Um dos exemplos mais recentes é sobre as Olimpíadas de Atlanta onde o trabalho de informática ficou a cargo da **IBM **( **http://www.ibm.com **) que montou um esquema grandioso de máquinas e redes e distribuição de informação via Internet que pode ser conferido na homepage das **Olimpíadas **( **http://www.atlanta.olympic.org **), onde os dados são atualizados tão logo são obtidos, assim, ao fim de cada jogo, a homepage pode ser atualizada e o mundo todo tem acesso a elas, não precisando esperar até o dia seguinte para lê-los nos jornais.

Falando em jornais, estes também não ficam atrás, colocando na WWW, muito das suas publicações diárias como o **The Gate **( **http://sfgate.com **) um produto baseado em Internet de dois jornais da Costa Oeste dos Estados Unidos, o **San Francisco Chronicle **e o **San Francisco Examiner **com direito a áreas de conferência com fóruns de discussão como Comunidade, Mídia, Esportes, Filmes, etc.

A Agência Estado, que publica jornais famosos como o Estado de São Paulo, também já distribui seu jornal via internet ( **http://www.agestado.com.br **) com as principais chamadas do dia e informações diversas, incluindo seus classificados e, num período de olimpíadas, com áreas especiais para os esportes em Atlanta.

Outro conceito que se tornou famoso com a Internet é a dos **serviços on-line **como as gigantes **Compuserve **e **America On-line **que atendem a pessoas do mundo todo e têm aliados como Netscape e Microsoft. Esse tipo de organização é baseada em “serviços” que incluem fóruns de discussão; bibliotecas com informações atualizadas; revistas, jornais e outros periódicos; lojas virtuais que vendem desde CDs a roupas; dicas de lazer e negócios; e também serviços comuns à Internet como e-mail e WWW.

No Brasil também começou a se disseminar tais tipos de serviço, com destaque para a **Folha de São Paulo **e o **Grupo Abril **que lançaram, respectivamente, o **Universo Online **e o Brasil Online. Tais serviços brasileiros ainda são experimentais e de graça, sem projeções quanto a custos. A título de ilustração, o **The New York Times **cobra US$ 30,00 por mês e a America Online cobra US$ 9,95 por 5 horas ou US$ 19,95 por 20 horas.

Tais serviços têm faturamentos muito altos principalmente por causa da empolgação atual do mundo em torno da virtualização de serviços e pelo aluguel do espaço digital para empresas que se interessam em colocar “out-doors virtuais” ou mesmo acrescentar outros serviços como lojas digitais nas páginas principais, visto que o número de pessoas que trafegam pelas linhas digitais todos os dias é muito grande. Para ver isso basta entrar na página do Brasil Online, por exemplo, e se deparar com chamadas de publicidade de empresas como a **Sun **ou a Credicard. Essas chamadas são links que levam às homepages das respectivas empresas.

E falando em propaganda, alguém deve estar confeccionando tais pages e anúncios. Essas empresas estão se especializando em desenhar páginas específicas e criativas para um tipo de mídia que sai das limitações do papel e possibilita coisas como **Hypertext **( palavras dentro de um texto que levam a outras páginas ), **Marquees **( frases que se movimentam na linha ), músicas ( através de arquivos **WAVE **ou da nova tecnologia **Real Audio **), animações ( via imagens **GIF **animadas ou então utilizando recursos da linguagem **Java **) ou ainda ambientes totalmente tridimensionais ( utilizando a tecnologia **VRML - Virtual Reality Markup Language **) e muito mais. Nesse filão mercadológico estão empresas como a **Vivid Studio **( **http://www.vivid.com **) que tem como clientes as gigantes **Silicon Graphics **e Microsoft ou a **Razorfish **( **http://www.razorfish.com **) que desenha para a **Time-Warner **e a Pepsi.

Comércio

O principal ponto de atrito quando se fala em comércio digital é a segurança. O protocolo TCP/IP é o ponto de partida para a Internet, concebido como um protocolo universal mas que peca no aspecto segurança, onde, ao contrário dos seus irmãos **IPX/SPX **ou **NetBIOS **por exemplo, não possui transmissão de dados encriptados. Uma vez sendo o protocolo padrão de transmissão de dados, teria sido conveniente estipular um protocolo também padrão de segurança de dados. Uma vez que este não existe, o impasse fica em torno de empresas que brigam para desenvolver o padrão do que causaria a arrancada inicial rumo ao fim do dinheiro impresso e o desenvolvimento do crédito digital.

Um dos mais antigos é o **cybercash **( **http://www.cybercash.com **) com mais ou menos um ano de idade. Por enquanto, a empresa só trabalha com serviços de cartões de crédito, mas em breve promete oferecer serviços de pagamentos monetários. Atualmente, com um browser ligado à rede pode-se comprar com segurança em shoppings virtuais. Através do protocolo **SIPS **( Secure Internet Payment Service ), segundo a empresa, é tão fácil quanto apontar e clicar. Nesse tipo de transação, compra-se quantos cybercashes quantos desejados e debita-se no cartão de crédito.

O padrão do Cybercash suporta todos os tipos de cartão de crédito. Usa os padrões de encriptação **768-bit RSA **e a 56-bit DES. Todas as transações são autenticadas com as assinaturas **MDS **e 768-bit RSA. A primeira providência para quem se interessou é baixar o programa gratuito que a empresa oferece. O servidor da Cybercash está ligado às redes privadas de vários bancos. Os serviços iniciais da empresa incluem cartões de crédito e de débito e um sistema de pagamentos eletrônicos. Pelos serviços, os usuários pagam uma quantia módica, comparável ao valor de um selo. Para os fornecedores, o sistema representa uma economia nas taxas cobradas pelas transações de cartões de crédito, em função do risco ainda existente nas transações por telefone e e-mail.

Nesse tipo de desenvolvimento ainda encontram-se empresas como a **Digicash **( **http://www.digicash.com **), com os serviços centrados no site da **First Digital Bank **( **http://bank.digicash.com **), utilizando sistema de e-cash ( dinheiro real convertido em dinheiro virtual em contas virtuais ). A **Visa **( **http://www.visa.com **) ( que também já é parceira da **Sony **- **http://www.sony.com **- no desenvolvimento de um ambiente multifacetado de entretenimento, informações e transações comerciais ) e a Microsoft possuem o **STT **( Secure Transaction Technology ), o padrão dessas duas poderosas quer se tornar uma versão eletrônica do cartão de crédito. A **Mastercard **( **http://www.mastercard.com **) está em parceria com a IBM, Netscape, GTE e Cybercash, com o padrão **SEPP **( Secure Eletronic Payment Protocol ). Trata-se de um protocolo aberto para transações on-line seguras.

A Netscape desenvolve o protocolo aberto de segurança **SSL **( Secure Sockets Layer ) e contribui no desenvolvimento da interface **SSL **do **W3C **( World Wide Web Consortium ), consórcio europeu que se dedica a criar um padrão para o Mercado Comum Europeu - **http://www.w3.org **). Desse consórcio fazem parte cerca de 50 companhias de todo o mundo. A empresa irá licenciar a tecnologia SSL a seus parceiros para uso comercial. A lista de parceiros inclui MCI ( http://www.mci.com ), Bank of America ( http://www.bankamerica.com ), Mastercard, First Data Corporation, Novell ( http://www.novell.com ), Digital ( http://www.dec.com ) e Silicon Graphics.

Praticamente todas as empresas do setor financeiro vêm investindo muito no desenvolvimento de uma plataforma segura e confiável suficiente para transações financeiras de todos os níveis de importância. Hackers à parte, os negócios via Internet não diferem muito dos efetuados fora dela. Ou seja, a melhor forma de estar livre de problemas é confiar na credibilidade das empresas sérias. Dificilmente alguém vai querer comprometer seu bom nome deixando de entregar a mercadoria no prazo ou “negociando” o número do cartão de crédito.

No Brasil, o **Mappin **( **http://www.mappin.com.br **) foi a primeira grande empresa a entrar no ramo das vendas por computador. Também é possível escolher doces e tortas na **Confeitaria Brunella **( **http://www.ams.com/brunella **) de São Paulo ou fazer reservas ao **Marcellu’s Bar **( **http://www.marcellus-bar.com.br **) do Rio de Janeiro. O consumidor escolhe o doce ou torta que quer comprar através das fotos e descrições na homepage da Brunella, depois a loja telefona para confirmar o pedido e encaminha a mercadoria. No caso do Marcellu’s Bar, a reserva é feita por e-mail.

Se há alguém de mudança para os Estados Unidos ou precisando simplesmente comprar preços, poderá consultar o For Sail By Owner Connection. Trata-se de um site especializado em vendas de casas, com fotos e especificações. Se na verdade você precisa vender a sua casa, também poderá anunciar nesta page : http://www.cracker.com/byowner.

Pensando em viagens, a **Cruisin **( **http://www.cracker.com/cruisin **) é a primeira agência de turismo especializada em cruzeiros que atende exclusivamente pela Internet. Mas já existem muitos hotéis e agências na rede. Realmente há alternativas para todos os limites bancários: de castanhas do Ceará por menos de R$ 3,00 até uma casa na Flórida por US$ 329 mil. Hoje em dia é virtualmente possível se comprar de tudo na Internet.

Afterwords

Criado para fins militares, depois expandido para os meios acadêmicos e, finalmente, atingindo o público em geral, a Internet caminha em evolução acelerada cobrindo praticamente todos os setores da sociedade onde se constrói as bases do que pode ser considerado um mundo virtual.

Quando a Internet evoluir o suficiente, as novas tecnologias irão construir a esperada **Information Super Highway **onde, aí sim, se constituirá uma rede verdadeiramente mundial, utilizando-se não somente os computadores da forma como os conhecemos mas também qualquer equipamento eletrônico, como os set-top-boxes ( os substitutos dos video-cassetes e video-lasers ).

Nessa próxima geração, “passear” será vestir uma roupa de realidade virtual e visitar locais virtuais com amigos de outros continentes num encontro digital. E isso não se trata de delírios de ficção científica: tanto estamos perto disso que tais tecnologias são reais e já existem, tudo que resta é o tempo para torná-las acessíveis e operacionais a nível de distribuição em massa.

O texto a seguir está exatamente como deixei num arquivo Word, em 3 de agosto de 1996, às 9:52 da manhã, com o nome “CAP12.DOC”. Vejam como eu via a Internet 17 anos atrás.

Vendas pela Internet

Forewords

A verdadeira Guerra Fria, nos anos 60, não estava sendo travada em campo, com soldados e aviões, e sim nos laboratórios de pesquisa, financiados pelo governo e universidades já estavam equipadas com os melhores recursos computacionais disponíveis. Achava-se que a habilidade de criar e manter vantagens tecnológicas sobre o adversário determinaria o vencedor do conflito.

A idéia de conectar esses centros, objetivando a troca de informações, começou a ser desenvolvida. Porém, foi atribuído um fator determinante na escolha da tecnologia de rede que viria a viabilizar a conexão dos centros estratégicos: a informação deveria continuar a fluir, mesmo sob as piores condições, tal como um ataque nuclear.

Foi delegada à ARPA ( Advanced Research Projects Agency ) e ao DoD ( Department of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para DARPA ( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do INWG ( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP ( Internet Protocol ) e o TCP ( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Números

Para entender a importância da Internet em todos os sentidos : sociais, políticos e financeiros, é preciso ver quem navega pela Internet. Vamos nos basear nas pesquisas de John Quarterman, um provedor de acesso, consultor e publisher de Austin, Texas, que pesquisa a composição da população da Internet na sua Internet Demographic Survey.

Uma das coisas que Quarterman tem feito é definir várias Internets de acordo com os tipos de aplicações que rodam nos servidores e as atividades dos usuários. O “núcleo da Internet” é constituído por computadores que oferecem serviços interativos como FTP, Telnet ou aplicações WWW. A “Internet de consumo” inclui pessoas que usam os serviços interativos oferecidos pelo núcleo - por exemplo, usuários que navegam no World Wide Web. O total do ciberespaço, que rotula como a “matriz”, são todos os usuários que trocam e-mail com outros usuários. Essas categorias se encaixam uma na outra: a matriz inclui a Internet de consumo, que inclui a Internet Núcleo.

Um dos problemas que Quarterman tem que enfrentar envolve hosts virtuais. Um provedor de acesso à Internet tem que registrar os nomes de domínio para os usuários, mas os endereços, na verdade, residem nas máquinas do provedor. Isso pode levar a equívocos, fazendo parecer que as pessoas têm máquinas conectadas à Internet. Esse grupo pertence à categoria de Internet de consumo, e todo o correio que Quarterman envia para os postmasters em vários endereços é no final englobado por um host.

“O problema dos hosts virtuais cresceu enormemente no ano passado ( 1995 )”, disse Quarterman. “Você pode acessar um site Web, realmente existe informação lá, e realmente corresponde à organização. Está de fato em um computador na Internet, mas pode ser o mesmo computador de outros domínios.”

A pesquisa mais recente, para 1995, foi publicada em janeiro de 1996. Do universo de 45.091 domínios, 2,9% ( 1.293 ) responderam. No mundo da estatística, mais de 1.000 respostas é um número grande de dados e essas respostas representam organizações inteiras, e não usuários apenas. Nessa pesquisa, Quarterman estima que havia 16,9 milhões de usuários da Internet nuclear ( mais do que o dobro do ano passado ) e 26,4 milhões de usuários da Internet de consumo ( novamente o dobro ); 39 milhões de usuários ( um aumento de 50% ) já dispunham de e-mail. Quarterman atribui o aumento aos usuários de Internet nas redes de consumo ( America Online, Compuserve, Prodigy, e outras ).

Na pesquisa de 1995, Quarterman contou 45 mil máquinas conectadas à Internet. O número real de domínios registrados excedeu este número porque nem todos os domínios registrados são usados e alguns são domínios em outras redes, como a UUCP, onde você pode enviar correio, mas não pode usar serviços Internet interativos.

O Web é quente, mas o FTP ainda supera a navegação. Quarterman também percebe que o uso do sistema operacional Windows está caindo e que os Macintoshes ( apesar do uso do Internet Protocol e não do MacOS ) e as máquinas Unix estão aumentando sua fatia no controle de domínios.

Os resultados são anunciados e veiculados no site Web da MIDS ( que publica as revistas mensais Matrix News e Matrix Maps Quarterly, ambas em papel e on-line, e vende mapas e outras informações sobre hosts Internet, sobre usuários e outros dados demográficos ). “O que disponibilizamos aos que responderam aos questionários, e à Internet como um todo há quase um mês, é um resultado das respostas para cada questão. Também conseguimos traçar níveis de detalhes entre as respostas individuais ( que nunca são reveladas ) e os resumos. É com isso que conseguimos alguma renda”.

Falando sobre o Brasil, o secretário de Política de Informática e Automação do Ministério da Ciência e Tecnologia, Ivan Moura Campos, diz que o Brasil ostenta um dos crescimentos mais espantosos rumo ao cyberspace - estamos crescendo 50% ao mês. Com isso chegamos à uma população de 260 mil cibernautas no início do mês de maio deste ano. Para se ter uma idéia, se a taxa de adesão continuasse nessa velocidade, até o final do ano o número de cibernautas brasileiros seria de 16 milhões. Mas as previsões do Secretário, mais realistas, estimam um milhão de usuários na virada do ano.

Publicidade

Depois da revolução dos microcomputadores na década de 80 e da disseminação da informática com “um micro em cada mesa e em cada casa”, tivemos uma das maiores evoluções já vistas na história onde a humanidade evoluiu em 10 anos o que não conseguiu evoluir desde a Idade Média, entrando na Era da Informação.

Com os microcomputadores e a Internet as fronteiras físicas foram apagadas, num lugar onde “países” e “oceanos” não têm mais significado e onde as distâncias físicas não fazem mais sentido. A virtualização evoluiu a tal ponto que uma pessoa que mora num país como o Brasil já pode conhecer e fazer amizade com pessoas de qualquer parte do mundo, como da Austrália, por exemplo. Ferramentas como o CoolTalk da Netscape Inc. que substitui o telefone ou o TimedVideo Grabber que possibilita a transmissão de imagens em real-time com o uso de câmera, tornam possível pessoas se conhecerem sem nunca precisarem realmente se encontrarem em “carne-e-osso”.

E falando em evolução, depois de 500 anos de reinado absoluto das mídias impressas como difusor de informação, esta está sendo rapidamente substituída por publicações digitais na World Wide Web, a parte da Internet que mais chama a atenção atualmente.

Com trabalhos pioneiros como a Enciclopédia Britannica, que foi absolutamente abalada depois que as enciclopédias impressas caíram em total desuso depois do surgimento das enciclopédias digitais como a Encarta da Microsoft, e também de serviços de procura do tipo “páginas amarelas” como as oferecidas por sites como o Yahoo! ou Lycos, tornaram a Internet também o maior repositório de dados já feito, o melhor lugar para pesquisas que se pode encontrar.

Revistas mundialmente famosas como a PC Magazine da Ziff Davis Publishing ou a Playboy já têm suas publicações exibidas e atualizadas periodicamente na WWW.

A World Wide Web ou WWW foi concebida para dar uma “cara” à Internet, possibilitando a edição de sites gráficos ao contrário da até então interface baseada em texto ( algo semelhante à passagem do DOS para o Windows, por exemplo ). Uma nova linguagem de script foi criada, a HTML ( Hyper Text Mark-Up Language ) e um protocolo específico, a HTTP ( Hyper Text Transfer Protocol ). E para a navegação por essas pages foram criados os browsers, programas feitos para interpretar o HTML. Logo de início, duas se sobressaíram, a Netscape com seu Netscape Navigator e a SpyGlass com seu Mosaic. A Netscape se tornou mais difundida e a SpyGlass vendeu os direitos do Mosaic para a Microsoft que hoje distribui o maior concorrente da Netscape, o Internet Explorer, numa das maiores campanhas de distribuição de softwares já vistas.

A possibilidade de se editar praticamente tudo que existe em mídias impressas, rapidamente chamou a atenção do mundo para a Internet. Novos conceitos começaram a surgir como o de publishing on-line. Um dos exemplos mais recentes é sobre as Olimpíadas de Atlanta onde o trabalho de informática ficou a cargo da IBM que montou um esquema grandioso de máquinas e redes e distribuição de informação via Internet que pode ser conferido na homepage das Olimpíadas, onde os dados são atualizados tão logo são obtidos, assim, ao fim de cada jogo, a homepage pode ser atualizada e o mundo todo tem acesso a elas, não precisando esperar até o dia seguinte para lê-los nos jornais.

Falando em jornais, estes também não ficam atrás, colocando na WWW, muito das suas publicações diárias como o The Gate um produto baseado em Internet de dois jornais da Costa Oeste dos Estados Unidos, o San Francisco Chronicle e o San Francisco Examiner com direito a áreas de conferência com fóruns de discussão como Comunidade, Mídia, Esportes, Filmes, etc.

A Agência Estado, que publica jornais famosos como o Estado de São Paulo, também já distribui seu jornal via internet com as principais chamadas do dia e informações diversas, incluindo seus classificados e, num período de olimpíadas, com áreas especiais para os esportes em Atlanta.

Outro conceito que se tornou famoso com a Internet é a dos serviços on-line como as gigantes Compuserve e America On-line que atendem a pessoas do mundo todo e têm aliados como Netscape e Microsoft. Esse tipo de organização é baseada em “serviços” que incluem fóruns de discussão; bibliotecas com informações atualizadas; revistas, jornais e outros periódicos; lojas virtuais que vendem desde CDs a roupas; dicas de lazer e negócios; e também serviços comuns à Internet como e-mail e WWW.

No Brasil também começou a se disseminar tais tipos de serviço, com destaque para a Folha de São Paulo e o Grupo Abril que lançaram, respectivamente, o Universo Online e o Brasil Online. Tais serviços brasileiros ainda são experimentais e de graça, sem projeções quanto a custos. A título de ilustração, o The New York Times cobra US$ 30,00 por mês e a America Online cobra US$ 9,95 por 5 horas ou US$ 19,95 por 20 horas.

Tais serviços têm faturamentos muito altos principalmente por causa da empolgação atual do mundo em torno da virtualização de serviços e pelo aluguel do espaço digital para empresas que se interessam em colocar “out-doors virtuais” ou mesmo acrescentar outros serviços como lojas digitais nas páginas principais, visto que o número de pessoas que trafegam pelas linhas digitais todos os dias é muito grande. Para ver isso basta entrar na página do Brasil Online, por exemplo, e se deparar com chamadas de publicidade de empresas como a Sun ou a Credicard. Essas chamadas são links que levam às homepages das respectivas empresas.

E falando em propaganda, alguém deve estar confeccionando tais pages e anúncios. Essas empresas estão se especializando em desenhar páginas específicas e criativas para um tipo de mídia que sai das limitações do papel e possibilita coisas como Hypertext ( palavras dentro de um texto que levam a outras páginas ), Marquees ( frases que se movimentam na linha ), músicas ( através de arquivos WAVE ou da nova tecnologia Real Audio ), animações ( via imagens GIF animadas ou então utilizando recursos da linguagem Java ) ou ainda ambientes totalmente tridimensionais ( utilizando a tecnologia VRML - Virtual Reality Markup Language ) e muito mais. Nesse filão mercadológico estão empresas como a Vivid Studio que tem como clientes as gigantes Silicon Graphics e Microsoft ou a Razorfish que desenha para a Time-Warner e a Pepsi.

Comércio

O principal ponto de atrito quando se fala em comércio digital é a segurança. O protocolo TCP/IP é o ponto de partida para a Internet, concebido como um protocolo universal mas que peca no aspecto segurança, onde, ao contrário dos seus irmãos IPX/SPX ou NetBIOS por exemplo, não possui transmissão de dados encriptados. Uma vez sendo o protocolo padrão de transmissão de dados, teria sido conveniente estipular um protocolo também padrão de segurança de dados. Uma vez que este não existe, o impasse fica em torno de empresas que brigam para desenvolver o padrão do que causaria a arrancada inicial rumo ao fim do dinheiro impresso e o desenvolvimento do crédito digital.

Um dos mais antigos é o cybercash com mais ou menos um ano de idade. Por enquanto, a empresa só trabalha com serviços de cartões de crédito, mas em breve promete oferecer serviços de pagamentos monetários. Atualmente, com um browser ligado à rede pode-se comprar com segurança em shoppings virtuais. Através do protocolo SIPS ( Secure Internet Payment Service ), segundo a empresa, é tão fácil quanto apontar e clicar. Nesse tipo de transação, compra-se quantos cybercashes quantos desejados e debita-se no cartão de crédito.

O padrão do Cybercash suporta todos os tipos de cartão de crédito. Usa os padrões de encriptação 768-bit RSA e a 56-bit DES. Todas as transações são autenticadas com as assinaturas MDS e 768-bit RSA. A primeira providência para quem se interessou é baixar o programa gratuito que a empresa oferece. O servidor da Cybercash está ligado às redes privadas de vários bancos. Os serviços iniciais da empresa incluem cartões de crédito e de débito e um sistema de pagamentos eletrônicos. Pelos serviços, os usuários pagam uma quantia módica, comparável ao valor de um selo. Para os fornecedores, o sistema representa uma economia nas taxas cobradas pelas transações de cartões de crédito, em função do risco ainda existente nas transações por telefone e e-mail.

Nesse tipo de desenvolvimento ainda encontram-se empresas como a Digicash, com os serviços centrados no site da First Digital Bank, utilizando sistema de e-cash ( dinheiro real convertido em dinheiro virtual em contas virtuais ). A Visa ( que também já é parceira da Sony - no desenvolvimento de um ambiente multifacetado de entretenimento, informações e transações comerciais ) e a Microsoft possuem o STT ( Secure Transaction Technology ), o padrão dessas duas poderosas quer se tornar uma versão eletrônica do cartão de crédito. A Mastercard está em parceria com a IBM, Netscape, GTE e Cybercash, com o padrão SEPP ( Secure Eletronic Payment Protocol ). Trata-se de um protocolo aberto para transações on-line seguras.

A Netscape desenvolve o protocolo aberto de segurança SSL ( Secure Sockets Layer ) e contribui no desenvolvimento da interface SSL do W3C ( World Wide Web Consortium ), consórcio europeu que se dedica a criar um padrão para o Mercado Comum Europeu. Desse consórcio fazem parte cerca de 50 companhias de todo o mundo. A empresa irá licenciar a tecnologia SSL a seus parceiros para uso comercial. A lista de parceiros inclui MCI, Bank of America, Mastercard, First Data Corporation, Novell, Digital e Silicon Graphics.

Praticamente todas as empresas do setor financeiro vêm investindo muito no desenvolvimento de uma plataforma segura e confiável suficiente para transações financeiras de todos os níveis de importância. Hackers à parte, os negócios via Internet não diferem muito dos efetuados fora dela. Ou seja, a melhor forma de estar livre de problemas é confiar na credibilidade das empresas sérias. Dificilmente alguém vai querer comprometer seu bom nome deixando de entregar a mercadoria no prazo ou “negociando” o número do cartão de crédito.

No Brasil, o Mappin foi a primeira grande empresa a entrar no ramo das vendas por computador. Também é possível escolher doces e tortas na Confeitaria Brunella de São Paulo ou fazer reservas ao Marcellu’s Bar do Rio de Janeiro. O consumidor escolhe o doce ou torta que quer comprar através das fotos e descrições na homepage da Brunella, depois a loja telefona para confirmar o pedido e encaminha a mercadoria. No caso do Marcellu’s Bar, a reserva é feita por e-mail.

Se há alguém de mudança para os Estados Unidos ou precisando simplesmente comprar preços, poderá consultar o For Sail By Owner Connection. Trata-se de um site especializado em vendas de casas, com fotos e especificações. Se na verdade você precisa vender a sua casa, também poderá anunciar nesta page.

Pensando em viagens, a Cruisin é a primeira agência de turismo especializada em cruzeiros que atende exclusivamente pela Internet. Mas já existem muitos hotéis e agências na rede. Realmente há alternativas para todos os limites bancários: de castanhas do Ceará por menos de R$ 3,00 até uma casa na Flórida por US$ 329 mil. Hoje em dia é virtualmente possível se comprar de tudo na Internet.

Afterwords

Criado para fins militares, depois expandido para os meios acadêmicos e, finalmente, atingindo o público em geral, a Internet caminha em evolução acelerada cobrindo praticamente todos os setores da sociedade onde se constrói as bases do que pode ser considerado um mundo virtual.

Quando a Internet evoluir o suficiente, as novas tecnologias irão construir a esperada Information Super Highway onde, aí sim, se constituirá uma rede verdadeiramente mundial, utilizando-se não somente os computadores da forma como os conhecemos mas também qualquer equipamento eletrônico, como os set-top-boxes ( os substitutos dos video-cassetes e video-lasers ).

Nessa próxima geração, “passear” será vestir uma roupa de realidade virtual e visitar locais virtuais com amigos de outros continentes num encontro digital. E isso não se trata de delírios de ficção científica: tanto estamos perto disso que tais tecnologias são reais e já existem, tudo que resta é o tempo para torná-las acessíveis e operacionais a nível de distribuição em massa.

O tema é Binary Radix Trie. Segue a tradução:

1

Um pouco de remédio de ciências da computação para os auditores PCIs na minha audiência.

Eu lhe dou um array com números inteiros aleatórios. Como você pode me dizer se o número 3 está nele?

Bem, aqui vai a maneira óbvia: cheque os números sequencialmente até encontrar o “3” ou terminar o array. Procura Linear. Dados 10 números, você precisa assumir que isso pode levar 10 passos; N números, N passos.

Procura linear é ruim. É difícil fazer pior do que linear. Vamos melhorar isso. Ordene o array.

Um array ordenado sugere uma estratégia diferente: pule direto para o meio do array e veja se o valor que está procurando é menor (à esquerda) ou maior (à direita). Repita, cortando o array no meio a cada vez, até encontrar o número.

Procura Binária. Dados 10 números, levará não mais do que 3 passos – log 10 (base 2) – para encontrar um deles num array ordenado. Procuras O(log n) são incríveis. Se tiver 65 mil elementos, levará somente 16 passos para encontrar. Dobre o número de elementos, e levará apenas 17 passos.

Mas arrays ordenados são uma porcaria; ordená-los custa mais caro do que procura binária. Então nós não usamos muito procura binária; em vez disso, usamos árvores binárias.

Para procurar numa árvore binária, você começa pelo topo, e se pergunta “minha chave é menor (esquerda) ou maior (direita) do que o nó atual” e repete até ok, ok, ok você já sabe. Mas essa árvore é bonita, não é?

Procura com uma árvore binária (balanceada) é O(log n), como procura binária, variando com o número de elementos na árvore. Árvores Binárias são incríveis: você consegue navega rapidamente de maneira ordenada, uma coisa que não se consegue de uma tabela Hash. Árvores Binárias são uma implementação default para tabelas melhor do que tabelas Hash.

2

Mas Árvored Binárias não é o único mecanismo de procura em estrutura de árvore. ‘Binary Radix Tries’, também chamados árvores PATRICIA, trabalham como árvores binárias com uma diferença fundamental. Em vez de comparar maior/menor em cada nó, você checa para ver se um bit está configurado, indo para a direita se estiver, ou para a esquerda se não estiver.

Estou deixando fora muita coisa sobre como binary radix tries trabalham. É uma vergonha, porque radix tries são notoriamente mal documentadas – Sedgewick os destruiu em “Algorithms”, e a página na Wikipedia também é uma droga. As pessoas ainda argumentam sobre como chamá-los! Em vez de uma explicação de backlinks e cantos etiquetados com posição de bits, aqui vai uma pequena implementação em Ruby

Eis porque radix tries são legais:

• A performance de procura varia com o tamanho da chave, não o número de elementos na árvore. Com chaves de 16-bits, você garantidamente tem 16 passos independente do número de elementos na árvore, sem balanceamento.

• Mais importante, radix tries lhe dá igualdade lexicográfica, que é uma maneira de dizer “procura com wildcards” ou “procura parecida com auto-complete de linha de comando”. Em um radix tree, você pode rapidamente procurar por “ro*” e conseguir “rome” e “romulous” e “roswell”.

3

Eu o perdi.

Vamos colocar isso em contexto. Tries são uma estrutura de dados crucial para roteamento de Internet. O problema de roteamento é mais ou menos assim:

• Você tem uma tabela de roteamento com entradas para “10.0.1.20/32 → a” e “10.0.0.0/16 → b”

• Você precisa que pacotes para 10.0.1.20 vão para “a”

• Você precisa que pacotes para 10.0.1.21 vão para “b”

Esse é um problema difícil de resolver com uma árvore binária básica, mas com uma radix trie, você está apenas perguntando por “1010.0000.0000.0000.0000.0001.0100” (para 10.0.1.20) e “1010”. (para 10.0.0.0). Procura Lexicográfica lhe dá o “melhor acerto” para roteamento. Você pode tentar no código Ruby acima; adicione *“10.0.0.0”.to_ip na trie, e procure por “10.0.0.1”.to_ip.

A correspondência entre roteamento e radix tries é tão forte que a mais popular biblioteca de uso geral de radix trie (aquele da CPAN) é na realidade roubado da GateD. É uma bagunça, aliás, não use isso.

Se você entende como um trie funciona, você entende como regular expressions trabalham. Tries são um caso especial de autômato finito determinístico (DFAs), onde galhos são baseados exclusivamente em comparações de bits e sempre se divide para frente. Um bom engine de regex apenas manipula DFAs com mais “funcionalidades”. Se minha figura faz sentido para você, as imagens nesse excelente artigo sobre o algoritmo de redução NFA-DFA de Thompson também vai, e esse artigo o fará mais esperto.

4

Você é um operador de rede no backbone de um provedor. Seu mundo consiste em boa parte de “prefixos” – pares de IPs de rede/netmasks. Os netmasks nesses prefixos são muito importantes para você. Por exemplo, 121/8 pertence à Coréia; 121.128/10 pertence à Korea Telecom, 121.128.10/24 pertence à um cliente da KT, e 121.128.10.53 é um computador desse cliente. Se estive rastreando um botnet ou uma operação de spam or propagação de worm, o número de netmask é bem importante para você.

Infelizmente, mesmo sendo importantes, em nenhum lugar no pacote IP está estampado um “netmask” – netmasks são completamente um detalhe de configuração. Então, quando você está olhando tráfego, você essencialmente tem esss dados para trabalhar:

Surpreendentemente, dados pacotes o suficiente para olhar, isso é informação suficiente para adivinhar netmasks. Quando trabalhava na Sony, Kenjiro Cho veio com uma maneira realmente elegante para isso, baseado em tries. Eis como:

Pegue uma binary radix trie básica, como os usados por roteadores em software. Mas fixe o número de nós na árvore, digamos, 10 mil. Em um link de backbone, gravando endereços de cabeçalhos de IP, você vai encher 10 mil nós em um instante.

Armazene a lista de nós em uma lista, ordenada em ordem LRU. Em outras palavras, quando bater um endereço IP com um nó, “toque” o nó, colocando-o no topo da lista. Gradualmente, frequentemente vendo endereços borbulhando para o topo, e infrequentemente vendo nós afundando para baixo.

Agora o truque. Quando acabarem os nós e precisar de uma nova, reclame de baixo da lista. Mas quando fizer isso, role os dados do nó para cima passando pelo seu pai, desta maneira:

10.0.1.2 e 10.0.1.3 são irmãos /32s, as duas metades de 10.0.1.2/31. Para reclamá-los, misture-os em 10.0.1.2/31. Se precisar reclamar 10.0.1.2/31, você pode misturá-la com 10.0.1.0/31 para formar 10.0.1.0/30.

Faça isso por, digamos, um minuto, e as fontes mais fortes vão defender suas posições na árvore ficando no topo da lista LRU, enquanto barulhos ambientes /32 borbulham para /0. Para a lista crua de IP’s acima, com 100 nós, você tem isso

Cho chama essa heurística de Aguri.

5

Aguri tem licença BSD. Você pode fazer download dele e um programa driver que observa pacotes via pcap, da antiga homepage de Cho.

6

Eu vou a algum lugar com isso, mas estou com mais de 1.300 palavras nesse post agora, e se você for uma pessoa de algoritmos, já deve estar cansado de mim agora, e se não for, já deve estar cansado de mim agora. Então, deixe o Aguri afundar, e eu lhe darei alguma coisa legal e inútil para fazer com isso na semana que vem.