3. Arquitetura TCP/IP
A arquitetura internet foi criada pelo Departamento de Defesa dos Estados Unidos, com o objetivo de se ter uma rede interligando v�rias universidades e �rg�os do governo de maneira descentralizada (ARPANET), para evitar a sua destrui��o no caso de ocorr�ncia de uma guerra. Com o passar do tempo, esta id�ia inicial perdeu o sentido e a infraestrutura foi aproveitada para se tornar o que hoje � a maior rede de computadores do mundo: a Internet.
Os padr�es da internet n�o s�o criados por �rg�os internacionais de padroniza��o, como a ISO ou o IEEE, mas ela � uma arquitetura muito aceita, sendo chamada por isso como padr�o "de facto", ao contr�rio do modelo OSI, considerado padr�o "de jure". O corpo t�cnico que coordena a elabora��o de protocolo e padr�es da internet � o IAB (Internet Activity Board). Qualquer pessoa pode criar um protocolo para ser utilizado pela rede internet. Para isto, basta que ela documente este protocolo atrav�s de um RFC (Request for Comments), que pode ser acessado na Internet. Estes RFC's s�o analisados pelos membros da IAB que poder�o sugerir mudan�as e public�-lo. Se ap�s seis meses da publica��o n�o houver nenhuma obje��o, este protocolo se torna um Internet Standard.
A arquitetura internet se destaca pela simplicidade de seus protocolos e pela efici�ncia com que atinge o seu objetivo de interconectar sistemas heterog�neos.
Obs: cabe comentar aqui que por rede internet entende-se qualquer rede que utiliza os protocolos TCP/IP, enquanto que o termo Internet (com I mai�sculo) � utilizado para designar a Internet (conjunto de redes baseada na ARPANET, com milh�es de usu�rios em todo o mundo).
3.1. Arquitetura Internet
A arquitetura internet se baseia praticamente em um servi�o de rede n�o orientado � conex�o (datagrama n�o confi�vel), o Internet Protocol (IP) e em um servi�o de transporte orientado � conex�o, oferecido pelo Transmission Control Protocol (TCP). Juntos, estes protocolos se completam, oferecendo um servi�o confi�vel de uma forma simples e eficiente.
A arquitetura internet se baseia em um modelo com quatro camadas (figura 1), onde cada uma executa um conjunto bem definido de fun��es de comunica��o. No modelo em camadas da internet, n�o existe uma estrutura��o formal para cada camada, conforme ocorre no modelo OSI. Ela procura definir um protocolo pr�prio para cada camada, assim como a interface de comunica��o entre duas camadas adjacentes.
Figura 3.1: Modelo em Camadas da Internet
3.1.1. Camada de Rede de Comunica��o
Na camada de rede de comunica��o da internet, n�o existe um padr�o para a sub-rede de acesso, possibilitando a conex�o de qualquer tipo de rede, desde que haja uma interface que compatibilize a tecnologia da rede com o protocolo IP. Desta forma, um n�mero muito grande de tecnologias pode ser utilizado na sub-rede de acesso, como Ethernet, Token Ring, FDDI, X.25, Frame Relay, ATM, etc.
Para que todas estas tecnologias possam ser "vistas" pela rede internet, existe a necessidade de uma convers�o de endere�amentos do formato utilizado pela sub-rede e o formato IP. Esta convers�o � realizada pelos gateways, que tornam a interconex�o das redes transparente para o usu�rio (figura 3.2). Al�m das convers�es de protocolos, os gateways s�o respons�veis pela fun��o de roteamento das informa��es entre as sub-redes.
Figura 3.2: Interconex�o de Sub-Redes � Rede Internet
3.1.2. Camada de Inter-Rede
A camada de Inter-Rede, tamb�m chamada de Internet, � equivalente � camada de rede do modelo OSI. Nela s�o especificados v�rios protocolos, dentre os quais se destaca o IP (Internet Protocol).
O IP � um protocolo n�o orientado a conex�o, cuja fun��o � transferir blocos de dados denominados datagramas da origem at� o destino, podendo passar inclusive por v�rias sub-redes (a origem e o destino s�o hosts identificados por endere�os IP). A opera��o no modo datagrama � uma comunica��o n�o confi�vel, n�o sendo usado nenhum reconhecimento fim a fim ou entre n�s intermedi�rios, nem qualquer tipo de controle de fluxo. Nenhum mecanismo de controle de erro de dados � utilizado, apenas um controle de verifica��o do cabe�alho, para garantir que os gateways encaminhem as mensagens corretamente. Algumas das principais caracter�sticas do protocolo IP s�o as seguintes:
3.1.2.1. Endere�amento IP
O roteamento dos datagramas atrav�s das sub-redes s�o feitos baseados no seu endere�o IP, n�meros de 32 bits normalmente escritos como quatro octetos (em decimal), por exemplo 9.179.12.66. Devido ao fato de existirem redes dos mais variados tamanhos compondo a inter-rede, utiliza-se o conceito de classes de endere�amento:
Figura 3.3: Formato dos Endere�os IP
Os endere�os IP indicam o n�mero da rede e o n�mero do host, sendo que a classe A suporta at� 128 redes com 16 milh�es de hosts cada uma, a classe B 16384 redes com at� 64 mil hosts cada uma, a classe C 2 milh�es de redes com at� 256 hosts cada uma e a classe D, onde um datagrama � dirigido a um grupo de hosts. Os endere�os a partir de 1111 est�o reservados para uso futuro.
A Internet utiliza a classe C para endere�amento de suas redes e m�quinas. Quando um novo provedor de acesso se conecta � ela, ele recebe 256 endere�os para serem utilizados pelos seus hosts (ou "usu�rios"). Como um provedor pode ter mais de 256 clientes, ele utiliza um esquema de aloca��o din�mica de IP, ou seja, quando o usu�rio se conecta ao provedor de acesso, ele recebe um endere�o IP, podendo desta forma haver at� 256 usu�rios conectados simultaneamente a um provedor de acesso.
3.1.2.2. Formato do Datagrama IP
O protocolo IP recebe da camada de transporte mensagens divididas em datagramas de 64 kbytes cada um, sendo que cada um destes � transmitido atrav�s da Internet, sendo ainda possivelmente fragmentados em unidades menores � medida em que passam por sub-redes. Ao chegarem ao seu destino, s�o remontados novamente pela camada de transporte, de forma a reconstituir a mensagem original.
O datagrama utilizado pelo protocolo IP consiste em um cabe�alho e um payload, sendo que o cabe�alho possui um comprimento fixo de 20 bytes mais um comprimento vari�vel (figura 3.4).
Figura 3.4: Cabe�alho IP
O campo VERS identifica a vers�o do protocolo que montou o quadro. O campo HLEN informa o tamanho do quadro em palavras de 32 bits, pois este pode ser vari�vel. O campo SERVICE TYPE indica �s sub-redes o tipo de servi�o que deve ser oferecido ao datagrama (por exemplo, para transmiss�o de voz digitalizada necessita-se mais de uma entrega r�pida do que um controle rigoroso de erros, ao passo que para um servi�o de transfer�ncia de arquivos, o tempo de entrega pode ser sacrificado para se obter um maior controle de erro).
O campo TOTAL LENGTH armazena o comprimento total do datagrama (dados e cabe�alho), com um valor m�ximo de 65.536 bytes. O campo IDENTIFICATION possibilita ao host determinar a que datagrama pertence um fragmento rec�m-chegado (todos os fragmentos de um datagrama possuem o mesmo valor). O campo FLAGS � composto de um bit n�o utilizado seguido por dois bits, DF e MF. O DF significa Don't Fragment e indica que os gateways n�o devem fragmentar este datagrama (por incapacidade do destino juntar novamente os fragmentos). MF significa More Fragments, e � utilizado como dupla verifica��o do campo TOTAL LENGTH, sendo que todos os fragmentos, menos o �ltimo possuem este bit setado.
O FRAGMENT OFFSET informa a que posi��o no datagrama atual pertence o fragmento. O campo TIME TO LIVE � um contador utilizado para se limitar o tempo de vida de um pacote. Quando o datagrama � criado, este campo recebe um valor inicial, que � decrementado toda vez que passa por um gateway. Quando este contador atinge o valor zero, isto indica que a rede est� em congestionamento ou que o datagrama est� em loop, e o datagrama � descartado.
O campo PROTOCOL indica o protocolo que gerou o datagrama e que deve ser utilizado no destino. O campo HEADER CHECKSUM � utilizado pelos gateways para se fazer uma verifica��o do cabe�alho (apenas do cabe�alho, n�o dos dados), para que o gateway n�o roteie um datagrama que chegou com o endere�o errado.
SOURCE IP ADRESS e DESTINATION IP ADRESS s�o, respectivamente, os endere�os de host origem e destino. O campo IP OPTIONS � usado para o transporte de informa��es de seguran�a, roteamento na origem, relat�rio de erros, depura��o, fixa��o da hora e outras. O campo PADDING possui tamanho vari�vel e � utilizado para se garantir que o comprimento do cabe�alho do datagrama seja sempre um m�ltiplo inteiro de 32 bits. Finalmente, o campo DATA transporta os dados do datagrama.
3.1.2.3. Roteamento
O roteamento consiste no processo de escolha do caminho atrav�s do qual deve ser enviado o dado para o sistema destino. Caso o destino esteja localizado na mesma sub-rede, esta � uma tarefa f�cil. Por�m quando o destino se encontra em um sub-rede diferente, a transmiss�o dos dados � feita atrav�s de um gateway. O gateway faz o roteamento baseado no endere�o IP de destino do datagrama. Se o gateway j� estiver conectado � rede para onde o dado deve ser enviado, o problema acabou. Por�m, o gateway pode n�o estar ligado diretamente � rede de destino. Neste caso, a partir da identifica��o da sub-rede, o endere�o f�sico do pr�ximo gateway na rota � obtido, atrav�s de processos de mapeamento. � importante observar que o gateway utilizado em uma rede internet possui funcionalidades distintas das normalmente aplicadas a ele nas redes OSI.
O roteamento pode, ent�o, ser dividido em dois tipos:
Para realizar o roteamento indireto, os gateways utilizam tabelas de roteamento, que armazenam informa��es sobre como atingir cada sub-rede da rede internet. Uma tabela de roteamento possui, tipicamente, entradas do tipo (N,G), onde N � um endere�o IP (de destino) e G � o endere�o IP do pr�ximo gateway a ser utilizado para se atingir N (figura 3.5):
Figura 3.5: Tabela de Roteamento
Para diminuir o tamanho das tabelas de roteamento, existem algumas t�cnicas a serem utilizadas. Por exemplo, pode-se utilizar rotas default (pr�-estabelecidas) para quando n�o se encontra refer�ncia na tabela sobre uma determinada rota. Este caso se aplica tipicamente para redes que possuem um �nico gateway, como por exemplo, departamentos de uma universidade ligados ao backbone por apenas um gateway. Ao inv�s de se ter uma rota para cada sub-rede, utiliza-se a rota default.
3.1.2.3.1. Algoritmos de Roteamento
Um algoritmo de roteamento � a parte do software da camada de rede que tem por objetivo decidir sobre qual linha de sa�da um pacote que chega deve ser transmitido. Para uma rede que trabalha com datagrama, a decis�o deve ser tomada para cada pacote de dados que chega. J� para a rede que trabalha com circuitos virtuais, a decis�o de roteamento deve ser tomada apenas quando se estabelece um circuito virtual.
Quando uma m�quina M tem um datagrama a ser enviado, ela deve executar os seguintes passos:
Existem basicamente dois tipos de algoritmos utilizados em redes internet: Vetor-Dist�ncia e Estado-do-Enlace, por�m n�o nos compete entrar em detalhes sobre eles neste momento. Mais detalhes sobre algoritmos de roteamento podem ser encontrados em [Tanenbaum 94].
3.1.2.4. Fragmenta��o e Remontagem de Datagramas
Como os datagramas IP atravessam redes das mais diversas tecnologias, os tamanhos dos quadros nem sempre devem ser os mesmos. Portanto deve haver uma certa flexibilidade em termos de tamanho de pacote a ser transmitido, de forma a este pacote se adaptar � sub-rede que vai atravessar. Esta flexibilidade se d� atrav�s da facilidade de fragmenta��o e remontagem de datagramas.
Quando for necess�rio transmitir um datagrama maior do que o suport�vel pela rede, deve-se particionar o pacote em fragmentos. Estes fragmentos s�o transportados como se fossem datagramas independentes. Para poder recompor o datagrama original no destino, s�o utilizados alguns campos do cabe�alho do datagrama, conforme visto em 3.1.2.2. Quando o destino recebe o primeiro fragmento, inicia-se uma temporiza��o para se aguardar o conjunto completo dos fragmentos que comp�em o datagrama. Caso um dos fragmentos n�o chegue durante este intervalo, o datagrama � descartado, acarretando em uma perda de efici�ncia.
3.1.3. Camada de Transporte
A camada de transporte tem o objetivo de prover uma comunica��o confi�vel entre dois processos, estando eles ocorrendo dentro da mesma rede ou n�o. Ela deve garantir que os dados sejam entregues livres de erros, em seq��ncia e sem perdas ou duplica��o.
A Arquitetura Internet especifica dois tipos de protocolos na camada de transporte: o UDP (User Datagram Protocol) e o TCP (Transmission Control Protocol). O UDP � um protocolo n�o orientado � conex�o que pode ser considerado como uma extens�o do protocolo IP, e n�o oferece nenhuma garantia em rela��o � entrega dos dados ao destino.
J� o protocolo TCP oferece aos seus usu�rios um servi�o de transfer�ncia confi�vel de dados, atrav�s da implementa��o de mecanismos de recupera��o de dados perdidos, danificados ou recebidos fora de seq��ncia, minimizando o atraso na sua transmiss�o.
A cada fragmento transmitido � incorporado um n�mero de seq��ncia, de forma a n�o se perder a ordem dos segmentos a serem juntados para formar o datagrama. Existe um mecanismo de reconhecimento para executar essa fun��o que funciona da seguinte forma: o reconhecimento transmitido pelo receptor ao receber o segmento X � o n�mero do pr�ximo segmento que o receptor espera receber (X+1), indicando que j� recebeu todos os segmentos anteriores a este. Atrav�s da an�lise dos n�meros de segmento, o receptor pode ordenar os segmentos que chegaram fora de ordem e eliminar os segmentos duplicados. Com base no checksum que � adicionado a cada segmento transmitido, os erros de transmiss�o s�o tratados e os segmentos danificados s�o descartados. Existe ainda um controle de fluxo baseado no envio da capacidade de recebimento do receptor, contado a partir do �ltimo byte recebido, ao transmissor. Desta forma o transmissor consegue controlar a quantidade de dados que s�o enviados ao receptor para n�o haver descarte de segmentos nem necessidade de retransmiss�o, que ocasionam a queda do desempenho da rede.
Para permitir que v�rios usu�rios (processos de aplica��o) possam utilizar simultaneamente os servi�os do protocolo TCP, foi criado o conceito de porta. Para n�o haver problemas de identifica��o de usu�rios, o identificador da porta � associado ao endere�o IP onde a entidade TCP est� sendo realizada, definindo assim um socket. A associa��o de portas a processos de aplica��o (usu�rios) � tratada de forma independente por cada entidade TCP. No entanto, processos servidores que s�o muito utilizados, como FTP, Telnet, etc, s�o associados a portas fixas, divulgadas aos usu�rios. Uma conex�o � identificada pelo par de sockets ligados em suas extremidades. Um socket local pode participar de v�rias conex�es diferentes com sockets remotos. Uma conex�o pode ser utilizada para transportar dados em ambas as dire��es simultaneamente, ou seja, as conex�es TCP s�o full-duplex.
� importante observar aqui que quando se fala que o TCP � orientado � conex�o, n�o se fala em conex�o a n�vel f�sico, mas sim a n�vel l�gico. Este conceito pode ser compreendido atrav�s da figura abaixo.
Figura 3.6: Servi�os orientados e n�o orientados � conex�o
No caso da figura acima, a m�quina A quer se comunicar com a m�quina B atrav�s de uma rede em anel utilizando TCP/IP. A �nica conex�o f�sica que existe entre A e B � atrav�s do anel, passando pelas m�quinas C e D. A n�vel de IP, a comunica��o n�o � orientada � conex�o, portanto � muito simples enxergar que os dados possuem apenas dois caminhos para ir de A at� B: atrav�s de C ou atrav�s de D. A n�vel de TCP, por�m, a comunica��o entre os computadores A e B ocorre como se houvesse uma conex�o direta entre eles. Isso implica que, se a n�vel de IP os dados podem chegar fora de ordem, o TCP tem que garantir a ordena��o destes dados, de forma que eles sempre chegem na ordem correta, como aconteceria se houvesse uma conex�o f�sica direta entre A e B.
3.1.4. Camada de aplica��o
As aplica��es na arquitetura Internet, ao contr�rio do que ocorre com as OSI, s�o implementadas de uma maneira isolada, ou seja, n�o existe um padr�o que defina como deve ser estruturada uma aplica��o. Cada aplica��o possui seu pr�prio padr�o, correspondente a um RFC (Request for Comments).
3.1.4.1. RPC (Remote Procedure Call)
O RPC � um mecanismo criado para suportar aplica��es distribu�das baseadas em um modelo cliente-servidor. A aplica��o cliente faz uma chamada de procedimento remoto onde o RPC, de forma autom�tica, obt�m os valores dos argumentos da chamada, monta a mensagem correspondente, a envia ao servidor e aguarda a resposta, armazenando os valores retornados nos argumentos definidos na chamada. Na realidade, o que ocorre � a mesma coisa que nas chamadas de fun��es locais comumente encontradas em aplica��es, com a diferen�a que a execu��o real da fun��o est� ocorrendo em um local remoto.
Figura 3.7: Funcionamento de uma RPC
3.1.4.2. SMTP (Simple Mail Transfer Protocol)
O SMTP � o protocolo utilizado no correio eletr�nico da arquitetura TCP/IP. Ela prev� uma interface com o usu�rio para enviar e receber mensagens que s�o armazenadas, inicialmente, em uma �rea de transfer�ncia de mensagens do sistema para serem, posteriormente, enviadas em background, conforme a figura 3.8.
Figura 3.8: Funcionamento do SMTP
O SMTP enxerga a mensagem como que dividida em duas partes: o corpo e o cabe�alho. O corpo da mensagem � onde s�o enviadas as mensagens propriamente ditas, sendo que o cabe�alho cont�m dados de endere�amento, assunto da mensagem etc. O protocolo SMTP n�o prov� mecanismos sofisticados de controle de envio e recebimento de mensagens, tais como notifica��es, seguran�a de viola��o, criptografia dentre outros.
3.1.4.3. FTP (File Transfer Protocol)
O FTP prov� servi�os de transfer�ncia, renomea��o e remo��o de arquivos, bem como cria��o, remo��o e modifica��o de diret�rios, entre outros. Para que um servi�o FTP seja prestado, s�o estabelecidas duas conex�es TCP entre o cliente e o servidor: uma para a transfer�ncia dos dados e outra para controle. A confiabilidade das transfer�ncias de arquivos realizadas fica por conta do protocolo TCP, j� que o FTP n�o possui nenhuma fun��o de controle adicional sobre os arquivos, a n�o ser a exig�ncia da senha do usu�rio para permitir a transfer�ncia. O FTP pode transmitir dois tipos de arquivos: arquivos texto (com dados no formato ASCII ou EBCDIC) ou arquivos bin�rios (dados enviados como uma seq��ncia de bytes sem qualquer convers�o).
3.1.4.4. TELNET (Terminal Virtual)
O TELNET � o protocolo utilizado para se permitir que o usu�rio de um sistema acesse um sistema remoto atrav�s de uma sess�o de terminal, operando como se estivesse diretamente conectado neste sistema.
3.3.4.5. DNS (Domain Name System)
O DNS � o mecanismo utilizado pelo TCP/IP que define um sistema de nomes baseado em uma estrutura de �rvore, que possibilita uma nomea��o organizada de sistemas de dom�nio universal. O DNS estabelece a sintaxe de nomes e regras para delega��o de autoridade sobre os nomes al�m de implementar um algoritmo computacional eficiente para mapear nomes em endere�os.
Os nomes das m�quinas s�o divididos em partes separadas por pontos correspondendo cada parte a um novo dom�nio de autoridade, em que o primeiro nome corresponde ao n�vel mais baixo e o �ltimo ao n�vel mais alto da hierarquia. No caso do n�vel mais alto, foram designados os seguintes nomes:
A figura 3.9 representa uma estrutura de nomes onde, por exemplo, o nome cctmn.inatel.br representa o dom�nio do CCTMN do INATEL.
Figura 3.9: Estrutura de nomes utilizada pelo DNS
3.2. Gerenciamento TCP/IP
O gerenciamento de uma rede TCP/IP se baseia no protocolo SNMP - Simple Network Management Protocol. O SNMP � um protocolo da camada de aplica��o que atua sobre o UDP - User Datagram Protocol. A figura 3.10 mostra a configura��o t�pica da implementa��o do protocolo SNMP. O protocolo UDP � um protocolo n�o orientado � conex�o, e a sua utiliza��o (ao inv�s do TCP) se explica pelo fato de que n�o deve haver interrup��es na comunica��o de mensagens SNMP. No caso do TCP, uma interrup��o em uma conex�o, ou rota, influiria no desempenho do sistema de ger�ncia. Ao se utilizar um servi�o de datagrama, apesar de se obter um servi�o de menor qualidade, esta limita��o � contornada, pois em caso de impossibilidade de utiliza��o de uma rota, outra rota � automaticamente escolhida.
Figura 3.10: SNMP
O gerenciamento de uma rede TCP/IP � baseado na estrutura agente-gerente, onde o gerente faz as requisi��es das opera��es a serem executadas sobre os recursos gerenciados. Estas requisi��es s�o enviadas ao agente, que executa as opera��es sobre os objetos gerenciados (abstra��es dos recursos gerenciados para o agente). Atrav�s de uma interface, estas opera��es realizadas nos objetos gerenciados se refletem nos recursos gerenciados, e geralmente uma resposta � enviada de volta ao gerente, completando a opera��o de gerenciamento.
O protocolo SNMP � baseado no paradigma conhecido como fecth-store (busca-armazenamento), ou seja, todas as opera��es previstas para este protocolo s�o derivadas de opera��es b�sicas de busca e armazenamento. Estas opera��es b�sicas incluem:
Segundo Marshall Rose, "o impacto do gerenciamento de rede adicionado para gerenciar os n�s deve ser m�nimo, refletindo o menor denominador comum. Cada n� � visto como tendo algumas vari�veis. Pela leitura dos valores destas vari�veis, o n� � monitorado. Alterando os valores destas vari�veis, o n� � controlado".
Em decorr�ncia disto, os agentes SNMP s�o simples e executam opera��es elementares, como estabelecer e obter valores das vari�veis. O programa que analisa, manipula, combina ou aplica algum algoritmo sobre os dados deve residir no gerente.
3.3. Compara��o entre as arquiteturas TCP/IP e OSI
Atualmente, com a necessidade da utiliza��o de modelos abertos em sistemas de comunica��o, torna-se imprescind�vel conhecer os dois principais modelos que visam atender esta necessidade (o modelo OSI e o modelo TCP/IP) e suas diferen�as.
A principal diferen�a entre os dois, � que o modelo OSI evoluiu de uma defini��o formal elaborada por comiss�es da ISO para o desenvolvimento de produtos, enquanto que o TCP/IP nasceu da necessidade do mercado e da demanda de produtos para resolver o problema de comunica��o e a partir da� passou por uma s�rie de implementa��es onde muitos produtos foram desenvolvidos fora da arquitetura internet, passando a ser incorporados a ela. Vale ent�o dizer que a arquitetura OSI � considerado um modelo de jure, enquanto que arquitetura internet � considerada um modelo de facto.
Analisando-se comparativamente a estrutura dos dois modelos (figura 3.10), pode-se observar que a parte referente �s sub-redes de acesso da arquitetura internet corresponde � camada f�sica, � de enlace e, parcialmente, � de rede do modelo OSI, sem que haja nenhuma padroniza��o neste sentido.
O IP corresponde � camada de rede, enquanto o TCP e o UDP oferecem servi�os semelhantes aos prestados, respectivamente, pelos protocolos de transporte orientados e n�o-orientados � conex�o do modelo OSI. Nas camadas superiores, a arquitetura Internet coloca sob responsabilidade da aplica��o os servi�os fornecidos pelas camadas de sess�o, apresenta��o e aplica��o do modelo OSI.
Figura 3.10: Compara��o entre as arquiteturas OSI e TCP/IP
O fato da arquitetura TCP/IP possuir menos camadas que o modelo OSI implica na sobrecarga de algumas camadas com fun��es que n�o lhe s�o espec�ficas. Por exemplo, podemos citar a transfer�ncia de arquivos: no ambiente TCP/IP, as fun��es correspondentes � camada de apresenta��o OSI s�o desempenhadas pelo pr�prio protocolo de transfer�ncia de arquivos FTP. Por outro lado, o TCP/IP nos fornece aplica��es simples, eficiente e de f�cil implementa��o a n�vel de produtos. Uma das maiores limita��es da arquitetura TCP/IP � quanto a sua capacidade de endere�amento, que j� est� se tornando limitada, devido ao crescimento da Internet.
J� a arquitetura OSI sofre cr�ticas por apresentar "modelos e solu��es acad�micas" e objetivar atendimento a requisitos de prop�sito geral em detrimento de solu��es imediatas, compat�veis com as exig�ncias atuais dos usu�rios. � tamb�m criticada por n�o apresentar meios de migra��o entre as arquiteturas atualmente em funcionamento e suas solu��es.
Diante desta situa��o, observa-se atualmente um emergente esfor�o de aproxima��o entre as duas arquiteturas, objetivando-se aproveitar o que cada uma tem de melhor a oferecer, de forma a se encontrar solu��es mistas.
Proximo Topico: Arquitetura TMN
