Redes de Computadores e a Internet Magnos Martinello Universidade Federal do Espírito Santo - UFES Departamento de Informática - DI Laboratório de Pesquisas em Redes Multimidia - LPRM 2011
Camada de Transporte Nossos objetivos: Entender os princípios de base nos serviços da camada de transporte: multiplexação/demulti plexação Transferência confiável de dados Controle de congestionamento Aprender sobre os protocolos de transporte na Internet: UDP: transporte não orientado à conexão TCP: transporte orientado a conexão Controle de congestionamento TCP
Camada de Transporte 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 Transporte não orientado à conexão: UDP 3.4 Princípios de transferência confiável de dados 3.5 Transporte orientado à conexão: TCP Estrutura do segmento Transferência confiável de dados Controle de fluxo Gerenciamento de conexão 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP
Protocolos e serviços de transporte Fornecem comunicação lógica entre processos de aplicação em diferentes hospedeiros Os protocolos de transporte são executados nos sistemas finais Lado emissor: quebra as mensagens da aplicação em segmentos e envia para a camada de rede Lado receptor: remonta os segmentos em mensagens e passa para a camada de aplicação Há mais de um protocolo de transporte disponível para as aplicações Internet: TCP e UDP application transport network data link physical logical end-end transport application transport network data link physical
Camada de Transporte vs. Camada de Rede Camada de rede: comunicação lógica entre os hospedeiros Camada de transporte: comunicação lógica entre os processos Depende dos serviços da camada de rede Analogia com uma casa familiar: 12 crianças enviam cartas para 12 crianças Processos = crianças Mensagens da aplicação = cartas nos envelopes Hospedeiros = casas Protocolo de transporte = Anna e Bill Protocolo da camada de rede = serviço postal
Protocolos da camada de transporte na Internet Confiável, garante ordem de entrega (TCP) Controle de congestionamento Controle de fluxo Orientado à conexão Não confiável, sem ordem de entrega: UDP Extensão do melhor esforço do IP Serviços não disponíveis: Garantia a atrasos Garantia de banda application transport network data link physical network data link physical logical end-end transport network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical
Camada de Transporte 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 Transporte não orientado à conexão: UDP 3.4 Princípios de transferência confiável de dados 3.5 Transporte orientado à conexão: TCP Estrutura do segmento Transferência confiável de dados Controle de fluxo Gerenciamento de conexão 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP
Multiplexação e Demultiplexação Demultiplexação no hospedeiro receptor: entrega os segmentos recebidos ao socket correto Multiplexação no hospedeiro emissor: coleta dados de múltiplos sockets, envelopa os dados com cabeçalho (usado depois para demultiplexação) 8
Como funciona a demultiplexação Computador recebe datagramas IP Cada datagrama possui endereço IP de origem e IP de destino Cada datagrama carrega 1 segmento da camada de transporte Cada segmento possui números de porta de origem e destino (lembre-se: números de porta bem conhecidos para aplicações específicas) O hospedeiro usa endereços IP e números de porta para direcionar o segmento ao socket apropriado 9
Demultiplexação não orientada a conexão Cria sockets com números de porta: DatagramSocket mysocket1 = new DatagramSocket(99111); DatagramSocket mysocket2 = new DatagramSocket(99222); Socket UDP identificado por dois valores: (endereço IP de destino, número da porta de destino) Quando o hospedeiro recebe o segmento UDP: Verifica o número da porta de destino no segmento Direciona o segmento UDP para o socket com este número de porta 10
Demultiplexação não orientada a conexão DatagramSocket serversocket = new DatagramSocket(6428); P2 P3 P1P1 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 SP: 5775 cliente IP: A DP: 6428 servidor IP: C DP: 6428 cliente IP: B SP fornece o endereço retorno 11
Demultiplexação orientada a conexão Socket TCP identificado por 4 valores: Endereço IP de origem End. porta de origem Endereço IP de destino End. porta de destino Hospedeiro receptor usa os quatro valores para direcionar o segmento ao socket apropriado Hospedeiro servidor pode suportar vários sockets TCP simultâneos: Cada socket é identificado pelos seus próprios 4 valores Servidores Web possuem sockets diferentes para cada cliente conectado HTTP não persistente terá um socket diferente para cada requisição 12
Demultiplexação orientada a conexão P1 P4 P5 P6 P2 P1P3 SP: 5775 DP: 80 S-IP: B D-IP: C SP: 9157 SP: 9157 cliente IP: A DP: 80 S-IP: A D-IP: C servidor IP: C DP: 80 S-IP: B D-IP: C cliente IP: B 13
Demux orientada à conexão servidor Web threaded Demultiplexação orientada a conexão com threads P1 P4 P2 P1P3 SP: 5775 DP: 80 S-IP: B D-IP: C cliente IP: A SP: 9157 DP: 80 S-IP: A D-IP: C servidor IP: C SP: 9157 DP: 80 S-IP: B D-IP: C cliente IP: B 14
Camada de transporte 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 Transporte não orientado à conexão: UDP 3.4 Princípios de transferência confiável de dados 3.5 Transporte orientado à conexão: TCP Estrutura do segmento Transferência confiável de dados Controle de fluxo Gerenciamento de conexão 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP 15
Transporte não orientado a conexão: UDP RFC 768 Protocolo de transporte da Internet sem gorduras Serviço best effort, segmentos UDP podem ser: Perdidos Entregues fora de ordem para a aplicação Sem conexão: Não há apresentação entre o UDP transmissor e o receptor Cada segmento UDP é tratado de forma independente dos outros Por que existe o UDP? Não há estabelecimento de conexão (que pode trazer atrasos) Simples: não há estado de conexão nem no transmissor, nem no receptor Cabeçalho de segmento reduzido Não há controle de congestionamento: UDP pode enviar segmentos tão rápido quanto desejado (e possível) 16
Um pouco mais sobre UDP Muito usado por aplicações de multimídia contínua (streaming) Tolerantes à perda Sensíveis à taxa Outros usos do UDP (por quê?): DNS SNMP Transferência confiável sobre UDP: acrescentar confiabilidade na camada de aplicação Recuperação de erro específica de cada aplicação O campo length tem um limite teórico de 65,535 bytes (8 byte header + 65,527 bytes of data) para um segmento UDP. O limite prático é de 65,507 bytes (65,535 8 byte UDP header 20 byte IP header) source port # dest port # length 32 bits Application data (message) UDP segment format 17 checksum
UDP checksum Objetivo: detectar erros (ex.: bits trocados) no segmento transmitido Transmissor: Trata o conteúdo do segmento como seqüência de inteiros de 16 bits Checksum: soma (complemento de 1 da soma) do conteúdo do segmento Transmissor coloca o valor do checksum no campo de checksum do UDP Receptor: Computa o checksum do segmento recebido Verifica se o checksum calculado é igual ao valor do campo checksum: NÃO - erro detectado SIM - não há erros. 18
Exemplo: Internet checksum Exemplo: UDP checksum Note que: Ao se adicionar números, um vai um do bit mais significativo deve ser acrescentado ao resultado A soma inclui o próprio cabeçalho UDP e seus dados Exemplo: adicione dois inteiros de 16 bits 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 Checksum = 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Complemento de 1 da soma 19
Camada de transporte 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 Transporte não orientado à conexão: UDP 3.4 Princípios de transferência confiável de dados 3.5 Transporte orientado à conexão: TCP Estrutura do segmento Transferência confiável de dados Controle de fluxo Gerenciamento de conexão 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP 20
Princípios de transferência confiável de dados importante na aplicação, transporte e nas camadas de enlace Lista dos 10 tópicos mais importante em redes! Características de um canal não-confiável determinam a complexidade do protolo de tranferência confiável de dados (rdt) 21
Princípios de transferência confiável de dados 22
Princípios de transferência confiável de dados 23
Transferência Princípios de confiável: transferência o ponto de partida confiável de dados rdt_send(): chamada da camada superior, (ex., pela aplicação). Passa dados para entregar à camada superior receptora deliver_data(): chamada pela entidade de transporte para entregar dados para cima lado transmissor lado receptor udt_send(): chamada pela entidade de transporte, para transferir pacotes para o receptor sobre o canal não confiável rdt_rcv(): chamada quando o pacote chega ao lado receptor do canal 24
Princípios de transferência confiável de dados 25
Transferência confiável de dados Proposta dividida em etapas: Desenvolver incrementalmente o transmissor e o receptor de um protocolo confiável de transferência de dados (rdt) Considerar apenas transferências de dados unidirecionais Mas informação de controle deve fluir em ambas as direções! Usar máquinas de estados finitos (FSM) para especificar o protocolo transmissor e o receptor estado: quando o sistema estiver no estado, o próximo estado é determinado unicamente pelo próximo evento estado 1 evento causando transição de estados ações tomadas na transição de estado evento ações estado 2 26
Canal perfeitamente confiável Canal de transmissão perfeitamente confiável Sem erros nos bits Sem perda de pacotes FSMs separadas para transmissor e receptor: Transmissor envia dados para o canal subjacente Receptor lê os dados do canal subjacente Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) emissor receptor 27
Canal com erros de bits Canal subjacente pode trocar valores dos bits num pacote Checksum para detectar erros de bits A questão é: como recuperar esses erros? Reconhecimentos (ACKs): receptor avisa explicitamente ao transmissor que o pacote foi recebido corretamente Reconhecimentos negativos (NAKs): receptor avisa explicitamente ao transmissor que o pacote tem erros Transmissor reenvia o pacote quando da recepção de um NAK Novos mecanismos no rdt2.0 (além do rdt1.0): Detecção de erros Retorno do receptor: mensagens de controle (ACK, NAK) Retransmissão Esta classe de Protocolos baseados em retransmissão são conhecidos como PROTOCOLOS ARQ (Automatic Repeat request) 28
RDT2.0: Especificação FSM rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Λ sender Wait for ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) receiver rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) 29
rdt2.0: operação sem erro rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Λ Wait for ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) 30
rdt2.0: cenário com erro rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) Wait for call from above rdt_rcv(rcvpkt) && isack(rcvpkt) Λ Wait for ACK or NAK rdt_rcv(rcvpkt) && isnak(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(nak) Wait for call from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ack) 31
RDT 2.0 tem um problema fatal O que acontece se o ACK/NAK é corrompido? Simplesmente reenviar o pacote de dados corrente Transmissor não sabe o que aconteceu no receptor! Não pode apenas retransmitir -> possível duplicata Tratando duplicatas: Transmissor acrescenta número de seqüência em cada pacote Transmissor reenvia o último pacote se ACK/NAK for corrompido Receptor descarta (não passa para a aplicação) pacotes duplicados Para este caso, um número de sequencia de 1 bit é suficiente (o número de sequencia é o mesmo ou é um novo pacote) stop and wait Emissor envia um pacote, então espera pela resposta do receptor 32
rdt2.1: emissor trata com ACK/NAKs corrompidos rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) Wait for call 0 from above Wait for ACK or NAK 1 rdt_send(data) Wait for ACK or NAK 0 Wait for call 1 from above rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Λ 33
rdt2.1: receptor trata com ACK/NAKs corrompidos rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) udt_send(sndpkt) 34
Discussão no RDT 2.1 Transmissor: Adiciona número de seqüência ao pacote Dois números (0 e 1) bastam. Por quê? Deve verificar se os ACK/NAK recebidos estão corrompidos Duas vezes o número de estados O estado deve lembrar se o pacote corrente tem número de seqüência 0 ou 1 Receptor: Deve verificar se o pacote recebido é duplicado Estado indica se o pacote 0 ou 1 é esperado Nota: receptor pode não saber se seu último ACK/NAK foi recebido pelo transmissor 35
Protocolo RDT 2.2 sem NAK Mesma funcionalidade do rdt2.1, usando somente ACKs Em vez de enviar NAK, o receptor envia ACK para o último pacote recebido sem erro Receptor deve incluir explicitamente o número de seqüência do pacote sendo reconhecido ACKs duplicados no transmissor resultam na mesma ação do NAK: retransmissão do pacote corrente 36
RDT2.2: Fragments do emissor e receptor rdt_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) udt_send(sndpkt) rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) Wait for call 0 from above Wait for 0 from below Wait for ACK 0 sender FSM fragment receiver FSM fragment rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Λ rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) udt_send(sndpkt) 37
RDT 3.0: Canais com erros e perdas Nova hipótese: canal de transmissão pode também perder pacotes (dados ou ACKs) Checksum, números de seqüência, ACKs, retransmissões ajudam, mas não são suficientes Abordagem: transmissor espera um tempo razoável pelo ACK Retransmite se nenhum ACK for recebido nesse tempo Se o pacote (ou ACK) estiver apenas atrasado (não perdido): Retransmissão será duplicata, mas os números de seqüência já tratam com isso Receptor deve especificar o número de seqüência do pacote sendo reconhecido Exige um temporizador decrescente 38
RDT 3.0 em ação 39
RDT 3.0 em ação 40
Desempenho do protocolo RDT3.0 rdt3.0 funciana bem, mas o desempenho... exemplo: enlace de 1 Gbps, 15 ms atraso de prop. e-e, 1KB pacote: Ttransmissão = L (packet length in bits) 8kb/pkt = R (taxa de transmissão, bps) 10**9 b/sec = 8 microsec U emissor : utilização fração do tempo que o emissor fica ocupado transmitindo 1 pacote de 1KB cada 30 msec -> 33kB/sec de vazão sobre um enlace de 1 Gbps Protocolo de rede limita o uso dos recursos físicos! 41
rdt3.0: operação do stop-and-wait first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R sender receiver RTT first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R U sender = L / R RTT + L / R =.008 30.008 = 0.00027 microsec 42
Protocolos com paralelismo Paralelismo (Pipelining): permite múltiplos pacotes em-trânsito ainda para ser reconhecidos Arranjo dos números de sequência deve ser aumentado Buferização no emissor e/ou no receptor Duas formas genéricas de protocolos com paralelismo: go-back-n (Volta N), selective repeat (repetição seletiva) 43
Paralelismo: aumenta a utilização first packet bit transmitted, t = 0 last bit transmitted, t = L / R sender receiver RTT ACK arrives, send next packet, t = RTT + L / R first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Aumenta a utilização por um fator de 3 U sender = 3 * L / R RTT + L / R =.024 30.008 = 0.0008 microsecon 44
Emissor: Go-Back-N Número de sequência de k-bits no cabeçalho do pacote janela de até N pacotes consecutivos não reconhecidos ACK(n): Reconhece todos os pacotes até o número de sequência n inclusive ACK cumulativo Pode receber ACKs duplicado Timer para cada pacote em trânsito timeout(i): retransmite pacote i e todos os pacotes com número de seqüência maior que estejam dentro da janela 45
Go-Back N em ação 46
Ver applet de simulação http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/go-back-n/index.html Se k for a quantidade bits no campo de número de sequência do pacote, então a faixa de número de sequência é de [0, 2^k - 1]. O que acontece com Go-Back-N, quando os pacotes no inicio da janela são perdidos? 47
Repetição Seletiva receptor reconhece individualmente todos os pacotes recebidos corretamente Armazena em buffer os pacotes para entregar em ordem para a camada superior Emissor reenvia somente pacotes para os quais o ACK não foi recebido Temporizador no emissor para cada pacote não reconhecido Janela do emissor N números de sequência consecutivos Novamente o número de sequência limita o envio de pacotes não reconhecidos 48
Repetição seletiva: janelas do emissor e receptor 49
sender Dados da camada acima: Se o próximo número de sequência estiver disponível, enviar pacote timeout(n): Repetição Seletiva Reenviar pacote n, reiniciar timer ACK(n) em [sendbase,sendbase+n]: Marcar pacote n como recebido Se n é o menor pacote não reconhecido, avançar a janela base para o próximo número de seq não reconhecido receiver pkt n em [rcvbase, rcvbase+n-1] enviar ACK(n) Fora de ordem: buffer Em-ordem: entregar, avançar janela para o próximo pkt não ainda reconhecido pkt n em [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignorar 50
SR em ação 51
Dilema do SR Exemplo: número de seq: 0, 1, 2, 3 Tamanho da janela=3 Receptor não vê diferença entre os dois cenários! Incorretamente entrega dados duplicados como novos no cenário (a) Q: qual é a relação entre o número de sequência e o tamanho da janela? 52
Suponha que o menor número de sequencia que o receptor está esperando é pelo pacote com número m. SR Neste caso, a janela do receptor é [m,m+w-1] e ele recebeu e reconheceu o pacote m-1 e os pacotes w-1 anteriores, i.e., onde w é o tamanho da janela. Se nenhum dos w ACKs foi recebido pelo emissor, então ACK mensagens com valores [m-w,m-1] podem ainda estar sendo propagados de volta. Se nenhum ACK com estes números de sequencia foi recebido pelo emissor, então a janela do emissor é [m-w,m-1] Assim, o menor ponto na janela do emissor é m-w, e o maior ponto na janela do receptor é m+w-1. Para garantir que não haja entrelaçamento nos numeros de sequencia, ou seja, o maior ponto da janela do receptor não entrelace com o menor do emissor, o espaço do número de sequencia deve ser suficiente para acomodar 2w números de sequência. Ou seja, o espaço do número de sequência deve ser ao menos duas vezes o tamanho da janela k >= 2w 53