SSC0641 Redes de Computadores - USPwiki.icmc.usp.br/images/0/00/Rc_transporte2017_1.pdf · confiável de dados importante nas camadas de aplicação, transporte e enlace lista dos

1

slide 1

SSC0641Redes de Computadores

Capítulo 3 - Camada de Transporte

Prof. Jó UeyamaAbril/2017

slide 2

Capítulo 3: Camada de transporte

Objetivos do capítulo: entender princípios

por trás dos serviçosda camada detransporte:� multiplexação/demul-

tiplexação� transferência de

dados confiável� controle de fluxo� controle de

congestionamento

aprender sobre osprotocolos da camada detransporte na Internet:� UDP: transporte sem

conexão� TCP: transporte orientado a

conexão� controle de

congestionamento TCP

slide 3

Capítulo 3: Esboço

3.1 Serviços dacamada de transporte

3.2 Multiplexação edemultiplexação

3.3 Transporte nãoorientado paraconexão: UDP

3.4 Princípios datransferência confiávelde dados

3.5 Transporte orientadopara conexão: TCP� estrutura de segmento� transferência confiável de

dados� controle de fluxo� gerenciamento da conexão

3.6 Princípios de controlede congestionamento

3.7 Controle decongestionamento no TCP

slide 4

Serviços e protocolos de transporte

oferecem comunicação lógica entre processos de aplicaçãorodando em hospedeirosdiferentes

protocolos de transporte rodam emsistemas finais � lado remetente: divide as msgs

da aplicação em segmentos,passa à camada de rede

� lado destinatário: remonta ossegmentos em msgs, passa àcamada de aplicação

mais de um protocolo detransporte disponível às aplicações� Internet: TCP e UDP

aplicaçãotransporte

redeenlacefísica


redeenlacefísica

transporte lógico fim a fim

slide 5

Camada de transporte versus rede

camada de rede: comunicação lógicaentre hospedeiros

camada de transporte: comunicação lógicaentre processos � conta com e amplia os

serviços da camada derede

analogia com a família:

12 crianças mandandocarta a 12 crianças

processos = crianças msgs da aplicação =

cartas nos envelopes hospedeiros = casas protocolo de transporte

= Ana e Bill protocolo da camada de

rede = serviço postal

slide 6

redeenlacefísica

redeenlacefísica

Protocolos da camada de transporte da Internet

remessa confiável e emordem (TCP)� controle de congestionamento� controle de fluxo� estabelecimento da conexão

remessa não confiável edesordenada: UDP� extensão sem fluxo do IP pelo

“melhor esforço” serviços não disponíveis:

� garantias de atraso� garantias de largura de banda� Jitter?


redeenlacefísica

networkdata linkphysical

redeenlacefísica

redeenlacefísica

redeenlacefísica rede

enlacefísica


redeenlacefísica

logical end-end transport

slide 7










slide 8

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

hospedeiro 1 hospedeiro 2 hospedeiro 3

= processo = socket

entregando segmentosrecebidos ao socket correto

demultiplexação no destinatário:colhendo dados de múltiplossockets, envelopando dadoscom cabeçalho (usados depoispara demultiplexação)

multiplexação no remetente:

slide 9

Como funciona a demultiplexação

hospedeiro recebedatagramas IP� cada datagrama tem

endereço IP de origem,endereço IP de destino

� cada datagrama carrega 1segmento da camada detransporte

� cada segmento temnúmero de porta deorigem, destino

hospedeiro usa endereços IP& números de porta paradirecionar segmento ao socketapropriado

# porta origem # porta destino

32 bits

dados daaplicação

(mensagem)

outros campos de cabeçalho

formato do segmento TCP/UDP

slide 10

Demultiplexação não orientada para conexão

cria sockets com númerosde porta:

DatagramSocket mySocket1 = newDatagramSocket(12534);

DatagramSocket mySocket2 = newDatagramSocket(12535);

socket UDP identificado portupla de dois elementos:

(endereço IP destino, número portadestino)

quando hospedeirorecebe segmento UDP:� verifica número de porta

de destino no segmento� direciona segmento UDP

para socket com essenúmero de porta

datagramas IP comdiferentes endereços IPde origem e/ou númerosde porta de origemdirecionados para omesmo socket

slide 11

DatagramSocket serverSocket = new DatagramSocket(6428);

ClienteIP:B

P2

cliente IP: A

P1P1P3

servidorIP: C

SP: 6428DP: 9157

SP: 9157DP: 6428

SP: 6428DP: 5775

SP: 5775DP: 6428

SP oferece “endereço de retorno”

slide 12

Demultiplexação orientada para conexão

socket TCP identificadopor tupla de 4 elementos: � endereço IP de origem� número de porta de origem� endereço IP de destino� número de porta de destino

hospedeiro destinatáriousa todos os quatrovalores para direcionarsegmento ao socketapropriado

hospedeiro servidor podeadmitir muitos sockets TCPsimultâneos:� cada socket identificado usa

própria tupla de 4 servidores Web podem ter

diferentes sockets paracada cliente conectando� HTTP não persistente terá

diferentes sockets para cadarequisição

slide 13

clienteIP:B

P1

cliente IP: A

P1P2P4

servidorIP: C

SP: 9157DP: 80

SP: 9157DP: 80

P5 P6 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP: 5775DP: 80

D-IP:CS-IP: B

slide 14

Demultiplexação orientada paraconexão: servidor Web threaded

clienteIP:B

P1

cliente IP: A

P1P2

servidorIP: C

SP: 9157DP: 80

SP: 9157DP: 80

P4 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP: 5775DP: 80

D-IP:CS-IP: B

slide 15










slide 16

UDP: User Datagram Protocol [RFC 768]

protocolo de transporte daInternet “sem luxo”, básico

serviço de “melhor esforço”,segmentos UDP podem ser:� Sem QoS; 8 bytes de header

enqt TCP 20 bytes� perdidos� entregues à aplicação fora

da ordem sem conexão:

� sem handshaking entreremetente e destinatárioUDP

� cada segmento UDP tratadoindependente dos outros

Por que existe um UDP? sem estabelecimento de

conexão (que pode geraratraso)

simples: sem estado deconexão no remetente,destinatário

cabeçalho de segmentopequeno

sem controle decongestionamento: UDPpode transmitir o maisrápido possível

slide 17

UDP: mais

normalmente usado parastreaming de aplicações demultimídia� tolerante a perdas� sensível à taxa

outros usos do UDP� DNS� SNMP

transferência confiável porUDP: aumenta confiabilidadena camada de aplicação� recuperação de erro

específica da aplicação!

# porta origem # porta dest.

32 bits

dados daaplicação

(mensagem)

formato de segmento UDP

tamanho soma verif.tamanho,

em bytes, dosegmento UDP,

incluindocabeçalho

slide 18

Soma de verificação UDP

remetente: trata conteúdo de

segmento como sequênciade inteiros de 16 bits

soma de verificação(checksum): adição (somapor complemento de 1) doconteúdo do segmento

remetente coloca valor dasoma de verificação nocampo de soma deverificação UDP

destinatário: calcula soma de verificação do

segmento recebido verifica se soma de verificação

calculada igual ao valor docampo de soma de verificação:� NÃO – erro detectado� SIM – nenhum erro

detectado. Mas pode havererros mesmo assim? Vejamais adiante ….

objetivo: detectar “erros” (p. e., bits invertidos) nosegmento transmitido

slide 19

Exemplo de soma de verificação da Internet

nota

� Ao somar números, um carryout do bitmais significativo precisa ser somado aoresultado

exemplo: somar dois inteiros de 16 bits1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

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

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

contorna

somasoma de

verificação

slide 20










slide 21

Princípios de transferência confiável de dados

importante nas camadas de aplicação, transporte e enlace lista dos 10 mais importantes tópicos de redes! características do canal confiável determinarão complexidade

do protocolo de transferência confiável (rdt)

slide 22

Transferência confiável de dados: introdução

ladoremetente

ladodestinatário

rdt_send(): chamado de cima, (p. e.,pela apl.). Dados passados para remeter

à camada superior do destinatário

udt_send(): chamado pelardt, para transferir pacote porcanal não confiável aodestinatário

rdt_rcv(): chamado quando pacotechega no lado destinatário do canal

deliver_data(): chamado pelardt para remeter dados para cima

slide 23

vamos: desenvolver de forma incremental os lados remetente e

destinatário do protocolo de transferência confiável de dados (rdt) considerar apenas a transferência 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

estado1

estado2

evento causando transição de estadoações tomadas sobre transição de estado

estado: quando neste“estado”, próximo

estado determinadoexclusivamente pelo

próximo evento

eventoações

FSM: Finite State Machine

slide 24

Rdt1.0: transferência 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

Esperachamadade cima packet = make_pkt(dados)

udt_send(pacote)

rdt_send(dados)

extract (pacote, dados)deliver_data(dados)

Esperachamadade baixo

rdt_rcv(pacote)

remetente destinatário

slide 25

Rdt2.0: canal 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

slide 26

rdt2.0: especificação da FSM

Esperachamadade cima

snkpkt = make_pkt(dados, soma_verif)udt_send(pctenv)

extract(pctrec,dados)deliver_data(dados)udt_send(ACK)

rdt_rcv(pctrec) && notcorrupt(pctrec)

rdt_rcv(pctrec) && isACK(pctrec)

udt_send(pctenv)

rdt_rcv(pctrec) && isNAK(pctrec)

udt_send(NAK)

rdt_rcv(pctrec) && corrupt(pctrec)

EsperaACK ou

NAK

Esperachamadade baixoremetente

destinatáriordt_send(dados)

slide 27

rdt2.0: operação sem erros






udt_send(pctenv)


udt_send(NAK)


EsperaACK ou

NAK


rdt_send(dados)

slide 28

rdt2.0: cenário de erro






udt_send(pctenv)


udt_send(NAK)


EsperaACK ou

NAK


rdt_send(dados)

slide 29

rdt2.0 tem uma falha fatal!

O que acontece seACK/NAK forcorrompido?

remetente não sabe o queaconteceu no destinatário!

não pode simplesmenteretransmitir: possívelduplicação

tratando de duplicatas: remetente retransmite pacote

atual se ACK/NAKcorrompido

remetente acrescenta númerode sequência a cada pacote

destinatário descarta (nãosobe) pacote duplicado

remetente envia um pacote, depois espera resposta dodestinatário

pare e espere

slide 30

rdt2.1: remetente trata de ACK/NAKs corrompidos

Esperachamada 0

de cima

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

rdt_send(dados)

EsperaACK ouNAK 0 udt_send(pctenv)

rdt_rcv(pctrec) && ( corrupt(pctrec) ||isNAK(pctrec) )


rdt_send(dados)

rdt_rcv(pctrec) && notcorrupt(pctrec) && isACK(pctrec)

udt_send(pctenv)

rdt_rcv(pctrec) && ( corrupt(pctrec) ||isNAK(pctrec) )

rdt_rcv(pctrec) && notcorrupt(pctrec) && isACK(pctrec)

Esperachamada 1

de cima

EsperaACK ou NAK 1

slide 31

Espera0 decima

pctenv = make_pkt(NAK, chksum)udt_send(pctenv)

rdt_rcv(pctrec) && not corrupt(pctrec) && has_seq0(pctrec)

rdt_rcv(pctrec) && notcorrupt(pctrec) && has_seq1(pctrec)

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

Espera1 debaixo


extract(pctrec,dados)deliver_data(dados)pctenv = make_pkt(ACK, chksum)udt_send(pctenv) rdt_rcv(pctrec) &&

(corrupt(pctrec)

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

rdt_rcv(pctrec) && not corrupt(pctrec) && has_seq1(pctrec)

rdt_rcv(pctrec) &&(corrupt(pctrec)

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

pctenv = make_pkt(NAK, chksum)udt_send(pctenv)

rtd2.1: destinatário

slide 32

rdt2.1: discussão

remetente: # seq acrescentado ao

pkt dois #s seq. (0,1)

bastarão. Por quê? deve verificar se

ACK/NAK recebido foicorrompido

o dobro de estados� estado de “lembrar” se

pacote “atual” tem #seq. 0 ou 1

destinatário: deve verificar se

pacote recebido estáduplicado� estado indica se 0 ou 1 é

# seq. esperado dopacote

nota: destinatário nãosabe se seu últimoACK/NAK foi recebidoOK no remetente

slide 33

rdt2.2: um protocolo sem NAK

mesma funcionalidade de rdt2.1, usando apenasACKs

em vez de NAK, destinatário envia ACK para últimopacote 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

slide 34

rdt2.2: fragmentos do remetente, destinatário

Esperachamada 0

de cima


rdt_send(dados)

udt_send(pctenv)

rdt_rcv(pctrec) && ( corrupt(pctrec) || isACK(pctrec,1) )

rdt_rcv(pctrec) && notcorrupt(pctrec) && isACK(pctrec,0)

EsperaACK

0

fragmento FSMdo remetente

Espera0 debaixo


extract(pctrec,dados)deliver_data(dados)pctenv = make_pkt(ACK1, chksum)udt_send(pctenv)

rdt_rcv(pctrec) && (corrupt(pctrec) || has_seq1(pctrec))

udt_send(pctenv)

fragmento FSMdo destinatário

slide 35

rdt3.0: canais com erros e perdas

nova suposição: canalsubjacente tambémpode perder pacotes(dados ou ACKs)

� soma de verificação, #seq., ACKs,retransmissões serãoúteis, mas nãosuficientes

técnica: remetente esperaquantidade “razoável” detempo por ACK

retransmite se não chegar ACKnesse tempo

se pct (ou ACK) simplesmenteatrasado (não perdido):� retransmissão será

duplicada, mas os #s de seq.já cuidam disso

� destinatário deve especificar# seq. do pacote sendoreconhecido com ACK

requer contador regressivo

slide 36

remetente rdt3.0

pctenv = make_pkt(0, dados, checksum)udt_send(pctenv)start_timer

rdt_send(dados)

EsperaACK0

rdt_rcv(pctrec) &&( corrupt(pctrec) ||isACK(pctrec,1) )

Esperachamada 1

de cima

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

rdt_send(dados)

rdt_rcv(pctrec) && notcorrupt(pctrec) && isACK(pctrec,0)

rdt_rcv(pctrec) &&( corrupt(pctrec) ||isACK(pctrec,0) )

rdt_rcv(pctrec) && notcorrupt(pctrec)&& isACK(pctrec,1)

stop_timerstop_timer

udt_send(pctenv)start_timer

timeout

udt_send(pctenv)start_timer

timeout

rdt_rcv(pctrec)

Esperachamada 0

de cima

EsperaACK1

rdt_rcv(pctrec)

slide 37

rdt3.0 em ação

slide 38

Temporização imatura

slide 39

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

U remet =

0,008

30,008 = 0,00027

microseconds

L / R RTT + L / R

=

� em 30 ms, só esteve enviando por 0,008 ms� 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!

slide 40

rdt3.0: operação pare e espere

U remet =

0,008

30,008 = 0,00027

microseconds

L / R RTT + L / R

=

slide 41

Protocolos com paralelismo

paralelismo: remetente permite múltiplos pacotes “noar”, 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

slide 42

Paralelismo: utilização aumentada

U remet =

0,024 30,008

= 0,0008 microseconds

3 * L / R RTT + L / R

=

Aumento de utilizaçãopor fator de 3!

slide 43

Protocolos com paralelismo

Go-back-N: visão geral remetente: até N pacotes

não reconhecidos napipeline

destinatário: só envia ACKscumulativos� não envia pct ACK se

houver uma lacuna remetente: tem

temporizador para pct semACK mais antigo� se o temporizador expirar:

retransmite todos ospacotes sem ACK

Repetição seletiva: visão geral remetente: até pacotes não

reconhecidos na pipeline destinatário: reconhece (ACK)

pacotes individuais remetente: mantém

temporizador para cada pct semACK� se o temporizador expirar:

retransmite apenas o pacotesem ACK

slide 44

Go-Back-Nremetente:

# 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 – “ACKcumulativo”

� 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

slide 45

GBN em operação

slide 46

Repetição seletiva

destinatário reconhece individualmente todos ospacotes 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

slide 47

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

slide 48

Repetição seletiva

dados de cima: se próx. # seq. disponível

na janela, envia pct

timeout(n): reenvia pct n, reinicia

temporizador

ACK(n) em[sendbase,sendbase+N]:

marca pct n como recebido se n menor pct com ACK,

avança base da janela parapróximo # seq. sem ACK

Pacote na janela� envia ACK(n)� fora de ordem: buffer� em ordem: entrega

(também entrega pcts emordem no buffer), avançajanela para próximo pctainda não recebido

Pacote já reconhecidona janela anterior� ACK(n)caso contrário: � ignora

destinatárioremetente

slide 49

Repetição seletiva em operação

slide 50

Repetição seletiva: dilemaExemplo:

# 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 entretamanho do # seq. e tamanho dejanela?

Tamanho da janela NÃO deve serigual ao espaço de numeração - 1

slide 51










slide 52

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

dados full duplex:� dados bidirecionais fluem

na mesma conexão� MSS: tamanho máximo do

segmento orientado a conexão:

� apresentação (troca demsgs de controle) iniciaestado do remetente edestinatário antes datroca de dados

fluxo controlado:� remetente não

sobrecarrega destinatário

ponto a ponto:� um remetente, um

destinatário cadeia de bytes confiável, em

ordem:� sem “limites de mensagem”

paralelismo:� congestionamento TCP e

controle de fluxo definemtamanho da janela

buffers de envio & recepção

slide 53

Estrutura do segmento TCP

porta origem porta destino

32 bits

dados daaplicação

(tamanho variável)

número sequêncianúmero reconhecimento

janela recepçãoponteiro dados urg.soma verificação

FSRPAUcompr.cab.

nãousado

opções (tamanho variável)

URG: dados urgentes (quase não usado)

ACK: # ACKválido

PSH: empurrar dadosagora (quase não usado)

RST, SYN, FIN:estab. conexão

(comandos setup,teardown)

# bytes destinatáriopode aceitar

contagem porbytes de dados(não segmentos!)

soma de verificaçãoda Internet

(como em UDP)

slide 54

#s sequência e ACKs do TCP

cenário telnet simples

#’s de sequência:� “número” na cadeia de

bytes do 1o byte nosdados do segmento

ACKs:� # seq do próximo byte

esperado do outro lado� ACK cumulativo

P: como o destinatário tratasegmentos fora de ordem

� R: TCP não diz – acritério doimplementador

slide 55

Tempo de ida e volta e timeout do TCP

P: Como definir o valorde timeout do TCP?

maior que RTT� mas RTT varia

muito curto: timeoutprematuro� retransmissões

desnecessárias muito longo: baixa

reação a perda desegmento

P: Como estimar o RTT? SampleRTT: tempo medido

da transmissão dosegmento até receber oACK� ignora retransmissões

SampleRTT variará;queremos RTT estimado“mais estável”� média de várias

medições recentes, nãoapenas SampleRTT atual

slide 56










slide 57

Transferência confiável de dados no TCP

TCP cria serviço rdt emcima do serviço nãoconfiável do IP

segmentos em paralelo ACKs cumulativos TCP usa único

temporizador deretransmissão

retransmissões sãodisparadas por:� eventos de timeout� ACKs duplicados

inicialmente, consideraremetente TCPsimplificado:� ignora ACKs duplicados� ignora controle de

fluxo, controle decongestionamento

slide 58

Eventos de remetente TCP:dados recebidos da apl.:

cria segmento com #seq

# seq # é número dacadeia de bytes doprimeiro byte de dadosno segmento

inicia temporizador, seainda não tiver iniciado(pense nele como parao segmento maisantigo sem ACK)

intervalo de expiração:TimeOutInterval

timeout: retransmite segmento

que causou timeout reinicia temporizador

ACK recebido: Reconhecem-se

segmentos sem ACKanteriores� atualiza o que

sabidamente tem ACK� inicia temporizador se

houver segmentospendentes

slide 59

RemetenteTCP(simplificado)

NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

loop (forever) { switch(event)

event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(dados)

event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer

event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer }

} /* end of loop forever */

Comentário:• SendBase-1: último bytecumulativo com ACKExemplo:• SendBase-1 = 71;y = 73, de modo quedestinatário deseja 73+ ;y > SendBase, de modo quenovos dados têm ACK

slide 60

TCP: cenários de retransmissão

Hosp. A

Seq = 100, 20 bytes dados

ACK = 100

tempoTimeout prematuro

Hosp. B


ACK = 120


Seq

= 92

tim

eout

ACK = 120

Hosp. A


ACK = 100

loss

tim

eout

Cenário de ACK perdido

Hosp. B

X


ACK = 100

tempo

Seq

= 92

tim

eout

SendBase = 100

SendBase = 120

SendBase = 120

Sendbase = 100

slide 61

Host A


ACK = 100

perda

tim

eout

Cenário ACK cumulativo

Host B

X


ACK =

120

tempo

SendBase = 120

slide 62

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

slide 63

Retransmissão rápida

período de timeoutrelativamente grande:� longo atraso antes de

reenviar pacote perdido detecta segmentos perdidos

por meio de ACKsduplicados� remetente geralmente

envia muitos segmentos umapós o outro

� se segmento for perdido,provavelmente haverámuitos ACKs duplicadospara esse segmento

se remetente recebe 3 ACKspara os mesmos dados, elesupõe que segmento apósdados com ACK foi perdido:� retransmissão rápida:

reenvia segmento antes queo temporizador expire

slide 64

Hosp. A

tim

eout

Hosp. B

tempo

X

reenvia seq X2

seq # x1seq # x2seq # x3seq # x4seq # x5

ACK x1

ACK x1ACK x1ACK x1

ACKsduplicadostrês vezes

slide 65










slide 66

Controle de fluxo TCP

lado receptor daconexão TCP tem umbuffer de recepção:

serviço decompatibilização develocidades: compatibiliza a taxa deenvio do remetentecom a de leitura daaplicação receptora

� processo da aplicaçãopode ser lento naleitura do buffer

remetente não estourarábuffer do destinatário

transmitindo muitosdados muito rapidamente

controle de fluxo

datagramasIP

dados TCP(no buffer)

espaçode buffer

(atualmente)não usado

processo daaplicação

slide 67

Controle de fluxo TCP: como funciona

(suponha que destinatário TCPdescarte segmentos fora deordem)

espaço de buffer não usado: = rwnd

= RcvBuffer-[LastByteRcvd -LastByteRead]

destinatário: anunciaespaço de buffer nãousado, incluindo valorde rwnd no cabeçalhodo segmento

remetente: limita # debytes com ACK a rwnd� garante que buffer do

destinatário não estoura

rwndRcvBuffer

datagramasIP

dados TCP(no buffer)

espaçode buffer

(atualmente)não usado

processo daaplicação

slide 68










slide 69

Gerenciamento da conexão TCP

lembre-se: Remetente edestinatário TCP estabelecem“conexão” antes que troquemsegmentos dados

inicializa variáveis TCP:� #s seq.:� buffers, informação de

controle de fluxo (p. e.RcvWindow)

cliente: inicia a conexão Socket clientSocket = new

Socket("hostname","port #"); servidor: contactado pelo

cliente Socket connectionSocket =

welcomeSocket.accept();

apresentação de 3 vias:

etapa 1: hosp. cliente envia segmentoSYN do TCP ao servidor

� especifica # seq. inicial� sem dados

etapa 2: hosp. servidor recebe SYN,responde com segmento SYNACK

� servidor aloca buffers� especifica # seq. inicial do

servidoretapa 3: cliente recebe SYNACK,

responde com segmento ACK, quepode conter dados

slide 70

fechando uma conexão:

cliente fecha socket: clientSocket.close();

etapa 1: sistema final do cliente envia segmento decontrole TCP FIN aoservidor

etapa 2: servidor recebe FIN,responde com ACK. Fechaconexão, envia FIN.

cliente

FIN

servidor

ACK

ACK

FIN

fecha

fecha

fechado

espe

ra

tem

pori

zada

slide 71

etapa 3: cliente recebe FIN,responde com ACK

� entra em “esperatemporizada” –responderá com ACKaos FINs recebidos

etapa 4: servidor recebe ACK- conexão fechada

Nota: Com pequenamodificação, pode tratar deFINs simultâneos.

cliente

FIN

servidor

ACK

ACK

FIN

fechado

fechando

fechado

fechadoes

pera

te

mpo

riza

da

slide 72

ciclo de vida docliente TCP

ciclo de vida doservidor TCP

slide 73










slide 74

Princípios de controle decongestionamento

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 nosroteadores)

� longos atrasos (enfileiramento nos buffers doroteador)

um dos maiores problemas da rede!

slide 75

Técnicas para controle decongestionamento

controle de congestionamentofim a fim:

nenhum feedback explícito darede

congestionamento deduzido daperda e atraso observados dosistema final

técnica tomada pelo TCP

controle decongestionamentoassistido pela rede:

roteadores oferecemfeedback aos sistemasfinais� único bit indicando

congestionamento (IBMSNA, DEC DECbit,TCP/IP ECN (ExplicitCong. Notif., ATM)

� taxa explícita que oremetente deve enviarno enlace de saída

duas técnicas amplas para controle de congestionamento:

slide 76

Estudo de caso: controle decongestionamento ATM ABR

ABR: taxa de bitdisponível:

“serviço elástico” se o caminho do remetente

está “sobrecarregado”: � remetente deve usar

largura de bandadisponível

se caminho do remetentecongestionado: � remetente sufocado à

taxa mínima garantida

células RM (gerenciamento derecursos) :

enviadas pelo remetente,intercaladas com células de dados

bits na célula RM definida porcomutadores (“assistido pela rede”) � bit NI: sem aumento na taxa

(congestionamento leve)� bit CI: indicação de

congestionamento células RM retornadas ao remetente

pelo destinatário, com bits intactos

slide 77










slide 78

Controle de congestionamento TCP:busca por largura de banda

� “procura por largura de banda”: aumenta taxa detransmissão no recebimento do ACK até por fim ocorrerperda; depois diminui taxa de transmissão

� continua a aumentar no ACK, diminui na perda (pois largura debanda disponível está mudando, dependendo de outras conexõesna rede) ACKs sendo recebidos,

de modo que aumentataxa

X

X

XX

X perda e diminuição de taxa

taxa

de

emis

são

tempo

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

comportamento“dente de serra”

do TCP

slide 79

Controle de congestionamento TCP: mais detalhes

evento de perda de segmento:reduzindo cwnd

timeout: sem resposta dodestinatário� corta cwnd para 1

3 ACKs duplicados: pelomenos alguns segmentospassando (lembre-se daretransmissão rápida)� corta cwnd pela metade,

menos agressivamente do queno timeout

ACK recebido: aumentacwnd

� fase de partida lenta: � aumento exponencialmente

rápido (apesar do nome) noinício da conexão, ou apóso timeout

� prevenção decongestionamento:

� aumento linear

slide 80

Partida lenta do TCP

quando conexão começa, cwnd = 1MSS� exemplo: MSS = 500 bytes &

RTT = 200 ms� taxa inicial = 20 kbps� desejável subir rapidamente

para taxa respeitável aumenta taxa exponencialmente até

o primeiro evento de perda ouquando o patamar é alcançado� cwnd duplo a cada RTT� feito incrementando cwnd por 1

para cada ACK recebido

Hosp. A

um segmento

RTT

Hosp. B

tempo

dois segmentos

quatro segmentos

slide 81

Tipos populares de TCP

slide 82

Equidade (mais)

equidade e UDP aplicações de multimídia

normalmente não usamTCP� não desejam que a taxa

seja sufocada pelocontrole decongestionamento

em vez disso, use UDP:� envia áudio/vídeo em

taxa constante, toleraperdas de pacotes

equidade e conexões TCPparalelas

nada impede que aaplicação abra conexõesparalelas entre 2hospedeiros.

navegadores Web fazemisso

exemplo: enlace de taxa Radmitindo 9 conexões; � nova aplicação solicita 1 TCP,

recebe taxa R/10� nova aplicação solicita 11

TCPs, recebe mais de R/2!

slide 83

Equidade (mais)

equidade e UDP aplicações de multimídia

normalmente não usamTCP� não desejam que a taxa

seja sufocada pelocontrole decongestionamento

em vez disso, use UDP:� envia áudio/vídeo em

taxa constante, toleraperdas de pacotes

equidade e conexões TCPparalelas

nada impede que aaplicação abra conexõesparalelas entre 2hospedeiros.

navegadores Web fazemisso

exemplo: enlace de taxa Radmitindo 9 conexões; � nova aplicação solicita 1 TCP,

recebe taxa R/10� nova aplicação solicita 11

TCPs, recebe mais de R/2!

slide 84

Capítulo 3: Resumo princípios por trás dos

serviços da camada detransporte:� multiplexação,

demultiplexação� transferência de dados

confiável� controle de fluxo� controle de

congestionamento instância e implementação na

Internet� UDP� TCP

Em seguida: saindo da “borda” da

rede (camada detransportes daaplicação)

no “núcleo” da rede

Documents

SSC0641 Redes de Computadores - USPwiki.icmc.usp.br/images/0/00/Rc_transporte2017_1.pdf · confiável de dados importante nas camadas de aplicação, transporte e enlace lista dos