Unidade A - Princípios da arquitetura cliente-servidor

A.1. Princípios da arquitetura cliente-servidor

Os serviços de rede que estudaremos referem-se a softwares implementados a partir das especificações de protocolos da camada de aplicação do modelo TCP/IP que utilizam a arquitetura cliente/servidor. Nesta arquitetura temos hosts com funções bem definidas, sempre havendo um host chamado servidor, que atende a requisições dos demais hosts denominados clientes. A comunicação entre os clientes nunca é direta, mas mediada pelo servidor. Este geralmente é identificado por um endereço IP fixo, visto que se trata de um host que é frequentemente referenciado pelos demais clientes de rede.

O servidor e clientes de rede comunicam-se através de mensagens. Para fazer uso de serviço, o cliente envia mensagens ao servidor que responde a estas solicitações com novas mensagens (Figura A.1.1). Essas são formatadas de acordo com as especificações do protocolo de aplicação, conhecidas como RFCs (Request for comments) , o que garante às mesmas a independência da plataforma utilizada, seja do fabricante do software provedor do serviço ou do sistema operacional utilizado por ambos. O servidor Web é o exemplo mais comum: ele utiliza o protocolo HTTP (HyperText Transfer Protocol ou Protocolo de Transferência de Hipertexto) que garante que os arquivos de hipertexto sejam transferidos e compreendidos pelos clientes (como o Firefox ou Internet Explorer) independentemente do software servidor utilizado (Apache ou IIS).

 

 

Todos os protocolos de aplicação estão documentados em RFCs (Request for comments) mantidos pela Internet Engineering Task Force (IETF), que podem ser consultadas no seguinte endereço: http://www.ietf.org/

 

 

Os protocolos de aplicação são associados a protocolos de transporte. Serviços orientados à conexão, como o HTTP, por exemplo, geralmente se encontram associados ao protocolo TCP (Transmission Control Protocol), já os serviços que exijam rapidez a na resposta as requisições, como o DHCP, encontram-se associados a protocolos não orientados à conexão como o UDP (User Datagram Protocol). A interface entre os protocolos de transporte de aplicação ocorre através de portas de comunicação. Trata-se de um número de 16 bits que permite realizar o encaminhamento das requisições de clientes aos protocolos de aplicação correspondentes. Para cada protocolo de transporte existem 65.535 portas disponíveis (216 -1). Quando a mensagem chega ao destinatário, o protocolo transporte encarrega-se de encaminhá-lo à aplicação correspondente, que é indicada por sua porta de comunicação. Por exemplo, sempre que um cliente de rede quiser acessar uma pagina web armazenada em um servidor HTTP, enviará uma requisição à porta 80. Ao receber essa solicitação, o servidor a encaminhará ao serviço que responde por esta porta de comunicação. Caso outro cliente solicite o mesmo acesso, o processo se repetirá, entretanto, serão criados processos individuais no servidor, a partir dos quais será possível controlar as solicitações dos diferentes clientes. Se este mesmo servidor também prover acesso remoto através do serviço SSH (Secure Shell), deverá receber solicitações pela porta 22 que serão encaminhadas ao serviço correspondente.

Cada solicitação realizada pelo cliente demanda da eleição de uma porta de comunicação local pela qual receberá a resposta do servidor. Por exemplo, para realizar o acesso remoto, o cliente envia uma mensagem ao servidor, requisitando esse serviço por meio da porta 22. Para realizar o envio dessa mensagem, o cliente dinamicamente abre uma porta de comunicação (1001, por exemplo) por meio da qual espera receber a resposta da sua requisição. Essa informação é adicionada ao cabeçalho da mensagem que é enviada ao servidor, que também contém o endereço IP do cliente. Após realizar o processamento dessa requisição, o servidor envia a resposta para o cliente, indicando o seu endereço lógico e a porta pela qual receberá esta mensagem. A figura A.1.2 procura exemplificar esse processo.

 

Nessa figura encontramos três clientes de rede solicitando serviços ao servidor: dois requisitam o serviço HTTP (porta 80) e um acesso remoto através de SSH (porta 22). Ao realizar essa requisição cada um desses clientes elege localmente uma porta de comunicação (no exemplo as portas 1001 a 1003), pela qual deve receber as respostas do servidor. Na mensagem enviada constam os endereços IP do host de origem, porta de comunicação de origem, o endereço IP do servidor e a porta de comunicação do serviço que está sendo solicitado. Ao receber essa requisição, o servidor a encaminha para a aplicação correspondente que a processa e encaminha o resultado ao cliente, com base nas informações de endereçamento contidas na mensagem enviada.

 

 

A distribuição das portas de comunicação é controlada pela Internet Assigned Numbers Authority (IANA). Pode-se consultar as portas documentadas no endereço: http://www.iana.org/assignments/port-numbers

 

 

O processo descrito anteriormente pode ser facilmente identificado através de um utilitário conhecido como netstat (disponível nos sistemas operacionais Linux e Windows). Esse utilitário permite verificar as conexões estabelecidas entre hosts, listando as portas de comunicação que estão sendo utilizadas. Por exemplo: para consultar as portas TCP e UDP utilizadas em um host, respectivamente, são os seguintes comandos:

#netstat –na –p TCP

#netstat –na –p UDP

Além dessas ferramentas, que são nativas dos sistemas operacionais citados, também é possível acompanhar a execução dos serviços de rede, utilizando softwares analisadores de rede que mapeiam todo o processo de execução de determinado serviço, permitindo detectar eventuais falhas.

A.1.2. Endereçamento lógico dos hosts de rede

Para realizar o identificação lógica dos hosts utilizaremos o protocolo IPv4, cujo endereço é composto por 32 bits, estando o mesmo associado a uma máscara de sub-rede, que determinará quantos desses bits identificam a rede lógica na qual o host está inserido e quantos bits identificam o host nessa rede. Por exemplo: um host com endereço IP 192.168.1.10, cuja mascara é 255.255.255.0, assinala que o mesmo está inserido na sub-rede 192.168.1.0 onde é possível endereçar 254 hosts (192.168.1.1 a 192.168.1.254), sendo que o endereço 10 o identifica.

Os endereços IP também podem ser identificados pela notação CIDR (Classless Inter-Domain Routing), na qual se identifica numericamente quantidade de bits que esta sendo utilizada para identificar a rede lógica a qual esse endereço pertence. Por exemplo: o mesmo endereço citado anteriormente pode ser descrito da seguinte forma: 192.168.1.10/24 onde o número 24 identifica quantos bits (dos 32) estão sendo utilizados para identificar a rede. Consequentemente, teremos outros 8 bits para endereçar hosts nessa rede (28-2=254). Como veremos no decorrer da disciplina, os serviços de rede suportam as duas notações.

O endereçamento lógico, proporcionado pelo protocolo IP, determina que a troca de mensagens poderá ocorrer somente entre os hosts de uma mesma faixa de endereços (roteamento direto) ou, caso o destinatário não esteja na nesta rede, a mensagem deve ser encaminhada para o gateway da rede, que realizara o encaminhamento dessa mensagem para o destinatário que atenda pelo endereço solicitado (roteamento indireto). O gateway da rede é o hardware a interligar redes e rotear as requisições que não se destinam à rede local.

A eleição do tipo de roteamento a ser realizado leva em consideração as rotas que são conhecidas por cada host registradas localmente em uma tabela de roteamento. Nela se encontram as informações das rotas para as sub-redes locais e externas. O gateway, por exemplo, geralmente é designado como rota padrão, ou seja, o destino das mensagens quando se identifica um roteamento indireto. Você pode verificar as rotas disponíveis no host Debian através do comando:

#route

E no Windows com o comando:

C:\> route print

Para gerenciar as configurações de rede, os sistemas operacionais Windows e Linux possuem utilitários específicos. No Windows temos o ipconfig que lista no prompt de comando as configurações do cliente de rede:

C:\> ipconfig

Para uma listagem mais detalhada das configurações de rede do host é necessário adicionar o parâmetro all:

C:\> ipconfig /all

Caso o host Windows seja cliente DHCP podemos utilizar esse comando para realizar a renovação da concessão de endereço IP:

C:\> ipconfig /release #libera a as configurações de endereço IP

C:\> ipconfig /renew #renova a concessão de endereço IP

O utilitário de rede padrão das distribuições Linux é o ifconfig. Através deste é possível consultar as configurações da interfaces de rede:

# ifconfig

Por meio desse utilitário também é possível habilitar, desabilitar e realizar a configuração IP de uma interface de rede. Veja os exemplos:

#ifconfig eth0 down

#ifconfig eth0 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.292.255

#ifconfig eth0 up

No caso de clientes DHCP, a renovação de endereços de endereços IP, no Debian, também pode ser feita através do comando:

# dhclient

Além desses utilitários, que são executados em modo texto, ambos sistemas operacionais possuem interfaces gráficas, que permitem realizar as configurações das interfaces de rede.

Problemas de conectividade são comuns em rede de computadores e faz parte das atribuições do administrador da rede identificar onde estão ocorrendo. Os sistemas operacionais possuem o utilitário ping que auxilia nessa tarefa. Elaborado a partir das especificações do protocolo ICMP (Internet Control Message Protocol), o ping envia um pedido de resposta (echo request) para um determinado host que retorna uma mensagem de resposta (echo response), cujo processo gera um relatório que é exibido na tela indicando a existência ou não de conectividade com o host em questão. Veja o exemplo:

#ping 192.168.1.10

Disparando 192.168.1.10 com 32 bytes de dados:
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128

Muitas vezes, o problema de conectividade pode estar na interface de rede local e não no host remoto. Podemos verificar se a interface respondendo a requisições testando-a por meio do endereço reservado de loopback:

#ping 127.0.0.1

Disparando 127.0.0.1 com 32 bytes de dados:
Resposta de 127.0.0.1: bytes=32 tempo<1ms TTL=128
Resposta de 127.0.0.1: bytes=32 tempo<1ms TTL=128
Resposta de 127.0.0.1: bytes=32 tempo<1ms TTL=128
Resposta de 127.0.0.1: bytes=32 tempo<1ms TTL=128

 

 

O PING é um utilitário eficaz na resolução de problemas de conectividade. Muitas vezes nos deparamos com situações onde identificamos que um determinado serviço aparentemente não está funcionando e voltamos a nossa atenção para o processo de configuração deste. Em alguns casos, o problema não está no serviço, mas na falta de conectividade entre o host cliente e servidor.