NewsGeneration: um serviço oferecido pela RNP desde 1997


ISSN 1518-5974
Boletim bimestral sobre tecnologia de redes
produzido e publicado pela  RNP – Rede Nacional de Ensino e Pesquisa
15 de janeiro de 1999 | volume 3, número 1

volta à página inicial de NewsGeneration

Nesta edição:

NewsGeneration:



T/TCP: TCP para Transações

Luiz Cláudio S. Silva <>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
Transações com UPD
Transações com TCP
Transações com TCP melhorado
O protocolo T/TCP
Conclusão
Referências bibliográficas

Muitas aplicações da Internet fazem uso de um tipo de comunicação onde pares de curtas mensagens são trocados entre um cliente e um servidor: são as transações. Como os protocolos de tranporte Internet existentes não são eficientes para este tipo de transferência, um novo foi proposto, o T/TCP.

^

Introdução

Toda a capacidade da Internet e de suas derivadas, Intranets e Extranets, está baseada na eficiência e integração do conjunto de protocolos TCP/IP. Este conjunto apresenta dois diferentes protocolos para execução de funções de transporte, ambos implementados sobre o protocolo de rede IP:

Quando os protocolos TCP/IP foram projetados, o uso das aplicações sobre redes de computadores visava, primordialmente, a cooperação entre máquinas de mesmo porte (mesma capacidade de processamento, memória primária, memória secundária, etc.) Contudo, o paradigma vem mudando para o das aplicações distribuídas, no qual os papéis do cliente e do servidor se especializam cada vez mais. Nesta nova realidade, têm dominado os protocolos de aplicação orientados a transação.

^

Transações com UPD

Uma transação que utiliza UDP é extremamente simples:

  1. O cliente manda um datagrama de pedido para o servidor em 1/2 RTT (round trip time, tempo de ida e volta).
  2. O servidor processa o pedido em SPT (server processing time, tempo de processamento do servidor) e devolve um datagrama de resposta em 1/2 RTT.


Figura 1 - Transação com UDP

O tempo total da transação é medido entre o momento em que o cliente manda um pedido e o em que ele recebe a resposta de volta do servidor. Assim, pelo que foi visto, o tempo total de uma transação, usando UDP, é RTT + SPT, e o número total de pacotes trocados é dois.

O tempo total (RTT + SPT) e o número de pacotes trocados (dois) são os menores valores possíveis para uma transação. São ideais, na verdade. Porém, o UDP tem muitas desvantagens que afetam o processamento de transações: por conta de sua não confiablidade, datagramas podem ser perdidos, reordenados ou duplicados, e ele ainda tem uma limitação na quantidade máxima de bytes por datagrama.

Portanto, cada aplicação baseada em UDP tem que implementar seu serviço confiável, controlando fragmentação, números seqüenciais, tempos de timeout, retransmissões, etc. Tudo isto causa repetição na implementação de diversas aplicações e consome tanto tempo e recursos quanto o próprio TCP. A vantagem aparente da maior leveza de implementação desaparece.

^

Transações com TCP

O TCP provê um serviço de transmissão de dados orientado à conexão, ordenado, confiável, em full-duplex. Mas, para garantir tudo isso, ele causa também um grande consumo de recursos (overhead):

Devido a estas caracterísitcas, aumentam o número de pacotes transmitidos, a necessidade de controle do fluxo e a necessidade de controle de conexão.


Figura 2 - Transação com TCP

Entre duas máquinas usando TCP podem haver diversas conexões simultâneas, as quais são difencenciadas pelos números de porta do cliente e do servidor. Para estabelecer uma conexão, o TCP usa o 3WHS para que possa definir os números seqüenciais iniciais e evitar que antigos segmentos SYN (de sincronização) duplicados possam estabelecer conexões incorretas.

Primeiro, o cliente manda um segmento SYN ao servidor, então o servidor manda seu segmento SYN com um ACK (confirmação) do SYN do cliente; finalmente, o cliente manda um segmento ACK do SYN do servidor. Toda esta troca dura RTT e o número de pacotes usados é três, e somente após o 3WHS é que qualquer dado recebido no primeiro segmento é repassado para a aplicação.

Já com a conexão estabelecida, o cliente manda um segmento com o pedido em 1/2 RTT, o servidor processa o pedido em SPT e manda de volta a resposta em 1/2 RTT.

Para encerrar a conexão, o TCP usa o 4WHS, que usa mais quatro segmentos. O cliente, após enviar seu pedido, envia um segmento FIN (finalização), indicando que não transmitirá mais dados. O servidor responde com um segmento ACK que confirma tanto o recebimento do pedido quanto o do segmento FIN; neste momento a conexão está semi-fechada (só no sentido cliente para servidor). O servidor, então, manda um segmento com a resposta e mais um segmento FIN, para finalizar a conexão no outro sentido. Finalmente, o cliente envia um segmento ACK para a chegada da resposta e do FIN do servidor. Agora, a conexão está fechada completamente.

Após um fechamento total de conexão, pedido por ele, o cliente ainda tem que permanecer no estado de TIME_WAIT, no qual a conexão não pode ser reaberta, pelo tempo de 2 MSL (Maximum Segment Life). Isto é para garantir que todos os segmentos duplicados antigos que estejam na rede expirem e que o último segmento ACK chegue ao servidor.

O tempo de 2 MSL corresponde a 240 segundos, o qual é muito longo para que uma conexão permaneça impedida; isto porque ele limita o número máximo de conexões a 64.512 (número de portas para o usuário, no TCP) divididas por 240 segundos (aproximadamente 268 conexões por segundo). Para aplicações com alta taxa de transações, isto é um fator limitante. Além disto, cada conexão em TIME_WAIT continua ocupando o mesmo espaço de memória de quando estava ativa.

Em resumo, o número total de segmentos para cada transação, usando TCP, é nove e esta leva um total de 2 RTT + SPT. Devido a todo seu overhead (3WHS, 4WHS e TIME_WAIT), o TCP também é uma solução ruim para as transações.

^

Transações com TCP melhorado

Para melhorar o desempenho do TCP, uma modificação pode ser feita: mandar o pedido no mesmo segmento de controle. No primeiro segmento do 3WHS, o pedido e o FIN são mandados junto com o SYN do cliente, e, no terceiro segmento, o FIN é mandado junto com o ACK do SYN do servidor, e assim sucessivamente, nos outros segmentos.


Figura 3 - Transação com TCP Melhorado

Apesar da diminuição de nove para cinco segmentos necessários, o tempo total continua o mesmo (2 RTT + SPT) por conta do 3WHS, que tem que ser feito para evitar segmentos antigos duplicados e para inicializar os números seqüenciais do SYN.

Na verdade, esta solução de combinar SIN e FIN num mesmo segmento foi considerada ainda quando da concepção do TCP, eram chamados de segmentos christmas tree (árvore de natal). Mas, devido à necessidade do mesmo tempo total, ela foi abandonada.

^

O protocolo T/TCP

Como tanto o UDP quanto o TCP, devido as suas implementações, não oferecem um serviço ideal para suporte a transações, um outro protocolo foi proposto [Braden92], o T/TCP, ou TCP for Transactions (TCP para Transações). A proposta do T/TCP partiu dos seguintes requisitos para uma comunicação orientada a conexão [Braden94]:

Na realidade, O T/TCP não é um protocolo novo e sim um conjunto de extensões ao protocolo TCP original, que visam a contornar os obstáculos que este apresenta. Assim, ele capaz de oferecer os dois serviços: o orientado a transação e o de circuito virtual. Dos requesitos apresentados, somente o último não é contemplado pelo T/TCP: sua transação mínima demanda três segmentos.

Para resolver os problemas que o TCP apresentava, o T/TCP:


Figura 4 - Transação com T/TCP


EVITANDO O 3WHS

Para evitar o 3WHS, o T/TCP introduz o novo mecanismo para validar segmentos SYN iniciais, ou seja, para garantir a semântica de "no máximo um" sem usar o 3WHS. Este mecanismo é chamado de TAO (TCP Accelerated Open, Abertura Acelerada do TCP):

Uma máquina que utiliza o T/TCP armazena o último valor do CC que recebeu de cada outra. Ao receber um novo segmento SYN, ela confere se o CC deste é maior que o último, caso no qual a conexão é válida. Este é o chamado Teste da TAO (TAO Test). O Teste pode falhar por diversos motivos:

REDUZINDO O TEMPO DE TIME_WAIT

O T/TCP reduz o tempo no estado de TIME_WAIT, após o fechamento de uma conexão de 2 MSL, 240 segundos, para 8 RTO (Retransmission Timeout, Tempo Expirado para Retransmissão).

O RTO não tem valor fixo, sendo determinado dinamicamente. Normalmente, as implementações do TCP utlizam um valor mínimo de 0,5 segundo [Braden92]. O multiplicador 8 é usado para garantir um fechamento confiável em ambos os sentidos, por permitir que cada máquina termine seu tempo de espera e retransmita o segmento final.

Mas, uma nova transação pode ser tentada ainda durante o estado TIME_WAIT. Quando isto ocorre, a conexão existente pode ser utlizada. Isto é possível graças ao valor armazenado do CC, que garante a proteção contra antigas duplicatas de uma antiga conexão.

IMPLEMENTAÇÃO DO T/TCP

O T/TCP é implementado pela adição de três novas opções no cabeçalho do TCP, que são utlizadas para validar segmentos e proteção contra duplicatas, sem necessidade de abertura com 3WHS ou fechamento com 4WHS. Todas elas se baseiam no conceito do CC.

Nome Descrição Número (Kind) Tam. (bytes)
CC A opção CC pode ser enviada num segmento SYN inicial ou em outros segmentos somente se a outra máquina mandar uma opção CC ou uma Ccnew, no SYN dela. 11 4
CCnew A opção Ccnew só pode aparecer num segmento SYN inicial. É mandada quando o cliente quer forçar um 3WHS para reinicializar as informações do T/TCP. 12 4
CCecho A opção CCecho só pode aparecer no segundo segmento de um 3WHS. Ela repete o valor da CC ou da Ccnew de um cliente e indica que o servidor suporta o T/TCP também. 13 4

Tabela 2. Novas Opções para o T/TCP

Além destas opções, o T/TCP requer que as informações sobre antigas conexões sejam mantidas. Elas o são em novas variáveis:

Abrangência Variável Conteúdo
Global tcp_gen Variável numérica inteira de 32 bits que contém o valor do próximo valor de CC a ser utlizado
Por Máquina Remota
(Cache da TAO)
tao_cc Último CC recebido da máquina em um segmento SYN válido
tao_ccsent Último CC enviado para a máquina em um segmento SYN
tao_mssopt Último MSS recebido da máquina
Por Conexão cc_send Valor de CC a ser enviado com todos os segmentos desta conexão
cc_recv Valor de CC a ser recebido da outra máquina em todos os segmentos desta conexão
t_duration Tempo de duração acumulado da conexão (em ciclos do clock interno)

Tabela 3. Novas Variáveis para o T/TCP

^

Conclusão

A idéia de um protocolo de transporte com suporte a serviço orientado a transação não é nova. Mas com o aumento do uso deste tipo de transferência na Internet, a diminuição de tráfego e de latência das transações ganha uma importância ainda maior.

Pelo que foi visto, o T/TCP realmente tem condições de ser este protocolo de transporte procurado, tanto por se basear no provado TCP, quanto pela relativa simplicidade que suas extensões exigem na implementação. Por enquanto, ele é só uma sugestão submetida ao IETF e tem sido implementado experimentalmente, fase na qual surgem as críticas e os melhoramentos. Mas as perspectivas futuras são as melhores.

^

Referências bibliográficas

[Braden92] Braden, R., RFC 1379. Extending TCP for Transactions - Concepts . 1992. University of South California, Information Sciences Institute. Disponível em http://www.cis.ohio-state.edu/htbin/rfc/rfc1379.html (06/jul/1998).
[Braden94] Braden, R., RFC 1644. T/TCP - TCP Extensions for Transactions - Functional Specification . 1994. University of South California, Information Sciences Institute. Disponível em http://www.cis.ohio-state.edu/htbin/rfc/rfc1644.html (06/jul/1998).
[TTCP01] Kohala Software. T/TCP Home Page (TCP for Transactions) . Online. Disponível em http://www.kohala.com/~rstevens/ttcp.html (06/jul/1998)
[TTCP02] University of Delaware, Department of Computer and Information Sciences. T/TCP: TCP for Transactions . Online. Disponível em http://www.cis.udel.edu/~sezen/sum.html (06/jul/1998)
[TTCP03] University of Delaware, Department of Computer and Information Sciences. Transaction T/TCP Examples . Online. Disponível em http://www.cis.udel.edu/~seetha/ttcp.htm (06/jul/1998)
[TTCP04] Universität Hannover, RVS. Simple Transactions using TCP . Online. Disponível em http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/ttcp.html (06/jul/1998)
[Zhang98] Zhang, C. X. (cxzhang@eecs.harvard.edu). "User Level Protocol Implementation of UDP and T/TCP". E-mail para Luiz Cláudio Santos Silva (lcss@bahianet.com.br). 01/jul/1998.

^


Sobre o Artigo:
Este artigo foi escrito por Luiz Cláudio Santos Silva como trabalho de conclusão da disciplina O Protocolo TCP/IP, do Curso de Pós-Graduação em Análise de Sistemas em Ambiente Internet da UNIFACS, em julho de 1998.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004