cap. 3 – o nível de transporte. material de suporte às aulas de redes de computadores de j....

Cap. 3 – O nível de transporte

Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins – Copyright DI - FCT/ UNL Transporte / 2

Nota prévia

A estrutura da apresentação é semelhante e utiliza algumas das figuras, textos e outros materiais do livro de base do curso

James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach Featuring the Internet,“ Addison Wesley Longman, Inc., 3rd Edition, 2005


Organização do capítulo

• Serviços do nível transporte• Multiplexing / Demultiplexing• Estudo do transporte: UDP• Como implementar a transferência fiável

de dados• Transporte orientado conexão: TCP

• Transferência fiável de dados• Controlo de fluxo• Gestão da conexão

• Controlo da saturação• Controlo da saturação no protocolo TCP


Papel do nível de transporte

• É o nível geralmente visível pelas aplicações pelo que é central em toda a arquitectura de protocolos

• Pode providenciar dois tipos de serviços: orientado à conexão e não orientado conexão ou modo datagrama ou connectionless

• razões de ser:• melhorar a qualidade de serviço oferecida pelo

nível rede e mascarar as suas deficiências (erros, perdas, etc.)

• multiplexing / demultiplexing• endereçamento extremo a extremo (end-to-end);

exemplo: endereço IP + porta• oferecer uma interface adequada às aplicações

(exemplo: accept, connect, send, receive, read, write, close, …)


Como se desenrola um protocolo de transporte

aplicação

transporte

rede

host

aplicação

transporte

rede

host


Mensagem de nível transporte - Segmentos

Aplicação

Transporte

Rede

Data link

(dados da aplicação)

DadosCabeçalhotransporte

trans Dados

Dados

Cabeçalho frame (Frame)

(Pacote)

(Segmento)

Cabeçalhorede

rede

trans

trans


Communication End Points em TCP/IP

Um endereço IP identifica um host. Para identificar o ponto de acesso a um serviço ao nível transporte é necessária alguma forma de “desdobramento” dentro do host. Em TCP/IP esse desdobramento faz-se através da noção de porta. Um ponto de terminação da comunicação é designado em TCP/IP por socket.

portas e filas de espera

processosEndereço IP

Host

Cada fila de espera corresponde a um socket distinto.


Portas TCP/IP

• As portas usados em UDP e TCP estão normalizadas em gamas de utilização. Existe uma gama reservada, e outra que pode ser usada para escrever novas aplicações

• Dentro das gamas reservadas, existem portas fixas associadas a aplicações normalizadas. Exemplos: HTTP funciona em TCP com o servidor httpd associado à porta 80, o smtpd (sendmail por exemplo) na porta 25, etc.

• Cada servidor que realiza um serviço normalizado tem uma porta fixa associada

• As portas em UDP e TCP correspondem a filas de mensagens independentes mesmo que usem o mesmo número de porta. Ex: a porta 45 em UDP é diferente da porta 45 em TCP

• A afectação de números de portas normalizadas está a cargo do IANA (Internet Addressing and Naming Authority)

• A respectiva tabela está no ficheiro /etc/services


Multiplexing / Demultiplexing

applicationtransportnetwork

MP2

applicationtransportnetwork

receiver

HtHnsegment

Segmentoou tpdu

Mapplicationtransportnetwork

P1M

M MP3 P4

header

application-layerdata

Multiplexing and Demultiplexing: determinar qual a fila de espera (e indirectamente o processo) a quem os dados se destinam. Multiplexing and Demultiplexing poderia ser traduzido por agregar / desagregar.

Tpdu - Transport Protocolo Data Unit é outra designação de Segmento


Multiplexing / Demultiplexing (continuação)

Os dados são marcados com a porta origem e destino

Os dois pares (porta, endereço IP) identificam inequivocamente a origem e o destino dos dados

Também se utilizam os termos segmento TCP, datagrama UDP ou pacote UDP para designar os TPDU TCP e UDP

source port # dest port #

32 bits

applicationdata

(message)

other header fields

Formato do segmento


Exemplos com portas TCP

host A server Bsource port: xdest. port: 23

source port:23dest. port: x

Exemplo: Telnet

Web clienthost A

Webserver B

Web clienthost C

Source IP: CDest IP: B

source port: x

dest. port: 80

Source IP: CDest IP: B

source port: y

dest. port: 80

Source IP: ADest IP: B

source port: x

dest. port: 80 Exemplo: Web server


Identificação dos sockets

O Socket UDP de um processo, e a respectiva fila de espera, são identificados univocamente pelo endereço IP do processo e pela porta associada ao socket.

UDP Socket ID = ( local IP address, local port number)

Nota: é possível fazer a associação de um socket UDP local a um socket UPD remoto.

O Socket TCP de um processo, e a respectiva fila de espera, são identificados univocamente pelo endereço IP do processo e pela porta associada ao socket, assim como pelo endereço IP remoto e a porta remota.

TCP Socket ID = ( local IP address, local port number, remote IP address, remote port number)


O protocolo UDP

Nível de serviço do protocolo UDP• Serviço “best effort” que só acrescenta multiplexagem e

desmultiplexagem ao nível rede. As mensagens UDP (Datagramas UDP) podem ser perdidos ou entregues fora de ordem

• Ausência de conexão (“connectionless”): não é necessário nenhum estabelecimento de conexão (“handshaking”) entre o emissor e o receptor e cada datagrama é processado independentemente dos outros

Vantagens do protocolo UDP• Sem necessidade de conexão (o que evita um RTT

suplementar e vários pacotes extra)• Simples - sem estado do lado do emissor ou do receptor• Cabeçalho mais pequeno que o TCP (8 bytes ao invés de 20

bytes)• Sem controlo de saturação - os dados podem ser enviados à

velocidade que o emissor desejar


Utilizações do protocolo UDP

• Geralmente utilizado pelas aplicações de “streaming multimedia”

• Tolerantes à perca de pacotes

• Sensíveis à velocidade de transmissão

• Outras utilizações do UDP (pela simplicidade e ausência de necessidade de conexão):

• DNS

• SNMP, ...

• Se for necessária fiabilidade é sempre possível introduzi-la ao nível aplicação


Os datagramas UDP

source port # dest port #

32 bits

Dados aplicação (mensagem)

Formato do datagrama UDP

length checksumTamanho, em

Bytes, do segmento UDP

incluindo o cabeçalho


UDP checksum

Emissor: trata o conteúdo do

segmento como uma sequência de inteiros de 16 bits

checksum: soma (complemento a 1’s) do conteúdo do segmento

O valor calculado é colocado no campo respectivo antes da emissão

Receptor: calcula o valor do checksum Compara o valor calculado

com o valor do campo do datagrama recebido:

≠ — o datagrama tem pelo menos um erro

= — não foram detectados erros. O que não quer dizer que estes não possam existir.

Objectivo: detectar “erros” (e.g., bits invertidos) nos segmentos transmitidos


Exemplo

Nota Quando se somam números em complemento a 1’s,

o carryout do bit mais significativo tem de ser adicionado ao resultado

Exemplo: com dois inteiros de 16 bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

carryout

somachecksum


Recepção dos datagramas UDP

frame

desmultiplexagem ip, icmp, arp, ...

desmultiplexagem udp, tcp, ...

Datagrama ou tpdu udp

datagrama ip

dados do datagrama ou tpdu udp

desmultiplexagem pelas portas

portas udp

cabeçalho frame cabeçalho ip cabeçalho udp dados utilizador


Compensação dos erros

• Os níveis inferiores ao nível de transporte podem introduzir erros, sobretudo perca de pacotes e frames

• Os frames com erros são em geral recusados ao nível data-link pelo que podem ser assimilados a pacotes perdidos

• Os protocolos de transporte que introduzem fiabilidade têm de mascarar os erros sob pena de violarem a sua especificação

• Quando um circuito tem uma taxa de erros elevada no nível data-link, também se usam protocolos para mascarar os erros a esse nível para evitar que os mesmos se propaguem para os níveis superiores e que sejam estes que os têm de recuperar

• Uma aplicação que use UDP pode também ter de realizar, ao nível aplicação, mecanismos de compensação dos erros

Material de suporte às aulas de Redes de Computadores de J. Legatheaux Martins –DI - FCT/ UNL Transporte / 20

Protocolo simplista e irrealista

Exemplo de um protocolo que pressupõe que não há erros, nem perca de segmentos e que o receptor tem uma capacidade ilimitada de receber segmentos (isto é, que o receptor tem buffers disponíveis ou que a aplicação consome os dados em tempo útil)

1

2

3

4

5

Emissor Receptor

tempo


Introdução de confirmações de recepção

O protocolo pressupõe que os segmentos não se perdem

s1

s4

Emissor Receptor

ack

s2

s3 Receptorsaturado

ack

ack

tempo

ACK = Acknowledgement ou confirmação de recepção (aviso de recepção).


Perca de um segmento

Quando um ACK se perde há uma situação de bloqueio eterno (deadlock)

s1

Emissor Receptor

ack

s2

s3

ack

ack

tempo


Introdução de temporizadores (Timeouts)

s1Emissor Receptor

ack

s2

s2

ack

s3

ack

s3 duplicado

timeout

timeout

tempo


Problemas ainda mal resolvidos

• A solução anterior não resolve ainda o problema da perca de um ACK que poderá conduzir à aceitação de um segmento duplicado

• O mesmo problema poderá ser introduzido por um receptor lento (face ao timeout) a enviar o ACK

• Um timeout mal regulado, muito curto por exemplo, poderá conduzir ao mesmo problema

• Na verdade as velocidades relativas do emissor e receptor podem não ser constantes nem conhecidas a priori

• Note-se que um timeout muito elevado conduz a uma recuperação demasiado lenta de uma perda


Situações patológicas

Timeout demasiado curto

s1Emissor Receptor

ack

s3

s1 duplicados2 perdeu-se

timeout

s1

s2

tempo


Números de sequência

• A solução consiste em introduzir números de sequência únicos para cada segmento. Estes números permitem ao receptor distingir dados esperados, dados repetidos, etc.

• Para se poupar espaço nos cabeçalhos interessa minimizar o número de bits a usar. O número pode então ser reutilizado ciclicamente desde que não se introduza confusão

• Se um protocolo pressupõe que o nível de baixo não troca a ordem dos segmentos e que o emissor só avança quando tem a certeza que o receptor recebeu os últimos dados enviados, então um número de sequência representado num só bit é suficiente


Protocolo stop & wait

s0(0)Emissor Receptor

a(0)

s1(1)

timeouts0(0)

s1(1)

timeouta(0)

ignora duplicadomas envia ack

a(1)ignora ackduplicado

s2(2)

a(2)

tempo


Funcionamento

• Quando tem um segmento para transmitir, o emissor transmite-o e activa um temporizador. Depois podem suceder os seguintes eventos:• O temporizador dispara – reenvia o segmento• Chega um ACK com o número de sequência esperado -

passa adiante• Chega um ACK com outro número de sequência -

ignora-o

• Quando recebe um segmento, o receptor emite sempre um ACK com o número de sequência igual ao do último segmento recebido correctamente. Se o segmento é novo, guarda-o e dá-o ao nível de cima, senão ignora-o pois é um duplicado.


Tempo de transmissão e RTT

Num canal de 10.000 Km com a velocidade de transmissão de 1 Mpbs quantossegmentos de 1000 bytes se poderiam transmitir antes que chegue o ack do primeiro ?

Tt = nº de bits a transmitir / velocidade de transmissão= 8000 / 1000000 = 0,008 = 8 ms

Tp = dimensão do canal / velocidade de propagação= 10000 / 200000 = 0,05 = 50 ms, logo RTT = 100 ms

Tt

Tp

O ack do segmento chegará 108 ms depois do início da transmissão do mesmo, se se admitir que o tempo de processamento do receptor é nulo e que o tempo de transmissão do ack também é nulo.

Resposta: 108/8 = 13,5


Desempenho do protocolo stop & wait

Circuito a 1 Mbps, RTT de 100 ms, frames de 1KB

TTransm.=8000 b/frame

10**6 bps= 8 ms

Taxa de utilização = U =

=8 ms

108 ms

Fracção de tempo em que o emissor está a transmitir

= 0,074 = 7,4 %

Conclusão: o protocolo não permite aproveitar completamente a capacidade

do circuito !


transmissão do 1º bit, t = 0

emissor receptor

RTT

transmissão do último bit, t = Tt

recepção do 1º bitrecepção do último bit, enviar ACK

ACK chega, enviar o próximo segmento, t = RTT

+ Tt

=8 ms

108 ms= 0,074 = 7,4 %

TtRTT + Tt

Desempenho do protocolo (continuação)

Taxa de utilização = U =(sem erros)


Protocolos com pipelining

• Pipelining: o emissor pode avançar e enviar segmentos mesmo que de alguns dos anteriores não esteja ainda confirmada a recepção.

• Duas formas genéricas destes protocolos: • go-Back-N• selective repeat


Protocolos com pipelining

transmissão do 1º bit, t = 0

RTT

transmissão do último bit, t = Tt

1º bit chega do 1º segmentoúltimo bit do 1º seg. chega, enviar ACK

ACK chega, enviar o próximo, t = RTT + Tt

último bit do 2º seg. chega, enviar ACKúltimo bit do 3º seg. chega, enviar ACK

A taxa de utilizaçãosubiu 3 vezes !

emissor receptor

Taxa de utilização = U =(sem erros)

=3 x 8 ms108 ms

= 22,2 %3 x Tt

RTT + Tt


Pipelining com go-back-N

O emissor vai transmitindo segmentos para a frente, usando um buffer dito “janela” do emissor.

segmentos esquecidos poisjá foram acknowledged

futurosegmentos no buffer de emissão à espera de seremacknowledged

nºs de sequência

Emissor buffer de emissão

Janela de emissão

segmentos esquecidos pois já foram consumidos pelo nível superior

futuro

nºs de sequência

Receptor


Funcionamento no emissor

• Dispõe de uma janela de até N segmentos consecutivos não acknowledged que pode ir transmitindo

• Coloca um nº de sequência no cabeçalho dos segmentos que emite

• Activa um timeout para cada segmento transmitido

• timeout(n): retransmite o segmento emitido há mais tempo e todos os outros até ao fim da janela (“go back N”)

• ACK(n): confirma todos os segmentos para trás incluindo o do nº de sequência (“cumulative ACK” – pode evitar repetições se possível)


Máquina de estados do emissor

Nota: a gestão dos “timeouts” indicada está simplificada.


Funcionamento do receptor

• Recebe segmento com o número de sequência esperado:• Entregar os dados ao nível superior• Enviar ACK correspondente

• Recebe segmento fora de ordem (atrasado ou adiantado): • Ignorar -> não há buffering suplementar no receptor !• Enviar ACK com o nº de sequência do último segmento

aceite, isto é, o último que foi retirado do buffer para entregar ao nível superior


GBN


Generalização

segmentos esquecidos poisjá foram acknowledged

futurosegmentos no buffer de emissão à espera de seremAcknowledged ou com “buracos”

nºs de sequência

Emissor

segmentos esquecidos poisjá foram consumidos pela aplicação

futurosegmentos no buffer de recepção à espera de seremconsumidos pela aplicação ouà espera de serem contíguos

nºs de sequência

Receptor

buffer de emissão

buffer de recepção

Notas: a janela doemissor ser > 1 permitepipelining

a janela do receptorser > 1 permitememorizar frames “dofuturo” (selectiverepeat”)

Um protocolo com asduas janelas iguais a1 diz-se stop and wait

tempo

Janela de emissão

Janela de recepção


A janela do receptor ser superior a 1 permite optimizar GBN

0 1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 9 10 11 12 13 14

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

timeout

não chegou ignorados

0 1 2 3 4 5 6 7 8 2 3 4 5 6 9 10 11 12 13 14 15 16

0 1 2 11 12 13 14 15 16

timeout

não chegou buffered

ack2

ack8

3 4 5 6 7 8 9 10

ack9

ignorados


Selective repeat

• O receptor envia um ACK de todos os segmentos correctamente recebidos e que conseguiu bufferizar, mesmo recebidos fora de ordem

• O emissor activa logicamente um timeout para cada segmento enviado e desactiva o respectivo timeout quando recebe um ACK

• Quando dispara um timeout, o emissor só volta a enviar os segmentos para os quais ainda não tenha recebido um ACK

• O emissor continua limitado pela dimensão da sua janela


Visão das janelas


Funcionamento do Selective Repeat

• Dados do nível superior :

• Se está disponível um nº de sequência na janela, enviar segmento

• Timeout(n):• reenviar segmento n,

activar timeout(n)

• ACK(n) in [sendbase,sendbase+N]:

• Marcar o segmento n como recebido

• Se n é o menor segmento unACKed, avançar a base da janela para o próximo unACKed nº de sequência

• Segmento n in [rcvbase, rcvbase+N-1]

• Send ACK(n)

• Out-of-order: bufferizar

• In-order: entregar (entregar também os outros segmentos contíguos já recebidos), avançar a base da janela para o próximo segmento não recebido

• Segmento n in [rcvbase-N,rcvbase-1]

• Send ACK(n)

• senão: • ignorar

Emissor: Receptor:


Piggybacking

Na prática os canais são quase sempre full-duplex. A implementação dos 2 canais de dados exigiria 4 canais lógicos por causa dos ACKs.

Usa-se então uma técnica chamada “piggybacking” que consiste em introduzir os ACKs nos segmentos do canal do sentido contrário. Tem no entanto que se tomar em consideração o caso em que o tráfego é assimétrico.

dados

nº de sequênciano sentido do envio

nº de sequência do ackdo tráfego do sentido contrário


Outros mecanismos

• Uma outra alternativa ao envio de ACK de todos os segmentos recebidos, mesmo fora de ordem, é não enviar senão ACKS cumulativos dos dados recebidos na ordem. Mas, o receptor, se receber vários ACKs seguidos com o mesmo número de sequência, pode concluir que houve um segmento que se perdeu mesmo que não tenha havido um timeout.

• Enviar NACKs (Negative Acknowledgement) sobre os segmentos em falta para que o emissor retransmita o mais cedo que possível, mesmo antes que o timeout seja desencadeado.


Números de sequência

• Os números de sequência são necessariamente cíclicos (“andam à roda”). Para diminuir o tamanho do cabeçalho, tenta-se usar o menor número possível de bits.

• Coloca-se então o problema de saber exactamente qual o menor número de valores distintos do número de sequência que são necessários :

1. Emissor com janela de dimensão K, receptor com janela de dimensão 1, isto é, “Go back N” e nível inferior que mantém a ordem dos segmentos e não memoriza os atrasados : K + 1

1. Emissor e receptor com janela de dimensão K, nível inferior mantém a ordem dos segmentos e não memoriza os atrasados: 2 K

1. Nível inferior é uma rede que não mantém a ordem dos pacotes e que pode memorizar os atrasados : então os nºs de sequência têm de acomodar o tráfego à velocidade máxima durante o máximo tempo de vida de um pacote (por convenção 3 minutos na Internet).


Valor dos timeouts

O valor dos timeouts deve ser superior ao RTT.

Um timeout demasiado curto ou demasiado longo diminui o rendimento do protocolo.

Um protocolo do nível transporte deve avaliar dinamicamente o RTT para afinar o valor do time-out.

O tamanho da janela de emissão depende da relação Tt / RTT.

Quando a janela de emissão é maior do que 1, uma janela de recepção maior que 1 permite sempre aumentar o rendimento.

O tamanho dos segmentos é variável (de algumas dezenas de bytes a vários milhares de bytes).


Taxa de utilização de uma canal com janela de emissão igual a 1

Tu = Tt / (Tt + RTT) = Tt / TA

Tu - taxa de utilizaçãoTt - tempo de transmissão de um frameTA - tempo que medeia entre o início da transmissão e a recepção do respectivo ackTp - tempo de propagação de extremo a extremoTA = Tt + 2 * Tp

Tu = Tt / (Tt + 2 * Tp ) = 1 / ( 1 + 2 Tp / Tt ) = 1 / ( 1 + 2 A )

A = Tp / Tt = Tempo de propagação / tempo de transmissão

O quociente A é tanto maior quanto maior for o tempo de propagação e menor for o tempo de transmissão. Em todos os casos está-se a desprezar o tempo de processamento (pelo receptor) e o tempo de transmissão do ACK.


Exemplo num canal de 1 Km

Funcionando a 1 Kbps (frame médio de 1000 bits)

Tempo de transmissão = Tt = 1000 / 1000 = 1 s

Tempo de propagação = Tp = 1 / 200000 = 5 . 10-6 s = 5 micro segundos

A = 5 . 10-6 / 1 = 5 . 10-6 => 1 + 2A aprox. = 1 => Tu = 1

Funcionando a 1 Mbps (frame médio de 1000 bits)

Tempo de transmissão = Tt = 1000 / 1.000.000 = 10-3 = 1 ms

Tempo de propagação = Tp = 1 / 200.000 = 5 . 10-6 s = 5 micro s

A = 5 . 10-6 / 10-3 = 5 . 10-3 => 1 + 2A aprox. = 1 => Tu = 1

Num canal de pequena dimensão a taxa de utilização é sempre igual a 100% seja qual for a velocidade de transmissão pois o tempo de propagação é muito reduzido.





Tempo de propagação = Tp = 200 / 200.000 = 1 . 10-3 s = 1 ms

A = 10-3 / 1 = 10-3 => 1 + 2A aprox. = 1 => Tu = 100 %


Tempo de transmissão = Tt = 1000 / 1.000.000 = 10-3 s = 1 ms

Tempo de propagação = Tp = 200 / 200.000 = 10-3 s = 1 ms

A = 10-3 / 10-3 = 1 => 1 + 2A = 3 => Tu = 33,33 %

Num canal de média dimensão a taxa de utilização é 1 se o canal for de baixa velocidade mas começa a diminuir conforme a velocidade de transmissão vai aumentado, ou seja, a velocidade de transmissão é significativa.





Tempo de propagação = Tp = 50.000 / 200.000 = 0,250 s = 250 ms

A = 0,250 / 1 = 0,250 => 1 + 2A = 1,5 => Tu = 66,66 %


Tempo de transmissão = Tt = 1000 / 1.000.000 = 10-3 s = 1 ms

Tempo de propagação = Tp = 50.000 / 200.000 = 0,250 s = 250 ms

A = 250 / 1 = 250 => 1 + 2A = 501 => Tu = 0,2 %

Num canal de grande dimensão a velocidade de propagação é sempre significativa.


Conclusões

1. Se a relação 1 + 2*Tp / Tt = 1 + 2A é próxima de 1, ou seja, quando o tempo de propagação é muito pequeno, uma janela de emissão de dimensão 1 pode ser adequada. Caso esta relação seja > 1, ou seja, quando o tempo de propagação começa a ser significativo face ao tempo de transmissão, é sempre necessário aumentar a janela de emissão para aumentar a taxa de utilização.

2. A janela de recepção maior que 1 destina-se a recuperar melhor dos erros e a acomodar melhor as variações de velocidade do receptor. Na ausência de erros, não garante aumento de rendimento.

3. Quando a janela de emissão é maior que 1, a taxa de utilização é aumentada proporcionalmente, mas não pode ultrapassar 100 % como é óbvio.

4. Numa conexão de transporte, a rede pode introduzir um tempo de propagação significativo (como num canal de grande dimensão) pelo que uma janela de emissão igual a 1 é quase sempre uma má ideia.


O Protocolo TCP


O protocolo TCP

• Connection oriented, reliable, full-duplex, end-to-end transport

• Stream oriented byte flow (unstructured)• Um processo pode trabalhar simultaneamente com várias

conexões

• Trabalha com "segmentos TCP" de comprimento variável e acomoda-se a canais com diferentes MTUs (Maximum Transfer Units)

• Implementa controlo de fluxos e fiabilidade através de técnicas de sliding window

• Utiliza temporizadores ajustados dinamicamente à situação da rede

• Implementa controlo da saturação da rede• A terminação da conexão é ordenada e simétrica, isto é,

espera até todos os dados serem recebidos de ambos os extremos


Conexões TCP

socket 1 socket 2

socket = endereço IP + porta

reliable, serial, full-duplex byte stream

Uma conexão é inequivocamente identificada pelo par (socket 1, socket 2)


TCP: o protocolo

• full duplex:• Cada conexão é bi-

direccional • MSS: maximum

segment size

• Orientado conexão: • Um hand shaking

(troca de mensagens de controlo) tem de ter lugar antes de qualquer troca de dados

• flow controlled:• O emissor não “afoga”

o receptor

• Ponto a ponto:• Um emissor e um receptor

• Byte stream ordenado e fiável:• Não há “delimitadores de

mensagens”

• pipelined:• A janela do emissor é

ajustada dinamicamente

• buffers de emissão e recepção

socketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data


Fiabilidade ao nível transporte e data-link

Os protocolos de transporte orientados conexão são em alguma medida semelhantes aos protocolos orientados conexão do nível data-link. No entanto, dado que o ambiente de execução desses protocolos é muito diferente, os protocolos de transporte são substancialmente mais complexos pois a rede pode “memorizar” pacotes e trocar-lhes a ordem

rede

canal físico de dadosrouter router

routerrouter hosthost


Transporte versus Data-link

• Endereçamento e eventual necessidade de multiplexagem é mais complexa ao nível transporte

• A rede tem capacidade de bufferização e pode trocar a ordem dos segmentos

• O estabelecimento da conexão é mais complexo devido aos dois factores anteriores

• O dinamismo da rede tem implicações delicadas sobre a performance do nível transporte tendo que se introduzir mecanismos não só de controlo de fluxos, como também de controlo da saturação


O segmento TCP

source port dest port

32 bits

Dados (variável)

sequence numberacknowledgement numberrcvr window size

ptr urgent datachecksum

FSRPAUheadlen

notused

Opções (variável)

URG: urgent data

ACK: o campo de ACK é válido

PSH: push data now

RST, SYN, FIN:(Comandos de

controlo da conexão)

Nº de bytes que o receptor pode aceitar

Contadores em bytes (não em segmentos!)

Internetchecksum

Flags:


Alguns dados sobre o cabeçalho

• Um segmento TCP tem no máximo 65535 - 20 - 20 bytes de dados

• Os números de sequência são dos bytes transmitidos; o ack number denota o próximo byte esperado e não o último correctamente recebido

• THL - TCP Header Length, indica o número de palavras de 32 bits do cabeçalho e é necessário devido às opções

• O campo Flags permite passar informação de controlo• Window size permite indicar à outra extremidade quanto

espaço há livre no buffer de recepção do emissor; o valor 0 é legal e permite indicar que o emissor está saturado

• O campo das opções permite negociar o MTU a usar na conexão, assim como outras opções como por exemplo “window scale option” e a utilização de “negative acknowledgements”; também é usado para “echo e echo reply probings”


Flags e segmentos de controlo

Cada segmento pode ou não ter flags posicionadas. Um segmento com flags posicionadas e sem dados é só de controlo. As flags são:

ACK - Acknowledgement field is validRST - Reset the connection (idem reject)SYN - Synchronyze sequence numbers (abertura da

conexão com SYN = 1 e ACK = 0)

FIN - Sender has reached the end of its byte stream (fecho

da conexão)URG - Urgent pointer field is validPSH - This segment requests a PUSH (o receptor não

deve “buferizar” estes dados à espera de mais e deve

entregá-los imediatamente à aplicação)

Os segmentos com SYN e FIN têm números de sequência para poderem ser repetidos em caso de perca e para ambas as partes se colocarem de acordo sobre os valores iniciais.


A gestão dos timeouts em TCP

P: Como determinar o valor do timeout ?

• Maior que o RTT

• mas o RTT é variável !

• Demasiado curto: timeout prematuro

• Retransmissões desnecessárias

• Demasiado longo: reacção lenta à perca de segmentos

P: Como determinar o RTT?

• RTTmedido: medir o tempo que medeia entre a transmissão e a recepção do ACK

• Ignorar as retransmissões e os segmentos cumulativamente ACKed

• O valor medido irá variar, pretende-se um RTT estimado menos sujeito a picos (smoother ou “alisado”)

• Usar várias medidas e fazer médias, não usar apenas o último valor lido


Distribuição do valor do RTT

Distribuição da probabilidade do valor do RTT (round trip time) num canal físico (à esquerda) e na Internet (à direita)

probabilidade

RTT (ms)

probabilidade

RTT (ms)

0.1

0.2

0.3

Verifica-se que em função da carga da rede, existe uma grande variância do RTT. Para uma rede carregada a 50% o RTT pode variar num factor de 4, mas para uma rede carregada a 90% o RTT pode variar num factor de 16 !

0.1

0.2

0.3


Exemplo da situaçãoRTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT (milliseconds)

SampleRTT Estimated RTT


Round Trip Time e Timeout

Cálculo do RTT:• Trata-se de uma amostragem pesada• A influência da última amostra decresce exponencialmente

• Valor típico de : 0.125

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

Valor do timeout a usar:• RTTestimado mais “margem de segurança”• Grande variação do RTTestimado -> maior margem de segurança

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|(tipicamente, = 0.25)TimeoutInterval = EstimatedRTT + 4*DevRTT


Outros aspectos da gestão do timeout

• O RTT dos segmentos retransmitidos não é usado para a estimativa do valor do timeout

• Sempre que se perde um segmento o valor do timeout usado é duplicado momentaneamente


Gestão dos números de sequência

Nºs de sequência:

• Nº do primeiro byte presente no segmento

ACKs:

• Nº de sequência do próximo byte esperado pelo receptor

• ACK cumulativo

P: como são geridos os segmentos recebidos fora de ordem ?

R: não faz parte da especificação de base

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

O utilizador escreve ‘C’

host A recebe o‘C’ ecoado

host Brecebe

‘C’, ecoa ‘C’

tempoCenário com telnet


Gestão de ACKS [RFC 1122, RFC 2581]

Evento

Segmentos recebidos sem buracos, todos os segmentosanteriores já ACKed

Segmentos recebidos sem buracos, todos os segmentosanteriores já ACKed menos um

Segmento fora de ordem gerando um buraco

Chegada de um segmento que preenche parcial ou totalmente um buraco

Acção do receptor

delayed ACK. Esperar até 500mspor outro segmento. Se este não chegar enviar ACK

Enviar imediatamente um ACK cumulativo

Enviar ACK duplicado, indicando o nº de sequência do próximo byte esperado (o 1º do 1º buraco)

Envio imediato de um ACK cumulativo


Host A

Seq=100, 20 bytes data

ACK=100

time

Host B


ACK=120


Seq=

92

tim

eout

ACK=120

Host A


ACK=100

loss

tim

eout

Host B

X


ACK=100

time

Seq=

92

tim

eout

SendBase= 100

SendBase= 120

SendBase= 120

Sendbase= 100

Cenários de retransmissão

Perca de um ACKTimeout prematuro,ACKs cumulativos


Host A


ACK=100

loss

tim

eout

Host B

X


ACK=120

time

SendBase= 120

Cenário com ACK cumulativo


Retransmissão rápida

O time-out é em geral muito longo: Assim a recuperação de um segmento perdido é lenta

A recepção de ACKs duplicados pode ser interpretada como um NACK

O emissor envia muitos segmentos seguidos Se um se perder, aprecerão muitos ACKs repetidos.

Se o emissor receber 3 ACKs com o mesmo número de sequência:

fast retransmit: reenviar os segmentos antes de o time-out expirar


Controlo de fluxos

Receptor: informa explicitamente o emissor do espaço livre no buffer de recepção • Campo RcvWindow no

segmentoEmissor: evita que a

dimensão dos dados ainda não confirmados (unACKed) ultrapasse o valor de RcvWindow

O emissor não satura os buffers do receptor por transmitir muito ou

muito depressa

Controlo de fluxo

Buffer do receptor

RcvBuffer = tamanho do Buffer de recepção

RcvWindow = espaço livre no Buffer


Estabelecimento da conexão

Three way handshake:

1: o cliente envia um segmento de controlo com a flag SYN posicionada para o servidor• Com o nº de sequência inicial do cliente

2: o servidor recebe o SYN, responde com um segmento de controlo com as flags SYN e ACK, isto é:

• ACK do SYN• Inicia o buffer• Especifica o nº de sequência inicial do servidor

3: o cliente responde com um segmento de ACK


Funcionamento

Host A Host B

SYN (seq = x )

SYN, ACK (seq=y, ack=x+1 )

Data, ACK (seq=x+1, ack=y+1 )

Tempo


Números de sequência inicial

• É essencial que, dadas as características da rede, os pacotes atrasados de uma conexão fechada não sejam interpretados como pacotes válidos de uma nova conexão entre os mesmos sockets. As técnicas usadas para lidar com este tipo de problema são uma ou mais das várias apresentadas a seguir:

• Ao fechar-se normalmente uma conexão espera-se o “Maximum Network Packet Life Time” ( MNPLT) antes de libertar as portas e os números de sequência (“estado TIME-WAIT” no fecho de um socket que dura 30 segundos).

• Após o “boot” espera-se o MNPLT

• Determinar o MNPLT adequado é delicado, o que conduz a valores muito elevados deste parâmetro, e portanto desinteressantes (actualmente vale 3 minutos)

• Usa-se um relógio monotonicamente crescente para gerar os números de sequência iniciais o que exige números de sequência com muitos bits se os canais admitem grandes velocidades de transmissão

• Usam-se números pseudo-aleatórios (usando o relógio da máquina como ponto de partida)


Fecho da conexão com um protocolo assimétrico

Host A Host B

data

disconnect request

data

Tempo

Este protocolo conduziria à quebra abrupta de conexões com perca de dados


Fecho da conexão TCP

Host A Host B

disconnect request (FIN, seq = x )Tempo

ack ( ACK, ack = y+1 )

ack ( ACK, ack = x+1 )

disconnect request (FIN, seq = y, ack = x+1 )timeout

fim


Evolução do estado de uma conexão

TCP clientlifecycle

TCP serverlifecycle


Princípios do controlo da saturação

• Saturação:• informalmente: demasiados pacotes estão a

ser injectados na rede para a capacidade que esta tem de os encaminhar

• diferente de controlo de fluxos!• sintomas:

• Perca de pacotes (buffers com overflows)• Tempos de trânsito elevados (filas de

espera de dimensão elevada – queueing)• Tempos de trânsito com uma grande

instabilidade (a rede está em “rotura” e tem comportamentos limite)


Origens/custos da saturação

• A saturação da rede implica um aumento significativo do tempo de trânsito dentro da rede

• Este aumento do tempo de trânsito conduz ao aumento das retransmissões

• Muitas dessas retransmissões revelam-se inúteis, pelo que conduzem a um desperdício da capacidade da rede

• Devido também ao aumento das filas de espera, muitos pacotes são suprimidos. Cada pacote suprimido no interior da rede implica o desperdício da capacidade da mesma até aí consumida

• Em condições de saturação da rede, o rendimento desta começa a decair e a percentagem da sua capacidade que é aproveitada de forma útil decai também


Conclusões

A saturação:• conduz a um comportamento em que o rendimento

da rede decresce rapidamente• tem por sintomas: perca de pacotes, tempos de

trânsito elevados, tempos de trânsito com uma grande instabilidade


Como lidar com a saturação ?

• O equipamento de rede lida com a saturação suprimindo os pacotes que não consegue encaminhar

• No entanto, tal medida não permite maximizar o rendimento da rede

• Uma supressão indiscriminada e inadequada pode até contribuir para o agravamento da situação

• É necessário encontrar formas de adaptar a procura à oferta e tal passa necessariamente por os hosts abrandarem o ritmo de geração de novo tráfego

• Os hosts têm pois de ser notificados ou pelo menos reagirem à saturação


Aproximações ao controlo da saturação

End-end:• Os routers não dão

feedback explícito da saturação

• O host final é que se apercebe da saturação pelo aumento do tempo de trânsito e pela perca de pacotes

• Aproximação usada pelo protocolo TCP

Network-assisted:• Os routers dão feedback

explícito sobre a saturação aos hosts:• Um bit assinala a

saturação (SNA, DECbit, TCP/IP ECN, ATM)

• É eventualmente explicitado o ritmo a que o emissor deve transmitir

Existem duas classes de aproximações (e também utilizações conjuntas das mesmas):


Controlo da saturação do protocolo TCP

• Controlo extremo a extremo (“end-end” - sem suporte explícito da rede)• Ritmo de transmissão dos segmentos condicionado pelo “congestion

window size”, Congwin:

• Janela com W segmentos, cada um com MSS bytes, transmitidos em cada RTT, conduzem ao seguinte ritmo de transmissão:

throughput = w * MSS

RTT Bytes/sec

Congwin


Filosofia do controlo da saturação em TCP

• “Probing” da banda passante disponível: • Transmitir tão rápido quanto possível sem perca

de segmentos• Ir incrementando a janela até à perca de

segmentos (saturação)• Perante a perca, decrementar a janela e depois

recomeçar a fazer “probing”

• Duas fases• Slow start• Congestion avoidance

• Variáveis importantes:• Congwin (janela de saturação)• Threshold (limite)


Gestão da janela do emissor do ponto de vista da saturação – Slow start

Maximum allowed window = minimum (Receiver window,Congwin )

A congestion window é gerida da seguinte forma durante esta fase:

1) No início ou após um período de saturação, o valor é igual a um segmento (equivalente ao MSS – “Maximum Segment Size”)

2) Por cada ACK chegado ao receptor (acked), Congwin é incrementada de 1 MSS (logo, duplica em cada RTT)

Esta estratégia conduz a uma subida exponencial do valor de Congwin. Quando surge um timeout, anota-se o valor na variável Treshold e inicializa-se Congwin ao valor do MSS de novo.


Aumento exponencial (por RTT) da dimensão da janela

início: Congwin = 1para (cada segmento ACKed) Congwin = Congwin+1 MSSaté (loss event OR CongWin > Threshold)

Slowstart algorithmHost A

one segment

RTT

Host B

time

two segments

four segments

TCP “Slowstart”


/* slowstart acabou pois */ /* Congwin > threshold */Até (loss event) { por cada w segments ACKed: Congwin++ }threshold = Congwin/2Congwin = 1Recomeçar a fase slowstart

Congestion avoidance

Segunda fase – subida linear


O Algoritmo descrito tem a designação de TCP Tahoe. A variante corrente, designada por Reno, trata a perca de um pacote isolado (assinalada por aparecerem 3 ACKs seguidos da mesma sequência) de forma diferente.

Com TCP Reno, quando a perca isolada de um pacote é detectada, a Congwin é reduzida a metade mas a fase “slow start” é evitada entrando-se logo na fase de subida linear (“congestion avoidance”).

Existem outras variantes mais modernas deste algoritmo (Vegas, etc.)

Variantes


Tahoe e Reno


Visão sintética

Se a CongWin está abaixo de Threshold, o emissor está na fase slow-start, a janela cresce exponencialmente.

Quando a CongWin está acima de Threshold, o emissor está na fase congestion-avoidance, a janela cresce linearmente.

Se ocorre um triple duplicate ACK, Threshold = CongWin/2 e CongWin = Threshold.

Se ocore um timeout, Threshold = CongWin/2 e CongWin = 1 MSS.


Acções

Event State TCP Sender Action Commentary

ACK receipt for previously unacked data

Slow Start (SS)

CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance”

Resulting in a doubling of CongWin every RTT

ACK receipt for previously unacked data

CongestionAvoidance (CA)

CongWin = CongWin+MSS * (MSS/CongWin)

Additive increase, resulting in increase of CongWin by 1 MSS every RTT

Loss event detected by triple duplicate ACK

SS or CA Threshold = CongWin/2, CongWin = Threshold,Set state to “Congestion Avoidance”

Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS.

Timeout SS or CA Threshold = CongWin/2, CongWin = 1 MSS,Set state to “Slow Start”

Enter slow start

Duplicate ACK SS or CA Increment duplicate ACK count for segment being acked

CongWin and Threshold not changed


Filosofia do TCP perante a saturação real

• O protocolo TCP procura encontrar um ponto de equilíbrio que permita extrair o máximo de rendimento da rede sem provocar saturação

• Quando a rede está saturada, o desvio padrão do RTT começa a aumentar significativamente, pelo que o valor do timeout usado também aumenta significativamente

• Ao mesmo tempo perdem-se pacotes pelo que Congwin tem frequentemente o valor de um MSS e o valor do time-out é duplicado

• Este conjunto de factores conduz a que o desempenho das ligações TCP nestas circunstância seja muito afectado


Variação da janela

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

Long-lived TCP connection


Desempenho do TCP

• Quando a janela tem a dimensão W (em bytes) e está estável, a taxa ou velocidade de transmissão ou capacidade, da conexão TCP, é:

W / RTT

• No entanto, a conexão nunca tem o mesmo valor de janela pois o TCP tentaria aumentar a mesma. Admitindo que o valor máximo que não provocaria saturação fosse W, quando a janela tiver W+MSS aparece um timeout e a mesma é reduzida a W/2, pelo que, desprezando a fase de slow start, a taxa de transmissão da conexão fica reduzida a:

W / 2 . RTT

• Assim, dado o valor da janela variar constantemente entre W / 2 e W, pode-se considerar que em velocidade de cruzeiro a taxa de transmissão da conexão TCP será:

0,75 . W / RTT

• W / RTT é a fracção máxima da capacidade da rede que a conexão poderia usar.


Equidade (“Fairness”) do protocolo TCP

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

Se o protocolo TCP for equitativo, então se N conexões TCP partilham um link, cada uma deveria obter 1/N da capacidade do link


Ilustração intuitiva

Duas conexões:• Consideremos que cada uma está já na fase “congestion avoidance”

• Sempre que há perca de pacotes o valor de Treshold é dividido por 2

R

R

equal bandwidth share

Connection 1 throughputConnect

ion 2

th

roughput

congestion avoidance: additive increase

loss: decrease window by factor of 2congestion avoidance: additive

increase

loss: decrease window by factor of 2


Conclusão

• Se a rede só tivesse tráfego TCP, os canais seriam partilhados com bastante equidade (“fairness” ou justiça)

• Tal não é verdade pois existem outros tipos de tráfego (UDP)

• A saturação penaliza o tráfego TCP mais do que outros tipos de tráfego

• Uma aplicação que use várias conexões TCP em paralelo obtêm uma fracção mais significativa da banda do que uma que só utilize uma conexão

• Este aspecto é tanto mais verdade quanto mais saturada estiver a rede

cap. 3 – o nível de transporte. material de suporte às aulas de redes de computadores de j....

Documents