0% found this document useful (0 votes)
3 views

Lecture 5 - Transport Layer Final

Lecture 5_Transport Layer Final

Uploaded by

Jac Tad Cupa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

Lecture 5 - Transport Layer Final

Lecture 5_Transport Layer Final

Uploaded by

Jac Tad Cupa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 35

Machine Translated by Google

Capítulo 3: roteiro
§ Serviços da camada de transporte

§ Multiplexação e demultiplexação § Transporte

sem conexão: UDP § Princípios de transferência

confiável de dados § Transporte orientado a

conexão: TCP • estrutura de segmento • transferência


confiável de dados

• controle de fluxo

• gerenciamento de conexão

§ Princípios de controle de congestionamento §

Controle de congestionamento TCP


Camada de Transporte: 3-1
Machine Translated by Google

Controle de fluxo TCP


aplicativo
P: O que acontece se a camada de processo
Aplicativo removendo
rede entregar dados mais rapidamente dados de buffers de
soquete TCP
do que a camada de aplicação Soquete TCP
remover dados dos buffers de soquete? buffers de receptor

TCP
código
Camada de rede
entregando carga útil de
datagrama IP em
buffers de soquete TCP PI
código

do remetente

pilha de protocolos do receptor

Camada de Transporte: 3-2


Machine Translated by Google

Controle de fluxo TCP


aplicativo
P: O que acontece se a camada de processo
Aplicativo removendo
rede entregar dados mais rapidamente dados de buffers de
soquete TCP
do que a camada de aplicação Soquete TCP
remover dados dos buffers de soquete? buffers de receptor

TCP
código
Camada de rede
entregando carga útil de
datagrama IP em
buffers de soquete TCP PI
código

do remetente

pilha de protocolos do receptor

Camada de Transporte: 3-3


Machine Translated by Google

Controle de fluxo TCP


aplicativo
P: O que acontece se a camada de processo
Aplicativo removendo
rede entregar dados mais rapidamente dados de buffers de
soquete TCP
do que a camada de aplicação Soquete TCP
remover dados dos buffers de soquete? buffers de receptor

TCP
código

janela de recebimento
controle de fluxo: # bytes
receptor disposto a aceitar PI
código

do remetente

pilha de protocolos do receptor

Camada de Transporte: 3-4


Machine Translated by Google

Controle de fluxo TCP


aplicativo
P: O que acontece se a camada de processo
Aplicativo removendo
rede entregar dados mais rapidamente dados de buffers de
soquete TCP
do que a camada de aplicação Soquete TCP
remover dados dos buffers de soquete? buffers de receptor

TCP

controle de fluxo código

o receptor controla o remetente,


para que o remetente não PI
código
transborde o buffer do
receptor transmitindo muito, muito rápido

do remetente

pilha de protocolos do receptor

Camada de Transporte: 3-5


Machine Translated by Google

Controle de fluxo TCP

§ O receptor TCP “anuncia” espaço livre no buffer


no campo rwnd no cabeçalho TCP para o processo de inscrição

• Tamanho do RcvBuffer definido via soquete


dados armazenados em buffer
opções (o padrão típico é 4096 bytes) RcvBuffer

• muitos sistemas operacionais se ajustam automaticamente


rwnd espaço livre no buffer
RcvBuffer

§ remetente limita quantidade de unACKed


Cargas úteis do segmento TCP
(“em voo”) dados para rwnd recebido

§ garante que o buffer de recebimento não irá Buffer do lado do receptor TCP
transbordar

Camada de Transporte: 3-6


Machine Translated by Google

Controle de fluxo TCP


controle de fluxo: # bytes receptor disposto a aceitar

§ O receptor TCP “anuncia” espaço livre no buffer


no campo rwnd no cabeçalho TCP
• Tamanho do RcvBuffer definido via soquete
janela de recebimento
opções (o padrão típico é 4096 bytes)

• muitos sistemas operacionais se ajustam automaticamente


RcvBuffer

§ remetente limita quantidade de unACKed


(“em voo”) dados para rwnd recebido

§ garante que o buffer de recebimento não irá


transbordar
Formato de segmento TCP

Camada de Transporte: 3-7


Machine Translated by Google

Gerenciamento de conexão TCP


antes da troca de dados, “aperto de mão” remetente/destinatário:
§
concordam em estabelecer conexão (cada um conhecendo o outro disposto a estabelecer conexão)
§
concordar com os parâmetros de conexão (por exemplo, iniciar seq #s)

aplicativo aplicativo

estado de conexão: ESTAB estado de conexão: ESTAB


variáveis de conexão: Variáveis de conexão:
seq # cliente para servidor seq # cliente para servidor
servidor para cliente servidor para cliente
Tamanho do rcvBuffer Tamanho do rcvBuffer
no servidor, cliente no servidor, cliente

rede rede

Soquete clienteSocket = Soquete connectionSocket = bem-


newSocket("nome do host","número da porta"); vindoSocket.accept();

Camada de Transporte: 3-8


Machine Translated by Google

Concordando em estabelecer uma conexão


Aperto de mão bidirecional:

P: O handshake bidirecional sempre funcionará


Vamos conversar
na rede?
ESTABELECER

OK § atrasos variáveis
ESTABELECER

§ mensagens retransmitidas (por exemplo


req_conn(x)) devido à perda de mensagem
§
reordenação de mensagens
escolha x § não consigo “ver” o outro lado
req_conn(x)
ESTABELECER

acc_conn(x)
ESTABELECER

Camada de Transporte: 3-9


Machine Translated by Google

Cenários de handshake bidirecional

escolha x
req_conn(x)
ESTABELECER

acc_conn(x)

ESTABELECER

dados (x+1) aceitar


dados (x+1)
ACK(x+1)

conexão
x concluída

Sem problemas!

Camada de Transporte: 3-10


Machine Translated by Google

Cenários de handshake bidirecional

escolha x
req_conn(x)
ESTABELECER

retransmitir
acc_conn(x)
req_conn(x)

ESTABELECER

req_conn(x)

conexão
cliente x concluída servidor
termina esquece x

ESTABELECER

acc_conn(x)
Problema: conexão
meio aberta! (sem cliente)
Camada de Transporte: 3-11
Machine Translated by Google

Cenários de handshake bidirecional

escolha x
req_conn(x)
ESTABELECER

retransmitir
acc_conn(x)
req_conn(x)

ESTABELECER

dados (x+1) aceitar


dados (x+1)
retransmitir
dados (x+1)
conexão
cliente x concluída servidor
termina esquece x
req_conn(x)

ESTABELECER

dados (x+1)
aceitar
dados (x+1)
Problema: dados
duplicados aceitos!
Machine Translated by Google

Aperto de mão TCP de 3 vias


Estado do servidor

serverSocket = soquete (AF_INET, SOCK_STREAM)


Estado do cliente serverSocket.bind(('',serverPort)) serverSocket.listen(1)
connectionSocket, addr =
clienteSocket = soquete(AF_INET, SOCK_STREAM) serverSocket.accept()
OUVIR
clientSocket.connect((nomeservidor,portaservidor)) OUVIR
escolha init seq num, x envie
mensagem TCP SYN
SINSENTO SYNbit = 1, Seq = x
escolha init seq num, e envie
a mensagem TCP
SYNACK, confirmando SYN SUA RCVD

SYNbit = 1, Seq = y
ACKbit=1; ACKnum=x+1
SYNACK(x) recebido
indica que o servidor está
ESTABELECER
ativo; envie ACK para
SYNACK; este segmento pode
ACKbit=1,
conter dados de cliente para servidor ACKnum=y+1
ACK recebido (y)
indica que o cliente está ativo
ESTABELECER

Camada de Transporte: 3-13


Machine Translated by Google

Um protocolo de handshake humano de 3 vias

1. Na segurança?

2. Aguarde.
3. Escalada.

Camada de Transporte: 3-14


Machine Translated by Google

Fechando uma conexão TCP


§ cliente, servidor fecham cada um seu lado da conexão •
envia segmento TCP com bit FIN = 1
§ responde ao FIN recebido com ACK •
ao receber FIN, ACK pode ser combinado com o próprio FIN
§ trocas FIN simultâneas podem ser tratadas

Camada de Transporte: 3-15


Machine Translated by Google

Capítulo 3: roteiro
§ Serviços da camada de
transporte § Multiplexação e demultiplexação
§ Transporte sem conexão: UDP §
Princípios de transferência confiável de
dados § Transporte orientado à conexão: TCP
§ Princípios de controle de
congestionamento § Controle
de congestionamento TCP §
Evolução da funcionalidade da camada de transporte

Camada de Transporte: 3-16


Machine Translated by Google

Princípios de controle de congestionamento

Congestionamento:

§ informalmente: “muitas fontes enviando muitos dados rápido demais para serem tratados
pela rede ”

§ manifestações:

• longos atrasos (enfileiramento nos buffers do roteador)


• perda de pacotes (estouro de buffer em roteadores)
§ diferente do controle de fluxo!
controle de congestionamento:
muitos remetentes,
§ um dos 10 principais problemas!
envio muito rápido

controle de fluxo: um remetente


muito rápido para um receptor

Camada de Transporte: 3-17


Machine Translated by Google

Abordagens para controle de congestionamento

Controle de congestionamento final:


§ nenhum feedback explícito da
rede

§ congestionamento inferido da dados dados


ACKs
perda observada, atraso ACKs

§ abordagem adotada pelo TCP

Camada de Transporte: 3-18


Machine Translated by Google

Abordagens para controle de congestionamento

Controle de congestionamento assistido


por rede:
informações explícitas sobre congestionamento

§ roteadores fornecem feedback direto para


hosts emissores/recebedores com fluxos dados dados
ACKs
ACKs
passando por roteadores congestionados

§
pode indicar o nível de congestionamento ou
definir explicitamente a taxa de envio

§ Protocolos TCP ECN, ATM, DECbit

Camada de Transporte: 3-19


Machine Translated by Google

Capítulo 3: roteiro
§ Serviços da camada de
transporte § Multiplexação e demultiplexação
§ Transporte sem conexão: UDP §
Princípios de transferência confiável de
dados § Transporte orientado à conexão: TCP
§ Princípios de controle de
congestionamento § Controle
de congestionamento TCP §
Evolução da funcionalidade da camada de transporte

Camada de Transporte: 3-20


Machine Translated by Google

Controle de congestionamento TCP: AIMD


§ abordagem: os remetentes podem aumentar a taxa de envio até que ocorra perda de pacotes
(congestionamento) e, em seguida, diminuir a taxa de envio em caso de perda

Aumento de Aditivos
Diminuição Multiplicativa

aumentar a taxa de envio em 1 tamanho reduzir a taxa de envio pela metade


máximo de segmento a cada em cada evento de perda
RTT até perda detectada

Dente de serra AIMD

comportamento: sondando
eeT
n
o
xvC
im
aP
etnetoe a er
d

para largura de banda

tempo Camada de Transporte: 3-21


Machine Translated by Google

TCP AIMD: mais


Detalhe de diminuição multiplicativa : a taxa de envio é §
cortada pela metade na perda detectada por ACK triplo duplicado (TCP Reno)
§ Cortar para 1 MSS (tamanho máximo do segmento) quando perda detectada
por timeout (TCP Tahoe)

Por que AIMD?


§ AIMD – um algoritmo distribuído e assíncrono – foi
mostrado para:

• otimizar taxas de fluxo congestionadas em toda a rede!


• têm propriedades de estabilidade desejáveis

Camada de Transporte: 3-22


Machine Translated by Google

Controle de congestionamento TCP: detalhes


espaço do número de sequência do remetente

bueiro Comportamento de envio TCP:


§ aproximadamente: envie bytes cwnd,
espere RTT por ACKS e envie
mais bytes
último byte
Reconhecido disponível, mas ~ bueiro
enviado, mas
não usado
Taxa TCP ~ bytes/s
ainda não RTT
confirmado (“em voo”) último byte enviado

§ O remetente TCP limita a transmissão: LastByteSent- LastByteAcked < cwnd

§ cwnd é ajustado dinamicamente em resposta ao observado


congestionamento de rede (implementando controle de congestionamento TCP)

Camada de Transporte: 3-23


Machine Translated by Google

Início lento do TCP


Anfitrião A Anfitrião B

§ quando a conexão começar,


aumente a taxa exponencialmente
até o primeiro evento de perda: um segmento

TTR
• inicialmente cwnd = 1 MSS
dois segmentos
• cwnd duplo a cada RTT
• feito incrementando cwnd
para cada ACK recebido quatro segmentos

§
resumo: a taxa inicial é lenta,
mas aumenta
tempo
exponencialmente rápido

Camada de Transporte: 3-24


Machine Translated by Google

TCP: do início lento à prevenção de congestionamento

P: quando o aumento exponencial


deve mudar para linear?
X
R: quando cwnd atinge 1/2 de seu
valor antes do tempo limite.

Implementação:
§ variável ssthresh

§ no evento de perda, ssthresh é definido


como 1/2 de cwnd logo antes do evento de perda

* Confira os exercícios interativos online para mais exemplos: http://gaia.cs.umass.edu/kurose_ross/interactive/


Camada de Transporte: 3-25
Machine Translated by Google

Resumo: Controle de congestionamento TCP


Novo
Novo ACK!
novo ACK
ACK!
ACK duplicado
dupACKcount++ novo ACK
.
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS
transmitir novo(s) segmento(s), conforme permitido
dupACKcount = 0
eu transmitir novo(s) segmento(s), conforme permitido
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0 início eu prevenção de
lento congestionamento
tempo
limite ssthresh =
cwnd/2 cwnd = ACK duplicado
tempo 1 MSS dupACKcount dupACKcount++
limite ssthresh = cwnd/ = 0 retransmitir segmento ausente
2 cwnd = 1 MSS
dupACKcount = 0
retransmitir segmento ausente Novo
tempo
limite ssthresh = cwnd/
ACK!
2 cwnd = Novo ACK
1 dupACKcount = 0 cwnd = ssthresh
dupACKcount == 3 dupACKcount == 3
retransmitir segmento ausente dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmite segmento ausente retransmite segmento ausente
rápido

recuperação

ACK duplicado
cwnd = cwnd + MSS
transmite novo(s) segmento(s), conforme permitido

Camada de Transporte: 3-26


Machine Translated by Google

TCP e o congestionado “link gargalo”


§ TCP aumenta a taxa de envio do TCP até que ocorra perda de pacotes na saída
de algum roteador: o link gargalo

fonte
destino

aplicativo aplicativo
TCP TCP
link de link de
rede rede
fila físico
física de pacotes
quase nunca vazia, às
vezes transborda pacotes (perda)

link gargalo (quase sempre ocupado)


Camada de Transporte: 3-27
Machine Translated by Google

TCP e o congestionado “link gargalo”


§ TCP aumenta a taxa de envio do TCP até que ocorra perda de pacotes na saída de
algum roteador: o link gargalo

§ compreensão do congestionamento: útil para focar em links de gargalos congestionados

insight: aumentar a taxa de envio de TCP


fonte não aumentará todo o processo com
destino
gargalo congestionado
aplicativo aplicativo
TCP TCP
link de link de
rede rede
físico físico

insight: aumentar a taxa


de envio de TCP
aumentará o RTT medido
Objetivo: “manter o tubo final cheio, mas não mais cheio”
RTT
Camada de Transporte: 3-28
Machine Translated by Google

Justiça TCP
Objetivo de justiça: se K sessões TCP compartilham o mesmo link de
gargalo de largura de banda R, cada uma deve ter taxa média de R/ K

Conexão TCP 1

gargalo O TCP é justo?


roteador R: Sim, sob suposições
Conexão TCP 2
capacidade R
idealizadas:
§ mesmo RTT
§ número fixo de sessões apenas para
evitar congestionamentos
Camada de Transporte: 3-29
Machine Translated by Google

Camada de transporte: roteiro

§ Serviços da camada de
transporte § Multiplexação e demultiplexação
§ Transporte sem conexão: UDP §
Princípios de transferência confiável de
dados § Transporte orientado à conexão: TCP
§ Princípios de controle de
congestionamento § Controle
de congestionamento TCP §
Evolução da funcionalidade da camada de transporte

Camada de Transporte: 3-30


Machine Translated by Google

Funcionalidade da camada de transporte em evolução

§ TCP, UDP: principais protocolos de transporte há 40 anos


§ diferentes “sabores” de TCP desenvolvidos, para cenários específicos:
Cenário Desafios
Pipes longos e grossos (grandes Muitos pacotes “em vôo”; perda desliga pipeline
transferências de dados)
Redes sem fio Perda devido a links sem fio barulhentos, mobilidade;
TCP trata isso como perda de congestionamento

Links de longo atraso RTTs extremamente longos


Redes de data centers Sensível à latência
Fluxos de tráfego em segundo plano Fluxos TCP de “fundo” de baixa prioridade

§ mover funções da camada de transporte para a camada de aplicação, além do UDP


• HTTP/3: QUIC
Camada de Transporte: 3-31
Machine Translated by Google

QUIC: conexões rápidas de Internet UDP


§ protocolo da camada de aplicação, além do UDP •
aumenta o desempenho do HTTP •
implantado em muitos servidores e aplicativos do Google (Chrome, aplicativo móvel do YouTube)

HTTP/2 HTTP/2 (reduzido)


Aplicativo HTTP/3
TLS QUEM

Transporte TCP UDP

Rede PI PI

HTTP/2 sobre TCP HTTP/2 sobre QUIC sobre UDP

Camada de Transporte: 3-32


Machine Translated by Google

QUIC: conexões rápidas de Internet UDP


adota abordagens que estudamos neste capítulo para
estabelecimento de conexão, controle de erros, controle de congestionamento
• controle de erros e congestionamento: “Leitores familiarizados com a perda de TCP
detecção e controle de congestionamento encontrarão aqui algoritmos paralelos aos TCP
bem conhecidos. [da especificação QUIC]
• estabelecimento de conexão: confiabilidade, controle de congestionamento,
autenticação, criptografia, estado estabelecido em um RTT

§ múltiplos “streams” em nível de aplicação multiplexados em um único QUIC


conexão
• transferência de dados confiável e separada, segurança
• controle de congestionamento comum

Camada de Transporte: 3-33


Machine Translated by Google

QUIC: Estabelecimento de conexão

Handshake TCP
(camada de transporte) Aperto de mão QUIC

dados
Aperto de mão TLS
(segurança)
dados

TCP (confiabilidade, estado de controle de


QUIC: confiabilidade, controle de congestionamento,
congestionamento) + TLS (autenticação, estado autenticação, estado criptográfico
criptográfico)
§ 1 aperto de mão
§ 2 apertos de mão seriais

Camada de Transporte: 3-34


Machine Translated by Google

QUIC: streams: paralelismo, sem bloqueio HOL

HTTP HTTP
PEGAR HTTP
PEGAR
PEGAR
HTTP HTTP
PEGAR PEGAR

HTTP
aplicativo
PEGAR QUEM QUEM QUEM QUEM
Criptografia QUIC
criptografar criptografar
criptografar criptografar Criptografia QUIC

QUEM QUEM QUEM QUEM QUEM QUEM


Criptografia TLS Criptografia TLS TDR TDR TDR erro!
TDR TDR TDR

OMS Cong. Cont. OMS Cong. Cont.


RDT TCP RDT
erro! TCP

transporte

Configuração TCP . Contr. Configuração TCP . Contr. UDP UDP

(a)HTTP 1.1 (b) HTTP/2 com QUIC: sem bloqueio HOL

Camada de Transporte: 3-35

You might also like