TCP/IP Transport Layer

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.

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

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

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 P1
P3
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]

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


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)

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

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


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

Recusa de uma Ligação TCP

Abortar uma Ligação TCP (Reset)

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


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

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- depende da
janela-
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
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.

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.

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

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

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.

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)


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


É 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

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 = (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ção
O tamanho da janela é o valor mínimo entre rwnd e cwnd, o qual é 3000
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?
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
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


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

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)

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

Revisão 1.0
Alexandre Fonte
(adf@est.ipcb.pt)

66

TCP/IP Transport Layer

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à TCP/IP Transport Layer

Similaire à TCP/IP Transport Layer (20)

Dernier

Dernier (20)

TCP/IP Transport Layer