PrincíPios de aPlicações de rede

Suponha que você tenha uma grande ideia para uma nova aplicação de rede. Essa aplicação será, talvez, um grande serviço para a humanidade, ou agradará a seu professor, ou fará de você uma pessoa rica; ou apenas será divertido desenvolvê-la. Seja qual for sua motivação, vamos examinar agora como transformar a ideia em uma aplicação do mundo real.

O núcleo do desenvolvimento de aplicação de rede é escrever programas que rodem em sistemas finais diferentes e se comuniquem entre si. Por exemplo, na aplicação Web há dois programas distintos que se comuni- cam um com o outro: o do navegador, que roda no hospedeiro do usuário (computador de mesa, laptop, tablet, smartphone e assim por diante); e o do servidor Web, que roda na máquina deste. Outro exemplo é um sistema de compartilhamento de arquivos P2P no qual há um programa em cada máquina que participa da comunidade de compartilhamento de arquivos. Nesse caso, os programas de cada máquina podem ser semelhantes ou idênticos.

Portanto, ao desenvolver sua nova aplicação, você precisará escrever um software que rode em vários sistemas finais. Esse software poderia ser criado, por exemplo, em C, Java ou Python. Importante: você não precisará escrever programas que executem nos elementos do núcleo de rede, como roteadores e comuta- dores. Mesmo se quisesse, não poderia desenvolver programas para esses elementos. Como aprendemos no Capítulo 1 e mostramos na Figura 1.24, equipamentos de núcleo de rede não funcionam na camada de aplicação, mas em camadas mais baixas, em especial na de rede e abaixo dela. Esse projeto básico — a saber, confinar o software de aplicação nos sistemas finais —, como mostra a Figura 2.1, facilitou o desenvolvi- mento e a proliferação rápidos de uma vasta gama de aplicações de rede.

2.1.1 arquiteturas de aplicação de rede

Antes de mergulhar na codificação do software, você deverá elaborar um plano geral para a arquitetura da sua aplicação. Tenha sempre em mente que a arquitetura de uma aplicação é bastante diferente da arquitetura da rede (por exemplo, a arquitetura em cinco camadas da Internet que discutimos no Capítulo 1). Do ponto de vista do profissional que desenvolve a aplicação, a arquitetura de rede é fixa e provê um conjunto específico de serviços. Por outro lado, a arquitetura da aplicação é projetada pelo programador e determina como a aplicação é orga- nizada nos vários sistemas finais. Ao escolher a arquitetura da aplicação, é provável que o programador aproveite uma das duas arquiteturas mais utilizadas em aplicações modernas de rede: cliente-servidor ou P2P.

Em uma arquitetura cliente-servidor há um hospedeiro sempre em funcionamento, denominado servidor, que atende a requisições de muitos outros hospedeiros, denominados clientes. Um exemplo clássico é a aplicação Web na qual um servidor Web que está sempre em funcionamento atende a solicitações de navegadores de hos- pedeiros clientes. Quando recebe uma requisição de um objeto de um hospedeiro cliente, um servidor Web res- ponde enviando o objeto solicitado. Observe que, na arquitetura cliente-servidor, os clientes não se comunicam diretamente uns com os outros; por exemplo, na aplicação Web, dois navegadores não se comunicam de modo direto. Outra característica dessa arquitetura é que o servidor tem um endereço fixo, bem conhecido, denomi- nado endereço IP (que discutiremos em breve). Por causa dessa característica do servidor e pelo fato de ele estar sempre em funcionamento, um cliente sempre pode contatá-lo, enviando um pacote ao endereço do servidor. Algumas das aplicações mais conhecidas que empregam a arquitetura cliente-servidor são Web, FTP, Telnet e e-mail. Essa arquitetura é mostrada na Figura 2.2(a).

Em aplicações cliente-servidor, muitas vezes acontece de um único hospedeiro servidor ser incapaz de atender a todas as requisições de seus clientes. Por exemplo, um site popular de redes sociais pode ficar logo sa- turado se tiver apenas um servidor para atender a todas as solicitações. Por essa razão, um datacenter, acomo- dando um grande número de hospedeiros, é usado com frequência para criar um servidor virtual poderoso. Os serviços de Internet mais populares — como mecanismos de busca (por exemplo, Google e Bing), comércio via Internet (por exemplo, Amazon e eBay), e-mail baseado na Web (por exemplo, Gmail e Yahoo Mail), rede social (por exemplo, Facebook e Twitter) — empregam um ou mais centros de dados. Conforme discutimos

na Seção 1.3.3, o Google tem de 30 a 50 datacenters distribuídos no mundo inteiro, que em conjunto tratam de busca, YouTube, Gmail e outros serviços. Um datacenter pode ter centenas de milhares de servidores, que precisam ser alimentados e mantidos. Além disso, os provedores de serviços têm de pagar pelos custos de in- terconexão recorrente e largura de banda para o envio de dados a partir de seus datacenters.

Em uma arquitetura P2P, há uma confiança mínima (ou nenhuma) nos servidores dedicados nos cen- tros de dados. Em vez disso, a aplicação utiliza a comunicação direta entre duplas de hospedeiros conectados alternadamente, denominados pares. Eles não são de propriedade dos provedores de serviço, mas são contro- lados por usuários de computadores de mesa e laptops, cuja maioria se aloja em residências, universidades e escritórios. Como os pares se comunicam sem passar por nenhum servidor dedicado, a arquitetura é deno- minada par a par (peer-to-peer — P2P). Muitas das aplicações de hoje mais populares e de intenso tráfego são

Rede móvel Transporte Rede Enlace Física Aplicação KR 02.01.eps AW/Kurose and Ross

Computer Networking, 6/e

size: 33p6 x 39p0 9/6/11, 10/28/11, 10/31/11 11/21/11 rossi ISP nacional ou global ISP local ou regional Enterprise Network Rede doméstica Transporte Rede Enlace Aplicação Física Transporte Rede Enlace Física Aplicação

figura 2.1 a comunicação de uma aPlicação de rede ocorre entre sistemas finais na camada

baseadas nas arquiteturas P2P, incluindo compartilhamento de arquivos (por exemplo, BitTorrent), aceleração de download assistida por par (por exemplo, Xunlei), telefonia por Internet (por exemplo, Skype) e IPTV (por exemplo, KanKan e PPstream). Essa arquitetura está ilustrada na Figura 2.2(b). Mencionamos que algumas aplicações possuem arquiteturas híbridas, combinando elementos cliente-servidor e P2P. Para muitas apli- cações de mensagem instantânea, os servidores costumam rastrear o endereço IP dos usuários, mas as men- sagens entre usuários são enviadas diretamente entre os hospedeiros do usuário (sem passar por servidores intermediários).

Uma das características mais fortes da arquitetura P2P é sua autoescalabilidade. Por exemplo, em uma aplicação de compartilhamento de arquivos P2P, embora cada par gere uma carga de trabalho solicitando ar- quivos, também acrescenta capacidade de serviço ao sistema distribuindo arquivos a outros pares. As arquite- turas P2P também possuem uma boa relação custo-benefício, visto que em geral não requerem infraestrutura e largura de banda de servidor significativas (ao contrário de projetos cliente-servidor com centros de dados). Entretanto, as futuras aplicações P2P estão diante de três principais desafios:

1. ISP Amigável. A maioria dos ISPs residenciais (incluindo o DSL e os ISPs a cabo) foi dimensionada para uso de largura de banda “assimétrica”, ou seja, para muito mais tráfego de entrada do que de saída. Mas a transmissão de vídeo P2P e as aplicações de distribuição de vídeo transferem o tráfego de saída dos ser- vidores para ISPs residenciais, colocando, assim, uma pressão significativa nos ISPs. As futuras aplicações P2P precisam ser criadas para que sejam amigáveis aos ISPs [Xie, 2008].

2. Segurança. Em razão de sua natureza altamente distribuída e exposta, as aplicações P2P podem ser um de- safio para proteger [Doucer, 2002; Yu, 2006; Liang, 2006; Naoumov, 2006; Dhungel, 2008; LeBlond 2011]. 3. Incentivos. O sucesso das futuras aplicações P2P também depende de usuários participativos para ofere- cer largura de banda, armazenamento e recursos da computação às aplicações, um projeto desafiador de incentivo [Feldman, 2005; Piatek, 2008; Aperjis, 2008; Liu, 2010].

a. Arquitetura cliente-servidor b. Arquitetura P2P

2.1.2 comunicação entre processos

Antes de construir sua aplicação de rede, você também precisará ter um entendimento básico de como pro- gramas que rodam em vários sistemas finais comunicam-se entre si. No jargão de sistemas operacionais, na verdade não são programas, mas processos que se comunicam. Um processo pode ser imaginado como um programa que está rodando dentro de um sistema final. Quando os processos rodam no mesmo sistema final, comunicam-se usando comunicação interprocessos, cujas regras são determinadas pelo sistema operacional do sistema final. Po- rém, neste livro, não estamos interessados na comunicação entre processos do mesmo hospedeiro, mas em como se comunicam os que rodam em sistemas finais diferentes (com sistemas operacionais potencialmente diferentes).

Os processos em dois sistemas finais diferentes se comunicam trocando mensagens por meio da rede de computadores. Um processo originador cria e envia mensagens para a rede; um processo destinatário recebe-as e responde, devolvendo outras. A Figura 2.1 mostra que processos se comunicam usando a camada de aplicação da pilha de cinco camadas da arquitetura.