E1_SIDI

Prévia do material em texto

e-Book 1
Ariel da Silva Dias
SISTEMAS DISTRIBUÍDOS
Sumário
INTRODUÇÃO ������������������������������������������������� 3
SISTEMA DISTRIBUÍDO ��������������������������������� 5
CONSIDERAÇÕES FINAIS ����������������������������34
REFERÊNCIAS BIBLIOGRÁFICAS & 
CONSULTADAS ��������������������������������������������36
3
INTRODUÇÃO
O ritmo acelerado com que os sistemas computa-
cionais mudam, foi e continua sendo esmagador. 
Do ano de 1945, que marcou o início da era do 
computador moderno, até meados de 1985, os 
computadores eram muito caros e, como não era 
possível interconectá-los, eles somente trabalhavam 
de forma independente um do outro. 
Em meados da década de 80, dois avanços tecno-
lógicos mudaram as perspectivas da computação: 
o desenvolvimento de microprocessadores pode-
rosos. Afinal, essas máquinas até então eram de 
8 bits, porém logo os computadores de 16, 32 e 
64 bits tornaram-se comuns.
Fazendo um paralelo da era atual dos computa-
dores para uma visão de 40 anos atrás, a geração 
atual de computadores, com CPUs multicores têm 
o poder computacional dos mainframes daquela 
época, mas por um milésimo do preço (ou talvez, 
até menos).
Além do advento dos microprocessadores, outro 
marco foi a invenção da rede de computadores de 
alta velocidade, de modo a permitir que milhares de 
computadores sejam conectados e troquem infor-
mações a taxas de bilhões de bits por segundos.
4
Como resultado de todas estas tecnologias, bem 
como com o desenvolvimento de máquinas cada vez 
mais potentes, nanocomputadores, smartphones 
e outros dispositivos tecnológicos, é que agora é 
muito mais fácil e viável criarmos um sistema de 
computação composto por muitos computadores 
em rede, sejam eles grandes ou pequenos. Esses 
computadores são geralmente dispersos geografi-
camente, formando assim um sistema distribuído.
55
SISTEMA DISTRIBUÍDO
A literatura apresenta diversas definições do con-
ceito de sistemas distribuídos, porém todas elas 
possuem pontos em comum. Tanenbaum (2016), 
define brevemente um sistema distribuído como 
“uma coleção de elementos de computação au-
tônomos que aparecem para seus usuários como 
um único sistema coerente”.
Podemos então adicionar mais algumas palavras 
a esta definição de sistema distribuído, também 
chamado de computação distribuída, a qual ca-
racteriza-se por um sistema com vários com-
ponentes autônomos localizados em diferentes 
máquinas que se comunicam e coordenam ações 
para aparecer como um único sistema coerente 
para o usuário final.
Vamos analisar as duas frases que estão em 
destaque. A citação “um sistema com vários com-
ponentes autônomos” se refere a todos os tipos 
de nós que constituem um sistema distribuído. 
Esses nós são formados desde computadores de 
grande porte e de alto desempenho, até pequenos 
computadores, smartphones e outros dispositivos 
ainda menores.
Observe que cada um dos dispositivos (dos nós) 
possui a característica de agir de modo indepen-
66
dente um dos outros, porém, são programados 
para atingir objetivos comuns por meio de trocas 
de mensagens entre eles. Muito cuidado aqui, 
apesar de eles serem independentes um dos ou-
tros, eles estão trabalhando por um objetivo em 
comum. Se eles não trabalharem por um objetivo 
comum, então não devem fazer parte do mesmo 
sistema distribuído.
Outra característica importante e destacada por 
Tanenbaum é que, como são dispositivos inde-
pendentes, cada um possui sua própria noção de 
tempo, logo, não existe um relógio global que co-
ordena as ações dos nós e, com isso, temos uma 
das principais questões relacionadas a sistemas 
distribuídos: a sincronização e a coordenação dos 
nós dentro de um sistema.
A segunda citação da definição de sistema distribu-
ídos diz que um sistema distribuído se caracteriza 
e deve aparecer como um único sistema coerente 
para o usuário final. Esta citação implica que um 
sistema possua transparência de distribuição, 
ou seja, o usuário final não deveria perceber os 
processos que estão ocorrendo, bem como não 
ter ciência de que os dados estão distribuídos em 
uma rede de computadores.
Observe que a palavra deveria está destacada, isso 
por que, segundo Tanenbaum, pedir para que um 
77
sistema distribuído seja totalmente transparente, 
aparentando ser como um sistema único, torna-o 
coerente, pois se comporta de acordo com as 
expectativas do usuário.
Os sistemas distribuídos se enquadram na cate-
goria de sistemas fracamente acoplados, ou seja, 
uma grande quantidade de computadores está 
interconectada, comunicando, porém não são 
necessariamente dependentes uns dos outros.
Um sistema distribuído é então uma coleção de 
elementos de computação autônomos, ligados por 
algum meio de comunicação e que aparecem para 
seus usuários como um único sistema coerente. 
Esses componentes (os quais vimos que são 
chamados de nós) podem ser dispositivos de har-
dware (por exemplo, computador, telefone celular) 
ou processos de software. Um bom exemplo é a 
Internet - o maior sistema distribuído do mundo. 
Composto por milhões de máquinas, para você, 
parece um único sistema. Você não tem ideia de 
onde os dados estão armazenados, quantos ser-
vidores estão envolvidos ou como as informações 
chegam ao seu navegador. 
Esse conceito é chamado de abstração e reaparece 
continuamente em TI. Resumindo, é como se seu 
navegador abstraísse a complexidade da Internet. 
O mesmo se aplica a aplicativos como Gmail, 
88
Salesforce, Facebook, Google Fotos ou qualquer 
aplicativo empresarial que você possa usar. Você 
literalmente interage com aplicativos distribuídos 
todos os dias!
Os sistemas distribuídos visam a otimizar o desem-
penho e reduzir o tempo de resposta. Esta otimiza-
ção e redução de tempo só são possíveis graças 
ao uso de múltiplos processadores presentes em 
um sistema de computação distribuída. Com isso, 
temos maior desempenho de processamento se 
comparado aos sistemas centralizados que utilizam 
apenas um processador (independentemente do 
tipo de processador, afinal, vários processadores 
juntos trabalham melhor do que apenas um isolado).
Características
No tópico anterior você viu os conceitos de sistemas 
distribuídos e que eles estão em toda parte. Agora 
serão apresentadas as principais características 
que justificam o emprego de sistemas distribuídos.
Concorrência
A concorrência é uma das principais características 
dos sistemas distribuídos, e representa o fato de 
que várias atividades estão sendo executadas ao 
mesmo tempo.
A concorrência ocorre a partir do momento em 
que vários clientes tentam acessar, ao mesmo 
99
tempo, um determinado recurso compartilhado. 
Por exemplo, no Brasil temos a entrega de imposto 
de renda, cujo prazo final geralmente é no mês de 
abril. Ocorre que muitos brasileiros, por qualquer 
razão que seja, deixam para entregar as decla-
rações nos últimos dias. Logo, o recurso (portal 
que recebe as declarações), registra um grande 
volume de acessos simultâneos, ocorrendo então 
a concorrência pelo recurso.
Logo, a partir do momento que os usuários realizam 
diversas solicitações a um mesmo recurso em 
um mesmo instante de tempo, isso obriga que o 
sistema distribuído seja capaz de atender a estas 
requisições simultaneamente.
Considere, por exemplo, uma empresa XYZ todos 
os usuários utilizam uma aplicação web ao mesmo 
tempo. Logo, este aplicativo web também é concor-
rente. Sendo assim, a concorrência não é limitada 
somente ao servidor web que deve lidar com as 
requisições dos clientes (no caso da Receita Federal 
citada anteriormente). Acrescenta-se ainda que o 
aplicativo está executando a lógica do negócio ao 
mesmo tempo que realizar o armazenamento e 
transações em um banco de dados no back-end, 
característica então de concorrência.
1010
Podemos dizer então que a concorrência é uma 
característica fundamental, uma propriedade intrín-
seca de qualquer tipo de sistema distribuído. 
O controle de concorrência é um dos desafios encon-
trados na arquiteturade sistemas distribuídos. Deste 
modo, para que você conheça como é realizado o 
controle de concorrência, é recomendado que você 
leia o artigo “Um controle de concorrência distri-
buído para Dados XML”, em que o autor apresenta 
técnicas de controle de concorrência para gerenciar 
dados. Acesse: https://www.researchgate.net/profile/
Javam-Machado/publication/221535849_Um_Contro-
le_de_Concorrencia_Distribuido_para_Dados_XML/
links/56044f4708aea25fce312232/Um-Controle-de-Con-
correncia-Distribuido-para-Dados-XML.pdf.
Escalabilidade
A escalabilidade está diretamente relacionada 
ao crescimento da carga de trabalho crescente 
ou decrescente (temos que considerar também 
que a carga de trabalho tende a diminuir) de um 
sistema. Em outras palavras, quando o a carga de 
trabalho aumenta ou diminui, o sistema distribuído 
e as aplicações relacionadas devem permanecer 
do mesmo modo, sem degradações.
SAIBA MAIS
1111
Considere por exemplo, uma empresa que possui 
uma aplicação web que é acessada por 10 esta-
ções de trabalho. Em um dado momento, 10 novos 
usuários são contratados e passarão, cada um 
deles, a utilizar uma estação de trabalho e intera-
gir com a mesma aplicação web, logo, serão 20 
estações acessando o servidor (e o aplicativo) ao 
mesmo tempo. De acordo com Coulouris (2012), 
este sistema será considerado como escalável se 
continuar a ser eficaz para 20 estações assim como 
era anteriormente para as 10 estações, em outras 
palavras, quando houver um aumento significativo 
do número de recursos ou usuários, o sistema não 
pode ter degradações.
Podemos dividir a escalabilidade em duas estra-
tégias básicas:
 y Escalabilidade vertical: Novos recursos (pro-
cessadores mais rápidos, memória, entre outros) 
são adicionados a um único nó, deste modo, este 
nó pode lidar com mais trabalho e fornecer ainda 
mais capacidade. Esta estratégia acelera direta-
mente o sistema.
 y Escalabilidade horizontal: Nesta estratégia, 
novos nós são adicionados. Esta estratégia requer 
algum tipo de distribuição dentro do próprio siste-
ma distribuído. A vantagem é que, caso o sistema 
possa ser dimensionado horizontalmente, ele pode 
ser ampliado na unidade de centenas a milhares 
1212
de máquinas. Logo, é uma estratégia ideal para 
arquiteturas de grande escala. 
Ao considerar um servidor web, por exemplo, po-
demos utilizar ambas as estratégias. No exemplo 
da Receita Federal e entrega do imposto de renda, 
seguindo a estratégia de escalabilidade horizontal, 
poderíamos adicionar novos nós próximo ao mês 
de abril para atender à crescente de demanda e, 
após este mês, remover estes nós, afinal, o número 
de acessos tendem a diminuir.
Tolerância a falhas
De acordo com Dantas (2005, p.44) a tolerância a 
falhas “pode ser definida como a habilidade que 
um sistema tem de apresentar um comportamento 
muito bem definido na ocorrência de falhas ativas”.
Em outras palavras, podemos definir Tolerância 
a Falhas como a capacidade de um sistema de 
continuar operando sem interrupções, apesar da 
falha de um ou mais de seus componentes. Isso é 
verdade quer se trate de um sistema de computador, 
um cluster de nuvem, uma rede ou qualquer outra 
coisa. Em outras palavras, a tolerância a falhas 
refere-se a como um sistema se comporta aos 
impactos causados pelas falhas, impedindo, mini-
mizando ou reduzindo estes impactos negativos.
1313
A tolerância a falhas visa a garantir a continuidade 
dos negócios e a alta disponibilidade, evitando 
interrupções decorrentes de um único ponto de 
falha. As soluções de tolerância a falhas, portan-
to, tendem a se concentrar mais em sistemas ou 
aplicativos de missão crítica.
Podemos elencar alguns níveis de tolerância a 
falhas, como:
 y No nível mais baixo (hardware), a capacidade 
de responder a uma falha de energia, por exemplo;
 y Indo um nível acima, no software: durante uma 
falha de um sistema web, por exemplo, a capacida-
de de usar um sistema de backup imediatamente;
 y Indo um pouco mais além: um disco do ser-
vidor de arquivos falha e os discos espelhados 
assumem imediatamente o controle. Isso fornece 
funcionalidade apesar de a falha parcial do siste-
ma ou degradação normal, em vez de uma pane 
imediata e perda de função, mantendo assim a 
transparência ao usuário;
 y Tolerância a falhas em computação de alto 
nível: vários processadores colaboram para fazer 
a varredura de dados e saída para detectar erros 
e, em seguida, corrigi-los imediatamente.
A tolerância a falhas pode fazer parte da interface 
do sistema distribuído, permitindo aos desenvol-
1414
vedores verificarem os dados críticos em pontos 
específicos durante uma transação.
Transparência
A transparência já foi tratada aqui, mas vale muito 
reforçar esta importante característica dos siste-
mas distribuídos. Ela se refere a algum aspecto 
do sistema distribuído que está oculto do usuário, 
seja ele o programador ou usuário do aplicativo. 
Deste modo, os usuários não devem estar cientes 
da localização dos serviços.
De acordo com (Crowcroft, 1996) e (Friederich, 
2002) existem quatro principais tipos de transpa-
rências, são elas:
 y Transparência no acesso: garante que não 
haja nenhuma diferença aparente entre o método 
de acesso local ou remoto a um sistema. Por 
exemplo: enviar um arquivo remotamente para 
uma impressora que está em outro local (outro 
departamento ou até outra cidade) deve ser idên-
tico a enviar o arquivo localmente à impressora 
que está conectada ao computador.
 y Transparência de migração: garante que se 
os dados ou processos migrarem de um servidor 
para outro (para fornecer melhor desempenho, por 
exemplo), o usuário não deve perceber. Por exemplo, 
suas fotos no Google Fotos estão armazenadas 
em um servidor X. Se a Google migrar suas fotos 
1515
para o servidor Y, enquanto você as visualiza, você 
não deve perceber este processo.
 y Transparência de concorrência: garante que 
os usuários devem acessar recursos compartilha-
dos (dados, por exemplo) sem interferência entre 
si. O Google Docs possui esta característica, dois 
usuários podem ao mesmo tempo editar o mesmo 
arquivo, sem que um interfira na ação do outro (a 
não ser que seja proposital). Isso requer mecanis-
mos complexos de controle de concorrência. Por 
exemplo, um serviço de impressão distribuído deve 
fornecer acesso atômico aos usuários, de modo 
que as impressões não saiam aleatoriamente 
intercaladas.
 y Transparência de replicação: garante que, se 
o sistema necessitar ser replicado (seja por motivo 
de segurança, disponibilidade ou desempenho) o 
usuário não deve perceber.
Compartilhamento de recursos
Esta é a principal motivação dos sistemas distribu-
ídos. Entenda como recurso: o hardware (câmera, 
scanner, impressora, processador, disco rígido, entre 
outros), software (banco de dados, compiladores 
e outros), dados (arquivos, página web e outros) 
além de outros tantos que poderiam ser citados. 
Observe então que a lista de recursos que podem 
ser compartilhados é extensa.
1616
Existem diversos motivos para compartilharmos 
recursos e, uma das principais, está relacionada à 
economia. Por exemplo, uma empresa pode comprar 
um servidor e investir em armazenamento (disco 
rígido de alta capacidade), tornando-o o servidor de 
arquivo. Isso é muito mais barato do que armazenar 
dados localmente no computador de cada usuário 
separadamente (TANENBAUM, 2016).
Outro exemplo de compartilhamento de recursos 
é a própria internet. Através de protocolos de co-
municação simples, os usuários trocam arquivos, 
mensagens de e-mail, documentos, áudio e vídeo. 
Desse modo, grupos que estão dispersos podem 
ter acesso ao mesmo documento (você está lendo 
este ebook e certamente outros alunos também 
estão, afinal, este arquivo está compartilhado para 
um grupo de alunos).
Heterogeneidade
Os sistemas distribuídos possuem uma gama 
enorme de diferentes tipos de hardwares e softwa-
res trabalhando juntos, de maneira cooperativa. A 
figura 1 ilustra uma típica arquitetura da internet,na qual sistemas heterogêneos estão conectados.
1717
Figura 1: Arquitetura típica web com diversos tipos de 
redes e dispositivos.
Fonte: Adaptado de Coulouris (2012, p. 9).
Neste contexto, considere um arquivo que está 
armazenado em um servidor. Este arquivo é aces-
sado por um usuário em seu notebook que, via 
rede cabeada, está conectado ao servidor. Outro 
usuário, ao mesmo tempo, utilizando o smartphone, 
acessa via wi-fi o arquivo no servidor. Um terceiro 
usuário requisita o mesmo arquivo por meio de 
um serviço web de seu escritório e o envia para 
impressão em outra unidade da empresa, a qual 
está em outro país. 
Observe que temos diversos dispositivos se co-
municando em diversas redes. Observe também 
que são dispositivos diferentes: um notebook, um 
smartphone e também uma impressora, todos 
1818
eles conectados ao mesmo sistema distribuído 
por canais diferentes.
Arquiteturas dos sistemas distribuídos
O conceito de arquitetura é um modo de organizar-
mos e representarmos o conhecimento dentro de 
um determinado campo de aplicação. Normalmente, 
ele fornece um modelo comum que identifica os 
principais componentes do sistema e as interações 
entre eles.
A seguir você conhecerá as arquiteturas de siste-
mas distribuídos.
Modelo de arquitetura cliente-servidor
O modelo cliente-servidor ou a arquitetura cliente-
-servidor referem-se a um modelo de design que 
pode ser considerado como um aplicativo exe-
cutado em uma rede. Em termos muito básicos, 
considere o cliente como a entidade que realiza 
solicitações - e o servidor aquele que executa ou 
que, de alguma forma, atende a solicitação. Isso 
é considerado uma arquitetura cliente-servidor de 
duas camadas.
Em aplicações web é comum o uso de arquiteturas 
de três camadas, sendo elas apresentadas a seguir:
 y Camada de apresentação: A camada de 
apresentação é a camada frontal no sistema de 3 
1919
camadas, e é por ela que o usuário interage com 
o sistema (front-end ou front-side). Essa interface 
do usuário geralmente é gráfica, acessível através 
de um navegador da Web ou aplicativo baseado 
na Web e exibe conteúdo e informações úteis para 
o usuário final. Essa camada geralmente é criada 
em tecnologias da web como HTML5, JavaScript, 
CSS ou por meio de outras estruturas populares 
de desenvolvimento da web e se comunica com 
outras camadas por meio de chamadas de APIs.
 y Camada de aplicação: A camada de apli-
cação ou de negócio contém a lógica funcional 
de negócios, a qual impulsiona as capacidades 
essenciais de um aplicativo. É frequentemente 
escrito em Java, .NET, C#, Python, C ++, PHP, entre 
outros. Esta camada está no back-end, ou seja, é 
transparente para o usuário, uma vez que ele não 
interage diretamente com esta camada.
 y Camada de dados: Esta camada, também 
chamada de camada de persistência, compreende 
a base de dados ou sistema de armazenamento de 
dados e de acesso aos dados. Exemplos de tais 
sistemas são MySQL, Oracle, PostgreSQL, Micro-
soft SQL Server, MongoDB, entre outros. Os dados 
são acessados pela camada de aplicação através 
de chamadas de APIs. Esta camada também está 
no back-end.
2020
Os computadores clientes acessam três camadas 
diferentes de servidores: Servidores da Web, que 
lidam com a troca de informações baseada na Web; 
servidores de aplicativos, que processam dados de 
e para os computadores clientes e o servidor de 
banco de dados; e o servidor de banco de dados, 
que armazena e recebe dados. Os computadores 
da rede são programados para executar o trabalho 
com eficiência, dividindo as tarefas de processa-
mento entre clientes e servidores.
Ao se pensar em arquitetura de sistemas distribuí-
dos, a mais tradicional e empregada amplamente é 
a arquitetura cliente-servidor. Observe um exemplo 
de comunicação entre cliente-servidor na figura 2, 
em que o cliente realiza requisições (invocation) e 
o servidor retorna uma resposta (result).
Figura 2: Cliente realizando requisições. 
Client
Client
invocation
result Server
invocation
result
Server
Key:
Process: Computer:
Fonte: Adaptado de Coulouris (2012, p. 47).
Ao ver o termo cliente, você pode ficar tentado 
a pensar em pessoas ou usuários; por exemplo, 
2121
falamos de “clientes de nossa empresa”. No mo-
delo cliente-servidor, entretanto, o termo cliente 
não se refere a pessoas, mas a máquinas em rede 
que são pontos de entrada típicos para o sistema 
cliente-servidor usado por humanos. D e s s e 
modo, os clientes podem ser desktops em rede, 
uma estação de trabalho, um smartphone ou qual-
quer outra forma pela qual o usuário possa entrar 
no sistema. Além disso, pela própria figura, você 
pode observar que um servidor (server) está rea-
lizando requisições para um outro servidor. Logo, 
o servidor mais à direita, em um dado momento, 
passa a ser o cliente do servidor central.
Modelo de arquitetura peer-to-peer
Uma arquitetura de sistema distribuído peer-to-peer 
(ponto a ponto ou simplesmente P2P) não possui 
clientes ou servidores específicos. Uma rede P2P 
representa um sistema distribuído de máquinas cha-
madas nós, em que estes nós podem desempenhar 
a função de cliente e servidor simultaneamente ou 
em diferentes momentos. O modelo é inerente ao 
próprio nome - em uma rede P2P, cada máquina é 
um par (peer) igual em responsabilidades e ações, 
ao invés de ser um cliente ou servidor.
As redes P2P se tornaram populares após o 
lançamento de serviços de compartilhamento 
de arquivos como o site de compartilhamento 
2222
de música Napster. A ideia do P2P ganhou uma 
espécie de status de culto porque os sistemas 
podiam operar independentemente de qualquer 
controle centralizado. 
O BitTorrent é um dos protocolos mais amplamente 
usados para a transferência de grandes arquivos 
pela web por meio de torrents na arquitetura P2P. A 
ideia principal é facilitar a transferência de arquivos 
entre diferentes pontos da rede sem ter que passar 
por um servidor principal.
Usando um cliente BitTorrent, você se conecta a 
vários computadores em todo o mundo para bai-
xar um arquivo. Ao abrir um arquivo .torrent, você 
se conecta a um rastreador, que é uma máquina 
que atua como um coordenador. Isso ajuda na 
descoberta de pares, mostrando os nós da rede 
que possuem o arquivo que você deseja. A figura 
3 apresenta um modelo de arquitetura P2P.
2323
Figura 3: Arquitetura P2P do BitTorrent.
Sharable
objects
Peer 1
Peer 2
App
App
Peer 3
App
Peers 4 .... N
Fonte: Adaptado de Coulouris (2012, p. 47).
Observe pela figura 3 que não existe um nó centra-
lizador, o que torna a arquitetura P2P mais flexível, 
uma vez que novos nós podem ser adicionados ou 
removidos da arquitetura, sem impactos severos. 
Observe também que com P2P podemos utilizar um 
grande número de computadores para realizarem 
uma determinada tarefa. 
2424
Caching
Vamos a um exemplo bem simples. Você é o pro-
fessor de matemática em uma escola de ensino 
fundamental. Ao entrar na sala você solicita aos 
alunos que respondam uma pergunta: “Qual o 
resultado da multiplicação 777x777?”. Os alunos 
param por um tempo com o objetivo de calcular 
e encontrar a resposta. Após alguns minutos eles 
respondem (corretamente): 603729.
Após passarem algumas horas, no fim da aula, 
você realiza a mesma pergunta e os alunos, como 
já haviam calculado anteriormente, respondem 
corretamente sem demora. Esta resposta só foi 
rápida e certeira porque os alunos já haviam feito 
o cálculo antes. Este é o conceito de cache.
Logo, podemos afirmar que o cache é um compo-
nente que armazena dados para que solicitações 
futuras desses dados possam ser atendidas mais 
rapidamente. Isso fornece alto rendimento e acesso 
de baixa latência aos dados de aplicativos comu-
mente usados, armazenando os dados na memória.
Ao evitar, por exemplo, o acesso a dados de alta 
latência em um servidor de banco de dados externo, 
o armazenamento em cache pode melhorar drasti-
camente a capacidade de resposta do aplicativo.
Os caches são usados com muitafrequência. O 
navegador web, por exemplo, possui um cache das 
2525
páginas e conteúdos vistos recentemente. Logo, 
quando você pede para acessar um determinado 
site, antes de ser realizada a requisição no servidor 
externo, primeiramente o navegador verifica se 
o conteúdo está na memória cache, se estiver, a 
página é exibida, se não estiver em cache, o nave-
gador realiza a requisição ao servidor.
Comunicação em sistemas distribuídos
Neste tópico será apresentada a comunicação 
em um ambiente de sistemas distribuídos. A co-
municação é o processo de troca de dados entre 
dois ou mais processos independentes em um 
ambiente distribuído, o que podemos chamar de 
comunicação entre processos.
A comunicação entre os processos pode ser sín-
crona e assíncrona, vamos conhecê-las a seguir.
Comunicação síncrona
Na comunicação síncrona, os processos ouvem e 
agem de acordo com as respostas uns dos outros. 
Por exemplo, quando você entra em um chat para 
conversar com um atendente via web, o atendente 
lhe envia uma mensagem, em seguida você res-
ponde e vocês dois realizam esta comunicação 
até que uma das partes resolva encerrar.
Neste exemplo, observe que tanto você quanto o 
atendente estabelecem uma sessão de comunicação. 
2626
A conversa é bidirecional e ocorre sem restrições. 
Esta é a característica da comunicação síncrona.
Comunicação assíncrona
Na comunicação assíncrona, os processos não 
ouvem as mensagens da mesma maneira que 
na comunicação síncrona. Vamos retornar ao 
exemplo do atendimento. Imagine que ao invés 
de utilizar o chat, você resolveu entrar em contato 
por e-mail. Você, como cliente, envia a mensagem, 
mas não espera por receber instantaneamente a 
mensagem de resposta. Na realidade, quando o 
atendente receber, ele vai analisar o seu e-mail e 
decidir quando e como responder.
Observe então que na comunicação assíncrona 
temos um atraso entre o início da comunicação 
(você enviando o e-mail) e a resposta (momento 
em que o atendente irá enviar a resposta ao seu 
e-mail).
Resumidamente: na comunicação síncrona, as duas 
partes envolvidas (os dois processos) funcionam 
juntas em tempo real, enquanto na comunicação 
assíncrona as duas partes não funcionam juntas 
em tempo real.
Protocolos TCP/IP e UDP
TCP/IP (Transmission Control Protocol / Internet 
Protocol) é um conjunto de protocolos da camada 
2727
de transporte e da camada de rede, respectivamen-
te, para que as máquinas se comuniquem entre si 
pela rede.
O IP lida com endereçamento e roteamento de 
rede. Em uma rede IP, cada máquina recebe um 
endereço IP exclusivo (por exemplo, 192.168.0.1) 
e o software IP é responsável por rotear uma 
mensagem do IP de origem para o IP de destino. 
No IPv4, o endereço IP consiste em 4 bytes, cada 
um varia de 0 a 255, separados por pontos. O IPv6 
mais recente, suporta mais endereços. Como a 
memorização do número é difícil para a maioria 
das pessoas, um nome de domínio semelhante ao 
inglês, como www.nomedosite.com.br é usado em 
seu lugar. O DNS (Domain Name Service) converte 
o nome do domínio no endereço IP (por meio de 
tabelas de pesquisa distribuídas). 
Um endereço IP especial 127.0.0.1 sempre se refere 
à sua própria máquina (chamado de localhost) e 
pode ser usado para teste local de loopback.
O TCP (Transmission Control Protocol) é um pro-
tocolo da camada de transporte, responsável por 
estabelecer uma conexão entre duas máquinas. 
O TCP consiste em 2 protocolos: TCP e UDP (User 
Datagram Package). O TCP é confiável, cada pacote 
possui um número de sequência e é esperado uma 
resposta. Um pacote será retransmitido se não 
2828
for recebido pelo receptor. A entrega de pacotes é 
garantida no TCP. O UDP não garante a entrega de 
pacotes e, portanto, não é confiável. No entanto, o 
UDP possui menos sobrecarga de rede e pode ser 
usado para aplicativos como streaming de vídeo e 
áudio, em que a confiabilidade não é crítica.
O UDP é um protocolo de comunicação que faci-
lita a troca de mensagens entre dispositivos de 
computação em uma rede. É uma alternativa ao 
protocolo de controle de transmissão (TCP). Em 
uma rede que usa o protocolo da Internet (IP), às 
vezes é referido como UDP/IP.
O UDP divide as mensagens em pacotes, chamados 
datagramas, que podem ser encaminhados pelos 
dispositivos na rede para o processo/servidor de 
destino. Embora o UDP não numere ou remonte 
os datagramas, ele inclui números de porta no 
cabeçalho do datagrama que ajudam a distinguir 
diferentes solicitações do usuário e um recurso 
de soma de verificação opcional que pode ajudar 
a verificar a integridade dos dados transferidos.
O TCP surgiu como o protocolo dominante usado 
para a maior parte da conectividade da Internet 
devido à sua capacidade de quebrar grandes con-
juntos de dados em pacotes individuais, verificar e 
reenviar pacotes perdidos e remontar os pacotes na 
sequência correta. Mas esses serviços adicionais 
2929
têm um custo em termos de latência e sobrecarga 
de dados adicionais.
O TCP multiplexa aplicativos em uma máquina IP. 
Para cada máquina IP, o TCP suporta até 65536 
portas (ou soquetes), variando este número de 0 a 
65535. Um aplicativo, como por exemplo o HTTP, 
executa (ou escuta) em um número de porta es-
pecífico para solicitações de entrada. A porta 0 a 
1023 é pré-atribuída a protocolos populares, por 
exemplo, HTTP em 80, FTP em 21, Telnet em 23, 
SMTP em 25, NTPN em 119 e DNS em 53. A porta 
1024 e as demais superiores, estão disponíveis 
para os usuários.
Embora a porta TCP 80 seja pré-atribuída ao HTTP 
como padrão, isso não proíbe de executar um 
servidor HTTP em outro número de porta entre 
1024 e 65535, como 8000, 8080, inclusive estas 
portas são especialmente utilizadas para servidor 
de teste. Você também pode executar vários ser-
vidores HTTP na mesma máquina em diferentes 
números de porta.
Quando um cliente emite uma URL sem especificar 
explicitamente o número da porta, por exemplo http://
www.google.com.br, o navegador se conectará ao 
número da porta padrão 80 do host www.google.
com.br. Você precisa especificar explicitamente o 
número da porta na URL, por exemplo, http://www.
3030
google.com.br:8000 se o servidor estiver escutando 
na porta 8000 e não na porta 80 padrão.
Em contraste ao TCP, o UDP é considerado um 
protocolo sem conexão porque não exige que um 
circuito virtual seja estabelecido antes de ocorrer 
qualquer transferência de dados. O protocolo de 
comunicação apenas envia os pacotes, o que sig-
nifica que tem muito menos sobrecarga de largura 
de banda e latência. Com UDP, os pacotes podem 
seguir caminhos diferentes entre o remetente e o 
receptor e, como resultado, alguns pacotes podem 
ser perdidos ou recebidos fora de ordem.
Em resumo, para se comunicar por TCP/IP, é ne-
cessário saber o endereço IP ou nome do host e 
também o número da porta.
Em alguns casos, as mensagens transmitidas por 
HTTP podem falhar, conheça os motivos:
 y Erro do usuário
 y Mau funcionamento do navegador ou servidor 
da web
 y Erros na criação de páginas da web
 y Falhas temporárias na rede
Quando essas falhas ocorrem, o protocolo captura 
a causa da falha e reporta um código de erro de 
volta ao navegador. Os erros começam com um 
determinado número para indicar que tipo de erro é.
3131
Por outro lado, ao contrário do TCP, o UDP não 
garante que os pacotes chegarão aos destinos 
corretos. Isso significa que o UDP não se conecta 
diretamente ao computador receptor - o que o TCP 
faz. Em vez disso, ele envia os dados e depende 
dos dispositivos entre os computadores de envio 
e recebimento para obter corretamente os dados 
para onde deveriam ir.
O quadro 1 apresenta o comparativo entre TCP e 
UDP.
Tabela 1: Comparativo entre TCP e UDP
Características TCP Características UDP
Protocolo orientado à 
conexão Protocolo sem conexão
Protocolo mais utilizado na 
internet
Usado para streaming de 
vídeo, jogos e transmissões 
ao vivo
Garante que nenhum pacote 
esteja faltando e todos os 
dados enviadoscheguem ao 
destinatário
Permite a perda de pacotes
Envia os pacotes em ordem Os pacotes não são enviados em ordem
Mais lento e requer mais 
recursos
Mais rápido e precisa de me-
nos recursos
Adequado para aplica-
tivos que requerem alta 
confiabilidade
Adequado para aplicativos 
que precisam de transmissão 
rápida e eficiente
Fonte: Elaborado pelo autor
3232
Socket
Quando um processo necessita se conectar a uma 
rede local ou de área ampla, como a Internet, ele 
usa um componente de software denominado 
socket. O socket abre a conexão de rede para o 
programa, permitindo que os dados sejam lidos e 
gravados na rede TCP/IP. 
Os sockets são uma parte fundamental dos siste-
mas operacionais baseados em Unix e Windows. 
Eles tornam mais fácil para os desenvolvedores 
de software criar programas habilitados para rede. 
Em vez de construir conexões de rede do zero para 
cada programa que escrevem, os desenvolvedo-
res podem simplesmente incluir socket em seus 
programas. A vantagem é que seu servidor e seu 
cliente podem se comunicar sem a sobrecarga de 
uma solicitação HTTP. 
O processo baseado em socket é executado em 
dois computadores separados na rede TCP/IP, 
mas os sockets também podem ser usados para 
se comunicar localmente (interprocessos) em um 
único computador.
Os sockets permitem que os programas usem os 
comandos internos do sistema operacional para 
lidar com as funções de rede. Como são usados 
para vários protocolos de rede diferentes (ou seja, 
33
HTTP, FTP, entre outros), muitos soquetes podem 
ser abertos ao mesmo tempo.
Em uma comunicação, tudo o que for enviado por 
socket é recebido pela outra parte da conexão na 
mesma ordem em que foi transmitido. Logo, os 
sockets garantem a entrega do conteúdo. (HOP-
SON, 1997)
34
CONSIDERAÇÕES FINAIS
Aqui você pôde compreender que os sistemas distri-
buídos surgiram por acaso, de maneira involuntária 
graças ao avanço tecnológico em consequência 
da criação da internet e do desenvolvimento de 
processadores mais poderosos.
Você pôde conhecer as principais características 
de um sistema distribuído que são: a concorrência 
(vários clientes acessando o mesmo recurso ao 
mesmo tempo); a escalabilidade (a configuração 
dos recursos computacionais de acordo com o 
crescimento da carga de trabalho). Viu que a es-
calabilidade pode ser vertical (novos recursos são 
adicionados a um nó) e pode ser horizontal (novos 
nós são adicionados para cooperar entre eles).
Outras características vistas foram a tolerância 
a falhas (o sistema deve ter um comportamento 
que garanta a sua disponibilidade mesmo em 
caso de falhas, garantindo a continuidade dos 
negócios); transparência (os usuários não devem 
estar cientes da localização dos recursos), com 
relação aos tipos de transparência, temos a trans-
parência de acesso, transparência de migração, 
transparência de concorrência e transparência de 
replicação; característica de compartilhamento de 
recursos e, por fim, a última característica vista foi 
a heterogeneidade que está relacionada a enorme 
35
quantidade de diferentes tipos de hardwares e 
softwares trabalhando juntos na rede.
Depois vimos a arquitetura dos sistemas distribuídos 
que pode ser o tradicional modelo cliente-servidor, 
em que temos um centralizador (servidor) que 
recebe requisições do cliente e envia respostas; 
modelo de arquitetura peer-to-peer, em que não 
temos um centralizador e nem o conceito de 
cliente e servidor, assim todos os nós assumem 
o papel simultaneamente de cliente e servidor, se 
comunicando pela rede; depois vimos o caching 
que é um componente que armazena dados para 
solicitações futuras, de modo a agilizar a entrega 
de dados.
Por fim, vimos a comunicação entre processos que 
pode ser síncrona ou assíncrona. Na comunicação 
síncrona, as duas partes envolvidas (os dois pro-
cessos) funcionam juntas em tempo real, enquanto 
na comunicação assíncrona as duas partes não 
funcionam juntas em tempo real.
Referências Bibliográficas 
& Consultadas
ANENBAUM, A. S.; STEEN, M. V. Sistemas 
Distribuídos: Princípios e Paradigmas. 2. ed. 
São Paulo: Pearson, 2007. [Biblioteca Virtual]
COMER, D. E. Redes de Computadores e 
Internet. 6. ed. Porto Alegre: Bookman, 2016.
COULOURIS, G. Sistemas Distribuídos: 
Conceitos e Projeto. 5. ed. Porto Alegre: 
Bookman, 2013.
BENJAMIN, E. Concurrent programming for 
scalable web architectures. Open Access 
Repositorium der Universität Ulm. http://dx.doi.
org/10.18725/OPARU-2423. (2012)
BOND, M. E. Aprenda J2EE em 21 dias. São 
Paulo: Pearson, 2003. [Biblioteca Virtual]
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. 
Distributed systems: concepts and design. 5. 
ed. England: Addison Wesley, 2012.
DANTAS, M. Computação distribuída de 
alto desempenho: redes, clusters e grids 
computacionais. Rio de Janeiro: Axcel Books, 
2005.
DEITEL, P.; DEITEL, H. Java: como programar. 
10. ed. São Paulo: Pearson, 2017. [Biblioteca 
Virtual]
ERL, T. SOA: Princípios do Design de Serviço. 
São Paulo: Pearson, 2009. [Biblioteca Virtual]
FRIEDRICH, L. Apostila de sistemas 
distribuídos: fundamentos. Florianópolis: UFSC, 
2002.
HOPSON, K. C.; INGRAM, E. Desenvolvendo 
applets com java. Rio de Janeiro: Campus, 
1997.
ROMAM, E.; AMBLER, S. W.; JEWELL, T. 
Dominando Enterprise Javabeans. 4. ed. 
Porto Alegre: Bookman, 2008.
ROY, Peter Van HARIDI, Seif. Concepts, 
Techniques, and Models of Computer 
Programming. The MIT Press (2004)
SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. 
Fundamentos de Sistemas Operacionais. 9. 
ed. Rio de Janeiro: LTC, 2015.
TANENBAUM, A.; STEEN, M. A brief introduction 
to distributed systems. Computing 98, 
967–1009 (2016). https://doi.org/10.1007/
s00607-016-0508-7
	Introdução
	Sistema Distribuído
	Considerações finais
	Referências Bibliográficas & Consultadas