03 Camada de Transporte

Ela desempenha o papel fundamental de fornecer servi�os de comunica��o diretamente

aos
processos de aplica��o que rodam em hospedeiros diferentes.

3.1 Introdu��o e servi�os de camada de transporte

Um protocolo da camada de transporte fornece comunica��o l�gica entre processos de
aplica��o que
rodam em hospedeiros diferentes. Comunica��o l�gica nesse contexto significa que,
do ponto de vista de
uma aplica��o, tudo se passa como se os hospedeiros que rodam os processos
estivessem conectados
diretamente;

Protocolos da camada de transporte s�o implementados nos sistemas finais, mas n�o
em roteadores de rede.

A camada de transporte converte as mensagens que recebe de um processo de aplica��o

remetente em
pacotes de camada de transporte, denominados segmentos de camada de transporte na
terminologia da
Internet.

Isso � feito fragmentando-se as mensagens da aplica��o em peda�os menores e

adicionando-se um
cabe�alho de camada de transporte a cada peda�o.

Essa camada, ent�o, passa o segmento para a de rede no sistema final remetente,
onde ele � encapsulado
em um pacote de camada de rede (um datagrama) e enviado ao destinat�rio.

No lado destinat�rio, a camada de rede extrai do datagrama o segmento de camada de

transporte e passa-o para a
camada de transporte que, em seguida, processa o segmento recebido,
disponibilizando os dados para a aplica��o
destinat�ria.

3.1.1 Rela��o entre as camadas de transporte e de rede

Enquanto um protocolo de camada de transporte fornece comunica��o l�gica entre
processos que rodam em hospedeiros
diferentes, um protocolo de camada de rede fornece comunica��o l�gica entre
hospedeiros.

0Protocolos de camada de transporte moram nos sistemas finais, onde movimentam

mensagens de processos de aplica��o para
a borda da rede (isto �, para a camada de rede) e vice-versa, mas n�o interferem no
modo como as mensagens s�o movimentadas
dentro do n�cleo.

Os servi�os que um protocolo de transporte pode fornecer s�o muitas vezes limitados
pelo modelo de servi�o do protocolo subjacente da
camada de rede

No entanto, certos servi�os podem ser oferecidos por um protocolo de transporte

mesmo quando o protocolo de rede subjacente n�o oferece o
servi�o correspondente na camada de rede. Por exemplo, um protocolo de transporte
pode oferecer servi�o confi�vel de transfer�ncia de dados a uma
aplica��o mesmo quando o protocolo subjacente da rede n�o � confi�vel, isto �,
mesmo quando o protocolo de rede perde, embaralha
ou duplica pacotes. Como outro exemplo, um protocolo de transporte pode usar
criptografia para garantir que as mensagens da aplica��o n�o sejam lidas por
intrusos mesmo quando a camada de rede n�o puder garantir o sigilo de segmentos de
camada de transporte.

3.1.2 Vis�o geral da camada de transporte na Internet

A rede TCP/IP disponibiliza dois protocolos de transporte distintos para a camada
de aplica��o. Um deles � o UDP (User Datagram Protocol � Protocolo de
Datagrama de Usu�rio), que oferece � aplica��o solicitante um servi�o n�o
confi�vel, n�o orientado para conex�o. O segundo � o TCP (Transmission Control
Protocol � Protocolo de Controle de Transmiss�o), que oferece � aplica��o
solicitante um servi�o confi�vel, orientado para conex�o.

O protocolo de camada de rede da Internet tem um nome � IP, que quer dizer Internet
Protocol. O IP oferece comunica��o l�gica entre hospedeiros. O modelo
de servi�o do IP � um servi�o de entrega de melhor esfor�o, o que significa que o
IP faz o �melhor esfor�o� para levar segmentos entre hospedeiros
comunicantes, mas n�o d� nenhuma garantia. Ele � denominado um servi�o n�o
confi�vel. Cada hospedeiro tem, no m�nimo, um endere�o de camada de rede,
denominado endere�o IP.

A responsabilidade fundamental do UDP e do TCP � ampliar o servi�o de entrega IP

entre dois sistemas finais para um servi�o de entrega entre dois
processos que rodam nos sistemas finais(multiplexa��o/demultiplexa��o de camada de
transporte).

Os dois servi�os m�nimos de camada de transporte � entrega de dados processo a

processo e verifica��o de erros � s�o os �nicos que o UDP fornece.
Em especial, como o IP, o UDP � um servi�o n�o confi�vel � ele n�o garante que os
dados enviados por um processo cheguem (quando chegam!) intactos
ao processo destinat�rio.

O TCP oferece transfer�ncia confi�vel de dados. Usando controle de fluxo, n�meros

de sequ�ncia, reconhecimentos e temporizadores. Ele converte o servi�o n�o
confi�vel do IP entre sistemas finais em um servi�o confi�vel de transporte de
dados entre processos. Ele tamb�m oferece controle de congestionamento.

3.2 Multiplexa��o e demultiplexa��o

No hospedeiro de destino, a camada de transporte recebe segmentos da camada de rede
logo abaixo dela e tem a responsabilidade de entregar os dados desses
segmentos ao processo de aplica��o apropriado que roda no hospedeiro.

Um processo (como parte de uma aplica��o de rede) pode ter um ou mais sockets,
portas pelas quais dados passam da rede para o processo e do processo
para a rede.
A camada de transporte do hospedeiro destinat�rio na verdade n�o entrega dados
diretamente a um processo, mas a um socket intermedi�rio.
Como, a qualquer dado instante, pode haver mais de um socket no hospedeiro
destinat�rio, cada um tem um identificador exclusivo.

Cada segmento de camada de transporte tem um conjunto de campos para direcionar, ao

socket apropriado, um segmento que chega.
A camada de transporte examina esses campos para identificar a porta receptora e
direcionar o segmento a esse socket.

-Multiplexa��o e demultiplexa��o n�o orientadas para conex�o

Quando um socket UDP � criado dessa maneira, a camada de transporte automaticamente
designa um n�mero de porta ao socket (1024
a 65535 ).
Se o desenvolvedor respons�vel por escrever o c�digo da aplica��o estivesse
executando o lado servidor de um �protocolo bem conhecido�,
ele teria de designar o n�mero de porta bem conhecido correspondente.

.A camada de transporte no hospedeiro A cria um segmento de camada de transporte

que inclui os dados de aplica��o, o n�mero da porta de
origem, o n�mero da porta de destino e mais outros dois valores.
.A camada de transporte passa o segmento resultante para a camada de rede, que
encapsula o segmento em um datagrama IP e faz uma
tentativa de melhor esfor�o para entregar o segmento ao hospedeiro destinat�rio.
.A camada de destino no hospedeiro destinat�rio examinar� o n�mero da porta de
destino no segmento e o entregar� a seu socket identificado
' pelo n�mero
.� importante notar que um socket UDP � totalmente identificado por uma tupla com
dois elementos, consistindo em um endere�o IP de destino e
um n�mero de porta de destino.
.O n�mero da porta de origem serve como parte de um �endere�o de retorno�

-Multiplexa��o e demultiplexa��o orientadas para conex�o

O socket TCP � identificado por uma tupla de quatro elementos: (endere�o IP de
origem, n�mero da porta de origem, endere�o IP de destino, n�mero
da porta de destino).

Ao contr�rio do UDP,dois segmentos TCP chegando com endere�os IP de origem ou

n�meros de porta de origem diferentes ser�o direcionados para
dois sockets diferentes.

� A aplica��o servidor TCP tem um �socket de entrada� que espera requisi��es de

estabelecimento de conex�o vindas de clientes TCP
na porta n�mero 12000.
� O cliente TCP cria um socket e envia um segmento de requisi��o de estabelecimento
de conex�o com as linhas:
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,12000))
� Uma requisi��o de estabelecimento de conex�o nada mais � do que um segmento TCP
com n�mero de porta de destino 12000 e um bit especial de
estabelecimento de conex�o marcado no cabe�alho TCP. O segmento inclui tamb�m um
n�mero de porta de origem que foi escolhido pelo cliente.
� Quando o sistema operacional do computador que est� rodando o processo servidor
recebe o segmento de requisi��o de conex�o que est� chegando e
cuja porta de destino � 12000, ele localiza o processo servidor que est� � espera
para aceitar uma conex�o na porta n�mero 12000. Ent�o, o processo
servidor cria um novo socket:
connectionSocket, addr = serverSocket.accept()
� A camada de transporte no servidor tamb�m nota os quatro valores seguintes no
segmento de requisi��o de conex�o: (1) o n�mero da porta de origem no
segmento, (2) o endere�o IP do hospedeiro de origem, (3) o n�mero da porta de
destino no segmento e (4) seu pr�prio endere�o IP. O socket de conex�o rec�m-
-criado � identificado por esses quatro valores; todos os segmentos subsequentes
que chegarem, cuja porta de origem, endere�o IP de origem, porta de
destino e endere�o IP de destino combinar com esses quatro valores, ser�o
demultiplexados para esse socket. Com a conex�o TCP agora ativa, o cliente e o
servidor podem enviar dados um para o outro.

3.3 Transporte n�o orientado para conex�o: UDP

O UDP faz apenas quase t�o pouco quanto um protocolo de transporte pode fazer. �
parte sua fun��o de multiplexa��o/demultiplexa��o e de alguma verifica��o
de erros simples, ele nada adiciona ao IP.
Porque algumas aplica��es usam UDP?
� Melhor controle no n�vel da aplica��o sobre quais dados s�o enviados e quando.
� N�o h� estabelecimento de conex�o.
� N�o h� estados de conex�o.
� Pequeno excesso de cabe�alho de pacote.

O UDP � usado para atualiza��o das tabelas de roteamento com o protocolo RIP
(Routing Information Protocol � protocolo de informa��es de roteamento).
Como as atualiza��es RIP s�o enviadas periodicamente (em geral, a cada cinco
minutos), atualiza��es perdidas ser�o substitu�das por mais recentes, tornando
in�til a recupera��o das perdidas.

O UDP tamb�m � usado para levar dados de gerenciamento de rede (SNMP). Nesse caso,
o UDP � prefer�vel, j� que aplica��es de gerenciamento de rede com
frequ�ncia devem funcionar quando a rede est� em estado sobrecarregado.

� poss�vel uma aplica��o ter transfer�ncia confi�vel de dados usando UDP. Isso pode
ser feito se a confiabilidade for embutida na pr�pria aplica��o.

3.3.1 Estrutura do segmento UDP

O cabe�alho UDP tem apenas quatro campos, cada um consistindo em 2 bytes.
Os n�meros de porta permitem que o hospedeiro destinat�rio passe os dados da
aplica��o ao processo correto que est� funcionando no sistema final destinat�rio
(demultiplexa��o).
O campo de comprimento especifica o n�mero de bytes no segmento UDP (cabe�alho mais
dados).
A soma de verifica��o � usada pelo hospedeiro receptor para verificar se foram
introduzidos erros no segmento.

3.3.2 Soma de verifica��o UDP

� usada para determinar se bits dentro do segmento UDP foram alterados.
O UDP no lado remetente realiza o complemento de 1 da soma de todas as palavras de
16 bits do segmento levando em conta o �vai um� em toda a soma.
Se houver um �vai um� no bit mais significativo ele deve ser somado ao bit menos
significativo.
No destinat�rio, todas as palavras de 16 bits s�o somadas, inclusive a soma de
verifica��o. Se nenhum erro for introduzido no pacote, a soma no destinat�rio
ser�, claro, 1111111111111111.

3.4 Princ�pios da transfer�ncia confi�vel de dados

A abstra��o do servi�o fornecido �s entidades das camadas superiores � a de um

canal confi�vel atrav�s do qual dados podem ser transferidos. Este � exatamente
o modelo de servi�o oferecido pelo TCP.
� responsabilidade de um protocolo de transfer�ncia confi�vel de dados implementar
essa abstra��o de servi�o. A tarefa � dificultada pelo fato de que a camada
abaixo do protocolo de transfer�ncia confi�vel de dados talvez seja n�o confi�vel.

rdt_send(): chamado de cima, (p. e.,pela apl.). Dados passados para remeter �
camada superior do destinat�rio

rdt_rcv(): chamado quando pacote chega no lado destinat�rio do canal

udt_send(): chamado pela rdt, para transferir pacote por canal n�o confi�vel ao
destinat�rio

deliver_data(): chamado pela rdt para remeter dados para cima

3.4.1 Construindo um protocolo de transfer�ncia confi�vel de dados

-Transfer�ncia confi�vel de dados sobre um canal perfeitamente confi�vel: rdt1.0

Existem m�quina de estado finito separadas para o remetente e o destinat�rio.
O evento que causou a transi��o � mostrado acima da linha horizontal que a rotula,
e as a��es realizadas quando ocorre o evento s�o mostradas abaixo dessa linha.
Nesse protocolo simples, n�o h� diferen�a entre a unidade de dados e um pacote. E,
tamb�m, todo o fluxo de pacotes corre do remetente para o destinat�rio; com um
canal perfeitamente confi�vel, n�o h� necessidade de o lado destinat�rio fornecer
qualquer informa��o ao remetente, j� que nada pode dar errado!

SLide: 24

-Transfer�ncia confi�vel de dados por um canal com erros de bits: rdt2.0

Basicamente, s�o exigidas tr�s capacita��es adicionais dos protocolos ARQ para
manipular a presen�a de erros de bits: Detec��o de erros, Realimenta��o do
destinat�rio
e Retransmiss�o

-Transfer�ncia confi�vel de dados por um canal com perda e com erros de bits:
rdt3.0
Suponha agora que, al�m de corromper bits, o canal subjacente possa perder pacotes,
um acontecimento que n�o � incomum nas redes de computadores de hoje.
Duas preocupa��es adicionais devem agora ser tratadas pelo protocolo: como detectar
perda de pacote e o que fazer quando isso ocorre.

A t�cnica adotada na pr�tica � a seguinte: o remetente faz uma escolha ponderada de

um valor de tempo dentro do qual seria prov�vel, mas n�o garantido, que a perda
tivesse acontecido. Se n�o for recebido um ACK nesse per�odo, o pacote �
retransmitido. Note que, se um pacote sofrer um atraso particularmente longo, o
remetente
poder� retransmiti-lo mesmo que nem o pacote de dados, nem o seu ACK tenham sido
perdidos. Isso introduz a possibilidade de pacotes de dados duplicados no canal
remetente-destinat�rio. Felizmente, o protocolo rdt2.2 j� disp�e de funcionalidade
suficiente (isto �, n�meros de sequ�ncia) para tratar dos casos de pacotes
duplicados.

O instante de recebimento de um pacote tem de ser posterior ao instante de envio de

um pacote, como resultado de atrasos de transmiss�o e de propaga��o.

Como os n�meros de sequ�ncia se alternam entre 0 e 1, o protocolo rdt3.0 �s vezes �

conhecido como protocolo bit alternante.