Redes 09 Camadadetransporte 090621170001 Phpapp02 PDF

Camada de Transporte
Luiz Arthur 1
A Camada de transporte e responsvel por fornecer um meio de transporte
lgicos aos dados transmitidos pela rede. Esse transporte pode ser orientado a
conexo e no orientado a conexo, isto na prtica tratado pelos protocolos
TCP (Transmission Control Protocol) e UP (User ata!ram Protocolo).
" transporte dos dados pode na prtica ser tratado na Camada de Enlace, porm
o modelo TCP#$P tra%al&a com a pior &ip'tese poss(vel, )ue a de a Camada de
Enlace no controlar o transporte dos dados, ento o modelo TCP#$P cuida disto
de forma l'!ica na Camada de Transporte, utili*ando principalmente o protocolo
TCP )ue orientado a conexo.
Alm, disso na camada de $nter+redes, um endere,o IP de destino identifica
apenas um host e nen&uma outra distin,o feita com referencia a )ual usurio
ou )ual pro!rama rece%er o data!rama.
Ento na Camada de Transporte os protocolos UP e o TCP ampliam a pil&a de
protocolos TCP#$P, acrescentando um mecanismo )ue permite discernir entre
diversas dire,-es em um dado &ost (isto c&amado de Porta de .ede),
permitindo )ue vrios pro!ramas aplicativos executados em determinado
computador enviem e rece%am data!ramas isoladamente.
$sto necessrio pois a maioria dos Sistemas Operacionais so multitarefa
podendo executar diversos aplicativos ao mesmo tempo. Tais tarefas so o
!eralmente o destino final da maioria das tarefas.

Luiz Arthur 2
Cada Porta de protocolo )ue identifica um processo de rede identificado por um
n/mero inteiro positivo. " 0istema "peracional fornece um mecanismo de
interface )ue os processos usam para especificar uma porta ou acess+la.
Para comunicar-se com uma porta exterior um transmissor precisa
conhecer tanto o endereo IP da mquina de destino como o nmero da
porta de destino de protocolo nessa m)uina. $dentificando assim o &ost de
destino da mensa!em %em como o aplicativo de destino.
Cada mensa!em de rede deve transportar o n/mero de porta de destino da
m)uina para )ual a mensa!em enviada e tam%m da porta de origem da
m)uina de ori!em para a )ual as respostas devero ser endere,adas. Assim,
poss(vel )ue )ual)uer processo )ue rece%a uma mensa!em responda ao
transmissor.
!s portas tam"#m ser$em para identificar uma dada conexo por exemplo,
ima!ine uma conexo da m)uina 12.2.2.1 para um servidor de p!inas na
m)uina 12.2.2.345, tal conexo pode ser representada da se!uinte forma6
%&'&'&'%())&&% * %&'&'&'+,-(.&. 0endo )ue 12.2.2.1 o &ost de ori!em 77221
a porta de ori!em ()ue aleat'ria) e 12.2.2.345 o &ost de destino 82
aporta %em con&ecida do servidor de p!inas. A resposta do servidor de p!inas
ocorrer no sentido inverso, exemplo6 %&'&'&'+,-(.& * %&'&'&'%())&&%, isto
permite a identifica,o da conexo, alm de permitir vrias conex-es na mesma
m)uina de ori!em e destino.

Luiz Arthur 3
/0P 1 2/ser 0atagram Protocol3
" User ata!ram Protocol (UP) fornece um servi,o de entre!a )ue dados sem
conexo no confivel, usando $P para transportar mensa!ens entre as m)uinas.
" UP usa o $P para identificar &osts (destino final), mas acrescenta a
capacidade de distin!uir entre vrios destinos (aplicativos) dentro de
determinado &ost, utili*ando as Portas.
Ento o UP fornece o mecanismo principal utili*ado pelos pro!ramas aplicativos
para enviar data!ramas a outros pro!ramas. 9ornecendo Portas de protocolo
para esta%elecer a distin,o entre os diversos pro!ramas executados em um
&ost.
Cada mensa!em UP leva, os dados a serem enviados, um n/mero de porta de
destino e tam%m um n/mero de porta de ori!em, tornando poss(vel )ue o
soft:are UP no destino, entre!ue a mensa!em ao destinatrio correto e
possi%ilitando, ao destinatrio enviar uma resposta.
Um pro!rama aplicativo )ue usa UP aceita inteiramente a responsa%ilidade de
lidar com o pro%lema de confia%ilidade, inclusive perda de mensa!em,
duplica,o, retardo, transmisso defeituosa e perda de conectividade. Cada
mensa!em UP con&ecida como um data!rama de usurio.

Luiz Arthur 4
Em o UP consiste em duas partes6 ca%e,al&o UP; e rea de dados UP.
Cada campo do ca%e,al&o UP tem as se!uintes fun,-es6
Source Port (Porta de "ri!em) e 0estination Port (Porta de estino)6 Cont<m
os n/meros de Porta do protocolo UP de 1= %its usados para demultiplexar
(entre!ar) os data!ramas entre os processos (pro!ramas) )ue esperam para
rece%<+los. A Porta de ori!em opcional e especifica a porta para a )ual devem
ser enviadas as respostas; se no usada dever ser *ero.
/0P lengh6 > o taman&o do data!rama e contm uma conta!em de octetos do
data!rama UP, incluindo o ca%e,al&o UP e os dados de usurios. Assim o valor
m(nimo para esse oito (apenas ca%e,al&o).
Source Port Destination Port
UDP length UDP Checksum
Playload/Dados
1! 31

Luiz Arthur "
/0P chec4sum6 Este campo rece%e a soma de verifica,o para ver se o
ata!rama UP est correto. Esse campo opcional (neste caso preenc&ida
com *eros), isso foi feito para permitir ao UP operar com o m(nimo de over&ead
poss(vel, e torn+lo mais simples. ?as lem%re+se )ue o $P no fa* a verifica,o de
inte!ridade da parte de dados. Portanto, a soma de verifica,o oferece o /nico
modo de asse!urar )ue os dados ten&am c&e!ado intactos e possam ser usados.
A soma de verifica,o UP a%ran!e mais informa,-es do )ue consta do
data!rama UP so*in&o. Para calcular a soma de verifica,o, o UP inicialmente
adiciona um pseudoca%e,al&o ao data!rama UP, acrescenta um octeto de *eros
para preenc&er o data!rama e fa*er dele um m/ltiplo exato de 1= %its e calcula a
soma de verifica,o co%rindo todo o o%@eto.
Porm o octeto usado para o preenc&imento e o pseudoca%e,al&o no so
transmitidos com o data!rama UP, nem so inclu(dos no comprimento. " uso de
um pseudoca%e,al&o tem como finalidade verificar se o data!rama UP atin!iu o
seu destino correto.
Source Address #$P de %rigem&
Destination Address #$P de Destino&
UDP length Protocol #'eros&
32 (its

Luiz Arthur !
" pseudoca%e,al&o feito com o endere,o $P de ori!em e destino, o campo
protocol ()ue indica o protocolo usado neste caso o UP). Aote )ue estes campos
so o%tidos no data!rama $P e no no data!rama UP.
" campo UP len!t& do pseudo ca%e,al&o o /nico campo extra(do do
data!rama UP.
A soma de verifica,o UP inclui ento os endere,os $P de ori!em, $P de destino
e protcolo. " )ue si!nificando )ue o soft:are UP deve intera!ir com o soft:are
$P para encontrar endere,os antes de enviar data!ramas.
A forte intera,o ente UP e $P violam a premissa %sica de )ue a coloca,o em
camadas reflete separa,o de funcionalidades. "u se@a, cada camada deveria ser
independente da outra, porm como poss(vel ver isto no acontece na prtica
com o modelo TCP#$P. B )ue o UP da Camada de Transporte est estreitamente
inte!rado com o protocolo $P da Camada de $nter+rede.
" TCP inclui o mesmo pseudo ca%e,al&o para a soma de verifica,o.
Por fim, depois do ca%e,al&o vem o plaCload#ados, )ue ir conter as
informa,-es uteis do usurio, a ser entre!ue ao protocolo da Camada de
Aplica,o.

Luiz Arthur )
5ncapsulamento do /0P
" Encapsulamento do UP ocorre da se!uinte forma6
Aeste caso iniciamos o encapsulamento na Camada de Transporte utili*ando o
protocolo UP e o encapsulamos (colocamos dentro) do data!rama $P na Camada
de $nter+rede, por fim, usamos um )uadro (frame) Et&ernet para enviar pela rede
a informa,o na Camada de Enlace. Ao &ost de destino feito o
desempacotamento do data!rama UP. Aote )ue a informa,o enviada pela rede
seria al!o como a fi!ura a se!uir6
Ca(e*alho
UDP
+rea de dados UDP
Ca(e*alho
$P
+rea de dados $P
Ca(e*alho
,thernet
+rea de dados ,thernet
Ca(e*alho
,thernet
Ca(e*alho
$P
Ca(e*alho
UDP
+rea de dados UDP

Luiz Arthur -
6ultiplexao7 demultiplexao e portas /0P
" conceito de multiplexar si!nifica %asicamente sair de uma camada e ir para
outra, por exemplo, sair da Camada de Aplica,o e ir para a Camada de
Transporte. B o conceito de demultiplexa,o o processo inverso, ou se@a, tirar a
informa,o da Camada de Transporte e ir para a Camada de Aplica,o.
Aote )ue este conceito @ foi usado na Camada de Enlace, com o campo Tipo do
padro Et&ernet, por exemplo para entre!ar a informa,o para a Camada de
$nter+.ede (para o protocolo $P, por exemplo). E na Camada de $nter+.ede para ir
para a Camada de Transporte, usando o campo Protocol do $P para entre!ar a
informa,o para o UP ou TCP.
Conceitualmente, toda a multiplexa,o e demultiplexa,o entre UP e os
pro!ramas aplicativos ocorre por meio do mecanismo de Porta. Assim, na prtica
cada pro!rama precisa ne!ociar com o sistema operacional para o%ter uma
Porta de protocolo e um n/mero de porta associado antes de poder envia um
data!rama UP. Duando a porta tiver sido atri%u(da, )ual)uer data!rama )ue o
pro!rama aplicativo enviar por ela ter esse n/mero de porta em seu campo
0ource Port.
Ao processar a entrada, o UP aceita data!ramas )ue c&e!am do $P e
desmultiplexa com %ase na porta de destino UP.

Luiz Arthur .
Duando o UP rece%e um data!rama, ele verifica se o n/mero da porta de
destino com%ina com uma das portas atualmente em uso. 0e no, ele envia uma
mensa!em de erro $C?P de porta inalcan,vel (port unreac&ea%le) e descarta o
data!rama. 0e for ac&ada uma com%ina,o, o UP enfileira o novo data!rama na
porta em )ue o pro!rama aplicativo pode acess+lo. Aaturalmente pode
acontecer desta fila @ estar c&eia e desta forma pode &aver erros na entre!a, e o
UP descarta o data!rama )ue c&e!a.
A multiplexa,o tam%m se aplica ao protocolo TCP.
Camada de $nter/0ede
$P
UDP1 Demulti2le3a*4o
com (ase na 2orta
Porta 1 Porta 2 Porta 5
Datagrama UDP chega

Luiz Arthur 1
8mero de porta /0P reser$ados e dispon9$eis
Antes de )ual)uer opera,o de rede dois computadores precisam com%inar a
respeito dos n/meros de portas a serem usadas. Existem duas tcnicas
fundamentais para a atri%ui,o de porta.
A primeira tcnica usa uma autoridade central atri%ua n/meros de porta
confirme a necessidade e pu%li)ue a lista de todas as atri%ui,-es. epois, todo
soft:are criado de acordo com a lista. Essa tcnica Es ve*es c&amada de
atri%ui,o universal, e as atri%ui,-es de porta especificadas pela autoridade so
c&amadas atri%ui,-es de porta %em con&ecidas (:ell+Fno:n port assi!nments).
A se!unda tcnica para atri%ui,o de porta utili*a o v(nculo dinGmico. Aa tcnica
de v(nculo dinGmico, as portas no so con&ecidas !lo%almente. Em ve* disso,
sempre )ue um pro!rama precisa de uma porta, o soft:are de rede atri%ui uma.
Para desco%rir a atri%ui,o de porta em outro computador, preciso enviar uma
re)uisi,o )ue per!unte a atri%ui,o de porta atual (por exemplo, H)ue porta o
servi,o de transfer<ncia de ar)uivos est usandoIJ). A m)uina de destino
responde dando o n/mero de porta correto a usar.
"s pro@etistas do TCP#$P adotaram uma tcnica &(%rida )ue atri%ui al!uns
n/meros de porta a priori, mas deixa muitos dispon(veis para os sites locais ou os
pro!ramas aplicativos atri%u(rem dinamicamente. "s n/meros de porta
atri%u(dos come,am com valores %aixos e se estendem para cima, deixando
valores inteiros !randes dispon(veis para atri%ui,o dinGmica. " mesmo vale para
o TCP.

Luiz Arthur 11
Kale a pena relem%rar explicitamente al!umas a,-es )ue o UP no reali*a. Ele
no reali*a controle de fluxo, controle de erros ou retransmisso ap's a recep,o
de um se!mento incorreto. "u se@a, ele um protocolo no orientado a conexo
assim como $P s' fornecendo ento uma maneira de entre!ar os dados na
Camada de Aplica,o (multiplexa,o).
" UP fornece apenas a)uilo )ue determinado. Uma rea na )ual o UP
especialmente /til a de situa,-es cliente#servidor. Com fre)L<ncia, o cliente
envia uma pe)uena solicita,o ao servidor e espera uma pe)uena resposta de
volta. 0e a solicita,o ou a resposta se perder, o cliente simplesmente c&e!ar ao
timeout (exceder o tempo) e tentar de novo.
Ao s' o c'di!o simples, mas necessrio um n/mero menor de mensa!ens
(uma em cada sentido) do )ue no caso de um protocolo )ue exi!e uma
confi!ura,o inicial, tal como o TCP.
Uma aplica,o )ue utili*a o UP desse modo o A0 (omain Aame 0Cstem),
)ue estudaremos no posteriormente na Camada de Aplica,o. Em resumo, um
pro!rama )ue precisa pes)uisar o endere,o $P de al!um nome de &ostM por
exemplo, :::.!oo!le.com M pode enviar um pacote UP contendo o nome do
&ost a um servidor A0. " servidor responde com um pacote UP )ue contm o
endere,o $P. Ao necessria nen&uma confi!ura,o antecipada e tam%m
nen&um encerramento posterior. Nasta enviar duas mensa!ens pela rede.

Luiz Arthur 12
" UP ento um protocolo muito simples de se implementar e de se utili*ar. E
al!umas aplica,-es iram re)uerer esta simplicidade, tal como aplica,-es em
tempo real, tal como Ko* so%re $P O Ko$P, dentre outras. Assim, podemos destacar
as vanta!ens e desvanta!ens do UP (de um protocolo no orientado a conexo).
esvanta!ens do UP6
Ao esta%elece circu(to entre transmissor e receptor;
Ao confirma a entre!a de dados;
Ao ordena os data!ramas enviados;
Todo e )ual)uer erro deve ser tratado na aplica,o.

Kanta!ens do UP6
0ua implementa,o mais simples;
Proporciona menos over&ead na rede, principalmente com mensa!ens de

controle;
Teoricamente, envia as mensa!ens de forma mais rpida )ue o TCP;

" UP e um protocolo no orientado a conexo tipico e deve ser utili*ado em
aplica,-es )ue no re)uerem se!uran,a na entre!a dos dados e sim )ue
re)uerem velocidade e simplicidade na entre!a dos dados. Pem%rando )ue todo e
)ual)uer controle deve ser oferecido pelo pro!ramador da aplica,o e no pelo
protocolo de transporte UP.

Luiz Arthur 13
Transmission Control Protocol 1 TCP
A !rande maioria dos protocolos do modelo TCP#$P vistos at a)ui (IP7 /0P, etc)
no so orientados a conexo no confivel )ue forma a %ase para toda a
comunica,o da $nternet e o protocolo $P )ue a define.
" TCP apresentado a)ui implementa uma funcionalidade su%stancial aos
protocolos @ discutidos )ue a orientao a conexo, mas )ue sua
implementa,o tam%m su%stancialmente mais complexa.
Ento em um n(vel mais %aixo (Camadas de $nter+.ede e Enlace), as redes de
comunica,o fornecem uma entre!a de pacotes no confivel.
Em um n(vel mais alto, os pro!ramas aplicativos fre)uentemente precisam enviar
!randes volumes de dados de um computado a outro. A utili*a,o de um sistema
de transmisso sem conexo e no-confi$el torna-se tediosa e irritante, e
re)uer )ue os pro!ramadores criem detec,o e recupera,o de erros em cada
pro!rama aplicativo.
" TCP um protocolo de prop'sito !eral )ue a@uda a isolar dos detal&es de
interli!a,o em redes, de pro!ramas aplicativos e possi"ilita definir uma
interface uniforme para o ser$io de transfer:ncia de streams de pacotes
orientados a conexo.

Luiz Arthur 14
A interface entre pro!ramas aplicativos e o servi,o TCP de transmisso confivel
pode ser representada por )uatro caracter(sticas6
Orientao de stream6 Duando dois pro!ramas aplicativos transferem !rande
volume de dados, consideramos os dados como um stream (fluxo) de %its. "
servi,o de transmisso de streams da m)uina de destino passa para o receptor
exatamente a mesma se)L<ncia de octetos (%Ctes) )ue o transmissor passa para
ele na m)uina de ori!em.
Conexo de circuito $irtual6 9a*er uma transfer<ncia de stream de dados
e)uivale a fa*er uma c&amada telefQnica. Em tese, um aplicativo fa* uma
Hc&amadaJ )ue deve ser aceita pelo outro. A comunica,o deve ser autori*ada e
estar pronta para comunica,o dos dois lados (transmissor#receptor). urante a
transfer<ncia de dados, os protocolos das duas m)uinas continuam a comunicar+
se para verificar se os dados so rece%idos corretamente. Porem, utili*ado o
termo circuito virtual por)ue em%ora os pro!ramas aplicativos considerem a
conexo um circuito de &ard:are dedicado, a confia%ilidade uma iluso
proporcionada pelo servi,o de transmisso de stream de dados.

Luiz Arthur 1"
Transmisso "ufferi;ada6 "s pro!ramas enviam um stream de dados atravs
do circuito virtual, repetidamente passando octetos de dados ao protocolo.
urante a transfer<ncia de dados, cada aplicativo utili*a )uais)uer taman&os )ue
ac&ar ade)uados, e )ue podem ser to pe)uenos )uanto um s' octeto. Ao final da
recep,o, o protocolo entre!a os octetos do stream de dados exatamente na
mesma ordem em )ue foram enviados. " protocolo livre para dividir em
pacotes um stream de dados, independente das partes )ue o pro!rama aplicativo
transfere. Para )ue a transfer<ncia se@a mais efica*, e para minimi*ar o trfe!o
de rede, as implementa,-es normalmente coletam de um stream os dados
suficientes para preenc&er um data!rama ra*oavelmente extenso, antes de
transmiti+lo por uma interli!a,o em redes. Assim mesmo se o pro!rama
aplicativo !erar ao stream um octeto de cada ve*, a transfer<ncia na interli!a,o
em redes poder ser muito efica*. a mesma forma, se o pro!rama aplicativo
optar por !erar %locos extremamente extensos, o protocolo talve* prefira dividir
cada %loco em pe)uenas partes para a transmisso.
Conexo full duplex6 As conex-es fornecidas pelo servi,o de stream TCP#$P
permitem transfer<ncia em am%as as dire,-es (full duplex). o ponto de vista de
um processo aplicativo, uma conexo full duplex consiste em dois streams
independentes fluindo em dire,-es opostas.

Luiz Arthur 1!
<ornecendo confia"ilidade
" servi,o de entre!a de fluxo confivel garante entre!ar um fluxo de dados
enviados de uma m)uina para outra sem duplicao ou perda de dados.
Porm, necessrio o%servar )ue toda a "ase do sistema # no confi$el.
Ento para solucionar este pro%lema utili*a+se uma tcnica c&amada como
confirmao positiva com retransmisso (Positive !c4no:led!ement :it&
.etransmition O PA.).
A tcnica re)uer )ue um destinatrio se comuni)ue com a ori!em, enviando de
volta uma mensa!em de confirma,o (!C=) en)uanto rece%e os dados.
" emissor mantm em re!istro de cada pacote )ue envia e espera uma
confirma,o antes de enviar o pr'ximo pacote.
" emissor mantm um re!istro de cada pacote )ue envia e espera uma
confirma,o antes de enviar a pr'ximo pacote. " emissor tam%m inicia um
timer )uando envia um pacote, e retransmite o pacote se o timer expirar antes
)ue a confirma,o c&e!ue.
Ento )uando o timer expira, o emissor assume )ue o pacote foi perdido e o
retransmite. > possivel notar isto nas fi!uras a se!uir.

Luiz Arthur 1)
,n6iar 2acote 1
0ece(er 2acote 1
,n6iar AC7 1
0ece(er 2acote 2
,n6iar AC7 2
0ece(er AC7 1
,n6iar 2acote 2
0ece(er AC7 2
,n6iar 2acote 1
$niciar timer
Pacote de6e
chegar e AC7
de6eria ser
en6iado
0ece(er 2acote 1
,n6iar AC7 1
AC7 normalmente
chegaria nesta hora
0ece(er AC7 1
Pacote Perdido
Timer expira
0etransmite 2acote 1
$niciar timer
,n6io de Pacotes
8CP sem 2ro(lemas
na 8ransmiss4o
,n6io de Pacotes
8CP com 2ro(lemas
na 8ransmiss4o

Luiz Arthur 1-
>anelas desli;antes
Antes de continuar a os estudos so%re o protocolo TCP, precisamos entender o
conceito de Banelas desli*antes, )ue torna a transmisso de pacotes mais
eficiente.
Pem%re+se )ue teoricamente, para conseguir confia"ilidade o emissor
transmite um pacote e depois espera por uma confirmao antes de
transmitir outro pacote. Assim, a rede permanecer completamente ociosa
durante os momentos em )ue os &osts atrasam as respostas.
Um protocolo de confirmao positiva simples (tal como o TCP) desperdia
uma )uantidade su%stancial de largura de "anda de rede, pois precisa adiar o
envio de um novo pacote at )ue rece%a uma confirma,o para o pacote anterior.
A t#cnica de ?anela desli;ante uma forma mais complexa de confirma,o
positiva e retransmisso do )ue o mtodo simples discutido anteriormente. "s
protocolos de @anela desli*ante utili;am melhor a largura de "anda de rede,
pois permitem )ue o emissor transmita vrios pacotes antes de esperar uma
confirma,o.
O protocolo coloca uma ?anela pequena7 de tamanho fixo7 na seq@:ncia e
transmite todos os pacotes que se encontram dentro da ?anela'

Luiz Arthur 1.
Um pacote tido como no+confirmado se tiver sido transmitido e nen&uma
confirma,o tiver sido rece%ida. Tecnicamente, o n/mero de pacotes )ue podem
ser confirmados em determinado momento restrin!ido pelo taman&o da @anela,
)ue limitado a um n/mero pe)ueno, fixo. Por exemplo, em um protocolo de
?anela desli;ante com tamanho de ?anela ,7 o emissor tem permisso de
transmitir , pacotes antes de rece"er uma confirmao.
Como mostra a fi!ura, quando o emissor rece"e uma confirmao para o
primeiro pacote dentro da ?anela7 ele Adesli;aB a ?anela e en$ia o prximo
pacote. A @anela continua a desli*ar en)uanto as confirma,-es so rece%idas.
Com um protocolo de @anela desli*ante %em a@ustado mant#m+se a rede
completamente saturada com pacotes, e poss(vel o%ter um t&rou!&put
su%stanciosamente maior do )ue um protocolo de confirma,o simples.
1 2 3 " ! ) - . 1 11 12 13 999 5
1 2 3 " ! ) - . 1 11 12 13 999 5
Janela Inicial
Janela desliza

Luiz Arthur 2
Ser$ios oferecidos pelo TCP
" TCP %em complexo, de modo )ue no existe uma resposta simples, mas ele
espec(fica6
" formato de dados;
Confirma )ue dois computadores trocam dados para conse!uir transfer<ncia

confivel;
$mplementa mecanismos para !arantir )ue os cados c&e!uem corretamente

no destino;
Permite distin!uir entre vrios destinos em determinado &ost;
Como os &osts devem recuperar pacotes perdidos ou duplicados;
Como iniciar uma transfer<ncia de fluxo TCP e como terminar;

" TCP no espec(fica6
Ao descreve como os pro!ramas aplicativos devem utili*ar o TCP em termos

!erais, a documenta,o no discute estes detal&es. $sto d uma flexi%ilidade
maior ao pro!ramador, porm o pro!ramador !eralmente usa a interface
oferecida pelo 0istema "peracional;

Luiz Arthur 21
Portas e conexCes
Assim, como UP, o TCP tam%m permite )ue vrios pro!ramas aplicativos em
determinado &ost se comuni)uem simultaneamente, e demultiplexa o trfe!o
TCP )ue c&e!a entre os pro!ramas aplicativos com os nmeros de portas de
protocolo.
Por#m as portas TCP so mais complexas )ue as UP, pois determinado
n/mero de porta no corresponde a um /nico o%@eto. Em ve* disto, o TCP foi
montado so"re a a"strao da conexo, em )ue os o%@etos a serem
identificados so conex-es de circuito virtual, e no portas individuais.
> fundamental entender )ue o TCP usa a no,o de conex-es, pois a@uda a
explicar o si!nificado e o uso dos n/meros de porta TCP. Cada conexo so
identificadas por um par de extremidades. 0endo a conexo um par de
inteiros (&ost, porta), isto feito com as duas extremidades, destino e ori!em
(exemplo6 1R3.1=8.2.1677221 S 1R3.1=8.2.345682).
Como o TCP identifica uma conexo por um par de extremidades, determinado
n/mero de porta TCP pode ser compartil&ado por vrias conex-es na mesma
m)uina. $sto si!nifica )ue um pro!ramador pode criar um pro!rama )ue
oferea ser$io concorrente a $rias conexCes simultaneamente, sem exi!ir
portas locais para cada conexo.

Luiz Arthur 22
!"erturas passi$as e ati$as
iferente do UP, o TCP # um protocolo orientado a conexo7 que exige que
as duas extremidades 2host de origem e destino3 concordem em participar
da transmisso.
Para isso, o pro!rama aplicativo em uma extremidade reali*a uma fun,o de
a"ertura passi$a, contatando seu 0istema "peracional e indicando )ue ele
aceitar uma conexo )ue c&e!a.
Aeste momento, o 0istema "peracional atri%ui um n/mero de porta TCP para sua
extremidade de conexo. " pro!rama aplicativo na outra extremidade precisa
ento contatar seu 0istema "peracional usando uma re)uisi,o de a"ertura
ati$a para esta"elecer uma conexo.
"s dois m'dulos de TCP se comunicam para esta%elecer e verificar uma conexo.
Duando uma conexo tiver sido criada, os pro!ramas aplicativos podem come,o
a passar dados; os m'dulos TCP em cada extremidade trocam mensa!ens )ue
!arantem a entre!a confivel. Keremos este assunto mel&or posteriormente.

Luiz Arthur 23
Tamanho de ?anelas $ari$el e controle de fluxo
Uma diferena entre o protocolo de @anela desli*ante TCP do protocolo
simplificado, ocorre por)ue o TCP permite que o tamanho da ?anela $arie
com o tempo.
Cada confirmao7 que especifica quantos octetos foram rece"idos7
cont#m um anncio de ?anela que espec9fica quantos octetos adicionais
de dados o receptor est preparado para aceitar'
Podemos pensar no an/ncio de @anela como especificador do tamanho de
"uffer atual do receptor. Em resposta a um anuncio de @anela maior, o emissor
aumenta o taman&o de sua @anela desli*ante e prosse!ue para enviar octetos )ue
no foram confirmados. Em resposta a um an/ncio de @anela diminu(da, o
emissor diminui o taman&o de sua @anela e pra de enviar octetos alm do limite.
" TCP no pode contradi*er os an/ncios anteriores, encurtando a @anela alm
das posi,-es anteriores, e para isto anncios menores de$em rece"er uma
confirmao da outra extremidade.
A vanta!em de usar uma @anela de taman&o varivel )ue ela oferece controle
de fluxo e tam%m transfer<ncia confivel. Para evitar )ue os &osts rece%am mais
dados do )ue podem arma*enar. "u at mesmo informar um %uffer *ero para
interromper uma transmisso, e outro taman&o para reiniciar a transmisso.

Luiz Arthur 24
> essencial ter um mecanismo para controle de fluxo em um am%iente no )ual
as m)uinas de vrias velocidades e taman&os se comunicam por redes e
roteadores de diversas velocidades e capacidades (exemplo, um computador e
um celular).
Assim, existem dois pro"lemas um # solucionar o fluxo de dados fim-a-fim
TCP, )ue aca%amos de ver como o TCP fa*, e outro controlar o
congestionamento (nos &osts intermedirios a conexo, tal como roteadores)
este assunto ser discutido posteriormente.
Pacotes TCP
A unidade de transfer:ncia entre o TCP nos dois &osts # chamada de
segmento ou pacote. "s pacotes so trocados para se esta%elecer conex-es.
0endo ainda )ue um se!mento pode fa*er o servi,o de piggD"ac4ing (carona)
permitindo )ue um /nico se!mento envie dados de um &ost e controle de outro
&ost. "u se@a em uma mensa!em podemos enviar os dados do &ost A para o &ost
N e na mesma mensa!em confirmar uma pacote enviado de N para A, o )ue
ameni*a o pro%lema de over&ead.
Cada se!mento ou pacote dividido em duas partes, um ca"ealho e a rea de
dados. " ca%e,al&o transporta a identifica,o esperada e informa,-es de
controle. Ao slide a se!uir podemos ver o formato do ca%e,al&o TCP.

Luiz Arthur 2"
%2tions # ou mais :ords de 32/(it&
Se;uence num(er
Source Port Destination Port
Ackno:ledgement num(er
<indo: size
8CP =eader
length
F
I
N
S
Y
N
R
S
T
P
S
H
A
C
K
U
R
G
Urgent 2ointer Checksum
Data #o2cional&
1! 31

Luiz Arthur 2!
Source Port6 Porta de ori!em, indica a aplica,o )ue ori!inou os dados;
0estination Port6 Porta de destino, indica a aplica,o para a )ual os dados
sero entre!ues no receptor;
Sequence num"er6 A/mero de se)L<ncia )ue identifica a posi,o no fluxo de
%Ctes do emissor dos dados no se!mento;
!c4noEledgement num"er6 A/mero de confirma,o, identifica o n/mero de
octeto )ue a ori!em espera rece%er em se!uida.
"%serve )ue o n/mero de se)L<ncia refere+se ao fluxo )ue se!ue na mesma
dire,o do se!mento, en)uanto o n/mero de confirma,o refere+se ao fluxo )ue
se!ue na dire,o oposta do se!mento;
TCP Feader length6 Esse campo especifica o taman&o do ca%e,al&o do pacote
TCP, contando em n/meros de 73 %its." taman&o m(nimo do ca%e,al&o de cinco
palavras de 73 %its (32 %Ctes), sendo esse o valor mais comum do campo TPEA,
@ )ue normalmente o campo "ption no usado. Duando este campo usado, o
valor do campo TPEA seis.
Existem depois do campo Teader len!t& = %its reservados, )ue no so usados e
ficam reservados para uso futuro.

Luiz Arthur 2)
epois dos %its reservados vem uma se)L<ncia de %its c&amados de %its de
Controle ou Nits de C'di!o6 Esses %its so usados por exemplo, esta%elecer
conex-es TCP, manter e finali*ar. " soft:are TCP utili*a tais campos para
determinar a finalidade e o conte/do do se!mento. "s seis %its podem ser vistos
a se!uir e di*em como interpretar outros campos no ca%e,al&o TCP.
Git Significado 2caso este?a ati$o - com $alor %3
/HI " campo Ur!ent Point vlido.
!C= " campo AcFno:led!ement num%er vlido.
PSF 9or,a a entre!a dos dados (pus& O empurrar).
HST .einiciar a conexo.
SJ8 0incroni*a n/meros de se)L<ncia.
<I8 " transmissor c&e!ou ao fim de seus dados.
" valor 1 atri%u(do a /HI se /rgent pointer esti$er sendo usado. Ur!ent
pointer usado para indicar um deslocamento de "Dtes no fluxo de dados
TCP a partir do n/mero de se)L<ncia atual em )ue os dados ur!entes devem ser
encontrados. Esse recurso su%stitui as mensa!ens interrompidas. Esse recuso
representa uma forma estruturada de permitir )ue o transmissor envie um sinal
ao receptor sem envolver o servi,o TCP no motivo da interrup,o.

Luiz Arthur 2-
Ao %it !C= atri%u(do o valor 1 para indicar que !c4noEledgement num"er
# $lido. 0e ACU for i!ual a *ero, isso si!nifica )ue o se!mento no contm uma
confirma,o e assim o campo AcFno:led!ement num%er i!norado.
" %it PSF indica dados com o fla! PU0T. Com ele # solicitado a entregar os
dados K aplicao mediante sua chegada, em ve* de arma*en+los at )ue um
%uffer completo ten&a sido rece%ido (o )ue ele poderia fa*er para manter a
efici<ncia).
" %it HST # utili;ado para reiniciali;ar uma conexo )ue ten&a ficado
confusa devido a uma fal&a no &ost ou por )ual)uer outra ra*o. Ele tam%m
utili*ado para re@eitar um se!mento invlido ou para recusar uma tentativa de
conexo. Em !eral, se rece%er um se!mento com o %it .0T ativado, isso si!nifica
)ue a conexo tem um pro%lema.
" %it SJ8 # usado para esta"elecer conexCes. A solicita,o de conexo tem
0VAW1 e ACUW2 para indicar )ue o campo de confirma,o de pi!!C%acF no est
sendo utili*ado. A resposta contm uma confirma,o e, portanto, tem 0VA W 1 e
ACU W 1. Nasicamente, o %it 0VA usado para denotar pedido de conexo e
conexo aceita, en)uanto o %it ACU usado para distin!uir entre essas duas
possi%ilidades.

Luiz Arthur 2.
" %it <I8 utili;ado para encerrar uma conexo. Ele indica )ue o
transmissor no tem mais dados a enviar. Entretanto, um processo pode
continuar a rece%er dados indefinidamente, mesmo depois da conexo ter sido
encerrada. Tanto o se!mento 0VA )uanto o se!mento 9$A t<m n/meros de
se)L<ncia e, portanto, so processados na ordem correta.
LindoE si;e6 Taman&o da @anela, define o tamanho da ?anela7 em "Dtes7 que
ser usada na conexo, ou se@a, o TCP anuncia )uantos dados ele espera
aceitar toda ve* )ue envia um se!mento, especificando seu taman&o de %uffer
neste campo. Este campo normalmente utili*a a tcnica de pi!!C%acFin!, pois
acompan&a todos os se!mentos, especialmente a)ueles carre!ando dados e
confirma,-es.
O controle de fluxo no TCP # administrado por meio de uma ?anela
desli;ante de tamanho $ari$el. " campo Xindo: si*e indica quantos "Dtes
podem ser en$iados a partir do "Dte confirmado. Um campo LindoE si;e
igual a & vlido e informa )ue todos os %Ctes at AcFno:led!ement num%er +
1 inclusive foram rece%idos, mas que o receptor precisa de um descanso no
momento e a!radeceria muito se nen&um outro dado fosse enviado.
A permisso para retomar a transmisso de dados pode ser enviada mais tarde
com o mesmo AcFno:led!ement num%er e com um campo Xindo: si*e diferente
de *ero.

Luiz Arthur 3
Chec4sum6 > calculado de forma similar ao c&ecFsum do protocolo UP, com a
cria,o de um pseudoca%e,al&o.
/rgent pointer6 Em%ora o TCP se@a orientado a fluxo (stream), Es ve*es
importante )ue o pro!rama em uma extremidade de uma conexo en$ia dados
fora da faixa, sem esperar )ue o pro!rama na outra extremidade da conexo
consuma o %uffer.
Por exemplo7 se o usurio quiser a"ortar a conexo antes de ela chegar ao
fim, essa informa,o deve ser processada antes de os dados c&e!arem ao fim, ou
o usurio no ter como a%ortar o processo. Esta informa,o, portanto, se!uir
em um se!mento com o %it U.Y ativado.
Para acomodar a sinali*a,o fora de faixa, o TCP permite )ue o emissor
especifi)ue dados como ur!entes, si!nificando )ue o pro!rama receptor deve ser
notificado so%re sua c&e!ada o mais rpido poss(vel, independente de sua
posi,o no fluxo de dados. " receptor deve entrar no modo ur!ente e depois )ue
todos os dados ur!entes tiverem sido consumidos, o TCP di* ao pro!rama
aplicativo para retornar E opera,o normal.
etal&es exatos de como o TCP informa ao pro!rama aplicativo so%re dados
ur!entes dependem do 0istema "peracional.

Luiz Arthur 31
Options6 " campo op,-es pode conter ;ero ou mais opCes no ca"ealho.
Cada op,o come,a com um campo de 1 octeto )ue espec(fica o tipo da op,o,
se!uida por um campo de 1 octeto )ue especifica o taman&o do da op,o em
octetos. 0e as op,-es no ocuparem um m/ltiplo exato de 73 %its, vai ser feito
um enc&imento (padding) no final do ca%e,al&o.
Al!umas opCes do campo Options do ca%e,al&o TCP so6
- Opo de tamanho mximo do segmento
/m emissor pode escolher a quantidade de dados que # colocada em cada
segmento. Porm, as duas extremidades de uma conexo TCP de$em
com"inar so"re um segmento mximo que elas transferiro.
" TCP usa uma op,o de taman&o mximo de se!mento (6aximum Segment
Si;e 1 6SS) para permitir )ue um receptor especifi)ue o se!mento de taman&o
mximo )ue ele dese@ar rece%er. Assim um &ost como um PA pode se
comunicar com um 0upercomputador, permitindo )ue m)uinas e redes
&etero!enias se comuni)uem.
Ento para maximi*ar o t&rou!&put, )uando dois &osts se conectam E mesma
rede f(sica, o TCP normalmente calcula o 66S de modo )ue o data!rama $P
resultantes com"inem com o 6T/ da rede.

Luiz Arthur 32
0e as extremidades no estiverem na mesma rede f(sica, elas podero tentar
desco"rir a 6T/ m9nima ao londo do caminho entre elas, ou escol&er um
taman&o de se!mento mximo de 47= ()ue o taman&o padro de um data!rama
$P, 4Z=, menos o taman&o padro dos ca%e,al&os $P e TCP.
M claro que em redes como a Internet a escolha de um "om 66S pode ser
dif9cil se no imposs9$el' $sto se torna um !rande pro"lema para a rede, pois a
escol&a de pacotes extremamente pequenos podem causar, por exemplo
o$erhead na rede, @ a escol&a de um 66S muito grande pode o%ri!ar, por
exemplo, os roteadores a fragmentar o pacote e !erar pro%lemas de
performance da rede.
Em teoria, o tamanho de segmento ideal, )uando os data!ramas $P
transportando os se!mentos so os maiores poss9$eis sem exigir
fragmentao em )ual)uer lu!ar ao lon!o do camin&o da ori!em ao destino.
?s na prtica isto muito dif(cil, pois por exemplo, os roteadores podem mudar
os pacotes de rota para redes com ?TU menores.
- Opo de ?anela m$el
Como a @anela no ca%e,al&o TCP tem 1= %its de extenso, o tamanho mximo
da ?anela # de N- ="Dtes. E este taman&o pode ser um pro%lema para se o%ter
alto t&rou!&put (por exemplos, linFs via satelite). Ento, para acomodar
?anelas maiores existe uma opo chamada de escala de ?anela, )ue
apresenta al!uns campos extras )ue permite informar o taman&o real da nova
@anela.

Luiz Arthur 33
- Opo de estampa de tempo
A op,o de estampa de tempo TCP foi inventada para a?udar o TCP a calcular o
atraso na rede su"?acente, e tam%m usada para lidar com o caso em )ue os
n/meros de se)L<ncia do TCP excedem dois elevado a trinta e dois %its
(con&ecidos como n/meros Protect A!aist Xrapper 0e)uence O PAX0).
A op,o de estampa inclui um valor de tempo e um valor de estampa de tempo de
resposta de eco.
Assim, um emissor coloca a &ora de seu clocF atual no campo estampa de tempo
ao enviar um pacote; um receptor copia o campo de estampa de tempo para o
campo de resposta de eco antes de retornar uma confirma,o para o pacote.
!ssim7 quando uma confirmao chega7 o emissor pode calcular com
preciso o tempo gasto total desde que o segmento foi en$iado.
- Hetransmisso seleti$a
"utra op,o o uso da retransmisso seletiva, em $e; do protocolo go "ac4 n,
nesse protocolo um receptor rece%er um se!mento defeituoso se!uido de um
!rande n/mero de se!mentos perfeitos, o protocolo TCP normal eventualmente
sofrer um timeout e retransmitir todos os segmentos no confirmados,
incluindo os que chegaram em perfeitas condiCes (isto , o protocolo !o
%acF n).

Luiz Arthur 34
Esta op,o (AAUs) para permitir que o receptor solicite um segmento (ou
se!mentos) espec9fico(s). epois de rece%er esses se!mentos, o receptor poder
confirmar todos os dados arma*enados no %uffer, redu*indo assim o volume de
dados a serem retransmitidos.
0ata6 O ultima parte do pacote TCP # a rea de dados, )ue opcional, pois
em muitos casos o TCP pode enviar apenas o ca%e,al&o, para efetivar uma
opera,o de controle TCP por exemplo. > claro )ue isto aumenta o over&ead na
rede (este o pre,o )ue se pa!a por um protocolo orientado a conexo), mas
existem tcnicas )ue tentam ameni*ar este tipo de pro%lema, usando por
exemplo a tcnica de pi!!C%acFin! (carona), )ue tenta enviar dados de controle
@unto com pacotes TCP )ue conten&am dados.
5sta"elecimento de conexCes TCP
Esta%elecer uma conexo parece uma tarefa fcil mas, na verdade, trata+se de
um procedimento complicado. " pro%lema )ue a rede pode perder, arma*enar e
duplicar pacotes. Esse comportamento causa srias complica,-es.
Para esta"elecer uma conexo7 o TCP usa um handsha4e de tr:s $ias.
Ao caso simples o processo de &ands&aFe funciona como a fi!ura a se!uir.

Luiz Arthur 3"
" primeiro se!mento de um s&ands&aFe pode ser identificado por)ue possui o %it
0VA marcado. A se!unda mensa!em possui os %its 0VA e ACU marcados,
indicando )ue ele confirma o primeiro se!mento 0VA, alm de continuar com o
&ands&aFe. A mensa!em de &ands&aFe final apenas uma confirma,o, e
simplesmente usada para informar ao destino de )ue am%os os lados concordam
)ue uma conexo foi esta%elecida.
" pro%lema sur!e se as re)uisi,-es retransmitidas e ori!inais c&e!arem
en)uanto a conexo estiver sendo esta%elecida (lem%re+se )ue o meio no
confivel). ?as o &ands&aFe de tr<s vias soluciona estes pro%lemas.
,n6iar se;9 S>5?3
0ece(er segmento S>5
,n6iar se;9 S>5?y@ AC7 3A1
0ece(er segmento AC7
0ece(er segmento S>5 A AC7
,n6iar AC7 yA1

Luiz Arthur 3!
8meros de seq@:ncias iniciais
O handsha4e reali;a duas funCes importantes. Ele garante que os dois
lados esto prontos para transferir dados e permite que os dois lados
concordem so"re nmeros de seq@:ncia iniciais. 0endo esses n/meros
enviados durante o &ands&aFe.
Cada m)uina precisa escol&er um n/mero de seq@:ncia inicial
aleatoriamente, )ue usar para identificar os %Ctes no fluxo )ue est enviando.
Aaturalmente, # importante que os dois lados concordem so"re um nmero
inicial, de modo )ue os n/meros de octetos usados nas confirma,-es com%inem
com a)ueles usados nos se!mentos de dados.
Para ver como as m)uinas podem com%inar so%re n/meros de se)L<ncia para
dois fluxos, ima!ine )ue6 " &ost A envia seu n/mero de se)L<ncia (x) na primeira
mensa!em do &ands&aFe, e o %it 0VA.
Um &ost N, rece%e o 0VA, re!istra o n/mero de se)L<ncia e reponde enviando
seu n/mero de se)L<ncia, alm da confirma,o )ue especifica )ue N espera x[1.
Aa mensa!em final do &ands&aFe, A confirma rece%er N todos os octetos at C.
Em todos os casos as confirma,-es se!uem a conven,o de usar o n/mero do
pr'ximo octeto esperado.

Luiz Arthur 3)
<echando uma conexo TCP
0ois programas que usam o TCP para se comunicar podemPde$em
terminar a con$ersao de modo controlado. Pem%re+se de )ue as conex-es
do TCP so full duplex e )ue as vemos como contendo duas transfer<ncia de
fluxos independentes, cada uma em uma dire,o.
Duando um pro!rama aplicativo TCP )ue no possui mais dados para enviar, o
TCP fecha a conexo em uma direo. Para fec&ar sua metade de uma
conexo, o TCP de envio termina e transmitir os dados restantes, espera )ue o
receptor confirme e depois envie um se!mento com o %it 9$A marcado. " TCP
receptor confirma o se!mento 9$A e informa ao pro!rama aplicativo em sua
extremidade )ue no & mais dados dispon(veis.
Duando uma conexo tiver sido fec&ada em determinada dire,o, o TCP se
recusa a aceitar mais dados para essa dire,o. ?as neste meio tempo, os dados
podem continuar fluindo na direo oposta at )ue o emissor a fec&e.
Aaturalmente, as confirma,-es continuam a fluir de volta ao emissor, mesmo
depois )ue uma conexo tiver sido fec&ada.
"s detal&es do fec&amento de uma conexo feito usando um &ands&aFe de tr<s
vias modificado para fec&ar uma conexo.

Luiz Arthur 3-
A diferen,a entre um &ands&aFe tradicional e o procedimento de finali*a,o
)ue em ve* de !erar um se!undo 9$A imediatamente, o TCP en$iar uma
confirmao e depois informar K aplicao quanto K requisio para
encerrar.
Pode ser necessrio muito tempo para informar ao pro!rama aplicativo )uanto E
re)uisi,o e o%ter uma resposta (isto pode depender, por exemplo da intera,o
&umana). A confirma,o impede a retransmisso do se!mento 9$A inicial durante
a espera.
9inalmente, )uando o pro!rama aplicativo instruir o TCP a encerrar a conexo
completamente, o TCP envia o se!undo se!mento 9$A, e o site ori!inal responde
com a terceira mensa!em, um ACU.
#A2lica*4o Becha a cone34o&
,n6ia C$5 se;?3
0ece(er segmento C$5
,n6iar AC7 3A1
#inBormar a2lica*4o&
0ece(er segmento C$5AS,D
,n6iar AC7 yA1
#A2lica*4o Becha a cone34o&
,n6iar C$5 se;?y@ AC7 3A1

Luiz Arthur 3.
Quando os dois sentidos da conexo esti$erem desati$ados7 a conexo
ser encerrada. e modo !eral, so necessrios )uatro se!mentos TCP para
encerrar uma conexo, isto , um 9$A e um ACU para cada sentido. Porm,
poss(vel )ue o primeiro ACU e o se!undo 9$A ocupem o mesmo se!mento, o )ue
%aixa o n/mero total para tr<s.
M claro que podem ocorrer pro"lemas e um host no terminar
corretamente uma conexo (fal&a no linF, por exemplo) assim se uma resposta
para um 9$A no c&e!ar no per(odo e)uivalente a duas ve*es o tempo mximo de
dura,o de um pacote, o transmissor do 9$A encerrar a conexo.
Eventualmente, o outro lado perce%er )ue no & mais nin!um na escuta e
tam%m sofrer um timeout. ?esmo )ue essa solu,o no se@a perfeita, pois a
solu,o perfeita teoricamente imposs(vel, ela ter de %astar. Aa prtica, os
pro%lemas so raros.
Hein9cio da conexo TCP
Rs $e;es surgem condiCes anormais que foram um programa aplicati$o
ou softEare de rede a interromper uma conexo' " TCP oferece uma
facilidade de reset para essas desconex-es. Para reiniciar uma conexo, um lado
inicia o termino enviando um se!mento %om o %it .0T e o outro lado responde a
um se!mento de reset imediatamente. A%ortando a conexo. " TCP tam%m
informa ao pro!rama aplicativo )ue &ouve um reset. /m reset # um a"orto
instantSneo, )ue si!nifica )ue a transfer<ncia nas duas dire,-es termina
imediatamente e )ue recursos como %uffers so li%erados.

Luiz Arthur 4
6quina de estados TCP
As etapas necessrias para o esta%elecimento e o encerramento de conex-es
podem ser representadas em uma m)uina de estados finitos com os 11 estados
mostrados. Em cada estado, determinados eventos so vlidos. Duando ocorre
um evento vlido, poss(vel executar uma a,o. 0e ocorrer al!um outro evento,
ser reportado um erro. Pem%re+se o TCP possu9 estados e o /0P no.
stado !escri"#o
CL%S,D 5enhuma cone34o estE ati6a ou 2endente
L$S8,5 % ser6idor estE es2erando 2ela chegada de uma chamada
S>5 0CFD Uma solicita*4o de cone34o chegouG es2era 2or AC7
S>5 S,58 A a2lica*4o come*ou a a(rir uma cone34o
,S8AHL$S=,D % estado normal 2ara a transBerIncia de dados
C$5 <A$8 1 A a2lica*4o inBormou ;ue aca(ou de transmitir
C$5 <A$8 2 % outro lado concordou em encerrar
8$J,D <A$8 Aguarda a entrega de todos os 2acotes
CL%S$5K Am(os os lados tentaram encerrar a transmiss4o
simultaneamente
CL%S, <A$8 % outro lado deu inLcio a uma encerramento
LAS8 AC7 Aguarda a entrega de todos os 2acotes

Luiz Arthur 41
CL%S,D
L$S8,5
S>5
S,58
S>5
0CFD
,S8AHL$S=,D
C$5
<A$8 1
CL%S$5K
CL%S,
<A$8
C$5
<A$8 2
8$J,
<A$8
CL%S,D
LAS8
AC7
$nicio
C%55,C8/S>5 #1/2asso handshake&
S>5/S>5 A AC7 #2/2asso handshake&
$nicio
CL%S,//
CL%S,//
S,5D/S>5
0S8//
S>5/S>5 A AC7
AC7//
S>5AAC7/AC7
#3/2asso handshake&
,stado de transBerIncia
de dados
CL%S,/C$5
CL%S,/C$5
C$5/AC7
C$5/AC7
AC7// AC7//
C$5/AC7
C$5AAC7/AC7
CL%S,/C$5
AC7//
#timeout&
0S8
L$S8,5//

Luiz Arthur 42
Cada conexo comea no estado CP"0E. Ela sai desse estado ao executar uma
a%ertura passiva (P$0TEA) ou ativa (C"AAECT). 0e o outro lado executar a
primitiva oposta, a conexo ser esta%elecida e o estado passar a ser
E0TANP$0TE. " encerramento da conexo pode ser iniciado por )ual)uer um
dos lados. Duando ele se completa, o estado volta a ser CP"0E.
Uma situa,o comum em )ue um cliente se conecta ativamente a um servidor
passivo representado pelas lin&as mais escuras M a linha cont9nua para o
cliente e a linha cin;a para o ser$idor. As lin&as mais claras representam
se)L<ncias de eventos incomuns.
Cada lin&a marcada por um par evento#a,o. " evento pode ser uma c&amada
de sistema iniciada pelo usurio (C"AAECT, P$0TEA, 0EA ou CP"0E), uma
c&e!ada de se!mento (0VA, 9$A, ACU ou .0T) ou, em um /nico caso, um per(odo
de timeout i!ual a duas ve*es a dura,o mxima dos pacotes. A a,o o envio de
um se!mento de controle (0VA, 9$A ou .0T) ou nada, indicado por um travesso
(M). "s comentrios so mostrados entre par<nteses.
Pol9tica de transmisso do TCP
Como mencionamos antes, o gerenciamento de ?anelas no TCP no est
diretamente $inculado Ks confirmaCes, como acontece na maioria dos
protocolos de enlace de dados.

Luiz Arthur 43
Por exemplo, supon&a )ue o receptor ten&a um %uffer de 52R= %Ctes. Se o
transmissor en$iar um segmento de +&-. "Dtes e este for rece"ido de
forma correta7 o receptor confirmar o segmento. Porm, como a!ora ele s'
tem 3258 %Ctes de espa,o dispon(vel em seu %uffer (at )ue al!uma aplica,o
retire al!uns dados do %uffer), o receptor anunciar uma ?anela de +&-.
"Dtes comeando no prximo "Dte esperado.
!gora o transmissor en$ia outros +&-. "Dtes7 que so confirmados7 mas a
?anela anunciada # &. " transmissor de$e parar at o processo de aplica,o
no &ost receptor remover al!uns dados do %uffer, )uando ento o TCP poder
anunciar uma @anela maior. Duando a @anela 2, o transmissor no pode enviar
se!mentos da forma como faria so% condi,-es normais, mas & duas exceCes.
Aa primeira, os dados urgentes podem ser enviados para, por exemplo, permitir
)ue o usurio elimine o processo executado na m)uina remota. Aa se!unda, o
transmissor pode en$iar um segmento de % "Dte para fa;er com que o
receptor anuncie no$amente o prximo "Dte esperado e o tamanho da
?anela. " padro TCP oferece essa op,o de forma expl(cita para evitar um
impasse no caso de um an/ncio de @anela se perder.
Os transmissores no so o"rigados a en$iar os dados assim que os
rece"em das aplicaCes. 8em os receptores t:m a o"rigao de en$iar as
confirmaCes imediatamente'
Este exemplo pode ser visto na fi!ura a se!uir.

Luiz Arthur 44
A2lica*4o
en6ia 27
2k M S,D ?
HuBBer de rece(imento
de dados
Fazio
k 4k
2k
AC7 ? 24- M <in 24-
A2lica*4o
en6ia mais 27
2k M S,D ? 24-
Jem9 cheia
AC7 ? 4.! M <in
AC7 ? 4.! M <in 24- 2k
A2lica*4o
en6ia mais 17
1k M S,D ? 4.!
2k 1k

Luiz Arthur 4"
O pro"lema da inefici:ncia na confirmao de segmentos pequenos
Considere uma conexo telnet com um editor interativo )ue rea!e a cada tecla
pressionada. Aa pior das &ip'teses, )uando um caractere c&e!ar E entidade TCP
receptora, o TCP cria um se!mento TCP de 31 %Ctes, )ue ser repassado ao $P
para ser enviado como um data!rama $P de 51 %Ctes. Ao lado receptor, o TCP
envia imediatamente uma confirma,o de 52 %Ctes (32 %Ctes de ca%e,al&o TCP e
32 %Ctes de ca%e,al&o $P). ?ais tarde, )uando o editor tiver lido o %Cte, o TCP
enviar uma atuali*a,o de @anela, movendo a @anela um %Cte para a direita. Esse
pacote tam%m tem 52 %Ctes. Por /ltimo, )uando o editor tiver processado o
caractere, ele o ecoar como um pacote de 51 %Ctes. Ao total, 1=3 %Ctes de
lar!ura de %anda so utili*ados e )uatro se!mentos so enviados para cada
caractere di!itado. Quando a largura de "anda # escassa7 esse m#todo no
se mostra uma "oa opo.
/ma a"ordagem usada por muitas implementaCes do TCP para otimi;ar
essa situao # retardar as confirmaCes e atuali;aCes de ?anelas
durante ,&& ms7 na esperana de encontrar algum dado que d: Tuma
carona 2piggD"ac4ing3T' 0upondo )ue o editor ecoe dentro de 422 ms, apenas
um pacote de 51 %Ctes precisar ser retornado ao usurio remoto, redu*indo E
metade a conta!em de pacotes e o uso da lar!ura de %anda.

Luiz Arthur 4!
Em%ora essa re!ra redu*a a car!a imposta E rede pelo receptor, o transmissor
ainda estar operando de modo ineficiente, enviando pacotes de 51 %Ctes )ue
cont<m apenas um %Cte de dados. Uma forma de redu*ir esse uso con&ecida
como al!oritmo de Aa!le (Aa!le, 1R85).
! sugesto de 8agle # simples( quando os dados chegarem ao transmissor
um "Dte por $e;7 "asta en$iar o primeiro "Dte e arma;enar no "uffer todos
os outros7 at# que o "Dte pendente tenha sido confirmado' 5m seguida7
en$ie todos os caracteres arma;enados no "uffer em um nico segmento
TCP e comece a arma;enar no "uffer no$amente7 at# todos os caracteres
terem sido confirmados'
0e o usurio estiver di!itando com rapide* e a rede for lenta, cada se!mento
poder conter um n/mero si!nificativo de caracteres, redu*indo %astante a
lar!ura de %anda utili*ada. " al!oritmo permite ainda )ue um novo pacote se@a
enviado se &ouver dados suficientes para preenc&er metade da @anela ou um
se!mento mximo. O algoritmo de 8agle # amplamente utili;ado por
implementa,-es do TCP, mas h ocasiCes em que # melhor desati$-lo. Em
particular, )uando uma aplica,o \ Xindo:s est sendo executada na $nternet,
os mo$imentos do mouse devem ser enviados ao computador remoto. ("
sistema \ Xindo:s o sistema de @anelas utili*ado na maioria dos sistemas
UA$\.) A!rup+los para depois envi+los em ra@adas fa* com )ue o cursor do
mouse se movimente de forma errtica, o )ue deixa os usurios insatisfeitos.

Luiz Arthur 4)
S9ndrome da >anela "o"a
"utro pro%lema )ue pode arruinar o desempen&o do TCP a s(ndrome da @anela
%o%a. 5sse pro"lema ocorre quando os dados so repassados para a
entidade TCP transmissora em grandes "locos7 mas uma aplicao
interati$a no lado receptor l: os dados um "Dte por $e;.
$nicialmente, o %uffer TCP no lado receptor est c&eio e o transmissor sa%e disso
(ou se@a, ele tem uma @anela de taman&o 2). Em se!uida, uma aplicao
interati$a l: um caractere do fluxo TCP. 5ssa ao fa; com que o TCP
receptor fique satisfeito e en$ie uma atuali;ao de ?anela ao transmissor7
informando que ele pode en$iar % "Dte. " transmissor a!radece e envia 1
%Cte. A!ora, o %uffer se enc&e outra ve*; portanto, o receptor confirma o
se!mento de 1 %Cte e atri%ui o valor 2 ao taman&o da @anela. 5sse
comportamento pode durar para sempre.
! soluo apresentada por Clar4 # e$itar que o receptor en$ie uma
atuali;ao de ?anela para % "Dte' 5m $e; disso7 ele # forado a aguardar
at# que ha?a um espao consider$el na ?anela para ento anunciar o fato.
Para ser mais espec(fico, o receptor no de$e en$iar uma atuali;ao de
?anela at# que possa lidar com o tamanho mximo de segmento que
anunciou quando a conexo foi esta"elecida, ou at )ue seu %uffer este@a
com metade de sua capacidade livre (o )ue for menor).

Luiz Arthur 4-
!l#m disso7 o transmissor tam"#m pode a?udar no en$iando segmentos
muito pequenos' Ele deve tentar a!uardar at ter acumulado espa,o suficiente
na @anela para en$iar um segmento inteiro ou pelo menos um segmento
que contenha dados equi$alentes K metade da capacidade do "uffer no
lado receptor (o )ue ele deve estimar a partir do padro de atuali*a,-es de
@anelas )ue @ rece%eu).
Isso redu; o nmero de chamadas ao TCP e7 conseq@entemente7 o
o$erhead. > '%vio )ue isso tam%m aumenta o tempo de resposta; no
entanto, para aplica,-es no interativas como a transfer<ncia de ar)uivos, a
efici<ncia prevalece so%re o tempo de resposta a solicita,-es individuais.
Controle de congestionamento do TCP
Quando a carga oferecida a qualquer rede # maior que sua capacidade7
acontece um congestionamento' A $nternet no exce,o a essa re!ra.
Em%ora a camada de $nter+rede tam%m tente !erenciar o con!estionamento, o
tra%al&o mais pesado feito pelo TCP, pois a $erdadeira soluo para o
congestionamento # diminuir a taxa de transmisso de dados'

Luiz Arthur 4.
Aa teoria, poss(vel lidar com o con!estionamento aplicando+se um princ(pio
emprestado da f(sica6 a lei da conser$ao de pacotes' ! id#ia # no in?etar
um no$o pacote na rede at# que um pacote antigo sai da rede (ou se@a, at
)ue o pacote anti!o ten&a sido entre!ue). " TCP tenta alcanar esse o"?eti$o
manipulando dinamicamente o tamanho da ?anela'
O primeiro passo para gerenciar o congestionamento # detect-lo.
Anti!amente, detectar um con!estionamento era dif(cil. Um timeout causado por
um pacote perdido podia ter sido provocado por (1) ru(do em uma lin&a de
transmisso ou (3) pelo fato de o pacote ter sido descartado em um roteador
con!estionado. Era dif(cil sa%er a diferen,a entre os dois casos. Fo?e em dia7 a
perda de pacotes de$ido a erros de transmisso # relati$amente rara,
por)ue a maioria dos troncos de lon!a distGncia de fi%ra (em%ora tam%m
existam as redes sem fios). Como conseq@:ncia7 a maioria dos timeouts de
transmisso na Internet se de$e a congestionamentos'
Antes de discutirmos como o TCP rea!e aos con!estionamentos, vamos descrever
o )ue ele fa* para tentar evitar sua ocorr<ncia. Duando uma conexo
esta%elecida, deve+se escol&er um taman&o de @anela ade)uado. " receptor pode
especificar uma @anela a partir do taman&o de seu %uffer. 0e o transmissor se
mantiver dentro do taman&o da @anela, no ha$er pro"lemas causados pela
so"recarga dos "uffers na extremidade receptora7 mas eles ainda podero
ocorrer de$ido a congestionamentos internos na rede'

Luiz Arthur "
! soluo da Internet # entender que existem dois pro"lemas potenciais
U a capacidade da rede e a capacidade do receptor U e lidar com cada um
deles separadamente' Para isso, cada transmissor mant#m duas ?anelas6 a
@anela fornecida pelo receptor e uma se!unda @anela, a @anela de
con!estionamento. Cada uma reflete o n/mero de %Ctes )ue o transmissor pode
enviar. " n/mero de %Ctes )ue podem ser transmitidos o valor m(nimo entre as
duas @anelas. esse modo, a @anela efetiva a @anela m(nima )ue o transmissor
ima!ina ser correta, e )ue o receptor tam%m ima!ina ser correta. 0e o receptor
pedir ]Envie 8 UN], mas o transmissor sou%er )ue )ual)uer ra@ada com mais de 5
UN ir con!estionar a rede, ele enviar apenas 5 UN. Por outro lado, se o
receptor pedir ]Envie 8 UN], e o transmissor sou%er )ue ra@adas de at 73 UN
passam pela rede sem pro%lemas, ele enviar os 8 UN solicitados.
Quando uma conexo # esta"elecida7 o transmissor a?usta a ?anela de
congestionamento ao tamanho do segmento mximo em uso na conexo'
5m seguida7 ele en$ia um segmento mximo' Se esse segmento for
confirmado antes de ocorrer um timeout7 o transmissor incluir o nmero
de "Dtes de um segmento na ?anela de congestionamento7 de modo que
ela tenha capacidade equi$alente a dois segmentos mximos7 e em
seguida en$iar dois segmentos' R medida que cada um desses segmentos
for confirmado7 a ?anela de congestionamento ser aumentada em um
tamanho de segmento mximo'

Luiz Arthur "1
Duando a @anela de con!estionamento c&e!ar a n se!mentos, se todos os n
se!mentos forem confirmados a tempo, a @anela de con!estionamento ser
aumentada no n/mero de %Ctes correspondente a n se!mentos. Aa prtica, cada
ra@ada confirmada duplica a @anela de con!estionamento. ! ?anela de
congestionamento mant#m seu crescimento exponencial at# que ocorra
um timeout ou que a ?anela do receptor se?a alcanada. 0e ra@adas de
taman&o i!ual a 1235, 3258 e 52R= %Ctes funcionarem %em, mas uma ra@ada de
81R3 %Ctes causar um timeout, a @anela de con!estionamento dever ser mantida
em 52R= %Ctes para evitar con!estionamentos.
5sse algoritmo # conhecido como iniciali;ao lenta, mas ele no lento de
modo al!um. Esse al!oritmo exponencial. Todas as implementa,-es do TCP
devem ser compat(veis com ele.
!gora7 $amos $er o algoritmo de controle de congestionamento da
Internet. Ele utili*a um terceiro parGmetro, o limiar, inicialmente i!ual a =5 UN,
alm das @anelas do receptor e de con!estionamento. Quando h um timeout7 o
limiar # definido como a metade da ?anela de congestionamento atual7 e a
?anela de congestionamento # redefinida como um segmento mximo'

Luiz Arthur "2
Em se!uida, a iniciali*a,o lenta usada para determinar o )ue a rede capa*
de !erenciar, exceto pelo fato de o crescimento exponencial ser interrompido
)uando o limiar alcan,ado. A partir da(, as transmiss-es %em+sucedidas
proporcionam um crescimento linear E @anela de con!estionamento (o aumento
de um se!mento mximo para cada ra@ada) em ve* de um para cada se!mento.
8a prtica7 esse algoritmo parte do princ9pio de que de$e ser aceit$el
redu;ir K metade a ?anela de congestionamento7 e depois retomar seu
crescimento a partir da9'
Ierenciamento de timers do TCP
" TCP utili*a $rios timers (pelo menos conceitualmente) para reali*ar seu
tra%al&o. O mais importante deles # o timer de retransmisso. Quando um
segmento # en$iado7 um timer de retransmisso # ati$ado' Se o segmento
for confirmado antes do timer expirar7 ele ser interrompido' Por outro
lado7 se o timer expirar antes da confirmao chegar7 o segmento ser
retransmitido (e o timer disparado mais uma ve*). Com isso, sur!e a se!uinte
per!unta6 Qual de$e ser o inter$alo de timeoutV
Esse pro%lema mais dif(cil na camada de transporte da $nternet do )ue nos
protocolos da camada de Enlace.

Luiz Arthur "3
eterminar o tempo de ida e volta para o destino no uma tarefa fcil. Se o
timeout for curto demais7 ocorrero retransmissCes desnecessrias7
so"recarregando a Internet com pacotes inteis' Por outro lado7 se ele for
longo demais7 o desempenho ser pre?udicado de$ido ao longo retardo de
retransmisso sempre que um pacote se perder' Alm disso, a mdia e a
variGncia na distri%ui,o da c&e!ada das confirma,-es podem mudar com muita
rapide* em um intervalo de poucos se!undos, devido E ocorr<ncia ou E resolu,o
de um con!estionamento.
! soluo # utili;ar um algoritmo altamente dinSmico que a?uste
constantemente os inter$alos de timeout7 com "ase na cont9nua a$aliao
do desempenho da rede' " al!oritmo )uase sempre utili*ado pelo TCP foi
criado por >aco"son (1R88) e funciona da se!uinte forma6 para cada conexo, o
TCP mantm uma varivel, HTT7 que # a melhor estimati$a no momento para
o tempo de percurso de ida e $olta at# o destino em questo. Duando um
se!mento enviado, um timer disparado, no s' para verificar )uanto tempo a
confirma,o leva para c&e!ar, como tam%m para acionar uma retransmisso,
caso a confirma,o demore demais. 0e a confirma,o voltar antes do timer
expirar, o TCP medir o tempo necessrio, )ue ser ?. Em se!uida, o TCP
atuali*a a varivel .TT de acordo com a f'rmula6
HTT W XHTT Y 2% -X36
onde um fator de suavi*a,o )ue determina o peso dado ao anti!o valor.
Aormalmente W Z#8. Baco%son alterou posteriormente esta formul para mel&or
desempen&o.

Luiz Arthur "4
/m pro"lema com a estimati$a dinSmica de HTT # o que fa;er quando um
segmento sofre um timeout e # retransmitido' Duando uma confirma,o
c&e!a, no fica claro se ela se refere E primeira transmisso ou a uma
transmisso posterior. /ma suposio errada pode comprometer seriamente
a estimati$a de HTT' Phil =arn desco"riu isto na prtica (@ )ue ele um
entusiasta do radioamadorismo, um meio notoriamente no confivel). 5le fe;
uma proposta simples( no atuali;ar HTT em qualquer segmento que
tenha sido retransmitido' 5m $e; disso7 o inter$alo de timeout seria
duplicado a cada falha7 at# os segmentos chegarem ao destino da
primeira $e;' 5ssa correo # conhecida como algoritmo de =arn' A
maioria das implementa,-es do TCP utili*a esse al!oritmo.
" timer de retransmisso no o /nico timer )ue o TCP utili*a. T outro timer,
c&amado timer de persist:ncia. Ele foi pro?etado para e$itar o impasse
descrito a seguir' O receptor en$ia uma confirmao com um tamanho de
?anela &7 pedindo ao transmissor para esperar' 6ais tarde7 o receptor
atuali;a a ?anela7 mas o pacote com a atuali;ao se perde' !gora7 tanto o
transmissor quanto o receptor esto aguardando que o outro faa alguma
coisa' Quando o timer de persist:ncia expirar7 o transmissor en$iar um
teste ao receptor' ! resposta ao teste fornece o tamanho da ?anela'

Luiz Arthur ""
Se ela ainda for ;ero7 o timer de persist:ncia ser ati$ado no$amente e o
ciclo se repetir' Se for diferente de ;ero7 os dados podero ser
transmitidos' /m terceiro timer utili;ado por algumas implementaCes #
o timer 4eepali$e 2manter $i$o3'
Duando uma conexo permanece inativa por muito tempo, o timer Feepalive pode
expirar para fa*er um lado verificar se o outro lado ainda est ativo. Se esse
outro lado no responder7 a conexo ser encerrada' Esse recurso
pol<mico por)ue, alm de aumentar o over&ead, pode encerrar uma %oa conexo
devido a uma parti,o transit'ria na rede.
" /ltimo timer usado em cada conexo TCP o timer empregado no estado
TI650 L!IT durante o encerramento' 5le # executado por um tempo
igual a duas $e;es a durao mxima dos pacotes para garantir que7
quando uma conexo for fechada7 todos os pacotes criados por ela sero
extintos.
Hesumindo o TCP
" principal protocolo de transporte da $nternet o TCP, )ue fornece um fluxo de
%Ctes %idirecional confivel. Ele utili*a um ca%e,al&o de 32 %Ctes em todos os
se!mentos. "s se!mentos podem ser divididos pelos roteadores da $nternet;
portanto, os &osts devem estar preparados para reor!ani*+los. 0endo fun,o
tam%m do TCP otimi*ar as transmiss-es de dados, mel&orando o desempen&o e
controlando pro%lemas adversos, como con!estionamento.

Luiz Arthur "!
Este material retirado dos se!uintes livros6
TAAEANAU?, Andre: 0. Hedes de Computadores. Editora Campus, 5 Edi,o.
3227.
C"?E., ou!las E. Interligao de Hedes com TCPPIP7 $olume %. Editora
Campus, 4 Edi,o. 322=.
T"..E0, Ya%riel. Hedes de Computadores( Curso Completo. Editora Axcel
NooFs. 1 Edi,o. 3221.
Todos os slides so apenas uma %ase para a disciplina e no dispensa a leitura
dos pr'prios livros para compreenso do assunto como um todo.

Luiz Arthur ")
fim

Redes 09 Camadadetransporte 090621170001 Phpapp02 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Redes 09 Camadadetransporte 090621170001 Phpapp02 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Camada de Transporte

Ao esta%elece circu(to entre transmissor e receptor;

Ao confirma a entre!a de dados;

Ao ordena os data!ramas enviados;

Todo e )ual)uer erro deve ser tratado na aplica,o.

0ua implementa,o mais simples;

Proporciona menos over&ead na rede, principalmente com mensa!ens de

Teoricamente, envia as mensa!ens de forma mais rpida )ue o TCP;

" formato de dados;

Confirma )ue dois computadores trocam dados para conse!uir transfer<ncia

$mplementa mecanismos para !arantir )ue os cados c&e!uem corretamente

Permite distin!uir entre vrios destinos em determinado &ost;

Como os &osts devem recuperar pacotes perdidos ou duplicados;

Como iniciar uma transfer<ncia de fluxo TCP e como terminar;

Ao descreve como os pro!ramas aplicativos devem utili*ar o TCP em termos

Você também pode gostar