Fatec................

Apostila de Fundamentos de redes de Computadores.

Disciplina do Curso de Análise e Desenvolvimento de Sistemas

Disciplina do Curso Gestão de Tecnologia da Informação

Prof. Carlos Aragão

 Fatec................ 2

Este material está baseado e foi extraído do curso CCNA da Cisco Network Academy, Fundamentos de Redes
versão 1.0

Objetivos do programa

A disciplina apresenta uma variedade de tópicos para desenvolver as habilidades e compreensão dos alunos
sobre redes, apresenta dispositivos de rede e o software Cisco IOS®. Os alunos aprenderão como as redes
são configuradas, como os dispositivos são configurados, como a comunicação ocorre em uma rede e os
princípios básicos da implementação de práticas recomendadas de segurança de rede que aumentam a
confiança dos alunos na comunicação de seus conhecimentos e trabalho em profissões relacionadas a redes.

O material apresentado a seguir, refere-se somente ao capítulo 4 do curso, visto que esta é a principal
abordagem que faremos ao longo do semestre.

Assim, esta apostila ajuda você, caro aluno na compreensão dos termos aplicados e facilita nos estudos.

Tópicos abordados:

1.1. Propósito da camada de transporte 3

1.2. Controle das conversações 6
1.3. Suporte de comunicação confiável 8
1.4. TCP e UDP 9
1.5. Endereçamento de Porta 10
1.6. Segmento e reagrupamento – Dividir e conquistar 13
2.1. TCP – Tornando as conversações confiáveis 14
2.2. Processos TCP em Servidores 15
2.3. Estabelecimento e término de conexões TCP 16
2.4. Handshake Triplo TCP 17
2.5. Encerramento de sessão TCP 20
3.1. Reagrupamento de Segmentos TCP 21
3.2. Retransmissão TCP 23
3.3. Controle de congestionamento TCP – Minimizando a perda de segmentos 24
4.1 UDP – Baixo overhead versus confiabilidade 26
4.2. Reagrupamento de datagramas – UDP 42
4.3. Solicitações UDP e Processos de servidores 28
4.4. Processos de cliente UDP 29
5.1. Questões de revisão 29
6.1 Teste do capítulo 30
 Fatec................ 3

1.1. Propósito da camada de transporte

A camada de Transporte proporciona a segmentação de dados e o controle necessário para reagrupar esses
segmentos em fluxos de comunicação. Suas responsabilidades primárias para realizar isto são:

Rastrear a comunicação individual entre as aplicações nos hosts de origem e destino.

Segmentar dados e gerenciar cada segmento

Reagrupar os segmentos em fluxos de dados de aplicação

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 serem enviados 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.
 Fatec................ 4

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.

Figura 1 Habilitando Aplicativos em Dispositivos para a Comunicação

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.
 Fatec................ 5

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 ocasionadas de partes de uma conversa telefônica podem ser consideradas
aceitáveis. 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.

Conforme foi explicado anteriormente, 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, habilitam 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.

Figura 2 Segmentação dos dados na camada de transporte

 Fatec................ 6

1.2. Controle das conversações

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 - Pode haver muitas aplicações ou serviços sendo executados em cada host na
rede. Cada uma destas aplicações ou serviços é designada 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:

 Conversações orientadas à conexão

 Entrega Confiável
 Reconstrução de dados ordenados
 Controle de Fluxo

Figura 3 Segmentação dos dados na camada de transporte

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.
 Fatec................ 7

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 todos 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 seqüenciamento 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.

Figura 4 Alguns protocolos da camada de transportes são responsáveis por algumas tarefas
 Fatec................ 8

1.3. Suporte de comunicação confiável

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:

 Rastreamento de dados transmitidos

 Confirmação de dados recebidos
 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 falhar 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.
 Fatec................ 9

Figura 5 Os programas de Aplicação escolhem o protocolo da Camada de Transporte

1.4. TCP e UDP

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. Os 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 entregas ordenadas, 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 6 para uma
comparação.
 Fatec................ 10

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

 Navegadores web
 E-mail
 FTP

Figura 6 Comparação em cabeçalho UDP e TCP

1.5. Endereçamento de Porta

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
 Fatec................ 11

80, a menos que 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.

Figura 7 Endereçamento de porta

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:

 Fatec................ 12

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
programadas 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.
 Fatec................ 13

Figura 8 Números de Portas

Às 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 pode 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.

 Fatec................ 14

Figura 9 Exemplo de saída do comando Netstat

1.6. Segmento e reagrupamento – Dividir e conquistar

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.
 Fatec................ 15

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.

Figura 10 Funções da Camada de Transporte

2.1. TCP – Tornando as conversações confiáveis

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 11. Estes campos serão discutidos mais tarde nesta seção.
 Fatec................ 16

Figura 11 Campos do cabeçalho do segmento TCP

2.2. Processos TCP em Servidores

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. Pode 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 13 mostra a alocação típica de portas de origem e destino em operações cliente/servidor TCP.
 Fatec................ 17

Figura 12 Funções da Camada de Transporte

2.3. Estabelecimento e término de conexões TCP

Quando dois hosts se comunicam usando o TCP, uma conexão é estabelecida antes que os dados possam ser
trocados. Depois de a 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 figura13 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çalho TCP indicam o progresso e o status da conexão.
O handshake triplo:

Estabelece que o dispositivo de destino esteja presente na rede

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.

Informa o dispositivo de destino que o cliente de origem pretende estabelecer uma sessão de comunicação
nesse 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 seqüencial
recebido mais 1, mais seu próprio valor seqüencial de sincronização. O valor é maior do que o número
seqüencial 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.
 Fatec................ 18

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.

Figura 13 Processo de quatro etapas na conexão TCP

2.4. Handshake Triplo TCP

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), é
 Fatec................ 19

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 14, 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.

Figura 14 Handshake triplo TCP (SYN)

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
 Fatec................ 20

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 15, 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.

Figura 15 Handshake triplo TCP (SYN ACK)

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 16, 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:

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

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

Figura 16 Handshake triplo TCP (ACK)

2.5. Encerramento de sessão TCP

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
 Fatec................ 22

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 17, 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.

Figura 17 Encerramento da Sessão TCP (FIN)

3.1. Reagrupamento de Segmentos TCP

Refazendo o Seqüenciamento 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 é
 Fatec................ 23

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 18.

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.

Figura 18 Segmentos TCP são reordenados no Destino

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.
 Fatec................ 24

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 19, 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.

Figura 19 Reconhecimento do Segmento TCP

3.2. Retransmissão TCP

 Fatec................ 25

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 seqüenciais
contíguos. Se estiver faltando um ou mais segmentos, 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.

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.

3.3. Controle de congestionamento TCP – Minimizando a perda de segmentos

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 20 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
 Fatec................ 26

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.

Figura 20 Reconhecimento de Segmento TCO e Tamanho da Janela

Redução do Tamanho de Janela

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 freqüentemente. Isto diminui efetivamente a velocidade da taxa de transmissão porque a
origem espera que os dados sejam confirmados mais freqüentemente.

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
 Fatec................ 27

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âmicos 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

Figura 21 Congestionamento de TCP e Controle de Fluxo

4.1 – UDP – Baixo overhead versus confiabilidade

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,
seqüenciamento e controle de fluxos 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.
 Fatec................ 28

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:

 Domain Name System (DNS)

 Simple Network Management Protocol (SNMP)
 Protocolo de Configuração Dinâmica de Host (DHCP)
 Routing Information Protocol (RIP)
 Trivial File Transfer Protocol (TFTP)
 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.

Figura 22 Transporte de Dados auxiliares UDP

4.2. Reagrupamento de datagramas – UDP

Por causa de o UDP ser sem conexão, as sessões não é estabelecido 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.
 Fatec................ 29

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.

Figura 23 UDP: Sem conexão e não seguro

4.3. Solicitações UDP e Processos de servidores

Do mesmo modo que com as aplicações baseadas em TCP, às 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.
 Fatec................ 30

Figura 24 Servidor UDP ouvindo Solicitações

4.4. Processos de cliente UDP

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 serem criados com o UDP, tão logo os dados esteja pronto 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.
 Fatec................ 31

Figura 25 Clientes enviando Solicitações UDP

5.1. Questões de revisão

1. Onde os processos da Camada de Transporte acontecem?

2. Quais são as responsabilidades da Camada de Transporte?
3. O que a segmentação fornece às comunicações?
4. Quais são as principais funções especificadas por todos os protocolos da camada de Transporte?
5. Em termos de rede o que é confiabilidade?
6. Liste três aplicações que use TCP.
7. Liste três aplicações que use UDP.
8. Quais são os diferentes tipos de números de porta?
9. O que está contido em cada cabeçalho de cada segmento ou data grama?
10. Qual é a finalidade de um número de seqüencia?
11. Qual seria a forma de melhorar a segurança em um servidor.
12. Descreva handshake triplo do TCP:
13. Para que os números de sequência do TCP são usados?
14. Explique uma confirmação esperada.
15. Após uma quantidade de tempo pré-determinada, o que o TCP faz quando não recebeu uma
confirmação?
16. A quantidade de dados que pode ser transmitida antes que uma confirmação TCP deva ser recebida é
referida como:
17. Liste os principais protocolos da camada de aplicação que usam UDP:
 Fatec................ 32

6.1. TESTE DO CAPÍTULO

1. Combine os números de porta do modelo TCP com o protocolo correto ligando as opções a esquerda
para os pontos apropriados a esquerda.

2. Associe as opções de acordo com as características do TCP e do UDP.

3. Na camada de transporte, qual dos seguintes controles é usado para evitar que o host transmissor
sobrecarregue os buffers de um host receptor?
a. Melhor esforço
b. Criptografia
c. Controle de fluxo
d. Compressão
e. Evitar congestionamento

4. Os sistemas finais usam números de portas para selecionar a aplicação correta. Qual é o número mais
baixo de porta que dinamicamente designado por um sistema host?
a. 1
b. 64
c. 128
d. 256
e. 512
f. 1024
 Fatec................ 33

5. Durante a transferência de dados, quais são as principais responsabilidades do host receptor? (escolha
duas.)
a. Throughput
b. Encapsulamento
c. Confirmação
d. Largura de banda
e. Remontagem

6. Em que camada do modelo TCP/IP o TCP opera?

a. Sessão
b. Transporte
c. Rede
d. Enlace

7. O que é que determina a quantidade de dados que uma estação emissora que roda TCP/IP pode
transmitir antes que seja necessário receber uma confirmação?
a. Tamanho do segmento
b. Taxa de transmissão
c. Largura de banda
d. Tamanho da janela
e. Número da sequência

8. Qual é o objetivo do número de sequência no cabeçalho TCP?

a. Reagrupar os segmentos em dados
b. Identificar o protocolo de camada de aplicação
c. Indicar o número do próximo byte esperado
d. Mostrar o número máximo de bytes permitido durante a sessão

9. Qual é o número de confirmação que deve ser enviado pelo receptor ilustrado no gráfico?

a. 3
b. 4
c. 5
d. 6
e. 7
f. 8
g. 9
 Fatec................ 34

10. Qual é o propósito do número de portas TCP/UDP

a. Indicar o início do handshake triplo
b. Remontar os segmentos na ordem correta
c. Identificar o número de pacotes de dados que podem ser enviados sem confirmação
d. Rastrear diferentes conversações que cruzam a rede simultaneamente

11. Descreva por que um desenvolvedor de aplicação pode escolher rodar uma aplicação sobre UDP em
vez de sobre TCP.

12. Por que o tráfego de voz e vídeo é frequentemente enviado por meio do UDP e não do TCP na Internet
de hoje? (dica: A resposta que procuramos não tem nenhuma relação com o mecanismo de controle
de congestionamento.)