Unidade_05_redes_computadores

Prévia do material em texto

Redes de Computadores 
Prof. M.Sc Fabiano Costa Teixeira 
U N I D A D E 5 
 5 Camada de Transporte 
 5.1 Considerações Iniciais 
Nesse ponto do curso já foram apresentados alguns conceitos sobre os meios físicos para 
transmissão de dados entre computadores, mecanismos e tecnologias para a comunicação entre nós 
adjacentes e o protocolo que permite que computadores em redes distintas e espalhadas por todo 
mundo possam trocar dados entre si. 
Serão apresentados aqui dois protocolos de transporte: TCP e UDP. É interessante observar 
que é comum que redes sejam tratadas como TCP/IP. Qual o motivo dessa notação? Se o modelo de 
camadas for observado, nota-se que a camada de transporte está localizada acima da camada de 
rede. Dessa forma, a notação TCP/IP deve ser entendida como TCP sobre IP. 
Na camada de transporte será visto como é possível realizar o controle fim-a-fim em uma 
transmissão de dados, como é possível auxiliar a redução de congestionamentos, permitir que 
diversas aplicações sejam executadas simultaneamente utilizando um único endereço IP, entre 
outros. 
Essa é a última camada antes de iniciar os estudos sobre as aplicações propriamente ditas. 
Isso significa que até esse ponto os conceitos são os mesmos para as aplicações que estejam 
utilizando a mesma tecnologia de enlace e protocolos de rede e transporte, caracterizando um 
estudo fundamental que deve ser muito bem assimilado. 
Essa unidade foi escrita de forma conjunta pelos professores Fabiano Costa Teixeira e Iran 
Calixto Abrão tendo como base os livros citados nas referências bibliográficas abaixo. Dessa forma, 
é de grande importância a leitura dessas obras para aprofundamento no tema. 
 
 5.2 Protocolo de Portas 
É comum que em uma mesma máquina diversas aplicações estejam trocando dados com a 
rede ao mesmo tempo. Se for observada a máquina de um usuário em um determinado momento é 
fácil verificar, por exemplo, que ele está com uma janela do navegador acessando o site da PUC e 
outra janela acessando a página do UOL, além de estar conversando com algum contato por meio 
do MSN. Nesse cenário, existem três computadores (PUC Minas, UOL e MSN) enviando dados 
para a mesma máquina que possui um único endereço IP. Aqui cabe uma questão: Todos os 
datagramas são destinados ao mesmo endereço IP. Como o sistema operacional sabe para qual 
aplicação o dado deve ser entregue? 
Uma situação parecida com essa ocorre na vida real com pessoas que moram em prédios. 
Todas elas possuem o mesmo endereço como, por exemplo, Rua Assis Figueiredo – 18.599, Centro, 
Poços de Caldas. Todas as cartas destinadas a essas pessoas são entregues na portaria do mesmo 
prédio, mas como elas são encaminhadas ao destinatário correto? Por meio do número do 
apartamento. 
Algo semelhante a isso é realizado pela camada de transporte por meio da multiplexação de 
portas. Para cada aplicação que faça uso da rede é associada um número de porta. Dessa forma, as 
mensagens que são recebidas pela camada de transporte possuem um campo informando para qual 
porta a mensagem está endereçada. Com isso, sabe-se para qual aplicação o conteúdo da mensagem 
deve ser entregue. 
 
Figura 1: Multiplexação de portas 
A figura 1 ilustra um exemplo da execução concorrente de 5 aplicações. Note que cada uma 
delas está associada a uma porta diferente. Dessa forma, quando o dado chegar na camada de 
transporte essa sabe para quem entregá-lo. 
Os números de portas até 1024 são reservados para aplicações “bem conhecidas”. A tabela 
abaixo (baseada em [1]) ilustra algumas dessas portas. Se uma nova aplicação é desenvolvida, pode-
se utilizar um número acima desse especificado para identificá-la junto à camada de transporte. 
Porta Protocolo Uso 
21 FTP Transferência de Arquivos 
23 Telnet Login remoto 
25 SMTP Envio de correio eletrônico 
80 HTTP WWW 
110 POP-3 Recebimento de correio eletrônico 
 
Cada protocolo de transporte realiza a sua multiplexação de portas de forma independente. 
Isso significa que a porta 100 do protocolo TCP é diferente da porta 100 do protocolo UDP. Jamais 
duas aplicações podem utilizar a mesma porta de um mesmo protocolo, no entanto duas aplicações 
diferentes que utilizam protocolos de transporte diferentes podem utilizar o mesmo número de 
porta. 
 5.3 Protocolo TCP 
O protocolo TCP (Transmission Control Protocol) é um protocolo de transporte que 
implementa alguns mecanismos que disponibilizam um ambiente adequado para a transmissão de 
dados de determinadas aplicações pela Internet (e também em redes locais), pois são oferecidos 
garantia de entrega e ordenação de dados, controle de fluxo e congestionamento, entre outros. 
As aplicações que comunicam entre si trocam os dados em formato de segmentos [1]. Cada 
segmento possui um cabeçalho de 20 bytes e a área de dados. Muitas vezes diversas requisições de 
transmissão diferentes tem seus dados inseridos em um único segmento, ao passo que também é 
possível que os dados de uma única requisição sejam inseridos em segmentos diferentes. Isso 
significa que o TCP implementa uma transmissão por fluxo de bytes onde não há uma demarcação 
que diferencie as diversas solicitações de transmissão feitas pelo transmissor, sendo necessário 
algum protocolo na camada de aplicação que seja responsável por esse tratamento. 
O tamanho dos segmentos é calculado em função do tamanho da carga útil do protocolo IP 
(onde o segmento é inserido na seqüência de encapsulamentos) e do MTU da rede. Dessa forma, é 
comum que os segmentos TCP possuam o tamanho de 1460 bytes, considerando o MTU da 
tecnologia Ethernet que é de 1500 bytes e os tamanhos dos cabeçalhos IP e TCP que possuem 20 
bytes cada. 
Uma vez que a camada de rede implementada pelo protocolo IP não oferece um ambiente 
confiável de transmissão, pacotes podem ser perdidos como também entregues fora de ordem por 
problemas como, por exemplo, congestionamento de partes da rede que fazem com que 
determinados pacotes sejam atrasados e entregues fora de ordem (lembre-se da forma de comutação 
do IP que permite uma rota diferente para cada datagrama). O protocolo TCP tem a missão de 
solucionar essas questões. 
A questão da garantia de entrega é resolvida por meio do estabelecimento de uma mensagem 
de confirmação de recebimento (ack) e de um timer que determina qual o tempo máximo que o 
receptor deve aguardar pelo recebimento dessa confirmação. Caso ela não chegue o dado é 
retransmitido. 
O problema da ordenação dos dados é realizado inserindo um número de seqüência em cada 
segmento. Se segmentos são entregues fora de ordem o TCP observa esse número de seqüência e os 
colocam na ordem original novamente. Esse número de seqüência tem uma função adicional: pode 
acontecer de um datagrama IP ter um retardo muito grande um uma parte da rede, demorar a chegar 
no receptor e ocasionar uma retransmissão dos dados. No entanto, os dados retransmitidos serão 
recebidos pelo receptor como também os dados atrasados, que são idênticos. Para evitar a 
duplicidade o TCP observa que foram recebidos dois segmentos com o mesmo número de 
seqüência e descarta a duplicata. 
5.3.1 Conexões 
O protocolo TCP adota o modelo de cliente/servidor. Uma aplicação assume um papel 
passivo (servidor) e outra o papel ativo (cliente). Antes de iniciar a transmissão dos dados 
propriamente ditos o cliente precisa realizar a requisição de conexão junto ao servidor que deve 
aceitá-la ou rejeitá-la. 
Esse processo conexão, entre outros, tem um papel muito importante relacionado ao número 
de seqüência de mensagens. A questão das mensagens atrasadas gera um problema a ser tratado. 
Imagine que uma cliente estabeleceu uma conexão Ca com um servidor e enviou três segmentos 
com as seqüências 0, 1 e 2. A mensagem 1 se atrasou muito e foi retransmitida, sendo que o 
segmento da retransmissão foi entregue a atrasadacontinuou presa em um roteador. A transmissão 
termina e a conexão é encerrada. Após isso, o cliente realiza outra conexão Cb com o servidor e 
envia três mensagens também de seqüência 0, 1, 2 e 3. A mensagem 0 é entregue e logo após isso a 
mensagem atrasada da conexão anterior é “liberada” e chega ao receptor, que “pensa” que essa 
mensagem faz parte da conexão atual (pois não existe identificador de conexões nos segmentos) e a 
aceita. Quando a seqüência 1 da conexão atual é recebida, o receptor considera como mensagem 
repetida e a descarta. Note que nesse caso houve o processamento equivocado dos dados. 
Como é fácil de ser percebido, começar a transmissão de dados de uma conexão pela 
seqüência zero gera problemas. Uma maneira de solucionar esse problema é fazer com que as 
conexões utilizem intervalos distintos de seqüência de segmentos. No entanto, ambas as partes 
(cliente e servidor) precisam saber com qual seqüência a outra parte irá começar para que o controle 
possa ser estabelecido. Essa é uma das principais funções do processo de estabelecimento de 
conexões. 
Conforme ilustrado pela figura 2, o processo de conexão é estabelecido em três etapas, por 
isso é denominado de Handshake em 3 vias. 
 
Figura 2: Handshake em 3 vidas 
 
Considere o Host 1 como cliente e o Host 2 como servidor. Para realizar a requisição de 
conexão o cliente envia um segmento TCP contendo o flag SYN do cabeçalho definido com o valor 
1. Ao receber essa mensagem o servidor identifica que é um pedido de conexão e pode rejeitá-lo 
(enviando uma mensagem TCP com o flag RST com valor 1 para o cliente) ou aceitar respondendo 
ao cliente com uma nova mensagem com o flag SYN também ativo. 
Quando o cliente envia o pedido de conexão ele já informa ao servidor qual será é o número 
de seqüência inicial (SEQ=x) e o mesmo é feito pelo servidor (SEQ=Y). 
A mensagem de pedido de conexão é transportada por um datagrama IP normalmente, 
podendo ser atrasada, perdida, etc. Dessa forma, é importante que quem recebe uma mensagem 
confirme seu recebimento. Nessa situação seriam, em um primeiro momento, necessárias quatro 
mensagens: o envio do SYN do cliente para o servidor, a confirmação do recebimento pelo servidor, 
o envio do SYN do servidor para o cliente e a confirmação do recebimento pelo cliente. No entanto, 
repare que quando o servidor envia o SYN para o cliente ele já envia junto a notificação ACK, o 
que economiza uma mensagem. Dessa forma, apenas o cliente precisa enviar uma mensagem 
exclusiva de confirmação do recebimento do SYN enviado pelo servidor, gerando um processo 
constituído por três mensagens. 
Quando uma mensagem de confirmação (ACK) é enviada sempre se notifica o número se 
seqüência recebido mais um, isso porque o TCP não “diz” qual seqüência ele recebeu”. Mas sim, 
quem é a próxima seqüência que ele espera receber. Isso será melhor detalhado a seguir. 
As conexões TCP são full-duplex, dessa forma pode-se imaginá-las como um canal no 
sentido cliente/servidor e outro no sentido servidor/cliente. Cada um desses canais pode ser 
encerrado de maneira independente. Sendo assim, se o cliente não deseja mais enviar informações 
para o servidor ele envia uma mensagem com o flag FIN ativo e aguarda por uma confirmação 
(ack). Nesse caso, o servidor ainda pode continuar enviando dados para o cliente até que seja 
enviada uma mensagem de FIN encerrando esse canal também. Quando ambos os canais são 
encerrados, a conexão se dá por finalizada. Por isso, para encerrar uma conexão são necessárias 
quatro mensagens: duas de FIN e duas confirmações (ack). 
A figura 3 apresenta um diagrama de estados finitos que demonstra os processos de conexão 
e desconexão do TCP. A aplicação servidora (com as ações representadas pela linha tracejada) 
quando executada está com a conexão fechada. A aplicação, por meio de uma chamada de sistema, 
entra em estado de “listen” e começa a aguardar pelos pedidos de conexões. Quando um segmento 
com o flag SYN (passo 1 do handshake) é recebido o servidor responde com a mensagem SYN + 
Ack (passo 2 do handshake) e entra no estado “SYN RCDV” onde ele aguarda o recebimento do 
ACK que representa o passo 3 do handshake. Quando isso ocorre, a conexão está estabelecida. 
O cliente, representado pela linha contínua mais escura, possui o papel ativo do processo. 
Sendo assim, ele envia a primeira mensagem do processo de handshake (mensagem SYN) e fica no 
estado “SYN-Sent” até que receba a mensagem SYN+Ack do servidor (passo 2 do handshake). 
Quando isso ocorre ele envia o ACK referente ao passo 3 e também entra no estado de conexão 
estabelecida. 
Quando o cliente deseja realizar a desconexão ele envia uma mensagem FIN para o servidor 
solicitando o encerramento de um canal de comunicação. Até que o cliente receba o “ack” dessa 
mensagem ele permanece no estado FIN-Wait 1. Quando a confirmação é recebida ele passa para o 
estado FIN-Wait 2 aguardando que o servidor também solicite o encerramento. Quando isso 
acontece o cliente confirma o recebimento da mensagem do servidor e aguarda alguns instantes 
(estado TIMED Wait) para verificar se ainda existe algum segmento em trânsito. Após isso a 
conexão é encerrada e volta ao estado inicial. 
 
Figura 3: Máquina de estados finitos de uma conexão TCP 
5.3.2 Janela Deslizante 
Conforme já foi visto anteriormente, o mecanismo de garantia de entrega do TCP é baseado 
na confirmação (ack) que o receptor de uma mensagem envia ao emissor, o qual, após enviar um 
segmento, aguarda um determinado tempo pela confirmação. Caso a confirmação não chegue 
dentro do tempo esperado o segmento é retransmitido. 
Se o protocolo fosse implementado de tal forma que toda vez que o emissor enviasse uma 
mensagem ele tivesse que aguardar pelo recebimento da confirmação para continuar seu trabalho, o 
modo de transmissão seria logicamente transformado em half-duplex. Veja o exemplo da figura 4: o 
emissor envia o pacote 1 e permanece esperando a confirmação. Somente ao receber essa 
confirmação que ele envia o pacote 2. 
 
Figura 4: Exemplo de protocolo onde o emissor fica parado esperando a chegada do "ack" 
 
Esse tipo de protocolo tornaria a transmissão muito lenta, o que precisou ser melhor 
elaborado. Para isso, utiliza-se no protocolo TCP o conceito de janela deslizante, que define o 
número de segmentos que podem ficar com o “ack” pendente. Quando um segmento é enviado, o 
transmissor também dispara um temporizador (timer). Quando o segmento chega ao destino, a 
entidade TCP receptora retorna um segmento com um número de confirmação igual ao próximo 
número de seqüências que espera receber. Se o timer expirar antes da confirmação a ser recebida, o 
segmento será retransmitido. Este protocolo utiliza melhor a largura de banda da rede, pois permite 
que o transmissor transmita pacotes múltiplos antes de esperar uma confirmação. 
O mecanismo de janelas deslizantes TCP opera em nível de octetos, e não de pacotes ou 
segmentos. Os octetos do stream de dados (fluxo a ser transmitido) são enumerados 
seqüencialmente, e um transmissor mantém três ponteiros associados a cada conexão. Segundo 
Comer, O desempenho dos protocolos de janelas deslizantes depende do tamanho da janela e da 
velocidade com que a rede aceita os pacotes. 
O primeiro ponteiro marca a esquerda da janela deslizante, separando os octetos que tenham 
sido enviados e confirmados, dos octetos ainda por enviar. Um segundo ponteiro à direita da janela 
deslizante define o maior octeto da seqüência que pode ser enviado antes que mais confirmações 
sejam recebidas. O terceiro ponteiro marca o limite interno da janela que separa os octetos já 
enviados daqueles que ainda não o foram. 
 
Figura 5: Três ponteiros da janela deslizante 
Imagine uma seqüência de pacotes a serem transmitidos, conforme mostra a figura 6, onde um 
protocolo de janeladeslizante com oito pacotes na janela ( a ) e ( b ) a janela deslizando de modo 
que o pacote nove possa ser enviado quando for recebida uma confirmação para o pacote um, 
somente os pacotes que não forem confirmados serão retransmitidos. 
 
Figura 6: Exemplo de deslocamento da janela 
De forma geral, um protocolo de janela deslizante sempre se lembra de quais pacotes foram 
confirmados e mantém um timer separado para cada pacote confirmado. Se um pacote for perdido, 
o timer termina e o transmissor retransmite esse pacote. Quando o transmissor desliza sua janela, 
ele move para trás todos os pacotes confirmados. Na extremidade do receptor, o protocolo mantém 
uma janela análoga que aceita e confirma os pacotes à medida que chegam. Desta forma, a janela 
particiona a seqüência de pacotes em três conjuntos: 
• Os pacotes à esquerda da janela que foram transmitidos com êxito, recebidos e confirmados; 
• Aqueles à direita ainda não transmitidos; e 
• Os pacotes que permanecem na janela e que estão sendo transmitidos. 
Para entender melhor o funcionamento do protocolo de janelas deslizantes, utilize o aplicativo 
web: http://www2.rad.com/networks/2004/sliding_window/, link: Sliding Window Demo. 
 
5.3.3 Seqüência dos pacotes 
Cada segmento TCP enviado tem um número de seqüência para que o TCP no nó destino 
possa reordená-los na chegada. 
 
 Quando o nó destino recebe um segmento, envia uma confirmação através de um segmento 
TCP com o campo Acknowledge preenchido. Neste campo está o número de seqüência do próximo 
segmento esperado, indicando para o nó origem o correto recebimento, pelo nó destino, dos pacotes 
anteriores. 
O seqüenciamento dos pacotes TCP é orientado a byte. O número de seqüência do segmento é 
sempre igual ao numero de seqüência do segmento anteriormente transmitido, somado ao número 
de bytes transmitidos. O primeiro número de seqüência é gerado randomicamente, e é determinado 
no estabelecimento da conexão TCP, conforme visto na sub-seção que tratou do processo de 
conexão. 
 
 
A confirmação de entrega dos segmentos TCP é também orientada a byte. O valor do campo 
acknowledgement de um segmento é sempre igual ao número de seqüência do segmento que está 
sendo confirmado somado ao número de bytes recebidos. 
 
Este valor indica para o nó origem o número de seqüência do próximo segmento que o nó 
destino espera receber. 
O ACK pode ser cumulativo, sendo enviado após o recebimento de todos os segmentos. Neste 
caso, o valor do campo acknowledgement será a soma do ultimo número de seqüência confirmado 
com o número de bytes recebidos. 
 
Ao enviar um ACK para todo um conjunto de dados, se ganha tempo e se diminui a 
quantidade de pacotes transmitidos. Uma forma de não desperdiçar um pacote somente com um 
ACK é fazer com que este sejam acompanhado de dados, denominado ack piggybacking. 
 
5.3.4 Controle de Fluxo 
Muitas vezes a capacidade de um receptor não é suficiente para realizar o processamento de 
todos os dados recebidos. Muitas vezes é preciso que o emissor diminua o fluxo de dados enviados 
para que seja possível recebê-los corretamente. 
Como exemplo disso, pode-se citar uma situação onde há uma obra e um fornecedor de areia. 
Esse fornecedor transporta o material e o coloca na calçada em frente à obra. Se a taxa de transporte 
do fornecedor for maior que a capacidade que os funcionários tem para armazenar a areia no 
interior da obra, chegará um ponto que não caberá mais material em frente a obra, ocorrendo a 
perda do mesmo. 
Para resolver essa situação um funcionário da obra deve se encarregar de controlar o fluxo de 
transporte de areia. Dessa forma se ele nota que a calçada está ficando cheia ele pede para o 
caminhão trazer menos areia de cada vez e se mesmo assim continuar enchendo ele pode pedir para 
suspender a entrega por um tempo e depois reiniciar novamente. 
No ambiente computacional a areia são os dados, o caminhão os segmentos, a calçada o buffer 
de entrada do receptor e o funcionário que controla o fluxo o protocolo TCP. 
Para realizar esse controle o TCP utiliza o tamanho da janela, a qual está sempre relacionada 
ao tamanho do buffer de recepção do destinatário, e o seu valor inicial é informado quando do 
estabelecimento da conexão TCP. No diagrama a seguir, a estação de trabalho só poderá enviar ate 
2.000 bytes de dados ao servidor sem que haja recebimento de confirmação dos pacotes enviados. 
 
No entanto, o tamanho da janela do TCP é ajustado dinamicamente (a cada ack de 
confirmação é informado o novo tamanho de janela que o emissor precisa respeitar) de acordo com 
a disponibilidade de buffers no receptor. Este mecanismo implementa o controle de fluxo fim-a-fim: 
se o servidor detectar que a estação está enviando um número de pacotes maior do que sua 
capacidade de recepção, ele sinalizará no segmento de ACK ou de dados um valor menor para a 
janela TCP, forçando uma diminuição na taxa de transferência de pacotes. 
Essa janela pode ir sendo diminuída até o ponto de ser zerada, situação em que o emissor para 
de transmitir dados. Nesse caso, quando o receptor ver que a situação foi normalizada ele repete o 
segmento utilizado para zerar a janela para informar o novo tamanho. 
Uma pergunta pode ser feita nesse momento? E se esse segmento informando o novo tamanho 
de janela for perdido? O emissor fica parado para sempre? 
Para resolver esse problema, quando o emissor recebe um tamanho de mensagem zerada ele 
dispara um temporizador que define o tempo máximo que ele aguardará passivamente pelo novo 
tamanho de janela. Se ele não receber um novo segmento contendo apenas um byte (o que é 
permitido mesmo com a janela zerada) é enviado, o que forçará o receptor a enviar um ack com 
tamanho de janela para o emissor. Se a janela realmente continua zerada, um ack com janela de 
tamanho zero é enviado novamente. Caso o segmento foi realmente perdido, o tamanho da janela é 
enviado novamente, re-estabelecendo a transmissão. 
Esse comportamento da janela caracteriza o TCP como um protocolo com tráfego por rajadas. 
Pois, a janela aumenta e vários segmentos são enviados. Tempo depois ela pode ser diminuída e até 
zerada voltando a ter seu tamanho incrementado posteriormente. 
5.3.5 Controle de Congestionamento 
Até algum tempo atrás os pacotes eram perdidos na internet por muitos motivos: 
interferências, má qualidade dos meios de transmissão, entre outros [1]. Com o advento das 
tecnologias de comunicação (com grande peso da fibra ótica) a taxa de perda de dados em função 
do meio físico diminuiu muito. 
Atualmente, um dos grandes responsáveis pela perda de pacotes na internet é o 
congestionamento. Nesse caso, a taxa de recebimento de pacotes de um roteador é maior que a taxa 
de envio que ele é capaz. Sendo assim, os pacotes começam a entrar em fila, a qual é implementada 
em memória. Chega um ponto que a capacidade da fila se esgota é o roteador começa a descartar 
pacotes, caracterizando a perda. 
O TCP é um protocolo consciente. Quando ele repara que um segmento foi perdido ele 
pressupõe que a taxa de envio de segmentos que ele está operando é maior que aquela suportada 
pela rede. Sendo assim, ele começa a diminuir essa taxa com o objetivo de minimizar a situação de 
congestionamento. 
Para realizar esse controle o TCP opera com uma janela adicional chamada de “Janela de 
Congestionamento”. Essa janela define o fluxo de dados que um emissor pode enviar sem que a 
rede seja congestionada. No entanto, qual é o tamanho dessa janela? 
O protocolo TCP tem por objetivo realizar a transmissão dos dados na maior taxa possível 
sem saturar a rede. Dessa forma, ele parte de um tamanho de janela de congestionamento 
relativamente pequeno e vai aumentando até que algum segmento seja perdido. Quando isso 
acontece, a janela é reduzida novamente.Essa redução e crescimento da janela funciona de uma forma bem interessante. 
Normalmente a janela de congestionamento é iniciada com o tamanho máximo de um segmento. É 
interessante que o limite da rede seja encontrado o mais rápido possível para que a transmissão 
tenha uma boa vazão. Dessa forma, a janela de congestionamento cresce de forma exponencial, ou 
seja, para cada rajada confirmada o tamanho da janela é dobrado. 
Quando um time-out (situação em que o ack não chega dentro do tempo esperado) ocorre o 
TCP chega à conclusão de que o limite da rede para aquele instante está entre o penúltimo tamanho 
de janela e o último (lembre-se do crescimento exponencial). Nesse momento o tamanho da janela é 
reduzido ao valor inicial (o tamanho máximo do segmento) e tudo começa novamente. No entanto 
se ele for crescendo sempre de forma exponencial o limite não será encontrado novamente. 
Considere o exemplo: Uma rede está com uma carga onde o tamanho de janela de 
congestionamento ideal é de 60K. Supondo que a janela de congestionamento comece por 1K, seu 
crescimento exponencial faria com que os próximos tamanhos de janela fossem 2K, 4K, 8K, 16K, 
32K e 64K. Quando esse último fosse utilizado ocorreria o time-out e tudo começaria novamente. 
Se a janela crescesse da mesma forma ela “pularia” de 32K para 64K novamente gerando outro 
time-out. Adotar o último tamanho de janela confirmado (32K) como o ideal seria correto? A 
resposta é não, pois haveria um desperdício, pois a rede suporta 60K. 
Para solucionar isso, é considerada uma variável chamada limiar. Essa variável representa o 
tamanho da janela até onde o crescimento é exponencial, a partir dela o crescimento é realizado de 
forma linear. Qual será o valor do limiar? É simples: Quando ocorre um time-out o limiar é definido 
como a metade da janela atual. 
Veja o exemplo da figura 7. É considerado que nesse momento o limiar está definido com 
32K. Sendo assim, a janela cresce exponencialmente até esse valor e depois cresce linearmente até 
o valor de 40K, onde ocorre um time-out e o limiar é definido como a metade desse valor: 20K. 
Nesse momento é fácil perceber que o TCP trabalha com duas janelas: a janela do receptor 
(que define o controle de fluxo) e a janela de congestionamento. Sendo assim, o TCP sempre utiliza 
a menor das duas para definir o tamanho das rajadas. 
Um detalhe adicional também é importante ser verificado: a janela de congestionamento 
cresce no máximo até o tamanho da janela do receptor. 
 
Figura 7: Exemplo de comportamento da janela de congestionamento. Baseado em [1]. 
5.3.6 Temporizadores 
Durante essa unidade tem sido visto a utilização de um temporizador para definir o tempo 
que o TCP aguarda para retransmitir um segmento caso não receba a confirmação (ack). Esse tempo 
tem uma influência bastante grande no desempenho da transmissão. Se ele é definido com um valor 
muito pequeno pode acontecer de muitos segmentos serem recebidos corretamente, o ack ser 
enviado e o tempo expirar antes desse chegar, gerando muitas retransmissões desnecessárias, o que 
causa tráfego redundante. 
Por outro lado, se o tempo for muito grande haverá uma demora para que um segmento 
perdido seja retransmitido, gerando atrasos que também comprometeriam o desempenho da rede. 
De maneira a procurar o tempo mais próximo possível daquele existente entre o envio do 
segmento e o recebimento do ack (considerando as condições atuais da rede), o TCP trabalha com 
algumas variáveis. O RTT (Round Trip Time) é uma variável que tem o função de armazenar esse 
tempo. Toda vez que um segmento é enviado o TCP calcula o tempo gasto entre o envio e o 
recebimento da confirmação, o armazena na variável M e recalcula o RTT utilizando a fórmula [1]: 
RTT=αRTT + (1-α)M. A variável α tem a função de determinar o peso a ser dado para o tempo 
calculado em função das transmissões passadas (RTT) e o tempo gasto na última transmissão (M). 
Normalmente essa variável tem o valor de 7/8. 
O simples cálculo do RTT não é suficiente para determinar o tempo de retransmissão, pois a 
rede utilizada para transmitir os segmentos pode ser bastante instável e possuir uma variação 
considerável do tempo. Para resolver isso, o TCP faz algo parecido com uma estimativa do desvio 
médio existente no tempo de confirmação das transmissões dos segmentos. Esse desvio é 
representado pela variável D e é calculada, a cada transmissão de um novo segmento, pela fórmula: 
D = αD + (1- α) | RTT-M |. 
Uma vez calculadas essas variáveis é possível calcular o valor do temporizador de 
retransmissão pela fórmula: Timeout = RTT + 4D. A multiplicação do desvio (D) por quatro, 
segundo alguns estudos, diminui as retransmissões desnecessárias a um percentual bastante 
pequeno. 
5.3.7 Cabeçalho TCP 
O cabeçalho do protocolo TCP tem seu formato conforme a figura 8. 
 
Figura 8: Formato do cabeçalho TCP 
Os campos source port e destination port do cabeçalho contém respectivamente os endereços 
dos processos origem e destino. 
Cada segmento tem um número de seqüência (sequence number) para que o TCP destino 
possa ordenar a mensagem na chegada. No campo acknowledgement number tem-se o número do 
segmento esperado, que servirá para o nó origem identificar os segmentos anteriores que foram 
enviados com sucesso. 
O campo hlen indica o tamanho, em palavras de 32 bits, do cabeçalho TCP. Os seguintes bits, 
quando ligados, indicam o tipo de segmento: 
• URG - sinaliza eventos assíncronos. 
• ACK - indica que este segmento confirma a recepção de outro. 
• PSH - indica que este segmento requer urgência. 
• SYN - indica segmento de pedido de estabelecimento de sessão TCP. 
• RST - indica segmento de término de sessão TCP de forma abrupta. 
• FIN - indica segmento de termino de sessão TCP de forma natural. 
O campo checksum contém o resultado do cálculo do checksum do segmento TCP. O campo 
window define o tamanho, em bytes, da janela. Já o campo urgent pointer é usado para sinalizar 
eventos assíncronos através do envio de caracteres de controle ou de outros comandos de 
interrupção. 
 5.4 Protocolo UDP 
O UDP é um protocolo de transporte não orientado à conexão. Possui um cabeçalho, 
conforme ilustrado pela figura 9, menor que o TCP (8 bytes) e não faz o seqüenciamento dos 
pacotes, deixando esta tarefa a cargo da aplicação. 
Algumas características do UDP: 
• Não realiza confirmação fim-a-fim; 
• Não possui controle de fluxo. 
• Aplicações: SNMP, TFTP, DNS. 
• Formato do cabeçalho: Note na figura a seguir que o cabeçalho UDP é muito simples e por isso 
pequeno. Esta característica permite a flexibilidade necessária por algumas aplicações, como 
jogos em rede, por exemplo. 
 
Figura 9: Cabeçalho UDP 
Os endereços, ou ports UDP funcionam de forma similar aos ports TCP, pois ambos foram 
implementados para prover a camada de transporte do modelo TCPIP. 
 5.5 Considerações Finais 
Conforme deve ter sido notado, nessa unidade o enfoque maior foi TCP, pois ele é o 
protocolo de transporte de maior uso na internet atualmente, principalmente por ser aquele utilizado 
na Web. Por oferecer controles de fluxo, congestionamento, garantia de entrega, ordenação de 
pacotes, entre outros, seu mecanismo é muito mais complexo do que o UDP, cabendo assim mais 
estudo sobre ele. 
Nesse ponto as camadas do modelo TCP/IP responsáveis por permitir que aplicações 
troquem dados utilizando uma rede de computadores já foram abordadas. Sendo assim, na próxima 
unidade de ensino são abordadas as aplicações propriamente ditas, ilustrando como elas podem 
fazer uso de toda essa estrutura apresentada para oferecer ao usuários os serviços que eles precisam. 
Referências Bibliográficas 
[1] Tanenbaum, A.S.: “Redes de Computadores”, Terceira Edição, Elsevier, 2003. 
[2] Kurose, F., Ross, K: “Redes de Computadores e a Internet: UmaAbordagem Top-Down”, 
Quinta Edição, Addison-Wesley, 2010.