Capítulo 4 - Camada de Transporte OSI

Prévia do material em texto

4 
 
Camada de Transporte OSI 
 
 
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: 
 Habilita a comunicação de múltiplas aplicações na rede ao mesmo tempo em um único dispositivo 
 Assegura que, se necessário, todos os dados sejam recebidos confiavelmente e em ordem pela aplicação correta. 
 Emprega mecanismos de tratamento de erros 
Objetivos 
Após o término deste capítulo, você será capaz de: 
 Explicar a necessidade da camada de Transporte. 
 Identificar o papel da camada de Transporte, visto que, ela proporciona a transferência fim-a-fim de dados entre aplicações. 
 Descrever o papel de dois protocolos TCP/IP da camada de Transporte: TCP e UDP. 
 Explicar as funções principais da camada de Transporte, incluindo confiabilidade, endereçamento de porta e segmentação. 
 Explicar como o TCP e o UDP gerenciam funções-chave. 
 Identificar quando é apropriado usar o TCP ou o UDP e apresentar exemplos de aplicações que usam cada um desses protoco-
los. 
 
 
 
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. 
 
 
4.0.1 INTRODUÇÃO AO CAPÍTULO 
4.1.1 PROPÓSITO DA CAMADA DE TRANSPORTE 
5 
 
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 congestionamento1 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 res-
ponsabilidade é 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. 
 
1 Estado de uma rede em que não há largura de banda suficiente para suportar a quantidade de tráfego na rede. 
6 
 
 
 
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 áudioa 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 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 recupe-
ração de erro e retransmissão de dados danificados. 
7 
 
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 Trans-
porte realizem diferentes funçõ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 - 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: 
 Conversações orientadas à conexão 
 Entrega Confiável 
 Reconstrução de dados ordenados 
 Controle de Fluxo 
 
4.1.2 CONTROLE DAS CONVERSAÇÕES 
8 
 
 
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 todos rastreiem os segmentos e 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. 
9 
 
 
 
 
 
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 Trans-
porte, 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, rastrea-
mento e retransmissão. Para suportar estas operações de confiabilidade, mais dados de controle2 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 Trans-
porte, 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 
 
2 Dados que guiam um processo. Uma flag num quadro de enlace de dados é um exemplo de controle. 
4.1.3 SUPORTE DE COMUNICAÇÃO CONFIÁVEL 
10 
 
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 
retardono 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. 
 
 
 
 
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 proto-
colo 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 datagramas3 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 fluxo4. 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. 
 
3 Pacotes de dados que percorrem uma rede IP. 
4 O controle de fluxo é o gerenciamento do fluxo de dados entre os dispositivos de uma rede. É usado para evitar que dados demais cheguem antes que 
o dispositivo possa lidar com eles, causando sobrecarga de dados. 
4.1.4 TCD E UDP 
11 
 
As aplicações que usam TCP são: 
 Navegadores web 
 E-mail 
 FTP 
 
 
 
 
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 e o 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. Con-
tanto 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 é retor-
nada, 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. 
4.1.5 ENDEREÇAMENTO DE PORTA 
12 
 
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. 
 
A Internet Assigned Numbers Authority (IANA)5 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 conhecidas6 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 (P2P) 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. Às 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. 
 
 
 
5 Organização responsável por alocar os endereços de Protocolo de Internet para os provedores de Internet (ISPs). 
6 Portas com intervalo de 0 à 1023. 
13 
 
Portas TCP 
 
Portas UDP 
 
Portas comuns TCP/UDP 
 
À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 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 recur-
sos valiosos do sistema, reduzindo a velocidade de desempenho do host. O Netstat deve ser usado para examinar as cone-
xões abertas em um host quando o desempenho parecer comprometido. 
Muitas opções úteis estão disponíveis para o comando netstat. 
14 
 
 
 
 
 
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 esti-
vessem 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 sufi-
ciente 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. 
 
4.1.6 SEGMENTAÇÃO E REAGRUPAMENTO – DIVIDIR E CONQUISTAR 
15 
 
 
 
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. 
 
 Número de Porta de Origem – Sessão TCP no dispositivo que abriu a conexão – normalmente um valor aleatório acima de 
1023. 
 Número de Porta de Destino – Identifica o protocolo de camada superior ou a aplicação em local remoto 
 Número de Sequência – Especifica o número do último octeto (byte) em um segmento. 
 Número de Reconhecimento – Especifica o número do octeto seguinte esperado pelo receptor. 
 H. Length – Comprimento do cabeçalho – especifica o tamanho do cabeçalho do segmento em byte. 
 Reservados – Usado no gerenciamento e sessão e no tratamento de segmentos. 
 Tamanho da Janela – É o valor da janela dinâmica (quando octetos podem ser enviados antes da espera do reconhecimento). 
 Checksum TCP – Usado para verificação de erros no cabeçalho de dados. 
 Urgente Pointer – Usado somente com um sinalizador URG (urgente) flag. 
 Opções (se houver) – Informações Opcionais. 
 Dados – Dados da aplicação. 
 
 
 
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. 
4.2.1 TORNANDO AS CONVERSAÇÕES CONFIÁVEIS 
4.2.2 PROCESSOS TCP EM SERVIDORES 
16 
 
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 fornece 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. 
Portas de Destino de Solicitações 
 
Portas de Origem de Solicitações 
 
Portas de Destino de Respostas 
 
17 
 
Portas de Origem de Respostas 
 
 
 
 
Quando dois hosts se comunicam usando o TCP, uma conexão for 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çãosobre 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 han-
dshake triplo7. 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 está 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 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 
 
7 Processo que estabelece uma sessão TCP entre dois pontos finais. O processo é o seguinte. 1. Um cliente quer se comunicar com um servidor. O cliente 
envia um segmento com uma flag SYN marcada. 2. Em resposta, o servidor responde com um SYN-ACK. 3. O cliente envia um ACK (em geral chamado de 
SYN-ACK-ACK) de volta ao outro ponto e a sessão e estabelecida. 
4.2.3 ESTABELECIMENTO E TÉRMINO DE CONEXÕES TCP 
18 
 
 SYN - Sincronizar números de sequência8 
 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 for 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. 
SYN ACK 
 
FIN ACK 
 
 
 
 
 
 
8 Usados pelo TCP para assegurar que os segmentos não sejam perdidos. Cada segmento tem um número de sequência anexado a ele. Isso também 
permite que a estação receptora se certifique de que os dados são entregues na outra extremidade na ordem correta. 
19 
 
 
 
 
 
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 hexadecimal9. 
 
9 Sistema de enumeração em base 16 cujo caracteres começam com 0-9 e A-F (para representar 10-15). 
4.2.4 HANDSHAKE TRIPLO TCP 
20 
 
 
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ção10 é 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. 
 
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 
 
10 As confirmações são sinais enviados pelas estações de destino às estações de origem para confirmar a recepção dos dados. 
21 
 
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: 
 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 
Esta segurança pode ser implementada para todas as sessões TCP ou apenas para as sessões selecionadas. 
 
 
 
 
Para fechar uma conexão, a flag de fim de comunicação FIN (Finish)11 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 
termoscliente 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, confir-
mando que todos os bytes de dados foram recebidos. Quando todos os segmentos tiverem sido confirmados, a sessão for 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. 
 
11 Mensagem usada pelo TCP que é usada por um dispositivo que deseja terminar sua sessão com outro dispositivo. Isso é feito inserindo uma flag FIN no 
campo flag encontrado no segmento TCP. 
4.2.5 ENCERRAMENTO DA SESSÃO TCP 
22 
 
É 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. 
 
 
 
 
 
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 designa-
dos 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 repre-
senta 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 recebi-
dos, 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.1 REAGRUPAMENTO DE SEGMENTOS TCP 
23 
 
 
 
 
 
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 rece-
bimento 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. 
4.3.2 CONFIRMAÇÃO TCP COM JANELAMENTO 
24 
 
A quantidade de dados que a origem pode transmitir antes que uma confirmação seja recebida é chamada de tamanho da 
janela12. O Tamanho de Janela é um campo no cabeçalho TCP que habilita o gerenciamento de dados perdidos e controle de fluxo. 
 
 
 
 
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 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. 
 
12 O TCP usa o tamanho da janela para determinar o tamanho do número de segmentos enviados pelo dispositivo de envio antes do dispositivo receptor 
enviar uma confirmação. 
4.3.3 RETRANSMISSÃO TCP 
25 
 
 
 
 
 
 
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. 
4.3.4 CONTROLE DE CONGESTIONAMENTO TCP – MINIMIZANDO A PERDA DE SEGMENTOS 
26 
 
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 aumen-
tar. À 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. 
 
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 efeti-
vamente 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 infraestrutura 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 
27 
 
 
 
 
 
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: 
 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. 
 
4.4.1 UDP – BAIXO OVERHEAD VERSUS CONFIABILIDADE 
28 
 
 
 
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 apli-
caçõ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. 
 
 
 
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 seunúmero de porta. 
 
 
4.4.2 REAGRUPAMENTO DE DATAGRAMA UDP 
4.4.3 SOLICITAÇÃO UDP E PROCESSOS DE SERVIDORES 
29 
 
 
 
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. 
Solicitar Portas de Destino 
 
Solicitar Portas de Origem 
 
 
 
 
 
 
4.4.4 PROCESSOS DE CLIENTE UDP 
30 
 
Responder Portas de Destino 
 
Solicitar Portas de Origem 
 
 
 
 
A camada de Transporte provê as necessidades da rede de dados através de: 
 Divisão de dados recebidos de uma aplicação em segmentos 
 Adição de um cabeçalho para identificar e gerenciar cada segmento 
 Uso da informação do cabeçalho para reagrupar os segmentos de volta nos dados da aplicação 
 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 execu-
tada 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 so-
brecarga 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 
RESUMO 
31 
 
perdidos. No entanto, isto não significa necessariamente que a comunicação em si não seja confiável; pode haver mecanismos nos pro-
tocolos 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. 
 
 
 
 
1. Onde os processos da Camada de Transporte acontecem? 
Os processos da Camada de Transporte acontecem na Camada de Aplicação e na Camada de Internet do modelo TCP/IP, e 
entre as Camadas de Sessão e de Rede do modelo OSI. 
 
2. Quais as responsabilidades da Camada de Transporte? 
A Camada de Transporte é responsável por: 
 Manter a conversação entre os aplicativos nos hosts de origem e destino 
 Segmentar dados e adicionar um cabeçalho para identificar e gerenciar cada segmento 
 Usar as informações do cabeçalho para reunir os segmentos 
 Passar os dados reunidos ao aplicativo correto 
 
3. O que a segmentação fornece às comunicações? 
Segmentação de dados conforme a Camada de Transporte, fornece os meios para enviar e receber dados ao executar múltiplos 
aplicativos ao mesmo tempo em um computador. 
 
4. Quais são as funções principais especificadas por todos os protocolos da Camada de Transporte? 
As principais funções especificadas por todos os protocolos da Camada de Transporte incluem: 
 Multiplexação da Conversa – Pode haver muitos aplicativos ou serviços sendo executados em cada host na rede. A 
cada um destes aplicativos ou serviços é designado um endereço como uma porta para que a Camada de Transporte 
possa determinar com qual aplicativo ou serviço os dados são identificados. 
 Segmentação e Agrupamento – A maioria das redes tem uma limitação na quantidade de dados que podem ser 
incluídos em uma única PDU. A Camada de Transporte divide dados do aplicativo em blocos de dados que têm um 
tamanho apropriado. No destino, a Camada de Transporte reúne os dados antes de enviá-los à aplicação ou serviço 
de destino. 
 Verificação de Erro – A verificação de erro pode ser desempenhada nos dados do segmento para determinar se os 
dados foram modificados durante a transmissão. 
 
5. Em termos de rede, o que é confiabilidade? 
Em termos de rede, confiabilidade significa garantir que cada segmento que a origem envie chegue ao destino. 
 
6. Liste três aplicativos que usam TCP. 
Aplicações que usam TCP incluem: 
 Navegação 
 E-Mail 
 Transferência de arquivos 
 
QUESTIONÁRIO 
32 
 
7. Liste três aplicações que usam UDP. 
Aplicações que usam UDP incluem: 
 Domain Name System (DNS) 
 Vídeo de Stream 
 Voz sobre IP (VoIP) 
 
8. Quais são os diferentes tipos de número de portas? 
Os diferentes tipos de números de portas são: 
 Portas Conhecidas (Números 0 a 1023) – Estes números são reservados para serviços e aplicativos. Eles são comu-
mente usados para aplicações como HTTP (servidor web) POP3/SMTP (servidor de e-mail) e Telnet. Definindo estas 
portas conhecidas para aplicações do servidor, aplicações do cliente podem ser programadas para solicitar uma co-
nexão para aquela 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 
do usuário. Estas são basicamente aplicações individuais que um usuário escolheu para instalar ao invés de aplicações 
comuns, aplicações universais que receberiam uma Porta Conhecida. 
 Portas Dinâmicas ou Privadas (Números 49152 a 65535) – Também conhecidas como Portas Efêmeras, elas são 
normalmente designadas dinamicamente às aplicações do cliente ao iniciar uma conexão. Não é muito comum para 
um cliente conectar a um serviço usando uma Porta Dinâmica ou Privada (apesar de alguns programas peer-to-peer 
de compartilhamento de arquivos usarem). 
 
9. O que está contido no cabeçalho de cada datagrama ou segmento? 
O número de porta de origem e destino. 
 
10. Qual a finalidade de um número de sequência? 
Um número de sequência permite que as funções da Camada de Transporte no host de destino reúnam segmentos na ordem 
na qual elasforam transmitidas. 
 
11. Qual seria uma forma de melhorar a segurança em um servidor? 
Uma forma de melhorar a segurança é restringir o acesso ao servidor apenas para aquelas portas associadas aos serviços e 
aplicações que devem ser acessíveis a solicitantes autorizados. 
 
12. Descreva o handshake triplo do TCP. 
O handshake triplo: 
 Estabelece que o dispositivo de destino está presente na rede 
 Verifica que o dispositivo de destino tem um serviço ativo e está aceitando solicitações no número da porta de destino 
que o cliente inicial pretende usar para sessão 
 Informar ao dispositivo de destino que o cliente de origem pretende estabelecer uma sessão de comunicação naquele 
número de porta 
 
13. Para que os números da sequência do TCP são usados? 
Para que a mensagem original seja entendida pelo destinatário, os dados do segmentos devem ser reunidos na ordem original. 
 
14. Explique a confirmação de espera. 
O TCP usa o número de confirmação em segmentos enviados de volta à origem para indicar o próximo byte nesta sessão que 
o destinatário espera receber. 
 
15. Após uma quantidade de tempo pré-determinada, o que o TCP faz quando não recebeu informações? 
Quando o TCP no host de origem não recebeu uma confirmação após uma quantidade pré-determinada de tempo, ele voltará 
ao último número de confirmação que recebe e retransmitirá novamente os dados daquele ponto em diante. 
 
16. A quantidade de dados pode ser transmitida antes que uma confirmação TCP deve ser recebida é referida como. 
O tamanho da janela. 
 
17. Liste os principais protocolos da Camada de Aplicação que usam UDP. 
 Domain Name System (DNS) 
 Simple Network Management Protocol (SNMP) 
 Protocolo DHCP 
 Protocolo RIP 
 Protocolo TFTP 
 Jogos online 
33 
 
 
4.0.1 INTRODUÇÃO AO CAPÍTULO 4 
4.1.1 PROPÓSITO DA CAMADA DE TRANSPORTE 4 
4.1.2 CONTROLE DAS CONVERSAÇÕES 7 
4.1.3 SUPORTE DE COMUNICAÇÃO CONFIÁVEL 9 
4.1.4 TCD E UDP 10 
4.1.5 ENDEREÇAMENTO DE PORTA 11 
4.1.6 SEGMENTAÇÃO E REAGRUPAMENTO – DIVIDIR E CONQUISTAR 14 
4.2.1 TORNANDO AS CONVERSAÇÕES CONFIÁVEIS 15 
4.2.2 PROCESSOS TCP EM SERVIDORES 15 
4.2.3 ESTABELECIMENTO E TÉRMINO DE CONEXÕES TCP 17 
4.2.4 HANDSHAKE TRIPLO TCP 19 
4.2.5 ENCERRAMENTO DA SESSÃO TCP 21 
4.3.1 REAGRUPAMENTO DE SEGMENTOS TCP 22 
4.3.2 CONFIRMAÇÃO TCP COM JANELAMENTO 23 
4.3.3 RETRANSMISSÃO TCP 24 
4.3.4 CONTROLE DE CONGESTIONAMENTO TCP – MINIMIZANDO A PERDA DE SEGMENTOS 25 
4.4.1 UDP – BAIXO OVERHEAD VERSUS CONFIABILIDADE 27 
4.4.2 REAGRUPAMENTO DE DATAGRAMA UDP 28 
4.4.3 SOLICITAÇÃO UDP E PROCESSOS DE SERVIDORES 28 
4.4.4 PROCESSOS DE CLIENTE UDP 29 
RESUMO 30 
QUESTIONÁRIO 31