As Arquiteturas de Aplicação Cliente-Servidor e P2P

• Definir a arquitetura de aplicação cliente-servidor e identificar as suas duas propriedades definidoras: um servidor sempre ligado, e clientes que não se comunicam diretamente entre si.
• Definir a arquitetura de aplicação peer-to-peer (P2P) e identificar a sua propriedade definidora: a autoescalabilidade, em que cada novo par acrescenta tanto demanda quanto capacidade.
• Comparar as duas arquiteturas quanto ao custo de infraestrutura de servidores, à facilidade de gerenciamento e ao comportamento de escalabilidade conforme o número de participantes cresce.
• Identificar uma arquitetura híbrida que toma emprestadas propriedades das duas, e explicar o que ela de fato está resolvendo.
• Dada a descrição de uma aplicação real, classificar a sua arquitetura e justificar a classificação.

Todo protocolo da camada de aplicação que esta disciplina cobre (HTTP, DNS e além) precisa responder uma pergunta estrutural antes que qualquer detalhe de protocolo importe: quem inicia a comunicação, e quem é alcançável por quem? As arquiteturas cliente-servidor e peer-to-peer são as duas respostas reais dominantes, e a escolha entre elas molda quase tudo o que vem depois: quanta infraestrutura uma aplicação precisa, como ela escala conforme a sua base de usuários cresce, e até quais garantias da camada de transporte acabam importando mais. Este conceito desenvolve as duas arquiteturas nos seus próprios termos, como uma fundação para o HTTP (um protocolo cliente-servidor, coberto a seguir) e como contexto para entender por que algumas aplicações (mais famosamente o compartilhamento de arquivos peer-to-peer e as redes blockchain) são construídas de forma inteiramente diferente.

A arquitetura cliente-servidor

Na arquitetura cliente-servidor, existe um host sempre ligado, o servidor, que atende requisições de muitos outros hosts, chamados clientes. O servidor tem um endereço fixo e bem conhecido, para que os clientes sempre consigam encontrá-lo. Os clientes não se comunicam diretamente entre si; toda a comunicação passa pelo servidor. Um único servidor (ou, de forma mais realista em escala, um data center cheio de servidores por trás de um único serviço logicamente unificado) precisa, portanto, ser provisionado para tratar a carga agregada de todo cliente que possa se conectar, e é precisamente por isso que serviços com milhões de usuários investem pesadamente em data centers e em infraestrutura de distribuição de conteúdo.

A arquitetura peer-to-peer (P2P)

Na arquitetura P2P, há dependência mínima ou nenhuma de servidores de infraestrutura sempre ligados. Em vez disso, sistemas finais arbitrários, chamados pares (peers), se comunicam diretamente entre si. Os pares se conectam de forma intermitente (entrando e saindo da rede conforme os seus donos ligam e desligam os dispositivos), e cada par pode atuar tanto como cliente (pedindo algo) quanto como servidor (fornecendo algo a outros pares) em momentos diferentes. A propriedade definidora de um sistema P2P bem projetado é a autoescalabilidade: cada novo par que entra na rede traz a sua própria capacidade (a sua própria largura de banda de upload, o seu próprio armazenamento) além da sua própria demanda, de modo que a capacidade total de serviço do sistema cresce aproximadamente em proporção à sua base de usuários, em vez de ficar fixa enquanto a demanda cresce sem limite contra ela.

Comparando as duas quanto à escalabilidade

A capacidade de um sistema cliente-servidor é fixada por quanta infraestrutura de servidores o seu operador provisionou; fazer a base de usuários crescer significa que o operador precisa acrescentar proativamente mais servidores, a um custo real, para acompanhar. A capacidade de um sistema P2P bem projetado cresce automaticamente conforme novos pares entram, já que cada um contribui com recursos além de consumi-los. Esta é a razão estrutural pela qual a distribuição de arquivos peer-to-peer consegue, em princípio, atender um número arbitrariamente grande de pessoas baixando simultaneamente o mesmo arquivo popular sem que a largura de banda de upload de nenhum nó isolado se torne um gargalo, algo com que um projeto cliente-servidor ingênuo teria dificuldade sem proporcionalmente mais capacidade de servidor.

Os custos reais do P2P

A autoescalabilidade não é de graça. Sistemas P2P são significativamente mais difíceis de gerenciar e de proteger que sistemas cliente-servidor: não há um ponto central de controle para impor uma política de acesso, aplicar uma atualização de software de forma uniforme ou garantir a disponibilidade de qualquer conteúdo específico (um par que guarda a única cópia de algum dado pode simplesmente se desconectar, levando esse dado para fora do ar junto com ele, de uma forma que um servidor bem provisionado geralmente não faz). A centralização do cliente-servidor, embora seja um gargalo de escalabilidade, é também o que torna diretos o gerenciamento centralizado, o controle de acesso consistente e a disponibilidade garantida de conteúdo.

Arquiteturas híbridas

Muitos sistemas reais não são nem puramente cliente-servidor nem puramente P2P. Sistemas de mensagens instantâneas, por exemplo, historicamente usaram uma arquitetura cliente-servidor para descobrir quais dos contatos de um usuário estão online no momento (um trabalho que genuinamente se beneficia de um diretório centralizado e sempre alcançável), enquanto as mensagens de fato, uma vez que dois usuários estão conectados, podiam fluir diretamente entre eles, peer-to-peer. Este padrão híbrido (centralizar o que se beneficia da centralização, como descoberta e coordenação, e descentralizar o que se beneficia da descentralização, como a transferência de dados em massa) se repete em muitos projetos de aplicações reais, e reconhecê-lo é mais útil do que tentar forçar todo sistema real numa classificação puramente de um tipo ou de outro.

Exemplo 1: Classificando três aplicações reais

text
Aplicação                  Arquitetura       Por quê
-------------------------  ----------------  ------------------------------
Um site típico de          Cliente-servidor  Servidores sempre ligados guardam
e-commerce                                    o catálogo e processam pedidos;
                                              os clientes nunca falam entre si
                                              diretamente pela infraestrutura
                                              do próprio site.

Um sistema de compar-      P2P               Os pares trocam pedaços de um
tilhamento de arquivos                        arquivo diretamente entre si;
no estilo BitTorrent                          nenhum servidor sempre ligado é
                                              necessário para guardar o próprio
                                              arquivo (um tracker leve ou uma
                                              DHT ajuda os pares a se acharem,
                                              um papel de coordenação).

Uma rede blockchain /      P2P               Nenhum servidor central guarda "o"
de criptomoeda                                livro-razão; todo nó completo o
                                              armazena e valida, e os nós se
                                              comunicam diretamente.

Exemplo 2: A capacidade de servidor em função da contagem de usuários

Um serviço de streaming de vídeo cliente-servidor suporta atualmente 1 milhão de espectadores simultâneos com uma quantidade fixa de infraestrutura de servidores e de rede. Se a base de usuários dobrar para 2 milhões de espectadores simultâneos, o operador precisa, num projeto cliente-servidor puro, aproximadamente dobrar a capacidade de servidores e de largura de banda de saída para manter a mesma qualidade de serviço por espectador: a capacidade não cresce sozinha com a demanda. Contraste isso com um projeto hipotético de streaming ao vivo P2P, em que cada novo espectador também recompartilha a transmissão com um punhado de outros espectadores, de modo que a capacidade total de upload disponível ao sistema cresce automaticamente junto com a contagem crescente de espectadores: a diferença qualitativa de comportamento de escalabilidade que as duas arquiteturas produzem.

Exemplo 3: Um projeto híbrido, raciocinado a partir de princípios básicos

Projete do zero uma aplicação de compartilhamento de arquivos. Dois subproblemas precisam ser resolvidos: (1) como um par procurando um arquivo descobre quais outros pares o têm no momento, e (2) como os dados de fato do arquivo são transferidos uma vez que os pares são encontrados? O subproblema (1) se beneficia da centralização: um único índice, sempre alcançável, é simples de manter consistente e de consultar rapidamente. O subproblema (2) se beneficia da descentralização: se o arquivo for popular, espalhar o fardo de upload por muitos pares (cada um dos quais já tem, ou está baixando, pedaços do arquivo) evita que qualquer host isolado se torne um gargalo de upload. O projeto natural, alcançado raciocinando sobre cada subproblema pelos seus próprios méritos em vez de escolher uma arquitetura e forçar os dois problemas nela, é exatamente o padrão híbrido que sistemas reais como o BitTorrent (com o seu tracker ou tabela hash distribuída para a descoberta) de fato usam.

• "P2P significa que nunca há servidor algum envolvido." Muitos sistemas P2P reais usam um componente leve e centralizado (ou semicentralizado) para descoberta ou coordenação (um tracker, um nó de bootstrap, um serviço de diretório), mantendo peer-to-peer a transferência de dados em massa de fato. A pureza é rara; projetos híbridos são comuns e frequentemente a escolha de engenharia certa.
• "Cliente-servidor não escala." Escala, acrescentando proporcionalmente mais infraestrutura de servidores conforme a demanda cresce, a um custo operacional real e contínuo. Não é que o cliente-servidor falhe em escalar; é que a sua escalabilidade exige um provisionamento ativo e caro, em vez de acontecer automaticamente, como a autoescalabilidade do P2P pode fornecer.
• "O P2P é inerentemente mais seguro ou mais resistente a falhas." A ausência de um ponto único central de falha não significa automaticamente alta disponibilidade de qualquer conteúdo específico: um sistema P2P pode perder com a mesma facilidade o acesso a dados se os pares que os guardam se desconectarem, e a falta de controle central do P2P genuinamente complica o controle de acesso e a imposição consistente de políticas de formas que o cliente-servidor não precisa resolver.
• "Toda aplicação moderna é claramente de um tipo ou de outro." Muitos sistemas reais são híbridos, centralizando as partes do seu projeto (tipicamente descoberta ou coordenação) que genuinamente se beneficiam de uma fonte única da verdade, e descentralizando as partes (tipicamente a transferência de dados em massa) que se beneficiam de capacidade distribuída.

A arquitetura cliente-servidor depende de um servidor sempre ligado pelo qual todos os clientes se conectam, com capacidade fixada por quanta infraestrutura é provisionada e com os clientes nunca falando diretamente entre si; ela é simples de gerenciar e proteger, mas exige uma escalabilidade proativa e cara conforme a demanda cresce. A arquitetura peer-to-peer tem pares se comunicando diretamente, cada um contribuindo com capacidade além de consumi-la, dando a sistemas P2P bem projetados uma propriedade genuína de autoescalabilidade, mas a um custo real em gerenciabilidade, segurança e garantias de disponibilidade de conteúdo, já que não há um ponto único de controle centralizado. Muitas aplicações reais são híbridas, centralizando a descoberta/coordenação enquanto descentralizam a transferência de dados em massa. Esta escolha arquitetural é o pano de fundo estrutural sobre o qual o próximo conceito, o HTTP, é construído: o HTTP é um protocolo totalmente cliente-servidor, e entender por que essa arquitetura foi a escolha natural para a Web exige exatamente o raciocínio desenvolvido aqui.