Redes de Computadores

Transcrição

1 Departamento de Informática UFPE Redes de Computadores Nível de Transporte Visão Geral do TCP/IP Telnet FTP... DNS RPC... Aplicação Usuário TCP UDP Transporte Kernel ICMP IP IGMP Rede ARP Hardware Interface RARP Enlace 1

2 Nível de Transporte Oferece um serviço eficiente e confiável com bom custo/beneficio Usuários de nível de transporte são processos de aplicação no host Entidade de transporte: pode ser no kernel do SO, um processo separado, biblioteca, NIC, etc. Tipos de serviços de transporte: orientados ou não a conexão Nível de transporte => usuário querendo controlar a conexão Oferece uma interface única para diferentes subredes => portabilidade das aplicações Exemplo de Primitivas de Transporte (Sockets) 2

3 Estabelecimento de Conexões Perda e duplicação de pacotes de pedidos de conexões -problema de duplicatas atrasadas Soluções Uso de endereços de transporte temporários (throw away) => inviabiliza o uso de um servidor de processos Associar identificadores com as conexões (numero de seqüência) => entidades de transporte devem manter informações sobre as conexões (problemas de falhas e perda de memória) Mecanismos para retirar da rede pacotes velhos projeto limitado da subrede uso de contadores (hop counter) nos pacotes uso de informação de tempo nos pacotes (timestamps) T: múltiplo do tempo de vida de um pacote ou reconhecimento Solução de Tomlinson: cada host tem um relógio com numero de bits >= numero de seqüência, o relógio continue funcionando ate no caso de falha do host Os primeiros k bits do relógio representem o numero de seqüência de um TPDU O Three-Way Handshake Problema dos dois exércitos 3

4 Alocação de Buffers Alocação de Buffers 4

5 Recuperação de Falhas Protocolos de Transporte da Internet Transmission Control Protocol orientado a conexão (RFC 793, 1122 e 1323) oferece um serviço fim-a-fim confiável sobre subredes com diferentes (velocidades, topologias, atrasos, tamanho de pacotes, etc.) executa no host na forma de um processo de usuário ou no kernel divisão dos mensagens em pacotes de ate 64KB (normalmente 1500 bytes) 5

6 Modelo de Serviço do TCP Cada entidade de transporte cria um socket com endereço IP + numero de porta (16 bits) Mais de uma conexão pode terminar no mesmo socket Identificação de uma conexão através da dupla (socket1, socket2) Números de portas ate 256 são conhecidos e reservados (ftp-21, telnet 23) Conexões TCP são full duplex e ponto a ponto TCP não suporta comunicação muticast ou broadcast TCP e baseado em um stream de bytes (não é baseado em mensagens) Uso de um flag para indicar dados urgentes (a entidade para de acumular dados para mandar o mensagem) CRC do cabeçalho é baseado no complemento de 1 => resultado deve ser 0 Segmentos pode ser sem dados (ACKs, mensagens de controle) Default payload = 536 bytes + 20 do cabeçalho do segmento = 556 bytes O Protocolo TCP O Header TCP 16-bit source port number 16-bit destination port number 32-bit sequence number 32-bit acknowledgment number 4-bit hdr length 6-bit reserved U R G A C K P S H R S T S Y N F I N 16-bit window size 16-bit TCP checksum 16-bit urgent pointer options data 6

7 O Protocolo TCP Estabelecimento de Conexão Protocolo Passo 1: o cliente envia um segmento SYN especificando a porta do servidor ao qual deseja se conectar e seu número de sequência inicial Passo 2: o servidor responde enviando outro segmento SYN com o ACK do segmento recebido e o seu próprio número de sequência Passo 3: o cliente retorna um ACK e a conexão se estabelece O tamanho máximo de segmento (MSS) que cada lado se propõe a aceitar também é definido no momento do estabelecimento da conexão Pode acontecer o problema do half open quando um dos hosts é desligado sem shutdown ou trava O Protocolo TCP-Estabelecimento de Conexão (cont.) Cliente Servidor Cliente SYN (SEQ = x) SYN (SEQ = x) SYN (SEQ = y, ACK = x + 1) Tempo SYN (SEQ = y) SYN (SEQ = y, ACK = x + 1) Servidor SYN (SEQ = x + 1, ACK = y + 1) SYN (SEQ = x, ACK = y + 1) 7

8 O Protocolo TCP Término de Conexão Cada direção da conexão é encerrada independentemente Protocolo Cliente FIN Servidor Passo 1: o cliente envia um segmento FIN Passo 2: o servidor retorna um FIN e um ACK para o cliente Passo 3: o cliente envia um ACK e a conexão se encerra É possível efetuar um half close, mantendo-se apenas uma conexão simplex ACK FIN ACK Tempo Gerenciamento de buffers no TCP 8

9 Protocolos de Transporte da Internet (cont.) Uso de uma tamanho de janela de 16 bits => problema em linhas de grande atraso (satélite ou transcontinental) RFC 1323 define um extensão ao tamanho da janela a ser 32 bits (suportado pelas implementações) RFC 1106 propõe o uso de uma repetição seletivo no lugar do go back n usando NAKs Gerenciamento de Conexões em TCP Estabelecimento de conexão TCP usando o Three-way handshake Na liberação de conexão (FIN), temporizadores são usados para evitar o problema dos exércitos Política de Transmissão em TCP O gerenciamento da janela TCP não é direitamente ligado aos reconhecimentos (ACKs) Quando o tamanho == 0, o transmissor pode enviar dados urgentes, ou um segmento de 1 byte pedindo ao receptor re-anunciar o próximo byte esperado (para evitar deadlock no caso da perda de um ACK!) Atrasar (de 500 msec) ACKs e updates das janelas para economizar na troca de pacotes 9

10 O Protocolo TCP - Tráfego Interativo Cada letra digitada gera um segmento: Telnet, Rlogin Muitos pacotes pequenos podem provocar congestionamento em redes lentas (WAN) O TCP tenta minimizar o número de pacotes trocados: Reconhecimentos (ACKs) atrasados Algoritmo Nagle Apenas um segmento pequeno pode ficar pendente (sem reconhecimento) a cada momento A taxa de envio dos pacotes se adequa a velocidade da rede Nem sempre é desejável. Ex: X Windows O Protocolo TCP - Tráfego constante FTP, SMTP Controle de fluxo é efetuado através do protocolo de janela deslizante ( Sliding Window Protocol ): O servidor (receptor) fica enviando o tamanho de sua janela de recepção (nº de bytes disponíveis no buffer de entrada) A janela de envio do cliente evolui da seguinte forma: a janela fecha quando segmentos são enviados e reconhecidos quando o servidor lê os dados recebidos liberando o buffer do TCP, este sinaliza a nova janela de recepção para o cliente, que abre sua janela de envio O cliente estabelece um persist timer para ficar inquirindo o servidor quanto ao tamanho de sua janela de recepção mesmo que ela esteja aparentemente fechada para evitar deadlocks O problema da Silly Window Sindrome (aplicação lendo 1 byte cada vez!) 10

11 O Protocolo TCP - Controle de Congestionamento Causas mais freqüentes Uma rede rápida (LAN) enviando dados por uma rede lenta (WAN) Um roteador com múltiplos fluxos de entrada extrapolando sua capacidade de saída O TCP assume que pacotes perdidos significam congestionamento O congestionamento procura ser evitado pelo TCP Cálculo dinâmico do RTO Algoritmo Slow Start Algoritmo de prevenção de congestionamento O Protocolo TCP - Controle de Congestionamento (cont.) Algoritmo Slow Start Controle de fluxo imposto pelo emissor de acordo com o congestionamento percebido Janela de congestionamento inicialmente com o tamanho de um segmento completo (MSS) O emissor envia a menor entre as quantidades permitidas pelas janelas de congestionamento e de envio (sinalizada pelo receptor) O tamanho da janela dobra a cada ACK recebido O timeout e retransmissão faz a janela voltar para o tamanho inicial 11

12 +, -,. / : ; + : < = > 4 5 < 4? : 5 O Protocolo TCP - Controle de Congestionamento (cont.) Algoritmo de prevenção de congestionamento Estabelece um limite para o crescimento exponencial da janela de congestionamento devido ao slow start A partir deste limite, a janela cresce de forma linear até o próximo timeout e retransmissão, quando o slow start recomeça. O limite passa então a ser a metade do tamanho da janela quando aconteceu o congestionamento O Protocolo TCP - Controle de Congestionamento (cont.) Resultado global Tamanho da janela de congestionamento Congestionamento Tempo! " # $ % # & ' ( ) ' * * ( 12

13 +, -,. / : ; + : < = > 4 5 < 4? : 5 UDP- User Datagram Protocol -Principais Características Camada de transporte (nível 4) Não confiável Utiliza o datagrama como unidade básica Consiste praticamente numa interface de acesso ao IP para as aplicações O Header UDP Pseudo-header 32-bit source IP address 32-bit destination IP address protocol length Header Source port Destination port UDP length UDP checksum! " # $ % # & ' ( ) ' * * ( 13

14 +, -,. / : ; + : < = > 4 5 < 4? : 5 Portas UDP Processos requerem portas UDP para transmissão e recepção de datagramas Sistemas que suportam multicast permitem que mais de um processo compartilhe a mesma porta Os servidores que usam UDP podem restringir o recebimento de datagramas a nível local e remoto Classes Originais de Serviço ATM! " # $ % # & ' ( ) ' * * ( 14

15 +, -,. / : ; + : < = > 4 5 < 4? : 5 Níveis ATM Protocolos ATM AAL - I363 AAL5 e semelhante a UDP (industria de computação) Nenhum dos protocolos AAL oferece transporte confiavel fim-a-fim Em ATM entrega rápida e muito mais importante que a entrega correta (serviços de vídeo, audio, etc.) Sem controle de erros, sem controle de fluxo, etc. Objetivo dos AALs: oferecer serviços adequados para diferentes aplicações: tempo real, taxa fixa de bits (CBR), orientação a conexão, etc. Classes C e D tem requisitos semelhantes => AAL ¾ Estrutura do AAL Subnível de convergência: framing e detecção de erros Subnível de segmentação e de remontagem (SAR)! " # $ % # & ' ( ) ' * * ( 15

16 +, -,. / : ; + : < = > 4 5 < 4? : 5 Protocolos ATM AAL - I363 (cont.) AAL 1 Trafego classe A (tempo real, CBR e orientado a conexão): audio e vídeo sem compressão Mínimo de atraso, jitter e sobrecarga o payload pode ser menus de 47 bytes O nível CS não define um protocolo mais o SAR define um AAL 2 Adequado para serviços VBR como vídeo com compressão O nível CS não define um protocolo mais o SAR define um Com CRC para detecção de erros Tamanho dos campos não definidos => não vai ser usado! AAL 3 / 4 Pode operar em dois modos (stream e mensagem), confiavel ou não Suporte para multiplexação (sobre um CV com o mesmo QoS) Tem ambos protocolos de CS e SAR Protocolos ATM AAL - I363 (cont.) AAL5 AAL 1-4 são ineficiente, complexos, dois subníveis (CS e SAR) etc. => industria de computação AAL 5 Simple Efficient Adaptation Layer SEAL Oferece diferentes tipos de serviços: confiavel com controle de fluxo não confiavel com a possibilidade de passar células com problemas de CRC a aplicação ou rejeitar Com suporte para unicast e multicast Suporte para modo mensagem e modo stream AAL5 não define um cabeçalho do subnível do CS, somente um trailer O SAR não define novos campos Uso de ALL 5 na Internet RFC 1483 e 1577 IP sobre ATM! " # $ % # & ' ( ) ' * * ( 16

17 +, -,. / : ; + : < = > 4 5 < 4? : 5 Observações Muitos ALLs com poucas diferenças AAL1 não é necessário, AAL2 é quebrado e AAL4 nunca foi terminado, AAL3 / 4 e ineficiente As classes A, B, C e D forram abandonadas O futuro com ALL 5 deve tem: números de seqüência um bit para a distinção entre dados e controle FIM!!! Obrigado! " # $ % # & ' ( ) ' * * ( 17