Camada de Transporte Transferindo Mensagem entre Processos

Camada de Transporte Transferindo Mensagem entre Processos 1

Serviços e protocolos de transporte rede enlace física rede enlace física a tr aplicação transporte rede enlace física rt po ns e gi ló rede enlace física co m fi a m fi rede enlace física rede enlace física provê comunicação lógica entre processos de aplicação executando em hosts diferentes aplicação transporte rede enlace física 2

Serviços? Como? 3

Capítulo 3: Camada de Transporte Metas do capítulo: compreender os princípios que guiam os serviços da camada de transporte: multiplexação/ demultiplexação transferência confiável de dados controle de fluxo controle de congestionamento instanciação e implementação na Internet dos protocolos de transporte UDP TCP Resumo do Capítulo: serviços da camada de transporte multiplexação/demultiplexação transporte sem conexão: UDP princípios da transferência confiável de dados transporte orientado a conexão: TCP transferência confiável controle de fluxo gerenciamento de conexões princípios do controle de congestionamento controle de congestionamento usados no TCP 4

Serviços e protocolos de transporte aplicação transporte rede enlace física rede enlace física rede enlace física a tr rt po ns e gi ló rede enlace física co m fi a rede enlace física rede enlace física m fi provê comunicação lógica entre processos de aplicação executando em hosts diferentes protocolos de transporte executam em sistemas finais emissor: fragmenta a mensagem da aplicação em segmentos e os envia para a camada de rede; receptor: rearranja os segmentos em mensagens e os transmite para a camada de aplicação; Mais de um protocolo de transporte disponível para as aplicações Internet: TCP e UDP aplicação transporte rede enlace física 5

Camada de Rede e Camada de Transporte camada de rede : comunicação lógica entre hosts ou sistemas; camada de transporte: comunicação lógica entre processos os serviços da camada de transporte e suas dimensões: Confiabilidade, Integridade, Vazão, e tempo; depende dos serviços da camada de rede; estende os serviços da camada de rede 6

Multiplexação/demultiplexação Multiplexação no transmissor: obter dados dos diversos processos, envelopando-os com cabeçalho (usado depois para demultiplexação) = socket aplicação transporte rede Demultiplexação no receptor: entrega de segmentos recebidos para os devidos processos da camada de aplicação. = processo P3 P1 P1 aplicação transporte P2 P4 aplicação transporte rede rede enlace enlace enlace física física física host 1 host 2 host 3 7

Os elementos da demultiplexação host recebe os datagramas IP Cada datagrama tem um endereço IP de origem e de destino; Cada datagrama carrega 1 segmento da camada de transporte; Cada segmento tem um número de porta de origem e um de destino lembrete: número de porta bem conhecido para aplicações específicas host usa o endereço IP e o número de porta para direcionar o segmento para o socket apropriado; 32 bits porta remetente porta receptor outros campos do cabeçalho dados da aplicação (mensagem) formato de segmento TCP/UDP 8

Demultiplexação não orientada a conexão Quando o host recebe o Cria sockets com os números de porta DatagramSocket mysocket1 = new DatagramSocket(); DatagramSocket mysocket2 = new DatagramSocket(9157); Socket UDP identificado pela 2-tupla: (endereço IP destino, no porta destino) segmento UDP: Verifica o número da porta de destino no segmento Direciona o segmento UDP para o socket correspondente ao número da porta; Datagramas IP com diferentes endereços IP de origem e/ou números de porta de origem são direcionados para o mesmo socket desde que... 9

Demultiplexação não orientada a conexão (cont) DatagramSocket serversocket = new DatagramSocket(6428); P2 SP: 6428 DP: 9157 client IP: A P1 P1 P3 SP: 9157 DP: 6428 SP: 6428 DP: 5775 server IP: C SP provê endereço de retorno SP: 5775 DP: 6428 Client IP:B 10

Demultiplexação orientada a conexão Identificação do socket, 4-tupla: endereço IP de origem número da porta de origem endereço IP de destino número da porta de destino Hosts receptor usa estes valores da tupla para direcionar os segmentos para o socket apropriado host servidor deve suportar múltiplos sockets TCP simultaneamente: Cada socket é identificado por sua 4-tupla servidores Web tem diferentes sockets para cada cliente HTTP não persistente tem diferentes sockets para cada requisição 11

Demultiplexação orientada a conexão P3 P3 SP: 80 DP: 9157 cliente IP: A SP: 9157 DP: 80 P1 P1 P4 SP: 80 DP: 5775 servidor IP: C SP: 5775 DP: 80 cliente IP:B 12

QUESTÕES Considere uma conexão de dados confiável. Suponha que um segmento que viaja do Sistema A para o Sistema B tem número de porta fonte x e número de porta destino y. Quais são as portas de origem e destino em um segmento que viaja de B para A? É possível para uma aplicação obter transferência confiável de dados se ela estiver usando o serviço de transferência não confiável da camada de transporte? 13

QUESTÕES(II) Supondo um processo em um sistema C esteja usando um socket com número de porta 6789 criado para uma comunicação não-orientada a conexão. Suponha que o sistema A e B envie segmentos para C destinada a porta 6789. Serão esses segmentos destinados ao mesmo socket? Se sim como o processo irá identificar a origem dos segmentos? 14

Atividade: Protocolo para a camada de transporte Tarefa: Projetar um protocolo para a camada de transporte que ofereça um serviço de transferência Não-confiável. Espera-se: Dinâmica de troca de mensagens pelas entidades que usam o protocolo; Formato das mensagens enviadas(msg requisição; msg resposta). 15

UDP: User Datagram Protocol [RFC 768] Protocolo de transporte da Por quê existe o UDP? Internet mínimo elimina estabelecimento de Serviço melhor esforço, conexão (o que pode causar segmentos UDP podem ser: retardo) perdidos simples: não se mantém estado entregues à aplicação fora da conexão no de ordem do envio remetente/receptor sem conexão: pequeno cabeçalho de segmento não há setup UDP entre sem controle de remetente, destinatário congestionamento: UDP pode tratamento independente transmitir o mais rápido possível para cada segmento UDP 16

Comprimento em bytes do segmento UDP, muito utilizado para apls. de meios incluindo contínuos (voz, vídeo) cabeçalho Mais sobre UDP 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 à aplicação 32 bits porta origem porta dest. comprimento checksum Dados de aplicação (mensagem) UDP segment format 17

Checksum UDP Meta: detecta 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 possui algum zero: SIM - erro detectado NÃO - nenhum erro detectado. 18

Checksum UDP: Cálculo Palavra 1 Palavra 2 CheckSum 0110011001100000 0101010101010101 0000000000000000 1000111100001100 Palavra 3 19

Checksum UDP: Cálculo palavra1 + palavra2 Palavra 1 Palavra 2 0110011001100000 0101010101010101 1011101110110101 20

Checksum UDP: Cálculo resultado anterior + palavra3 Resultado anterior Checksum 1011101110110101 0000000000000000 1011101110110101 21

Checksum UDP: Cálculo resultado anterior + palavra3 Resultado anterior Palavra 3 CheckSum Compleme nto de 1 1011101110110101 1000111100001100 0100101011000010 1011010100111101 Lembra do campo checksum zerado???? 22

Checksum UDP: Cálculo Palavra 1 Palavra 2 0110011001100000 0101010101010101 1000111100001100 Palavra 3 1011010100111101 CheckSum Compleme nto de 1 Lembra do campo checksum zerado???? 23

Checksum UDP: Após o Cálculo Palavra 1 Palavra 2 CheckSum 0110011001100000 0101010101010101 1011010100111101 1000111100001100 Palavra 3 24

Checksum UDP: No destinatário Resultado Palavra 1+ Palavra 2 Palavra 3 1011101110110101 1000111100001100 0100101011000010 CheckSum 1011010100111101 25

Checksum, pra quê? Já que existe serviço similar na camada de Enlace, então pra quê um serviço redundante? 26

Capítulo 3: Camada de Transporte Metas do capítulo: compreender os princípios que guiam os serviços da camada de transporte: multiplexação/ demultiplexação transferência confiável de dados controle de fluxo controle de congestionamento instanciação e implementação na Internet dos protocolos de transporte UDP TCP Resumo do Capítulo: serviços da camada de transporte multiplexação/demultiplexação transporte sem conexão: UDP princípios da transferência confiável de dados transporte orientado a conexão: TCP transferência confiável controle de fluxo gerenciamento de conexões princípios do controle de congestionamento controle de congestionamento usados no TCP 27

Uma máquina de estado Estado: caracteriza uma certa configuração da máquina; Evento: eventualmente causam mudanças no estado da máquina; Ações: executadas quando da transição de um estado para outro; Transição é determinada unicamente pelo próximo evento evento causando transição de estados ações tomadas na transição de estado estado 1 evento ações estado 2 28

Vamos modelar a dinâmica do Trabalho 29

Qual a suposição???? Serviço: Transfer. Conf. Dados 30

Princípios de Transferência confiável de dados Serviço Prestado: MELHOR Esforço 31

Princípios de Transferência confiável de dados (rdt) importante pois outras camadas implementam o conceito; características do canal não confiável determinam a complexidade de 32 um protocolo de transferência confiável de dados (rdt)

Transferência confiável de dados (rdt): Interfaces do protocolo rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/ entregar à camada sup. do receptor Lado Trans. 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 Lado Recep. rdt_rcv(): chamada quando pacote chega no lado receptor do 33 canal

Transferência confiável de dados (rdt): A abordagem Desenvolver incrementalmente os lados remetente, receptor do protocolo RDT; Considerar apenas fluxo unidirecional de dados mas info de controle flui em ambos os sentidos! Usar máquinas de estados finitos (FSM) p/ especificar remetente, e receptor. 34

Transferência confiável de dados (rdt): Uma máquina de estado Estado: caracteriza uma certa configuração da máquina; Evento: eventualmente causam mudanças no estado da máquina; Ações: executadas quando da transição de um estado para outro; Transição é determinada unicamente pelo próximo evento evento causando transição de estados ações tomadas na transição de estado estado 1 evento ações estado 2 35

Rdt1.0: transferência confiável usando um canal confiável canal subjacente é confiável não tem erros de bits; não tem perda de pacotes. FSMs separadas para remetente e receptor: remetente envia dados pelo canal subjacente receptor recebe dados do canal subjacente 36

Rdt2.0: canal com erros de bits canal subjacente pode inverter bits no pacote a questão: como recuperar dos erros? lembre-se: checksum UDP pode detectar erros de bits reconhecimentos (ACKs): receptor avisa explicitamente ao remetente que pacote chegou bem reconhecimentos negativos (NAKs): receptor avisa explicitamente ao remetente que pacote tinha erros remetente retransmite pacote ao receber um NAK ARQ(Automatic Repeat request). novos mecanismos em rdt2.0 (em relação ao rdt1.0): deteção de erros realimentação pelo receptor: msgs de controle (ACK,NAK) receptor>remetente Retransmissão 37

rdt2.0: especificação da FSM FSM do remetente FSM do receptor 38

rdt2.0: especificação da FSM FSM do remetente FSM do receptor 39

rdt2.0: em ação (sem erros) FSM do remetente FSM do receptor 40

rdt2.0: em ação (com erro) FSM do remetente FSM do receptor 41

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/NAKs p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente? Melhorar o procedimento de Checksum permitindo a correção do erro, mas o pacote pode se perde; retransmitir, mas pode causar retransmissão de pacote recebido corretamente! 42

rdt2.1, lidando com a duplicação! remetente inclui número de sequência para cada pacote; remetente retransmite pacote atual se ACK/NAK foi recebido com erro; receptor descarta (não entrega) pacote duplicado. receptor transmite ACK para pacotes duplicados; 43

rdt2.1: remetente, trata ACK/NAKs c/ erro 44

rdt2.1: remetente, trata ACK/NAKs c/ erro 45

rdt2.1: receptor, trata ACK/NAKs com erro 46

rdt2.1: receptor, trata ACK/NAKs com erro 47

rdt2.1: discussão Remetente: no. de seq no pacote bastam dois nros. de seq. (0,1). Por quê? deve checar se ACK/NAK recebido tinha erro duplicou o no. de estados estado deve lembrar se pacote corrente tem no. de seq. 0 ou 1. Receptor: deve checar se pacote recebido é duplicado estado indica se no. de seq. esperado é 0 ou 1 note: receptor não tem como saber se último ACK/NAK foi recebido bem pelo remetente 48

rdt2.2: um protocolo sem NAKs mesma funcionalidade que rdt2.1, só com ACKs ao invés de NAK, receptor envia ACK p/ último pacote recebido corretamente receptor deve incluir explicitamente no. de seq do pacote reconhecido ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual 49

rdt2.2: Protocolo sem NAKs remetente 50

rdt2.2: Protocolo sem NAK - Receptor 51

Para-e-Espera: canais com erros e perdas 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 52

Para-e-Espera: canais com erros e perdas Abordagem: remetente aguarda um tempo razoável pelo ACK retransmite se nenhum ACK for recebido neste intervalo se pacote (ou ACK) apenas estiver atrasado (e não perdido): retransmissão será duplicada, mas o uso de no. de seq. já cuida disto receptor deve especificar no. de seq do pacote sendo reconhecido requer temporizador 53

Para-e-espera: Remetente 54

Para-e-Espera: em ação 55

Desempenho de Para-e-Espera Algoritmo Funciona, porém seu desempenho é muito ruim exemplo: enlace de 1 Gbps, retardo fim a fim(a ida) de 15 ms, pacote de 1KB: 8Kb Ttransmitir= L (tamanho do pacote - bits) = = 8 microsec R (taxa de transmissão, bps) 10**9 b/sec U = transmissor L/R RTT + L / R =.008 30.008 = 0.00027 (0.027%) Utilização: porcentagem/fração de tempo remetente está ocupado pac. de 1KB a cada ~30 mseg -> num enlace de 1 Gbps 1000 1KB 30 vazão de 33KB/seg protocolo limita uso dos recursos físicos! 56

A operação do para-e-espera emissor receptor bit primeiro pacote transmitido, t = 0 último bit transmitido, t = L / R bit do primeiro pacote recebido último bit do pacote recebido, envia ACK RTT ACK recebido, envia próximo pacote, t = RTT + L/R U = emissor L/R RTT + L / R =.008 30.008 = 0.00027 57

Protocolos dutados (pipelined) Dutagem (pipelining): remetente admite múltiplos pacotes em trânsito, ainda não reconhecidos 58

Pipelining: aumenta utilização emissor receptor bit primeiro pacote transmitido, t = 0 último bit transmitido, t = L / R primeiro bit do pacote recebido último bit recebido, envia ACK último bit do 2o pacote recebido, envia ACK último bit do 3o pacote recebido, envia ACK RTT ACK recebido, envia próximo pacote, t = RTT + L / R Aumenta a utilização de um fator de 3 U = emissor 3*L / R RTT + L / R =.024 30.008 = 0.0008 microsegundos 59

Protocolos dutados (pipelined) Volta-N e Retransmissão seletiva. 60

Protocolos para dutagem Volta-N: visão geral Remetente pode ter até N pacotes Não-acks no pipeline Receptor envia somente acks acumulativos Retransmissão Seletiva: Visão geral Não reconhece pacotes se existir espaço. Remetente tem timer para o pacote mais antigo enviado Se o timer expirar, retransmite todos os pacotes não acks. Remetente pode ter até N pacotes Não-acks no pipeline; Receptor reconhece pacotes individualmente; Remetente mantém timer para cada pacote não-ack Quando o timer expirar retransmite somente pacotes Não-acks. 61

Volta N Remetente pode ter até N pacotes Não-acks no pipeline Receptor envia somente acks acumulativos Não reconhece pacotes se existir espaço. Remetente tem timer para o pacote mais antigo enviado Se o timer expirar, retransmite todos os pacotes não acks. 62

Volta-N Remetente: 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 que serve para cada pacote em trânsito timeout(n): retransmite pacote n e todos os pacotes com no. de seq maiores na janela 63

Volta-N: FSM do remetente rdt_send(data) Λ base=1 nextseqnum=1 if (nextseqnum < base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) Wait rdt_rcv(rcvpkt) && corrupt(rcvpkt) timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer 64

Volta-N: FSM do receptor default udt_send(sndpkt) Λ Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ack,chksum) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ack,chksum) udt_send(sndpkt) expectedseqnum++ 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 65

Volta-N em ação 66

Retransmissão seletiva receptor reconhece individualmente todos os pacotes recebidos corretamente remetente apenas re-envia pacotes para os quais ACK não recebido armazena pacotes no buffer, conforme precisa, para posterior entrega em-ordem à camada superior 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 67

Retransmissão seletiva: janelas de remetente, receptor 68

Retransmissão seletiva remetente 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. receptor 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 69

Retransmissão seletiva em ação 70

Para-e-Espera: em ação 71

Questões de Implementação Perdas e atrasos são tratados pelas mesmas idéias ACK Número de Sequência Timer Retransmissão Como tratar o tamanho da dutagem? Como determinar que pacote foi perdido? Que pacote deve ser retransmitido? O duto tem tamanho fixo? 72

Exercício Capture, identifique e explique a troca de mensagens entre dois hospedeiros que se comunicam utilizando o TCP. Considere: O Uso do wireshark para capturar as mensagens Aponte as mensagens de sincronização da conexão Houve restabelecimento da conexão? A conexão foi aceita na primeira tentativa? Qual o tamanho do duto? 73

Princípios de Transferência confiável de dados (rdt) importante pois outras camadas implementam o conceito; características do canal não confiável determinam a complexidade de 74 um protocolo de transferência confiável de dados (rdt)

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 ponto a ponto: não estruturado em msgs dutado: socket door a p p l ic a t i o n re a d s d a ta TCP s e n d b u ffe r TCP r e c e iv e b u f f e r segm ent socket door handshaking (troca de msgs de controle) inicia estado de remetente, receptor antes de trocar dados fluxo controlado: a p p li c a t io n w r it e s d a t a fluxo de dados bidirecional na mesma conexão MSS: tamanho máximo de segmento orientado a conexão: tam. da janela ajustado por controle de fluxo e congestionamento do TCP buffers de envio e recepção transmissão full duplex: 1 remetente, 1 receptor fluxo de bytes, ordenados, confiável: receptor não será sobrecarregado 75

TCP: estrutura do segmento 32 bits URG: aviso de dados no. porta origem no. porta dest Urgentes (pouco usado) ACK: no. ACK válido PSH: Transf. Imediata Cam. aplic(pouco usado) RST, SYN, FIN: gestão de conexão (comandos de estabelecimento, liberação) checksum Internet (como UDP) 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) contagem de dados por bytes (não segmentos!) no. bytes rcpt quer aceitar dados da aplicação (tam. variável) 76

TCP: nos. de seq. e ACKs Nos. de seq.: número do byte, relativo ao fluxo, no segmento ACKs: no de seq do próx. byte esperado do outro lado Que tipo de ACK? P: como receptor trata segmentos fora da ordem? R: espec do TCP omissa - deixado ao implementador Estação A Usuário tecla C A reconhece chegada do C ecoado Seq=4 2, AC K=7 Estação B 9, dat a = C B reconhece chegada de C =, data C, ecoa 3 4 = K C A 79, C de volta Seq= Seq=4 3, ACK= 80 cenário simples de telnet tempo 77

TCP: Tempo de Resposta (RTT) RTT_estimado = (1-α)* RTT_estimado + α*rtt_amostra média móvel exponencialmente ponderada influência de cada amostra diminui exponencialmente com o tempo valor típico de α : 0.125 78

TCP: Temporização Escolhendo o intervalo de temporização RTT_estimado mais uma margem de segurança variação grande em RTT_estimado -> margem de segurança maior Temporização = RTT_estimado + 4*Desvio Desvio = (1- β)* Desvio + β * RTT_amostra - RTT_estimado valor típico de β : 0.25 79

Estimativa RTT e Cálculo do Timeout ICOMP - Google RTT medio (alpha=0.875) Timeout (Beta = 0.25) Medido Estimado timeout 76 74 72 70 RTT 68 66 64 62 60 medidas 80

TCP: transferência confiável de dados TCP cria serviço rdt sobre o serviço não confiável IP Utiliza pipeline para Retransmissões são disparadas por: timeout Acks duplicados enviar segmentos ACKS cumulativos TCP usa temporizador para retransmissão 81

Eventos dotcp emissor: Dados recebidos da aplic: timeout: Cria o segmento com no Retransmite o segmento que seq X é o número do Reinicializa o temporizador de seq X byte do fluxo no segmento Inicia o temporizador se ele não foi iniciado anteriormente Intervalo de expiração: TimeOutInterval causou o timeout Ack recebido: Se reconhece segmentos não reconhecidos anteriormente Atualiza a informação sobre pacotes reconhedidos Inicia o temporizador se existem ainda segmentos não reconhecidos 82

TCP: Tempo de Resposta (RTT) e Temporização P: como escolher valor do temporizador TCP? maior que o RTT note: RTT pode variar P: como estimar RTT? RTTamostra: tempo medido entre a transmissão do segmento e o recebimento do ACK correspondente muito curto: temporização prematura retransmissões desnecessárias muito longo: reação demorada à perda de segmentos ignora retransmissões, segmentos com ACKs cumulativos RTTamostra vai variar, queremos amaciador de RTT estimado usa várias medições recentes, não apenas o valor corrente 83 (RTTamostra)

Transferência confiável de dados Remetente TCP simplificado 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 sendbase = número de seqüência inicial nextseqnum = número de seqüência inicial loop (forever) { switch(event) event: dados recebidos da aplicação acima cria segmento TCP com número de seqüência nextseqnum inicia temporizador para segmento nextseqnum passa segmento para IP nextseqnum = nextseqnum + comprimento(dados) event: expirado temporizador de segmento c/ no. de seqüência y retransmite segmento com número de seqüência y calcula novo intervalo de temporização para segmento y reinicia temporizador para número de seqüência y event: ACK recebido, com valor de campo ACK de y se (y > sendbase) { /* ACK cumulativo de todos dados até y */ cancela temporizadores p/ segmentos c/ nos. de seqüência < y sendbase = y } senão { /* é ACK duplicado para segmento já reconhecido */ incrementa número de ACKs duplicados recebidos para y if (número de ACKs duplicados recebidos para y == 3) { /* TCP: retransmissão rápida */ reenvia segmento com número de seqüência y reinicia temporizador para número de seqüência y } } /* fim de loop forever */ 84

TCP: cenários de retransmissão Host A Estação A Estação B X bytes AC os 00 K=1 perda Seq=9 2, 8 bytes = ACK tempo de da d Seq=9 2, 8 de da d os Temp. p/ Seq=100 Temp.p/ Seq=92 temporização Seq=9 2, 8 Seq= 1 00, 2 bytes 0 byt de da d es de os dado s 0 10 = K 120 = C K A AC Seq=9 2, 8 bytes de da d os 0 =12 K AC 100 cenário do ACK perdido Host B tempo temporização prematura, 85 ACKs cumulativos

TCP: cenários de retransmissão (cont) Host A Host B timeout Seq=9 2, 8 Seq=1 00, X bytes data =100 K C A 20 byt es da ta loss = ACK 120 time Cenário de ACK cumulativo 86

TCP geração de ACKs [RFCs 1122, 2581] Evento Ação do receptor TCP chegada de segmento em ordem sem lacunas, anteriores já reconhecidos ACK retardado. Espera até 500ms 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 87

Fast Retransmit Período de timeout é geralmente longo: Longo atraso até a retransmissão do segmento perdido Detectar segmentos perdidos via ACKs duplicados Emissores geralmente enviam vários segmentos Se um segmento é perdido, provavelmente vão ser recebidos ACKs duplicados Se o emissor recebe 3 ACKs para o mesmo segmento, supõe que o segmento subseqüente foi perdido: fast retransmit: retransmite o segmento antes que o temporizador expire 88

TCP fast retransmit Host B Host A Seq=92, 8 bytes de dado Seq=100, 20 bytes de dado X t i me o u t ACK=100 ACK=100 ACK=100 ACK=100 Seq=100, 20 bytes de dado fast retransmit após remetente receber triplo ACK Duplicado Transport Layer 3-89

Algoritmo Fast retransmit: evento: ACK recebido, com valor de ACK igual a y if(y > SendBase) { SendBase = y if (existem segmentos 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 } Um ACK duplicado para um segmento já reconhecido previamente fast retransmit 90

TCP: Controle de Fluxo Lado receptor de uma conexão TCP tem um buffer de recepção: controle de fluxo remetente não esgotaria buffers do receptor por transmitir muito, ou muito rapidamente Serviço de Processo da aplicação pode ser lento para retirar os dados do buffer compatibilização de velocidades: compatibilizar a taxa de envio do emissor com a taxa de recebimento dos dados pela aplicação no receptor 91

TCP: estrutura do segmento 32 bits 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) no. bytes rcpt quer aceitar dados da aplicação (tam. variável) 92

Controle de Fluxo TCP: como funciona? receptor: explicitamente avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente) (Suponha que o TCP receptor descarte pacotes fora de ordem) = RcvWindow = RcvBuffer-[LastByteRcvd LastByteRead] campo RcvWindow no segmento TCP remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de RcvWindow Garante que não tenha overflow no buffer do receptor 93

TCP: Gerenciamento de Conexões Lembrete: Remetente, receptor TCP estabelecem conexão antes de trocar segmentos de dados inicializam variáveis TCP: nos. de seq. buffers, info s/ controle de fluxo (p.ex. RcvWindow) cliente: iniciador de conexão Socket clientsocket = new Socket("hostname","port number"); servidor: contactado por cliente Socket connectionsocket = welcomesocket.accept(); Inicialização em 3 tempos: Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor especifica no. inicial de seq sem dados Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK aloca buffers especifica no. inicial de seq. Passo 3: sistema cliente recebe SYNACK, responde com um segmento de ACK, que pode conter dados 94

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

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 FIN Step 4: servidor, recebe ACK. fechando Note: com pequena modificação, consegue tratar de FINs simultâneos. espera temporizada Conexão encerrada. fechada ACK fechada 96

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

Princípios de Controle de Congestionamento 98

Princípios de Controle de Congestionamento 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) 99

Controle de Congestionamento 20 Questões!!! Problema de Otimização (NUM) TCP Tahoe (1988) e Reno (fast recover) soluções para NUM específico Outras versões: TCP Vegas(1995), FAST TCP(2002), CUBIC (2005) 100

Abordagens de controle de congestionamento Duas abordagens amplas para 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 final 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 109

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 Min{CongWin, RcvWin} Como TCP detecta congestionamento? Evento de perda = timeout ou 3 acks duplicados TCP emissor reduz taxa de transmissão (CongWin) depois de um evento de perda CongWin é dinâmica, e é função Três mecanismos: AIMD do congestionamento na rede; Partida lenta Prevenção de congestionamento 112

TCP: Controle de Congestionamento Congwin w segmentos, cada um c/ MSS bytes, enviados por RTT: Vazão = w * MSS Bytes/sec RTT 113

TCP: Controle de Congestionamento sondagem para banda utilizável: O ideal: 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 duas fases partida lenta Prevenção de congestionamento variáveis importantes: Congwin threshold: define limiar entre fases de partida lenta, controle de congestionamento 114

Os mecanismos: AIMD Multiplicative Decrease (decréscimo multiplicativo: reduz CongWin pela metade depois de um evento de perda c own ign ed so twi o n 2 4 K b y te s Additive Increase (crescimento aditivo): aumenta CongWin de 1 MSS a cada RTT na ausência de um evento de perda: probing 1 6 K b y te s 8 K b y te s tim e Conexão TCP de longa duração 115

Os mecanismos: Partida lenta Quando a conexão começa, CongWin = 1 MSS Exemplo: MSS = 1460 bytes & RTT = 200 msec Taxa inicial = 7.3 kbps A banda disponível deve ser >> MSS/RTT Quando a conexão começa, aumenta a taxa exponencialmente até o primeiro evento de perda Resumo: taxa inicial baixa, mais cresce rapidamente (crescimento exponencial) 116

Os mecanismos: Partida lenta Quando a conexão começa, aumenta a taxa exponencialmente até que ocorra uma perda Dobra CongWin a cada RTT, através do incremento de CongWin, a cada ACK recebido RTT Algoritmo Partida Lenta inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR CongWin > threshold) Estação A Estação B um segme nto dois segm en tos quatro seg mentos tempo 117

Refinamento: TCP Reno Filosofia: Depois de 3 DupACKs: CongWin é reduzida a metade 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 Janela cresce linearmente transmitir alguns Mas depois de um evento de segmentos Ocorrência de timeout timeout: antes de 3 ACKs duplicados CongWin é reduzida a 1 é mais alarmante MSS; 118

Refinamento (mais) Q: Quando o crescimento deve mudar de exponencial para linear? A: Quando CongWin atinge 1/2 do seu valor antes do timeout. Implementação: Threshold variável Quando ocorre uma perda, faz-se Threshold = CongWin/2 119

Os mecanismos: Prevenção do Congestionamento prevenção congestionamento /* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faça partida lenta 1 1: TCP Reno pula partida lenta (recuperação rápida) depois de três ACKs duplicados 120

Resumo: Controle de Congestionamento Quando CongWin está abaixo do Threshold, o emissor está na fase de partida lenta, e a janela cresce exponencialmente Quando CongWin está acima do Threshold, o emissor está na fase de prevenção de congestionamento, 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. 121

Resumo: Princípios Controle fim-a-fim via retorno negativo Controle baseado em janela deslizante Inferido por ACK duplicado e temporizadores Aumento e redução do tamanho da janela controla a taxa de dados Aumento aditivo e redução multiplicativa Evita congestionamento sendo conservador Infere congestionamento pela perda ou atraso de pacotes Estima perda e atraso de pacotes usando temporizadores 122

Eqüidade TCP 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 TCP conexão 1 TCP conexão 2 Roteador gargalo capacidade R 123

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 Vazão da conexão 2 compartilhamento igual da banda perda: diminui janela por fator de 2 evitar congestionamento: aumento aditivo perda: diminui janela por fator de 2 evitar congestionamento: aumento aditivo Vazão da conexão 1 R 124

Eqüidade (mais) Eqüidade e UDP Aplic. Multimídia Eqüidade e conexões TCP paralelas geralmente não usam TCP Nada previne que aplic. abram várias conexões Não desejam que a taxa simultânceas entre os 2 seja reduzida pelo controle de hosts; congestionamento Geralmente usam UDP: audio/video a taxa constante, toleram perdas de pacotes Área de pesquisa: TCP friendly Browsers fazem isto Exemplo: enlace com taxa igual a R, com 9 conexões; Nova aplic. requer uma conexão TCP, recebe R/10 da taxa Nova aplic. requer 11 conexões 125 TCP, recebe R/2 da taxa

TCP: modelagem de latência P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido? Notação, suposições: Ignorando o congestionamento, a latência é influenciada por: Estabelecimento de conexão TCP retardo de transferência de dados Slow start 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 126

Janela de congestionamento de tamanho fixo (1) Primeiro caso: WS/R > RTT + S/R: ACK do primeiro segmento na janela chega antes de enviar todos dados na janela latência = 2RTT + O/R 127

Janela de congestionamento de tamanho fixo (2) Segundo caso: WS/R < RTT + S/R: aguarda ACK depois de enviar todos os dados na janela latência = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] 128

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 é: [ ] O S S Latência=2 RTT P RTT 2 P 1 R R R Onde: - P é o número de vezes TCP para no servidor: P=min{Q, K 1} - onde Q é o número de vezes que o servidor pararia se o objeto fosse de tamanho infinito. - e K é o número de janelas que cobrem o objeto. 129

TCP: modelagem de latência: Slow Start(2) Exemplo: O/S = 15 segmentos K = 4 janelas Q=2 P = min{k-1,q} = 2 in itia te T C P c o n n e c t io n re q u e s t o b je c t f ir s t w in d o w = S /R RTT s e c o n d w in d o w = 2 S /R Servidor para P=2 vezes th ir d w in d o w = 4 S /R Componentes da Latência: 2 RTT for connection estab and fo u r th w in d o w = 8 S /R request O/R to transmit object time server idles due to slow starto b j e c t c o m p le t e tr a n s m is s io n d e liv e r e d Servidor para: P = min{k-1,q} vezes tim e a t c lie n t tim e a t s e rv e r 130

TCP: modelagem de latência: (3) S + RTT =tempo quando o servidor inicia o envio do segmento R até quando o servidor recebe reconhecimento 2k 1 S = tempo para enviar a k-ésima janela R inicia conexão TCP pede objeto + S tempo de bloqueio após a k 1 S + RTT 2 = k-ésima janela R R RTT primeira janela = S/R segunda janela = 2S/R terceira janela = 4S/R P O latencia = + 2 RTT + TempoBloqueio p R p =1 P = O + 2 RTT + [ S + RTT 2k 1 S ] R R k =1 R = O + 2 RTT + P[ RTT + S ] (2P 1) S R R R quarta janela = 8S/R objeto entregue tempo no cliente transmissão completa 131 tempo no servidor

Modelagem HTTP Assuma que páginas Web consistem de: 1 página HTML base (com tamanho igual a O bits) M imagens (cada uma com O bits) HTTP não-persistente : M+1 conexões TCP em série Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma dos períodos de inatividade HTTP persistente : 2 RTT para requisitar e receber o arquivo base HTML 1 RTT para requisitar e receber M imagens Tempo de resposta = (M+1)O/R + 3RTT + soma dos períodos de inatividade HTTP não-persistente com X conexões paralelas 1 TCP conexão para o arquivo base M/X conjuntos de conexões paralelas para as imagens Tempo de resposta = (M+1)O/R + (M/X + 1)2RTT + soma dos períodos de inatividade 132

HTTP: tempo de resposta (em segundos) RTT = 100 msec, O = 5 Kbytes, M=10 e X=5 20 18 16 14 12 10 8 6 4 2 0 não-persistente persistente paralela nãopersistente 28 100 1 10 Kbps Kbps Mbps Mbps 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 a133 conexões paralelas

HTTP: tempo de resposta (em segundos) RTT =1 seg, O = 5 Kbytes, M=10 e X=5 70 60 50 40 30 20 10 0 não-persistente persistente paralela nãopersistente 28 100 1 10 Kbps Kbps Mbps Mbps Para valores grandes de RTT, o tempo de resposta é dominado pelo atraso do estabelecimento da conexão e slow start. Conexões persistentes possibilita 134 uma melhora importante para a redução do atraso: particularmente em redes com grandes valores de atrasoxbanda (delay bandwidth)

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 135