Infraestrutura de Comunicação (Camada de Transporte versão 2)

Prévia do material em texto

MÓDULO 3: Camada 
Transporte 
3.1 Serviços da camada transporte 
● A camada de transporte provê o 
transporte fim-a-fim lógico da 
camada de aplicação de um host 
até um servidor 
● Serviços e protocolos de transporte: 
− Proveem comunicação lógica 
entre processos aplicativos 
executando em hosts distintos. 
− Protocolos “rodam” em end 
systems 
o Lado emissor: quebra 
mensagens da 
aplicação em 
segmentos que são 
passados à camada de 
rede 
o Lado receptor: remontar 
segmentos em 
mensagens e os passa à 
camada aplicação 
− Mais de um protocolo de 
transporte disponível para as 
aplicações (Internet: TCP, UDP) 
● Camada transporte x de rede: 
− Rede: comunicação lógica 
entre hosts 
− Transporte: comunicação 
lógica entre processos 
− A camada de transporte conta 
com serviços da camada de 
rede e pode melhorá-los 
(prover confiabilidade, por ex) 
● Protocolos da camada transporte da 
Internet: 
− TCP: 
o Entrega confiável (em 
ordem) 
o Controle de 
congestionamento 
o Estabelecimento de 
conexão 
− UDP: 
o Entrega não-confiável 
(sem garantia de ordem) 
o Extensões “sem 
ornamentos” ao serviço 
de melhor esforço (best 
effort) IP 
− Serviços indisponíveis: garantia 
de atraso e de banda passante 
3.2 Multiplexação Demultiplexação 
● Demultiplexação no host receptor: 
entrega dos segmentos recebidos aos 
sockets corretos 
● Multiplexação no host emissor: coletar 
dados dos vários sockets, adiciona 
cabeçalho aos dados (mais tarde 
usados para demultiplexação) 
● Funcionamento da demultiplexação: 
− Host recebe datagramas IP na 
camada de rede 
o Cada datagrama possui 
endereço IP fonte 
(camada de rede) e de 
destino 
o Cada datagrama 
carrega 1 segmento da 
camada de transporte 
o Cada segmento possui o 
número de porta de 
origem (camada 
transporte) e da porta 
de destino 
− Host usa os endereços IP e os 
números das portas para enviar 
segmento ao socket adequado 
● Demultiplexação com UDP: 
− Criar sockets com portas 
respectivas 
− Socket UDP identificado pela 
tupla: 
o Endereço IP de destino 
o Número da porta de 
destino 
OBS.: Para entregar o segmento ao processo 
adequado, só precisa conferir o IP destino e 
o número da porta de destino. Ou seja, não 
importa qual o IP e a porta de origem. 
− Quando um host recebe um 
segmento UDP: 
o Verifica o número da 
porta de destino no 
segmento 
o Direciona segmento UDP 
p/ o socket com número 
da especificado 
− Datagramas IP com endereço 
IP fonte diferentes e/ou 
números de porta diferentes 
são direcionados ao mesmo 
socket 
● Demultiplexação com TCP: 
− Socket TCP é identificado pela 
quádrupla: 
o Endereço IP de origem 
o Número da porta de 
origem 
o Endereço IP de destino 
o Número da porta de 
destino 
− O host receptor usa os 4 valores 
para enviar o segmento ao 
socket adequado 
− O host servidor pode suportar 
diversos sockets TCP 
simultaneamente (cada socket 
é identificado por sua própria 
tupla quádrupla) 
− Servidores web possuem 
sockets diferentes para cada 
cliente conectado 
o HTTP não-persistente terá 
diferentes sockets para 
cada requisição 
3.3 UDP (Transporte não orientado à 
conexão) 
● Protocolo Internet de transporte “sem 
ornamentos” e com “elementos 
básicos” 
● Serviço “best-effort” 
− Segmentos UDP podem ser 
perdidos ou entregues à 
aplicação fora da ordem que 
foram enviados 
● Não orientado à conexão 
− Sem handshaking entre o 
emissor e o receptor UDP 
− Cada segmento UDP é tratado 
de forma independente dos 
outros 
● Usado para aplicações multimídia de 
streaming 
− Tolerante à perda 
− Sensível à taxa de dados 
● Outros usos do UDP: DNS e SNMP 
● Pontos positivos: 
− Sem estabelecimento de 
conexão (pode gerar atraso) 
− É simples (sem estado de 
conexão no emissor nem no 
receptor) 
− Cabeçalho do segmento 
pequeno (menos informações 
pois tem menos serviços sendo 
oferecidos) 
− Não tem controle de 
congestionamento (aplicações 
de áudio e vídeo requerem 
taxa de envio constante, e 
com o controle, a taxa varia) 
OBS.: Se a aplicação necessitar de 
transferência confiável de dados, a 
confiabilidade pode ser adicionada na 
camada de aplicação. 
● Formato do segmento UDP: 
− Porta de origem (16 bits) 
− Porta de destino (16 bits) 
− Tamanho (em bytes do 
segmento UDP, incluindo o 
cabeçalho) 
− Checksum (detectar erros no 
segmento transmitido; troca de 
bits, erro de transmissão) 
− Dados da aplicação 
(mensagem) 
3.4 Princípios da transferência 
confiável de dados 
● Importante nas camadas aplicação, 
transporte e enlace (transferência 
confiável existe também nessas 
camadas, além da de aplicação) 
● Características do canal não 
confiável determinará a 
complexidade do protocolo de 
transferência confiável 
● Funcionamento: 
− Rdt_send(): chamado pela 
camada superior (aplicação) 
para passar seus dados 
− Udt_send(): chamado pelo 
protocolo rdt para transferir 
pacote pelo canal não-
confiável ao receptor 
− Rdt_rcv(): chamado quando o 
pacote chega no lado 
receptor do canal 
− Deliver_data(): chamado pelo 
rdt para enviar dados à 
camada superior 
 
Rdt 1.0: Transferência confiável sobre um 
canal confiável 
● Canal de base confiável 
− Nenhum erro de bits 
− Nenhuma perda de pacotes 
● FSMs separadas para emissor e 
receptor 
− Emissor envia dados no canal 
− Receptor lê dados do canal 
● Máquina de estados: 
 
Emissor: 
− Esperando por uma chamada da 
camada de cima 
− Evento: aplicação manda dados para 
baixo chamando método rdt_send (1) 
− Ações (tomadas pelo protocolo de 
transporte): construir pacote com os 
dados que recebeu (2) + mandar 
pacote (3) 
− Permanece sempre no mesmo estado 
 
Receptor: 
− Esperando chamada da camada 
inferior 
− Evento: receber pacote (1) 
− Ações: extrai dados do pacote (2) + 
entrega esses dados para a camada 
superior (3) 
− Permanece sempre no mesmo estado 
Rdt 2.0: Canal com erros em bits 
● Canal de base pode trocar bits dos 
pacotes (checksum para detectar 
erros nos bits) 
● Mensagens de controle (como 
recuperar erros): 
− ACKs: receptor informa 
explicitamente ao emissor que 
o pacote recebido está ok 
(não detectou erro de 
checksum) 
− NAKs: receptor informa 
explicitamente ao emissor que 
o pacote possui erros 
OBS.: Emissor retransmite pacote ao receber 
um NAK do receptor 
● Novos mecanismos: 
− Detecção de erros 
− Feedback do receptor 
(mensagens de controle) 
● Máquina de estados: 
 
Emissor: 
− Esperando chamda da camada 
superior 
− Evento: aplicação gera os dados (1) 
− Ações: constrói pacote com os dados 
e com o checksum (2) + manda esse 
pacote (3) 
− Vai para o próximo estado 
− (SEM ERRO) Evento: recebeu um 
pacote e é um ACK (6) / volta para o 
primeiro estado 
− (ERRO) Evento: recebeu um pacote e 
é um NAK (4) / Ação: chama método 
para mandar novamente o mesmo 
pacote (5) / continua mesmo estado 
 
Receptor: 
− Espera chamada da camada inferior 
− (ERRO) Evento: recebeu pacote e está 
corrompido (1) / Ação: mandar NAK 
(2) / permanece no estado 
− (SEM ERRO) Evento: recebeu pacote e 
não está corrompido (3) / Ação: extrai 
dados do pacote, entrega dados 
para a camada superior e manda um 
ACK (4) 
● Problema fatal do Rdt 2.0: 
− ACKs ou NAKs podem ser 
corrompidos 
o Emissor não sabe o que 
aconteceu no receptor 
o Não pode só retransmitir 
(pode ter duplicação) 
− Tratando duplicações: 
o Emissor retransmite 
pacote atual se 
ACK/NAK é corrompido 
o Emissor adiciona 
números de sequência 
em cada pacote 
o Receptor descarta (não 
entrega à camada 
superior) pacotes duplos 
− Stop and wait: emissor envia 1 
pacote e aguarda pela 
resposta do receptor 
Rdt 2.1: Trata ACKs/NAKs corrompidos 
 
Emissor: 
− Espera chamada 0 camada superior 
− Evento: aplicação gera os dados (1) 
− Ação: construir pacote com número 
de sequência, dados e checksum + 
mandar pacote (2) 
− Próximo estado: esperando por ACK 
ou NAK do pacote 0 que mandou 
− (ERRO) Evento: Recebe um pacote e 
ele está corrompido oué um NAK (3) / 
Ação: manda pacote novamente (4) 
/ Permanece no estado 
− (SEM ERRO) Evento: Recebe um 
pacote e não está corrompido e é um 
ACK (5) / Passa para próximo estado 
− Próximo estado: espera chamada 1 
da camada superior e passos 
repetem com 1 e não 0 (6, 7, 8, 9 e 10) 
 
Receptor: 
− Inicialmente esperando por chamada 
com pacote 0 da camada abaixo 
− Evento: Recebe pacote, não está 
corrompido e tem número de 
sequência 0 que é o esperado (1) 
− Ação: Extrai dados do pacote, 
entrega os dados para a camada 
superior, constrói ACK (outro pacote) 
com seu checksum e manda (2) 
− Próximo estado: esperando chamada 
da camada inferior com número 1 
− (ERRO) Evento: recebe pacote 
corrompido (3) / Ação: constrói NAK 
com seu checksum e manda (4) / 
Permanece no mesmo estado 
− (SEM ERRO) Evento: recebe pacote 
não corrompido e com número de 
sequência 0 (5) / Ação: constrói ACK 
com seu checksum e manda (6) / 
Permanece no mesmo estado 
− Próximo estado: espera chamada 1 
da camada inferior e passos repetem 
com 1 e não 0 (7,8, 9,10,11 e 12) 
● Características do emissor e receptor: 
− Emissor: 
o Num de seq adicionado 
aos pacotes 
o Só precisamos de dois 
números (0 e 1) pois a 
abordagem é stop and 
wait 
o Deve verificar se ACK ou 
NAK recebido está 
corrompido 
o Duas vezes mais estados 
que a versão 2.0: state 
deve “recordar” se o 
pacote atual possui num 
de seq 0 ou 1 
− Receptor: 
o Deve verificar se pacote 
recebido é duplicado 
(estado indica se o num 
de seq do pacote 
esperado é 0 ou 1) 
o Receptor não pode 
saber se seu último ACK 
ou NAK foi recebido ok 
no emissor (a conexão 
não terminaria nunca, 
pois sempre teria uma 
nova confirmação) 
Rdt 2.2: Um protocolo sem NAKs 
● Igual ao Rdt 2.1 mas usando ACKs 
somente 
● Ao invés de NAK, receptor envia ACK 
do último pacote recebido 
corretamente 
− Receptor deve incluir 
explicitamente o num de seq 
do pacote sendo confirmado 
● ACK duplicado no emissor resulta na 
mesma ação como para o NAK: 
retransmissão do pacote atual 
● Diferenças nas máquinas de estado: 
Emissor: 
− Manda pacote e vai para o estado 
esperando ACK 0 
− Recebe pacote e está corrompido ou 
é o ACK do pacote 1 
− Recebe pacote, não está corrompido 
e é o ACK esperado, então muda de 
estado 
Receptor: 
− Vindo de outro estado, recebe 
pacote não corrompido com num de 
seq 1 (esperado) 
− Extrai os dados do pacote, entrega 
para aplicação, constrói ACK do 
pacote 1 que recebeu e manda o 
pacote 
− Vai para o estado esperando 
chamada da camada anterior com 
num de seq 0 
 
Rdt 3.0: Canais com erros e perdas 
● Canal de base pode agora perder 
pacotes (dados ou ACKs) 
− Checksum, num de seq, ACKs, 
retransmissões ajudam, mas 
não serão suficientes 
● Emissor aguarda um tempo “razoável” 
a recepção de ACKs 
− Retransmite se nenhum ACK é 
recebido nesse tempo 
− Se pacote ou ACK está apenas 
atrasado (não foi perdido): 
o Retransmissão causará 
duplicação, mas num de 
seq trata isso 
o Receptor deve 
especificar num de seq 
do pacote que está 
sendo confirmado 
− Requer temporizador 
● Máquina de estados: 
 
Emissor: 
− Começa esperando por uma 
chamada da camada de cima com 
num de seq 0 
− Aplicação gera os dados 
− Constrói pacote com os dados, num 
de seq 0 e checksum, manda o 
pacote e inicializa temporizador 
(diferença básica) 
− Próximo estado: aguardar ACK 0 
− Receber um pacote e está 
corrompido ou é ACK 1, não faz nada 
e continua no mesmo estado 
− Deu timeout (temporizador expirou), 
manda de novo o pacote e reinicia o 
tempo, continua no estado 
− Receber pacote e não está 
corrompido e é ACK 0, para o 
temporizador e vai para o próximo 
estado 
− Passos se repetem para o número 1 
● Desempenho: 
− Funciona, mas o desempenho 
do Rdt 3.0 é ruim 
− Utilização é a fração do tempo 
em que o emissor está 
ocupado enviando o pacote 
− O protocolo de rede limita o 
uso de recursos físicos 
● Funcionamento do stop and wait: 
 
Protocolos com pipeline: 
● Pipelining (otimização): emissor 
permite múltiplos pacotes enviados 
que ainda não foram confirmados 
− Range do num de seq deve ser 
aumentado 
− “Bufferização” (memória) no 
emissor e/ou receptor 
 
● Aumento da utilização: 
 
GO-BACK-N (GBN): 
● Feito numa época em que memória 
era caro (o protocolo foi feito para 
lidar com o fato de que não tinha 
buffer para receber muitos pacotes) 
● Emissor: 
− Num de seq de k bits no 
cabeçalho do pacote 
− Janela de até N consecutivos 
pacotes não confirmados 
permitida (deslizante para a 
direita) 
 
● Regras: 
− ACK(n): confirma todos os 
pacotes até o num de seq n 
(“ACK cumulativo”) 
− Temporizador para cada 
pacote enviado 
− Timeout(n): retransmite pacote 
n e todos os pacotes com num 
de seq maiores que estão 
dentro da janela 
− ACK-only: sempre envia ACK 
para pacote recebido “na 
ordem” corretamente com 
num de seq mais elevado 
o Pode gerar ACKs 
duplicados 
o Precisa recordar 
somente o num de seq 
esperado 
− Pacote fora de ordem: 
o Descarta (não 
armazena) pois receptor 
não tem buffer 
o Confirma o pacote com 
num de seq mais 
elevado e na ordem 
certa (último recebido) 
OBS.: Como o receptor não tem buffer na 
camada de transporte, ou seja, só cabe um 
pacote, se o primeiro pacote da janela deu 
timeout, todos da frente foram descartados, 
mesmo se tiverem chegado ok do outro 
lado, pois chegaram fora da ordem 
esperada (como não tem memória para 
guarda-los até receber o certo, descarta 
para deixar o espaço livre para receber o 
pacote esperado) 
 
SELECTIVE REPEAT (SR): 
● Outra abordagem, não havia mais 
limitação de memória (lidar agora 
com buffer para armazenar pacotes 
que saíram da ordem correta) 
● Receptor confirma individualmente 
cada pacote recebido corretamente 
− Armazena pacotes, quando 
necessário, para eventual envio 
de pacotes ordenados à 
camada superior 
● Emissor reenvia somente pacotes para 
os quais ACK não foi recebido 
− Emissor possui temporizador 
para cada pacote não 
confirmado 
● Mesma ideia de janela deslizante do 
emissor (mandar pacotes em avanço) 
− N consecutivos num de seq 
− Limita num de seq de enviados 
a pacotes não confirmados 
 
● Regras emissor: 
− Recebeu dados da camada 
superior: 
o Se o próximo num de seq 
estiver disponível dentro 
da janela, envia o 
pacote 
− Se der timeout(n): 
o Reenvia somente o 
pacote n e reinicia o 
temporizador 
− Se receber ACK(n) que esteja 
dentro do intervalo [sendbase, 
sendbase+N]: 
o Marca pacote n como 
recebido 
o Se n é o menor num de 
seq de pacotes não 
confirmados, avança 
base da janela para o 
próximo num de seq não 
confirmado 
 
● Regras receptor: 
− O pacote n no intervalo 
[rcvbase, rcvbase+N-1] envia 
ACK(n): 
o Se o pacote está fora da 
ordem esperada: vai 
para o buffer (memória) 
o Se está ordenado: 
entrega os pacotes para 
a camada superior 
(incluindo pacotes 
ordenados no buffer) e 
avança a janela para o 
próximo pacote ainda 
não recebido 
− Se o pacote n estiver no 
intervalo [rcvbase-N, rcvbase-1] 
manda o ACK(n) 
− Caso contrário: ignorar 
OBS.: As janelas do emissor e do receptor se 
movem de maneiras diferentes. A do emissor 
só muda quando ACK chega e a do 
receptor, quando o pacote é recebido (na 
ordem)
 
3.5 TCP (Transporte orientado à 
conexão) 
Overview: 
● Ponto a ponto: liga um emissor a um 
receptor 
● Stream de bytes confiável e em ordem 
− “Mensagens não possuem 
limites” 
− Contagem do que recebe em 
bytes e não em pacotes 
● Pipelined: controle de fluxo e 
congestionamento do TCP setam 
tamanho da janela 
● Buffers no emissor e no receptor (não 
tinha mais problema com memória) 
● Dados full duplex: 
− Fluxo de dados bidirecional 
sobre a mesma conexão 
− MSS (Maximum Segment Size)= 
tamanho máximo do segmento 
● Orientado à conexão: 
− Handshaking (troca de 
mensagens) inicia emissor e 
estado do emissor antes da 
troca de dados 
● Controle de fluxo: 
− Emissor não envia mais dadosque o receptor pode receber 
Estrutura do segmento TCP: 
 
● Num de seq: número do primeiro byte 
do segmento do dado 
● ACKs: num de seq do próximo byte 
aguardado pelo outro lado (ACK 
cumulativo) 
● Especificação do TCP não diz como 
receptor trata segmentos fora de 
ordem (deixado para desenvolvedor) 
● Timeout: 
− Maior que o RTT (mas o RTT 
varia) 
− Muito curto: timeout prematuro 
(retransmissões desnecessárias) 
− Muito longo: reação lenta à 
perda de segmentos 
● RTT: 
− SampleRTT: tempo medido a 
partir da transmissão do 
segmento até a recepção do 
ACK (ignora retransmissões) 
− SampleRTT varia, deseja-se uma 
estimativa de RTT “suavizada” 
o Faz-se uma média de 
várias medidas recentes, 
não se usa somente a 
atual 
Transferência de dados confiável: 
● TCP cria serviço de transferência 
confiável no topo do serviço não 
confiável do IP 
● Segmentos “pipelined” (vários ao 
mesmo tempo) 
● ACKs cumulativos (menos sensível a 
perda de partes) 
● Conceitualmente o TCP usa múltiplos 
temporizadores de transmissão 
● Retransmissões são disparadas por: 
− Eventos de expiração (timeout), 
quando houve erro (perda de 
pacotes) 
− ACKs duplicados (otimização) 
● Eventos no emissor TCP: 
− Dados recebidos da aplicação: 
o Cria segmento com num 
de seq 
o Num de seq é o número 
do primeiro byte de 
dados no segmento 
o Inicia temporizador se já 
não estiver executando 
o Intervalo de expiração: 
TimeOutInterval 
− Timeout: 
o Retransmite segmento 
que causou o timeout 
o Reinicia temporizador 
− ACK recebido: 
o Se confirma segmentos 
prévios não confirmados 
(atualiza o que é 
conhecido a ser 
confirmado e inicia 
temporizador se existem 
segmentos devidos) 
● Cenários com retransmissão: 
 
 
● Geração de ACKS no TCP: 
 
● Fast Retransmit (Retransmissão Rápida) 
− Período de expiração 
relativamente longo 
o Grande atraso antes de 
reenviar pacote perdido 
− Detecta segmentos perdidos 
via ACKs duplicados 
o Emissor frequentemente 
envia muitos segmentos 
sucessivos 
o Se segmento é perdido, 
haverá provavelmente 
muitos ACKs duplicados 
− Se emissor recebe 3 ACKs 
duplicados (4 ACKS 
consecutivos, idênticos, sem 
outros pacotes no meio) para o 
mesmo dado, ele supõe que o 
segmento após dado 
confirmado foi perdido 
o Fast retransmit: reenvia 
segmento antes do 
temporizador expirar 
Controle de fluxo: 
● Emissor não estoura o buffer do 
receptor transmitindo demais ou muito 
rápido 
● Lado receptor possui um buffer 
 
● Processo aplicação pode ser lento ao 
ler dados do buffer 
● Serviço de casamento de taxas: 
“casar” a taxa de envio com a taxa 
de drenagem de dados da aplicação 
receptora 
● Espaço livre no buffer 
− = RcvWindow 
− = RcvBuffer – [LastByteRcvd – 
LastByteRead] 
● Receptor informa espaço livre através 
da inclusão nos segmentos do valor 
da janela de recepção RcvWindow 
● Emissor limita dados não confirmados 
ao tamanho da janela RcvWindow 
− Garante que o buffer do 
receptor não transborde 
Gerenciamento de conexão: 
● Estabelecimento de conexão entre 
emissor e receptor TCP antes da troca 
de segmentos de dados 
● Inicializar variáveis TCP: 
− Num de seq 
− Cria buffers, aloca memória, 
tem informação de controle de 
fluxo (RcvWindow) 
● Cliente é o iniciador da conexão e 
servidor é contactado pelo cliente 
● Three-way handshake: 
− Passo 1: host cliente envia 
segmento SYN TCP para o 
servidor 
o Especifica num de seq 
inicial 
o Sem dados 
− Passo 2: host servidor recebe 
SYN e responde com segmento 
SYNACK 
o Servidor aloca buffers 
o Especifica num de seq 
inicial do servidor 
− Passo 3: cliente recebe 
SYNACK, responde com 
segmento ACK que pode 
conter dados 
● Fechando uma conexão: 
− Cliente fecha socket: 
clientSocket.close(); 
− Passo 1: cliente envia segment 
TCP de controle FIN ao servidor 
− Passo 2: servidor recebe FIN, 
responde com ACK. Fecha 
conexão e envia FIN 
− Passo 3: cliente recebe FIN e 
responde com ACK 
o Entra na “espera 
temporizada” 
(responderá com ACK 
aos FINs recebidos) 
− Passo 4: servidor recebe ACK. 
Conexão foi fechada 
 
● Ciclo de vida: 
− Cliente 
 
− Servidor 
 
3.6 Princípios do controle de 
congestionamento 
● Congestionamento: 
− Informalmente: fontes demais 
enviando dados demais, muito 
rápido, ultrapassando a 
capacidade da rede 
− É diferente de controle de fluxo 
− Manifestações: 
o Pacotes perdidos 
(“estouro” de buffer nos 
roteadores) 
o Atrasos elevados 
(“enfileiramento” em 
buffers nos roteadores) 
− Custos: 
o Mais trabalho 
(retransmissões) 
o Retransmissões 
desnecessárias (enlace 
carrega múltiplas cópias 
do mesmo pacote) 
o Quando um pacote é 
descartado, a 
capacidade de 
transmissão upstream 
usada para esse pacote 
foi desperdiçada 
OBS.: Se superdimensionarmos a banda 
passante, o problema de congestionamento 
é praticamente resolvido (TCP não teria que 
detectar congestionamento e derrubar a 
taxa de transmissão de dados). Isso porque o 
congestionamento ocorre se a banda 
passante da rede não é suficiente para a 
quantidade de fontes que estão mandando 
dados. No entanto, aumentar a banda 
passante ainda é caro. 
● Abordagens para o controle de 
congestionamento: 
− Controle de congestionamento 
fim-a-fim: 
o Sem feedback explícito 
da rede 
o Congestionamento 
inferido pelos end 
systems através das 
perdas e atrasos 
observados 
o Abordagem usada pelo 
TCP 
− Controle de congestionamento 
assistido pela rede: 
o Roteadores proveem 
feedback para os end 
systems (bit único 
indicando 
congestionamento e 
taxa explícita que 
emissor deve usar) 
o Abordagem usada pela 
rede ATM 
3.7 Controle de congestionamento 
TCP 
● Controle fim a fim (sem apoio da 
rede) 
● Taxa de transmissão limitada pelo 
tamanho da janela (CogWin) 
 
Algoritmos para setar o tamanho da janela: 
● Partida lenta (slow start): 
− Inicializa CogWin = 1 
For (cada segmento com ACK) 
 CogWin++ 
Until (evento de perda ou 
CogWin>Threshold) 
− Aumento exponencial (por RTT) 
no tamanho da janela (não 
muito lenta) 
− Evento de perda: temporizador 
(Tahoe TCP) e/ou 3 ACKs 
duplicados (Reno TCP) 
● Evitar congestionamento: 
− //Partida lenta acabou pois 
CogWin>threshold 
Until (envento de perda){ 
Cada w segmentos 
reconhecidos: CogWin++ 
} 
Threshold = CogWin/2 
CogWin = 1 
Faça partida lenta 
● Additive increase, multiplicative 
decrease (AIMD): 
− Aumentar a taxa de 
transmissão (tamanho da 
janela), sondar bw ainda 
utilizável, até ocorrência de 
perda de pacote 
− Aumento aditivo: aumenta 
CogWin de 1 MSS a cada RTT 
até perda ser detectada 
− Redução multiplicativa: reduz 
CogWin pela metade após 
detectar perda 
− Comportamento dente de 
serra 
 
OBS.: No Tahoe, quando ocorre uma perda, 
seja ela detectada por timeout ou por 3 
ACKs duplicados, a janela volta para 1 e 
começa a partida lenta. No Reno, quando a 
perda é detectada por timeout, a janela 
volta para 1. Mas, quando é detectada por 
3 ACKs duplicados, a janela volta para um 
novo limiar e começa pela fase de evitar o 
congestionamento. Ou seja, ele diferencia os 
eventos de perda enquanto o Tahoe não. 
Nos ACKs duplicados, não derruba a janela 
para 1 pois os ACKs continuam chegando, 
então entende que o problema foi somente 
pontual. Já o timeout é um cenário mais 
alarmante, e por isso volta para 1. 
 
● Após 3 ACKS duplicados: 
− CogWin é reduzida pela 
metade 
− Janela cresce linearmente 
● Após evento de timeout: 
− CogWin é setada para 1 MSS 
− Janela cresce 
exponencialmente 
− Até um threshold (limiar), e 
então volta a crescer 
linearmente 
● Sumário do controle de 
congestionamento: 
− Tahoe + Reno: Quando CogWin 
está abaixo de Threshold, 
emissor está na fase de partida 
lenta, janela cresce 
exponencialmente. 
− Tahoe + Reno: Quando CogWin 
está acima de Threshold, 
emissor está na fase de 
controle de congestionamento, 
janela cresce linearmente. 
− Reno: Quando 3 ACKs 
duplicados ocorrem, Threshold 
é setadopara CogWin/2 e 
CogWin é setado para 
Threshold. 
− Tahoe: Quando 3 ACKs 
duplicados ocorrem, Threshold 
é setado para CogWin/2 e 
CogWin é setado para 1. 
− Tahoe e Reno: Quando timeout 
ocorre, Threshold é setado para 
CogWin/2 e CogWin é setado 
para 1. 
Justiça no TCP: 
● Objetivo: se K sessões TCP 
compartilham um mesmo enlace (de 
gargalo) de banda passante R, cada 
uma deve ter uma taxa média de R/K 
● TCP é justo: 
− 2 sessões competindo: 
o Aumento aditivo, saltos 
de 1 (vazão aumenta) 
o Redução multiplicativa 
reduz vazão 
proporcionalmente 
 
Tende a compartilhar igualmente a banda 
● Justiça e o UDP: 
− Apps multimídia geralmente 
não usam TCP (para não 
restringir taxa devido ao 
controle de congestionamento) 
− Em vez do TCP, as aplicações 
multimídia usam UDP (áudio e 
vídeo injetados a taxas 
constantes, toleram perdas de 
pacotes) 
− Área de pesquisa: TCP friendly 
(protocolos amigos do TCP) 
● Justiça e conexões TCP paralelas: 
− Nada previne apps de abrirem 
conexões paralelas entre dois 
hosts 
− Web browsers fazem isso