T/TCP: TCP para Transações

Luiz Cláudio S. Silva <lcss@bahianet.com.br>

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:

UDP
Bem simples, provê um serviço orientado a datagramas, sem estabelecimento de conexão e sem confiabilidade de entrega das informações. Aplicações basedas em UDP trabalham com trocas rápidas de informação, que mandam pequenas quantidades de dados e recebem de volta respostas curtas também. Por exemplo NFS, DNS, TFTP, BOOTP, SNMP.
TCP
Orientado à conexão, implementa um serviço de circuito virtual com entrega confiável e ordenada de dados. Aplicações baseadas em TCP necessitam da manutenção de um fluxo de dados confiável entre os pares. Telnet, FTP, Rlogin e SMTP são alguns exemplos.

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:

O cliente manda um datagrama de pedido para o servidor em 1/2 RTT (round trip time, tempo de ida e volta).
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):

Handshake de três transmissões (three-way handshake, 3WHS) para o estabelecimento de uma conexão;
Handshake de quatro transmissões (4WHS) para o fechamento de uma conexão;
Envio de mensagens de confirmação de recepção (acknowledgement, ACK);
Tempo de espera mínimo (time-wait) após cada conexão ser fechada para que ela possa ser reaberta.

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

A interação fundamental é um pedido seguido por uma resposta;
Uma fase explícita de abertura ou fechamento pode representar aumento excessivo no tempo necessário;
A semântica de "no máximo um" é requerida, ou seja, a transação não pode ser repetida como resultado de um segmento repetido de pedido;
A duração mínima da transação para o cliente deve ser RTT + SPT;
Em circunstâncias favoráveis, um handshake de pedido/resposta deve ser conseguido com exatamente um pacote em cada sentido.

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:

Utiliza as informações da conexão anterior para evitar o estabelecimento de conexão através do 3WHS;
Requer somente três segmentos para cada transação, por combinar SIN, FIN e dados no primeiro segmento e SIN, FIN, ACK e dados no segundo segmento;
Evita o fechamento de conexão através de 4WHS (o T/TCP não fecha as conexões e usa as antigas);
Reduz o tempo em estado de TIME_WAIT de 240 para 12 segundos e provê uma transação confiável em apenas RTT + SPT.

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

O TCP de uma máquina usa informação de cache sobre a última conexão estabelecida com determinada outra para validar imediatamente os novos segmentos SYN que recebe;
Se esta validação falhar, é feito o 3WHS normal. Assim, o T/TCP não elimina o 3WHS, mas procura usá-lo somente na primeira vez que uma conexão é estabelecida entre duas máquinas.
Para controlar as conexões da TAO, é utlizado um novo número de 32 bits, o CC (Connection Count, Contador de Conexão), que é incrementado a cada transação que a máquina faz com qualquer outra.

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:

O segmento era realmente uma duplicata;
Não havia ainda informação de cache para aquele determinada máquina;
O segmento SYN pode ser um de uma série de SYN quase simultâneos de diferentes conexões vindas da mesma máquina, os quais chegaram fora de ordem;
O espaço de numeração de 32 bits do CC foi todo utilizado e teve que ser recomeçado, entre uma conexão e outra, com o mesma máquina;
O valor do CC avançou muito vagarosamente para transações muito próximas.

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.