Interconexão e Transporte em Redes

1. Interconexão e Transporte em Redes Prof. Ricardo S. Casado

2. Transferência Confiável de Dados • É um processo que ocorre não só na camada de transporte mas também na camada de enlace (Swithes e Roteadores consequentemente); • Com um canal confiável nenhum dos dados é corrompido e nem perdido e todos são entregues na ordem em que foram enviados; • Porém a transferência confiável de dados é um problema de redes de computadores que se não for está entre os primeiros da lista.

3. CamadasModelo OSI

4. Transferência Confiável

5. Transferência confiável de Dados • É responsabilidade de um protocolo de transferência confiável de dados implementar essa abstração de serviço; • A tarefa é dificultada pelo fato de que a camada a baixo do protocolo de transferência pode não ser confiável; • Ex: O TCP é um protocolo de transferência confiável de dados que é implementado sobre uma camada de rede fim-a-fim não confiável (IP);

6. Pacote perdido

7. ACK Perdido

8. Protocolos de transferência confiável de dados com paralelismo • Vamos considerar um caso ideal de dois hospedeiros, um localizado na costa oeste e outro na costa leste do brasil. • O atraso de propagação de ida e volta à velocidade da luz, Tprop, entre esses dois sistemas finais é de aproximadamente 30 milissegundos. • Suponha que eles estejam conectados por um canal com capacidade de transmissão (R), de 1 gigabit (10^9 bits) por segundo. Para um tamanho de pacote (L) de 1 Kbyte (8 mil bits) por pacote, incluindo o campo de cabeçalho e também de dados.

9. Protocolos de transferência confiável de dados com paralelismo • O tempo necessário para realmente transmitir o pacote para o enlace de 1Gbps é: • Tprop = Velocidade da luz (fibra) • L = Tamanho do pacote • R = Capacidade de transmissão do canal

10. Paralelismo

11. Pare e espere

12. Paralelismo

13. Pare e espere • A figura 1 mostra que, com nosso protocolo pare e espere, se o remetente começar a enviar o pacote em t = 0, então em t = L/R = 8 microssegundos, o último bit entrará no canal do lado remetente. • O pacote então faz sua jornada de 15 milissegundos atravessando o país, com o último bit do pacote emergindo no destinatário em t = RTT/2 + L/R = 15,008 milissegundos.

14. Pare e espere • Supondo, para simplificar, que pacotes ACK sejam extremamente pequenos (para ignorarmos seu tempo de transmissão) e que o destinatário pode enviar um ACK logo que receber o último bit de um pacote de dados, o ACK emergirá de volta no remetente em t = RTT + L/R = 30,008 milissegundos, o remetente esteve enviando por apenas 0,008 milissegundos.

15. Pare e espere • Se definirmos a utilização do remetente (ou do canal) como a fração de tempo em que o remetente está realmente ocupado enviando bits para dentro do canal, analisando a 1 figura mostra que o protocolo pare e espere tem uma utilização do remetente Uremet bastante desanimadora.

16. Pare e espere • Portanto o remetente ficou ocupado apenas 2,7 centésimos de 1% do tempo. Visto de outra maneira ele só foi capaz de enviar 1.000 bytes em 30,008 milissegundos, uma vazão efetiva de apenas 267Kbps, mesmo estando disponível para envio um enlace de 1Gbps. • Imagine o desperdício e isso que desconsideramos o tempo de processamento das camadas inferiores nos sistemas finais e também o atraso de processamento e fila do roteadores.

17. Paralelismo • A solução para este problema de desempenho em particular é simples: em vez de operar em modo pare e espere, o remetente é autorizado a enviar vários pacotes sem esperar por reconhecimentos, como mostra a figura 2 (pipelining).

18. Pipelining

19. Retransmissão Cenário com perda do ACK Temporizaçãoprematura, ACKs cumulativos

20. Controle de Fluxo Controle de fluxo Transmissornãodeveesgotaros buffers de recepçãoenviando dados rápidodemais  lado receptor da conexão TCP possui um buffer de recepção:  Serviço de speed-matching: encontra a taxa de envioadequada à taxa de vazãodaaplicaçãoreceptora  Processos de aplicaçãopodem ser lentos paraler o buffer

21. Controle de Fluxo  Receptor informa a área disponível incluindo valorRcvWindownos segmentos • Transmissor limita os dados não confimados aoRcvWindow  Garantia contra overflow no buffer do receptor (suponha que o receptor TCP descarte segmentos fora de ordem)  Espaço disponível no buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

22. Gerenciamento de Conexão TCP TCP transmissor estabelece conexão com o receptor antes de trocar segmentos de dados  Inicializar variáveis:  Números de seqüência  Buffers, controle de fluxo(ex.RcvWindow)  Cliente: iniciador da conexão Socket clientSocket = new Socket(“hostname","port number");  Servidor: chamado pelo cliente Socket connectionSocket = welcomeSocket.accept(); Three way handshake: Passo 1: sistema final cliente envia TCP SYN ao servidor  Especifica número de seqüência inicial Passo 2: sistema final servidor que recebe o SYN, responde com segmento SYNACK  Reconhece o SYN recebido  Aloca buffers  Especifica o número de seqüência inicial do servidor Passo 3: o sistema final cliente reconhece o SYNACK

23. Gerenciamento de Conexão TCP Fechando uma conexão: cliente fecha o socket:clientSocket.close(); Passo 1: o cliente envia o segmento TCP FIN ao servidor Passo 2:servidor recebe FIN, responde com ACK. Fecha a conexão, envia FIN

24. GerenciamentodaConexão TCP Passo 3:cliente recebe FIN, responde com ACK.  Entra “espera temporizada” - vai responder com ACK a FINs recebidos Passo 4:servidor, recebe ACK. Conexão fechada Nota: com uma pequena modificação, pode-se manipular FINs simultâneos

25. GerenciamentodaConexão TCP Estados do cliente Estados do servidor