Camada de Transporte e suas funções

CISCO Accessible Theme Página 1 de 21

Mudar idioma para English | Busca | Glossário

Índice do Curso:
4 Camada de Transporte OSI Selecione

CCNA Exploration - Fundamentos de Rede
4 Camada de Transporte OSI
4.0 Introdução ao Capítulo
4.0.1 Introdução ao Capítulo

Página 1:
As redes de dados e a Internet suportam a rede humana através do fornecimento de
comunicação contínua e confiável entre pessoas localmente e ao redor do mundo. Através de um
simples dispositivo, as pessoas podem usar múltiplos serviços como e-mail, web e mensagens
instantâneas para enviar mensagens ou recuperar informação. Aplicações como clientes de e-
mail, navegadores e clientes de envio de mensagem instantânea permitem às pessoas usarem
os computadores e redes para enviar mensagens e encontrar informação.

Dados de cada uma dessas aplicações são empacotadas, transportadas e entregues ao servidor
daemon apropriado ou aplicação no dispositivo de destino. Os processos descritos na camada de
Transporte do modelo OSI aceitam dados da Camada de Aplicação e os preparam para
endereçamento na camada de Rede. A camada de Transporte é responsável pela transferência
fim-a-fim geral de dados de aplicação.

Neste capítulo, nós examinaremos o papel da camada de Transporte no encapsulamento de
dados de aplicação para uso pela camada de Rede. A camada de Transporte também abrange
estas funções:

z Habilita a comunicação de múltiplas aplicações na rede ao mesmo tempo em um único
dispositivo
z Assegura que, se necessário, todos os dados sejam recebidos confiavelmente e em ordem
pela aplicação correta.
z Emprega mecanismos de tratamento de erros

Objetivos

Após o término deste capítulo, você será capaz de:

z Explicar a necessidade da camada de Transporte.
z Identificar o papel da camada de Transporte, visto que, ela proporciona a transferência fim-
a-fim de dados entre aplicações.
z Descrever o papel de dois protocolos TCP/IP da camada de Transporte: TCP e UDP.
z Explicar as funções principais da camada de Transporte, incluindo confiabilidade,
endereçamento de porta e segmentação.
z Explicar como o TCP e o UDP gerenciam funções-chave.
z Identificar quando é apropriado usar o TCP ou o UDP e apresentar exemplos de aplicações
que usam cada um desses protocolos.

Mostrar mídia visual

4.1 Funções da Camada de Transporte
4.1.1 Propósito da Camada de Transporte

Página 1:
A camada de Transporte proporciona a segmentação de dados e o controle necessário para

http://curriculum.netacad.net/virtuoso/servlet/org.cli.delivery.rendering.servlet.CCSer... 06/10/2011


reagrupar esses segmentos em fluxos de comunicação. Suas responsabilidades primárias para
realizar isto são:

z Rastrear a comunicação individual entre as aplicações nos hosts de origem e destino.
z Segmentar dados e gerenciar cada segmento
z Reagrupar os segmentos em fluxos de dados de aplicação
z Identificar as diferentes aplicações

Rastreamento de Conversações Individuais

Qualquer host pode ter múltiplas aplicações que se comunicam através da rede. Cada uma
destas aplicações irá se comunicar com uma ou mais aplicações em hosts remotos. É
responsabilidade da camada de Transporte manter fluxos múltiplos de comunicação entre estas
aplicações.

Segmentação de Dados

Como cada aplicação cria um fluxo de dados para ser enviado a uma aplicação remota, estes
dados devem ser preparados para serem enviados através do meio em segmentos gerenciáveis.
Os protocolos de camada de Transporte descrevem serviços que segmentam estes dados a
partir da camada de Aplicação. Isto inclui o encapsulamento necessário em cada lado do
segmento. Cada segmento de dados de aplicação requer a adição de cabeçalhos da camada de
Transporte para indicar a qual comunicação ele está associado.

Reagrupamento de Segmentos

No host de destino, cada segmento de dados pode ser direcionado para a aplicação apropriada.
Em adição a isso, estes segmentos de dados individuais também precisam ser reconstruídos em
um fluxo completo de dados que seja útil para a camada de Aplicação. Os protocolos da camada
de Transporte descrevem como a informação do cabeçalho da camada de Transporte é usada
para reagrupar os segmentos de dados em fluxos a serem passados para a camada de
Aplicação.

Identificação das Aplicações

Para passar os fluxos de dados para as aplicações apropriadas, a camada de Transporte deve
identificar a aplicação de destino. Para realizar isso, a camada de Transporte designa à aplicação
um identificador. Os protocolos TCP/IP chamam esse identificador de número de porta. A cada
processo de software que precise acessar a rede é designado um número de porta único naquele
host. Este número de porta é usado no cabeçalho da camada de transporte para indicar a qual
aplicação aquele segmento de dado está associado.

A camada de Transporte é o link entre a camada de Aplicação e a camada inferior, que são
responsáveis pela transmissão na rede. Esta camada aceita dados de diferentes conversações e
os passa para as camadas inferiores como segmentos gerenciáveis que podem ser finalmente
multiplexados no meio.

As aplicações não precisam saber dos detalhes operacionais da rede em uso. As aplicações
geram dados que são enviados de uma aplicação a outra, sem considerar o tipo de host de
destino, o tipo de meio sobre o qual o dado deve trafegar, o caminho tomado pelo dado, o
congestionamento em um link, ou o tamanho da rede.

Adicionalmente, as camadas inferiores não estão a par de que existem múltiplas aplicações
enviando dados na rede. Sua responsabilidade é entregar os dados ao dispositivo apropriado. A
camada de transporte então organiza esses segmentos antes de entregá-los à aplicação
apropriada.

As Necessidades de Dados Variam



Devido ao fato de diferentes aplicações terem diferentes necessidades, existem múltiplos
protocolos da camada de Transporte. Para algumas aplicações, os segmentos devem chegar em
uma sequência específica para serem processados com sucesso. Em alguns casos, todos os
dados precisam ser recebidos por qualquer um deles para poder ser usado. Em outros casos,
uma aplicação pode tolerar alguma perda de dados durante a transmissão através da rede.

Nas redes convergidas atuais, as aplicações com diferentes necessidades de transporte podem
se comunicar na mesma rede. Os diferentes protocolos da camada de Transporte têm diferentes
regras que permitem aos dispositivos lidar com essas necessidades diversas de dados.

Alguns protocolos fornecem apenas as funções básicas para entregar eficientemente os
segmentos de dados entre as aplicações apropriadas. Estes tipos de protocolos são úteis para
aplicações cujos dados são sensíveis a atrasos.

Outros protocolos da camada de Transporte descrevem processos que fornecem características
adicionais, tais como assegurar a entrega confiável entre as aplicações. Embora estas funções
adicionais proporcionem uma comunicação mais robusta na camada de Transporte entre as
aplicações, elas geram uma sobrecarga adicional e fornecem maiores demandas sobre a rede.

Página 2:
Separação de Múltiplas Comunicações

Considere um computador conectado a uma rede que está simultaneamente recebendo e
enviando e-mails e mensagens instantâneas, exibindo websites e conduzindo uma chamada
VoIP. Cada uma destas aplicações está enviando e recebendo dados através da rede ao mesmo
tempo. No entanto, os dados da chamada telefônica não são direcionados ao navegador web, e o
texto de uma mensagem instantânea não aparece em um e-mail.

Além disso, os usuários necessitam que um e-mail ou página web sejam completamente
recebidos e apresentados para que a informação seja considerada útil. Atrasos leves são
considerados aceitáveis para assegurar que a informação completa seja recebida e apresentada.

Em contraste, pequenas perdas ocasionada de partes de uma conversa telefônica pode ser
considerada aceitável. Uma pessoa pode inferir a perda de áudio a partir do contexto da conversa
ou pedir a outra pessoa para repetir o que foi dito. Isto é considerado preferível a atrasos que
resultariam de pedido à rede para gerenciar e reenviar os segmentos perdidos. Neste exemplo, o
usuário - não a rede - gerencia o reenvio ou substituição da informação perdida.

Página 3:
Conforme foi explicado no capítulo anterior, o envio de alguns tipos de dados - um vídeo por
exemplo - através da rede com um fluxo de comunicação completa pode impedir que outras
comunicações ocorram ao mesmo tempo. Isso também dificulta a recuperação de erro e
retransmissão de dados danificados.

A divisão de dados em partes pequenas, e o envio dessas partes a partir da origem, habilita
muitas comunicações diferentes que podem estar intercaladas (multiplexadas) na mesma rede.

A segmentação de dados, de acordo com os protocolos de camada de Transporte, fornece os
meios para enviar e receber dados quando se executam múltiplas aplicações concorrentemente
em um computador. Sem segmentação, apenas uma aplicação, o vídeo em streaming, por
exemplo, seria capaz de receber dados. Você não poderia receber e-mails, conversar em um
programa de mensagens instantâneas, ou exibir páginas web enquanto estivesse exibindo o
vídeo.



Na camada de Transporte, cada conjunto particular de segmentos que flui entre uma aplicação
de origem e uma aplicação de destino é conhecido com uma conversação.

Para identificar cada segmento de dados, a camada de Transporte adiciona ao segmento um
cabeçalho contendo dados binários. Este cabeçalho contém campos de bits. São os valores
nesses campos que habilitam que diferentes protocolos de camada de Transporte realizem
diferentes funções.

4.1.2 Controle das Conversações

Página 1:
As funções principais especificadas por todos os protocolos da camada de Transporte incluem:

Segmentação e Reagrupamento - A maioria das redes tem uma limitação da quantidade de
dados que podem ser incluídos em uma única PDU. A camada de Transporte divide os dados da
aplicação em blocos de dados que estão em um tamanho apropriado. No destino, a camada de
Transporte reagrupa os dados antes de enviá-los à aplicação ou serviço de destino.

Multiplexação de Conversação - Podem haver muitas aplicações ou serviços sendo executados
em cada host na rede. Cada uma destas aplicações ou serviços é designado a um endereço
conhecido como uma porta para que a camada de Transporte possa determinar com qual
aplicação ou serviço o dado é identificado.

Além de usar a informação contida nos cabeçalhos, para as funções básicas de segmentação e
reagrupamento de dados, alguns protocolos da camada de Transporte fornecem:

z Conversações orientadas à conexão
z Entrega Confiável
z Reconstrução de dados ordenados
z Controle de Fluxo


Página 2:
Estabelecimento de uma Sessão

A camada de Transporte pode fornecer essa orientação de conexão através da criação de
sessões entre as aplicações. Estas conexões preparam as aplicações para se comunicarem
entre si antes que qualquer dado seja transmitido. Dentro destas sessões, os dados para uma
comunicação entre as duas aplicações podem ser gerenciados de perto.

Entrega Confiável

Por muitas razões, é possível que um segmento de dados se torne corrompido, ou
completamente perdido, quando ele é transmitido através da rede. A camada de Transporte pode
assegurar que todorastreiem todas os segmentos atinjam seu destino tendo o dispositivo de
origem para retransmitir qualquer dado que seja perdido.

Entrega na Mesma Ordem

Devido ao fato de que as redes podem fornecer múltiplas rotas que podem ter diferentes tempos
de transmissão, os dados podem chegar na ordem errada. Através da numeração e
sequenciamento dos segmentos, a camada de Transporte pode assegurar que esses segmentos



sejam reagrupados na ordem apropriada.

Controle de Fluxo

Os hosts de rede têm recursos limitados, como memória e largura de banda. Quando a camada
de Transporte está ciente de que esses recursos estão sobrecarregados, alguns protocolos
podem solicitar que a aplicação de envio reduza a taxa de fluxo de dados. Isto é feito na camada
de Transporte regulando a quantidade de dados que a origem transmite como um grupo. O
controle de fluxo pode prevenir a perda de segmentos na rede e evitar a necessidade de
retransmissão.

À medida que os protocolos forem discutidos neste capítulo, estes serviços serão explicados
mais detalhadamente.

4.1.3 Suporte de Comunicação Confiável

Página 1:
Relembre que a função principal da camada de Transporte é gerenciar os dados da aplicação
para as conversações entre os hosts. No entanto, diferentes aplicações têm diferentes
necessidades para seus dados e, por isso, diferentes protocolos de Transporte têm sido
desenvolvidos para satisfazer estas necessidades.

O protocolo da camada de Transporte pode implementar um método para assegurar a entrega
confiável dos dados. Em termos de rede, confiabilidade significa assegurar que cada segmento
de dado enviado pela origem chegue ao seu destino. Na camada de Transporte, as três
operações básicas de confiabilidade são:

z rastreamento de dados transmitidos
z confirmação de dados recebidos
z retransmissão de quaisquer dados não confirmados

Isto requer que os processos da camada de Transporte da origem rastreiem todos os segmentos
de dados de cada conversação e retransmitam quaisquer dados que realmente não foram
confirmados pelo destino. A camada de Transporte do host receptor também deve rastrear o
dado à medida que ele é recebido e confirmar o recebimento do dado.

Estes processos de confiabilidade colocam uma sobrecarga adicional sobre os recursos de rede
devido à confirmação, rastreamento e retransmissão. Para suportar estas operações de
confiabilidade, mais dados de controle são trocados entre os hosts de envio e recepção. Esta
informação de controle está contida no cabeçalho da Camada 4.

Isto cria um dilema entre o valor de confiabilidade e a carga que ela coloca sobre a rede. Os
desenvolvedores de aplicações devem escolher que tipo de protocolo de transporte é apropriado
com base nas necessidades de suas aplicações. Na camada de Transporte, existem protocolos
que especificam métodos que sejam para entrega confiável, entrega garantida ou entrega de
melhor esforço. No contexto de rede, a entrega de melhor esforço é referida como não confiável,
porque não há confirmação de que o dado foi recebido no seu destino.

Determinação da Necessidade de Confiabilidade

As aplicações, tais como as bases de dados, páginas web e e-mail, necessitam de que todos os
dados enviados cheguem ao destino em seu estado original, em ordem, para que os dados sejam
úteis. Quaisquer perdas de dados podem causar uma comunicação corrompida que é incompleta
ou ilegível. Portanto, estas aplicações são projetadas para usar um protocolo da camada de
Transporte que implemente confiabilidade. A sobrecarga adicional de rede é considerada como
uma necessidade para essas aplicações.



Outras aplicações são mais tolerantes com a perda de pequenas quantidades de dados. Por
exemplo, se um ou dois segmentos de um fluxo de vídeo falharem ao chegar, isso cria apenas
uma interrupção momentânea no fluxo. Isto pode parecer como uma distorção na imagem, mas
pode até mesmo não ser notado pelo usuário.

A imposição de sobrecarga para assegurar a confiabilidade para essa aplicação pode reduzir a
utilidade da mesma. A imagem do vídeo em streaming seria muito degradada se o dispositivo de
destino tivesse de se responsabilizar pelos dados perdidos e pelo retardo no fluxo quando da
espera por sua chegada. É melhor projetar uma boa imagem possível no tempo com os
segmentos que chegam e abrir mão da confiabilidade. Se a confiabilidade é necessária por
alguma razão, estas aplicações podem apresentar solicitações de verificação de erro e
retransmissão.

4.1.4 TCP e UDP

Página 1:
Os dois protocolos da camada de Transporte mais comuns da pilha de protocolos TCP/IP são o
Protocolo TCP e o Protocolo UDP. Ambos os protocolos gerenciam a comunicação de múltiplas
aplicações. As diferenças entre os dois são as funções específicas que cada protocolo
implementa.

Protocolo UDP (User Datagram Protocol)

O UDP é um protocolo simples e sem conexão, descrito na RFC 768. Ele tem a vantagem de
fornecer uma entrega de dados de baixa sobrecarga. As segmentos de comunicação em UDP
são chamados datagramas. Estes datagramas são enviados como o "melhor esforço" por este
protocolo da camada de Transporte.

As aplicações que usam UDP incluem:

(DNS)

Vídeo em Streaming

Voz Sobre IP (VOIP)

Protocolo TCP

O TCP é um protocolo orientado à conexão, descrito na RFC 793. O TCP causa sobrecarga
adicional para adicionar funções. As funções adicionais especificadas pelo TCP são as ditas
entrega ordenada, entrega confiável e controle de fluxo. Cada segmento TCP tem 20 bytes de
overhead no cabeçalho que encapsula o dado da camada de Aplicação, enquanto que o
segmento UDP tem apenas 8 bytes. Veja a figura para uma comparação.

As aplicações que usam TCP são:

Navegadores web

E-mail

FTP



4.1.5 Endereçamento de Porta

Página 1:
Identificação de Conversações

Considere o exemplo anterior de um computador que simultaneamente recebe e envia e-mail,
mensagens instantâneas, páginas web e chamada VOIP.

Os serviços baseados em TCP e UDP rastreiam as várias aplicações que estão se comunicando.
Para diferenciar os segmentos e datagramas para cada aplicação, o TCP e o UDP têm campos
de cabeçalho que podem identificar unicamente essas aplicações. Estes identificadores únicos
são os números de porta.

No cabeçalho de cada segmento ou datagrama, há uma porta de origem e destino. O número da
porta de origem é o número para essa comunicação associado à aplicação originada no host
local. O número da porta de origem é o número para essa comunicação associada à aplicação
originada no host local.

Os números de porta são designados de várias maneiras, dependendo se a mensagem é uma
solicitação ou uma resposta. Embora os processos do servidor tenham números de porta
estáticos designados a eles, os clientes escolhem dinamicamente um número de porta para cada
conversação.

Quando uma aplicação cliente envia uma solicitação à aplicação servidor, a porta de destino
contida no cabeçalho é o número da porta que é designado ao serviço daemon executado no
host remoto. O software cliente deve conhecer qual número de porta está associado ao processo
servidor no host remoto. Este número de porta de destino é configurado, seja através do padrão
ou manualmente. Por exemplo, quando uma aplicação de navegador web faz uma solicitação a
um servidor web, o navegador usa o TCP é número de porta 80, a menos que um outro seja
especificado. Isso acontece porque a porta 80 TCP é a porta padrão designada a aplicações web.
Muitas aplicações comuns têm designações de porta padrão.

A porta de origem em um cabeçalho de segmento ou datagrama de uma solicitação de cliente é
gerada aleatoriamente. Contanto que ela não entre em conflito com outras portas em uso no
sistema, o cliente pode escolher qualquer número de porta. Este número de porta age com um
endereço de retorno para a aplicação que faz a solicitação. A camada de Transporte rastreia esta
porta e a aplicação que iniciou a solicitação, de modo que quando uma resposta é retornada, ela
pode ser encaminhada para a aplicação correta. O número de porta da aplicação solicitante é
usado com o número de porta de destino na resposta que volta do servidor.

A combinação do número de porta da camada de Transporte e do endereço IP da camada de
Rede designada ao host identifica exclusivamente um processo particular sendo executado em
um dispositivo de host específico. Esta combinação é chamada de soquete. Ocasionalmente,
você pode encontrar os termos número de porta e soquete sendo usados alternadamente. No
contexto deste curso, o termo soquete se refere apenas à combinação única de endereço IP e
número de porta. Um par de soquete, que consiste de endereços IP de origem e destino, é
também único e identifica a conversação entre os dois hosts.

Por exemplo, uma solicitação de página HTTP sendo enviada a um servidor web (porta 80) sendo
executado em um host com um endereço de IPv4 Camada 3 192.168.1.20 seria destinado ao
soquete 192.168.1.20:80.

Se o navegador web que faz a solicitação à web está sendo executado no host 192.168.100.48 e
o número Dinâmico de porta designado ao navegador web é 49152, o soquete para a página web
seria 192.168.100.48:49152.



Página 2:
A Internet Assigned Numbers Authority (IANA) designa números de porta. A IANA é um órgão de
padrões responsável pela designação de vários padrões de endereçamento.

Existem diferentes tipos de números de portas:

Portas Conhecidas (Números 0 a 1023) - Esses números estão reservados para serviços e
aplicações. Eles são comumente usados para aplicações como o HTTP (servidor web)
POP3/SMTP (servidor de e-mail) e Telnet. Através da definição destas portas conhecidas para
aplicações de servidor, aplicações de clientes podem ser programados para solicitar uma
conexão com essa porta específica e seu serviço associado.

Portas Registradas (Números 1024 a 49151) - Estes números de portas são designados para
processos ou aplicações de usuário. Estes processos são principalmente aplicações individuais
que um usuário escolheu para instalar em vez de aplicações comuns que receberiam uma Porta
Conhecida. Quando não usadas para um recurso de servidor, estas portas também podem ser
dinamicamente selecionadas por um cliente como sua porta de origem.

Portas Dinâmicas ou Privadas (Números 49152 a 65535) - Elas são geralmente designadas
dinamicamente a aplicações de cliente quando se inicia uma conexão. Não é muito comum um
cliente se conectar a um serviço usando uma Porta Dinâmica ou Privada (embora alguns
programas de compartilhamento de arquivos peer-to-peer o façam).

Utilização do TCP e do UDP

Algumas aplicações podem usar tanto TCP como UDP. Por exemplo, o baixo overhead
(sobrecarga) do UDP habilita ao DNS servir a muitas solicitações de clientes muito rapidamente.
As vezes, no entanto, o envio da informação solicitada pode exigir a confiabilidade do TCP. Neste
caso, o número 53 de porta conhecida é usado por ambos os protocolos com este serviço.

Links

Uma lista atual de números de porta pode ser encontrada em
http://www.iana.org/assignments/port-numbers.

Página 3:
As vezes é necessário conhecer quais conexões TCP ativas estão abertas e sendo executadas
em um host de rede. O Netstat é um utilitário de rede importante que pode ser usado para
verificar essas conexões. O Netstat lista o protocolo em uso, o endereço local e o número de
porta, o endereço externo, o número de porta e o estado da conexão.

Conexões TCP inexplicáveis podem ser uma grande ameaça de segurança. Isto acontece porque
elas podem indicar que algo ou alguém está conectado ao host local. Adicionalmente, as
conexões TCP desnecessárias podem consumir recursos valiosos do sistema, reduzindo a
velocidade de desempenho do host. O Netstat deve ser usado para examinar as conexões
abertas em um host quando o desempenho parecer comprometido.

Muitas opções úteis estão disponíveis para o comando netstat.

4.1.6 Segmentação e Reagrupamento - Dividir e Conquistar

Página 1:
O capítulo anterior explicou como as PDUs são construídas para passar os dados de uma



aplicação para os vários protocolos para criar uma PDU que seja então transmitida no meio. No
host de destino, este processo é revertido até que os dados possam ser passados até a
aplicação.

Algumas aplicações transmitem grandes quantidades de dados - em alguns casos, muitos
gigabytes. Seria impraticável enviar todos estes dados em um segmento muito grande. Nenhum
outro tráfego de rede poderia ser transmitido enquanto estes dados estivessem sendo enviados.
Um segmento muito grande de dados pode levar minutos ou mesmo horas para ser enviado.
Além disso, se houvesse algum erro, o arquivo inteiro seria perdido ou reenviado. Dispositivos de
rede não teriam buffers de memória grandes o suficiente para armazenar estes dados enquanto
eles fossem transmitidos ou recebidos. O limite varia dependendo da tecnologia de rede e do
meio físico específico que está sendo usado.

Dividir os dados da aplicação em segmentos assegura que os dados sejam transmitidos
dentro dos limites do meio e que os dados de diferentes aplicações possam ser
multiplexadas no meio.

O TCP e o UDP Lidam com a Segmentação de Maneira Diferente.

No TCP, cada cabeçalho de segmento contém um número sequencial. Este número sequencial
confere as funções da camada de Transporte no host de destino para reagrupar segmentos na
ordem em que eles foram transmitidos. Isso assegura que as aplicações de destino tenham os
dados na forma exata pretendida pelo remetente.

Embora os serviços que usam UDP também rastreiem as conversações entre as aplicações, eles
não estão preocupados com a ordem que a informação foi transmitida, ou na manutenção de
uma conexão. Não existe número sequencial no cabeçalho UDP. O UDP é um esquema mais
simples e gera menos overhead do que o TCP, resultando em uma transferência mais rápida de
dados.

A informação pode chegar em ordem diferente da qual ela foi transmitida porque diferentes
pacotes podem tomar diferentes caminhos através da rede. Uma aplicação que usa o UDP
precisa tolerar o fato de que os dados podem não chegar na ordem em que foram enviados.

Página 2:
Nesta atividade, você "olhará dentro" de pacotes para ver como o DNS e o HTTP usam os
números de porta.

Clique no ícone do Packet Tracer para iniciar a atividade.

4.2 O Protocolo TCP - Comunicando com Confiabilidade
4.2.1 TCP - Tornando as Conversações Confiáveis

Página 1:
A distinção principal entre o TCP e o UDP está na confiabilidade. A confiabilidade da
comunicação TCP é realizada com o uso de sessões orientadas à conexão. Antes que um host
usando o TCP envie dados para outro host, a camada de Transporte inicia um processo para
criar uma conexão com o destino. Esta conexão habilita o rastreamento de uma sessão, ou um
fluxo de comunicação entre os hosts. Este processo assegura que cada host está ciente e
preparado para a comunicação. Uma conversação TCP completa exige o estabelecimento de
uma sessão entre os hosts em ambas as direções.

Após uma sessão ter sido estabelecida, o destino envia confirmações para a origem para os



segmentos que ele recebe. Estas confirmações formam a base da confiabilidade dentro de uma
sessão TCP. À medida que a origem recebe uma confirmação, ela sabe que os dados foram
entregues com sucesso e pode parar o rastreamento daqueles dados. Se a origem não recebe
uma confirmação dentro de um período pré-determinado de tempo, ela retransmite aqueles
dados para o destino.

Parte do overhead adicional do uso do TCP é o tráfego de rede gerado por confirmações e
retransmissões. O estabelecimento de sessões cria um overhead na forma de segmentos
adicionais sendo trocados. Há também um overhead adicional nos hosts individuais criado pela
necessidade de rastrear quais segmentos estão esperando pela confirmação e pelo processo de
retransmissão.

Esta confiabilidade é alcançada tendo campos no segmento TCP, cada um com uma função
específica, conforme mostrado na figura. Estes campos serão discutidos mais tarde nesta seção.

4.2.2 Processos TCP em Servidores

Página 1:
Conforme discutido anteriormente neste capítulo, os processos de aplicações são executados
nos servidores. Estes processos esperam até que um cliente inicie a comunicação com uma
solicitação de informação ou outros serviços.

Cada processo de aplicação sendo executado no servidor é configurado para usar um número de
porta, seja no modo padrão ou manualmente através de um administrador do sistema. Um
servidor individual não pode ter dois serviços designados ao mesmo número de porta
dentro dos mesmos serviços da camada de Transporte. Um host executando uma aplicação
de servidor web e uma aplicação de transferência de arquivo não pode ter ambos configurados
para usar a mesma porta (por exemplo, a porta TCP 8080). Quando uma aplicação de servidor
ativo é designada a uma porta específica, essa porta é considerada como estando "aberta" no
servidor. Isto significa que a camada de Transporte aceita e processa segmentos endereçados
àquela porta. Qualquer solicitação de cliente que chega endereçada ao soquete correto é aceita e
os dados são transmitidos à aplicação do servidor. Podem haver muitas portas simultâneas
abertas em um servidor, uma para cada aplicação de servidor ativo. É comum para um servidor
fornecer mais de um serviço, como um servidor web e um servidor FTP, ao mesmo tempo.

Uma maneira de melhorar a segurança em um servidor é restringir o acesso de servidor a apenas
essas portas associadas com os serviços e as aplicações que devem ser acessíveis para
solicitantes autorizados.

A figura mostra a alocação típica de portas de origem e destino em operações cliente/servidor
TCP.

4.2.3 Estabelecimento e Término de conexões TCP

Página 1:
Quando dois hosts se comunicam usando o TCP, uma conexão é estabelecida antes que os
dados possam ser trocados. Depois da comunicação ter sido completada, as sessões são
fechadas e a conexão é encerrada. Os mecanismos de conexão e sessão habilitam a função de
confiabilidade do TCP.

Veja a figura para saber as etapas para estabelecer e terminar uma conexão TCP.

O host rastreia cada segmento de dados dentro de uma sessão e troca informação sobre qual



dado é recebido por cada host usando a informação no cabeçalho TCP.

Cada conexão representa dois fluxos de comunicação, ou sessões. Para estabelecer uma
conexão, os hosts realizam um handshake triplo. Bits de controle no cabeçaçho TCP indicam o
progresso e o status da conexão. O handshake triplo:

z Estabelece que o dispositivo de destino está presente na rede
z Verifica se o dispositivo de destino tem um serviço ativo e está aceitando solicitações no
número de porta de destino que o cliente pretende usar para a sessão.
z Informa o dispositivo de destino que o cliente de origem pretende estabelecer uma sessão
de comunicação nessa número de porta

Nas conexões TCP, o host que serve como um cliente inicia a sessão para o servidor. Os três
passos no estabelecimento da conexão TCP são:

1. O cliente iniciador envia um segmento contendo um valor sequencial inicial, que serve como
uma solicitação ao servidor para começar uma sessão de comunicações.

2. O servidor responde com um segmento contendo um valor de confirmação igual ao valor
sequencial recebido mais 1, mais seu próprio valor sequencial de sincronização. O valor é maior
do que o número sequencial porque o ACK é sempre o próximo Byte ou Octeto esperado. Este
valor de confirmação habilita o cliente a submeter à resposta de volta ao segmento original que
ele enviou ao servidor.

3. O cliente iniciador responde com um valor de confirmação igual ao valor sequencial que ele
recebeu mais um. Isso completa o processo de estabelecimento da conexão.

Para entender o processo do handshake triplo, é importante examinar os vários valores que os
dois hosts trocam. Dentro do cabeçalho de segmento TCP, existem seis campos de 1 bit que
contêm a informação de controle usada para gerenciar os processos TCP. Esses campos são:

URG - Indicador urgente de campo significativo

ACK - Campo significativo de confirmação

PSH - função Push

RST - Restabelecer a conexão

SYN - Sincronizar números de sequência

FIN - Não há mais dados do remetente

Estes campos são referidos como flags (flags), porque o valor de um desses campos é apenas 1
bit e, portanto, tem apenas dois valores: 1 ou 0. Quando um valor de bit é definido como 1, ele
indica que a informação de controle está contida no segmento.

Com o uso de um processo de quatro etapas, as flags são trocadas para encerrar uma conexão
TCP.

4.2.4 Handshake Triplo TCP

Página 1:
Usando as entradas Wireshark, você pode examinar a operação do handshake triplo TCP:

Etapa 1



Um cliente TCP inicia o handshake triplo enviando um segmento com a flag de controle SYN
(número sequencial de sincronia) definido, indicando um valor inicial no campo do número de
sequência no cabeçalho. Este valor inicial para o número de sequência, conhecido como o
Número de Sequência Inicial (ISN), é escolhido aleatoriamente e é usado para iniciar o
rastreamento do fluxo de dados do cliente para o servidor para esta sessão. O ISN no cabeçalho
de cada segmento é aumentado em um para cada byte de dados enviados do cliente para o
servidor à medida que a conversação de dados continua.

Conforme mostrado na figura, a saída de um analisador de protocolo mostra a flag de controle
SYN e o número de sequência relativo.

A flag de controle SYN é definida e o número de sequência relativo é 0. Embora o analisador de
protocolo no gráfico indique os valores relativos para os números de sequências e de
confirmação, os valores verdadeiros são números binários de 32 bits. Nós podemos determinar
os números reais enviados nos cabeçalhos do segmento examinando a tela de Pacote de Bytes.
Aqui você pode ver os quatro bytes representados em hexadecimal.

Página 2:
Etapa 2

O servidor TCP precisa confirmar o recebimento do segmento SYN do cliente para estabelecer a
sessão do cliente para o servidor. Para fazer isso, o servidor envia um segmento de volta para o
cliente com a flag ACK indicando que o número de Confirmação é significativo. Com esta flag
indicada no segmento, o cliente confirma isto como uma confirmação de que o servidor recebeu o
SYN do cliente TCP.

O valor do campo de número de confirmação é igual ao número de sequência inicial mais 1. Isto
estabelece uma sessão do cliente para o servidor. A flag ACK permanecerá definida para o
equilíbrio da sessão. Relembre que a conversação entre o cliente e o servidor é na verdade duas
sessões unidirecionais, uma do cliente para o servidor, e outra do servidor para o cliente. Nesta
segunda etapa do handshake triplo, o servidor precisa iniciar a resposta do servidor para o
cliente. Para iniciar esta sessão, o servidor usa a flag SYN da mesma maneira que o cliente o fez.
Ele define a flag de controle SYN no cabeçalho para estabelecer a sessão do servidor para o
cliente. A flag SYN indica que o valor inicial do campo de número de sequência está no
cabeçalho. Este valor será usado para rastrear o fluxo de dados nesta sessão do servidor de
volta para o cliente.

Conforme mostrado na figura, a saída do analisador de protocolo mostra que as flags de controle
ACK e SYN estão definidas e os números de sequência relativo e de confirmação são mostrados.

Página 3:
Etapa 3

Finalmente, o cliente TCP responde com um segmento contendo um ACK que é a resposta para
o TCP SYN enviado pelo servidor. Não há dado de usuário neste segmento. O valor do campo de
número de confirmação contém um 1 a mais do que o número de sequência inicial recebido do
servidor. Já que ambas as sessões estão estabelecidas entre cliente e servidor, todos os
segmentos adicionais trocados nesta comunicação terão uma flag ACK definida.

Conforme mostrado na figura, a saída do analisador de protocolo mostra a flag de controle ACK
definida e os números de confirmação são mostrados.



A segurança pode ser adicionada à rede de dados por:

z Negação de estabelecimento de sessões TCP
z Apenas permitindo sessões que sejam estabelecidas para serviços específicos
z Apenas permitindo tráfego como parte de sessões já estabelecidas

Esta segurança pode ser implementada para todas as sessões TCP ou apenas para as sessões
selecionadas.

4.2.5 Encerramento de Sessão TCP

Página 1:
Para fechar uma conexão, a flag de fim de comunicação FIN (Finish) no cabeçalho do segmento
precisa ser definida. Para terminar cada sessão TCP unidirecional, um handshake duplo é usado,
consistindo de um segmento FIN e um segmento ACK. Portanto, para terminar uma conversação
única suportada pelo TCP, quatro trocas são necessárias para finalizar ambas as sessões. Nota:
Nesta explicação, os termos cliente e servidor são usados nesta descrição com uma referência
visando a simplicidade, mas o processo de encerramento pode ser iniciado por qualquer um dos
dois hosts que completarem a sessão:

1. Quando o cliente não tem mais dados para enviar no fluxo, ele envia um segmento com uma
flag FIN definida.

2. O servidor envia uma ACK para confirmar o recebimento do FIN para encerrar a sessão do
cliente para o servidor.

3. O servidor envia um FIN para o cliente, para encerrar a sessão do servidor para o cliente.

4. O cliente responde com um ACK para confirmar o FIN do servidor.

Quando o cliente final de uma sessão não tem mais dados para transferir, ele define a flag FIN no
cabeçalho de um segmento. A seguir, o servidor irá enviar um segmento normal contendo dados
com a flag ACK definida usando o número de confirmação, confirmando que todos os bytes de
dados foram recebidos. Quando todos os segmentos tiverem sido confirmados, a sessão é
fechada.

A sessão na outra direção é fechada usando o mesmo processo. O receptor indica que não há
mais dados para enviar definindo uma flag FIN no cabeçalho de um segmento enviado à origem.
Uma confirmação de retorno confirma que todos os bytes de dados foram recebidos e que a
sessão está, por sua vez, fechada.

Conforme mostrado na figura, as flags de controle FIN e ACK são definidas no cabeçalho do
segmento, fechando com isso a sessão HTTP.

É possível encerrar a conexão através de um handshake triplo. Quando o cliente não tem mais
dados para enviar, ele envia um FIN ao servidor. Se o servidor também não tem mais dados para
enviar, ele pode responder com ambas as flags FIN e ACK definidas, combinando duas etapas
em uma. O cliente responde com um ACK.

Página 2:
Nesta atividade, você irá estudar o handshake triplo TCP para estabelecimento de sessão e o
processo TCP para encerramento. Muitos protocolos de aplicações usam TCP, e visualizar os
processos de estabelecimento e encerramento de sessão com o Packet Tracer aprofundará o



seu entendimento.


4.3 Gerenciamento de Sessões TCP
4.3.1 Reagrupamento de Segmentos TCP

Página 1:
Refazendo o Sequenciamento de Segmentos na Ordem Transmitida

Quando os serviços enviam dados usando o TCP, os segmentos podem chegar no seu destino
fora de ordem. Para a mensagem original ser entendida pelo receptor, os dados desses
segmentos são reagrupados na sua ordem original. Os números de sequência são designados no
cabeçalho de cada pacote para alcançar essa meta.

Durante a instalação de uma sessão, um número de sequência inicial (ISN) é definido. Este
número de sequência inicial representa o valor de partida para os bytes para esta sessão que
será transmitida para a aplicação receptora. À medida que os dados são transmitidos durante a
sessão, o número de sequência é incrementado pelo número de bytes que foram transmitidos.
Este rastreamento de bytes de dados habilita a cada segmento ser identificado e reconhecido de
forma única. Segmentos perdidos podem ser identificados.

Os números de sequência do segmento habilitam a confiabilidade, indicando como reagrupar e
reordenar segmentos recebidos, conforme mostrado na figura.

O processo TCP do receptor coloca os dados de um segmento em um buffer. Os segmentos são
colocados na ordem de número de sequência apropriada e passados para a camada de
Aplicação quando reagrupados. Quaisquer segmentos que cheguem com números de sequência
não contíguos são retidos para processamento posterior. Então, quando os segmentos com os
bytes perdidos chegam, esses segmentos são processados.

4.3.2 Confirmação TCP com Janelamento

Página 1:
Confirmação de Recebimento de Segmentos

Uma das funções do TCP é assegurar que cada segmento atinja o seu destino. Os serviços TCP
no host de destino confirmam os dados que ele recebeu para a aplicação de origem.

O número de sequência do cabeçalho do segmento e o número de confirmação são usados
juntamente para confirmar o recebimento dos bytes de dados contidos nos segmentos. O número
de sequência é o número relativo de bytes que foram transmitidos nessa sessão mais 1 (que é o
número do primeiro byte de dado no segmento corrente). O TCP usa o número de confirmação
em segmentos enviados de volta à origem para indicar o próximo byte que o receptor espera
receber nessa sessão. Isto é chamado de confirmação esperada.

A origem é informada de que o destino recebeu todos os bytes neste fluxo de dados até, mas não
incluindo, o byte indicado pelo número de confirmação. Espera-se que o host de envio envie um
segmento que use um número de sequência que é igual ao número de confirmação.

Lembre-se, cada conexão é na verdade composta por duas sessões unidirecionais. Os números
de sequência e de confirmação estão sendo trocados em ambas as direções.



No exemplo da figura, o host da esquerda está enviando dados para o host da direita. Ele envia
um segmento contendo 10 bytes de dados para essa sessão e um número de sequência igual a 1
no cabeçalho.

O host receptor da direita recebe o segmento na Camada 4 e determina que o número de
sequência é 1 e que ele tem 10 bytes de dados. O host então envia um segmento de volta ao
host da esquerda para confirmar o recebimento deste dado. Neste segmento, o host define o
número de confirmação em 11 para indicar que o próximo byte de dados que ele espera receber
nessa sessão é o byte número 11.

Quando o host de envio da esquerda recebe essa confirmação, ele pode agora enviar o próximo
segmento contendo dados para essa sessão iniciando com o byte número 11.

Examinando esse exemplo, se o host de envio tiver que esperar pela confirmação de
recebimento de cada 10 bytes, a rede teria muito overhead. Para reduzir o overhead dessas
confirmações, múltiplos segmentos de dados podem ser enviados e confirmados com uma única
mensagem TCP na direção oposta. Este confirmação contém um número de confirmação
baseado no número total de bytes recebidos na sessão.

Por exemplo, começando com um número de sequência de 2000, se 10 segmentos de 1000
bytes cada fossem recebidos, o número de confirmação 12001 seria retornado à origem.

A quantidade de dados que a origem pode transmitir antes que uma confirmação seja recebida é
chamada de tamanho da janela. O Tamanho de Janela é um campo no cabeçalho TCP que
habilita o gerenciamento de dados perdidos e controle de fluxo.

4.3.3 Retransmissão TCP

Página 1:
Lidando com a Perda de Segmento

Não importa quanto uma rede seja bem projetada, a perda de dados ocorrerá ocasionalmente.
Portanto, o TCP fornece métodos para gerenciar essas perdas de segmentos. Entre estes
métodos há um mecanismo que retransmite segmentos com dados não confirmados.

Um serviço de host de destino usando TCP geralmente reconhece os dados apenas para bytes
sequenciais contíguos. Se estiver faltando um ou mais segementos, apenas os dados nos
segmentos que completam o fluxo serão confirmados.

Por exemplo, se os segmentos com números de sequência de 1500 a 3000 e de 3400 a 3500
fossem recebidos, o número de confirmação seria 3001. Isto porque existem segmentos com os
números de sequência de 3001 a 3399 que não foram recebidos.

Quando o TCP no host de origem não recebeu uma confirmação depois de um período pré-
determinado de tempo, ele voltará ao último número de confirmação que recebeu e retransmitirá
os dados a partir daquele ponto para frente.

O processo de retransmissão não é especificado pela RFC, mas é deixado para a implementação
específica do TCP.

Para uma implementação de TCP típica, um host pode transmitir um segmento, colocar uma
cópia do segmento numa fila de retransmissão e iniciar uma contagem. Quando a confirmação do
dado é recebida, o segmento é deletado da fila. Se a confirmação não for recebida antes da
contagem expirar, o segmento é retransmitido.

A animação demonstra a retransmissão de segmentos perdidos.



Os hosts atualmente podem também empregar um atributo adicional chamado de Confirmações
Seletivas. Se ambos os hosts suportam Confirmações Seletivas, é possível para o destino
confirmar bytes em segmentos não contíguos e o host precisará apenas retransmitir os dados
perdidos.

4.3.4 Controle de Congestionamento TCP - Minimizando a Perda de Segmentos

Página 1:
Controle de Fluxo

O TCP também fornece mecanismos para o controle de fluxo. O controle de fluxo ajuda na
confiabilidade de transmissões TCP através do ajuste da taxa de fluxo de dados efetiva entre os
dois serviços na sessão. Quando a origem é informada de que uma quantidade especificada de
dados nos segmentos é recebida, ela pode continuar a enviar mais dados para essa sessão.

O campo Tamanho de Janela no cabeçalho TCP especifica a quantidade de dados que podem
ser transmitidos antes que uma confirmação precise ser recebida. O tamanho de janela inicial é
determinado durante a inicialização da sessão através do handshake triplo.

O mecanismo de feedback do TCP ajusta a taxa efetiva de transmissão de dados até o fluxo
máximo que a rede e o dispositivo de destino podem suportar sem perda. O TCP tenta gerenciar
a taxa de transmissão de modo que todos os dados sejam recebidos e as retransmissões sejam
minimizadas.

Veja a figura para uma representação simplificada do tamanho de janela e confirmações. Neste
exemplo, o tamanho de janela inicial para uma sessão TCP representada é definido em 3000
bytes. Quando o remetente tiver transmitido 3000 bytes, ele espera por uma confirmação destes
bytes antes de transmitir mais segmentos nesta sessão.

Quando o remetente tiver recebido esta confirmação do receptor, o remetente poderá transmitir
mais 3000 bytes.

Durante o atraso no recebimento de uma confirmação, o remetente não enviará quaisquer
segmentos adicionais para essa sessão. Em períodos em que a rede está congestionada ou os
recursos do host de recebimento estão extenuados, o atraso pode aumentar. À medida que este
atraso aumenta, a taxa de transmissão efetiva dos dados para esta sessão diminui. A diminuição
da velocidade na taxa de dados ajuda a reduzir a contenção de recursos.

Página 2:
Redução do Tamanho de Janela

Um outro modo de controlar o fluxo de dados é usar tamanhos de janela dinâmicos. Quando os
recursos da rede são restringidos, o TCP pode reduzir o tamanho de janela para exigir que os
segmentos recebidos sejam confirmados mais frequentemente. Isto diminui efetivamente a
velocidade da taxa de transmissão porque a origem espera que os dados sejam confirmados
mais frequentemente.

O host de recebimento envia o valor do tamanho de janela ao remetente para indicar o número
de bytes que ele está preparado para receber como parte desta sessão. Se o destino precisar
diminuir a velocidade da taxa de comunicação por causa de memória de buffer limitada, ele pode
enviar um valor de tamanho de janela pequeno para a origem como parte de uma confirmação.



Conforme mostrado na figura, se um host de recebimento tem um congestionamento, ele pode
responder ao host de envio com um segmento com tamanho de janela reduzido. Neste gráfico,
há uma perda de um dos segmentos. O receptor mudou o campo da janela no cabeçalho TCP de
segmentos retornados nesta conversação de 3000 para 1500. Isto levou o remetente a reduzir o
tamanho de janela para 1500.

Após períodos de transmissão com nenhuma perda de dados ou restrição de recursos, o receptor
começará a aumentar o campo da janela. Isto reduz a sobrecarga na rede porque poucas
confirmações precisam ser enviadas. O tamanho de janela continuará a aumentar até que haja
perda de dados, o que levará à diminuição novamente.

Este aumento e diminuição dinâmico no tamanho de janela é um processo contínuo no TCP, que
determina o tamanho de janela adequado para cada sessão TCP. Em redes altamente eficientes,
os tamanhos de janela podem se tornar muito grandes porque os dados não estão sendo
perdidos. Nas redes em que a infra-estrutura subjacente é pressionada, o tamanho de janela
provavelmente permanecerá pequeno.

Links

Detalhes das várias características de gerenciamento de congestionamento do TCP podem ser
encontrados na RFC 2581.

http://www.ietf.org/rfc/rfc2581.txt

4.4 O Protocolo UDP - Comunicação com Baixo Overhead
4.4.1 UDP - Baixo Overhead versus Confiabilidade

Página 1:
O UDP é um protocolo simples que fornece as funções básicas da camada de Transporte. Ele
possui overhead muito mais baixo do que o TCP, já que não é orientado à conexão e não fornece
mecanismos de retransmissão, sequenciamento e controle de fluxo sofisticados.

Isto não significa que as aplicações que usam UDP sejam sempre não confiáveis. Isto
simplesmente significa que estas funções não são fornecidas pelo protocolo da camada de
Transporte e devem ser implementadas em outros locais se houver necessidade.

Embora a quantidade total de tráfego UDP encontrada em uma rede típica geralmente não seja
baixo, os principais protocolos da camada de Aplicação que usam UDP incluem:

z Domain Name System (DNS)
z Simple Network Management Protocol (SNMP)
z Protocolo de Configuração Dinâmica de Host (DHCP)
z Routing Information Protocol (RIP)
z Trivial File Transfer Protocol (TFTP)
z Jogos On-line

Algumas aplicações, como jogos on-line ou VOIP, podem tolerar alguma perda de dados. Se
estas aplicações usarem TCP, elas podem passar por grandes atrasos enquanto o TCP detecta a
perda e retransmite dados. Estes atrasos seriam mais prejudiciais para a aplicação do que
pequenas perdas de dados. Algumas aplicações, como o DNS, simplesmente irão tentar
novamente a solicitação se não receberem resposta e, portanto, eles não precisarão do TCP para
garantir a entrega da mensagem.

O baixo overhead do UDP o torna muito desejável para tais aplicações.



4.4.2 Reagrupamento de Datagramas UDP

Página 1:
Por causa do UDP ser sem conexão, as sessões não são estabelecidas antes que a
comunicação ocorra enquanto elas estão com TCP. Diz-se que o UDP é baseado em transação.
Em outras palavras, quando uma aplicação tem dados para enviar, ele simplesmente envia os
dados.

Muitas aplicações que usam o UDP enviam pequenas quantidades de dados que podem se
ajustar a um segmento. No entanto, algumas aplicações enviarão quantidades maiores de dados
que precisam ser divididos em múltiplos segmentos. A PDU UDP é referida como um datagrama,
embora os termos segmento e datagrama sejam usados algumas vezes de modo alternado para
descrever uma PDU da camada de Transporte.

Quando múltiplos datagramas são enviados a um destino, eles podem tomar diferentes caminhos
e chegar na ordem errada. O UDP não rastreia os números de sequência da forma que o TCP
faz. O UDP não tem um modo para reordenar os datagramas na sua ordem de transmissão. Veja
a figura.

Portanto, o UDP simplesmente reagrupa os dados na ordem que eles foram recebidos e os
encaminha para a aplicação. Se a sequência dos dados é importante para a aplicação, ele terá
que identificar a sequência apropriada dos dados e determinar como os dados devem ser
processados.

4.4.3 Solicitações UDP e Processos de Servidores

Página 1:
Do mesmo modo que com as aplicações baseadas em TCP, aos aplicações de servidores
baseados em UDP são designados números de porta Conhecida ou Registrada. Quando estas
aplicações ou processos estão sendo executados, eles aceitarão os dados correspondentes ao
número de porta designado. Quando o UDP recebe um datagrama destinado a uma destas
portas, ele encaminha os dados à aplicação apropriada com base em seu número de porta.

4.4.4 Processos de Cliente UDP

Página 1:
Do mesmo modo que o TCP, a comunicação cliente/servidor é iniciada por uma aplicação cliente
que está solicitando dados de um processo servidor. O processo cliente UDP seleciona
aleatoriamente um número de porta a partir de uma faixa dinâmica de números de porta e o usa
como a porta de origem para a conversação. A porta de destino será geralmente o número de
porta Conhecida ou Registrada designado ao processo do servidor.

Números de porta de origem randomizados também ajudam na segurança. Se há um padrão
previsível para seleção da porta de destino, um intruso pode simular um acesso a um cliente mais
facilmente tentando conectar-se ao número de porta mais provável de ser aberto.

Por não haver sessão a ser criada com o UDP, tão logo os dados estejam prontos para serem
enviados e a portas identificadas, o UDP pode formar o datagrama e passá-lo para a camada de
Rede para ser endereçado e enviado pela rede.

Lembre-se, uma vez que o cliente escolheu as portas de origem e destino, o mesmo par de



portas é usado no cabeçalho de todos os datagramas da transação. Para dados que retornam
para o cliente a partir do servidor, os números de porta de origem e destino no cabeçalho do
datagrama são invertidos.

Página 2:
Nesta atividade, verifique como o DNS usa o UDP.


4.5 Atividades de Laboratório
4.5.1 Observando TCP e UDP usando Netstat

Página 1:
Nesta sessão de laboratório, você examinará o comando netstat (network statistics utility) em um
computador host, e ajustará as opções de saída do netstat para analisar e entender o status do
protoloco da camada de Transporte TCP/IP.

Clique no ícone do Laboratório para ver mais detalhes.

4.5.2 Protocolos da Camada de Transporte TCP/IP, TCP e UDP

Página 1:
Nesta sessão de laboratório, você usará o Wireshark para capturar e identificar os campos do
cabeçalho TCP, a operação durante uma sessão FTP, e campos do cabeçalho UDP e operação
durante uma sessão TFTP.


4.5.3 Protocolos das Camadas de Aplicação e Transporte

Página 1:
Nesta sessão de laboratório, você usará o Wireshark para monitorar e analisar as comunicações
da aplicação cliente (FTP e HTTP) entre um servidor e clientes.


Página 2:
Nesta atividade, você usará o modo de Simulação de Packet Tracer para capturar e analisar uma
solicitação web usando uma URL.




4.6 Resumo do Capítulo
4.6.1 Resumo e Revisão

Página 1:
A camada de Transporte provê as necessidades da rede de dados através de:

z Divisão de dados recebidos de uma aplicação em segmentos
z Adição de um cabeçalho para identificar e gerenciar cada segmento
z Uso da informação do cabeçalho para reagrupar os segmentos de volta nos dados da
aplicação
z Transmitir os dados agrupados para a aplicação correta

O UDP e o TCP são os protocolos da camada de Transporte mais comuns.

Os datagramas UDP e os segmentos TCP têm cabeçalhos pré-fixados aos dados que incluem o
número de porta de origem e o número de porta de destino. Estes números de porta habilitam os
dados a serem redirecionados para a aplicação correta sendo executada no computador de
destino.

O TCP não passa qualquer dado para a rede até que saiba que o destino está pronto para
recebê-lo. O TCP então gerencia o fluxo de dados e reenvia quaisquer segmentos de dados que
não são confirmados conforme sejam recebidos no destino. O TCP usa mecanismos de
handshake triplo, temporizador e confirmações, e janelamento dinâmico para alcançar estas
características confiáveis. Esta confiabilidade, no entanto, impõe uma sobrecarga na rede em
termos de cabeçalhos de segmentos muito maior e mais tráfego de rede entre a origem e o
destino no gerenciamento do transporte de dados.

Se os dados da aplicação precisam ser entregues rapidamente pela rede, ou se a largura de
banda da rede não suporta a sobrecarga ou overhead de mensagens de controle sendo trocadas
entre os sistemas de origem e destino, o UDP será o protocolo da camada de Transporte
preferido pelo programador. Devido ao fato do UDP não rastrear ou confirmar o recebimento de
datagramas no destino - ele apenas passa os datagramas recebidos para a camada de Aplicação
à medida que eles chegam - e não reenvia datagramas perdidos. No entanto, isto não significa
necessariamente que a comunicação em si não seja confiável; pode haver mecanismos nos
protocolos e serviços da camada de Aplicação que processam datagramas perdidos ou com
atraso se a aplicação tem estas necessidades.

A escolha do protocolo da camada de Transporte é feito pelo programador da aplicação para
melhor satisfazer as necessidades do usuário. O programador tem em mente que, apesar disso,
todas as outras camadas têm um papel nas comunicações de rede de dados e influenciarão o
seu desempenho.

Página 2:

Página 3:
Nesta atividade, processo que ocorre cada vez que você solicita uma página web da Internet - a
interação DNS, HTTP, UDP e TCP - é examinada em profundidade.

Instruções de Integração de Habilidades do Packet Tracer (PDF)




Página 4:
Para aprender mais

Questões para Reflexão

Discuta as necessidades de uma aplicação da camada de Aplicação que determine se o
programador selecionou o UDP ou o TCP como o protocolo da camada de Transporte a ser
usado.

Se uma aplicação de rede exigiu que seus dados sejam entregues confiavelmente, discuta como
o UDP poderia ser usado como protocolo da camada de Transporte e sob quais circunstâncias
isso seria usado.

Links

Introdução a Conexão de Redes

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm

4.7 Teste do Capítulo
4.7.1 Teste do Capítulo

Página 1:

Ir para a próxima
Ir para a anterior
Rolar Para o Topo

All contents copyright © 2007-2009 Cisco Systems, Inc. | Translation courtesy of: Fundação Bradesco
& NCE - UFRJ. Sobre


Camada de Transporte e suas funções

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Semelhante a Camada de Transporte e suas funções

Semelhante a Camada de Transporte e suas funções (20)

Camada de Transporte e suas funções