Introdução
No mundo de hoje, não se pode falar de redes sem falar do
TCP/IP. O conjunto de protocolos originalmente desenvolvido pela
Universidade da Califórnia em Berkeley, sob contrato para
o Departamento de Defesa dos EUA, se tornou o conjunto de protocolos
padrão das redes locais e remotas, suplantando conjuntos de
protocolos bancados por pesos pesados da indústria, como a
IBM (SNA), Microsoft (NetBIOS/NetBEUI) e Novell (IPX/SPX).
O grande motivo de todo este sucesso foi justamente o fato do TCP/IP
não ter nenhuma grande empresa associada ao seu desenvolvimento.
Isto possibilitou a sua implementação e utilização
por diversas aplicações em praticamente todos os tipos
de hardware e sistemas operacionais existentes.
Mesmo antes do boom da Internet o TCP/IP já era o protocolo
obrigatório para grandes redes, formadas por produtos de muitos
fornecedores diferentes, e havia sido escolhido pela Microsoft como
o protocolo preferencial para o Windows NT, devido às limitações
técnicas do seu próprio conjunto de protocolos, o NetBEUI.
Entretanto, ao contrário dos procolos proprietários
para redes locais da Microsoft e da Novell, que foram desenhados
para serem praticamente "plug and play", as necessidades que orientaram
o desenvolvimento do TCP/IP obrigaram ao estabelecimento de uma série
de parametrizações e configurações que
devem ser conhecidas pelo profissional envolvido com instalação,
administração e suporte de redes.
As Pilhas de Protocolos
Quem já estudou mais a fundo a documentação
de produtos de redes ou participou de cursos mais específicos
certamente se deparou com o "Modelo OSI de 7 Camadas". Todos os softwares
de redes são baseados em alguma arquitetura de camadas, e
normalmente nos referimos a um grupo de protocolos criado para funcionar
em conjunto como uma pilha de protocolos (em inglês, protocol
stack, por exemplo the TCP/IP stack). O termo "pilha" é utilizado
porque os protocolos de uma dada camada normalmente interagem somente
com os protocolos das camadas imediatamente superior e inferior.
O modelo de pilha traz a vantagem de modularizar naturalmente o
software de redes, permitindo a sua expansão com novos recursos,
novas tecnologias ou aperfeiçoamentos sobre a estrutura existente,
de forma gradual.
Entretanto, o Modelo OSI é uma modelo conceitual, e não
a arquitetura de uma implementação real de protocolos
de rede. Mesmo os protocolos definidos como padrão oficial
pelo ISO - International Standards Organization - a entidade criadora
do modelo OSI, não foram projetados e construídos segundo
este modelo.
Por isso, vamos utilizar nesta aula uma simplificação
do modelo OSI. O importante é entender o conceito de pilhas
de protocolos, pelo qual cada camada realiza uma das funções
necessárias para a comunicação em rede, tornando
possível a comunicação em redes de computadores
utilizando várias tecnologias diferentes.
O modelo de pilha de 4 camadas do TCP/IP
O TCP/IP foi desenhado segundo uma arquitetura de pilha, onde diversas
camadas de software interagem somente com as camadas acima e abaixo.
Há diversas semelhanças com o modelo conceitual OSI
da ISO, mas o TCP/IP é anterior à formalização
deste modelo e portanto possui algumas diferenças.
O nome TCP/IP vem dos nomes dos protocolos mais utilizados desta
pilha, o IP (Internet Protocol) e o TCP (Transmission Control Protocol).
Mas a pilha TCP/IP possui ainda muitos outros protocolos, dos quais
veremos apenas os mais importantes, vários deles necessários
para que o TCP e o IP desempenhem corretamente as suas funções.
Visto superficialmente, o TCP/IP possui 4 camadas, desde as aplicações
de rede até o meio físico que carrega os sinais elétricos
até o seu destino:
4. Aplicação (Serviço) |
FTP, TELNET, LPD, HTTP, SMTP/POP3, NFS, etc. |
3. Transporte |
TCP, UDP |
2. Rede |
IP |
1. Enlace |
Ethernet, PPP, SLIP |
Além das camadas propriamente ditas, temos uma série
de componentes, que realizam a interface entre as camadas:
Aplicação / Transporte |
DNS, Sockets |
Rede / Enlace |
ARP, DHCP |
Vamos apresentar agora uma descrição da função
de cada camada do TCP/IP:
1. Os protocolos de enlace tem a função de fazer com
que informações sejam transmitidas de um computador
para outro em uma mesma mídia de acesso compartilhado (também
chamada de rede local) ou em uma ligação ponto-a-ponto
(ex: modem). Nada mais do que isso. A preocupação destes
protocolos é permitir o uso do meio físico que conecta
os computadores na rede e fazer com que os bytes enviados por um
computador cheguem a um outro computador diretamente desde que haja
uma conexão direta entre eles.
2. Já o protocolo de rede, o Internet Protocol (IP), é responsável
por fazer com que as informações enviadas por um computador
cheguem a outros computadores mesmo que eles estejam em redes fisicamente
distintas, ou seja, não existe conexão direta entre
eles. Como o próprio nome (Inter-net) diz, o IP realiza a
conexão entre redes. E é ele quem traz a capacidade
da rede TCP/IP se "reconfigurar" quando uma parte da rede está fora
do ar, procurando um caminho (rota) alternativo para a comunicação.
3. Os protocolos de transporte mudam o objetivo, que era conectar
dois equipamentos, para' conectar dois programas. Você pode
ter em um mesmo computador vários programas trabalhando com
a rede simultaneamente, por exemplo um browser Web e um leitor de
e-mail. Da mesma forma, um mesmo computador pode estar rodando ao
mesmo tempo um servidor Web e um servidor POP3. Os protocolos de
transporte (UDP e TCP) atribuem a cada programa um número
de porta, que é anexado a cada pacote de modo que o TCP/IP
saiba para qual programa entregar cada mensagem recebida pela rede.
4. Finalmente os protocolos de aplicação são
específicos para cada programa que faz uso da rede. Desta
forma existe um protocolo para a conversação entre
um servidor web e um browser web (HTTP), um protocolo para a conversação
entre um cliente Telnet e um servidor (daemon) Telnet, e assim em
diante. Cada aplicação de rede tem o seu próprio
protocolo de comunicação, que utiliza os protocolos
das camadas mais baixas para poder atingir o seu destino.
Pela figura acima vemos que existem dois protocolos de transporte
no TCP/IP. O primeiro é o UDP, um protocolo que trabalha com
datagramas, que são mensagens com um comprimento máximo
pré-fixado e cuja entrega não é garantida. Caso
a rede esteja congestionada, um datagrama pode ser perdido e o UDP
não informa as aplicações desta ocorrência.
Outra possibilidade é que o congestionamento em uma rota da
rede possa fazer com que os pacotes cheguem ao seu destino em uma
ordem diferente daquela em que foram enviados. O UDP é um
protocolo que trabalha sem estabelecer conexões entre os softwares
que estão se comunicando.
Já o TCP é um protocolo orientado a conexão.
Ele permite que sejam enviadas mensagens de qualquer tamanho e cuida
de quebrar as mensagens em pacotes que possam ser enviados pela rede.
Ele também cuida de rearrumar os pacotes no destino e de retransmitir
qualquer pacote que seja perdido pela rede, de modo que o destino
receba a mensagem original, da maneira como foi enviada.
Agora, vamos aos componentes que ficam na interface entre os níveis
3 e 4 e entre os níveis 1 e 2.
O Sockets é uma API para a escrita de programas que trocam
mensagens utilizando o TCP/IP. Ele fornece funções
para testar um endereço de rede, abrir uma conexão
TCP, enviar datagramas UDP e esperar por mensagens da rede. O Winsockets,
utilizado para aplicações Internet em Windows é nada
mais do que uma pequena variação desta API para acomodar
limitações do Windows 3.1. No Windows NT e Win95 pode
ser usada a API original sem problemas.
O Domain Name Service (DNS), que será visto com maiores detalhes
mais adiante, fornece os nomes lógicos da Internet como um
todo ou de qualquer rede TCP/IP isolada.
Temos ainda o ARP realiza o mapeamento entre os endereços
TCP/IP e os endereços Ethernet, de modo que os pacotes possam
atingir o seu destino em uma rede local (lembrem-se, no final das
contas quem entrega o pacote na rede local é o Ethernet, não
o TCP ou o IP).
Por fim, o DHCP permite a configuração automática
de um computador ou outro dispositivo conectado a uma rede TCP/IP,
em vez de configurarmos cada computador manualmente. Mas, para entender
o porque da necessidade do DHCP, temos que entender um pouco mais
do funcionamento e da configuração de uma rede TCP/IP.
Endereçamento e roteamento
Em uma rede TCP/IP, cada computador (ou melhor, cada placa de rede,
caso o computador possua mais do que uma) possui um endereço
numérico formado por 4 octetos (4 bytes), geralmente escritos
na forma w.x.y.z. Além deste Endereço IP, cada computador
possui uma máscara de rede (network mask ou subnet mask),
que é um número do mesmo tipo mas com a restrição
de que ele deve começar por uma seqüência contínua
de bits em 1, seguida por uma seqüência contínua
de bits em zero. Ou seja, a máscara de rede pode ser um número
como 11111111.11111111.00000000.00000000 (255.255.0.0), mas nunca
um número como 11111111.11111111.00000111.00000000 (255.255.7.0).
A máscara de rede serve para quebrar um endereço IP
em um endereço de rede e um endereço de host. Todos
os computadores em uma mesma rede local (fisicamente falando, por
exemplo, um mesmo barramento Ethernet) devem ter o mesmo endereço
de rede, e cada um deve ter um endereço de host diferente.
Tomando-se o endereço IP como um todo, cada computador em
uma rede TCP/IP (inclusive em toda a Internet) possui um endereço
IP único e exclusivo.
O InterNIC controla todos os endereços IP em uso ou livres
na Internet, para evitar duplicações, e reserva certas
faixas de endereços chamadas de endereços privativos
para serem usados em redes que não irão se conectar
diretamente na Internet.
Quando o IP recebe um pacote para ser enviado pela rede, ele quebra
o endereço destino utilizado a máscara de rede do computador
e compara o endereço de rede do destino com o endereço
de rede dele mesmo. Se os endereços de rede forem iguais,
isto significa que a mensagem será enviada para um outro computador
na mesma rede local, então o pacote é repassado para
o protocolo de enlace apropriado (em geral o Ethernet). Se os endereços
forem diferentes, o IP envia o pacote para o default gateway, que é nada
mais do que o equipamento que fornece a conexão da rede local
com outras redes. Este equipamento pode ser um roteador dedicado
ou pode ser um servidor com múltiplas placas de rede, e se
encarrega de encaminhar o pacote para a rede local onde está o
endereço IP do destino.
É importante que o endereço IP do default gateway
esteja na mesma subnet que o a máquina sendo configurada,
caso contrário ela não terá como enviar pacotes
para o default gateway e assim só poderá se comunicar
com outros hosts na mesma subnet.
Resumindo um computador qualquer em uma rede TCP/IP deve ser configurado
com pelo menos estes três parâmetros: o seu endereço
IP exclusivo, a sua máscara de rede (que deve ser a mesma
utilizada pelos demais computadores na mesma LAN) e o endereço
IP do default gateway.
Como se processa a comunicação em uma rede TCP/IP
Digamos que o host com o endereço IP é 172.16.1.101
deseje enviar um pacote para o endereço 172.16.2.102. Caso
a máscara de rede seja 255.255.0.0, o AND binário do
enredeço fonte será 172.16.0.0, e o AND do endereço
destino será 172.16.0.0, indicando que ambos possuem o mesmo
endereço de rede e portanto estão diretamente conectados
no nível de enlace.
Neste caso, o nível IP envia um pacote ARP pela rede Ethernet
para identificar qual o endereço Ethernet do host cujo IP é 172.16.2.2.
Este pacote é enviado como um broadcast, de modo que todos
os hosts conectados no mesmo segmento Ethernet receberão o
pacote, e o host configurado para o endereço desejado irá responder
ao pacote ARP indicando qual o seu endereço Ethernet. Assim
o IP pode montar o pacote Ethernet corretamente endereçado
e enviar o pacote para o seu destino.
Agora digamos que a máscara de rede não fosse 255.255.0.0,
mas sim 255.255.255.0. Neste caso, os endereços de rede da
origem e destino seriam respectivamente 172.16.1.0 e 172.16.2.0.
Como os endereços de rede são diferentes, isto significa
que não temos conectividade direta (no nível de enlace)
entre os dois hosts, portanto o pacote deverá ser entregue
por intermédio de um roteador, que é o default gateway.
Digamos que o default gateway seja 172.16.1.1 (observe que o endereço
de rede do default gateway é 172.16.1.0, o mesmo do nosso
host de origem). Então o host irá enviar um pacote
ARP pela rede para descobrir o endereço Ethernet do default
gateway, e enviará o pacote para este.
Ao receber o pacote, o default gateway irá verificar que
o endereço IP de destino é o IP de outro host que não
ele, e irá verificar qual o endereço de rede do destino.
Pode ser que o pacote esteja endereçado para uma rede local
na qual o default gateway tenha uma conexão direta, ou pode
ser que o default gateway tenha que direcionar o pacote para um outro
roteador mais próximo do destino final. De qualquer forma,
o default gateway segue o mesmo processo de gerar o endereço
de rede utilizando a netmask, e em seguida enviar um pacote ARP pedindo
o endereço Ethernet do próximo host a receber o pacote.
A diferença é que um roteador não tem um default
gateway, mas sim uma tabela de roteamento, que diz quais endereços
de rede podem ser alcançados por quais roteadores.
Notem que este exemplo considerou apenas a comunicação
entre dois equipamentos, não entre dois programas. O nosso
exemplo ficou apenas no nível de rede da pilha TCP/IP, mas
acima dela o processo é simples: o IP verifica que tipo de
pacote foi recebido (TCP, UDP ou outro) e repassa o pacote para o
protocolo apropriado.
O protocolo de transporte irá então verificar o número
de porta contido no pacote e qual programa está associado
aquela porta. Este programa será notificado da chegada de
um pacote, e será responsabilidade dele decodificar e utilizar
de alguma forma as informações contidas no pacote.
Como testar uma rede TCP/IP
Caso você venha a ter problemas de comunicação,
todas as pilhas TCP/IP, independente de qual sistema operacional,
trazem o utilitário ping para testar a conectividade entre
dois hosts TCP/IP. Siga o seguinte procedimento:
1. ping 127.0.0.1. Este endereço IP é um loopback,
ou seja, não vai para a rede, fica no computador que originou
a mensagem. Se o ping acusar o recebimento da resposta, significa
que a pilha TCP/IP está instalada e ativa no computador onde
foi realizado o teste. (Somente a título de curiosidade, você pode
usar o loopback do TCP/IP para desenvolver aplicações
de rede em uma máquina stand-alone, sem nenhum tipo de conexão
de rede disponível.)
2. ping meu_ip. Tendo comprovado que o TCP/IP está ativo
na máquina origem, vamos enviar uma mensagem para ela mesmo,
para verificar se a placa de rede (ou modem) estão ativos
no que diz respeito ao TCP/IP. Aqui você testa apenas o driver
da sua placa de rede, não a placa em si nem os cabos da rede.
3. ping ip_na_minha_rede. Agora vamos testar a comunicação
dentro da rede local onde o computador de origem está localizado.
Garanta que o computador dono do ip_na_minha_rede está com
o TCP/IP e a sua placa de rede ativos, segundo os dois testes acima.
Se não funcionar, você tem um problema de cabos ou em
uma placa de rede, ou simplesmente as suas máscaras de rede
e endereços IP estão incorretos.
4. ping ip_do_default_gateway. Se a comunicação dentro
da minha rede local está OK, temos que verificar se o default
gateway da minha rede está no ar, pois todos os pacotes que
saem da minha rede local passam por ele.
5. ping ip_do_outro_lado. Digamos que o meu default gateway esteja
diretamente conectado na rede destino. Eu tenho que testar se a interface
de rede que liga o default gateway a esta rede está no ar.
Então eu dou um ping no endereço IP desta placa. Se
o default gateway não estiver diretamente conectado na rede
destino, eu repito os passos (4) e (5) para cada equipamento que
esteja no caminho entre origem e destino.
6. ping ip_do_destino. Sabendo que a outra rede pode ser alcançada
via TCP/IP, resta saber se eu consigo me comunicar com o computador
desejado.
Serviços de nomeação
Até agora nós estamos vendo a comunicação
em rede utilizando apenas os endereços IP. Imagine o seu cartão
de visitas, indicando a sua home-page como: "164.85.31.230". Imagine-se
ainda com uma lista contendo dezenas de números como esse
pendurada na parede junto ao seu computador, para quando você precisar
se conectar a um dos servidores da sua empresa.
No início do desenvolvimento do TCP/IP, cada computador tinha
um arquivo de hosts que listava os nomes dos computadores e os endereços
IP correspondentes. Na Internet, certamente seria inviável
manter estes arquivos, não só pelo tamanho que eles
teriam mas também pela dificuldade em se manter milhões
de cópias atualizadas. Logo foi desenvolvido o DNS, pelo qual
diversos servidores mantém um banco de dados distribuído
com este mapeamento de nomes lógicos para endereços
IP.
O DNS funciona de forma hierárquica. Vejam um endereço
Internet típico, como www.petrobras.com.br. Inicialmente,
separamos o primeiro nome (até o primeiro ponto), "www", que é o
nome de um computador ou host, e o restante do endereço, "petrobras.com.br",
que é o nome da organização, ou o nome do domínio.
Por favor, não confundam o conceito de domínios em
endereços Internet com o conceito de domínios em uma
Rede Microsoft. Não existe nenhuma relação entre
eles.
O domínio petrobras.com.br possui o seu servidor DNS, que
contém os nomes dos computadores (e endereços IP correspondentes)
sob a sua autoridade. E ele sabe o endereço IP do servidor
DNS do domínio que está acima dele, .com.br. Os computadores
na Petrobras fazem todas as consultas por endereços IP ao
servidor do seu domínio, e ele repassa as consultas a outros
servidores DNS quando necessário. Os clientes necessitam saber
apenas sobre o servidor do seu domínio, e mais nada.
Já o servidor DNS do domínio .com.br sabe os endereços
IP de todos os servidores dos domínios a ele subordinados
(por exemplo, texaco.com.br, mantel.com.br, etc) e o endereço
IP do servidor acima dele (domínio .br, o domínio que
engloba todo o Brasil). Por fim, o servidor DNS do domínio
br sabe os endereços de todos os servidores dos domínios
a ele subordinados (.com.br, .gov.br, etc) e o endereço do
servidor DNS do InterNIC, que é o servidor DNS raiz de toda
a Internet.
Uma consulta de uma aplicação por um endereço
IP sobe por toda a hierarquia de servidores DNS, até o domínio
comum de nível mais baixo que seja comum a origem e destino,
ou até chegar ao servidor do InterNIC, e depois desce na hierarquia
até o domínio onde está o computador destino.
A resposta volta pelo caminho inverso, porém cada servidor
DNS mantém um cache das respostas recebidas, de modo que uma
nova requisição pelo mesmo nome não necessitará percorrer
novamente todos os servidores DNS.
Pode parecer que é realizado um trabalho muito grande somente
para obter um endereço IP, mas o processo como um todo é rápido
(quem navega na Web sabe bem disso), e ele possibilita que milhares
de organizações integrem suas redes a um custo aceitável
e com grande autonomia. Quando você acrescenta uma máquina
no seu domínio, você não precisa comunicar ao
InterNIC e às redes vizinhas, basta registrar o novo computador
no seu servidor DNS.
O protocolo DHCP
Recapitulando, cada estação ou servidor em uma rede
TCP/IP típica deverá ser configurada com os seguintes
parâmetros:
Endereço
IP
Máscara
de Rede
Default
Gateway
Além disso, caso a sua rede utilize um servidor DNS o seu
endereço IP também deve ser configurado em cada host.
Em uma rede com dezenas ou mesmo centenas de computadores, manter
o controle dos endereços IP já utilizados pelas máquinas
pode ser um pesadelo. É muito fácil errar o endereço
IP de uma máquina, ou errar a máscara de rede ou endereço
do default gateway, e geralmente é muito difícil identificar
qual a máquina onde existe um erro de configuração
do TCP/IP.
Para resolver esses problemas você poderá instalar
um servidor DHCP na sua rede local (ou melhor, um servidor DHCP para
cada subnet, logo veremos porque) e deixar que ele forneça
estes parâmetros para as estações da rede.
Se você tem uma pilha TCP/IP instalada que suporta o protocolo
DHCP, você pode configurar cada estação para
usar o DHCP e ignorar todos esses parâmetros. Na inicialização
da pilha TCP/IP, a estação irá enviar um pacote
de broadcast para a rede (um broadcast é um pacote que é recebido
por toda a rede) e o servidor DHCP, ao receber este pacote, enviará os
parâmetros de configuração para a estação.
Aqui temos comunicação apenas no nível de enlace
(pois o TCP/IP ainda não foi completamente inicializado),
e portanto não temos a função de roteamento
habilitada. Por isso o servidor DHCP deve estar na mesma LAN física
onde está a estação que será inicializada.
Normalmente os servidores tem sua configuração realizada
manualmente, pois o endereço IP deve concordar com o endereço
IP cadastrado no servidor DNS.
O servidor DHCP é configurado com uma faixa de endereços
IP que ele pode fornecer aos clientes. Inicialmente, todos os endereços
estão disponíveis. Quando uma estação é inicializada,
ela envia o broadcast pedindo pela sua configuração,
e o servidor DHCP reserva um endereço para ela (que deixa
de estar disponível) e registra o endereço Ethernet
para o qual o endereço foi reservado. Então ele envia
uma resposta contendo este endereço e os demais parâmetros
listados acima.
O endereço é apenas "emprestado" pelo servidor DHCP,
que registra também o momento do empréstimo e a validade
deste empréstimo. No próximo boot, a estação
verifica se o empréstimo ainda é válido e se
não pede um novo endereço (que pode até ser
o mesmo, por coincidência). Se o empréstimo estiver
em metade da sua validade, o cliente pede uma renovação
do empréstimo, o que aumenta a sua validade. E a cada inicialização,
o cliente verifica se o endereço emprestado ainda é dela,
pois ela pode ter sido deslocada para uma outra LAN, onde a configuração
do TCP/IP é diferente, ou por qualquer motivo o Administrador
da Rede pode ter forçado a liberação do endereço
que havia sido emprestado.
O servidor verifica periodicamente se o empréstimo não
expirou, e caso afirmativo coloca o endereço novamente em
disponibilidade. Desta forma, a não ser que você tenha
um número de estações muito próximo ao
número de endereços IP reservados para o servidor DHCP,
você pode acrescentar, retirar ou mover estações
pela sua rede sem se preocupar em configurar manualmente as pilhas
TCP/IP a cada mudança.
Geralmente o DHCP é utilizado somente para configurar estações
cliente da rede, enquanto que os servidores são configurados
manualmente. Isso porque o endereço IP do servidor deve ser
conhecido previamente (para configuração do default
gateway, para configuração do arquivo de hosts, para
configuração de DNS, configuração de
firewall, etc). Se fosse utilizado o DHCP, o endereço do servidor
poderia ser diferente em cada boot, obrigando a uma série
de mudanças de configuração em diversos nós
da rede.
Você também pode configurar o servidor DHCP para entregar
aos clientes outras informações de configuração,
como o endereço do servidor DNS da rede. O Linux pode operar
tanto como cliente quanto como servidor DHCP, entretanto não
veremos estas configurações no nosso curso.