View
228
Download
0
Category
Preview:
Citation preview
3: Camada de Transporte 3a-1
Capítulo 3: Camada de TransporteMetas do capítulo: compreender os princípios
que guiam os serviços da camada de transporte: multiplexação/
demultiplexação transferência confiável de
dados controle de fluxo controle de
congestionamento instanciação e
implementação na Internet dos protocolos de transporte
UDP TCP
Resumo do Capítulo: serviços da camada de transporte multiplexação/demultiplexação transporte sem conexão: UDP princípios da transferência confiável de
dados transporte orientado a conexão: TCP
transferência confiável controle de fluxo gerenciamento de conexões
princípios do controle de congestionamento
controle de congestionamento usados no TCP
3: Camada de Transporte 3a-2
Serviços e protocolos de transporte provê comunicação lógica entre
processos de aplicação executando em hosts diferentes
protocolos de transporte executam em sistemas terminais emissor: fragmenta a
mensagem da aplicação em segmentos e os envia para a camada de rede;
receptor: rearranja os segmentos em mensagens e os transmite para a camada de aplicação;
Mais de um protocolo de transporte disponível para as aplicações
Internet: TCP e UDP
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
transporte lógico fim a fim
3: Camada de Transporte 3a-3
Camada de Rede e Camada de Transporte
camada de rede : comunicação lógica entre hosts ou sistemas;
camada de transporte: comunicação lógica entre processos os serviços da camada de transporte e suas
dimensões: Segurança, Integridade, Vazão, e tempo;
depende dos serviços da camada de rede; extende os serviços da camada de rede
3: Camada de Transporte 3a-4
Multiplexação/demultiplexação
aplicação
transporte
rede
enlace
física
P1 aplicação
transporte
rede
enlace
física
aplicação
transporte
rede
enlace
física
P2P3 P4P1
host 1 host 2 host 3
= processo= socket
entrega de segmentos recebidos para os devidos processos da camada de aplicação.
Demultiplexação no receptor:juntar dados de múltiplosprocessos de apl, envelopandodados com cabeçalho (usado depois para demultiplexação)
Multiplexação no transmissor:
3: Camada de Transporte 3a-5
Os elementos da demultiplexação host recebe os datagramas IP
Cada datagrama tem um endereço IP de origem e de destino;
Cada datagrama carrega 1 segmento da camada de transporte;
Cada segmento tem um número de porta de origem e um de destino
lembrete: número de porta bem conhecido para aplicações específicas
host usa o endereço IP e o número de porta para direcionar o segmento para o socket apropriado;
porta remetente porta receptor
32 bits
dados daaplicação
(mensagem)
outros campos do cabeçalho
formato de segmento TCP/UDP
3: Camada de Transporte 3a-6
Demultiplexação não orientada a conexão Cria sockets com os
números de portaDatagramSocket mySocket1 = new
DatagramSocket();DatagramSocket mySocket2 = new
DatagramSocket(9157);
Socket UDP identificado pela 2-tupla:
(endereço IP destino, no porta destino)
Quando o host recebe o segmento UDP:
Verifica o número da porta de destino no segmento
Direciona o segmento UDP para o socket correspondente ao número da porta;
Datagramas IP com diferentes endereços IP de origem e/ou números de porta de origem são direcionados para o mesmo socket desde que...
3: Camada de Transporte 3a-7
Demultiplexação não orientada a conexão (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
serverIP: C
ClientIP:B
P2
client IP: A
P1P1P3
SP: 6428DP: 9157
SP: 9157DP: 6428
SP: 6428DP: 5775
SP: 5775DP: 6428
SP provê “endereço de retorno”
3: Camada de Transporte 3a-8
Demultiplexação orientada a conexão
Identificação do socket, 4-tupla:
endereço IP de origem número da porta de origem endereço IP de destino número da porta de destino
Hosts receptor usa estes valores da tupla para direcionar os segmentos para o socket apropriado
host servidor deve suportar múltiplos sockets TCP simultaneamente:
Cada socket é identificado por sua 4-tupla
servidores Web tem diferentes sockets para cada cliente
HTTP não persistente tem diferentes sockets para cada requisição
3: Camada de Transporte 3a-9
Demultiplexação orientada a conexão (cont)
clienteIP:B
P3
cliente IP: A
P1P1P3
servidorIP: C
SP: 80DP: 9157
SP: 9157DP: 80
SP: 80DP: 5775
SP: 5775DP: 80
P4
3: Camada de Transporte 3a-10
Atividade: Protocolo para a camada de transporte Tarefa: Projetar um protocolo para a
camada de transporte que ofereça um serviço de transferência Não-confiável, sem-controle de fluxo, nem-controle de congestionamento.
Espera-se: Dinâmica de troca de mensagens pelas entidades
que usam o protocolo; Formato das mensagens enviadas(msg requisição;
msg resposta).
3: Camada de Transporte 3a-11
UDP: User Datagram Protocol [RFC 768]
Protocolo de transporte da Internet mínimo
Serviço “melhor esforço”, segmentos UDP podem ser: perdidos entregues à aplicação fora
de ordem do envio sem conexão:
não há “setup” UDP entre remetente, destinatário
tratamento independente para cada segmento UDP
Por quê existe o UDP? elimina estabelecimento de
conexão (o que pode causar retardo)
simples: não se mantém “estado” da conexão no remetente/receptor
pequeno cabeçalho de segmento sem controle de
congestionamento: UDP pode transmitir o mais rápido possível
3: Camada de Transporte 3a-12
Mais sobre UDP muito utilizado para apls. de meios
contínuos (voz, vídeo) tolerantes de perdas sensíveis à taxa de transmissão
outros usos de UDP (por quê?):
DNS (nomes) SNMP (gerenciamento)
transferência confiável com UDP: incluir confiabilidade na camada de aplicação
recuperação de erro específica à apl.!
porta origem porta dest.
32 bits
Dados de aplicação
(mensagem)
UDP segment format
comprimento checksum
Comprimento embytes do
segmento UDP,incluindo cabeçalho
3: Camada de Transporte 3a-13
Checksum UDP
Remetente: trata conteúdo do segmento
como seqüência de inteiros de 16-bits
campo checksum zerado checksum: soma (adição
usando complemento de 1) do conteúdo do segmento
remetente coloca complemento do valor da soma no campo checksum de UDP
Receptor: calcula checksum do
segmento recebido verifica se checksum
computado possui algum zero: SIM - erro detectado NÃO - nenhum erro
detectado.
Meta: detecta “erro” (e.g., bits invertidos) no segmento transmitido
3: Camada de Transporte 3a-14
Checksum UDP: Cálculo
011001100110000001010101010101011000111100001100
Palavra 1
Palavra 2
Palavra 3
3: Camada de Transporte 3a-15
Checksum UDP: Cálculo palavra1 + palavra2
011001100110000001010101010101011011101110110101
Palavra 1
Palavra 2
3: Camada de Transporte 3a-16
Checksum UDP: Cálculo resultado anterior + palavra3
101110111011010110001111000011000100101011000010
Resultado anterior
Palavra 3
CheckSumComplemento de 1
1011010100111101
3: Camada de Transporte 3a-17
Checksum, pra quê?
Já que existe serviço similar na camada de Enlace, então pra quê um serviço redundante?
3: Camada de Transporte 3a-18
Princípios de Transferência confiável de dados (rdt)
importante pois outras camadas implementam o conceito;
características do canal não confiável determinam a complexidade de um protocolo de transferência confiável de dados (rdt)
3: Camada de Transporte 3a-19
Transferência confiável de dados (rdt): Interfaces do protocolo
sendside
receiveside
rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor
udt_send(): chamada por rdt, p/ transferir pacote pelocanal ñ confiável ao receptor
rdt_rcv(): chamada quando pacote chega no lado receptor do
canal
deliver_data(): chamada por rdt p/ entregar dados
p/ camada superior
3: Camada de Transporte 3a-20
Transferência confiável de dados (rdt): A abordagem
Desenvolver incrementalmente os lados remetente, receptor do protocolo RDT;
Considerar apenas fluxo unidirecional de dados mas info de controle flui em ambos os sentidos!
Usar máquinas de estados finitos (FSM) p/ especificar remetente, e receptor.
3: Camada de Transporte 3a-21
Transferência confiável de dados (rdt): Uma máquina de estado
➔ Estado: caracteriza uma certa configuração da máquina;➔ Evento: eventualmente causam mudanças no estado da máquina;➔Ações: executadas quando da transição de um estado para outro;➔ Transição é determinada unicamente pelo próximo evento
estado1
estado2
evento causando transição de estadosações tomadas na transição de estado
eventoações
3: Camada de Transporte 3a-22
Rdt1.0: transferência confiável usando um canal confiável
canal subjacente é confiável não tem erros de bits; não tem perda de pacotes.
FSMs separadas para remetente e receptor: remetente envia dados pelo canal subjacente receptor recebe dados do canal subjacente
3: Camada de Transporte 3a-23
Rdt2.0: canal com erros de bits canal subjacente pode inverter bits no pacote
lembre-se: checksum UDP pode detectar erros de bits
a questão: como recuperar dos erros? reconhecimentos (ACKs): receptor avisa explicitamente ao
remetente que pacote chegou bem reconhecimentos negativos (NAKs): receptor avisa
explicitamente ao remetente que pacote tinha erros remetente retransmite pacote ao receber um NAK ARQ(Automatic Repeat reQuest).
novos mecanismos em rdt2.0 (em relação ao rdt1.0): deteção de erros realimentação pelo receptor: msgs de controle (ACK,NAK)
receptor->remetente Retransmissão
3: Camada de Transporte 3a-27
rdt2.0 tem uma falha fatal!O que acontece se ACK/NAK com erro?
remetente usa ACKs/NAKs p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente?
Melhorar o procedimento de Checksum permitindo a correção do erro, mas o pacote pode se perde;
retransmitir, mas pode causar retransmissão de pacote recebido certamente!
O que fazer?
Remetente não sabe o que passou no receptor! não se pode apenas retransmitir: possibilidade de pacotes
duplicados
3: Camada de Transporte 3a-28
rdt2.1, lidando com a duplicação!
remetente inclui número de sequência para cada pacote; remetente retransmite pacote atual se ACK/NAK foi
recebido com erro; receptor descarta (não entrega) pacote duplicado. receptor transmite ACK para pacotes duplicados;
3: Camada de Transporte 3a-31
rdt2.1: discussão
Remetente: no. de seq no pacote bastam dois nros. de seq.
(0,1). Por quê? deve checar se ACK/NAK
recebido tinha erro duplicou o no. de estados
estado deve “lembrar” se pacote “corrente” tem no. de seq. 0 ou 1.
Receptor: deve checar se pacote
recebido é duplicado estado indica se no. de
seq. esperado é 0 ou 1
note: receptor não tem como saber se último ACK/NAK foi recebido bem pelo remetente
3: Camada de Transporte 3a-32
rdt2.2: um protocolo sem NAKs
mesma funcionalidade que rdt2.1, só com ACKs ao invés de NAK, receptor envia ACK p/ último
pacote recebido corretamente receptor deve incluir explicitamente no. de seq do pacote
reconhecido
ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual
3: Camada de Transporte 3a-35
rdt3.0: canais com erros e perdas
Nova suposição: canal subjacente também pode perder pacotes (dados ou ACKs)
checksum, no. de seq., ACKs, retransmissões podem ajudar, mas não serão suficientes
remetente espera até ter certeza que se perdeu pacote ou ACK, e então retransmite
P: como lidar com perdas?
3: Camada de Transporte 3a-36
rdt3.0: canais com erros e perdas
Abordagem: remetente aguarda um tempo “razoável” pelo ACK
retransmite se nenhum ACK for recebido neste intervalo se pacote (ou ACK) apenas estiver atrasado (e não perdido):
retransmissão será duplicada, mas o uso de no. de seq. já cuida disto
receptor deve especificar no. de seq do pacote sendo reconhecido
requer temporizador
3: Camada de Transporte 3a-41
Resposta
A diferença entre o remetente dos protocolos rdt3.0 e rdt2.2 é a adição do temporizador. A introdução da “data de validade” (timeouts) do temporizador introduz a possibilidade da ocorrência de pacotes duplicados no fluxo estabelecido entre remetente-e-receptor. Entretanto, o receptor do protocolo rdt2.2 é capaz de lidar com pacotes duplicados. (Duplicações no lado do receptor do rdt 2.2 podem ocorrer caso o receptor envie um ACK e este sofra perda, induzindo o remetente então a retransmitir dados antigos). Assim, o receptor do protocolo rdt2.2 servirá aos propósitos do protocolo rdt 3.0.
3: Camada de Transporte 3a-42
Desempenho de rdt3.0 rdt3.0 funciona, porém seu desempenho é muito ruim exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de
1KB:
Utilização: porcentagem/fração de tempo remetente está ocupado
pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps
protocolo limita uso dos recursos físicos!
Ttransmitir=8kb
10**9 b/sec = 8 microsecL (tamanho do pacote - bits)R (taxa de transmissão, bps)=
U emissor =
.008
30.008 = 0.00027L / R
RTT + L / R =
3: Camada de Transporte 3a-43
rdt3.0: operação para-e-espera
bit primeiro pacote transmitido, t = 0
emissor receptor
RTT
último bit transmitido, t = L / R
bit do primeiro pacote recebidoúltimo bit do pacote recebido, envia ACK
ACK recebido, envia próximo pacote, t = RTT +
L / R
U emissor =
.008
30.008 = 0.00027 microsegundos L / R
RTT + L / R =
3: Camada de Transporte 3a-44
Protocolos “dutados” (pipelined)Dutagem (pipelining): remetente admite múltiplos
pacotes “em trânsito”, ainda não reconhecidos faixa de números de seqüência deve ser aumentada buffers no remetente e/ou no receptor
Duas formas genéricas de protocolos de dutagem: Volta-N e Retransmissão seletiva.
3: Camada de Transporte 3a-45
Pipelining: aumenta utilizaçãobit primeiro pacote transmitido, t = 0
emissor receptor
RTT
último bit transmitido, t = L / R
primeiro bit do pacote recebido
último bit recebido, envia ACK
ACK recebido, envia próximo pacote, t = RTT + L / R
último bit do 2o pacote recebido, envia ACKúltimo bit do 3o pacote recebido, envia ACK
Aumenta a utilização de um fator de 3
U emissor =
.024
30.008 = 0.0008 microsegundos 3*L / R
RTT + L / R =
3: Camada de Transporte 3a-46
Protocolos para dutagem
Volta-N: visão geral Remetente pode ter até N
pacotes Não-acks no pipeline Receptor envia somente acks
acumulativos Não reconhece pacotes se
existir espaço.
Remetente tem timer para o pacote mais antigo enviado
Se o timer expirar, retransmite todos os pacotes não acks.
Retransmissão Seletiva: Visão geral Remetente pode ter até N
pacotes Não-acks no pipeline;
Receptor reconhece pacotes individualmente;
Transmissor mantém timer para cada pacote não-Ack
Quando o timer expirar retransmite somente pacotes Não-acks.
3: Camada de Transporte 3a-47
Volta N
Remetente pode ter até N pacotes Não-acks no pipeline
Receptor envia somente acks acumulativos Não reconhece pacotes se existir espaço.
Remetente tem timer para o pacote mais antigo enviado
Se o timer expirar, retransmite todos os pacotes não acks.
3: Camada de Transporte 3a-48
Volta-NRemetente: no. de seq. de k-bits no cabeçalho do pacote admite “janela” de até N pacotes consecutivos não reconhecidos
ACK(n): reconhece todos pacotes, até e inclusive no. de seq n - “ACK cumulativo” pode receber ACKs duplicados (veja receptor)
temporizador para cada pacote em trânsito timeout(n): retransmite pacote n e todos os pacotes com no. de seq maiores na janela
3: Camada de Transporte 3a-49
Volta-N: FSM estendida do remetente
Wait start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])
timeout
rdt_send(data)
if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ }else refuse_data(data)
base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timer
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
base=1nextseqnum=1
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Λ
3: Camada de Transporte 3a-50
Volta-N: FSM estendida do receptor
receptor simples: usa apenas ACK: sempre envia ACK para pacote recebido bem com o
maior no. de seq. em-ordem pode gerar ACKs duplicados só precisa se lembrar do expectedseqnum
pacote fora de ordem: descarta (não armazena) -> receptor não usa buffers! manda ACK de pacote com maior no. de seq em-ordem
Wait
udt_send(sndpkt)
default
rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)
extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++
expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)
Λ
3: Camada de Transporte 3a-52
Retransmissão seletiva
receptor reconhece individualmente todos os pacotes recebidos corretamente armazena pacotes no buffer, conforme precisa, para
posterior entrega em-ordem à camada superior
remetente apenas re-envia pacotes para os quais ACK não recebido
temporizador de remetente para cada pacote sem ACK
janela do remetente N nos. de seq consecutivos outra vez limita nos. de seq de pacotes enviados, mas
ainda não reconhecidos
3: Camada de Transporte 3a-54
Retransmissão seletiva
dados de cima: se próx. no. de seq na janela,
envia pacotetimeout(n): reenvia pacote n, reiniciar
temporizadorACK(n) em
[sendbase,sendbase+N]: marca pacote n “recebido” se n for menor pacote não
reconhecido, avança base da janela ao próx. no. de seq não reconhecido.
pacote n em [rcvbase, rcvbase+N-1]
envia ACK(n) fora de ordem: buffer em ordem: entrega (tb. entrega
pacotes em ordem no buffer), avança janela p/ próxima pacote ainda não recebido
pacote n em [rcvbase-N,rcvbase-1]
ACK(n)senão: ignora
receptorremetente
3: Camada de Transporte 3a-56
Retransmissão seletiva: dilemaExemplo: nos. de seq : 0, 1, 2, 3 tam. de janela =3
receptor não vê diferença entre os dois cenários!
incorretamente passa dados duplicados como novos em (a)
Q: qual a relação entre tamanho de no. de seq e tamanho de janela?
3: Camada de Transporte 3a-57
TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581
transmissão full duplex: fluxo de dados bi-
direcional na mesma conexão
MSS: tamanho máximo de segmento
orientado a conexão: handshaking (troca de
msgs de controle) inicia estado de remetente, receptor antes de trocar dados
fluxo controlado: receptor não será afogado
ponto a ponto: 1 remetente, 1 receptor
fluxo de bytes, ordenados, confiável:
não estruturado em msgs dutado:
tam. da janela ajustado por controle de fluxo e congestionamento do TCP
buffers de envio e recepçãos o c k e t
d o o rT C P
s e n d b u f f e rT C P
r e c e i v e b u f f e r
s o c k e td o o r
s e g m e n t
a p p l i c a t i o nw r i t e s d a t a
a p p l i c a t i o nr e a d s d a t a
3: Camada de Transporte 3a-58
TCP: estrutura do segmento
no. porta origem no. porta dest
32 bits
dados daaplicação
(tam. variável)
número de seqüêncianúmero de reconhecimento
janela receptorptr dados urg.checksum
FSRPAUtam.cab.
semuso
Opções (tam. variável)
URG: dados urgentes (pouco usados)
ACK: no. ACKválido
PSH: envia dados já(pouco usado)
RST, SYN, FIN:gestão de conexão
(comandos deestabelecimento,
liberação)
no. bytes rcpt queraceitar
contagem de dadospor bytes (não segmentos!)
checksum Internet
(como UDP)
3: Camada de Transporte 3a-59
TCP: nos. de seq. e ACKsNos. de seq.:
“número”dentro do fluxo de bytes do primeiro byte de dados do segmento
ACKs: no de seq do próx.
byte esperado do outro lado
ACK cumulativoP: como receptor trata
segmentos fora da ordem?
R: espec do TCP omissa - deixado ao implementador
Estação A Estação B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usuáriotecla
‘C’
A reconhecechegada
do ‘C’ecoado
B reconhecechegada de
‘C’, ecoa‘C’ de volta
tempocenário simples de telnet
3: Camada de Transporte 3a-60
TCP: Tempo de Resposta (RTT) e TemporizaçãoP: como escolher valor
do temporizador TCP?
maior que o RTT note: RTT pode
variar muito curto:
temporização prematura retransmissões são
desnecessárias muito longo: reação
demorada à perda de segmentos
P: como estimar RTT? RTTamostra: tempo medido
entre a transmissão do segmento e o recebimento do ACK correspondente
ignora retransmissões, segmentos com ACKs cumulativos
RTTamostra vai variar, queremos “amaciador” de RTT estimado
usa várias medições recentes, não apenas o valor corrente (RTTamostra)
3: Camada de Transporte 3a-61
TCP: Tempo de Resposta (RTT)
RTT_estimado = (1-α)* RTT_estimado + α*RTT_amostra
média corrente exponencialmente ponderada influência de cada amostra diminui exponencialmente com o
tempo valor típico de α : 0.125
3: Camada de Transporte 3a-62
TCP: Temporização
Escolhendo o intervalo de temporização RTT_estimado mais uma “margem de segurança” variação grande em RTT_estimado
-> margem de segurança maior
Temporização = RTT_estimado + 4*Desvio
Desvio = (1- β)* Desvio + β *|RTT_amostra - RTT_estimado|
valor típico de β : 0.25
3: Camada de Transporte 3a-63
Exemplo estimativa RTTRTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(mill
isec
onds
)
SampleRTT Estimated RTT
3: Camada de Transporte 3a-64
TCP: transferência confiável de dados TCP cria serviço rdt
sobre o serviço não confiável IP
Utiliza pipeline para enviar segmentos
ACKS cumulativos TCP usa temporizador
para retransmissão
Retransmissões são disparadas por: timeout Acks duplicados
Inicialmente considere um TCP emissor simplificado:
ignore acks duplicados ignore controle de fluxo
e controle de congestionamento;
3: Camada de Transporte 3a-65
Eventos doTCP emissor:Dados recebidos da aplic: Cria o segmento com no
de seq X seq X é o número do
primeiro byte do segmento
Inicia o temporizador se ele não foi iniciado anteriormente
Intervalo de expiração: TimeOutInterval
timeout: Retransmite o segmento que
causou o timeout Reinicializa o temporizador Ack recebido: Se reconhece segmentos não
reconhecidos anteriormente Atualiza a informação sobre
pacotes reconhedidos Inicia o temporizador se
existem ainda segmentos não reconhecidos
3: Camada de Transporte 3a-66
TCP: transfe-rência confiável de dados
00 sendbase = número de seqüência inicial01 nextseqnum = número de seqüência inicial0203 loop (forever) { 04 switch(event) 05 event: dados recebidos da aplicação acima06 cria segmento TCP com número de seqüência nextseqnum 07 inicia temporizador para segmento nextseqnum 08 passa segmento para IP 09 nextseqnum = nextseqnum + comprimento(dados) 10 event: expirado temporizador de segmento c/ no. de seqüência y 11 retransmite segmento com número de seqüência y 12 calcula novo intervalo de temporização para segmento y 13 reinicia temporizador para número de seqüência y 14 event: ACK recebido, com valor de campo ACK de y 15 se (y > sendbase) { /* ACK cumulativo de todos dados até y */ 16 cancela temporizadores p/ segmentos c/ nos. de seqüência < y 17 sendbase = y 18 } 19 senão { /* é ACK duplicado para segmento já reconhecido */ 20 incrementa número de ACKs duplicados recebidos para y 21 if (número de ACKs duplicados recebidos para y == 3) { 22 /* TCP: retransmissão rápida */ 23 reenvia segmento com número de seqüência y 24 reinicia temporizador para número de seqüência y 25 } 26 } /* fim de loop forever */
RemetenteTCPsimplificado
3: Camada de Transporte 3a-67
TCP: cenários de retransmissãoEstação A
Seq=92, 8 bytes de dados
ACK=100
perdatem
pori
zaçã
o
tempo cenário doACK perdido
Estação B
X
Seq=92, 8 bytes de dados
ACK=100
Host A
Seq=100, 20 bytes de dados
ACK=100
Tem
p.p/
Seq
=92
temporização prematura,ACKs cumulativos
Host B
Seq=92, 8 bytes de dados
ACK=120
Seq=92, 8 bytes de dados
Tem
p. p
/ Se
q=10
0
ACK=120
tempo
3: Camada de Transporte 3a-68
TCP: cenários de retransmissão (cont)Host A
Seq=92, 8 bytes data
ACK=100
loss
tim
eout
Cenário de ACK cumulativo
Host B
X
Seq=100, 20 bytes data
ACK=120
time
3: Camada de Transporte 3a-69
TCP geração de ACKs [RFCs 1122, 2581]
Evento
chegada de segmento em ordemsem lacunas,anteriores já reconhecidos
chegada de segmento em ordemsem lacunas,um ACK retardado pendente
chegada de segmento fora de ordem, com no. de seq. maiorque esperado -> lacuna
chegada de segmento que preenche a lacuna parcial oucompletamente
Ação do receptor TCP
ACK retardado. Espera até 500msp/ próx. segmento. Se não chegarsegmento, envia ACK
envia imediatamente um únicoACK cumulativo
envia ACK duplicado, indicando no. de seq.do próximo byte esperado
ACK imediato se segmento noinício da lacuna
3: Camada de Transporte 3a-70
Fast Retransmit Período de timeout é
geralmente longo: Longo atraso até a
retransmissão do segmento perdido
Detectar segmentos perdidos via ACKs duplicados
Emissores geralmente enviam vários segmentos
Se um segmento é perdido, provavelmente vão ser recebidos ACKs duplicados
Se o emissor recebe 3 ACKs para o mesmo segmento, supõe que o segemtno subseqüente foi perdido:
fast retransmit: retransmite o segmetno antes que o temporizador expire
3: Camada de Transporte 3a-71
evento: ACK recebido, com valor de ACK igual a y if(y > SendBase) { SendBase = y if (existem segemtnos ainda não reconhecidos) inicializa o temporizador } else { incrementa o contador de ACKs duplicados para y if (contador de ACKs duplicados para y = 3) { retransmite o segmento com no seq y }
Algoritmo Fast retransmit:
Um ACK duplicado para um segmento já reconhecido previamente
fast retransmit
3: Camada de Transporte 3a-72
remetente não esgotaria buffers do receptor por
transmitir muito, ou muito rápidamente
controle de fluxo
TCP: Controle de Fluxo
Lado receptor de uma conexão TCP tem um buffer de recepção:
Processo da aplicação pode ser lento para retirar os dados do buffer
Serviço de compatibilização de velocidades: compatibilizar a taxa de envio do emissor com a taxa de recebimento dos dados da aplicação do receptor
3: Camada de Transporte 3a-73
Controle de Fluxo TCP: como funciona ?
(Suponha que o TCP receptor discarte pacotes fora de ordem)
= RcvWindow= RcvBuffer-[LastByteRcvd -
LastByteRead]
receptor: explicitamente avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente)
campo RcvWindow no segmento TCP
remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de RcvWindow
Garante que não tenha overflow no buffer do receptor
3: Camada de Transporte 3a-74
TCP: Gerenciamento de Conexões
Lembrete: Remetente, receptor TCP estabelecem “conexão” antes de trocar segmentos de dados
inicializam variáveis TCP: nos. de seq. buffers, info s/ controle
de fluxo (p.ex. RcvWindow) cliente: iniciador de conexão Socket clientSocket = new
Socket("hostname","port
number"); servidor: contactado por
cliente Socket connectionSocket =
welcomeSocket.accept();
Inicialização em 3 tempos:Passo 1: sistema cliente envia
segmento de controle SYN do TCP ao servidor
especifica no. inicial de seq sem dados
Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK
aloca buffers especifica no. inicial de seq.
Passo 3: sistema cliente recebe SYNACK, responde com um segmento de ACK, que pode conter dados
3: Camada de Transporte 3a-75
TCP: Gerenciamento de Conexões (cont.)
Encerrando uma conexão:
cliente fecha soquete: clientSocket.close();
Passo 1: sistema cliente envia segmento de controle FIN ao servidor
Passo 2: servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN.
cliente
FIN
servidor
ACK
ACK
FIN
fechar
fechar
fechada
espe
ra
tem
por i
zada
3: Camada de Transporte 3a-76
TCP: Gerenciamento de Conexões (cont.)
Passo 3: cliente recebe FIN, responde com ACK.
Entre em “espera temporizada” - responderá com ACK a FINs recebidos
Step 4: servidor, recebe ACK. Conexão encerrada.
Note: com pequena modificação, consegue tratar de FINs simultâneos.
cliente
FIN
servidor
ACK
ACK
FIN
fechando
fechando
fechada
espe
rate
mpo
r iza
dafechada
3: Camada de Transporte 3a-77
TCP: Gerenciamento de Conexões (cont.)
Ciclo de vidade cliente TCP
Ciclo de vidade servidor TCP
3: Camada de Transporte 3a-78
Princípios de Controle de CongestionamentoCongestionamento: informalmente: “muitas fontes enviando muitos
dados muito rapidamente para a rede poder tratar”
diferente de controle de fluxo! manifestações:
perda de pacotes (esgotamento de buffers em roteadores)
longos atrasos (enfileiramento nos buffers dos roteadores)
um dos 10 problemas mais importantes em redes!
3: Camada de Transporte 3a-79
Causas/custos de congestionamento: cenário 1
dois remetentes, dois receptores
um roteador, buffers infinitos
sem retransmissão
grandes retardos qdo. congestionada
vazão máxima alcançável
3: Camada de Transporte 3a-80
Causas/custos de congestionamento: cenário 2
Um roteador, buffers finitos retransmissão pelo remetente de pacote
perdido
Buffer finito compatilhado
Host A λin : dados originais
Host B
λout
λ'in : dados originais, mais dados retransmitidos
3: Camada de Transporte 3a-81
Causas/custos de congestionamento: cenário 2 sempre: (“goodput”)
retransmissão “perfeito” apenas quando perda:
retransmissão de pacote atrasado (não perdido) faz maior
(que o caso perfeito) para o mesmo
λin
λout=
λin
λout>
λin
λout
“custos” de congestionamento: mais trabalho (retransmissão) para dado “goodput” retransmissões desnecessárias: enviadas múltiplas cópias do pacote
3: Camada de Transporte 3a-82
Causas/custos de congestionamento: cenário 3 quatro remetentes caminhos com múltiplos enlaces temporização/retransmissão
λin
P: o que acontece à medida que e crescem ?
λin
Buffer finito compartilhado
Host Aλin : dados originais
Host B
λout
λ'in : dados originais, mais dados retransmitidos
3: Camada de Transporte 3a-83
Causas/custos de congestionamento: cenário 3
Outro “custo” de congestionamento: quando pacote é descartado, qq. capacidade de
transmissão já usada (antes do descarte) para esse pacote foi desperdiçado!
Host A
Host B
λo
u
t
3: Camada de Transporte 3a-84
Abordagens de controle de congestionamento
Controle de congestionamento fim a fim :
não tem realimentação explícita pela rede
congestionamento inferido das perdas, retardo observados pelo sistema terminal
abordagem usada pelo TCP
Controle de congestionamento com apoio da rede:
roteadores realimentam os sistemas terminais
bit único indicando congestionamento (SNA, DECbit, TCP/IP ECN, ATM)
taxa explícita p/ envio pelo remetente
Duas abordagens amplas para controle de congestionamento:
3: Camada de Transporte 3a-85
Estudo de caso: controle de congestionamento no ABR da ATM
ABR: available bit rate: “serviço elástico” se caminho do remetente
“sub-carregado”: remetente deveria
usar banda disponível se caminho do remetente
congestionado: remetente reduzido à
taxa mínima garantida
células RM (resource management):
enviadas pelo remetente, intercaladas com células de dados
bits na célula RM iniciados por comutadores (“apoio da rede”)
bit NI: não aumente a taxa (congestionamento moderado)
bit CI: indicação de congestionamento
células RM devolvidos ao remetente pelo receptor, sem alteração dos bits
3: Camada de Transporte 3a-86
Estudo de caso: controle de congestionamento em ABR da ATM
Campo ER (explicit rate) de 2 bytes na célula RM comutador congestionado pode diminuir valor ER na célula taxa do remetente assim ajustada p/ menor valor possível entre os
comutadores do caminho bit EFCI em células de dados ligado por comutador congestionado
se EFCI ligado na célula de dados antes da célula RM, receptor liga bit CI na célula RM devolvida
3: Camada de Transporte 3a-87
TCP: Controle de Congestionamento
controle fim a fim (sem apoio da rede)
taxa de transmissão limitada pela tamanho da janela de congestionamento:
LastByteSent-LastByteAcked
≤ CongWin
CongWin é dinâmica, e é função do congestionamento na rede;
Como TCP detecta congestionamento?
Evento de perda = timeout ou 3 acks duplicados
TCP emissor reduz taxa de transmissão (CongWin) depois de um evento de perda
Três mecanismos: AIMD slow start conservative after
timeout events
3: Camada de Transporte 3a-88
TCP: Controle de Congestionamento
w segmentos, cada um c/ MSS bytes, enviados por RTT:
throughput = w * MSS
RTT Bytes/sec
Congwin
3: Camada de Transporte 3a-89
TCP: Controle de Congestionamento
duas “fases” partida lenta evitar
congestionamento
variáveis importantes: Congwin
threshold: define limiar entre fases de partida lenta, controle de congestionamento
“sondagem” para banda utilizável:
idealmente: transmitir o mais rápido possível (Congwin o máximo possível) sem perder pacotes
aumentar Congwin até perder pacotes (congestionamento)
perdas: diminui Congwin, depois volta a à sondagem (aumento) novamente
3: Camada de Transporte 3a-90
TCP AIMD
8 K b y t e s
1 6 K b y t e s
2 4 K b y t e s
t i m e
c o n g e s t i o nw i n d o w
multiplicative decrease (decréscimo multiplicativo: reduz CongWin pela metade depois de um evento de perda
additive increase (crescimento aditivo): aumenta CongWin de 1 MSS a cada RTT na ausência de um evento de perda: probing
Conexão TCP de longa duração
3: Camada de Transporte 3a-91
TCP: Partida lenta (Slow Start)
Quando a conexão começa, CongWin = 1 MSS
Exemplo: MSS = 500 bytes & RTT = 200 msec
Taxa inicial = 20 kbps
A banda disponível deve ser >> MSS/RTT
Quando a conexão começa, aumenta a taxa exponencialmente até o primeiro evento de perda
Resumo: taxa inicial baixa, mais cresce rapidamente (crescimento exponencial)
3: Camada de Transporte 3a-92
TCP: Partida lenta (slow start)
Quando a conexão começa, aumenta a taxa exponencialmente até que ococra uma perda
Dobra CongWin a cada RTT, através do incremento de CongWin, a cada ACK recebido
inicializa: Congwin = 1for (cada segmento c/ ACK) Congwin++until (evento de perda OR CongWin > threshold)
Estação A
um segmento
RTT
Estação B
tempo
dois segmentos
quqtro segmentos
Algoritmo Partida Lenta
3: Camada de Transporte 3a-93
Refinamento Depois de 3 DupACKs:
CongWin é reduzida a metade
Janela cresce linearmente Mas depois de um evento de
timeout: CongWin é reduzida a 1
MSS; Janela cresce
exponencialmente até o valor do threshold, e depois cresce linearmente
o recebimento de 3 ACKs duplicados indica que a rede tem condição de transmitir alguns segmentosOcorrência de timeout antes de 3 ACKs duplicados é “mais alarmante”
Filosofia:
3: Camada de Transporte 3a-94
Refinamento (mais)Q: Quando o
crescimento deve mudar de exponencial para linear ?
A: Quando CongWin atinge 1/2 do seu valor antes do timeout.
Implementação: Threshold variável Quando ocorre uma perda,
faz-se Threshold = CongWin/2
0
2
4
6
8
10
12
14
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Transmission round
con
ge
stio
n w
ind
ow
siz
e
(se
gm
en
ts)
Series1 Series2
threshold
TCP Tahoe
TCP Reno
3: Camada de Transporte 3a-95
TCP: Prevenção do Congestionamento (congestion Avoidance
/* partida lenta acabou */ /* Congwin > threshold */Until (event de perda) { cada w segmentos reconhecidos: Congwin++ }threshold = Congwin/2Congwin = 1faça partida lenta
1
1: TCP Reno pula partida lenta (recuperaçãorápida) depois de três ACKs duplicados
prevenção congestionamento
3: Camada de Transporte 3a-96
Resumo: Controle de Congestionamento Quando CongWin está abaixo do Threshold, o
emissor está na fase de slow-start, e a janela cresce exponencialmente
Quando CongWin está acima do Threshold, o emissor está na fase de congestion-avoidance, e a janela cresce linearmente
Quando são recebidos três ACK duplicados, faz-se Threshold = CongWin/2 e CongWin = Threshold.
Quando ocorre um timeout, faz-se Threshold = CongWin/2 e CongWin = 1 MSS.
3: Camada de Transporte 3a-97
Meta de eqüidade: se N sessões TCP compartilham o mesmo enlace de gargalo, cada uma deve ganhar 1/N da capacidade do enlace
Eqüidade TCP
TCP conexão 1
Roteadorgargalo
capacidade R
TCP conexão 2
3: Camada de Transporte 3a-98
Por quê TCP é justo?Duas sessões concorrentes: Aumento aditivo dá gradiente de 1, enquanto vazão aumenta decrementa multiplicativa diminui vazão proporcionalmente
R
R
compartilhamento igual da banda
Vazão da conexão 1
Vazã
o d a
con
e xão
2
evitar congestionamento: aumento aditivoperda: diminui janela por fator de 2
evitar congestionamento: aumento aditivoperda: diminui janela por fator de 2
3: Camada de Transporte 3a-99
Eqüidade (mais)Eqüidade e UDP Aplic. Multimídia
geralmente não usam TCP Não desejam que a taxa
seja reduzida pelo controle de congestionamento
Geralmente usam UDP: audio/video a taxa
constante, toleram perdas de pacotes
Área de pesquisa: TCP friendly
Eqüidade e conexões TCP paralelas
Nada previne que aplic. abram várias conexões simultânceas entre os 2 hosts;
Wrowsers fazem isto Exemplo: enlace com taxa
igual a R, com 9 conexões; Nova aplic. requer uma
conexão TCP, recebe R/10 da taxa
Nova aplic. requer 11 conexões TCP, recebe R/2 da taxa
3: Camada de Transporte 3a-100
TCP: modelagem de latência
P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido?
Ignorando o congestionamento, a latência é influenciada por:
Estabelecimento de conexão TCP retardo de transferência de dados Slow start
Notação, suposições: Supomos um enlace entre cliente e
servidor de taxa R Supomos: janela de congestionamento
fixo, W segmentos S: MSS (bits) O: tamanho do objeto (bits) sem retransmissões (sem perdas, sem
erros)
Tamanho da janela: Assume-se: janela de transmissão
fixa, igual a w segmentos; Depois janelas dinâmicas,
modelando slow start
3: Camada de Transporte 3a-101
Janela de congestionamento de tamanho fixo (1)
Primeiro caso:WS/R > RTT + S/R: ACK do
primeiro segmento na janela chega antes de enviar todos dados na janela
latência = 2RTT + O/R
3: Camada de Transporte 3a-102
Janela de congestionamento de tamanho fixo (2)Segundo caso: WS/R < RTT + S/R:
aguarda ACK depois de enviar todos os dados na janela
latência = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]
3: Camada de Transporte 3a-103
TCP: modelagem de latência: Slow Start(1) Agora supomos que a janela cresce de acordo com o
algoritmo de Slow Start. Mostramos que a latência de um objeto de tamanho O é:
Onde:- P é o número de vezes TCP para no servidor:
P=min{Q, K−1}- onde Q é o número de vezes que o servidor pararia se o objeto fosse de tamanho infinito.
- e K é o número de janelas que cobrem o objeto.
Latência=2RTTORP[RTTS
R ]−2P−1 SR
3: Camada de Transporte 3a-104
TCP: modelagem de latência: Slow Start(2)
R T T
i n i t i a t e T C Pc o n n e c t i o n
r e q u e s to b j e c t
f i r s t w i n d o w= S / R
s e c o n d w i n d o w= 2 S / R
t h i r d w i n d o w= 4 S / R
f o u r t h w i n d o w= 8 S / R
c o m p l e t et r a n s m i s s i o no b j e c t
d e l i v e r e d
t i m e a tc l i e n t
t i m e a ts e r v e r
Exemplo:• O/S = 15 segmentos• K = 4 janelas• Q = 2• P = min{K-1,Q} = 2
Servidor para P=2 vezes
Componentes da Latência:
• 2 RTT for connection estab and request
• O/R to transmit object
• time server idles due to slow start
Servidor para: P = min{K-1,Q} vezes
3: Camada de Transporte 3a-105
TCP: modelagem de latência: (3)
R
S
R
SRTTPRTT
R
O
R
SRTT
R
SRTT
R
O
TempoBloqueioRTTR
O
P
kP
k
P
pp
)12(][2
]2[2
2latencia
1
1
1
−−+++=
−+++=
++=
−
=
=
∑
∑
tempo de bloqueio após ak-ésima janela 2 1
R
SRTT
R
S k =
−+
+−
até quando o servidor recebe reconhecimento
tempo quando o servidor inicia o envio do segmento=+RTTR
S
tempo para enviar a k-ésima janela2 1 =−
R
Sk
RTT
iniciaconexão TCP
pedeobjeto
primeira janela= S/R
segunda janela= 2S/R
terceira janela= 4S/R
quarta janela= 8S/R
transmissãocompletaobjeto
entregue
tempo nocliente
tempo noservidor
3: Camada de Transporte 3a-106
Modelagem HTTP Assuma que páginas Web consistem de:
1 página HTML base (com tamanho igual a O bits) M imagens (cada uma com O bits)
HTTP não-persistente : M+1 conexões TCP em série Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma dos
períodos de inatividade HTTP persistente :
2 RTT para requisitar e receber o arquivo base HTML 1 RTT para requisitar e receber M imagens Tempo de resposta = (M+1)O/R + 3RTT + soma dos períodos de
inatividade HTTP não-persistente com X conexões paralelas
1 TCP conexão para o arquivo base M/X conjuntos de conexões paralelas para as imagens Tempo de resposta = (M+1)O/R + (M/X + 1)2RTT + soma dos
períodos de inatividade
3: Camada de Transporte 3a-107
02468
101214161820
28Kbps
100Kbps
1Mbps
10Mbps
HTTP: tempo de resposta (em segundos)RTT = 100 msec, O = 5 Kbytes, M=10 e X=5
Para redes com valores de banda baixos, o tempo de conexão e resposta e domindado pelo tempo de transmissãoConexões persistentes não apresentam melhora significativa em relação a conexões paralelas
não-persistente
persistente
paralela não-persistente
3: Camada de Transporte 3a-108
0
10
20
30
40
50
60
70
28Kbps
100Kbps
1Mbps
10Mbps
não-persistente
persistente
paralela não-persistente
HTTP: tempo de resposta (em segundos)RTT =1 seg, O = 5 Kbytes, M=10 e X=5
Para valores grandes de RTT, o tempo de resposta é dominado pelo atraso do estabelecimento da conexão e slow start. Conexões persistentes possibilita uma melhora importante para a redução do atraso: particularmente em redes com grandes valores de atrasoXbanda (delay•bandwidth)
3: Camada de Transporte 3a-109
Capítulo 3: Resumo
Princípios atrás dos serviços da camada de transporte: multiplexação/
demultiplexação transferência confiável de dados controle de fluxo controle de congestionamento
instanciação e implementação na Internet
UDP TCP
Próximo capítulo: saímos da “borda” da
rede (camadas de aplicação e transporte)
entramos no “núcleo”da rede
Recommended