Camada de Transporte TCP

Prévia do material em texto

Aulas do livro disponíveis em:
http://www-net.cs.umass.edu/kurose-ross-ppt-7e/
Camada de 
transporte
TCP
Transmission Control Protocol
TCP: Visão Geral RFCs: 793,1122,1323, 2018, 2581
§ Dados full duplex:
• Fluxo de dados bidirecional na
mesma conexão
• MSS: maximum segment size
§ Orientado a conexão:
• Handshaking (troca de msgs do 
controle) em seu remetente, estado
do receptor antes da troca de 
dados
• Fluxo controlado:
• O remetente não irá sobrecarregar
o receptor
§ Ponto a ponto:
• Um transmissor, um receptor
§ Fluxo de bytes confiável e 
em ordem:
• Sem "limites de mensagem”
• Limitação:
• Congestionamento TCP e controle
de fluxo definem tamanho da janela
Estrutura do segmento TCP
source port # dest port #
32 bits
application
data 
(variable length)
sequence number
acknowledgement number
receive window
Urg data pointerchecksum
FSRPAUhead
len
not
used
options (variable length)
URG: urgent data 
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
# bytes 
rcvr willing
to accept
counting
by bytes 
of data
(not segments!)
Internet
checksum
(as in UDP)
Numero de sequência - ACKs
Numeros de sequencia
• "número" de primeiro byte nos dados 
do segmento
acknowledgements:
• seq # do próximo byte esperado de 
outro lado
• ACK acumulativo
Q: Como o receptor lida com 
segmentos fora de ordem?
R: Não especificado em RFC, 
depende do implementador source port # dest port #
sequence number
acknowledgement number
checksum
rwnd
urg pointer
incoming segment to sender
A
sent 
ACKed
sent, not-
yet ACKed
(“in-
flight”)
usable
but not 
yet sent
not 
usable
window size
N
sender sequence number space 
source port # dest port #
sequence number
acknowledgement number
checksum
rwnd
urg pointer
outgoing segment from sender
Numero de sequência, ACKs
User
types
‘C’
host ACKs
receipt 
of echoed
‘C’
host ACKs
receipt of
‘C’, echoes
back ‘C’
Cenário simples de telnet
Host BHost A
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
TCP round trip time, timeout
Q: como definir o 
valor do timeout 
no TCP?
§ Maior que RTT
• mas RTT varia
§ Muito curto: tempo de 
espera prematuro, 
retransmissões 
desnecessárias
§ Muito longo: reação lenta 
à perda de segmento
Q: Como estimar o RTT?
§ SampleRTT: tempo 
medido desde a transmissão 
do segmento até o 
recebimento ACK (RTT 
instantâneo)
§ Ignora retransmissões
§ SampleRTT : deve variar, 
usar RTT estimado 
”mudança mais suave”
• Média de várias medições recentes, e 
não somente SampleRTT
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RT
T 
(m
illi
se
co
nd
s)
SampleRTT Estimated RTT
EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT
§ Média móvel ponderada exponencial
§ Influência da amostra do passado diminui exponencialmente rápido
§ valor típico: a = 0.125
TCP round trip time, timeout
RT
T 
(m
illi
se
co
nd
s)
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
sampleRTT
EstimatedRTT
time (seconds)
§ Intervalo timeout: EstimatedRTT maior “margem de segurança”
• Grande variação em EstimatedRTT -> maior margem de segurança
• Estimar o desvio padrão de SampleRTT e EstimatedRTT: 
DevRTT = (1-b)*DevRTT +
b*|SampleRTT-EstimatedRTT|
TCP round trip time, timeout
(typically, b = 0.25)
TimeoutInterval = EstimatedRTT + 4*DevRTT
RTT estimado “margem de segurança”
* Check out the online interactive exercises for more 
examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transferência de dados confiável (rdt) no TCP
§ TCP cria serviço rdt em 
cima do serviço não 
confiável do IP
§ Segmentos em paralelo
• Acks acumulativos
• Temporizador de retransmissão
§ Retransmissões 
desencadeadas por:
§ Eventos de timeout
• Acks duplicados
Vamos considerar
inicialmente remente TCP 
simplificado :
• Ignora acks duplicados
• Ignora controle de fluxo e controle
de congestionamento
rdt: reliable data transfer
Eventos remetente TCP
Dados recebidos da aplicação:
§ Cria segmento com 
numero de sequencia (seq 
#)
§ seq # é o fluxo de bytes, 
numero do primeiro byte 
no segmento
§ Iniciar o temporizador se 
ainda não estiver em 
execução
§ Pense no temporizador como no 
segmento mais antigo
§ Intervalo de expiração: 
TimeOutInterval
timeout:
§ Retransmitir segmento 
que causou timeout
§ Reiniciar temporizador
ack recebido:
§ Se ack reconhecer 
segmentos anteriormente 
não reconhecidos
§ Atualizar o que é conhecido por 
ser ACKed
§ Iniciar o temporizador se ainda 
houver segmentos não 
reconhecidos
Remente TCP(simplificado)
wait
for 
event
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
L
create segment, seq. #: NextSeqNum
pass segment to IP (i.e., “send”)
NextSeqNum = NextSeqNum + length(data) 
if (timer currently not running)
start timer
data received from application above
retransmit not-yet-acked segment 
with smallest seq. #
start timer
timeout
if (y > SendBase) { 
SendBase = y 
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer 
} 
ACK received, with ACK field value y 
TCP: cenários de retransmissões
lost ACK scenario
Host BHost A
Seq=92, 8 bytes of data
ACK=100
Seq=92, 8 bytes of data
Xtim
eo
ut
ACK=100
premature timeout
Host BHost A
Seq=92, 8 bytes of data
ACK=100
Seq=92, 8
bytes of data
tim
eo
ut
ACK=120
Seq=100, 20 bytes of data
ACK=120
SendBase=100
SendBase=120
SendBase=120
SendBase=92
TCP: cenários de retransmissões
X
cumulative ACK
Host BHost A
Seq=92, 8 bytes of data
ACK=100
Seq=120, 15 bytes of data
tim
eo
ut
Seq=100, 20 bytes of data
ACK=120
TCP geração ACKs [RFC 1122, RFC 2581]
Evento no receptor
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
expected seq #. One other 
segment has ACK pending
arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
arrival of segment that 
partially or completely fills gap
Ação do receptor TCP
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
immediately send single cumulative 
ACK, ACKing both in-order segments 
immediately send duplicate ACK,
indicating seq. # of next expected byte
immediate send ACK, provided that
segment starts at lower end of gap
TCP retransmissão rápida
• Período de timeout 
frequentemente 
relativamente longo:
§ Atraso longo antes de reenviar 
pacotes perdidos
§ Detectar segmentos 
perdidos via ACKs 
duplicados.
• O remetente frequentemente 
envia muitos segmentos 
• Se o segmento for perdido, 
provavelmente haverá muitos 
ACKs duplicados.
Se o remetente receber 3 ACKs 
para os mesmos dados
(“triple duplicate ACKs”),
Reenvie o segmento não 
confirmado com o menor # seq 
•Provável que o segmento não 
confirmado esteja perdido, por isso 
não espera por timeout
TCP retransmissão rápida
X
Retransmissão rápida após o remetente
receber triplo ACK duplicado
Host BHost A
Seq=92, 8 bytes of data
ACK=100
tim
eo
ut ACK=100
ACK=100
ACK=100
TCP retransmissão rápida
Seq=100, 20 bytes of data
Seq=100, 20 bytes of data
Controle de Fluxo do TCP
application
process
TCP socket
receiver buffers
TCP
code
IP
code
application
OS
Pilha de protocolo do receptor
Aplicação pode
remover dados de
buffers de sockets TCP … 
… mais lento 
do que o TCP 
receptor está 
entregando
(o emissor está 
enviando)
from sender
receptor controla o remetente, 
de modo que o remetente não 
transbordará o buffer do receptor, 
transmitindo muito rápido
Controle de fluxo
Controle de Fluxo do TCP 
buffered data
free buffer spacerwnd
RcvBuffer
TCP segment payloads
to application process
§ Receptor "anuncia" espaço de 
buffer livre, incluindo o valor 
rwnd no cabeçalho TCP de 
segmentos de receptor para 
remetente
§ O tamanho do RcvBuffer é definidoatravés de opções de soquete (o 
padrão padrão é 4096 bytes)
§ Muitos sistemas operacionais auto 
ajustam o RcvBuffer
§ O remetente limita a quantidade 
de dados não recebidos (”no ar") 
para o valor de rwnd do 
receptor
§ Garante que o buffer do receptor 
não transbordará
receiver-side buffering
Gerência de Conexão
Antes de trocar dados, "handshake" do emissor / receptor:
• Concordam em estabelecer conexão (cada um conhecendo o outro 
disposto a estabelecer conexão)
• Acordo sobre parâmetros de conexão
connection state: ESTAB
connection variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client 
application
network
connection state: ESTAB
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client 
application
network
Socket clientSocket = 
newSocket("hostname","port 
number");
Socket connectionSocket = 
welcomeSocket.accept();
Q: O handshake em 2 vias 
sempre irá funcionar em 
uma rede?
§ Atrasos variáveis
§ Mensagens retransmitidas 
(e.g. req_conn(x)) devido a 
perda de mensagem
§ Reordenação de mensagens
§ Não pode “ver” outro lado
Handshake 2 vias :
Let’s talk
OK
ESTAB
ESTAB
choose x req_conn(x)
ESTAB
ESTAB
acc_conn(x)
Concordando em estabelecer uma conexão
Concordando em estabelecer uma conexão
Cenários de falhas de handshake de 2 vias:
retransmit
req_conn(x)
ESTAB
req_conn(x)
half open connection!
(no client!)
client 
terminates
server
forgets x
connection 
x completes
retransmit
req_conn(x)
ESTAB
req_conn(x)
data(x+1)
retransmit
data(x+1)
accept
data(x+1)
choose x
req_conn(x)
ESTAB
ESTAB
acc_conn(x)
client 
terminates
ESTAB
choose x
req_conn(x)
ESTAB
acc_conn(x)
data(x+1) accept
data(x+1)
connection 
x completes server
forgets x
TCP 3-way handshake (troca em 3 vias)
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
ESTAB
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
choose init seq num, y
send TCP SYNACK
msg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x) 
indicates server is live;
send ACK for SYNACK;
this segment may contain 
client-to-server data received ACK(y) 
indicates client is live
SYNSENT
ESTAB
SYN RCVD
client state
LISTEN
server state
LISTEN
TCP 3-way handshake: FSM
closed
L
listen
SYN
rcvd
SYN
sent
ESTAB
Socket clientSocket = 
newSocket("hostname","port 
number");
SYN(seq=x)
Socket connectionSocket = 
welcomeSocket.accept();
SYN(x)
SYNACK(seq=y,ACKnum=x+1)
create new socket for 
communication back to client
SYNACK(seq=y,ACKnum=x+1)
ACK(ACKnum=y+1)ACK(ACKnum=y+1)
L
TCP: fechando uma conexão
§ Cliente, servidor cada fechar seu lado de conexão
§ Enviar segmento TCP com bit FIN = 1
§ Responder ao FIN recebido com ACK
• Ao receber FIN, o ACK pode ser combinado com o próprio FIN
• Trocas simultâneas FIN podem ser manipuladas
FIN_WAIT_2
CLOSE_WAIT
FINbit=1, seq=y
ACKbit=1; ACKnum=y+1
ACKbit=1; ACKnum=x+1
wait for server
close
can still
send data
can no longer
send data
LAST_ACK
CLOSED
TIMED_WAIT
timed wait 
for 2*max 
segment lifetime
CLOSED
TCP: fechando uma conexão
FIN_WAIT_1 FINbit=1, seq=xcan no longer
send but can
receive data
clientSocket.close()
client state server state
ESTABESTAB