1. Capítulo 3: Camada de Transporte
Objetivos do Capítulo: Resumo do Capítulo:
• entender os princípios por trás • serviços da camada de transporte
dos serviços da camada de • multiplexação/demultiplexação
transporte: • transporte sem conexão: UDP
– multiplexação/demultiplexação • princípios de transferência confiável de
– transferência de dados dados
confiável • transporte orientado à conexão: TCP
– controle de fluxo – transferência confiável
– controle de congestionamento – controle de fluxo
• instanciação e implementação – gerenciamento de conexão
na Internet • princípios de controle de
congestionamento
• controle de congesetionamento do TCP

2. Protocolos e Serviços de Transporte
• Fornecem comunicação lógicas entre aplicação
transporte
processos de aplicação em diferentes eerede
enlace
hosts física
rede
enlace
tr
• Os protocolos de transporte são rede física
an
enlace
sp
executados nos sistemas finais da rede física
or
rede
t
• serviço de transporte vs serviços de enlace
e
ló
física rede
gi
rede : enlace
co
física
fi
• camada de rede: transferência de
m
rede
-a
dados entre computadores (end enlace
-fi
física
m
systems)
• camada de transporte: transferência aplicação
transporte
de dados entre processos rede
enlace
– utiliza e aprimora os serviços física
oferecidos pela camada de rede

3. Protocolos da Camada de Transporte
Serviços de Transporte da Internet: application
transporte
rede
• confiável, seqüencial e unicast enlace rede
física
(TCP) enlace
tr
rede física
an
– congestão enlace
sp
física
or
– controle de fluxo rede
t
enlace
e
ló
física rede
– orientado à conexão
gi
enlace
co
física
• não confiável (“best-effort”), não
fi
m
rede
-a
seqüencial, entrega unicast or enlace
-
física
fi
m
multicast : UDP
application
• serviços não disponíveis: transporte
rede
– tempo-real enlace
física
– garantia de banda
– multicast confiável

4. Multiplexação de Aplicações
Segmento - unidade de dados trocada
Demultiplexação: entrega de
entre entidades da camada de
segmentos recebidos aos
transporte
processos de aplicação corretos
– TPDU: transport protocol data
unit (unidade de dados do
protocolo de transporte) receptor
P3 P4
dados da camada M M
de aplicação
aplicação
cabeçalho do P1 transporte P2
segmento M
M rede
aplicação aplicação
segmento Ht M transporte transporte
Hn segmento rede rede

5. Multiplexação de Aplicações
Multiplexação:
reunir dados de múltiplos 32 bits
processo de aplicação, juntar
cabeçalhos com informações porta origem porta destino
para demultiplexação
outros campos de cabeçalho
multiplexação/demultiplexação:
• baseada nos número de porta do
transmissor, número de porta do dados de aplicação
receptor e endereços IP (mensagem)
– números de porta origem e
destino em cada segmento
– lembre: portas com números
bem-conhecidos são usadas
formato do segmento TCP/UDP
para aplicações específicas

6. Multiplexação: exemplos
porta origem: x cliente Web
host A porta dest.: 23 servidor B host C
porta origem:23
port dest.: x
IP Origem: C IP Origem: C
IP Dest: B IP Dest: B
porta origem: y porta origem: x
aplicação Telnet porta dest.: 80 porta dest.: 80
IP Origem: A
IP Dest: B Servidor
cliente Web porta origem : x Web B
host A porta dest.: 80
aplicação: servidor Web

7. UDP: User Datagram Protocol [RFC 768]
• protocolo de transporte da
Internet “sem gorduras” “sem Porque existe um UDP?
frescuras”
• não há estabelecimento de
• serviço “best effort” , segmentos
conexão (que pode redundar em
UDP podem ser:
atrasos)
– perdidos • simples: não há estado de conexão
– entregues fora de ordem nem no transmissor, nem no receptor
para a aplicação • cabeçalho de segmento reduzido
• sem conexão: • não há controle de congestionamento:
– não há apresentação entre o UDP pode enviar segmentos tão
UDP transmissor e o rápido quanto desejado (e possível)
receptor
– cada segmento UDP é
tratado de forma
independente dos outros

8. Mais sobre UDP
• muito usado por aplicações de
mutimídia contínua (streaming) 32 bits
– tolerantes à perda Tamanho, em
porta origem porta destino
– sensíveis à taxa bytes do segmento tamanho checksum
UDP, incluíndo
• outros usos do UDP cabeçalho
(porque?):
– DNS
– SNMP Dados de Aplicação
(mensagem)
• transferência confiável sobre
UDP: acrescentar confiabilidade na
camada de aplicação
– recuperação de erro
específica de cada aplicação formato do segmento UDP

9. UDP checksum
Objetivo: detectar “erros” (ex.,bits trocados) no segmento
transmitido
Transmissor: Receptor:
• trata o conteúdo do segmento • computa o checksum do segmento
como seqüencia de inteiros de recebido
16 bits • verifica se o checksum calculado é
• checksum: soma (complemento igual ao valor do campo checksum:
de 1 da soma) do conteúdo do – NÃO - error detectado
segmento
– SIM - não há erros. Mas,
• transmissor coloca o valor do
talvez haja erros apesar
checksum no campo de checksum
do UDP disto? Mais depois ….

10. Princípios de Transferência Confiável de
Dados
• importante nas camadas de aplicação, transporte e enlace
• top-10 na lista dos tópicos mais importants de redes!
• caracteristicas dos canais não confiáveis determinarão a complexidade
dos protocolos confiáveis de transferência de dados (rdt)

11. Transferência confiável: o ponto de partida
rdt_send(): chamada da camada superior, deliver_data(): chamada pela
(ex., pela aplicação). Passa dados para entidade de transporte para
entregar à camada superior receptora entregar dados para cima
lado lado
transmissor receptor
udt_send(): chamada pela entidade rdt_rcv(): chamada quando o pacote chega
de transporte, para transferir pacotes ao lado receptor do canal
para o receptor sobre o canal não
confiável

12. Transferência confiável: o ponto de partida
Etapas:
• desenvolver incrementalmente o transmissor e o receptor de um
protocolo confiável de transferência de dados (rdt)
• considerar apenas transferências de dados unidirecionais
– mas informação de controle deve fluir em ambas as direções!
• usar máquinas de estados finitos (FSM) para especificar o
protocolo transmissor e o receptor
evento causando transição de estados
ações tomadas na transição de estado
estado: quando neste “estado”
o próximo estado fica estado estado
1 evento
unicamente determinado 2
pelo próximo evento ações

13. Rdt1.0: transferência confiável sobre canais
confiáveis
• canal de transmissão perfeitamente confiável
– não há erros de bits
– não há perdas de pacotes
• FSMs separadas para transmissor e receptor:
– transmissor envia dados para o canal subjacente
– receptor lê os dados do canal subjacente

14. Rdt2.0: canal com erros de bit
• canal subjacente pode trocar valores dos bits num pacote
– lembrete: checksum do UDP pode detectar erros de bits
• a questão: como recuperar esses erros:
– reconhecimentos (ACKs): receptor avisa explicitamente ao
transmissor que o pacote foi recebido corretamente
– reconhecimentos negativos (NAKs): receptor avisa explicitamente
ao transmissor que o pacote tem erros
– transmissor reenvia o pacote quando da recepção de um NAK
– cenários humanos usando ACKs, NAKs?
• novos mecanismos no rdt2.0 (além do rdt1.0):
– deteção de erros
– retorno do receptor: mensagens de controle
(ACK,NAK) rcvr->sender

15. rdt2.0: especificação da FSM
FSM do transmissor FSM do receptor

16. rdt2.0: em ação (ausência de erros)
FSM do transmissor FSM do receptor

17. rdt2.0: em ação (cenário com erros)
FSM do transmissor FSM do receptor

18. rdt2.0 tem um problema fatal!
O que acontece se o ACK/NAK é Tratando duplicatas:
corrompido? • transmissor acrescenta número de
• transmissor não sabe o que seqüência em cada pacote
aconteceu no receptor! • Transmissor reenvia o último
• não pode apenas retransmitir: pacote se f ACK/NAK for perdido
possível duplicata • receptor descarta (não passa para a
aplicação) pacotes duplicados
O que fazer?
• Transmissor envia ACKs/NAKs
para reconhecer os ACK/NAK do stop and wait
receptor? O que acontece se estes Transmissor envia um pacote
ACK/NAK se perdem? e então espera pela resposta
• retransmitir os ACK/NAK, mas do receptor
isto poderia causar a retransmissão
de um pacote recebido
corretamente!

19. rdt2.1: transmissor, trata ACK/NAKs perdidos

20. rdt2.1: receptor, trata ACK/NAKs perdidos

21. rdt2.1: discusssão
Transmissor: Receptor:
• adiciona número de seqüência • deve verificar se o pacote
ao pacote
recebido é duplicado
• Dois números (0 e 1) bastam.
Porque? – estado indica se o pacote 0
ou 1 é esperado
• deve verificar se os ACK/NAK
recebidos estão corrompidos • nota: receptor pode não
• duas vezes o número de estados saber se seu últino
– o estado deve “lembrar” se o ACK/NAK foi recebido
pacote “corrente” tem número pelo transmissor
de seqüência 0 ou 1

22. rdt2.2: um protocolo sem NAK
• mesma funcionalidade do rdt2.1,
usando somente ACKs
• ao invés de enviar NAK, o
receptor envia ACK para o
último pacote recebido sem erro
– receptor deve incluir
explicitamente o número de
seqüência do pacote sendo
reconhecido
• ACKs duplicados no !
transmissor resultam na mesma
ação do NAK: retransmição do FSM do
pacote corrente transmissor

23. rdt3.0: canais com erros e perdas
Nova Hipótese: canal de Abordagem: transmissor espera
transmissão pode também um tempo “razoável” pelo
perder pacotes (dados oo ACK
ACKs) • retransmite se nenhum ACK for
recebido neste tempo
– checksum, números de
seqüência, ACKs, • se o pacote (ou ACK) estiver
retransmissões serão de apenas atrasado (não perdido):
ajuda, mas não o bastante – retransmissão será duplicata,
mas os números de seqüência
Q: como tratar com perdas?
já tratam com isso
– transmissor espera até que
– receptor deve especificar o
certos dados ou ACKs
número de seqüência do
sejam perdidos, então
pacote sendo reconhecido
retransmite
• exige um temporizador
– problemas?
decrescente

24. rdt3.0 sender

25. rdt3.0 em ação
(a) operação sem perda
(b) pacote perdido

26. rdt3.0 em ação
(c) ACK perdido (d) timeout prematuro

27. Desempenho do rdt3.0
• rdt3.0 funciona, mas o desempenho é sofrível
• exemplo: enlace de 1 Gbps, 15 ms de atraso de propagação,
pacotes de 1KB:
8kb/pct
transmissão = = 8 µs
10**9 b/seg
fração do tempo 8 µs
Utilização = U = transmissor ocupado = = 0.00015
30,016 ms
– Um pacote de 1KB cada 30 ms -> 33kB/seg de vazão sobre
um canal de 1 Gbps
– o protocolo de rede limita o uso dos recursos físicos!

28. Protocolos com Paralelismo (pipelining)
Paralelismo: transmissor envia vários pacotes ao mesmo
tempo, todos esperando para serem reconhecidos
– faixa de números de seqüência deve ser aumentada
– armazenamento no transmissor e/ou no receptor
(a) operação do protocolo stop-and-wait (a) operação do protocolo com paralelismo
• Duas formas genéricas de protocolos com paralelismo: go-
Back-N, retransmissão seletiva

29. Go-Back-N
Transmissor:
• Número de seqüência com k bits no cabeçalho do pacote
• “janela” de até N, pacotes não reconhecidos, consecutivos, são permitidos
• ACK(n): reconhece todos os pacotes até o número de seqüência N
(incluindo este limite). “ACK cumulativo”
– pode receber ACKS duplicados (veja receptor)
• temporizador para cada pacote enviado e não confirmado
• timeout(n): retransmite pacote n e todos os pacotes com número de
seqüência maior que estejam dentro da janela

30. GBN: FSM estendida para o transmissor

31. GBN: FSM estendida para o receptor
receptor simples:
• somente ACK: sempre envia ACK para pacotes corretamente recebidos
com o mais alto número de seqüência em ordem
– pode gerar ACKs duplicados
– precisa lembrar apenas do número de seqüência esperado
(expectedseqnum)
• pacotes fora de ordem:
– descarte (não armazena) -> não há buffer de recepção!
– reconhece pacote com o mais alto número de seqüência em ordem

32. GBN em ação

33. Retransmissão Seletiva
• receptor reconhece individualmente todos os
pacotes recebidos corretamente
– armazena pacotes, quando necessário, para eventual
entrega em ordem para a camada superior
• transmissor somente reenvia os pacotes para os
quais um ACK não foi recebido
– transmissor temporiza cada pacote não reconhecido
• janela de transmissão
– N números de seqüência consecutivos
– novamente limita a quantidade de pacotes enviados,
mas não reconhecidos

34. Retransmissão seletiva: janelas do transmissor e
do receptor
(a) visão dos números de seqüência pelo transmissor
(b) visão dos números de seqüência pelo receptor

35. Retransmissão seletiva
transmissor receptor
dados da camada superior : pacote n em [rcvbase, rcvbase+N-1]
• se o próximo número de seqüência • envia ACK(n)
disponível está na janela, envia o • fora de ordem: armazena
pacote
• em ordem: entrega (também
timeout(n): entrega pacotes armazenados
• reenvia pacote n, em ordem), avança janela para
restart timer
o próximo pacote ainda não
ACK(n) em [sendbase,sendbase+N]: recebido
• marca pacote n como recebido
pkt n em [rcvbase-N,rcvbase-1]
• se n é o menor pacote não
reconhecido, avança a base da • ACK(n)
janela para o próximo número de caso contrário:
seqüência não reconhecido
• ignora

36. Retransmissão seletiva em ação

37. Retransmissão seletiva:
dilema
Exemplo:
• seqüências: 0, 1, 2, 3
• tamanho da janela=3
• receptor não vê diferença
nos dois cenários!
• incorretamente passa
dados duplicados como
novos (figura a)
Q: qual a relação entre o
espaço de numeração
seqüencial e o tamanho da
janela?