REDES DE COMPUTADORES

UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS

ReitorPe. Marcelo Fernandes de Aquino, SJ

Vice-reitorPe. Jos Ivo Follmann, SJ

Editora Unisinos

DiretorPe. Pedro Gilberto Gomes, SJ

Editora da Universidade do Vale do Rio dos SinosEditora UnisinosAv. Unisinos, 950

93022-000 So Leopoldo RS Brasil

Telef.: 51.35908239Fax: 51.35908238

editora@unisinos.br

REDES DE COMPUTADORES

[Conceitos, aplicaes e tipos de transporte]

Mateus Raeder

Editora Unisinos2010

do autor, 2010

2010 Direitos de publicao e comercializao daEditora da Universidade do Vale do Rio dos Sinos

Editora Unisinos

Sobre o autorMateus Raeder. Graduou-se no curso de Bacharelado em Cincia da Computao pela Pontifcia Universidade Catlica do Rio Grande do Sul (PUCRS) no ano de 2006. Em 2008, obteve o ttulo de Mestre em Cincia da Computao pela PUCRS. Doutorando em Cincia da Computao pela PUCRS. professor da UNISINOS desde o primeiro semestre de 2009, lecionando disciplinas como Laboratrio I, Programao II, Redes Avanadas, Programao de Alto Desempenho e Redes de Computadores.

Dados Internacionais de Catalogao na Publicao (CIP)(Bibliotecrio Flvio Nunes, CRB 10/1298)

Esta obra segue as normas do Acordo Ortogrfico

da Lngua Portuguesa vigente desde 2009.

EditorCarlos Alberto Gianotti

Acompanhamento editorialMateus Colombo Mendes

RevisoCaroline Ferreira Soares

EditoraoPubblicato

CapaIsabel Carballo

Impresso, inverno 2010

A reproduo, ainda que parcial, por qualquer meio, das pginas que compem este livro, para uso no individual, mesmo para fins didticos, sem autorirazo escrita do editor,

ilcita e constitui uma contrafao danosa cultura. Foi feito o depsito legal.

R134r Raeder, Mateus. Redes de computadores : (conceitos, aplicaes e tipos de transporte) / Mateus Raeder. So Leopoldo, RS : Ed. UNISINOS, 2010. 66 p. (EAD)

ISBN 978-85-7431-401-3

1. Redes de computadores. I. Ttulo. II. Srie.CDD 004.6CDU 004.7

APRESENTAO

Este livro Redes de Computadores: conceitos, aplicaes e tipos de transporte objetiva introduzir o estudo s redes de computadores e sua essn-cia. Assim sendo, a obra traz desde alguns aspectos bsicos, como classificaes e meios de transmisso nas redes, at caractersticas mais avanadas, como o funcionamento dos protocolos mais frequentemente usados. O contedo apre-sentado foi baseado em alguns estudos e autores importantes e de excelente referncia na rea de Redes, o que garante a qualidade do contedo.

O leitor perceber que a linguagem bastante didtica e de fcil entendimento, apresentando exemplos e situaes do dia a dia (como, por exemplo, o envio de e-mails, a transmisso de arquivos e o acesso a pginas na Internet).

O livro est organizado de forma gradativa e de maneira comple-mentar, procurando sempre intercalar um assunto no outro. Comea com um estudo sobre aplicaes e seus principais protocolos, passando pelo entendi-mento de como os envios de mensagens pela rede so tratados, finalizando com uma classe de aplicaes utilizada com grande frequncia pelos usurios da Internet (transmisso de udio e vdeo).

A principal expectativa que a linguagem didtica utilizada, em con-junto com a sequncia do contedo abordado, possa auxiliar o leitor no enten-dimento da mensagem passada.

SUMRIO

CAPITULO 1: INTRODUO S REDES DE COMPUTADORES ........................ 91 Introduo s redes de computadores .......................................................... 9

1.1 Elementos principais e classificao ................................................... 101.2 Internet e servios .................................................................................. 131.3 Meios de transmisso ............................................................................ 15

1.3.1 Meios de transmisso guiados .................................................... 151.3.2 Meios de transmisso no-guiados ............................................ 16

1.4 Protocolos ............................................................................................... 171.4.1 Protocolos hierrquicos ............................................................... 181.4.2 Modelo de referncia OSI ............................................................ 191.4.3 Modelo Internet............................................................................. 20

1.5 Atrasos .................................................................................................... 221.6 Consideraes finais .............................................................................. 23

CAPTULO 2: CAMADA DE APLICAO. .................................................................251 Camada de Aplicao .................................................................................... 25

1.1 Funes da Camada de Aplicao ...................................................... 251.2 Programao em sockets com Java ....................................................... 261.3 HTTP ....................................................................................................... 28

1.3.1 Mensagens HTTP .......................................................................... 301.3.2 Cookies ............................................................................................. 311.3.3 GET condicional ............................................................................ 32

1.4 FTP ........................................................................................................... 321.5 DNS ......................................................................................................... 331.6 Protocolos de e-mail ............................................................................... 35

1.6.1 SMTP............................................................................................... 351.6.2 POP e IMAP ................................................................................... 37

1.7 Consideraes finais .............................................................................. 38

CAPTULO 3: CAMADA DE TRANSPORTE..............................................................391 Camada de transporte ................................................................................... 39

1.1 UDP ......................................................................................................... 401.2 TCP .......................................................................................................... 42

1.2.1 Go-Back-N ....................................................................................... 451.2.2 Pacote TCP ..................................................................................... 47

1.2.3 Abertura de conexo .................................................................... 501.2.4 Encerramento da conexo ........................................................... 511.2.5 Sndrome da Janela Boba ............................................................. 521.2.6 Controle de congestionamento ................................................... 521.2.7 Gerenciamento de Timers ............................................................. 531.2.8 Mquina de estados TCP ............................................................. 53

1.3 Consideraes finais .............................................................................. 54

CAPTULO 4: P2P ............................................................................................................551 P2P .................................................................................................................... 55

1.1 Elementos fundamentais ................................................................ 561.2 Arquiteturas ...................................................................................... 561.3 Pesquisa e acesso .............................................................................. 571.4 Consideraes finais ........................................................................ 58

CAPTULO 5: MULTIMDIA .........................................................................................591 Multimida ...................................................................................................... 59

1.1 RTSP ........................................................................................................ 621.2 RTP .......................................................................................................... 631.3 RTCP ........................................................................................................ 641.4 Consideraes finais .............................................................................. 65

REFERNCIAS ..................................................................................................... 66

Captulo 1

INTRODUO S REDES DE COMPUTADORES

1 Introduo s Redes de Computadores

As primeiras redes de computadores datam dos anos 1960, quando se percebeu que era possvel a troca de informaes entre computadores dis-tintos. O que conhecemos como a Internet de hoje foi criado a partir da cha-mada Arpanet, que comeou a funcionar em dezembro de 1969. A Arpanet possua apenas quatro localidades, que eram sediadas no Stanford Research Institute (SRI), na Universidade da Califrnia (UCLA), na Universidade de Santa Brbara (UCSB) e na Universidade de Utah (UTAH). Linhas telefni-cas interligavam os ns presentes nestes locais. Cerca de 15 anos depois, 30 instituies j se comunicavam em rede, e o conjunto de protocolos TCP/IP, o mais importante da Arpanet e atualmente da Internet, foi criado.

Assim sendo, a tentativa de interligar computadores no nova, e j vem sendo bastante estudada h diversos anos. Com o passar do tempo, en-tretanto, o intuito da interligao de computadores foi evoluindo, chegando Internet que conhecemos nos dias de hoje.

Uma rede de computadores um conjunto de dispositivos interco-nectados entre si, que se conhecem de alguma maneira. Estes dispositivos, sejam quais forem eles, so conectados com duas finalidades principais: trocar informaes de forma barata e rpida e compartilhar recursos de hardware e software disponveis. Alguns exemplos de troca de informaes com baixo custo e alta velocidade so percebidas desde um simples envio de e-mail entre duas pessoas da mesma famlia, at um complexo site atualizado minuto a minuto com notcias correm o mundo todo em segundos. Os exem-plos no param por a, pois, atualmente, a comunicao em rede o corao de diversas ideias, tais como transaes bancrias, marketing, comrcio ele-trnico, educao a distncia e instituies que disponibilizam informaes para seus afiliados em sistemas pela Internet. Um bom exemplo de compar-tilhamento de recursos a utilizao de um dispositivo de impresso em rede, no qual todos os participantes podem enviar seus documentos para impresso em uma mesma impressora. No somente impressoras podem ser compartilhadas, mas tambm recursos de hardware, como espao em dis-co e at mesmo outros processadores; e de software, como arquivos e conexo Internet.

No comeo, entretanto, as redes de computadores eram formadas por dispositivos convencionais, ou seja, computadores pessoais. Com as constantes evolues da tecnologia, surge uma pergunta: hoje em dia, a uti-lizao do termo redes de computadores bem empregada? Esta pergunta

MATEUS RAEDER 10

UNISINOS

plausvel atualmente, pois no so somente os computadores tradicionais que participam de uma rede. Diversos exemplos podem ser citados (Figura 1): as prprias impressoras (relatadas anteriormente), notebooks, videogames, celulares e dispositivos mveis em geral, geladeiras, torradeiras, e mais uma infi nidade de aparelhos. Isto se deve ao fato de que, nos dias de hoje, a palavra computador tem um sentido muito mais amplo do que h alguns anos.

Figura 1: Alguns dispositivos que se conectam a redes.

Embora seja amplamente utilizada por pessoas para as mais diver-sas fi nalidades (acesso a informaes remotas, comunicao, diverso), a utilizao das redes ultrapassou diversas barreiras. Empresas de todos os ramos as utilizam para a comunicao entre suas diversas sedes, monitoran-do, por exemplo, estoques em todas as suas unidades. Agregado a todo este crescimento, as redes trazem uma enorme liberdade de expresso, trazendo tona discusses do que pode ou no ser compartilhado, o que agride ou no aos princpios etc. Apesar de ser uma questo de extrema importncia, no vamos entrar nesta discusso, pois foge do escopo principal do estudo.

A seguir, comeamos a estudar os principais aspectos das redes de computadores: como so formadas, classifi caes mais utilizadas, meios de transmisso entre os computadores, protocolos de rede e atrasos.

1.1 Elementos principais e classi cao

Em toda rede existem algumas entidades que realizam papis funda-mentais para uma comunicao correta: o transmissor, o receptor, o dado, o canal de comunicao e a interface de rede. A Figura 2 ilustra estas entidades e sua distribuio bsica em uma rede.

Figura 2: Entidades de uma rede.

INTRODUO S REDES DE COMPUTADORES11

UNISINOS

O primeiro deles trata-se do Transmissor, tambm chamado de Ori-gem. Este o componente que deseja enviar alguma informao pela rede. Esta mensagem contm os Dados que sero enviados para o Receptor, ou des-tino, atravs do Canal de Comunicao. O ltimo componente a Interface de Rede. Este componente responsvel pela conexo fsica dos dispositivos (transmissor e receptor) ao canal de comunicao, colocando os dados da rede na origem e retirando-os do destino.

Os transmissores e receptores tambm conhecidos como hosts geral-mente realizam os papis de enviar e receber dados, sendo comumente din-micos, pois em um momento podem estar tanto enviando quanto recebendo dados. Cada um deles possui uma identifi cao nica na rede. similar ao que acontece com as pessoas: cada uma possui seu prprio CPF e/ou RG, que a identifi ca unicamente. No caso das redes de computadores, cada host possui um endereo IP nico.

As redes so, ento, comumente classifi cadas de acordo com a distn-cia entre os hosts. A Tabela 1 apresenta uma possvel classifi cao das redes de computadores.

Abrangncia Localizados no mesmo Classi cao

10 m Sala

Rede Local (LAN)100 m Prdio

1 km Campus

10 km Cidade Rede Metropolitana (MAN)

100 km Estado/PasRede Geografi camente Distribuda (WAN)1.000 km Continente

10.000 km Planeta

Os tipos mais importantes de classifi cao de redes so as LANs, MANs, WANs e a Internet. A seguir, so comentadas cada uma destas trs, exemplifi cando e descrevendo-as de acordo com suas principais caracte-rsticas.

Uma LAN (Local Area Network) trata-se de, como a traduo do nome sugere, uma Rede Local. Comumente refere-se a uma rede privada, com al-gumas caractersticas bem especfi cas. Primeiramente, so redes que possuem poucos quilmetros de extenso, geralmente conectando alguns prdios, como um campus universitrio, por exemplo. Nestas redes, a taxa de transferncia bastante alta, devido proximidade dos hosts. Alm disto, uma LAN apre-senta uma taxa de erros extremamente baixa quando comparada com outros tipos de rede. Dentro de uma rede deste tipo no h roteamento das informa-es, sendo o envio caracterizado por um broadcast (envio para todos).

Os dispositivos em uma rede de computadores so distribudos e in-terligados de diferentes maneiras, o que chamamos de topologia. As princi-pais topologias utilizadas em redes locais so as topologias em estrela, em barra e em anel.

A topologia em estrela pode ser vista na Figura 3. Essa topologia ca-racteriza-se por possuir uma estao central, pela qual todas as informaes devem passar. Esta estao responsvel por enviar o trfego para os demais nodos da rede.

Tabela 1: Classifi cao das redes de computadores de acordo com a abrangncia

MATEUS RAEDER 12

UNISINOS

Figura 3: Topologia em estrela.

Quando os dispositivos so interligados atravs de uma topologia em barra, conforme ilustra a fi gura 4, todos os computadores so ligados em um mesmo barramento. A grande desvantagem da utilizao desta topologia o fato de que somente um n pode utilizar o barramento, que permanece ocu-pado enquanto uma transmisso est ocorrendo.

Figura 4: Topologia em barra.

Uma topologia em anel , por sua vez, caracterizada por criar um circuito fechado na forma de um anel. Neste tipo de topologia, a comunicao ocorre em uma nica direo (unidirecional), e cada n conectado a apenas dois outros ns. uma topologia em desuso (fi gura 5).

Figura 5: Topologia em anel.

INTRODUO S REDES DE COMPUTADORES13

UNISINOS

Quando uma rede atinge uma distncia maior, classifi cada como uma MAN (Metropolitan Area Network). Estas so as Redes Metropolitanas, que so uma verso ampliada das LANs. As principais caractersticas que a dife-rem das redes locais so a abrangncia (abrangem uma regio metropolitana, uma cidade) e o roteamento das informaes, pois diferentemente das LANs, nas MANs as informaes sofrem roteamento, de modo transparente para o usurio. Um padro bastante usado nas redes metropolitanas o DQBD (Dis-tributed Queue Dual Bus), ilustrado na Figura 6. So dois cabos que interligam os hosts, cada um levando informao para um sentido diferente. Um dos barramentos utilizado para transmitir os dados, enquanto outro utilizado para envi-los. Esta topologia possui duas estaes controladoras nas extre-midades, que controlam a sincronizao do barramento.

Figura 6: Distributed Queue Dual Bus.

As redes que interligam uma grande regio (como um estado, um pas, um continente) so as Redes Geografi camente Distribudas, ou WAN (Wide Area Network). A distncia dos hosts e os possveis obstculos existentes no caminho dos canais de comunicao fazem com que este tipo de rede pos-sua uma alta taxa de erros e uma baixa taxa de transmisso (quando compa-radas com as LANs). Assim como as MANs, estas redes realizam o roteamento das informaes trafegadas entre os diversos hosts.

Nos dias de hoje, o segmento da rea de redes e da indstria de com-putadores que mais cresce o das Redes Sem Fio (conhecidas como Wireless). Estas redes permitem conexes em carros, avies, celulares, e qualquer outro tipo de dispositivo (principalmente dispositivos mveis). Com esta tecnolo-gia, empresrios podem, por exemplo, criar seus prprios escritrios port-teis, com um custo baixssimo de infraestrutura. As redes sem fi o possuem classifi caes, da mesma maneira que as redes com fi o listadas acima, tambm chamadas de redes cabeadas, por utilizarem cabos para a comunicao, entre-tanto, no sero alvo de estudo neste momento.

1.2 Internet e servios

A rede mundial de computadores a chamada Internet. Trata-se de um conjunto de redes pblicas e privadas interconectadas entre si: uma rede de redes. ela que conecta milhes de equipamentos do mundo inteiro. Estes equipamentos so os j comentados hosts, ou sistemas terminais. Cada host presente na Internet opera um conjunto de protocolos, e estes protocolos so responsveis por controlar todos os passos entre o envio e o recebimento das informaes na rede, como, por exemplo, o TCP e o IP (que so os protocolos mais importantes da Internet, conhecidos coletivamente como TCP/IP). Nos captulos que seguem sero estudados diversos destes protocolos, incluindo o TCP e alguns de aplicao.

MATEUS RAEDER 14

UNISINOS

Entre os hosts, existem os canais de comunicao (ou links), que a par-tir deste momento tambm sero chamados de enlace. Estes enlaces podem ser cabos de fi bra tica, cabos coaxiais e outros meios, que tambm sero es-tudados mais adiante.

Os hosts ainda so, geralmente, conectados por equipamentos que comutam (trocam) as informaes de um host para outro. So os roteadores (routers). Estes equipamentos so utilizados para encaminhar os dados entre um enlace e outro por toda a rede, at que as informaes cheguem ao seu destino.

Conforme dito anteriormente, a Internet uma rede de redes (a rede mundial de computadores) que interliga redes pblicas e privadas. A Inter-net pblica esta rede discutida anteriormente, na qual todos os dispositivos podem ser acessados pelos demais. A Internet privada a chamada Intranet. Neste tipo de rede, os computadores no so acessveis por mquinas exter-nas. So extremamente utilizadas por corporaes, rgos governamentais e instituies de todos os setores. A Intranet utiliza as mesmas tecnologias (ro-teadores, hosts, padres, protocolos) que a Internet.

Para as aplicaes de rede (aplicaes distribudas), existem dois ti-pos de servios prestados: um servio orientado conexo e um servio no orientado conexo. A principal diferena entre estes servios que quando se utiliza um servio orientado conexo, h a garantia de entrega dos dados corretamente ao destino, diferentemente dos servios no orientados cone-xo. Estes tipos de servio tambm sero estudados mais detalhadamente nos captulos que seguem.

Para guiar a comunicao entre os hosts, o modelo de comunicao que predomina na Internet o modelo cliente/servidor. Neste modelo, os hosts presentes na rede podem ser divididos em duas categorias principais: clientes e servidores. Os clientes so classicamente estaes de trabalho co-muns, que solicitam um determinado servio aos hosts servidores. Por sua vez, os servidores so mquinas mais potentes, que tm a funo de prestar determinados servios para os clientes. Este modelo (que pode ser visualiza-do na fi gura 7) amplamente utilizado por inmeras aplicaes populares, tais como a Web, o e-mail, grupos de discusso, transferncia de arquivos, login remoto etc.

Figura 7: Arquitetura cliente/servidor

No modelo cliente/servidor, o processo cliente e o processo servidor podem estar em mquinas separadas, em redes totalmente diferentes e fi si-camente distantes um do outro, separados por uma ou vrias redes (fi gura 8). Dentre os inmeros tipos de servidores existentes, podem ser citados os servidores de arquivo de banco de dados, de impresso, de gerenciamento, dentre outros.

INTRODUO S REDES DE COMPUTADORES15

UNISINOS

Figura 8: Cliente e servidor em mquinas separadas

1.3 Meios de transmisso

J conhecemos as principais entidades presentes em uma rede de computadores, e algumas das principais caractersticas de determinados tipos de rede. Agora, vamos falar sobre um ponto de extrema importncia no momento da criao de uma rede: o meio de transmisso. Meios de transmisso nada mais so do que os caminhos fsicos que os dados per-correro da origem at o destino. onde ocorre efetivamente a comunica-o entre o remetente e o destinatrio. A regio, a verba disponvel, o que se almeja para a utilizao da rede a ser implantada so alguns dos fatores que impactam diretamente no momento da escolha do meio de transmis-so mais adequado.

Os meios de transmisso podem ser classifi cados como guiados e no-guiados. Os meios de transmisso guiados utilizam meios fsicos (ca-bos) para o envio dos dados. Os meios no-guiados, por sua vez, utilizam a prpria atmosfera terrestre, o espao para a comunicao.

1.3.1 Meios de transmisso guiados

Os meios guiados possuem sua capacidade limitada pela distncia dos hosts, pois os cabos devem ser capazes de alcanar distncias por vezes extremamente grandes. Este fato faz com que haja uma restrio na largu-ra de banda da comunicao, restringindo a taxa de transmisso (em bits/segundo). Dentre os meios de transmisso guiados, os mais comuns so: cabos coaxiais, pares tranados e fi bra tica.

Cabos coaxiais (fi gura 9) so formados por um fi o de cobre envol-vido por um material isolante (dieltrico, no conduz corrente eltrica). Por fora deste isolante ainda existem duas camadas protetoras: a mais in-terna um condutor cilndrico e a mais externa trata-se de um plstico protetor.

Como acontece com os meios de transmisso guiados, a largura de banda depende muito do tamanho do cabo, mas chega a cerca de 2Gbps em cabos com extenso de 1km. So bidirecionais e eram muito utilizados no sistema telefnico, sendo gradativamente substitudos pela fi bra tica.

Figura 9: Cabo coaxial

MATEUS RAEDER 16

UNISINOS

Os cabos de par tranado so divididos em dois tipos: sem blinda-gem (UTP - Unshielded Twisted Pair) e com blindagem (STP - Shielded Twisted Pair), sendo os sem blindagem os mais utilizados. So formados por dois fi os de cobre encapados e enrolados de forma helicoidal (fi gura 10). So en-rolados desta maneira como uma forma de diminuir a interferncia eltrica entre os fi os.

Figura 10: Cabo de par tranado

O meio de transmisso guiado que vem sendo muito utilizado o cabo de fi bra tica. Trata-se de uma fi bra de vidro extremamente fi na, ilu-minada por pulsos alternados de luz. A presena de luz no vidro signifi ca um bit em 1, enquanto a ausncia de luz indica um bit em 0. As opera-es so realizadas em alta velocidade, principalmente ponto a ponto (at 10Gbps). Os cabos de fi bra tica, alm de apresentar maior velocidade na transmisso, possuem baixa taxa de erros. A estrutura formada por um ncleo de vidro, coberto por camadas externas para proteo (fi gura 11).

Figura 11: Cabo de fi bra tica

1.3.2 Meios de transmisso no-guiados

Os meios guiados, que utilizam cabos para comunicao e envio dos dados, so bons para locais sem muitos obstculos, onde os cabos podem facilmente ser utilizados. Entretanto, quando existe a necessidade de trans-misso em locais onde a passagem dos cabos impossvel, como desertos, pntanos, regies demasiadamente montanhosas ,deve ser utilizada outra alternativa: os meios no-guiados. Os meios de transmisso no-guiados mais conhecidos so: satlites, microondas e infravermelho.

O satlite o meio de transmisso no-guiado mais conhecido no Brasil. Possibilita a comunicao entre grandes distncias, trazendo como consequncia retardos na comunicao. J os canais de micro-ondas trans-

INTRODUO S REDES DE COMPUTADORES17

UNISINOS

mitem os dados com frequncias maiores, mas para distncias menores que o satlite. O infravermelho, por sua vez, sofre muita interferncia do meio, e as distncias alcanadas so extremamente pequenas. Por exem-plo, os controles de televiso que fazem uso de infravermelho. Quando voc deseja alternar o canal da televiso, ou aumentar (ou diminuir) o vo-lume, e algum se posiciona entre o controle e o aparelho, difcil acionar a funo desejada devido difi culdade de ultrapassar obstculos que este meio apresenta.

1.4 Protocolos

No comeo do nosso estudo, comentamos sobre o fato de que os hosts operam um conjunto de protocolos. Neste captulo, vamos estud-los em detalhes, desde suas funes at a maneira na qual esto organizados.

Mas, primeiramente, uma questo deve ser bem defi nida e escla-recida: o que um protocolo? Um protocolo um conjunto de regras que determinam como a comunicao entre duas estaes de uma rede deve ocorrer. Os protocolos defi nem padres e estruturas de comunicao, nas quais mensagens especfi cas so enviadas e, de acordo com estas mensa-gens, determinadas aes so tomadas.

A associao mais comum que podemos realizar uma analogia com os seres humanos. Analise a fi gura 12. Duas pessoas bem educadas e que no se conhecem (Alan e Joana), antes de qualquer coisa trocam cumpri-mentos, e depois comeam uma conversa. Ao fi nal desta conversa, as pesso-as se despedem. O que pode ser visto neste exemplo que h um protocolo para a comunicao entre os personagens Alan e Joana, ou seja, regras de boa educao que regem a conversa, ditando que deve haver uma fase de apresentao, uma fase de conversa e uma fase de despedida.

Figura 12: Comunicao entre humanos.

Em redes de computadores temos o mesmo caso, porm, com mqui-nas ao invs de pessoas (fi gura 13). Toda a comunicao presente na Internet comandada por protocolos que defi nem o formato das mensagens, a ordem que elas devem chegar ao destino, o que deve ser feito em cada situao, alm de outros controles.

MATEUS RAEDER 18

UNISINOS

Figura 13: Comunicao entre computadores

Na comunicao entre hosts, para que as mensagens cheguem ao des-tino, informaes de controle so adicionadas a cada mensagem enviada. As-sim, para que um protocolo funcione corretamente e atenda as suas funes, necessrio que os dois lados da comunicao (origem e destino) entendam as mensagens trocadas da mesma maneira, e que as respondam tambm de uma forma legvel para ambos. A adio destas informaes de controle chamada de overhead. Quanto mais overhead for includo nas mensagens que trafegam na rede, mais lenta a comunicao. Resumidamente, os protocolos so responsveis por defi nir:

o tipo das mensagens trocadas entre as mquinasa sintaxe das mensagens (defi nindo o formato de cada um dos campos)a semntica dos campos (o que cada campo signifi ca)as regras de quando e como as mensagens so enviadas

1.4.1 Protocolos hierrquicos

As redes de computadores tm evoludo constantemente. Um dos as-pectos importantes que surgiu juntamente com esta evoluo a organizao dos protocolos de uma maneira estruturada, separando os componentes (pro-tocolos) em camadas.

Mas qual o benefcio de uma estrutura de protocolos organizada em camadas? O principal objetivo desta modularizao isolar as camadas supe-riores dos detalhes de implementao das camadas inferiores, possibilitando, assim, que funcionalidades de uma camada sejam substitudas e alteradas sem que isso infl uencie nas demais camadas. Ou seja, tornar cada camada independente das demais, de maneira transparente para o usurio.

Cada camada em uma rede de computadores realiza suas prprias funes, e denominada camada de nvel n. Como todos os hosts implemen-tam os mesmos protocolos, as camadas de mesmo nvel n em uma mquina trocam informaes entre si de acordo com um determinado protocolo. En-tretanto, as informaes no so transmitidas diretamente da camada n da mquina origem para a camada n da mquina destino.

Cada camada repassa dados e informaes para a camada imedia-tamente inferior. As entidades n utilizam servios do nvel n-1 (provi-dos pelos nveis inferiores) e fornecem servios ao nvel n+1. Na Figura 14 temos um exemplo da comunicao entre os protocolos. Perceba que uma camada no nvel n no se comunica diretamente com a sua correspondente na mquina destino, passando pelos protocolos mais abaixo na origem e che-gando ao destino, a partir do qual realiza o caminho inverso.

INTRODUO S REDES DE COMPUTADORES19

UNISINOS

Figura 14: Comunicao entre protocolos

1.4.2 Modelo de referncia OSI

Pensando na organizao em camadas dos protocolos (com a ideia de independncia e modularidade descrita anteriormente), surgiu o chamado Modelo OSI (Open Systems Interconnection, ou Interconexo de Sistemas Aber-tos). Este modelo trouxe um conjunto de diretrizes que objetivavam permitir a interconexo de redes heterogneas. Para alcanar os principais aspectos necessrios para a comunicao efi ciente de uma rede de computadores, o modelo OSI defi ne sete camadas, cada uma com suas funes especfi cas. A fi gura 15 apresenta as 7 camadas defi nidas no modelo OSI: aplicao, apre-sentao, sesso, transporte, rede, enlace e fsica.

Figura 15: Modelo de referncia OSI

MATEUS RAEDER 20

UNISINOS

A primeira camada (ou primeiro nvel) a camada Fsica. Neste nvel esto os equipamentos fsicos, como os cabos e demais meios de co-municao. esta camada a responsvel por mover os bits entre os hosts atravs do meio de transmisso. A camada Fsica tambm controla a taxa de transferncia dos bits e a velocidade de transmisso da rede.

Logo aps a camada Fsica, surge a camada de Enlace. A principal funo desta camada detectar possveis erros ocorridos no nvel fsico e corrigi-los, se for o caso.

Em seguida, a camada de Rede responsvel, principalmente, por enderear corretamente cada mensagem ao seu destino. Nesta cama-da ocorre o roteamento das mensagens (encontrar o caminho entre o host origem e o host destino), de acordo com o endereo IP dos participantes da comunicao.

A camada de Transporte vem logo a seguir. ela a responsvel por transmitir os dados que vm dos nveis superiores para a camada de Rede, realizando, (quando necessrio), controle de fl uxo, ordenao de pacotes e eventuais correes de erros.

Para marcar uma comunicao entre dois hosts, o modelo OSI traz a camada de Sesso. Esta camada possibilita que, caso algum erro ocor-ra na rede durante determinada comunicao, os hosts possam continuar suas transmisses de onde haviam parado ou, no mnimo, da ltima mar-cao realizada.

A penltima camada a de Apresentao, na qual os dados podem ser criptografados na origem e decodifi cados no destino (no mesmo nvel). Alm disso, a camada de Apresentao pode comprimir os dados que vm da aplicao, agilizando o envio.

Finalmente, a camada mais prxima do usurio a camada de Aplicao. Nela, os dados que o usurio deseja enviar so obtidos, e onde comea toda a necessidade de comunicao entre computadores dis-tintos. a camada que responsvel por tratar todos os aspectos relativos aos aplicativos utilizados para a comunicao.

Apesar de surgir como uma alternativa atraente pela diviso totalmente modular dos protocolos, o modelo OSI no obteve xito co-mercial. Isto se deve a alguns fatores, sendo o principal deles a com-plexidade de implementao e implantao. As primeiras verses deste modelo demoraram muito para serem lanadas e no apresentavam um bom desempenho como desejado. Alm disso, nem sempre todas as camadas so necessrias na comunicao pela rede. Por exemplo, o envio de e-mails no utiliza a ideia de sesso, e a transferncia de arquivos no utiliza criptografia.

Assim sendo, o modelo OSI tornou-se um modelo de referncia terico e no utilizado na prtica.

1.4.3 Modelo Internet

Diferentemente do modelo OSI, a pilha de protocolos da Internet, chamada Modelo Internet ou ainda Modelo TCP/IP apresentou-se mais efi -ciente e mais prtica do que as complexas camadas do modelo OSI. Este novo modelo formado por 5 camadas1, que agrupam as funes do mo-delo OSI em uma estrutura mais simples e com um desempenho melhor. A fi gura 16 ilustra as camadas da pilha de protocolos da Internet, mostran-do onde so situadas as funcionalidades previstas no Modelo de Refern-cia OSI.

1 Alguns autores agrupam as duas ltimas camadas, classifi cando o modelo com apenas 4 camadas

INTRODUO S REDES DE COMPUTADORES21

UNISINOS

Figura 16: Pilha de protocolos da Internet

As 5 camadas do Modelo Internet so: aplicao, transporte, rede, enlace e fsica. Conforme pode ser percebido na fi gura 16, as camadas de Sesso e Apresentao foram retiradas deste modelo, mas suas funcionali-dades permanecem presentes. A camada de Aplicao do modelo Internet agrega as funcionalidades das camadas de Aplicao, Apresentao e Sesso do modelo OSI, enquantos demais camadas realizam as funes discutidas anteriormente.

Figura 17: Comunicao horizontal dos protocolos

Lembre-se de que todos os hosts implementam as camadas do modelo Internet. A principal caracterstica da diviso em camadas que os protocolos do mesmo nvel em um host origem comunicam-se com os protocolos do mesmo n-vel no host destino. Ou seja, a camada de Aplicao no host A comunica-se com a camada de Aplicao no host B, a camada de Transporte no host A comunica-se com a camada de Transporte no host B, e assim sucessivamente. Esta comunica-o dita comunicao horizonta, e exemplifi cada na fi gura 17.

Obviamente, os protocolos no conversam horizontalmente uns com os outros pela rede de forma direta. Esta comunicao horizontal apenas lgica, e no fsica. A comunicao fsica a comunicao vertical, conforme visto anteriormente na fi gura 14.

MATEUS RAEDER 22

UNISINOS

Para que a comunicao entre os protocolos empilhados seja realizada, a mensagem que sai de um usurio passa por todas as camadas exatamente na ordem ilustrada na Figura 14. Primeiramente os dados passam pela camada de Aplicao, que possui uma interface de comunicao com a camada de Trans-porte, que por sua vez comunica-se com a camada de Rede, que passa os dados para a camada de Enlace, que vai repassar para a camada Fsica. Neste ponto, os dados so enviados at o host destino pela rede de comunicao.

Mas como um protocolo de nvel n conversa com outro protocolo de nvel n em outro host? Atravs da introduo de informaes de controle na mensagem original. A cada camada que os dados passam na comunicao vertical, estas informaes de controle adicionais so introduzidas na men-sagem, na forma de cabealhos (Figura 19). Ou seja, cada camada adiciona mensagem o seu cabealho especfi co. A mensagem percorre a rede com todas estas informaes adicionais encapsuladas at encontrar seu destino. No des-tino, o processo oposto realizado, e estes cabealhos so retirados um a um a cada nvel que a mensagem passa.

Figura 19: Introduo de cabealhos na mensagem

Assim sendo, a comunicao vertical adiciona informaes em cada nvel n, e no destino estas informaes so removidas e lidas pelo mesmo nvel n, o que caracteriza a comunicao horizontal.

1.5 Atrasos

As mensagens enviadas atravs de uma rede de computadores no che-gam ao seu destino instantaneamente. Os dados enviados sofrem alguns atrasos durante o seu trajeto e a maneira de calcul-los sero estudados a seguir.

Considere a viso geral de uma rede de computadores vista na fi -gura 1. Os dados que trafegam pela rede de um n at outro, seja este n um host ou um roteador, sofrem os seguintes tipos de atraso (mais impor-tantes): atraso de processamento nodal, atraso de enfi leiramento, atraso de transmisso e atraso de propagao. A fi gura 20 ilustra onde ocorre cada um destes tipos de atraso.

Figura 20: Atrasos e seus locais de ocorrncia

INTRODUO S REDES DE COMPUTADORES23

UNISINOS

Quando um pacote chega a um n, ele examinado para determi-nar para onde deve ser encaminhado. O tempo necessrio para fazer esta verifi cao o atraso de processamento (Dproc). Alm disso, parte do atraso de processamento o tempo gasto para verifi car a ocorrncia de erros nos bits do pacote. Logo aps estes processos, o pacote enviado para uma fi la de sada, na qual encontram-se todos os pacotes que esto prontos para serem enviados ao enlace. O tempo que o pacote espera na fi la para ser enviado para a rede o atraso de enfi leiramento (Dqueue). Este atraso de-pende, obviamente, da quantidade de pacotes que j se encontram na fi la aguardando o momento da transmisso. Quanto mais trfego, maior ser o atraso Dqueue. Se no houver pacotes na fi la, o atraso de enfi leiramento do pacote zero.

O pacote, em algum momento, torna-se o prximo a ser enviado. A partir da, calculado o prximo atraso: o de transmisso (Dtrans). Este atraso a quantidade de tempo necessria para retirar o pacote da fi la e coloc-lo no enlace, ou seja, o tempo necessrio para colocar todos os bits do pacote para o canal de comunicao. Mas cuidado! No se refere ao tempo de transmisso do pacote para o prximo n, mas sim o tempo de retirar o pacote da fi la. Assim sendo, considere um pacote de L bits de comprimento. Se a taxa de transmisso do enlace denotada por R bits por segundo (bps), temos que: Dtrans = L/R segundos.

Assim que um bit do pacote empurrado para o enlace, ele no fi ca esperando os demais, e comea a ser imediatamente propagado para o pr-ximo n pelo enlace. O tempo necessrio para propagar um bit do pacote para o prximo n o atraso de propagao (Dprop). A medida deste atraso depende muito do meio fsico utilizado no enlace (fi bra tica, fi o de cobre etc), e calculada como a distncia entre os dois ns (de onde o pacote est saindo e para onde deve chegar) dividida pela velocidade de propagao do enlace. Deste modo, para ns a uma distncia de D metros, interligados por um enlace com velocidade de propagao de S metros por segundo, temos que: Dprop = D/S segundos.

de extrema importncia perceber a diferena entre o atraso de transmisso e o atraso de propagao. No primeiro (Dtrans), o atraso a quantidade de tempo para que o n empurre todos os bits do pacote para o enlace, enquanto no segundo (Dprop) o tempo que um bit leva para pro-pagar de um n a outro.

A soma destes atrasos resulta no atraso nodal total (Dnodal), que dado pela frmula: Dnodal = Dproc + Dqueue + Dtrans + Dprop.

O atraso fi m a fi m (desde o host origem do pacote at o host destino) a soma de todos os atrasos nodais sofridos pelo pacote no percurso.

1.6 Consideraes nais

Vimos at agora conceitos iniciais e importantes sobre redes de computadores. Seus componentes principais, tipos de classifi cao, meios de transmisso mais utilizados e algumas caractersticas de cada um de-les. Ainda neste captulo, falamos sobre protocolos, defi nindo o que so, para que servem e como so organizados. Estudamos sobre o modelo de referncia OSI, e sua importncia na criao dos protocolos e na diviso em camadas utilizada na Internet. Aprendemos, tambm, a calcular o atraso so-frido pelas mensagens na rede, relatando os tipos importantes de atraso e o motivo de existirem.

A partir deste ponto, vamos comear a estudar as duas camadas su-periores da pilha de protocolos TCP/IP: a camada de aplicao e a camada de transporte. No estudo de cada uma destas camadas, sero estudados os principais protocolos existentes em detalhes.

Captulo 2

CAMADA DE APlICAO

Sabemos que a pilha de protocolos da Internet dividida em camadas, cada uma delas com suas funes especficas. Neste captulo, comeamos a estudar em detalhes a Camada de Aplicao. So apresentados os principais protocolos desta camada, dentre eles: HTTP, FTP, SMTP, POP, IMAP e DNS.O principal intuito deste captulo o aprendizado tanto terico quanto prtico destes protocolos. Alm disso, a programao de aplicaes de rede com sockets, em Java, abordada.

1 Camada de aplicao

1.1 Funes da Camada de Aplicao

A camada de Aplicao situa-se no ltimo nvel da pilha de protoco-los da Internet, sendo a mais prxima dos usurios. Geralmente, cada camada possui poucos protocolos principais (1 ou 2). Isso no ocorre na camada de Aplicao, na qual existem diversos protocolos, um para cada tipo de servio, podendo, ainda, um determinado servio fazer uso de mais de um protocolo de Aplicao (como o servio de e-mail, por exemplo, que utiliza ou pode utilizar os protocolos SMTP, POP e IMAP).

Na camada de aplicao encontramos a parte principal das redes de computadores: de nada serviria a implantao de uma rede se nenhuma aplica-o fosse utiliz-la. Estas aplicaes, que so distribudas em diversos hosts, co-municam-se atravs de troca de mensagens, e os protocolos do nvel de Aplicao so os responsveis por detalhar desta comunicao, no que tange a aspectos de controle e formato das mensagens trocadas entre as aplicaes.

Entretanto, importante ressaltar que os protocolos da camada de Apli-cao no so a aplicao, mas sim uma parte fundamental delas, definindo as mensagens que sero enviadas e cada ao que deve ser tomada em determina-das situaes.

Vamos chamar um determinado programa que est sendo executado em um host de processo. Dentro do mesmo host, a comunicao entre dois processos definida pelo sistema operacional (interprocess communication). J processos em hosts diferentes utilizaro protocolos da camada de Aplicao para se comunicarem.

Entre o usurio e a aplicao de rede existe a figura do Agente de Usu-rio (User Agent UA), que a interface entre o usurio e a aplicao de rede. Como exemplos de agentes de usurio, podemos citar os browsers (que so os UA da aplicao Web), os leitores de e-mail (que so os UA de correio) e os tocadores de mdia (que so os UA das aplicaes de streaming de udio e vdeo).

O paradigma que mais utilizado na Internet o paradigma cliente/servidor. Nele existem duas figuras principais:

26

UNISINOS

MATEUS RAEDER

cliente : que solicita um determinado servio (por exemplo, leitores de correio eletrnico)servidor : que recebe um determinado pedido, executa este pedido e res-ponde (por exemplo, servidores de correio eletrnico)

Existe uma interface de programao de aplicaes (Application Pro-gram Interface - API), que defi ne a comunicao entre a aplicao e a camada de transporte. Para aplicaes da Internet, vamos utilizar sockets. Na rede de computadores, dois processos, em locais diferentes ou no, comunicam-se um com o outro atravs do recebimento e do envio de dados atravs de um socket. Na prxima seo, estudaremos mais sobre sockets, apresentando como criar uma aplicao que permita a comunicao entre duas mquinas da rede com a utilizao da linguagem Java.

1.2 Programao em sockets com Java

Vamos, neste captulo, aprender a criar aplicaes cliente/servidor que se comunicam em rede atravs de sockets. A linguagem de programao que iremos utilizar a Java.

Um socket um mecanismo que permite que um host envie uma mensa-gem e outro host receba. Mais especifi camente, um host grava informaes em um socket, e outro retira estas informaes do socket. Para isto, devemos defi nir uma porta de comunicao, que por onde os dados iro entrar no host destino.

Vamos criar uma aplicao simples, na qual o cliente envia uma men-sagem de texto para o servidor, que a imprime e retorna uma resposta de agradecimento, que ser impressa no cliente.

O cliente l uma linha de entrada digitada pelo usurio via teclado e envia para o servidor via socket. O servidor, ento, processa os dados (neste caso simplesmente imprime a mensagem) e retorna para o cliente uma res-posta, tambm atravs do socket. O cliente l a mensagem de resposta do ser-vidor e exibe-a na tela.

O servio que vamos utilizar aqui orientado conexo (usando TCP), embora seja possvel a criao de sockets que utilizem o protocolo UDP (ambos os protocolos sero estudados no decorrer dos captulos). Veja abaixo o cdigo-fonte da classe que far o papel de servidor na aplicao.

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.

import java.io.*;import java.net.*;class Servidor { public static void main(String argv[]) throws Exception { String mensagemRecebida; String mendagemEnviada = Obrigado!;

ServerSocket serverSocket = new ServerSocket(6789);

while(true) { Socket meuSocket = serverSocket.accept();

Bu eredReader entrada = new Bu eredReader(new InputStreamReader(meuSocket.getInputStream()));

DataOutputStream saida = newDataOutputStream(meuSocket.getOutputStream());

mensagemRecebida = entrada.readLine(); System.out.println(Cliente enviou: + mensagemRecebida); saida.writeBytes(mendagemEnviada); } }}

27

UNISINOS

CAMADA DE APLICAO

As primeiras linhas so importantes para as funes de entrada e sada (linha 1) e de suporte a rede (linha 2). Primeiramente, para que uma comunicao cliente/servidor ocorra, deve haver um servidor executando, aguardando uma conexo. Esta conexo ser realizada em determinada porta do host servidor, e deve ser defi nida pelo usurio. A defi nio da porta na qual o servidor estar aguardando conexes realizada na linha 9 do cdigo exemplo, na qual o servidor cria um ServerSocket. Neste caso, estamos criando um servidor que vai aguardar que algum host se conecte nele atravs da porta 6789. O servidor aguarda (linha 12) uma conexo de algum cliente na porta defi nida. Esta linha bloqueante, e o servidor s seguir sua execuo quan-do algum cliente solicitar a conexo. Quando isto ocorre, o servidor cria um fl uxo de entrada ligado ao socket (linha 14), e cria um fl uxo de sada ligado ao socket (linha 17). Na linha 20, o servidor l o que o cliente escrever no socket (tambm bloqueante). A frase , ento, exibida na tela (linha 21) e a resposta enviada para o cliente pelo mesmo socket (linha 22). Abaixo, podemos visuali-zar o cdigo-fonte do cliente da nossa aplicao.

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.

import java.io.*;import java.net.*;class Cliente { public static void main(String argv[]) throws Exception { String mensagemParaServidor; String respostaServidor;

Bu eredReader digitado = new Bu eredReader(new InputStreamReader(System.in));

Socket meuSocket = new Socket(IP_Servidor, 6789);

DataOutputStream saida = new DataOutputStream(meuSocket.getOutputStream());

Bu eredReader entrada = new Bu eredReader(new InputStreamReader(meuSocket.getInputStream()));

mensagemParaServidor = digitado.readLine(); saida.writeBytes(mensagemParaServidor + \n); respostaServidor = entrada.readLine(); System.out.println(Servidor enviou: + respostaServidor); meuSocket.close(); }}

O cliente cria um uxo de entrada do usurio na linha 9, que servir para ler a frase que ser enviada para o servidor. na linha 12 que o socket cliente criado. Repare que no somente a porta informada, mas tambm o endereo IP, no formato de uma String. Esta linha a responsvel por solicitar a conexo no cliente de IP IP_Servidor na porta determinada (no caso, 6789). Conforme vimos no cdigo anterior, o servidor est aguardando uma conexo exatamente nesta porta. As prximas linhas so anlogas ao cdigo do servidor, criando o uxo de sada e o uxo de entrada do cliente, ambos ligados ao socket. A linha 21 a leitura da linha do usurio, e na linha 22 o cliente de fato escreve no socket a informao que o servidor deve ler (perceba que o servidor est bloqueado no readLine(), aguardando esta escrita). Logo em seguida, a vez do cliente fi car bloqueado, aguardando uma resposta do ser-vidor (linha 23). Quando a resposta fi nalmente chega, a mensagem exibida na tela e o socket fechado (linhas 24 e 25, respectivamente).

A partir desta simples aplicao, vrios exemplos podem ser criados e analisados. Cabe ressaltar que a utilizao de sockets em Java no permite apenas o envio de textos simples, mas tambm permite o envio de classes inteiras e objetos mais complexos. Tudo depende do que o usurio deseja im-plementar.

28

UNISINOS

MATEUS RAEDER

2.3 HTTP

O primeiro protocolo da camada de Aplicao que vamos abor-dar trata-se do protocolo HTTP (HyperText Transfer Protocol), que defi ne as regras de comunicao na World Wide Web (WWW ou simplesmente Web). Antes de falarmos especifi camente sobre o HTTP, apresentaremos alguns aspectos importantes.

A comunicao na Web feita atravs de pginas, que so arquivos descritos atravs da linguagem HTML (HyperText Markup Language). Trata-se de uma linguagem simples para hipertexto, que comeou como uma ver-so de SGML (Standard Generalized Markup Language). Uma pgina HTML construda basicamente por cadeias de texto, formadas por tags inseridas no corpo do arquivo entre os caracteres < (menor) e > (maior). Alguns exem-plos de tags HTML so:

texto : formata o texto em negrito texto : formata o texto em itlico texto : centraliza o texto: insere uma imagem (mais espe-

cifi camente o arquivo referenciado no caminho indicado)

Alm destas, existem diversas outras tags que formatam textos e in-serem objetos na pgina (listas, tabelas, frames, imagens, vdeos, sons etc.).

Assim, uma pgina Web consiste de vrios objetos referenciados por uma URL (Universal Resource Locator). Esta URL tem duas partes: o nome do hospedeiro e o nome do caminho. Estas pginas so armazenadas em servidores Web. Para visualizar tais pginas, existe a fi gura do agente de usurio, que chamado de Browser. Exemplos de browsers so o Internet Explorer e o Firefox.

O protocolo HTTP opera com o modelo cliente/servidor. O cliente o lado que solicita e recebe os objetos Web armazenados no servidor. O ser-vidor, por sua vez, recebe os pedidos dos clientes e envia os objetos referen-ciados como resposta. o HTTP1 que controla as regras desta comunicao entre cliente e servidor.

O protocolo da camada de Transporte utilizado pelo HTTP o TCP2. O fl uxo da comunicao do HTTP ocorre basicamente com os passos a seguir:

o cliente abre uma conexo TCP com o servidor (atravs do socket) na porta 80o servidor aceita a conexo TCP solicitadacliente e servidor trocam mensagens HTTP (ou seja, o agente de usurio troca mensagens com o servidor Web)a conexo encerrada

Suponha que o usurio digita a URL www.inf.unisinos.br/index.html no seu browser. Suponha, ainda, que esta HTML possui quatro imagens re-ferenciadas. A fi gura 21 ilustra o fl uxo de mensagens trocadas entre cliente e servidor.

Perceba que uma conexo aberta para cada objeto solicitado. Assim, seriam nove conexes abertas e encerradas: uma para a solicitao do objeto inicial (index.html) e oito para os objetos referenciados (no caso, as imagens presentes no arquivo). Este o procedimento realizado no HTTP/1.0. O servi-dor analisa o pedido, responde e encerra a conexo, utilizando dois RTTs3 para cada objeto (um para iniciar a conexo e um para receber a resposta). Logo, o tempo de transmisso do arquivo dado por dois 2RTT + tempo de transmis-so, conforme ilustra a fi gura 22.

1 A verso 1.0 do HTTP de-fi nida na RFC 1945, e a ver-so 1.1 na RFC 2068

2 O protocolo TCP ser estu-dado no Captulo 3. No mo-mento, basta sabermos que um servio da camada de Transporte que garante a entrega correta dos dados

3 RTT (Round Trip Time) o tempo que um pacote leva para ser enviado e retornar ao remetente

29

UNISINOS

CAMADA DE APLICAO

Figura 21: Fluxo de mensagens entre cliente e servidor

Figura 22: Round Trip Time

Objetivando diminuir a quantidade de aberturas de conexes entre o mesmo cliente e o mesmo servidor, o HTTP/1.1 utiliza uma s conexo para o envio de todos os objetos. Assim, o cliente abre uma conexo com o servidor e envia seu pedido. O servidor responde para o cliente, que realiza um novo pe-dido, na mesma conexo. Assim, ocorre uma diminuio no nmero de RTTs.

Suponha o mesmo caso anterior, uma HTML com quatro objetos refe-renciados. Como h somente uma abertura de conexo, teremos um RTT para esta conexo ser criada e um RTT para cada objeto referenciado (quando antes tnhamos dois RTTs por objeto).

Apesar de prover regras para a comunicao, o HTTP um protocolo que no guarda estado, ou seja, stateless. Isto signifi ca que o servidor no tem a capacidade de manter histricos e informaes sobre os pedidos que foram

30

UNISINOS

MATEUS RAEDER

realizados anteriormente pelo cliente. Tal fato acrescentaria certa complexida-de ao protocolo, uma vez que os estados guardados pelo cliente e pelo servi-dor deveriam ser, necessariamente, os mesmos guardados pelo servidor caso um dos lados casse, por exemplo.

1.3.1 Mensagens HTTP

Existem dois tipos de mensagens HTTP: requisio e resposta. Ambas utilizam o formato ASCII, um formato legvel por humanos. A fi gura 23 mos-tra o formato geral de uma mensagem HTTP de requisio.

Figura 23: Formato da mensagem HTTP de requisio

Na primeira linha da requisio informa-se o mtodo de mensagem. Note que o que separa os campos desta linha um espao. Ao fi nal de cada linha, existe um (Carriage Return e Line Feed). Estes mtodos podem ser, por exemplo (HTTP1.1):

GET: solicita um recurso (um arquivo, por exemplo)HEAD: similar ao GET, porm, o recurso no includo na respostaPOST: envia dados que devem ser processadosPUT: envia arquivos no corpo da mensagemDElETE: apaga o arquivo especifi cado

Os mtodos TRACE, CONNECT e OPTIONS tambm podem ser utili-zados. Em seguida, existe a rea de cabealhos, onde zero ou mais cabealhos podem ser adicionados. Primeiramente, deve-se colocar o nome do cabea-lho, seguido por : (dois pontos). Logo aps, o valor do campo informa-do, e para indicar o trmino de uma linha acrescenta-se . Quan-do houver algum objeto para ser enviado, ele vem no corpo da mensagem. A fi gura 24 apresenta um exemplo real de uma mensagem HTTP de requisi-o. No caso ilustrado, utiliza-se o mtodo GET.

Figura 24: Exemplo de mensagem de requisio (utilizando GET)

31

UNISINOS

CAMADA DE APLICAO

Assim, quando clicamos em botes e escrevemos o endereo de uma pgina no browser, mensagens deste tipo so criadas e trocadas entre o cliente e o servidor. O formato geral de uma mensagem de resposta do protocolo HTTP pode ser visto na fi gura 25.

Figura 25: Formato geral de uma mensagem HTTP de resposta

Na primeira linha, verifi camos o cdigo de status da mensagem e uma frase referente a este status. Alguns dos cdigos mais comuns so:

200 OK : indica sucesso, e o objeto pedido est na mensagem; 301 Moved Permanently : indica que o objeto solicitado no se en-contra no local informado, e informa o novo local do objeto no corpo da mensagem, para que possa ser acessado corretamente; 400 Bad Request : indica que o servidor no conseguiu, por algum motivo, interpretar o pedido realizado pelo cliente; 404 Not Found : indica que o objeto solicitado no est presente no servidor; 505 HTTP Version Not Supported: indica que o servidor no est apto a utilizar a verso HTTP informada pelo cliente.

A estrutura da mensagem de resposta similar de requisio. O que muda, basicamente, o contedo da primeira linha. A fi gura 26 ilustra uma mensagem de resposta HTTP representando que o objeto solicitado foi encontrado no servidor. Esta resposta referente requisio realizada na fi gura 24.

Figura 26: Exemplo de mensagem de resposta (com cdigo 302 Found)

1.3.2 Cookies

O protocolo HTTP faz uso dos chamados cookies, que so utilizados para guardar as informaes dos usurios. Os cookies so defi nidos na RFC 2109. Por exemplo, um usurio entra em um determinado site que utiliza o mecanismo de cookies. O servidor ir incluir em sua mensagem de resposta a

32

UNISINOS

MATEUS RAEDER

linha Set-cookie: id, onde id a identifi cao do cookie. Quando o cliente recebe esta resposta, armazena este cookie em uma lista local. Assim, nos prximos pedidos para o mesmo servidor, o cliente ir incluir na sua mensagem a linha Cookie: id, que servir para que o servidor recupere as informaes do usu-rio que foram previamente armazenadas (o servidor, de maneira anloga, mantm uma lista de cookies, para que as informaes de cada cliente possam ser recuperadas).

A funo deste mecanismo autenticar o usurio sem a necessidade de pedir ao usurio que digite sua senha em todas as visitas, lembrar prefe-rncias do usurio, apresentar mensagens direcionadas a um determinado cliente, de acordo com o que ele costuma pesquisar etc.

1.3.3 GET condicional

Vimos que o protocolo HTTP recupera objetos armazenados no servi-dor e referenciados em pginas HTML. Porm, algumas vezes estes objetos j foram previamente extrados, e podem estar na cache do cliente. Com o intuito de reduzir os custos da extrao destes objetos remotos, o HTTP implementa um mecanismo chamado GET Condicional. O objetivo deste mecanismo que o objeto no precisa ser enviado pelo servidor se o cliente j possui uma verso atual armazenada em sua cache.

Uma mensagem de requisio um GET Condicional se utiliza o mtodo GET e possui a linha de cabealho: If-modifi ed-since: (onde data indica a data em que o objeto foi armazenado na cache do cliente). Caso o objeto no servidor no tenha sido modifi cado desde data, respon-der com uma mensagem sem o objeto includo e com a linha de status 304 Not Modifi ed.

1.4 FTP

Transferir arquivos uma das tarefas mais realizadas na Web. Quan-do criamos um site, por exemplo, necessitamos enviar os arquivos HTML e demais arquivos (imagens, vdeos etc.) para o servidor que ir armazen-los. Assim, quando algum acessar o site, os objetos sero recuperados via HTTP, conforme visto anteriormente. Para transferir arquivos entre hosts, utilizamos o protocolo FTP (File Transfer Protocol).

O FTP tambm utiliza o modelo cliente/servidor e o protocolo TCP para o transporte dos dados. O cliente o lado da comunicao que iniciar a transferncia. Esta transferncia pode ser para o servidor remoto (upload) ou do servidor remoto (download). O protocolo FTP defi nido na RFC 959 e os servidores FTP operam na porta 21.

A principal caracterstica deste protocolo ser um protocolo chamado fora da banda. Isso se deve ao fato de que, quando um cliente abre uma conexo com um servidor, duas conexes so abertas:

conexo de controle : controla toda a comunicao e envio entre os hosts. Opera na porta 21.conexo de dados : envia os dados desejados entre os hosts. Opera na porta 20.

Ou seja, duas conexes TCP so criadas, e o controle enviado em uma conexo diferente. importante ressaltar que a conexo de controle persistente, enquanto a de dados no persistente. Isso signifi ca que uma conexo TCP criada para cada arquivo transferido, enquanto o controle per-manece sempre com a mesma conexo.

Os comandos tpicos do protocolo so enviados em modo texto ASCII pelo canal de controle. Os mais tpicos so:

33

UNISINOS

CAMADA DE APLICAO

USER nome: informa o nome de usurio para autenticaoPASS senha: informa a senha do usurio para autenticaolIST : lista os arquivos que se encontram no diretrio correnteRETR arquivo: recupera o arquivo remotoSTOR arquivo: armazena o arquivo no host remoto

Como resposta a estes comandos, as mensagens de resposta so na forma cdigo e frase (como no HTTP). Alguns exemplos so:

331 username OK, password required : indica que o usurio indicado foi aceito, e que o mesmo necessita informar senha.125 data connection already open, transfer starting : informa que os da-dos j podem comear a ser transferidos, pois a conexo de dados j foi estabelecida425 cant open data connection : ocorreu um erro na abertura da conexo de dados.

Diferentemente do HTTP, o servidor FTP consegue armazenar infor-maes de estado, como por exemplo, o diretrio em que o usurio encontra-se e a autenticao previamente realizada por ele.

1.5 DNS

Cada dispositivo conectado Internet possui um identifi cador ni-co, chamado endereo IP (Internet Protocol). Este identifi cador utilizado para enderear as mensagens enviadas, e so compostos por nmeros. Por exem-plo, o host www.unisinos.br possui o endereo 200.188.161.4 (utilizando IPv4). Obviamente, muito mais fcil e intuitivo para ns humanos lembrar-nos do nome (hostname) www.unisinos.br do que do seu endereo IP. Imagine se fosse necessrio que soubssemos o endereo IP de todos os sites que acessamos no dia a dia.

Entretanto, este endereo o que vai informar a exata localizao de determinado host na Internet, e um mapeamento necessrio, ou seja, a transformao (ou traduo) do hostname para o seu respectivo endereo IP. Este servio de traduo de nomes de responsabilidade do DNS (Domain Name Server). O DNS utiliza o protocolo UDP1 e trabalha por padro na porta 53. Podemos ver o DNS como um conjunto de bancos de dados que esto distribudos em diversos servidores ao redor do mundo. Nestes servidores (chamados servidores DNS) encontram-se as informaes de qual IP est associado a cada hostname.

O funcionamento do DNS d-se como segue:suponha que o usurio deseja acessar o site www.unisinos.brpara que a mensagem de requisio HTTP chegue ao seu destino, necessrio a obteno do endereo IP de www.unisinos.bro host do usurio roda, ento, o lado cliente do DNS, enviando ao servidor uma consulta informando o nome do host que deseja traduzir (no caso, www.unisinos.br)o cliente recebe como resposta o endereo IP do host desejado

Para a resoluo dos nomes, o DNS utiliza uma estrutura hierr-quica de servidores. Estes servidores so de 3 tipos: servidores de nomes locais, servidores de nomes raiz e servidores de nomes com autoridade.

Os servidores de nomes locais so aqueles que esto mais prximos do cliente, e o primeiro servidor a ser consultado. Quando este servidor no sabe resolver o nome solicitado, uma consulta ao servidor de nomes raiz realizada. Se este servidor tambm no consegue resolver o hostname solicitado, um servidor de nomes com autoridade utilizado. Todo host

1 O protocolo UDP ser estu-dado no Captulo 3. No mo-mento, basta sabermos que um servio da camada de Transporte que no garante a entrega correta dos dados

34

UNISINOS

MATEUS RAEDER

est necessariamente registrado em um servidor de nomes com autoridade, garantindo que o mapeamento ser corretamente realizado. Quando o host-name for resolvido, a resposta retorna ao cliente com o IP correspondente.

Figura 27: Exemplo de consulta recursiva (a) e iterativa (b)

Estas consultas realizadas podem ser recursivas ou iterativas. Nas consultas recursivas, a responsabilidade de traduzir o nome solicitado repassada ao prximo servidor, e a resposta com o IP solicitado realiza o mesmo caminho de volta (fi gura 27a). Nas consultas iterativas, por sua vez, quando um servidor solicita a resoluo para um servidor e este no sabe realizar o mapeamento, este servidor no pega a responsabilidade para si, mas responde para o cliente: no conheo este nome, mas per-gunte para este servidor. Assim, o prprio cliente vai pesquisando nos demais servidores, at que uma resposta seja encontrada. Normalmente, o host solicita a resoluo para o servidor local, que age como cliente fazendo consultas iterativas, enviando a resposta ao host quando esta for encontra-da (fi gura 27b).

Os servidores armazenam os chamados RRs Registros de Recursos. Na resposta do servidor, so includos um ou mais RRs. O formato de um recurso dado por: (nome, valor, tipo, TTL).

Os campos nome e valor dependem estritamente do tipo. Quando o tipo A (o mais comum), o contedo de nome contm o hostname e o de valor contm o IP. Se o tipo for CNAME, o campo nome possui um apelido (alias) para o nome verdadeiro, e valor possui o nome real do host desejado. Caso o tipo do registro seja NS, o campo nome ser o domnio e o campo valor ser o servidor de autoridade para aquele domnio, ou seja, o dono do domnio. Caso o tipo do registro seja MX, trata-se de informaes que se-ro utilizadas por servidores de e-mail para o envio correto das mensagens (roteamento). Assim, o nome o domnio e o valor o nome do servidor de correio para este domnio.

O ltimo campo trata-se do TTL (Time To Live). Cada vez que uma resposta enviada ao cliente, o servidor armazena este mapeamento em uma cache local. Assim, quando for requisitado novamente em outra oca-sio, o endereo j conhece o IP e pode responder diretamente. Como os endereos IP podem sofrer mudanas, estas entradas so descartadas depois de certo tempo. Este tempo o TTL.

35

UNISINOS

CAMADA DE APLICAO

1.6 Protocolos de e-mail

Uma das aplicaes mais utilizadas na Internet o correio eletrnico. Seu crescimento repentino deu-se devido ao fato de que enviar uma mensa-gem via Internet mais rpido, mais barato, de mais fcil distribuio, e com mais recursos (envio de imagens, vdeos e sons) do que atravs de outros sistemas, como o correio tradicional.

Quando falamos sobre correio eletrnico, estamos falando basica-mente sobre trs grandes entidades (fi gura 28): Agente de Usurio (Mail User Agent MUA), Agente de Transporte (Mail Transport Agent) e os Proto-colos de Correio.

Figura 28: Componentes do e-mail.

Os agentes de usurio so os conhecidos leitores de e-mail. So as apli-caes sobre as quais o usurio interage, compondo, editando, lendo men-sagens de correio. Como exemplos, podemos citar o Outlook Express, Evo-lution, Pegasus, Thunderbird, dentre outros. Estas aplicaes fazem o papel de cliente do correio eletrnico. Entretanto, as mensagens no so enviadas diretamente para os agentes de usurio. Quando uma mensagem chega ou enviada, elas fi cam armazenadas nos agentes de transporte, que so os servi-dores de correio.

1.6.1 SMTP

Servidores de correio armazenam as mensagens recebidas em uma fi la de mensagens que sero posteriormente entregues ao usurio. Alm disso, armazenam as mensagens que o usurio deseja mandar (que foram enviadas atravs do agente de usurio) em uma fi la de sada. Neste con-texto, quando um servidor de correio deseja enviar uma mensagem para outro servidor de correio, utilizado o protocolo SMTP (Simple Mail Trans-fer Protocol). O papel de cliente executado pelo servidor que enviar a mensagem, e o papel de servidor ser realizado pelo servidor que receber a mensagem.

O SMTP5 utiliza TCP para a transferncia dos dados, e a conexo feita na porta 25. o protocolo que faz a transferncia direta entre o servidor remetente e o servidor receptor, no havendo servidores intermedirios no caminho. O SMTP permite o envio de mensagens de texto simples, em ASCII de 7 bits.

5 O protocolo SMTP defi ni-do na RFC 822

36

UNISINOS

MATEUS RAEDER

A transferncia do e-mail realizada em trs fases: handshaking, trans-ferncia das mensagens e encerramento. Estas fases podem ser visualizadas na fi gura 29.

Figura 29: Exemplo de uma interao SMTP

Primeiramente ocorre o cumprimento inicial, onde o servidor conhe-ce o cliente e autentica o destinatrio da mensagem, caso este exista no servi-dor. Logo aps, o cliente avisa que comear a enviar seus dados. O servidor, ento, informa ao cliente que escreva sua mensagem, terminando com um caractere . (ponto) em uma linha separada. com este caractere que o ser-vidor sabe que a mensagem foi completamente redigida. Depois desta fase de transferncia do e-mail, fi nalizada a conexo.

Figura 30: Formato da mensagem (a) e exemplo da mensagem (b)

Dentro da fase de transferncia, existem dados de cabealho que po-dem ser informados na mensagem. A fi gura 30a mostra o formato geral do e-mail. Primeiramente existe o cabealho, no qual so inseridas as informa-es, tais como To:, From: e Subject: (fi gura 30b). No corpo da mensagem, apenas caracteres ASCII, fi nalizando com um caractere . (ponto) em uma nica linha (conforme dito anteriormente).

Porm, estamos acostumados a enviar imagens, vdeos, sons e qual-quer formato multimdia por e-mail, no somente mensagens de texto. Para que isso seja possvel, cabealhos extras so adicionados nas mensagens. So extenses para multimdia (MIME Multimedia Mail Extension, defi nidas nas RFCs 2045 e 2056).

37

UNISINOS

CAMADA DE APLICAO

Figura 31: Mensagem com MIME

Figura 32: Mensagem com MIME e Multipart

Com a utilizao destas extenses, quando se deseja enviar uma ima-gem, por exemplo, a mensagem fi ca conforme mostra a fi gura 31. Podemos, inclusive, enviar mais de um objeto, utilizando o tipo Multipart, ilustrado na fi gura 32.

Entre os tipos possveis, temos Text, Image, Video, Audio e Appli-cation, que so outros dados que necessitam de outra aplicao para serem lidos, como por exemplo, documentos do Microsoft Word.

1.6.2 POP e IMAP

O protocolo SMTP envia mensagens de um servidor de correio para outro. Entretanto, para que o usurio leia as suas mensagens, necessria a utilizao de um protocolo de acesso ao correio. Os protocolos mais conheci-dos para recuperao de mensagens dos servidores de correio so o POP (Post O ce Protocol) e o IMAP (Internet Mail Access Protocol). O POP utiliza a porta 100 e defi nido na RFC 1939, enquanto o IMAP utiliza a porta 143 e defi nido na RFC 1730.

O protocolo POP caracteriza-se por retirar as mensagens do servidor, armazenando-as na mquina que acessou o correio. Possui uma fase de auto-rizao, com comandos para informar nome de usurio e senha. Logo aps, comea a fase de transao, na qual possvel listar as mensagens, recuper-las do servidor, apag-las e terminar a conexo. Estes passos podem ser acom-panhados na fi gura 33.

38

UNISINOS

MATEUS RAEDER

Figura 33: Exemplo de interao do protocolo POP.

Contudo, o protocolo POP no bom para usurios nmades, que acessam seus e-mails de diferentes lugares, pois as mensagens fi caro espa-lhadas em diversas mquinas. O protocolo IMAP surge como uma alternativa para estes usurios. um protocolo de recuperao de e-mails do servidor com mais recursos que o POP. Nele, o usurio pode manter as mensagens no servidor, podendo, inclusive, criar uma hierarquia de pastas e at mesmo recuperar apenas as partes da mensagem multipart que desejar.

1.7 Consideraes nais

Neste captulo apresentamos diversas caractersticas da camada mais prxima dos usurios: a Camada de Aplicao. a camada mais importante da pilha de protocolos, pois no haveria a necessidade de comunicao em rede se no existissem as aplicaes de rede.

Estudamos os principais protocolos, os quais auxiliam nas execues dos principais servios. Com este estudo mais detalhado, percebemos o que antes, talvez, no fosse to claro: o que acontece quando enviamos um e-mail, quando transferimos arquivos para servidores remotos, quando acessamos nossos sites preferidos na Web etc.

Fugindo um pouco da teoria, a prtica da criao de aplicaes de rede tambm foi abordada. Escolhemos a linguagem de programao Java para ilustrar nosso exemplo, mas o mais importante, aqui, o entendimento de como a comunicao via socket realizada.

Quando enviamos dados de um host para o outro, estes dados so en-capsulados em mensagens que permitem o controle da troca de informaes. No prximo captulo, estudaremos a camada abaixo da Camada de Aplica-o, que recebe as informaes que trafegaro na rede e responsabiliza-se por entreg-las ao destino.

Captulo 3

CAMADA DE TRANSPORTE

1. Camada de transporte

Quando o usurio utiliza uma aplicao de rede, dados so transpor-tados de um host para outro. Para que haja esta comunicao, a camada de Transporte responsvel pela transmisso lgica dos dados. A transmisso fsica realizada pela camada de Enlace da pilha de protocolos da Internet. Entretanto, a camada de Transporte parte da hiptese de que o Enlace no capaz de controlar o transporte. Logo, os protocolos de Transporte tratam deste envio de maneira lgica, e no de maneira fsica. A transmisso fsica dos dados no ser foco do nosso estudo.

A camada abaixo do Transporte (a camada de Rede) no faz distino sobre qual aplicao (processo) do usurio deve receber as informaes. Esta camada sabe apenas para qual host a mensagem deve ser endereada. Como os sistemas operacionais executam vrias tarefas ao mesmo tempo (multita-refas), existem vrios aplicativos enviando e recebendo mensagens. Assim, para que um determinado aplicativo converse com outro aplicativo no outro host, os protocolos de Transporte acrescentam o mecanismo de portas. Cada porta significa um local diferente no host, ou seja, cada porta identifica um processo, um aplicativo sendo executado.

Ento, os aplicativos que fazem uso da rede comunicam-se atravs de portas. Isto implica no fato de que o processo transmissor deve conhecer no somente o endereo IP do host com o qual est se comunicando, mas tambm deve conhecer a porta que est sendo utilizada pelo processo na outra mqui-na. Cada porta definida como um nmero inteiro e positivo.

O que acontece pode ser exemplificado com a Figura 34. Nela, perce-bemos que a mensagem que sobe na pilha de protocolos chega at o Transpor-te e, de acordo com a porta informada, esta mensagem entregue a um deter-minado processo. o que chamamos de Multiplexao e Demultiplexao. Multiplexar o fato de o host origem acrescentar informaes na mensagem que identificam corretamente em que porta encontra-se o processo que vai re-ceber a mensagem. Demultiplexar o fato de o host destino direcionar (entre-gar) cada mensagem para o processo adequado, de acordo com a informao de porta que a mensagem carrega.

So dois os tipos de transmisso na camada de Transporte: orientada e no orientada a conexo. Ao utilizar um servio orientado conexo, tem-se a garantia da entrega de todos os dados, sem erros e exatamente na mesma ordem que foram enviados pelo remetente. J quando se utiliza um servio de transporte no orientado a conexo, no h esta garantia.

MATEUS RAEDER 40

UNISINOS

Figura 34: Demultiplexao

Mas por que utilizarmos um servio que no garante a entrega dos dados ao destinatrio? Principalmente por causa da velocidade que este ser-vio oferece. Para garantir a entrega correta dos dados (com controle de erros, fl uxo, congestionamento, sequncia), os protocolos da camada de Transporte precisam acrescentar informaes extras s mensagens (overhead), para terem um maior controle. A partir destas informaes, mensagens so trocadas entre o host origem e o host destino da conexo, para que todos os dados que devem ser entregues cheguem de maneira adequada. Como os protocolos no orientados conexo possuem o mnimo de overhead possvel, o volume de dados enviados pela rede bem menor, aumentando a velocidade do envio.

Nas prximas sees, vamos estudar os dois principais protocolos da camada de Transporte: UDP e TCP.

1.1 UDP

O protocolo UDP (User Datagram Protocol) um protocolo de trans-porte no orientado conexo. Conforme dito anteriormente, este protocolo caracteriza-se por no ser confi vel, no mantendo uma conexo entre o re-metente e o destinatrio. Trata-se de um protocolo que oferece apenas a prin-cipal funo da camada de Transporte: entrega dos dados de um processo do host origem (executando em determinada porta) para outro processo do host destino (tambm rodando em determinada porta). Com isto, o UDP permite a distino entre os vrios processos dos hosts (ou seja, faz multiplexao e demultiplexao).

Se uma aplicao utiliza o protocolo UDP, ela deve estar preparada para eventuais perdas de mensagens, mensagens duplicadas, mensagens com atraso, erros no envio etc., pois nada disso ser tratado pela camada de Trans-porte utilizando UDP.

As mensagens enviadas entre duas aplicaes que utilizam o protoco-lo UDP so os chamados Datagramas. Quando a aplicao da camada de Apli-cao envia uma mensagem pela rede, esta mensagem passa para a camada de Transporte, e o protocolo UDP acrescenta a ela algumas informaes que se encontram no cabealho UDP (fi gura 35).

CAMADA DE TRANSPORTE41

UNISINOS

Figura 35: Cabealho UDP

O datagrama UDP possui duas partes: cabealho e dados. No ca-bealho UDP existem os seguintes campos: porta origem, porta destino, tamanho e checksum.

As portas origem e destino so nmeros de 16 bits utilizados para entregar os datagramas para os respectivos programas, ou seja, multiple-xar e demultiplexar.

O campo tamanho representa o tamanho total do datagrama, o que inclui o cabealho e a rea de dados.

O prximo campo o checksum. uma soma de verifi cao que ser-ve para verifi car se o datagrama est correto. Mas, como dissemos antes, o protocolo UDP no recupera erros, sendo a funo do clculo do check-sum somente verifi car se algum erro ocorreu. Caso algum problema tenha acontecido com a mensagem, o UDP nada faz, simplesmente descarta o datagrama, sem a responsabilidade de avisar ao remetente que sua men-sagem no ser entregue. Entretanto, nem todas as mensagens enviadas atravs do UDP precisam realizar este clculo do checksum. Logo, o check-sum do UDP opcional, e isto indicado com o preenchimento do campo com zeros. Isto , se o remetente preencher todos os bits do checksum com valor 0, indicar para o destinatrio que ele no deve realizar a soma de verifi cao. Esta soma de verifi cao realizada da mesma maneira do que no protocolo TCP, e vamos detalh-la mais abaixo.

Finalmente, a ltima parte do datagrama UDP so os dados. Esta rea possui as informaes do host origem que devem ser entregues ao host destino.

O clculo da soma de verifi cao (checksum) opcional no UDP, mas obrigatrio no TCP (protocolo de Transporte que estudaremos mais adiante). Para calcular o checksum, UDP e TCP utilizam mais informaes do que as que existem em seus cabealhos. criado um pseudocabealho (pseudoheader) para realizar o clculo. O pseudoheader (fi gura 36) criado utilizando informaes da camada abaixo do Transporte (Rede).

Figura 36: Pseudoheader

MATEUS RAEDER 42

UNISINOS

O nico campo do pseudoheader que extrado do cabealho dos pro-tocolos de transporte o tamanho. Os demais campos so: IP origem (que identifi ca o endereo IP do host que est enviou a mensagem), IP destino (que identifi ca o endereo IP do host que deve receber a mensagem), um campo preenchido com zeros, somente para completar o tamanho do pseudoheader e protocolo, que identifi ca qual protocolo sendo utilizado.

O checksum calculado utilizando todos os objetos: o pseudoheader, o cabealho do protocolo e os dados. Entretanto, importante percebermos que o pseudoheader no percorre a rede! Ele criado na origem, o checksum cal-culado e a mensagem enviada sem o pseudoheader. Quando a mensagem che-gar ao destino, este criar um pseudoheader e realizar o clculo do cheksum.

O processo de clculo d-se como segue: o remetente soma todos os valores dos campos, agrupados de 16 em 16 bits (pois o tamanho do checksum). Realiza-se o complemento de 1 no resultado encontrado, ou seja, inverte-se os bits. Este valor colocado no campo checksum do cabealho da mensagem. No destino, o mesmo clculo realizado (tambm com o pseudoheader). Se o resul-tado da soma encontrado no destino for zero, signifi ca que no houve erros na mensagem e ela est intacta. Caso contrrio, algum erro ocorreu e a mensagem ser tratada de acordo com o protocolo que est sendo utilizado (no UDP ser descartada, enquanto no TCP ser tratada, por exemplo).

O protocolo UDP extremamente simples, uma vez que simplesmen-te entrega os dados para o destinatrio, sem nenhum controle de mensagens a serem retransmitidas caso tenham ocorrido erros, sem lidar com a ordem que as mensagens chegam. um protocolo de fcil implementao, utilizado por aplicaes que no necessitam de segurana nos dados enviados.

Aplicaes que frequentemente enviam seus dados atravs do proto-colo UDP so comumente aplicaes de tempo real, como Voz sobre IP (VoIP), aplicaes de videoconferncia, transmisses ao vivo etc. Para estas aplica-es, mais vantajoso perder alguns pedaos mnimos que no afetam drasti-camente o funcionamento da aplicao do que gastar muito tempo corrigindo eventuais erros, o que atrasaria bastante a transmisso.

1.2 TCP

Ao contrrio do UDP, o protocolo TCP (Transmission Control Protocol) orientado a conexo, e implementa as funcionalidades que no so implemen-tadas no UDP. O TCP oferece:

controle errosretransmisso de mensagens erradascontrole de fl uxocontrole de congestionamentosequenciamento das mensagens

Para isto, diversas informaes devem ser introduzidas nas mensa-gens, acarretando um maior volume de dados trafegando na rede (pois h muito overhead) e tornando o protocolo TCP mais complexo do que o protocolo UDP. As mensagens enviadas utilizando TCP so chamadas de pacotes.

O TCP possui quatro caractersticas que se destacam:Orientao de streams: os dados enviados so um fl uxo de bits, e o destinatrio recebe este fl uxo exatamente na mesma ordem que fo-ram enviados;Circuito virtual : para que a comunicao acontea, ela deve ser previa-mente autorizada por ambos os hosts. Quando uma conexo est aberta, ento, os protocolos os hosts distintos continuam se comunicando para controlar e corrigir erros;

CAMADA DE TRANSPORTE43

UNISINOS

Transmisso bu erizada : os processos no host origem de uma men-sagem podem enviar a quantidade de dados que desejarem, repassando estes dados para o protocolo. O protocolo, ento, pode dividir o fl uxo de dados em quantas partes desejar para realizar a transmisso;Conexo full-duplex: quando uma conexo aberta entre dois hosts A e B (previamente autorizada por ambos) a transmisso de dados pode ocorrer tanto de A para B quanto de B para A.

Neste protocolo, existe a garantia de que os fl uxos enviados chegaro sem perdas, sem erros e sem duplicao ao seu destino. Para isto, o TCP utiliza uma tcnica chamada Positive Acknowledgement with Retransmission (Confi r-mao Positiva com Retransmisso). Esta tcnica determina que um destina-trio envie uma mensagem de confi rmao para informar ao remetente que a mensagem chegou corretamente ao seu destino. Esta mensagem de confi rma-o ser chamada de ACK.

A cada envio de uma mensagem, o host remetente armazena um re-gistro, que serve para aguardar a confi rmao de cada pacote enviado. A Fi-gura 37 apresenta um envio de dois pacotes com o protocolo TCP.

Figura 37: Exemplo de um envio utilizando TCP

O remetente envia o pacote 1, que chega ao destino. Quando o destino recebe o pacote, ou seja, o pacote no se perdeu, ele verifi ca se h erros (check-sum) e, caso o pacote esteja intacto, ele envia uma mensagem de reconhecimen-to positivo para a origem (ACK). Quando esta mensagem chega, a origem sabe que o pacote anterior chegou sem problemas de transmisso, e pode enviar o prximo pacote. A transmisso dos pacotes continua do mesmo modo.

Entretanto, alguns pacotes podem se perder pela rede e nunca che-garem ao destino. Os pacotes podem, tambm, sofrer alguma inverso de bits (por eventuais problemas eltricos, por exemplo), que ocasionam um erro na mensagem enviada (neste ltimo caso, o checksum acusar o erro). Qualquer que seja o problema ocorrido com o pacote enviado, a mensagem ACK no ser enviada pelo destino, pois o pacote no chegou corretamente.

Para sanar este problema, o remetente, ao enviar cada pacote, dispara um timer (um controlador de tempo). Este timer signifi ca que, se uma confi r-mao no chegar at que o timer expire, o pacote no chegou como deveria ao destino. Assim, quando ocorre um timeout, ou seja, acaba o tempo do timer o pacote correspondente retransmitido. A fi gura 38 apresenta uma situao na qual o pacote 1 no chegou ao destino corretamente e a origem o retransmite ao trmino do timer.

MATEUS RAEDER 44

UNISINOS

Figura 38: Exemplo de uma falha de envio utilizando TCP

Isto garante que as mensagens chegaro corretamente ao destino, pois toda vez que qualquer erro ocorre, o host origem no envia o ACK, e o pacote retransmitido aps o trmino do timer.

O pacote que contm o ACK enviado pelo destino tambm pode se perder pela rede. O que acontece quando o ACK se perde? A fi gura 39 ilustra o envio de um ACK que se perdeu antes de chegar ao host origem.

Figura 39: Exemplo de um envio com perda da mensagem ACK

Cada pacote identifi cado com um nmero de sequncia nico, para garantir a entrega em ordem dos pacotes para a aplicao e evitar duplicatas. Assim, o destinatrio sabe exatamente qual ser o prximo pacote. Logo, se o ACK no chegar ao host origem, este no saber que o pacote chegou correta-mente e o timer expirar, acarretando em uma retransmisso do pacote. Quan-do o pacote chega duplicado no destino, ele descartado, pois j havia sido recebido anteriormente, e um ACK para aquele pacote retransmitido, pois o destino sabe que a origem est aguardando pelo recebimento deste ACK para continuar os envios. Quando o ACK fi nalmente chega ao host origem, a trans-misso dos demais pacotes pode continuar normalmente.

Assim, com o mecanismo de confi rmao positiva das mensagens corretas, duplicatas, mensagens erradas e a ordem das mensagens so verifi -cadas e tratadas. Entretanto, para garantir esta confi abilidade, o host origem deve aguardar o ACK de cada um dos pacotes enviados e, s ento, pode enviar o prximo pacote. Esta maneira de transmisso no muito efi ciente.

CAMADA DE TRANSPORTE45

UNISINOS

Imagine a transmisso de milhares de pacotes pela rede. Se cada pacote deve aguardar o ACK anterior para ser enviado, um grande atraso na entrega ocor-rer e a rede permanecer ociosa por muito tempo.

1.2.1 Go-Back-N

Para tentar amenizar o processo de espera pelo ACK anterior, o pro-tocolo TCP utiliza o mecanismo conhecido como Go-Back-N. Este mecanismo permite que mais de um pacote seja enviado sem que os ACKs anteriores te-nham sido recebidos. Com isto, uma implementao mais complexa que o mecanismo simples de confi rmao positiva visto anteriormente, porm, mais efi ciente.

Entretanto, fundamental que a entrega seja ordenada, logo, os ACKs dos pacotes anteriores so de extrema importncia. O Go-Back-N trabalha com a tcnica de janelas deslizantes. O protocolo cria uma janela de determinado tamanho e todos os pacotes dentro dela podem ser transmitidos antes de re-ceberem confi rmao dos demais. A fi gura 40 ilustra o envio de 9 pacotes com uma janela de tamanho 3.

Conforme supracitado, todos os pacotes dentro da janela podem ser enviados antes da confi rmao dos demais. No exemplo da fi gura 40, os pa-cotes 1, 2 e 3 so enviados sem aguardar ACKs anteriores. O Go-Back-N utiliza ACKs cumulativos para confi rmar o recebimento. Isto signifi ca que o recebi-mento do ACK do pacote 3 informa ao remetente que at o 3 (e ele inclusive), todos os pacotes foram recebidos corretamente.

Figura 40: Exemplo de envio com Go-Back-N e janela de tamanho 3

Perceba no exemplo que o host destino envia ACK 3, confi rmando o recebimento cumulativo de todos os pacotes anteriores. No momento do r