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.
Esta primeira aula tem por objetivo passar os conhecimentos teóricos necessários para tornar os alunos aptos a seguirem as aulas seguintes, que explicarão como implementar redes TCP/IP no Windows 95, Windows NT, Netware e outros sistemas populares no mercado. Ao contrário da maioria dos livros “introdutórios” sobre TCP/IP que vemos nas livrarias e universidades, não vamos nos preocupar com os detalhes sobre formatos de pacotes e algoritmos empregados na implementação do protocolo. Vamos nos preocupar sim com os conhecimentos realmente necessários para se trabalhar corretamente com os vários produtos existentes no mercado.
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
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.
