Camada de Transporte layers

UDP e TCP (Camada 4)

Introdução

A Camada de Transporte (Camada 4 do OSI, Camada 3 do TCP/IP) proporciona comunicação fim-a-fim entre processos em hosts diferentes. Utiliza portas para multiplexação, oferecendo serviços como entrega confiável (TCP), entrega rápida (UDP), controle de fluxo e congestionamento. Depende da Camada de Rede (Aula 6, 7, 8) para entrega de pacotes.

Serviços Principais

Serviço Descrição Protocolo
Multiplexação Permite múltiplos processos compartilharem a interface de rede via portas TCP, UDP
Confiabilidade Garante entrega e ordem correta dos dados TCP
Controle de Fluxo Evita sobrecarga do receptor usando janela deslizante TCP
Controle de Congestionamento Ajusta a taxa de envio para evitar sobrecarga da rede TCP

Topologia de Comunicação

transport_topology.txt
[Client: 192.168.1.10:12345]---[Router]---[Server: 203.0.113.2:80]
! Exemplo: HTTP (TCP) de Client:12345 para Server:80

Observação Prática

Liste conexões ativas para identificar portas e protocolos:

netstat_example.txt
$ netstat -tuln
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:53 0.0.0.0:*

Atividade Rápida (5 min)

Execute netstat -tuln (ou ss -tuln) em um terminal Linux/Windows. Identifique pelo menos duas portas bem-conhecidas (e.g., 80 para HTTP, 53 para DNS) e seus protocolos (TCP/UDP).

Entregáveis: Lista de portas observadas com seus protocolos.

Leitura: RFC 768 (UDP), RFC 793 (TCP); Kurose §3; Tanenbaum §6.

Portas, Sockets & Multiplexação settings_input_component

Identificação de Processos

Portas

Portas são números de 16 bits que identificam processos em um host, formando um socket único com o IP (Aula 6). Faixas:

  • 0–1023: Bem-conhecidas (e.g., HTTP 80, DNS 53).
  • 1024–49151: Registradas (e.g., apps específicas).
  • 49152–65535: Dinâmicas (atribuídas temporariamente).
Porta Protocolo Aplicação
80 TCP HTTP (web)
53 UDP/TCP DNS
25 TCP SMTP (e-mail)
443 TCP HTTPS

Sockets & API

Um socket é um par IP:porta que identifica um endpoint de comunicação. A API de sockets (Berkeley) inclui:

  • socket(): Cria um socket.
  • bind(): Associa socket a um IP/porta.
  • listen()/accept(): Servidor espera conexões.
  • connect(): Cliente inicia conexão.
  • send()/recv(): Envia/recebe dados.
  • close(): Encerra conexão.

Multiplexação

Permite múltiplos processos compartilharem uma interface de rede:

  • Upward: Vários processos (e.g., navegador, e-mail) usam o mesmo IP via portas diferentes.
  • Downward: Aplicação usa múltiplas interfaces de rede para maior banda.

Topologia de Exemplo

multiplexing_topology.txt
[Client1: 192.168.1.10:12345]---[Router]---[Server: 203.0.113.2:80]
[Client2: 192.168.1.11:12346]---[Router]---[Server: 203.0.113.2:80]
! Múltiplos clientes acessam o mesmo servidor (HTTP, TCP:80)

Exemplo Prático: Sockets Ativos

Observe sockets ativos com:

netstat_example.txt
$ netstat -tunap
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
tcp 0 0 192.168.1.10:12345 203.0.113.2:80 ESTABLISHED 1234/firefox
udp 0 0 0.0.0.0:53 0.0.0.0:* 5678/dnsmasq

Exemplo de Código: Cliente e Servidor TCP

tcp_client.py
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('203.0.113.2', 80))
s.send(b'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n')
data = s.recv(1024)
print(data.decode())
s.close()
tcp_server.py
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('0.0.0.0', 8080))
s.listen(1)
print("Servidor escutando em 0.0.0.0:8080...")
conn, addr = s.accept()
print(f"Conectado por {addr}")
data = conn.recv(1024)
print(f"Dados recebidos: {data.decode()}")
conn.send(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nHello from server!")
conn.close()
s.close()

Análise com Wireshark

Capture pacotes com filtro tcp.port == 80 or udp.port == 53:

  • TCP: Veja portas (e.g., 12345 → 80) no cabeçalho TCP.
  • UDP: Veja portas (e.g., 12346 → 53) no cabeçalho UDP.

Atividade Prática (10 min)

1. Salve o código tcp_client.py e execute-o para conectar a um servidor HTTP (e.g., example.com:80).
2. Use netstat -tunap para verificar o socket ativo (IP:porta).
3. Em Packet Tracer, configure a topologia acima e capture pacotes HTTP com Wireshark.
Entregáveis: Screenshot do netstat mostrando o socket e captura Wireshark com portas.

Leitura: RFC 768 (UDP), RFC 793 (TCP), RFC 6335 (Portas); Kurose §3; Tanenbaum §6.

UDP vs TCP swap_horiz

Comparativo de Serviços

Introdução

UDP (RFC 768) e TCP (RFC 793) são protocolos da Camada de Transporte que oferecem serviços distintos. UDP prioriza velocidade com baixa sobrecarga, enquanto TCP garante confiabilidade, ideal para aplicações críticas. Ambos usam portas para multiplexação (Slide 2).

Comparativo

Característica UDP TCP
Conexão Sem conexão (datagramas independentes) Orientado a conexão (handshake de 3 vias, Slide 4)
Confiabilidade Não confiável (sem retransmissão) Confiável (retransmite dados perdidos)
Controle de Fluxo Sem controle Janela deslizante (limita envio com base no buffer do receptor)
Ordem Não garantida Garantida (usa números de sequência)
Overhead 8 bytes (cabeçalho simples) 20 bytes + opções (cabeçalho complexo)
Latência Baixa (sem delays de conexão) Maior (devido a handshake e controles)
Uso Típico DNS, streaming, VoIP HTTP, FTP, e-mail

Topologia de Exemplo

udp_tcp_topology.txt
[Client: 192.168.1.10:12345]---[Router]---[Server: 203.0.113.2:80] (TCP, HTTP)
[Client: 192.168.1.10:12346]---[Router]---[DNS: 8.8.8.8:53] (UDP, DNS)

Exemplo Prático: Conexões Ativas

Observe conexões UDP e TCP com:

netstat_example.txt
$ netstat -tunap
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
tcp 0 0 192.168.1.10:12345 203.0.113.2:80 ESTABLISHED 1234/firefox
udp 0 0 192.168.1.10:12346 8.8.8.8:53 - 5678/dig

Análise com Wireshark

Capture pacotes com filtro tcp.port == 80 or udp.port == 53:

  • UDP: Cabeçalho simples (8 bytes, portas 12346→53).
  • TCP: Cabeçalho complexo (20 bytes, portas 12345→80, sequência, ACK).

📌 UDP (Porta 12346 → 53)

Por que essas portas?

  • Porta 12346 (origem): Aleatória/ephemeral (cliente)
  • Porta 53 (destino): 53/UDP: DNS (precisa de baixa latência)

Contexto técnico:

Cliente (12346) → Servidor DNS (53)
# Cabeçalho UDP mínimo (8 bytes): Portas + Checksum

📌 TCP (Porta 12345 → 80)

Por que essas portas?

  • Porta 12345 (origem): Aleatória/ephemeral (cliente)
  • Porta 80 (destino): 80/TCP: HTTP (exige confiabilidade)

Contexto técnico:

Cliente (12345) → Servidor Web (80)
# Cabeçalho TCP complexo (20+ bytes): Sequência, ACK, flags, janela

Atividade Prática (10 min)

1. Em Packet Tracer, configure a topologia acima com um cliente (192.168.1.10), servidor HTTP (203.0.113.2:80), e servidor DNS (8.8.8.8:53).
2. Gere tráfego: HTTP (navegador no cliente) e DNS (comando dig example.com).
3. Capture pacotes com Wireshark ou Packet Tracer (filtros tcp.port == 80, udp.port == 53).
4. Use netstat -tunap para verificar conexões.
Entregáveis: Screenshot do netstat mostrando conexões TCP/UDP e captura Wireshark com cabeçalhos.

Leitura: RFC 768 (UDP), RFC 793 (TCP), RFC 6335 (Portas); Kurose §3; Tanenbaum §6.

Handshake TCP & Controle de Fluxo sync

3 Vias e Janela Deslizante

Introdução

TCP (RFC 793) é orientado a conexão, usando o three-way handshake para estabelecer comunicação confiável e o controle de fluxo para evitar sobrecarga do receptor. Esses mecanismos garantem confiabilidade (Slide 3) e eficiência.

Three-Way Handshake

O handshake de três vias estabelece uma conexão TCP, sincronizando números de sequência (seq) e confirmação (ack):

  1. Client → Server: SYN (seq=x, estado: SYN-SENT)
  2. Server → Client: SYN-ACK (seq=y, ack=x+1, estado: SYN-RECEIVED)
  3. Client → Server: ACK (ack=y+1, estado: ESTABLISHED)
handshake_diagram.txt
Client Server
| SYN (seq=x) →| [CLOSED → SYN-SENT]
|← SYN-ACK (seq=y, ack=x+1) [CLOSED → SYN-RECEIVED]
| ACK (ack=y+1) →| [SYN-RECEIVED → ESTABLISHED]
| [SYN-SENT → ESTABLISHED] |

Controle de Fluxo

O receptor anuncia o tamanho da janela (buffer livre, em bytes) no campo Window do cabeçalho TCP. O emissor limita o envio a esse tamanho, evitando sobrecarga. A janela desliza à medida que dados são confirmados.

Exemplo: Receptor anuncia janela de 4096 bytes; emissor envia até 4096 bytes antes de esperar ACK.

Topologia de Exemplo

tcp_topology.txt
[Client: 192.168.1.10:12345]---[Router]---[Server: 203.0.113.2:80]
! Exemplo: HTTP (TCP) com handshake e controle de fluxo

Exemplo Prático: Handshake

Capture o handshake com Wireshark (filtro tcp.port == 80 and tcp.flags.syn == 1):

wireshark_handshake.txt
1. TCP 192.168.1.10:12345 → 203.0.113.2:80 [SYN] Seq=0 Win=65535
2. TCP 203.0.113.2:80 → 192.168.1.10:12345 [SYN, ACK] Seq=0 Ack=1 Win=64240
3. TCP 192.168.1.10:12345 → 203.0.113.2:80 [ACK] Seq=1 Ack=1 Win=65535

Exemplo Prático: Janela Deslizante

Observe a janela com tcpdump ou Wireshark (filtro tcp.port == 80):

tcp_window.txt
TCP 203.0.113.2:80 → 192.168.1.10:12345 [PSH, ACK] Seq=1 Ack=1 Win=64240
TCP 192.168.1.10:12345 → 203.0.113.2:80 [ACK] Seq=1 Ack=1000 Win=64535

Atividade Prática (10 min)

1. Em Packet Tracer, configure a topologia com um cliente (192.168.1.10) e servidor HTTP (203.0.113.2:80).
2. Gere tráfego HTTP (navegador no cliente acessando o servidor).
3. Capture pacotes com Wireshark ou Packet Tracer (filtro tcp.port == 80).
4. Identifique o handshake (SYN, SYN-ACK, ACK) e mudanças na janela (Win=).
5. Use netstat -tunap para verificar a conexão TCP.
Entregáveis: Screenshot do Wireshark mostrando o handshake e janela, e saída do netstat.

Leitura: RFC 793 (TCP), RFC 7323 (Extensões TCP); Kurose §3; Tanenbaum §6.

Controle de Congestionamento timeline

Slow Start, Congestion Avoidance, Fast Retransmit & Recovery

Introdução

O controle de congestionamento do TCP (RFC 5681) evita sobrecarga da rede, ajustando dinamicamente a janela de congestionamento (cwnd). Diferente do controle de fluxo (Slide 4), que protege o receptor, o controle de congestionamento protege a rede.

Mecanismos de Controle

  • Slow Start: cwnd inicia em MSS (e.g., 1460 bytes) e dobra a cada RTT até atingir o limiar (ssthresh, e.g., 65535 bytes).
  • Congestion Avoidance: Após ssthresh, cwnd cresce linearmente (e.g., +MSS por RTT).
  • Fast Retransmit: Retransmite segmento perdido após 3 ACKs duplicados, sem esperar timeout.
  • Fast Recovery: Após retransmissão, ajusta cwnd e ssthresh sem voltar ao Slow Start.

Crescimento da Janela (cwnd)

```chartjs { "type": "line", "data": { "labels": ["RTT 1", "RTT 2", "RTT 3", "RTT 4", "RTT 5", "RTT 6"], "datasets": [{ "label": "cwnd (bytes)", "data": [1460, 2920, 5840, 11680, 23360, 24820], "borderColor": "rgba(0, 136, 255, 1)", "backgroundColor": "rgba(0, 136, 255, 0.2)", "fill": true }] }, "options": { "scales": { "y": { "beginAtZero": true, "title": { "display": true, "text": "Tamanho da Janela (bytes)" } }, "x": { "title": { "display": true, "text": "Round-Trip Time (RTT)" } } }, "plugins": { "title": { "display": true, "text": "Crescimento de cwnd: Slow Start → Congestion Avoidance" }, "annotation": { "annotations": { "threshold": { "type": "line", "yMin": 17520, "yMax": 17520, "borderColor": "rgba(255, 99, 132, 1)", "borderWidth": 2, "label": { "content": "ssthresh", "enabled": true } } } } } } } ```

Topologia de Exemplo

congestion_topology.txt
[Client1: 192.168.1.10:12345]---[Router]---[Server: 203.0.113.2:80]
[Client2: 192.168.1.11:12346]---[Router]---[Server: 203.0.113.2:80]
! Múltiplos clientes causam congestionamento no servidor (TCP, HTTP)

Exemplo Prático: Retransmissão

Capture retransmissões com Wireshark (filtro tcp.port == 80 and tcp.analysis.retransmission):

wireshark_retransmission.txt
TCP 192.168.1.10:12345 → 203.0.113.2:80 [PSH, ACK] Seq=1000 Ack=1 Win=65535
TCP 203.0.113.2:80 → 192.168.1.10:12345 [ACK] Seq=1 Ack=1000 Win=64240
TCP 192.168.1.10:12345 → 203.0.113.2:80 [ACK] Seq=1000 Ack=1 Win=65535 [Duplicate ACK #1]
TCP 192.168.1.10:12345 → 203.0.113.2:80 [ACK] Seq=1000 Ack=1 Win=65535 [Duplicate ACK #2]
TCP 192.168.1.10:12345 → 203.0.113.2:80 [ACK] Seq=1000 Ack=1 Win=65535 [Duplicate ACK #3]
TCP 192.168.1.10:12345 → 203.0.113.2:80 [Retransmission] Seq=1000 Ack=1 Win=65535

Exemplo Prático: Janela de Congestionamento

Observe cwnd com Wireshark (filtro tcp.port == 80):

tcp_window.txt
TCP 192.168.1.10:12345 → 203.0.113.2:80 [PSH, ACK] Seq=1 Ack=1 Win=65535
TCP 203.0.113.2:80 → 192.168.1.10:12345 [ACK] Seq=1 Ack=2920 Win=64240
TCP 203.0.113.2:80 → 192.168.1.10:12345 [ACK] Seq=1 Ack=5840 Win=64240

Atividade Prática (10 min)

1. Em Packet Tracer, configure a topologia com dois clientes (192.168.1.10, 192.168.1.11) e um servidor HTTP (203.0.113.2:80).
2. Gere tráfego intenso (e.g., múltiplos downloads HTTP simultâneos).
3. Capture pacotes com Wireshark (filtro tcp.port == 80 and tcp.analysis.retransmission).
4. Identifique retransmissões e mudanças na janela (Win=).
5. Use netstat -tunap para verificar conexões TCP.
Entregáveis: Screenshot do Wireshark mostrando retransmissões e janela, e saída do netstat.

Leitura: RFC 5681 (Controle de Congestionamento), RFC 793 (TCP); Kurose §3; Tanenbaum §6.

Ferramentas & Simulações terminal

ss, netstat, telnet, nc, Wireshark, Packet Tracer

Introdução

Ferramentas como ss, netstat, telnet, nc, e Wireshark, junto com simulações em Packet Tracer, permitem analisar conexões TCP/UDP (Slides 1–5), incluindo portas (Slide 2), handshake (Slide 4), e controle de congestionamento (Slide 5).

Observação de Conexões

  • ss -tuln / netstat -tuln: Lista portas TCP/UDP em escuta (e.g., 80, 53).
  • netstat -tunap: Mostra conexões ativas com processos (e.g., Firefox, dnsmasq).
  • telnet host porta / nc host porta: Testa handshake TCP (Slide 4).
netstat_example.txt
$ netstat -tunap
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
tcp 0 0 192.168.1.10:12345 203.0.113.2:80 ESTABLISHED 1234/firefox
udp 0 0 192.168.1.10:12346 8.8.8.8:53 - 5678/dig
telnet_example.txt
$ telnet 203.0.113.2 80
Trying 203.0.113.2...
Connected to 203.0.113.2.
GET / HTTP/1.1
Host: example.com
[Enter, Enter]
HTTP/1.1 200 OK...

Simulação Wireshark

Capture tráfego para analisar TCP handshake (Slide 4) e UDP datagramas (Slide 3):

  • TCP: Filtro tcp.port == 80 and tcp.flags.syn == 1 para handshake.
  • UDP: Filtro udp.port == 53 para DNS.
  • Congestionamento: Filtro tcp.port == 80 and tcp.analysis.retransmission para retransmissões (Slide 5).
wireshark_tcp.txt
1. TCP 192.168.1.10:12345 → 203.0.113.2:80 [SYN] Seq=0 Win=65535
2. TCP 203.0.113.2:80 → 192.168.1.10:12345 [SYN, ACK] Seq=0 Ack=1 Win=64240
3. TCP 192.168.1.10:12345 → 203.0.113.2:80 [ACK] Seq=1 Ack=1 Win=65535
wireshark_udp.txt
UDP 192.168.1.10:12346 → 8.8.8.8:53 Src Port: 12346, Dst Port: 53, Length: 60

Simulação Packet Tracer

Configure uma topologia com clientes, servidor HTTP, e servidor DNS para gerar tráfego TCP/UDP e observar handshake, fluxo, e congestionamento (Slides 4–5).

packet_tracer_topology.txt
[Client1: 192.168.1.10:12345]---[Router]---[Server: 203.0.113.2:80] (TCP, HTTP)
[Client2: 192.168.1.11:12346]---[Router]---[DNS: 8.8.8.8:53] (UDP, DNS)
! Tráfego intenso simula congestionamento

Atividade Prática (15 min)

1. Execute netstat -tunap ou ss -tuln para listar conexões TCP/UDP ativas.
2. Use telnet 203.0.113.2 80 ou nc 203.0.113.2 80 para testar um handshake TCP.
3. Em Packet Tracer, configure a topologia acima com dois clientes, um servidor HTTP (203.0.113.2:80), e um servidor DNS (8.8.8.8:53).
4. Gere tráfego: HTTP (navegador) e DNS (dig example.com ou simulação).
5. Capture pacotes com Wireshark (filtros tcp.port == 80, udp.port == 53, tcp.analysis.retransmission).
6. Identifique: handshake TCP, datagramas UDP, retransmissões.
Entregáveis: Screenshot do netstat, saída do telnet/nc, e capturas Wireshark (TCP handshake, UDP, retransmissões).

Leitura: RFC 793 (TCP), RFC 768 (UDP), RFC 5681 (Congestionamento), RFC 6335 (Portas); Kurose §3; Tanenbaum §6.