INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MÉCANICA

Y ELÉCTRICA
UNIDAD ZACATENCO
INGENIERÍA EN COMUNICACIONES Y
ELÉCTRONICA

AGUILAR JAIME MARCO AXEL

8CM2
REDES DE ÁREA AMPLIA
DELGADO PÉREZ JULIO

“PROTOCOLO TCP (TRANSMITION CONTROL

PROTOCOL)”
El "protocolo de control de transmisión" ('Transmission Control Protocol', TCP) está
pensado para ser utilizado como un protocolo 'host' a 'host' muy fiable entre miembros de
redes de comunicación de computadoras por intercambio de paquetes y en un sistema
interconectado de tales redes.
Los sistemas de comunicación entre computadoras están jugando un papel cada vez más
importante en entornos militares, gubernamentales y civiles.
TCP es un protocolo orientado a la conexión, fiable y entre dos extremos, diseñado para
encajar en una jerarquía en capas de protocolos que soportan aplicaciones sobre múltiples
redes. TCP proporciona mecanismos para la comunicación fiable entre pares de procesos
en computadoras 'host' ancladas en redes de comunicación de computadoras distintas, pero
interconectadas. Se hacen muy pocas suposiciones sobre la fiabilidad de los protocolos de
comunicación por debajo de la capa de TCP. TCP sólo supone que puede acceder a un
servicio de transmisión de datagramas simple, aunque en principio poco fiable, de los
protocolos del nivel inferior. En principio, TCP debería ser capaz de operar encima de un
amplio espectro de sistemas de comunicaciones que incluye desde conexiones por cables
fijos ('hard-wired conections') hasta redes de intercambio de paquetes o redes de circuitos
conmutados.
TCP presenta interfaz por un lado con el usuario o los procesos de aplicación y por el otro
con un protocolo de más bajo nivel como es el protocolo de internet (IP).
Para proporcionar este servicio encima de un entorno de internet menos fiable, el sistema
de comunicación requiere de mecanismos relacionados con las siguientes áreas:
 Transferencia básica de datos
 Fiabilidad
 Control de flujo
 Multiplexamiento
 Conexiones
 Prioridad y seguridad
A continuación, se describe cada uno de los mecanismos antes mencionados

Transferencia básica de datos:

TCP es capaz de transferir un flujo continuo de octetos en cada sentido entre sus usuarios
empaquetando un cierto número de octetos en segmentos para su transmisión a través del
sistema de internet. En general, los módulos de TCP deciden cuándo bloquear y enviar
datos según su propia conveniencia.
Fiabilidad:
El módulo de TCP debe poder recuperar los datos que se corrompan, pierdan, dupliquen o
se entreguen desordenados por el sistema de comunicación del entorno de internet. Esto se
consigue asignando un número de secuencia a cada octeto transmitido, y exigiendo un
acuse de recibo (ACK, N.T.:del inglés 'acknowledgment') del módulo de TCP receptor. Si
no se recibe un ACK dentro de un cierto plazo de expiración prefijado, los datos se
retransmiten. En el receptor, se utilizan los números de secuencia para ordenar
correctamente los segmentos que puedan haber llegado desordenados y para eliminar los
duplicados. La corrupción de datos se trata añadiendo un campo de suma de control
('checksum') a cada segmento transmitido, comprobándose en el receptor y descartando los
segmentos dañados.

Flujo de control:
TCP proporciona al receptor un medio para controlar la cantidad de datos enviados por el
emisor. Esto se consigue devolviendo una "ventana" con cada ACK, indicando el rango de
números de secuencia aceptables más allá del último segmento recibido con éxito. La
ventana indica el número de octetos que se permite que el emisor transmita antes de que
reciba el siguiente permiso.

Multiplexamiento:
Para permitir que muchos procesos dentro de un único 'host' utilicen simultáneamente las
posibilidades de comunicación de TCP, el módulo de TCP proporciona una serie de
direcciones o puertos dentro de cada 'host'. Concatenadas con las direcciones de red y de
'host' de la capa de comunicación internet conforman lo que se denomina una dirección de
conector ('socket'). Un par de direcciones de conector identifica de forma única la
conexión. Es decir, un conector puede utilizarse simultáneamente en múltiples conexiones.

Conexiones:
La fiabilidad y los mecanismos de control de flujo descritos más arriba exigen que los
módulos de TCP inicialicen y mantengan una información de estado para cada flujo de
datos. La combinación de esta información, incluyendo las direcciones de los conectores,
los números de secuencia y los tamaños de las ventanas, se denomina una conexión. Cada
conexión queda especificada de forma única por un par de conectores que corresponden
con sus dos extremos.
Cuando dos procesos desean comunicarse, sus módulos de TCP deben establecer primero
una conexión (inicializar la información de estado en cada lado). Cuando la comunicación
se ha completado, la conexión se termina o cierra con la intención de liberar recursos para
otros usos.
Como las conexiones tienen que establecerse entre 'hosts' no fiables y sobre un sistema de
comunicación internet no fiable, se utiliza un mecanismo de acuerdo que usa números de
secuencia basados en tiempos de reloj para evitar una inicialización errónea de las
conexiones.

Prioridad y seguridad:
Los usuarios de TCP pueden indicar el nivel de seguridad y prioridad de su comunicación.
Se emplean valores por defecto cuando estas características no se necesiten.

FILOSOFIA DEL PROTOCOLO TCP

Elementos del sistema de inter-redes.
El entorno de inter-redes consiste en una serie de 'hosts' conectados a varias redes que a su
vez están interconectadas vía pasarelas ('gateways'). Aquí se supone que las redes pueden
ser tanto redes locales (i.e. de tipo de ETHERNET) como grandes redes (i.e. ARPANET),
pero en cualquier caso basadas en tecnología de intercambio de paquetes. Los agentes
activos que producen y consumen los mensajes son los procesos. Varios niveles de
protocolos en las redes, las pasarelas y 'hosts' dan soporte a un sistema de comunicación
entre procesos que proporciona un flujo de datos bidireccional sobre conexiones lógicas
entre los puertos de los procesos.
El término paquete o trama se utiliza generalmente aquí para significar el conjunto de datos
de una transacción entre un 'host' y su red. El formato de bloques de datos intercambiados
dentro de una red, en general, no nos importará aquí.
Los 'hosts' son computadoras unidas a una red, y, desde el punto de vista de la
comunicación en la red, constituyen los orígenes y destinos de los paquetes. Los procesos
han de verse como los elementos activos en los computadores anfitriones (de acuerdo con
la definición bastante común de un proceso como un programa en ejecución). Incluso los
terminales y ficheros u otros dispositivos de E/S son vistos como comunicándose unos con
otros a través del uso de procesos. Así, toda comunicación puede verse como una
comunicación entre procesos.
Ya que un proceso puede necesitar distinguir entre varios flujos de comunicación entre él
mismo y otro proceso (o procesos), se supone que un proceso puede tener un cierto número
de puertos a través de los cuales se comunica con los puertos de otros procesos.
Modelo de operación
Los procesos transmiten datos llamando al módulo de TCP y pasando búferes de datos
como argumentos de la llamada. El módulo de TCP empaqueta en segmentos los datos
provenientes de estos búferes y efectúa una llamada al módulo de internet para que
transmita cada segmento al módulo de TCP de destino. El TCP receptor coloca los datos
de un segmento en el búfer de recepción del usuario y lo notifica al usuario receptor. Los
módulos de TCP incluyen información de control en los segmentos que puede ser utilizada
para asegurar una transmisión fiable y ordenada de datos.
El modelo de comunicación del protocolo de internet es de tal forma que hay un módulo del
protocolo internet asociado con cada módulo de TCP y que, a su vez, proporciona una
interfaz con la red local. Este módulo de internet empaqueta los segmentos de TCP dentro
de los datagramas de internet y encamina estos datagramas hacia un módulo de internet de
destino por una pasarela intermedia. Para poder transmitir el datagrama a través de la red
local, se encapsula dentro de un paquete de red local.
En una pasarela entre redes, el datagrama de internet es "desenvuelto" a partir del paquete
de red local y examinado para determinar a través de qué red debería el datagrama viajar a
continuación. El datagrama de internet es entonces "envuelto" otra vez por un paquete de
red apropiado, envíado a la red siguiente y encaminado hacia la siguiente pasarela, o hacia
el destino final.
Se permite que una pasarela divida un datagrama de internet en fragmentos de datagrama
más pequeños, si esto es necesario para la transmisión a través de la siguiente red. Para
hacer esto, la pasarela produce un conjunto de datagramas de internet; cada uno de ellos
transportando un fragmento. Los fragmentos pueden ser subdivididos a su vez en ulteriores
pasarelas. El formato de fragmento de datagrama de internet se ha diseñado de tal forma
que el módulo de internet de destino puede reensamblar los fragmentos en datagramas de
internet.
El módulo de internet de destino desenvuelve el segmento del datagrama (después de haber
reensamblado el datagrama, si así era necesario) y lo pasa al módulo de TCP de destino.
El entorno del 'host'
Se supone que el módulo de TCP lo es del sistema operativo. Los usuarios accederán a
dicho módulo de una forma muy similar a como acceden al sistema de archivos. El módulo
de TCP, a su vez, puede llamar a otras funciones del sistema operativo, por ejemplo, para
gestionar las estructuras de datos. Se supone que la interfaz real final con la red se controla
mediante un módulo manejador del dispositivo ('device driver') de red. El módulo de TCP
no llama directamente al manejador, sino que efectúa llamadas al módulo del protocolo de
datagramas de internet que en su lugar llama al manejador del dispositivo de red.
Los mecanismos de TCP no impiden la implementación de TCP en un procesador
intermediario ('front-end'). Sin embargo, en una implementación de este tipo, un protocolo
de 'host' a 'front-end' debe proporcionar la funcionalidad necesaria para soportar el tipo de
interfaz TCP-usuario.

Interfaces
La interfaz TCP/usuario proporciona al usuario funciones de llamada al módulo de TCP
para abrir (OPEN) o cerrar (CLOSE) una conexión, para enviar (SEND) o recibir
(RECEIVE) datos, o para obtener información de estado (STATUS) sobre una conexión.
Estas llamadas son del mismo tipo que otras llamadas al sistema operativo realizadas desde
programas de usuario como, por ejemplo, las llamadas para abrir, leer y cerrar un fichero.
La interfaz TCP/internet proporciona llamadas para enviar y recibir datagramas
direccionados a los módulos TCP en cualquier 'host' del sistema de internet. Estas llamadas
tienen parámetros para pasar la dirección, el tipo de servicio, la prioridad y otra
información de control.
Relación con otros protocolos
El siguiente diagrama ilustra el lugar de TCP en la jerarquía de protocolos:

RELACIÓN ENTRE PROTOCOLOS

Se espera que TCP sea capaz de soportar protocolos de nivel superior eficientemente.
Debería ser fácil implementar la interfaz de TCP con los protocolos de nivel superior como
Telnet de ARPANET o AUTODIN II THP.

Comunicación fiable
Un flujo de datos enviado sobre una conexión de TCP se entrega de forma fiable y
ordenada al destino.
La transmisión es fiable gracias al uso de números de secuencia y de acuses de recibo.
Básicamente, se le asigna un número de secuencia a cada octeto de datos. El número de
secuencia del primer octeto de datos en un segmento se transmite con ese segmento y se le
denomina el número de secuencia del segmento. Los segmentos también llevan un número
de acuse de recibo que es el número de secuencia del siguiente octeto de datos esperado en
la transmisión en el sentido inverso. Cuando el módulo de TCP transmite un segmento
conteniendo datos, pone una copia en una cola de retransmisión e inicia un contador de
tiempo; si llega el acuse de recibo para esos de datos, el segmento se borra de la cola. Si no
se recibe el acuse de recibo dentro de un plazo de expiración, el segmento se retransmite.
La llegada del acuse de recibo no garantiza que los datos ya hayan sido entregados al
usuario final, sino únicamente que el TCP receptor ha asumido la responsabilidad de
hacerlo.
Para controlar el flujo de datos entre los módulos de TCP, se utiliza un mecanismo de flujo
de control. El TCP receptor devuelve una "ventana" al TCP emisor. Esta ventana
especifica el número de octetos, a contar a partir del número del acuse de recibo, que el
TCP receptor está en ese momento preparado para recibir.

Establecimiento y finalización de la conexión

Para identificar los distintos flujos de datos que un módulo TCP puede manejar
simultáneamente, TCP proporciona un identificador de puerto. Como los identificadores de
puertos son seleccionados de forma independiente por cada TCP, puede que no sean únicos.
Para disponer de direcciones únicas dentro de cada TCP, se concatena la dirección de
internet que identifica al módulo de TCP con el identificador de puerto para así conformar
una dirección de conector ('socket') que será única a largo de todo el conjunto de redes
interconectadas.
Una conexión queda completamente especificada por el par de conectores de sus extremos.
Un conector local puede participar en muchas conexiones con diferentes conectores
foráneos. Una conexión puede ser utilizada para transportar datos en los dos sentidos, es
decir, es bidireccional ('full duplex').
Una conexión se especifica en la llamada de apertura OPEN con los argumentos de un
puerto local y una dirección de conector remoto. como respuesta, el módulo de TCP
proporciona un nombre local (corto) a la conexión con la que el usuario puede referirse a la
conexión en subsiguientes llamadas. Hay varias cosas que deben recordarse acerca de una
conexión. Para guardar esta información podemos imaginar que existe una estructura
llamada "Bloque de control de transmisión" (TCB, 'Transmission Control Block'). Una
estrategia para su implementación tendría el nombre local de la conexión como un puntero
al TCB de esta conexión. La llamada OPEN también especifica si se persigue de forma
activa el establecimiento de la conexión o si se espera de forma pasiva.
El uso de conectores públicos ('well-known') constituye un mecanismo conveniente para la
asociación a priori de direcciones de conectores con un servicio estándar.
Los procesos pueden ejecutar OPEN pasivos y esperar a otros OPEN activos que
concuerden y provengan de otros procesos, siendo entonces informados por el módulo de
TCP cuando las conexiones se hayan finalmente establecido. Dos procesos que se dirigen
OPEN activos entre sí al mismo tiempo serán conectados correctamente. Esta flexibilidad
es crítica para dar soporte a la computación distribuída en la que los componentes pueden
actuar asíncronamente unos con respecto a otros.
Hay dos casos principales para la concordancia de conectores entre OPEN pasivos locales y
OPEN activos remotos. En el primer caso, un OPEN pasivo local ha especificado
completamente el conector remoto. En este caso, la concordancia debe ser exacta. En el
segundo caso, los OPEN pasivos locales han dejado el conector remoto sin especificar. En
este caso, cualquier conector remoto es aceptable en tanto en cuanto los conectores locales
concuerden. Otras posibilidades incluirían concordancias parcialmente restringidas.
Los procedimientos para establecer conexiones utilizan el indicador de control de
sincronización (SYN) e involucran un intercambio de tres mensajes. Se ha denominado a
este intercambio como el acuerdo en tres pasos ('three-way handshake').
Una conexión se inicia ante la coincidencia de un segmento entrante que contiene un SYN
y una entrada de TCB en espera previa, habiendo sido ambos creados por un comando de
usuario OPEN. La concordancia de conectores locales y remotos determina cuándo una
conexión ha sido iniciada. La conexión queda "establecida" cuando los números de
secuencia quedan sincronizados en ambos sentidos.
La finalización de una conexión también involucra el intercambio de segmentos, en este
caso transportando un indicador de control FIN.

Comunicación de datos
Puede pensarse en los datos que fluyen en una conexión como en un flujo de octetos. El
usuario emisor indica en cada llamada SEND mediante la puesta a uno del indicador PUSH
si los datos de esa llamada (y de cualquier llamada precedente) deben ser entregados
inmediatamente al usuario receptor.
Se permite a un TCP emisor recolectar datos del usuario emisor y enviar esos datos en
segmentos según propia conveniencia, siempre y cuando no se invoque la función 'push', en
ese caso, el TCP emisor debe enviar todos los datos pendientes. Cuando el TCP receptor ve
el indicador PUSH, no debe esperar más datos del TCP receptor antes de pasar los datos al
proceso receptor.
No hay, necesariamente, una relación entre el uso de funciones 'push' y el tamaño de los
segmentos. Los datos de cualquier segmento en particular pueden ser el resultado, total o
parcial, de una llamada SEND única, o de múltiples llamadas SEND.
El propósito de la función 'push' y del indicador PUSH consiste exclusivamente en
transportar inmediatamente los datos desde el usuario emisor al usuario receptor. No
proporciona en ningún caso un servicio de registro.
TCP también proporciona un mecanismo para comunicar al receptor de los datos que en
algún punto más adelante en el flujo de datos que está actualmente leyendo habrá datos
urgentes. TCP no intenta definir lo que el usuario debe hacer en concreto cuando se le
notifica la existencia de datos urgentes pendientes, sólo da la noción general de que el
proceso receptor tendrá que tomar medidas para procesar los datos urgentes de forma
rápida.

Prioridad y seguridad
TCP hace uso del campo de tipo de servicio del protocolo de internet y de la opción de
seguridad para proporcionar prioridad y seguridad a los usuarios de TCP, tomando como
base cada conexión. No todos los módulos de TCP trabajarán necesariamente en un entorno
de seguridad multinivel; algunos puede que estén limitados a usos reservados solamente, y
otros puede que operen en un único nivel de seguridad y compartimentación.
Consecuentemente, algunas implementaciones y servicios de TCP para usuarios puede que
estén limitados a un subconjunto del caso con seguridad multinivel.
Los módulos de TCP que operen en un entorno con seguridad multinivel deben marcan
apropiadamente los segmentos salientes con los niveles de seguridad, compartimentación y
prioridad. Estos módulos TCP deben también proporcionar a sus usuarios o a los
protocolos de más alto nivel como Telnet o THP una interfaz que les permita especificar el
grado de seguridad, compartimentación y prioridad de las conexiones.

Principio de robustez
Las implementaciones de TCP seguirán un principio general de robustez: sé conservador en
lo que hagas, sé liberal en lo que aceptes de los demás.

ESPECIFICACIÓN FUNCIONAL
Formato de la cabecera
Los segmentos de TCP se envían como datagramas de internet. La cabecera del protocolo
de internet transporta varios campos de información, entre los que se incluyen las
direcciones de los 'host' de origen y de destino. Una cabecera de TCP sigue a la cabecera de
internet, aportando información específica del protocolo de TCP. Esta división permite la
existencia de otros protocolos de la capa de 'host' distintos de TCP.
Formato de la cabecera de TCP

 Puerto de origen: 16 bits

El número del puerto de origen.
 Puerto de destino: 16 bits
El número del puerto de destino.
 Número de secuencia: 32 bits
El número de secuencia del primer octeto de datos de este segmento (excepto cuando el
indicador SYN esté puesto a uno). Si SYN está puesto a uno es el número de secuencia
original (ISN: 'initial sequence number') y, entonces, el primer octeto de datos es ISN+1.
 Número de acuse de recibo: 32 bits
Si el bit de control ACK está puesto a uno, este campo contiene el valor del siguiente
número de secuencia que el emisor del segmento espera recibir. Una vez que una conexión
queda establecida, este número se envía siempre.
 HLEN: 4 bits
El número de palabras de 32 bits que ocupa la cabecera de TCP. Este número indica dónde
comienzan los datos. La cabecera de TCP (incluso una que lleve opciones) es siempre un
número entero de palabras de 32 bits.
 Reservado: 6 bits
Reservado para uso futuro. Debe valer 0.
 Bits de código: 6 bits (de izquierda a derecha):
 URG: Hace significativo el campo "Puntero urgente"
 ACK: Hace significativo el campo "Número de acuse de recibo"
 PSH: Función de "Entregar datos inmediatamente" ('push')
 RST: Reiniciar ('Reset') la conexión
 SYN: Sincronizar ('Synchronize') los números de secuencia
 FIN: Últimos datos del emisor
 Ventana: 16 bits
El número de octetos de datos, a contar a partir del número indicado en el campo de
"Número de acuse de recibo", que el emisor de este segmento está dispuesto a aceptar.
 Suma de verificación: 16 bits
El campo "Suma de control" es el complemento a uno de 16 bits de la suma de los
complementos a uno de todas las palabras de 16 bits de la cabecera y del texto. Si un
segmento contiene un número impar de octetos de cabecera y texto, el último octeto se
rellena con ceros a la derecha para formar una palabra de 16 bits con el propósito de
calcular la suma de control. En el cálculo de la suma de control, el propio campo suma de
control se considera formado por ceros.
La suma de control también incluye una pseudocabecera de 96 bits prefijada
imaginariamente a la cabecera TCP. Esta pseudocabecera contiene la dirección de origen, la
dirección de destino, el protocolo, y la longitud del segmento de TCP. Esto proporciona una
protección ante segmentos mal encaminados. Esta información es transportada por el
protocolo de internet y es transferida a través de la interfaz TCP/Red en los argumentos o
en los resultados de las llamadas de TCP a IP.
 Puntero urgente: 16 bits.
Este campo indica el valor actual del puntero urgente como un desplazamiento positivo
desde el número de secuencia de este segmento. El puntero urgente apunta al número de
secuencia del octeto al que seguirán los datos urgentes. Este campo es interpretado
únicamente si el bit de control URG está establecido a uno.
 Opciones: variable
Los campos de opciones pueden ocupar un cierto espacio al final de la cabecera de TCP,
pero siempre de una longitud múltiplo de 8 bits. En el cálculo de la suma de control, se
incluyen todas las opciones. Una opción puede empezar en cualquier posición múltiplo de
ocho.
Existen dos posibilidades para el formato de una opción:
Caso 1: Un octeto único con el tipo de opción.
Caso 2: Un octeto con el tipo de opción, un octeto con la longitud de la opción, y los
octetos con los datos propiamente dichos de la opción.
La longitud de la opción tiene en cuenta tanto el octeto con el tipo de opción como el
propio octeto de longitud, así como los octetos con los datos de la opción.
Nótese que la lista de opciones puede ser más corta que lo que el campo "Posición de los
datos" podría implicar. El contenido de la cabecera más allá de la opción "Fin de la lista de
opciones" debe ser un relleno de cabecera (es decir, ceros).
Un módulo de TCP debe implementar todas las opciones.
Las opciones definidas en la actualidad incluyen (donde el tipo se indica en octal):

TIPO LONGITUD SIGNIFICADO

0 - Fin de la lista de opciones
1 - Sin operación
2 4 Tamaño máximo de segmento

1. Definiciones de opciones específicas

Fin de la lista de opciones
+|00000000|+ Tipo 0
Este código de opción indica el final de la lista de opciones. Éste podría no coincidir con el
final de la cabecera de TCP deducida a partir del campo "Posición de los datos". Esta
opción se utiliza al final de todas las opciones, no al final de cada opción, y sólo es
necesario utilizarla si el final de las opciones restantes no coincide con el final de la
cabecera de TCP.
Sin operación
+--------+|00000001|+--------+ Tipo=1
Este código de opción puede ser utilizado entre opciones, por ejemplo, para alinear el
comienzo de una opción subsiguiente con el comienzo de una palabra. No se garantiza que
los emisores vayan a utilizar esta opción, por lo que los receptores deben estar preparados
para procesar todas las opciones, incluso si no comienzan al principio de una palabra.
Máximo tamaño de segmento
+|00000010|+|00000100|+|máx tam seg|+ Tipo=2 Longitud=4
Datos de la opción "Máximo tamaño de segmento": 16 bits
Si esta opción está presente, entonces indica el tamaño máximo de segmento que puede
recibir el módulo de TCP que envía este segmento. Este campo debe enviarse únicamente
en la petición inicial de conexión (i.e., en los segmentos con el bit de control SYN puesto a
uno). Si no se utiliza esta opción, se permite cualquier tamaño de segmento.
 Relleno: variable
El relleno de la cabecera de TCP se utiliza para asegurar que la cabecera de TCP finaliza, y
que los datos comienzan, en una posición múltiplo de 32 bits. El relleno está compuesto de
ceros.

Terminología
El mantenimiento de una conexión de TCP requiere el almacenamiento y seguimiento de
varias variables. Estas variables han de imaginarse almacenadas en un registro de conexión
denominado "Bloque de control de la transmisión” o TCB ('Transmission Control Block').
Entre las variables almacenadas en el TCB se hallan las direcciones de los conectores local
y remoto, los valores de seguridad y prioridad de la conexión, los punteros a los búferes de
envío y recepción del usuario, los punteros a la cola de retransmisión y al segmento actual.
También se almacenan en el TCB algunas variables relacionadas con los números de
secuencia de envío y recepción.
Variables de la secuencia de envío
 [Link] - envío sin acuse de recibo recibido ('unacknowledged')
 [Link] - envío siguiente ('next')
 [Link] - ventana ('window') de envío
 [Link] - puntero urgente ('urgent pointer') de envío
 SND.WL1 - número de secuencia del segmento utilizado en la última ('last')
actualización de la ventana
 SND.WL2 - número de acuse de recibo del segmento utilizado en la última
actualización de la ventana
 ISS - número de secuencia de envío inicial ('initial send sequence')
Variables de la secuencia de recepción
 [Link] - siguiente recepción
 [Link] - ventana de recepción
 [Link] - puntero urgente de recepción
 IRS - número de secuencia de recepción inicial ('initial receive sequence')
Los siguientes diagramas pueden ayudar a relacionar alguna de estas variables con el
espacio de secuencias.
1 2 3 4
----------|----------|----------|----------
[Link] [Link] [Link]+[Link]
1. anteriores números de secuencia de los que ya se ha recibido acuse de recibo
2. número de secuencia de datos sin acuse de recibo recibido
3. número de secuencia permitido en la siguiente transmisión de datos
4. futuros números de secuencia no permitidos todavía en la siguiente transmisión
Espacio de secuencias de envío

1 2 3
----------|----------|----------
[Link] [Link] + [Link]
1. anteriores números de secuencia de los que ya se han enviado el acuse de recibo
2. números de secuencia permitidos para una nueva recepción
3. futuros números de secuencia que todavía no están permitidos
Espacio de secuencias de recepción

Además, hay algunas variables que se utilizarán con frecuencia en la exposición que sigue
más adelante y que toman sus valores de los campos del segmento actualmente en proceso.
Variables del segmento actual
 [Link] - número de secuencia del segmento
 [Link] - número de acuse de recibo del segmento
 [Link] - longitud ('length') del segmento
 [Link] - ventana del segmento
 [Link] - puntero urgente del segmento
 [Link] - valor de prioridad del segmento
Una conexión progresa de acuerdo con una serie de estados durante su tiempo de vida. Los
estados son: 'LISTEN' (en escucha), 'SYN-SENT' (SYN enviado), 'SYN-RECEIVED'
(SYN recibido), 'ESTABLISHED' (establecida), 'FIN-WAIT-1' ("en espera de fin-1"),
'FIN-WAIT-2' ("en espera de fin-2"), 'CLOSE-WAIT' (en espera de cierre), 'CLOSING'
(cerrándose), 'LAST-ACK' (último acuse de recibo), 'TIME-WAIT' (en espera), y el estado
ficticio 'CLOSED' (cerrada). 'CLOSED' es un estado ficticio porque representa el estado en
el que no existe TCB, y, por lo tanto, no hay conexión. De forma breve, los significados de
los estados son (N.T.: de aquí en adelante no se entrecomillarán los estados y llamadas
salvo cuando aparezcan en frases en mayúsculas):
 LISTEN - representa la espera de una solicitud de conexión proveniente de cualquier
TCP y puerto remotos.
 SYN-SENT - representa la espera de una solicitud de conexión concordante tras haber
enviado previamente una solicitud de conexión.
 SYN-RECEIVED - representa la espera del acuse de recibo confirmando la solicitud de
conexión tras haber recibido tanto como enviado una solicitud de conexión.
 ESTABLISHED - representa una conexión abierta, los datos recibidos pueden ser
entregados al usuario. El estado normal para la fase de transferencia de una conexión.
 FIN-WAIT-1 - representa la espera de una solicitud de finalización de la conexión
proveniente del TCP remoto, o del acuse de recibo de la solicitud de finalización
previamente enviada.
 FIN-WAIT-2 - representa la espera de una solicitud de finalización del TCP remoto.
 CLOSE-WAIT - representa la espera de una solicitud de finalización de la conexión
proveniente del usuario local.
 CLOSING - representa la espera del paquete, proveniente del TCP remoto, con el acuse
de recibo de la solicitud de finalización.
 LAST-ACK - representa la espera del acuse de recibo de la solicitud de finalización de
la conexión previamente enviada al TCP remoto (lo que incluye el haber enviado el
acuse de recibo de la solicitud remota de finalización de la conexión).
 TIME-WAIT - representa la espera durante suficiente tiempo para asegurar que el TCP
remoto recibió el acuse de recibo de su solicitud de finalización de la conexión.
 CLOSED - representa un estado sin conexión en absoluto
Una conexión de TCP progresa de un estado a otro en respuesta a eventos. Los eventos
son: las llamadas de usuario, OPEN ("abrir"), SEND ("enviar"), RECEIVE ("recibir"),
CLOSE ("cerrar"), ABORT ("interrumpir"), and STATUS ("mostrar el estado"); la llegada
de segmentos, particularmente aquellos que contengan alguno de los indicadores SYN,
ACK, RST y FIN, y la expiración de plazos de tiempos.

Números de secuencia
El hecho de que todo octeto de datos enviados por una conexión de TCP tenga asociado un
número de secuencia constituye una noción fundamental en el diseño de TCP. Ya que cada
octeto se secuencia, puede realizarse un acuse de recibo de cada uno de ellos. El
mecanismo de acuse de recibo empleado es acumulativo, de tal forma que el acuse de
recibo de un número de secuencia X indica que todos los octetos hasta, pero no incluyendo,
X, han sido recibidos. Este mecanismo permite la detección fácil y directa de duplicados
generados por retransmisiones.
La numeración de octetos dentro de un segmento es de la siguiente forma: el primer octeto
de datos inmediatamente tras la cabecera es el de menor número y los octetos siguientes
son numerados consecutivamente.
Es esencial tener presente que el espacio real de números de secuencia es finito, aunque
muy grande. Este espacio abarca desde el 0 hasta 2**32 -1. Como el espacio es finito, toda
la aritmética con números de secuencia debe ser desarrollada módulo 2**32. Esta
aritmética sin signo preserva la relación entre números de secuencia incluso cuando se rota
desde 2**32 -1 a 0 de nuevo. Hay algunas sutilezas en los cálculos de la aritmética de
módulos, por tanto, se ha de tener un especial cuidado a la hora de programar las funciones
de comparación de valores. El símbolo "=<" significa "menor o igual" (modulo 2**32).
Las típicas comparaciones de números de secuencia que TCP debe realizar incluyen:
a) Determinar si un acuse de recibo se refiere a algún número de secuencia enviado,
pero del que no se ha recibido todavía su acuse de recibo
b) Determinar si se ha recibido el acuse de recibo de todos los números de secuencia
ocupados por un segmento (por ejemplo, para eliminar un segmento de la cola de
retransmisión).
c) Determinar si un segmento entrante contiene números de secuencia esperados (es
decir, si el segmento cabrá en la ventana de recepción).
Como respuesta a sus envíos de datos, el módulo de TCP recibirá acuses de recibo. Es
necesario realizar las siguientes comparaciones para procesar los acuses de recibo.
[Link] = el menor número de secuencia sin acuse de recibo recibido
[Link] = número de secuencia del próximo envío
[Link] = acuse de recibo procedente del TCP receptor (próximo número de secuencia
esperado por el TCP receptor)
[Link] = primer número de secuencia de un segmento
[Link] = el número de octetos ocupados por los datos en el segmento (incluyendo SYN
y FIN)
[Link]+[Link]-1 = último número de secuencia de un segmento
Un nuevo acuse de recibo (denominado un "acuse de recibo aceptable"), es aquél para el
cual la siguiente desigualdad es cierta:
[Link] < [Link] =< [Link]
Un segmento ubicado en la cola de retransmisión queda completamente confirmado por un
acuse de recibo si la suma de su número de secuencia inicial y su longitud es menor o igual
que el valor del acuse de recibo indicado en el segmento entrante.
Es necesario realizar las siguientes comparaciones cuando se reciben datos.
[Link] = siguiente número de secuencia esperado de los segmentos entrantes, lo que
define el borde izquierdo o inferior de la ventana de recepción
[Link]+[Link]-1 = último número de secuencia esperado en un segmento entrante,
lo que define el borde derecho o superior de la ventana de recepción
[Link] = primer número de secuencia ocupado por el segmento entrante
[Link]+[Link]-1 = último número de secuencia ocupado por el segmento entrante
Se considera que un segmento ocupa una porción válida del espacio de secuencias de
recepción si
[Link] =< [Link] < [Link]+[Link]
o si
[Link] =< [Link]+[Link]-1 < [Link]+[Link]
La primera parte de esta comprobación mira a ver si el comienzo del segmento cae dentro
de la ventana, la segunda parte comprueba si el final del segmento cae dentro de la ventana;
si el segmento pasa cualquiera de las dos partes de la comprobación, entonces es que
contiene datos dentro de la ventana.
La realidad es algo más compleja que todo esto. Debido a la existencia de ventanas y
segmentos de tamaño cero, tenemos cuatro posibilidades a considerar a la hora de aceptar
un segmento entrante:
Longitud Ventana
Comprobación
segmento receptora
0 0 [Link] = [Link]
0 >0 [Link] =< [Link] < [Link] + [Link]
>0 0 NO ACEPTABLE
[Link] =< [Link] < [Link]+[Link]
o [Link] =< [Link]+[Link]-1 <
>0 >0
[Link]+[Link]
Selección del número de secuencia inicial
Este protocolo no pone ninguna restricción sobre el hecho de reutilizar una y otra vez la
misma conexión. Una conexión se define por el par de conectores. Cualquier nueva
instancia de una conexión será referida como una encarnación de la conexión. El problema
que aparece aquí es: “¿cómo identifica TCP los segmentos duplicados de encarnaciones
previas de la conexión?" Este problema resulta evidente si la conexión se abre y se cierra en
una sucesión muy rápida, o si la conexión se corta acompañada de pérdidas de memoria y
después se reestablece.
Para evitar una confusión, se debe evitar que los segmentos de una encarnación de una
conexión utilicen los números de secuencia que todavía posiblemente estén siendo
utilizados en la red por otra encarnación anterior. Se desea asegurar esto, incluso si un TCP
se cuelga y pierde todo conocimiento de los números de secuencia que estaba empleando.
Cuando se crean nuevas conexiones se utiliza un generador de números iniciales de
secuencia (ISN, 'initial sequence number') que selecciona un nuevo ISN de 32 bits. El
generador estará asociado a un reloj (posiblemente ficticio) de 32 bits, cuyo bit menos
significativo se incrementa aproximadamente cada 4 microsegundos. Así, el ISN rota
aproximadamente cada 4.55 horas. Como queda asumido que los segmentos no
permanecerán más tiempo en la red que la "vida máxima del segmento" (MSL, 'Maximum
Segment Lifetime') y que el MSL es menor que 4.55 horas, podemos por tanto
razonablemente presuponer que los ISN serán únicos.
Para cada conexión existe un número de secuencia de envío y un número de secuencia de
recepción. El número de secuencia de envío inicial (ISS, 'initial send sequence') lo elige el
TCP emisor, y el número de secuencia de recepción inicial (IRS, 'initial receive sequence')
se asume durante el procedimiento de establecimiento de la conexión.
Para que una conexión quede establecida o inicializada, los dos TCP deben sincronizarse
entre sí mediante sus números de secuencia iniciales. Esto se consigue durante el
establecimiento de la conexión mediante el intercambio de segmentos que transportan un
bit de control denominado "SYN" (acrónimo de 'syncronize' o sincronizar en inglés) y los
números de secuencia iniciales. A modo de abreviatura, los segmentos que transportan el
bit SYN se denominan también "SYN". Por tanto, la solución requiere de un apropiado
mecanismo para elegir un número de secuencia inicial y una forma de acuerdo ligeramente
complicada para intercambiar los ISN.
La sincronización requiere que cada parte envíe su propio número de secuencia inicial y
que reciba una confirmación de su llegada en la forma de un acuse de recibo de la otra
parte. Cada parte debe también recibir el número de secuencia inicial de la otra parte y
enviar un acuse de recibo como confirmación.
1) A --> B SYN mi número de secuencia es X
2) A <-- B ACK tu número de secuencia es X
3) A <-- B SYN mi número de secuencia es Y
4) A --> B ACK tu número de secuencia es Y
Como los pasos 2 y 3 pueden combinarse en un único mensaje, este procedimiento se
denomina acuerdo en tres pasos (o en tres mensajes).
Es necesario un acuerdo en tres pasos porque los números de secuencia no están sujetos a
un reloj global de la red, y los TCP puede que tengan diferentes mecanismos para elegir los
ISN. El receptor del primer SYN no tiene forma de saber si el segmento era uno anterior
retrasado o no, a menos que recuerde el último número de secuencia utilizado en la
conexión (lo que no siempre es posible), y por tanto debe pedir al emisor que verifique este
SYN.

Saber cuándo permanecer en silencio

Para estar seguro de que un TCP no cree un segmento que transporte un número de
secuencia que podría estar duplicado por la existencia de otro segmento anterior que
todavía permanezca en la red, TCP debe permanecer en silencio durante el tiempo de vida
máximo de un segmento (MSL, 'maximum segment lifetime') antes de que asigne cualquier
número de secuencia tras arrancar o recuperarse de una caída en la que se perdieron los
números de secuencia en uso. En esta especificación, el MSL se toma como de 2 minutos.
Esta es la elección de un ingeniero, y puede ser cambiada si la experiencia indica que es
conveniente hacerlo. Nótese que, si un TCP se reinicializa de alguna forma en la que
todavía retenga en memoria los números de secuencia en uso, entonces no es necesaria
ninguna espera en absoluto; en ese caso, basta con utilizar números de secuencia mayores
que los utilizados con anterioridad.

Establecimiento de una conexión

El procedimiento de acuerdo en tres pasos se utiliza para establecer una conexión.
Normalmente, este procedimiento se inicia por un TCP y responde otro TCP distinto. El
procedimiento también funciona si dos TCP simultáneamente inician el procedimiento. En
el caso de intentos simultáneos, cada TCP recibe un segmento 'SYN', que no lleva acuse de
recibo, tras haber envíado su 'SYN'. Por supuesto, la llegada de un segmento 'SYN' anterior
duplicado puede, potencialmente, hacer creer al receptor que está en progreso una
iniciación simultánea de conexión. Un uso adecuado de los segmentos de tipo 'reset' puede
eliminar la ambigüedad de estos casos.
Conexiones "medio abiertas" y otras anomalías
Una conexión establecida se dice que está "medio abierta" ('half-open') si uno de los TCP
ha cerrado o interrumpido la conexión en su extremo sin avisar a la otra parte, o si los dos
extremos de la conexión han quedado desincronizados por culpa de una caída que causó
pérdidas de memoria. Tales conexiones se reiniciarán automáticamente (mediante un
"reset") si hay un intento de enviar datos en cualquier sentido. Sin embargo, es de esperar
que las conexiones medio abiertas se den con poca frecuencia, y además el procedimiento
de recuperación no es excesivamente complicado.

Generación de reinicios ('resets')

Como regla general, se debe envíar un 'reset' (RST) siempre que llegue un segmento que
aparentemente no esté destinado para la conexión actual. No debe enviarse un 'reset' si no
está claro que éste sea el caso.
Hay tres grupos de estados:
1. Si la conexión no existe (estado CLOSED) entonces se envía un 'reset' como respuesta a
cualquier segmento entrante excepto si es otro 'reset'. En particular, los SYN enviados a
una conexión no existente serán rechazados de esta forma.
Si en el segmento entrante tiene significado el campo ACK, el 'reset' escoge como su
número de secuencia el valor del campo ACK del segmento, en otro caso el número de
secuencia del 'reset' tiene valor cero y el campo ACK se establece a la suma del número de
secuencia y la longitud del segmento entrante. La conexión permanece en el estado
CLOSED.
2. Si la conexión está en cualquier estado no sincronizado (LISTEN, SYN-SENT, SYN-
RECEIVED), y el segmento entrante confirma un número todavía no enviado (el
segmento lleva un ACK inaceptable), o si un segmento entrante tiene un nivel de
seguridad o compartimentación que no concuerda exactamente con el solicitado para la
conexión, entonces, se envía un 'reset'.
Si nuestro SYN no ha sido confirmado y el nivel de prioridad del segmento entrante es más
alto que el nivel de prioridad solicitado entonces o se aumenta el nivel de prioridad local (si
esto está permitido por el usuario y el sistema) o se envía un 'reset'; o si el nivel de
prioridad del segmento entrante es menor que el nivel de prioridad solicitado entonces se
continúa como si los niveles de prioridad hubieran concordado exactamente (si el TCP
remoto no puede elevar el nivel de prioridad para concordar el nuestro sería detectado en el
próximo segmento que enviara, y la conexión se finalizaría entonces).
Si nuestro SYN ha sido confirmado (quizás en este mismo segmento entrante), el nivel de
prioridad del segmento entrante debe concordar exactamente con el nivel de prioridad local,
si no es así, se envía un 'reset'.
Si el segmento entrante tiene un campo ACK, el 'reset' escoge su número de secuencia del
campo ACK del segmento, en otro caso el "reset" tiene como número de secuencia cero y el
campo ACK se establece a la suma del número de secuencia y la longitud del segmento
entrante. La conexión permanece en el mismo estado.
3. Si la conexión está en un estado sincronizado (ESTABLISHED, FIN-WAIT-1, FIN-
WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), cualquier segmento
inaceptable (con un número de secuencia fuera de la ventana o con un número de acuse
de recibo inaceptable) debe desencadenar únicamente el envío de un segmento de acuse
de recibo vacío de datos, que llevaría el actual número de secuencia y un valor de acuse
de recibo indicando el siguiente número de secuencia que se espera recibir; entonces la
conexión permanece en el mismo estado.
Si el segmento entrante tiene un nivel de seguridad, o compartimentación, o prioridad que
no concuerda exactamente con los solicitados para la conexión, entonces se envía un 'reset'
y la conexión pasa al estado CLOSED. El 'reset' escoge como su número de secuencia el
valor del campo ACK del segmento entrante.

Procesamiento de 'resets'.
En todos los estados exceptuando SYN-SENT, todos los segmentos de tipo 'reset' (RST)
son validados comprobando sus campos SEQ. Un 'reset' es válido si su número de
secuencia está dentro de la ventana. En el estado SYN-SENT (con un RST recibido en
respuesta a un SYN inicial), el RST es aceptable si el campo ACK confirma el SYN.
El receptor de un RST primero lo comprueba, entonces cambia de estado. Si el receptor
estaba en el estado LISTEN, lo ignora. Si el receptor estaba en el estado SYN-RECEIVED
y estaba previamente en el estado LISTEN, entonces el receptor vuelve al estado LISTEN,
en cualquier otro caso el receptor interrumpe la conexión y pasa al estado CLOSED. Si el
receptor, estaba en cualquier otro estado, interrumpe la conexión, avisa de ello al usuario y
pasa al estado CLOSED.

Cierre de una conexión

CLOSE (N.T.: "cerrar" en inglés) es una operación que significa "no tengo más datos que
enviar". La noción de cerrar una conexión bidireccional tiene una interpretación ambigua,
desde luego, dado que puede no resultar obvio como tratar a la parte receptora de la
conexión. Se ha elegido tratar a CLOSE de una forma simple.
El usuario que hace la llamada CLOSE puede continuar recibiendo mediante llamadas
RECEIVE hasta que se le indique que el otro lado ha cerrado también la conexión mediante
otro CLOSE. Por tanto, un programa puede iniciar varias llamadas SEND seguidas por una
llamada CLOSE y continuar recibiendo (con RECEIVE) hasta que se le indique que falló
una llamada RECEIVE debido a que su interlocutor cerró la conexión con un CLOSE. Se
asume que TCP indicará al usuario que el otro lado de la conexión ha cerrado ésta incluso
si no hay llamadas RECEIVE pendientes, de forma que pueda cerrar su conexión
limpiamente. Una conexión TCP entregará de forma fiable todos los búferes enviados en
llamadas SENT antes de que la conexión sea cerrada, de forma que un usuario que no
espera datos de respuesta sólo necesite esperar a que la conexión sea cerrada con éxito para
saber que todos sus datos fueron recibidos en el TCP de destino. Los usuarios deben
mantenerse leyendo en las conexiones que cierren para envío hasta que TCP notifique que
no hay más datos.
Existen fundamentalmente tres casos:
1. El usuario inicia el cierre de la conexión enviando la llamada CLOSE a TCP.
2. El TCP remoto inicia el cierre enviando una señal de control FIN.
3. Ambos usuarios realizan la llamada CLOSE simultáneamente.
Caso 1: el usuario local inicia el cierre
En este caso se puede construir un segmento FIN y ponerlo en la cola de salida de
segmentos. TCP no aceptará más llamadas SEND y entrará en el estado FIN-WAIT-1. En
este estado se permiten las llamadas RECEIVE. Todos los segmentos que preceden al FIN,
incluido éste, serán retransmitidos hasta que se reciban los correspondientes acuses de
recibo. Cuando el TCP remoto haya realizado el acuse de recibo del FIN y enviado su
propio FIN, el TCP local puede realizar el acuse de recibo de este FIN. Nótese que un TCP
que recibe un FIN enviará su ACK, pero no enviará su propio FIN hasta que su usuario
haya cerrado también la conexión con un CLOSE.
Caso 2: TCP recibe un FIN desde la red
Si llega un FIN no solicitado desde la red, el TCP receptor puede responder con un ACK y
advertir al usuario de que la conexión se está cerrando. El usuario responderá con una
llamada CLOSE, ante la cual TCP puede enviar un FIN al otro TCP tras enviar los datos
restantes. Entonces TCP espera hasta el acuse de recibo de su propio FIN y elimina la
conexión. Si el ACK no llega en el tiempo de espera del usuario, la conexión se aborta y así
se notifica al usuario.
Caso 3: ambos usuarios cierran simultáneamente
El cierre simultáneo a ambos lados de la conexión causa el intercambio de segmentos FIN.
Cuando todos los segmentos que preceden a los FIN se han procesado y confirmado con
acuses de recibo, cada TCP puede responder con un ACK el FIN que ha recibido. Ambos,
ante la recepción de los ACK, eliminarán la conexión.

Prioridad y seguridad
La intención es que la conexión sólo se permita entre puertos que operen exactamente con
los mismos valores de seguridad y compartimentación y con un nivel de prioridad igual al
mayor de los solicitados por ambos puertos.
Los parámetros de prioridad y seguridad usados en TCP son exactamente los definidos en
el protocolo de internet (IP) [2]. A lo largo de esta especificación de TCP el término
"seguridad/compartimentación" indica los parámetros de seguridad utilizados por IP que
incluye los de seguridad, compartimentación, grupo de usuario y manejo de restricciones.
Un intento de conexión con valores de seguridad/compartimentación erróneos o con un
nivel de prioridad menor debe ser rechazado enviando un 'reset'. El rechazo de una
conexión debido a un nivel de prioridad demasiado bajo ocurre solamente tras la recepción
del acuse de recibo del SYN.
Los parámetros de seguridad pueden ser utilizados incluso en un entorno inseguro (los
valores indicarían datos reservados secretos), por lo que las máquinas en entornos inseguros
deben estar preparadas para recibir los parámetros de seguridad, aunque no es obligatorio
que los envíen.

Comunicación de datos
Una vez establecida la conexión los datos se transmiten mediante el intercambio de
segmentos. Dado que los segmentos pueden perderse debido a errores (fallo en la suma de
comprobación) o congestión de la red, TCP utiliza la retransmisión (tras un tiempo de
espera) para asegurar la entrega de cada segmento. Pueden llegar segmentos duplicados
debido a la red o a la retransmisión de TCP. Tal y como se explica en la sección sobre
números de secuencia, TCP realiza ciertas comprobaciones sobre los números de secuencia
y de acuse de recibo en los segmentos para verificar su admisibilidad.
El emisor de los datos mantiene un registro del próximo número de secuencia a usar en la
variable [Link]. El receptor de los datos mantiene un registro del siguiente número de
secuencia esperado en la variable [Link]. El emisor mantiene también un registro del
número de secuencia sin acuse de recibo menor en la variable [Link] el flujo de
datos queda momentáneamente inactivo y de todos los datos enviados se tiene acuse de
recibo entonces las tres variables será idénticas.
Cuando el emisor crea un segmento y lo transmite, incrementa [Link]. Cuando el
receptor acepta un segmento incrementa [Link] y envía un acuse de recibo. Cuando el
emisor de los datos recibe un acuse de recibo incrementa [Link]. La diferencia entre
los valores de estas variables es una medida del retardo en la comunicación. El valor en el
cual se incrementan estas variables es el de la longitud de los datos del segmento. Nótese
que, una vez en el estado ESTABLISHED todos los segmentos deben llevar la información
del acuse de recibo actualizada.

Interfaces
Existen, por supuesto, dos interfaces de interés: la interfaz usuario/TCP y la interfaz
TCP/nivel-inferior. Tenemos un modelo completamente elaborado de la interfaz
usuario/TCP, pero dejamos sin especificar aquí la interfaz con el protocolo de nivel
inferior, ya que estará especificado en detalle en la especificación del protocolo de nivel
inferior. Para el caso en que el protocolo de nivel inferior sea IP, apuntamos algunos de los
valores de los parámetros que los TCP pueden utilizar.

Interfaz usuario/TCP
La siguiente descripción funcional de las órdenes de usuario al módulo de TCP es, en el
mejor de los casos, ficticia, dado que cada sistema operativo dispondrá de distintos
recursos. En consecuencia, debemos advertir al lector que diferentes implementaciones de
TCP pueden tener diferentes interfaces de usuario. Sin embargo, todos los TCP deben
proporcionar un cierto conjunto mínimo de servicios para garantizar que todas las
implementaciones TCP pueden soportar la misma jerarquía de protocolo. Esta sección
especifica las interfaces funcionales obligatorias para todas las implementaciones de TCP.

Ordenes de usuario de TCP

Las siguientes secciones caracterizan de forma funcional una interfaz USUARIO/TCP. La
notación utilizada es similar a la mayoría de las llamadas a procedimiento o función de los
lenguajes de alto nivel, lo cual no significa que se excluyan las llamadas de servicio tipo
'trap' (i.e., SVC, UUO, EMT).
Las órdenes de usuario descritas más abajo especifican las funciones básicas que debe
ejecutar TCP para soportar la comunicación entre procesos. Las implementaciones
individuales deben definir su propio formato exacto, y pueden proporcionar combinaciones
o subconjuntos de las funciones básicas en llamadas simples. En particular, algunas
implementaciones pueden querer realizar la llamada de apertura OPEN de la conexión
automáticamente en el primer SEND o RECEIVE enviado por el usuario para una conexión
dada.
Al proporcionar recursos para la comunicación entre procesos, el TCP no debe limitarse a
aceptar órdenes, sino que también debe devolver información al proceso que sirve. Esta
información consistirá en:
a) información general acerca de una conexión (i.e., interrupciones, cierre remoto,
enlace a un conector remoto sin especificar).
b) respuestas a órdenes de usuario específicas indicando éxito o varios tipos de error.

Open (N.T: "abrir" en inglés)

Formato: OPEN (puerto local, conector remoto, 'active'/'passive' [, tiempo de espera] [,
prioridad] [, seguridad/compartimentación] [, opciones]) -> nombre de la conexión local
(N.T.: 'active' es "activa" en inglés, 'passive' es "pasiva")
Se asume que el TCP local conoce la identidad de los procesos a los que sirve y que
comprobará que el proceso tiene autoridad para utilizar la conexión especificada.
Dependiendo de la implementación del TCP, los identificadores del TCP y de la red local
serán proporcionados bien por el módulo de TCP o bien por el protocolo de nivel inferior
(i.e. IP). Estas consideraciones derivan de cuestiones de seguridad, de forma que ningún
TCP pueda hacerse pasar por otro, y así sucesivamente. De forma similar, ningún proceso
puede hacerse pasar por otro sin la connivencia del módulo de TCP.
Send (N.T: "enviar" en inglés)
Formato: SEND (nombre de la conexión local, dirección del búfer, contador de bytes,
indicador PUSH, indicador URGENT [, tiempo de espera])
Esta llamada hace que se envíen mediante la conexión indicada los datos contenidos en el
búfer de usuario indicado. Si la conexión no se ha abierto, el SEND se considera un error.
Puede que algunas implementaciones permitan a los usuarios enviar un SEND primero; en
este caso, se efectuará un OPEN automático. Si el proceso llamador no está autorizado a
usar esta conexión, se devuelve un error.
CLOSE
Formato: CLOSE (nombre de la conexión local)
Esta orden cierra la conexión especificada. Si la conexión no está abierta o el proceso
solicitante no está autorizado a usar dicha conexión, se devuelve un error. El cierre de
conexiones está pensado para que sea una operación limpia en el sentido de que las
llamadas SEND pendientes serán transmitidas (y retransmitidas), en la medida en que el
control de flujo lo permita, hasta que todas hayan sido servidas. Por tanto, es aceptable
enviar varias órdenes SEND seguidas de una llamada CLOSE, y suponer que todos los
datos serán enviados a su destino. Debe quedar claro que los usuarios pueden continuar
recibiendo por conexiones que se están cerrando, ya que el otro lado de la conexión puede
estar intentando transmitir el resto de sus datos. Por tanto, cerrar una conexión significa "no
tengo nada más que enviar" pero no "no recibiré nada más". Puede suceder (si el protocolo
del nivel de usuario no está bien ideado) que el lado de la conexión que cierra no sea capaz
de deshacerse de todos sus datos antes de que se cumpla el tiempo de espera. En este caso,
la llamada CLOSE se convierte en una llamada ABORT, y el TCP que cierra la conexión
deja de seguir.
Status (N.T. "estado" en inglés)
Formato: STATUS (nombre de la conexión local) -> datos de estado
Esta orden de usuario depende de la implementación y puede excluirse sin efectos adversos.
La información devuelta provendrá típicamente del TCB asociado con la conexión.
Esta orden devuelve un bloque de datos que contiene la siguiente información:
1. conector local,
2. conector remoto,
3. nombre de la conexión local,
4. ventana de recepción,
5. ventana de envío,
6. estado de la conexión,
7. número de búferes en espera del acuse de recibo,
8. número de búferes pendientes de recepción,
9. estado urgente,
10. prioridad,
11. seguridad/compartimentación,
12. y tiempo de espera de transmisión
Dependiendo del estado de la conexión, o de la implementación misma, parte de esta
información puede no estar disponible o no tener ningún significado útil. Si el proceso
solicitante no está autorizado a utilizar esta conexión se devuelve un error. Esto evita que
los procesos no autorizados puedan obtener información sobre una conexión.
ABORT
Formato: ABORT (nombre de la conexión local)
Esta orden aborta la ejecución de todas las órdenes SEND y RECEIVE pendientes, elimina
el TCB y envía un mensaje especial RESET al otro lado de la conexión. Dependiendo de la
implementación, los usuarios pueden recibir avisos de abandono por cada orden SEND o
RECEIVE pendiente, o simplemente recibir una confirmación de la ejecución de la orden
ABORT.

Mensajes de TCP a usuario

Se da por supuesto que el sistema operativo proporciona algún medio para que TCP pueda
enviar una señal asíncrona al programa de usuario. Cuando TCP envía una señal a un
programa de usuario pasa cierta información al usuario. A menudo en la especificación la
información será un mensaje de error. En otros casos habrá información relativa a la
finalización del procesamiento de una orden SEND o RECEIVE o cualquier otra llamada
del usuario.
Se proporciona la siguiente información:
 Nombre de la conexión local Siempre
 Texto de respuesta Siempre
 Dirección del búfer SEND y RECEIVE
 Número de bytes (núm. de bytes recibidos) RECEIVE
 Indicador de entrega inmediata RECEIVE
 Indicador urgente RECEIVE

Interfaz TCP/nivel inferior

Realmente, TCP realiza llamadas al módulo del protocolo de nivel inferior para enviar y
recibir información a través de una red. Uno de estos casos es el del sistema de
interconexión de redes ARPA, donde el módulo del nivel inferior es el protocolo de internet
(IP).
Si el protocolo de nivel inferior es IP, éste proporciona argumentos para un tipo de servicio
y un tiempo de vida. TCP utiliza los siguientes valores para estos parámetros:
 Tipo de servicio = prioridad: habitual, retardo: normal, rendimiento: normal,
fiabilidad: normal; ó 00000000.
 Tiempo de vida = un minuto, ó 00111100.
REFERENCIAS BIBLIOGRÁFICAS
[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE
Transactions on Communications, Vol. COM-22, Nº. 5, págs 637-648, Mayo de 1974.
[2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification",
RFC 791, USC/Information Sciences Institute, septiembre de 1981. (N.T. Versión en
castellano por P.J. Ponce de León: "Protocolo Internet", mayo de 1999)
[3] Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols",
Computer Networks, Vol. 2, No. 6, pp. 454-473, diciembre de 1978.
[4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences Institute,
September de 1981.
[5] Information Sciences Institute, Ponce de León, P. J., Sánchez Ruiz, D., & Usera Estirado, J. I.
(2002, marzo). RFC 0793. [Link] [Link]
[Link]/rfc/[Link]