c
 




 
c  

  c   
    c 
 

Un servicio orientado a la conexión proporciona el establecimiento, mantenimiento y

cierre de una conexión lógica entre usuarios de transporte (un usuario de transporte
puede ser un protocolo de capa superior como FTP, SMTP, Telnet, etc.).
Este tipo de servicio es el más utilizado por ser un servicio fiable. Básicamente, cuando se
hable de este tipo de servicios, se estará refiriendo a TCP, que es el mayor referente de
transporte orientado a la conexión.

Aunque se puede argumentar que no existe una capa del modelo TCP/IP que presente
mayores problemas que otra, también es justo argumentar que la capa de transporte es
una de las más complejas, por el número tareas que se llevan a cabo.

 

Existen algunos servicios que son fiables casi al 100%, asegurando una entrega secuencial
de los mensajes:

Ê u.25
Ê pedes que implementen LAPF (implementación de capa de enlace)
Ê Lan IEE 802.3 con LLC orientado a la conexión

Estos escenarios son ciertos siempre y cuando exista una conexión entre clientes finales a
la misma red, y no una simple interconexión de red.

Este servicio considera básicamente cuatro cosas:

!

Al querer establecer una conexión o realizar una transferencia entre entidades de

transporte que usen el mismo protocolo, es necesario que se identifique a los usuarios
destinos mediante alguna información:

Ê Identificación del usuario: Se refiere a la identificación del usuario de transporte,

en sí define el puerto que se utilizará (por ejemplo en TCP 80 para HTTP, 22 para
SSH, etc.)
Ê Identificación de la entidad de transporte: Identifica al protocolo que hará uso, por
ejemplo, si es TCP o UDP. Normalmente, solo existirá una o dos entidades en una
estación.
 Ê Dirección de la estación: Es una dirección que identifica al host y es obtenida como
es natural, desde la capa de red. A la combinación de la dirección de host y número
de puerto se le conoce como Socket en TCP.
Ê Número de la red: Información proveniente de la capa de red acerca de la red.

" # $%

El proceso de multiplexación y demultiplexación consiste en que varios usuarios de

transporte (protocolos de capa superior) hacen uso de un mismo protocolo de transporte
(TCP o UDP por ejemplo), distinguiéndose unos de otros a través de números de puerto.

c & "'

El control de flujo es una de las tareas más complejas dentro de la capa de transporte,
existen dos razones para ello:

Ê El retardo de transmisión entre entidades de transporte (protocolos) es

generalmente grande comparado con el tiempo de transmisión real.
Ê Como la capa de transporte opera sobre una red o una interconexión de redes, la
cantidad de retardo en la transmisión puede ser variable, por lo que se dificulta
utilizar de forma efectiva un mecanismo de tiempos de expiración para la
retransmisión de datos perdidos.

Ante este problema existen varias soluciones:

Ê No hacer nada: Si existe una diferencia en las capacidades y tasas de envío y

recepción, entonces los segmentos que no se alcancen a recibir se descartarán; el
emisor al no recibir una confirmación de recepción los retransmitirá, pero esto no
es concordante con una red fiable, ya que esto solo agravará el problema al
generar más congestión.
Ê pechazar la aceptación de más segmentos del servicio de red: Al bloquear la
recepción de información de la capa de nivel inferior, esto desencadena la emisión
de información de la capa par en el emisor, por tanto bloquea además el envió de
la capa de transporte. Este mecanismo es bastante tosco e inexacto, por ejemplo,
si varias conexiones de transporte utilizan la misma conexión de red (por ejemplo
un circuito virtual).
Ê Usar un protocolo de ventana deslizante: Este principio se basa en establecer el
tamaño de un grupo segmentos a ser enviados (conocido como ventana), agregar
números de secuencias a las unidades de datos (en este caso a los segmentos) y
utilizar confirmaciones para avanzar en el envió de ventanas.
Ê Esquema de créditos: Separa las confirmaciones y el control de flujo, lo que
permite que se pueda confirmar un segmento sin la concesión de un nuevo crédito
para control de flujo, y viceversa.

( !) $%

En cualquier ambiente de conexión, siempre existe la necesidad de establecimiento y

cierre de la misma, con la idea de cumplir tres objetivos:

Ê Permitir a cada extremo asegurarse de la existencia del otro

Ê Permitir el intercambio de parámetros opcionales (como el tamaño máximo del
segmento, la ventana y la calidad del servicio)
Ê Iniciar la reserva de recursos en las entidades de transporte (reservando espacio
de memoria, haciendo entradas en la tabla de conexiones, etc.)

El proceso de apertura ideal, inicia estando tanto el emisor como el receptor en un estado
CLOSED. Luego el emisor cambia a un estado SYN SENT (donde se envía una solicitud de
sincronización y se cambia a estado de apertura activa), entonces el receptor al recibir el
segmento SYN cambia a LISTEN (apertura pasiva) luego contesta con su propio segmento
SYN y cambia a modo ESTAB, done el emisor original, al recibir el SYN cambia a ESTAB.
También puede suceder que ambos pares deseen intercambiar información y envíen
prácticamente un segmento SYN al mismo tiempo, con lo que se cambiaría
inmediatamente a estado ESTAB en ambos pares.

El proceso de cierre sucede de forma similar. Puede iniciar el cierre cualquiera de los pares
o ambos a la vez, y la conexión es cerrada por mutuo acuerdo. Existe dos tipos de cierres:
un cierre repentino hace que se pierdan los datos en tránsito, mientras que un cierre
ordenado hace que se espere hasta que todos los datos hayan sido recibidos.
De todas formas el proceso de cierre inicia cuando uno de los pares recibe de un usuario
de transporte una primitiva de cierre (close), entonces se envía un segmento FIN al otro
par para solicitar el cierre, y se pasa a estado FIN WAIT. En este estado aun seguirá
recibiendo información y pasándola a la capa correspondiente. Este estado finaliza cuando
se recibe un segmento FIN, con lo que se libera al usuario y se cierra la conexión.

[
*c 

 & +


Para un protocolo de transporte el escenario más complejo es cuando el servicio de red no

es fiable, tal es el caso de redes que utilicen IP, redes de retransmisión de tramas que usen
únicamente núcleos del protocolo LAPF, o redes LAN IEEE 202.3 con servicios LLC no
orientados a la conexión.

Nótese que el problema puede no ser únicamente que se pierdan ocasionalmente algunos
segmentos, sino que los mismos pueden llegar sin atender a ninguna secuencia debido a
retardos de tráfico en la red, por lo que es necesario un elaborado mecanismo que haga
frente a estas deficiencias derivadas del modelo de red. Para complicar aún más la
situación, las soluciones planteadas para las redes fiables, no son aplicables, ya que
conducen a nuevos problemas que solo agravan más las cosas.
En definitiva se deben tratar siete cosas: la entrega ordenada, estrategia de retransmisión,
dirección de duplicados, control de flujo, establecimiento de la conexión, cierre de la
conexión y recuperación de fallos.



Es posible que los segmentos, incluso en el caso de que llegasen todos, lleguen en forma
desordenada. La solución a este problema consiste en numerar los segmentos
secuencialmente. En algunos protocolos que abarcan tanto la capa de red como la de
enlace (HDLC o u.25) cada unidad de datos, es decir, cada trama o paquete, se numeran
secuencialmente. Este mismo esquema se utiliza en algunos protocolos de transporte. Sin
embargo TCP usa un esquema que se diferencia en que cada octeto que se transmite se
numera implícitamente. Por ejemplo, el primer segmento puede tener el número de
secuencia igual a 1, y si ese segmento contiene 200 octetos de datos, entonces el segundo
segmento tendría el número de secuencia 201, y no 2.

((!(%

La retransmisión de un segmento puede ser causado por dos razones. La primera es que el
segmento puede dañarse en el camino, llegando eventualmente a su destino. Si en el
segmento se incluye una suma de comprobación, la entidad de transporte que recibe los
datos puede detectar el error y descartar el segmento. La segunda razón, es que la
entidad emisora no sabe que la transmisión del segmento no se ha realizado con éxito, y
para tratar esta contingencia se usa un esquema de confirmaciones de recepción, donde
la entidad receptora debe confirmar cada segmento recibido satisfactoriamente
devolviendo un segmento con un número de confirmación. Para mayor eficiencia, no se
necesita una confirmación por cada segmento, sino que se puede usar una confirmación
acumulada. Por ejemplo, el receptor puede recibir lo segmentos numerados como 1, 201
y 401 pero solo envía AN=601 de regreso. El emisor interpreta AN=601 entendiendo que
los segmentos anteriores se recibieron correctamente.

Ahora, si un segmento no se recibe, no se enviará una confirmación positiva y se tendrá

que efectuar una retransmisión. Esto puede traer problemas mayores, por lo que debe
haber un temporizador asociado a cada segmento que se envía. Si el temporizador expira
antes de que se confirme, entonces el emisor envía de nuevo el segmento.
Pero si los temporizadores resuelven el problema, ahora el problema radica en decidir qué
valor asignarle al temporizador. Para ello existen dos estrategias. La primera es usar un
valor fijo, basado en el entendimiento del comportamiento típico de la red, pero entonces
no se contaría con la capacidad de reaccionar ante los cambios en las condiciones de la
red, provocando muchas retransmisiones si el valor es demasiado bajo, o causando que el
protocolo sea muy lento en reaccionar ante la pérdida de un segmento si el valor es
demasiado alto. Una aproximación para este valor es un valor poco mayor que el tiempo
de ida y vuelta. Desde luego que este valor es variable, incluso si la red funcionase con
carga constante. La segunda estrategia es usar un esquema adaptable, el cual acarrea sus
propios problemas. Suponga que la entidad e transporta registra el tiempo que toma
confirmar los segmentos y fija los temporizadores de retransmisión de acuerdo a la media
de los retardos observados, el valor puede no ser válido debido a que la entidad receptora
puede que no confirme inmediatamente un segmento utilizando confirmaciones
acumuladas, o si un segmento ha sido retransmitido, el emisor no sabe si la confirmación
positiva recibida es una respuesta del segmento original o de la retransmisión, y por
supuesto, las condiciones de la red pueden cambiar repentinamente.
Este no es un problema con soluciones completas, siempre existirá alguna incerteza con el
mejor valor para el temporizador de un valor de retransmisión, que no es el único
temporizador usado por el protocolo de transporte:

Ê De retransmisión: Para retransmitir un segmento no confirmado.

Ê De reconexión: Tiempo mínimo entre el cierre de la conexión y el establecimiento
de una nueva con la misma dirección de destino.
Ê De ventana: Tiempo máximo entre segmentos ACK/CpEDIT
Ê de retransmisión SYN: intervalo entre intentos de establecimiento de una
conexión.
Ê De persistencia: Usado para abortar una conexión cuando no se confirma ningún
segmento.
Ê De inactividad: Aborta una conexión cuando no se recibe ningún segmento.

%"# (

Si al perderse un segmento y después retransmitirlo, no se produce ninguna confusión,

pero si uno o más segmentos sucesivos se entregan satisfactoriamente pero se pierde el
ACK, el temporizador de la entidad de transporte emisora expirará y retransmitirá uno o
más segmentos. Por ello, el receptor debe ser capaz de reconocer los duplicados, el hecho
de que cada segmento lleve un número de secuencia ayuda, pero la detección y gestión
de duplicados no es algo sencillo. Existen dos escenarios concretos:

Ê Si se recibe un duplicado antes del cierre de la conexión

Ê O se recibe después del cierre de la misma.

Para el primer escenario, note que se dice recibir "un" duplicado, ya que desde el punto
de vista del emisor, el segmento retransmitido es el duplicado, sin embargo, el segmento
duplicado puede llegar antes que el original debido a algún retardo, en cuyo caso el
receptor vería el segmento original como el duplicado. Como sea, se necesitan dos
tácticas para tratar el caso:
 Ê El receptor debe asumir que su confirmación se perdió y por tanto, confirmar el
duplicado. Entonces el emisor no debe confundirse si recibe varias confirmaciones
positivas para el mismo segmento.
Ê El espacio de números de secuencia debe ser lo suficientemente grande para no
agotarse antes del tiempo máximo de vida para un segmento.

El segundo escenario será tratado en el establecimiento de la conexión.

c & "'

El mecanismo de control de flujo basado en créditos es bastante robusto para redes no

fiables y requiere pocas modificaciones. El funcionamiento es muy simple, un segmento
que contenga (AN=i, W=j) confirma todos los octetos con números de secuencia menores
a i, y concede j créditos extras iniciando por el octeto i. El método es tan flexible que
permite confirmar datos sin conceder créditos.

La pérdida de un segmento ACK/CpEDIT tiene poco impacto en el funcionamiento del

diseño. Confirmaciones posteriores se encargarán de sincronizar de nuevo el protocolo.
Además, si no hay nuevas confirmaciones en camino, en el emisor expirará un
temporizador y retransmitirá un segmento de datos, que eventualmente disparará una
nueva confirmación. Aun así puede ocurrir un bloqueo mutuo. Por ejemplo B envía (AN=i,
W=0) cerrando temporalmente la ventana, luego B envía (AN=i, W=j), pero el segmento se
pierde, A estará esperando la oportunidad de enviar datos y B pensará que ya ha
concedido dicha oportunidad. Para resolver este problema se utiliza un temporizador de
ventana, el cual es reiniciado cada vez que se envía un segmento (ya que todos los
segmentos poseen campos AN y W).

( ! $%

Como con otros mecanismos de protocolo, el establecimiento de la conexión también

debe considerar la falta de fiabilidad en el servicio de red. En síntesis, el establecimiento
de la conexión requiere el intercambio de SYN, en un procedimiento conocido como
"saludo de dos vías" o "diálogo de dos pasos". Sunga que A emite un SYN para B, luego de
emitirlo, esperará un SYN de regreso para confirmar la conexión. Aquí dos cosas pueden ir
mal: que se pierda o el SYN de A o la respuesta de B. Cualquiera de los casos puede ser
resuelto a través del uso de temporizadores de retransmisión SYN.

Potencialmente, esto puede causar duplicación de SYN. Si se pierde el SYN de A, no habría

duplicados, pero si se pierde la respuesta de B, entonces B probablemente recibiría dos
SYN de parte de A, aun, si la respuesta de B no se perdiese, sino solo se retrasase, A podría
recibir dos SYN de respuesta. En cualquier caso, A y B deben simplemente ignorar los SYN
duplicados una vez que la conexión se haya establecido.
Además, existen otros problemas que deben ser abordados. Al igual que un SYN retrasado
o una respuesta perdida producen un SYN duplicado, un segmento de datos retrasado o
una confirmación perdida puede generar duplicidad de segmentos de datos causando a su
vez interferencias en la transferencia de datos. Para ilustrarlo, suponga que con cada
nueva conexión, cada entidad del protocolo de transporte inicio la numeración de sus
segmentos de datos con el número de secuencia 1. Imagine que una copia duplicada del
segmento SN=401 de una antigua conexión llega durante el tiempo de vida de una nueva
conexión y es entregada a B antes que el segmento SN=401 legítimo para esta conexión.
Una posible solución es iniciar las conexiones nuevas con un número de secuencia que
difiera lo suficiente del último número de secuencia de la conexión más reciente. Para
lograrlo, la solicitud de conexión es de la forma SYN i, donde i es el número de secuencia
del primer segmento de datos que será enviado en esta conexión.

Ahora, vea el caso en que un SYN i duplicado sobrevive hasta después del cierre de la
conexión. Si un SYN i obsoleto llega a B luego de que la conexión haya terminado, B
supone que se trata de una petición nueva y responde con un SYN=j, lo que significa que B
acepta la solicitud de conexión y que comenzará a transmitir con SN=j. Mientras tanto A
decide abrir una nueva conexión con B y envía SYN=k. B descarta el último con duplicado,
provocando que ambos extremos hayan transmitido y recibido un segmento SYN, lo que
les conduce a pensar que existe una conexión válida. Sin embargo, cuando A inicia la
transferencia de datos con un segmento numerado con k, B rechaza el segmento por no
corresponder con la secuencia que espera.

La solución en realidad es bastante sencilla, simplemente cada lado de la conexión debe

confirmar explícitamente el SYN y número de secuencia del otro. Este procedimiento es
conocido como "saludo de tres vías" o "diálogo en tres pasos". Para ejemplificar el
proceso, suponga que la entidad de transporte A inicia la conexión con un SYN que incluye
el número de secuencia de envío i, que es el número de secuencia inicial (ISN) y se asocia
con el SYN mismo. Entonces B acepta el inicio de la conexión y confirma con SYN j, AN=i+1,
para que entonces A confirme y transmita el primer octeto de datos con el número de
secuencia SN=i+1, y AN=j+1. Ahora, en el escenario de un SYN i obsoleto que llegue a B
luego del cierre de la conexión, B supondrá que se trata de una solicitud nueva y responde
con SYN j, AN=i+1; cuando A reciba este mensaje, se dará cuenta de que él no ha
solicitado una conexión y por tanto enviará un pST, AN=j, para evitar que un mensaje pST
duplicado y obsoleto cancele el establecimiento de una conexión legítima. La regla básica
consiste en enviar un pST si el estado de la conexión no es todavía ESTAB y se recibe un
ACK inválido (uno que no haga referencia a algún segmento que haya sido enviado).

c $%

Como ya se vio, el diálogo en dos pasos no es satisfactorio para establecer conexiones en

ambientes de red no fiables, lo mismo sucede al momento de cerrar la conexión. Esto se
debe a que puede ocurrir que los segmentos lleguen en desorden al destino causando
pérdida de información, ya que una entidad de transporte en estado CLOSE WAIT envía su
último segmento de datos, seguido por un segmento FIN, pero el segmento FIN llega al
otro externo antes que el último segmento de datos. La entidad receptora aceptaría ese
FIN y cerraría la conexión perdiendo el último segmento de datos. Para evitar este
problema, se puede asociar un número de secuencia al segmento FIN, el cual puede ser el
siguiente número de secuencia tras el último octeto de los datos transmitidos.
Un problema más serio es la potencial pérdida de segmentos y la posible presencia de
segmentos obsoletos. Para ello, cada extremo debe confirmar explícitamente el segmento
FIN del otro usuario usando un ACK con el número de secuencia del segmento FIN a
confirmar. Para realizar un cierre ordenado una entidad de transporte requiere lo
siguiente:

Ê Enviar un FIN i y recibir un AN=i+1

Ê pecibir un FIN j y enviar un AN=j+1
Ê Esperar un intervalo de tiempo igual a dos veces el tiempo máximo de vida de los
segmentos

"#%"#(

Cuando el sistema sobre el cual una entidad de transporte está operando falla y
posteriormente se recupera, la información de estado de todas las conexiones activas se
pierde. Las conexiones afectadas pasan a estar "semiabiertas" ya que el lado que no se vio
afectado por la interrupción no se habrá dado cuenta aun del problema.
El extremo activo de la conexión semiabierta puede cerrar la conexión usando un
temporizador de persistencia, el cual mide el tiempo que la máquina de transporte
continuará esperando una confirmación (o la respuesta apropiada) de un segmento
transmitido, luego de que el segmento haya sido retransmitido el máximo número de
veces. Cuando el temporizador expira, la entidad de transporte asume que ha fallado la
otra entidad o la red intermedia, cierra la conexión e indica al usuario TS que se produjo
un cierre anormal.

En el caso de que una entidad de transporte falle y se reinicie rápidamente, la conexión

semiabierta se puede terminar más rápidamente a través del uso del segmento pST. El
lado que falla devuelve un pST i por cada segmento i que reciba. Cuando el pST i se recibe
al otro lado, se debe comprobar su validez basándose en el número de secuencia i, ya que
el pST podría serla respuesta de un segmento obsoleto como se mencionaba previamente.
Si el reinicio es válido, la entidad de transporte efectúa un cierre anormal.
Estas medidas solucionan la situación en la capa de transporte. La decisión de reabrir la
conexión se deja a los usuarios TS. En definitiva el problema es de sincronización, ya que
cuando ocurrió la interrupción, puede que hubiera uno o más segmentos pendientes en
ambos sentidos. El usuario TS del lado que no falló sabe cuántos datos ha recibido, pero el
otro usuario no puede saberlo si perdió la información de estado, con lo que se corre el
riesgo de que algunos datos de usuario se pierdan o dupliquen.

, c


TCP está diseñado para asegurar comunicación fiable independientemente si se despliega

en redes fiables o no fiables.

TCP se vale de dos servicios de etiquetados de datos:

1.Ê Flujo de datos forzado: Por lo general TCP decide cuando se han acumulado
suficientes datos para enviar un segmento. Los clientes TCP pueden modificar este
comportamiento agregando una etiqueta para entrega forzada.
2.Ê Señalización de datos urgentes: A través de esto se informa al destinatario que los
datos son significativos o ͞urgentes͟. El destinatario decide entonces qué hacer
con esos datos.

cc


La cabecera de un segmento TCP tiene una longitud mínima de 20 octetos.

Ê Puerto de origen (16 bits): Usuario TCP de origen

Ê Puerto destino (16 bits): Usuario TCP destino
Ê Número de secuencia (32 bits): Número de secuencia del primer octeto de datos
en este segmento, a excepción de cuando aparece un indicador SYN, en cuyo caso
es un número de secuencia inicial (ISN) y l primer octeto de datos es ISN+1.
Ê Número de confirmación (32 bits): Número de secuencia del siguiente octeto que
la entidad TCP espera recibir
Ê Longitud de la cabecera (4 bits): Número de palabras de 32 bits de la cabecera.
Ê peservado (6 bits): peservado para uso futuro. Por ejemplo notificaciones de
congestión en las redes, etc.
Ê Indicadores (6 bits): Up ʹ urgente, ACK ʹ confirmación, PSH ʹ forzado, pST ʹ
reiniciar la conexión, SYN ʹ sincronizar los números de secuencia, FIN ʹ el emisor
no enviará más datos.
Ê Xentana (16 bits): Créditos para el control del flujo, indicado en octetos. Número
de octetos de datos, iniciando con el número de secuencia que se indica en el
campo de confirmación que el emisor está dispuesto a aceptar.
Ê Suma de comprobación (16 bits)
Ê Puntero Urgente (16 bits): Al ser sumado con el número de secuencia del
segmento genera el número de secuencia del último octeto de la secuencia
urgente.
 Ê Opciones (variable): Aquí se incluyen cosas como la longitud máxima del segmento
a ser aceptado.


,
c  c


( ! c$%

Siempre se utiliza un saludo en tres vías. Se activa el indicador SYN para solicitar una
conexión. El receptor responde con SYN y ACK.

Una conexión está definida por un Socket origen ʹ destino por tanto solo puede haber una
única conexión TCP entre un único par de puertos.

((

A pesar de que los datos son transmitidos en segmentos, dicha transmisión es vista como
un flujo de octetos. Cada segmento contiene el número de secuencia del primer octeto
del campo de datos. El control de flujo es regulado a través de la asignación de créditos,
donde el crédito representa un número de octetos y no de segmentos.

La unidad de transporte almacena temporalmente los datos de entrada y de salida en

buffers separados.

TCP normalmente decide cuando construir un segmento para ser transmitido y cuando
entregar los datos recibidos al usuario. Un indicador PSH obliga a que los datos
acumulados sean enviados o entregados según sea el caso, sirviendo como una función de
fin de bloque.

El usuario puede indicar que un bloque es urgente, y para ello TCP aplica al fin del bloque
un puntero urgente y lo envía con el flujo ordinario de datos.

Si durante el intercambio de datos llega un segmento que aparentemente no va dirigido a

la conexión actual, se enviará un segmento con valor pST activado. Los SYN duplicados
retrasados y las confirmaciones de datos todavía no enviados constituyen ejemplos de
esto.

c $%

Normalmente ocurre un cierre ordenado. Cada usuario TCP emite una primitiva Close,
mientras que la entidad TCP establece el bit FIN en el último segmento que envía.
Si el usuario emite una primitiva ABOpT se produce un cierre repentino. En este caso, la
entidad deja de intentar de recibir o transmitir datos y limpia los buffers de entrada y
salida para finalmente enviar un segmento pST al otro extremo.


,[
c 




 c c


Aunque el protocolo está ampliamente definido existen algunas consideraciones que

pueden ser abordadas de distintas formas para cada entidad TCP.

Ê Política de envío: Si no existe un indicador de forzado o una ventana cerrada,

pueden enviarse datos tan pronto sea posible mientras dure la validez de su
crédito. Entonces TCP puede construir un segmento por cada lote de datos de
usuario o esperar a que se acumule cierta cantidad de los mismos antes de
construir y enviar el segmento.
Ê Política de entrega: Ante la falta de un indicador de forzado, una entidad TCP es
libre de entregar los datos al usuario tan pronto sea posible. Puede entregar los
segmentos en orden o acumularlos en los buffer de recepción antes de entregar un
conjunto completo.
Ê Política de aceptación: Cuando los segmentos no llegan en secuencia, la entidad
receptora tiene dos opciones:
!Ê Aceptación ordenada: Se descartan los segmentos que no llegan en orden y
se aceptan solo los que sí lo hagan.
!Ê Aceptación en ventana: Se aceptan todos los segmentos que estén dentro
de la ventana receptora.
Ê Política de petransmisión: TCP mantiene una cola de segmentos enviados pero no
confirmados. El protocolo establece que un segmento debe ser retransmitido si no
se recibe su confirmación en determinado periodo de tiempo. Para ello existen
tres estrategias:
!Ê Solo el primero: Se mantiene un temporizador de retransmisión para toda
la cola. Si el temporizador expira, retransmite el primer segmento de la cola
y reinicia el temporizador.
!Ê Por lotes: Se mantiene un temporizador para toda la cola. Si dicho
temporizador caduca, retransmite todos los segmentos de la cola y reinicia
el temporizador.
!Ê Individual: Mantiene un temporizador por cada segmento de la cola. Si
algún temporizador expira, retransmite el segmento correspondiente y
reinicia el temporizador.
Ê Política de confirmación: Cuando llega un segmento en orden, el receptor TCP
tiene dos opciones:
!Ê Inmediata: Cuando se aceptan los datos se transmite un segmento vacío
que contiene el número de confirmación adecuado.
!Ê Acumulada: Cuando se aceptan los datos se registra la necesidad de una
confirmación, pero se espera un segmento de datos de salida al que se le
 incorpora la confirmación. Para evitar retardos exagerados se crea un
temporizador de ventana, que transmite la confirmación adecuada dentro
de un segmento vacío al expirar antes de haber enviado alguna
confirmación.


,,c  

c -
 

El control de flujo basado en créditos de TCP se diseñó para evitar la saturación del buffer
de la entidad receptora. Actualmente este mecanismo es utilizado por Internet para
controlar la congestión entre origen y destino. Esta congestión tiene dos efectos:

Ê Cuando empieza a producirse, el tiempo de transmisión a través de la

interconexión de redes aumenta.
Ê Mientras la congestión se hace más grave, la red o mejor dicho los nodos empiezan
a descartar paquetes.

Por tanto, TCP puede utilizarse para detectar el inicio de la congestión y reaccionar a
través de alguna técnica de reducción en el flujo de datos. Como sea, estas técnicas se
pueden agrupar en dos categorías:

Ê estión de Temporizadores de petransmisión: En función de los cambios en las

condiciones de red, un temporizador de retransmisión definido de manera estática
puede expirar demasiado rápido o demasiado tarde. Debido a esto, todas las
implementaciones TCP intentan determinar el retardo de ida y vuelta, a través de
la observación del patrón de retardo de los segmentos más recientes.
Ê estión de Xentana: El tamaño de la ventana transmisión y la velocidad con que se
adapta a las condiciones de transmisión puede tener un efecto decisivo para que
TCP pueda ser utilizado eficientemente sin causar congestión.


 .


Además de TCP, existe otro protocolo muy popular para la capa de transporte y que
además pertenece a la pila TCP/IP, el Protocolo de Datagrama de Usuario (UDP, User
Datagram Protocol), especificado en el pFC 768.

UDP proporciona un servicio no orientado a la conexión para los procedimientos de capa

de aplicación, por lo que UDP es básicamente un servicio no fiable ya que no se garantiza
la entrega y la protección contra duplicados, lo que permite reducir la carga del protocolo,
lo cual resulta conveniente en muchos casos.

La fortaleza del enfoque orientado a la conexión es clara, ya que despliega características

como control de flujo, control de errores y entrega ordenada. Sin embargo, un servicio no
orientado a la conexión es más apropiado en algunos contextos donde la sobrecarga del
establecimiento y cierre de la conexión resultan contraproducentes:

Ê pecolección de datos internos: incluye un muestreo activo o pasivo de fuentes de

datos, como los que provienen de sensores e informes automáticos de
autocomprobación de componentes de red. En una situación de monitorización de
tiempo real, la pérdida de algún dato ocasional no causa un desastre ya que el
siguiente informe debería llegar en breve. Un ejemplo claro de esto es el uso de
SNMP.
Ê Diseminación de datos externos: incluye difusión de mensajes a usuarios de la red,
el anuncio de un nuevo nodo o el cambio de dirección de un servicio, o tareas tan
simples como sincronizar la hora en varias máquinas.
Ê Petición/respuesta: Aplicaciones en las cuales un servidor común proporciona un
servicio de transacción a varios usuarios de transporte distribuidos y para el cual
usar una secuencia del tipo de petición/respuesta es usual. El uso del servicio se
regula en la capa de aplicación y las conexiones de capas inferiores son
frecuentemente innecesarias y molestas. Un ejemplo claro de esto es el uso del
protocolo DNS.
Ê Aplicaciones en tiempo real: Como aplicaciones de voz y telemedios, que llevan
consigo el requisito de utilizar cierto grado de redundancia y/o transmisión en
tiempo real. Estos requisitos no pueden tener funciones orientadas a conexión
como la retransmisión.

UDP se sitúa sobre IP, y como es no orientado a la conexión, tiene pocas tareas que
realizar. Esencialmente, incorpora a IP la capacidad de un direccionamiento de puerto.
Esto se aprecia mejor al examinar la cabecera UDP. Dicha cabecera incluye un puerto
origen y un puerto destino. El campo de longitud contiene la longitud de todo el segmento
UDP, incluyendo la cabecera y los datos. La suma de comprobación es el mismo algoritmo
usado en TCP e IP. Para UDP, la suma de comprobación se aplica al segmento UDP entero
más una seudo - cabecera incorporada a la cabecera UDP en el momento del cálculo. Si se
detecta un error, el segmento se descarta sin tomar ninguna medida adicional.

El campo de suma de comprobación en UDP es opcional. Si no se utiliza, se le asigna el

valor de cero. Sin embargo, hay que recordar que la suma de comprobación de IP se aplica
solo a la cabecera IP y no al campo de datos, que en este caso está compuesto por la
cabecera UDP y los datos de usuario, por tanto, si UDP no realiza la suma de
comprobación, los datos de usuario no se verificarán.