Douglas E.

Comer

Redes de
Computadores
e Internet
6ª EDIÇÃO
O autor
Dr. Douglas Comer é um internacionalmente reconhecido especialista em redes de com-
putadores, protocolos TCP/IP e Internet. Foi um dos pesquisadores que contribuíram
com a formação da Internet no fim dos anos 1970 e nos anos 1980, sendo membro do In-
ternet Architecture Board, o grupo responsável por guiar o desenvolvimento da Internet.
Também foi presidente do comitê técnico CSNET, membro do comitê executivo CSNET
e presidente do Distributed Systems Architecture Board da DARPA (Defense Advanced
Research Projects Agency). Foi ainda Vice-Presidente de Pesquisa na Cisco Systems.
Comer é consultor de projeto de redes de computadores para empresas e palestran-
te frequente em ambientes acadêmicos e profissionais ao redor do mundo. Seu sistema
operacional, Xinu, e a implementação de protocolos TCP/IP (ambos documentados em
seus livros) são utilizados em produtos comerciais. É professor honorário de Ciências
da Computação na Purdue University, onde leciona redes de computadores, redes de
internet, arquitetura de computadores e sistemas operacionais. Lá desenvolveu labora-
tórios de informática inovadores que dão aos alunos a oportunidade de ter experiências
práticas na operação de sistemas, redes de computadores e protocolos.
Além de escrever livros técnicos best-sellers, já traduzidos para 16 idiomas, atuou
como editor norte-americano do periódico Software – Practice and Experience por 20
anos. Comer é membro da ACM. Informações adicionais podem ser encontradas em:
www.cs.purdue.edu/homes/comer.

C732r Comer, Douglas E.

Redes de computadores e internet [recurso eletrônico] /
Douglas E. Comer ; tradução: José Valdeni de Lima, Valter
Roesler. – 6. ed. – Porto Alegre : Bookman, 2016.

Editado como livro impresso em 2016.

ISBN 978-85-8260-373-4

1. Redes de computadores. 2. Internet. I. Título.

CDU 004.7

Catalogação na publicação: Poliana Sanchez de Araujo – CRB 10/2094

28 Parte I Introdução a redes e aplicações da Internet

3.4 O modelo de interação cliente-servidor

O primeiro passo no Algoritmo 3.1 leva a uma questão: como um par de aplicações
executadas em dois computadores diferentes se coordena para solicitar uma conexão
ao mesmo tempo? A resposta está em uma forma de interação conhecida como modelo
cliente-servidor. Uma aplicação, conhecida como servidor, inicia antes e aguarda con-
tato. A outra aplicação, conhecida como cliente, inicia depois e solicita a conexão. A
Figura 3.2 resume a interação cliente-servidor.

Aplicação servidor Aplicação cliente

Inicia antes Inicia depois

Não precisa saber qual cliente vai se conectar Precisa saber a qual servidor se conectar

Espera passivamente um tempo indeterminado pelo Inicia o contato quando a comunicação é necessária
contato do cliente

Comunica-se com o cliente enviando e recebendo Comunica-se com o servidor enviando e recebendo
dados dados

Continua executando após atender um cliente, Pode encerrar após interagir com o servidor
esperando pelo próximo

Figura 3.2 Resumo do modelo cliente-servidor.

As próximas seções descrevem como serviços específicos utilizam o modelo clien-

te-servidor. Por enquanto, é suficiente lembrar o seguinte:
Embora forneça comunicação básica, a Internet não inicia nem aceita contato
de um computador remoto; programas de aplicação conhecidos como clientes e
servidores manipulam todos os serviços.

3.5 Características de clientes e servidores

Embora variações menores existam, a maioria das instâncias de aplicações que seguem
o paradigma cliente-servidor tem as seguintes características gerais:

Software cliente
• Consiste em um programa de aplicação arbitrário que se torna um cliente
temporariamente quando acesso remoto é necessário.
• É invocado diretamente pelo usuário e executa somente durante uma sessão.
• Roda localmente no computador ou dispositivo do usuário.
• Inicia contato ativamente com o servidor.
• Pode acessar múltiplos serviços se necessário, mas usualmente se comunica
com um servidor por vez.
• Não necessita hardware potente.

Software servidor
• Consiste em um programa de propósito especial, com privilégios, dedicado
a fornecer um serviço.
 Capítulo 3 Programação em redes e aplicações da Internet 29

• É invocado automaticamente quando o sistema inicializa e continua execu-

tando enquanto o computador estiver ligado.
• É executado em um computador dedicado.
• Espera passivamente pelos contatos dos clientes remotos.
• Pode aceitar conexões de muitos clientes ao mesmo tempo, porém (usual-
mente) oferece somente um serviço.
• Requer um hardware mais poderoso e um sistema operacional sofisticado.

3.6 Programas servidores e computadores servidores

Algumas vezes o termo servidor é compreendido de forma inadequada. Formalmen-
te, ele se refere a um programa que espera passivamente o contato de clientes, e não
ao computador no qual ele executa. Entretanto, quando um computador é dedicado
a executar um ou mais programas servidores, seus administradores normalmente o
chamam de “servidor”. Fabricantes de hardware aumentam a confusão, pois classifi-
cam computadores que possuem CPUs mais rápidas, grande quantidade de memória
e sistemas operacionais sofisticados como máquinas servidoras. A Figura 3.3 ilustra
as definições.

cliente executa servidor executa

em um computador em um computador
normal servidor

conexão Internet

Figura 3.3 Ilustração de um cliente e de um servidor.

3.7 Requisições, respostas e direção do fluxo de dados

Os termos cliente e servidor surgiram porque quem inicia a conexão é um cliente. Entre-
tanto, uma vez que a conexão tenha sido estabelecida, a comunicação flui em ambas as
direções (i.e., dados podem fluir do cliente para o servidor e do servidor para o cliente).
Tipicamente, um cliente envia uma requisição ao servidor, e o servidor envia uma res-
posta ao cliente. Em alguns casos, um cliente envia uma série de requisições e o servidor
uma série de respostas (por exemplo, um cliente de banco de dados deve permitir ao
usuário acessar mais de um item por vez). O conceito pode ser resumido:
A informação pode fluir em ambas as direções entre cliente e servidor. Embora
muitos serviços sejam baseados no cliente enviando uma ou mais requisições e
no servidor enviando as respostas, outras interações são possíveis.
30 Parte I Introdução a redes e aplicações da Internet

3.8 Múltiplos clientes e múltiplos servidores

Um cliente ou servidor consiste em um programa de aplicação, e um computador pode
executar múltiplas aplicações ao mesmo tempo. Como consequência, um dado compu-
tador pode executar:
• Um cliente individual
• Um servidor individual
• Múltiplas cópias de um cliente se comunicando com um dado servidor
• Múltiplos clientes individuais se comunicando com diferentes servidores
• Múltiplos servidores, cada um para um serviço diferente
Permite que um computador opere múltiplos clientes é útil, pois diferentes servi-
ços podem ser acessados simultaneamente. Por exemplo, um usuário roda três aplica-
ções ao mesmo tempo: um navegador Web, um software de mensagens instantâneas e
uma videoconferência. Cada aplicação é um cliente que se comunica com um servidor
particular, de forma independente das outras aplicações. Na verdade, a tecnologia per-
mite a um usuário executar várias cópias de uma mesma aplicação, cada uma se comu-
nicando com um servidor (por exemplo, duas janelas em um navegador Web, cada uma
acessando uma página diferente).
Permitir a um dado computador executar múltiplos programas servidores é útil por
duas razões. Primeira, utilizar somente um computador físico em vez de vários reduz o es-
forço administrativo de manutenção. Segunda, a experiência mostra que a demanda para um
serviço é muitas vezes esporádica – um determinado servidor frequentemente permanece
ocioso por muito tempo, e um servidor ocioso não consome CPU. Assim, se a demanda total
por serviços é pequena, consolidar vários servidores em um único computador físico pode
reduzir custos drasticamente sem redução significativa no desempenho. Resumindo:
Um único computador potente pode oferecer múltiplos serviços ao mesmo tem-
po, basta executar um programa servidor para cada serviço.

3.9 Identificação de servidores e demultiplexação

Como um cliente identifica um servidor? Os protocolos da Internet dividem a identifi-
cação em duas partes:
• Um identificador que especifica o computador onde o programa servidor está sen-
do executado.
• Um identificador que especifica o serviço naquele computador.
Identificando o computador. Cada computador na Internet possui um identifica-
1
dor único conhecido como endereço do protocolo da Internet (endereço IP) . Quando
vai iniciar a comunicação, o cliente deve especificar o endereço IP do servidor. Para
facilitar a identificação dos servidores pelos seres humanos, cada computador também
possui um nome, e o DNS (Domain Name System), descrito no Capítulo 4, é utilizado
para traduzir um nome em um endereço. Assim, o usuário especifica um nome, como
www.cisco.com, em vez de um endereço IP.

1
O Capítulo 21 trata de endereços IP em detalhes e explica os formatos de endereços em IPv4 e IPv6.
 Capítulo 3 Programação em redes e aplicações da Internet 31

Identificando um serviço. Cada serviço disponível na Internet possui um identi-

ficador único de 16 bits conhecido como número da porta do protocolo (normalmente
abreviado para número da porta ou simplesmente porta). Por exemplo, o serviço de
envio de mensagens de e-mail utiliza a porta 25, e o serviço de navegação Web utiliza a
porta 80. Quando um servidor inicia a execução, ele se registra com o sistema local es-
pecificando o número da porta por onde seu serviço será acessível. Quando um cliente se
conecta a um servidor remoto para requisitar determinado serviço, a requisição contém
esse número de porta. O sistema operacional do servidor utiliza o número de porta da
requisição para determinar qual aplicação deve tratá-la.
A Figura 3.4 resume a discussão listando os passos básicos que um cliente e um
servidor devem efetuar para se comunicar.

• Inicia depois que o • Inicia antes de todos

servidor já está rodando os clientes
• Usuário fornece o • Registra a porta N
nome do servidor Internet com o sistema local
• Usa DNS para traduzir • Espera contato dos clientes
o nome para endereço IP
• Interage com o cliente
• Especifica a porta do até ele encerrar
serviço que deseja
utilizar, no caso, porta N • Espera conexão do
próximo cliente
• Conecta com o servidor
e interage com ele

Figura 3.4 Passos conceituais de que cliente e servidor necessitam para se comunicar.

3.10 Servidores concorrentes

Os passos na Figura 3.4 mostram que o servidor lida com um cliente por vez. Embora
uma abordagem sequencial funcione em alguns casos triviais, a maioria dos servidores
trabalha de forma concorrente, ou seja, o servidor utiliza mais que uma thread de con-
trole2 para lidar com múltiplos clientes ao mesmo tempo.
Para entender a importância do serviço concorrente, imagine o que acontece se
um cliente efetua o download de um filme do servidor. Se o servidor atender a uma
requisição por vez, todos os outros clientes vão ter que esperar até ele transferir todo o
filme. Num servidor concorrente isso não acontece. Assim, se outro cliente se conectar
requisitando um pequeno download (por exemplo, de uma música), sua requisição
começa imediatamente e pode terminar antes que a transferência do filme seja comple-
tada (dependendo do tamanho dos arquivos e da velocidade na qual cada cliente pode
receber dados).
Os detalhes da execução concorrente dependem do sistema operacional, mas a
ideia é fácil de entender. O código do servidor concorrente é dividido em duas partes: o
programa principal (thread principal) e o atendimento (thread de controle). O programa
principal somente aceita a conexão do cliente e cria a thread de controle para atender a
ele. Cada thread de controle interage com um único cliente e executa o código de atendi-

2
Alguns sistemas operacionais utilizam o termo thread de execução ou processo para se referir à thread de
controle.
32 Parte I Introdução a redes e aplicações da Internet

mento. Depois de atender o cliente, a thread termina. Enquanto isso, o programa princi-
pal mantém o servidor ativo – após criar a thread para atender à requisição, o programa
principal espera novas conexões.
Note que, se N clientes estão utilizando simultaneamente um servidor concorrente,
haverão N+1 threads sendo executadas: o programa principal esperando conexões e as N
threads interagindo com seus respectivos clientes. Podemos resumir:
Um servidor concorrente utiliza threads de execução para atender a requisições
dos múltiplos clientes ao mesmo tempo. Assim, um cliente pode ser atendido
imediatamente, sem precisar esperar um cliente anterior finalizar sua conexão.

3.11 Dependências circulares entre servidores

Tecnicamente, qualquer programa que contate outro está agindo como cliente, e qual-
quer programa que aceite contato de outro está agindo com servidor. Na prática, a dis-
tinção não é tão clara, pois um servidor de um serviço pode agir como cliente de outro.
Por exemplo, antes de preencher uma página Web, o servidor Web pode ter que se tornar
cliente de um servidor de banco de dados ou de um serviço de segurança (por exemplo,
para verificar se o cliente tem permissão de acesso à página Web solicitada).
É claro que os programadores devem ter cuidado para evitar dependências circula-
res entre servidores. Por exemplo, considere o que pode acontecer se um servidor para o
serviço X1 se tornar um cliente do serviço X2, que se torna um cliente do serviço X3, que
se torna um cliente do serviço X1. A cadeia de requisições pode continuar indefinida-
mente até que todos os três servidores esgotem seus recursos. O potencial de circularida-
de é alto especialmente quando serviços são projetados de forma independente, porque
nenhum dos programadores tem acesso a todos os servidores.

3.12 Interações peer-to-peer (par-a-par)

Se um único servidor fornecer um determinado serviço, a conexão de rede entre ele e a
Internet pode se tornar o gargalo. A Figura 3.5 ilustra o problema.

servidor
todo o tráfego ocorre
sobre um único enlace
Internet

Figura 3.5 Gargalo de tráfego em um sistema que utiliza servidor único.

A questão que surge é: como serviços da Internet podem ser oferecidos sem criar
um gargalo central? Uma forma de evitar o gargalo é a base das aplicações de compar-
tilhamento de arquivos. Conhecido como arquitetura peer-to-peer (p2p ou par-a-par),
 Capítulo 3 Programação em redes e aplicações da Internet 33

o esquema evita manter os dados em um servidor central. Conceitualmente, dados são

distribuídos igualmente por N servidores, e cada requisição de cliente é enviada para
o servidor mais apropriado. Como um determinado servidor somente fornece 1/N dos
dados, a quantidade de tráfego entre o servidor e a Internet é 1/N quando comparado
à arquitetura de servidor único. A ideia principal é que o software do servidor pode
rodar no mesmo computador dos clientes. Se cada usuário concordar em localizar 1/N
dos dados em seu computador, não serão necessários servidores especiais. A Figura 3.6
ilustra a arquitetura. O exemplo mostra somente quatro computadores. Em um sistema
p2p real, o tráfego em um computador pode ser extremamente pequeno, pois N pode ser
extremamente grande (dezenas de milhares).

1/N de todo o tráfego

Internet

Figura 3.6 Interação exemplo em um sistema peer-to-peer.

3.13 Programação em redes e API de sockets

A interface utilizada pelas aplicações para comunicação na Internet é conhecida como
interface de programas de aplicação (API, Application Program Interface)3. Embora os
detalhes exatos de uma API dependam do sistema operacional, uma API particular tem
emergido como um padrão de fato para softwares que se comunicam via Internet. Co-
nhecida como API de sockets e comumente abreviada como sockets, a API está disponí-
vel para muitos sistemas operacionais, como Microsoft Windows, Apple OS-X, Android
e vários sistemas UNIX, incluindo o Linux. Em resumo:

A API de sockets, que se tornou o padrão de fato para comunicação via Inter-
net, está disponível na maioria dos sistemas operacionais.

O restante do capítulo descreve funções na API de sockets; leitores que não são progra-
madores podem pular os detalhes.

3
O Apêndice 1 contém uma API simplificada (com somente sete funções) e um código-exemplo que demons-
tra como tal API pode ser utilizada para criar aplicações na Internet, incluindo um servidor Web funcional.
 Encerra aqui o trecho do livro disponibilizado para
esta Unidade de Aprendizagem. Na Biblioteca Virtual
da Instituição, você encontra a obra na íntegra.