3: Camada de Transporte 3a-1
Capítulo 3: Camada de TransporteMetas do capítulo:Ø compreender os 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 dos protocolosde transporte
ü UDPü TCP
Resumo do Capítulo:Ø serviços da camada de transporteØ multiplexação/demultiplexaçãoØ transporte sem conexão: UDPØ princípios de 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 de controle de congestionamento
Ø controle de congestionamento em 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 paraa camada de rede;
ü receptor: rearranja os segmentos em mesnagense 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çãotransporteredeenlacefísica
redeenlacefísica
aplicaçãotransporteredeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
transporte lógico fima fim
3: Camada de Transporte 3a-3
Camada de Rede versus Camada de TransporteØ camada de rede :comunicação lógica entre hosts ou sistemas;
Ø camada de transporte:comunicação lógica entre processosü depende dos serviços da camada de rede
ü extende os serviços da camada de rede
Analogia de Casas:12 crianças enviando cartas para 12 crianças
Ø processos = criançasØ Mensagens da aplicação= cartas no envelope
Ø hosts = casasØ Protolo de transporte = Ann e Bill
Ø Protocolo da camada de rede = serviço de correio
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 processos da camada de apl corretos
Demultiplexação no receptor:juntar dados de múltiplosprocessos de apl, envelopandodados com cabeçalho (usado depois para demultiplexação)
Multiplexação no emissor:
3: Camada de Transporte 3a-5
Como demultiplexação funcionaØ 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 segemento tem um número de porta de origeme 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 paradirecionar 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 orientadaa conexãoØ Cria sockets com os números de porta
DatagramSocket mySocket1 = new
DatagramSocket(99111);
DatagramSocket mySocket2 = new
DatagramSocket(99222);
Ø Socket UDP identificadopela 2-tupla:
(endereço IP destino, no porta destino)
Ø Quando o host recebe o segmetno UDP:
ü Verifica o número da porta de destino no segmento
ü Direciona o segmento UDP para o socket correspondente ao númeroda porta;
Ø Datagramas IP com diferentes endereços IP de origem e/ou números de porta de origem sãodirecionados para o mesmo socket
3: Camada de Transporte 3a-7
Demultiplexação não orientadaa conexão (cont)
DatagramSocket serverSocket = new DatagramSocket(6428);
ClientIP:B
P3
clientIP: A
P1P1P3
serverIP: C
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últiplossockets TCP simultaneamente:
ü Cada socket é identificadopor sua 4-tupla
Ø servidores Web tem diferentes sockets paracada cliente
ü HTTP não persistente tem diferentes sockets paracada requisição
3: Camada de Transporte 3a-9
Demultiplexação orientada a conexão (cont)
clienteIP:B
P3
clienteIP: A
P1P1P3
servidorIP: C
SP: 80DP: 9157
SP: 9157DP: 80
SP: 80DP: 5775
SP: 5775DP: 80
P4
3: Camada de Transporte 3a-10
UDP: User Datagram Protocol [RFC 768]
Ø Protocolo de transporte da Internet mínimo, “sem frescura”,
Ø Serviço “melhor esforço”, segmentos UDP podem ser:
ü perdidosü entregues à aplicação fora de ordem do remesso
Ø sem conexão:ü não há “setup” UDP entre remetente, receptor
ü tratamento independente para cada segmento UDP
Por quê existe um 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-11
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-12
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 checksumde UDP
Receptor:Ø calcula checksum do segmento recebido
Ø verifica se checksumcomputado é zero:
ü NÃO - erro detectadoü SIM - nenhum erro detectado. Mas ainda pode ter erros? Veja depois ….
Meta: detecta “erro” (e.g., bits invertidos) no segmento transmitido
3: Camada de Transporte 3a-13
Princípios de Transferência confiável de dados (rdt)
Ø importante nas camadas de transporte, enlaceØ na lista dos 10 tópicos mais importantes em redes!
Ø características do canal não confiável determinam a complexidadede um protocolo de transferência confiável de dados (rdt)
3: Camada de Transporte 3a-14
Transferência confiável de dados (rdt): como começar
sendside
receiveside
rdt_rcv(): chamada quandopacote chega chega no lado
receptor do canal
deliver_data(): chamada por rdt p/ entregar dados
p/ camada superior
3: Camada de Transporte 3a-14
Transferência confiável de dados (rdt): como começar
sendside
receiveside
rdt_rcv(): chamada quandopacote chega chega no lado
receptor do canal
deliver_data(): chamada por rdt p/ entregar dados
p/ camada superior
rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor
3: Camada de Transporte 3a-14
Transferência confiável de dados (rdt): como começar
sendside
receiveside
rdt_rcv(): chamada quandopacote chega chega no lado
receptor do canal
deliver_data(): chamada por rdt p/ entregar dados
p/ camada superior
rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor
udt_send(): chamada porrdt, p/ transferir pacote pelocanal ñ confiável ao receptor
3: Camada de Transporte 3a-15
Transferência confiável de dados (rdt): como começarEtapas:Ø 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, receptor
estado: neste “estado” o próximo estado é
determinado unicamente pelopróximo evento
estado1
estado2
evento causando transição de estadosações tomadas na transição de estado
eventoações
3: Camada de Transporte 3a-16
Rdt1.0: transferência confiável usando um canal confiável
Ø canal subjacente perfeitamente confiávelü não tem erros de bitsü não tem perda de pacotes
Ø FSMs separadas para remetente, receptor:ü remetente envia dados pelo canal subjacenteü receptor recebe dados do canal subjacente
3: Camada de Transporte 3a-17
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ü cenários humanos usando ACKs, NAKs?
Ø 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
3: Camada de Transporte 3a-18
rdt2.0: especificação da FSM
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-19
rdt2.0: em ação (sem erros)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-20
rdt2.0: em ação (cenário de erro)
FSM do remetente FSM do receptor
3: Camada de Transporte 3a-21
rdt2.0 tem uma falha fatal!O que acontece se ACK/NAK com erro?
Ø Remetente não sabe o que passou no receptor!
Ø não se pode apenas retransmitir: possibilidade de pacotes duplicados
O que fazer?Ø remetente usa ACKs/NAKsp/ ACK/NAK do receptor? E se perder ACK/NAK do remetente?
Ø retransmitir, mas pode causar retransmissão de pacote recebido certo!
Lidando c/ duplicação: Ø remetente inclui número de seqüência p/ cada pacote
Ø remetente retransmite pacote atual se ACK/NAK recebido com erro
Ø receptor descarta (não entrega) pacote duplicado
Remetente envia um pacote,e então aguarda resposta do receptor
para e espera
3: Camada de Transporte 3a-22
rdt2.1: remetente, trata ACK/NAKs c/ erro
3: Camada de Transporte 3a-23
rdt2.1: receptor, trata ACK/NAKs com erro
3: Camada de Transporte 3a-24
rdt2.1: discussão
Remetente:Ø no. de seq no pacoteØ bastam dois nos. 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-25
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 bem
ü receptor deve incluir explicitamente no. de seqdo pacote reconhecido
Ø ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual
FSM doremetente
!
3: Camada de Transporte 3a-26
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
P: como lidar com perdas?ü remetente espera até ter certeza que se perdeu pacote ou ACK, e então retransmite
ü eca!: desvantagens?
Abordagem: remetente aguarda um tempo “razoável” pelo ACK
Ø retransmite e nenhum ACK recebido neste intervalo
Ø se pacote (ou ACK) apenas atrasado (e não perdido):
ü retransmissão será duplicada, mas 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-27
rdt3.0: remetente
3: Camada de Transporte 3a-28
rdt3.0 em ação
3: Camada de Transporte 3a-29
rdt3.0 em ação
3: Camada de Transporte 3a-30
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: fração do temporemetente 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/pkt10**9 b/sec = 8 microsec
L (tamanho do pacote - bits)R (taxa de transmissão, bps)
=
Uemissor=
.008
30.008 = 0.00027 microsegundosL / R
RTT + L / R=
3: Camada de Transporte 3a-31
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
Uemissor=
.008
30.008 = 0.00027 microsegundosL / R
RTT + L / R=
3: Camada de Transporte 3a-32
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 dutados: volta-N, retransmissão seletiva
3: Camada de Transporte 3a-33
Pipelining: aumenta utilização
bit 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
Uemissor=
.024
30.008 = 0.0008 microsegundos3*L / R
RTT + L / R=
3: Camada de Transporte 3a-34
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-35
Volta-N: FSM estendida do remetente
3: Camada de Transporte 3a-36
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
3: Camada de Transporte 3a-37
Volta-Nem ação
3: Camada de Transporte 3a-38
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-39
Retransmissão seletiva: janelas de remetente, receptor
3: Camada de Transporte 3a-40
Retransmissão seletiva
dados de cima:Ø se próx. no. de seq na janela, envia pacote
timeout(n):Ø reenvia pacote n, reiniciar temporizador
ACK(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-41
Retransmissão seletiva em ação
3: Camada de Transporte 3a-42
Retransmissão seletiva: dilema
Exemplo: Ø 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 seqe tamanho de janela?
3: Camada de Transporte 3a-43
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çãosocket
doorTCP
send buffer
TCP
receive buffer
socket
door
segment
application
writes dataapplication
reads data
3: Camada de Transporte 3a-44
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 receptor
ptr dados urg.checksumFSRPAUtam.
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-45
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 reconhecechegadado ‘C’ecoado
B reconhecechegada de ‘C’, ecoa‘C’ de volta
tempocenário simples de telnet
3: Camada de Transporte 3a-46
TCP: Tempo de Resposta (RTT) e TemporizaçãoP: como escolher valor do temporizadorTCP?
Ø 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 ACKscumulativos
Ø 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-47
TCP: Tempo de Resposta (RTT) e TemporizaçãoRTT_estimado = (1-αααα)* RTT_estimado + x*RTT_amostra
Ø média corrente exponencialmente ponderadaØ influência de cada amostra diminui exponencialmente com o tempo
Ø valor típico de α : 0.125
Escolhendo o intervalo de temporizaçãoØ RTT_estimado mais uma “margem de segurança”Ø variação grande em RTT_estimado
-> margem de segurança maiorTemporização = RTT_estimado + 4*Desvio
Desvio = (1- ββββ)* Desvio + ββββ *|RTT_amostra - RTT_estimado|
valor típico de β : 0.25
3: Camada de Transporte 3a-48
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)
RT
T (
mil
lise
con
ds)
SampleRTT Estimated RTT
3: Camada de Transporte 3a-49
TCP: transferência confiável de dadosØ TCP cria serviço rdtsobre o serviço nãoconfiável IP
Ø Utiliza pipeline para enviar segmentos
Ø ACKS cumulativosØ TCP usa temporizadorpara retransmissão
Ø Retransmissões sãodisparadas por:
ü timeoutü Acks duplicados
Ø Inicialmente considere um TCP emissor simplificado:
ü ignore acks duplicadosü ignore controle de fluxoe controle de congestionamento;
3: Camada de Transporte 3a-50
Eventos doTCP emissor:Dados recebidos da aplic:Ø Cria o segmento com node seq X
Ø seq X é o número do primeiro byte do segmento
Ø Inicia o temporizadorse ele não foi iniciadoanteriormente
Ø Intervalo de expiração: TimeOutInterval
timeout:Ø Retransmite o segmento quecausou o timeout
Ø Reinicializa o temporizadorAck recebido:
Ø Se reconhece segmentos não reconhecidos anteriormente
ü Atualiza a informação sobrepacotes reconhedidos
ü Inicia o temporizador se existem ainda segmentosnão reconhecidos
3: Camada de Transporte 3a-51
TCP: transfe-rênciaconfiável de dados
00 sendbase = número de seqüência inicial01 nextseqnum = número de seqüência inicial
0203 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-52
TCP: cenários de retransmissão
Estação A
Seq=92, 8 bytes de dados
ACK=100
perdatemporizaçã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
Temp.p/Seq=92
temporização prematura,ACKs cumulativos
Host B
Seq=92, 8 bytes de dados
ACK=120
Seq=92, 8 bytes de dados
Temp. p/Seq=100
ACK=120
tempo
3: Camada de Transporte 3a-53
TCP: cenários de retransmissão (cont)Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
Cenário de ACK cumulativo
Host B
X
Seq=100, 20 bytes data
ACK=120
time
3: Camada de Transporte 3a-54
TCP geração de ACKs [RFCs 1122, 2581]
Evento
chegada de segmento em ordem
sem lacunas,
anteriores já reconhecidos
chegada de segmento em ordem
sem lacunas,
um ACK retardado pendente
chegada de segmento fora de
ordem, com no. de seq. maior
que esperado -> lacuna
chegada de segmento que
preenche a lacuna parcial ou
completamente
Ação do receptor TCP
ACK retardado. Espera até 500ms
p/ próx. segmento. Se não chegar
segmento, envia ACK
envia imediatamente um único
ACK cumulativo
envia ACK duplicado, indicando no.
de seq.do próximo byte esperado
ACK imediato se segmento no
início da lacuna
3: Camada de Transporte 3a-55
Fast Retransmit
Ø Período de timeout é geralmente longo:
ü Longo atraso até a retransmissão do segmento perdido
Ø Detectar segmentosperdidos via ACKsduplicados
ü Emissores geralmenteenviam váriossegmentos
ü Se um segmento é perdido, provavelmente vão ser recebidos ACKs duplicados
Ø Se o emissor recebe 3 ACKs para o mesmosegmento, supõe que o segemtno subseqüente foi perdido:
ü fast retransmit:retransmite o segmetno antes que o temporizador expire
3: Camada de Transporte 3a-56
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-57
remetente não esgotaria buffers do receptor portransmitir muito, oumuito rápidamente
controle de fluxo
TCP: Controle de Fluxo
Ø Lado receptor de umaconexão TCP tem um buffer de recepção:
Ø Processo da aplicaçãopode ser lento pararetirar os dados do buffer
Ø Serviço decompatibilização de velocidades: compatibilizara taxa de envio do emissorcom a taxa de recebimentodos dados da aplicação do receptor
3: Camada de Transporte 3a-58
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 tenhaoverflow no buffer do receptor
3: Camada de Transporte 3a-59
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ãoSocket clientSocket = new Socket("hostname","port
number");
Ø servidor: contactado por clienteSocket 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 recebeSYNACK, responde com um segmento de ACK, que pode conter dados
3: Camada de Transporte 3a-60
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
espera
temporizada
3: Camada de Transporte 3a-61
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
espera
temporizada
fechada
3: Camada de Transporte 3a-62
TCP: Gerenciamento de Conexões (cont.)
Ciclo de vidade cliente TCP
Ciclo de vidade servidor TCP
3: Camada de Transporte 3a-63
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 emroteadores)
ü longos atrasos (enfileiramento nos buffers dosroteadores)
Ø um dos 10 problemas mais importantes em redes!
3: Camada de Transporte 3a-64
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-65
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, maisdados retransmitidos
3: Camada de Transporte 3a-66
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-67
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 finitocompartilhado
Host Aλin : dados originais
Host B
λout
λ'in : dados originais, maisdados retransmitidos
3: Camada de Transporte 3a-68
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!
Ho
st A
Ho
st B
λou
t
3: Camada de Transporte 3a-69
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-70
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-71
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-72
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çãodo congestionamento na rede;
Como TCP detectacongestionamento?
Ø 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-73
TCP: Controle de Congestionamento
Ø w segmentos, cada um c/ MSS bytes, enviados por RTT:
throughput = w * MSSRTT Bytes/sec
Congwin
3: Camada de Transporte 3a-74
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-75
TCP AIMD
8 Kbytes
16 Kbytes
24 Kbytes
time
congestion
window
multiplicative decrease (decréscimo multiplicativo:reduz CongWin pela metadedepois de um evento de perda
additive increase (crescimento aditivo):aumenta CongWin de 1 MSS a cada RTT naausência de um eventode perda: probing
Conexão TCP de longa duração
3: Camada de Transporte 3a-76
TCP: Partida lenta (Slow Start)
Ø Quando a conexãocomeça, CongWin = 1 MSS
ü Exemplo: MSS = 500 bytes & RTT = 200 msec
ü Taxa inicial = 20 kbps
Ø A banda disponível deveser >> MSS/RTT
Ø Quando a conexãocomeça, aumenta a taxaexponencialmente até o primeiro evento de perda
Ø Resumo: taxa inicial baixa, mais cresce rapidamente(crescimento exponencial)
3: Camada de Transporte 3a-77
TCP: Partida lenta (slow start)
Ø Quando a conexão começa, aumenta a taxaexponencialmente até que ococra uma perda
ü Dobra CongWin a cadaRTT, 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-78
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 algunssegmentos�Ocorrência de timeout antes de 3 ACKs duplicados é “mais alarmante”
Filosofia:
3: Camada de Transporte 3a-79
Refinamento (mais)Q: Quando o crescimento devemudar de exponencial paralinear ?
A: Quando CongWinatinge 1/2 do seuvalor 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
co
ng
est
ion
win
do
w s
ize
(se
gm
en
ts)
Series1 Series2
threshold
TCP Tahoe
TCP Reno
3: Camada de Transporte 3a-80
TCP: Prevenção do Congestionamento(congestion Avoidance
/* partida lenta acabou */ /* Congwin > threshold */
Until (event de perda) {cada w segmentos
reconhecidos:Congwin++
}
threshold = Congwin/2Congwin = 1
faç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-81
Resumo: Controle de CongestionamentoØ Quando CongWin está abaixo do Threshold, o emissor está na fase de slow-start, e a janelacresce 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-82
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-83
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 ãodaconexã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-83
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 ãodaconexã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-83
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 ãodaconexã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-83
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 ãodaconexã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-83
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 ãodaconexã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-83
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 ãodaconexã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-83
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 ãodaconexã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-83
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 ãodaconexã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-84
Eqüidade (mais)Eqüidade e UDPØ Aplic. Multimídiageralmente não usamTCP
ü Não desejam que a taxaseja reduzida pelocontrole de congestionamento
Ø Geralmente usam UDP:ü audio/video a taxaconstante, toleramperdas de pacotes
Ø Área de pesquisa: TCP friendly
Eqüidade e conexões TCP paralelas
Ø Nada previne que aplic. abram várias conexõessimultânceas entre os 2 hosts;
Ø Wrowsers fazem isto Ø Exemplo: enlace com taxa igual a R, com 9 conexões;
ü Nova aplic. requer umaconexão TCP, recebe R/10 da taxa
ü Nova aplic. requer 11 conexões TCP, recebe R/2 da taxa
3: Camada de Transporte 3a-85
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-86
Janela de congestionamento de tamanho fixo (1)
Primeiro caso:WS/R > RTT + S/R: ACK doprimeiro segmento na janela chega antes deenviar todos dados na janela
latência = 2RTT + O/R
3: Camada de Transporte 3a-87
Janela de congestionamento de tamanho fixo (2)
Segundo caso:Ø WS/R < RTT + S/R: aguarda ACK depois deenviar todos os dados na janela
latência = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]
3: Camada de Transporte 3a-88
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:
}1,{min −= KQP
- onde Q é o número de vezes que o servidor parariase o objeto fosse de tamanho infinito.
- e K é o número de janelas que cobrem o objeto.
R
S
R
SRTTP
R
ORTTLatência
P )12(2 −−
+++=
3: Camada de Transporte 3a-89
TCP: modelagem de latência: Slow Start(2)
RTT
initiate TCPconnection
request
objectfirst window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window= 8S/R
complete
transmissionobjectdelivered
time at
client
time atserver
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-90
TCP: modelagem de latência: (3)
R
S
R
SRTTPRTT
R
O
R
SRTT
R
SRTT
R
O
TempoBloqueioRTTR
O
P
kP
k
P
p
p
)12(][2
]2[2
2latencia
1
1
1
−−+++=
−+++=
++=
−
=
=
∑
∑
tempo de bloqueio após a
k-ésima janela2
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 janela21 =−
R
Sk
RTT
iniciaconexão TCP
pedeobjeto
primeira janela= S/R
segunda janela= 2S/R
terceira janela= 4S/R
quarta janela= 8S/R
transmissão
completaobjetoentregue
tempo no
cliente
tempo no
servidor
3: Camada de Transporte 3a-91
+=
+≥=
≥−=
≥+++=
≥+++=−
−
)1(log
)}1(log:{min
}12:{min
}/222:{min
}222:{min
2
2
110
110
S
O
S
Okk
S
Ok
SOk
OSSSkK
k
k
k
L
L
O cálculo do número Q, de inatividade por objeto de tamanho infinito,é similar (veja HW).
Lembre que K = número de janelas que cobrem um objetoComo calculamos o valor de K?
TCP modelagem de latência: partida lenta (4)
3: Camada de Transporte 3a-92
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 dosperí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 deinatividade
Ø 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-93
0
2
4
6
8
10
12
14
16
18
20
28
Kbps
100
Kbps
1
Mbps
10
Mbps
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ão
Conexõ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-94
0
10
20
30
40
50
60
70
28
Kbps
100
Kbps
1
Mbps
10
Mbps
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-95
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
Top Related