0% acharam este documento útil (0 voto)
10 visualizações2 páginas

tcp-notes

O TCP foi introduzido em 1974 e utiliza mecanismos de controle como controle de fluxo, congestionamento e ordem para garantir a entrega de dados. O protocolo implementa janelas de recepção e de congestionamento para regular a transmissão de dados, além de ter diferentes algoritmos como TCP Tahoe e TCP Reno para lidar com a perda de pacotes. Desafios em redes de alta largura de banda e latência são abordados com técnicas como TCP window scaling e SACK para otimizar a transmissão.

Enviado por

Suetham Gamer
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato TXT, PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
10 visualizações2 páginas

tcp-notes

O TCP foi introduzido em 1974 e utiliza mecanismos de controle como controle de fluxo, congestionamento e ordem para garantir a entrega de dados. O protocolo implementa janelas de recepção e de congestionamento para regular a transmissão de dados, além de ter diferentes algoritmos como TCP Tahoe e TCP Reno para lidar com a perda de pacotes. Desafios em redes de alta largura de banda e latência são abordados com técnicas como TCP window scaling e SACK para otimizar a transmissão.

Enviado por

Suetham Gamer
Direitos autorais
© © All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato TXT, PDF, TXT ou leia on-line no Scribd
Você está na página 1/ 2

# tcp notes

- Ano em que o TCP foi introduzido


- foi introduzido em 1974
- Mecanismos de controle
- controle de fluxo
- Receive Window (tem a função de um buffer): define quantos bytes
podem ser recebidos. É definido por quem está recebendo os bytes
- Espaço disponível no buffer do sistema que recebe os bytes
(quantos bytes o destino pode receber)
- Envio de mensagens ACK confirmando a recepção dos dados
- controle de congestionamento
- estimativa do congestionamento da rede com base no número de
mensagens ACK recebidas e no tempo do RTT
- regula sua taxa de transmissão (congestion window) com base nisso
- controle de ordem
- usa números de sequência para reorganizar os pacotes quando eles
chegam ao destinatário
- os pacotes podem chegar fora de ordem durante o envio
- Controle de fluxo e como é implementado
- Serve para controlar o tamanho do "buffer" (window) de recebimento de
dados.
- Esse buffer serve para que a taxa de recebimento de dados não ultrapasse a
capacidade de processamento
- Detecção de pacotes perdidos e qual a reação do TCP com isso
- detecção: recepção de ACK duplo ou sinal de timeout
- reação: reduz a Congestion Window
- Congestion window: variável que define quantos bytes podem ser enviados
antes de receber um ACK. É definida por quem está enviando os bytes
- Espaço disponível no buffer do sistema que envia os bytes (quantos
bytes a origem pode enviar)
- ACK duplicado
- um ACK duplo é enviado pelo receptor de um segmento quando ele vem fora de
ordem (ou seja, um dos segmentos está faltando)
- TCP Tahoe vs TCP Reno
- TCP Tahoe: quando ocorre uma perda de pacote: os bytes são enviados
novamente, o ssthresh (limite slow start) é definido como metade do Congestion
Window e o algoritmo de slow start recomeça
- TCP Reno: o mesmo processo do TCP Tahoe, porém no lugar de recomeçar o
algoritmo de slow start, ele começa o algoritmo de congestion avoidance (que é
linear)
- Window size
- Receive window (explicado lá em cima)
- Congestion window (explicado lá em cima)
- Algoritmo de início lento
- algoritmo que determina o tamanho da Congestion window (a taxa de
transmissão)
- cresce exponencialmente até que ocorra algum congestionamento na rede,
então reduz o Congestion window.
- Mecanismo de janela deslizante
- Determina quantos bytes podem ser enviados antes de receber um ACK
- Esse ACK determina o novo tamanho da janela
- O tamanho dessa janela é o menor valor entre o Receive Window e o
Congestion Window
- TCP Fast Retransmit vs TCP Reno
- Fast retransmit: retransmite o segmento perdido ao receber três "duplo ACK"
sem esperar pelo timeout desse segmento
- Reno: (explicado lá em cima)
- Estados de uma conexão TCP
- LISTEN: Esperando por uma requisição de conexão
- 3-way handshake
- SYN-SENT: primeiro SYN foi enviado
- SYN-RECEIVED: SYN-ACK foi enviado
- ESTABLISHED: 3-way handshake já foi feito, ACK recebido
- 4-way handshake
- FIN-WAIT-1: o primeiro FIN do 4-way handshake foi enviado
(solicitação para encerrar a conexão)
- CLOSE-WAIT: o FIN foi recebido e um ACK foi enviado
- FIN-WAIT-2: o ACK foi recebido e o sistema está esperando pelo
próximo FIN
- LAST-ACK: o último FIN foi enviado, esperando pelo último ACK
- TIME-WAIT: recebe o último FIN, envia o último ACK
- CLOSED: 4-way handshake feito, ACK recebido
- Estimativa de Round-Trip Time (RTT) para ajustar temporizadores
- temporizador = timeout
- para definir um tempo de timeout funcional, o RTT não pode ser nem muito
maior (espera desnecessária), nem muito menor (retransmissões desnecessárias)
- é importante estimar o RTT dos segmentos para que o temporizador funcione
de maneira eficiente
- Como o TCP garante que os dados cheguem na ordem correta?
- por meio do controle de orgem (explicado lá em cima)
- números de sequência: todo segmento enviado tem um número de sequência
associado a ele, seu valor inicial é gerado automaticamente
- seu valor (após o valor inicial) é: valor do último ACK recebido
- ACK: o ACK confirma a recepção de um segmento enviando um ACK de valor =
tamanho do segmento + número de sequência
- indica o próximo segmento que ele precisa receber
- Desafios do TCP em redes de alta largura de banda e latência (BDP elevadas) e
como pode ser otimizado nesses ambientes
- Desafios: não utilizar adequadamente a capacidade de rede e perder muito
tempo em detecção e correção de pacotes perdidos
- BDP = capacidade de transmissão * tempo de RTT (representa a quantidade de
bytes transmitidos simultaneamente)
- TCP window scaling: aumenta a janela de 65KB para cerca de 1GB. Alguns
firewalls não implementam essa opção, podendo causar problemas na conexão. É útil
para quando o BDP é maior que 65KB (o tamanho máximo da janela padrão), pois quanto
maior o BDP, maior é o buffer necessário
- SACK: quando ocorre uma perda de múltiplos pacotes, o receptor avisa o
emissor sobre os pacotes que estão faltando e então o emissor reenvia todos esses
pacotes ao mesmo tempo. É útil para o contexto de vários pacotes sendo enviados em
um RTT grande, pois seria custoso ter que reenviar um de cada vez

https://docs.google.com/forms/d/e/1FAIpQLSe9Y2WY9ceeM4XkLPVhMKWL-
7gCR1mOelSvvZwAsEcONQLgYg/formResponse

> DICA:
- Socket (a lib do python por exemplo) é uma API que realiza a comunicação com a
camada de transporte

Você também pode gostar

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy