Capítulo 3 A Camada de Transporte da Arquitectura TCP/IP 3.1 Portos e Sockets 3.2 O Protocolo UDP 3.3 O Protocolo TCP 1 3.1. Portos e Sockets A Camada de Transporte fornece transferência de dados fim-a-fim Ligação fim-a-fim entre duas aplicações: necessário identificar de forma unívoca cada um dos processos associados Conceito de processo: Um processo corresponde a uma instância activa de uma aplicação num determinado momento A cada processo é atribuído um identificador de processo (PID), único no sistema em que está a correr, e que pode ser diferente de cada vez que essa aplicação é iniciada 2
3.1. Portos e Sockets Conceito de processo (cont.): O processo de um programa "Servidor" pode ter várias conexões, para múltiplos clientes, ao mesmo tempo, logo os identificadores de conexões podem não ser únicos Surgem assim os conceitos de Porto e de Socket, como formas de identificar de maneira uniforme e única conexões entre programas e respectivos hosts associados, de forma independente dos PID s locais 3 3.1. Portos e Sockets - Conceito de Porto Porto: identificador perante a pilha TCP/IP de um processo que pretende comunicar com outro número de 16 bits, usado pelos protocolos host-to-host para identificar que protocolo de nível superior ou que aplicação pretende estabelecer comunicação com outra Existem dois tipos de portos: well-known (bem conhecidos) ephemeral (efémeros) 4
3.1. Portos e Sockets - Conceito de Porto Portos well-known: são associados a servidores standard (p. e. o daemon servidor Telnetd usa o porto 23) São identificados por números, que variam entre 1 e 1023 Os portos well-known são controlados e atribuídos pela IANA, encontrando-se definidos no STD 2 - Assigned Internet Numbers 5 3.1. Portos e Sockets - Conceito de Porto Alguns dos portos standard mais utilizados: 20: ftp-data 21: ftp 23: telnet 25: smtp 53: domain 80: http 110: pop3 143: imap 6
3.1. Portos e Sockets - Conceito de Porto Portos ephemeral: Os clientes não precisam de utilizar números de portos well-known, já que são eles que iniciam a comunicação com os servidores, enviando assim o número do seu porto nos datagramas valores desde o número 1024 até 65535 Os clientes podem usar qualquer número que lhes seja alocado, desde que a combinação <protocolo de transporte, endereço IP, porto> seja única Estes portos não são controlados pela IANA, podendo ser utilizados "livremente" pelos utilizadores 7 3.1. Portos e Sockets - Conceito de Porto 8
3.1. Portos e Sockets - Conceito de Porto 9 3.1. Portos e Sockets - Conceito de Porto 10
3.1. Portos e Sockets - Conceito de Socket Interface de Sockets: application programming interface - (API) para protocolos de comunicação Socket: é um tipo especial de descritor de ficheiro (file handle), que é usado pelos processos para requisitar serviços de rede ao sistema operativo O endereço de um socket é obtido através do triplo: <protocol, local-address, local-process> Exemplo, para a arquitectura TCP/IP: <tcp, 193.136.195.221, 12549> Uma conversação é a ligação que permite comunicação entre dois processos O conjunto <protocol, local-address, local-process, foreign-address, foreign-process> é denominado associação, especificando de forma completa dois processos com uma ligação estabelecida Exemplo, na pilha TCP/IP: <tcp, 193.136.195.105, 1500, 193.136.195.221, 21> 11 Protocolo UDP User Datagram Protocol (RFC 768): 3.2. Protocolo UDP protocolo que permite o estabelecimento de uma conexão fim-a-fim (ao nível da camada de transporte do TCP/IP) funciona como um interface de aplicação do IP, NÃO adicionando fiabilidade, controlo de fluxo ou recuperação de erros a este simplesmente serve como um multiplexador/desmultiplexador para envio e recepção de datagramas, usando portos para os guiar fornece um mecanismo que permite a uma aplicação enviar datagramas para outra 12
3.2. Protocolo UDP Multiplexador/Desmultiplexador 13 3.2. Protocolo UDP O nível de actuação do UDP pode ser visto como extremamente leve, introduzindo pouco overhead Em contrapartida, exige às aplicações a responsabilidade pela recuperação de erros, verificação da sequenciação, etc Cada datagrama UDP é enviado em simples datagramas IP, que podem ser fragmentados pelo nível IP, e posteriormente reassemblados no destino, antes de ser apresentados ao nível UDP Qualquer implementação IP tem de aceitar datagramas até 576 bytes Considerando um máximo de 60 bytes para o cabeçalho IP, restam 516 bytes para tamanho mínimo de um segmento UDP 14
3.2. Protocolo UDP Formato do cabeçalho 15 3.2. Protocolo UDP - Aplicações Algumas aplicações que usam tráfego UDP: Trivial file Transfer Protocol (TFTP) Domain Name System (DNS) Remote Procedure Call (RPC) Simple Network Management Protocol (SNMP) Lightweight Directory Access Protocol (LDAP) 16
3.3. Protocolo TCP Protocolo TCP Transmission Control Protocol (RFC 793): Tem como objectivo principal fornecer um canal de comunicação lógico fiável entre pares de processos Não assume fiabilidade de comunicação nos protocolos de nível inferior (p. e. IP), garantindo ele próprio essa fiabilidade Fornece às aplicações bastante mais facilidades que o UDP, nomeadamente recuperação de erros, controlo de fluxo e fiabilidade Protocolo orientado à conexão, ao contrário do UDP, que é não orientado à conexão 17 3.3. Protocolo TCP 18
3.3. Protocolo TCP - Características Transferência de Sequências de Dados: do ponto de vista das aplicações, o TCP transfere sequências contínuas de bytes através da rede a aplicação não tem de se preocupar em agrupar os dados em blocos ou datagramas, já que o TCP realiza esta tarefa, agrupando os bytes a transferir em segmentos TCP, que são passados de seguida ao IP para serem transmitidos 19 3.3. Protocolo TCP - Características Transferência de Sequências de Dados (cont.): 20
3.3. Protocolo TCP - Características Sequenciação: o TCP atribui um número de sequência a cada byte transmitido e espera uma confirmação positiva (positive acknowledgement - ACK) do host de destino Se o ACK não é recebido durante um intervalo de timeout, os dados são retransmitidos Se os dados forem transmitidos em blocos (segmentos TCP), é enviado apenas o número de sequência do primeiro byte de dados O TCP de destino usa os números de sequência para reagrupar os segmentos, quando estes chegam fora de ordem, bem como para eliminar segmentos duplicados 21 3.3. Protocolo TCP - Características Controlo de Fluxo: o TCP de destino, quando envia um ACK para a origem, indica também qual o número de bytes que pode receber a seguir, sem causar congestionamento dos seus buffers A informação de controlo de fluxo é enviada no ACK na forma do maior número de sequência que pode receber sem problemas Este mecanismo é também conhecido como o princípio das Janelas Deslizantes 22
3.3. Protocolo TCP - Características Controlo de Fluxo Princípio das Janelas Deslizantes 23 3.3. Protocolo TCP - Características Multiplexagem: é fornecida recorrendo ao uso dos portos, da mesma forma que o UDP Conexões lógicas: A sequênciação e o controlo de fluxo necessitam que o TCP inicialize e mantenha determinada informação de estado para cada sequência de dados O conjunto desta informação, que inclui os sockets usados, números de sequência e tamanho das janelas é denominado conexão lógica Cada conexão é identificada de forma unívoca por um par de sockets Full Duplex: o TCP fornece tranferência de sequências de dados, de forma concorrente, em ambas as direcções 24
3.3. Protocolo TCP - Cabeçalho 25 3.3. Protocolo TCP Abertura de Conexão 26
3.3. Protocolo TCP Confirmação e Retransmissões 27 3.3. Protocolo TCP Controlo de Congestão Uma das principais diferenças entre o TCP e o UDP está nos algoritmos de controlo de congestão O TCP pode adaptar o fluxo de dados do emissor à capacidade da rede, para prevenir potenciais situações de congestão As modernas implementações do TCP contém quatro algoritmos standard para a realização desta tarefa: Slow Start Congestion Avoidance Fast Retransmit Fast Recovery 28
3.3. Protocolo TCP Slow Start As implementações mais antigas do TCP costumavam iniciar uma conexão com o emissor a injectar múltiplos segmentos na rede, até atingir o limite imposto pelo window size anunciado pelo receptor Se este comportamento não levanta problemas de maior em LAN s, já em WAN s, que incluem encaminhadores intermédios, e podem incluir ligações lentas pelo meio, podem surgir problemas. Nesta situação os encaminhadores intermédios podem começar a descartar pacotes, a partir do momento em que os seus buffers atingem um limite 29 3.3. Protocolo TCP Slow Start O algoritmo Slow Start previne esta situação, iniciando o envio dos dados a débitos baixos, e, conforme se vai apercebendo das capacidades do canal, vai aumentando progressivamente este débito, até ao máximo possível sem entrar em congestão O emissor começa por enviar um segmento e espera pelo seu ACK Quando este é recebido, incrementa a congestion window de um para dois, enviando então de seguida dois segmentos sem esperar pelos respectivos ACK Quando estes chegarem incrementa novamente o congestion window para quatro, e assim sucessivamente Este aumento exponencial termina quando o receptor começa a atrasar o envio dos ACK, que é a forma deste regular o débito do emissor 30
3.3. Protocolo TCP Slow Start 31 3.3. Protocolo TCP Congestion Avoidance A perda de um pacote, indica que pode haver congestão algures na rede Existem duas indicações base de pacotes perdidos: quando ocorre um timeout e quando são recebidos ACKs duplicados O algoritmo Congestion Avoidance, que funciona em conjunto com o Slow Start, permite recuperar de situações de congestão evitando reinicialização completa do estado do canal 32
3.3. Protocolo TCP Fast Retransmit O algoritmo Fast Retransmit evita que o TCP tenha de esperar pela ocorrência de um timeout para reenviar segmentos perdidos Quando um pacote chega fora de ordem, o TCP gera e envia imediatamente um conjunto de ACK duplicados (do último segmento recebido dentro da ordem) Este ACK duplicado vai indicar ao emissor que foram recebidos segmentos fora de ordem, e qual é a sequência correcta que o receptor espera 33 3.3. Protocolo TCP Fast Retransmit 34
3.3. Protocolo TCP Fast Recovery O algoritmo Fast Recovery é implementado em conjunto com o Fast Retransmit, permitindo acelerar o processo de recuperação de situações de congestão Nesta situação, após a aplicação do Fast Retransmit, aplica-se o algoritmo Congestion Avoidance, em vez do Slow Start, permitindo uma recuperação mais rápida 35