A Camada de

Transporte
Introdução

Dênio Mariz
Carlos Kamienski

IFPB, Maio/2009

1
Protocolos,
Serviços &
Portas
3
Modelo de camadas OSI & TCP/IP

Aplicação
Aplicação
Apresentação

Sessão
Transporte
Transporte

Rede Inter-Rede

Enlace
Sub-IP
Físico

Modelo OSI Modelo TCP/IP

4
Família TCP/IP

USUÁRIO
DNS SNMP NFS OSPF FTP HTTP SSH SMTP

Aplicação

SISTEMA OPERACIONAL
Transporte
UDP SCTP RTP TCP

Inter-Rede ARP IGMP IP ICMP RARP

Enlace & Físico ETHERNET PPP TOKEN RING FDDI ATM 802.11 ...

Modelo TCP/IP
5
Encapsulamento

DADOS Pacote da Aplicação

CABEÇALHO
TCP
DADOS Pacote TCP

CABEÇALHO CABEÇALHO
IP TCP
DADOS Pacote IP

CABEÇALHO CABEÇALHO CABEÇALHO RODAPÉ

ETHERNET IP TCP
DADOS
ETHERNET Pacote Ethernet

6
Identificação da aplicação no host
 Como cada host é identificado unicamente na Internet?
 Endereço IP
 IPv4  2^32 = 4.294.967.296 hosts
 IPv6  2^128 = 340.282.366.920.938.463.463.374.607.431.768.211.456
hosts
 Como a entidade de rede (protocolo IP) identifica qual o é protocolo de
transporte que ele está carregando?
 Tipo de protocolo de transporte está indicado no cabeçalho IP
 Dentro do host, como a entidade de transporte (TCP,UDP) sabe para
qual aplicação entregar o pacote ?
 Cada aplicação tem uma “Porta” única no host
 Porta é identificada no pacote TCP,UDP
 Como uma aplicação do cliente identifica a aplicação no servidor
remoto para poder enviar pacotes?
 Alguns serviços têm números de portas já convencionadas (portas “bem
conhecidas”)

7
A Camada de
Transporte
Principais Funções

8
A Camada de Transporte
 É uma camada que é executada somente nos sistemas finais
(puramente fim a fim)
 “É o coração de toda a hierarquia de protocolos” (Tanenbaum)
 A camada de Rede oferece um serviço "cru" de transferência de
pacotes, ou seja, sem nenhum refinamento
 IP: Pacotes podem ser perdidos
 IP: Pacotes podem chegar fora de ordem
 Transporte: corrige esses problemas
 A camada de Transporte usa esse serviço (rede) para criar a abstração
de um enlace fim-a-fim
 Fim-a-fim = entre aplicações

9
Principais funções
 Controle de erros (TCP, UDP)
 Multiplexação de aplicações (TCP, UDP)
 Extensão do envio host-a-host para o envio
aplicação-a-aplicação
 Usa o conceito de “porta” para endereçar aplicações no host
 Reordenação de segmentos (TCP)
 Recuperação de pacotes perdidos (TCP)
 Controle de fluxo (TCP)
 Controle de congestionamento (TCP)
 Protocolos de transporte podem implementar conjuntos diferentes de
serviços
 Exemplo: UDP faz apenas controle de erros e multiplexação

10
Multiplexação de Aplicações

HTTP server X
porta=80

HTTP server Y
porta=80

Pacote IP

Pacote IP

TCP Host A

As aplicações não confundem os pacotes que chegam ?

13
Pilha de Protocolos, na prática

Aplicação Aplicação Aplicação

Porta 1 Porta 2 Porta N

Sistema Operacional
UDP TCP
Transporte

IP, IPX, ICMP, ARP, ...

Rede

Driver da Interface de Rede

Interface de Rede

Rede (hub, switch, router, ...)

14
Pilha de Protocolos, na prática
Browser Browser FTP Server SNMP agent FTP client Web Server

Porta 3245 Porta 4251 Porta 21 Porta 161 Porta 3245 Porta 80

HOST A  Windows 2000

HOST B  Linux
UDP TCP UDP TCP
Transporte Transporte

IP IP

Rede Rede

Driver da Interface de Rede Driver da Interface de Rede

Interface de Rede Interface de Rede

Rede (hub, switch, router, ...)

Outro host

O TCP/IP sabe para qual aplicação entregar o pacote olhando a TUPLA:

Endereço IP origem, Endereço IP destino, Porta origem, Porta destino, Protocolo
15
Multiplexação de Aplicações:
A porta identifica a aplicação no host
HTTP server X
porta=80

HTTP server Y
porta=80

Pacote IP

PORTA=4756
Pacote IP

PORTA=4943
PACOTE IP
PORTA=5623
Endereço IP origem
Endereço IP destino TCP Host A
Porta origem
Porta destino
Protocolo Pacote informa a aplicação através da PORTA
16
Algumas Portas Bem Conhecidas
 21  FTP  110  POP3
 22  SSH  135-139  NetBIOS Services
 23  Telnet  161-162  SNMP
 25  SMTP  443  HTTPS (HTTP+SSL)
 53  DNS  995  POP3S (POP3+SSL)
 69  TFTP  1433  MS-SQL Server
 79  Finger  2049  NFS
 80  HTTP  3006  MySQL
 88  KERBEROS  6000  X Windows

Detalhes em www.iana.org/assignments/port-numbers
17
 A Camada de
Transporte
TCP – Transmission Control Protocol

18
Principais funções
 Controle de erros
 Multiplexação de aplicações
 Reordenação de segmentos
 Recuperação de pacotes perdidos
 Controle de fluxo
 Controle de congestionamento

19
O protocolo TCP
 RFC 793 (Setembro, 1981)
 Em teoria, O TCP não depende do IP
 Ponto-a-ponto
 Um emissor, um receptor
 Confiável, garante ordenação do fluxo
 Trata de retransmissão em caso de erro
 Ordena segmentos no receptor para remontar a mensagem
 Controle de congestionamento
 Controle de fluxo
 Emissor não atropela o receptor
 Full duplex
 Fluxo bidirecional na mesma conexão
 Orientado a conexão
 handshaking iniciado pelo cliente

21
Características do serviço TCP
 Voltado para streams (fluxos)
 Aplicações vêem “streams” bytes
 Conexão no estilo “circuito virtual”
 Aplicações vêem o serviço TCP como um circuito
 Transferência buferizada e segmentada
 Implementação TCP não precisa respeitar limites das
mensagens transmitidas pelas aplicações
 Stream sem estrutura interna
 Não existe nenhuma estruturação no stream

22
O Cabeçalho TCP
20 bytes 20 bytes Variável

IP header TCP header TCP Payload

Porta origem (16 bits) Porta Destino (16 bits)

Número de seqüência (32 bits)

Número de seqüência reconhecido – ACK (32 bits)

Tamanho U A P R S F
Reservado
Cabeçalho
(6 bits)
R C S S Y I Tamanho da janela (16 bits)
(4 bits) G K H T N N

TCP checksum (16 bits) Apontador Flag URG (16 bits)

Opções (campo opcional, tamanho variável)

23
Campos do Cabeçalho TCP
 Porta Origem
 A porta da aplicação que envia os dados
 Porta Destino
 A porta da aplicação para onde os dados são enviados
 Número de seqüência
 Contém o número de seqüência do primeiro byte de dados neste segmento, exceto
quando o flag SYN está presente.
 Se o flag SYN está presente, indica o número de seqüência inicial (NSI) e o primeiro byte
de dados será numerado como NSI+1.
 Número de seqüência reconhecido
 Se o flag ACK está ligado, este campo contém o valor do próximo número de sequência
esperado por quem enviou o ACK.
 Tamanho do cabeçalho
 A quantidade de blocos de 32 bits contidos no cabeçalho.
 Exemplo: número 5 indica que existem 5x32 bits = 5x4bytes= 20 bytes. Isso indica que os
dados começam a partir do vigésimo-primeiro byte.
 Flags (vide adiante)
 Tamanho da janela
 A quantidade de bytes de dados que o emissor está disposto a aceitar, iniciando pelo
número de seqüência indicado no campo “Número de seqüência reconhecido”.
 Exemplo: ACK=1000, TAMJANELA=20 indica “mande no máximo 20 bytes a partir da
posição 1000”.

24
TCP Flags
 SYN (synchronize)
 Iniciar a conexão
 Sincroniza números de sequência
 ACK – Campo “acknowledgement number” é válido
 FIN – Emissor terminou de enviar dados
 RST (reset) – força o término da conexão sem delongas
 PSH (push)
 Normalmente o TCP passa dados para aplicação de forma buferizada.
 “push” indica “mande dados para a aplicação imediatamente” (ex: TELNET)
 URG (urgent)
 TCP “normal” usa o sistema First-In-First-Out (FIFO)
 Com URG ligado, o TCP entende que os dados têm prioridade
 Neste caso, o campo “urgent pointer” indica o último byte urgente do
segmento. TCP repassa dados urgentes primeiro.
 Exemplo: usuário manda “ESC” para interromper um comando que foi
enviado anteriormente.

25
Estabelecimento de Conexão TCP

 Usa o “three-way handshake”

 Protocolo
 Passo 1: o cliente envia um segmento SYN especificando a
porta do servidor ao qual deseja se conectar e seu número
de seqüência inicial
 Passo 2: o servidor responde enviando outro segmento SYN
com o ACK do segmento recebido e o seu próprio número de
seqüência
 Passo 3: o cliente retorna um ACK e a conexão se
estabelece
 O MSS que cada lado se propõe a aceitar também é
negociado durante o estabelecimento da conexão

26
TCP – Como Funciona

Client Server Status: LISTENING

TEMPO

27
TCP – Como Funciona

Client Server Status: SYN_RECV

SYN Conexão solicitada pelo cliente

TEMPO

28
TCP – Como Funciona

Client Server Status: SYN_RECV

SYN
SYN-ACK Servidor aloca recursos (memória)
Para a “potencial” conexão
e liga relógio de TIMEOUT
TEMPO

29
TCP – Como Funciona

Client Server Status: ESTABILISHED

SYN
SYN-ACK
ACK
Cliente confirma o pedido de conexão
TEMPO

(DATA) E inicia envio de dados.

30
TCP – Como Funciona

Client Server Status: ESTABILISHED

SYN
SYN-ACK
ACK
THREE WAY HANDSHAKE
TEMPO

31
Término da conexão
 Cada direção da conexão é encerrada independentemente
 Protocolo
 Passo 1: o cliente envia um segmento FIN
 Passo 2: o servidor retorna um ACK para o cliente
 Passo 3: o servidor envia um segmento FIN
 Passo 4: o cliente envia um ACK e a conexão se encerra
 Os passos 2 e 3 podem ser combinados em um mesmo
pacote

32
TCP – Como Funciona
Client Server Status: CLOSED
STABLISHED

SYN
SYN-ACK
ACK
(DATA)
TEMPO

(DATA)
(DATA)

FIN Após troca de informação, um dos

lados solicita fim da conexão e o
FIN-ACK
outro lado confirma.
ACK

33
Checksum com Pseudo-cabeçalho TCP
 Checksum usa mais informações além do segmento TCP
 Monta um “pseudo-cabeçalho” com campos adicionais
 IP de origem (cabeçalho IP)
 IP do destino (cabeçalho IP)
 Tamanho do segmento TCP (computado)
 + Outros  Total = 96 bytes
 Vantagens: protege adicionalmente contra:
 Erros de entrega (erros no IP-SRC, IP-DST)
 Pacotes que são entregues ao TCP por engano
 Tamanho incorreto do segmento
 Adiciona proteção sem mandar controles adicionais!

35
Pseudo-cabeçalho TCP

 Source Address (4 bytes)

 IP de origem (cabeçalho IP)
 Destination Address (4 bytes)
 IP do destino (cabeçalho IP)
 Reserved (1 byte)
 Não usado (8 bits 'zero')
 Protocol (1 byte)
 Campo 'Protocol' do cabeçalho IP (TCP=6)
 TCP Length (2 bytes)
 Tamanho do segmento TCP (cabeçalho+dados) - é computado.

Figura: http://www.tcpipguide.com
36
TCP: Cálculo do Checksum
 Processo de cálculo:
 Pseudo-cabeçalho é montado
 Campo “checksum” é gravado com ‘0’
 Calcula o checksum envolvendo Pseudo-Cabeçalho+segmento
 Grava o valor obtido no campo “checksum”
 Pseudo-cabeçalho é descartado

Checksum é calculado com base no PseudoCabeçalho + segmento

Figura: http://www.tcpipguide.com37
Diagrama de Estados do TCP
Cliente
Início Servidor
envia SYN conexão passiva

cancela status
Closed cancela status

recebe SYN recebe SYN

SYN sent envia ACK SYN recv envia SYN,ACK Listen
recebe
recebe SYN,ACK ACK
envia ACK
Established
envia FIN recebe FIN
FIN wait 1 envia ACK
Close wait
recebe recebe FIN,ACK recebe FIN
ACK envia ACK envia ACK envia FIN

FIN wait 2 Closing Last ACK

recebe FIN recebe ACK recebe ACK
envia ACK
Time wait time out Closed
Fonte: RFC 793
38
Máquina de estados TCP
ESTADO DESCRIÇÃO
CLOSED Nenhuma conexão ativa ou pendente
LISTEN O servidor está esperando um pedido de conexão
SYN RCVD Chegou um pedido de conexão; aguarda um ACK
SYN SENT TCP solicitou abertura de conexão e aguarda o mesmo do
TCP remoto
ESTABLISHED Conexão aberta: estado de transferência de dados
FIN WAIT 1 Esperando FIN do TCP remoto ou ACK do FIN enviado
FIN WAIT 2 Esperando FIN do TCP remoto
TIME WAIT Espera tempo suficiente para que o TCP remoto receba o
ACK correspondente ao seu pedido de FIN
CLOSING Esperando ACK após enviar FIN
CLOSE WAIT O outro lado iniciou o fechamento da conexão
LAST ACK Esperando ACK to TCP remoto após enviar FIN
39
MTU
 Maximum Transmission Unit (MTU) é o tamanho (em
bytes) do maior pacote que pode ser enviado através da
camada de enlace.
 O MTU depende do tamanho máximo do frame
determinado em cada tecnologia de enlace
Tecnologia MTU (em bytes) Definido por
Hyperchannel 65,535 RFC 1374
16 MB/s Token Ring 17,914 IBM
802.4 Token Bus 8,166 RFC 1042
4 MBs Token Ring 4,464 RFC 1042
FDDI 4,352 RFC 1390
Ethernet 1,500 RFC 894
Point-to-Point Protocol (PPP) 1,500 RFC 1548
802.3 Ethernet 1,492 RFC 1042
Serial-Line IP (SLIP) 1,006 RFC 1055
X.25 & ISDN 576 RFC 1356
ARCnet 508 RFC 1051
40
Segmento TCP
 Cabeçalho TCP
 20 bytes + opções (até 40)
 Tamanho do pacote IP levando um segmento TCP
 Cabeçalho IP + cabeçalho TCP + dados
 MSS = Maximum Segment Size
 MSS conta apenas dados do segmento
 MSS não inclui TCP header nem IP header (RFC 879))
 MSS = MTU - sizeof(TCPHDR) - sizeof(IPHDR)
 Tipicamente, numa rede ethernet: MSS = MTU – 40

20 bytes 20 bytes Variável

IP header TCP header TCP Payload

MSS
MTU
41
Sequencia de Bytes (Byte Stream)
 TCP quebra a mensagem da aplicação em vários
segmentos
 Tamanho do segmento depende da rede
 Cada segmento deve ser reconhecido (acknowledged) pelo
receptor
 ACKs podem pegar carona no fluxo de dados
Dados da Aplicação
Aplicação MENSAGEM A ENVIAR
Bloco 2 Bloco 3

TCP ME NS AG EM A E NV IA R
Segmento

42
Temporizadores, ACKs e Retransmissão
 Quando um segmento é enviado, o transmissor ativa um
temporizador (timer)
 Quando o segmento chega ao destino, o TCP receptor
retorna um segmento ACK com o próximo número de
seqüência que espera receber
 Timer é desativado no transmissor
 ACK da sequencia “X” indica que o receptor recebeu todos os
bytes anteriores a X
 Se o temporizador do transmissor expirar antes da
confirmação chegar, haverá uma retransmissão
 Pacote pode ter sido perdido na rede
 Pacote pode ter se atrasado, mas ainda chegar (duplicado)
no receptor
 O ACK pode ter se perdido

43
Geração de ACK do TCP [RFC 1122, RFC 2581]
Evento
Chegada de um segmento em
ordem, sem buracos, todos os
anteriores já reconhecidos
Chegada de um segmento em
ordem, sem buracos, com um ACK
atrasado pendente
Segmento chega fora da ordem (nº
sequência maior que o esperado):
buraco detectado
Chegada de um segmento que
enche totalmente ou parcialmente
um buraco
Ação do Receptor TCP
Atrasa o ACK: espera até 500ms
pelo próximo segmento. Se não
chegar, envia o ACK
Envia imediatamente um único ACK
cumulativo
Envia um ACK duplicado indicando o
nº do próximo byte esperado
(duplicado=repetido=2,3,4…vezes)
Envia um ACK imediatamente
reconhecendo o último segmento
do bloco contíguo
44
Exemplo: Telnet
Host A Host B

Usuário Seq=4
2, ACK=7
digita 9, data =
‘C’ ‘C’
host acusa
Recebimento de
’
, data = ‘C ‘C’ (ACK) e ecoa de
3
9, ACK=4 volta ‘C’
Seq=7

host acusa
recebimento Seq=43
do ‘C’ ecoado , ACK=
80
(ACK)

time

45
Retransmissão por perda de ACK
Host A Host B

Seq=9
2 , 8 byt
es dat
a
timeout
K =100
AC
X
loss
Seq=9
2, 8 b
yt es dat
a

K= 100
AC

time

46
Retransmissão por Timeout
Host A Host B

Seq=9
2, 8 byte
Seq=92 timeout Seq= s data
100,
20 by
tes da
Seq=100 timeout

ta
0
10
CK =
K = 120
A AC
Seq=9
2, 8 byte
s data

timeout prematuro
=120
K
AC

time cumulative ACKs

47
Sobre a Vazão de um Canal …
 Taxa de Transferência de um canal (vazão)
Bits enviados [bits por segundo]
Vazão =
Tempo decorrido

 Tempo de Transferência em um canal

Bits enviados
Tempo = [segundo]
Capacidade do canal

 Utilização (U)
 Fração de tempo em que o emissor está usando canal em
relação ao tempo ocioso

Tempo enviando
U= [%]
Tempo esperando
48
Sobre a Vazão de um Canal …
 Exemplo:
 Enlace de 1 Gbps
 Tempo de propagação fim-a-fim (delay) = 15 ms
 Pacotes de 1kB
 Tempo de transferência (TTX)
8*10**3 bit
TTX = = 0.000008 sec
10**9 bit/sec
 1 pacote de 1kB a cada 30.008ms
 Utilização (U)
 U = 0.000008 sec
= 0.00027 = 0.027%
2*15+0.000008 sec

 Conclusão
 Vazão efetiva de um canal de 1Gbps = 8000/0.030008 bits/s 
267kbps
 Protocolo limita o uso dos recursos físicos! 49
Controle de Fluxo no TCP

 Emissor não deve enviar mais dados do que o receptor é capaz de

receber Bufferização do receptor
RcvWindow
 Receptor avisa ao emissor o tamanho da janela (espaço livre no buffer)
 Campo RcvWindow no cabeçalho TCP
Dados TCP
Buffer livre
no buffer

RcvBuffer

Applicação Applicação
grava dados lê dados
socket socket
TCP TCP
send buffer receive buffer
segmento

50
Janela Deslizante

Transmissor
Transmissor Receptor
Receptor
Máx ACK Próximo próximo Máximo
recebido a enviar esperado aceitável

… … … …

Sender window Receiver window

Enviado &
reconhecido Enviado, não Recebido & Pacote não
(Acked) reconhecido reconhecido recebido
Recebido
OK para Não usável Não usável
enviar fora de ordem
(não reconhecido)

51
 A Camada de
Transporte
Controle de Congestionamento do TCP

Dênio Mariz

denio@ifpb.edu.br

CEFET-PB, ABR/2004

52
Por que Ocorre Congestionamento?
 Congestionamento ocorre quando há muito tráfego na rede
 Roteadores têm capacidade de enfileiramento
 Quando pacotes não podem ser transmitidos naquele
momento, eles aguardam na fila até que o roteador tenha a
chance de encaminhar
 Filas têm tamanho limitado
 Se a fila está cheia, pacotes que chegam são descartados

Fila
máx= n pacotes
Enlace A

Enlace C
Enlace B Roteador
53
Por que Ocorre Congestionamento?

Fila
máx= n pacotes
Enlace A

Enlace C
Enlace B Roteador

 Fluxo de entrada no roteador é <= fluxo de saída

 Fila vazia

54
Por que Ocorre Congestionamento?

Fila
máx= n pacotes
Enlace A

Enlace C
Enlace B Roteador

 Fluxo de entrada no roteador é <= fluxo de saída

 Fila vazia
 Fluxo alternado  multiplexação do enlace
 Na prática isso não acontece sempre
55
Por que Ocorre Congestionamento?

Fila
máx= n pacotes
Enlace A

Enlace C
Enlace B Roteador

 Fluxo de entrada no roteador é > fluxo de saída

 Fila entra em ação
 Pacotes sofrerão atrasos
 Crescimento da fila depende do comportamento da chegada
dos pacotes
56
Por que Ocorre Congestionamento?

Fila
máx= n pacotes
Enlace A

Enlace C
Enlace B Roteador
PACOTES
DESCARTADOS

 Fluxo de entrada no roteador é > fluxo de saída

 Descartes ocorrem quando a fila está cheia
 Descartes são geralmente aleatórios
 Mas existem vários tipos de fila que podem dar prioridade a
certos tipos de pacote
57
Filas
 Filas com alta ocupação implicam:
 Aumento do atraso
 Aumento da variação do atraso
 Aumento da probabilidade de perda

58
Controle de Congestionamento no TCP
 Idéia básica:
 Não há maneiras do TCP determinar exatamente as
condições da rede
 TCP considera um pacote perdido como congestionamento
 Controla a transmissão com algoritmos simples
 While true
 Se pacotes não são perdidos
 TCP assume que a rede não está congestionada
 Aumenta a taxa de transmissão
 Se pacotes são perdidos
 TCP assume que a rede está congestionada
 Reduz a taxa de transmissão
 End while
 Reduzir ou aumentar = controle da transmissão
64
Como o TCP controla a Transmissão ?
 Usa uma variável "congestion window (cwnd)" que indica o
tamanho da janela deslizante
 cwnd é usada para controle de congestionamento
 Determinado pelo transmissor em função da vazão da rede
 Controla a quantidade de dados sendo injetada na rede
 Advertised Window (awnd) é usada para controle de fluxo
 Enviada ao TCP transmissor pelo TCP receptor no cabeçalho
 Como determinar o tamanho efetivo da janela ?
 Window Size = min(advertised window, congestion window)

65
Controle de Congestionamento TCP

 Objetivo
 Tentar fazer com que a rede esteja sempre em plena carga,
porém não congestionada
 Fazer uma aproximação do ideal: introduzir um novo pacote
na rede assim que outro saiu
 O TCP testa o tempo todo a capacidade da rede
 Método
 Notificação implícita (ao invés de comunicação explícita da
rede)
 perda de pacotes indicam situações de congestionamento

66
Controle de Congestionamento TCP
Janela de congestionamento (KB) (cwnd)

44

40 Limiar (threshold)
36

32
28

24

20

16

12

8
4

0
0 2 4 6 8 10 12 14 16 18 20 22 24
Número da transmissão
71
Evolução do Fluxo de Dados no TCP
 No início, a janela de congestionamento tem o tamanho de um
segmento.
 Tal segmento tem o tamanho do maior segmento suportado.
 O primeiro segmento é enviado e então é esperado seu
reconhecimento (ACK).
 Se o ACK chegar antes que ocorra o timeout, o transmissor
duplica o tamanho da janela de congestionamento e envia
dois segmentos.
 Se esses dois segmentos também forem reconhecidos antes
de seus timeouts, o transmissor duplica novamente sua
janela, enviando agora quatro segmentos.
 Esse processo continua até que:
 O tamanho da janela de congestionamento seja maior que o
limiar, ou maior que o tamanho da janela do receptor;
 Ocorra timeout antes do ACK
72
Duas Fases dessa Evolução
 A primeira fase
 A janela de congestionamento cresce exponencialmente
 chamada de inicialização lenta (slow start), pelo fato de
começar com um segmento.
 A taxa de transmissão começa pequena porém cresce muito
rapidamente.
 Uma vez ultrapassado o limiar, e a janela do receptor ainda não
seja um limitante, o crescimento da janela passa a ser linear.
 A Segunda Fase
 chamada de prevenção de congestionamento (congestion
avoidance).
 Sua duração também depende da não ocorrência timeouts, e
da aceitação do fluxo por parte do receptor.

73
Graficamente ...

SLOW START
74
Graficamente ...

CONGESTION
AVOIDANCE
75
Evolução de uma Conexão TCP
 Na ocorrência de um timeout, as seguintes atitudes são
tomadas:
 O valor do limiar passa a ser a metade do atual tamanho da
janela de congestionamento.
 O tamanho da janela de congestionamento volta ser do
tamanho de um segmento (ativa-se o slow start).
 O tamanho da janela de congestionamento volta a crescer
exponencialmente.

76
Resumo
 Quando o tamanho da janela de congestionamento está
abaixo do limiar, seu crescimento é exponencial.

 Quando este tamanho está acima do limiar, o crescimento

é linear.

 Todas as vezes que ocorrer um timeout, o limiar é

modificado para a metade do tamanho da janela e o
tamanho da janela passa a ser 1.

77
Graficamente ...

78
RTT - Round Trip Time
 RTT é o tempo decorrido entre o envio de um segmento
de dados e o recebimento do seu ACK
 RTT É bastante variável para cada segmento
 RTT = propagação + atraso em filas
 Atraso em filas é altamente variável, devido às condições de
tráfego e roteamento sofridas na rede
 Logo, RTT é altamente variável
 Determina o ciclo da Janela de Congestionamento do TCP
(cwnd)
 Serve de base para o cálculo do RTO - Retransmission
Timeout

79
RTO - Retransmission Timeout

 Tempo que o emissor espera por um ACK antes de

retransmitir o segmento
 Cada segmento transmitido é colocado em uma “Fila de
Retransmissão” e um timer de RTO é acionado
 Quando o novo ACK é recebido, o segmento é retirado da
fila e o contador reiniciado (ou parado se a fila estiver
vazia)
 Se o ACK não chegar antes que RTO expire
 segmento é retransmitido
 valor de RTO é dobrado e o timer é reiniciado (“Timer
Backoff”)

80
Estimativa do RTO e RTT
 Problema:
 Ao contrário do enlace físico, o RTT de um enlace lógico pode
variar muito (ex: filas)
 Qual deve ser o valor do RTO ? Ou seja, quanto tempo o TCP
deve esperar para retransmitir um segmento?
 Se RTO for longo demais
 sub-utilização
 reação lenta às perdas de segmento
 Se RTO for curto demais
 retransmissões desnecessárias
 Solução
 RTO dinâmico e adaptativo, baseado na estimativa do RTT
 RTO é Calculado em função da média e variância de RTT

81
Cálculo de RTT e RTO (RFC 2988 )

 Algumas variáveis
 AmostraRTT  RTT medido
 MediaRTT  Média RTT amortizada
 DesvioRTT  Variação de RTT
 G  Granularidade de clock do TCP (~500 ms)
 k  Desvios da média (k=4)
   Amortizador da Média ( =1/4)
   Amortizador do Desvio padrão ( =1/8)
 Assume-se que nenhum valor de RTO deve ser menor do que G
 max (G, valor)
 G= granularidade do relógio

82
Cálculo de RTT e RTO (RFC 2988 ) (cont.)

 Valor inicial  RTO = 3 segundos

 Para o primeiro valor medido de AmostraRTT
1.DesvioRTT = (AmostraRTT / 2)
2. MediaRTT = AmostraRTT
3. RTO = MediaRTT + K * DesvioRTT
 Para os próximos valores medidos de AmostraRTT :
1. DesvioRTT = (1 - ) *DesvioRTT +  * |MediaRTT – AmostraRTT|
2. MediaRTT = (1 - ) * MediaRTT +  * AmostraRTT
3. RTO = MediaRTT + k * DesvioRTT
4. Ajusta RTO para que 1 < RTO < 60 segundos
 AmostraRTT deve ser medido de acordo com o “Algoritmo de Karn”
 (veja adiante)

83
Cálculo de RTT e RTO (RFC 2988 )

 Por que k = 4 ?
 Teorema de Chebyshev
 MaxRTT = AvgRTT + k* DesvioRTT
 Probabilidade de erro é menor que 1/(k**2)
 k=4  probabilidade de acerto é de 93,75%
 Qualquer que seja a distribuição de RTT

84
 Tempo (ms)

10000
20000
30000
40000
50000
60000
70000

0
1
11
21
31
41
51
DesvioRTT
AmostraRTT

61
71
81
91
101
111
RTOFinal
MediaRTT
Cálculo do RTO

121
131
141
151
161
171
181
191
201
211
Cálculo do RTO

Rodada
221
231
241
251
261
271
281
291
301
311
321
331
341
351
361
371
381
86

391
Ambiguidade da Retransmissão

A B A B
Original tran
sm ission Original tran
smission
X
RTO RTO
ACK
retran retran
smiss Amostra smiss
ion ion
Amostra RTT
RTT ACK ACK

O ACK é do segmento original ou do segmento retransmitido?

87
Algoritmo de Karn
 Leva em conta o problema da “ambiguidade de retransmissão”
 Se um segmento foi retransmitido (recebeu um ACK ambíguo)
 Não atualize o estimador do RTT (AmostraRTT)
 Timer Backoff: RTO = 2*RTO
 Depois de um Timer Backoff
 MediaRTT e DesvioRTT são reiniciados (cálculo usado no primeiro
valor de AmostraRTT)
 AmostraRTT é atualizado apenas na próxima transmissão bem
sucedida
 Algoritmo de Karn não é usado quando TCP usa Timestamps
 (veja adiante)

88
Timestamp Extension (RFC 1323)

 Usado para melhorar o mecanismo de timeout

 Faz uma medição mais precisa do RTT
 Quando envia um pacote
 Insere o tempo atual do relógio do emissor (timestamp) no
cabeçalho TCP (campo “options”)
 4 bytes para os segundos, 4 bytes para microsegundos
 Receptor “ecoa” o timestamp
 Copia o timestamp recebido para o pacote ACK
 Não modifica: apenas copia
 Remove a “ambiguidade da retransmissão”
 Pode obter o RTT de qualquer pacote

89
Fast Retransmit

ACK Duplicado
 Significa que um cwnd = 1 segment 1

pacote fora de ACK 1

sequência foi cwnd = 2 segment 2
segment 3
recebido ACK 2

Fast retransmit ACK 3

cwnd = 4 segment 4
 Reenvia um segment 5
segment 6
segmento depois de segment 7
ACK 4
3 ACKs duplicados
timeout
ACK 4

 Não espera timeout ACK 4

segment 4

3 ACKs
para mesmo
retransmissão
segmento antes do timeout
90
 A Camada de
Transporte
UDP – User Datagram Protocol

Dênio Mariz

dmts@cin.ufpe.br

CEFET-PB, ABR/2004

91
UDP
 RFC 768 - Agosto 1980 (2 páginas)
 Principais Características
 Camada de transporte
 Não confiável (sem garantia de entrega)
 Utiliza o datagrama como unidade básica
 Uma interface simples de acesso ao IP para as aplicações
 Sem sofisticações (controles de conexão, fluxo, congestionamento)
 Cabeçalho de oito bytes
 Por que um protocolo não-confiável?
 Algumas aplicações não querem recuperar perdas
 Exemplo: voz, vídeo
 Por que um protocolo não orientado a conexão?
 Aplicações que precisam mandar dados o mais rápido possível
 Exemplo: Request-response do SNMP

92
 O Protocolo UDP

 Serviços
 Application-to-application data delivery (multiplexação)
 Error checking

Cabeçalho UDP
0 15 16 31
Source port Destination port

UDP length UDP checksum

93
TCP vs UDP

94
TCP
 Confiável, faz tratamento de erros (perdas) e garante a
entrega dos dados
 Adaptativo
 controle de congestionamento variando a taxa de envio
 Adapta a taxa de transmissão à banda disponível
 Usa ACKs
 Aplicação não se preocupa com controle de perdas de
pacotes e sequenciamento
 Controle de fluxo: janela deslizante, temporização
 Usado pelos protocolos FTP, HTTP, POP, SMTP, ...
 Requer tempo adicional para estabelecer conexão
 Three-way handshake

95
UDP
 Não Confiável
 Não trata a perda de pacotes
 Não Garante a entrega dos dados
 Se a aplicação desejar, ela executa controle de perdas de
pacotes e sequenciamento de dados
 Quem usa UDP raramente trata perdas
 Usado pelo SNMP, DHCP, DNS, ...
 Não faz controle de fluxo
 Manda dados na maior taxa que puder
 Não Adaptativo
 Toma o máximo da banda disponível
 Não requer tempo adicional para estabelecer conexão
 Não orientado a conexão

96