( Publicado originalmente no e-zine CTRL-C nº 01, de novembro/99 )
Para possibilitar a interconexão de diferentes equipamentos informáticos através das diferentes redes de comunicações faz-se necessário estabelecer uma série de normas que incluem os requisitos físicos e os procedimentos a serem seguidos. Disso se encarregam diversos organismos internacionais, entre os quais a ISO (International Standard Organization) e o CCITT (Consultive Committe for International Telephone and Telegraph).
Antes das normatizações, cada fabricante estabelecia suas próprias normas ou protocolos, o que impossibilitava a comunicação entre equipamentos de diferentes fabricantes.
Assim, podemos definir como protocolo de comunicações o conjunto de convenções e procedimentos que regulamentam a transmissão de dados entre diferentes equipamentos, completamente ou em alguns de seus aspectos. Ou seja, graças ao protocolo de comunicações é que os computadores conseguem se comunicar, “falando a mesma língua”.
A organização ISO definiu a normatização de comunicações entre equipamentos informáticos estabelecendo sete níveis no que se refere à arquitetura:
1. Físico – define as características dos equipamentos e requisitos para a realização das ligações entre um terminal e um modem.
2. Ligação/Enlace – define os meios e procedimentos para a transmissão de blocos de informação e controle dos possíveis erros que possam ocorrer.
3. Rede – define o intercâmbio de informação dentro de uma rede de teleprocessamento. Trata do agrupamento de quadros em pacotes, do endereçamento e da detecção e correção de erros.
4. Transporte – trata da transferência de mensagens, do agrupamento dos pacotes de dados (mensagens) e da sua decomposição, relacionando-se desta forma com o nível inferior.
5. Sessão – o seu principal objetivo é o controle das operações realizadas sobre os dados, a fim de assegurar a sua integridade com respeito ao uso compartilhado dos mesmos. Neste nível agrupam-se as mensagens relacionadas estabelecendo uma sessão, cada uma das quais devendo ser independente das demais.
6. Apresentação – trata da organização das entradas e saídas, definindo os formatos necessários dos terminais, os arquivos e os trabalhos, a fim de que possam ser utilizados pela sessão e pela aplicação do usuário.
7. Aplicação – a sua principal função consiste no controle e supervisão dos processamentos de usuários que se intercomunicam.
Mas o que verdadeiramente importa, no nosso caso, é a arquitetura TCP/IP – o protocolo de comunicação oficial utilizado na Internet. E dá-lhe história !
Tudo começou na década de 60, com o Comunismo no auge e a chegada de armas nucleares em Cuba. Nos Estados Unidos foi sentido um grande aumento das pressões imposta pela Guerra Fria – que também estava sendo travada em laboratórios de pesquisa patrocinados pelo governo, pois tinha-se como regra que a habilidade de criar e manter vantagens tecnológicas sobre o adversário é que determinaria o vencedor do conflito.
Assim, quando a década de 60 aproximava-se do final, a maioria dos centros de pesquisa financiados pelo governo e universidades já estavam equipados com os melhores recursos computacionais disponíveis à época. Era primordial providenciar a conexão destes centros, mas, para atender aos militares “donos do dinheiro” havia um fator determinante a ser respeitado na escolha da tecnologia de rede a ser utilizada: a informação deveria continuar a fluir, mesmo sob as piores condições possíveis, tal como um ataque nuclear.
Em 1957 havia sido criado a ARPA (Advanced Research Projects Agency), ligada ao Departamento de Defesa (DoD) – diga-se de passagem que sua criação teve por intuito fazer frente ao lançamento do satélite Sputnik por parte da União Soviética. E foi delegado à ARPA a responsabilidade de desenvolver a tecnologia de rede necessária.
Para resolver a questão a ARPA financiou um projeto para a empresa BBN (Bolt Beranek and Newman) para desenvolver um modelo de comunicações que se aplicasse ao caso. Assim, em 1969, a BBN apresentou um protocolo de rede comutada por pacotes denominada NCP (Network Control Protocol) e desenvolveu um computador para controlar a rede, denominado IMP (Information Message Processor), que foi instalado na UCLA, em Los Angeles. No ano seguinte a primeira rede comutada por pacotes já estava em funcionamento, conectando quatro localidades nos estados da Califórnia e Utah: a UCLA, em Los Angeles; o SRI (Stanford Research Institute); a UCSB, em Santa Bárbara; e a Universidade de Utah. Surgia a ARPANET – Advanced Research Projects Agency Network.
Em 1972, 40 diferentes localidades já estavam conectadas à ARPANET. Nesse ano houve o primeiro ICCC (International Conference on Computer Communications), sediado em Washington, que buscava um consenso sobre protocolos de comunicação entre computadores e redes distintas. Foi instituído o INWG (InterNetwork Working Group), um grupo responsável pela criação de um protocolo que pudesse ser utilizado para a comunicação entre a maioria das redes de computadores do mundo, e cujo primeiro moderador nomeado foi Vinton Cerf. Por sua vez a DARPA (Defense Advanced Research Projects Agency), antiga ARPA, iniciou um projeto para investigar as formas possíveis de conexão entre redes de pacotes comutados.
Como resultado destes estudos foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP (Internet Protocol) e o TCP (Transmission Control Protocol), que especificavam a forma pela qual as mensagens (arquivos ou comandos) seriam transferidos entre os computadores na Internet.
Em que pese o conjunto de protocolos TCP/IP não pertencer a nenhuma organização, entidade ou fabricante específico, existe uma organização responsável pela padronização, documentação e desenvolvimento da arquitetura TCP/IP e da Internet: é o IAB (Internet Activities Board), o qual é dividido em dois grandes grupos, o IETF (Internet Engineering Task Force) – que concentra seus esforços em problemas de engenharia de curto e médio prazo, e o IRTF (Internet Research Task Force) – que coordena as atividades de pesquisa.
As propostas para revisão ou criação de protocolos relacionados ao TCP/IP são documentadas através de relatórios técnicos, conhecidos como RFCs (Request for Comments). As RFCs podem ser pequenas ou grandes, podem cobrir aspectos gerais ou apenas detalhes, e podem ser padrões ou meramente propostas para um novo protocolo ou modificação do já existente.
Já a função de organizar e distribuir toda a documentação, assim como a administração de nomes de domínio e faixas de endereço IP foi atribuída ao NIC (Network Information Center).
Bem, até aqui vimos um pouco de história e um pouco de padronização. Agora vem a parte para fundir os miolos. Diga a verdade, você nunca se perguntou o que significam aqueles números e nomes esotéricos que utilizamos para conexão em diversos sites? Pois é, vou revelar a cabala que existe neles. Ah, seria totalmente impossível repassar estas informações se não fosse o excelente artigo escrito muitos anos atrás por Alexandre Martins Gomes, especialista em redes e consultor de informática, seja lá ele quem for. ADVERTÊNCIA: a leitura a seguir contém fortes elementos maçantes para os “não-iniciados”, sendo plenamente recomendável para casos de insônia profunda.
O endereço IP é uma estrutura virtual, totalmente implementada em software, de modo a haver plena liberdade para a escolha do formato e tamanho dos pacotes, endereços, etc, já que nada é ditado pelo hardware. Ou seja, a cada máquina participante de uma rede IP é atribuído um endereço IP único de 32 bits que é utilizado em todas as comunicações com aquela máquina.
Conceitualmente, cada endereço é formado por um par, onde o primeiro identifica a rede (net_id), e o segundo identifica a máquina dentro desta rede (host_id). Na prática, cada endereço IP deve possuir uma das três primeiras formas abaixo:
Classe A 0 + 7 bits + 24 bits = 32 bits - o campo de 7 bits representa a rede e o de 24 representa a máquina Classe B 10 + 14 bits + 16 bits = 32 bits - o campo de 14 bits representa a rede e o de 16 representa a máquina Classe C 110 + 21 bits + 8 bits = 32 bits - o campo de 21 bits representa a rede e o de 8 representa a máquina Classe D (Endereços de Multicast) 1110 + 28 bits = 32 bits Classe E (Reservado para utilização futura) 11110 + 27 bits = 32 bits
Assim, a partir de um determinado endereço IP, podemos descobrir sua classe observando os três bits de maior magnitude, sendo que precisamos de apenas dois para distinguirmos entre as três primeiras classes. A tabela abaixo especifica o número máximo de redes de cada classe, assim como o número máximo de host_id suportado por cada rede.
Classe A B C
Nr. de bits para net_id 7 14 21
Nr. de bits para host_id 24 16 8
Nr. máximo teórico de redes 128 16.384 2.097.152
Nr. máximo teórico de nós 16.777.216 65.536 256
por rede
Observando essa tabela, pode parecer um absurdo alguém querer ou mesmo precisar construir uma rede que possua mais de 16 milhõees de nós, ou até mesmo 65.536; porém, quando a técnica de “subnetting” (RFC 950) é utilizada, ganhamos muito mais flexibilidade para criar um grande número de redes físicas distintas utilizando apenas uma faixa de endereço IP.
Como estamos acostumados a trabalhar na base decimal, a representação em binário de um endereço IP fica um tanto complicado, pois possui um total de 32 números. Tendo isto em vista, foi adotada a notação decimal pontuada (dotted decimal notation) para a representação daqueles números. Como exemplo, abaixo temos um inteiro de 32 bits e logo a seguir seu correspondente:
11001000 10110010 00010001 00000001 = 200.178.17.1
Existem, porém, alguns endereços IP especiais, a saber:
net_id host_id SIGNIFICADO OBSERVAÇÃO
todos todos este permitido apenas na
zero zero nó inicialização do sistema,
nunca sendo um endereço
de destino válido
todos host nó permitido apenas na
zero nesta inicialização do sistema,
rede nunca sendo um endereço
de destino válido
todos todos broadcast não é um endereço de
um um limitado origem válido
net todos broadcast não é um endereço de
um direcionado origem válido
para a rede
net
Qualquer endereço válido da rede classe A 127.0.0.0 (127.0.0.1 a 127.255.255.254) são reservados para loopback e foram projetados para testes e comunicações entre processos na máquina local. A título de teste, experimente pingar o endereço 127.0.0.1 em sua máquina e observe o resultado.
Por fim, endereços IP podem ser utilizados para referenciarmos redes, nós individuais ou todos os nós da rede. Por convenção, o endereço de rede possui a parte host_id com todos os bits em zero e o endereço de broadcast da mesma rede possui a parte host_id com todos os bits em um. Em resumo, se uma rede possui, teoricamente, n endereços disponíveis, na verdade a quantidade de endereços realmente disponíveis é n-2, já que um endereço IP é reservado para a rede em si e outro é reservado para broadcast. Maiores informações nas RFCs 990 e 997.
Well, devemos ter em mente que para duas máquinas efetivamente se comunicarem dentro de uma mesma rede IP, isto é feito através de um meio físico (linha telefônica, cabos de rede, ondas de rádio, etc). O hardware de cada um destes equipamentos possui um endereço específico e completamente sem vínculo com o endereço IP, o qual é apenas uma abstração genérica. Ou seja, a única forma de selecionarmos uma máquina entre várias é pelo endereço da interface de hardware, que chamaremos de endereço físico.
Existem algumas técnicas para a resolução de endereços, porém a mais utilizada é a Amarração Dinâmica, implementada através do protocolo ARP (Address Resolution Protocol). Funciona da seguinte maneira:
Suponhamos que a máquina A (192.10.10.1) tenha que enviar uma informação para a máquina B (192.10.10.2), ambas participantes da mesma rede IP. A máquina A sabe o endereço IP da máquina B, mas não seu endereço físico, o qual é essencial. Desta forma, antes que a máquina A possa enviar a informação, esta enviará um ARP request em broadcast (todas as máquinas daquela rede “escutarão” a requisição) com o seguinte pedido: “APENAS a máquina que possuir o endereço IP 192.10.10.2, favor responder”. Se a máquina B estiver ligada e funcionando corretamente, atenderá esse pedido enviando seu endereço de hardware para a máquina A. Neste momento, a máquina A “aprenderá” o endereço físico da máquina B e então poderá efetuar a transmissão da informação.
Por questões de eficiência, existe uma área reservada em memória que contém uma espécie de cache de resolução de endereços, pois se a cada informação que A precisasse enviar para B fosse precedida de um broadcast a fim de resolver endereços, provavelmente o desempenho seria comprometido. Neste caso, se for enviada uma segunda informação de A para B, não mais será necessário o ARP request, uma vez que A já sabe o endereço físico de B. Maiores detalhes na RFC 826.
Com relação ao roteamento (o caminho a se percorrer para entregar a informação), podemos dividir o problema em dois grupos: roteamento direto e roteamento indireto.
O roteamento direto é utilizado quando duas máquinas estão conectadas diretamente numa mesma rede, o que é facilmente verificável através da análise de semelhança entre o net_ide e host_id de ambas as máquinas.
O roteamento indireto é necessário quando a máquina destino não está diretamente conectada à rede da máquina de origem, forçando o transmissor a enviar a informação para um gateway. Gateway é um dispositivo que conecta duas redes locais diferentes, ou uma rede local e uma rede remota; possui processador e memória próprios, podendo fazer a conversão de protocolos e de larguras de banda.
No roteamento indireto o transmissor deve enviar a informação para um gateway e este deverá determinar o melhor caminho para alcançar a rede dstino e enviá-la. Concluímos, pois, que existem múltiplos caminhos para uma origem chegar a um destino, sendo que o gerenciamento destas rotas pode ser administrado manualmente (sempre que uma nova rota for adicionada ou removida, alguém deve “reprogramar” os gateways) ou dinamicamente, isto é, os próprios gateways trocarão informações sobre as tabelas de roteamento e adicionarão ou removerão rotas quando for necessário.
Justamente por isso temos o ICMP (Internet Control Message Protocol), que provê aos gateways e aos hosts um mecanismo para reportar informações de controle ou erro. As mensagens ICMP são enviadas em várias situações, como, por exemplo: quando uma informação não consegue alcançar seu destino ou quando um gateway informa a um host a existência de uma rota mais curta. Existem alguns utilitários que nos permitem gerar mensagens ICMP, normalmente com objetivo de testar a rede, parte dela, ou um host/gateway específico. Os mais utilizados são PING e TRACEROUTE.
O utilitário ping gera um ICMP ECHO_REQUEST para obter um ICMP ECHO_RESPONSE de um host ou gateway. É útil para determinação do estado da rede; descobrir e isolar problemas de hardware e software; testar, medir o desempenho e gerenciar redes. Por default o ping envia uma informação por segundo e imprime uma linha para cada resposta recebida. Podemos obter, ainda, algumas estatísticas, como tempo médio de resposta e taxa de perda de pacotes.
Já o utilitário traceroute determina a rota utilizada até um destino enviando pacotes ICMP_ECHO com o TTL (Time-To-Live) variando. Cada gateway ao longo da rota decrementa o TTL de pelo menos uma unidade antes de propagá-lo. Quando o TTL de um pacote chega a zero, o gateway envia a origem uma mensagem ICMP_TIME_EXCEEDED. Assim o traceroute determina a rota enviando o primeiro ICMP_ECHO com um TTL igual a 1, incrementando-o de uma unidade a cada transmissão subsequente, até que o destino responda ou o TTL máximo seja alcançado. A rota é determinada observando-se as mensagens de ICMP_TIME_EXCEEDED dos gateways intermediários. Maiores detalhes, RFC 792.
Uma vez que entendemos como as redes se distinguem na Internet, agora precisamos verificar de perto como funciona o endereçamento completo, ou seja, as sub-redes. A forma mais fácil para o entendimento do endereçamento de sub-rede é imaginarmos a seguinte situação: uma organização obteve junto ao NIC o seguinte endereço classe B: 158.56.0.0 (conforme já vimos, número máximo teórico de 65.536 endereços IP); considerando que possui 5 escritórios em cidades diferentes e que cada escritório possui 150 computadores, como seria possível conectar todas as 5 redes sob o mesmo endereço classe B, já que para cada rede distinta é necessário um endereço IP distinto?
A solução se baseia na forma de como um endereço IP é interpretado. Antes da padronização do endereçamento de sub-rede, o endereço IP era dividido em 2 partes (um prefixo para a rede e um sufixo para o host). Agora, as duas partes identificam uma porção para rede e uma porção para endereçamento local. Esta última porção ainda pode ser dividida em duas, a saber: rede física e host.
Portanto, estamos aptos a resolver satisfatoriamente o exemplo proposto. Como cada rede local é composta de 150 máquinas, precisaremos de 8 bits para representar cada host em cada rede física. A porção rede já foi definida pela NIC (158.56), utilizando 16 bits. Como o IP é um identificador de 32 bits, sobraram 8 bits para representarmos a rede física. Um dos possíveis resultados seria:
Rede 1 - 158.5.10.0 (endereços IP válidos: 158.56.10.1 à 158.56.10.254) Rede 2 - 158.5.11.0 (endereços IP válidos: 158.56.11.1 à 158.56.11.254) Rede 3 - 158.5.12.0 (endereços IP válidos: 158.56.12.1 à 158.56.12.254) Rede 4 - 158.5.13.0 (endereços IP válidos: 158.56.13.1 à 158.56.13.254) Rede 5 - 158.5.14.0 (endereços IP válidos: 158.56.14.1 à 158.56.14.254)
Neste caso, podemos fazer a seguinte associação ao endereço IP 158.56.12.15:
158.56 - identifica a organização (site); .12 - identifica a rede física no site; .15 - identifica o host na rede física.
É importante observarmos que a associação supra só foi possível devido ao fato de conhecermos o número de bits utilizado para representar os hosts em cada rede física. O nome formal do identificador que contém esta informação é subnet mask (máscara de sub-rede). A subnet mask também é um identificador de 32 bits e seu conteúdo pode ser interpretado da seguinte forma: quando os bits na máscara são setados em 1, os bits correspondentes do endereço IP são tratados como parte do endereço da rede; caso contrário, são tratados como parte do identificador do host.
Em nosso exemplo, todas as redes têm máscara 255.255.255.0, ou seja, os três primeiros bytes identificam a rede e o último identifica um host numa determinada rede. De posse desta informação, podemos garantir que os endereços 158.56.12.15 e 158.56.12.89 pertencem à mesma rede. O mesmo não acontece para os endereços 158.56.13.45 e 158.56.14.1. Cabe ressaltar que esta análise do terceiro byte só é válida quando a máscara de sub-rede for 255.255.255.0, em outros casos deve-se proceder a uma comparação através de um “E” booleano. Vide RFC 950.
Na arquitetura TCP/IP temos que o objetivo básico dos protocolos de transporte é prover um mecanismo de multiplexação, permitindo que processos diversos em uma determinada máquina possam se comunicar com um ou mais processos em outras máquinas simultaneamente. Para isso são utilizados dois protocolos de transporte com características bastante distintas, o UDP (User Datagram Protocol) e o TCP (Transmission Control Protocol).
O UDP utiliza os serviços do IP para transportar as mensagens de uma máquina para outra. Porém não existe a garantia da entrega das mensagens, já que o UDP não utiliza acknowledgements (reconhecimentos) para assegurar a chegada das mesmas, de modo que podem ser perdidas, duplicadas, entregues fora de ordem ou os pacotes podemser recebidos numa taxa mais elevada do que o destinatário possa processar. Porém, existe um ponto positivo na utilização do UDP: desempenho. O processamento de suas mensagens gera um overhead bastante pequeno, possibilitando uma maior taxa de transferência. Como exemplo, uma das aplicações mais conhecidas que utilizam o UDP é o NFS (Network File System). Maiores referências na RFC 768.
Já o protocolo TCP especifica o formato dos dados e dos acknowledgements que duas máquinas trocam para obter uma transferência de dados confiável, assim como os procedimentos utilizados para assegurar que os dados chegaram ao destino corretamente. Detalhes em RFC 793.
Se você chegou até aqui, parabéns! Você realmente promete, pequeno gafanhoto… Antes que me perguntem o porquê de colocar um texto tão técnico no que “deveria” ser um e-zine jurídico, permita-me lembrar (mais uma vez) que somente através do conhecimento detalhado do funcionamento da Rede é que se tornará viável a criação de uma legislação mais de acordo com a realidade. Para finalizar, o autor do texto original no qual este foi baseado, Alexandre Martins Gomes, recomenda o livro Internetworking with TCP/IP, v. I, de Douglas E. Comer, Editora Prentice Hall International Editions. Se alguém achar, me avise.