Redes TCP/IP

Protocolos de Transporte e Aplicação

Edgard Jamhour

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.

1
 Protocolo do nível de transporte

DADOS

Camada de Aplicação Seqüência de

Aplicação HTTP, FTP, SMTP, etc empacotamento

Interface Sockets aplicaç

aplicação

Camada de Transporte
TCP, UDP transporte
S.O.
Camada de Rede pacote
IP
Placa de
rede Camada de Enlace e quadro
Fisica

Edgard Jamhour

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.

2
 Endereçamento por Portas
Computador 1 Computador 2
Processo
A Processo Processo Processo
Processo
Processo B

Porta Porta
1024 Porta Porta Porta 80 Porta

TCP UDP TCP UDP

Endereço IP Endereço IP

IP IP

End. Físico End. Físico

Ethernet Ethernet

barramento
1024 80 Mensagem
Edgard Jamhour

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).

3
 TCP X UDP

TCP UDP

Orientado a Conexão Não Orientado a Conexão

Identifica uma seqüência de
pacotes com pertencentes a uma
mesma transmissão
Transmissão por Fluxo
Segmentação e Remontagem feita
pelo S.O.
Cada pacote é uma transmissão
independente
Transmissão por Datagramas:
Segmentação e Remontagem feita
pela aplicação.

Transmissão Confiável Não confiável

Confirma recebimento e Cabe a aplicação implementar os
retransmite pacotes perdidos mecanismos de retransmissão

Edgard Jamhour

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.

4
 TCP X UDP

TCP UDP
Controle de Fluxo Sem controle
Controle de Congestionamento
Somente Unicast Unicast, Multicast ou BroadCast

Indicado para transferir grandes Indicado para transmissões

quantidades de dados em modo rápidas (poucos dados)
confiável ou que não admitam grande
atraso (tempo-real)

Edgard Jamhour

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ão automá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.

5
 Protocolo TCP

0 4 8 12 16 20 24 28 31

Byte 1 Byte 2 Byte 3 Byte 4

Porta de Origem Porta de Destino

Número de Seqüência

Número de Confirmação

HLEN Reservado Flags Janela de Recepção

Checksum Ponteiro de Urgência

Opções

Dados
....

FLAGS: ACK, SYN, FIN, RST, URG, CWR, ECN, PUSH

Edgard Jamhour

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.

6
 Transmissão por Fluxo (TCP)

aplicação aplicação
Fluxo contínuo de Fluxo contínuo de
bytes (stream) bytes (stream)
socket socket

TCP TCP
segmentos segmentos

IP IP

Edgard Jamhour

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).

7
 Segmentação e Remontagem
Início da Conexão Fim da Conexão

Fluxo Contínuo de Bytes

0 200 500 800 bytes

NIS Dados NIS Dados NIS Dados

+ + +
0 200 800

SEGMENTO SEGMENTO SEGMENTO

Edgard Jamhour

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.

8
 Comunicação Confiável
segmento 1 segmento 2 segmento A segmento B

1000 - 1499 1500 - 1799 2000- 2099 2100 - 2989

cliente servidor
seq=1000, conf=2000, dados=500 bytes

seq=2000, conf=1500, dados=100 bytes

seq=1500, conf=2100, dados=300

seq=2100, conf=1800, dados=890 bytes

tempo tempo
Edgard Jamhour

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.

9
 Recomendações RFC 1122 e 2581
EVENTO AÇÃO TCP DESTINATÁRIO

• Chegada de um segmento na • Aguarda 500 ms. Se outro

ordem. segmento não chegar, confirma o
segmento. Se outro segmento vier,
confirma os dois com um único
ACK.

• Envia imediatamente o ACK

• Chegada de um segmento fora de duplicado com o número do byte
ordem (número mais alto que o aguardado (isto é, repete o último
esperado). ACK de ordem correta).

• Envia imediatamente o ACK (se o

• Chegada de um segmento que preechimento foi na parte contigua
preenche a lacuna. baixa da lacuna).

Edgard Jamhour

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.

10
 Conexão TCP
cliente servidor
seq=C_NIS, ACK=0, SYN=1

abertura seq=S_NIS, conf=C_NIS+1, ACK=1, SYN=1

de
conexão
seq=C_NIS+1, conf=S_NIS+1, ACK=1,SYN=0

ACK=1,SYN=0 transmissão
dos dados
...

FIN=1
ACK=1
encerramento
de
conexão
FIN=1

ACK=1

tempo tempo

Edgard Jamhour

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.

11
 Controle de Fluxo

S.O.
3000 RcvBuffer

2000

LastByteRcvd
1000 aplicação
LastByteRead
0

A B
conf=1000
RcvWindow=1000

Transmissor Receptor
Edgard Jamhour

É 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]

12
 Controle de Congestionamento
MSS

congwindow
evento de falha
crescimento prevenção de
exponencial congestionamento

Threshold prevenção de
congestionamento

Threshold

t
RTT RTT RTT RTT RTT RTT RTT RTT RTT RTT

A envio B

RTT

confirmação

Edgard Jamhour

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 de Congestionamento: 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)

13
 Congestionamento X Controle de Fluxo

Dados a Serem Trasmitidos

tempo 2000 RcvWindow

1800 CongWindow

1500

LastByteSent

1000
LastByteAcked
0

A envio B

RTT

confirmação

Edgard Jamhour

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).

14
 Protocolo UDP

0 4 8 12 16 20 24 28 31

Byte 1 Byte 2 Byte 3 Byte 4

Porta de Origem Porta de Destino

Ponteiro de Urgência Checksum

Dados
....

Edgard Jamhour

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.

15
 Protocolos de Aplicação

Camada de Aplicaç
Aplicação HTTP FTP SMTP NFS DNS DHCP

Camada de Transporte TCP UDP

Camada de Rede IP

Edgard Jamhour

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.

16
 Portas bem Conhecidas
http
httpd 80 >1023 wget

ftp control
21 >1023
ftpd ftp data ftp
20 >1023
servidor cliente
smtp
smptd 25 >1023 firefox

nfs
nfsd 2049 >1023 nfs client

dns
named 53 >1023 dig

dhcp
dhcpd 67 >1023 dhclient

Edgard Jamhour

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.

17
 Conclusão

Protocolos de Transporte e Aplicação

Edgard Jamhour

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.

18