Redes de Computadores - Volume 2

Prévia do material em texto

Recife, 2011
Redes de Computadores
UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)
UNIDADE ACADÊMICA DE EDUCAÇÃO A DISTÂNCIA E TECNOLOGIA
Juliano Bandeira Lima
Obionor Nóbrega
Volume 2
Universidade Federal Rural de Pernambuco
Reitor: Prof. Valmar Corrêa de Andrade
Vice-Reitor: Prof. Reginaldo Barros
Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho
Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski
Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire
Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira
Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena
Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos
Produção Gráfica e Editorial
Capa e Editoração: Rafael Lira, Italo Amorim e Arlinda Torres
Revisão Ortográfica: Elias Vieira
Ilustrações: Moisés de Souza
Coordenação de Produção: Marizete Silva Santos
Sumário
Apresentação ................................................................................................................. 4
Conhecendo o Volume 2 ................................................................................................ 5
Capítulo 1 – A Camada de Transporte ............................................................................. 6
1.1 Introdução .................................................................................................................6
1.2 Multiplexação e demultiplexação na camada de transporte .....................................8
1.3 UDP – Protocolo de Datagrama do Usuário .............................................................10
1.4 TCP – Protocolo de Controle de Transmissão ..........................................................12
1.5 TCP e UDP: Tópicos Adicionais .................................................................................21
Capítulo 2 – A Camada de Rede e o Protocolo IP .......................................................... 29
2.1 Introdução ...............................................................................................................29
2.2 Algoritmos de roteamento ......................................................................................35
2.3 A Camada de Rede na Internet ................................................................................42
Capítulo 3 – Internet, Intranet e Extranet ..................................................................... 55
3.1 Internet ....................................................................................................................55
3.2 Intranet ....................................................................................................................56
3.3 Extranet ...................................................................................................................58
Considerações Finais .................................................................................................... 62
Conheça os Autores ..................................................................................................... 63
4
Apresentação
Caro(a) aluno(a),
Seja bem-vindo(a) ao curso de Redes de Computadores. Este curso é composto por 4 volumes. Neste 
primeiro volume, vamos estudar os conceitos introdutórios e os principais modelos de referência na área Redes de 
Computadores. Também estudaremos, neste volume, as principais aplicações utilizadas em ambiente de Internet 
(como, por exemplo, navegação na Web, correio eletrônico, telefonia via Internet, dentre outros). 
No segundo volume, serão abordados os protocolos que fazem transporte de informações em uma rede. 
Um outro assunto que será abordado é a identificação e localização de computadores em um ambiente de Rede. 
No terceiro volume, você aprenderá sobre como os dados são enviados através dos meios físicos de comunicação 
com e sem fio. Por fim, o quarto e último volume abordará tópicos de gerenciamento e segurança de redes de 
computadores. Concluindo a nossa disciplina, apresentaremos conceitos sobre a Próxima Geração de Redes de 
Computadores.
Bons estudos!
Juliano Bandeira Lima e Obionor O. Nóbrega
Professores Autores
5
Redes de Computadores
Conhecendo o Volume 2
Módulo 2 – O Protocolo TCP/IP e a Internet
Carga Horária: 15 h/aula
Objetivo: Introduzir os principais conceitos relacionados à camada de transporte e à 
camada de rede, apresentando seus protocolos básicos e descrevendo suas funcionalidades. 
Conceituar Internet, Intranet e Extranet, relacionando a sua importância nos diversos 
cenários das redes de computadores.
Conteúdo Programático
» Camada de Transporte;
» Camada de Rede;
» Internet, Intranet e Extranet.
6
Redes de Computadores
Capítulo 1 – A Camada de Transporte
Vamos conversar sobre o assunto?
Caro(a) aluno(a), 
No volume 1, você teve a oportunidade de conhecer importantes conceitos 
relacionados às redes de computadores. Ao longo da sua apresentação a este mundo cheio 
de novidades, você estudou aspectos como topologia e classificação de redes, meios físicos 
e técnicas de comutação. Você pôde perceber, também, a importância do uso de modelos 
de camadas para descrever e estudar as redes de computadores. Considerando de maneira 
particular este último tópico, podemos iniciar nossa conversa levantando um simples 
questionamento: por que o modelo TCP/IP recebeu este nome? Por que não recebeu, por 
exemplo, o nome HTTP/FTP, como referência a dois dos protocolos que conhecemos na 
camada de aplicação? Bom, a respota à pergunta feita guarda uma relação com as duas 
camadas que, neste capítulo, começaremos a estudar: a camada de transporte e a camada de 
rede. Alguns autores mencionam que, sem as funções desempenhadas por essas camadas, 
o conceito de protocolos em camadas não faria qualquer sentido. Naturalmente, esta é uma 
afirmação que só será compreendida de forma completa quando voltarmos nossa atenção 
para as próximas páginas e descobrirmos os detalhes que a justificam. Por enquanto, é 
suficiente que mantenhamos acesa a vontade de conhecer cada vez mais sobre as redes de 
computadores e que, em nossa memória, estejam presentes os conceitos aprendidos nos 
tópicos estudados enteriormente. Assim, será mais fácil reunir as informações e perceber a 
interdependência que existe entre os diversos assuntos dessa disciplina. Vamos em frente!
1.1 Introdução
Ao longo dos nossos estudos sobre a camada de aplicação, realizados no volume 1 
desta disciplina, algumas “manchetes” sobre a camada de transporte já foram publicadas. 
Neste capítulo, entretanto, conheceremos de forma mais minuciosa certos aspectos que 
concedem a esta camada o status de núcleo de toda a hierarquia de protocolos. Para 
começar, podemos descrever as três responsabilidades básicas da camada de transporte. 
A primeira delas depende, fundamentalmente, da relação entre esta camada e a camada 
de rede. Quando, num sistema de origem (um computador pessoal que temos em casa, por 
exemplo), monta-se um datagrama, os algoritmos e protocolos da camada de rede devem 
se encarregar de encaminhá-lo até o sistema de destino (um servidor no qual estejamos 
buscando uma página, por exemplo). No entanto, é de responsabilidade da camada de 
transporte ampliar este serviço e fazer com que a comunicação aconteça, não entre os 
sistemas simplesmente, mas entre dois processos das camadas de aplicação que rodam 
nesses sistemas finais.
A segunda responsabilidade da camada de transporte tem a ver com a 
heterogeneidade que se pode encontrar nos níveis mais baixos de uma pilha de protocolos. 
Sinais transmitidos por meio de fibras ópticas, por exemplo, estão menos propensos à ação 
de ruído do que aqueles transmitidos por cabos metálicos ou num meio físico sem fio; nas 
camadas de enlace e na de rede, protocolos com características bem distintas podem ser 
7
Redes de Computadores
utilizados. Tudo isso tem impacto sobre o desempenho de uma comunicação, mas, a camada 
de transporte possui a atribuição de fazer com queduas entidades possam se comunicar de 
maneira confiável, independentemente dos cenários implementados na chamada subrede.
O terceiro desafio enfrentado pela camada de transporte diz respeito aos controles 
de congestionamento e de fluxo. A taxa em que um processo da camada de aplicação de um 
host produz dados a serem entregues às camadas inferiores e, posteriormente, enviados 
nem sempre é comportada pelos recursos disponíveis na rede. Se o envio de pacotes for 
feito sem qualquer preocupação, podem-se formar filas nas entradas dos roteadores e, 
consequentemente, haver descartes de dados. Essa é uma situação de congestionamento. 
De outra forma, mesmo que os enlaces e equipamentos da subrede sejam capazes de 
lidar com a injeção de pacotes num ritmo acelerado, o sistema de destino pode não ser 
suficientemente robusto para isso, isto é, não ter a capacidade de processar os dados na 
velocidade em que a rede os entrega. Neste caso, estamos diante de um problema de fluxo, 
algo cujo controle também se deve à camada de transporte.
A fim de cumprir com as responsabilidades descritas, a camada de transporte 
estabelece uma comunicação lógica entre processos de aplicação que rodam em hosts 
diferentes. Isso significa que, para uma aplicação, é como se dois computadores que se 
comunicam estivessem diretamente ligados, mesmo que, na realidade, existam entre 
eles dezenas de roteadores e tipos bem distintos de enlaces. Esta ideia pode ser melhor 
compreendida se observarmos a Figura 1.1. Nesta ilustração, vê-se que, nos equipamentos 
da subrede (roteadores), acessa-se apenas até a camada 3, o que é suficiente para o 
desempenho da tarefa básica desses equipamentos (determinação do percurso a ser seguido 
pelos datagramas). Os dados referentes à camada de transporte, que, na terminologia 
da Internet, são denominados segmentos, são encapsulados e desencapsulados apenas 
nos sistemas finais; o mesmo acontece com as mensagens recebidas de um processo de 
aplicação do sistema de origem e entregues a outro processo de aplicação no sistema de 
destino.
Figura 1.1 – Comunicação lógica provida pela camada de transporte
Por meio dessa comunicação lógica entre processos, diversos serviços são 
oferecidos pelas entidades de transporte (hardware/software que executam o trabalho). 
Nesse contexto, os serviços orientados a conexão possuem destacada importância. Com 
eles, uma entidade remetente estabelece uma espécie de contato com a entidade de 
8
Redes de Computadores
destino, para se certificar de que ela está lá, aguardando a chegada dos dados que só depois 
serão enviados. Isso é necessário sempre que, nos níveis inferiores da rede, estiverem 
trabalhando protocolos que simplesmente injetam os dados nos enlaces, sem saber se, no 
outro extremo, existe “alguém” os aguardando. Os serviços com confirmação também são 
de grande importância. Por meio deles, entidades de transporte que se comunicam trocam 
dados para informar se um segmento específico foi entregue com sucesso. Quando isso não 
acontece, ações como a de reenvio de segmentos podem ser executadas. A lista a seguir 
resume algumas das propriedades comuns que se espera que um protocolo de transporte 
ofereça:
» Garantia de entrega da mensagem;
» Entrega de mensagens na mesma ordem em que foram enviadas;
» Entrega de, no máximo, uma cópia de cada mensagem;
» Admissão de mensagens arbitrariamente grandes;
» Implementação de controle de fluxo entre o transmissor e o receptor;
» Concentração dos vários processos de aplicação existentes em cada host.
Apesar de boa parte dos processos de aplicação requisitar serviços orientados a 
conexão e com garantias de entrega (o que não se consegue com a camada de rede), há 
situações em que serviços sem conexão e não confiáveis são necessários. Considere, por 
exemplo, uma situação em que se deseja assistir um vídeo pela Internet. Você já imaginou 
se, a cada quadro de vídeo recebido, nosso computador tivesse que enviar uma informação 
ao remetente, confirmando a entrega, para só então ele injetar um novo quadro na rede? 
A sensação de movimento do filme seria completamente perdida. Por outro lado, se nossa 
máquina deixar de receber ou receber com erro um ou outro quadro, dentre os 30 quadros 
que recebemos por segundo, talvez o prejuízo não seja tanto. Na Internet, essa questão é 
administrada pelo uso de dois protocolos na camada de transporte: o UDP (User Datagram 
Protocol, Protocolo de Datagrama de Usuário), que provê à aplicação solicitante um serviço 
não confiável e não orientado a conexão, e o TCP (Transmission Control Protocol, Protocolo 
de Controle de Transmissão), que provê à aplicação solicitante um serviço confiável e 
orientado a conexão. O projetista de uma aplicação de rede deve especificar o protocolo de 
transporte a ser usado. Aprenderemos mais sobre o UDP e o TCP noutras seções.
1.2 Multiplexação e demultiplexação na camada 
de transporte
Na seção introdutória deste capítulo, colocamos como a primeira responsabilidade 
de uma camada de transporte a ampliação do serviço de entrega desempenhado pela 
camada de rede. Esta tarefa é necessária porque, sobre uma única interface de rede por meio 
da qual um host se comunique, diversos processos de aplicação podem estar em execução. 
Para explicar melhor, consideremos uma situação em que estejamos, simultaneamente, 
acessando uma página da Internet, enviando um arquivo via FTP e mandando um e-mail, 
o que envolve 3 processos de aplicação. Os dados que são gerados por essas aplicações, 
ao serem repassados para as camadas inferiores, devem possuir um único identificador 
de rede, visto que estão relacionados ao mesmo sistema de origem. Até aí, tudo bem... 
mas quando precisarmos receber de volta esses dados da camada de rede (ou entregá-
los nos respectivos destinos), como saberemos para que processo de aplicação cada um 
deve seguir? É por este motivo que existem os sockets, que são portas pelas quais os dados 
passam da rede para o processo e do processo para a rede.
9
Redes de Computadores
Quando os dados vindos de uma aplicação chegam à camada de transporte, eles 
trazem consigo um número de porta específico, que indica o seu processo de origem. Este 
número é, então, escrito em determinado campo do segmento de camada de transporte a 
ser montado. No segmento, também se escreve o número da porta de destino, que indica 
o processo ao qual se deve entregar os dados do outro lado da conexão. Só depois desse 
procedimento é que se faz o repasse dos dados à camada de rede. Fazendo uma simples 
analogia, é como se desejássemos enviar uma carta a alguém que morasse num edifício. 
Se escrevêssemos no envelope apenas o número do prédio, o mensageiro não saberia 
para quem encaminhar a correspondência. O número de porta funciona como o número 
do apartamento, permitindo o passo final da entrega. A reunião de dados provenientes de 
diferentes processos, aos quais diferentes números de portas são atribuídos, e seu repasse 
à camada de rede é denominada multiplexação; a recepção, por meio de uma interface de 
rede, de um grupo de dados e sua entrega a diferentes processos de aplicaçao é denominada 
demultiplexação. A multiplexação e a demultiplexação na camada de transporte são 
ilustradas na Figura 1.2.
Figura 1.2 – Multiplexação e demultiplexação na camada de transporte
Na camada de transporte da Internet, cada um dos campos reservados aos números 
de portas, presentes tanto no UDP quanto no TCP, possuem 16 bits (números decimais de 
0 a 65535). Os números de porta entre 0 e 1023 são denominados números de porta bem 
conhecidos, estando reservados a protocolos cuja utilização é ampla, como o HTTP (porta 
de número 80) e o FTP (porta de número 21). A lista completa dos números de porta bem 
conhecidos pode ser encontrada na RFC 1700 e na RFC 3232, em http://www.iana.org.
Como nem todos os protocolos de aplicação possuem números de porta 
bem conhecidos, outras estratégias são necessárias para prover a multiplexação/ 
demultiplexação. Umaprimeira opção é empregar um servidor de processos, que atua 
num esquema conhecido como protocolo de conexão inicial. Este servidor atende a uma 
série de portas ao mesmo tempo, aguardando uma solicitação de conexão. Quando uma 
solicitação a qual nenhum servidor está associado é recebida, o servidor de processos 
gera uma conexão para o servidor solicitado, funcionando como uma espécie de proxy 
(intermediário). Noutro modelo, emprega-se um processo especial chamado servidor de 
nomes, que mantém um registro com os nomes dos diversos serviços e seus respectivos 
números de porta. As solicitações recebidas e que contêm, inicialmente, o nome do serviço 
que desejam são, então, encaminhadas para este servidor, o qual retorna o número de 
porta após uma consulta no registro. Depois disso, a conexão com o servidor de nomes é 
encerrada e uma nova conexão com o serviço desejado é estabelecida.
10
Redes de Computadores
Você Sabia?
Firewall é o nome dado ao dispositivo de uma rede de computadores que tem por objetivo 
aplicar uma política de segurança a um determinado ponto de controle da rede? Algumas das 
ações mais importantes de um firewall têm efeito por meio do bloqueio ou da restrição do 
estabelecimento de conexões de certas portas da camada de transporte. Aprenderemos mais 
sobre firewalls quando tratarmos de segurança em redes de computadores.
1.3 UDP – Protocolo de Datagrama do Usuário
Nesta seção, começaremos nossos estudos sobre os protocolos que atuam na 
camada de transporte da Internet. O primeiro protocolo a ser examinado é o UDP e a sua 
principal característica é a de não ser orientado a conexão. O UDP não se preocupa em 
estabelecer um contato inicial com a entidade a quem os dados serão enviados, não sendo, 
portanto, capaz de oferecer qualquer tipo de garantia de que uma entrega bem sucedida 
será efetuada. Diante disso, resta a este protocolo a funcionalidade básica que descrevemos 
na seção anterior: multiplexar e demultiplexar dados, para fins de intermediação entre 
os diversos processos de aplicação e a interface de rede. Diante da sua simplicidade, a 
importância do UDP enquanto protocolo de transporte poderia até ser questionada... isso 
sugere a apresentação de alguns motivos que indicam a sua relevância em certos cenários e 
diante de necessidades específicas.
Quando o TCP é empregado na camada de transporte, antes de repassar os 
dados vindos dos processos de aplicação à camada de rede, uma série de verificações é 
realizada. O protocolo precisa verificar, por exemplo, se a entidade de destino possui espaço 
suficiente para acomodar novos dados (controle de fluxo); além disso, é necessário verificar 
se confirmações de entrega de segmentos anteriormente enviados já foram recebidas. Em 
caso negativo, pode-se priorizar o reenvio de dados antigos, em vez de injetar na rede dados 
mais recentes. Com o UDP, nada disso acontece. Tão logo um processo de aplicação passe 
dados à entidade de transporte, o UDP ele os empacotará num segmento e os repassará 
imediatamente à camada de rede. Essa forma de proceder tem grande utilidade em 
aplicações que requerem o que chamamos de tempo real, como uma videoconferência ou 
uma chamada de voz pela Internet. Em situações como essas, minimizar o tempo decorrido 
entre a criação dos dados no lado do transmissor e a sua entrega no destino é a prioridade. 
O alcance desse objetivo seria fortemente comprometido, caso empregássemos o TCP e 
tivéssemos aguardar verificações como as que descrevemos.
O não estabelecimento de conexões por parte do UDP também traz benefícios a 
aplicações como o DNS. O que o DNS faz se resume a uma simples consulta a um banco de 
dados; se este banco, por algum motivo, não responder, o solicitante pode refazer a consulta 
sem grandes prejuízos. Nesse contexto, ao dispensar toda uma troca inicial de informações 
de configuração de conexão, o UDP acelera o envio de pedidos e respostas, evitando uma 
lentidão desnecessária. Uma outra consequência disso é o fato de, no UDP, não ser preciso 
manter estados de conexão, que incluem buffers de envio e recebimento, parâmetros de 
controle de congestionamento e parâmetros numéricos de sequência e de reconhecimento 
(quando estudarmos o TCP, entenderemos melhor tudo isso). Como esses parâmetros não 
precisam ser monitorados, um servidor dedicado a uma aplicação específica pode suportar 
um número muito maior de clientes ativos quando a aplicação roda sobre UDP. Por fim, no 
UDP, temos uma sobrecarga de cabeçalho de pacote menor: apenas 8 bytes, em troca de 20 
11
Redes de Computadores
bytes do TCP.
A Figura 1.3 apresenta um quadro relacionando aplicações conhecidas e o 
protocolo de transporte utilizado por cada uma delas. Como era de se esperar, aplicações 
como o correio eletrônico, o acesso a um terminal remoto e a Web, que requerem certas 
garantias de entrega, utilizam o TCP. No gerenciamento de uma rede, o UDP é preferível; 
é comum que tarefas de gerenciamento sejam executadas em momentos em que a rede 
já está com algum tipo de sobrecarga, o que dificulta a transferência confiável de dados 
com congestionamento controlado. Como já foi comentado, as aplicações que envolvem 
multimídia utilizam, normalmente, o UDP. Todavia, em muitos casos, tem-se empregado 
o TCP, para evitar, por exemplo, situações em que muitos remetentes enviem pacotes 
“indiscriminadamente”, sem que a rede tome qualquer atitude. É importante mencionar, 
ainda, que o uso do UDP permite que a confiabilidade da transferência dos dados esteja 
embutida na própria aplicação.
Aplicação
Protocolo de camada de 
aplicação
Protocolo de transporte 
subjacente
Correio eletrônico SMTP TCP
Acesso a terminal remoto Telnet TCP
Web HTTP TCP
Transferência de arquivo FTP TCP
Servidor remoto de arquivo NFS Tipicamente UDP
Recepção de multimídia Tipicamente proprietária UDP ou TCP
Telefonia pela Internet Tipicamente proprietária UDP ou TCP
Gerenciamento de rede SNMP Tipicamente UDP
Protocolo de roteamento RIP Tipicamente UDP
Tradução de nome DNS Tipicamente UDP
Figura 1.3 – Algumas aplicações da Internet e seus protocolos de transporte subjacentes
Na Figura 1.4, é apresentada a estrutura de um segmento UDP. Conforme já 
tínhamos comentado, além do campo de dados da aplicação, o segmento UDP contém um 
cabeçalho bastante simples, com apenas quatro informações que perfazem um total de 8 
bytes. Na primeira linha, observamos os campos porta de origem e porta de destino, que 
têm a função de orientar os procedimentos de multiplexação e de demultiplexação descritos 
na seção anterior. O número da porta de origem é particularmente importante quando uma 
resposta deve ser devolvida à origem (o processo que transmite a resposta copia o campo 
porta de origem do segmento de entrada no campo porta de destino no segmento de saída, 
especificando qual processo na máquina transmissora deve recebê-lo).
O campo comprimento especifica o tamanho total do segmento, incluindo o 
cabeçalho, e o campo soma de verificação serve para detectar erros. O valor do campo 
soma de verificação auxilia uma espécie de “prova dos 9”, que envolve os dados presentes 
no segmento e que é executada na sua entrega. Se, por meio desse procedimento, for 
12
Redes de Computadores
identificado um erro (proveniente, por exemplo, de alguma imperfeição ao longo da 
transmissão em camadas inferiores), o segmento será simplesmente descartado ou será 
repassado à camada de aplicação com algum aviso de alerta (o UDP não realiza a correção 
de um erro detectado). É importante que se tenha esse mecanismo de controle de erros 
fim a fim, mesmo no UDP, porque não há garantia de que todos os enlaces entre a origem 
e o destino forneçam verificação de erros (lembremos que o que acontece na camada de 
transporte deve ser, de certo modo, independente do que acontece nas camadas inferiores).
Figura 1.4 – Estrutura do segmento UDP
1.4 TCP – Protocolo de Controle de Transmissão
O TCP é um protocolo projetado para oferecer um fluxo de bytesfim a fim 
sobre uma rede possivelmente heterogênea e não-confiável. Quando mencionamos a 
heterogeneidade da rede, estamos nos referindo à possibilidade de, nas camadas inferiores 
à de transporte, termos, na prática, um “emaranhado” de redes com topologias, larguras 
de banda, tamanhos máximos de pacotes e retardos bem diferentes. Os protocolos que 
lidam com essa diversidade não oferecem a garantia de que os dados são entregues na 
ordem em que são enviados, por exemplo; na verdade, muitos deles não oferecem sequer 
a garantia de que os dados são entregues (ainda que fora de ordem). O TCP vem para cobrir 
essas “brechas”, sendo representado por uma entidade de transporte que pode ser um 
procedimento de biblioteca, um processo do usuário ou parte do núcleo numa máquina.
Com o TCP, estabelecem-se conexões lógicas full-duplex entre processos que estão 
sendo executados sobre dois computadores quaisquer da Internet. Isso significa que, antes 
do envio dos dados úteis, é necessária uma fase de estabelecimento de conexão explícita, 
de modo análogo ao que ocorre numa chamada telefônica usual, por exemplo. Também 
se faz necessária uma fase para que a conexão seja encerrada. Este protocolo precisa, 
ainda, se adaptar à comunicação entre dois computadores que estão bem distantes um 
do outro, bem como à comunicação entre máquinas que se encontram numa mesma sala. 
A diferença básica entre estes dois cenários é que os tempos para que os dados enviados 
por um dos lados vão até a outra a extremidade e retornem (RTT, round-trip time) podem 
variar bastante. Veremos que o RTT é uma variável crítica para que o serviço de confirmação 
oferecido pelo TCP funcione corretamente. 
Outro aspecto que o TCP considera é a entrega em ordem dos dados. As redes 
sobre as quais uma camada de transporte é implementada podem ser bastante dinâmicas 
do ponto de vista de encaminhamento dos dados. Isso acontece porque os algoritmos 
de roteamento, sobre os quais falaremos no próximo capítulo, buscam direcionar os 
datagramas por linhas que apresentam custos menores (em relação ao retardo, à distância 
geográfica a ser percorrida, ao congestionamento a ser enfrentado etc). O fato é que esses 
custos podem ser modificados com o passar do tempo e datagramas com origem e destino 
13
Redes de Computadores
iguais podem seguir rotas distintas, sendo entregues fora de ordem. O TCP recorre, então, a 
números de sequência e faz com que, em alguns casos, a entidade de transporte de destino 
fique aguardando a chegada de um segmento mais antigo, para que os dados recebidos 
possam ser repassados à camada de aplicação na ordem correta, sem a presença “lacunas”.
Uma última funcionalidade a ser abordada nesta introdução ao TCP é a de 
controle de fluxo fim a fim, a qual se baseia no emprego de buffers ou janelas (mais tarde, 
entenderemos o porquê de se utilizar este termo). Um buffer é uma espécie de área de 
armazenamento de dados presente nas entidades de transporte transmissoras e receptoras. 
No transmissor, buffers são necessários para armazenar dados cuja entrega ainda não foi 
confirmada. Caso seja necessária uma retransmissão, os dados estarão lá, seguramente 
guardados. No receptor, os buffers armazenam dados que estão esperando “pedaços” 
mais antigos que ainda não chegaram ou dados que estão simplesmente aguardando 
o repasse a um processo da camada de aplicação (costuma-se dizer que um processo 
de aplicação, no momento apropriado, lê dados que estão armazenados num buffer da 
camada de transporte). Pela ação do controle de fluxo fim a fim, sob condições normais de 
funcionamento, uma entidade transmissora não pode enviar uma quantidade de segmentos 
que não caiba na área de armazenamento da entidade receptora. Para isso, juntamente 
com a confirmação de entrega de um segmento, a entidade de transporte receptora envia à 
origem um aviso, informando a sua disponibilidade de buffers (ou o tamanho da sua janela). 
Naturalmente, o controle de fluxo deve observar, também, questões de congestionamento. 
Não adiantaria termos, por exemplo, dois computadores com grande capacidade de 
processamento e com janelas grandes se comunicando por uma rede lenta; as limitações de 
velocidade da rede teriam que ser respeitadas. Algo semelhante aconteceria se tivéssemos 
dois computadores lentos se comunicando por enlaces de grande velocidade.
1.4.1 O segmento TCP
Como já mencionamos, o nome dado a um pacote trocado entre duas entidades 
de transporte TCP é segmento. Cada segmento possui um campo de dados, no qual uma 
certa quantidade de bytes recebidos do processo transmissor é agrupado. Além disso, um 
segmento TCP possui um cabeçalho como o que é ilustrado na Figura 1.5.
Figura 1.4 – Estrutura do segmento TCP 
Os campos porta de origem e porta de destino possuem a finalidade já descrita no 
estudo do UDP. Juntamente com os endereços das interfaces de rede de origem e destino, 
esses campos identificam de forma exclusiva uma conexão TCP. Os campos número de 
sequência, número de confirmação e janela estão envolvidos em algumas das funções que 
mencionamos (prevenção contra entrega de duplicatas, conformação de entrega, controle 
de fluxo etc). O número de sequência, especificamente, contém a numeração associada ao 
14
Redes de Computadores
primeiro byte de dados transportado no segmento. Os campos URG a FIN são todos flags 
(sinalizadores). SYN e FIN são usados, respectivamente, no estabelecimento e no término 
de uma conexão. ACK é ativado quando o campo número de confirmação tiver que ser 
considerado. URG é ativado quando o segmento contém dados urgentes (o campo ponteiro 
de urgência indica onde começam os dados não urgentes contidos no segmento). A ativação 
de PSH indica que o receptor deve entregar os dados à aplicação mediante sua chegada, 
em vez de armazená-los até que um buffer completo tenha sido recebido. RST é utilizado 
para reiniciliar uma conexão que tenha ficado confusa por algum motivo. O campo soma de 
verificação funciona como no UDP e o campo opções serve para o oferecimento de recursos 
extras, não previstos pelo cabeçalho comum. Nas opções, um host pode, por exemplo, 
estipular o máximo de carga útil do TCP que está disposto a receber.
1.4.2 Estabelecimento e encerramento de conexões
Para explicarmos como uma conexão é estabelecida no TCP, consideraremos que 
um dos lados, o host 1, desempenha o papel de chamador ou de cliente (entidade que toma 
a iniciativa para o estabelecimento da conexão) e que o outro lado, o host 2, desempenha 
a função de chamado ou de servidor (participante passivo). O algoritmo que determina 
os passos que devem ser seguidos para que a conexão seja estabelecida é denominado 
handshake de três vias (veja a Figura 1.5).
Figura 1.5 – Handshake de três vias: estabelecimento de uma conexão TCP
(1) Inicialmente, o cliente envia ao servidor um segmento contendo o número de 
sequência incial que ele pretende usar. O flag SYN deve estar ativado, indicando uma ação 
para estabelecimento de conexão. O campo número de sequência do segmento carrega 
o valor x. (2) O servidor responde com um segmento em que, além do SYN, está ativado, 
também, o flag ACK, indicando que o campo número de confirmação, ao qual se atribui o 
valor x + 1, contém uma confirmação relacionada ao segmento recebido (o valor atribuído 
é x + 1 para informar ao outro lado o número de sequência do próximo segmento que o 
servidor espera receber; noutras palavras, o servidor indica que todos os segmentos com 
números de sequências iguais ou menores a x já foram recebidos). (3) Finalmente, o cliente 
responde com um terceiro segmento que confirma o número de sequência do servidor e, a 
partir de então, os dados úteis podem fluir de um lado a outro.
Os critérios para a escolha dos números de sequência iniciais dos segmentos 
trocados numa conexão TCP não serão tratados em detalhes neste material. No entanto, 
15
Redes de Computadores
é suficiente dizermos que as numerações de cada lado são determinadas de maneiraa evitar que um mesmo número de sequência seja reutilizado com frequência. Se isso 
acontecesse, o TCP teria mais dificuldade para rejeitar segmentos duplicados ou entregues 
fora de ordem. Outro detalhe importante no estabelecimento de conexões no TCP tem a 
ver com o uso de timers ou temporizadores (estudaremos isso mais à frente). Sempre que 
um cliente envia um segmento na tentativa de iniciar uma conexão, ele ativa um timer e 
aguarda o retorno do servidor por um certo tempo. Se este retorno não acontecer, o cliente 
entende que o segmento inicial se perdeu e realiza um novo pedido. Juntamente com os 
números de sequência, são os timers que asseguram que não haverá confusão durante o 
estabelecimento de uma conexão.
Dica
Na página http://www.netbook.cs.purdue.edu/animations/TCP%203-way%20handshake.html, 
encontra-se uma animação em flash que ilustra o estabelecimento de uma conexão por meio do 
handshake de três vias. Acesse!
No TCP, o encerramento de uma conexão pode ser melhor compreendido se 
interpretarmos a conexão (que é full-duplex) como um par de conexões simplex, as quais 
podem ser finalizadas de modo independente de sua parceira (encerramento simétrico). 
Quando um lado deseja encerrar a conexão, ele simplesmente envia um segmento com 
o flag FIN ativado e fica no aguardo de uma confirmação. Isso significa que ele não tem 
mais dados a enviar, embora ainda possa permanecer recebendo dados que o outro lado 
envia. Depois que este outro lado fizer o mesmo, a conexão estará encerrada em ambos os 
sentidos. Aqui, um timer também é utilizado. Ele tem o objetivo de fazer com que a resposta 
ao envio de um FIN seja aguardada apenas durante certo tempo. Se ela não retornar, a 
conexão será encerrada.
Você Sabia?
Não existe solução teórica para se ter certeza de que o encerramento de uma conexão TCP 
pode ser realizado sem perda de dados que ainda se deseja transmitir de um lado a outro? É 
por isso que se recorre aos timers que, na prática, funcionam muito bem. Essa questão pode 
ser entendida com mais detalhes por meio do chamado problema dos dois exércitos. Pesquise e 
descubra do que se trata esse problema e qual a sua relação com o encerramento de conexões 
na camada de transporte.
1.4.3 Política de transmissão do TCP
Conforme comentamos quando apresentamos alguns campos presentes no 
cabeçalho do segmento TCP, as principais funcionalidades desse protocolo dependem, 
fundamentalmente, dos números de sequência, dos números de confirmação e das janelas. 
Tais funcionalidades estão relacionadas à política de transmissão do TCP, que contempla 
questões de controle de fluxo e de garantia de entrega. Uma explicação bem ilustrativa 
dessas questões pode ser conduzida com base na Figura 1.6. Nesta figura, observamos a 
troca de segmentos entre transmissor e receptor e verificamos os valores que certos campos 
dos cabeçalhos desses segmentos e que o buffer do receptor assumem.
16
Redes de Computadores
Figura 1.6 – Política de transmissão e gerenciamento de janelas no TCP
Incialmente, o buffer do receptor, que possui um tamanho de 4096 bytes, encontra-
se vazio. No passo (1), o transmissor envia 2048 bytes de dados, partindo de um número 
de sequência igual a 0 (zero). Quando este segmento é recebido, metade da janela é 
preenchida. Por isso, no passo (2), o receptor responde com o número de confirmação igual 
a 2048 e com a janela igual a 2048, identificando o tamanho do espaço vazio em seu buffer. 
Lembre-se que o número de confirmação tem relação com o próximo byte que o receptor 
espera receber; é como se, no primeiro segmento, tivessem chegado os bytes 0 a 2047 e, no 
próximo segmento, o primeiro byte devesse ser o byte 2048.
Se, no passo (3), o transmissor enviar mais 2048 bytes, a janela do receptor será 
completamente preenchida, pois, nesse meio tempo, a aplicação ainda não leu nada 
que foi armazenado no buffer. Depois disso, em (4), o receptor responde com o número 
de confirmação igual a 4096 e com a janela igual a 0. Neste momento, o transmissor se 
encontra bloqueado, pois ele sabe que, do outro lado, não há espaço para guardar novos 
dados que ele venha a enviar; o transmissor poderia enviar apenas dados urgentes, com 
o objetivo de eliminar um processo que estivesse sendo executado no receptor, ou um 
segmento de 1 byte, “pedindo” para que o receptor enviasse mais uma vez o ACK e a janela 
atuais. Quando a aplicação, do lado do receptor, lê 2048 bytes que estavam no buffer, o 
estado da janela muda. Então, em (5), o receptor envia um segmento repetindo o último 
número de confirmação e indicando a nova situação da janela. A troca de dados volta, 
agora, a fluir como anteriormente.
17
Redes de Computadores
Dica
No link http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/flow/FlowControl.
htm, encontra-se uma applet que ilustra por meio de animações um processo semelhante ao 
que estudamos com base na Figura 1.6. São apresentadas duas máquinas, host A e host B; o 
usuário pode determinar os tamanhos dos dados que essas máquinas trocam e as respectivas 
janelas. Quando o início da transmissão é ordenado, é possível observar as confirmações e as 
mudanças no buffer passando de um lado a outro da conexão. Experimente!
O passo a passo descrito parece funcionar muito bem e, do ponto de vista 
teórico, de fato, funciona! No entanto, se alguns cuidados não forem tomados, a política 
de transmissão do TCP pode levar a situações de ineficiência, em que a largura de banda 
disponibilizada pela rede é mal aproveitada e os esforços solicitados ao transmissor e ao 
receptor são desnecessários. Em primeiro lugar, é importante sabermos que um transmissor 
não é obrigado a enviar os dados assim que os recebe do processo de aplicação. No cenário 
que descrevemos, antes de executar o passo (1), o transmissor poderia ter esperado o 
acúmulo de mais 2048 bytes para, em seguida, enviar um segmento com 4096 bytes de 
dados. Isso “diluiria” melhor os bytes do cabeçalho, levando a um melhor aproveitamento 
da rede.
Consideremos, agora, uma situação em que caracteres digitados no teclado de 
uma máquina (transmissor) estão sendo enviados para uma máquina remota (receptor), 
como uma espécie de editor interativo via telnet. Você já imaginou se, a cada caractere 
(byte) digitado e enviado, o receptor tivesse que criar um segmento TCP apenas para 
enviar confirmações e atualizações de janela?! Quase a totalidade dos bytes retornados 
seria apenas de cabeçalho, o que, certamente, seria bastante ineficiente. Numa situação 
como essa, o que o receptor normalmente faz é aguardar a chegada de vários segmentos e 
confirmar todos de uma só vez, gerando “economia” de números de sequência e de largura 
de banda. Do lado do transmissor, que também estaria trabalhando de forma “burra”, 
pois, para cada byte enviado, haveria 40 bytes de cabeçalho (considerando os cabeçalhos 
das camadas de transporte e de rede), outra estratégia é adotada. O que se faz é enviar o 
primeiro byte recebido do processo de aplicação e acumular em buffer os bytes que vem em 
seguida, até que o byte pendente tenha sido confirmado. Após essa confirmação, os bytes 
do buffer são enviados num único segmento TCP e uma nova fase de armazenamento é 
iniciada até que todas as confirmações retornem. Este procedimento recursivo é conhecido 
como algoritmo de Nagle.
Outra situação específica que pode ocorrer é a chamada síndrome da janela 
boba, a qual descrevemos a seguir. Imagine um processo de aplicação que repassa à 
camada de transporte grandes blocos de dados, que, por sua vez, são colocados num 
segmento TCP e enviados a uma entidade receptora. Considere ainda que, com a janela 
do receptor totalmente preenchida, o respectivo processo de aplicação inicia a leitura dos 
bytes recebidos um por vez. Quando 1 byte for lido, o receptor informará ao transmissor 
sua nova janela, que possui espaço para recebimento de apenas mais 1 byte. Mesmo que 
o transmissor já possua muitos bytes prontos para envio, ele precisará respeitara janela 
do receptor e enviará apenas 1 byte de dados (além de um grande número de bytes de 
cabeçalho!). A janela do receptor estará novamente cheia e o transmissor deve esperar por 
uma nova atualização. Se, mais uma vez, a aplicação no receptor ler apenas 1 byte, esse 
processo voltará a se repetir de maneira indefinida (observe a Figura 1.7).
18
Redes de Computadores
Figura 1.7 – Síndrome da janela boba
A solução para a síndrome da janela boba foi apresentada por Clark. Em vez de 
o receptor informar ao transmissor pequenas mudanças em sua janela (como a mudança 
de apenas 1 byte, em nosso exemplo), ele espera até que um espaço maior tenha sido 
liberado, ou seja, até que um certo número de bytes tenha sido lido pelo processo de 
aplicação. Na prática, o transmissor aguarda até que o seu buffer esteja ocupado pela 
metade ou até que haja espaço suficiente para acomodar o tamanho máximo de segmento 
que as duas entidades combinaram no estabelecimento da conexão. Só depois que uma 
dessas condições for alcançada é que uma atualização de janela deve ser enviada; é como 
se o receptor dissesse ao transmissor: “pode mandar mais um bloco de bytes, pois, agora, 
já tenho espaço suficiente.” Obviamente, a solução de Clark e o algoritmo de Nagle são 
complementares.
Outras ações podem ser tomadas pelas entidades de transporte a fim de melhorar a 
eficiência no envio dos segmentos. O próprio transmissor pode acumular um número maior 
de bytes, antes de enviá-los ao receptor. Apesar de estratégias como essa aumentarem o 
tempo de resposta, elas elevam o desempenho na transmissão, o que é importante em 
aplicações como a transferência de arquivos. No que diz respeito à entrega e à confirmação 
ordenada de dados, o receptor também pode agir. Se os segmentos 1, 2, 3, 4, 6 e 7 chegarem 
a um receptor, ele pode confirmar os segmentos 1, 2, 3 e 4 e manter os segmentos 6 e 7 
armazenados. Quando, do lado do transmissor, o segmento 5 sofrer uma temporização, ele 
será reenviado. Assim que o receptor recebê-lo, ele poderá ser confirmado juntamente com 
os segmentos 6 e 7 (o transmissor não precisará reenviar os segmentos 6 e 7).
1.4.4 Controle de congestionamento no TCP
Em seções anteriores, já conversamos um pouco sobre congestionamento e fluxo. 
Assim, vamos admitir que você já conhece, de forma clara, as diferenças entre essas questões 
e as responsabilidades que, nesse contexto, a camada de transporte precisa assumir. Nesta 
seção, explicaremos de forma mais detalhada a atuação do TCP na prevenção e na reação 
a situações de congestionamento. Veremos que o TCP recorre a algo que denominamos 
manipulação dinâmica das janelas e que as diversas opções fornecidas por essa estratégia 
permitem solucionar as questões mencionadas.
Para começar, é interessante que descrevamos como a camada de transporte pode 
fazer pressuposições acerca do que acontece nas camadas inferiores. Nesse processo, 
19
Redes de Computadores
a chegada (ou não!) de confirmações desempenha um papel imprescindível. Quando 
uma entidade de transporte envia um segmento para um receptor, se a confirmação da 
entrega deste segmento não chegar, o transmissor suporá que algo “estranho” aconteceu. 
Antigamente, quando boa parte dos enlaces era de baixa qualidade e expunha os sinais à 
ação intensa das diversas fontes de distorção presentes no meio físico, era difícil saber o 
real motivo daquela perda. Hoje, a maioria das linhas de longa distância é de fibras ópticas, 
em que são raros descartes por conta de ruídos ou interferências. Assim, caso não aconteça 
a chegada de um segmento que uma entidade de transporte está esperando, ela atribuirá, 
automaticamente, este fato à ocorrência de um congestionamento em algum ponto da rede.
Para colaborar com a prevenção de congestionamentos, o TCP precisa, antes de 
qualquer coisa, respeitar a janela do receptor (isso tem a ver com o controle do fluxo). No 
entanto, mesmo que o fluxo esteja sob controle, a rede pode não comportar a taxa em 
que transmissor e receptor desejam trocar segmentos. Por conta disso, cada transmissor 
deve manter duas janelas: a própria janela do receptor e a janela de congestionamento, 
e fazer um nivelamento por baixo, isto é, transmitir rajadas de dados segundo a menor 
dessas janelas. O tamanho da janela de congestionamento começa a ser definido logo 
após o estabelecimento de uma conexão, sendo ajustado, inicialmente, ao tamanho 
do segmento máximo acordado entre as duas entidades. Se um segmento de tamanho 
máximo for transmitido e sua confirmação retornar antes de uma temporização, a janela 
de congestionamento será reajustada, passando a ter o dobro do tamanho anterior. É 
como se a entidade de transporte pensasse: “já que a rede está suportando, vou injetar 
segmentos maiores...” Esse processo de sucessivos incrementos no tamanho da janela de 
congestionamento persiste até que um segmento enviado sofra uma temporização. Se 
isso acontecer, o algoritmo recuará, reatribuindo à janela de congestionamento o último 
valor com o qual se conseguiu uma transmissão bem sucedida. O procedimento descrito é 
denominado algoritmo de Jacobson ou algoritmo de inicialização lenta (perceba que não há 
nada de lento no algoritmo, já que ele é exponencial!).
Na Internet, para que o controle de congestionamento funcione efetivamente, 
é necessário considerar um parâmetro adicional ao algoritmo apresentado, o limiar, 
que é inicialmente igual a 64KB. O algoritmo de Jacobson, para incremento da janela de 
congestionamento, continua funcionando normalmente. A diferença é que, quando o 
limiar é alcançado, o incremento da janela de congestionamento deixa de ser exponencial 
para se tornar linear; a cada nova confirmação recebida com sucesso, o tamanho da 
janela de congestionamento, em vez de dobrar, é incrementado de um número de bytes 
correspondente ao tamanho do segmento máximo acordado no estabelecimento da 
conexão. Quando uma temporização acontece, o limiar é redefinido para a metade do 
tamanho da janela de congestionamento em que a temporização ocorreu e o algoritmo de 
Jacobson volta para o começo. Essa descrição é ilustrada na Figura 1.8. 
É claro que qualquer alteração na janela de congestionamento deve respeitar 
a janela do receptor. Quando o tamanho da janela do receptor é alcançado, a janela de 
congestionamento para de crescer e permanece constante desde que não ocorra outra 
temporização e desde que a janela do receptor não mude de tamanho por algum outro 
motivo.
20
Redes de Computadores
Figura 1.8 – Funcionamento do algoritmo de controle de congestionamento na Internet
1.4.5 Temporizadores no TCP
Você já deve ter percebido que os temporizadores possuem uma importância 
essencial no bom funcionamento do TCP. Constantemente, temos mencionado a ocorrência 
de temporizações como um fator determinante para que alguma providência seja 
tomada na camada de transporte. O principal temporizador do TCP é o temporizador de 
retransmissão, que consiste no tempo em que um transmissor aguarda o retorno de uma 
confirmação antes de retransmitir o respectivo segmento. Bom, esse processo de esperar 
e decidir sobre uma retransmissão é bem simples de entender... mas você já parou para 
pensar sobre quanto tempo o transmissor deve ficar esperando? Definitivamente, essa não 
é uma questão simples. Se este tempo for superdimensionado, o transmissor pode estar 
esperando desnecessariamente por uma confirmação que nunca vai chegar, o que gera 
atraso na transmissão dos dados; por outro lado, se este tempo for subdimensionado, o 
transmissor pode realizar uma retransmissão desnecessária (imagine que a confirmação 
ainda não tinha chegado, mas já estava a caminho...), gerando um tráfego adicional e 
contribuindo para a sobrecarga da rede.
Na camada de transporte, a obtenção do tempo “ótimo” de espera por uma 
confirmação requer algumas consideraçõs. Como a comunicação é fim a fim, esse tempo 
precisa ser, de certo modo, adaptativo; o tempo para que uma confirmação vinda de umamáquina que se encontra do outro lado do mundo retorne ao transmissor será, certamente, 
bem maior que aquele necessário à chegada de uma confirmação vinda de um computador 
que se encontra na sala ao lado (já falamos sobre isso antes). Consequentemente, os 
temporizadores precisarão ter um pouco mais de paciência no primeiro caso. O algoritmo 
que materializa esse raciocínio foi desenvolvido por Jacobson, em 1988. Para cada conexão, 
o TCP mantém um parâmetro denotado por RTT (round-trip time), que corresponde a 
melhor estimativa que, em determinado instante, se tem para o tempo de ida e volta até 
o destino em questão. Quando um segmento TCP é enviado, um cronômetro é acionado. 
Imaginando que a confirmação retorne após M unidades de tempo, o RTT é atualizado 
segundo a expressão
21
Redes de Computadores
RTT = α.RTT + (1 – α).M,
Em que α é uma constante de suavização que representa o peso dado ao antigo 
valor (usualmente, tem-se α = 7/8). Além disso, o algoritmo requer outra variável de 
suavização, D, o desvio, que é atualizado conforme a expressão
D = α.D + (1 – α).|RTT – M|;
O valor de α não precisa ser o mesmo utilizado na atualização de RTT. D corresponde 
a uma estimativa para o desvio-padrão de RTT. Finalmente, calcula-se o valor do tempo para 
temporização de retransmissão por
Tr = RTT + 4.D.
Em casos em que uma retransmissão precise ser realizada, poderia ainda acontecer 
de o transmissor, ao receber uma confirmação, ficar confuso. A confirmação recebida 
seria referente ao segmento mais antigo (que o transmissor julgara perdido) ou à sua 
retransmissão? Para contornar esta falha, o TCP emprega o algoritmo de Karn. Quando uma 
retransmissão acontece, em vez de se calcular um novo RTT e atualizar o valor de Tr, este 
último parâmetro é recursivamente multiplicado por dois, à espera que o segmento chegue 
ao seu destino pela primeira vez.
No TCP, há outros temporizadores. Um deles é o temporizador de persistência. 
Quando a janela do receptor é completamente preenchida, conforme já vimos, ele envia 
ao transmissor um segmento com o campo janela igual a 0 (zero). O transmissor se 
colocará, então, à espera de uma atualização e, simultaneamente, ativará o temporizador 
de persistência. Quando for liberado um espaço na janela do receptor, isso será informado 
ao transmissor. Contudo, essa informação pode se perder no caminho. Diante disso, em vez 
de ficar esperando “eternamente”, o transmissor pode, decorrido o tempo do temporizador 
de persistência, perguntar ao receptor sobre alguma alteração em sua janela e reiniciar a 
transmissão dos dados.
Outro temporizador é o de keepalive. Ele é utilizadao quando a troca de dados entre 
dois lados de uma conexão é cessada por um certo tempo. Decorrido o tempo definido pelo 
temporizador, uma das entidades pode enviar ao outro lado uma mensagem que representa 
algo como “você ainda está aí ou desligou sem que eu soubesse?” Se não houver resposta, 
a conexão é simplesmente encerrada. Há outro temporizador relacionado ao encerramento 
de conexões. Após a decisão de se encerrar uma conexão, esse temporizador corresponde 
a um tempo de espera igual a duas vezes a duração máxima dos pacotes para garantir que, 
quando uma conexão for fechada, todos os pacotes criados por ela serão extintos.
1.5 TCP e UDP: Tópicos Adicionais
Nesta seção, abordaremos alguns tópicos adicionais envolvendo o TCP e o UDP. 
Iniciaremos com algumas aplicações relacionadas ao UDP, a saber, a RPC (Remote Procedure 
Call, chamada de procedimento remoto) e o RTP (Real-time Transport Protocol, protocolo 
de transporte de tempo real), e, em seguida, levantaremos alguns aspectos sobre a camada 
de transporte em redes sem fio e sobre questões de desempenho.
1.5.1 Chamada de procedimento remoto
Em alguns tópicos estudados nesta disciplina, temos recorrido a situações em que 
um cliente envia uma mensagem de solicitação a um servidor, o servidor responde com 
uma mensagem de resposta, e o cliente bloqueia (suspende a execução) esperando essa 
22
Redes de Computadores
resposta. Esse é o chamado paradigma de solicitação/resposta, largamente empregado 
pelos programas de aplicação. Uma chamada de procedimento remoto (RPC) é um 
mecanismo que funciona de forma semelhante ao paradigma descrito, mas que realiza uma 
chamada a um procedimento (uma espécie de solicitação) sem considerar se ele é local 
ou remoto. O motivo de se tratar deste assunto aqui é que, embora uma RPC possa existir 
independentemente dos protocolos usuais da camada de transporte, ela se adapta muito 
bem ao UDP, o qual pode ser responsável por “levar” a solicitação do cliente ao servidor e 
trazer de volta a resposta.
Quando se deseja implementar uma RPC, duas questões principais precisam 
ser levadas em consideração. Em primeiro lugar, a complexidade da rede existente entre 
as máquinas em que se encontram o processo chamado e o chamador é bem maior que 
aquela interna aos computadores (fazer uma chamada local seria bem mais fácil). Depois, as 
máquinas que desejam se comunicar podem ter arquiteturas e formatos de representação 
de dados significativamente diferentes. Em suma, para facilitar o seu funcionamento, uma 
RPC pode tentar fazer com que a chamada remota se pareça o máximo possível com uma 
chamada local. Isso é conseguido por meio de um pequeno procedimento de biblioteca 
chamado stub. De um lado, o programa cliente deve estar vinculado a um stub do cliente, 
que represente o procedimento do servidor no espaço de endereços do cliente; do lado do 
servidor, algo semelhante é necessário (veja a Figura 1.9).
Figura 1.9 – Etapas na criação de uma chamada de procedimento remoto
Primeiro, o cliente faz uma chamada ao seu stub, o que corresponde a uma chamada 
local. Em seguida, o stub reune os parâmetros em uma mensagem (empacotamento) e 
efetua uma chamda de sistema para enviar a mensagem. Depois, o núcleo (kernel) envia a 
mensagem da máquina cliente até a máquina servidora. Do lado do servidor, a mensagem é 
recebida seguindo, em ordem reversa, os passos descritos. O envio da resposta é realizada 
de maneira semelhante. Esta técnica pode ser empregada numa série de aplicações, como, 
por exemplo, no serviço desempenhado pelo DNS. Conforme estudamos, o DNS envolve 
basicamente o envio de parâmetros e uma resposta obtida em função dos parâmetros 
recebidos.
1.5.2 RTP – Protocolo de transporte de tempo real
Uma área em que o UDP é amplamente utilizado é a de multimídia em tempo 
real. Nesse contexto, estão envolvidas aplicações como o rádio e a telefonia pela Internet, 
a música e o vídeo sob demanda e a realização de videoconferências. O protocolo de 
transporte de tempo real (RTP) surgiu como uma solução que pudesse se adequar ao 
23
Redes de Computadores
transporte de aplicações como essas. Na pilha de protocolos, o RTP se encontra no espaço 
do usuário (juntamente com a aplicação) e oferece uma espécie de biblioteca em que os 
diversos fluxos de multimídia podem ser armazenados (observe a Figura 1.10). Por outro 
lado, o RTP é genérico e independe das aplicações, o que é característico de um protocolo de 
transporte. É como se ele fosse um protocolo meio “híbrido”, entre a camada de transporte 
e a de aplicação.
Figura 1.10 – (a) A posição do RTP na pilha de protocolos. (b) Encapsulamento
Basicamente, o RTP serve para multiplexar diversos fluxos de dados de tempo real 
num único fluxo de pacotes UDP. Sobre a forma como esses dados serão transportados, não 
se fornece nenhuma informação adicional (a não ser em casos excepcionais). Isso significa 
que todas as características do UDP são preservadas, como as ausências de controle de 
fluxo, de erros, confirmações e retransmisssões. Conforme sugerimos em abordagens 
anteriores, normalmente, essa estratégia é aceitável quando se trata de multimídia. O que 
se faz é numerar de forma ordenada os pacotes enviados para que o receptor saiba se algum 
deles está faltando. Caso isso aconteça, o próprio receptor pode tomar alguma providência.No caso de um vídeo, por exemplo, é natural que cada quadro possua uma alta correlação 
com seus quadros adjacentes. Assim, é possível estimar quadros ausentes por meio de 
técnicas de interpolação. Quando isso não é possível, um quadro pode simplesmente não 
ser exibido. Talvez nem notássemos a ausência de um ou outro quadro dentre os 25 ou 30 
que assistimos a cada segundo; pirivilegiaríamos a questão do tempo real.
No cabeçalho do RTP, há um campo para que a codificação de fonte utilizada nos 
dados da carga útil seja especificada. Isso é essencial, pois, ao chegarem ao receptor, os 
dados só poderão ser exibidos corretamente se o decodificador apropriado estiver presente. 
O RTP também possui um campo para o timbre de hora, a fim de reduzir a flutuação (jitter) 
e sincronizar fluxos com origens distintas. Em conjunto com o RTP, trabalha o RTCP (Real-
time Transport Control Protocol, protocolo de controle de transporte de tempo real), que 
se responsabiliza pelo feedback (informações sobre largura de banda, retardo, flutuação, 
congestionamento etc), pela sincronizaçao e pela interface com o usuário.
Você Sabia?
Um CODEC é um programa que permite compactar e descompactar dados digitais? Os dados 
em questão podem conter informações de áudio, de vídeo ou imagens. Normalmente, as 
técnicas utilizadas nos CODECs resultam em perda de informação, comprometendo um pouco a 
qualidade do que se vê ou se escuta (você percebe que a qualidade de algumas imagens salvas 
no formato JPG é muito pior que a qualidade de imagens em BMP?). Por outro lado, o uso de um 
CODEC diminui bastante o tamanho de um arquivo multimídia, facilitando o seu armazenamento 
e a permitindo transmissões mais rápidas.
24
Redes de Computadores
1.5.3 TCP e UDP sem fio
Quando estudamos o controle de congestionamento na camada de transporte, 
afirmamos que uma premissa normalmente adotada é a de que os enlaces atuais para 
transmissão de dados são de boa qualidade, sendo implementados sobre fibras ópticas ou 
sendo curtos o suficiente para evitar que as fontes de distorção presentes no meio físico 
degradem os sinais que ali trafegam. Entretanto, se uma camada de transporte tiver que 
“atravessar” trechos de uma rede sem fios, a coisa muda bastante de figura. Em casos como 
esse, quando uma entidade TCP envia um segmento, se a confirmação não retornar em 
tempo hábil, haverá uma grande chance de que isso tenha acontecido por conta da falta de 
confiabilidade do meio não-guiado; não se terá mais tanta certeza de que este fenônemo foi 
provocado por um congestionamento...
A estratégia básica para lidar com esse problema consiste em mudar radicalmente 
a maneira de agir diante de uma perda. Em redes cabeadas, quando acontece uma 
temporização, os transmissores diminuem o seu ritmo, à espera que a rede se recupere 
e retome o fôlego gradativamente. Em redes sem fio, quando uma confirmação não 
chega, o transmissor deve tentar reenviar o segmento o mais rápido possível. É como se o 
transmissor concluísse: “já que o meio físico à minha disposição é ruim e os segmentos se 
perdem o tempo todo, vou mandar o máximo de segmentos possível para ver se algum deles 
chega!” O fato é que a maioria das redes é heterogênea, isto é, parte é implementada sobre 
meios guiados (normalmente o backbone) e outra parte pode ser implementada sem fios 
(normalmente, a “última milha”). Uma solução para isso é dividir o caminho a ser percorrido 
em duas partes. Essa técnica é denominada TCP indireto e é apresentada na Figura 1.11.
Figura 1.11 – Divisão da conexão TCP em duas conexões 
Na primeira parte, é estabelecida a conexão TCP #1, que funciona como um TCP 
sobre redes cabeadas. É como se seu destino final fosse a estação-base. No segundo trecho, 
sem fios, estabelece-se a conexão TCP #2, que adota a estratégia descrita para a injeção 
de segmentos na rede. A dificuldade é que, quando o transmissor receber as confirmações 
de entrega, elas significarão que os segmentos chegaram à estaçao-base e não à estação 
móvel, a qual representa, de fato, o destino final dos dados. Isso pode gerar confusão. Além 
do mais, a divisão do que deveria ser uma só conexão em duas partes viola a semântica do 
TCP.
Uma solução para isso consiste em permanecer com apenas uma conexão 
de transporte e realizar modificações no código da camada de rede da estação-base. 
Resumidamente, o que se faz é instalar uma espécie de espião na estação-base, capaz de 
monitorar o que é enviado e recebido pelo enlace sem fio. Os segmentos enviados para 
a estação móvel ficam guardados na estação-base e quando o espião percebe que um 
deles não foi confirmado, ele mesmo se encarrega de reenviar, sem comunicar nada ao 
transmissor. A desvantagem é que o transmissor pode sofrer uma temporização, se muitas 
tentativas tiverem que ser feitas para entregar um segmento à estação móvel.
25
Redes de Computadores
No caso do UDP, um ambiente sem fios também pode trazer alguns problemas. Por 
mais que as aplicações saibam que o UDP não é confiável, elas esperam que ele ofereça 
o mínimo de desempenho neste sentido. Quando acontece uma mudança repentina no 
cenário da rede, o efeito sobre essas aplicações pode ser bastante danoso. É como se 
deixássemos de perder um ou outro quadro de um vídeo e passássemos a perder uma 
série de quadros em sequência e, mesmo que pudéssemos esperar por uma retransmissão, 
não tivéssemos como solicitá-la. Com o ganho de popularidade das redes sem fio, novas 
estratégias têm sido desenvolvidas para lidar com situações como essa.
Aprenda Praticando 
Agora é chegada a hora de você praticar os conceitos aprendidos. Para isso, alguns 
exercícios foram selecionados para você avaliar seu entendimento do nosso primeiro 
capítulo. Você deverá procurar entender os exercícios resolvidos e suas respectivas 
respostas com o intuito de consolidar os conceitos aprendidos neste capítulo. 
Algumas questões dos exercícios propostos fazem parte das atividades somativas 
que você deverá responder em relação ao capítulo 1, do Volume 2, de acordo com as 
orientações e prazos sugeridos pelo seu professor e tutor. 
Lista de exercícios propostos
1. O que você mencionaria como principais funcionalidades da camada de transporte?
2. O handshake de três vias é um procedimento básico no estabelecimento de uma 
conexão na camada de transporte. Caso não efetuássemos o último passo desse 
procedimento, faria alguma diferença? A conexão seria estabelecida normalmente 
em qualquer situação ou algum impasse poderia ser gerado?
3. Suponha que um processo no computador C possua um socket UDP com númer 
de porta 6790 e que o computador A e o computador B, individualmente, enviem 
um segmento UDP ao computador C com número de porta de destino 6790. Esses 
dois segmentos serão encaminhados para o mesmo socket no computador C? Se 
sim, como o processo no computador C saberá que esses dois segmentos vieram de 
duas máquinas diferentes?
4. Por que o UDP existe? Não seria suficiente deixar que os processos dos usuários 
enviassem pacotes IP brutos?
5. Por que o tráfego de voz e de vídeo é frequentemente enviado por meio do UDP e 
não do TCP na Internet de hoje?
6. Numa conexão TCP, um transmissor que recebe o anúncio de uma janela igual a 0 
(zero) sonda o receptor periodicamente para descobrir quando a janela se torna 
diferente de 0. Por que o receptor precisaria de um temporizador extra se ele fosse 
responsável por informar que sua janela anunciada se tornou maior que 0 (ou seja, 
se o transmissor não sondasse)?
7. Apresente uma desvantagem potencial do uso do algoritmo de Nagle numa rede 
muito congestionada.
8. Descreva um cenário em que pode acontecer a chamada síndrome da janela boba.
9. Suponha que um host queira medir a confiabilidade de um enlace enviando pacotes 
e medindo a porcentagem dos que são recebidos (os roteadores, por exemplo, 
fazem isso); Explique a possibilidade de se fazer isso por uma conexão TCP.
26
Redes de Computadores
10. Suponha que a janela de congestionamentodo TCP seja definida como 36 KB e que 
ocorra uma temporização. Qual será o tamanho da janela se as próximas quatro 
rajadas de transmissão forem bem sucedidas? Suponha que o tamanho máximo do 
segmento seja 2 KB.
11. Os hosts A e B estão se comunicando por meio de uma conexao TCP, e o host B já 
recebeu de A todos os bytes até o byte 126. Suponha que o host A envie, então, 
dois segmentos para o host B sucessivamente. O primeiro e o segundo segmentos 
contêm 70 e 50 bytes de dados, respectivamente. No primeiro segmento, o número 
de sequência é 127, o número de porta de origem é 302, e o número de porta de 
destino é 80. O host B envia uma confirmação ao receber um segmento do host A.
a. No segundo segmento enviado do host A para B, quais são o número de 
sequência, a porta de origem e a porta de destino?
b. Se o primeiro segmento chegar antes do segundo, na confirmação do primeiro 
segmento que chegar, qual é o número de confirmação, da porta de origem e 
da porta de destino?
c. Se o segundo segmento chegar antes do primeiro, na confirmação do primeiro 
segmento que chegar, qual é o número de confirmação?
d. Suponha que dois segmentos enviados por A cheguem em ordem a B. A 
primeira confirmação é perdida e a segunda chega após o primeiro intervalo 
de temporização. Elabore um diagrama de temporização mostrando esses 
segmentos, e todos os outros, e as confirmações enviadas (assuma que não 
há outras perdas de pacotes). Para cada segmento de seu desenho, apresente 
o número de sequência e o número de bytes de dados; para cada confirmação 
adicionada por você, apresente o número de confirmação.
12. Se o tempo de viagem de ida e volta no TCP, denominado RTT, for igual a 20 ms, e 
se as confirmações seguintes chegarem depois de 26, 32 e 24 ms, respectivamente, 
qual será a nova estimativa para RTT empregando-se o algoritmo de Jacobson? 
Considere α = 0,9.
13. Por que o UDP se adequa tão bem ao transporte de uma RCP (chamda de 
procedimento remoto)?
14. Se perguntássemos em que camada da pilha de protocolos se encontra o RTP 
(protocolo de transporte de tempo real), o que você responderia?
15. Explique o motivo pelo qual se diz que o TCP indireto, utilizado em redes sem fio, 
viola a semântica do TCP.
Conheça Mais
Caro(a) aluno(a), ao longo do nosso estudo, você deve ter percebido que 
os protocolos da camada de transporte são de essencial importância para o bom 
funcionamento de uma rede de computadores. Eles estão presentes em diversos cenários e, 
idealmente, precisam se comportar bem, independentemente da estrutura de rede sobre a 
qual são implementados. Hoje, o interesse pelas redes sem fio é bastante grande, por conta 
da mobilidade e da facilidade de instalação que elas provêem. Nesse contexto, encontra-se 
uma tecnologia denominada WiMAX, que é, basicamente, uma rede sem fio metropolitana e 
de banda larga. Nos links a seguir, você vai encontrar o vídeo de uma apresentação intitulada 
27
Redes de Computadores
Análise de Desempenho do TCP sobre Redes WiMAX, realizada em 2008, na 25ª reunião 
do Grupo de Trabalho de Engenharia e Operação de Redes, GTER (http://gter.nic.br). Está 
disponível, também, a apresentação em .pdf utilizada na palestra. Apesar de a apresentação 
discutir alguns pontos que, talvez, você ainda não conheça, procure identificar, ao longo do 
vídeo, pontos que você estudou so longo deste capítulo e perceba a aplicabilidade prática 
de cada conceito aprendido.
 Vídeo: ftp://ftp.registro.br/pub/gter/gter25/videos/mp4/gter-07-desempenho-tcp-wimax.
mp4
 Arquivo em .pdf: ftp://ftp.registro.br/pub/gter/gter25/07-desempenho-tcp-wimax.pdf
Atividades e Orientações de Estudos
Dedique, pelo menos, 10 horas de estudo para o Capítulo 1. Você deve organizar 
uma metodologia de estudo que envolva a leitura dos conceitos apresentados e pesquisas 
sobre o tema, usando a Internet e livros de referência. 
Vamos trocar idéias nos fóruns temáticos desta disciplina no ambiente virtual, 
pois a interação com colegas, tutores e o professor da disciplina irá ajudá-lo a refletir sobre 
aspectos fundamentais tratados aqui. Os chats também serão muito importantes para a 
interação em tempo real com o seu tutor virtual, seu professor e seus colegas.
Também é importante que você leia atentamente o guia de estudo da disciplina, 
pois nele você encontrará a divisão de conteúdo semanal, ajudando-o a dividir e administrar 
o seu tempo de estudo semanal. Procure responder as atividades propostas como atividades 
somativas para este capítulo, dentro dos prazos estabelecidos pelo seu professor, pois você 
não será avaliado apenas pelas atividades presenciais, mas também pelas virtuais. Muitos 
alunos não acessam o ambiente e isso poderá comprometer a nota final. Não deixe que isso 
aconteça com você!
Os assuntos abordados neste capítulo podem ser encontrados no Quiz de número 1 
da disciplina de Redes de Computadores. Através do Quiz você poderá avaliar o seu próprio 
desempenho. Após respondê-lo, você terá o resultado de seu desempenho e conhecerá as 
suas deficiências, podendo supri-las nas suas próximas horas de estudo. 
Vamos Revisar?
Neste capítulo, você estudou definições e conceitos relacionados à camada de 
transporte. Dentro da abordagem que temos desenvolvido, percebemos que a camada de 
transporte é essencial para que cada processo de aplicação envie e receba dados da maneira 
adequada. Já pensou se um e-mail enviado por você aparecesse na tela do computador de 
destino quando o usuário estivesse solicitando uma página da Internet!? A grosso modo, é 
esse “confusão” entre as aplicações que a camada de transporte ajuda a evitar.
Aprendemos que os principais protocolos da camada de transporte na Internet são 
o TCP e o UDP. O primeiro tem como responsabilidade principal cobrir certas “brechas” 
deixadas pela rede. Quando enviamos dados a outro computador, queremos ter a certeza 
de que eles chegaram no destino, de que a máquina remota os aceitou e de que eles foram 
28
Redes de Computadores
entregues em ordem ao respectivo processo de aplicação. São coisas desse tipo que o TCP 
garante, por meio de mecanismos baseados em números de sequência e confirmação e 
utilizando controle de fluxo e de congestionamento.
O UDP, por sua vez, encontra aplicabilidade em cenários em que uma perda, talvez, 
não faça tanta diferença. Nesse contexto, enquadram-se os serviços multimídia e aqueles 
baseados em solicitação/resposta. No caso de voz ou vídeo pela Internet, dependendo 
do CODEC utilizado, quadros ou pacotes perdidos podem ser estimados via interpolação; 
no caso de um pedido a um servidor, se uma resposta não acontece, o pedido pode ser 
simplesmente enviado outra vez. TCP e UDP, cada um com sua importância, continuam 
fazendo parte da “coração” das redes de computadores, adaptando-se aos novos cenários 
e trabalhando em conjunto com as tecnologias emergentes. No próximo capítulo, 
estudaremos a camada de rede e comprenderemos melhor sua relação com o que já 
aprendemos até agora.
29
Redes de Computadores
Capítulo 2 – A Camada de Rede e o 
Protocolo IP
Vamos conversar sobre o assunto?
Caro(a) aluno(a),
Durante a nossa abordagem sobre a camada de transporte, muitas vezes, fizemos 
questão de enfatizar que “os protocolos da camada de transporte devem funcionar bem, 
independentemente do que aconteça na rede”. Mas o que, de fato, pode estar acontecendo 
na rede? Que rede é essa e quais são as suas atribuições? É isso que começaremos a 
esclarecer neste capítulo, quando realizaremos nosso estudo sobre a camada de rede, 
localizada imediatamente abaixo da camada de transporte.
Diferentemente da camada de transporte, a camada de rede não é uma camada 
fim a fim; suas partes, além de serem implementadas nos sistemas finais (hosts), aparecem 
também nos roteadores, os “caras” que dizem o caminho que os dados devem seguir para 
chegar ao destino. Você já deve estar imaginando a trabalheira que essa camada deve ter... 
para que tudo dê certo, ela vai precisar recorrer a esquemasde endereçamento diferentes 
daquele usado na camada de transporte. Antes, o objetivo era entregar os dados (já 
recebidos por um host) aos processos de aplicação corretos (pra isso, usamos a ideia de 
portas, lembram?); agora, queremos levar os dados de um computador a outro que pode 
estar do outro lado do mundo!
Na camada de rede, falaremos bastante sobre roteamento e discutiremos os 
algoritmos responsáveis por essa tarefa. Veremos que, para que tudo funcione bem, a rede 
deve estar organizada de uma forma hierárquica e que, em níveis diferentes, algoritmos 
diferentes devem ser empregados. De uma maneira mais específica, estudaremos aspectos 
relacionados à camada de rede na Internet. Falaremos sobre o famoso protocolo IP 
(Internet Protocol), a tradução de endereço de rede (NAT, Network Address Translation), a 
fragmentação de datagramas e o protocolo de mensagem de controle da Internet (ICMP, 
Internet Control Message Protocol). Além disso, abordaremos os principais aspectos do IPv6. 
Antes de tudo isso, porém, inciemos com uma seção introdutória em que aprenderemos 
conceitos básicos, como os que permitem diferenciarmos redes baseadas em datagramas 
daquelas baseadas em circuitos virtuiais e conhecermos a arquitetura básica de um roteador 
bem como suas principais funções.
2.1 Introdução
Nesta seção, discutiremos alguns conceitos importantes para darmos sequência ao 
nosso estudo. Em primeiro lugar, precisamos entender qual é, basicamente, a função da 
camada de rede no que diz respeito à sua interação com as demais camadas. Já sabemos 
que, num host, os processos de aplicação entregam os dados a serem enviados à camada de 
transporte que, por sua vez, os coloca em segmentos de protocolos como o TCP e o UDP. Os 
segmentos de transporte são, então, entregues às camadas inferiores e adentram no enlace 
por meio do qual serão transmitidos.
30
Redes de Computadores
Quando alcançam um roteador, os dados precisam saber para onde vão; um 
roteador possui várias linhas de entrada e várias linhas de saída. O roteador, então, retira os 
dados do enlace pelo qual os recebeu e utiliza um algoritmo de roteamento, para determinar 
para que linha de saída os dados devem ser repassados. O repasse propriamente dito dos 
dados é realizado conforme tabelas que são mantidas pelos roteadores. Para realizar essa 
tarefa, o roteador precisa implementar até a camada de rede (veremos que é no cabeçalho 
do protocolo utilizado na camada de rede que se encontra o endereço final dos dados); por 
motivos óbvios, ele não precisa implementar a camada de transporte e menos ainda a de 
aplicação. Esse procedimento é ilustrado na Figura 2.1.
Figura 2.1 – A camada de rede
Podemos falar um pouco mais sobre as tabelas de repasse... Como dissemos, no 
cabeçalho do protocolo da camada de rede, encontra-se um endereço ou alguma outra 
informação sobre o destino que os dados precisam alcançar. A tabela consiste, basicamente, 
em duas colunas, relacionando destinos a serem alcançados com linhas de saída do roteador. 
Recebido um datagrama, basta que se verifique seu destino e se procure na tabela a linha 
de saída que deve ser usada. A montagem das tabelas é feita com base nos algoritmos de 
roteamento, que podem ser centralizados, descentralizados, estáticos, dinâmicos. Como 
regra geral, um algoritmo de roteamento tentará, respeitando certas restrições, fazer com 
que um datagrama percorra o caminho com menor custo possível (veremos que o que se 
entende por custo pode envolver muita variáveis...). Em alguns casos, a determinação desse 
caminho pode envolver o estabelecimento de conexões. Isso mesmo! Como na camada de 
transporte... no entanto, no presente contexto, isso tem uma finalidades bem específicas 
como a reserva de recursos e o estabelecimento de prioridades.
Outro conceito a ser discutido nesta introdução é o que chamamos de modelo de 
serviço de rede, que define tipos de serviços que a camada de rede poderia oferecer para 
o transporte dos dados (isso não significa que a camada de transporte pode “relaxar” e 
confiar plenamente na camada de rede). Entre esses serviços se encontram:
» Entrega garantida: assegura que o pacote chegará ao seu destino 
(independentemente do atraso que venha sofrer);
» Entrega garantida com atraso limitado: incrementa o serviço descrito acima, 
estabelecendo limites de atraso.
Entre os serviços que se prestam a um fluxo de pacotes entre uma fonte e um 
destino determinados, podemos destacar a (i) entrega de pacotes na ordem, (ii) a garantia 
de uma largura de banda mínima, (iii) a garantia de um jitter máximo (jitter corresponde 
a uma medida de variabilidade dos atrasos sofridos pelos pacotes) e (iv) os serviços de 
segurança. Na prática, diversas variações dos exemplos citados são possíveis. Quando 
se trata de Internet, entretanto, o modelo de serviço oferecido se resume ao de melhor 
esforço. Com ele, não há garantias de entrega em ordem e nem mesmo garantias de entrega 
(mesmo que fora de ordem). Mais tarde, veremos que isso não significa que a camada de 
rede não desempenhe bem as suas responsabilidades.
Noutras arquiteturas de rede, há serviços que vão além do serviço de melhor 
31
Redes de Computadores
esforço oferecido pela Internet. Um bom exemplo disso acontece nas redes ATM, que 
oferece as chamadas classes de serviço. Entre essas classes, encontra-se a de taxa constante 
de bits, que é voltada à transmissão de pacotes que “carregam” voz, por exemplo. É como 
se a rede tentasse imitar uma comutação por circuitos, que é usada no sistema telefônico 
convencional; outra classe é a de taxa variável de bits, que se aplica, por exemplo, à 
transmissão de vídeo (diferentes quadros de um mesmo vídeo podem ser compactados a 
taxas diferentes); tem-se, ainda, o serviço de rede de taxa de bits disponível, que pode ser 
caracterizado como um serviço de melhor esforço ligeiramente incrementado.
2.1.1 Redes de circuitos virtuais e de datagramas
Durante os nossos estudos do capítulo 1, vimos que a camada de transporte é 
capaz de oferecer serviços orientados a conexão e serviços não orientados a conexão. A 
camada de rede também contempla ambas as possibilidades, introduzindo, naturalmente, 
algumas mudanças na maneira em que esses serviços são oferecidos. Já dissemos que a 
implementação de um serviço orientado a conexão, na camada de transporte, ocorre 
na borda da rede; na camada de rede, essa responsabilidade é fundamentalmente dos 
roteadores. Além disso, a comunicação na camada de rede é entre hosts apenas, não 
havendo qualquer relação com os processos de aplicação, como ocorre na camada de 
transporte. Quando quisermos nos referir a redes que oferecem um serviço orientado a 
conexão, utilizaremos a terminologia redes de circuitos virtuais (redes CV); quando nos 
referirmos a redes que oferecem um serviço não orientado a conexão, empregaremos o 
termo redes de datagramas.
Muitas arquiteturas de redes alternativas, como ATM e Frame Relay, se baseiam 
em circuitos virtuais. Um circuito virtual consiste, basicamente, num caminho entre hosts de 
origem e de destino; uma espécie de sequência de saltos desde o host de origem, passando 
por diversos roteadores, até alcançar o host de destino. Um pacote que precise ser 
encaminhado ao longo de uma rede dessas deve ser marcado com um número de circuito 
virtual, para que, com o auxílio de tabelas de repasse, os roteadores possam encaminhá-lo. 
O principal objetivo dessa estratégia é evitar a necessidade de escolher uma nova rota para 
cada pacote enviado. No momento em que uma conexão é estabelecida, escolhe-se uma 
rota desde o host de origem até o de destino, a qual é armazenada e utilizada por todo o 
tráfego que flui pela conexão.
Numa rede de datagramas, sempre que um sistema final quer enviar um pacote, ele 
“escreve” no pacote o endereço do destino que se deseja alcançar e o envia para dentro da 
rede. Isso é o que faz, por exemplo, a Intenet! Como nenhum circuito virtual é estabelecido, 
os roteadores não têm