1 / 50

Capítulo 3: Camada de Transporte

Metas do capítulo: compreender os princípios atrás dos serviços da camada de transporte: multiplexação/ demultiplexação transferência confiável de dados controle de fluxo controle de congestionamento. Capítulo 3: Camada de Transporte.

suchin
Download Presentation

Capítulo 3: Camada de Transporte

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Metas do capítulo: compreender os princípios atrás dos serviços da camada de transporte: multiplexação/demultiplexação transferência confiável de dados controle de fluxo controle de congestionamento Capítulo 3: 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: Camada de Transporte

  2. 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 UDP: Transporte não orientado a conexão 3.4 Princípios da transferência confiável de dados 3.5 Transporte orientado a conexão: TCP transferência confiável controle de fluxo gerenciamento de conexões 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP Conteúdo do Capítulo 3 3: Camada de Transporte

  3. provê comunicação lógica entre processos de aplicação executando em hospedeiros diferentes protocolos de transporte executam em sistemas finais: 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 existem mais de um protocolo de transporte disponível para as aplicações Internet: TCP e UDP aplicação transporte rede enlace física aplicação transporte rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física transporte lógico fim a fim Serviços e protocolos de transporte 3: Camada de Transporte

  4. camada de rede: comunicação lógica entre hospedeiros camada de transporte: comunicação lógica entre processos depende de, estende serviços da camada de rede Analogia doméstica: 12 crianças enviando cartas para 12 crianças processos = crianças mensagens da apl. = cartas nos envelopes hospedeiros = casas protocolo de transporte = Ann e Bill protocolo da camada de rede = serviço postal Camadas deTransporte x rede 3: Camada de Transporte

  5. entrega confiável, ordenada (TCP) controle de congestionamento controle de fluxo estabelecimento de conexão (“setup”) entrega não confiável, não ordenada: UDP extensão sem “frescuras” do “melhor esforço” do IP serviços não disponíveis: garantias de atraso garantias de largura de banda aplicação transporte rede enlace física aplicação transporte rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física rede enlace física transporte lógico fim a fim Protocolos da camada de transporte Internet 3: Camada de Transporte

  6. 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 UDP: Transporte não orientado a conexão 3.4 Princípios da transferência confiável de dados 3.5 Transporte orientado a conexão: TCP transferência confiável controle de fluxo gerenciamento de conexões 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP Conteúdo do Capítulo 3 3: Camada de Transporte

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

  8. 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) Como funciona a demultiplexação formato de segmento TCP/UDP 3: Camada de Transporte

  9. Crie sockets com números de porta: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); socket UDP identificado pela dupla: (end IP dest, no. da porta destino) Quando host recebe segmento UDP: verifica no. da porta de destino no segmento 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 Demultiplexação sem Conexões 3: Camada de Transporte

  10. P3 P2 P1 P1 SP: 9157 cliente IP: A DP: 6428 Cliente IP:B servidor IP: C SP: 5775 SP: 6428 SP: 6428 DP: 6428 DP: 9157 DP: 5775 Demultiplexação sem Conexões (cont) DatagramSocket serverSocket = new DatagramSocket(6428); SP (source port) provê “endereço de retorno” 3: Camada de Transporte

  11. 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 Demultiplexação Orientada a Conexões 3: Camada de Transporte

  12. SP: 9157 SP: 5775 P1 P1 P2 P4 P3 P6 P5 cliente IP: A DP: 80 DP: 80 Demultiplexação Orientada a Conexões (cont) S-IP: B D-IP:C SP: 9157 DP: 80 Cliente IP:B servidor IP: C S-IP: A S-IP: B D-IP:C D-IP:C 3: Camada de Transporte

  13. SP: 9157 SP: 5775 P1 P1 P2 P3 cliente IP: A DP: 80 DP: 80 Demultiplexação Orientada a Conexões: Servidor Web com Threads P4 S-IP: B D-IP:C SP: 9157 DP: 80 Cliente IP:B servidor IP: C S-IP: A S-IP: B D-IP:C D-IP:C 3: Camada de Transporte

  14. 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 UDP: Transporte não orientado a conexão 3.4 Princípios da transferência confiável de dados 3.5 Transporte orientado a conexão: TCP transferência confiável controle de fluxo gerenciamento de conexões 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP Conteúdo do Capítulo 3 3: Camada de Transporte

  15. 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 UDP: User Datagram Protocol [RFC 768] 3: Camada de Transporte

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

  17. 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 …. Checksum UDP Meta:detectar “erro” (e.g., bits invertidos) no segmento transmitido 3: Camada de Transporte

  18. 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 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 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 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 transbordo soma checksum 3: Camada de Transporte

  19. 3.1 Serviços da camada de transporte 3.2 Multiplexação e demultiplexação 3.3 UDP: Transporte não orientado a conexão 3.4 Princípios da transferência confiável de dados 3.5 Transporte orientado a conexão: TCP transferência confiável controle de fluxo gerenciamento de conexões 3.6 Princípios de controle de congestionamento 3.7 Controle de congestionamento do TCP Conteúdo do Capítulo 3 3: Camada de Transporte

  20. 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) Princípios de Transferência confiável de dados (rdt) 3: Camada de Transporte

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

  22. Iremos: desenvolver incrementalmente os lados remetente, receptor do protocolo RDT considerar apenas fluxo unidirecional de dados mas info de controle flui em ambos os sentidos! Usar máquinas de estados finitos (FSM) p/ especificar remetente, receptor evento estado 1 estado 2 ações Transferência confiável de dados (rdt): como começar evento causador da transição de estado ações executadas ao mudar de estado estado: neste “estado” o próximo estado é determinado unicamente pelo próximo evento 3: Camada de Transporte

  23. canal subjacente perfeitamente 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 Rdt1.0: transferência confiável usando um canal confiável rdt_send(data) rdt_rcv(packet) Wait for call from below Wait for call from above packet = make_pkt(data) udt_send(packet) transmissor receptor 3: Camada de Transporte

  24. canal subjacente pode inverter bits no pacote lembre-se: checksum UDP pode detectar erros de bits a questão: como recuperar dos erros? reconhecimentos (ACKs): receptor avisa explicitamente ao remetente que pacote chegou bem reconhecimentos negativos (NAKs): receptor avisa explicitamente ao remetente que pacote tinha erros remetente retransmite pacote ao receber um NAK cenários humanos usando ACKs, NAKs? novos mecanismos em rdt2.0 (em relação ao rdt1.0): detecção de erros realimentação pelo receptor: msgs de controle (ACK,NAK) receptor->remetente Rdt2.0: canal com erros de bits 3: Camada de Transporte

  25. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt2.0: especificação da FSM rdt_send(data) receptor snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) L transmissor rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 3: Camada de Transporte

  26. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) rdt2.0: operação sem erros rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 3: Camada de Transporte

  27. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) rdt2.0: cenário com erros rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 3: Camada de Transporte

  28. O que acontece se ACK/NAK com erro? Remetente não sabe o que se 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? retransmitir, mas pode causar retransmissão de pacote recebido certo! Lidando c/ duplicação: remetente inclui número de seqüência p/ cada pacote remetente retransmite pacote atual se ACK/NAK recebido com erro receptor descarta (não entrega) pacote duplicado pára e espera rdt2.0 tem uma falha fatal! Remetente envia um pacote, e então aguarda resposta do receptor 3: Camada de Transporte

  29. Wait for ACK or NAK 0 Wait for call 1 from above Wait for ACK or NAK 1 rdt2.1: remetente, trata ACK/NAKs c/ erro rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) Wait for call 0 from above udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt) 3: Camada de Transporte

  30. Wait for 0 from below Wait for 1 from below rdt2.1: receptor, trata ACK/NAKs com erro rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) 3: Camada de Transporte

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

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

  33. Wait for ACK 0 Wait for call 0 from above Wait for 0 from below rdt2.2: fragmentos do transmissor e receptor rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) udt_send(sndpkt) Fragmento da FSM do transmissor rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) L Fragmento da FSM do receptor udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) 3: Camada de Transporte

  34. Nova suposição: canal subjacente também pode perder pacotes (dados ou ACKs) checksum, no. de seq., ACKs, retransmissões podem ajudar, mas não serão suficientes P: como lidar com perdas? remetente espera até ter certeza que se perdeu pacote ou ACK, e então retransmite eca!: desvantagens? Abordagem: remetente aguarda um tempo “razoável” pelo ACK retransmite se nenhum ACK for recebido neste intervalo se pacote (ou ACK) apenas atrasado (e não perdido): retransmissão será duplicada, mas uso de no. de seq. já cuida disto receptor deve especificar no. de seq do pacote sendo reconhecido requer temporizador rdt3.0: canais com erros e perdas 3: Camada de Transporte

  35. Wait for ACK0 Wait for ACK1 Wait for call 1 from above Wait for call 0from above rdt3.0: remetente rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer L rdt_rcv(rcvpkt) L timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L 3: Camada de Transporte

  36. rdt3.0 em ação 3: Camada de Transporte

  37. rdt3.0 em ação 3: Camada de Transporte

  38. 8kb/pacote T = = 8 microseg transmitir 10**9 b/seg Desempenho de rdt3.0 • rdt3.0 funciona, porém seu desempenho é muito ruim • exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de 1KB: • pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps • protocolo limita uso dos recursos físicos! 3: Camada de Transporte

  39. rdt3.0: stop-and-wait operation transmissor receptor transm. do 1º bit do pacote, t = 0 tx último bit do pacote, t = L / R chegada do 1º bit do pacote RTT chegada do último bit, envia ACK chegada do ACK, envia próximo pacote, t = RTT + L / R 3: Camada de Transporte

  40. Paralelismo (pipelining): remetente admite múltiplos pacotes “em trânsito”, ainda não reconhecidos faixa de números de seqüência deve ser aumentada buffers no remetente e/ou no receptor Duas formas genéricas de protocolos com paralelismo: Go-back-N, retransmissão seletiva Protocolos “com paralelismo” (pipelined) 3: Camada de Transporte

  41. Paralelismo: maior utilização transmissor receptor transm. do 1º bit do pacote, t = 0 tx do último bit, t = L / R chegada do primeiro bit RTT chegada do último bit, envia ACK cheg. do último bit do 2o pct., envia ACK cheg. do último bit do 3o pct., envia ACK chegada do ACK, envia próximo pacote, t = RTT + L / R Aumenta a utilização por um fator de 3! 3: Camada de Transporte

  42. Remetente: no. de seq. de k-bits no cabeçalho do pacote admite “janela” de até N pacotes consecutivos não reconhecidos Go-back-N (GBN) • ACK(n): reconhece todos pacotes, até e inclusive no. de seq n - “ACK cumulativo” • pode receber ACKs duplicados (veja receptor) • temporizador para cada pacote em trânsito • timeout(n): retransmite pacote n e todos os pacotes com no. de seq maiores na janela 3: Camada de Transporte

  43. GBN: FSM estendida do remetente 3: Camada de Transporte

  44. 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 expectedseqnum=expectedseqnum+1 GBN: FSM estendida do receptor 3: Camada de Transporte

  45. GBNem ação 3: Camada de Transporte

  46. receptor reconhece individualmente todos os pacotes recebidos corretamente armazena pacotes no buffer, conforme necessário, para posterior entrega em-ordem à camada superior remetente apenas re-envia pacotes para os quais ACK não recebido temporizador de remetente para cada pacote sem ACK janela do remetente N nos. de seq consecutivos outra vez limita nos. de seq de pacotes enviados, mas ainda não reconhecidos Retransmissão seletiva 3: Camada de Transporte

  47. Retransmissão seletiva: janelas de remetente, receptor 3: Camada de Transporte

  48. 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 remetente Retransmissão seletiva 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 3: Camada de Transporte

  49. Retransmissão seletiva em ação 3: Camada de Transporte

  50. Exemplo: nos. de seq : 0, 1, 2, 3 tam. de janela =3 receptor não vê diferença entre os dois cenários! incorretamente passa dados duplicados como novos em (a) Q: qual a relação entre tamanho de no. de seq e tamanho de janela? Retransmissão seletiva: dilema 3: Camada de Transporte

More Related