Protocolos de Transporte da

Pilha TCP/IP

UDP (User Datagram Protocol)

O protocolo UDP bastante simples

Orientado a datagrama
No orientado conexo
No executa controle de fluxo, controle de erro
e sequenciamento
No tem reconhecimento dos datagramas
(ACK/NACK)

Devido a sua simplicidade considerado

no confivel

Header UDP
0

16

31

Porta Origem

Porta Destino

Tamanho

Checksum
Dados

Onde,
Porta Origem e Porta Destino identificam o processo de
aplicao que est enviando dados e o processo de aplicao que
ir receber os dados.
Tamanho representa o tamanho total do frame UDP
Checksum calculado usando o header UDP e tambm a rea
de dados, e destina-se a verificao de erros de transmisso.

Checksum UDP

O Checksum no UDP opcional

Campo de checksum = 0, no executa

verificao
Campo de checksum <> 0, executa verificao

O clculo do checksum utiliza o header, os

dados e tambm o Pseudo-Header

Este pseudo-header utilizado para

verificao adicional e confirmao de que o
datagrama chegou ao destino correto

Pseudo-Header
0

16

31

Endereo IP Origem
Endereo IP Destino
Zero

Protocolo

Tamanho

Onde,
Endereo IP Origem e Endereo IP destino so do nvel de rede
(protocolo IP) utilizadas para a segunda validao do destino do datagrama.
Zero um campo com valor zero para complementar a estrutura
do pseudo-header.
Protocolo indica qual o protocolo de transporte (TCP ou UDP), pois
o pseudo-header utilizado para os dois protocolos.
Tamanho indica o tamanho do frame de transporte (UDP ou TCP)

Ordem de Header para o

Checksum do UDP
0

16

31

Endereo IP Origem
Endereo IP Destino
Zero
Header UDP

Protocolo

Pseudo-Header

Tamanho

Porta Origem

Porta Destino

Tamanho

Checksum
Datagrama UDP

Dados

Ateno!
O Pseudo-Header no transmitido junto com o datagrama
UDP, ele utilizado apenas para clculo do Checksum.

Processamento do Checksum

Na origem, as informaes necessrias so

organizadas em blocos de 16 bits para o
clculo do checksum

Caso o clculo resulte em zero, os 16 bits do

checksum sero configurado todos em 1
(valor = 65535)

Se optar-se por no utilizar checksum, os

16 bits sero configurados todos em 0

Processamento do Checksum

Se o checksum recebido tem todos os bits

em zero, no necessrio calcul-lo (pois
no est sendo utilizado)
Caso contrrio, o clculo do checksum
realizado novamente

Se o clculo resultar em Zero, o datagrama

no contm erros
Se o clculo resultar diferente de Zero, o
datagrama descartado

Tamanho Mximo do Datagrama

Teoricamente o tamanho mximo de

64Kb

Porque no IP o campo tamanho total de 16

bits
Mas deve-se considerar que no IP esto sendo
calculado

Tamanho do Header do IP (20 bytes)

Datagrama UDP (8 bytes)

Assim, o tamanho mximo de 65507 bytes

Tamanho Mximo do Datagrama

Outros fatores podem influenciar

Programas de aplicao podem ser limitados

pela interface de programao
Implementao do kernel do TCP/IP

Truncando Datagramas

Apesar do tamanho mximo, nem todas as

aplicaes podem estar preparadas para
receber um datagrama maior que esperado

Truncar ou no? Depende da implementao de

cada interface de programao

UDP e ICMP Source Quench

Mensagens ICMP Source Quench

Podem ser geradas pelo sistema quando ele recebe

dados a uma taxa maior que ele consegue processar
No obrigatria a gerao, mesmo que o sistema
descarte os datagramas

O sentimento corrente que esta mensagem

deve ser considerada obsoleta

Porque consome largura de banda e ineficaz para o

controle de congestionamento

Almquist 1993 (RFC???)

UDP e ICMP Source Quench

Vrias sistemas operacionais no geram

estas mensagens
Vrios sistemas operacionais no
repassam tais mensagens para o protocolo
UDP
Somente o TCP notificado quando estas
mensagens ocorrem!!!

TCP (Transmission Control

Protocol)

Protocolo de transporte considerado

confivel

Orientado conexo
Controle de erros com retransmisso
Controle de fluxo
Sequenciamento
Entrega ordenada

Orientado a byte stream

Header TCP
Porta origem

Porta destino

Nmero de Seqncia
Acknowlegement
Tam.

Reser.

Flags

Checksum

Window
Urgent Pointer

Opes (se houver)

Dados

Header TCP
Onde,
Porta Origem e Porta Destino identificam o processo de aplicao que
est enviando dados e o processo de aplicao que ir receber os
dados.
Nmero de seqncia identifica os bytes enviados. Na prtica ele a
identificao do primeiro byte de dados contido no segmento enviado. Os
demais so seqenciados a partir deste byte.
Acknowledgement identifica os bytes que foram recebidos e tratados
sem erro pelo destino, bem como a seqncia do prximo byte esperado
Tamanho representa o tamanho total do frame TCP
Reservado um campo ainda no utilizado
FLAGS identifica as flags (syn, fin, psh, rst, ack, urg)
Window identifica o tamanho da janela para o controle de fluxo
Checksum destina-se a verificao de erros de transmisso. calculado
usando o pseudo header, o header TCP e tambm a rea de dados
Urgent Poninter um ponteiro para dados urgentes, contidos na rea
de dados.

Controle de Conexo TCP

Trs Fases

Estabelecimento da Conexo
Transmisso de Dados
Encerramento da Conexo

Flags

SYN solicitao de conexo

FIN Finalizao da Conexo
RST Reset da Conexo
ACK Reconhecimento de recebimento

Estabelecimento da Conexo
Origem
A

SYN 1415531521:1415531521 (0) <mss 1024>

SYN 1823083521: 1823083521 (0) <mss 1024>

ACK 1415531521

ACK 1823083522

Destino
B

Estabeleci mento da Conexo

Ativo x passivo

A origem da solicitao de conexo executa o

active open
O destino que recebe a solicitao de conexo
executa o passive open

Origem e destino enviam seus nmero de

seqncia iniciais para a conexo em curso

Este nmero deve ser alterado ao longo do

tempo e ser diferente de conexo para conexo

Inicializao do Nmero de
Seqncia

RFC 793

Nmero de 32 bits
incrementado a cada 4 microsegundos

Como escolher o nmero inicial?

4.4BSD

Quando sistema inicializado o nmero de

seqncia 1 (violao da RFC)
A varivel incrementada de 64.000 a cada
segundo
Isso significa que ir retornar a 0 em perodos de 9
horas e

MSS (Maximum Segment Size)

O MSS representa o tamanho do maior

bloco de dados que poder ser enviado
para o destino.
No negocivel, cada host divulga o seu
MSS

Default: 536 bytes (20 bytes IP, 20 bytes TCP,

para um total de 576 bytes)
Ethernet: 1460 bytes (20 bytes IP, 20 bytes
TCP, para um total de 1500 bytes)

MSS...

Em geral, quanto maior o MSS melhor, at

que ocorra fragmentao

Quanto maior a quantidade de dados enviados

em um nico bloco, menor o overhead de
headers do TCP e do IP

Exemplo

MSS 1460

MSS 256

Outras Opes TCP

End of option list (1 byte)

No operation (NOP) (1 byte)
Windows scale factor (3 bytes)
Timestamp (10 bytes)
MSS (4 bytes)

Encerramento da Conexo
Origem
A

FIN 1415531522:1415531522 (0) ACK 1823083522

ACK 1415531523

FIN 1823083522: 1823083522 (0)

ACK 1415531523

ACK 1823083523

Destino
B

Encerramento da Conexo

Half Close

Conexes TCP so full-duplex, logo cada lado

da conexo deve finalizar a conexo de forma
independente
Quando um dos lados envolvidos recebe uma
solicitao de finalizao deve enviar a
notificao para a aplicao

Uma aplicao aps receber o pedido de

finalizao ainda pode mandar dados

Half Close - Exemplo

bsdi

sun
FIN + ACK

Exemplo:

ACK

sun% rsh bsdi < datafile

Data
Ack of Data
datafile

std
input

sun
rsh

terminal

std
output

bsdi
sort

FIN + ACK

ACK

Timeout no Estabelecimento da
Conexo

Trecho de trfego monitorado (tcpdump)

Importante: tempo entre cada tentativa vs.

tempo mximo exigido na RFC

Tempo: 75 segundos
4.4 BSD: leva 76 segundos
Problema: Timeout

Diagrama de Estados - TCP

Estados x Mensagens
Origem
SYN_SENT

SYN

Destino
LISTEN
SYN_RCVD

SYN + ACK
ESTABLISHED

ACK
ESTABLISHED

FIN_WAIT 1

FIN
CLOSE_WAIT
ACK

FIN_WAIT 2
FIN + ACK
TIME_WAIT 2

LAST_ACK

ACK
CLOSED

2MSL Wait State

O TIME_WAIT tabm chamado 2MSL

MSL = Maximum Segment Life

Tempo mximo que um segmento pode existir
antes de ser descartado
TTL do IP ???

RFC 793

MSL dever ser de 2 minutos

Mas as implementaes variam de entre 30
segundos, 1 minuto e 2 minutos

Utilizao do 2MSL

Quando executado um active close e

enviado o ACK final, a conexo deve
permanecer no estado TIME_WAIT pelo
dobro do tempo especificado no MSL

Isso ir permitir a retransmisso do ACK final,

caso o primeiro seja perdido
Outra conseqncia a no liberao do par
de sockets utilizados para a conexo
Algumas implementaes restringem tambm
o uso das portas locais durante o 2MSL

Utilizao do 2MSL

Socket option

SO_REUSEADDR
Transpor as regras sobre uso do endereo das
portas

Quanto a transmisso de dados

Qualquer segmento que chegue para uma

conexo neste perodo (2MSL) dever ser
descartado

Conseqncias para clientes e servidores?

Quite Time

Considere a seguinte situao

Ocorre uma falha no host que est no estado 2MSL

Ele faz o reboot ainda no perodo de espera do MSL
Ele estabelece uma nova conexo imediatamente,
usando o mesmo endereo de porta local e porta
remota

O que poder ocorrer neste caso?

Para prevenir, o host deve esperar por MSL
segundos, aps o reboot, antes de estabelecer
qualquer conexo nova.

Reset de Conexes

Em geral, um Reset gerado sempre que

recebido um segmento que no parece
estar correto para a conexo identificada.
Casos

Solicitaes de conexes para portas

inexistentes
Aborto de conexes
Solicitaes de conexes falsas

Estabelecimento de Conexes
Simultneas

possvel que 2 hosts tentem estabelecer

conexo entre eles simultaneamente

Ambos executam um active open

Exemplo:

Host A solicita conexo ao Host B na porta 777 e usa

como porta local 888
Host B solicita conexo ao Host A na porta 888 e usa
como porta local 777

TCP foi projetado para suportar estes casos

Apenas uma conexo resulta, no duas

Encerramento de Conexes
simultneas

Os hosts tambm podem tomar a iniciativa

de encerrar a conexo simultaneamente
Origem
FIN_WAIT 1

CLOSING

TIME_WAIT

Destino
FIN

ACK

FIN

ACK

FIN_WAIT 1

CLOSING

TIME_WAIT

SYN FLOOD

Flooding de solicitaes de conexo falsas

Normalmente usa IP Spoofing

Intruso

SYN
SYN
SYN
SYN
SYN
SYN

Destino

Suposta Origem
SYN + ACK

RST
RST

Controle de Erros

O TCP executa controle de erro com

retransmisso

Neste caso o checksum no opcional

Se um segmento TCP recebido com
checksum igual a zero, ele descartado
O destino envia mensagens de
reconhecimento positivo

No envia NACK
A necessidade de realizar uma retransmisso
detectada pela ausncia do ACK

Controle de Fluxo

O TCP executa o
algoritmo de
janela deslizante

A cada envio de
mensagens o host
informa o nmero
de bytes que podem
ser recebidos

Origem

Destino
Dados, ACK(D), Seq (O)
WIN (4096)
Dados, ACK(O), Seq (D)
WIN (512)
Dados, ACK(D), Seq (O)
WIN (4096)

Timeout

Dados, ACK(D), Seq (O)

WIN (4096)
Dados, ACK(O), Seq (D)
WIN (3000)
Dados, ACK(D), Seq (O)
WIN (512)

Erro!!!!

Fluxo Interativo

piggback

Exemplo: rlogin

Origem
digitado

Destino
Dados, ACK(D), Seq (O)
WIN (4096)
servidor

Origem
digitado

ACK(O) + WIN

Destino
Dados, ACK(D), Seq (O)
WIN (4096)
servidor
DADOS + ACK(O) + WIN

display

display

Dados, ACK(O), Seq (D)

WIN

ACK(D) + WIN
echo

ACK(D) + WIN

delayed

echo

Algoritmo de Nagle

Exemplo do Rlogin

Problema?

1 byte de dados
20 bytes TCP + 20 Bytes IP
Overhead de controle

Nagle:

Pequenos segmentos s podem ser enviados

aps o recebimento do ACK dos dados
enviados anteriormente

Algoritmo de Nagle

Assim, o TCP coleta pequenos segmentos de

dados e os envia juntos
A velocidade de envio ir variar com de acordo
com a velocidade de recebimento do ACK

Algoritmo self-clocking

Exemplo: Ethernet

RTT aproximadamente de 16 ms
Para ser mais rpido deveria digitar mais de 60
caracteres por segundo
Isto significa que raramente aplicado nestas redes
Utilizado em redes com RTT maior (p.ex: WAN)

Desabilitando Nagle

Quando necessrio?

Trafego Interativo
Xwindow (movimentos do mouse....)

A API do socket pode utilizar a opo

TCP_NODELAY para desabilitar o
algoritmo