Protocolos de Transporte Tcp e Udp

Camada de Transporte TCP/IP

Unidade Curricular de Arquitectura InternetLicenciatura em Engenharia Informática – 1º Ciclo Bolonha

2º Ano – 4º SemestreAno lectivo 2008-2009

1

Ano lectivo 2008-2009

Alexandre Fonte([email protected])

Nota Prévia

� Este material é uma versão actualizada e adaptada à presenteunidade curricular, baseada nas versões criadas pelo ProfessorDoutor Osvaldo Santos, o Lic. Vasco Soares e por mim própriopara utilização durante anos lectivos anteriores em UnidadesCurriculares, com tópicos relacionados, de cursos ministrados noDepartamento de Engenharia Informática, ESTCB-IPCB.

� Sumário� Serviços e Protocolos de Transporte � Objectivos dos Protocolos de Transporte� Transporte não orientado à ligação: Protocolo UDP

� Características do UDP

� Porquê usar UDP? vantagens UDP

Camada de Transporte TCP/IP

� Porquê usar UDP? vantagens UDP

� Estrutura do Segmento UDP

� Transporte Orientado à ligação: Protocolo TCP� Características do TCP� Estrutura do Segmento TCP� Gestão de ligações TCP� Transmissão de Dados� Controlo de fluxo TCP� Controlo de Congestão TCP

Serviços e Protocolos de Transporte

� Oferecer um comunicação lógica entre processos aplicacionais (e.g., Cliente-Servidor) em execução em diferente hosts.

� Os protocolos de transporte são executados nos sistemas finais� Lado Emissor: divide as mensagens

das aplicações em segmentos e

application

transportnetworkdata linkphysical

networkdata link

networkdata linkphysical

networkdata linkphysicalnetwork

data linkphysical

das aplicações em segmentos e passa-os a camada de rede (i.e., ao IP)

� Lado receptor: reassembla os segmentos nas mensagens e passa-as à camada da aplicação.

� Na Internet estão disponíveis às aplicações dois protocolos de transporte:

� O TCP (Transmission Control Protocol e o UDP (User Datagram Protocol)

application

transportnetworkdata linkphysical

networkdata linkphysical

data linkphysical

Camada de Rede vs Camada de Transporte

� Camada de Rede: Comunicação lógica entre máquinas� Camada de Transporte: Comunicação lógica entre processos

� Confia nos serviços da camada de rede.� Melhora os serviços da camada de rede.

� Principais Objectivos de um protocolo de transporte� Garantir a integridade do fluxo de dados (orientação à ligação).

� Mecanismos de detecção e recuperação de pacotes fora de ordem.� Mecanismos de recuperação de erros e perdas.

� Garantir a entrega dos pacotes à aplicação correcta.Mecanismos de identificação da aplicação de destino dos pacotes.

Camada de Transporte

6

� Mecanismos de identificação da aplicação de destino dos pacotes.

� Garantir a eficiência da transmissão de dados.� Mecanismos que garantam um atraso baixo sem degradar o

overhead da rede.

� Controlo de Fluxo e Controlo de Congestão� Evitar congestionar o Receptor� Evitar congestionar a Rede e o Receptor

� Mecanismo de Númeração (Números de Sequência)� Resolve-se através de numeração dos pacotes e associação de cada

pacote a uma determinada posição.

Emissor Receptor

Camada de Transporte: Mecanismos de recuperação de Recuperação de Pacotes Fora de Ordem

7

10

21024

32048

43072

54096

65120

76144

7168

01

10242

20483

30724

40965

51206

61447

7168

7 43

2 1

Rota

65

Camada de Transporte: Mecanismos de recuperação de erros e perdas

� Uso de somas de control (checksums) – Detecção de pacotes corrumpidos

� Uso de mecanismos de retransmissão� números de confirmação (acknowledgment) � timers de retransmissão (retransmission time-out timers, RTO)� Janela deslizante

� Controlo de fluxo e melhor utilização de LB da rede

� Confirmações e Retransmissões� Para garantia fiabilidade cada pacote enviado deve ser confirmado � Se um ACK não for recebido dentro de um certo intervalo de

tempo o emissor retransmite o pacote


9

RTOExemplo:stop-and-wait

� Príncipios Janela deslizante� No exmplo, anterior apesar de garantir

fiabilidade não garante uma boa utilização da largura de banda disponível

� Solução: utilização de uma janela deslizante!� Podem ser enviado n pacotes até à dimensão

da janela� Um RTO timer é associado a cada pacote

enviado


10

2 3 4 5 6 710 2102 3 4 5 6 710

Janela de tamanho 7

Pacotes não enviadosPacotes enviados

e confirmados

Pacotes enviados mas não confirmados

Um RTO timer é associado a cada pacote enviado

� O emissor desliza a janela após a recepção de um ACK

� Conceito de Porto (1) - Capacidade de distinguir múltiplos destinos (aplicações) numa mesma máquina.

� Resolve-se associando cada pacote a uma determinada aplicação através de ‘ports’. Cada pacote terá assim um campo com o port de destino.

� Trata-se do mecanismo através do qual as aplicações distintas contactam o TCP.� O porto é uma palavra de 16 bits.

Camada de Transporte: Mecanismo de entrega à aplicação destino

P1 P1P2P4 P5 P3

11

ClienteIP:B

P1

clienteIP: A

P1P2P4

servidorIP: C

PF: 9157PD: 110

PF: 9157PD: 25

P5 P3

IP-D:C

IP-F: AIP-D:C

IP-F: B

PF: 5775PD: 80

IP-D:C

IP-F: B

110 25 80

� Conceito de Porto (2)� Existem portos em UDP e TCP (espaços de identificação separados).

� 65536 portos para o UDP (do 0 ao 65535).� 65536 portos para o TCP (do 0 ao 65535).

� Valor de 16 bits - 0 a 65535.Well Known Ports (WKP) - de 0 a 1023.

Camada de Transporte: Mecanismo de entrega à aplicação destino

12

� Well Known Ports (WKP) - de 0 a 1023.� Portos para os uso dos programadores superiores a 1023, embora muitos

deles estejam registados para múltiplos protocolos. � (ver http://www.iana.org/assignments/port-numbers)

0-1023 49152-655351024-49151

Well-known Registados Dinâmicos ou privados

Portos� Um host recebe datagramas IP

� Cada datagrama possui um endereço IP fonte, um endereço IP destino

� Cada datagrama transporta 1 segmento da camada de transporte

� Cada segmento possui possui um porto fonte, um

Porto fonte# Porto dest. #

32 bits

Outros campos cabeçalho

possui um porto fonte, um porto destino

� Um host usa os endereços IP & os números dos portos para despachar o segmento para o socket apropriado

Dados aplicação(mensagem)

Formato segmento TCP/UDP

� Protocolo simples, não é orientado à ligação.� Não existe handshaking entre o emissores e receptores UDP. � Cada segmento UDP é manipulado independentemente dos outros.

� Trabalha em modo datagrama:� Cada pedido da aplicação gera um datagrama;� Não existe confirmação da recepção dos datagramas.

UDP – User Datagram Protocol

14

� Fornece um serviço best-effort serviço, não fiável (igual ao do IP), os segmentos UDP podem ser:� Perdidos - Sem mecanismo de controlo de erros (acknowledge);� Entregues fora de ordem ou em duplicado.

� Multiplexagem de canais lógicos utilizando o conceito de porto.

(Para saber mais … Cap. 11 do Livro TCP/IP Illustrated)

Porquê usar UDP? vantagens UDP

� Não existe o estabelecimento de ligação lógica entre processos (a qual introduz atrasos)

� Simples: não necessita de guardar o estado das ligações em ambos os lados.

� O segmento UDP possui um cabeçalho de tamanho reduzido (menores tempos de processamento do cabeçalho).

� Sem mecanismos de controlo de fluxo.� Sem controlo de congestão: o UDP pode transmitir tão rápido o � Sem controlo de congestão: o UDP pode transmitir tão rápido o

emissor desejar.� Frequentemente usado por aplicações streaming multimedia:

� Tolerantes a perdas� Sensiveis à taxa de transmissão

� Os fluxos UDP possuem “sempre” o mesmo débito� Os fluxos TCP diminuem o débito em situações de congestão – débitos variáveis

(qualidade variável)

� Usado em serviços que não exigem fiabilidade: � DNS� SNMP

Bit: 0 16 31

Port de origem(16 bit)

Comprimento UDP(16 bit)

Port de destino(16 bit)

Checksum(16 bit)

Dados(variável)

Máximo

65515 bytes

Datagrama/Segmento UDP

16

(variável)

� Port de origem: identifica a aplicação que transmitiu este datagrama.� Port de destino: identifica a aplicação a que se destina este datagrama.� Comprimento UDP: comprimento do datagrama, incluindo o cabeçalho.� Checksum: usado para detectar erros no cabeçalho e campo de dados

(também se entra em linha de conta com os campos de endereço do cabeçalho IP para verificar se o datagrama está a ser entregue no endereço correcto).

� Dados: dados transmitidos entre as duas aplicações.

Exemplos de Portos UDP reservados (WKP)

17

TCP – Transmission Control Protocol� TCP (Cap. 17 do Livro TCP/IP Illustrated)� Gestão das Ligações TCP (Cap. 18 do Livro TCP/IP Illustrated)� Transmissão de Dados (Cap. 19 e 20 do Livro TCP/IP � Transmissão de Dados (Cap. 19 e 20 do Livro TCP/IP

Illustrated)� Controlo de Fluxo e Controlo de Congestão (Cap. 20 e 21 do

Livro TCP/IP Illustrated)� RTT e Timeout (Cap. 21 do Livro TCP/IP Illustrated)

� Estabelecimento de ligação - canais virtuais (modo circuito).� Protocolo complexo, orientado à ligação:

� Estabelecimento da ligação;� Transferência de dados;� Fecho da ligação.

� Fornece serviço fiável end-to-end:

TCP – Transmission Control Protocol (1)

19

� Fornece serviço fiável end-to-end:� Mecanismo de Numeração (Usa números de Sequência)� Mecanismo de controlo de erros (checksum e acknowledge);

� Um timer para cada segmento (retransmissão implícita);� Mecanismo de controlo de fluxo (campo window);� Mecanismo de controlo de congestão

� Multiplexagem de canais lógicos utilizando o conceito de porto.� Transfere streams (fluxo) de bytes sem estrutura.

(Para saber mais … Capítulo 17 do Livro TCP/IP Illustrated Vol. 1)

� Comunicação Ponto-a-Ponto� Um emissor, Um receptor

� Comunicação nos dois sentidos em simultâneo (full-duplex).� “Bufferização” dos dados enviados e recebidos.� Define byte como unidade de transferência os quais são

transferidos em segmentos.

TCP – Transmission Control Protocol (2)

20

� É o protocolo de transporte da maior parte das aplicações da Internet (WWW, E-mail, IRC, FTP, Telnet, etc..).

� Utiliza os serviços IP.

Funcionamento Básico TCP & Buffers de Emissão e Recepção

Processoemissor

ProcessoRecepção1 - Estabelecimento de ligação

2 - Transmissão de dados

(full duplex)

3 - Fecho de ligação

Segmentos TCP

Bit: 0 16 31

Port de origem(16 bit)

Port de destino(16 bit)

Número de sequência(32 bit)

Número de confirmação(32 bit)

Formato do Segmento TCP

22

Checksum(16 bit)

Ponteiro urgente(16 bit)

Dados(variável)

Máximo

65515 bytes

(32 bit)

Header len(4 bit)

FIN

SYN

RST

PSH

ACK

URG

Reservado(6 bit)

Tamanho da janela Recepção(16 bit)

Opções (se existirem)(32 bit)

� Port de origem: identifica a aplicação que transmitiu este segmento.� Port de destino: identifica a aplicação a que se destina este segmento.� Número de sequência: identifica a posição do primeiro byte de dados

deste segmento no fluxo de dados.� Número de confirmação (ACK): identifica a posição do byte que o

emissor deste segmento está à espera de receber.� Header length: número de blocos de 32 bit do cabeçalho (tamanho).

Significado dos Campos do Cabeçalho TCP

23

� Header length: número de blocos de 32 bit do cabeçalho (tamanho).� Flags: várias flags que determinam várias acções especiais.� Tamanho da janela (W): tamanho da janela de recepção.� Checksum: usado para detecção de erros no cabeçalho TCP e dados.� Ponteiro urgente: aponta para uma posição no campo de dados que

contém informação urgente; só é válido activando a flag URG.� Dados: dados transmitidos entre as duas aplicações.

Números de Sequência & ACKs

� Os bytes de Dados a serem transferidos em cada ligação são numerados pelo TCP. A numeração começa com um número gerado aleatoriamente (ou mais simplesmente por 0).

� 32 bits� 0 ≤ SN ≤ 232-1

� Quando é recebido um segmento com número de confirmação, ack=i, isso significa que:ack=i, isso significa que:� São confirmados todos os bytes até ao byte i-1;

� Quando é recebido um segmento com o Tamanho da Janela de Recepção, W=j, e ack=i, isso significa que:� Podem ser enviados ser enviados j bytes;� Ou seja, podem ser enviados os byte de i até i+j-1

[Mais à frente abordaremos novamente este assunto no âmbito do controlo de fluxo]

Host A Host B

Utilizador escrever‘C’

host B confirma a recepção de ‘C’,envia o echo ’C’ a A


host A recebe e confirma o echo ‘C’

tempoUma simples sessão telnet


� Exercicio: Suponha que pretende-se numa ligação TCP transferir um ficheiro de 5000 bytes. O primeiro byte é numerado com 10001. Quais são os números de sequência para cada segmento se os dados forem enviados em 5 segmentos, cada transportando 1000 bytes?

Solução :

Segmento 1– Nr. de Sêquencia: 10,001 (gama: 10,001 a 11,000)





� URG: significa que o campo ‘ponteiro urgente’ é válido

� ACK: significa que o campo ‘número de confirmação’ é válido.

Significado das flags do Campo Controlo

27

� PSH (PUSH): significa que o receptor deve passar estes dados à aplicação o mais rapidamente possível.

� RST: deve executar-se um reset à ligação.

� SYN: sincroniza os números de sequência (sequência e confirmação) de modo a iniciar uma ligação.

� FIN: indica que o emissor não tem mais dados para enviar ao receptor.

Exemplos de Portos TCP Reservados (WKP)

28

Em Linux/UNIX, os porto bem-conhecidos são guardados numficheiro /etc/services. Cada linha neste ficheiro gurda o nome doserviço e o número do porto. Pode-se usar o comando grep paraextrair a linha correspondente ao serviço desejado.

Exemplos de Portos TCP Reservados (WKP)

29

$ grep ftp /etc/services

ftp-data 20/tcpftp-control 21/tcp

� Estabelecimento de uma ligação TCP: É usado um Three way handshake (aperto de mão triplo)Passo 1: O Cliente TCP envia um segmento TCP SYN

ao servidor:� Especifica o número de sequência inicial SN=# e o porto do

servidor ao qual se pretende ligar.� Um segmento SYN não transporta dados, mas consome um

número de sequência.

Passo 2: O servidor TCP que recebe o segmento SYN,

Cliente Servidor

Gestão de Ligações TCP (1)

30

Passo 2: O servidor TCP que recebe o segmento SYN, responde com um SYNACK segment

� Confirma a recepção do segmento SYN (os segmentos SYN consomem um número) activando a Flag ACK e indicando o próximo nr de seq a receber.

� Especifica o número de sequência inicial SN=# do servidor� Um segmento SYNACK não transporta dados, mas consome

um número de sequência. � O servidor aloca um buffer de recepção.

Passo 3: O Cliente recebe o segmento SYNACK e confirma a sua recepção com um segmento ACK.

� Um segmento ACK pode ou não transportar dados. Senão transportar dados não consome um número de sequência.

� Anúncio do MSS (Maximum Segment Size)� É o tamanho máximo do campo de dados de um

segmento TCP� Quando a ligação é estabelecida, cada extremo

anuncia o seu MSS.� As estações usam a opção MSS� A opção MSS apenas aparece pode aparecer nos

segmentos SYN� Se o MSS não for anunciado, o outro extremo

assume MSS=536byte (pois o tamanho de defeito

Cliente Servidor


31

assume MSS=536byte (pois o tamanho de defeito de um pacote IP é 576bytes)

� Na Ethernet, o MSS é 1460bytes pois o MTU=1500bytes

Cliente Servidor� Fecho de uma ligação TCP

Passo 1: Quando um dos nós (neste caso o cliente) não tem mais dados para transmitir, envia um segmento FIN.

Passo 2: O servidor recebe o segmento FIN e confirma a sua recepção com um segmento ACK. Quando o servidor não tem dados para enviar, solicita o fecho da ligação enviando também um segmento FIN.


32

também um segmento FIN.

Passo 3: O cliente confirma a recepção do segmento FIN com um segmento ACK.

Passo 4: O servidor receive o segmento ACK e termina o processo de fecho de ligação.

� Uma vez que a transmissão de dados é feita em full-duplex, este processo termina a ligação em cada um dos sentidos de uma forma independente.

� A este processo chama-se “half-close”.

� Recusa de uma Ligação TCP


� Abortar uma Ligação TCP (Reset)


Cenário comum

� Fluxo de Dados Interactivos (TCP Interactive Data Flow)� Existe troca frequente de mensagens curtas entre os dois nós.� Exemplo: sessão de telnet ou aplicação de ‘chat’.� Requisitos: atraso baixo, taxa de transferência não é importante.

Transmissão de Dados

36

� Fluxo de Dados Não Interactivos (TCP Bulk Data Flow)� Fluxo de dados, tipicamente num único sentido, com o objectivo de

transmitir uma elevada quantidade de informação.� Exemplo: transferência de ficheiros.� Requisitos: taxa de transferência elevada, atraso não é importante.

(Capítulos 19 e 20 do Livro TCP/IP Illustrated Vol. 1)

� Exemplo Clássico: rlogin� Por exemplo, na aplicação rlogin, é gerado tráfego interactivo. Por

cada tecla premida podem ser gerados quatro (!) segmentos TCP.� Este tipo de tráfego apresenta um overhead considerável, uma vez

que para transmitir um único caracter, são necessários 41 octetos em cada segmento (20 do header IP + 20 do header TCP + 1 dados) e um total de 4 segmentos.

TCP – Fluxo de dados Interactivos

37

Cliente Servidor

Tecla premida

Visualização do caracter

Cliente Servidor

� Delayed acknowledgements (atraso na confirmação) ou ACK piggyback com dados� Sempre que um nó recebe um segmento, a confirmação não é feita imediatamente,

é esperado um período de tempo na esperança da confirmação ser enviada juntamente com um segmento de dados.


38

Cliente Servidor

Período de atraso, tipicamente 200 ms

(Ack atrasado)

� Algoritmo de Nagle� Determina que só se deve enviar um segmento após a recepção da confirmação do anterior.� Permite juntar vários blocos de dados num único segmento, diminuindo o overhead na rede à custa

do aumento do atraso de entrega dos dados. Isto poderá ser limitado pelo MTU e pela dimensão da TCP window.

� Quanto mais rápido chegam os ACKS mais rápido são enviados os dados. Um ACK poderá confirmar n bytes.

� Ajusta-se automaticamente à rede. Se a rede possuir um atraso baixo (caso de uma LAN) as confirmações chegam rapidamente e este algoritmo não produz nenhum efeito. No caso das WAN,


39

Cliente Servidor

dados

dados

dados

dados

dados

Aplicação

confirmações chegam rapidamente e este algoritmo não produz nenhum efeito. No caso das WAN, mais congestionadas, poucos segmentos são gerados.

Certas aplicações, contudo, exigem que o algoritmo Nagle seja desabilitado:

E.g., aplicações de remote Desktop ou X Window server para capturar os movimentos do rato em tempo real

Cliente Servidor

� Exemplo de transferência de um ficheiro de 8 KBytes em 8 segmentos com 1024 Bytes de dados.

� Nestes casos, durante o estabelecimento da ligação, no campo options, é também negociado o MSS (Maximum Segment Size)

� As confirmações são cumulativas.

Fluxo de Dados NÃO Interactivos

40

� As confirmações são cumulativas. � Confirmam a recepção correcta de dados até uma

determinada posição.

� Por vezes as confirmações estão ligeiramente atrasadas relativamente ao último segmento recebido, devido ao atraso na confirmação e atrasos no processamento dos pacotes recebidos.

� O mecanismo de janela deslizante é utilizado. � O tamanho da janela é medido em termos de número de

bytes e é anunciado por cada nó ao outro nó.

�� O mecanismo de controlo de Fluxo regula a quantidade de dados O mecanismo de controlo de Fluxo regula a quantidade de dados que uma fonte pode enviar antes da recepção de um que uma fonte pode enviar antes da recepção de um acknowledgment (ACK) do destino. acknowledgment (ACK) do destino.

�� O TCP define uma “variável” janela (window) imposta sobre o O TCP define uma “variável” janela (window) imposta sobre o buffer de emissão, cujo valor buffer de emissão, cujo valor ––o tamanho da janelao tamanho da janela-- depende da depende da velocidade do receptor, i.e.,velocidade do receptor, i.e.,

Controlo de Fluxo TCP (1)

Window<= velocidade do receptorWindow<= velocidade do receptor(no caso de não haver controlo de congestão)(no caso de não haver controlo de congestão)

Segmento de dados

Segmento de controlo

Emissor

Receptor

Buffer com dados


� O Receptor de uma ligação TCP aloca à ligação um buffer de recepção:

O emissor TCP tenta não esgotar o buffer

(overflow) do receptor tentando não transmitir pacotes em excesso, i.e., demasiado depressa

Controlo de Fluxo

Dados ProcessoReceptor

Rcvwindow

� Idealmente o rate de envio deverá ser ajustado/idêntico ao rate de leitura do buffer da aplicação consumidora.

� A aplicação lê do buffer a uma determinada velocidade, podendo conduzir à necessidade de abrandar a transmissão.

demasiado depressa

RcvBuffer

Dados do IP

Receptor(lê do buffer) Espaço livre

no buffer

Dados no

Buffer


� O Rcv anuncia o espaço livre no buffer através do campo RcvWindow nos segmentos.

� À medida que os dados vão sendo passados ao processo, a janela anunciada pode aumentar.

RcvBuffer

Dados do IP

Processoreceptor Espaço livre

no buffer

Dados no

Buffer

Rcvwindow

� O espaço livre no buffer: = RcvWindow

= RcvBuffer-[LastByteRcvd -LastByteRead]

aumentar.� O emissor limita os dados

transmitidos não confirmados unACKed à dimensão da RcvWindow

� Isto garantirá que o buffer do receptor não será

esgotado.

RcvBuffer

� Baseia-se no Controlo da Dimensão da Janela Deslizante em bytes (Sliding Window) – Lado Emissor� Á medida que são confirmados segmentos, mais precisamente bytes, o limite inferior

da janela desloca-se para a frente

2 3 4 5 6 710 2102 3 4 5 6 710

Window <=RcvWindow


Bytes não enviados e que não podem ser enviados

2 3 4 5 6 710 2102 3 4 5 6 710

Bytes não enviados, mas que podem ser enviados

Bytes enviados

e confirmados

Bytes enviados mas não confirmados

No exemplo window=7 <=Rcvwindow

A janela deslizante é usada para tornar a transmissão mais eficiente e para controlo do fluxo de dados de modo a que o receptor não fique sobrecarregado com dados.

No exemplo, na situação actual o tamanho da janela utilizável é 5


� Variáveis mantidas pelo Emissor� Tamanho da janela de transmissão (TJT) em bytes� Último ACK recebido (UAR)� Último byte enviado (USE)� USE – UAR <= TJT & TJT<=RcvWindow

TJT

2 3 4 5 6 710 2102 3 4 5 6 710

USEUAR

� Exercício 1: Qual é o valor da janela de recepção (rcvwindow) enviada para o emissor, computador A, se o receptor, computador B, tem um buffer de 4000 bytes e 1000 bytes dos dados recebidos ainda não foram processados?

Solução:


Dados Processo

1000bytesRcvwindow

RcvBuffer=4000 bytes

Dados do IP

Processo

Espaço livreno buffer

Dados no

Buffer

A rcvwindow é = 4000 − 1000 = 3000 bytes. Significa que o Computador B pode receber apenas 3000 bytes de dados antes do seu buffer sobrecarregar. O computador B anuncia este valor no próximo segmento para B.

Controlo de Congestão TCP

Noção de Congestão:� É um fenómeno inevitável� Informalmente definida: “demasiadas fontes TCP enviando demasiados dados

demasiado depressa para a rede manipular” (e.g., surge nas ligações entre LAN-WAN)

� Efeitos da Congestão da Rede:� Perdas de pacotes (devido a buffer overflow nos routers)� Longos RTTs (Round-Trip Times) (devido aos atrasos nas filas dos routers)

Atraso dos pacotes e carga na rede Débito

e carga na rede

Origem da Congestão

H1

R1 H3

A1(t)10Mb/s

D(t)1.5Mb/s

H2

1.5Mb/s

A2(t)100Mb/s

A1(t)

A2(t)X(t)

D(t)

� Efeitos da Congestão da rede (outra Vez)� Aumento do tempo de trânsito dos pacotes (RTT) devido ao aumento dos

tempos de atraso nas filas (buffers)Os timers associados aos pacotes expiram, provocando um aumento das

retransmissões, que por sua vez vão agravar ainda mais o congestionamento.

� Aumento das perdas de pacotes

↑ Tráfego => ↑carga => ↑ RTTs (& ↑ Perdas) => ↑ Retransmissões => ↑ ↑ Tráfego


49

↑ Tráfego => ↑carga => ↑ RTTs (& ↑ Perdas) => ↑ Retransmissões => ↑ ↑ Tráfego


� É do tipo end-end control (sem assistencia da rede)� Uma fonte TCP mantém uma variável

Congestion Window = Cwnd com o valor da janela de congestão

� O emissor limita a transmissão:

Como é que uma fonte TCP percebe a congestão?

� Evento perda de pacote = timeout ou 3 acks duplicados

� Uma fonte TCP reduz o rate (CongWin) após a detecção de um evento de perdaLastByteSent-LastByteAcked<=

CongWin

� Grosseiramente, a taxa de transmissão é: rate = CongWin/RTT Bytes/seg

� CongWin é dinâmica, função da congestão da rede

um evento de perda

Principais Mecanismos Standard de Controlo de Congestão TCP:� Slow start� AIMD (Congestion

Avoidance)

� As fontes TCP alteram a taxa de transmissão modificando o tamanho da janela de transmissão (i.e., da slidding window):

Max Window = min{Advertized rcv window, Congestion Window}

� Por outras palavras, enviam à taxa da componente mais lenta: a rede ou receptor.


ou receptor.

� Embora cwnd seja definida em bytes, na literatura frequentemente discute-se controlo de congestão em termos do número de pacotes, ou mais formalmente em número de MSS == Maximum Segment Size.

� MSS por defeito é 576bytes

Perda de um pacote (Indicador de Congestão)

� A perda de um pacote é detectada por: � Retransmission TimeOut (RTO timer)� ACKs duplicados (pelo menos 3)

1 2 3 4 5 6

Pacotes

71 2 3 4 5 6

1 2 3

Acknowledgements

3 3

7

3

RTT e Timeout (1)

Q: Como definir o valor de RTO?

� Deve ser maior que o RTT� Mas o RTT é variável

� Demasiado pequeno:� Reacção rápida� Conduz a retransmissões

desnecessárias

Q: Como estimamos o RTT? � AmostraRTT: tempo medido

desde da transmissão até à recepção do ACK

� A amostraRTT varia, deseja-se uma estimativa “suavizada”� E.g., usa-se a média de Conduz a retransmissões

desnecessárias� Demasiado longo:

� Reacção lenta às perdas de segmentos

� E.g., usa-se a média de várias amostras, e não apenas a única amostra

RTT e Timeout (2)

� Média móvel exponencial� Inclui a influência do passado� Valor típico: = 0.125

EstimativaRTT = (1- αααα)*EstimativaRTT + αααα*AmostraRTT

RTT: 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)

RT

T (

mill

isec

on

ds)

SampleRTT Estimated RTT

RTT e Timeout (3)

� Definição do Timeout� EstimativaRTT mais uma “margem segura”

� Grandes variações na EstimativaRTT -> maior margem de segurança

� Primeiro precisamos de estimar em quanto a AmostraRTT se desvia da EstimativaRTT:

ββββDevRTT = (1-ββββ)*DevRTT +ββββ*|AmostraRTT-EstimativaRTT|

(tipicamente, ββββ = 0.25)

Timeout:

RTO = EstimativaRTT + 4*DevRTT

Exercício 2: Qual é o tamanho da janela para uma fonte TCP se o valor de rwnd é 3000 bytes e o valor da cwnd é 3500 bytes?

SoluçãoO tamanho da janela é o valor mínimo entre rwnd e cwnd, o qual é 3000 bytes.


bytes.

Exercício 3: Imagine que uma fonte TCP pretende transmitir 1000bytes, tendo já enviado 202 bytes. Considerando que o receptor já enviou um segmento ack=200, com uma rwnd de 9 bytes. Determine:a) Qual o valor da janela assumindo que a cwnd actual é de 20bytes?b) Os bytes desde o byte 200 ao 202 já foram confirmados? c) Quantos bytes pode a fonte enviar a mais sem se preocupar com a confirmação? d) A partir de que byte a fonte não pode transmitir mais?


d) A partir de que byte a fonte não pode transmitir mais?e) Desenhe um diagrama com a posição actual da janela

Exercício 4 (cont. do ex. 3) Se o receptor enviou um ack=202, com uma rwnd=9, e a fonte TCP já enviou-lhe os bytes 203, 204 e 205, qual é a nova posição da janela assumindo que cwnd continua igual a 20 bytes?

� No algoritmo Slow-Start, o tamanho da Janela de Congestão aumenta exponencialmente até atingir um threshold (um dado limite)

� O mecanismo “slow start” foi adicionado por duas razões principais:� Evitar a congestão em WANs devido a um arranque demasiado

rápido, i.e., o slow start impede um fast start.

Controlo de Congestão TCP: Mecanismo Slow Start (1)

rápido, i.e., o slow start impede um fast start.� Inicialmente o TCP não possuia nenhum mecanismo de controlo de

congestão; Injectava-se pacotes até ao limite da rcv_window.� O mecanismo “slow start” é mais lento (daí a designação)

comparando com caso das fontes iniciarem as transmissões enviando uma rajada de segmentos de uma só vez para o servidor (com tamanho até à dimensão da janela).

� Fornecer um aumento exponencial dos valores iniciais do tamanho da cwnd, i.e., o slow start impede um slow start.

� Após o estabelecimento de uma ligação {cold start} , um aumento linear aditivo da cwnd é demasiado lento.

� O emissor começa com cwnd = 1 MSS (Maximum Segment Size), isto é envia um único segmento e espera pela confirmação;

[Sempre que um ACK chega, a cwnd is incrementada]

� De seguida envia dois segmentos e espera pela confirmação; � Depois, quatro segmentos e espera pela confirmação... até

conhecer a dimensão da janela de congestão (a cwnd) [Ganha-se confiança sobre à cerca do débito da rede]

Cliente ServidorControlo de Congestão TCP: Mecanismo Slow Start (2)

[Ganha-se confiança sobre à cerca do débito da rede]

[A cwnd duplicada em cada “época” RTT]

� O crescimento exponencial do número de segmentos a enviar continua até:

� Até ao slow start threshold (ssthreshold) -> fase Congestion Avoidance.

� Até ser atingido o limite em que os routers começam a perder pacotes IP, nessa altura ssthreshold= ½ * Cwnd.

59

Controlo de Congestão TCP: Mecanismo Slow Start (3)

10

11

12

13

14

15

16

Cwnd

0 1 2 3 40

1

2

3

4

5

6

7

8

9

Cwnd

RTT

Controlo de Congestão TCP: Congestion Avoidance

No algoritmo Congestion Avoidance o tamanho daJanela de Congestão aumenta aditivamente atéser detectada congestão.

� Começa quando termina a Fase Slow-Start, i.e., quando cwnd >= ssthresh.Após a recepção cada cwnd ACK: cwnd=cwnd+1. (aumento � Após a recepção cada cwnd ACK: cwnd=cwnd+1. (aumento em 1 pacote).

� Quando for detectada congestão:� Após detecção de perda de um pacote (timeout): cwnd=1 (nova

fase slow-start)� Após detecção de 3 ACKs duplicados, Threshold = CongWin/2 e a

CongWin = Threshold (nova fase congestion avoidance)

Controlo de Congestão TCP: Congestion Avoidance

� Ilustração do Crescimento Aditivo

Slow Start & Congestion Avoidance

if cwnd<ssthresh do slow start

Para cada perda (time-out):ssthresh= cwnd/2

O ssthresh do slow start é habitualmente initializado com um valor elevado

ssthresh= cwnd/2Cwnd= 1MSS

Designa-se esta acção como Fast

Recovery

Ilustração Slow Start + AIMD

Ocorrência de congestão

Resumo: Controlo de Congestão TCP

� Quando CongWin < Threshold, o emissor encontra-se na fase slow-start, a janela cresce exponencialmente.

� Quando CongWin >= Threshold, o emissor encontra-se na fase congestion-avoidance, a janela cresce linearmente.

� Quando é detectado um triple duplicate ACK, Threshold = CongWin/2 e a CongWin = Threshold (nova fase congestion avoidance)

� Quando um timeout ocorre, Threshold = CongWin/2 e CongWin = 1 MSS (nova fase slow-start).

Camada de Transporte TCP/IPRevisão 1.0

66

Revisão 1.0Alexandre Fonte([email protected])

Protocolos de Transporte Tcp e Udp

Documents

Transcript of Protocolos de Transporte Tcp e Udp