TCP (Tra­n­s­mi­s­sion Control Protocol): retrato del protocolo de tra­n­s­po­r­te

Cuando nos queremos conectar a Internet, solo ne­ce­si­ta­mos un par de maniobras para es­ta­ble­cer una conexión entre el rúter y el ordenador o el terminal móvil. No se requieren más pasos, ya que el inicio de sesión en red es au­to­má­ti­co, al igual que la asi­g­na­ción de una dirección in­di­vi­dual de Internet que necesitas para enviar y recibir datos. Todo ello es posible gracias a una serie de pro­to­co­los que también se conoce como familia de pro­to­co­los de Internet. En este contexto, uno de los miembros más im­po­r­ta­n­tes y antiguos es el protocolo de control de tra­n­s­mi­sión TCP, siglas de Tra­n­s­mi­s­sion Control Protocol, y sirve para de­te­r­mi­nar cómo los di­s­po­si­ti­vos reunidos en la red deben tra­n­s­mi­tir sus datos.

El protocolo TCP es un acuerdo es­ta­n­da­ri­za­do de tra­n­s­mi­sión de datos entre distintos pa­r­ti­ci­pa­n­tes de una red in­fo­r­má­ti­ca. La historia de este protocolo se remonta hasta el año 1973, cuando los in­fo­r­má­ti­cos Robert E. Kahn y Vinton G. Cerf pu­bli­ca­ron su primera versión en el marco de su trabajo de in­ve­s­ti­ga­ción. No obstante, tuvieron que pasar otros ocho años para que se es­ta­n­da­ri­za­ra con el documento RFC 793. Desde entonces, se ha ido su­ce­die­n­do una serie de mejoras y am­plia­cio­nes, aunque el núcleo del producto se mantiene sin cambios hasta hoy en día. La versión actual, publicada en el RFC 7323 es del año 2014.

El estado actual de de­sa­rro­llo del protocolo TCP permite es­ta­ble­cer una conexión entre dos puntos te­r­mi­na­les en una red in­fo­r­má­ti­ca común que po­si­bi­li­te un in­te­r­ca­m­bio mutuo de datos. En este proceso, cualquier pérdida de datos se detecta y resuelve, por lo que se considera un protocolo fiable. Dentro de la familia de pro­to­co­los de Internet, el TCP, junto con el UDP y el SCTP forma el grupo de los pro­to­co­los de tra­n­s­po­r­te, que, según el modelo OSI, se ubican en la capa de tra­n­s­po­r­te dentro de la ar­qui­te­c­tu­ra de red. Como el protocolo TCP se combina casi en todos los casos con el protocolo de Internet (IP) y esta conexión forma la base de la gran mayoría de redes locales y servicios de red, es común hablar del conjunto de pro­to­co­los TCP/IP, aunque en realidad se haga re­fe­re­n­cia a la familia de pro­to­co­los de Internet.

El protocolo de control de tra­n­s­mi­sión permite la tra­n­s­mi­sión de in­fo­r­ma­ción en ambas di­re­c­cio­nes. Por lo tanto, los sistemas in­fo­r­má­ti­cos que se comunican mediante TCP pueden enviar y recibir datos de forma si­mu­l­tá­nea, como si se tratase de una llamada te­le­fó­ni­ca. En este contexto, las unidades de tra­n­s­mi­sión básicas de las que echa mano el protocolo son segmentos (paquetes) que, aparte de los datos de uso, también pueden contener in­fo­r­ma­ción de control y están limitados a un tamaño de 1500 bytes. El es­ta­ble­ci­mie­n­to y la in­te­rru­p­ción de las co­ne­xio­nes, que se pueden catalogar como co­ne­xio­nes de terminal a terminal, así como la tra­n­s­mi­sión de datos en sí, la realiza el software TCP en la pila de pro­to­co­los de red del sistema operativo co­rre­s­po­n­die­n­te.

El software TCP se activa mediante distintas apli­ca­cio­nes de red, como los na­ve­ga­do­res de red o los se­r­vi­do­res, a través de in­te­r­fa­ces es­pe­cí­fi­cas. Cada conexión se debe ide­n­ti­fi­car siempre cla­ra­me­n­te mediante dos puntos te­r­mi­na­les definidos (cliente y servidor). En este contexto, qué lado desempeña el papel de cliente y cuál el de servidor es in­di­fe­re­n­te. Lo que importa es que el software TCP cuente con una pareja ordenada de dirección IP y puerto (también de­no­mi­na­da “2-tupla” o “socket”) en cada punto terminal.

Para que el es­ta­ble­ci­mie­n­to de una conexión TCP válida sea posible, ambos puntos te­r­mi­na­les deben contar con una dirección IP unívoca (IPv4 o IPv6) y deben haber declarado y ha­bi­li­ta­do el puerto deseado para la tra­n­s­mi­sión de datos. Mientras que la dirección IP funciona como ca­ra­c­te­rí­s­ti­ca de ide­n­ti­fi­ca­ción, el puerto sirve para que el sistema operativo pueda asignar las co­ne­xio­nes a las apli­ca­cio­nes de servidor y de cliente.

Como el es­ta­ble­ci­mie­n­to de la conexión mediante el Tra­n­s­mi­s­sion Control Protocol implica un total de tres pasos, se ha acuñado el nombre de “triple apretón de manos” para este proceso.

No obstante, para la parte que envía el último segmento ACK (en nuestro caso, el cliente), la conexión no se in­te­rru­m­pe in­me­dia­ta­me­n­te. Como no existe forma de ga­ra­n­ti­zar que el último paquete enviado ha llegado a su destino, el co­rre­s­po­n­die­n­te in­te­r­lo­cu­tor de co­mu­ni­ca­ción permanece en un modo de espera (también estado “Time-Wait”) hasta que hayan tra­n­s­cu­rri­do los tiempos de ejecución máximos del segmento ACK y de un posible nuevo segmento FIN (según RFC 793, 2 minutos en cada caso).

Como es costumbre en los pro­to­co­los, los datos más im­po­r­ta­n­tes, es decir, los datos que se necesitan para el es­ta­ble­ci­mie­n­to de la conexión y la tra­n­s­mi­sión de datos con el protocolo de control de tra­n­s­mi­sión se en­cue­n­tran en el en­ca­be­za­do de un paquete TCP. Estos datos de cabecera (también in­fo­r­ma­ción de control) están antes de la carga útil (Payload) y suelen tener un tamaño de 20 bytes (160 bits), seguidos de hasta 40 bytes (320 bits) de in­fo­r­ma­ción adicional que es opcional y que no se usa en todos los paquetes.

En este contexto, los distintos co­m­po­ne­n­tes o campos del en­ca­be­za­do del protocolo TCP tienen el siguiente si­g­ni­fi­ca­do:

Puerto de origen (16 bits): indica el número de puerto del emisor.

Puerto de destino (16 bits): indica el número de puerto del receptor.

Número de secuencia (32 bits): el número de secuencia indica el primer byte de los datos de uso anexos o se envía en el contexto del es­ta­ble­ci­mie­n­to o la in­te­rru­p­ción de la conexión. Sirve para la va­li­da­ción y cla­si­fi­ca­ción (después de la tra­n­s­mi­sión) de los segmentos.

Número de co­n­fi­r­ma­ción (32 bits): en este campo se indica el número de co­n­fi­r­ma­ción que espera el emisor en siguiente lugar. La condición para su validez es una etiqueta ACK (en el campo “Flags”).

Offset (4 bits): el campo “Offset” indica la longitud del en­ca­be­za­do en bloques de 32 bits para destacar el punto de inicio de los datos de uso. Dicho punto varía de segmento a segmento debido al campo variable de opciones.

Reservado (6 bits): según RFC 793, reservado para un uso futuro (sin uso hasta ahora). Este campo siempre debe tener un valor igual a “0”.

Flags (6 bits): mediante los 6 posibles bits in­di­vi­dua­les en el campo “Flags” se pueden activar distintas acciones TCP para organizar la co­mu­ni­ca­ción y el pro­ce­sa­mie­n­to de datos. Las flags, que se ajustan o no para estas ac­ti­va­cio­nes, son las si­guie­n­tes:

• URG. La etiqueta “Urgent” (en español, “urgente”) señaliza a la apli­ca­ción TCP que los datos de uso hasta el Urgent-Pointer (véase más abajo) fijado se deben procesar in­me­dia­ta­me­n­te.
• ACK. Junto con el número de co­n­fi­r­ma­ción, ACK sirve para confirmar la recepción de paquetes TCP. Si no se ha ajustado la etiqueta, el número de co­n­fi­r­ma­ción se convierte en inválido de forma au­to­má­ti­ca.
• PSH. “Push” sirve para facilitar un segmento TCP in­me­dia­ta­me­n­te sin tener que pasar por el buffer de datos del emisor y el receptor.
• RST. Si ha surgido un error durante la tra­n­s­mi­sión, la apli­ca­ción se puede re­s­ta­ble­cer mediante un paquete TCP con flag RST (“Reset”) ajustado.
• SYN. Los mensajes con una etiqueta SYN re­pre­se­n­tan el primer paso del triple apretón de manos, es decir, inician el es­ta­ble­ci­mie­n­to de conexión.
• FIN. “Finish” señaliza a la co­n­tra­par­te que uno de los in­te­r­lo­cu­to­res de la co­mu­ni­ca­ción ha fi­na­li­za­do la tra­n­s­mi­sión.

Tamaño de ventana (16 bits): en este campo se le transmite al in­te­r­lo­cu­tor de co­mu­ni­ca­ción el número de bytes que el emisor está dispuesto a recibir.

Suma de co­m­pro­ba­ción (16 bits): el protocolo es capaz de reconocer errores de tra­n­s­mi­sión de manera fiable. En este contexto, se usa la suma de co­m­pro­ba­ción, que se calcula a partir del en­ca­be­za­do, los datos de uso y el de­no­mi­na­do seu­doe­n­ca­be­za­do.

Urgent-Pointer (16 bits): el Urgent-Pointer (indicador “urgente”) indica la posición del primer byte después de los datos de uso que deben tratarse con carácter urgente. Por lo tanto, este campo solo es válido y relevante si tiene una etiqueta URG.

Opciones (0-320 bits): si se desea que se faciliten funciones TCP que no pe­r­te­ne­cen al en­ca­be­za­do general, esta tarea se realiza mediante el campo de opciones. Un ejemplo es la de­fi­ni­ción del tamaño máximo de segmento. La longitud de las opciones siempre debe ser un múltiplo de 32 bits, en caso contrario, hay que rellenar con bits cero (padding).

Antes de que se tra­n­s­mi­tan los primeros datos, el emisor y el receptor se ponen de acuerdo en cuanto al tamaño máximo de los segmentos que se van a enviar (Maximum Segment Size, MSS). Por defecto se permiten hasta 1500 bytes por segmento, de los que hay que tener en cuenta que 20 bytes son para el en­ca­be­za­do TCP y otros 20 bytes, para el en­ca­be­za­do IP, de manera que quedan 1460 bytes di­s­po­ni­bles para datos de uso. Si se desea un tamaño concreto, hay que es­pe­ci­fi­car­lo a través del campo de opciones, tal y como se ha explicado an­te­rio­r­me­n­te, por lo que hay que restar más capacidad a los bytes de­s­ti­na­dos para los datos de uso.

Si contamos con el tamaño máximo de segmento menos los en­ca­be­za­dos, esto significa que un paquete TCP no puede tra­n­s­mi­tir datos de un tamaño superior a 1,46 KB, o sea, 0,00146 MB. Para que el protocolo se pueda usar para enviar contenido web, como imágenes, que pueden ocupar varios cientos de kilobytes, se emplea la se­g­me­n­ta­ción, en la que los datos de apli­ca­ción se dividen en varios bloques de datos antes del tra­n­s­po­r­te, se numeran y se envían en un orden aleatorio. Como el receptor debe confirmar la recepción de cada uno de los segmentos y puede re­co­n­s­truir el orden real mediante los números de secuencia, no tiene ningún problema para re­co­m­po­ner todos los datos de uso recibidos después de la tra­n­s­mi­sión.

El protocolo TCP ya lleva un cuarto de siglo marcando la historia y el de­sa­rro­llo de las redes in­fo­r­má­ti­cas. Esto es debido, por un lado, a su buena co­m­pa­ti­bi­li­dad con el también histórico protocolo de Internet (IP) y, por el otro, gracias a las ca­ra­c­te­rí­s­ti­cas pri­n­ci­pa­l­me­n­te ve­n­ta­jo­sas que le di­fe­re­n­cian de al­te­r­na­ti­vas como el UDP o el SCTP. En este contexto, este es un resumen de las ca­ra­c­te­rí­s­ti­cas más im­po­r­ta­n­tes:

• El TCP está orientado a la conexión y permite una co­mu­ni­ca­ción recíproca entre dos puntos te­r­mi­na­les mediante el de­no­mi­na­do triple apretón de manos.
• Es fiable, ya que el protocolo garantiza que se tra­n­s­mi­ten todos los datos de forma íntegra y que el receptor pueda re­co­m­po­ne­r­los en el orden correcto.
• Envía los datos en segmentos in­di­vi­dua­les con un tamaño máximo de 1500 bytes (incluidos los en­ca­be­za­dos).
• En el modelo OSI, el TCP se clasifica en la capa de tra­n­s­po­r­te (capa 4).
• En la mayoría de los casos, el protocolo se suma al protocolo de Internet (IP), por lo que a menudo se habla del conjunto de pro­to­co­los TCP/IP.
• El en­ca­be­za­do TCP cuenta con un tamaño por defecto de 20 bytes y pueden llegar a sumarse hasta 40 bytes de opciones adi­cio­na­les.