Protocolos da Camada de Transporte

A comunicao de dados na Internet acontence entre dois processos finais (programas, na

camada de aplicativos). A comunicao acontece entre processos finais (process-to-process).
Como muitos processos podem estar rodando em um dado computador ao mesmo tempo,
necessrio um mecanismo para garantir a entrega dos pedaos de informao aos processos
corretos.
A camada de transporte a responsvel pela entrega dos dados entre aplicativos. Para tal
usa uma mecansmo de endereamento discutido adiante. Ela tambm pode oferecer servios
orientados a conexo (ou no) e confiabilidade (ou no).

A camada de transporte responsvel pela comunicao envolvendo processos finais.

Paradigma Cliente-Servidor

Existem diversas maneiras de efetuar a comunicao entre processos finais, mas o mais
amplamento utilizado o paradigma cliente-servidor. Um processo que em um host local,
denominado cliente, precisa dos servios de outro processo localizado em um host remoto,
denominado servidor.
Ambos processos (cliente e servidor) possuem o mesmo nome. Por exemplo, para obter o
dia e a hora de uma mquina remota necessitamos de um cliente, denominado Daytime, rodando no
host local e um processo servidor, Daytime tambm, rodando no host remoto.
Para a comunicao devemos definir:
Host local
Processo local
Host remoto
Processo remoto

Mecanismo de endereamento

Sempre que dados devem fluir entre dois destinos dentre muitos possveis, necessrio um
mecanismo de endereamento. Na camada de enlace, os endereos de hardware (MAC address) so
responsveis por identificar um n em uma rede local. Na camada de rede, os nmeros IP
identificam unicamente um determinado host na rede de alcance global. Em cada caso, um endereo
de origem e um de destino esto especificados.
Na camada de transporte o mesmo se faz valer. So utilizados dois endereos, um de
origem e outro de destino. Estes endereos recebem o nome de portas nesta camada. Na Internet,
os endereos de portas so nmeros inteiros de 16 bits (0 at 65535, 64K).
No host que roda o processo cliente, os nmeros das portas so designados (em geral) de
maneira aleatria ou pelo menos no determinada. Pode-se dizer que esses nmeros de portas so
temporrios (ou efmeros), pois so atribudos apenas enquanto o processo cliente est
comunicando com o servidor.
No host que roda o servidor, as portas so estticas (ou permanentes). Se as portas fossem
escolhidas ao acaso (ou de maneira no previamente conhecida), o processo cliente no saberia para
qual porta direcionar suas requisies. Ele teria ento que procurar previamente a qual porta se
dirigir.
Existem algumas excees a essas regras. Existem processos clientes que utilizam sempre
a mesma porta (o SMTP originalmente) e processos servidores que no tm portas pr-determinadas
(o RCP ainda assim; ele possui um servidor RPC que funciona como um catlogo das portas
utlizadas pelos demais processos RPC (servidor de arquivos por exemplo)).
O IANA (Internet Assigned Number Authority, www.iana.org) detm a autoridade sobre
os nmeros de portas. Para tal dividiu os nmeros em trs faixas:
Portas bem conhecidas (well known). Portas com nemros entre 0 e 1023 so
atribuidas e controladas pela IANA. So portas pblicas e bem conhecidas, ex.: telnet, ftp,
http.
Portas registradas. So portas com nmeros entre 1024 e 49.151 e no so
atribudas pela IANA, apenas controladas por ela, para evitar duplicao. Apenas empresas
podem requerer um registro.
Portas dinmicas. So as portas de 49.152 at 65.535. No so registradas nem
controladas. Qualquer processo pode utilizar estas portas.
A lista completa dos nmeros atribudos e controlados pelo IANA pode ser verificado em:
http://www.iana.org/assignments/port-numbers
importante notar que apenas um processo pode utilizar uma porta especfica em um dado
momento.

Deve ficar claro que os endereos IP identificam um host. Os endereos de

portas identificam um processo. So camadas distintas.

Um endereo de socket definido pelos quatro nmeros dados pelos endereos

IP de origem e destino e as portas de origem e destino. Uma dada conexo
definida pelo seu endereo de socket.

A API mais empregada para programao de redes a API Sockets (est

implementada virtualmente em todas linguagens, desde C, C++ e Java at
linguagens de script, tais como Perl, Python, ASP e VB)

Servios Sem Conexo versus Servios Orientados a Conexo

Em um servio sem conexo, os pacotes so enviados de uma parte a outra, sem a

necessidade de estabelecer uma conexo. Os pacotes no so numerados. Eles podem chegar
atrasados, se perder ou at mesmo chegar fora de ordem. No existe a obrigao de reconehcimento
de recebimento (ACK).
Em um servio orientado a conexo, antes dos dados serem realmente transmitidos, uma
conexo deve ser previamente estabelecida. Depois de enviados os dados, essa conexo deve ser
encerrada. Existe todo um mecnismo de numerao dos dados e todo envio deve ter seu
recebimento reconhecido. Para estabelecer uma conexo so necessrias as seguintes etapadas:
 O host A envia um pacote para anunciar o desejo de iniciar uma conexo e inclui a
informao de inicializao sobre o trafego de A para B.
O host B envia um pacote de confirmao de recebimento (ACK) da solicitao de
A.
Caso o host B aceite a comunicao com A, envia um pacote sobre a inicializao
do trafego de B para A.
O host A envia um reconhecimento (ACK) para confirmar a solicitao de B.
Para finalizar uma conexo ambas as pontas devem concordar no seu encerramento, caso
contrrio a ponta que o desejar, pode continuar enviando dados. O seguinte procedimento deve ser
seguido:
O host A envia um pacote informando o desejo de terminar a conexo.
O host B envia um reconhecimento (ACK) da solicitao de A; a conexo
encerrada em uma direo. B pode continuar a enviar dados se assim o desejar.
O host B, depois de finalizar seu envio, dispacha uma solicitaa de finalizao de
conexo para A
Quando A enviar o reconhecimento para B, a conexo estar encerrada em ambos
os sentidos.

Servios confiveis e no confiveis

Na Internet existem dois protocolos diferentes, um oferecendo confiabilidade (da entrega

correta dos dados) e outro, muito mais simples, que no oferece esse servio. O UDP protocolo de
transporte sobre IP que no apresenta confiabilidade e no orientado a conexo. O TCP, como
veremos adiante um protocolo muito mais sofisticado (e por isso consome muito mais recursos do
host hospedeiro) orientado a conexo e que oferece o servio de confiabilidade da entrega correta
dos dados.
O TCP faz trs garantias sobre os dados:
Entrega completa
Em ordem
Sem repetio

User Datagram Protocol (UDP)

O protocolo UDP no orientado a conexo e no confivel, carecendo assim

de mecnismos de controle de fluxoe de erros. Utiliza nmeros de portas para
multiplexar os dados da camada de aplicao.

Um datagrama UDP consiste de um cabealho UDP e uma carga de dados (payload). O

cabealho UDP realmente muito simples, consistindo de apenas 4 campos, dos quais apenas 3 so
obrigatrios:
Porta de Origem. Representa a porta usada pelo processo no host de origem.
Tamanho de 16 bits.
 Porta de Destino. Representa a porta utilizada pelo processo no host de destino. 16
bits de tamanho.
Tamanho. Indica o tamanho total do datagrama UDP, consistindo de outros 16
bits.
Checksum. Utilizado para detectar erros no datagrama. Sua utilizao opcional,
uma vez que viola o conceito de idependncia das camadas de rede. Os projetistas,
originalmente propuseram a utilizao de partes do cebealho IP no clculo desta soma. Se
no for utilizado, seus espao de 16 bits deve ser preenchido com zeros.

Desafio: Quais protocolos utilizam o UDP e quais suas respectivas portas (existe pelo menos um
protocolo de aplicao que fundamental para o correto funcionamento da WEB)?

Transmission Control Protocol (TCP)

A confiabilidade dos processos de comunicao na camada de transporte no modelo da
Internet foi deixada para o Transmition Control Protocol (TCP). O TCP um protocolo de
transporte orientado a conexo e confivel. o TCP orienta e fornece confiabilidade aos servios da
camada IP.

Nmero de portas
Como o UDP, o TCP usa nmero de portas como mecanismo de endereamento na camada
de transporte. Algumas portas mais conhecidas so:

Porta Protocolo Descrio

7 Echo Eco
9 Discard Descarta qualquer datagrama
11 Users Usurios Ativos
13 Daytime Dia e Hora
19 Chargen Gerador de Caracteres
20 FTP (dados) File Transfer Protocol
21 FTP (comandos) File Transfer Protocol
23 TELNET Terminal Remoto
25 SMTP Simple Mail Transfer Protocol
53 DNS Domain Name Service
67 BOOTP Bootstrap Protocol
80 HTTP HyperText Transfer Protocol
111 RPC Remote Procedure Call
 Servios TCP
Fluxo do servio de entrega
O TCP permite ao processo transmissor entregar dados como uma cadeia de bytes e ao
processo receptor obter os dados como uma cadeia de bytes. O TCP cria um ambiente no qual os
dois processos parecem estar conectados por um tubo imaginrio por onde so transportados os
dados atravs da Internet.

Buffers de Transmisso e Recepo

Visto que os dois processos (transmisso e recepo) podem no produzir e consumir
dados mesma velocidade, o TCP necessita de um esquema de bufferizao. O TCP requer dois
buffers: um para transmisso e outro para recepo (um em cada direo). Veremos adiante que tais
buffers tambm so utilizados pelos mecanismos de controle de fluxo e de erros. Um modo de
implementar um buffer usar um arranjo circular tipo FIFO (first-in-first-out). Usualmente estes
buffers tm tamanhos diferentes.

Bytes e Segmentos
Embora o esquema de bufferizao controle a disparidade de velocidade entre os processos
transmissor e receptor, precisamos de uma etapa a mais antes da transmisso de dados. A camada
IP, enquanto provedora de servios para o TCP, precisa enviar pacotes de dados e no uma cadeia
de bytes. Na camada de transporte, o TCP agrupa uma certa quantidade de bytes juntos para formar
um pacote denominado segmento. O TCP anexa um cabealho a cada segmento (com o propsito
de controle) e entrega o segmento camada IP para transmisso. Os segmentos so encapsulados
em um datagrama IP e em seguida transmitidos. Toda essa operao transparente ao processo que
estiver rodando no receptor. Observe que os segmentos no tm necessariamente o mesmo
tamanho.

Servio Full-Duplex
O TCP oferece servios de entrega em modo full-duplex, onde dados podem fluir nas duas
direes ao mesmo tempo. O protocolo TCP rodando em cada uma das pontas agrega um buffer de
transmisso e outro de recepo capazes de transmitir segmentos em ambas direes.

Servio Orientado a Conexo

O TCP, diferente do UDP, um protocolo orientado a conexo. Quando um processo A
desejar transmitir dados a outro processo B acontecem as seguintes etapas:
1. O protocolo TCP que cuida dos processos de A solicita ao protocolo TCP de B, que cuida
dos processos de B, aprovao para iniciar a transmisso.
2. O TCP de A e B trocam dados em ambas direes.
3. Quando ambos processos no tiverem dados a transmitir, os buffers tornam-se vazios. Os
protocolos TCP nos dois lados reciclam os respectivos buffers.
Observe que isto uma conexo virtual, no uma conexo fsica. O segmento TCP
encapsulado em um datagrama IP e, por isso, pode chegar fora de ordem, perder-se, ser corrompido,
e ento precisar ser retransmitido. Cada segmento pode seguir um caminho diferente at o destino,
porque no existe uma conexo fsica dedicada entre as duas pontas. Entretanto, o TCP cria o
ambiente orientado conexo, aceitando para si a responsabilidade de entregar os bytes de dados no
outro lado.

Servio Confivel
O TCP um protocolo de transporte confivel. Ele utiliza um mecanismo de confirmao
(ACK) para verificar a integridade dos dados.
 Numerao de Bytes

Embora o protocolo TCP mantenha os registros dos segmentos transmitidos e/ou

recebidos, no h um campo especfico para o nmero de segmento. Ao invs disso, h dois campos
denominados nmero de seqncia e nmero de confirmao. Estes dois campos referem-se ao
nmero do byte e no ao nmero do segmento.

Nmero de Bytes
O protocolo TCP numera todos os bytes de dados que so transmitidos em uma conexo. A
numerao independente em cada direo. O TCP numera os bytes quando recebe os dados de um
processo e os armazena no buffer de transmisso. A numerao no comea necessariamente em
zero. O valor inicial por um gerador de nmeros aleatrios entre 0 e 232 1. Por exemplo, se o
nmero aleatrio escolhido for 1057 e a quantidade total de bytes 6000, os bytes so numerados
de 1057 at 7056.

Os bytes de dados em cada conexo so numerados pelo TCP. A numerao

inicial escolhida a partir de um gerador de nmeros aleatrios.

Nmero de Seqncia
Aps os bytes terem sido numerados, o TCP atribui um nmero de seqncia para cada
segmento transmitido. O nmero de seqncia do segmento idntico ao nmero do primeiro byte
transportado por este segmento.

Exemplo 1
Imagine uma conexo TCP transferindo 6000 bytes. O primeiro byte recebe a numerao
10010. Quais so os nmeros de seqncia para cada segmento se os dados so transmitidos em 5
segmentos, os quatro primeiros transportando 1000 bytes cada e o ltimo 2000 bytes?

Soluo
A seguir vemos os nmeros de seqncia para cada segmento:
Segmento 1: nmero de seqncia 10010 (faixa 10010 a 11009)
Segmento 2: nmero de seqncia 11010 (faixa 11010 a 12009)
Segmento 3: nmero de seqncia 12010 (faixa 12010 a 13009)
Segmento 4: nmero de seqncia 13010 (faixa 13010 a 14009)
Segmento 5: nmero de seqncia 14010 (faixa 14010 a 16009)

O valor do campo nmero de seqncia em um segmento define o nmero do

primeiro byte do conjunto de dados do segmento.

Nmero de Confirmao
Como discutimos antes, a comunicao TCP full-duplex. Quando uma conexo
estabelecida, ambas partes podem enviar e receber dados ao mesmo tempo. Cada uma das partes
numera os bytes com um nmero inicial recebido do gerador de nmeros aleatrios e, por isso,
geralmente estes nmeros so diferentes. O nmero de seqncia em cada direo identifica o
nmero do primeiro byte transportado pelo segmento.
 Cada parte usa tambm um nmero de confirmao para assegurar ao transmissor que os
bytes foram recebidos. Entretanto o nmero ACK define o nmero do prximo byte que o protocolo
TCP receptor espera receber. Alm disso, o nmero ACK cumulativo, isto , o receptor toma o
nmero do ltimo byte recebido, salva, incrementa-o de uma unidade e o utiliza como nmero de
confirmao.

O valor do campo ACK em um segmento define o prximo byte que um

processo espera receber. O nmero ACK cumulativo.

Segmento TCP

A unidade de dados transferida entre dois processos utilizando o TCP o segmento. O

segmento consiste de um cabealho de 20 a 60 bytes, seguido do campo de dados dos processos da
camada de aplicao. O cabealho possui 20 bytes, sem as opes e 60 bytes com elas.

Porta de Origem nmero de porta do programa que est transmitindo.

Porta de Destino nmero de porta do programa que est enviando.
Nmero de Seqncia nmero atribudo ao primeiro byte do segmento.
Nmero de Confirmao nmero que indica o recebimento de todos os bytes at n, e
espera a recepo do byte n+1.
Tamanho do cabealho indica a quantidade de palavras de 4 bytes que formam o
cabealho. Em geral entre 5 (5 X 4 = 20) e 15 (15 X 4 = 60).
Reservado para uso futuro.
Flags veja a seguir.
Tamanho da Janela Devine o tamanho da janela (em bytes) que a outra parte deve
suportar. O tamanho da janela tem 16 bits, 65535 bytes de tamanho, a menos que o tamanho
seja aumentado por alguma opo extra.
 Checksum checksum para o cabealho (apenas).
Urgncia indicador de que o segmento possui bytes que devem ser entregues com
urgncia.
Opes opes extra ao cabealho TCP.

Os flags do TCP so:

URG Valida o campo indicador de urgncia (pouco utilizado)
ACK Este segmento confirmao algum segmento anterior
PSH Fora o recebimento dos dados (raramente utilizado)
RST reseta imediatamente a conexo
SYN Sincroniza nmero de seqncia (incio de conexo)
FIN Finaliza a conexo

Conexo

Estabelecimento de uma conexo TCP:

Encerramento da conexo TCP:

Reset da conexo:
O TCP pode solicitar ainda o resetting da conexo. Resetar a conexo significa que ela encerrada
sumariamente. Isto pode acontecer em trs situaes:
1. O TCP do cliente solicitou uma conexo a uma porta no aberta. O TCP do servidor pode
enviar um segmento com o bit RST configurando para anular a solicitao.
2. O TCP do servidor pode querer abortar a conexo devido a uma situao anormal. Ele pode
enviar um segmento RST para encerrar a conexo.
3. O TCP do cliente pode descobrir que o TCP do servidor est ocioso por muito tempo. Ele
pode enviar um segmento RST para desligar a conexo.

Diagrama de Transio de Estados

Closed sem conexo

Listen servidor esperando
Syn-Sent solicitao de conexo enviada; esperando pelo ACK
Syn-Rcvd recebida colicitao de conexo
Estabilished conexo estabelecida
Fin-Wait-1 a aplicao solicitou o encerramento
Fin-Wait-2 a outra extremidade solicitou o encerramento
Time-Wait aguardando pelos segmentos enviados para encerrar
Close-Wait servidor esperando a aplicao encerrar
Last-Ack servidor esperando pelo ltimo ACK

Cada transio caracterizada por Entrada/Sada.

 Controle de Fluxo

O controle de Fluxo estabelece a quantidade de dados que um host de origem pode

transmitir antes de receber um reconhecimento (ACK) do host de destino. Em casos extremos, um
protocolo de transporte poderia transmitir um nico byte e esperar pela confirmao antes de
transmitir o prximo byte. Mas isso geraria um processo de comunicao extremamente lento. Se os
dados tiverem que percorrer uma distncia fsica muito grande, o host de origem ficaria muito
tempo ocioso, esperando por um ACK.
No outro extremo, um protocolo de transporte pode transmitir todos os dados de uma nica
vez, sem se preocupar em receber ACKs. Isso pode aumentar a velocidade do processo de
comunicao, mas pode sobrecarregar o receptor. Alm disso, se alguma parte da massa de dados
for perdida, duplicada, recebida fora de ordem ou corrompida, o host de origem no saber at que
todos os dados tenham sido verificados pelo host de destino.
O TCP apresenta uma soluo entre estes dois extremos. Ele envia tandos dados quantos
forem definidos pelo mecanismo baseado numa janela deslizante (mvel).

O Mecanismo Janela Deslizante

O Janelamento um mecanismo de controle de fluxo que exige que o dispositivo de

origem receba uma confirmao do destino depois de transmitir uma determinada quantidade de
dados. Neste mtodo, ambos hosts usam uma janela para cada conexo. A janela ocupa uma poro
do buffer contendo bytes que o host transmissor pode enviar antes de se preocupar em receber um
ACK do receptor. O mecanismo chamado janela mvel ou janela deslizante porque ocorre uma
movimentao sobre o buffer de dados a medida que dados e confirmaes so enviados e
recebidos.

Expandindo a Janela de Transmisso

Se o processo que estiver recebendo dados puder utiliz-los a uma velocidade superior
taxa de recepo, o tamanho da janela de recepo pode ser expandido. Esta situao pode ser
informada ao transmissor, resultando no aumento do tamanho da janela.

Reduzindo a Janela de Transmisso

Se o processo que estiver recebendo consumir os dados mais lentamente do que eles esto
sendo recebido no buffer, o tamanho da janela de recepo reduzido. Neste caso, o receptor deve
informar ao transmissor para que ele reduza o tamanho da janela de transmisso.

Fechando a janela de transmisso

O que acontece quando o buffer do receptor atingir a capacidade mxima? Neste caso, o
valor da janela de recepo vai a zero. Quando isto informado ao transmissor, ele fecha a janela.
O transmissor no pode enviar outros bytes adicionais at que o receptor retorne um valor diferente
de zero para a janela de recepo.

No TCP, o tamanho da janela de transmisso totalmente controlado pelo valor da

janela de recepo (a quantidade de entradas livres no buffer do receptor). Contudo,
o tamanho real da janela pode ser menor se houver congestionamento na rede.
 Controle de Erros

O TCP um protocolo de transporte confivel. Isto significa que um processo na camada

de aplicao pode confiar no TCP para entregar todos os dados em ordem aplicao na outra
extremidade, sem erros, isto , sem partes perdidas, fora de ordem, perdidas ou segmentos
duplicados.
O TCP utilzia trs ferramentas simples: checksum, ACK e time-out.
O campo de checksum do cabealho indica se o mesmo foi corrompido. Em caso afirmativo,
os segmento inteiramente descartado
O TCP utiliza o ACK para enviar confirmao de recebimento para os segmentos realmente
chegaram e no foram danificados.
Um contador time-out disparado no host de origem para cada segmento enviado. Todos os
contadores so verificados periodicamente. Quando um contador expira, o segmento
correspondente considerado perdido ou danificado, sendo solicitada a restransmio dele.

No protocolo TCP no so enviadas respostas negativas de confirmao.

Relgios do TCP
O TCP utiliza quatro relgios para suavizar sua operao:

Relgio de Retransmisso
O TCP utiliza o relgio de retransmisso para controlar o tempo de retransmisso dos
segmentos perdidos ou corrompidos, esperando o tempo de confirmao de um segmento. Quando
o TCP transmite um segmento, ele configura um relgio de retransmisso para esse segmento em
particular. Podem ocorrer duas situaes:
1. Se um ACK recebido para um segmento particular antes do relgio expirar, o relgio
desarmado.
2. Se ocorrer um time-out antes do ACK ser recebido, o segmento retransmitido e o relgio
resetado.
A maneira mais comum configurar o tempo do time-out como duas vezes o RTT (Roud-
Trip Time), o tempo entre o envio do segmento anterior e o recebimento do seu ACK. Se um ACK
no recebido, o tempo decrementado pela metade sempre que o relgio precisa ser rearmado.

Relgio de Persistncia
Para lidar com a informao do tamanho de janela mvel igual a zero, o TCP precisa de
outro relgio. Suponha que um TCP receptor informe o tamanho de janela zero. O TCP transmissor
no pode transmitir at que uma confirmao anunciando uma janela de tamanho maior do que zero
seja informada. Caso essa confirmao seja perdida, ambos processos ficam parados, um
aguardando pelo outro.
Para evitar isso, utilizado o relgio de persistncia. Quando o TCP transmissor recebe um
ACK de tamanho de janela zero, ele dispara um relgio. Quando esse relgio expira, o transmissor
envia um segmento especial, contendo apenas um nico byte, que no contabilizado nas contagem
do TCP, apenas para alertar o receptor de que seu ACK pode ter sido perdido. Neste caso o receptor
envia uma nova confirmao.
Se uma resposta no recebida, o valor do relgio duplicado e disparado novamente. O
processo se repete at o relgio atingir valores da ordem de 60 segundos, quando ento estabiliza
neste valor.
Relgio Keep-Alive
Algumas implementaes utilizam este relgio para evitar conexes ociosas entre dois
protocolos TCP. Caso um cliente envie uma certa quantidade de dados ao um servidor, e por algum
motivo a aplicao tenha travado. O TCP no encerra a conexo sem a requisio explicita da
aplicao. Neste caso a conexo continua aberta.
Este relgio funciona assim: O relgio resetado toda vez que o servidor escuta algum
dado do cliente. O valor do time-out tipicamente de 2 horas. Um segmento de sondagem
enviado pelo servidor caso ele no escute o cliente aps 2 horas. As sondagens so espaadas de 75
segundos. Aps 10 sondagens sem nenhuma resposta, o servidor considera o cliente inativo e
encerra a conexo.

Relgio de Espera
O relgio de espera utilizado para a finalizao de conexes. Quando o TCP fecha uma
conexo, ele no considera a conexo fechada efetivamente. A conexo mantida no limbo por um
perodo de espera. Isso possibilita que os segmentos FIN duplicados, se existirem, cheguem ao
destino para serem descartados. O valor para este relgio tipicamente o mesmo que o relgio de
retransmisso.
Exerccios:

1. Considere uma conexo TCP entre o host A e o host B. Suponha que os segmentos TCP que
trafegam do host A para o host B tenham um nmero de porta de origem X e o nmero da
porta de destino Y. Quais so os nmeros de porta origem e porta de destino para os
segmentos que trafegam de B para A?
2. Por que um desenvolvedor de uma aplicao poderia escolher rodar um aplicao sobre
UDP em vez de TCP?
3. possvel que uma aplicao desfrute de transferncia confivel de dados mesmo quando
roda sobre UDP? Se sim, como isto possvel?
4. Verdadeiro ou Falso
a. O host A est enviando ao host B um arquivo muito grande por uma conexo TCP.
Suponha que o host B no tenha dados para enviar para o host A. O host B no enviar
reconhecimentos para A pois os reconhecimentos no podem "pegar carona" com os dados.
b. O tamanho da janela de recebimento nunca muda enquanto dura uma conexo.
c. Imagine que o host A est enviando ao host B uma arquivo muito grande via TCP. Se o
nmero de seqncia para um segmento desta conexo for M, ento o nmero de seqncia
para o segmento seguinte ser necessariamente M+1.
d. O cabealho do TCP tem um campo para o tamanho da "Janela de Recebimento".
e. Imagine que o host A envie ao host B, por uma conexo TCP, um segmento com o
nmero de seqncia 38 e 4 bytes de dados. Neste mesmo segmento, o nmero de
reconhecimento ser 42.
5. Suponha que um host A envie dois segmentos TCP, um atrs do outro, ao host B. O
primeiro segmento tem nmero de seqncia 90 e o segundo nmero de seqncia 110.
a. Quantos bytes tem o primeiro segmento?
b. Suponha que o primeiro segmento seja perdido, mas o segundo chegue a B. No
reconhecimento que B envia para A, qual ser o nmero?
6. O cliente A inicia uma sesso Telnet com o servidor S. Quase ao mesmo tempo, o cliente B
tambm inicia uma sesso Telnet com o mesmo servidor S. Fornea possveis nmeros de
porta de origem e de destino para:
a. Os segmentos enviados de A para S.
b. Os segmentos enviados de B para S.
c. Os segmentos enviados de S para A.
d. Os segmentos enviados de S para B.
e. Se A e B so hosts diferentes, possvel que o nmero de porta de origem nos segmentos
de A para S sem os mesmos que de B para S?
f. E se A e B forem o mesmo host?