IntRedes Aula14TransfConfiav

Redes de Computadores
→ Aula n° 14 
Prof. Petrônio Carlos Bezerra

petroniocg@ifpb.edu.br
1 Hoje veremos...
◼ Princípios de Transferência Confiável

◼ rdt 1.0
◼ rdt 2.0
◼ rdt 2.1
◼ rdt 2.2
◼ rdt 3.0
◼ Protocolos de transferência confiável de dados com
paralelismo
IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

2 Camada de Transporte – TCP/IP
◼ rdt 2.0
◼ Transferência confiável de dados por um canal com erros de bits.
◼ Um modelo mais realista: Canal em que os bits podem ser

corrompidos
◼ Continuaremos a admitir que todos os pacotes transmitidos sejam

recebidos na ordem em que foram enviados
• Embora os bits possam estar corrompidos

◼ Antes, considere como as pessoas enfrentariam uma situação

como essa
• Como você ditaria uma mensagem longa por telefone?
• Esse protocolo de ditado de mensagens usa reconhecimentos positivos
(‘Ok’) e reconhecimentos negativos (‘Repita, por favor’)
• Essas mensagens de controle fazem o remetente saber o que foi recebido
corretamente e o que precisa de repetição
◼ Em Redes de Computadores, protocolos de transferência confiável

de dados baseados nesse tipo de retransmissão são conhecidos
como protocolos ARQ

◼ Protocolo ARQ: Automatic Repeat reQuest – Solicitação

Automática de Repetição
◼ São exigidas três capacitações adicionais dos protocolos ARQ para

manipular a presença de erros de bits:
• Detecção de erros: é preciso um mecanismo de detecção no destinatário;
• Realimentação do destinatário:
◼ Reconhecimentos positivos (ACK) ou negativo (NAK);
◼ Por exemplo, um bit, NAK = 0 e ACK = 1.
• Retransmissão:
◼ Pacote recebido com erro será retransmitido pelo transmissor.

◼ A figura mostra a representação por FSM do rdt2.0 (lado remetente)

• Protocolo de transferência de dados que emprega detecção de erros, reconhecimentos
positivos e negativos.

◼ Quando o remetente está no estado de espera por ACK ou NAK,

não pode receber mais dados da camada superior [rdt_send ( ) não
pode ocorrer]
◼ Só poderá ocorrer quando o remetente receber um ACK e sair

desse estado
 Não enviará novos dados até ter certeza que o anterior foi
recebido
◼ Devido a esse comportamento, protocolos como o rdt2.0 são

conhecidos como protocolos pare e espere (stop-and-wait)

◼ A FSM do rdt2.0 do lado destinatário tem um único estado

◼ Pode parecer que o rdt2.0 funciona, mas ele tem um defeito fatal.
Qual?
• Em particular, não tratamos da possibilidade de um pacote ACK
ou NAK estar corrompido!
◼ A questão mais difícil é: Como o protocolo deve se recuperar de

erros em pacotes ACK ou NAK?
• Se um ACK ou um NAK estiver corrompido → remetente não
tem como saber se o destinatário recebeu corretamente
◼ Considere três possibilidades para manipular ACKs ou NAKs

corrompidos:
• Primeira: No ditado do exemplo, se quem estiver ditando não

entender o ‘Ok’ ou o ‘Repita por favor’, vai perguntar: ‘o que foi
que você disse?’
◼ Esse é um caminho difícil!
• Segunda: Adicionar um número suficiente de bits de soma de

verificação  Remetente detecte e se recupere do erro de bits
◼ Resolve para um canal que pode corromper pacotes, mas não
perdê-los

• Terceira: Reenviar, quando receber um pacote ACK ou NAK

truncado. Qual o problema aqui?
◼ Pacotes duplicados. Destinatário não sabe se o pacote que
chega contém novos dados ou é uma retransmissão.
◼ Solução simples: adicionar um novo campo ao pacote de dados

com numeração sequencial dos pacotes
• Adotada em protocolos de transferência de dados, inclusive o TCP
◼ Destinatário verifica esse campo para saber se é ou não uma

retransmissão
◼ Para esse caso simples de protocolo pare e espere, um número de

sequência de um bit é suficiente
◼ Estamos admitindo que este canal não perde pacotes, então os

pacotes ACK e NAK não precisam indicar número de sequência do
pacote que estão reconhecendo
◼ ACK ou NAK recebido (truncado ou não) é uma resposta ao pacote

de dados transmitido mais recentemente

◼ rdt 2.1
◼ O protocolo rdt2.1 é uma versão corrigida do rdt2.0
◼ Cada um dos diagramas remetente e destinatário da FSM do

rdt2.1 tem um número duas vezes maior de estados
◼ Estado do protocolo deve agora refletir se o pacote que está

sendo correntemente enviado (remetente) ou aguardado
(destinatário) deveria ter um número de sequência 0 ou 1



◼ Nosso protocolo rdt2.1 usa tanto reconhecimentos positivos quanto

negativos
◼ Podemos conseguir o mesmo efeito sem utilizar pacotes NAK

• Basta enviar um ACK para o último pacote corretamente recebido
◼ O remetente entende que, ao receber ACKs duplicados para o

mesmo pacote, o destinatário não recebeu corretamente o pacote
seguinte ao que recebeu dois ACKs.

◼ rdt 2.2
◼ Nosso protocolo de transferência confiável de dados sem NAK para um canal

com erros de bits é o rdt2.2
◼ Uma modificação sutil entre rdt2.1 e rdt2.2 é que o destinatário agora deve
incluir o número de sequência do pacote que está sendo reconhecido por uma
mensagem ACK (0 ou 1)
◼ E o remetente agora deve verificar o número de sequência do pacote que está

sendo reconhecido por uma mensagem ACK recebida



◼ rdt3.0
◼ Suponha agora que além de corromper bits, o canal possa perder
pacotes (fato comum nas redes)
◼ Duas preocupações adicionais:

• Como detectar a perda de pacotes?
• O que fazer quando isso ocorrer?
◼ A utilização de soma de verificação, números de sequência,

pacotes ACK e retransmissões (técnicas do rdt2.2) resolvem a
segunda preocupação
◼ Perda de pacotes exigirá a adição de um novo mecanismo
◼ Há muitas abordagens possíveis. Aqui, vamos atribuir ao

remetente o encargo de detectar e se recuperar das
perdas de pacotes
◼ Suponha:
• Remetente transmita um pacote de dados e esse, ou o ACK do
destinatário, seja perdido. Qual a visão do remetente?
◼ Em qualquer caso, nenhuma resposta chegará ao remetente

◼ Se o remetente estiver disposto a esperar o tempo

suficiente para ter certeza que o pacote foi perdido  ele
pode simplesmente retransmitir
• Tenha certeza que isso funciona mesmo!
◼ Quanto tempo esperar?

• No mínimo: Tempo de ida e volta entre ele e o destinatário;
• Mais o tempo necessário para processar um pacote.
◼ O atraso máximo é um tempo difícil até de estimar

◼ Ideal: Que o protocolo se recuperasse da perda de pacotes logo

que possível
• Esperar pelo atraso do pior dos casos pode significar um longo tempo para
se recuperar do erro
◼ Abordagem adotada na prática:

 Remetente faz uma escolha ponderada de um valor de tempo
dentro do qual seria provável, mas não garantido, que a perda
tivesse acontecido
 Se não receber um ACK nesse período o pacote é retransmitido

◼ Note que, se um pacote sofrer um atraso longo, o remetente

poderá retransmiti-lo mesmo que, nem o pacote de dados nem o
seu ACK tenham sido perdidos
◼ Possibilidade: Pacotes de dados duplicados!

• Mas, o rdt2.2 já trata os casos de pacotes duplicados
◼ Do ponto de vista do remetente: Retransmissão é uma panaceia

• Não sabe se o pacote de dados foi perdido, se um ACK foi perdido ou se o
pacote ou o ACK estavam atrasados

◼ Em todos os casos a ação é a mesma. (Qual?)

• Retransmitir
◼ Para implementar um mecanismo de retransmissão com

base no tempo, precisamos de um temporizador de
contagem regressiva

◼ Remetente precisa
• Acionar o temporizador sempre que um pacote for enviado;
• Responder a uma interrupção feita pelo temporizador
(realizando as ações necessárias);
• Parar o temporizador.
◼ A figura seguinte mostra a FSM remetente para o rdt3.0, um

protocolo que transfere confiavelmente dados por um canal que
pode corromper ou perder pacotes

26
◼ A figura mostra como o rdt3.0

funciona:
• Passagem do tempo do topo pra
baixo;
• Instante de recebimento de um
pacote é necessariamente
posterior ao de envio;
• Colchetes indicam os instantes de
acionamentos do temporizador e,
mais tarde, os instantes em que
ele parou.



◼ Como os números de sequência se alternam entre 0 e 1, o

protocolo rdt3.0 às vezes é conhecido como protocolo bit
alternante.
◼ Para concluir, reunimos os elementos fundamentais de um

protocolo de transferência de dados:
• Soma de verificação, números de sequência, temporizadores e pacotes de
reconhecimentos negativos e positivos.
◼ Temos agora em funcionamento um protocolo de transferência

confiável de dados
◼ O rdt3.0 é correto mas é pouco provável que alguém fique

satisfeito com o desempenho dele
◼ Grande problema do desempenho: ser um protocolo do tipo pare e

espere
◼ Vamos avaliar o impacto sobre

o desempenho. Considere um
caso ideal:
• Dois hosts  um na Costa Oeste
e outro na Costa Leste dos EUA;

• Atraso de propagação de ida e volta à velocidade da luz, é de

aproximadamente: Tprop = 30 milissegundos
• Suponha eles conectados por um canal com R = 1 Gb (109 bits) por
segundo
• Para um tamanho de pacote: L = 1 kbyte (8 mil bits) [incluindo cabeçalho
e dados]

◼ O tempo para transmitir o pacote é: t trans

L 8 kbits/pacote
= = = 8 microssegundos
9
R 10 bits/seg
◼ Vamos analisar a figura seguinte:
• Começa a enviar em t = 0. Então em t =
L/R = 8 microssegundos o último bit
entra no canal do lado remetente;
• Faz sua jornada de 15 milissegundos
atravessando o país;
• Último bit do pacote chega ao destino
em:
t = RTT/2 + L/R = 15,008 milissegundos
• Supondo pacotes ACK extremamente
pequenos (ignorar ttrans);

• ACK vai emergir de volta no remetente em:

t = RTT + L/R = 30,008 milissegundos
• Agora o remetente pode enviar o próximo pacote.
◼ Em 30,008 milissegundos, o remetente esteve enviando por apenas 0,008

milissegundos
◼ Defina: utilização do canal = fração do tempo em que o remetente está

enviando bits:
L/R 0,008
U remet = = = 0,00027
RTT + L/R 30,008

◼ Portanto o remetente ficou ocupado apenas 2,7 centésimos de 1%

do tempo
◼ Ou, só foi capaz de enviar 1.000 bytes em 30,008 milissegundos,

uma vazão de apenas 267 kbps, mesmo com um enlace de 1
Gbps
◼ Este é um exemplo de como um protocolo de rede pode limitar as

capacidades oferecidas pelo hardware subjacente

◼ A solução para o problema de desempenho é simples:

• Em vez do modo pare e espere, o remetente pode enviar vários
pacotes sem esperar por reconhecimentos

◼ A figura seguinte mostra que, se um remetente for autorizado a

transmitir 3 pacotes antes de ter que esperar por reconhecimentos,
sua utilização será essencialmente triplicada
Técnica
conhecida
como pipeline
(em inglês) ou
paralelismo
(em português)

◼ Consequências:
• Faixa de números de sequência ampliada;
• Remetente e destinatário dos protocolos podem ter de reservar buffers
para mais de um pacote;
• A faixa de números de sequência necessária e as necessidades de buffer
dependerão de como o protocolo responde a pacotes perdidos,
corrompidos e demasiadamente atrasados.
◼ Duas abordagens básicas em relação à recuperação de erros com

paralelismo podem ser identificadas:
• Go-back-N e repetição seletiva

Redes de Computadores
→ Aula n° 14 
Prof. Petrônio Carlos Bezerra

petroniocg@ifpb.edu.br

IntRedes Aula14TransfConfiav

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

IntRedes Aula14TransfConfiav

Enviado por

Direitos autorais:

Formatos disponíveis

Redes de Computadores

Prof. Petrônio Carlos Bezerra

◼ Princípios de Transferência Confiável

◼ Protocolos de transferência confiável de dados com

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Um modelo mais realista: Canal em que os bits podem ser

◼ Continuaremos a admitir que todos os pacotes transmitidos sejam

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Antes, considere como as pessoas enfrentariam uma situação

◼ Em Redes de Computadores, protocolos de transferência confiável

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Protocolo ARQ: Automatic Repeat reQuest – Solicitação

◼ São exigidas três capacitações adicionais dos protocolos ARQ para

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ A figura mostra a representação por FSM do rdt2.0 (lado remetente)

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Quando o remetente está no estado de espera por ACK ou NAK,

◼ Só poderá ocorrer quando o remetente receber um ACK e sair

◼ Devido a esse comportamento, protocolos como o rdt2.0 são

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ A FSM do rdt2.0 do lado destinatário tem um único estado

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ A questão mais difícil é: Como o protocolo deve se recuperar de

◼ Considere três possibilidades para manipular ACKs ou NAKs

• Primeira: No ditado do exemplo, se quem estiver ditando não

• Segunda: Adicionar um número suficiente de bits de soma de

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

• Terceira: Reenviar, quando receber um pacote ACK ou NAK

◼ Solução simples: adicionar um novo campo ao pacote de dados

◼ Destinatário verifica esse campo para saber se é ou não uma

◼ Para esse caso simples de protocolo pare e espere, um número de

◼ Estamos admitindo que este canal não perde pacotes, então os

◼ ACK ou NAK recebido (truncado ou não) é uma resposta ao pacote

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ O protocolo rdt2.1 é uma versão corrigida do rdt2.0

◼ Cada um dos diagramas remetente e destinatário da FSM do

◼ Estado do protocolo deve agora refletir se o pacote que está

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Nosso protocolo rdt2.1 usa tanto reconhecimentos positivos quanto

◼ Podemos conseguir o mesmo efeito sem utilizar pacotes NAK

◼ O remetente entende que, ao receber ACKs duplicados para o

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Nosso protocolo de transferência confiável de dados sem NAK para um canal

◼ E o remetente agora deve verificar o número de sequência do pacote que está

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Duas preocupações adicionais:

◼ A utilização de soma de verificação, números de sequência,

◼ Perda de pacotes exigirá a adição de um novo mecanismo

◼ Há muitas abordagens possíveis. Aqui, vamos atribuir ao

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Se o remetente estiver disposto a esperar o tempo

◼ Quanto tempo esperar?

◼ O atraso máximo é um tempo difícil até de estimar

◼ Ideal: Que o protocolo se recuperasse da perda de pacotes logo

◼ Abordagem adotada na prática:

 Se não receber um ACK nesse período o pacote é retransmitido

IFPB – Campus de Campina Grande Prof. Petrônio Carlos Bezerra

◼ Note que, se um pacote sofrer um atraso longo, o remetente

◼ Possibilidade: Pacotes de dados duplicados!