Redes de Computadores

(1)

Redes de Computadores

6. Camada de Transporte

Elvio Leonardo

DIN/CTC/UEM

(2)

Principais Fun¸c˜oes

I

Oferece conex˜ao l´ogica entre duas extremidades da rede

I

Oferece controle fim-a-fim de fluxo e confiabilidade

I

Independente da tecnologia utilizada na rede

I _{meio f´ısico, estrutura e topologia da rede, etc.}

I

Significa a fronteira entre equipamento de rede e de usu´ario

I

Tipicamente utiliza o modelo cliente-servidor

I

Protocolos mais populares:

I Transmission Control Protocol (TCP) I User Datagram Protocol (UDP)

I

Tarefas:

I Segmenta¸cão de dados da camada superior I Estabelecimento da conexão fim-a-fim I Multiplexa¸cão de fluxos

I _{Envio de segmentos com confiabilidade (com controle de fluxo,}

(3)

Berkeley Sockets

I

Fornece uma API (application programming interface) para

comunica¸c˜ao entre processos (locais ou remotos)

I

Inclui uma biblioteca em linguagem C; hoje dispon´ıvel em

outras linguagens

I

Inicialmente desenvolvido para Unix; hoje dispon´ıvel em outros

sistemas operacionais

I

Tornou-se a interface padr˜ao para abstrair conex˜oes de rede

I

Utiliza o modelo cliente-servidor

(4)

Berkeley Sockets

I

Servidor

I _{Cria um socket utilizando a primitiva (fun¸c˜ao) SOCKET} I _{Liga o socket a uma porta (utilizando BIND)}

I Prepara o socket para ouvir (utilizando LISTEN)

I Permanece bloqueado enquanto aceita solicita¸c˜oes de conex˜ao

(utilizando o ACCEPT)

I Comunica-se com o cliente (utilizando SEND e RECEIVE) I Fecha o socket que não é mais necessário (utilizando CLOSE)

I

Cliente

I Cria um socket (utilizando SOCKET)

I Conecta com o servidor (utilizando CONNECT)

I Comunica-se com o servidor (utilizando SEND e RECEIVE) I Termina a conexão que não é mais necessária (utilizando

(5)

Endere¸camento

I

Endere¸co de rede especifica a m´aquina (interface)

I

Endere¸co de transporte especifica o processo/aplica¸c˜ao

I

Na internet, esse endere¸co ´e denominado porta

(6)

Endere¸camento

I

Como o cliente sabe o endere¸co (n´umero da porta) onde o

servidor estar´a oferecendo os seus servi¸cos?

I

Servi¸cos tˆem o endere¸co fixo e publicamente conhecido

I Servi¸cos com menor demanda podem usar um servidor de

processos

I _{Servidor de processos aceita pedidos de conex˜ao e encaminha}

(7)

Estabelecimento da Conex˜ao

I

_{Problema: segmentos que ficam vagando pela rede e podem}

causar efeitos indesej´aveis

I

Solu¸c˜ao:

I Segmentos e suas confirma¸cões têm vida limitada I Evita reutilizar os números se existe chance de segmentos

antigos ainda existirem

I Objetivo ´e evitar que 2 PDUs diferentes com numera¸c˜ao

idˆentica existam na rede I

Mecanismo:

I _{Todas as máquinas mantém um relógio imune a falhas} I Os k bits menos significativos desse relógio são usados para

numera¸c˜ao dos segmentos

I A faixa de numera¸c˜ao deve ser ampla o suficiente evitar que

segmentos diferentes utilizem o mesmo n´umero

(8)

Estabelecimento da Conex˜ao

(9)

Estabelecimento da Conex˜ao

(10)

Encerramento da Conex˜ao

I

Encerramento sim´etrico com 3-way handshake

I _{Cada sentido ´e tratado independentemente (isto ´e, como se}

(11)

User Datagram Protocol (UDP)

I

_{Servi¸co sem conex˜ao (veja RFC 768)}

I

Porta (endere¸co) utiliza 16 bits: de 0 a 65535

I _{Portas 0 a 1023 s˜ao denominadas “bem conhecidas” (well}

known) e foram as primeiras definidas

I _{Portas 1024 a 49151 s˜ao designadas pela Internet Corporation}

for Assigned Names and Numbers (ICANN)

I Portas 49152 a 65535 s˜ao de uso geral e tempor´ario

I

Utilizado por:

I Aplica¸c˜oes sens´ıveis ao atraso (retardo) porque um segmento

perdido ´e melhor do que um segmento atrasado

I Servidores respondendo a pequenas requisi¸c˜oes I Exemplos: DNS, IPTV, VoIP, jogos em rede, etc.

(12)

Real-time Transport Protocol (RTP)

I

Protocolo padr˜ao para transporte de dados em tempo real

(audio e v´ıdeo on demand ou interativo) (veja RFC 3551 e

RFC 4571)

I

Controle ´e definido pelo RTP Control Protocol (RTCP)

I

Utiliza UDP e mais raramente TCP (portas 5004 para dados e

5005 para controle)

I

Protocolo de carga (RTP)

I Camada fina para tráfego cont´ınuo oferece deteçcão de perda,

seguran¸ca, reconstru¸cão temporal e identifica¸cão de conteúdo I

Protocolo de controle (RTPC)

I Permite conferˆencia em tempo real

I Oferece controle de QoS (Quality of Service) e sincroniza¸c˜ao

(13)

Real-time Transport Protocol (RTP)

I

Cabe¸calho RTP

I V (version): vers˜ao do protocolo (atualmente 2) I P (padding): enchimento foi utilizado

I X (extension): indica presen¸ca do cabe¸calho de extensão I CC (CSRC count): número de identificadores CSRC existentes I M (mark): utilizado pela aplica¸cão (por exemplo, indica fim de

bloco)

I PT (payload type): formato dos dados

I _{sequence number: número do segmento (para deteçcão de}

perda de segmentos)

I _{timestamp: informa¸c˜ao de tempo}

I SSRC (synchronization source): identifica fluxos de dados para

efeito de sincroniza¸c˜ao temporal

I CSRC (contributing source): identifica fontes contribuindo

para o fluxo (opcional)

I Extension header: cabe¸calho de extens˜ao, dependente do perfil

(14)

Real-time Transport Protocol (RTP)

I

Cabe¸calho RTP

I

RTP Control Protocol (RTCP)

I Principal fun¸c˜ao ´e oferecer feedback da qualidade da

transmiss˜ao

I Transmite periodicamente mensagens de controle a todos os

participantes da sess˜ao

(15)

Transmission Control Protocol (TCP)

I

Servi¸co orientado a conex˜ao (veja RFC 793 para come¸co)

I

E provavelmente o protocolo mais importante da Internet

´

I

Caracter´ısticas principais

I Servi¸co full ou half duplex

I Confirma¸c˜ao de recebimento (com ACK) I Janela deslizante com tamanho vari´avel I Sequence number conta bytes

I Checksum no cabe¸calho e no dado

I _{Receptor re-ordena segmentos e descarta duplicados} I _{Permite controle de fluxo}

(16)

Transmission Control Protocol (TCP)

(17)

Transmission Control Protocol (TCP)

I

Cabe¸calho

I Source port e destination port: endere¸cos I Sequence number: número de seqüência

I Acknowledgement number: confirma¸cão de recebimento I _{URG: campo Urgent pointer é válido}

I _{ACK: campo Acknowledgement number ´e valido}

I _{PSH (push): dado deve ser passado à aplica¸cão imediatamente} I RST (reset): reinicia a conexão

I SYN: sincroniza números de seqüência para iniciar conexão I FIN: fonte terminou de enviar dados

I Window size: janela de transmiss˜ao

I Checksum: para deteçcão de erros do cabe¸calho e dado I Urgent pointer: aponta para conteúdo urgente (por exemplo,

(18)

Transmission Control Protocol (TCP)

I

Estabelecimento da conex˜ao

I 3-way handshake

(19)

Transmission Control Protocol (TCP)

I

M´aquina de estados finitos:

I _{CLOSED: nenhuma conex˜ao ativa ou pendente} I LISTEN: servidor esperando conex˜ao

I SYN RCVD: pedido de conexão recebido I SYN SENT: aplica¸cão solicitou conexão

I ESTABLISHED: conexão estabelecida; transferência de dados I FIN WAIT 1: aplica¸cão solicitou fim da conexão

I FIN WAIT 2: outro lado concordou com término da conexão I TIMED WAIT: aguarda todos os segmentos extinguirem-se I CLOSING: ambos os lados tentam terminar simultaneamente I CLOSE WAIT: outro lado iniciou término da conexão I LAST ACK: aguarda todos os segmentos extinguirem-se

(20)

Transmission Control Protocol (TCP)

Linhas grossas = transi¸cões normais para cliente; Linhas pontilhadas = transi¸cões normais para servidor; e Linhas finas = transi¸cões anormais

(21)

Transmission Control Protocol (TCP)

I

Números de seqüência (sequence numbers)

I Importante que n˜ao se re-utilizem n´umeros de segmentos que

ainda estejam circulando pela rede

I Existe um amplo espa¸co para numera¸cão (32 bits) I Valor inicial é definido por um relógio na fonte

I Máquinas devem evitar números de seqüência na faixa proibida I _{Números de seqüência (enviados e confirmados) referem-se a}

bytes

I O ACK indica o pr´oximo byte que o receptor espera receber I Mesmo parˆametro utilizado para janelas: quantos bytes o

destino est´a apto a receber I

Persistence timer

I Evita a seguinte situa¸c˜ao:

I _{receptor enviou ACK com janela = 0, e depois com}

janela 6= 0, mas esse ´ultimo segmento perdeu-se

I _{ambos os lados agora esperam algo acontecer} I _{Origem temporiza pausas de transmiss˜ao e pergunta ao}

(22)

Transmission Control Protocol (TCP)

(23)

Transmission Control Protocol (TCP)

I

Pol´ıtica de transmiss˜ao

I Desde que respeitando a janela do receptor, a origem pode

enviar dados segundo seu desejo

I _Deve-se:

I _{Esperar (500 ms) para que uma quantidade de dados se}

acumule antes do envio para evitar tinygrams

I _{Aplica¸c˜ao pode solicitar um PUSH para for¸car transmiss˜ao} I _{Atrasar o envio de ACK na esperan¸ca de que ele possa ser}

embutido em um segmento de dados

I _{Evitar a sindrome da janela boba} I _{Algoritmo de Nagle}

I _{Uso tipico: aplica¸c˜oes como telnet}

I _{Origem envia primeiro byte e armazena os seguintes} I _{Quando o primeiro byte ´e confirmado (ACK) envia aqueles}

armazenados e volta a armazenar os seguintes

(24)

Transmission Control Protocol (TCP)

I

Pol´ıtica de transmiss˜ao

(25)

Transmission Control Protocol (TCP)

I

Controle de congestionamento

I Na Internet, com o protocolo de rede (IP) sendo sem conex˜ao,

a maior parte da responsabilidade em evitar congestionamentos cai sobre o protocolo de transporte (TCP)

(26)

Transmission Control Protocol (TCP)

I

Controle de congestionamento

I Problemas com capacidade do receptor: I _{Utiliza janela deslizante}

I Problemas com capacidade da rede:

I _{Perda de pacotes devido a ru´ıdo ou erros causados pelo meio}

s˜ao raros

I _{Assim, perda de pacote ´e causado por timeout} I _{E timeout ´e causado por congestionamento}

I _{Conclus˜ao: TCP assume que perda de pacotes ´e devido a}

congestionamento

I Janela de Congestionamento (congestion window) I _{Fonte mant´em janela de congestionamento (valor inicial:}

m´aximo tamanho de segmento)

I _{Se ACK recebido, janela de congestionamento tem valor}

dobrado até chegar ao limiar (valor inicial: 64 Kbytes) ou aumenta linearmente se já está acima do limiar

I _{Se ocorrer timeout, o limiar ´e reduzido a metade e a janela de}

(27)

Transmission Control Protocol (TCP)

I

Controle de congestionamento

I Mecanismo denominado slow-start

I Janela de transmiss˜ao = valor m´ınimo entre janela do

(28)

Transmission Control Protocol (TCP)

I

Controle de retransmiss˜ao

I Dificuldade em estimar o tempo correto de timeout

I Para funcionamento efetivo, retransmiss˜ao deve ser adaptativa I Fonte monitora atraso do ACK e calcula o timeout utilizando

an´alise estat´ıstica

Densidade de probabilidade do tempo de recebimento do ACK (a) camada de enlace de dados; (b) camada de transporte

(29)

Transmission Control Protocol (TCP)

I

Controle de retransmiss˜ao

I _{Com uma nova medida M do tempo necess´ario para}

transmiss˜ao e recebimento do ACK (round trip time ou RTT), calcula-se

I _{Nova estimativa do round trip time:}

RTTnovo = RTTvelho + (1 − α) M onde α ´e um fator de escala (tipicamento 7/8)

I _{Estimativa do desvio padr˜ao (D) do RTT}

Dnovo = α Dvelho + (1 − α) |RTT − M|

I _{Tipicamente o valor do timeout ´e dado por}

(30)

Transmission Control Protocol (TCP)

I

Controle de retransmiss˜ao

I Algoritmo de Karn

I _{Quando ocorre timeout, o segmento TCP é retransmitido} I _{Quando o ACK chega, ele é para a transmissão original ou}

para o segmento retransmitido?

I _{Uma reposta incorreta pode ter uma influˆencia muito negativa}

na estimativa do RTT

I _{O algoritmo de Karn recomenda atualizar o RTT s´omente}

para segmentos que n˜ao s˜ao retransmitidos

(31)

Transmission Control Protocol (TCP)

I

Wireless TCP

I _{Enlaces por r´adio (sem fio) tem confiabilidade mais baixa e}

podem perder mensagens/pacotes por causa do ru´ıdo

I Portanto a presun¸c˜ao do TCP de que retransmiss˜ao indica

congestionamento não é mais válida

I Conex˜oes TCP s˜ao fim-a-fim e podem incluir um segmento

feito por r´adio

I _{Alternativas:}

I _{Quebrar a conex˜ao TCP em 2 partes: a parte com fio e a}

parte sem fio

I _{Base Station antecipar-se e enviar ACK para evitar “falso”}

(32)

Transmission Control Protocol (TCP)

I

Transactional TCP (T/TCP)

I _{TCP não é eficiente para conexões de curta dura¸cão} I _{UDP não é confiável}

I Uma solu¸c˜ao: TCP transacional