Redes de Computadores UNISINOS

REDES DE COMPUTADORES
UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS
Reitor
Pe. Marcelo Fernandes de Aquino, SJ
Vice-reitor
Pe. Jos Ivo Follmann, SJ
Editora Unisinos
Diretor
Pe. Pedro Gilberto Gomes, SJ
Editora da Universidade do Vale do Rio dos Sinos

Editora Unisinos
Av. Unisinos, 950
93022-000 So Leopoldo RS Brasil
Telef.: 51.35908239
Fax: 51.35908238
editora@unisinos.br
REDES DE COMPUTADORES
[Conceitos, aplicaes e tipos de transporte]
Mateus Raeder
Editora Unisinos
2010
do autor, 2010
2010 Direitos de publicao e comercializao da

Editora da Universidade do Vale do Rio dos Sinos
Editora Unisinos
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.6
CDU 004.7
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.
Editor
Carlos Alberto Gianotti
Acompanhamento editorial
Mateus Colombo Mendes
Reviso
Caroline Ferreira Soares
Editorao
Pubblicato
Capa
Isabel 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.
Sobre o autor
Mateus 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.
APRESENTAO
Este livro Redes de Computadores: conceitos, aplicaes e tipos de
transporte objetiva introduzir o estudo s redes de computadores e sua essncia. 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 apresentado 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 complementar, procurando sempre intercalar um assunto no outro. Comea com um
estudo sobre aplicaes e seus principais protocolos, passando pelo entendimento 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 conjunto com a sequncia do contedo abordado, possa auxiliar o leitor no entendimento da mensagem passada.
SUMRIO
Capitulo 1: Introduo s Redes de Computadores........................ 9
1 Introduo s redes de computadores........................................................... 9

1.1 Elementos principais e classificao.................................................... 10
1.2 Internet e servios................................................................................... 13
1.3 Meios de transmisso............................................................................. 15
1.3.1 Meios de transmisso guiados..................................................... 15
1.3.2 Meios de transmisso no-guiados............................................. 16
1.4 Protocolos................................................................................................ 17
1.4.1 Protocolos hierrquicos................................................................ 18
1.4.2 Modelo de referncia OSI............................................................. 19
1.4.3 Modelo Internet............................................................................. 20
1.5 Atrasos..................................................................................................... 22
1.6 Consideraes finais............................................................................... 23
CAPTULO 2: Camada de Aplicao...................................................................25
1 Camada de Aplicao..................................................................................... 25
1.1 Funes da Camada de Aplicao....................................................... 25
1.2 Programao em sockets com Java........................................................ 26
1.3 HTTP........................................................................................................ 28
1.3.1 Mensagens HTTP........................................................................... 30
1.3.2 Cookies.............................................................................................. 31
1.3.3 GET condicional............................................................................. 32
1.4 FTP............................................................................................................ 32
1.5 DNS.......................................................................................................... 33
1.6 Protocolos de e-mail................................................................................ 35
1.6.1 SMTP............................................................................................... 35
1.6.2 POP e IMAP.................................................................................... 37
CAPTULO 3: Camada de transporte..............................................................39
1 Camada de transporte.................................................................................... 39
1.1 UDP.......................................................................................................... 40
1.2 TCP........................................................................................................... 42
1.2.1 Go-Back-N........................................................................................ 45
1.2.2 Pacote TCP...................................................................................... 47
1.2.3 Abertura de conexo..................................................................... 50

1.2.4 Encerramento da conexo............................................................ 51
1.2.5 Sndrome da Janela Boba.............................................................. 52
1.2.6 Controle de congestionamento.................................................... 52
1.2.7 Gerenciamento de Timers.............................................................. 53
1.2.8 Mquina de estados TCP.............................................................. 53
CAPTULO 4: P2P.............................................................................................................55
1 P2P..................................................................................................................... 55
1.1 Elementos fundamentais................................................................. 56
1.2 Arquiteturas....................................................................................... 56
1.3 Pesquisa e acesso............................................................................... 57
1.4 Consideraes finais......................................................................... 58
CAPTULO 5: Multimdia..........................................................................................59
1 Multimida....................................................................................................... 59
1.1 RTSP......................................................................................................... 62
1.2 RTP........................................................................................................... 63
1.3 RTCP......................................................................................................... 64
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 distintos. O que conhecemos como a Internet de hoje foi criado a partir da chamada 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 telefnicas 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, entretanto, o intuito da interligao de computadores foi evoluindo, chegando
Internet que conhecemos nos dias de hoje.
Uma rede de computadores um conjunto de dispositivos interconectados 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 exemplos no param por a, pois, atualmente, a comunicao em rede o corao
de diversas ideias, tais como transaes bancrias, marketing, comrcio eletrnico, educao a distncia e instituies que disponibilizam informaes
para seus afiliados em sistemas pela Internet. Um bom exemplo de compartilhamento 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 disco 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 utilizao do termo redes de computadores bem empregada? Esta pergunta
10
MATEUS RAEDER
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
infinidade 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 diversas finalidades (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, monitorando, 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, classificaes mais utilizadas, meios de
transmisso entre os computadores, protocolos de rede e atrasos.
1.1 Elementos principais e classicao
Em toda rede existem algumas entidades que realizam papis fundamentais 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.
UNISINOS
11
INTRODUO
REDES
DE
COMPUTADORES
O primeiro deles trata-se do Transmissor, tambm chamado de Origem. Este o componente que deseja enviar alguma informao pela rede.
Esta mensagem contm os Dados que sero enviados para o Receptor, ou destino, 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 geralmente realizam os papis de enviar e receber dados, sendo comumente dinmicos, pois em um momento podem estar tanto enviando quanto recebendo
dados. Cada um deles possui uma identificao nica na rede. similar ao
que acontece com as pessoas: cada uma possui seu prprio CPF e/ou RG, que
a identifica unicamente. No caso das redes de computadores, cada host possui
um endereo IP nico.
As redes so, ento, comumente classificadas de acordo com a distncia entre os hosts. A Tabela 1 apresenta uma possvel classificao das redes de
computadores.
Abrangncia
Localizados no mesmo
10 m
Sala
100 m
Prdio
1 km
Campus
10 km
Cidade
100 km
Estado/Pas
1.000 km
Continente
10.000 km
Planeta
Classicao
Rede Local (LAN)
Rede Metropolitana (MAN)

Rede Geograficamente
Distribuda (WAN)
Tabela 1: Classificao das redes de computadores de acordo com a abrangncia
Os tipos mais importantes de classificao de redes so as LANs,

MANs, WANs e a Internet. A seguir, so comentadas cada uma destas trs,
exemplificando e descrevendo-as de acordo com suas principais caractersticas.
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 algumas caractersticas bem especficas. 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 apresenta uma taxa de erros extremamente baixa quando comparada com outros
tipos de rede. Dentro de uma rede deste tipo no h roteamento das informaes, sendo o envio caracterizado por um broadcast (envio para todos).
Os dispositivos em uma rede de computadores so distribudos e interligados de diferentes maneiras, o que chamamos de topologia. As principais 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 caracteriza-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.
UNISINOS
12
MATEUS RAEDER
Figura 3: Topologia em estrela.
Quando os dispositivos so interligados atravs de uma topologia em

barra, conforme ilustra a figura 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 ocupado 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 (figura 5).
Figura 5: Topologia em anel.
UNISINOS
13
INTRODUO
REDES
DE
COMPUTADORES
Quando uma rede atinge uma distncia maior, classificada como

uma MAN (Metropolitan Area Network). Estas so as Redes Metropolitanas, que
so uma verso ampliada das LANs. As principais caractersticas que a diferem 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 (Distributed 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 extremidades, 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 Geograficamente 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 possua uma alta taxa de erros e uma baixa taxa de transmisso (quando comparadas 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 computadores 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 tecnologia, empresrios podem, por exemplo, criar seus prprios escritrios portteis, com um custo baixssimo de infraestrutura. As redes sem fio possuem
classificaes, da mesma maneira que as redes com fio listadas acima, tambm
chamadas de redes cabeadas, por utilizarem cabos para a comunicao, entretanto, 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.
UNISINOS
14
MATEUS RAEDER
Entre os hosts, existem os canais de comunicao (ou links), que a partir deste momento tambm sero chamados de enlace. Estes enlaces podem
ser cabos de fibra tica, cabos coaxiais e outros meios, que tambm sero estudados 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 Internet 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 externas. So extremamente utilizadas por corporaes, rgos governamentais e
instituies de todos os setores. A Intranet utiliza as mesmas tecnologias (roteadores, hosts, padres, protocolos) que a Internet.
Para as aplicaes de rede (aplicaes distribudas), existem dois tipos 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 conexo. 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 comuns, 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 visualizado na figura 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 fisicamente distantes um do outro, separados por uma ou vrias redes (figura
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.
UNISINOS
15
INTRODUO
REDES
DE
COMPUTADORES
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 percorrero da origem at o destino. onde ocorre efetivamente a comunicao 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 transmisso mais adequado.
Os meios de transmisso podem ser classificados como guiados e
no-guiados. Os meios de transmisso guiados utilizam meios fsicos (cabos) 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 largura 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 fibra tica.
Cabos coaxiais (figura 9) so formados por um fio de cobre envolvido por um material isolante (dieltrico, no conduz corrente eltrica).
Por fora deste isolante ainda existem duas camadas protetoras: a mais interna 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 fibra tica.
Figura 9: Cabo coaxial
UNISINOS
16
MATEUS RAEDER
Os cabos de par tranado so divididos em dois tipos: sem blindagem (UTP - Unshielded Twisted Pair) e com blindagem (STP - Shielded Twisted
Pair), sendo os sem blindagem os mais utilizados. So formados por dois
fios de cobre encapados e enrolados de forma helicoidal (figura 10). So enrolados desta maneira como uma forma de diminuir a interferncia eltrica
entre os fios.
Figura 10: Cabo de par tranado
O meio de transmisso guiado que vem sendo muito utilizado o

cabo de fibra tica. Trata-se de uma fibra de vidro extremamente fina, iluminada por pulsos alternados de luz. A presena de luz no vidro significa
um bit em 1, enquanto a ausncia de luz indica um bit em 0. As operaes so realizadas em alta velocidade, principalmente ponto a ponto (at
10Gbps). Os cabos de fibra 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 (figura 11).
Figura 11: Cabo de fibra 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 transmisso 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 transUNISINOS
17
INTRODUO
REDES
DE
COMPUTADORES
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 exemplo, os controles de televiso que fazem uso de infravermelho. Quando
voc deseja alternar o canal da televiso, ou aumentar (ou diminuir) o volume, e algum se posiciona entre o controle e o aparelho, difcil acionar
a funo desejada devido dificuldade 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 definida e esclarecida: 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 definem padres e estruturas de comunicao, nas
quais mensagens especficas so enviadas e, de acordo com estas mensagens, determinadas aes so tomadas.
A associao mais comum que podemos realizar uma analogia
com os seres humanos. Analise a figura 12. Duas pessoas bem educadas e
que no se conhecem (Alan e Joana), antes de qualquer coisa trocam cumprimentos, e depois comeam uma conversa. Ao final desta conversa, as pessoas 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 mquinas ao invs de pessoas (figura 13). Toda a comunicao presente na Internet
comandada por protocolos que definem o formato das mensagens, a ordem
que elas devem chegar ao destino, o que deve ser feito em cada situao, alm
de outros controles.
UNISINOS
18
MATEUS RAEDER
Figura 13: Comunicao entre computadores
Na comunicao entre hosts, para que as mensagens cheguem ao destino, informaes de controle so adicionadas a cada mensagem enviada. Assim, 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 definir:

o tipo das mensagens trocadas entre as mquinas

a sintaxe das mensagens (definindo o formato de cada um dos campos)

a semntica dos campos (o que cada campo significa)

as regras de quando e como as mensagens so enviadas
1.4.1 Protocolos hierrquicos
As redes de computadores tm evoludo constantemente. Um dos aspectos importantes que surgiu juntamente com esta evoluo a organizao
dos protocolos de uma maneira estruturada, separando os componentes (protocolos) em camadas.
Mas qual o benefcio de uma estrutura de protocolos organizada em
camadas? O principal objetivo desta modularizao isolar as camadas superiores dos detalhes de implementao das camadas inferiores, possibilitando,
assim, que funcionalidades de uma camada sejam substitudas e alteradas
sem que isso influencie 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 implementam os mesmos protocolos, as camadas de mesmo nvel n em uma mquina
trocam informaes entre si de acordo com um determinado protocolo. Entretanto, 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 imediatamente inferior. As entidades n utilizam servios do nvel n-1 (providos 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 chegando ao destino, a partir do qual realiza o caminho inverso.
UNISINOS
19
INTRODUO
REDES
DE
COMPUTADORES
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 Abertos). Este modelo trouxe um conjunto de diretrizes que objetivavam permitir
a interconexo de redes heterogneas. Para alcanar os principais aspectos
necessrios para a comunicao eficiente de uma rede de computadores, o
modelo OSI define sete camadas, cada uma com suas funes especficas.
A figura 15 apresenta as 7 camadas definidas no modelo OSI: aplicao, apresentao, sesso, transporte, rede, enlace e fsica.
Figura 15: Modelo de referncia OSI
UNISINOS
20
MATEUS RAEDER
A primeira camada (ou primeiro nvel) a camada Fsica. Neste

nvel esto os equipamentos fsicos, como os cabos e demais meios de comunicao. 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 camada 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 fluxo, 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 ocorra na rede durante determinada comunicao, os hosts possam continuar
suas transmisses de onde haviam parado ou, no mnimo, da ltima marcao realizada.
A penltima camada a de Apresentao, na qual os dados podem
ser criptografados na origem e decodificados 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 distintos. 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 comercial. Isto se deve a alguns fatores, sendo o principal deles a complexidade 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
Alguns autores agrupam

as duas ltimas camadas,
classificando o modelo com
apenas 4 camadas
Diferentemente do modelo OSI, a pilha de protocolos da Internet,

chamada Modelo Internet ou ainda Modelo TCP/IP apresentou-se mais eficiente e mais prtica do que as complexas camadas do modelo OSI. Este
novo modelo formado por 5 camadas1, que agrupam as funes do modelo OSI em uma estrutura mais simples e com um desempenho melhor.
A figura 16 ilustra as camadas da pilha de protocolos da Internet, mostrando onde so situadas as funcionalidades previstas no Modelo de Referncia OSI.
UNISINOS
21
INTRODUO
REDES
DE
COMPUTADORES
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 figura 16, as camadas de
Sesso e Apresentao foram retiradas deste modelo, mas suas funcionalidades 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 nvel 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 comunicao dita comunicao horizonta, e exemplificada na figura 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 figura 14.
UNISINOS
22
MATEUS RAEDER
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 Transporte, 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 mensagem, na forma de cabealhos (Figura 19). Ou seja, cada camada adiciona
mensagem o seu cabealho especfico. A mensagem percorre a rede com todas
estas informaes adicionais encapsuladas at encontrar seu destino. No destino, 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 chegam 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 figura 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 importantes): atraso de processamento nodal, atraso de enfileiramento, atraso de
transmisso e atraso de propagao. A figura 20 ilustra onde ocorre cada um
destes tipos de atraso.
Figura 20: Atrasos e seus locais de ocorrncia
UNISINOS
23
INTRODUO
REDES
DE
COMPUTADORES
Quando um pacote chega a um n, ele examinado para determinar para onde deve ser encaminhado. O tempo necessrio para fazer esta
verificao o atraso de processamento (Dproc). Alm disso, parte do
atraso de processamento o tempo gasto para verificar a ocorrncia de erros
nos bits do pacote. Logo aps estes processos, o pacote enviado para uma
fila de sada, na qual encontram-se todos os pacotes que esto prontos para
serem enviados ao enlace. O tempo que o pacote espera na fila para ser
enviado para a rede o atraso de enfileiramento (Dqueue). Este atraso depende, obviamente, da quantidade de pacotes que j se encontram na fila
aguardando o momento da transmisso. Quanto mais trfego, maior ser
o atraso Dqueue. Se no houver pacotes na fila, o atraso de enfileiramento
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 fila 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 fila. 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 fica
esperando os demais, e comea a ser imediatamente propagado para o prximo 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 (fibra tica, fio 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 propagar 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 fim a fim (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 classificao, meios
de transmisso mais utilizados e algumas caractersticas de cada um deles. Ainda neste captulo, falamos sobre protocolos, definindo 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 sofrido 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 superiores 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.
UNISINOS
Captulo 2
Camada de Aplicao
abemos 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 protocolos 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 aplicao fosse utiliz-la. Estas aplicaes, que so distribudas em diversos hosts, comunicam-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 Aplicao no so a aplicao, mas sim uma parte fundamental delas, definindo as
mensagens que sero enviadas e cada ao que deve ser tomada em determinadas 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 Usurio (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
MATEUS RAEDER

cliente: que solicita um determinado servio (por exemplo, leitores de
correio eletrnico)

servidor: que recebe um determinado pedido, executa este pedido e responde (por exemplo, servidores de correio eletrnico)
Existe uma interface de programao de aplicaes (Application Program Interface - API), que define 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 mensagem e outro host receba. Mais especificamente, um host grava informaes em um
socket, e outro retira estas informaes do socket. Para isto, devemos definir 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 mensagem 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 resposta, tambm atravs do socket. O cliente l a mensagem de resposta do servidor 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();
BueredReader entrada = new BueredReader(new
InputStreamReader(meuSocket.getInputStream()));
DataOutputStream saida = new
DataOutputStream(meuSocket.getOutputStream());
}
}
mensagemRecebida = entrada.readLine();
System.out.println(Cliente enviou: + mensagemRecebida);
saida.writeBytes(mendagemEnviada);
}
UNISINOS
27
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 definida pelo usurio. A definio 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
definida. Esta linha bloqueante, e o servidor s seguir sua execuo quando algum cliente solicitar a conexo. Quando isto ocorre, o servidor cria um
fluxo de entrada ligado ao socket (linha 14), e cria um fluxo 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 visualizar 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;
BueredReader digitado =
new BueredReader(new InputStreamReader(System.in));
Socket meuSocket = new Socket(IP_Servidor, 6789);
DataOutputStream saida =
new DataOutputStream(meuSocket.getOutputStream());
BueredReader entrada =
new
BueredReader(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 ficar bloqueado, aguardando uma resposta do servidor (linha 23). Quando a resposta finalmente 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 implementar.
UNISINOS
28
MATEUS RAEDER
2.3 HTTP
O primeiro protocolo da camada de Aplicao que vamos abordar trata-se do protocolo HTTP (HyperText Transfer Protocol), que define as
regras de comunicao na World Wide Web (WWW ou simplesmente Web).
Antes de falarmos especificamente 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). Tratase de uma linguagem simples para hipertexto, que comeou como uma verso 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 exemplos de tags HTML so:
<b> texto </b>: formata o texto em negrito
<i> texto </i>: formata o texto em itlico
<h1 align=center> texto </h1>: centraliza o texto
<img src=caminho do arquivo>: insere uma imagem (mais especificamente o arquivo referenciado no caminho indicado)
A verso 1.0 do HTTP definida na RFC 1945, e a verso 1.1 na RFC 2068
O protocolo TCP ser estudado no Captulo 3. No momento, basta sabermos que

um servio da camada de
Transporte que garante a
entrega correta dos dados
RTT (Round Trip Time)

o tempo que um pacote leva
para ser enviado e retornar
ao remetente
Alm destas, existem diversas outras tags que formatam textos e inserem 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 figura 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 servidor, por sua vez, recebe os pedidos dos clientes e envia os objetos referenciados 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 fluxo 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 80

o servidor aceita a conexo TCP solicitada

cliente 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 referenciadas. A figura 21 ilustra o fluxo 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 servidor 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 transmisso, conforme ilustra a figura 22.
UNISINOS
29
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 pedido, na mesma conexo. Assim, ocorre uma diminuio no nmero de RTTs.
Suponha o mesmo caso anterior, uma HTML com quatro objetos referenciados. 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 significa que o servidor no tem
a capacidade de manter histricos e informaes sobre os pedidos que foram
UNISINOS
30
MATEUS RAEDER
realizados anteriormente pelo cliente. Tal fato acrescentaria certa complexidade ao protocolo, uma vez que os estados guardados pelo cliente e pelo servidor 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 figura 23 mostra 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 final de cada
linha, existe um <CR><LF> (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 resposta
POST: envia dados que devem ser processados
PUT: envia arquivos no corpo da mensagem
DElETE: apaga o arquivo especificado
Os mtodos TRACE, CONNECT e OPTIONS tambm podem ser utilizados. Em seguida, existe a rea de cabealhos, onde zero ou mais cabealhos
podem ser adicionados. Primeiramente, deve-se colocar o nome do cabealho, seguido por : (dois pontos). Logo aps, o valor do campo informado, e para indicar o trmino de uma linha acrescenta-se <CR><LF>. Quando houver algum objeto para ser enviado, ele vem no corpo da mensagem.
A figura 24 apresenta um exemplo real de uma mensagem HTTP de requisio. No caso ilustrado, utiliza-se o mtodo GET.
Figura 24: Exemplo de mensagem de requisio (utilizando GET)
UNISINOS
31
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 figura 25.
Figura 25: Formato geral de uma mensagem HTTP de resposta
Na primeira linha, verificamos 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 encontra 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 figura 26 ilustra
uma mensagem de resposta HTTP representando que o objeto solicitado foi
encontrado no servidor. Esta resposta referente requisio realizada na
figura 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 definidos 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
UNISINOS
32
MATEUS RAEDER
linha Set-cookie: id, onde id a identificao 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 usurio 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 preferncias 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 servidor 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-modified-since:<data> (onde
data indica a data em que o objeto foi armazenado na cache do cliente).
Caso o objeto no servidor no tenha sido modificado desde data, responder com uma mensagem sem o objeto includo e com a linha de status 304
Not Modified.
1.4 FTP
Transferir arquivos uma das tarefas mais realizadas na Web. Quando 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 definido 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 significa que uma
conexo TCP criada para cada arquivo transferido, enquanto o controle permanece sempre com a mesma conexo.
Os comandos tpicos do protocolo so enviados em modo texto ASCII
pelo canal de controle. Os mais tpicos so:
UNISINOS
33
CAMADA
DE
APLICAO

USER nome: informa o nome de usurio para autenticao

PASS senha: informa a senha do usurio para autenticao

lIST: lista os arquivos que se encontram no diretrio corrente

RETR arquivo: recupera o arquivo remoto

STOR 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 dados j podem comear a ser transferidos, pois a conexo de dados j foi
estabelecida

425 cant open data connection: ocorreu um erro na abertura da conexo
de dados.
Diferentemente do HTTP, o servidor FTP consegue armazenar informaes de estado, como por exemplo, o diretrio em que o usurio encontrase e a autenticao previamente realizada por ele.
1.5 DNS
Cada dispositivo conectado Internet possui um identificador nico, chamado endereo IP (Internet Protocol). Este identificador utilizado para
enderear as mensagens enviadas, e so compostos por nmeros. Por exemplo, 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.br

para que a mensagem de requisio HTTP chegue ao seu destino,
necessrio a obteno do endereo IP de www.unisinos.br

o 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 hierrquica 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
UNISINOS
O protocolo UDP ser estudado no Captulo 3. No momento, basta sabermos que

um servio da camada de
Transporte que no garante
a entrega correta dos dados
34
MATEUS RAEDER
est necessariamente registrado em um servidor de nomes com autoridade,

garantindo que o mapeamento ser corretamente realizado. Quando o hostname 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 (figura 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 pergunte 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 encontrada (figura 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 sero 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 ocasio, 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.
UNISINOS
35
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 mensagem 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 basicamente sobre trs grandes entidades (figura 28): Agente de Usurio (Mail
User Agent MUA), Agente de Transporte (Mail Transport Agent) e os Protocolos de Correio.
Figura 28: Componentes do e-mail.
Os agentes de usurio so os conhecidos leitores de e-mail. So as aplicaes sobre as quais o usurio interage, compondo, editando, lendo mensagens de correio. Como exemplos, podemos citar o Outlook Express, Evolution, 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 ficam armazenadas nos agentes de transporte, que so os servidores de correio.
1.6.1 SMTP
Servidores de correio armazenam as mensagens recebidas em uma
fila 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 fila de sada. Neste contexto, quando um servidor de correio deseja enviar uma mensagem para
outro servidor de correio, utilizado o protocolo SMTP (Simple Mail Transfer 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.
UNISINOS
5
O protocolo SMTP definido na RFC 822
36
MATEUS RAEDER
A transferncia do e-mail realizada em trs fases: handshaking, transferncia das mensagens e encerramento. Estas fases podem ser visualizadas
na figura 29.
Figura 29: Exemplo de uma interao SMTP
Primeiramente ocorre o cumprimento inicial, onde o servidor conhece o cliente e autentica o destinatrio da mensagem, caso este exista no servidor. 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 servidor sabe que a mensagem foi completamente redigida. Depois desta fase de
transferncia do e-mail, finalizada a conexo.
Figura 30: Formato da mensagem (a) e exemplo da mensagem (b)
Dentro da fase de transferncia, existem dados de cabealho que podem ser informados na mensagem. A figura 30a mostra o formato geral do
e-mail. Primeiramente existe o cabealho, no qual so inseridas as informaes, tais como To:, From: e Subject: (figura 30b). No corpo da mensagem,
apenas caracteres ASCII, finalizando com um caractere . (ponto) em uma
nica linha (conforme dito anteriormente).
Porm, estamos acostumados a enviar imagens, vdeos, sons e qualquer 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, definidas nas
RFCs 2045 e 2056).
UNISINOS
37
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 imagem, por exemplo, a mensagem fica conforme mostra a figura 31. Podemos,
inclusive, enviar mais de um objeto, utilizando o tipo Multipart, ilustrado na
figura 32.
Entre os tipos possveis, temos Text, Image, Video, Audio e Application, 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 conhecidos para recuperao de mensagens dos servidores de correio so o POP (Post
Oce Protocol) e o IMAP (Internet Mail Access Protocol). O POP utiliza a porta
100 e definido na RFC 1939, enquanto o IMAP utiliza a porta 143 e definido
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 autorizao, com comandos para informar nome de usurio e senha. Logo aps,
comea a fase de transao, na qual possvel listar as mensagens, recuperlas do servidor, apag-las e terminar a conexo. Estes passos podem ser acompanhados na figura 33.
UNISINOS
38
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 ficaro espalhadas 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.

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 encapsulados em mensagens que permitem o controle da troca de informaes.
No prximo captulo, estudaremos a camada abaixo da Camada de Aplicao, que recebe as informaes que trafegaro na rede e responsabiliza-se por
entreg-las ao destino.
UNISINOS
Captulo 3
Camada de transporte
1. Camada de transporte
Quando o usurio utiliza uma aplicao de rede, dados so transportados 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 (multitarefas), 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 mquina. Cada porta definida como um nmero inteiro e positivo.
O que acontece pode ser exemplificado com a Figura 34. Nela, percebemos que a mensagem que sobe na pilha de protocolos chega at o Transporte e, de acordo com a porta informada, esta mensagem entregue a um determinado 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 receber a mensagem. Demultiplexar o fato de o host destino direcionar (entregar) 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.
40
MATEUS RAEDER
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 servio oferece. Para garantir a entrega correta dos dados (com controle de erros,
fluxo, 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 transporte no orientado conexo. Conforme dito anteriormente, este protocolo
caracteriza-se por no ser confivel, no mantendo uma conexo entre o remetente e o destinatrio. Trata-se de um protocolo que oferece apenas a principal 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 Transporte utilizando UDP.
As mensagens enviadas entre duas aplicaes que utilizam o protocolo UDP so os chamados Datagramas. Quando a aplicao da camada de Aplicao 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 (figura 35).
UNISINOS
41
CAMADA
DE TRANSPORTE
Figura 35: Cabealho UDP
O datagrama UDP possui duas partes: cabealho e dados. No cabealho 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, multiplexar 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 verificao que serve para verificar se o datagrama est correto. Mas, como dissemos antes,
o protocolo UDP no recupera erros, sendo a funo do clculo do checksum somente verificar 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 mensagem no ser entregue. Entretanto, nem todas as mensagens enviadas
atravs do UDP precisam realizar este clculo do checksum. Logo, o checksum 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
verificao. Esta soma de verificao 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 verificao (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 (figura 36) criado
utilizando informaes da camada abaixo do Transporte (Rede).
Figura 36: Pseudoheader
UNISINOS
42
MATEUS RAEDER
O nico campo do pseudoheader que extrado do cabealho dos protocolos de transporte o tamanho. Os demais campos so: IP origem (que
identifica o endereo IP do host que est enviou a mensagem), IP destino (que
identifica 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 identifica 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 calculado e a mensagem enviada sem o pseudoheader. Quando a mensagem chegar 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 resultado da soma encontrado no destino for zero, significa 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 simplesmente 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 protocolo UDP so comumente aplicaes de tempo real, como Voz sobre IP (VoIP),
aplicaes de videoconferncia, transmisses ao vivo etc. Para estas aplicaes, mais vantajoso perder alguns pedaos mnimos que no afetam drasticamente 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 implementadas no UDP. O TCP oferece:

controle erros

retransmisso de mensagens erradas

controle de fluxo

controle de congestionamento

sequenciamento das mensagens
Para isto, diversas informaes devem ser introduzidas nas mensagens, 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 fluxo de bits, e o
destinatrio recebe este fluxo exatamente na mesma ordem que foram enviados;

Circuito virtual: para que a comunicao acontea, ela deve ser previamente autorizada por ambos os hosts. Quando uma conexo est aberta,
ento, os protocolos os hosts distintos continuam se comunicando para
controlar e corrigir erros;
UNISINOS
43
CAMADA
DE TRANSPORTE

Transmisso buerizada: os processos no host origem de uma mensagem podem enviar a quantidade de dados que desejarem, repassando
estes dados para o protocolo. O protocolo, ento, pode dividir o fluxo 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 fluxos enviados chegaro
sem perdas, sem erros e sem duplicao ao seu destino. Para isto, o TCP utiliza
uma tcnica chamada Positive Acknowledgement with Retransmission (Confirmao Positiva com Retransmisso). Esta tcnica determina que um destinatrio envie uma mensagem de confirmao para informar ao remetente que a
mensagem chegou corretamente ao seu destino. Esta mensagem de confirmao ser chamada de ACK.
A cada envio de uma mensagem, o host remetente armazena um registro, que serve para aguardar a confirmao de cada pacote enviado. A Figura 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 verifica se h erros (checksum) e, caso o pacote esteja intacto, ele envia uma mensagem de reconhecimento 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 chegarem 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 significa que, se uma confirmao 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 figura 38 apresenta uma situao na
qual o pacote 1 no chegou ao destino corretamente e a origem o retransmite
ao trmino do timer.
UNISINOS
44
MATEUS RAEDER
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 figura 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 identificado 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 corretamente e o timer expirar, acarretando em uma retransmisso do pacote. Quando 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 finalmente chega ao host origem, a transmisso dos demais pacotes pode continuar normalmente.
Assim, com o mecanismo de confirmao positiva das mensagens
corretas, duplicatas, mensagens erradas e a ordem das mensagens so verificadas e tratadas. Entretanto, para garantir esta confiabilidade, 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 eficiente.
UNISINOS
45
CAMADA
DE TRANSPORTE
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 ocorrer 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 protocolo TCP utiliza o mecanismo conhecido como Go-Back-N. Este mecanismo
permite que mais de um pacote seja enviado sem que os ACKs anteriores tenham sido recebidos. Com isto, uma implementao mais complexa que o
mecanismo simples de confirmao positiva visto anteriormente, porm, mais
eficiente.
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 receberem confirmao dos demais. A figura 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 confirmao dos demais. No exemplo da figura 40, os pacotes 1, 2 e 3 so enviados sem aguardar ACKs anteriores. O Go-Back-N utiliza
ACKs cumulativos para confirmar o recebimento. Isto significa que o recebimento 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, confirmando o

recebimento cumulativo de todos os pacotes anteriores. No momento do receUNISINOS
46
MATEUS RAEDER
bimento do ACK 3, o host origem sabe que o pacote 1, o pacote 2 e o pacote 3

foram enviados corretamente, e sua janela desliza at o primeiro pacote que
no foi confirmado (no caso, o pacote 4 que no foi enviado ainda). Agora,
os pacotes 4, 5 e 6 esto na janela de envio, e podem ser enviados. Todos so
enviados, e o destino confirma o recebimento com ACK 6, fazendo com que
a janela no host origem deslize at o pacote 7. Os pacotes na janela (7, 8 e 9)
so enviados e o recebimento confirmado com o ACK 9.
Quando um pacote no chega corretamente ao destino, ele no
confirmado. O Go-Back-N trata isso da mesma maneira, no enviando o ACK
para aquele pacote. A figura 41 mostra o envio de 10 pacotes, utilizando uma
janela de tamanho 4, com um erro de transmisso.
Figura 41: Exemplo de uma falha no envio com Go-Back-N e janela de tamanho 4
Os quatro primeiros pacotes dentro da janela so enviados. Entretanto, o pacote 3 no chega ao destino, e este host enviar um ACK 2
confirmando apenas o recebimento dos pacotes 1 e 2. Perceba que o pacote 4 chega corretamente ao destino, mas descartado, pois o pacote que
deveria chegar era o pacote 3, para garantir a ordem de entrega. Quando
o ACK 2 chega ao host origem, a janela desliza at o primeiro pacote no
confirmado (no caso, o pacote 3). A janela, neste caso, desliza em duas
posies, travando no pacote 3, para aguardar a confirmao. Agora, os
pacotes 5 e 6 esto dentro da janela e podem ser enviados. Porm, quando
chegam ao destino, estes dois pacotes sero descartados pelo mesmo motivo que o pacote 4 foi descartado anteriormente. No host origem, o timer
do pacote 3 expira, indicando que este pacote deve ser reenviado. Assim, o
host origem reenvia todos os pacotes da janela, pois sabe que estes pacotes
no foram entregues ao destino. Os pacotes, finalmente, chegam ao host
destino, que envia um ACK 6, fazendo com que a janela deslize e permita o
UNISINOS
47
CAMADA
DE TRANSPORTE
envio dos pacotes 7, 8, 9 e 10. O host destino envia o ACK 10, confirmando
o recebimento de todos os pacotes.
Com um mecanismo de janela ajustado de maneira adequada, a rede
no fica to ociosa, possuindo mais pacotes trafegando entre os hosts. Este
mecanismo continua garantindo a transferncia confivel dos dados, com
uma eficincia maior do que a simples confirmao positiva. O mecanismo
Go-Back-N padro do protocolo TCP.
Conforme o tempo passa, mudanas ocorrem na rede e na capacidade
de recebimento do destino. O TCP permite que o tamanho da janela de envio
seja alterado com o passar do tempo. A cada ACK recebido, o host destino
envia junto a informao de quantos pacotes o receptor est apto a receber.
Desta maneira, o remetente atualiza a sua janela de acordo com a capacidade
informada pelo receptor.
Esta possibilidade de janelas variveis melhora o controle de fluxo
para a comunicao. Controle este essencial para hosts com capacidades e
velocidades de processamento diferentes, utilizando a rede de maneira mais
adequada.
1.2.2 Pacote TCP
A unidade de transferncia entre dois hosts que utilizam o protocolo
TCP um pacote (ou segmento). As informaes (dados) que vm da camada
de Aplicao so encapsuladas em um pacote, que acrescenta diversas informaes de controle para a confiabilidade do TCP. O pacote TCP pode ser visualizado na Figura 42, e composto de duas partes: cabealho e dados.
Alguns campos representam as mesmas informaes presentes do
cabealho UDP: as portas origem e destino e o checksum. Cabe lembrar que
o clculo do checksum obrigatrio no TCP, para garantir que as informaes
que chegam so as mesmas que foram enviadas. Os demais campos do cabealho so explicados a seguir.
O nmero de sequncia representa a identificao da ordem do pacote em relao aos demais, garantindo que os pacotes sero entregues para o
processo no host destino ordenadamente.
O nmero ACK indica qual pacote est sendo confirmado. Por exemplo, quando o destino confirma o recebimento do pacote 7, o valor deste campo ser o nmero de sequncia do pacote 7.
Figura 42: Pacote TCP
O prximo campo o tamanho do cabealho, que especifica qual

o tamanho da parte do pacote referente ao cabealho. Este tamanho no mUNISINOS
48
MATEUS RAEDER
nimo 5 palavras de 32 bits, pois as opes podem no ser utilizadas, mas o

restante do cabealho sempre estar preenchido.
O campo tamanho do cabealho seguido por um campo no utilizado, que so bits reservados para uso futuro.
Em seguida, aparecem seis bits de controle, que iro identificar a finalidade daquele segmento. So eles:

URG: indica que o campo Ponteiro Urgente vlido e deve ser lido;

ACK: indica que o campo Nmero ACK vlido e deve ser lido, ou
seja, uma mensagem de confirmao;

PSH: indica que o receptor no deve armazenar a mensagem recebida e deve entregar a mensagem foradamente, sem armazen-la;

RST: indica que ocorreu um problema e a conexo entre os dois
hosts deve ser reiniciada;

SYN: indica a solicitao de conexo;

FIN: indica que o remetente no tem mais dados a serem enviados e
deseja finalizar seu lado da conexo.
Com a utilizao destes bits de controle, uma tcnica de piggybacking
(carona) muito utilizada: informaes de controle podem ser enviadas juntamente com dados. Por exemplo, um pacote que est enviando dados pode
enviar junto (de carona) o ACK de recebimento do pacote anterior, amenizando o overhead e a troca de informaes pela rede, pois seria necessrio o envio
de dois pacotes, um para os dados e um para o ACK.
O campo tamanho da janela guarda a informao do tamanho da
janela que ser usado naquela conexo. com este campo que os hosts indicam o tamanho varivel da janela de transmisso estudado anteriormente.
Por exemplo, quando um host no deseja, ou no pode, receber mais mensagens, pois est cheio, envia uma janela de tamanho 0. Isso ir interromper a
transmisso por determinado tempo. Quando desejar receber novamente, o
destinatrio envia um pacote com o valor do campo tamanho da janela diferente de 0.
O campo ponteiro urgente informa ao receptor que o processo receptor deve receber os dados o mais rapidamente possvel, sem buerizar antes de entreg-los para a aplicao. Com este ponteiro, no importa a posio
da mensagem no fluxo de dados. Por exemplo, informar que a conexo deve
ser abortada imediatamente. Este campo vlido quando o bit URG setado.
Finalmente, existe o campo de opes, que no obrigatoriamente
usado. Existem diversas opes que podem ser utilizadas pelo protocolo TCP.
Algumas delas so: Maximum Segment Size (MSS), Escala de Janela, Estampa
de Tempo e Retransmisso Seletiva. As opes de Maximum Segment Size e
Retransmisso Seletiva sero detalhadas a seguir.
Maximum Segment Size
Esta opo permite que a comunicao entre redes e hosts heterogneos
seja mais eficiente. Com a utilizao desta opo, os hosts combinam entre si o
tamanho mximo do pacote a ser transferido na rede.
Como a comunicao ocorre (geralmente) entre hosts que no se encontram na mesma rede fsica, a capacidade de cada parte da rede (entre o
roteador e outro) pode ser muito diferente. Assim, um pacote que pode ser
enviado tranquilamente em uma rede com uma determinada capacidade no
necessariamente pode ser enviado pela prxima parte da rede, que pode possuir uma capacidade muito menor.
A escolha deste tamanho no trivial, pois se o tamanho escolhido for
demasiadamente pequeno, haver muito overhead e uma sobrecarga grande
na rede, pois vrios pacotes pequenos estaro trafegando. Quando se escolhe
um tamanho muito grande para o MSS, as partes do caminho que possuem
UNISINOS
49
CAMADA
DE TRANSPORTE
uma capacidade menor sero obrigadas a fragmentar o pacote em vrios, o

que causa uma diminuio considervel no desempenho da rede.
Retransmisso Seletiva
A opo Retransmisso Seletiva uma tcnica para substituir o mecanismo Go-Back-N visto anteriormente.
O Go-Back-N utiliza uma janela de transmisso que permite o envio de
mais de um pacote de cada vez antes do recebimento dos ACKs anteriores, objetivando utilizar a rede mais eficientemente. Quando um pacote perdido ou
chega ao destino com algum defeito, este pacote descartado. Entretanto, os
demais pacotes da janela que foram enviados depois deste pacote e foram recebidos corretamente tambm so descartados, unicamente porque o destino estava aguardando o pacote perdido. Quando o pacote com erro retransmitido,
todos os pacotes que chegaram corretamente tambm so retransmitidos.
Retransmisso Seletiva tambm utiliza janelas deslizantes, porm,
os pacotes que chegaram corretamente no so descartados, mas sim armazenados. Se o pacote est na sua ordem de entrega correta, este pacote est
pronto para ser entregue para a aplicao. Caso o pacote recebido no seja o
esperado, porm chegou corretamente ao destino, este pacote buerizado
at que o pacote esperado chegue. Entretanto, estes pacotes buerizados
no esto prontos para serem entregues para a aplicao, pois falta algum
pacote que deveria ter chegado antes. Quando este pacote chegar, os pacotes
buerizados podem ser entregues para a aplicao, mas no precisam ser
retransmitidos, como ocorreria no Go-Back-N, pois chegaram corretamente ao
destino. A figura 43 apresenta um exemplo do envio de 10 pacotes com a utilizao da opo Retransmisso Seletiva, com uma janela de tamanho 4 e um
erro de transmisso.
Figura 43: Falha de envio com Retransmisso Seletiva e janela de tamanho 4
UNISINOS
50
MATEUS RAEDER
O remetente envia os quatro pacotes dentro da janela. Diferentemente

do mecanismo Go-Back-N, os pacotes no so reconhecidos com ACKs cumulativos, mas sim individualmente. Logo, a cada pacote recebido, um ACK enviado ao host origem. Conforme os ACKs vo chegando ao host origem, a janela
desliza, travando no primeiro pacote no confirmado (no caso, o 3). Perceba
que o pacote 4, 5 e 6 so enviados e chegam corretamente ao destino, mas o pacote 3 no chegou ainda. O Go-Back-N descartaria estes pacotes, o que no ocorre aqui. Os pacotes 4, 5 e 6 so buerizados e confirmados com ACKs. A janela
do remetente no desliza, pois o pacote 3 ainda no foi confirmado. Quando o
timer do pacote 3 expirar, este (e somente este) pacote retransmitido. Chegando ao host destino corretamente, os pacotes que j haviam chegado agora esto
prontos para serem entregues para a aplicao, pois a ordem de recebimento
foi mantida. Um ACK enviado para o pacote 3, o que faz com que a janela do
remetente deslize at o pacote 7, pois os pacotes 4, 5 e 6 j haviam sido previamente reconhecidos. A transmisso continua da mesma forma.
1.2.3 Abertura de conexo
Como o protocolo TCP orientado conexo, uma conexo entre os
dois hosts deve ser criada. Antes de comear toda a comunicao e transmisso de pacotes entre eles, os dois lados precisam necessariamente aceitar esta
conexo.
Quando um host deseja abrir uma conexo com outro, d incio ao
chamado handshaking (cumprimento) de trs vias. O host que envia a primeira mensagem desejando estabelecer uma conexo realiza uma abertura ativa,
enquanto o host que recebe e aceita a conexo realiza uma abertura passiva. As
trs vias do handshaking podem ser vistas na figura 44, e so:

Primeira via: um host que deseja estabelecer uma conexo envia um
pacote com o bit de controle SYN setado;

Segunda via: o host que recebe o pedido de conexo concorda em
estabelecer a conexo, e envia um pacote com os bits SYN e ACK
setados;

Terceira via: o host que iniciou o pedido de conexo envia uma confirmao final.
Figura 44: Handshaking inicial para abertura da conexo
A partir de ento, a conexo est estabelecida, e os dois hosts podem

transmitir mensagens entre si.
UNISINOS
51
CAMADA
DE TRANSPORTE
O handshaking tem duas funes principais na conexo TCP. Primeiramente, garante que os dois lados esto prontos para receber e enviar mensagens. Tambm permite que um host conhea o nmero de sequncia inicial
do outro. Este ltimo aspecto muito importante, pois quando a mquina
A envia uma mensagem para a mquina B, fundamental que a mquina B
saiba qual o nmero de sequncia desta mensagem, para garantir a ordenao e controlar eventuais erros e duplicaes de mensagens, assim como as
retransmisses necessrias.
O primeiro host envia seu nmero de sequncia na primeira via do
handshaking, juntamente com o bit SYN. O outro host, ao receber este pacote,
guarda o nmero de sequncia do fluxo que vem daquele host e responde com
o seu nmero de sequncia juntamente com os bits SYN e ACK setados. O host
que realizou a abertura ativa, ento, guarda o nmero de sequncia do fluxo
vindo do outro host e confirma o recebimento.
Outra informao importante trocada na abertura da conexo o tamanho da janela. Da mesma forma que os nmeros de sequncia iniciais, o
tamanho da janela informado no handshaking inicial.
1.2.4 Encerramento da conexo
As conexes no TCP so full-duplex. Desta maneira, cada host deve encerrar o seu lado da conexo, no sendo necessrio o encerramento dos dois
lados simultaneamente (figura 45).
Quando a aplicao que utiliza o protocolo TCP no possui mais nenhum dado para enviar para a aplicao do outro host, ela inicia o processo
de encerramento do seu lado da conexo. Analise a figura 45. Para que o host
A finalize seu lado da conexo, ele envia um pacote com o bit FIN setado. O
host B recebe este pacote e confirma o recebimento com um ACK. Entretanto,
isto significa que o host A no deseja mais enviar dados para o host B, mas o
contrrio no verdade. O host B, ento, pode continuar enviando dados para
o host A, que somente envia pacotes de confirmao. Quando o host B deseja
finalizar o seu lado da conexo, ele envia uma mensagem de finalizao (com
o bit FIN setado) e o host A confirma com o ACK final. Neste momento, a conexo est completamente encerrada.
Figura 45: Encerramento da conexo
UNISINOS
52
MATEUS RAEDER
1.2.5 Sndrome da Janela Boba

A sndrome da janela boba um problema que surge quando o host
origem envia muitos dados para o host destino, mas a aplicao que deve consumir estes dados consome poucos dados por vez.
O que acontece neste caso que o buer do lado receptor enche, e envia um pacote com tamanho de janela 0 (indicando que no pode mais receber
pacotes por algum tempo). A transmisso pelo outro host , ento, interrompida. A aplicao destino consome apenas uma pequena parte do fluxo de
dados enviados (1 byte, por exemplo). Neste momento, o receptor envia uma
mensagem para o remetente com o tamanho da janela igual a 1. A transmisso continua com o envio de apenas 1 byte pela rede, o que causa um overhead
muito grande, diminuindo muito o desempenho do TCP.
Para que este problema no ocorra, o TCP deve evitar que o receptor
possa enviar uma atualizao de janela muito pequena. Assim, o host receptor forado a esperar que sua janela tenha um tamanho considervel para
anunciar o novo tamanho. Uma nova janela s pode ser informada quando o
receptor possa receber ou o tamanho mximo de segmento (MSS) ou a metade da capacidade do seu buer, o que for menor.
1.2.6 Controle de congestionamento
Existem dois tipos de congestionamento: um que ocorre devido
capacidade do receptor e um que ocorre devido capacidade da rede. Para
evitar congestionamentos, o TCP escolhe um tamanho de janela adequado,
e o remetente envia pacotes dentro da janela do receptor. Isto faz com que o
receptor no fique sobrecarregado e no fique congestionado, o que ocasionaria descarte de pacotes. Contudo, a rede ainda pode ficar congestionada.
O host remetente, ento, possui duas janelas: uma do receptor e uma
de congestionamento. Ambas indicam a quantidade de bytes que pode ser
enviada pelo remetente. A quantidade de bytes que o remetente poder enviar o mnimo entre as duas janelas.
Por exemplo: se o receptor informa que pode receber 10Kb, e o remetente sabe que com mais de 6Kb a rede fica congestionada, ele enviar
somente 6Kb para no sobrecarregar a rede. Caso o receptor informe que
pode receber os 10Kb mas o remetente sabe que a rede suporta at 32Kb
sem congestion-la, ele enviar somente os 10Kb que no sobrecarregam o
receptor.
A janela de congestionamento ajustada no comeo da conexo com
o valor do tamanho mximo de segmento (MSS). Isso feito da seguinte
maneira: um pacote (de tamanho MSS) enviado. Caso este pacote seja confirmado antes do timer expirar, significa que a rede suporta este tamanho.
O remetente, ento, acrescenta o dobro do tamanho do MSS janela de congestionamento e envia dois pacotes. Se todos os pacotes forem confirmados antes do timeout, duplica-se o tamanho da janela de congestionamento
e um pacote de tamanho dobrado enviado. A cada pacote recebido antes
do timeout, o tamanho da janela dobrado e uma nova tentativa de envio
realizada, com pacotes duas vezes maiores.
O crescimento da janela de congestionamento continua exponencial
at que ocorra um timeout. Quando isso ocorre, a ltima janela (antes do
timeout) a que permanece. Comea, ento, um processo conhecido como
inicializao lenta: um processo similar ao anterior executado, entretanto, aumentando o tamanho do pacote em apenas 1 MSS, no duplicando o
tamanho. Assim, o crescimento da janela a partir deste ponto no mais
exponencial como antes, mas sim linear, incrementando o tamanho da janela
em um MSS a cada envio confirmado.
UNISINOS
53
CAMADA
DE TRANSPORTE
1.2.7 Gerenciamento de Timers

Alguns timers so utilizados no TCP. Dentre eles, o mais importante o timer de retransmisso, aquele disparado no envio de cada pacote.
Entretanto, qual o intervalo ideal para este timer?
Se um timer muito grande for escolhido, pacotes que se perdem
demoram muito para serem descobertos, o que acarreta em um retardo
desnecessrio na retransmisso. Com o contrrio, se o timer for um tempo
muito pequeno, podem ocorrer inmeras retransmisses desnecessrias,
pois as confirmaes podem demorar mais para chegar do que o tempo
definido para o timer.
Alguns algoritmos so definidos para ajustar o timeout. Um deles
descrito por Jacobson(1988), que utiliza um clculo sobre o RTT (tempo de
ida e volta de um pacote) para estimar o novo timeout dinamicamente.
Outro timer utilizado de persistncia. Quando o receptor envia
uma janela de tamanho 0, o remetente vai interromper a transmisso. Neste momento, o remetente dispara o timer de persistncia. O receptor envia a mensagem que atualiza o novo tamanho da janela, para continuar
a transmisso. Entretanto, esta mensagem que informa o novo tamanho
da janela pode se perder no caminho, e as duas extremidades da conexo
permanecem ociosas aguardando alguma ao. Em algum momento, o timer de persistncia expira, e o remetente envia uma mensagem de teste ao
receptor, para saber se houve um erro ou se a janela continua com tamanho
0. A resposta do receptor vai informar o tamanho da janela, seja ela maior
ou igual a 0.
1.2.8 Mquina de estados TCP
Diferentemente do UDP, o protocolo TCP possui uma mquina de estados (figura 46). Nela, todos os estados e possveis aes que podem ocorrer
podem ser vistas, assim como as transies e os novos estados que so atingveis de acordo com o estado atual.
Figura 46: Mquina de estados do TCP
UNISINOS
54
MATEUS RAEDER

Neste captulo estudamos a camada de Transporte da pilha de protocolos Internet. Os principais protocolos desta camada so o UDP e o TCP, que
utilizam servio no orientado e orientado conexo, respectivamente.
O protocolo UDP no confivel na entrega dos dados, sem uma garantia de ordem e sem controle algum sobre os dados que so enviados. J o
protocolo TCP, por sua vez, garante a entrega correta dos dados, controlando
fluxo, congestionamento, erros, retransmitindo pacotes e entregando-os na
ordem desejada.
No podemos dizer qual protocolo melhor, pois possuem caractersticas e funes diferentes. A utilizao do UDP, por exemplo, elimina vrios
retardos na conexo, com um cabealho muito mais simples, transferindo os
dados da maneira mais rpida possvel. Entretanto, diversas aplicaes no
podem perder dados, como o envio de e-mails e a transferncia de arquivos.
Para estas aplicaes, nas quais a confiabilidade um aspecto fundamental,
necessita-se a utilizao de um protocolo orientado conexo como o caso
do TCP.
UNISINOS
Captulo 4
P2P
1. P2P
Comumente as aplicaes da Web (como correio eletrnico, servidor
de nomes, transferncia de arquivos, dentre outras, utilizam o paradigma
cliente/servidor. Existem servidores centralizados que executam determinados pedidos (servios) dos diversos clientes distribudos. Este paradigma traz
a ideia de que a maioria (clientes) usa o que a minoria (servidores) tem.
Entretanto, o constante crescimento do nmero de usurios que fazem o papel de cliente causa uma elevada utilizao dos servidores, que necessitam cada vez mais de poder de processamento e largura de banda para
executarem suas funes de maneira eficiente.
Diferentemente desta arquitetura, surge a arquitetura P2P (Peer-ToPeer). Nestas aplicaes, todos os usurios (hosts que participam da rede) realizam tanto a funo de cliente quanto a funo de servidor, ou seja, mquinas
que solicitam e fornecem servios umas s outras. Este tipo de arquitetura
caracteriza-se por no haver um servidor centralizado, eliminando problemas
causados pelas falhas de servidores. No possuem uma organizao hierrquica, e um usurio pode participar da rede desde que fornea acesso aos
recursos que ele possui.
Assim sendo, sistemas P2P no possuem uma coordenao centralizada, tendo todos os recursos acessveis por qualquer componente da rede.
O principal objetivo deste tipo de arquitetura claramente visvel: compartilhamento de recursos (informaes, processamento, arquivos etc.).
Existem quatro tipos principais de aplicaes P2P, classificadas em:

Mensagem instantnea: permite aos usurios o envio de mensagens em tempo real para os demais participantes. Exemplos deste
tipo de aplicao so o MSN e o ICQ;

Compartilhamento de arquivos: permite aos usurios a transferncia de arquivos de uma mquina para a outra diretamente. Exemplos deste tipo de aplicao so o Emule e o LimeWire;

Computao distribuda: permite aos usurios utilizarem recursos computacionais ociosos. Exemplos deste tipo de aplicao so
SETI@Home e DNS;

Trabalhos colaborativos: permite aos usurios melhorar a produtividade de grupos que compartilham dos mesmos interesses, suportando alguns aspectos como: calendrio, espao de trabalho, listas
de discusso, gerncia de documentos, videoconferncia etc. Exemplos deste tipo de aplicao so LotusNotes e Groove.
56
MATEUS RAEDER
A popularidade dos sistemas P2P cresceu rapidamente, principalmente a partir do ano 2000, chegando a ultrapassar os servios de e-mail e FTP,
igualando-se muito a utilizao da prpria Web. Alguns pontos ilustram o
porqu deste crescimento, tais como o custo de compartilhamento minimizado, maior autonomia e colaborao entre os hosts participantes. Alm disso,
elimina o ponto nico de falha presente em arquiteturas cliente/servidor.
1.1 Elementos fundamentais
Os sistemas P2P possuem os chamados peers. Cada peer o nodo, um
host no sistema P2P. Cada peer possui uma identificao nica, e pode pertencer a um ou mais grupos, chamados PeerGroups. Estes peers podem se comunicar tanto com peers do seu grupo quanto com peers de outros grupos
diferentes. Os peers podem ser classificados como:

Peer simples: um nodo comum, que fornece e solicita recursos
para a rede;

Peer Rendezvous: um peer que auxilia na localizao dos peers e
dos recursos disponveis na rede;

Peer Router: um peer que auxilia os peers a comunicarem-se atravs
de um rewall, por exemplo.
Os PeerGroups agrupam peers que possuem os mesmos interesses, podendo fornecer determinados servios somente aos seus integrantes, no possibilitando acesso direto a peers que no participam do grupo.
Os servios oferecidos pelos peers so basicamente quaisquer servios
que eles possam realizar, como transferncia de arquivos, execuo de algoritmos etc.
1.2 Arquiteturas
Com a evoluo dos sistemas P2P, alguns diferentes tipos de arquitetura foram sendo criados, com o objetivo de aumentar a confiabilidade e facilitar
a descoberta de recursos, uma vez que o nmero de usurios cresceu muito, o
que passou a dificultar alguns aspectos da comunicao direta entre os hosts.
Duas principais arquiteturas so vistas em sistemas P2P: descentralizada e semicentralizada (ou parcialmente centralizada). Na arquitetura descentralizada no existe a figura de um n central, sendo todos os ns da rede
do mesmo nvel. a arquitetura bsica de sistemas P2P, na qual os ns compartilham seus recursos, e eles mesmos gerenciam os recursos e o trfego da
rede (figura 47).
Figura 47: P2P descentralizado
UNISINOS
57
P2P
Os peers so autnomos e conseguem se conectar e se comunicar entre

si. Enquanto clientes, os peers enviam pedidos para os outros peers da rede, e
recebem as respostas a estes pedidos. Enquanto servidores, os peers recebem
pedidos dos demais peers, executam os servios solicitados e respondem estes
pedidos de acordo com o que podem realizar.
J a arquitetura semicentralizada inclui ns centrais para controle, geralmente controle de trfego. Geralmente, existe um conjunto dos chamados
SuperPeers para realizar as funes de controle, para que a queda de um deles
no afete o sistema P2P inteiro, afetando apenas os ns inferiores diretamente
ligados a ele. Os demais ns da rede so peers simples (figura 48).
Figura 48: P2P semicentralizado
Assim, as funes dos peers simples (inferiores) so as mesmas da arquitetura descentralizada, diferenciando apenas no fato de que os servios
so geralmente feitos para os SuperPeers, ou seja, os peers inferiores enviam
os pedidos aos SuperPeers, que, por sua vez, recebem estes pedidos e encaminham-nos para os peers inferiores que possuem os recursos. Os SuperPeers,
ento, mantm um controle dos peers e dos recursos presentes na rede.
1.3 Pesquisa e acesso
Os sistemas P2P permitem que os peers busquem por recursos e/ou
servios compartilhados, assim como a maneira de acess-los. Podemos
classificar os sistemas P2P quanto ao tipo de busca que realiza. Os principais so: centralizada, inundao (ooding) e hash distribuda.
Nos sistemas que utilizam busca centralizada, existe a presena
de um ponto central de buscas. Quando um n entra nesta rede, ele deve
conectar-se ao centralizador e inform-lo dos recursos disponveis. Os ns,
ento, pesquisam no centralizador em qual(ais) peer(s) a informao desejada
pode ser encontrada. O centralizador ir informar o peer que possui determinado recurso, e a comunicao entre eles ocorre diretamente (figura 49).
Como qualquer sistema centralizado, este tipo de busca passvel de falhas
e possui um desempenho baixo, pois diversas consultas sero realizadas ao
mesmo servidor, que se torna um gargalo no sistema como um todo. Apesar
disto, trata-se de um sistema de busca de fcil implementao.
UNISINOS
58
MATEUS RAEDER
Figura 49: Busca P2P centralizada.
Na busca por inundao (ou ooding), por sua vez, no h a figura

do centralizador. Cada peer independente, e pesquisa somente nos ns vizinhos. Esta busca tem este nome porque cada n pesquisa nos seus vizinhos,
e assim sucessivamente, temos a ideia de uma inundao de pesquisas pelos
peers da rede. A informao encontrada retorna pelo mesmo caminho pelo
qual a busca foi realizada. Para que a pesquisa no vague indefinidamente
pelos peers da rede sem um fim, existe um TTL (Time To Live) da busca, que
geralmente a quantidade mxima de peers que ela pode passar. Neste tipo de
busca no necessrio que os peers publiquem os recursos que possuem em
lugar algum, uma vez que os vizinhos fazem as pesquisas diretamente.
Existe ainda a pesquisa conhecida como DHT (Distributed Hash Table),
ou tabela hash distribuda. Esta busca utiliza a ideia de funes hash para identificar os recursos e os ns da rede. Este hash , ento, distribudo entre os peers.
A ideia da tabela de separar espaos de busca, pois quando uma consulta
realizada, ela diretamente repassada para o n que sabe o caminho da informao. Nesta busca, os peers conhecem alguns dos peers que existem na rede.
Cada recurso, ento, associado a um idenficador, que ser calculado atravs
de uma funo hash. O peer ir, ento, pegar o resultado obtido na funo hash
e pesquisar pelo recurso no peer com identificao mais prxima.
Alguns problemas no foram resolvidos quanto utilizao de P2P.
Alguns destes problemas so comuns no dia-a-dia, como propriedade intelectual e segurana.
Com esta liberdade que existe entre os hosts para se comunicarem e
trocarem informaes diretamente, os usurios podem facilmente distribuir
materiais com direitos autorais de maneira inadequada, rapidamente e em
grande escala. No a toa que os sistemas P2P ganharam uma grande fama
de colaborar muito com a pirataria.
Entretanto, com uma utilizao apropriada e respeitando algumas
questes de propriedade intelectual, os sistemas P2P so extremamente teis,
justamente por diminuir o gargalo includo pelos sistemas centralizados, que
apresentam um nico ponto de falhas.
UNISINOS
Captulo 5
Multimdia
1. Multimdia
Aplicaes que so capazes de transmitir contedos multimdia so
cada vez mais utilizadas na Internet. Estas aplicaes executam em um determinado host e transferem udio e vdeo, e s tornaram-se possveis por causa
do crescimento da utilizao das redes de computadores.
Alguns exemplos destas aplicaes so: teleconferncias, sites de transmisso de vdeos (como o YouTube, por exemplo), rdios e televiso online,
aprendizado a distncia, telefonia IP etc. Este tipo de aplicao sensvel ao
atraso, mas pode tolerar algumas perdas sem que estas afetem a execuo
como um todo. As aplicaes multimdia so comumente dividas em trs
grandes grupos principais: fluxo contnuo armazenado, fluxo contnuo ao
vivo e tempo real.
Na primeira classe de aplicaes fluxo contnuo armazenado , a
mdia j se encontra previamente armazenada em um servidor. A qualquer
momento, um cliente solicita os arquivos multimdia (udio e vdeo) que deseja receber.
Neste caso, a mdia j foi pr-gravada e est armazenada no servidor.
Isso permite que o usurio possa pausar, voltar e avanar a mdia no momento que bem entender. Outro ponto importante o fluxo contnuo, no qual o
cliente pode comear a reproduzir a mdia antes mesmo que ela chegue por
completo. O cliente j comea a reproduzir o vdeo enviado antes mesmo que
ele tenha sido completamente transmitido.
A reproduo nestes casos deve ser contnua, ou seja, quando a reproduo comea, esta deve prosseguir normalmente sem qualquer interrupo.
Isto , todos os dados devem ser recebidos em um tempo adequado para que
possam ser reproduzidos corretamente pelo cliente.
As aplicaes de fluxo contnuo ao vivo assemelham-se s transmisses de televiso e rdio. Neste tipo de aplicao, no existe uma mdia previamente gravada (como ocorre na outra classe vista anteriormente). Uma vez
que no h fluxo armazenado, no possvel adiantar a reproduo para uma
parte mais a frente da mdia. Contudo, este tipo de mdia armazenado localmente, e algumas aplicaes podem prover recursos para pausar e retroceder
a reproduo. Os atrasos nesta classe de aplicaes causam mais problemas
para os usurios do que em aplicaes de mdia armazenada.
A ltima classe trata-se das aplicaes de udio e vdeos interativos
de tempo real. Nesta classe, a comunicao entre os usurios realizada em
tempo real, como uma conversa atravs de telefonia pela Internet ou uma
60
MATEUS RAEDER
videoconferncia. Os usurios podem se movimentar e falar a qualquer instante, o que faz com que os atrasos neste tipo de aplicao devam ser muito
pequenos, pois acarretam em dificuldades na comunicao.
As aplicaes multimdia so tolerantes a falhas, mas so extremamente sensveis ao atraso em alguns casos. Dentre os principais tipos de atraso, esto o Jitter e o Skew.
O primeiro deles (jitter) a variao do atraso dos pacotes que esto
no mesmo fluxo. Os pacotes no levam o mesmo tempo para serem transmitidos pela rede, principalmente por ocasionais congestionamentos ou at
mesmo pulsos eletromagnticos que possam causar algum dano aos pacotes,
gerando perda. O jitter , ento, o desvio padro do tempo de envio de dois
pacotes, a variao do atraso. Por exemplo, 5 pacotes consecutivos so enviados do host origem com 5 milissegundos de diferena. No receptor, entretanto, a diferena de chegada entre um pacote e outro pode ser maior ou menor
do que este valor.
Para amenizar este atraso, as aplicaes retardam a reproduo das
pores de mdia. Desta maneira, uma parte da mdia armazenada no cliente, compensando a variao do atraso (jitter) que a rede provoca.
Outro atraso refere-se ao atraso em mdias que envolvem udio e vdeo que devem ser sincronizados, chamado de skew. Ningum gostaria de ver
um vdeo de um jogo de futebol, por exemplo, e ouvir o som 5 ou 6 segundos
aps a imagem ter passado. Deve-se determinar qual o atraso aceitvel para a
chegada de cada um dos pacotes de vdeo e de udio.
Na Internet atual, no h uma distino entre pacotes contendo udio
e vdeo em tempo real. Os pacotes que contm este tipo de mdia so tratados
exatamente como os demais. Alguns esforos vm sendo realizados para que
possam ser providos servios diferenciados que garantam a qualidade de servio (QoS) para este tipo de dado.
Por enquanto, a implementao de um buer do lado do cliente (para
armazenar parte dos dados e retardar a reproduo), a utilizao do protocolo
de transporte UDP e o envio de informaes redundantes so alguns exemplos
do que pode ser feito para minimizar os efeitos de erros e atrasos, melhorando
o servio para esta classe de aplicaes.
A popularidade das aplicaes de udio e vdeo de fluxo contnuo na
Internet aumentou consideravelmente. Dois aspectos que esto amplamente relacionados com este crescimento so o custo de armazenamento minimizado,
pois h muito mais multimdia armazenada na Internet, e a melhoria na prpria Internet (as velocidades de acesso residencial, por exemplo, tornaram-se
cada vez maiores).
Geralmente, a multimdia solicitada atravs de um cliente Web (browser). A reproduo, no entanto, no est integrada com os browsers, e necessria
uma aplicao auxiliar que ir reproduzir a mdia no cliente. Estas aplicaes
so chamadas de transdutores, sendo alguns dos mais comuns o Real Player e o
Windows Media Player. Estes aplicativos realizam funes alm de reproduzir,
tais como descomprimir o contedo, remover o jitter e oferecer uma interface
grfica para que o usurio possa acessar as opes de controle sobre a mdia.
Dentro da janela do browser, a interface do transdutor pode ser inserida com a
utilizao de certos programas especiais, chamados de plug-ins.
Quando um cliente solicita os arquivos de udio e vdeo, estes arquivos
podem ser acessados atravs de servidores Web tradicionais ou servidores especiais para fluxo contnuo.
Quando uma mdia est armazenada em um servidor Web tradicional,
trata-se de um objeto comum, assim como um JPEG. Suponhamos que o cliente
solicite um arquivo de vdeo. Uma conexo TCP criada entre o cliente e o
servidor, e uma requisio HTTP realizada para aquele objeto. No cabealho
do arquivo (enviado pelo servidor como resposta), existe a informao de como
UNISINOS
61
MULTIMDIA
o arquivo foi codificado. O browser, ento, analisa o tipo do arquivo e aciona o

transdutor correspondente que pode reproduzir a mdia (figura 50).
Figura 50: Mdia em servidor Web tradicional
O servidor pode, ainda, informar um metarquivo, que contm as informaes sobre o arquivo a ser entregue (figura 51). O usurio, ao clicar no
link correspondente ao arquivo, recebe o metarquivo, que repassado para
o transdutor correspondente (de acordo com o tipo de mdia). O transdutor,
ento, vai estabelecer uma conexo TCP com o servidor Web requisitando o
arquivo desejado. O arquivo, ento, enviado dentro de uma resposta HTTP.
Figura 51: Mdia em servidor Web com metarquivo
Quando h um servidor de fluxo contnuo (no um servidor Web), outros protocolos que no TCP podem ser utilizados entre o servidor e o reprodutor. O cliente requisita o arquivo de descrio atravs do browser (utilizando
HTTP) para um servidor Web. Este arquivo repassado para o transdutor correspondente, que se comunica diretamente com o servidor de fluxo contnuo
(figura 52).
UNISINOS
62
MATEUS RAEDER
Figura 52: Mdia em servidor de uxo contnuo
Nas prximas sees, vamos estudar alguns protocolos importantes para o controle da mdia a ser enviada e reproduzida. So eles: RTSP,
RTP e RTCP.
1.1 RTSP
O protocolo RTSP (Real Time Streaming Protocol) data de 1996, e
trata-se de uma especificao do IETF (Internet Engineering Task Force) para
o controle de transmisso de multimdia na Internet. um protocolo da
camada de Aplicao que funciona fora de banda (assim como o FTP): as
mensagens do protocolo so enviadas em uma banda e a mdia em si
enviada em outra.
Neste protocolo, o cliente pode controlar a reproduo da mdia
conforme a sua vontade. A transmisso, ento, controlada pelo transdutor.
O RTSP pode rodar tanto sobre o protocolo UDP quanto sobre o protocolo TCP,
na porta 544.
O RTSP funciona da seguinte maneira: o metarquivo enviado para o
cliente Web, que dispara a execuo do transdutor. Este, por sua vez, estabelece uma conexo de controle RTSP e uma conexo de dados com o servidor de
mdia (figura 53).
Acompanhando a figura 53 percebemos que o transdutor envia o
comando RTSP SETUP, e receber como resposta um RTSP SETUP do servidor. Em seguida, um comando RTSP PLAY enviado para o servidor, que
responde com o mesmo comando. O servidor comea a descarregar a mdia, e as operaes continuam sendo trocadas no decorrer da execuo, de
acordo com o que o usurio deseja. A sesso encerrada com a utilizao
da operao TEARDOWN. A tabela 2 apresenta as operaes suportadas pelo
protocolo RTSP.
OPTIONS
SETUP
PLAY
PAUSE
Descreve os tipos de pedidos suportados pelo servidor

Especifica o modo de transporte as informaes de portas
Inicia a execuo do fluxo de mdia
Interrompe a execuo por um tempo
Pode enviar o fluxo de mdia para um servidor
RECORD
de armazenamento
TEARDOWN
Encerra a sesso, liberando os recursos
Tabela 2: Operaes suportadas pelo RTSP
UNISINOS
63
MULTIMDIA
Figura 53: Funcionamento do RTSP
1.2 RTP
O protocolo RTP (Real-time Transport Protocol) utilizado para fluxos
de mdia de aplicaes em tempo real, como Voz sobre IP, por exemplo.
especificado na RFC 1889, e as verses mais recentes so definidas nas RFCs
3550 e RFC 3551. o principal protocolo para o transporte de mdia em tempo
real. Alguns autores dizem que o RTP um protocolo da camada de Aplicao, enquanto outros defendem que um protocolo da camada de Transporte.
Comumente, este protocolo colocado na pilha de protocolos separadamente,
conforme mostra a figura 54.
Figura 54: Localizao do RTP na pilha de protocolos Internet
As principais caractersticas do RTP so: aplicar nmeros de sequncia aos pacotes para reconstituir as informaes enviadas, identificar o tipo da
carga que est sendo enviada e adicionar marcas de tempo.
UNISINOS
64
MATEUS RAEDER
O RTP especifica uma estrutura (cabealho) para os pacotes que transportam udio e vdeo. Os principais campos do cabealho RTP podem ser
visualizados na Figura 55.
Figura 55: Cabealho RTP
O campo tipo de carga til possui 7 bits, e indica a codificao utilizada. atravs deste campo que eventuais mudanas na codificao so
informadas ao receptor. O nmero de sequncia utilizado para detectar
perdas e restaurar a sequncia dos pacotes. Para verificar se o pacote foi
afetado pelo jitter (podendo remov-lo para sincronizar a reproduo), o
instante de tempo do primeiro byte marcado no campo marca de tempo.
A fonte de um fluxo RTP identificada no campo identicador de sincronizao da fonte (SSRC).
Utilizando o protocolo RTP, o remetente envia as pores dos dados de udio com o cabealho RTP acrescentado. Os pacotes RTP so encapsulados em datagramas UDP, e no lado receptor, a aplicao extrai a
poro de udio, utilizando campos do cabealho para decodificar e reproduzir a poro de udio de maneira correta.
Para reduzir os gastos de envio, uma das funes do protocolo
comprimir o cabealho, enfatizando os dados da mensagem. Aplicaes
que exemplificam a utilizao do RTP so: MSN, Skype, videoconferncia e
Windows Media Player.
1.3 RTCP
Em conjunto com o RTP, o protocolo RTCP (Real-time Transport Control Protocol) prov funes de controle e de identificao dos participantes
da comunicao. Esta funo realizada atravs de feedbacks de qualidade
do servio que est sendo prestado, objetivando a transmisso para diversos usurios.
Os participantes de uma sesso RTP enviam, periodicamente, pacotes de controle RTCP para todos os participantes. Estes pacotes contm
relatrios com estatsticas teis para as aplicaes, tais como o nmero de
pacotes enviados, nmero de pacotes perdidos, variao do atraso entre as
chegadas dos pacotes etc. Desta forma, o remetente pode modificar suas
taxas de transmisso baseado nestas informaes de controle.
Ao entrar em uma sesso RTP, os participantes devem enviar um
pacote RTCP, que ser til para que todos saibam a quantidade de participantes presentes, quantidade esta que ser impactante no tempo de envio
dos seus pacotes de controle. Isto feito para no sobrecarregar a rede,
mantendo a escalabilidade da sesso.
Os pacotes RTCP possuem um cabealho e devem ser compostos
por, no mnimo, dois pacotes. O primeiro deles sempre ser ou um SR
(Sender Report) ou um RR (Receiver Report). O RTCP possui 5 tipos de pacote, a saber: SR (Sender Report), RR (Receiver Report), SDES (Source Description
Items), BYE e APP.
Este protocolo usado por aplicaes de tempo real que desejam
manter certo controle sobre a qualidade do servio que est sendo executado, como as de videoconferncia, por exemplo, que necessitam sincronia
entre o udio e o vdeo.
UNISINOS
65
MULTIMDIA

Conforme estudamos, o crescimento da classe de aplicaes multimdia necessita um atendimento especial pelos protocolos de Aplicao e de
Transporte. Assim sendo, diferentes protocolos so utilizados com o intuito
de minimizar o overhead que os atrasos da rede provocam, encontrando alternativas diferentes para o envio e transmisso da mdia.
Diferentes estudos e esforos vm sendo constantemente estudados
para garantir a qualidade de servio, principalmente deste tipo de aplicaes.
Um exemplo que pode ser citado um protocolo chamado RSVP (ReSerVation
Protocol). Com ele, cada fluxo possui uma determinada banda alocada, sendo
esta largura de banda gerenciada pelos roteadores. No entraremos em maiores detalhes sobre este protocolo neste estudo, mas um grande aliado para a
garantia de Qualidade de Servio para as aplicaes multimdia.
UNISINOS
66
MATEUS RAEDER
REFERNCIAS BIBLIOGRFICAS
COMER, D. E. Redes de Computadores e Internet. Porto Alegre: Bookman, 2001, 522p.
. Computer networks and internets. 5. ed. Upper Saddle River: Prentice
Hall, 2009. 600 p.
. Interligao em Redes com TCP/IP, Vol I, 3a Edio, Editora Campus, 2006.
FALBRIARD, C. Protocolos e aplicaes para redes de computadores. So Paulo:
rica, 2002. 228 p.
FOROUZAN, B. A. Comunicao de dados e redes de computadores. 3. ed. Porto
Alegre: Bookman, 2006. 840 p.
JACOBSON, V. Congestion avoidance and control. In: Prodeedings of SIGCOMM88
(Stanford, CA, Aug.1988), ACM.
KUROSE, J.; ROSS, K. Redes de Computadores e Internet: uma abordagem topdown. So Paulo: Pearson, 2005, 3ed, 633p.
TANENBAUM, A. C. Redes de Computadores. 4ed., Rio de Janeiro: Campus, 2003, 950p.
TITTEL, E. Teoria e problemas de rede de computadores. Porto Alegre: Bookman,
2003. 264 p.
TORRES, G. Redes de computadores: curso completo. Rio de Janeiro: Axcel Books,
2001. 664 p.
UNISINOS

Redes de Computadores UNISINOS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Redes de Computadores UNISINOS

Caricato da

Copyright:

Formati disponibili

REDES DE COMPUTADORES

UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS

Editora da Universidade do Vale do Rio dos Sinos

2010 Direitos de publicao e comercializao da

Redes de computadores : (conceitos, aplicaes e tipos de

1. Redes de computadores. I. Ttulo. II. Srie.

Dados Internacionais de Catalogao na Publicao (CIP)

Esta obra segue as normas do Acordo Ortogrfico

1 Introduo s redes de computadores........................................................... 9

1.2.3 Abertura de conexo..................................................................... 50

1 Introduo s Redes de Computadores

plausvel atualmente, pois no so somente os computadores tradicionais

Figura 1: Alguns dispositivos que se conectam a redes.

Figura 2: Entidades de uma rede.

Rede Local (LAN)

Rede Metropolitana (MAN)

Tabela 1: Classificao das redes de computadores de acordo com a abrangncia

Os tipos mais importantes de classificao de redes so as LANs,

Figura 3: Topologia em estrela.

Quando os dispositivos so interligados atravs de uma topologia em

Figura 4: Topologia em barra.

Uma topologia em anel , por sua vez, caracterizada por criar um

Figura 5: Topologia em anel.

Quando uma rede atinge uma distncia maior, classificada como

Figura 6: Distributed Queue Dual Bus.

As redes que interligam uma grande regio (como um estado, um

Figura 7: Arquitetura cliente/servidor

No modelo cliente/servidor, o processo cliente e o processo servidor

Figura 8: Cliente e servidor em mquinas separadas

1.3 Meios de transmisso

Figura 9: Cabo coaxial

Figura 10: Cabo de par tranado

O meio de transmisso guiado que vem sendo muito utilizado o

Figura 11: Cabo de fibra tica

1.3.2 Meios de transmisso no-guiados

mitem os dados com frequncias maiores, mas para distncias menores

Figura 12: Comunicao entre humanos.

Figura 13: Comunicao entre computadores

Figura 14: Comunicao entre protocolos

1.4.2 Modelo de referncia OSI

Figura 15: Modelo de referncia OSI

A primeira camada (ou primeiro nvel) a camada Fsica. Neste

1.4.3 Modelo Internet

Alguns autores agrupam

Diferentemente do modelo OSI, a pilha de protocolos da Internet,

Figura 16: Pilha de protocolos da Internet

As 5 camadas do Modelo Internet so: aplicao, transporte, rede,

Figura 17: Comunicao horizontal dos protocolos

Lembre-se de que todos os hosts implementam as camadas do modelo

Para que a comunicao entre os protocolos empilhados seja realizada,

Figura 19: Introduo de cabealhos na mensagem

Assim sendo, a comunicao vertical adiciona informaes em cada

Figura 20: Atrasos e seus locais de ocorrncia

As primeiras linhas so importantes para as funes de entrada e

O protocolo TCP ser estudado no Captulo 3. No momento, basta sabermos que

RTT (Round Trip Time)

Figura 21: Fluxo de mensagens entre cliente e servidor

Figura 22: Round Trip Time

Objetivando diminuir a quantidade de aberturas de conexes entre o

Figura 23: Formato da mensagem HTTP de requisio

Na primeira linha da requisio informa-se o mtodo de mensagem.

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

Assim, quando clicamos em botes e escrevemos o endereo de uma

Figura 25: Formato geral de uma mensagem HTTP de resposta