Redes de Computadores - Redes TCP/IP - Protocolos de Transporte e Aplicação

Prévia do material em texto

1
Edgard Jamhour
Redes TCP/IPRedes TCP/IP
Protocolos de Transporte e Aplicação
O objetivo desta unidade é apresentar uma revisão dos principais conceitos relacionados 
aos protocolos de transporte TCP e UDP, bem com os protocolos de aplicação.
Os conceitos dessa unidade são requisitos importantes para compreender o funcionamento 
dos mecanismos de Proxy e NAT que serão abordados na seqüência deste módulo. Eles 
serão igualmente importantes nas disciplinas que abordarão aspectos de segurança da 
arquitetura TCP/IP.
A leitura desse capítulo não é obrigatória para os alunos que se sentem familiarizados com 
esses conceitos.
2
Edgard Jamhour
Protocolo do nProtocolo do níível de transportevel de transporte
Camada de Aplicação
HTTP, FTP, SMTP, etc
Camada de Transporte
TCP, UDP
Camada de Enlace e 
Fisica
Camada de Rede
IP
Seqüência de 
empacotamento
DADOSDADOS
aplicaaplicaççãoão
transportetransporte
pacotepacote
quadroquadro
Placa de 
rede
S.O.
Aplicação
Interface Sockets
Conforme vimos, a arquitetura TCP/IP é composta por três camadas: Aplicação, 
Transporte e Rede. Os protocolos que compõe a arquitetura TCP/IP são padronizados e 
publicados por uma entidade denominada IETF (Internet Engineering Task Force). Os 
documentos gerados pelo IETF são denominados RFC (Request for Comments) e 
descrevem em detalhes o funcionamento dos protocolos. Todas as RFCs são acessíveis 
gratuitamente pelo site www.ietf.org.
As camadas inferiores (Enlace e Física) não são consideradas parte da arquitetura TCP/IP 
pois são definidas por outra entidade (geralmente, o IEEE - Institute of Electrical and 
Electronics Engineers).
A arquitetura TCP/IP define dois protocolos de transporte: TCP (Transmission Control
Protocol) e UDP (User Datagram Protocol).
Como pertencem a mesma camada, os protocolos TCP e UDP são concorrentes, isto é, eles 
nunca podem ser usados ao mesmo tempo.
Observe que os protocolos TCP e UDP são implementados pelo sistema operacional. Isso 
simplifica consideravelmente o desenvolvimento de aplicações que funcionam em rede, 
pois as especificidades de cada protocolo podem ficar escondidas da aplicação. 
Cabe a aplicação decidir qual dos dois protocolos será utilizado. Isto é feito através da 
interface padronizada com o sistema operacional denominada “sockets”. Essa interface 
define um conjunto de APIs (funções padronizadas) para mapear aplicações em portas e 
enviar e receber pacotes. A escolha do protocolo de transporte depende muito dos objetivos 
da aplicação, como será discutido na seqüência dessa unidade.
3
Edgard Jamhour
EndereEndereççamento por Portasamento por Portas
Computador 2Computador 1
TCP
IP
Ethernet
End. Físico
Endereço IP
Porta
1024
Processo
A
Processo
barramentobarramento
UDP
Porta Porta
Processo
TCP
IP
Ethernet
End. Físico
Endereço IP
Porta
Processo
Processo
B
UDP
Porta
80 Porta
Processo
1024 80 Mensagem
Antes de iniciar a discussão referente as diferenças entre os protocolos TCP e UDP, 
convém discutirmos suas semelhanças.
O objetivo de ambos os protocolos é oferecer um nível de endereçamento para processos 
no computador. Como vimos anteriormente, esse endereçamento é feitos por números de 
16 bits, denominados portas.
A maneira como as portas são mapeadas aos processos é definido pela interface sockets. 
Uma processo (aplicação) pode ou não escolher uma porta quando é iniciado utilizando 
uma operação denominada BIND. Se o processo for iniciado sem chamar o BIND, uma 
porta aleatória (geralmente entre 1024 e 65535) será atribuída pelo sistema operacional. O 
sistema operacional garante que nunca duas portas sejam atribuídas para dois processos ao 
mesmo tempo. Geralmente, os processos clientes não executam a operação de BIND.
Os processos servidores sempre precisam fazer um BIND, pois sua porta não pode ser 
aleatória (já que os clientes não teriam como endereçá-los). Como discutido na unidade de 
introdução, a porta usada pelos processos servidores depende de sua natureza. Ela pertence 
a faixa de portas bem conhecidas (0 a 1023) para aplicações padronizadas para Internet 
(como web, email, e outros) e a faixa de portas registradas (1024 a 49151) para as 
aplicações servidoras de fabricantes específicos (como Bancos de Dados).
4
Edgard Jamhour
TCP X UDPTCP X UDP
Não confiável
Cabe a aplicação implementar os 
mecanismos de retransmissão
Transmissão Confiável 
Confirma recebimento e 
retransmite pacotes perdidos
Transmissão por Datagramas:
Segmentação e Remontagem feita 
pela aplicação.
Transmissão por Fluxo
Segmentação e Remontagem feita 
pelo S.O.
Não Orientado a Conexão
Cada pacote é uma transmissão 
independente
Orientado a Conexão
Identifica uma seqüência de 
pacotes com pertencentes a uma 
mesma transmissão
UDPTCP
Os protocolos TCP e UDP são muito diferentes. O protocolo UDP é muito simples, e 
praticamente só oferece um serviço de endereçamento por portas para a aplicação. Já o 
TCP é um protocolo muito sofisticado, que realiza diversas operações para a aplicação, 
como a verificação de recebimento e a retransmissão automática de pacotes perdidos. 
A primeira diferença entre o TCP e o UDP refere-se a existência ou não de conexão. Uma 
conexão é criada através de uma troca de pacotes de controle entre um cliente e o servidor 
que ocorre antes do início do primeiro pacote de dados ser transmitido. O TCP utiliza os 
pacotes de controle para criar, monitorar e encerrar as conexões. A conexão é um requisito 
para realizar muitos dos serviços adicionais oferecidos pelo TCP. O UDP, transmite apenas 
pacotes de dados.
A segunda diferença refere-se ao modo de transmissão dos dados. No TCP, uma aplicação 
não precisa controlar quantos dados cabem em um pacote. Ela pode simplesmente 
transmitir os dados em um fluxo contínuo, que o S.O. decide como segmentar os dados em 
pacotes. O S.O. no receptor também remonta os pacotes de forma transparente para a 
aplicação, que recebe os dados também como um fluxo contínuo. No caso do UDP, cabe a 
aplicação fornecer para o S.O. uma quantidade de dados que caiba em um pacote. 
A terceira diferença refere-se ao controle de recebimento e a retransmissão de pacotes 
perdidos. No caso do TCP os pacotes enviados são confirmados pelo receptor. Caso eles 
não sejam confirmados, eles são re-enviados automaticamente pelo sistema operacional, 
sem necessidade de intervenção da aplicação. No caso do UDP, a detecção de pacotes 
perdidos e a retransmissão precisa ser feita pela aplicação.
5
Edgard Jamhour
TCP X UDPTCP X UDP
Sem controleControle de Fluxo
Controle de Congestionamento
Indicado para transmissões 
rápidas (poucos dados) 
ou que não admitam grande 
atraso (tempo-real)
Indicado para transferir grandes 
quantidades de dados em modo 
confiável
Unicast, Multicast ou BroadCastSomente Unicast
UDPTCP
O TCP implementa ainda dois mecanismos bastante sofisticados que não são 
implementados pelo UDP: o controle de fluxo e o controle de congestionamento. 
O controle de fluxo é um ajuste automático da velocidade do transmissor, que reduz sua 
taxa de envio de pacotes para evitar que o receptor perca pacotes por não ter capacidade de 
recebê-los. Isso é necessário quando dois computadores de capacidade muito distinta se 
comuniquem numa rede de alta-velocidade. Nesse caso, o limitante de velocidade não é a 
rede, mas a capacidade de processamento dos computadores.
O controle de congestionamento é também um ajuste de velocidade, mas provocado pela 
perda de pacotes na rede. Quando o TCP detecta perda de pacotes, ele assume que os 
roteadores da rede tiveram que descartar os pacotes porque a rede está congestionada. Esse 
mecanismo foi implementado nos primórdios da Internet, quando se percebeu que a 
retransmissãoautomática de pacotes sem controle de congestionamento podia levar a rede 
rapidamente a um colapso.
As funcionalidades adicionais oferecidas pelo TCP sobre o UDP vem com um custo: o 
TCP só suporta transmissões em unicast. Isto é, não é possível usar endereços de 
broadcast ou multicast em conexão TCP. Isso acontece, entre outras coisas, porque os 
pacotes TCP precisam ser confirmados pelo receptor. A confirmação não funciona quando 
se usa um endereço genérico de destino, pois o transmissor não sabe de quantos 
destinatários ele deve aguardar a confirmação. Todas as aplicações que precisam transmitir 
broadcast ou multicast precisam usar UDP. O TCP também é um protocolo mais custoso 
em termos de processamento para os sistemas operacionais e também em termos do 
volume de dados transmitido pela rede. Ele não é indicado quando a aplicação precisa 
transmitir apenas mensagens curtas ou mensagens sensíveis ao atraso, que não podem ser 
retransmitidas.
6
Edgard Jamhour
Protocolo TCPProtocolo TCP
HLEN Reservado Flags Janela de Recepção
Checksum Ponteiro de Urgência
Número de Seqüência
Número de Confirmação
Opções
Dados
....
Byte 1 Byte 2 Byte 3 Byte 4
0 4 8 12 16 20 24 28 31
Porta de Origem Porta de Destino
FLAGS: ACK, SYN, FIN, RST, URG, CWR, ECN, PUSH
A unidade de informação do TCP é denominada segmento. A estrutura do cabeçalho TCP é
mostrada na figura.
Além das portas de origem e destino, os demais campos do cabeçalho TCP estão 
relacionadas as funções oferecidas pelo protocolo.
Os campos Número de Seqüência e Número de Confirmação estão relacionados com o 
mecanismo de transmissão confiável.
O campo Janela de Recepção está relacionado com o mecanismo de controle de fluxo.
O campo de Flags contém um conjunto de bits de controle utilizado no controle da 
conexão TCP e também no processo de transmissão confiável.
O campo Ponteiro de Urgência é pouco usado na prática. Ele permite informar ao 
receptor que os dados recebidos devem ser processados de forma mais prioritária, passando 
a frente de outros dados que estão no buffer aguardando processamento. 
O campo de Opções não é obrigatório, sendo frequentemente omitido do cabeçalho TCP. 
Todavia, devido a sua existência, o cabeçalho TCP tem tamanho variável. Por isso, o 
campo HLEN define o tamanho do cabeçalho em palavras de 4 bytes.
7
Edgard Jamhour
TransmissãoTransmissão porpor FluxoFluxo (TCP) (TCP) 
aplicação aplicação
TCP
socket
TCP
socket
IP IP
Fluxo contínuo de 
bytes (stream)
Fluxo contínuo de 
bytes (stream)
segmentos segmentos
Quando se utiliza o TCP, a decisão de quando um segmento é criado e transmitido é feita 
pelo protocolo e não pela aplicação. Essa estratégia é denominada de transmissão por 
fluxo.
Utilizando a API de sockets, a aplicação pode solicitar ao sistema operacional (TCP) que 
transmita bytes em um fluxo contínuo. Cada pedido de transmissão não gera 
necessariamente um pacote, pois o TCP pode aguardar que uma quantidade razoável de 
bytes seja recebida, a fim de não gerar muitos pacotes de tamanho pequeno. 
O tamanho do pacote é uma solução de compromisso entre minimizar o número de pacotes 
transmitidos, e não causar um atraso excessivo na transmissão quando o volume de dados a 
ser transmitido é pequeno.
Teoricamente, um pacote IP pode ter até 64Kbytes. A principio seria aproximadamente 
esse o volume de dados (menos o tamanho do cabeçalho TCP) que o TCP deveria aguardar 
antes de gerar um pacote. 
Nas implementações dos sistemas operacionais modernos, contudo, a quantidade de bytes 
que o TCP acumula é definida de acordo com o MTU da interface de rede (1500 bytes para 
o Etherent). Isso é feito para evitar que o pacote seja fragmentado pela camada IP.
O tamanho máximo de um segmento é denominado MSS (Maximum Segment Size), ele 
corresponde a 1460 bytes (1500 bytes – 20 bytes do cabeçalho IP – 20 bytes do cabeçalho 
TCP). 
8
Edgard Jamhour
SegmentaSegmentaçção e Remontagemão e Remontagem
Fluxo Contínuo de Bytes
Dados
0 200 500 800
DadosDados
bytes
SEGMENTO SEGMENTO SEGMENTO
NIS
+
0
NIS 
+ 
200
NIS 
+ 
800
Início da Conexão Fim da Conexão
A fim de tornar o processo de segmentação e remontagem transparente para as aplicações, 
o TCP inclui em seu cabeçalho informações necessárias para que o sistema operacional do 
receptor efetue a remontagem de forma automática.
É importante ressaltar que uma conexão TCP é identificada por quatro endereços: IP de 
Origem, Porta de Origem, IP de Destino e Porta de Destino.
Conforme ilustrado na figura, após o estabelecimento de uma conexão TCP, todos os 
segmentos transmitidos são numerados em bytes, utilizando o campo “Número de 
Seqüência”. A contagem em bytes, todavia, não começa no número zero, mas sim em um 
número inicial de seqüência (NIS) escolhido de forma aleatória. 
O valor do NIS é escolhido para cada conexão. Se um par de computadores (A e B) 
encerrar uma conexão e iniciar uma outra entre si imediatamente depois, um outro NIS 
será utilizado. 
O valor do NIS é também unidirecional, isto é, um NIS é utilizado para o fluxo de pacotes 
de A para B, e outro de B para A. A justificativa inicial para o NIS ser aleatório é
justamente evitar uma montagem errônea de pacotes quando uma conexão entre os 
mesmos computadores usando o mesmo par de portas é iniciada muito próximo da conexão 
previamente encerrada. Devido a atrasos da rede, os pacotes da conexão encerrada 
anteriormente poderiam ser confundidos com os pacotes da nova conexão.
9
Edgard Jamhour
ComunicaComunicaçção Confião Confiáávelvel
tempo tempo
cliente servidor
seq=1000, conf=2000, dados=500 bytes
seq=2000, conf=1500, dados=100 bytes
seq=1500, conf=2100, dados=300
1000 - 1499 1500 - 1799 2000- 2099 2100 - 2989
seq=2100, conf=1800, dados=890 bytes
segmento 1 segmento 2 segmento A segmento B
O TCP implementa um processo de comunicação confiável denominado “retransmissão 
por ausência de confirmação”. Conforme mostra a figura, os segmentos enviados entre os 
computadores utilizam os campos número de seqüência (seq) e número de confirmação 
(conf) para implementar essa estratégia.
O campo seq indica sempre o primeiro byte do segmento sendo transmitido. O campo conf
indica o próximo byte que o transmissor espera receber do seu parceiro (peer). Observe que 
o campo conf tem o significado implícito de reconhecimento de recebimentos. Isto é, se 
um peer envia um segmento com o número de confirmação 2000, por exemplo, ele está
confirmado que já recebeu os bytes anteriores numerados até 1999.
No TCP não é necessário enviar uma mensagem só para confirmar o recebimento de dados. 
O TCP utiliza uma estratégia em que o mesmo segmento usado para transmitir novos 
dados também confirma o recebimento dos dados já recebidos.
Para ilustrar esse conceito, suponha que o cliente tem dois segmentos para transmitir: 
segmento 1 (bytes 1000 a 1499) e segmento 2 (bytes de 1500 a 1799). O servidor também 
tem dois segmentos para transmitir: segmento A (bytes 2009 a 2099) e segmento B (bytes 
2100 a 2989).
O cliente transmite o segmento 1 (500 bytes) com seq=1000 e conf=2000. Isso significa 
que ele está confirmado para o servidor que ele já recebeu os bytes anteriores a 2000. O 
servidor responde com seq=2000 e conf=1500. Observe o campo seq corresponde 
exatamente ao próximo byte esperado pelo cliente e o campo conf confirma o recebimento 
dos bytes correspondentes ao segmento 1. O processo se repete conforme ilustrado na 
figura.
10
Edgard Jamhour
RecomendaRecomendaççõesões RFC 1122 e 2581RFC 1122 e 2581
EVENTO
• Chegada de um segmento na
ordem.
• Chegada de um segmento fora de 
ordem (número mais alto que o 
esperado).
• Chegada de um segmento que
preenche a lacuna.
AÇÃO TCP DESTINATÁRIO
• Aguarda 500 ms. Seoutro
segmento não chegar, confirma o 
segmento. Se outro segmento vier, 
confirma os dois com um único
ACK.
• Envia imediatamente o ACK 
duplicado com o número do byte 
aguardado (isto é, repete o último
ACK de ordem correta).
• Envia imediatamente o ACK (se o 
preechimento foi na parte contigua
baixa da lacuna).
A técnica de retransmissão do TCP é o reconhecimento positivo com temporizadores. O 
TCP não usa mensagens de erro. Se uma confirmação de recebimento não chegar no 
transmissor num tempo pré-determinado, o segmento é retransmitido. O receptor pode 
enviar pacotes sem dados, apenas com confirmação, quando não tem nada para transmitir.
O tempo máximo para aguardar uma confirmação é estimado em função do tempo médio 
de Round-Trip Time (RTT) para enviar e confirmar um segmento. O transmissor pode 
adotar várias técnicas para estimar este tempo. Uma estratégia comum é a seguinte:
EstimatedRTT = 0.875 EstimatedRTT + 0.125 SampleRTT
Temporizador = EstimatedRTT + 4 . Desvio
Desvio = 0.875 Desvio + 0.125 (SampleRTT – EstimatedRTT)
onde: 
SampleRTT: última medição de RTT
Temporizador: tempo máximo para aguardar uma confirmação
Desvio: medida da flutuação do valor do RTT
O receptor não confirma segmentos recebidos fora da ordem. Ao invés disso, para cada 
segmento recebido fora de ordem, o receptor repete o número de confirmação do último 
segmento recebido na seqüência correta para o transmissor. 
Se o transmissor receber 3 segmentos com o mesmo número de confirmação, ele 
retransmite todos os segmentos ainda não confirmados. Essa técnica é denominada 
retransmissão rápida (retransmissão antes de expirar o temporizador do segmento). 
A figura apresenta um resumo das principais recomendações sobre o funcionamento do 
TCP, descritas nas RFCs 1122 e 2581.
11
Edgard Jamhour
Conexão TCPConexão TCP
tempo tempo
cliente servidor
seq=C_NIS, ACK=0, SYN=1
seq=S_NIS, conf=C_NIS+1, ACK=1, SYN=1
seq=C_NIS+1, conf=S_NIS+1, ACK=1,SYN=0
ACK=1,SYN=0
...
FIN=1
ACK=1
FIN=1
ACK=1
abertura 
de 
conexão
encerramento 
de 
conexão
transmissão 
dos dados
Os bits ACK, SYN e FIN (definidos no campo FLAS do TCP) são utilizados para controlar a abertura e o 
encerramento das conexões TCP. O ACK é o flag de confirmação de recebimento. Ele é 0 no primeiro 
segmento transmitido (pois não há nada a confirmar) e 1 em todos os demais. O SYN é o flag de sincronismo. 
Seu valor é 1 é apenas nos dois primeiros segmentos trocados entre o cliente e o servidor. O flag FIN é flag
de finalização. Quando seu valor é um, ele indica o desejo de encerrar a conexão. 
Uma conexão TCP estabelece os números de seqüência iniciais (NIS) usados pelo cliente e o servidor. Isso 
envolve a troca de três segmentos:
1) O cliente envia para o servidor pedido de abertura de conexão (segmento SYN). Esse segmento define o 
valor inicial do número de seqüência do cliente (C_NIS), e é identificado pelos flags SYN=1, ACK=0. 
2) O servidor envia para o cliente a confirmação da abertura da conexão (segmento SYNACK). Esse 
segmento informa o valor inicial do número de seqüência do servidor (S_NIS), e é identificado pelos flags
SYN=1 e ACK=1. 
3) O cliente envia para o servidor a confirmação do recebimento do segmento SYNACK. 
Após essa fase, os dados podem ser trocados indefinidamente entre o cliente e o servidor. Observe que 
durante a fase de troca de dados que ACK=1 e SYN=0. 
O encerramento da conexão pode ser feito por iniciativa do servidor ou do cliente. A conexão TCP é
bidirecional, então o encerramento completo da conexão precisa que ambos, o cliente e o servidor, enviem 
pedidos de encerramento. O encerramento envolve a troca de 4 segmentos. No exemplo da figura, a iniciativa 
de encerramento da conexão foi feita pelo cliente. Assim, primeiro, o cliente envia para o servidor um 
segmento com o flag FIN=1. O servidor envia um segmento confirmando o recebimento do FIN, e outro 
solicitando encerramento da sua conexão. Finalmente o cliente confirma o recebimento do segmento FIN do 
servidor. 
O TCP permite também um encerramento rápido da conexão utilizando o flag Reset (RST). Quando o cliente 
ou o servido enviam um pacote com RST=1, a conexão é encerrada com um único pacote.
12
Edgard Jamhour
Controle de FluxoControle de Fluxo
A B
1000
0
2000
3000
LastByteRead
LastByteRcvd
Transmissor Receptor
S.O.
aplicação
conf=1000
RcvWindow=1000
RcvBuffer
É importante lembrar que quando um segmento TCP é transmitido, ele primeiramente é
recebido pelo sistema operacional (S.O.) da máquina receptora e armazenado em um 
buffer. Esse processo de recepção ocorre de forma transparente para a aplicação, uma vez 
que o TCP é implementado pelo S.O. Esse buffer contudo, tem capacidade limitada. A 
aplicação do receptor deve ser capaz de remover os dados do buffer numa velocidade 
compatível com a taxa de recebimento. Se o receptor for muito lento (ou a aplicação tiver 
sido mal escrita), pode ser que a aplicação receptora não dê conta de ler os dados do buffer, 
e este se encha por completo. Quando o buffer do S.O. está cheio, os novos segmentos 
recebidos são simplesmente descartados.
O controle de fluxo é um mecanismo do TCP que evita que isso aconteça. Nesse 
mecanismo, o receptor informa junto com a confirmação do recebimento de cada segmento 
a quantidade de buffer que ele ainda tem disponível utilizando o campo Janela de 
Recepção (RcvWindow) do cabeçalho do TCP. 
Para ilustrar como o controle de fluxo funciona, considere o cenário da figura, onde o 
computador A é o transmissor, e o computador B é o receptor. O algoritmo para o cálculo 
da Janela de Recepção utiliza três parâmetros:
RcvBuffer = buffer de recepção de B
LastByteRead = número do último byte lido pela aplicação B
LastByteRcvd = último byte recebido por B
A Janela de Recepção RcvWindow enviada de B para A é definida por:
RcvWindow = RcvBuffer - [LastByteRcvd - LastByteRead]
13
Edgard Jamhour
Controle de CongestionamentoControle de Congestionamento
A B
RTT
envio
confirmação
t
RTT RTT RTT RTT RTT RTT RTT RTT RTT RTT
crescimento
exponencial
prevenção de 
congestionamento
prevenção de 
congestionamento
evento de falha
congwindow
MSS
Threshold
Threshold
Na prática, o TCP impõe uma outra janela que limita o envio de bytes pelo transmissor. Essa janela é
denominada Janela de Congestionamento (CongWindow). 
Ao contrário da Janela de Recepção, a Janela de Congestinamento não possui um campo correspondente no 
cabeçalho do TCP. Ela é calculada internamente pelo sistema operacional do transmissor com base no 
sucesso ou fracasso na transmissão de segmentos. Todas as vezes que um segmento é perdido, o TCP assume 
que a rede está congestionada e tenta reduzir a velocidade do transmissor. Quando os segmentos são 
transmitidos com sucesso, a janela é aumentada.
A janela CongWindow é calculada em múltiplos de MSS (Maximum Segment Size = 1460 bytes). A figura 
ilustra como a CongWindow evolui ao longo do tempo. Inicialmente, a janela é ajustada para 1 MSS e é
dobrada a cada segmento confirmado com sucesso. Esse processo de crescimento exponencial continua até
um certo valor de Threshold. A partir desse ponto, a janela entre numa fase de prevenção de 
congestionamento, onde o crescimento é mais lento (apenas um 1 MSS a cada confirmação bem sucedida). 
Em caso de falha, o tamanho da janela e do Threshold são reduzidos a metade.
O algorimto de cáculo da CongWin pode ser resumido da seguinte forma: 
a) Inicialização: 
CongWin = 1 MSS (Maximum Segment Size = 1460 bytes)
Threshold = 65 kbps
b) Fase de crescimento exponencial (a cada confirmação recebida)
se CongWin < Threshold vai para Partida Lenta: CongWin = CongWin + MSS 
Isto é, CongWin= Congwin*2 por RTT
senão vai para Prevenção deCongestionamento: CongWin = CongWin + (MSS/CongWin)
Isto é, CongWin = CongWin + 1 MSS por RTT 
c) Em caso de detecção de segmentos fora de ordem:
Threshold = CongWin = CongWin/2
Vai para prevenção de congestionamento
d) Em caso de detecção de perda por temporização
Threshold = CongWin/2
CongWin = 1 MSS (volta para partida lenta)
14
Edgard Jamhour
Congestionamento X Controle de FluxoCongestionamento X Controle de Fluxo
1000
0
1500
2000
Dados a Serem Trasmitidos
LastByteAcked
tempo
LastByteSent
A
CongWindow
RcvWindow
B
RTT
envio
confirmação
1800
Em um dado instante, a taxa máxima de envio de segmentos pelo transmissor é dada pela 
menor valor de janela definida pelo controle de fluxo e o controle de congestionamento. 
Esse valor é calculado da seguinte forma:
taxa_máxima = [min(CongWindow,RcvWindow) - (LastByteSent-LastByteAcked)]/RTT bytes/s.
onde:
LastByteSent: último byte enviado pelo transmissor
LastByteAcked: última byte confirmado pelo receptor
O TCP distingue dois eventos de falha: perda de segmento (isto é, o receptor não enviou 
nenhuma confirmação) e chegada de segmentos fora de ordem (isto é, o receptor está
enviou segmentos com o número de confirmação duplicado). O primeiro evento é
considerado mais grave que o segundo, pois no caso dos segmentos fora de ordem, o 
receptor ainda consegue sinalizar segmentos ao transmissor.
Existem algumas variantes na implementação do TCP, de acordo como o mecanismo de 
controle congestionamento reage a esses eventos de falha. 
A versão Tahoe é a mais antiga, e volta para partida lenta (CongWin=1MSS) para 
qualquer evento de falha. 
A versão Reno é mais recente, e adota uma recuperação rápida (CongWin=CongWin/2) no 
caso de segmentos fora de ordem, e partida lenta (CongWin=1MSS) em caso de perda de 
segmentos. 
O TCP Vegas é uma proposta não implementada em muitos SOs. Ela reduz a taxa de 
transmissão de pacotes mesmo antes da ocorrência de perda, monitorando o aumento do 
valor do RTT (tempo de confirmação).
15
Edgard Jamhour
Ponteiro de Urgência Checksum
Dados
....
Byte 1 Byte 2 Byte 3 Byte 4
0 4 8 12 16 20 24 28 31
Porta de Origem Porta de Destino
Protocolo UDPProtocolo UDP
O cabeçalho UDP (User Datagram Protocol) são bem mais simples que o TCP, pois ele não 
oferece nenhuma funcionalidade além da simples multiplexação de portas. O nome da 
unidade de dados do protocolo UDP é geralmente denominada datagrama UDP.
Apesar do UDP possuir um campo para verificação de erros de transmissão (CheckSum), o 
protocolo não oferece nenhum serviço de confirmação para o transmissor, nem a 
retransmissão dos pacotes perdidos. Ele também não tem o conceito de conexão, sendo 
portanto, incapaz de segmentar e remontar de forma transparente para a aplicação os dados 
transmitidos.
Isso não significa que não é possível desenvolver aplicações sobre o protocolo UDP que 
sejam confiáveis ou que possam transmitir grandes volumes de dados. Significa, 
simplesmente, que essas funcionalidades adicionais deverão estar embutidas no código da 
aplicação, pois elas não serão oferecidas pelo sistema operacional. Por exemplo, o NFS 
(Network File System) que permite aos sistemas Unix compartilharem diretórios pela rede 
é construído sobre UDP.
Em muitos casos, os desenvolvedores optam por não usar as funcionalidades do TCP 
devido ao custo de performance associado. Isso é particularmente verdade para as 
aplicações sensíveis atraso e jitter (i.e., aplicações tempo-real). Por exemplo, em uma 
aplicação de VoIP (Voz Sobre IP) não vale a pena retransmitir pacotes perdidos, pois a 
capacidade de re-ordenamento do terminal de VoIP é limitada.
O UDP é ainda essencial nos casos das aplicações que precisam transmitir mensagens em 
multicast ou broadcast, pois TCP suporta apenas o modo unicast.
16
Edgard Jamhour
Protocolos de AplicaProtocolos de Aplicaççãoão
HTTPHTTP
TCPTCP
IPIP
UDPUDP
FTPFTP SMTPSMTP NFSNFS DNSDNS DHCPDHCP
Camada de TransporteCamada de Transporte
Camada de AplicaCamada de Aplicaççãoão
Camada de RedeCamada de Rede
Os protocolos da camada de aplicação seguem uma estratégia bem diferente dos protocolos 
das camadas de transporte e rede. Enquanto os protocolos TCP, UDP e IP oferecem a 
possibilidade de grande quantidade de reuso de código entre aplicações distintas, os 
protocolos de aplicação são particulares a cada aplicação. Dessa forma, não vale a pena 
implementar os protocolos de aplicação ao nível do sistema operacional, ficando mais 
simples implementá-los nas próprias aplicações cliente e servidora.
O objetivo dos protocolos de aplicação é permitir a comunicação entre programas 
desenvolvidos por fabricantes diferentes. Os protocolos de aplicação relacionados aos 
serviços IP são padronizados na forma de RFCs pelo IETF. 
Muitos dos protocolos usados na Internet são formados de mensagem em texto. Nesses 
protocolos, a separação entre campos do protocolo é muitas vezes feitas por um caractere 
de quebra de linha (\n). Por exemplo, o uma mensagem do protocolo HTTP solicitando a 
pagina http://espec.ppgia.pucpr.br/~jamhour/welcome.html pode ter o seguinte 
formato:
GET /~jamhour/welcome.html HTTP/1.1\r\n
Host: espec.ppgia.pucpr.br\r\n
Cache-Control: no-cache\r\n
\r\n
Para os protocolos em formato texto, como o HTTP, a transmissão de informações binárias 
(como figuras ou videos) precisa ser codificada utilizando algoritmos como o base64, que 
codificam qualquer tipo de informação binária em caracteres do tipo texto, a fim de que 
possa ser transmitida.
17
Edgard Jamhour
Portas bem ConhecidasPortas bem Conhecidas
servidor
httpd
ftpd
smptd
nfsd
named
dhcpd
cliente
80
21
25
2049
53
67
>1023
>1023
>1023
>1023
>1023
>1023
wget
ftp
firefox
nfs client
dig
dhclient
dhcp
dns
nfs
smtp
ftp control
>102320
ftp data
http
Conforme discutido anteriormente, a IANA (Internet Assigned Number Authority) define 
um mapeamento padrão entre os principais protocolos de aplicação e as portas TCP ou 
UDP. Essas portas padronizadas são denominadas “Portas Bem Conhecidas” (Well Known
Ports).
A figura ilustra as portas associadas a alguns protocolos bem conhecidos. Observe que a 
porta bem conhecida é usada apenas no lado do servidor. No lado do cliente, a porta é
dinâmica, e é escolhida pelo sistema operacional no momento em que a aplicação cliente 
solicita uma conexão com o servidor.
Por exemplo, o cliente http de comando de linha (modo não gráfico) do Linux é o wget. 
Quando você digita o comando abaixo o cliente wget vai receber uma porta dinâmica que 
ficará associada a ele durante a transferência do arquivo vlan.tar.gz, sendo liberada após o 
término do download do arquivo. :
wget http://espec.ppgia.pucpr.br/~jamhour/vlan.tar.gz
Observe que quando você digita o comando wget não é necessário especificar em que porta 
o servidor http estará escutando. Isso acontece porque o cliente wget assume por default 
que o servidor estará conectado na porta 80. É possível, contudo, instalar as aplicações 
servidoras em portas alternativas. Por exemplo, se o servidor http da espec for instalado na 
porta 8080 (não padrão), o cliente wget precisar informar a porta da seguinte forma.
wget http://espec.ppgia.pucpr.br:8080/~jamhour/vlan.tar.gz
Observe também, que a maioria das aplicações servidoras do Linux tem seu nome 
terminado com “d”. Isso acontecer porque as aplicações servidoras do Linux que rodam 
em segundo plano (sem interface visível com o usuário) são denominadas daemon.
18
Edgard Jamhour
ConclusãoConclusão
Protocolos de Transporte e Aplicação
Nesta unidade, fizemos uma revisão dos principais conceitos relacionados aos protocolos 
de transporte e aplicação da arquitetura TCP/IP.Este documento deve ser revisto pelo aluno sempre que ele tiver dúvidas relativas ao 
funcionamento desses protocolos. Conhecimentos mais aprofundados sobre o 
funcionamento dos protocolos TCP e UDP serão necessários, por exemplo, na disciplinas 
de segurança em redes, que irá discutir a configuração de firewalls. Como veremos a 
configuração dos firewalls levam em conta o conceito de conexão do TCP e, sua ausência, 
no caso do UDP.
O conhecimento sobre o funcionamento desse protocolos também será importante para 
compreender o funcionamento do mecanismo de Proxy e NAT, discutidos na seqüência 
dessa disciplina.
O conceito de protocolo de aplicação também é necessário para compreender o 
funcionamento dos Proxies.