Protocolos de Transporte Histórico V1.0, Paula Viana, 1999 V2.0, Paula Viana, 2004 v2.1, Paula Viana, 2005 v2.2, Paula Viana, 2006 v3.0, Miguel Leitão, 2007 v3.1, Miguel Leitão, 2010 V3.2, Miguel Leitão, 2012 V3.3, Miguel Leitão, 2017 Modelo TCP/IP SMPT DNS FTP... Aplicação TCP UDP Transporte ICMP IP Arp/Rarp Rede Ethernet Token R. SATNET... Físico+DLL 1
Protocolos de Transporte na Internet TCP - Transmission Control Protocol comunicação fiável orientada às ligações (connection oriented) garante entregas sem erro implementa controlo de fluxo e de congestionamento (mecanismos baseados na janela deslizante) UDP - User Datagram Protocol ligações não fiáveis (connection less) rapidez de entrega mais importante que ausência de erros (video, audio) serviços do tipo pergunta/resposta IP + pequeno cabeçalho (8 bytes) 2 bytes - porto origem 2 bytes - porto destino 2 bytes - UDP length 2 bytes - UDP checksum UDP User Datagram Protocol RFC 768 Não existe confirmação ou re-transmissão de pacotes Tal como o TCP, implementa endereçamento para a camada de aplicação (ports) Cabeçalho 32 bits Source port Length Destination port Checksum Valor mínimo = 8 bytes Com IP, não dá qualquer informação adicional... Controlo de erros no cabeçalho e dados do pacote (end-to-end checksum tal como no TCP) (ver o cabeçalho IP) 2
Checksum UDP O Checksum no UDP é opcional Campo de checksum = 0, não é efetuada verificação Campo de checksum <> 0, verificação realizada O cálculo do checksum utiliza o header, os dados e também um Pseudo-Header. O pseudo-header é utilizado para verificação adicional e confirmação de que o datagrama chegou ao destino correto Pseudo-Header 0 16 31 Endereço IP Origem Endereço IP Destino Zero Protocolo Tamanho São Utilizados: 3 campos do Cabeçalho IP Endereço IP Origem Endereço IP destino Protocolo Campo Zero Tamanho do datagrama 3
Ordem de Header para o Checksum do UDP Header UDP 0 16 31 Endereço IP Origem Endereço IP Destino Zero Protocolo Tamanho Porta Origem Porta Destino Tamanho Checksum Dados Pseudo-Header Datagrama UDP O Pseudo-Header não é transmitido. Apenas é utilizado para cálculo do Checksum. Portos Abstração de pontos de entrada num nó da rede. Não têm correspondência com hardware específico. Identificados através de um número inteiro positivo. Normalmente identificam um processo ou uma aplicação. Implementam um nível adicional de segurança. Cada serviço tem normalmente um porto associado. Cada servidor mantem-se à escuta de um porto. Portos com número <1024 são well known ports. 4
Well-known Ports Port TCP UDP Description Status 0 UDP Reserved Official 1 TCP UDP TCP Port Service Multiplexer (TCPMUX) Official 2 TCP UDP Management Utility Official 3 TCP UDP Compression Process Official 4 TCP UDP Unassigned Official 5 TCP UDP Remote Job Entry Official 6 TCP UDP Unassigned Official 7 TCP UDP Echo Protocol Official 8 TCP UDP Unassigned Official 9 TCP UDP Discard Protocol https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt /etc/services tcpmux 1/tcp # TCP port service mux tcpmux 1/udp # TCP port service mux rje 5/tcp # Remote Job Entry rje 5/udp # Remote Job Entry echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users systat 11/udp users daytime 13/tcp daytime 13/udp qotd 17/tcp quote qotd 17/udp quote msp 18/tcp # message send protocol msp 18/udp # message send protocol chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp-data 20/udp ftp 21/tcp ftp 21/udp fsp fspd 5
Tamanho Máximo do Datagrama No IP, o campo tamanho total (Total Lenght) é de 16 bits. => Tamanho Máximo do datagrama IP: 64 KiB Tamanho do Header IP: 20 Bytes Tamanho do Header UDP: 8 Bytes Tamanho máximo dos dados dum datagrama UDP: 64Ki 20 8 = 65507 Bytes IPH UDPH Data TCP Transmission Control Protocol RFC 793 Funcionalidades Adiciona fiabilidade à camada de rede Detecção e correcção de erros Checksum do cabeçalho e dados (melhor que IP!) Controlo de fluxo Gere a taxa de transmissão do emissor para o receptor (evita overflow de buffers) Re-ordenação dos pacotes Gestão de eventual duplicação de pacotes Essencialmente produzidos pelos mecanismos de recuperação de erros implementados pelo TCP Implementa endereçamento para a camada de aplicação (ports) Mecanismos utilizados Numeração sequencial de pacotes Confirmação (ACK) dos pacotes recebidos correctamente Retransmissão dos pacotes dos quais não foi recebida confirmação 6
TCP Cabeçalho SN - Sequence Number (32 bits) Indica a posição do 1º byte de dados do pacote global de dados. Significa que todos os bytes transmitidos são numerados sequencialmente pelo TCP. 32 bits garantem que um determinado número de sequência só será repetido ao fim de várias horas. AN - Acknowledgment Number (32 bits) Próximo número de sequência que o emissor do ACK espera receber (SN do último byte recebido corretamente + 1) Uma vez que a comunicação pode ser full-duplex, cada um dos terminais de comunicação deve manter um AN independente Utilizado em conjunto com flag ACK TCP Cabeçalho Header Length Indica o offset (em palavras de 32 bits) dos dados dentro do segmento (porquê?) Flags URG dados urgentes. Pode ser utilizado por aplicações de Telnet e FTP quando o utilizador aborta a sessão ou a transferência de dados. ACK se for 1 indica que o valor do campo Acknowledgement deve ser considerado. No início da ligação esse campo deve ser ignorado PSH Push flag - não espera por mais dados: o buffer de dados deve ser entregue à camada de aplicação. Pode ser utilizado por aplicações interactivas: se um pacote de dados contém um comando/acção, deve ser processado imediatamente. Na realidade não é utilizado. RST Reset flag termina a ligação devido à ocorrência de algum tipo de erro. Pode ser utilizada quando é pedido o estabelecimento de 1 ligação com 1 servidor que não existe... SYN Synchronize flag utilizada na fase de estabelecimento de ligação para indicar CONNECTION_REQUEST (SYN=1,ACK=0) e CONNECTION_ACCEPTED (SYN=1,ACK=1) FIN utilizada para terminar uma ligação Window Size (16 bits) Indica o tamanho da janela utilizada pelo mecanismo de Janela Deslizante Valor máximo é de 65535 bytes Checksum (16 bits) Controlo de erros no cabeçalho e dados do pacote Urgent Pointer Apenas válido se URG=1 Indica onde terminam os dados urgentes Options Indica qual o tamanho máximo de dados que suporta (MSS semelhante ao MTU) 7
MSS (Maximum Segment Size) MSS - Maximum Segment Size Representa o tamanho do maior bloco de dados que poderá ser enviado para o destino. Não é negociável, cada host divulga o seu MSS Default: 536 bytes (20 bytes IP, 20 bytes TCP, 576 bytes total) Ethernet: 1460 bytes (20 bytes IP, 20 bytes TCP, 1500 bytes total) Redes de Computadores TCP Comunicação A B SEQ 950 ACK 320 Data=Hi there SEQ 320 ACK 958 Data=Shut Up SEQ 958 ACK 327 Acknowledge pode ser efectuado em pacotes de dados Piggypacked Acknowledge 8
TCP Estabelecimento de Ligação A B SEQ 921 - SYN NoACK SEQ 302 - SYN ACK 922 SEQ 922 - NoSYN ACK 303 A pretende comunicar com B : A envia 1 pacote com a flag SYN a 1 e com um valor de SEQ B responde com flag SYN a 1, um valor de SEQ e o campo de acknowledegment (ACK) com o valor da sequência recebida + 1 A faz o acknowledegement do pacote que recebeu Estabelecimento de Conexões Simultâneas É possível que 2 hosts tentem estabelecer uma conexão entre eles simultaneamente. A B Apenas é criada uma conexão. 9
Encerramento da Ligação Origem A FIN 1415531522:1415531522 (0) ACK 1823083522 Destino B ACK 1415531523 FIN 1823083522: 1823083522 (0) ACK 1415531523 ACK 1823083523 Half Close As ligações TCP são full-duplex, Cada lado da conexão deve finalizar a ligação de forma independente. Quando um dos lados recebe uma solicitação de finalização deve: confirmar recepção do pedido de finalização enviar a notificação para a aplicação. Uma aplicação ainda pode mandar dados após receber o pedido de finalização. 10
Half Close - Exemplo sun bsdi Exemplo: FIN + ACK $ rsh bsdi sort < datafile ACK Data datafile std input sun bsdi Ack of Data rsh sort FIN + ACK terminal std output ACK Encerramento simultâneo Os hosts podem tomar a iniciativa de encerrar a ligação simultaneamente Origem Destino FIN_WAIT 1 FIN FIN FIN_WAIT 1 CLOSING ACK ACK CLOSING TIME_WAIT TIME_WAIT 11
TCP Máquina de Estados (simplificada) TCP Máquina de Estados 12
TCP TIME_WAIT Após finalização de uma ligação TCP ainda é possível que alguns pacotes cheguem ao destino (devido a retransmissões e atrasos) Para impedir que esses dados interfiram com novas ligações, nos mesmos portos, entre o mesmo cliente e servidor, a ligação entra num estado de TIME_WAIT Neste estado são recusadas ligações nos mesmos portos por um tempo prédefinidos (geralmente 240 segundos) Muitas ligações por períodos curtos podem levar um servidor a uma situação de falta de recursos (portos), impossibilitando-o de aceitar ligações. Utilizado por hackers para ataques DOS (Denial Of Service), tentando que um número elevado de portos estejam num situação de TIME_WAIT TCP Perda de 1 Pacote Em cada ACK, indicado também o valor da Janela Pacote com SEQ=39 não chega ao destino Pacote seguinte (SEQ=49) chega ao destino Não é feito ACK do 49 pois não foram recebidos todos os pacotes intermédios! Time-out do timer 39 Retransmissão do pacote com SEQ=39 ACK com valor 57 confirma simultaneamente 2 pacotes! 13
TCP Perda de ACK - 1 Timers 9 Todos os pacotes de dados chegam ao destino ACK 35 perdido na rede! Time-out do timer 21 21 Retransmissão do pacote com SEQ=21 ACK 35 também é retransmitido. Recetor elimina pacote duplicado. 21 TCP Perda de ACK - 2 Todos os pacotes de dados chegam ao destino ACK 39 perdido na rede! ACK 49 já tinha sido enviado e é correctamente recebido! Não é necessária retransmissão de nenhum pacote de dados ACK=49 confirma a receção de todos os pacotes de dados com confirmação pendente 14
TCP Janela Deslizante Receptor indica, em cada ACK, qual o próximo byte que deve ser enviado Receptor indica também qual o máximo número de bytes que pode ser enviado Pacotes não precisam de ser confirmados 1 a 1: o Receptor podia optar por não enviar este ACK uma vez que ainda tem espaço disponível e que a Janela foi anunciada antecipadamente (no estabelecimento da ligação) Receptor deve remover dados do buffer para poder receber novamente Evolution of TCP 1975 Three-way handshake Ray Tomlinson 1974 TCP described by Vint Cerf, Bob Kahn In IEEE Trans Comm 1981 TCP & IP RFC 793 & 791 1984 Nagel s algorithm to reduce overhead of small packets; predicts congestion collapse 1983 BSD Unix 4.2 supports TCP/IP 1987 Karn s algorithm to better estimate round-trip time In SIGCOMM 75 1988 Van Jacobson s 1986 Congestion collapse 1 st observed algorithms slow start, congestion avoidance, fast retransmit (all implemented in 4.3BSD Tahoe) SIGCOMM 88 1990 4.3BSD Reno fast recovery delayed ACK s 1975 1980 1985 1990 15
Evolution of TCP 1993 TCP Vegas(not implemented) real congestion avoidance (Brakmo et al) 1994 ECN Explicit Congestion Notification (Floyd) 1994 T/TCP Transaction TCP (Braden) 1996 Improving TCP startup (Hoe) 1996 NewReno modified fast recovery SACK TCP Selective Ack (Floyd et al) 1996 FACK TCP Forward Ack extension to SACK (Mathis et al) 1993 1994 1996 Small Packet Problem Algumas aplicações têm tendência a enviar pequenos pacotes de dados com muita frequência. Exemplo: rlogin 1 byte cada vez que o utilizador usa uma tecla. A cada pacote (1 Byte) são anexados: 20 bytes de cabeçalho TCP 20 bytes de cabeçalho IP 14 bytes de cabeçalho Ethernet. Eficiência = 1/55 < 2% 16
Algoritmo de Nagle John Nagle, 1984. Tenta evitar o problema dos pacotes pequenos. Pequenos segmentos só são enviados após a receção do ACK dos segmentos anteriores. Segmentos completos (=MSS) são enviados imediatamente. Segmentos pequenos podem ser agrupados e enviados em conjunto. Algoritmo de Nagle A velocidade de envio varia com a velocidade da rede: Algoritmo é self-clocking Exemplo: Rlogin sobre Ethernet RTT aproximadamente 16 ms 2 teclas só são anexadas se dt<rtt => velocidade de escrita > 60 teclas por segundo. Isto significa que raramente é aplicado nestas redes 17
Algoritmo de Nagle Quando é necessário? Tráfego Interativo Utilizado em redes com RTT maior (p.ex: WAN) Xwindows (movimentos do mouse...) Pode ser desabilitado através da opção TCP_NODELAY da API sockets Receptor com pouca capacidade TCP - Controlo de Fluxo e Congestionamento Ajuste do ritmo de transmissão Rede Receptor com muita capacidade Congestionamento Interno Problema: a rede pode ser o bottleneck! Solução: definir uma janela de congestionamento juntamente com a janela de controlo de fluxo definida pelo receptor. A janela a usar é a mínima das duas. (janelas definem o número máximo de bytes a enviar) Algoritmo: inicializar janela de congestionamento com o comprimento máximo do segmento que vai ser usado na ligação enviar um segmento se houver confirmação, então duplicar o tamanho da janela e repetir até falhar re-inicializar a janela com o valor inicial além das janelas, usar um threshold que indica até quando é que se deve duplicar a janela se atingido o threshold, aumentar a janela de forma linear e não exponencial num timeout, diminuir o valor do threshold para 50% da janela de congestionamento e re-inicializar a janela 18
TCP - Controlo de Fluxo e Congestionamento 1. Comprimento máximo do segmento: 1K 2. Threshold inicial: 32K 3. Janela de Congestionamento duplica em cada transmissão 4. Atingindo o threshold, janela passa a crescer linearmente 5. Na transmissão 13 há um timeout (pode significar congestionamento da rede) 6. Threshold diminuído para metade da janela de congestionamento ( 40 K - 20 K) 7. Janela de Congestionamento re-inicializada 8. Na transmissão 18 atinge-se novamente o threshold 9. Crescimento da janela passa a ser linear 10. Se não ocorrer mais nenhum timeout, a janela de congestionamento cresce até ao tamanho da janela do receptor 11. A janela de congestionamento deixa de crescer TCP - Controlo de Fluxo e Congestionamento A Janela de Congestionamento permite que o Emissor se adapte ao estado da rede e não apenas ao tamanho do buffer do Receptor (como faz a Janela de Controlo de Fluxo) Se existir congestionamento Time-out de pacotes TCP Janela re-inicializada com valor igual a 1 segmento de forma a evitar que Emissor envie muito tráfego para a rede Novo threshold com metade do valor para evitar que o crescimento exponencial da Janela de Congestionamento provoque rapidamente novos congestionamentos Desta forma, evita-se que o Emissor contribua para aumento do congestionamento da rede Janela de Congestionamento funciona bem para ligações que permanecem activas durante um período considerável de tempo Para ligações HTTP o valor da janela nunca atinge um valor óptimo 19
Cumulative Acknowledgements TCP uses cumulative acknowledgements. One ACK confirms multiple receptions. Delay exists before sender knows of a lost packet. Multiple timeouts can occur due to a single loss. Result: poor TCP performance and low throughput. Solution: Selective Acknowledgments (SACK) Selective Acknowledgements Receiver informs the sender about ALL received packets. Sender can then resend ONLY the ones which were not received. SACK is a TCP Option. It is applied only when both machines agreed. 20
SACK-permitted Option Two-byte option. Kind = 4. May be sent in a TCP SYN by a host that can receive (and presumably process) SACK options. Format: 16 bit Kind = 4 Length = 2 SACK Option Kind = 5 The SACK option is sent by a data receiver to inform the data transmitter of non-contiguous blocks of data that have been received and queued. When missing segments are received, the data receiver acknowledges the data normally by advancing the left window edge in the ACK Field of the TCP header. Each contiguous block of data queued at the data receiver is defined by two 32-bit unsigned integers. 21
sender receiver SACK Option A SACK option that specifies n blocks will have a length of 8*n+2 bytes. SACK Example receiver s buffer 1-100 101-200 1-100 101-200 401-500 501-600 22
ECN ECN Explicit Congestion Notification RFC 3168 Extensão ao IP e ao TCP. Só aplicável quando extremos e rede suportam mecanismo de ECN. Um encaminhador pode assinalar a congestão marcando uma flag no cabeçalho IP. O datagrama não é eliminado. O recetor reenvia a indicação para o emissor. O emissor actua como quando detecta perda de pacotes: Reduz a dimensão da janela de congestionamento Reduz a taxa de transmissão. Implementa controlo preventivo de congestionamento. Notificação Explícita da Congestão ECN Explicit Congestion Notification ECT - ECN Capable Transport CE Congestion Encountered ECT CE ECT CE Cabeçalho IP Cabeçalho TCP 1 0 0 1 1 1 0 2 CWR CWR 1 ECN-Echo Cabeçalho do ACK TCP Cabeçalho TCP 1 CWR Congestion Window Reduced 4 3 Fonte Encaminhador Destino 23
Syn Flood Flooding de solicitações de conexão falsas Normalmente usa IP Spoofing Intruso Destino Suposta Origem SYN SYN + ACK SYN RST SYN SYN RST SYN SYN Problema exemplo Troca de mensagens TCP numa sessão estabelecida entre as máquinas A e B. Para cada mensagem são apresentados os valores dos campos de Sequência (Seq) e de Confirmação (ack) e a dimensão do bloco de dados (data). Sem esquecer a devida justificação, determine: a) o valor do campo de Confirmação (ack) da 1ª mensagem de B para A, ack 1. b) o valor do campo de Sequência (Seq) da 2ª mensagem de B para A, seq 1. c) a dimensão dos dados incluídos na 3ª mensagem de A para B, data 1. d) o valor do campo de Sequência (Seq) da 4ª mensagem de A para B, seq 2. 24
Bibliografia recomendada Andrew S. Tanembaum, Computer Networks, 3rd Edition, Prentice Hall, pp 521-542 William Stallings, Data and Computer Communications, Chapter 20 - Transport Protocols 25