REDES DE COMPUTADORES Prof Evandro Cant Prof Evandro

REDES DE COMPUTADORES Prof. Evandro Cantú

Prof. Evandro Cantú, Dr. Eng. cantu@sj. cefetsc. edu. br www. sj. cefetsc. edu. br/wiki Slides adaptados de J. Kurose & K. Ross (http: //www. aw-bc. com/kurose-ross/), e J. A. Suruagy (http: //www. nuperc. unifacs. br/suruagy/redes/index. html) 2 Curso de Capacitação Intelbras Redes Computadores Maio 2007

Objetivos: • 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 Camada de Transporte aprender os protocolos da camada de transporte da Internet: UDP: transporte sem conexão TCP: transporte orientado a conexões Controle de congestionamento do TCP 3

Serviços e protocolos de transporte rede enlace física po ns rede enlace física e rt o c gi ló m fi a rede enlace física m fi – lado transmissor: quebra as mensagens das aplicações em segmentos, repassa-os para a camada de rede – lado receptor: remonta as mensagens a partir dos segmentos, repassa-as para a camada de aplicação transporte rede enlace física a tr • provê comunicação lógica entre processos de aplicação executando em hospedeiros diferentes • protocolos de transporte executam em sistemas finais: aplicação transporte rede enlace física • existem mais de um protocolo de transporte disponível para as aplicações – Internet: TCP e UDP 4

Camadas de Transporte x Rede • camada de rede: comunicação lógica entre hospedeiros • camada de transporte: comunicação lógica entre processos – depende da camada rede e estende os serviços por ela oferecidos 5

Protocolos da camada de transporte Internet aplicação • entrega confiável, ordenada transporte rede (TCP) enlace e o c gi ló m fi a rede enlace física m fi • serviços não disponíveis: rede enlace física rt – extensão sem “frescuras” do “melhor esforço” do IP rede enlace física po ns • entrega não confiável, não ordenada: UDP rede enlace física a tr – controle de congestionamento – controle de fluxo – estabelecimento de conexão (“setup”) física aplicação transporte rede enlace física – garantias de atraso – garantias de largura de banda 6

Multiplexação/ demultiplexação Multiplexação no transmisspr: reúne dados de muitos sockets, envelopa os dados com o cabeçalho (usado posteriormente para a demultiplexação) Demultiplexação no receptor: Entrega dos segmentos recebidos ao socket correto = socket aplicação transporte rede = processo P 3 P 1 aplicação transporte P 2 P 4 aplicação transporte rede enlace física host 1 host 2 host 3 7

Como funciona a demultiplexação • host recebe os datagramas IP – cada datagrama possui os endereços IP da origem e do destino – cada datagrama transporta 1 segmento da camada de transporte – cada segmento possui números das portas origem e destino (lembre: números de portas bem conhecidas para aplicações específicas) • host usa os endereços IP e os números das portas para direcionar o segmento ao socket apropriado 32 bits porta remetente porta receptor outros campos do cabeçalho dados da aplicação (mensagem) formato de segmento TCP/UDP 8

Demultiplexação sem Conexões • socket UDP • Quando host recebe segmento UDP: identificado – verifica no. da porta de destino no pela dupla: segmento (end IP dest, no. da porta destino) – encaminha o segmento UDP para o socket com aquele no. de porta • Datagramas IP com diferentes endereços IP origem e/ou números de porta origem são encaminhados para o mesmo socket 9

Demultiplexação sem Conexões P 2 P 1 P 3 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 cliente IP: A DP: 6428 servidor IP: C SP: 5775 DP: 6428 Cliente IP: B SP (source port) provê “endereço de retorno” 10

Demultiplexação Orientada a Conexões • Socket TCP identificado pela 4 -dupla: – – endereço IP origem número da porta origem endereço IP destino número da porta destino • receptor usa todos os quatro valores para direcionar o segmento para o socket apropriado • Servidor pode dar suporte a muitos sockets TCP simultâneos: – cada socket é identificado pela sua própria 4 -dupla • Servidores Web têm sockets diferentes para cada conexão cliente – HTTP não persistente terá sockets diferentes para cada pedido 11

Demultiplexação Orientada a Conexões P 1 P 4 P 5 P 2 P 6 P 1 P 3 SP: 5775 DP: 80 S-IP: B D-IP: C cliente IP: A SP: 9157 DP: 80 S-IP: A D-IP: C SP: 9157 servidor IP: C DP: 80 S-IP: B D-IP: C Cliente IP: B 12

Demultiplexação Orientada a Conexões: Servidor Web com Threads P 1 P 2 P 4 P 1 P 3 SP: 5775 DP: 80 S-IP: B D-IP: C cliente IP: A SP: 9157 DP: 80 S-IP: A D-IP: C SP: 9157 servidor IP: C DP: 80 S-IP: B D-IP: C Cliente IP: B 13

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 de 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 14

• muito utilizado para apls. de meios contínuos (voz, vídeo) – tolerantes de perdas – sensíveis à taxa de transmissão • outros usos de UDP: – DNS (nomes) – SNMP (gerenciamento) • transferência confiável com UDP: incluir confiabilidade na camada de aplicação – recuperação de erro específica à apl. ! Comprimento em bytes do segmento UDP, incluindo cabeçalho Mais sobre UDP 32 bits porta origem porta dest. comprimento checksum Dados de aplicação (mensagem) Formato do segmento UDP 15

Checksum UDP Meta: detectar “erro” (e. g. , bits invertidos) no segmento transmitido 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 é zero: – NÃO - erro detectado – SIM - nenhum erro detectado. Mas ainda pode ter erros? Veja depois …. 16

Exemplo do Checksum Internet • Note – Ao adicionar números, o transbordo do bit mais significativo deve ser adicionado o resultado • Exemplo: adição de dois inteiros de 16 -bits 1 1 0 0 1 1 1 0 1 0 1 transbordo 1 1 0 1 1 soma 1 1 0 1 1 0 0 checksum 1 0 0 0 0 1 1 17

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 complexidade de um protocolo de transferência confiável de dados (rdt) 18

Transferência confiável de dados (rdt) rdt_send(): chamada de cima, (p. ex. , pela apl. ). Dados recebidos p/ entregar à camada sup. do receptor send side udt_send(): chamada por rdt, p/ transferir pacote pelo canal ñ confiável ao receptor deliver_data(): chamada por rdt p/ entregar dados p/ camada superior receive side rdt_rcv(): chamada quando pacote chega no lado receptor do canal 19

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 • ponto a ponto: • transmissão full duplex: – 1 remetente, 1 receptor – fluxo de dados bi-direcional na mesma conexão • fluxo de bytes, ordenados, confiável: – MSS: tamanho máximo de – não estruturado em msgs segmento • com paralelismo (pipelined): – tam. da janela ajustado por controle • orientado a conexão: – handshaking (troca de msgs de de fluxo e congestionamento do controle) inicia estado de TCP remetente, receptor antes de • buffers de envio e recepção trocar dados • fluxo controlado: – receptor não será afogado

TCP: estrutura do 32 bits URG: dados urgentes (pouco usados) ACK: no. ACK válido PSH: envia dados já (pouco usado) RST, SYN, FIN: gestão de conexão (comandos de estabelecimento, liberação) checksum Internet (como UDP) segmento no. porta origem no. porta dest número de seqüência número de reconhecimento tam. sem UA P R S F cab. uso checksum janela receptor ptr dados urg. Opções (tam. variável) dados da aplicação (tam. variável) contagem de dados por bytes (não segmentos!) no. bytes rcpt quer aceitar

TCP: Seq e Ack Números de sequência (Seq): – “número”dentro do fluxo de bytes do primeiro byte de dados do segmento Números de Reconhecimento (Ack): – no. de seq do próx. byte esperado do outro lado – ACK cumulativo Estação B Estação A Usuário tecla ‘C’ A reconhece chegada do ‘C’ ecoado Seq=4 2, ACK = 79, da ta = ‘C’ B reconhece chegada de ’ C ‘ ‘C’, ecoa ata = d , 3 4 = K ‘C’ de volta , AC 9 7 = q e S Seq=4 3, ACK =80 cenário simples de telnet tempo

TCP: Tempo de Resposta e Temporização P: como escolher valor do temporizador TCP? • maior que o RTT (Round Trip Time) – 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 • Como o RTT_amostra vai varia, usa-se várias medições recentes, não apenas o valor corrente.

Exemplo de estimativa do RTT:

TCP: Tempo de Resposta (RTT) e Temporização Escolhendo o intervalo de temporização • RTT_estimado mais uma “margem de segurança” – grande variação no RTT_estimado -> maior margem de segurança • primeiro estima o quanto a RTTamostra desvia do RTT_estimado, então, seta o temporizador para: Temporização = RTT_estimado + 4*Desvio_RTT

Transferência de dados confiável do TCP • O TCP cria um serviço confiável sobre o serviço não confiável do IP • Segmentos em série (pipelined) • Acks cumulativos • O TCP usa um único temporizador para retransmissões • As retransmissões são disparadas por: – estouros de temporização – acks duplicados • Considere inicialmente um transmissor TCP simplificado: – ignora acks duplicados – ignora controles de fluxo e de congestionamento

Eventos do Dados recebidos da aplicação: • Cria segmento com no. de seqüência (nseq) • nseq é o número de seqüência do primeiro byte do segmento • Liga o temporizador se já não estiver ligado (temporização do segmento mais antigo ainda não reconhecido) • Valor do temporizador: calculado anteriormente transmissor TCP: estouro do temporizador: • Retransmite o segmento que causou o estouro do temporizador • Reinicia o temporizador Recepção de Ack: • Se reconhecer segmentos ainda não reconhecidos – atualizar informação sobre o que foi reconhecido – religa o temporizador se ainda houver segmentos pendentes (não reconhecidos)

TCP: cenários de retransmissão Host A 2, 8 by tes da t Seq=92 timeout a =100 X ACK loss Seq=9 2, 8 by tes da Host B Seq=9 ta 100 Sendbase = 100 Send. Base = 120 = ACK Send. Base = 100 tempo cenário de perda de ACK Send. Base = 120 2, 8 by Seq= 100, 2 tes da ta 0 byte s data 0 10 = K 120 = C K A AC Seq=92 timeout Seq=9 timeout Host A Host B tempo 2, 8 by tes da ta 20 K=1 AC estouro prematuro do temporizador

TCP: cenários de retransmissão Host A Host B Seq=9 timeout 2, 8 by Send. Base = 120 tes da Seq=1 00, 20 X ta =100 K C A bytes data loss 120 = ACK tempo Cenário de ACK cumulativo

TCP geração de ACKs [RFCs 1122, 2581] Evento no Receptor Ação do Receptor TCP chegada de segmento em ordem sem lacunas, anteriores já reconhecidos ACK retardado. Espera até 500 ms p/ próx. segmento. Se não chegar segmento, envia ACK chegada de segmento em ordem sem lacunas, um ACK retardado pendente envia imediatamente um único ACK cumulativo chegada de segmento fora de ordem, com no. de seq. maior que esperado -> lacuna envia ACK duplicado, indicando no. de seq. do próximo byte esperado chegada de segmento que preenche a lacuna parcial ou completamente ACK imediato se segmento no início da lacuna

Retransmissão rápida • O intervalo do temporizador é • freqüentemente bastante longo: – longo atraso antes de retransmitir um pacote perdido • Detecta segmentos perdidos através de ACKs duplicados. – O transmissor normalmente envia diversos segmentos – Se um segmento se perder, provavelmente haverá muitos ACKs duplicados. Se o transmissor receber 3 ACKs para os mesmos dados, ele supõe que o segmento após os dados reconhecidos se perdeu: – Retransmissão rápida: retransmite o segmento antes que estoure o temporizador

Controle de Fluxo do TCP • Lado receptor da conexão TCP possui um buffer de recepção: • Processo da apl. pode demorar a ler do receptor Controle de fluxo o transmissor não inundará o buffer do receptor transmitindo muito e rapidamente • serviço de casamento de velocidades: adaptando a taxa de transmissão à taxa de leitura da aplicação receptora

Controle de Fluxo do TCP: como funciona • O receptor anuncia o espaço livre incluindo o valor da Rcv. Window nos segmentos • O transmissor limita os (Suponha que o receptor TCP dados não reconhecidos ao receba segmentos fora de ordem) tamanho da Rcv. Window • espaço livre no buffer – Garante que o buffer do = Rcv. Window receptor não transbordará = Rcv. Buffer[Last. Byte. Rcvd Last. Byte. Read]

TCP: Gerenciamento de Conexões Inicialização em 3 tempos: Passo 1: sistema cliente envia segmento de Lembrete: Remetente, receptor TCP controle SYN do TCP ao servidor estabelecem “conexão” antes de trocar segmentos de dados – especifica no. inicial de seq • inicializam variáveis TCP: – não envia dados – nos. de seq. Passo 2: sistema servidor recebe SYN, – buffers, info s/ controle de fluxo responde com segmento de controle (p. ex. Rcv. Window) SYNACK • cliente: iniciador de conexão – aloca buffers • servidor: contactado por cliente – especifica no. inicial de seq. servidor-> receptor Passo 3: receptor recebe SYNACK, responde com segmento ACK que pode conter dados.

TCP: Gerenciamento de Conexões (cont. ) cliente Encerrando uma conexão: fechar cliente fecha soquete: Passo 1: sistema cliente envia segmento de controle FIN ao servidor FIN ACK FIN espera temporizada Passo 2: servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN. servidor fechada ACK fechar

TCP: Gerenciamento de Conexões (cont. ) Passo 3: cliente recebe FIN, responde com ACK. – Entre em “espera temporizada” - responderá com ACK a FINs recebidos cliente fechando servidor FIN ACK Passo 4: servidor, recebe ACK. Conexão encerrada. fechando espera temporizada FIN fechada ACK fechada

TCP: Gerenciamento de Conexões (cont. ) Ciclo de vida de servidor TCP Ciclo de vida de cliente TCP

Princípios de Controle de Congestionamento: • 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!

Abordagens de controle de congestionamento Duas abordagens amplas para controle de congestionamento: Controle de congestionamento fim a fim : com apoio da rede: • não tem realimentação • roteadores realimentam os explícita pela rede sistemas terminais • congestionamento inferido – bit indicando a partir das perdas, retardo congestionamento observados pelo sistema (ATM) terminal – taxa explícita p/ envio • abordagem usada pelo TCP pelo remetente

Controle de Congestionamento do • controle fim-a-fim (sem assistência da rede) • transmissor limita a transmissão: Last. Byte. Sent-Last. Byte. Acked Cong. Win • Praticamente, taxa = Cong. Win Bytes/seg RTT • Cong. Win é dinâmica, em função do congestionamento percebido da rede TCP Como o transmissor percebe o congestionamento? • evento de perda = estouro do temporizador ou 3 acks duplicados • transmissor TCP reduz a taxa (Cong. Win) após evento de perda três mecanismos: – AIMD – partida lenta – conservador após eventos de estouro de temporização

AIMD do TCP decrescimento multiplicativo: corta Cong. Win pela metade após evento de perda crescimento aditivo: incrementa Cong. Win de 1 MSS a cada RTT na ausência de eventos de perda: sondagem Conexão TCP de longa duração

Partida Lenta do TCP • No início da conexão, aumenta a taxa Cong. Win = 1 MSS exponencialmente até o – Exemplo: MSS = 500 primeiro evento de perda bytes & RTT = 200 mseg – taxa inicial = 20 kbps • largura de banda disponível pode ser >> MSS/RTT – é desejável um crescimento rápido até uma taxa considerável

TCP: Partida lenta (mais) Estação A Estação B RTT • No início da conexão, aumenta a taxa exponencialmente até o primeiro evento de perda: – duplica Cong. Win a cada RTT – através do incremento da Cong. Win para cada ACK recebido • Resumo: taxa inicial é baixa mas cresce rapidamente de forma exponencial um segmen to dois segme ntos quqtro segm entos tempo

Refinamento Filosofia: • Após 3 ACKs duplicados: – corta Cong. Win pela metade – a janela depois cresce linearmente • Mas após estouro de temporizador: – Cong. Win é reduzida a 1 MSS; – janela cresce exponencialmente – até um limiar, depois cresce linearmente • 3 ACKs duplicados indica que a rede é capaz de entregar alguns segmentos • estouro de temporizador antes de 3 ACKs duplicados é mais “alarmante”.

Refinamento (mais) P: Quando o crescimento exponencial deve mudar para linear? R: Quando Cong. Win atinge 1/2 do seu valor antes do estouro do temporizador. Implementação: • Limiar (Threshold) variável • Com uma perda o limiar passa a ser 1/2 da Cong. Win imediatamente anterior à perda.

Resumo: Controle de Congestionamento do TCP • Quando a Cong. Win está abaixo do limiar, transmissor está na fase de início lento, janela cresce exponencialmente. • Quando a Cong. Win está acima do limiar, transmissor está na fase de evitar congestionamento, janela cresce linearmente. • Quando chegam ACKs triplicados, Limiar passa a ser Cong. Win/2 e Cong. Win passa ao valor do Limiar. • Quando estoura o temporizador, Limiar passa a ser Cong. Win/2 e Cong. Win passa a ser 1 MSS.

Controle de congestionamento do transmissor TCP Evento Estado Ação do Transmissor TCP Comentário ACK recebido para dados ainda não reconhecidos Partida lenta Cong. Win = Cong. Win + MSS, If (Cong. Win > Limiar) seta estado para “Evitar congestionamento” Resulta na duplicação da Cong. Win a cada RTT ACK recebido para dados ainda não reconhecidos Evitar congestiona mento Cong. Win = Cong. Win+MSS * (MSS/Cong. Win) Incremento aditivo, resultando no incremento da Cong. Win de 1 MSS a cada RTT Perda detectada por ACKs triplicados qualquer Limiar = Cong. Win/2, Cong. Win = Limiar, Seta estado para “Evitar Congestionamento” Recuperação rápida, implementa decrescimento multiplicativo. Cong. Win não cai abaixo de 1 MSS. Estouro de temporizador qualquer Limiar = Cong. Win/2, Cong. Win = 1 MSS, Seta estado para “Partida lenta” Entra estado de “partida lenta” ACK duplicado qualquer Incrementa contador de ACKs duplicados para o segmento que está sendo reconhecido Cong. Win e Threshold não se alteram