TCP

O **TCP** (acrónimo para o inglés ***Transmission Control Protocol***) é un dos protocolos baixo os cales asenta o núcleo de Internet. A versatilidade e robustez deste protocolo fíxoo adecuado para redes globais, xa que verifica se os datos se envían de forma correcta, na secuencia apropiada e sen erros, pola rede.

O TCP é un protocolo do nivel da capa de transporte (capa 4) do Modelo OSI e sobre el asentan a maioría das aplicacións cibernéticas, como o SH, FTP, HTTP, e polo tanto, a *World Wide Web*.

## Características técnicas 
|}
As características fundamentais do TCP son:
* *Orientado á conexión*: a aplicación envía unha solicitude de conexión ao destino e usa a "conexión" para transferir datos.
* *Punto a punto*: unha conexión TCP é estabelecida entre dous puntos.
* *Confiabilidade*: O TCP usa varias técnicas para proporcionar unha entrega confiábel dos paquetes de datos, que é a gran vantaxe que ten en relación ao UDP, e motivo do seu uso extensivo nas redes de computadores. O TCP permite a recuperación de paquetes perdidos, duplicados, a recuperación de dados corruptos, e pode recuperar a ligazón en caso de problemas no sistema e na rede.
* *Full duplex*: é posíbel a transferencia simultánea en ambas direccións (cliente-servidor) durante toda a sesión.
* *Handshake*: mecanismo de estabelecemento e finalización de conexión en tres e catro tempos, respectivamente, o que permite a autenticación e peche dunha sesión completa. O TCP garante que, no final da conexión, todos os paquetes foron ben recibidos.
* *Entrega ordenada*: a aplicación fai a entrega ao TCP de bloques de datos cun tamaño arbitrario nun fluxo (ou *stream*) de datos, tipicamente en octetos. O TCP parte estes dados en segmentos de tamaño especificado polo valor MTU. Porén, a circulación dos paquetes ao longo da rede (utilizando un protocolo de encamiñamento, na capa inferior, como o IP) pode facer que os paquetes non cheguen ordenados. O TCP garante a reconstrución do *stream* no destinatario mediante os *números de secuencia*.
* *Control de fluxo*: o TCP usa o campo fiestra ou *window* para controlar o fluxo. O receptor, á medida que recibe os datos, envía ACK, que pode especificar o tamaño do *buffer* no campo (fiestra) do segmento TCP, en que determina a cantidade de bytes que o lado transmisor do ACK pode recibir. O transmisor pode transmitir segmentos cun número de bytes que deberá estar confirmado cun tamaño de fiestra permitido.

## Descrición do funcionamento 
miniatura|210px|Fig. 1 - Neste exemplo considérase o *backlog* preenchido para forzar o *timeout* no cliente para que o paquete SYN sexa reenviado. Porén, o primeiro paquete podía terse perdido debido a erros na rede.
O protocolo TCP especifica tres fases durante unha conexión: estabelecemento da ligazón, transferencia e finalización da ligazón. O estabelecemento da ligazón faise en tres pasos, en tanto que a finalización se fai en catro. Durante o estabelecemento inicialízanse algúns parámetros, como o *Sequence Number* (número de secuencia) para garantir a entrega ordenada e robustez durante a transferencia.

### Estabelecemento da ligazón 
Tipicamente, nunha ligazón TCP existe aquel designado de servidor (que abre un socket e espera pasivamente por ligazóns), nun extremo, e o cliente no outro. O cliente inicia a ligazón enviando un paquete TCP coa *flag* SYN activa e espera que o servidor acepte a ligazón enviando un paquete SYN+ACK. Se, durante un determinado espazo de tempo, ese paquete non for recibido ocorre un *timeout* e reenvíase o paquete SYN. O estabelecemento da ligazón é concluído por parte do cliente, confirmando a aceptación do servidor, que responde cun paquete ACK.

Durante estes intercambios, envíanse números de secuencia iniciais (*ISN*) entre os interlocutores que van servir para identificar os datos ao longo do fluxo, así como de contador de bytes transmitidos durante a fase de transferencia de datos (sesión).

No final desta fase, o servidor inscribe o cliente como unha ligazón estabelecida nunha táboa propia que contén un límite de conexións, o *backlog*. No caso de que o *backlog* estea cheo, a ligazón rexéitase ignorando (silenciosamente) todos os subsecuentes paquetes SYN.

### Transferencia de datos (sesión) 
Durante a fase de transferencia o TCP está equipado con varios mecanismos que aseguran a fiabilidade e robustez: números de secuencia que garanten a entrega ordenada, código detector de erros (*checksum*) para detección de fallos en segmentos específicos, confirmación de recepción e temporizadores que permiten o axuste e contorno de eventuais atrasos e perdas de segmentos.

Como se pode observar, existen permanentemente un par de números de secuencia, de agora en diante referidos como *número de secuencia* e *número de confirmación* (*ACKnoledg*). O emisor determina o seu propio número de secuencia e o receptor confirma o segmento usando como número ACK o número de secuencia do emisor. Para manter a fiabilidade, o receptor confirma os segmentos indicando que recibiu un determinado número de bytes contiguos. Unha das melloras introducidas no TCP foi a posibilidade de que o receptor poida confirmar a recepción de bloques fóra da orde esperada. Esta característica designase por *selective ACK*, ou simplemente SACK.

A reensamblaxe ordenada dos segmentos faise usando os números de secuencia, de 32 bit, que reinician a cero cando superan o valor máximo, 231-1, tomando o valor da diferenza. Así, a escolla do ISN tórnase vital para a robustez deste protocolo.

O campo *checksum* permite asegurar a integridade do segmento. Este campo exprésase en complemento para un consistindo na suma dos valores (en *complemento para un*) da trama. A escolla da operación de suma en complemento para un débese ao feito de que esta pode calcularse da mesma forma para múltiplos dese lonxitude - 16 bit, 32 bit, 64 bit etc - e o resultado, encapsulado, será o mesmo. A verificación deste campo por parte do receptor faise coa recomputación da suma en complemento para un que dará -0 caso o paquete teña sido recibido intacto.

Esta técnica (*checksum*), aínda que moi inferior a outros métodos detectores, como o CRC, é parcialmente compensada coa aplicación do CRC ou outras probas de integridade mellores ao nivel da capa 2, logo abaixo do TCP, como no caso do PPP e Ethernet. Con todo, isto non fai este campo redundante: en efecto, estudos de tráfico revelan que a introdución de erro é bastante frecuente entre *hops* protexidos por CRC e que este campo detecta a maioría deses erros.

As confirmacións de recepción (ACK) serven tamén ao emisor para determinar as condicións da rede. Dotados de temporizadores, tanto os emisores como os receptores poden alterar o fluxo dos datos, todear eventuais problemas de conxestión e, nalgúns casos, previr a conxestión da rede. O protocolo está dotado de mecanismos para obter un aproveitamento máximo da rede sen a conxestionar — o envío de tramas por un emisor máis rápido que calquera dos intermediarios (*hops*) ou mesmo do receptor pode inutilizar a rede. Son exemplos a fiestra deslizante, o algoritmo de inicio-lento

### Adecuación de parámetros 
miniatura|esquerda|210px|Neste simple exemplo só está a considerarse a fiestra do servidor. O cliente ten a percepción do estado da fiestra do servidor a cada ACK recibido.
O cabezallo TCP posúe un parámetro que permite indicar o espazo libre actual do receptor (emisor cando envía a indicación): a *fiestra* (ou *window*). Así, o emisor sabe que só poderá ter en tránsito aquela cantidade de información ata esperar pola confirmación (ACK) dun dos paquetes, que á súa vez traerá, con certeza, unha actualización da *fiestra*. Curiosamente, TCP no Windows foi concibida para se autoaxustar na maioría dos ambientes e, nas versións actuais, o valor patrón é superior en comparación con versións máis antigas.

Porén, debido ao tamaño do campo, que non pode ser expandido, os límites *aparentes* da fiestra varían entre 2 e 65535, o que é bastante pouco en redes de alto débito e hardware de alto rendemento. Para superar esa limitación úsase unha *opción* especial que permite obter múltiplos do valor da fiestra, chamado *escala da fiestra*, ou *TCP window scale*; este valor indica cantas veces o valor da fiestra, de 16 bit, debe operarse por movemento de bits (para a esquerda) para obter os múltiplos, podendo variar entre 0 e 14. Así, tórnase posíbel obter fiestras de 1 xigabyte. O parámetro de escala defínese unicamente durante o estabelecemento da ligazón.

### Termo da ligazón 
miniatura|210px|Termo de conexión.
A fase de finalización da sesión TCP é un proceso de catro fases, no que cada interlocutor responsabilízase da finalización do seu lado da ligazón. Cando un deles pretende finalizar a sesión, envía un paquete coa *flag* FIN activa, e espera recibir unha resposta ACK. Á súa vez, o outro interlocutor procederá da mesma forma, enviando un FIN que deberá ser respondido cun ACK.

Pode ocorrer, no entanto, que un dos lados non conclúa a sesión. Chámase a este tipo de evento conexión *semi-aberta*. O lado que non concluíu a sesión poderá continuar enviando información pola conexión, mais o outro lado non.

## Portos ou servizos 
O TCP introduce o concepto de *porto* tipicamente asociado a un servizo (capa aplicación)/ligazón específica. Así, cada un dos intervenientes na conexión dispón dun porto asociado (un valor de 16 bit) que dificilmente será o mesmo do interlocutor. Algúns servizos (que fan uso de protocolos específicos) son tipicamente accesíbeis en portos fixos, coñecidos como portos ben coñecidos, que son aqueles numerados do 1 ao 1023. Alén destes, existen aínda dúas gamas de portos, *rexistrados* e *privados* ou dinámicos. Os *portos ben coñecidos* son atribuídos pola Internet Assigned Numbers Authority (IANA) e son tipicamente utilizados por procesos con dereitos de sistema ou superusuario. Nestes portos atópanse en escoita pasiva os servizos triviais, como HTTP, SH, FTP etc. Todos os protocolos da suite IP se atopan rexistrados dentro desta gama.

A gama de portos privados segue regras de atribución específicas do sistema operativo e serve para abrir ligazóns a outras máquinas, como *navegar na rede*, por exemplo.

## Implementacións 
## Utilización do IP para entrega de datos 
O TCP, como o UDP, usa o protocolo IP para a entrega dos datagramas á rede, e os puntos de acceso á aplicación identifícanse por portas accedidas por *multiplexing*, tal como acontece co UDP, o que permite múltiplas ligazóns en cada host. As portas poden asociarse cunha aplicación (Proceso).

O IP trata o paquete TCP como datos e non interpreta ningún contido da mensaxe do TCP, sendo que os dados TCP viaxan pola rede en datagramas IP. Os routers que interligan as redes só verifican o cabezallo IP, cando fan o envío dos datagramas. O TCP no destino interpreta as mensaxe do protocolo TCP.

## Véxase tamén 
### Outros artigos
* bic-tcp
* Lista de protocolos de redes
* Implementacións do TCP

### Ligazóns externas 
* RFC 793