Redes de Computadores: Camada de Transporte UFPB

Universidade Federal da Paraíba
Centro de Ciências Aplicadas e Educação
Departamento de Ciências Exatas

Redes de Computadores:
Camada de Transporte

Prof. Rafael Marrocos Magalhães
rafael@dce.ufpb.br

20 de Setembro de 2011 UFPB - CCAE - DCE

Esta apresentação contém partes, ou mesmo slides inteiros, da apresentação original disponibilizada por J.F Kurose e K.W. Ross, com permissão para
utilização como material de apoio instrucional. E, conforme solicitação do original, incluí aqui a nota de direito autoral.

quarta-feira, 28 de setembro de 11 1

Motivação

Como as aplicações
se comunicam?


Sumário
Serviços da camada de transporte
Multiplexação e demultiplexação
Transporte não orientado para conexão: UDP
Princípios de transferência conﬁável de dados
Transporte orientado para conexão: TCP
Princípios de controle de congestionamento
Controle de congestionamento: TCP


Sumário
3.1 Serviços da camada de transporte


Serviços e protocolos
de transporte
!  oferecem comunicação lógica aplicação

entre processos de aplicação transporte
rede
rodando em hospedeiros enlace
física
diferentes
!  protocolos de transporte rodam
em sistemas finais
"  lado remetente: divide as msgs
da aplicação em segmentos,
passa à camada de rede
"  lado destinatário: remonta os
segmentos em msgs, passa à aplicação

camada de aplicação transporte
rede
enlace
!  mais de um protocolo de física

transporte disponível às
aplicações
"  Internet: TCP e UDP


Camada de transporte
Transporte X Rede
versus rede
Camada de transporte
!  camada de rede:
versus rede comunicação lógica
entre hospedeiros
!  camada de rede: analogia com a família:
!  camada de transporte:
comunicação lógica
entre hospedeiros
X comunicação mandando
12 crianças lógica
entre processos
carta a 12 crianças
conta com e amplia os
!  camada de transporte: !  processos = crianças
" 
serviços da camada de
comunicação lógica !  msgs da aplicação =
rede
entre processos cartas nos envelopes
"  conta com e amplia os !  hospedeiros = casas
serviços da camada de
rede !  protocolo de transpor

da de transporte
s rede Analogia
da de rede: analogia com a família:
nicação lógica 12 crianças mandando
hospedeiros carta a 12 crianças
da de transporte: !  processos = crianças
nicação lógica !  msgs da aplicação =
processos cartas nos envelopes
ta com e amplia os !  hospedeiros = casas
viços da camada de
e !  protocolo de transporte
= Ana e Bill
!  protocolo da camada de
rede = serviço postal


Protocolos da camada
Protocolos de transporte
de transporte da Internet
!  remessa confiável e em
aplicação
transporte
rede
ordem (TCP) enlace
física

"  controle de congestionamento rede
enlace rede
enlace
"  controle de fluxo física
física

"  estabelecimento da conexão rede
enlace
!  remessa não confiável e física

desordenada: UDP rede
enlace
física
"  extensão sem luxo do IP pelo network
rede
data link
enlace
“melhor esforço” physical
física
rede aplicação
transporte
enlace

!  serviços não disponíveis:
física rede
enlace
física
"  garantias de atraso
"  garantias de largura de banda


Sumário
3.2 Multiplexação e demultiplexação


Multiplexação/
Multiplexação
demultiplexação
e demultiplexação
demultiplexação no destinatário: multiplexação no remetente:
entregando segmentos colhendo dados de múltiplos
recebidos ao socket correto sockets, envelopando dados
com cabeçalho (usados depois
= socket = processo para demultiplexação)

aplicação P3 P1
P1 aplicação P2 P4 aplicação

transporte transporte transporte

rede rede rede

enlace enlace enlace

física física física

hospedeiro 2 hospedeiro 3
hospedeiro 1


Como funciona a
Como funciona: demultiplexação
Como funciona a
demultiplexação
demultiplexação
!  hospedeiro recebe
!  hospedeiro recebe
datagramas IP
datagramas IP 32 bits bits
32
"  cada datagrama tem
"  cada datagrama tem
endereçoIP de origem, # porta origem # porta destinodestino
# porta origem # porta
endereço IP de origem,
endereçoIP de destino
endereço IP de destino
"  cada datagrama carrega 1 1
"  cada datagrama carrega outros campos de cabeçalho
outros campos de cabeçalho
segmentoda camada de
segmento da camada de
transporte
transporte
"  cada segmento tem
"  cada segmento tem dados da
número de porta de dados da
número destino de
de porta aplicação
origem, aplicação
(mensagem)
origem, destino (mensagem)
!  hospedeiro usa endereços IP
!  hospedeirode porta para
& números usa endereços IP
& números segmento ao
direcionar de porta para formato do segmento TCP/UDP
direcionar segmento ao
socket apropriado formato do segmento TCP/U
socket apropriado

demultiplexação não orientada para conexão
Demultiplexação
não orientada para conexão
!  quando hospedeiro
!  cria sockets com números
recebe segmento UDP:
de porta: "  verifica número de porta
DatagramSocket mySocket1 = new de destino no segmento
DatagramSocket(12534); "  direciona segmento UDP
DatagramSocket mySocket2 = new para socket com esse
DatagramSocket(12535); número de porta
!  socket UDP identificado por !  datagramas IP com
tupla de dois elementos: diferentes endereços IP
(endereço IP destino, número porta de origem e/ou números
destino) de porta de origem
direcionados para o
mesmo socket


demultiplexação não orientada para conexão

DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

SP: 6428 SP: 6428
DP: 9157 DP: 5775

SP: 9157 SP: 5775
cliente DP: 6428 DP: 6428 Cliente
servidor
IP: A IP: C IP:B

SP oferece “endereço de retorno”


Demultiplexaçãoorientada para conexão
demultiplexação orientada
para conexão
!  socket TCP identificado !  hospedeiro servidor pode
por tupla de 4 elementos: admitir muitos sockets
"  endereço IP de origem TCP simultâneos:
"  número de porta de origem "  cada socket identificado
"  endereço IP de destino por usa própria tupla de 4
"  número de porta de destino !  servidores Web têm
!  hospedeiro destinatário diferentes sockets para
usa todos os quatro cada cliente conectando
valores para direcionar "  HTTP não persistente terá
segmento ao socket diferentes sockets para
cada requisição
apropriado


demultiplexação orientada para conexão

P1 P4 P5 P6 P2 P1
P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157
cliente DP: 80 DP: 80 cliente
servidor
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C


Demultiplexação orientada
demultiplexação orientada para conexão
para conexão: servidor Web
threadedWEB
Servidor

P1 P4 P2 P1
P3

SP: 5775
DP: 80
S-IP: B
D-IP:C

SP: 9157 SP: 9157
cliente DP: 80 DP: 80 cliente
servidor
IP: A S-IP: A
IP: C S-IP: B IP:B
D-IP:C D-IP:C


Sumário
3.3 Transporte não orientado para conexão:
UDP


UDP: User Datagram
UDP: User Datagram Protocol
Protocol [RFC 768] RFC 768
!  protocolo de transporte da
Internet “sem luxo”, básico Por que existe um UDP?
!  serviço de “melhor esforço”, !  sem estabelecimento de
segmentos UDP podem ser: conexão (que pode gerar
atraso)
"  perdidos !  simples: sem estado de
"  entregues à aplicação conexão no remetente,
fora da ordem destinatário
!  cabeçalho de segmento
!  sem conexão: pequeno
"  sem handshaking entre !  sem controle de
remetente e destinatário congestionamento: UDP
UDP pode transmitir o mais
rápido possível
"  cada segmento UDP
tratado independente
dos outros


Quem usa UDP?

DNS Stream Multimídia

RIP VoIP

SNMP NFS

Muitos outros...


UDP: User Datagram Protocol
UDP: mais
!  normalmente usado para
streaming de aplicações de 32 bits
multimídia
tamanho, # porta origem # porta dest.
"  tolerante a perdas em bytes, do tamanho soma verif.
"  sensível à taxa segmento UDP,
incluindo
!  outros usos do UDP cabeçalho
"  DNS
"  SNMP dados da
!  transferência confiável por aplicação
UDP: aumenta confiabilidade (mensagem)
na camada de aplicação
"  recuperação de erro
específica da aplicação! formato de segmento UDP


Soma de Veriﬁcação
Soma de verificação UDP

objetivo: detectar “erros” (p. e., bits invertidos) no
segmento transmitido
destinatário:
remetente: !  calcula soma de verificação do
!  trata conteúdo de segmento recebido
segmento como sequência !  verifica se soma de verificação
de inteiros de 16 bits
!  soma de verificação
calculada igual ao valor do
(checksum): adição (soma campo de soma de verificação:
por complemento de 1) do "  NÃO – erro detectado
conteúdo do segmento
"  SIM – nenhum erro
!  remetente coloca valor da
soma de verificação no detectado. Mas pode haver
campo de soma de erros mesmo assim? Veja
verificação UDP mais adiante ….


Exemplo de soma de
verificação da Exemplo
Internet

!  nota
"  Ao somar números, um carryout do bit mais
significativo precisa ser somado ao resultado
!  exemplo: somar dois inteiros de 16 bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

contorna 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

soma 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
soma de 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
verificação


Sumário
3.4 Princípios de transferência conﬁável
de dados

Princípios

Importante também nas três camadas: aplicação,
transporte e enlace
Está na lista dos 10 tópicos mais importantes no
desenvolvimento das redes de computadores!
As características do canal confiável são
determinantes na complexidade do protocolo de
transferência confiável

Protocolo fictício de estudo [rdt]


Transferência conﬁável dede
Transferência confiável dados: introdução
dados: introdução
rdt_send(): chamado de cima, (p. e., deliver_data(): chamado pela
pela apl.). Dados passados para remeter rdt para remeter dados para cima
à camada superior do destinatário

lado lado
remetente destinatário

udt_send(): chamado pela rdt_rcv(): chamado quando pacote
rdt, para transferir pacote por chega no lado destinatário do canal
canal não confiável ao
destinatário


Protocolo ﬁctício
vamos:
!  desenvolver de forma incremental os lados remetente e
destinatário do protocolo de transferência confiável de dados
(rdt)
!  considerar apenas a transf. de dados unidirecional
"  mas informações de controle fluirão nas duas direções!
!  usar máquinas de estado finito (FSM) para especificar
remetente, destinatário
evento causando transição de estado
ações tomadas sobre transição de estado
estado: quando neste
“estado”, próximo estado estado
1 evento
estado determinado 2
exclusivamente pelo ações
próximo evento


Rdt1.0: transferência
[rdt 1.0] : transferência conﬁável por canal conﬁável
confiável por canal confiável
!  canal subjacente perfeitamente confiável
"  sem erros de bit
"  sem perda de pacotes

!  FSMs separadas para remetente e destinatário:
"  remetente envia dados para canal subjacente
"  destinatário lê dados do canal subjacente

Espera rdt_send(dados) Espera rdt_rcv(pacote)
chamada chamada extract (pacote, dados)
de cima packet = make_pkt(dados) de baixo deliver_data(dados)
udt_send(pacote)



Rdt2.0: canal2.0] : canal com erros de bit
[rdt com erros
de bit
!  canal subjacente pode inverter bits no pacote
"  soma de verificação para detectar erros de bit

!  a questão: como recuperar-se dos erros:
"  reconhecimentos (ACKs): destinatário diz explicitamente
ao remetente que o pacote foi recebido OK
"  reconhecimentos negativas (NAKs): destinatário diz
explicitamente ao remetente que o pacote teve erros
"  remetente retransmite pacote ao receber NAK
!  novos mecanismos no rdt2.0 (além do rdt1.0):
"  detecção de erro
"  feedback do destinatário: msgs de controle (ACK,NAK)
destinatário->remetente


[rdt 2.0] : especiﬁcação de uma
máquina de estado ﬁnita
rdt2.0: especificação da FSM
rdt_send(dados)
snkpkt = make_pkt(dados, soma_verif)
udt_send(pctenv)
destinatário
rdt_rcv(pctrec) &&
isNAK(pctrec)
Espera Espera rdt_rcv(pctrec) &&
chamada ACK ou udt_send(pctenv) corrupt(pctrec)
de cima NAK
udt_send(NAK)

rdt_rcv(pctrec) && isACK(pctrec)
Espera
!"
chamada
remetente de baixo

rdt_rcv(pctrec) &&
notcorrupt(pctrec)
extract(pctrec,dados)
deliver_data(dados)
udt_send(ACK)


[rdt 2.0] : operação sem erros
rdt2.0: operação sem erros
rdt_send(dados)
udt_send(pctenv)
rdt_rcv(pctrec) &&
isNAK(pctrec)
de cima NAK
udt_send(NAK)

Espera
!" chamada
de baixo

rdt_rcv(pctrec) &&
notcorrupt(pctrec)
deliver_data(dados)
udt_send(ACK)


[rdt 2.0] : operação com erros
rdt2.0: cenário de erro
rdt_send(dados)
udt_send(pctenv)
rdt_rcv(pctrec) && isNAK(pctrec)

de cima NAK
udt_send(NAK)

Espera
!" chamada
de baixo

rdt_rcv(pctrec) &&
notcorrupt(pctrec)
deliver_data(dados)
udt_send(ACK)


[rdt 2.0] : problema nesta versão!
rdt2.0 tem uma falha fatal!

O que acontece se ACK/ tratando de duplicatas:
NAK for corrompido? !  remetente retransmite
!  remetente não sabe o que pacote atual se ACK/NAK
aconteceu no destinatário! corrompido
!  não pode simplesmente !  remetente acrescenta
retransmitir: possível número de sequência a cada
duplicação pacote
!  destinatário descarta (não
sobe) pacote duplicado

pare e espere
remetente envia um pacote,
depois espera resposta do
destinatário


[rdt 2.1] : remetente ACK/NACKs corrompidos
rdt2.1: tratamento de trata de
ACK/NAKs corrompidos
rdt_send(dados)
remetente
pctenv = make_pkt(0, dados, checksum)
udt_send(pctenv)
rdt_rcv(pctrec) &&
( corrupt(pctrec) ||
Espera Espera
isNAK(pctrec) )
chamada 0 ACK ou
NAK 0 udt_send(pctenv)
de cima
rdt_rcv(pctrec)
&& notcorrupt(pctrec) rdt_rcv(pctrec)
&& isACK(pctrec) && notcorrupt(pctrec)
&& isACK(pctrec)
!"
!"
Espera Espera
ACK ou chamada 1
rdt_rcv(pctrec) && NAK 1 de cima
isNAK(pctrec) ) rdt_send(dados)

udt_send(pctenv) pctenv = make_pkt(1, dados, checksum)
udt_send(pctenv)


[rdt 2.1] : tratamento de ACK/NACKs corrompidos

rdt_rcv(pctrec) && notcorrupt(pctrec)
destinatário && has_seq0(pctrec)
deliver_data(dados)
pctenv = make_pkt(ACK, chksum)
udt_send(pctenv)
rdt_rcv(pctrec) && (corrupt rdt_rcv(pctrec) && (corrupt
(pctrec) (pctrec) = make_pkt(NAK, chksum)
pctenv = make_pkt(NAK, chksum) pctenv
udt_send(pctenv) udt_send(pctenv)
Espera Espera
rdt_rcv(pctrec) && 0 de 1 de rdt_rcv(pctrec) &&
not corrupt(pctrec) && cima baixo not corrupt(pctrec) &&
has_seq1(pctrec) has_seq0(pctrec)
pctenv = make_pkt(ACK, chksum) pctenv = make_pkt(ACK, chksum)
udt_send(pctenv) udt_send(pctenv)
&& has_seq1(pctrec)

deliver_data(dados)
pctenv = make_pkt(ACK, chksum)
udt_send(pctenv)


rdt2.1: discussão
[rdt 2.1] : considerações

remetente: destinatário:
!  # seq acrescentado ao !  deve verificar se
pkt pacote recebido está
!  dois #s seq. (0,1) duplicado
bastarão. Por quê? "  estado indica se 0 ou 1 é
# seq. esperado do
!  deve verificar se ACK/ pacote
NAK recebido foi
!  nota: destinatário não
corrompido
sabe se seu último
!  o dobro de estados ACK/NAK foi recebido
"  estado de “lembrar” se OK no remetente
pacote “atual” tem #
seq. 0 ou 1


[rdt 2.2] : um protocolo sem NAK*
rdt2.2: um protocolo sem NAK

!  mesma funcionalidade de rdt2.1, usando apenas ACKs
!  em vez de NAK, destinatário envia ACK para último
pacote recebido OK
"  destinatário precisa incluir explicitamente # seq. do pacote
sendo reconhecido com ACK
!  ACK duplicado no remetente resulta na mesma ação
de NAK: retransmitir pacote atual


rdt2.2: fragmentos do
[rdt 2.2] : um protocolo sem NAK*
remetente, destinatário
rdt_send(dados)
udt_send(pctenv)
rdt_rcv(pctrec) &&
Espera Espera
ACK isACK(pctrec,1) )
chamada 0
de cima 0 udt_send(pctenv)
fragmento FSM
do remetente rdt_rcv(pctrec)
&& notcorrupt(pctrec)
rdt_rcv(pctrec) && && isACK(pctrec,0)
(corrupt(pctrec) || !"
has_seq1(pctrec)) Espera fragmento FSM
0 de
udt_send(pctenv) baixo do destinatário
&& has_seq1(pctrec)
deliver_data(dados)
pctenv = make_pkt(ACK1, chksum)
udt_send(pctenv)


rdt3.0: canais: canais erros
[rdt 3.0] com com erros e perdas
e perda
nova suposição: canal técnica: remetente espera
subjacente também quantidade “razoável” de
pode perder pacotes tempo por ACK
(dados ou ACKs) !  retransmite se não chegar ACK
"  soma de verificação, # nesse tempo
seq., ACKs, !  se pct (ou ACK) simplesmente
retransmissões serão atrasado (não perdido):
úteis, mas não "  retransmissão será
suficientes duplicada, mas os #s de seq.
já cuidam disso
"  destinatário deve especificar
# seq. do pacote sendo
reconhecido com ACK
!  requer contador regressivo


[rdt 3.0] : canais com erros e perdas
remetente rdt3.0
rdt_send(dados)
remetente rdt_rcv(pctrec) &&
udt_send(pctenv) ( corrupt(pctrec) ||
start_timer isACK(pctrec,1) )
rdt_rcv(pctrec) !"
!" Espera Espera timeout
chamada 0 ACK0 udt_send(pctenv)
de cima
start_timer
rdt_rcv(pctrec)
&& notcorrupt(pctrec) rdt_rcv(pctrec)
&& isACK(pctrec,1) && notcorrupt(pctrec)
stop_timer && isACK(pctrec,0)
stop_timer

Espera Espera
timeout chamada 1
udt_send(pctenv) ACK1
de cima
start_timer rdt_rcv(pctrec)
rdt_send(dados) !"
rdt_rcv(pctrec) &&
( corrupt(pctrec) || pctenv = make_pkt(1, dados, checksum)
isACK(pctrec,0) ) udt_send(pctenv)
start_timer
!"


[rdt 3.0] : em ação
rdt3.0 em ação


[rdt 3.0] : em ação


[rdt 3.0] : desempenho
Desempenho do rdt3.0
!  rdt3.0 funciona, mas com desempenho ruim
!  ex.: enlace 1 Gbps, 15 ms atraso propriedade, pacote
8000 bits:

"  U remet: utilização – fração do tempo remet. ocupado enviando

"  Pct. 1 KB cada 30 ms -> 33 kB/s vazão em enlace de 1 Gbps
"  protocolo de rede limita uso de recursos físicos!


rdt3.0: operação pare e pare e espere
[rdt 3.0] : operação tipo
espere


Protocolos com paralelismo
Protocolos com paralelismo
paralelismo: remetente permite múltiplos pacotes
“no ar”, ainda a serem reconhecidos
"  intervalo de números de sequência deve ser aumentado
"  buffering no remetente e/ou destinatário

!  duas formas genéricas de protocolo com paralelismo:
Go-Back-N, repetição seletiva


Paralelismo: utilizaçãoutilização do canal
Paralelismo aumenta
aumentada

Aumento de utilização
por fator de 3!


rotocolos com paralelismo Protocolos com paralelismo

Go-back-N: visão geral Repetição seletiva: visão geral
!  remetente: até N pacotes !  remetente: até pacotes não
não reconhecidos na reconhecidos na pipeline
pipeline !  destinatário: reconhece (ACK)
!  destinatário: só envia ACKs pacotes individuais
cumulativos !  remetente: mantém
"  não envia pct ACK se temporizador para cada pct sem
houver uma lacuna ACK
!  remetente: tem "  se o temporizador expirar:
temporizador para pct sem retransmite apenas o pacote
ACK mais antigo sem ACK
"  se o temporizador expirar:
retransmite todos os
pacotes sem ACK


Go-Back-N
Go-Back-N
remetente:
!  # seq. de k bits no cabeçalho do pacote
!  “janela” de até N pcts consecutivos sem ACK permitidos

!  ACK(n): ACK de todos pcts até inclusive # seq. n – “ACK
cumulativo”
"  pode receber ACKs duplicados (ver destinatário)
!  temporizador para cada pacote no ar
!  timeout(n): retransmite pct n e todos pcts com # seq. mais alto
na janela


GBN:Máquina de estado estendida GBN
FSM estendido no
remetente
rdt_send(dados)

remetente if (nextseqnum < base+N) {
pctenv[nextseqnum] = make_pkt(nextseqnum,dados,chksum)
udt_send(pctenv[nextseqnum])
if (base = = nextseqnum)
start_timer
nextseqnum++
}
!" else
refuse_data(dados)
base = 1
nextseqnum = 1
timeout
start_timer
Espera
udt_send(pctenv[base])
rdt_rcv(pctrec) udt_send(pctenv[base+1])
&& corrupt(pctrec) …
udt_send(pctenv
[nextseqnum-1])
rdt_rcv(pctrec) &&
notcorrupt(pctrec)
base = getacknum(pctrec)+1
If (base = = nextseqnum)
stop_timer
else
start_timer


Máquina de estado estendida GBN
GBN: FSM estendido no
destinatário
destinatário default
udt_send(pctenv) rdt_rcv(pctrec)
&& notcurrupt(pctrec)
!" && hasseqnum(pctrec,expectedseqnum)
expectedseqnum = 1 Espera extract(pctrec,dados)
pctenv = deliver_data(dados)
make_pkt(expectedseqnum,ACK,chksum) pctenv = make_pkt(expectedseqnum,ACK,chksum)
udt_send(pctenv)
expectedseqnum++

apenas ACK: sempre envia ACK para pct recebido
corretamente com # seq. mais alto em ordem
"  pode gerar ACKs duplicados
"  só precisa se lembrar de expectedseqnum
!  pacote fora de ordem:
"  descarta (não mantém em buffer) -> sem buffering no
destinatário!
"  reenvia ACK do pct com # seq. mais alto em ordem


GBN em operação
Go-Back-N em ação


Repetição seletiva

!  destinatário reconhece individualmente todos os
pacotes recebidos de modo correto
"  mantém pcts em buffer, se for preciso, para eventual
remessa em ordem para a camada superior
!  remetente só reenvia pcts para os quais o ACK
não foi recebido
"  temporizador no remetente para cada pct sem ACK
!  janela do remetente
"  N # seq. consecutivos
"  novamente limita #s seq. de pcts enviados, sem ACK


Repetição seletiva: janelas
Repetição seletiva: janelas
de remetente, destinatário
remetente

destinatário


dados de cima: pct n em [rcvbase, rcvbase
+N-1]
!  se próx. # seq. disponível
na janela, envia pct !  envia ACK(n)
!  fora de ordem: buffer
timeout(n):
!  em ordem: entrega
!  reenvia pct n, reinicia
(também entrega pcts em
temporizador
ordem no buffer), avança
ACK(n) em [sendbase,sendbase janela para próximo pct
+N]: ainda não recebido
!  marca pct n como recebido
pct n em [rcvbase-N,rcvbase-1]
!  se n menor pct com ACK,
!  ACK(n)
avança base da janela para
próximo # seq. sem ACK caso contrário:
!  ignora


Repetição seletiva em
Repetição seletiva em ação
operação


Repetição seletiva:
Repetição seletiva: dilema
dilema
Exemplo:
!  # seq.: 0, 1, 2, 3
!  tamanho janela = 3
!  destinatário não vê
diferença nos dois cenários!
!  passa incorretamente
dados duplicados como
novos em (a)

P: Qual o relacionamento
entre tamanho do # seq. e
tamanho de janela?


Sumário
3.5 Transporte orientado para conexão:
TCP


TCP: Visão geral
TCP: Visão geral
RFCs: 793, 1122, 1323, 2018, 2581
!  ponto a ponto:
!  dados full duplex:
"  um remetente, um
destinatário "  dados bidirecionais fluem
!  cadeia de bytes confiável, em na mesma conexão
ordem: "  MSS: tamanho máximo do
"  sem “limites de mensagem” segmento
!  paralelismo: !  orientado a conexão:
"  congestionamento TCP e
controle de fluxo definem "  apresentação (troca de
tamanho da janela msgs de controle) inicia
!  buffers de envio & recepção estado do remetente e
destinatário antes da
troca de dados
!  fluxo controlado:
"  remetente não
sobrecarrega destinatário


Estrutura do segmento TCP
TCP: Estrutura do segmento

32 bits
URG: dados urgentes contagem por
(quase não usado) porta origem porta destino bytes de dados
(não segmentos!)
ACK: # ACK número sequência
válido número reconhecimento
compr. não
cab. usado
UA P R S F janela recepção # bytes
PSH: empurrar dados destinatário
agora (quase não usado) soma verificação ponteiro dados urg. pode aceitar
RST, SYN, FIN: opções (tamanho variável)
estab. conexão
(comandos setup,
teardown)
dados da
soma de verificação
da Internet aplicação
(como em UDP) (tamanho variável)


TCP: número de seqüência [#s] e ACKs do TCP
#s sequência e ACKs do TCP

#’s de sequência:
"  “número” na cadeia de
bytes do 1o byte nos
dados do segmento
ACKs:
"  # seq do próximo byte
esperado do outro lado
"  ACK cumulativo
P: como o destinatário trata
segmentos fora de ordem
"  R: TCP não diz – a critério
do implementador
cenário telnet simples


TCP: tempoe volta volta [RTT] e timeout
Tempo de ida de ida e e
timeout do TCP
P: Como definir o valor P: Como estimar o RTT?
de timeout do TCP? !  SampleRTT: tempo medido
!  maior que RTT da transmissão do segmento
"  mas RTT varia até receber o ACK
!  muito curto: "  ignora retransmissões

timeout prematuro !  SampleRTT variará;
"  retransmissões queremos RTT estimado
desnecessárias “mais estável”
!  muito longo: baixa "  média de várias medições

reação a perda de recentes, não apenas
segmento SampleRTT atual


TCP: tempo de ida e volta [RTT] e timeout

EstimatedRTT = (1- #)*EstimatedRTT + #*SampleRTT

!  média móvel exponencial ponderada
!  influência da amostra passada diminui exponencialmente
rápido
!  valor típico: # = 0,125


Amostras de RTTs estimados:
Amostras de RTTs estimados


Tempo de ida
TCP: tempo dee volta e [RTT] e timeout
ida e volta
timeout do TCP
definindo o timeout
!  EstimtedRTT mais “margem de segurança”
"  grande variação em EstimatedRTT -> maior margem de seg.
!  primeira estimativa do quanto SampleRTT se desvia de
EstimatedRTT:

DevRTT = (1-$)*DevRTT +
$*|SampleRTT-EstimatedRTT|

(geralmente, $ = 0,25)

depois definir intervalo de timeout

TimeoutInterval = EstimatedRTT + 4*DevRTT


TCP: transferência conﬁável de dados
Transferência confiável
de dados no TCP
!  TCP cria serviço rdt !  retransmissões são
em cima do serviço não disparadas por:
confiável do IP "  eventos de timeout
!  segmentos em paralelo "  ACKs duplicados
!  ACKs cumulativos !  inicialmente, considera

!  TCP usa único
remetente TCP
temporizador de simplificado:
ignora ACKs duplicados
retransmissão " 
"  ignora controle de
fluxo, controle de
congestionamento


TCP: transferência conﬁável de dados
eventos no remetente remetente TCP:
Eventos de
dados recebidos da apl.: timeout:
!  cria segmento com # !  retransmite segmento
seq que causou timeout
!  # seq # é número da !  reinicia temporizador
cadeia de bytes do ACK recebido:
primeiro byte de dados !  Reconhecem-se
no segmento segmentos sem ACK
anteriores
!  inicia temporizador, se
"  atualiza o que
ainda não tiver iniciado sabidamente tem ACK
(pense nele como para "  inicia temporizador se
o segmento mais antigo houver segmentos
pendentes
sem ACK)
!  intervalo de expiração:
TimeOutInterval


RemetenteTCP (simplificado)
RemetenteTCP (simplificado) de dados
TCP: transferência conﬁável
NextSeqNum = InitialSeqNum
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event) {
loop (forever)
switch(event)
event: data received from application above Comentário:
event: data received from application above
create TCP segment with sequence number NextSeqNum Comentário:
if (timer currently not running) sequence number NextSeqNum
create TCP segment with •  SendBase-1: último byte
•  SendBase-1: último byte
if (timer currently not running) cumulativo com ACK
start timer
start timer cumulativo com ACK
pass segment to IP Exemplo:
pass segment to IP Exemplo:
NextSeqNum = NextSeqNum + length(dados)
NextSeqNum = NextSeqNum + length(dados) •  SendBase-1 = = 71;
•  SendBase-1 71;
y = = 73, de modo que
y 73, de modo que
event: timer timeout
event: timer timeout
retransmit not-yet-acknowledged segment with destinatário deseja 73+ ; ;
destinatário deseja 73+
retransmit not-yet-acknowledged segment with
smallest sequence number
smallest sequence number
y > SendBase, de modo que
y > SendBase, de modo que
start start timer
timer novos dados têm ACK
novos dados têm ACK
event: ACKACK received, with ACK field valueyof y
event: received, with ACK field value of
if (y > SendBase) { {
if (y > SendBase)
SendBase = y = y
SendBase
if (there are currently not-yet-acknowledged segments)
startstart timer
timer
} }

} /* end of loop loop forever */
} /* end of forever */


TCP: cenários de de retransmissão
TCP: cenários
retransmissão
Hosp. A Hosp. B Hosp. A Hosp. B

Seq = Seq =
92, 8 92, 8
bytes bytes
dados Seq = dados

Seq = 92 timeout
100,
20 by
tes d
a
timeout

0 dos
= 10
ACK
X
loss
Seq = Seq =
92, 8 92, 8
bytes Sendbase bytes
dados
dados
= 100

Seq = 92 timeout
SendBase
= 120
=
ACK
100
SendBase
= 100 SendBase
= 120 Timeout prematuro
tempo tempo
Cenário de ACK perdido


TCP: cenários de retransmissão

Host A Host B

Seq =
92, 8
bytes
dados

10 0
timeout

Seq =
100, 2 AC K=
0 byte
s dado
s
X
perda

SendBase A CK =
= 120 120

tempo
Cenário ACK cumulativo


TCP: geração de ACK

TCP: geração de ACK
[RFC 1122, RFC 2581]


Erro no slide original.
TCP: retransmissão rápida
Retransmissão rápida Correto: 4 ACKs idênticos
(1 original, 3 duplicatas).
Vide RFC 2581…
Erro no slide original.
Retransmissão rápida
!  período de timeout
Correto: 4 ACKs idênticos
!  se remetente recebe 3 ACKs
(1 original, 3 duplicatas).
relativamente grande: para os Vide RFC 2581… ele
mesmos dados,
longo atraso antes de
"  supõe que segmento após
!  período de timeout perdido
reenviar pacote !  se dados com ACK foi perdido:
remetente recebe 3 ACKs
relativamente grande:
!  detecta segmentos para os mesmos dados, ele
"  retransmissão rápida:
" perdidos porantes de ACKs
longo atraso meio de supõe reenvia segmento antes que
que segmento após
duplicados
reenviar pacote perdido dadosocom ACK foi perdido:
temporizador expire
!  detecta segmentos
"  remetente geralmente "  retransmissão rápida:
perdidos por meiosegmentos um
envia muitos de ACKs reenvia segmento antes que
duplicados o outro
após o temporizador expire
"  se segmento for perdido,
"  remetente geralmente
provavelmente haverá
envia muitos segmentos um
muitos ACKs duplicados
após o outro
para esse segmento
"  se segmento for perdido,
provavelmente haverá
muitos11ACKs duplicados
quarta-feira, 28 de setembro de 70

TCP: retransmissão rápida
Hosp. A Hosp. B

seq # x1
seq # x2
seq # x3
ACK x1
seq # x4 X
seq # x5
ACK x1
ACK x1
ACK x1
ACKs
duplicados
três vezes reenv
ia seq
X2
timeout

tempo


Algoritmo de retransmissão rápida
TCP: Algoritmo retransmissão
rápida:

event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}

ACK duplicado para retransmissão rápida
segmento já com ACK


TCP: Controle de ﬂuxo
Controle de fluxo TCP
controle de fluxo
!  lado receptor da
conexão TCP tem um remetente não estourará
buffer do destinatário
buffer de recepção: transmitindo muitos
dados muito rapidamente
espaço
datagramas de buffer dados TCP processo da !  serviço de
IP (atualmente) (no buffer) aplicação
não usado
compatibilização de
velocidades:
compatibiliza a taxa de
envio do remetente
!  processo da aplicação
com a de leitura da
pode ser lento na
aplicação receptora
leitura do buffer


TCP: Controle de ﬂuxo - funcionamento
Controle de fluxo TCP:
como funciona
espaço !  destinatário: anuncia
datagramas de buffer dados TCP processo da
IP (atualmente) (no buffer) aplicação espaço de buffer não
não usado
usado incluindo valor de
rwnd rwnd no cabeçalho do
RcvBuffer
segmento
(suponha que destinatário TCP !  remetente: limita # de
descarte segmentos fora de bytes com ACKa rwnd
ordem) "  garante que buffer do
!  espaço de buffer não usado: destinatário não estoura
= rwnd
= RcvBuffer-[LastByteRcvd -
LastByteRead]


Gerenciamento da
TCP: Gerenciamento da conexão
conexão TCP
lembre-se: Remetente e
destinatário TCP
estabelecem “conexão” antes apresentação de 3 vias:
que troquem segmentos
etapa 1: hosp. cliente envia segmento
dados
SYN do TCP ao servidor
!  inicializa variáveis TCP:
"  especifica # seq. inicial
"  #s seq.:
"  sem dados
"  buffers, informação de
etapa 2: hosp. servidor recebe SYN,
controle de fluxo (p. e.
responde com segmento SYNACK
RcvWindow)
!  cliente: inicia a conexão "  servidor aloca buffers
Socket clientSocket = new "  especifica # seq. inicial do

Socket("hostname","port #");
servidor
!  servidor: contactado pelo etapa 3: cliente recebe SYNACK,
responde com segmento ACK, que
cliente
Socket connectionSocket =
pode conter dados
welcomeSocket.accept();



fechando uma conexão: cliente servidor

fecha
cliente fecha socket: FIN

clientSocket.close();

etapa 1: sistema final do ACK
fecha
cliente envia segmento de FIN
controle TCP FIN ao
servidor
temporizada
espera ACK

etapa 2: servidor recebe
FIN, responde com ACK.
Fecha conexão, envia FIN.
fechado



etapa 3: cliente recebe cliente servidor
FIN, responde com ACK fechado
FIN
"  entra em “espera
temporizada” –
responderá com ACK ACK
fechando
aos FINs recebidos
FIN

etapa 4: servidor recebe
temporizada
ACK - conexão fechada ACK
espera

fechado
Nota: Com pequena
modificação, pode tratar
de FINs simultâneos. fechado


ciclo de vida d
servidor TCP

ciclo de vida do
servidor TCP

ciclo de vida do
cliente TCP

o de vida do
nte TCP

Sumário
3.6 Princípios de controle de
congestionamento


Princípios de controle de de
Princípios de controle congestionamento
congestionamento
Congestionamento:
!  informalmente: “muitas fontes enviando muitos
dados muito rápido para a rede tratar”
!  diferente de controle de fluxo!
!  manifestações:
"  pacotes perdidos (estouro de buffer nos
roteadores)
"  longos atrasos (enfileiramento nos buffers do
roteador)
!  um dos maiores problemas da rede!


Causas / custos do congestionamento: cenário 1
Causas/custos do
congestionamento: cenário 1
!  dois remetentes,
dois destinatários
!  um roteador,
infinitos buffers
!  sem retransmissão

!  grandes atrasos
quando
congestionado
!  vazão máxima
alcançável


Causas/custos do

!  um roteador, buffers finitos
!  retransmissão do pacote perdido pelo remetente



!  sempre: " = % %"out (vazão)
in
!  retransmissão “perfeita” apenas quando há perda: %" > %"out
in
!  retransmissão do pacote adiado (não pedido) torna %" maior
in
(que o caso perfeito ) para o mesmo %"
out
R/2 R/2 R/2

R/3
%out

%out

%out
R/4

R/2 R/2 R/2
%in %in %in

a. b. c.
“custos” do congestionamento:
!  mais trabalho (retransmissão) para determinada “vazão”
!  retransmissões desnecessárias: enlace transporta várias cópias
do pacote

Causas/custos do
!  quatro remetentes P: O que acontece quando%"
!  caminhos com vários saltos in
e in
%" aumentam ?
!  timeout/retransmissão



H %
o
o
st
u
A t

H
o
st
B

outro “custo” do congestionamento:
!  quando pacote é descartado, qualquer capacidade
de transmissão “upstream” usada para esse pacote
foi desperdiçada!


Técnicaspara controle dede
Técnicas para controle congestionamento
congestionamento
duas técnicas amplas para controle de congestionamento:

controle de controle de
congestionamento fim a congestionamento
fim: assistido pela rede:
!  roteadores oferecem
!  nenhum feedback explícito da
feedback aos sistemas
rede finais
!  congestionamento deduzido da "  único bit indicando
perda e atraso observados do congestionamento
sistema final (SNA, DECbit, TCP/IP
!  técnica tomada pelo TCP ECN, ATM)
"  taxa explícita que o
remetente deve enviar
no enlace de saída


Exemplo:de caso: de congestionamento ATM ABR
Estudo controle controle de
congestionamento ATM ABR
ABR: taxa de bit células RM (gerenciamento de
disponível: recursos) :
!  “serviço elástico” !  enviadas pelo remetente,
intercaladas com células de dados
!  se caminho do remetente
“sobrecarregado”: !  bits na célula RM definida por
comutadores (“assistido pela rede”)
"  remetente deve usar
largura de banda "  bit NI: sem aumento na taxa

disponível (congestionamento leve)
!  se caminho do remetente "  bit CI: indicação de

congestionado: congestionamento
"  remetente sufocado à !  células RM retornadas ao remetente
taxa mínima garantida pelo destinatário, com bits intactos


Exemplo: controle de congestionamento ATM ABR

!  campo ER (explicit rate) de 2 bytes na célula RM
"  comutador congestionado pode reduzir valor de ER na célula
"  taxa de envio do remetente é taxa máxima admissível no caminho

!  bit EFCI nas células de dados: defina como 1 no
comutador congestionado
"  se a célula de dados anterior à célula RM tiver EFCI definido,
remetente define bit CI na célula RM retornada


Sumário
3.7 Controle de congestionamento: TCP


Controle de controle de congestionamento
TCP: congestionamento
TCP: buscabuscalargura
por por largura de banda
de banda
!  “procura por largura de banda”: aumenta taxa de
transmissão no recebimento do ACK até por fim ocorrer
perda; depois diminui taxa de transmissão
"  continua a aumentar no ACK, diminui na perda (pois largura de
banda disponível está mudando, dependendo de outras conexões
na rede) ACKs sendo recebidos,
X perda e diminuição de taxa
de modo que aumenta taxa
X
taxa de emissão

X
X
comportamento
X “dente de serra”
do TCP

tempo

!  P: Com que velocidade aumentar/diminuir?
"  detalhes a seguir


Controle de congestionamento
TCP: detalhes
TCP: detalhes
!  remetente limita taxa limitando número de
bytes sem ACK “na pipeline”:
LastByteSent-LastByteAcked & cwnd
"  cwnd: difere de rwnd (como, por quê?)
"  remetente limitado por min(cwnd,rwnd)
bytes
!  aproximadamente, cwnd!

cwnd
taxa = bytes/seg
RTT
RTT
!  cwnd é dinâmico, função do
congestionamento de rede percebido ACK(s)


Controle de congestionamento
TCP: mais detalhes
TCP: mais detalhes
evento de perda de segmento: ACK recebido: aumenta
reduzindo cwnd! cwnd!
!  timeout: sem resposta do !  fase de partida lenta:
destinatário "  aumento exponencialmente
"  corta cwnd para 1 rápido (apesar do nome) no
início da conexão, ou após
!  3 ACKs duplicados: pelo
o timeout
menos alguns segmentos
!  prevenção de
passando (lembre-se da
retransmissão rápida) congestionamento:
"  aumento linear
"  corta cwnd pela metade,
menos agressivamente do que
no timeout


TCP: partida lenta
Partida lenta do TCP
!  quando conexão começa, cwnd = 1
MSS Hosp. A Hosp. B
"  exemplo: MSS = 500 bytes &
um segme
RTT = 200 ms nto

RTT
"  taxa inicial = 20 kbps
!  largura de banda disponível pode dois segm
entos
ser >> MSS/RTT
"  desejável subir rapidamente
para taxa respeitável quatro seg
mentos
!  aumenta taxa exponencialmente até
o primeiro evento de perda ou
quando o patamar é alcançado
"  cwnd duplo a cada RTT
tempo
"  feito incrementando cwnd por 1
para cada ACK recebido


Redes de Computadores: Camada de Transporte UFPB

Redes de Computadores: Camada de Transporte UFPB

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Redes de Computadores: Camada de Transporte UFPB

Similar to Redes de Computadores: Camada de Transporte UFPB (20)

Recently uploaded

Recently uploaded (20)

Redes de Computadores: Camada de Transporte UFPB