Sei sulla pagina 1di 66

Camada de Transporte TCP/IP

Unidade Curricular de Arquitectura Internet


Licenciatura em Engenharia Informática – 1º Ciclo Bolonha
2º Ano – 4º Semestre
Ano lectivo 2008-2009

Alexandre Fonte
(adf@est.ipcb.pt)

1
Nota Prévia
 Este material é uma versão actualizada e adaptada à presente
unidade curricular, baseada nas versões criadas pelo Professor
Doutor Osvaldo Santos, o Lic. Vasco Soares e por mim próprio
para utilização durante anos lectivos anteriores em Unidades
Curriculares, com tópicos relacionados, de cursos ministrados no
Departamento de Engenharia Informática, ESTCB-IPCB.
Camada de Transporte TCP/IP
 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
 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- applicatio
n
Servidor) em execução em diferente transport
hosts. network network
data link data link
physical network physical
data link
 Os protocolos de transporte são physical
executados nos sistemas finais network
data link
 Lado Emissor: divide as mensagens physical network
das aplicações em segmentos e data link
physical
passa-os a camada de rede (i.e.,
ao IP) network
data link
 Lado receptor: reassembla os physical
segmentos nas mensagens e
applicatio
passa-as à camada da aplicação. n
transport
network
data link
 Na Internet estão disponíveis às physical
aplicações dois protocolos de
transporte:
 O TCP (Transmission Control Protocol e
o UDP (User Datagram Protocol)
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.
Camada de Transporte
 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.

 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

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

 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
7168 7168
6144
7 6144
7
5120
6 2 1 5120
6
4096
5 5 4096
5
4 3 4
3072 6 3072
3 7 4 3
2048 2048
2 2
1024 Rota 1024
0
1
0
1

7
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
Camada de Transporte: Mecanismos de
recuperação de erros e perdas
 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

Exemplo:
stop-and-wait
RTO

9
Camada de Transporte: Mecanismos de
recuperação de erros e perdas
 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
 O emissor desliza a janela após a recepção de
um ACK
Janela de tamanho 7

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2

Pacotes enviados Pacotes não enviados


e confirmados

Pacotes enviados mas não confirmados 10


Camada de Transporte: Mecanismo de
entrega à aplicação destino
 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.

P1 P4 P5 P2 P1P3
110 25 80
PF: 5775
PD: 80
IP-F: B
IP-D:C

PF: 9157 PF: 9157


cliente PD: 110 servidor PD: 25 Cliente
IP: A IP: C IP:B
IP-F: A IP-F: B
IP-D:C IP-D:C
11
Camada de Transporte: Mecanismo de
entrega à aplicação destino
 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.
 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 1024-49151 49152-65535

Well-known Registados Dinâmicos ou privados


12
Portos
 Um host recebe datagramas IP
 Cada datagrama possui um
32 bits
endereço IP fonte, um
endereço IP destino Porto fonte# Porto dest. #
 Cada datagrama transporta
1 segmento da camada de
transporte Outros campos cabeçalho
 Cada segmento possui
possui um porto fonte, um
porto destino
Dados aplicação
 Um host usa os endereços IP & (mensagem)
os números dos portos para
despachar o segmento para o
socket apropriado

Formato segmento TCP/UDP


UDP – User Datagram Protocol
 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.

 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)

14
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
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
Datagrama/Segmento UDP
Bit: 0 16 31
Port de origem Port de destino
(16 bit) (16 bit)

Comprimento UDP Checksum


(16 bit) (16 bit) Máximo
65515
Dados bytes
(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.
16
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
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)
TCP – Transmission Control Protocol (1)
 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:
 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)
19
TCP – Transmission Control Protocol (2)
 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.
 É o protocolo de transporte da maior parte das aplicações da
Internet (WWW, E-mail, IRC, FTP, Telnet, etc..).
 Utiliza os serviços IP.

20
Funcionamento Básico TCP
& Buffers de Emissão e Recepção
Processo Processo
emissor 1 - Estabelecimento de ligação Recepção

2 - Transmissão de dados
(full duplex)

3 - Fecho de ligação

Segmentos TCP
Formato do Segmento TCP

Bit: 0 16 31
Port de origem Port de destino
(16 bit) (16 bit)

Número de sequência
(32 bit)

Número de confirmação
(32 bit)
U A P R S F
Header len Reservado Tamanho da janela Recepção
R C S S Y I
(4 bit) (6 bit) (16 bit)
G K H T N N Máximo
Checksum Ponteiro urgente
(16 bit) (16 bit) 65515
Opções (se existirem)
bytes
(32 bit)

Dados
(variável)

22
Significado dos Campos do Cabeçalho TCP
 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).
 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.

23
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:
 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]
Números de Sequência & ACKs
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’

tempo
Uma simples sessão telnet
Números de Sequência & ACKs

 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)
Segmento 2 – Nr. de Sêquencia: 11,001 (gama: 11,001 a 12,000)
Segmento 3 – Nr. de Sêquencia: 12,001 (gama: 12,001 a 13,000)
Segmento 4 – Nr. de Sêquencia: 13,001 (gama: 13,001 a 14,000)
Segmento 5 – Nr. de Sêquencia: 14,001 (gama: 14,001 a 15,000)
Significado das flags do Campo Controlo

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

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

 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.
27
Exemplos de Portos TCP Reservados (WKP)

28
Exemplos de Portos TCP Reservados (WKP)

Em Linux/UNIX, os porto bem-conhecidos são guardados num


ficheiro /etc/services. Cada linha neste ficheiro gurda o nome do
serviço e o número do porto. Pode-se usar o comando grep para
extrair a linha correspondente ao serviço desejado.

$ grep ftp /etc/services


ftp-data 20/tcp
ftp-control 21/tcp

29
Gestão de Ligações TCP (1)
 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:
Cliente 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,


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.

30
Gestão de Ligações TCP (2)
 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. Cliente Servidor
 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
de um pacote IP é 576bytes)
 Na Ethernet, o MSS é 1460bytes pois o
MTU=1500bytes

31
Gestão de Ligações TCP (3)

 Fecho de uma ligação TCP Cliente Servidor

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.
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”.

32
Gestão de Ligações TCP (4)
 Recusa de uma Ligação TCP
Gestão de Ligações TCP (5)
 Abortar uma Ligação TCP (Reset)
Cenário comum
Transmissão de Dados

 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.

 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)

36
TCP – Fluxo de dados Interactivos
 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.
Cliente Servidor

Tecla premida

Visualização do caracter

37
TCP – Fluxo de dados Interactivos

 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.

Cliente Servidor

Período de atraso,
tipicamente 200 ms
(Ack atrasado)

38
TCP – Fluxo de dados Interactivos
 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,
mais congestionadas, poucos segmentos são gerados.

Cliente Servidor

dados Certas aplicações,


dados contudo, exigem que o
algoritmo Nagle seja
dados desabilitado:
Aplicação dados E.g., aplicações de remote
Desktop ou X Window
server para capturar os
dados movimentos do rato em
tempo real

39
Fluxo de Dados NÃO
Interactivos 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.


 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ó.


40
Controlo de Fluxo TCP (1)
 O mecanismo de controlo de Fluxo regula a quantidade de dados
que uma fonte pode enviar antes da recepção de um
acknowledgment (ACK) do destino.
 O TCP define uma “variável” janela (window) imposta sobre o
buffer de emissão, cujo valor –o tamanho da janela-
janela- depende da
velocidade do receptor, i.e.,

Window<= velocidade do receptor


(no caso de não haver controlo de congestão)
Buffer com dados
Segmento de dados
Emissor
Receptor

Segmento de controlo
Controlo de Fluxo TCP (2)
Controlo de Fluxo
 O Receptor de uma ligação O emissor TCP tenta não
TCP aloca à ligação um esgotar o buffer
buffer de recepção: (overflow) do receptor
Rcvwindow tentando não transmitir
Processo pacotes em excesso, i.e.,
Dados Receptor demasiado depressa
do IP Espaço livre Dados (lê do buffer)
no
no buffer Buffer

RcvBuffer  Idealmente o rate de envio


 A aplicação lê do buffer a uma deverá ser ajustado/idêntico
determinada velocidade, podendo ao rate de leitura do buffer
conduzir à necessidade de da aplicação consumidora.
abrandar a transmissão.
Controlo de Fluxo TCP (3)
Rcvwindow
 O Rcv anuncia o espaço livre
Dados Processo no buffer através do campo
do IP Espaço livre Dados receptor RcvWindow nos segmentos.
no
no buffer Buffer
 À medida que os dados vão
sendo passados ao processo,
RcvBuffer a janela anunciada pode
aumentar.
 O espaço livre no buffer:  O emissor limita os dados
= RcvWindow transmitidos não confirmados
= RcvBuffer-[LastByteRcvd - unACKed à dimensão da
LastByteRead] RcvWindow
 Isto garantirá que o buffer
do receptor não será
esgotado.
Controlo de Fluxo TCP (4)
 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
Window <= Bytes não enviados e que não
podem ser enviados
RcvWindow

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2

No exemplo
Bytes enviados Bytes não enviados, mas window=7 <=Rcvwindow
que podem ser enviados
e confirmados A janela deslizante é usada para
tornar a transmissão mais eficiente e
para controlo do fluxo de dados de
Bytes enviados mas não modo a que o receptor não fique
confirmados sobrecarregado com dados.

No exemplo, na situação actual o


tamanho da janela utilizável é 5
Controlo de Fluxo TCP (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
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2

UAR USE
Controlo de Fluxo TCP (6)
 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: Rcvwindow 1000bytes

Dados Processo
do IP Espaço livre Dados
no
no buffer Buffer

RcvBuffer=4000 bytes
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 A1(t)
10Mb/s
D(t)
R1 1.5Mb/s H3

H2 A2(t)
100Mb/s
A1(t)
D(t)
X(t)
A2(t)
Controlo de Congestão TCP

 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
Controlo de Congestão TCP

 É do tipo end-end control (sem assistencia Como é que uma fonte TCP
da rede) percebe a congestão?
 Uma fonte TCP mantém uma variável  Evento perda de pacote =
Congestion Window = Cwnd com o timeout ou 3 acks duplicados
valor da janela de congestão  Uma fonte TCP reduz o rate
 O emissor limita a transmissão: (CongWin) após a detecção de
LastByteSent-LastByteAcked<= um evento de perda
CongWin

Principais Mecanismos Standard de


 Grosseiramente, a taxa de transmissão é: Controlo de Congestão TCP:
rate = CongWin/RTT Bytes/seg  Slow start

 AIMD (Congestion
 CongWin é dinâmica, função da congestão Avoidance)
da rede
Controlo de Congestão TCP
 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.

 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)

Pacotes
1 2 3 4 5 6 7

Acknowledgements
1 2 3 3 3 3
RTT e Timeout (1)
Q: Como definir o valor de Q: Como estimamos o RTT?
RTO?  AmostraRTT: tempo medido
 Deve ser maior que o RTT desde da transmissão até à
 Mas o RTT é variável
recepção do ACK
 Demasiado pequeno:
 A amostraRTT varia, deseja-
 Reacção rápida
se uma estimativa “suavizada”
 Conduz a retransmissões
 E.g., usa-se a média de
desnecessárias várias amostras, e não
 Demasiado longo: apenas a única amostra
 Reacção lenta às perdas de
segmentos
RTT e Timeout (2)

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


 Média móvel exponencial
 Inclui a influência do passado
 Valor típico:  = 0.125
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300
RTT (milliseconds)

250

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

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 +
DevRTT = (1-β
β*|AmostraRTT-EstimativaRTT|
(tipicamente, β = 0.25)

Timeout:
RTO = EstimativaRTT + 4*DevRTT
Controlo de Congestão TCP

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ção
O tamanho da janela é o valor mínimo entre rwnd e cwnd, o qual é 3000
bytes.
Controlo de Congestão TCP
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?
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?
Controlo de Congestão TCP:
Mecanismo Slow Start (1)
 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.


 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.
Controlo de Congestão TCP: Cliente Servidor
Mecanismo Slow Start (2)
 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]

[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)

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

RTT
Controlo de Congestão TCP:
Congestion Avoidance

No algoritmo Congestion Avoidance o tamanho da


Janela 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
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
O ssthresh do slow start é
habitualmente initializado
com um valor elevado

if cwnd<ssthresh do slow
start

Para cada perda (time-


out):
ssthresh= cwnd/2
Cwnd= 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/IP
Revisão 1.0
Alexandre Fonte
(adf@est.ipcb.pt)

66

Potrebbero piacerti anche