Redes de

computadores/Prot
ocolo TCP
< Redes de comput adores

Transporte orientado para conexão: TCP, prot ocolo de t ransport e confiável da camada de
t ransport e, orient ado para conexão, da Int ernet .[1]

O TCP (Transmission Cont rol Prot ocol - Prot ocolo de Cont role de Transmissão) é um dos
prot ocolos[2], sob os quais assent a o núcleo da Int ernet nos dias de hoje. A versat ilidade e
robust ez dest e prot ocolo t ornou-o adequado para redes globais, já que est e verifica se os
dados são enviados de forma corret a, na sequência apropriada e sem erros, pela rede.

A conexão TCP
TCP(Transmission Cont rol Prot ocol) é um prot ocolo da camada de t ransport e, orient ado a
conexão. Ele é responsável pela divisão da mensagem em dat agramas, reagrupament o e
ret ransmissão no caso de dat agramas perdidos.

Dent re suas principais vant agens, podemos dest acar a segurança quant o à reposição de
pacot es perdidos e ordenação desses pacot es.
Estrutura do segmento TCP
[3]

O segment o TCP é dividido em part es. Didat icament e é represent ado pelo bloco abaixo
ilust rado, porém na prát ica é enviado sequencialment e. Cada linha da t abela é um bloco de 32
bit s, sendo que o bit inicial é de número 0.

O prot ocolo TCP permit e que seu cabeçalho t enha t amanho variável, conforme as
necessidades das est ações comunicant es e especifidades do enlace. A est rut ura básica
possui valores bem definidos, como as port as de origem (16 bit s) e de dest ino (16 bit s).

Part es import ant es no TCP são o número de seqüência (32 bit s) e o número de
reconheciment o (32 bit s), pois est es campos garant em a confiabilidade da t ransferência.Há
t ambém out ros campos, como compriment o do cabeçalho (4 bit s), que indica qual t amanho
do cabeçalho em palavras de 32 bit , as flags (6 bit s), que podem ser de 6 t ipos:

URG – urgência
ACK – número ack válido
PSH – push (envio imediato de dados)
RST – reset (reinício da conexão)
SYN – sync (estabelecimento de
conexão)
FIN – finalizar conexão
Há t ambém a janela de recepção (16 bit s) que indica o t amanho da janela para cont role de
fluxo (figura acima), o checksum (16 bit s) que verifica a int egridade dos dados de t odo o
pacot e, como um hash; o pont eiro para dados urgent es (16 bit s) que indica que det erminado
dado deve ser ent regue no mesmo inst ant e, as opções (quant idade variável de bit s), que
podem alocar mais banda do enlace para a t ransmissão dent re out ras possibilidades, e os
dados, cuja quant idade é definida no MSS.

A conexão TCP, por ser confiável, exige o est abeleciment o de uma conexão, embora não seja
necessário alocar exclusividade de enlace (circuit o dedicado[4]). É necessário exist ir um
client e e um servidor, porém como é um prot ocolo full-duplex, um t erminal pode ser
simult aneament e servidor e client e.

A confiabilidade da t ransmissão se deve ao número de seqüência e ao número de

reconheciment o. O primeiro indica qual é o primeiro byt e do segment o de dados, e o segundo
indica o primeiro byt e do próximo segment o de dados. Isso permit e que os dados sejam
agrupados corret ament e, mesmo que pacot es t enham sofrido at rasos na t ransmissão.

O número de sequência é escolhido aleat oriament e no servidor e no client e, e são

independent es ent re si, ou seja, não é exigência que o número de sequência do servidor seja o
mesmo do client e. Mas ent ão como é feit a a comunicação?

Para ist o é ut ilizada a flag ACK. Est a flag faz a sincronização dos números de sequência, como
most rado na figura a seguir.

[5]
Estimativa do tempo de
viagem de ida e volta e de
esgotamento de
temporização
O TCP ut iliza um mecanismo de cont role de t emporização/ret ransmissão para recuperar
segment os perdidos. Em um prot ocolo real como o TCP, surgem problemas de
implement ação de um mecanismo de cont role de t emporização/ret ransmissão como por
exemplo, est imar o t empo de viagem de ida e volt a da conexão - RTT (a duração dos
int ervalos de cont role deve ser maior do que o RTT, evit ando o envio de ret ransmissões
desnecessárias).

Estimativa do tempo de viagem de

ida e volta - RTT(Round-Trip Time)
[6]

O RTT para um segment o, denominado RTTamostra, é a quant idade de t empo t ranscorrido

ent re o moment o em que o segment o é enviado (ist o é, passado ao IP) e o moment o em que
é recebido um reconheciment o para o segment o. Ao invés de medir um RTTamostra para
cada segment o t ransmit ido, a maioria das implement ações de TCP execut a apenas uma
medição de RTTamostra por vez. Ist o é, em qualquer inst ant e, o RTTamostra est ará sendo
est imado para apenas um dos segment os t ransmit idos mas ainda não reconhecidos, o que
result a em um novo valor de RTTamostra para aproximadament e cada RTT. E mais, o TCP
nunca comput a um RTTamostra para um segment o que foi ret ransmit ido; apenas mede-o
para segment os que foram t ransmit idos uma vez.
Os valores de RTTamostra sofrerão variação de segment o para segment o devido a
congest ionament o nos rot eadores e a variações de carga nos sist emas finais. Por causa
dessa variação, qualquer dado valor de RTTamostra pode ser at ípico. Port ant o, para est imar
um RTT t ípico, é nat ural t omar alguma espécie de média dos valores de RTTamostra. O TCP
mant ém uma média, denominada RTTestimado, dos valores de RTTamostra. Ao obt er um
novo RTTamostra, o TCP at ualiza RTTestimado de acordo com a seguint e fórmula:

RTTestimado = (1 - a) * RTTestimado + a * RTTamostra

Est a fórmula est á escrit a sob a forma de um comando de linguagem de programação. O valor
recomendado de a é a = 0,125 (ist o é, 1/8) [RFC 2988 ], caso em que essa fórmula de t orna:

RTTestimado = 0,875 * RTTestimado + 0,125 * RTTamostra

Onde RTTestimado é uma média ponderada dos valores de RTTamostra. Essa média
ponderada at ribui um peso maior às amost ras recent es do que às amost ras ant igas.

Observação: O valor de "a" det ermina o peso das amost ras mais recent es no cálculo da média,
por exemplo, se "a" vale 0,125, a últ ima amost ra analisada t erá peso de 12,5% no valor de
RTTestimado.

Além de t er uma est imat iva do RTT, t ambém é valioso t er uma medida de sua variabilidade. O
[RFC 2988 ] define a variação do RTT, RTTdesvio, como uma est imat iva do desvio t ípico
ent re RTTamostra e RTTestimado:

RTTdesvio = (1 - b) * RTTdesvio + b * | RTTamostra - RTTestimado |

Onde RTTdesvio é uma MMEP (Média Móvel Exponencial Pura) da diferença ent re
RTTamostra e RTTestimado. Se os valores de RTTamostra apresent arem pouca variação,
ent ão RTTdesvio será pequeno; por out ro lado, se houver muit a variação, RTTdesvio será
grande. O valor recomendado para b é 0,25.

Estabelecimento e gerenciamento
da temporização de retransmissão
Considerando-se dispor dos valores RTTestimado, RTTamostra e RTTdesvio, pode-se
est abelecer um valor para a t emporização de ret ransmissão do TCP (IntervaloTimeOut). Est e
valor deve ser maior ou igual a RTTestimado, caso cont rário seriam enviadas ret ransmissões
desnecessárias, porém não deve ser muit o maior pois se houver perda de algum segment o, o
TCP não o ret ransmit iria rapidament e, o que result aria em grandes at rasos de t ransferência de
dados. Dessa forma, é desejável que o valor est abelecido para a t emporização seja igual a
RTTestimado mais uma cert a margem, que deverá ser grande quando houver muit a variação
nos valores de RTTamostra e pequena quando houver pouca variação. Assim, o valor de
RTTdesvio deve ser considerado:

IntervaloTimeOut = RTTestimado + (4 * RTTdesvio)

Transferência confiável de
dados
Usa reconheciment os posit ivos, t emporizadores,números de seqüência e paralelismo

Recuperação de perdas de
segmentos
Retransmissão rápida

Ignora os ACKs duplicados

Ignora cont role de fluxo e de congest ionament o

RFC 2581 : Três ACKs duplicados ® ret ransmit e o segment o que Falt a

Reconheciment o cumulat ivo evit a a ret ransmissão do primeiro segment o

Controle de fluxo
Gerenciamento da conexão
TCP
A maior part e dos at aques à Web, at ualment e, exploram vulnerabilidades apresent adas no
gerenciamento das conexões TCP. Além disso, import ant e observar, que o
est abeleciment o da conexão TCP int erfere, significat ivament e, nos at rasos percebidos em
nossa navegação. Port ant o, saber como as conexões TCP são est abelecidas e finalizadas,
possibilit ando gerenciá-las, é bast ant e import ant e para garant ia da confiabilidade inerent e ao
prot ocolo TCP.

Para envio de pacot es ent re hospedeiros, via TCP, é necessário, previament e, o

est abeleciment o de uma conexão ent re client e e servidor. Para t ant o, são necessárias t rês
et apas, comument e chamada de apresentação de 3 vias (3 way handshake), conforme
det alhado abaixo.

Etapa 1: o lado cliente

do TCP encapsula e envia
ao
servidor, em um datagrama
IP, um segmento contendo
um bit de flag
SYN ativado em 1
(requisição de
estabelecimento de
conexão) e um
número de sequência
inicial escolhido
aleatoriamente pelo
próprio
cliente. Esse segmento é
chamado TCP SYN.

Etapa 2: o servidor, por

sua vez, ao receber
datagrama IP,
extrai o segmento TCP
SYN, aloca buffers e
variáveis para conexão
TCP e envia um segmento
de aceitação de conexão,
chamado SYNACK, contendo
um bit de flag SYN ainda
ativado em
1 e um ACK de
reconhecimento do número
de sequência inicial do
cliente, juntamente com a
informação de sequência
inicial do
servidor.

Etapa 3: por fim, o

cliente recebe o SYNACK,
reserva
buffers e variáveis para
a conexão TCP, enviando um
 segmento
contendo um ACK de
reconhecimento do número
de sequência inicial
do servidor, o próximo
número de sequência do
cliente e um bit de
flag SYN ajustado em zero
(conexão já estabelecida).

Pode acont ecer, ent ret ant o, sit uações em que o segment o TCP SYN recebido pelo
hospedeiro apresent a número de port a e/ou IP incompat íveis com as port as nele exist ent es.
Nest e caso, não há o reconheciment o do segment o TCP SYN e, ent ão, o hospedeiro
(servidor) ret orna ao client e um segment o cont endo um bit de sinalização RST, at ivado em 1,
para reenvio/reinicialização da conexão.

Se essas t rês et apas forem bem sucedidas, os dados podem ser enviados ent re um client e e
um servidor em hospedeiros diferent es. Quando não se deseja cont inuar enviando pacot es, a
conexão TCP pode ser finalizada pelo client e ou pelo servidor.

O encerrament o acont ece em 4 passos. Em suma, inicialment e o client e envia, ao servidor, um

segment o TCP FIN, com um bit de flag FIN ajust ado em 1, requisit ando a finalização da
conexão. O servidor recebe e envia, ao client e, um ACK de reconheciment o (et apa 2).
Post eriorment e, o servidor envia um segment o FIN, t ambém at ivado em 1, ao client e. Quando
o client e o recebe, responde com um ACK de reconheciment o e, ent ão, a conexão é
encerrada e os recursos (buffers e variáveis) alocados para a conexão TCP são liberados.
 Encerramento da conexão TCP

Referências

1. KUROSE,J. F.; ROSS,K. W. Redes de

Computadores e a Internet - Uma
abordagem top-down, 3ª Edição
2. http://pt.wikiversity.org/wiki/Introduç
ão_às_Redes_de_Computadores/Pro
tocolos_e_serviços_de_rede
3. TANENBAUM, A. S. Redes de
Computadores; 4ª edição
 4. http://pt.wikiversity.org/wiki/Introduç
ão_às_Redes_de_Computadores/Co
mutação_de_circuitos_e_de_pacote
s
5. KUROSE,J. F.; ROSS,K. W. Redes de
Computadores e a Internet - Uma
abordagem top-down, 3ª Edição
6. KUROSE,J. F.; ROSS,K. W. Redes de
Computadores e a Internet - Uma
abordagem top-down, 3ª Edição

Obtido em
"https://pt.wikibooks.org/w/index.php?
title=Redes_de_computadores/Protocolo_TCP&o
ldid=468273"
Esta página foi editada pela última vez às
18h18min de 15 de dezembro de 2020. •
Conteúdo disponibilizado nos termos da CC BY-
SA 4.0 , salvo indicação em contrário.