Redes de Computadores Camada de Transporte. 2 Serviços e protocolos de transporte r Provê comunicação lógica entre processos de aplicação executando em

Redes de Computadores

Camada de Transporte

Camada de Transporte 2

Serviços e protocolos de transporte Provê comunicação lógica entre

processos de aplicação executando em hospedeiros diferentes

Provê um serviço confiável, eficiente e econômico aos seus usuários (processos na camada de aplicação)

Também pode oferecer serviços orientados e não orientados à conexão

protocolos de transporte executam em sistemas terminais

serviços das camadas de transporte X rede:

camada de rede : dados transferidos entre sistemas

camada de transporte: dados transferidos entre processos depende de, estende serviços

da camada de rede

aplicaçãotransporte

redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísicarede

enlacefísica

redeenlacefísica

transporte lógico fim a fim

Interação – camadas de rede, transporte e aplicação


Primitivas de comunicação – camada de transporte



Protocolos da camada de transporteServiços de transporte na

Internet: entrega confiável, ordenada,

ponto a ponto (TCP) congestionamento controle de fluxo estabelecimento de

conexão (setup) entrega não confiável,

(“melhor esforço”), não ordenada, ponto a ponto ou multiponto: UDP

serviços não disponíveis: tempo-real garantias de banda multiponto confiável


redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísicarede

enlacefísica

redeenlacefísica

transporte lógico fim a fim

Sockets de Berkeley


API de desenvovimento de aplicações para rede Utilizada direta ou indiretamente, através de bibliotecas

disponíveis nas linguagens de programação. Envio e recepção de dados em um nível de abstração

baixo.

Socket - continuação


LADO SERVIDORSocket• Cria um ponto final e aloca espaço de tabela para ele na entidade de

transporteBind• Associa um endereço ao soquete recém criado (primitiva socket não faz

isso)Listen• Aloca espaço para a fila de chamadas recebidas, caso vários cliente

desejem se conectar ao mesmo tempo.Accept• Bloqueia a espera por uma conexão de entrada.LADO CLIENTESocketBind: não é necessárioConnect: bloqueia o responsável pela chamada e inicia o processo de

conexão.Send e Receive: envio e recepção de dados full-duplexClose: encerramento da conexão


#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h>

#define SERVER_PORT 12345 /* arbitrary, but client & server must agree */ #define BUF_SIZE 4096 /* block transfer size */

int main(int argc, char **argv) { int c, s, bytes; char buf[BUF_SIZE]; /* buffer for incoming file */ struct hostent *h; /* info about server */ struct sockaddr_in channel; /* holds IP address */

if (argc != 3) fatal("Usage: client server-name file-name"); h = gethostbyname(argv[1]); /* look up host's IP address */ if (!h) fatal("gethostbyname failed");

s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); i f (s <0) fatal("socket"); memset(&channel, 0, sizeof(channel)); channel.sin_family= AF_INET; memcpy(&channel.sin_addr.s_addr, h->h_addr, h->h_length); channel.sin_port= htons(SERVER_PORT);

c = connect(s, (struct sockaddr *) &channel, sizeof(channel)); if (c < 0) fatal("connect failed");

/* Connection is now established. Send file name including 0 byte at end. */ write(s, argv[2], strlen(argv[2])+1);

/ * Go get the file and write it to standard output. */ while (1) { bytes = read(s, buf, BUF_SIZE); /* read from socket */ if (bytes <= 0) exit(0); /* check for end of file */ write(1, buf, bytes); /* write to standard output */ } }

fatal(char *string) { printf("%s\n", string); exit(1); }

#include <sys/types.h> /* This is the server code */ #include <sys/fcntl.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h>

#define SERVER_PORT 12345 /* arbitrary, but client & server must agree */ #define BUF_SIZE 4096 /* block transfer size */ #define QUEUE_SIZE 10

int main(int argc, char *argv[]) { int s, b, l, fd, sa, bytes, on = 1; char buf[BUF_SIZE]; /* buffer for outgoing file */ struct sockaddr_in channel; /* holds IP address */

/* Build address structure to bind to socket. */ memset(&channel, 0, sizeof(channel)); /* zerochannel */ channel.sin_family = AF_INET; channel.sin_addr.s_addr = htonl(INADDR_ANY); channel.sin_port = htons(SERVER_PORT);

/* Passive open. Wait for connection. */ s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); /* createsocket */ if (s < 0) fatal("socket failed"); setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *) &on, sizeof(on));

b = bind(s, (struct sockaddr *) &channel, sizeof(channel)); if (b < 0) fatal("bind failed");

l = listen(s, QUEUE_SIZE); /* specify queue size */ if (l < 0) fatal("listen failed");

/* Socket is now set up and bound. Wait for connection and process it. */ while (1) { sa = accept(s, 0, 0); /* block for connection request */ if (sa < 0) fatal("accept failed");

read(sa, buf, BUF_SIZE); /* read file name from socket */

/* Get and return the file. */ fd = open(buf, O_RDONLY); /* open the file to be sent back */ if (fd < 0) fatal("open failed"); while (1) { bytes = read(fd, buf, BUF_SIZE); /* read from file */ if (bytes <= 0) break; /* check for end of file */ write(sa, buf, bytes); /* write bytes to socket */ } close(fd); /* closefile */ close(sa); /* close connection */ } }

Trabalho: Desenvolvimento de aplicação Java

usando Sockets Utilização de interface gráfica para

comunicação ponto a ponto. Valor: 2 pontos Quanto maior o número de recursos,

melhor.


Elementos de protocolos de transporte


Semelhanças com a camada de enlace.• Como na outra camada, também deve lidar com controle de erros, fluxo e

definição de sequência.

• Diferença na forma de aborgadem:

• Outro possível problema: a capacidade de armazenamento da rede. Dependendo do tipo de roteamento usado (adaptativo), o roteador poderá reter o pacote por alguns segundos para enviá-lo mais tarde.

• Cuidado especial com a utilização de buffers na camada de transporte. O motivo tem a ver com o grande número de conexões que podem ser estabelecidas nessa camada, e dedicar vários buffers para cada uma cada uma pode não ser um boa idéia.

Endereçamento


Cenário: Usuário deseja se conectar a um processo remoto de rede:

• Deve-se especificar com qual aplicação o mesmo deseja se conectar• Como estabelecer os endereços de transporte associados à camada de

transporte ?• Lembrete: dados na camada de transporte são transferidos entre

processos !!!• Solução: uso de portas, ou TSAP (Transport Service Access Point).• Obs: na camada de rede, os endereços IP´s são conhecidos por NSAP.

Vantagem dessa abordagem:• Em diversos sistemas, cada computador pode

ter apena 1 NSAP, porém pode compartilhá-lo a diversos TSAP.

• Na figura ao lado, um servidor de hora do dia se associa à porta 1522, e fica aguardando conexões com a primitiva LISTEN

• O cliente então estabelece uma conexão (CONNECT) com porta de origem 1208 e com porta de destino 1522.

• É enviada a solicitação da hora do dia• Servidor envia a resposta• Conexão de transporte é então liberada.

Endereçamento Dúvida: como saber a qual endereço está associado o serviço de hora do dia ? Os serviços mais conhecidos, de um modo geral, estão associados à portas

bem definidas. O HTTP, por exemplo, usa porta 80. E os serviços dos usuários ??? Ai a coisa complica ... Abordagem UNIX – Protocolo de conexão inicial.


Idéia:• Servidor de processos intermediará (PROXY) o

acesso do usuário à aplicação desejada.• Atende a diversas portas, aguardando

solicitação de conexão• Ao receberem o pedido de conexão ao

serviço, encaminham o mesmo ao servidor de destino final, e desta forma a conexão é herdada.

• Conceito pode ser ampliado usando os “servidores de diretórios” ou “servidor de nomes”

• Após um serviço ser criado, o mesmo deve também constar do servidor de nomes


UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte da Internet mínimo, “sem frescura”,

Serviço “melhor esforço”, segmentos UDP podem ser: perdidos entregues à aplicação

fora de ordem do remesso

Não orientado à conexão: não há “setup” UDP entre

remetente, receptor tratamento independente

de cada segmento UDP

Por quê existe um UDP?

elimina estabelecimento de conexão (o que pode causar retardo)

simples: não se mantém “estado” da conexão no remetente/receptor

pequeno cabeçalho de segmento

sem controle de congestionamento: UDP pode transmitir o mais rápido possível

Sem controle de fluxo e erros.

Sem retransmissão.


Mais sobre UDP muito utilizado para apls. de

meios contínuos (voz, vídeo) tolerantes de perdas sensíveis à taxa de

transmissão outros usos de UDP (por

quê?): DNS (nomes) SNMP (gerenciamento)

transferência confiável com UDP: incluir confiabilidade na camada de aplicação recuperação de erro

específica à apl.!

Source port dest. port32 bits

Dados de aplicação

(mensagem)

UDP segment format

UDP length UDP checksum

Comprimento embytes do

segmento UDP,incluindo cabeçalho


Checksum UDP

Remetente: trata conteúdo do segmento

como seqüência de inteiros de 16-bits

campo checksum zerado checksum: soma (adição

usando complemento de 1) do conteúdo do segmento

remetente coloca complemento do valor da soma no campo checksum de UDP

Receptor: calcula checksum do

segmento recebido verifica se checksum

computado é zero: NÃO - erro detectado SIM - nenhum erro

detectado.

Meta: detecta “erro” (e.g., bits invertidos) no segmento transmitido

RPC – Remote procedure call Base para diversas aplicações em rede. Procura estruturar a chamada

remota parecida com uma chamada local. Basicamente trata do envio de uma solicitação parametrizada à um

host remoto e obter uma resposta de volta. Ex: get_IP_address(host_name) Vinculação de procedimento de biblioteca chamada Stub. Server

Stub / Client Stub. Reunião dos parâmetros no stub é chamado de marshaling

Problema: uso de ponteiros, variáveis globais


RTP – Real time tranport protocol Aplicações multimídia em tempo real: videoconferência, rádio e

música por demanda... Estruturação do RTP é um pouco diferente da tradicional.


Aplicações deste tipo normalmente geram diversos fluxos: vídeo, audio, texto, etc ..., que são armazenados na biblioteca RTP, que se encontra no espaço do usuário com a aplicação.

A biblioteca então multiplexa os fluxos e os transforma em pacotes RTP, que serão decodificados na outra ponto nos fluxos originais.

Utilizado por MP3, GSM, PCM de 8 bits ..

RTP – cabeçalho

Vale notar: Payload Type: indica qual algoritmo de codificação foi usado: audio não

compactado, MP3 Sequence number: contador incrementado em cada pacote enviado. Usado

para detectar pacotes perdidos.



TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

transmissão full duplex: fluxo de dados bi-

direcional na mesma conexão

MSS: tamanho máximo de segmento

orientado a conexão: handshaking (troca de

msgs de controle) inicia estado de remetente, receptor antes de trocar dados

fluxo controlado: receptor não será

afogado

ponto a ponto (fim a fim): 1 remetente, 1 receptor

fluxo de bytes, ordenados, confiável: não estruturado em msgs

dutado: tam. da janela ajustado por

controle de fluxo e congestionamento do TCP

buffers de envio e recepção

socketdoor

T CPsend buffer

T C Preceive buffer

socketdoor

segm ent

applicationwrites da ta

applicationreads da ta

TCP - continuação Estabelece conexões através de sockets. Cada socket possui seu respectivo número associado de um endereço IP

do host e uma porta (TSAP). Um soquete pode ser usado por mais de uma conexão ao mesmo tempo. Portas bem conhecidas, ou reservadas, são aquelas abaixo de 1024.

Acima deste número, o uso é livre. Lista de portas conhecidas: www.iana.org


No UNIX, um único serviço (daemon) gerencia todos os serviços de rede: inetd (originalmente) e agora o xinetd.

Todas as conexões TCP são full-duplex, não aceita difusão e multidifusão.

É um fluxo de bytes, não de mensagens. Não há limites entre os dados enviados.


TCP: estrutura do segmento

no. porta origemno. porta dest 32 bits

dados daaplicação

(tam. variável)

número de seqüêncianúmero de

reconhecimentojanela receptorptr dados urg.checksum

FSRPAUtam.cab.

semuso

Opções (tam. variável)

URG: dados urgentes (pouco usados)

ACK: no. ACKválido

PSH: envia dados já(pouco usado)

RST, SYN, FIN:gestão de conexão

(comandos deestabelecimento,

liberação)

no. bytes rcpt queraceitar

contagem de dadospor bytes (não segmentos!)

checksum Internet

(como UDP)

TCP e UDP sem fio Em tese, a estruturação dos protocolos em camadas não deveria se preocupar se o

IP está sendo enviado por fibra ou rádio. Em redes sem fio, a abordagem deve ser mais cuidadosa. Em redes cabeadas, a maior parte dos timeouts se deve a redes congestionadas, e

não a perda de pacotes. O tratamento, nesse caso, é diminuir o envio de pacotes, até que a rede possa

voltar ao estado de normalidade. Não é o caso das redes sem fio. Diminuir o envio nesse caso, seria catastrófico. Para complicar, as redes podem ser mistas: uma parte cabeada e outra sem fio .... Solução: TCP indireto – divisão da conexão TCP em duas separadas.] São geradas duas conexões homogêneas. Políticas diferentes de reenvio de pacotes podem ser adotadas, de acordo com o

perfil do enlace utilizado. UDP é menos sensível a perda de dados, portanto possui menor necessidade de

adequação de uso em redes sem fio



Three-Way Handshake - Cenários

Duplicatade CR e de

ACK

OperaçãoNormal

Duplicatade CR

Encerramento de conexões


Encerrando uma conexão:2 tipos: simétrico e assimétrico. Assimétrico: Um dos interlocutores desliga e a conexão é

desfeita. Pode ocorrer perda de dados. Ex: ligação telefônica.Simétrico: Trata a conexão como duas conexões unidirecionais

isoladas e exige que as mesmas sejam encerradas separadamente. Neste caso, um receptor pode ainda receber dados mesmo tendo enviado um TPDU Disconnect

Desconexão abrupta com perda de dados

Encerramentos das conexões


Exemplo clássico ilustrativo: Problema dos dois exércitos.

Idéia: O exército azul junto é maior que o branco, mas individualmente é menor. Para vencer, os dois devem atacar em conjunto, simultaneamente

Porém, ataque não ocorrerá devido à hesitação da última mensagem de confirmação

Encerramento das conexões




rede

M P2aplicaçãotransporte

rede

Multiplexação/demultiplexação

Lembrança: segmento - unidade de dados trocada entre entidades da camada de transporte = TPDU: transport

protocol data unit

receptor

HtHn

Demultiplexação: entrega de segmentos recebidos para os processos da camada de apl corretos

segmentosegmento M


rede

P1M

M MP3 P4

cabeçalhode segmento

dados da camada de aplicação


Multiplexação/demultiplexação

multiplexação/demultiplexação: baseadas em números de porta e

endereços IP de remetente e receptor números de porta de

remetente/receptor em cada segmento

lembrete: número de porta bem conhecido para aplicações específicas

juntar dados de múltiplosprocessos de apl, envelopandodados com cabeçalho (usado depois para demultiplexação)

porta remetente porta receptor32 bits

dados daaplicação

(mensagem)

outros campos do cabeçalho

formato de segmento TCP/UDP

Multiplexação:


Multiplexação/demultiplexação: exemplosestação

Aservidor

Bporta orig.: xporta dest: 23

porta orig:23porta dest: x

uso de portas: apl. simples de telnet

cliente WWWestação A

servidor WWW B

Web clienthost C

IP orig: CIP dest: B

porta orig: xporta dest: 80

IP orig : CIP dest: B

porta orig: yporta dest: 80

uso de portas : servidor WWW

IP orig: AIP dest: B

porta orig: xporta dest:

80

Recuperação de desastres Como se recuperar de problemas depois de uma pane no

host. Exemplo: host envia um arquivo muito grande a um

servidor, usando protocolo Stop-and-Wait. No meio da transmissão, servidor sai do ar. Ao voltar, tabelas são reinicializadas e portanto não

saberá onde a transmissão parou. A princípio, o servidor poderá enviar uma TPDU de

difusão, comunicando o problema e solicitando aos clientes o status das conexões abertas.

Se houver alguma TPDU pendente, este indicará o status S1. Caso contrário, enviará status S0.

Esta abordagem simples porém esconde alguns detalhes. Pode ocorrer a situação onde o servidor envia a confirmação de recebimento do dado, e imediatamente após sai do ar. Ou seja, em seus registros internos, essa informação ainda não foi gravada.

O host nesse caso recebe a confirmação, e no momento em que o servidor voltar, este estará inconsistente, mas o host terá seu status marcado por S0, como se tudo estivesse certo, o que é incorreto.

Mesmo que a gravação ocorra primeiro que a confirmação, o problema ainda existirá. Por que ?


Recuperação de desastres Sempre existirá um exemplo onde o protocolo não será capaz de

recuperar o funcionamento de forma apropriada. Em qualquer situação (gravar ou confirmar primeiro), levará a novas situações de erro.

Programação possível no cliente: SEMPRE RETRANSMITIR A ÚLTIMA TPDU NUNCA RETRANSMITIR A ÚLTIMA TPDU RETRANSMITIR APENAS EM ESTADO S0 RETRANSMITIR APENAS EM ESTADO S1

Eventos possíveis no servidor: A – ENVIAR UM CONFIRMAÇÃO W- GRAVAR UM PROCESSO DE SAÍDA C- SOFRER UMA PANE Parênteses indicam que nem A nem W podem seguir C


Recuperação de desastres

Trabalho: interpretar a tabela acimaCamada de Transporte 32

Documents

Redes de Computadores Camada de Transporte. 2 Serviços e protocolos de transporte r Provê comunicação lógica entre processos de aplicação executando em