RFC 793 TCP (TRANSMISSION CONTROL PROTOCOL).

Arvalo Bravo, David Cod. 25343

daviddd182@gmail.com
Buitrago, Heiner Fernando Cod. 25312
heiner2588@gmail.com
Cepeda vila, Julio Csar Cod. 25194
ing.cesarcepeda@hotmail.com


RESUMEN: En este documento vamos
a exponer las caractersticas principales de la RFC
793, la cual corresponde al protocolo TCP
(Transmission Control Protocol) que traduce
Protocolo de Control de Transmisin.
Analizaremos las partes que lo componen, su
relacin con otros protocolos, especificaciones,
entre otros.

PALABRAS CLAVE: Cabecera,
datagrama, host, paquete.


1. INTRODUCCIN

Est diseado para ser un protocolo bastante
confiable para el transporte de paquetes entre
computadores de una red, para esto a
continuacin se describirn sus funciones e
interfaces que intervienen para el correcto
entendimiento de un usuario que los requiera
utilizar.

1.1. Motivacin.

Los sistemas de comunicacin estn jugando un
papel bastante importante en prcticamente todos
los entornos que encontramos a diario. Aqu
encontraremos los requisitos de comunicacin
militares, disponibilidad y congestin.
A medida que crecen las comunicaciones entre
computadoras es de suma importancia crear
interconexiones entre estas y as brindar
protocolos estndares de comunicaciones. Para
todo lo descrito anteriormente se cre el protocolo
TCP, por el Departamento de Defensa.
TCP es un protocolo orientado a la conexin
fiable, el cual se hacer entre 2 extremos,
soportando diferentes aplicaciones sobre las
redes. Adicionalmente proporciona un mecanismo
con el cual se pueden comunicar 2 host de
diferente red, pero interconectadas, con el cual
podemos acceder a un servicio de transmisin de
datagramas simple.
TCP se basa en una arquitectura de protocolos en
capas, por encima del protocolo de internet, el
cual nos proporciona un medio para TCP de
enviar y recibir segmentos de longitud variable de
informacin envuelta en "sobres" de datagramas
de internet, en este datagrama encontraremos la
direccin origen y destino


Fig. 1 Capas de Protocolos

Este documento contiene la implementacin de
TCP con protocolos de ms alto nivel en el
computador anfitrin. Algunos equipos se
conectan a la red por medio de un computador
intermedio. Esta especificacin de TCP describe
una interfaz con protocolos de mayor nivel, an
entre un host y un computador intermedio,
siempre y cuando manejen el mismo protocolo.

1.2. mbito.

Este protocolo est diseado para brindar un
servicio fiable de comunicacin de host a host, en
redes mltiples.

1.3. Sobre este documento.

Es una especificacin del comportamiento e
implementacin de TCP, en el que se muestra la
interaccin con protocolos de ms alto nivel u
otros TCP, observaremos las interfaces del
protocolo, diseo de TCP, exigencias hacia TCP,
detalles y formatos de los segmentos.

1.4. Interfaces.

Por un lado muestra interfaz con el usuario y por
el otro con un protocolo de un nivel ms bajo,
como lo es el de internet (IP).
La interfaz entre el proceso de aplicacin y TCP
consiste en un conjunto de llamadas, unas de
estas son para abrir y cerrar conexiones. Por otro
lado la interfaz entre TCP y un nivel inferior no se
especifica, ya que solamente se entiende que
existe un mecanismo asncrono que permite el
paso de informacin entre los niveles.
Nivel Superior
TCP
Protocolo de Internet
Red de Comunicacin
1.5. Operacin.

Teniendo en cuenta que el protocolo TCP tiene
como funcin principal brindar una conexin fiable
y segura, sobre un entorno de internet menos
confiable, se requiere de mecanismos
relacionados con las siguientes reas:

Transferencia bsica de datos
Fiabilidad
Control de flujo
Multiplexamiento
Conexiones
Prioridad y seguridad

3.5 Transferencia bsica de datos.

TCP est en la capacidad de enviar un flujo
continuo de octetos entre sus usuarios, es decir
que TCP bloquea y enva datos de acuerdo a su
mejor conveniencia. En ocasiones el usuario
desea asegurarse que todos los datos que se han
enviado, todos sean transmitidos y para esto se
tiene la funcin 'push' ("enviar inmediatamente")
con lo que se asegura que TCP enve y entregue
inmediatamente los datos que tenga almacenados
hasta ese instante.

3.5 Fiabilidad.

TCP debe estar en la capacidad de recuperar los
datos que se daen, dupliquen o se entreguen
desordenados en internet. Esto se logra
asignando un nmero de secuencia a cada octeto
transmitido, y exigiendo un acuse de recibo (ACK,
'acknowledgment'). Si este no es recibido en
determinado tiempo, los datos se enviarn
nuevamente. Los nmeros de secuencia sirven al
receptor ya que con estos puede identificar los
segmentos que hayan llegado desordenados y
eliminar los duplicados.

3.5 Flujo de Control.

TCP brinda al receptor una herramienta o medio,
con el que puede controlar la cantidad de datos
enviados por el emisor, esta herramienta consiste
en que el receptor devuelve una ventana con cada
ACK indicando el rango de nmeros de secuencia
aceptables. La ventana lo que nos indica es el
nmero de octetos que puede transmitir el emisor.

3.5 Multiplexamiento.

Con el fin de permitir varios procesos simultneos
en un solo host, TCP proporciona unos puertos
dentro de cada host. Las direcciones de red y los
host juntos conforman la denominada direccin de
conector ('socket').



3.5 Conexiones.

Teniendo en cuenta la fiabilidad y control de flujo
descritos anteriormente, obligan a que TCP
mantengan una informacin de estado para cada
flujo de datos. Toda la informacin que TCP pueda
guardar la llamamos conexin y cada una de estas
se especifica de una forma nica por un par de
conectores. En el momento que 2 procesos
desean comunicarse, TCP establece una conexin
(informacin de estado en cada lado)y cuando
esta se ha completado, el paso a seguir es
liberarla, para que estos recursos se puedan usar
de otra forma.

3.5 Prioridad y Seguridad.

Son valores que se encuentran determinados por
defecto, sin embargo el usuario est en la
capacidad de modificarlos de acuerdo a su
necesidad.

2. FILOSOFA.

2.1. Elementos del sistema inter
redes.

Consiste en una serie de equipos conectados a
diferentes redes, las cuales estn conectadas a
diversos gateways. Estas redes pueden ser
locales o amplias las cuales se basan en
tecnologa de intercambio de paquetes y se busca
brindar un soporte a procesos que proporciona un
flujo de datos bidireccional sobre las conexiones
lgicas.
La definicin de paquete o trama es usada para
identificar los datos que fluyen entre un host y la
red, independientemente del formato que pueda
manejar.
Los host son computadores conectados a una red
y son el origen y destino de los paquetes
enviados. Adicionalmente los procesos que reaiza
cada computador se debe d distinguir entre varios
flujos de comunicacin, por ello la comunicacin
se hace entre puertos de diversos procesos.

2.2. Modelo de Operacin.

Los procesos transmiten datos a travs de TCP,
este empaqueta en segmentos y realiza una
llamada al mdulo de internet, con el fin de
transmitir cada segmento al TCP del destino. Los
mdulos que se reciben tienen informacin
empaquetada de control, los cuales son usado
para asegurar una transmisin fiable y ordenada
de datos.
El protocolo IP se asocia a cada mdulo de TCP
con el fin de crear una interfaz con la red local con
el fin de empaquetar los segmentos de TCP en
datagramas de internet y los encamina hacia el
destino.
Finalmente entre las redes, el datagrama de
internet se desenvuelve a partir del paquete de red
local, se examina y determina a travs de cual red
debe viajar el datagrama. Una vez realizado esto,
nuevamente se empaqueta en la red y se
transfiere hacia la siguiente, hasta llegar a su
destino final.
Es permitido que el datagrama sea dividido en
datagramas ms pequeos, solamente si es
necesario para la transmisin hacia la siguiente
red. El formato de los datagramas permiten que el
mdulo de destino reensamble los fragmentos del
datagrama enviado. Luego el mdulo de internet
de destino desenvuelve el datagrama y lo pasa al
TCP de destino.
Este modelo nos permite conocer bastantes
detalles acerca del tipo de servicio, ya que brinda
informacin con la que se puede determinar el
camino que debe seguir entre las redes.

2.3. El entorno del Host

El mdulo de TCP tiene la capacidad de llamar
funciones del sistema operativo, a la cuales los
usuarios pueden acceder, como por ejemplo,
gestionar las estructuras de datos. El
funcionamiento de TCP no impide la
implementacin de TCP en un procesador
intermediario ('front-end'), no obstante si se desea
implementar un protocolo de 'host' a 'front-end', es
necesario que la interfaz TCP usuario soporte
esta funcionalidad.

2.4. Interfaces

La interfaz TCP / Usuario, permite al usuario final
llamar por el mdulo de TCP funciones para abrir
o cerrar conexiones, enviar o recibir datos.
La interfaz TCP / Internet tiene la funcionalidad de
enviar y recibir datagramas los cuales se
direccionan a los mdulos TCP en cualquier 'host'
de una red. Sin embargo se debe tener en cuenta
los parmetros para pasar la direccin, el tipo de
servicio, la prioridad y otra informacin de control.

2.5. Relacin con otros protocolos

El siguiente diagrama ilustra el lugar de TCP en la
jerarqua de protocolos:


Fig. 2 Relacin entre protocolos.


2.6. Comunicacin fiable

Un flujo de datos enviado por TCP se entrega de
forma ordenada y fiable, esto se logra gracias a
los nmeros de secuencia que son asignados a
cada octeto. Cuando TCP transmite, deja una
copia de los datos en la cola de transmisin e
inicia un conteo, al recibir el acuse de recibido se
elimina la copia de la cola, pero si el contador
expira y no se ha recibido el acuse, se retransmite.
No obstante el acuse de recibido no confirma que
los datos se hayan entregado al receptor, sino que
el TCP receptor se encargar de esto.
Para controlar el flujo de datos, el receptor enva
una ventana al emisor, en la que se cuenta el
nmero de octetos a partir del acuse de recibo.

2.7. Establecimiento y finalizacin de
la conexin.

TCP tiene la capacidad de identificar puertos para
disponer de direcciones nicas, esto tanto en el
emisor como en el receptor, esto con el fin de
conformar una direccin de conector (socket), el
cual se compone de la direccin de internet y la
direccin de puerto de TCP.
Los mdulos de TCP asocian de forma libre los
puertos a procesos, sin embargo es necesario que
se tengan predeterminados un conjunto de
conectores asociados a ciertos procesos, lo cual
se podra manejar localmente. Sin embargo el
comando Request Port se encarga de asignar de
forma nica puertos a procesos.
El uso de conectores pblicos ('well-known') es un
proceso de bastante ayuda, ya que con este se
logra reservar direcciones de conectores con
algn servicio en especfico y guardarlos en
memoria.
La finalizacin de una conexin tambin involucra
el intercambio de segmentos, en este caso
transportando un indicador de control FIN.

2.8. Comunicacin de datos

Los datos que viajan en una conexin son un flujo
de octetos, en el cual el emisor determina si estos
deben ser entregados de forma inmediata el
receptor. TCP permite al emisor recopilar
informacin del usuario emisor y enviarlos al
receptor mediante segmentos, siempre y cuando
no se use la funcin push, ya que si se enva
esta, obligar al emisor a transmitir todos los datos
pendientes y as mismo el receptor identifica que
no debe esperar ms datos e iniciar el proceso de
recepcin. Se debe tener en cuenta que la funcin
push solamente se usa para transportar de forma
inmediata los datos desde el emisor al receptor.

2.9. Prioridad y seguridad

TCP utiliza los campos de tipo de servicio del
protocolo de internet y de la opcin de seguridad
para proporcionar prioridad y seguridad a los
usuarios. Los mdulos usados para esto deben
asegurar a usuarios y protocolos de ms alto nivel
una interfaz que les permita especificar el grado
de seguridad, compartimentacin y prioridad de
las conexiones.

2.10. Principio de robustez

TCP se rige por los siguientes principios:

S conservador en lo que hagas.
s liberal en lo que aceptes de los
dems.


3. ESPECIFICACION FUNCIONAL

3.1. Formato de la cabecera

La cabecera del protocolo IP posee varios campos
de informacin, como las direcciones de los 'host'
de origen y de destino, pero TCP aporta
informacin ms especfica, como se observa a
continuacin:



Fig. 3 Formato de la cabecera TCP

Puerto de origen: 16 bits (puerto de origen).
Puerto de destino: 16 bits (puerto de destino).
Nmero de secuencia: 32 bits (El nmero de
secuencia del primer octeto de datos).
Nmero de acuse de recibo: 32 bits (valor del
siguiente nmero de secuencia que el emisor del
segmento espera recibir).
Posicin de los datos: 4 bits (Este nmero indica
dnde comienzan los datos).
Reservado: 6 bits (Reservado para uso futuro.
Debe valer 0).
Bits de control: 6 bits.
URG: Hace significativo el campo "Puntero
urgente".
ACK: Hace significativo el campo "Nmero de
acuse de recibo".
PSH: Funcin de "Entregar datos inmediatamente"
('push').
RST: Reiniciar ('Reset') la conexin.
SYN: Sincronizar ('Synchronize') los nmeros de
secuencia.
FIN: ltimos datos del emisor.
Ventana: 16 bits (nmero de octetos de datos que
el emisor de este segmento est dispuesto a
aceptar).
Suma de control: 16 bits (complemento a uno de
16 bits de la suma de los complementos a uno de
todas las palabras de 16 bits).
Puntero urgente: 16 bits (apunta al nmero de
secuencia del octeto al que seguirn los datos
urgentes).
Opciones: Variable. Las opciones definidas en la
actualidad incluyen

Tipo Longitud Significado
0 - Fin de la lista de opciones.
1 - Sin operacin.
2 4 Tamao mximo de segmento.

Datos de la opcin "Mximo tamao de
segmento": 16 bits (indica el tamao
mximo de segmento que puede recibir el mdulo
de TCP que enva este segmento).
Relleno: Variable (se utiliza para asegurar que la
cabecera de TCP finaliza).

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
Opciones Relleno
Datos
Nmero de secuencia
Nmero de acuse de recibido
Posic
de los
datos
Reservado Ventana
Suma de control Puntero urgente
0 1 2 3
Puerto Origen Puerto de Destino
3.2. Terminologa

Para el mantenimiento de una conexin TCP se
requiere el almacenamiento y seguimiento de
varias variables, las cuales se almacenan en un
registro de conexin llamado "Bloque de control
de la transmisin" o TCB ('Transmission Control
Block'). A continuacin las evidenciaremos:

Variables de la secuencia de envo.

SND.UNA - envo sin acuse de recibo
recibido ('unacknowledged').
SND.NXT - envo siguiente ('next').
SND.WND - ventana ('window') de envo.
SND.UP - puntero urgente ('urgent
pointer') de envo.
SND.WL1 - nmero de secuencia del
segmento utilizado en la ltima ('last')
actualizacin de la ventana.
SND.WL2 - nmero de acuse de recibo
del segmento utilizado en la ltima
actualizacin de la ventana.
ISS - nmero de secuencia de envo
inicial ('initial send sequence').

Variables de la secuencia de recepcin.

RCV.NXT - siguiente recepcin.
RCV.WND - ventana de recepcin.
RCV.UP - puntero urgente de recepcin.
IRS - nmero de secuencia de
recepcin inicial ('initial receive
sequence').

Con el siguiente diagrama se pueden evidenciar
las variables con el espacio de secuencias.



Fig. 4 Espacio de secuencias de envo


1- Anteriores nmeros de secuencia de los que ya
se ha recibido acuse de recibo.
2- Nmero de secuencia de datos sin acuse de
recibo recibido.
3- Nmero de secuencia permitido en la siguiente
transmisin de datos.
4- Futuros nmeros de secuencia no permitidos
todava en la siguiente transmisin.

La ventana de envo es la porcin del espacio de
nmeros de secuencia etiquetada como 3 en la
figura 4.



Fig. 5 Espacio de secuencias de Recepcin.

1- Anteriores nmeros de secuencia de los que ya
se han enviado el acuse de recibo.
2- Nmeros de secuencia permitidos para una
nueva recepcin.
3- Futuros nmeros de secuencia que todava no
estn permitidos.

La ventana de recepcin es la porcin del espacio
de secuencias etiquetada como 2 en la figura 5.

Variables del segmento actual

SEG.SEQ - nmero de secuencia del
segmento.
SEG.ACK - nmero de acuse de recibo
del segmento.
SEG.LEN - longitud ('length') del
segmento.
SEG.WND - ventana del segmento.
SEG.UP - puntero urgente del segmento.
SEG.PRC - valor de prioridad del
segmento.

Una conexin posee los siguientes estados:

LISTEN: Espera de una solicitud de
conexin de cualquier TCP.
SYN-SENT: Espera de una solicitud de
conexin despus de enviar una solicitud
de conexin.
SYN-RECEIVED: Espera del acuse de
recibo confirmando la solicitud de
conexin.
ESTABLISHED: Es una conexin abierta,
fase de transferencia de una conexin.
FIN-WAIT-1: Espera de una solicitud de
finalizacin de la conexin del TCP
remoto.
FIN-WAIT-2: Espera de una solicitud de
finalizacin del TCP remoto.
CLOSE-WAIT: Espera de una solicitud de
finalizacin por parte del usuario local.
CLOSING: Espera del paquete del TCP
remoto con el acuse de recibo de la
solicitud de finalizacin.
LAST-ACK: espera del acuse de recibo
de la solicitud de finalizacin enviada al
TCP remoto.
TIME-WAIT: Espera durante el tiempo
suficiente para asegurar que el TCP
remoto recibi el acuse de recibo de su
solicitud de finalizacin de la conexin.
CLOSED: Sin conexin en absoluto.

La conexin TCP vara de un estado a otro, de
acuerdo a los siguientes 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
expiracin de plazos de tiempos.

En la siguiente figura observaremos slo los
cambios de estados, junto con los eventos
causantes y las acciones resultantes, sin tener en
cuenta errores.


Fig. 6 - Diagrama de estados de una conexin de
TCP


3.3. Nmeros de secuencia

Todo octeto de datos enviado por TCP tiene
asociado un nmero de secuencia y un acuse de
recibido. El acuse de recibido se cuenta de forma
acumulativa, lo que permite evidenciar de forma
clara y directa los duplicados por retransmisiones.
Se debe tener en cuenta que el espacio real de
nmeros de secuencia es finito, aunque muy
grande, el cual va desde 0 hasta

1. De esta
forma mostramos las comparaciones numricas
que realiza TCP.

Determinar si un acuse de recibo se
refiere a algn nmero de secuencia
envado pero del que no se ha recibido
todava su acuse de recibo.
Determinar si se ha recibido el acuse de
recibo de todos los nmeros de
secuencia ocupados por un segmento
(por ejemplo, para eliminar un segmento
de la cola de retransmisin).
Determinar si un segmento entrante
contiene nmeros de secuencia
esperados (es decir, si el segmento cabr
en la ventana de recepcin).

Tambin se realizan las siguientes comparaciones
para procesar los acuses de recibidos.

SND.UNA = El menor nmero de
secuencia sin acuse de recibo recibido.
SND.NXT = Nmero de secuencia del
prximo envo.
SEG.ACK = Acuse de recibo procedente
del TCP receptor (prximo nmero de
secuencia esperado por el TCP receptor).
SEG.SEQ = Primer nmero de secuencia
de un segmento.
SEG.LEN = El nmero de octetos
ocupados por los datos en el segmento
(incluyendo SYN y FIN).
SEG.SEQ+SEG.LEN-1 = ltimo nmero
de secuencia de un segmento.

Un nuevo acuse de recibido, es en el que la
siguiente desigualdad es verdadera.

SND.UNA < SEG.ACK =< SND.NXT

Es necesario realizar las siguientes
comparaciones cuando se reciben datos.

RCV.NXT = Siguiente nmero de
secuencia esperado de los segmentos
entrantes, lo que define el borde
izquierdo o inferior de la ventana de
recepcin.
RCV.NXT+RCV.WND-1 = ltimo nmero
de secuencia esperado en un segmento
entrante, lo que define el borde derecho o
superior de la ventana de recepcin
SEG.SEQ = Primer nmero de secuencia
ocupado por el segmento entrante
SEG.SEQ+SEG.LEN-1 = ltimo nmero
de secuencia ocupado por el segmento
entrante.

Se considera que un segmento ocupa una porcin
vlida del espacio de secuencias de recepcin en
cualquier de estos escenarios.

RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
o
RCV.NXT =< SEG.SEQ+SEG.LEN-1 <
RCV.NXT+RCV.WND


A la hora de aceptar un segmento entrante
contemplamos las siguientes posibilidades.

Longitud
Segment
o
Ventan
a recep.
Comprobacin
0 0 SEG.SEQ = RCV.NXT
0 >0
RCV.NXT =< SEG.SEQ <
RCV.NXT+RCV.WND
>0 0 No aceptable
>0 >0
RCV.NXT =< SEG.SEQ <
RCV.NXT+RCV.WND
RCV.NXT =<
SEG.SEQ+SEG.LEN-1 <
RCV.NXT+RCV.WND

Cuando el tamao de la ventana de recepcin es
0, no se acepta ningn segmento, excepto los
SCK.
El sistema de numeracin se usa para proteger
informacin de control, incluyendo indicadores de
control en espacio de secuencias que puedan ser
retransmitidas y confirmadas, sin ninguna
confusin. SIN y FIN son los nicos indicadores de
control que requieren proteccin, ya que se usan
para la apertura y cierre de la conexin.

Seleccin del nmero de secuencia Inicial

Este protocolo permite utilizar la misma conexin
varias veces, es decir el mismo par de conectores.
Para evitar confusiones en el envo de datos se
debe evitar que la encarnacin de una conexin
utilice nmeros de secuencia que an sean
utilizados. Para ello TCP utiliza un ISN asociado a
un reloj ficticio que rota aproximadamente cada
4.55 horas, este es el tiempo de vida del
segmento en la red.
En TCP existe el nmero de secuencia de envo y
recepcin, el de envo lo elige el TCP emisor y el
destino se asume durante la conexin.
Para que la conexin se realice ambos TCP deben
sincronizarse por medio de nmeros de
secuencia, a travs del segmento de secuencia
SYN o bit de control. En la sincronizacin, cada
parte debe enviar nmero de secuencia inicial y
recibir confirmacin de la llegada, este proceso lo
hacen ambas partes como se describe a
continuacin.

1) A --> B SYN mi nmero de secuencia es X
2) A <-- B ACK tu nmero de secuencia es X
3) A <-- B SYN mi nmero de secuencia es Y
4) A --> B ACK tu nmero de secuencia es Y

Los pasos 2 y 3 se ejecutan en el mismo mensaje
(acuerdo en 3 pasos). Es necesario este acuerdo
en 3 pasos, ya que los nmeros de secuencia no
estn sujetos a ningn reloj y el receptor no podra
identificar el primer segmento.

Saber cundo permanecer en silencio

TCP para asegurarse de no generar un segmento
con un nmero de secuencia que ya se encuentra
en la red, permanece en silencio durante el tiempo
de vida del segmento, esto se hace antes de
asignar cualquier nmero despus de recuperarse
de alguna cada.

El concepto de "tiempo en silencio" ('Quiet
Time') de TCP

Para los host que ingresen a la red, sin tener
informacin de los nmeros de secuencia
transmitidos, no deben enviar ningn segmento al
menos durante el tiempo de vida que tengan estos
y se haya acordado previamente.
TCP consume el espacio de los nmeros de
secuencia segn se forman los segmentos en la
cola de salida del host origen.
Normalmente TCP lleva la cuenta del siguiente
nmero de secuencia y del ltimo acuse de recibo,
para evitar usar equvocamente un nmero de
secuencia.
El algoritmo que usa TCP para la deteccin de
duplicados y de secuenciacin puede confundirse
si un TCP de origen no mantiene ninguna
memoria de los nmeros de secuencia. En estos
casos se recomienda que el origen retrase la
emisin de cualquier segmento en la conexin
durante el tiempo de vida del nmero de
secuencia, para asegurar que estos nmeros
desaparezcan de la red.


3.4. Establecimiento de una Conexin

El procedimiento inicia con un TCP y responde
otro TCP distinto, tambin funciona de forma
simultnea. A continuacin, se dan algunos
ejemplos de iniciacin de conexin.

: Indica la salida de un segmento TCP o la
llegada de un segmento.
: Indica lo contrario al anterior.
(..): Indican un segmento que todava est en la
red.
XXX: indica un segmento que se perdi o fue
rechazado.




Fig. 7 - Acuerdo en 3 pasos bsico de
sincronizacin de la conexin

En la lnea 2, el TCP A enva un segmento SYN
que indica que va a utilizar nmeros de secuencia
comenzando por el 100. En la lnea 3, el TCP B
enva un SYN confirmando la recepcin del SYN
que le envi el TCP A. Ntese que el campo de
acuse de recibo indica que el TCP B est
esperando recibir el 101 de la secuencia,
confirmado la recepcin del SYN que ocup el
lugar 100 de la secuencia. En la lnea 4, el TCP A
responde con un segmento vaco conteniendo un
ACK para el SYN del TCP B; y en la lnea 5, el
TCP A enva algunos datos. El nmero de
secuencia del segmento en la lnea 5 es el mismo
que el de la lnea 4 porque el ACK no consume un
nmero del espacio de secuencias.



Fig. 8 - Sincronizacin simultnea de la conexin



Fig. 9 - Recuperacin ante un SYN duplicado
anterior.

Como ejemplo de una recuperacin ante la
presencia de duplicados anteriores, tomamos, la
figura 9. En la lnea 3, un SYN duplicado anterior
llega al TCP B. El TCP B no puede discernir si se
trata de un duplicado anterior, y por tanto
responde de forma normal (lnea 4). El TCP A
detecta que el campo ACK es incorrecto y
devuelve un RST ("reset") con su campo SEQ
elegido de tal forma que el segmento sea creble.
El TCP B, al recibir el RST, vuelve al estado
LISTEN. Cuando el SYN original (N.T: en el
original ingls aqu aparece entre parntesis la
expresin "juego de palabras intencionado", ya
que 'original SYN' se pronuncia igual en ingls que
"pecado original") llega finalmente al otro extremo
en la lnea 6, la sincronizacin procede de forma
normal. Si el SYN de la lnea 5 hubiera llegado
antes que el RST, podra haberse dado un
intercambio ms complejo con RST enviados en
ambas direcciones.

Conexiones medio abiertas y otras
anomalas

Se llama conexin medio abierta, cuando uno de
los extremos cierra la conexin sin notificar a la
otra parte o por desincronizacin por cada. A
continuacin un ejemplo de esta conexin.



Fig. 10 - Descubrimiento de una conexin "medio
abierta"

TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT <SEQ=100><CTL=SYN> SYN-RECEIVED
3. ESTABLISHED <SEQ=300><ACK=101><CTL=SYN,ACK> SYN-RECEIVED
4. ESTABLISHED <SEQ=101><ACK=301><CTL=ACK> ESTABLISHED
5. ESTABLISHED <SEQ=101><ACK=301><CTL=ACK><DATOS> ESTABLISHED
TCP A TCP B
1. CLOSED CLOSED
2. SYN-SENT <SEQ=100><CTL=SYN> .
3. SYN-RECEIVED <SEQ=300><CTL=SYN> SYN-SENT
4. . <SEQ=100><CTL=SYN> SYN-RECEIVED
5. SYN-RECEIVED <SEQ=100><ACK=301><CTL=SYN,ACK> .
6. ESTABLISHED <SEQ=300><ACK=101><CTL=SYN,ACK> SYN-RECEIVED
7. .. <SEQ=101><ACK=301><CTL=ACK> ESTABLISHED
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT <SEQ=100><CTL=SYN> .
3. (duplicado) .. <SEQ=90><CTL=SYN> SYN-RECEIVED
4. SYN - SENT <SEQ=300><ACK=91><CTL=SYN,ACK> SYN-RECEIVED
5. SYN - SENT <SEQ=91><CTL=RST> LISTEN
6. .. <SEQ=100><CTL=SYN> SYN-RECEIVED
7. SYN - SENT <SEQ=400><ACK=101><CTL=SYN,ACK> SYN-RECEIVED
8. ESTABLISHED <SEQ=101><ACK=401><CTL=ACK> ESTABLISHED
TCP A TCP B
1. (CADA) (enviar el 300, recibir el 100)
2. CLOSED ESTABLISHED
3. SYN - SENT <SEQ=400><CTL=SYN> (??)
4. (!!) <SEQ=300><ACK=100><CTL=ACK> ESTABLISHED
5. SYN - SENT <SEQ=100><CTL=RST> (Interrumpir )
6. SYN - SENT CLOSED
7. SYN - SENT <SEQ=400><CTL=SYN>
En la lnea 3, el SYN llega, el TCP de B, estando
en un estado sincronizado y el segmento entrante
siendo mayor que la ventana, responder con un
acuse de recibo indicando qu nmero de
secuencia espera recibir a continuacin (ACK
100). El TCP de A aprecia que este segmento no
confirma nada envado y, estando desincronizado,
enva un 'reset' (RST) porque ha detectado que la
conexin est medio-abierta. En la lnea 5, el TCP
de B interrumpe la conexin. EL TCP de A
continuar intentando reestablecer la conexin; el
problema queda reducido ahora al acuerdo en tres
pasos bsico descrito en la figura.



Fig. 11 - Un extremo activo causa el
descubrimiento de una conexin "medio abierta"

En la figura 12, encontramos los TCP de A y de B
ambos con conexiones pasivas esperando un
SYN.



Fig. 12 - Un SYN anterior duplicado inicia un reset'
en dos conectores pasivos

Generacin de reinicios resets

Slo se enva cuando llegue un segmento que no
est destinado para la conexin.
Existen 3 estados:

1. Si la conexin no existe, se enva un reset como
respuesta a cualquier segmento entrante.
2. Si la conexin est en cualquier estado no
sincronizado.
3. Si la conexin est en un estado sincronizado.

Procesamiento de resets.

En todos los estados exceptuando SYN-SENT, los
segmentos de tipo 'reset' son validados
comprobando sus campos SEQ, este es vlido si
su nmero de secuencia est dentro de la
ventana.
El receptor de un RST primero lo comprueba y
cambia de estado 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 conexin y pasa al estado CLOSED.
Si el receptor, estaba en cualquier otro estado,
interrumpe la conexin, avisa de ello al usuario y
pasa al estado CLOSED.

3.5 Cierre de una conexin

CLOSE (N.T.: "cerrar" en ingls) es una operacin
que significa "no tengo ms datos que enviar". a
nocin de cerrar una conexin bidireccional tiene
una interpretacin ambigua, desde luego, dado
que puede no resultar obvio como tratar a la parte
receptora de la conexin. 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 tambin la
conexin 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 conexin con un CLOSE. Se
asume que TCP idicar al usuario que el otro lado
de la conexin ha cerrado sta incluso si no hay
llamadas RECEIVE pendientes, de forma que
pueda cerrar su conexin limpiamente. Una
conexin TCP entregar de forma fiable todos los
bferes enviados en llamadas SENT antes de que
la conexin sea cerrada, de forma que un usuario
que no espera datos de respuesta slo necesite
esperar a que la conexin 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 envo hasta que TCP notifique que no
hay ms datos.

Existen fundamentalmente tres casos:

1) El usuario inicia el cierre de la conexin
enviando la llamada CLOSE a TCP.

2) El TCP remoto inicia el cierre enviando una
seal de control FIN.

3) Ambos usuarios realizan la llamada CLOSE
simultneamente.

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 ms llamadas SEND y entrar en el
estado FIN-WAIT-1. En este estado se permiten
las llamadas RECEIVE. Todos los segmentos que
TCP A TCP B
1. (CADA) (enviar el 300, recibir el 100)
2. (??) <SEQ=300><ACK=100><DATA=10><CTL=ACK> ESTABLISHED
3. <SEQ=100><CTL=RST> (INTERRUMPIR!!)
TCP A TCP B
1. LISTEN LISTEN
2. .. <SEQ=Z><CTL=SYN> SYN-RECEIVED
3. (??) <SEQ=X><ACK=Z+1><CTL=SYN,ACK> SYN-RECEIVED
4. <SEQ=Z+1><CTL=RST> (vuelve a LISTEN)
5. LISTEN LISTEN
preceden al FIN, incluido ste, sern
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. Ntese
que un TCP que recibe un FIN enviar su ACK
pero no enviar su propio FIN hasta que su
usuario haya cerrado tambin la conexin 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 conexin 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 conexin. Si el ACK no llega en el
tiempo de espera del usuario, la conexin se
aborta y as se notifica al usuario.

Caso 3: ambos usuarios cierran simultneamente
El cierre simultneo a ambos lados de la conexin
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 recepcin de
los ACK, eliminarn la conexin.

3.6. Prioridad y seguridad
La intencin es que la conexin slo se permita
entre puertos que operen exactamente con los
mismos valores de seguridad y compartimentacin
y con un nivel de prioridad igual al mayor de los
solicitados por ambos puertos.
Los parmetros de prioridad y seguridad usados
en TCP son exactamente los definidos en el
protocolo de internet (IP) [2]. A lo largo de esta
especificacin de TCP el trmino
"seguridad/compartimentacin" indica los
parmetros de seguridad utilizados por IP que
incluye los de seguridad, compartimentacin,
grupo de usuario y manejo de restricciones.
Un intento de conexin con valores de
seguridad/compartimentacin errneos o con un
nivel de prioridad menor debe ser rechazado
enviando un 'reset'. El rechazo de una conexin
debido a un nivel de prioridad demasiado bajo
ocurre solamente tras la recepcin del acuse de
recibo del SYN.
Ntese que los mdulos de TCP que operan
nicamente al nivel de prioridad por defecto
debern comprobar un as la prioridad de los
segmentos entrantes y posiblemente elevar el
nivel de prioridad que usen en la conexin.
Los parmetros de seguridad pueden ser
utilizados incluso en un entorno inseguro (los
valores indicaran datos reservados secretos), por
lo que las mquinas en entornos inseguros deben
estar preparadas para recibir los parmetros de
seguridad, aunque no es obligatorio que los
enven.
3.7. Comunicacin de datos

Una vez establecida la conexin los datos se
transmiten mediante el intercambio de segmentos.
Dado que los segmentos pueden perderse debido
a errores (fallo en la suma de comprobacin) o
congestin de la red, TCP utiliza la retransmisin
(tras un tiempo de espera) para asegurar la
entrega de cada segmento. Pueden llegar
segmentos duplicados debido a la red o a la
retransmisin de TCP. Tal y como se explica en la
seccin sobre nmeros de secuencia, TCP realiza
ciertas comprobaciones sobre los nmeros de
secuencia y de acuse de recibo en los segmentos
para verificar su admisibilidad.
El emisor de los datos mantiene un registro del
prximo nmero de secuencia a usar en la
variable SND.NXT. El receptor de los datos
mantiene un registro del siguiente nmero de
secuencia esperado en la variable RCV.NXT. El
emisor mantiene tambin un registro del nmero
de secuencia sin acuse de recibo menor en la
variable SND.UNA. Si el flujo de datos queda
momentneamente inactivo y de todos los datos
enviados se tiene acuse de recibo entonces las
tres variables sern idnticas.
Cuando el emisor crea un segmento y lo
transmite, incrementa SND.NXT. Cuando el
receptor acepta un segmento incrementa
RCV.NXT y enva un acuse de recibo. Cuando el
emisor de los datos recibe un acuse de recibo
incrementa SND.UNA. La diferencia entre los
valores de estas variables es una medida del
retardo en la comunicacin. El valor en el cual se
incrementan estas variables es el de la longitud de
los datos del segmento. Ntese que, una vez en el
estado ESTABLISHED todos los segmentos
deben llevar la informacin del acuse de recibo
actualizada.
La llamada de usuario CLOSE implica la funcin
de entrega inmediata 'push', tal y como sucede
con el indicador de control FIN en un segmento
entrante.
Tiempo de espera de retransmisin
Debido a la variabilidad de las redes que
componen un sistema de redes de internet y la
gran cantidad de casos de conexiones TCP el
tiempo de espera de retransmisin se debe
determinar dinmicamente. Se ilustra a
continuacin un procedimiento para determinar un
tiempo de espera de retransmisin.
Un ejemplo de procedimiento de tiempo de
espera de retransmisin
Mdase el tiempo transcurrido entre el envio de un
octeto de datos con un nmero de secuencia
determinado y la recepcin de un acuse de recibo
que incluya ese nmero de secuencia (los
segmentos enviados no tienen por qu concordar
con los segmentos recibidos). Este tiempo medido
es el "tiempo de ida y vuelta ('Round Trip Time' o
RTT). Calclese despus el "tiempo de ida y
vuelta suavizado" ('Smoothed Round Trip Time' o
SRTT) como (N.T.: esta frmula aparece
exactamente as en el original): SRTT = ( ALPHA *
SRTT ) + ((1-ALPHA) * RTT) y basndose en este,
calclese el tiempo de espera de retransmisin
(RTO) como: RTO =
min[COTASUP,max[COTAINF,(BETA*SRTT)]]
donde COTASUP es una cota superior del tiempo
de espera (i.e., 1 minuto), COTAINF es una cota
inferior del tiempo de espera (i.e., 1 segundo),
ALPHA es un factor de suavizado (i.e., entre 0,8 y
0,9) y BETA es un factor de varianza del retardo
(i.e., entre 1,3 y 2,0).
La comunicacin de informacin urgente El
objetivo del mecanismo de urgencia de TCP
consiste en permitir al usuario emisor la
posibilidad de estimular al usuario receptor para
que acepte ciertos datos urgentes y en permitir al
TCP receptor que indique al usuario receptor
cundo se le han entregado todos los datos
urgentes conocidos hasta el momento.
Este mecanismo permite elegir un punto en el flujo
de datos como el final de la informacin urgente.
Siempre que este punto est ms adelante del
nmero de secuencia de recepcin (RCV.NXT) en
el TCP receptor, ste debe avisar al usuario para
que cambie al "modo urgente"; cuando el nmero
de secuencia de recepcin alcance el puntero
urgente, TCP debe avisar al usuario que cambie al
"modo normal". Si el puntero urgente se actualiza
mientras el usuario est en el "modo urgente",
dicha actualizacin no ser visible para el usuario.
El mtodo emplea un campo urgente em todos los
segmentos transmitidos. El indicador de control
URG indica que el campo urgente tiene significado
y debe ser aadido al nmero de secuencia de
segmento para obtener el puntero urgente. La
ausencia de este indicador denota la ausencia de
datos urgentes. Para enviar una indicacin de
urgencia el usuario debe enviar tambin al menos
un octeto de datos. Si el usuario emisor indica
tambin una llamada 'push', entonces se acelera
la entrega de la informacin urgente al proceso de
destino.
Manejo de la ventana
La ventana, que se envia en cada segmento,
indica el rango de nmeros de secuencia que el
emisor de la ventana (el receptor de los datos)
est preparado para aceptar en ese momento. Se
supone que normalmente este rango est
relacionado con el espacio de almacenamiento de
datos disponible en ese momento para la
conexin.
Indicar una ventana grande favorece las
transmisiones. Si llegan ms datos de los que
pueden ser aceptados, sern descartados. Esto
resultar en un exceso de retransmisiones,
aadiendo una carga innecesaria a la red y a los
mdulos de TCP. Indicar una ventana pequea
puede restringir la transmisin de datos hasta el
punto de introducir un retardo de ida y vuelta entre
cada nuevo segmento transmitido.
Los mecanismos proporcionados permiten a un
TCP anunciar una ventana grande y
seguidamente anunciar una mucho menor sin
tener que aceptar todos los datos. Esta prctica,
conocida como "reduccin la ventana", no se
recomienda bajo ningn concepto. El principio de
robustez dicta que cada mdulo de TCP no
reducir la ventana por s mismo, pero s que
deben estar preparados para esperar este
comportamiento por parte de otros TCP.
El TCP emisor debe estar preparado para aceptar
datos del usuario y enviar al menos un octeto de
nuevos datos, incluso si el tamao de la ventana
de envo es cero. El TCP emisor debe retransmitir
regularmente al receptor TCP incluso cuando el
tamao de la ventana es cero. Cuando el tamao
de la ventana es cero, se recomienda un intervalo
de retransmisin de dos minutos. Esta
retransmisin es esencial para garantizar que,
siempre que uno de los TCP tenga una ventana
de tamao cero, la reapertura de la ventana sea
notificada de forma fiable al otro.
Cuando el TCP receptor tiene una ventana de
tamao cero y llega un segmento debe todava
enviar un acuse de recibo con su prximo nmero
de secuencia esperado y su tamao de ventana
actual (cero).
El TCP emisor empaqueta los datos para
transmitir en segmentos que caben en la ventana
actual y puede que re empaquete segmentos de la
cola de retransmisin. Este re empaquetamiento
no es obligatorio, pero puede resultar til.
En una conexin con un flujo de datos de una sola
direccin, la informacin de la ventana se
transmite en segmentos de acuse de recibo, todos
con el mismo nmero de secuencia, de manera
que no hay forma de reordenarlos si llegan
desordenados. Este no es un problema serio, pero
permite que en ocasiones la informacin de
ventana est basada en informacin anticuada del
receptor. Un refinamiento para evitar este
problema consiste en escoger la informacin de
ventana de los segmentos con el nmero de
acuse de recibo ms alto (es decir, los segmentos
con nmero de acuse de recibo igual o mayor que
el ms alto recibido hasta el momento).
El procedimiento de gestin de ventana tiene una
influencia significativa sobre el rendimiento de la
comunicacin. Los comentarios siguientes son
sugerencias para los implementadores.
Sugerencias sobre la gestin de la ventana
Disponer de una ventana muy pequea provoca
que los datos sean transmitidos en muchos
segmentos pequeos, cuando se puede conseguir
un mejor rendimiento usando menos segmentos
de mayor tamao.
Una sugerencia para evitar las ventanas pequeas
es que el receptor retrase la actualizacin de una
ventana hasta que el tamao disponible sea al
menos un X por ciento del tamao mximo posible
para la conexin (donde X podra estar entre 20 y
40).
Otra sugerencia consiste en que el emisor evite el
envo de pequeos segmentos esperando hasta
que la ventana sea lo bastante grande para enviar
los datos. Si el usuario indica una funcin de
entrega inmediata 'push' entonces los datos
debern ser enviados incluso si se trata de un
segmento pequeo.
Ntese que los acuses de recibo no deben
retrasarse o se producirn retransmisiones
innecesarias. Una estrategia podra consistir en
enviar un acuse de recibo cuando llega un
segmento pequeo (sin actualizar la informacin
de ventana), y luego enviar otro acuse de recibo
con la nueva informacin de ventana cuando sta
sea mayor.
El segmento que se enva para sondear una
ventana de tamao cero puede tambin dar
comienzo a un particionado de los datos
transmitidos en segmentos ms y ms pequeos.
Si un segmento que contiene un nico octeto de
datos enviado para sondear una ventana de
tamao cero se acepta entonces se consume un
octeto de la ventana ahora disponible. Si el TCP
emisor simplemente enva todo lo que puede
como cuando el tamao de la ventana es distinto
de cero, los datos transmitidos sern partidos en
segmentos alternativamente grandes y pequeos.
Conforme avance el tiempo, las pausas
ocasionales en el receptor para permitir el ajuste
de la ventana producirn una particin de cada
segmento grande en uno pequeo y otro no tan
grande como el original. Despus de un rato la
transmisin de datos se producir en su mayor
parte en segmentos pequeos.
La sugerencia aqu es que las implementaciones
de TCP tienen que intentar, de forma activa,
combinar las ventanas pequeas en ventanas de
mayor tamao, dado que en las implementaciones
simples, los mecanismos de gestin de ventana
tienden a producir muchas ventanas pequeas.
3.8. Interfaces
Existen, por supuesto, dos interfaces de inters: 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 especificacin del
protocolo de nivel inferior. Para el caso en que el
protocolo de nivel inferior sea IP, apuntamos
algunos de los valores de los parmetros que los
TCP pueden utilizar.
Interfaz usuario/TCP
La siguiente descripcin funcional de las rdenes
de usuario al mdulo 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 mnimo de servicios para garantizar que
todas las implementaciones TCP pueden soportar
la misma jerarqua de protocolo. Esta seccin
especfica 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 notacin
utilizada es similar a la mayora de las llamadas a
procedimiento o funcin 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 ms abajo
especifican las funciones bsicas que debe
ejecutar TCP para soportar la comunicacin entre
procesos. Las implementaciones individuales
deben definir su propio formato exacto, y pueden
proporcionar combinaciones o subconjuntos de las
funciones bsicas en llamadas simples. En
particular, algunas implementaciones pueden
querer realizar la llamada de apertura OPEN de la
conexin automticamente en el primer SEND o
RECEIVE enviado por el usuario para una
conexin dada.

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
conexin especificada. Dependiendo de la
implementacin del TCP, los identificadores del
TCP y de la red local sern proporcionados bien
por el mdulo de TCP o bien por el protocolo de
nivel inferior (i.e. IP). Estas consideraciones
derivan de cuestiones de seguridad, de forma que
ningn TCP pueda hacerse pasar por otro, y as
sucesivamente. De forma similar, ningn proceso
puede hacerse pasar por otro sin la connivencia
del mdulo de TCP.
Si el indicador 'active'/'passive' est puesto a
'passive', entonces sta ser una llamada para
escuchar (LISTEN) una conexin entrante. Un
OPEN pasivo puede tener o bien un conector
remoto completamente especificado para esperar
una conexin particular o un conector remoto sin
especificar para esperar cualquier llamada. Una
llamada pasiva completamente especificada
puede activarse mediante la ejecucin
subsecuente de un SEND.
Se crea un bloque de control de transmisin
('Transmision control block' o TCB) y se rellena
parcialmente con los datos de los parmetros de
la orden OPEN. En una orden OPEN activa, el
TCP iniciar el procedimiento para sincronizar (es
decir, establecer) la conexin en una sola vez.
El tiempo de espera, si est presente, permite al
llamador aplicar un tiempo de espera para todos
los datos enviados por el TCP. Si los datos no se
entregan con xito en el destino dentro del tiempo
de espera, TCP interrumpir la conexin. El valor
por defecto estndar en la actualidad es de 5
minutos. TCP o algn componente del sistema
operativo verificar la autorizacin de los usuarios
para abrir una conexin con los valores de
prioridad o seguridad/compartimentacin
especificados. La ausencia de valores de prioridad
o seguridad/compartimentacin en la llamada
OPEN indica que se deben utilizar los valores por
defecto. TCP aceptar peticiones entrantes como
vlidas solamente si la informacin sobre
seguridad/compartimentacin es exactamente la
misma y slo si la prioridad es igual o mayor que
la prioridad solicitada en la llamada OPEN.
La prioridad en la conexin es el mayor de los
valores solicitados en la llamada OPEN y recibidos
de la solicitud entrante, y fijado a este valor
durante el resto de la conexin. Los
implementadores pueden querer dar el control de
la negociacin de la prioridad al usuario. Por
ejemplo, se podra permitir al usuario especificar
que la prioridad sea exactamente la misma, o que
cualquier intento de elevar la prioridad sea
confirmado por el usuario.
TCP devolver al usuario el nombre de la
conexin local. Este nombre puede ser usado
despus como un atajo para denotar la conexin
definida por el par <conector local, conector
remoto>. Send (N.T: "enviar" en ingls) Formato:
SEND (nombre de la conexin local, direccin del
bfer, contador de bytes, indicador PUSH,
indicador URGENT [, tiempo de espera])
Esta llamada hace que se enven mediante la
conexin indicada los datos contenidos en el bfer
de usuario indicado. Si la conexin 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 automtico. Si el proceso
llamador no est autorizado a usar esta conexin,
se devuelve un error. Si el indicador PUSH est
activado, los datos deben ser transmitidos cuanto
antes al receptor, y se activar el indicador PUSH
en el ltimo segmento TCP creado a partir del
bfer. Si el indicador PUSH no est activado, los
datos pueden ser combinados con datos de
llamadas SEND subsiguientes en favor de la
eficiencia de la transmisin.
Si el indicador URGENT est activado, los
segmentos enviados al TCP de destino tendrn un
valor en el campo de puntero urgente.
El TCP receptor sealar la condicin de urgencia
al proceso receptor si el puntero urgente indica
que los datos que le preceden no han sido
consumidos por el proceso receptor. El propsito
de este indicador es estimular al receptor para que
procese los datos urgentes e indicar al receptor
cuando se han recibido todos los datos urgentes
actualmente conocidos. El nmero de veces que
el TCP del usuario emisor seala una condicin de
urgencia no ser necesariamente igual al nmero
de veces que el usuario receptor ser notificado
de la presencia de datos urgentes.
Si no se ha especificado un conector remoto en la
llamada OPEN, pero se establece la conexin
(i.e., debido a que una conexin en estado de
escucha LISTEN se ha hecho especfica debido a
la llegada de un segmento remoto al conector
local), se enva el bfer indicado al conector
remoto implcito. Los usuarios que hacen uso de la
llamada OPEN sin especificar un conector remoto
pueden usar la llamada SEND sin conocer
explcitamente la direccin del conector remoto.
Sin embargo, si se intenta una llamada SEND
antes de que el conector remoto se haya vuelto
especfico, se devolver un error. Los usuarios
pueden utilizar la llamada STATUS para
determinar el estado de la conexin. En algunas
implementaciones TCP puede notificar al usuario
cundo un conector sin especificar queda fijado.
Si se especifica un tiempo de espera, el tiempo
de espera actual para esta conexin se cambia al
nuevo valor. En la implementacin ms simple, la
llamada SEND no devolver el control al usuario
hasta que se complete la transmisin o se supere
el tiempo de espera. Sin embargo, este mtodo
simple est sujeto a puntos muertos ('deadlocks')
(por ejemplo, ambos lados de la conexin podran
intentar realizar operaciones SEND antes de hacer
ninguna operacin RECEIVE) y ofrece un
rendimiento pobre, por lo cual no se recomienda.
Una implementacin ms sofisticada devolver el
control inmediatamente para permitir al proceso
ejecutarse concurrentemente con la E/S de red y,
adems, permitir que mltiples operaciones SEND
tengan lugar a la vez. Las operaciones SEND
mltiples son atendidas segn van llegando, de
forma que TCP pondr en cola aquellas a las que
no puede atender inmediatamente.
Hemos asumido implcitamente una interfaz de
usuario asncrona en la cual una llamada SEND
provoca ms tarde algn tipo de seal o pseudo-
interrupcin en el TCP servidor. Una posible
alternativa es devolver una respuesta
inmediatamente. Por ejemplo, las llamadas SEND
podran devolver un acuse de recibo local
inmediato, incluso si el acuse de recibo del
segmento enviado no ha sido an recibido. Se
puede asumir, de forma optimista, que la
operacin tendr eventualmente xito. Si no es
as, la conexin se cerrar de todas formas debido
a la superacin del tiempo de espera. En
implementaciones de este tipo (sncronas),
existirn todava algunas seales asncronas, pero
stas estarn relacionadas con la propia conexin,
no con segmentos o bferes especficos.
Con objeto de que el proceso distinga entre las
distintas indicaciones de error o xito
correspondientes a las distintas llamadas SEND,
puede resultar apropiado devolver la direccin del
bfer junto con la respuesta codificada a la
solicitud SEND. Las seales de TCP al usuario se
discuten ms abajo, indicando qu informacin
debe ser devuelta al proceso llamador.
Receive (N.T: "recibir" en ingls) Formato:
RECEIVE (nombre de la conexin local, direccin
del bfer, nmero de bytes) -> nmero de bytes,
indicador 'urgent', indicador 'push'.
Esta orden inicializa un bfer de recepcin
asociado con la conexin especificada. Si esta
orden no viene precedida de una llamada OPEN o
el proceso solicitante no est autorizado a usar
esta conexin, se devuelve un error. En la
implementacin ms simple, el control no volver
al programa solicitante hasta que el bfer se llene
u ocurra algn error, pero este esquema tiene un
alto riesgo de puntos muertos. Una
implementacin ms sofisticada permitira que
varios RECEIVE se ejecutaran a la vez. Estos se
iran completando segn van llegando los
segmentos. Esta estrategia permite incrementar el
rendimiento a costa de un esquema ms
elaborado (posiblemente asncrono) para notificar
al programa solicitante que se ha detectado una
llamada de entrega inmediata PUSH o se ha
llenado un bfer.
Si llegan datos suficientes como para llenar el
bfer antes de que se detecte el PUSH, el
indicador PUSH no se activar en la respuesta al
RECEIVE. El bfer ser llenado con tantos datos
como le quepan. Si se detecta un PUSH antes de
que el bfer est lleno, ste ser devuelto
parcialmente lleno y con el indicador PUSH
activado.
Si hay datos urgentes el usuario habr sido
informado tan pronto como llegaron por medio de
una seal de TCP al usuario. El usuario receptor
debe entonces estar en 'modo urgente'. Si el
indicador URGENT est activado, es que quedan
todava datos urgentes. Si est desactivado, esta
llamada a RECEIVE ha devuelto todos los datos
urgentes y el usuario puede ahora abandonar el
"modo urgente". Ntese que los datos que siguen
al puntero urgente (datos no urgentes) no pueden
ser entregados al usuario en el mismo bfer con
los datos urgentes precedentes a menos que el
lmite entre ellos est claramente marcado para el
usuario.
Para distinguir entre varias llamadas RECEIVE
pendientes y para tener en cuenta el caso de un
bfer no saturado, el cdigo de retorno viene
acompaado de un puntero al bfer y un nmero
de bytes que indica la longitud de los datos
recibidos.
En algunas implementaciones alternativas, el
TCP se encargara de reservar el espacio de
almacenamiento para el bfer, o bien podra
compartir un bfer circular con el usuario.
CLOSE
Formato: CLOSE (nombre de la conexin local)
Esta orden cierra la conexin especificada. Si la
conexin no est abierta o el proceso solicitante
no est autorizado a usar dicha conexin, se
devuelve un error. El cierre de conexiones est
pensado para que sea una operacin limpia en el
sentido de que las llamadas SEND pendientes
sern 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
sern enviados a su destino. Debe quedar claro
que los usuarios pueden continuar recibiendo por
conexiones que se estn cerrando, ya que el otro
lado de la conexin puede estar intentando
transmitir el resto de sus datos. Por tanto, cerrar
una conexin significa "no tengo nada ms que
enviar" pero no "no recibir nada ms". Puede
suceder (si el protocolo del nivel de usuario no
est bien ideado) que el lado de la conexin 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 conexin deja de seguir.
La orden CLOSE implica la funcin de entrega
inmediata 'push'. Status (N.T. "estado" en ingls)
Formato: STATUS (nombre de la conexin local) -
> datos de estado
Esta orden devuelve un bloque de datos que
contiene la siguiente informacin: conector local,
conector remoto, nombre de la conexin local,
ventana de recepcin, ventana de envo, estado
de la conexin, nmero de bferes en espera del
acuse de recibo, nmero de bferes pendientes de
recepcin, estado urgente, prioridad,
seguridad/compartimentacin, y tiempo de espera
de transmisin
Dependiendo del estado de la conexin, o de la
implementacin misma, parte de esta informacin
puede no estar disponible o no tener ningn
significado til. Si el proceso solicitante no est
autorizado a utilizar esta conexin se devuelve un
error.
Esto evita que los procesos no autorizados
puedan obtener informacin sobre una conexin.

ABORT
Formato: ABORT (nombre de la conexin local)
Esta orden aborta la ejecucin de todas las
rdenes SEND y RECEIVE pendientes, elimina el
TCB y enva un mensaje especial RESET al otro
lado de la conexin. Dependiendo de la
implementacin, los usuarios puede recibir avisos
de abandono por cada orden SEND o RECEIVE
pendiente, o simplemente recibir una confirmacin
de la ejecucin de la orden ABORT.
Mensajes de TCP a usuario
Se da por supuesto que el sistema operativo
proporciona algn medio para que TCP pueda
enviar una seal asncrona al programa de
usuario. Cuando TCP enva una seal a un
programa de usuario pasa cierta informacin al
usuario. A menudo en la especificacin la
informacin ser un mensaje de error. En otros
casos habr informacin relativa a la finalizacin
del procesamiento de una orden SEND o
RECEIVE o cualquier otra llamada del usuario.
3.9. Procesamiento de eventos
El procesamiento explicado en esta seccin es un
ejemplo de una posible implementacin. Otras
implementaciones pueden tener secuencias de
procesamiento ligeramente diferente, pero slo en
los detalles, no en lo esencial.
Se puede caracterizar la actividad del TCP como
una serie de respuestas a eventos. Los eventos
posibles se pueden clasificar en tres categoras:
llamadas del usuario, segmentos entrantes y fin de
tiempos de espera. Esta seccin describe el
procesamiento que realiza TCP en respuesta a
cada uno de estos eventos. En muchos casos el
procesamiento necesario depende del estado de
la conexin
Una forma natural de pensar en el procesamiento
de segmentos entrantes es imaginar que primero
se comprueba que su nmero de secuencia sea el
adecuado (es decir, que su contenido caiga dentro
del rango de la "ventana de recepcin" esperada
en el espacio de nmeros de secuencia) y que
despus generalmente son puestos en cola y
procesados segn el orden por nmeros de
secuencia.
Cuando un segmento se solapa con otros
segmentos ya recibidos se reconstruye el
segmento de forma que contenga nicamente los
nuevos datos, y se ajustan los campos de
cabecera para que sean consistentes.
Ntese que si no se menciona un cambio de
estado TCP permanece en el mismo estado.
ESTADO 'CLOSE-WAIT'
Dado que la parte remota ya ha enviado un FIN,
los RECEIVE debern ser rellenados con texto ya
disponible, pero an no entregado al usuario. Si
no hubiera texto en espera para ser entregado, el
RECEIVE obtendr una respuesta 'error:
connection closing' ("error: cerrando la conexin").
En caso contrario, cualquier texto presente podr
usarse para alimentar el RECEIVE.
ESTADO 'ESTABLISHED'
Se deja en cola hasta que todas las rdenes
SEND precedentes hayan sido segmentadas,
entonces se construye un segmento FIN y se
enva. En cualquier caso, se pasa al estado FIN-
WAIT-1.
ESTADO 'FIN-WAIT-1'
ESTADO 'FIN-WAIT-2'
Estrictamente hablando, se trata ste de un error,
y debera recibir una respuesta 'error: connection
closing'. Una respuesta 'ok' ("correcto") sera
aceptable tambin, ya que no se ha emitido an
un segundo FIN (no obstante, el primer FIN puede
ser retransmitido).
Los segmentos se procesan secuencialmente.
Aunque se practican comprobaciones iniciales de
llegada con objeto de descartar los duplicados
caducados, se efecta un procesado ulterior en el
orden segn SEG.SEQ. Si los contenidos de un
segmento produjeran un solapamiento de
fronteras entre segmentos viejos y nuevos, slo
debern procesarse las partes nuevas.
ESTADO 'ESTABLISHED'
Si la seguridad/compartimentacin y prioridad del
segmento no coincidieran exactamente con la
seguridad/compartimentacin y prioridad del TCB,
deber enviarse una orden de reinicio, y
cualesquiera RECEIVEs y SEND debern recibir
respuestas "reset". Todas las colas de segmento
debern ser inicializadas. Los usuarios debern
tambin recibir un aviso unilateral general de
"connection reset". Se pasa al estado CLOSED,
se borra el TCB, y se retorna.
Ntese que esta comprobacin se ubica a
continuacin de la comprobacin de secuencia
para evitar que un segmento procedente de una
conexin anterior entre los mismos puertos y con
distintos valores de seguridad o prioridad origine
una interrupcin de la conexin actual.
GLOSARIO
ACK, Un bit de control (del ingls
'acknowledge') que no ocupa posicin del
espacio de nmeros de secuencias y que
indica que el campo de acuse de recibo de
este segmento especifica el prximo nmero
de secuencia que el emisor de este segmento
espera recibir, por lo que tambin realiza un
acuse de recibo de todos los nmeros de
secuencia anteriores.
ARPANET, mensaje de La unidad de
transmisin entre un 'host' y un IMP en
ARPANET. Su tamao mximo es de 1012
octetos (8096 bits).

ARPANET, paquete de Una unidad de
transmisin que ARPANET utiliza
internamente entre los IMP. Su tamao
mximo es de 126 octetos (1008 bits).
Cabecera, Informacin de control al
comienzo de un mensaje, segmento,
fragmento, paquete o bloque de datos.
Conector, En ingls: 'socket'. Direccin que
especficamente incluye un identificador de
puerto, es decir, la concatenacin de una
direccin de internet con un puerto de TCP.
Conexin, Un camino lgico de comunicacin
identificado por un par de conectores.
Datagrama, Un mensaje que se enva en una
red de comunicaciones de ordenadores por
intercambio de paquetes.
direccin de destino, La direccin de
destino, habitualmente los identificadores de
red y de 'host'.
direccin de origen, la direccin de origen,
generalmente los identificadores de red y de
'host'.
envo, secuencia de Siguiente nmero de
secuencia que el TCP local (emisor)
utilizar en la conexin. Se selecciona
inicialmente de una serie de nmeros de
secuencias iniciales (ISN, 'initial sequence
number') y se incrementa por cada octeto de
datos o de control que se transmita.
envo, ventana de Representa los nmeros
de sencuencia que el TCP remoto (receptor)
espera recibir. Es el valor del campo de
ventana que se especifica en los segmentos
provenientes del TCP remoto (receptor de
los datos). El rango de los nuevos nmeros
de secuencia que un TCP puede emitir va
desde SND.TXT hasta SND.UNA + SND.WND -
1. (Las retransmisiones de los nmeros de
secuencia entre SND.UNA y SND.NXT son de
esperar, por supuesto).
FIN, Un bit de control (de 'finis') que ocupan
una posicin del espacio de nmeros de
secuencia y que indica que el emisor no
enviar ms datos o informacion de control
que ocupe posiciones del espacio de
nmeros de secuencia.
Fragmento, Una porcin de una unidad
lgica de datos, en particular, un fragmento
de internet es una porcin de un datagrama
de internet.

FTP, Un protocolo de transferencia de
ficheros.
Host, Un computador. En particular, un
origen o destino de los mensajes desde el
punto de vista de la red de comunicaciones.
Identificacin, Un campo del protocolo de
internet. Identifica el valor asignado por el
emisor que sirve de ayuda para el
ensamblaje de los fragmentos de un
datagrama.
IMP, La interfaz de procesamiento de
mensajes o 'Interface Message Processor', el
commutador de paquetes de ARPANET.
internet, direccin de Una direccin de
origen o de destino especfica del nivel de
'host'.
Proceso, Un programa en ejecucin. Un
origen o destino de datos desde el punto de
vista de TCP o cualquier otro protocolo de
'host' a 'host'.
PUSH Un bit de control que no ocupa
posicin en el espacio de nmero de
secuencias, y que indica que un segmento
que contiene datos debe entregarse
inmediatamente ('pushed') al usuario
receptor.
TCP, Bloque de control de la transmisin
('Transmission control block'), la estructura
de datos que registra el estado de una
conexin.
TCB.PRC, La prioridad de una conexin
TCP, Procotocolo de control de transmisin
('Transmission Control Protocol': un
protocolo de 'host' a 'host' para las
comunicaciones fiables en entornos de inter-
redes.
TOS, Tipo de servicio ('Type of Service'), un
campo del protocolo de internet.
Tipo de servicio, Un campo del protocolo de
internet que indica el tipo de servicio para
este fragmento de internet.
URG, Un bit de control (urgente), que no
ocupa posicin en el espacio de nmeros de
secuencia y que se utiliza para indicar que se
le debera notificar al usuario receptor que
realice un procesamiento urgente tan
pronto como los datos le vayan siendo
entregados mientras que sus nmeros de
secuencia sean menores que los indicados en
el puntero urgente.