TCP Udp

Protocolos de Transporte da
Pilha TCP/IP

Redes II
Redes de Computadores Profa. Ana Benso
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
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.
Porta Destino Porta Origem
Tamanho Checksum

Dados

0 16 31
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 Destino
Endereo IP Origem
Zero Tamanho Protocolo
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
Porta Destino Porta Origem
Tamanho Checksum

Dados

0 16 31
Endereo IP Destino
Endereo IP Origem
Zero Tamanho Protocolo
Pseudo-Header
Datagrama UDP
Header UDP
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
Window Tam. Reser. Flags
Checksum 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
Destino
B
SYN 1415531521:1415531521 (0) <mss 1024>
SYN 1823083521: 1823083521 (0) <mss 1024>
ACK 1415531521
ACK 1823083522
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

A B
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)

Origem
A
Destino
B
FIN 1415531522:1415531522 (0) ACK 1823083522
ACK 1415531523
ACK 1823083523
FIN 1823083522: 1823083522 (0)
ACK 1415531523

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
FIN + ACK
ACK
ACK
FIN + ACK
Data
Ack of Data
Exemplo:

sun% rsh bsdi < datafile

datafile
terminal
std
input
std
output
rsh
sort
sun bsdi
sun
bsdi
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 Destino
SYN
SYN + ACK
ACK
SYN_SENT
SYN_RCVD
LISTEN
ESTABLISHED
ESTABLISHED
FIN
FIN_WAIT 1
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 Destino
FIN
FIN_WAIT 1
ACK
CLOSING
TIME_WAIT
ACK
FIN FIN_WAIT 1
CLOSING
TIME_WAIT
SYN FLOOD
Flooding de solicitaes de conexo falsas
Normalmente usa IP Spoofing

Intruso Destino Suposta Origem
SYN
SYN + ACK
RST
SYN
SYN
SYN
SYN
SYN
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
Destino Origem
Dados, ACK(D), Seq (O)
WIN (4096)
Dados, ACK(O), Seq (D)
WIN (512)
WIN (4096)
Erro!!!!
WIN (4096)
Timeout
WIN (3000)
WIN (512)
Fluxo Interativo
Exemplo: rlogin
Destino Origem
WIN (4096)
ACK(O) + WIN
ACK(D) + WIN
WIN
digitado
servidor
echo
display
Destino Origem
WIN (4096)
DADOS + ACK(O) + WIN
ACK(D) + WIN
digitado
servidor
echo
display
piggback
delayed
Algoritmo de Nagle
Exemplo do Rlogin
1 byte de dados
20 bytes TCP + 20 Bytes IP
Problema?
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

TCP Udp

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCP Udp

Enviado por

Direitos autorais:

Formatos disponíveis

Protocolos de Transporte da

Você também pode gostar