SlideShare una empresa de Scribd logo
Capa de Transporte OSI

El modelo de referencia de Interconexión de Sistemas Abiertos (OSI,
Open System Interconnection) es el modelo de red descriptivo
creado por la Organización Internacional para la Estandarización
lanzado en 1984. Es decir, es un marco de referencia para la
definición de arquitecturas de interconexión de sistemas de
comunicación.

El nivel de transporte o capa transporte es el cuarto nivel del
modelo OSI encargado de la transferencia libre de errores de los
datos entre el emisor y el receptor, aunque no estén directamente
conectados, así como de mantener el flujo de la red.

La tarea de esta capa es proporcionar un transporte de datos
confiable y económico de la máquina de origen a la máquina
destino, independientemente de la red de redes física en uno. Sin la
capa transporte, el concepto total de los protocolos en capas
tendría poco sentido.

Capa encargada de efectuar el transporte de los datos (que se
encuentran dentro del paquete) de la máquina origen a la de
destino, independizándolo del tipo de red física que se esté
utilizando. La PDU de la capa 4 se llama Segmento o Datagrama,
dependiendo de si corresponde a TCP o UDP. Sus protocolos son
TCP y UDP; el primero orientado a conexión y el otro sin conexión.
Trabajan, por lo tanto, con puertos lógicos y junto con la capa red
dan forma a los conocidos como Sockets IP:Puerto
(192.168.1.1:80).
Servicios
Hay dos tipos de servicio en la capa transporte, orientado y no
orientado a la conexión.

En el servicio orientado a la conexión consta de tres partes:
establecimiento, transferencia de datos, y liberación.

En el servicio no orientado a la conexión se tratan los paquetes de
forma individual.

Es la primera capa que lleva a cabo la comunicación extremo a
extremo, y esta condición ya se mantendrá en las capas superiores.

Primitivas del servicio de transporte
Para permitir que los usuarios accedan al servicio de transporte, la
capa de transporte debe proporcionar algunas operaciones a los
programas de aplicación, es decir, una interfaz del servicio de
transporte. Cada servicio de transporte tiene su propia interfaz.
Con el propósito de ver los aspectos básicos, en esta sección
examinaremos primero un servicio de transporte sencillo y su
interfaz.

El servicio de transporte es parecido al servicio en red, pero hay
algunas diferencias importantes.

La principal, es que, el propósito del servicio de red es modelar el
servicio ofrecido por las redes reales, con todos sus problemas. Las
redes reales pueden perder paquetes, por lo que generalmente el
servicio no es confiable.

En cambio, el servicio de transporte (orientado a la conexión) si es
confiable.
Claro que las redes reales no están libres de errores, pero ése es
precisamente el propósito de la capa de transporte: ofrecer un
servicio confiable en una red no confiable.

Otra diferencia entre la capa transporte y la de red es a quien van
dirigidos sus servicios. El servicio de red lo usan únicamente las
entidades de transporte. Pocos usuarios escriben sus entidades de
transporte y pocos usuarios o programas llegan a ver los aspectos
internos del servicio de red. En cambio, muchos programas ven
primitivas de transporte.

En consecuencia el servicio de transporte debe ser adecuado y fácil
de usar.

Las primitivas de un transporte sencillo serían:
     LISTEN: Se bloquea hasta que algún proceso intenta el
     contacto.
     CONNECT: Intenta activamente establecer una conexión.
     SEND: Envía información.
     RECEIVE: Se bloque hasta que llegue una TPDU de DATOS.
     DISCONNECT: Este lado quiere liberar la conexión.

Y con estas primitivas podemos hacer un esquema sencillo de
manejo de conexiones. Las transiciones escritas en cursiva son
causadas por llegadas de paquetes. Las líneas continuas muestran
la secuencia de estados del cliente y las líneas punteadas muestran
la secuencia del servidor.
Elementos de los protocolos de transporte

El servicio de transporte se implementa mediante un protocolo de
transporte entre dos entidades de transporte. En ciertos aspectos,
los protocolos de transporte se parecen a los protocolos de red.
Ambos se encargan del control de errores, la secuenciación y el
control del flujo.

Pero también existen diferencias importantes entre ambas, como
los entornos en que operan, la capa transporte necesita el
direccionamiento explícito de los destinos, mientras que la capa de
red no, otra diferencia es la cantidad de datos, mucho mayor en la
capa de transporte que en la de enlace de datos.

DIRECCIONAMIENTO

Cuando un proceso desea establecer una conexión con un proceso
de aplicación remoto, debe especificar a cuál se conectará. (¿A
quién mando el mensaje?) El método que normalmente se emplea
es definir direcciones de transporte en las que los procesos pueden
estar a la escucha de solicitudes de conexión. En Internet, estos
puntos terminales se denominan puertos, pero usaremos el
término genérico de TSAP (Punto de Acceso al Servicio de
Transporte). Los puntos terminales análogos de la capa de red se
llaman NSAP (Punto de Acceso al Servicio de Red). Las direcciones
IP son ejemplos de NSAPs.
Establecimiento de una conexión
El establecimiento de una conexión parece fácil, pero en realidad es
sorprendentemente difícil. A primera vista, parecería que es
suficiente con mandar una TPDU (Unidad de Datos del Protocolo de
Transporte) con la petición de conexión y esperar a que el otro
acepte la conexión. El problema viene cuando la red puede perder,
almacenar, o duplicar paquetes. El principal problema es la
existencia de duplicados retrasados. Esto puede solucionarse de
varias maneras (ninguna es muy satisfactoria). Una es utilizar
direcciones de transporte desechables. En este enfoque cada vez
que necesitemos una dirección la creamos. Al liberarse la conexión
descartamos la dirección y no se vuelve a utilizar. O también
asignar una secuencia dentro de los datos transmitidos, pero estos
plantean los problemas de que si se pierde la conexión perdemos el
orden del identificador y ya no funciona. Pero la solución sería más
fácil si los paquetes viejos se eliminaran de la subred cada cierto
tiempo de vida. Para ello podemos utilizar las siguientes técnicas:
Un diseño de subred Restringido. Colocar un contador de saltos en
cada paquete. Marcar el tiempo de cada paquete. Pero en la
práctica no vale solo con hacer esto sino que tenemos que
garantizar que todas las confirmaciones de los paquetes también se
eliminan.

Liberación de una conexión
La liberación de una conexión es más fácil que su establecimiento.
No obstante, hay más escollos de los que uno podría imaginar. Hay
dos estilos de terminación de una conexión: liberación asimétrica y
liberación simétrica. La liberación asimétrica es la manera en que
funciona el mecanismo telefónico: cuando una parte cuelga, se
interrumpe la conexión. La liberación simétrica trata la conexión
como dos conexiones unidireccionales distintas, y requiere que
cada una se libere por separado. La liberación asimétrica es abrupta
y puede resultar en la perdida de datos. Por lo que es obvio que se
requiere un protocolo de liberación más refinado para evitar la
pérdida de datos. Una posibilidad es usar la liberación simétrica, en
la que cada dirección se libera independientemente de la otra.
Aquí, un host puede continuar recibiendo datos aun tras haber
enviado una TPDU de desconexión.

La liberación simétrica es ideal cuando un proceso tiene una
cantidad fija de datos por enviar y sabe con certidumbre cuándo los
ha enviado. En otras situaciones, la determinación de si se ha
efectuado o no todo el trabajo y se debe terminarse o no la
conexión no es tan obvia. Podríamos pensar en un protocolo en el
que el host 1 diga:”Ya termine, ¿Terminaste también?”. Si el host 2
responde “Ya termine también. Adiós”, la conexión puede liberarse
con seguridad.

Pero no es tan fiable por el problema de que siempre tendremos
que esperar la confirmación de los mensajes recibidos y si esta
confirmación no llega no libera la conexión y después puede que
necesite la confirmación de que llego la confirmación y entraríamos
en un bucle del que no podemos salir.

Podemos hacer que al host 1 si no le llega la confirmación después
de N intentos (es que quiere la desconexión), se libere. Esto
produce una conexión semiabierta en la que el host 1 está
desconectado pero el host 2 no como no le llega la confirmación no
se desconecta nunca. Para solucionar esto creamos una regla por la
cual si al host 2 no le llega ninguna TPDU durante cierta cantidad de
segundos, se libera automáticamente.
CONTROL DE FLUJO Y ALMACENAMIENTO EN BUFFER

Ya examinamos la conexión y la desconexión, veamos la manera en
que se manejan las conexiones mientras están en uso. Uno de los
aspectos clave es el control de flujo. Necesitamos un esquema para
evitar que un emisor rápido desborde a un receptor lento. La
diferencia principal es que un enrutador por lo regular tiene
relativamente pocas líneas, y un host puede tener numerosas
conexiones. Esta diferencia hace poco práctico emplear la
implementación que se hace en la capa de enlace

En esta capa lo que se hace es, si el servicio de red no es confiable,
el emisor debe almacenar en un buffer todas las TPDUs enviadas,
igual que en la capa enlace de datos. Sin embargo, con un servicio
de red confiable son posibles otros arreglos. En particular, si el
emisor sabe que el receptor siempre tiene espacio de buffer, no
necesita tener copias de las TPDUs que envía. Sin embargo, si el
receptor no garantiza que se aceptará cada TPDU que llegue, el
emisor tendrá que usar buffers de todas maneras. En el último
caso, el emisor no puede confiar en la confirmación de recepción
de la capa red porque esto sólo significa que ha llegado la TPDU, no
que ha sido aceptada.

Los Buffers pueden ser de tres tipos, y usaremos cada uno de ellos
cuando más nos convenga.

El equilibrio óptimo entre el almacenamiento del buffer en el
origen y en el destino depende del tipo de trafico transportado por
la conexión.
Multiplexión

La multiplexión de varias conversaciones en conexiones, circuitos
virtuales o enlaces físicos desempeña un papel importante en
diferentes capas de la arquitectura de red. En la capa de transporte
puede surgir la necesidad de multiplexión por varias razones. Por
ejemplo, si en un host sólo se dispone de una dirección de red,
todas la conexiones de transporte de esa máquina tendrán que
utilizarla. Cuando llega una TPDU, se necesita algún mecanismo
para saber a cuál proceso asignarla. Esta situación se conoce como
multiplexión hacia arriba.

La multiplexión también puede ser útil en la capa transporte para la
utilización de circuitos virtuales, que dan más ancho de banda
cuando se reasigna a cada circuito una tasa máxima de datos. La
solución es abrir múltiples conexiones de red y distribuir el tráfico
entre ellas. Esto se denomina multiplexión hacia abajo.

RECUPERACIÓN DE CAÍDAS

Si los hosts y los enrutadores están sujetos a caídas, la recuperación
es fundamental. Si la entidad de transporte está por entero dentro
de los hosts, la recuperación de caídas de red y de enrutadores es
sencilla. Si la capa de red proporciona servicio de datagramas, las
entidades de transporte esperan pérdida de algunas TPDUs todo el
tiempo, y saben cómo manejarla. Si la capa de red proporciona
servicio orientado a la conexión, entonces la pérdida de un circuito
virtual se maneja estableciendo otro nuevo y sondeando la entidad
de transporte remota para saber cuáles TPDUs ha recibido y cuáles
no.
Un problema más complicado es la manera de recuperarse de
caídas del host. Al reactivarse, sus tablas están en el estado inicial y
no sabe con precisión donde estaba.

En un intento por recuperar su estado previo, el servidor podría
enviar una TPDU de difusión a todos los demás host, anunciando
que se acaba de caer y solicitando a todos sus clientes que le
informen el estado de todas la conexiones abiertas.
Capa de transporte
Funciones de la Capa De Trasporte

• Esta capa debe proporcionar un transporte de datos confiable y
  económico desde la máquina origen a la máquina de destino,
  independientemente de la red o redes físicas en uso.

• La capa de transporte es el corazón de la jerarquía de protocolos.

• Permite aplicaciones múltiples para comunicarse en la red al
  mismo tiempo que en un dispositivo sencillo.

• Asegura que, si es necesario, la aplicación correcta reciba todos
  los datos de forma confiable y en orden.

• Emplea mecanismos de manejo de errores.

• Define los mecanismos para mantener la confiabilidad de las
  comunicaciones en la red.

• Su función es regular el flujo de mensajes, retransmisión de
  paquetes, inicio y término de sesiones entre nodos.


                        Protocolo TCP

El protocolo TCP es el encargado de dividir el mensaje original en
segmentos de menor tamaño, más manejables, que serán luego
empaquetados en datagramas o paquetes y dirigidos a través del
protocolo IP de forma individual, y añade a cada uno de los
datagramas información necesaria para su manejo, envío y control
de errores en la transmisión.
Comunicación con Confiabilidad

La diferencia clave entre TCP y UDP es la confiabilidad

La confiabilidad de la comunicación TCP se lleva a cabo utilizando
sesiones orientadas a la conexión. Antes de que un host que utiliza
TCP envíe datos a otro host, la capa de Transporte inicia un proceso
para crear una conexión con el destino. Esta conexión permite el
rastreo de una sesión o stream de comunicación entre los hosts.
Este proceso asegura que cada host tenga conocimiento de la
comunicación y se prepare. Una conversación TCP completa
requiere el establecimiento de una sesión entre los hosts en ambas
direcciones.

Luego de establecida la sesión, el destino envía acuses de recibo al
origen por los segmentos que recibe. Estos acuses de recibo forman
la base de la confiabilidad dentro de la sesión TCP. Cuando el origen
recibe un acuse de recibo, reconoce que los datos se han entregado
con éxito y puede dejar de rastrearlos. Si el origen no recibe el
acuse de recibo dentro de un tiempo predeterminado, retransmite
esos datos al destino.

Parte de la carga adicional que genera el uso de TCP es el tráfico de
red generado por los acuses de recibo y las retransmisiones. El
establecimiento de las sesiones genera cargas en forma de
segmentos adicionales intercambiados. También existen cargas
adicionales en los hosts individuales, generadas por la necesidad de
mantener un seguimiento de los segmentos que esperan acuse de
recibo y por el proceso de retransmisión.
Esta confiabilidad se logra contando con campos en el segmento
TCP, cada uno con una función específica.

Procesos del servidor TCP

Como se explicó en el capítulo anterior, los procesos de aplicación
se ejecutan en servidores. Estos procesos esperan hasta que un
cliente inicie comunicación con una solicitud de información o de
otros servicios.

Cada proceso de aplicación que se ejecuta en el servidor es
configurado por el administrador del sistema para utilizar un
número de puerto, de forma predeterminada o manual. Un
servidor individual no puede tener dos servicios asignados al mismo
número de puerto dentro de los mismos servicios de la capa de
Transporte.
Un host que ejecuta una aplicación de servidor Web y una de
transferencia de archivos no puede configurar ambas para utilizar
el mismo puerto (por ejemplo, el puerto TCP 8.080). Cuando una
aplicación de servidor activa se asigna a un puerto específico, este
puerto se considera "abierto" para el servidor. Esto significa que la
capa de Transporte acepta y procesa segmentos direccionados a
ese puerto. Toda solicitud entrante de un cliente direccionada al
socket correcto es aceptada y los datos se envían a la aplicación del
servidor. Pueden existir varios puertos simultáneos abiertos en un
servidor, uno para cada aplicación de servidor activa. Es común que
un servidor provea más de un servicio, como un servidor Web y un
servidor FTP, al mismo tiempo.
Una manera de mejorar la seguridad en un servidor es restringir el
acceso al servidor a sólo aquellos puertos asociados con los
servicios y aplicaciones accesibles a solicitantes autorizados. La
figura muestra la asignación típica de puertos de origen y destino
en operaciones de cliente o servidor TCP.
Establecimiento y finalización de la conexión TCP

Cuando dos hosts se comunican utilizando TCP, se establece una
conexión antes de que puedan intercambiarse los datos. Luego de
que se completa la comunicación, se cierran las sesiones y la
conexión finaliza. Los mecanismos de conexión y de sesión habilitan
la función de confiabilidad de TCP.

Ver la figura para observar los pasos para establecer y finalizar una
conexión TCP.

El host rastrea cada segmento de datos dentro de una sesión e
intercambia información sobre los datos recibidos por cada host a
través de la información del encabezado TCP.

Cada conexión representa dos streams de comunicación de una vía
o sesiones. Para establecer la conexión los hosts realizan un
intercambio de señales de tres vías. Los bits de control en el
encabezado TCP indican el progreso y estado de la conexión. Enlace
de tres vías:

  • Establece que el dispositivo de destino esté presente en la
    red.
  • Verifica que el dispositivo de destino tenga un servicio activo
    y esté aceptando las peticiones en el número de puerto de
    destino que el cliente que lo inicia intente usar para la sesión.
  • Informa al dispositivo de destino que el cliente de origen
    intenta establecer una sesión de comunicación en ese
    número de puerto.
En conexiones TCP, el host que brinde el servicio como cliente inicia
la sesión al servidor. Los tres pasos para el establecimiento de una
conexión TCP son:

  1. El cliente que inicia la conexión envía un segmento que
     contiene un valor de secuencia inicial, que actúa como
     solicitud para el servidor para comenzar una sesión de
     comunicación.
  2. El servidor responde con un segmento que contiene un valor
     de reconocimiento igual al valor de secuencia recibido más 1,
     además de su propio valor de secuencia de sincronización. El
     valor es uno mayor que el número de secuencia porque el
     ACK es siempre el próximo Byte u Octeto esperado. Este valor
     de reconocimiento permite al cliente unir la respuesta al
     segmento original que fue enviado al servidor.
  3. El cliente que inicia la conexión responde con un valor de
     reconocimiento igual al valor de secuencia que recibió más
     uno. Esto completa el proceso de establecimiento de la
     conexión.

Para entender el proceso de enlace de tres vías, es importante
observar los distintos valores que intercambian los dos hosts.
Dentro del encabezado del segmento TCP, existen seis campos de 1
bit que contienen información de control utilizada para gestionar
los procesos de TCP. Estos campos son los siguientes:

URG: Urgente campo de señalizador significativo.
ACK: Campo significativo de acuse de recibo.
PSH: Función de empuje.
RST: Reconfiguración de la conexión.
SYN: Sincronizar números de secuencia.
FIN: No hay más datos desde el emisor.

A estos campos se los denomina señaladores porque el valor de
uno de estos campos es sólo de 1 bit, entonces tiene sólo dos
valores: 1 ó 0. Si el valor del bit se establece en 1, indica la
información de control que contiene el segmento.

Si se utiliza un proceso de cuatro pasos, los señalizadores se
intercambian para finalizar la conexión TCP
Terminación de la sesión TCP

Para cerrar la conexión se debe establecer el señalizador de control
FIN (Finalizar) en el encabezado del segmento. Para finalizar todas
las sesiones TCP de una vía, se utiliza un enlace de dos vías, que
consta de un segmento FIN y un segmento ACK. Por lo tanto, para
terminar una conversación simple admitida por TCP, se requieren
cuatro intercambios para finalizar ambas sesiones.

Nota: En esta explicación se usan los términos cliente y servidor
como referencia por simplicidad

Pero la finalización del proceso puede ser iniciada por cualquiera de
los dos hosts que completen la sesión:

  1. Cuando el cliente no tiene más datos para enviar al stream,
     envía un segmento con el señalizador FIN establecido.
  2. El servidor envía un ACK para acusar recibo de Fin y terminar
     la sesión del cliente al servidor.
  3. El servidor envía un FIN al cliente para finalizar la sesión del
     servidor al cliente.
  4. El cliente responde con un ACK para dar acuse de recibo de
     FIN desde el servidor.

Cuando la finalización de sesión del cliente no tiene más datos para
transferir, establece el señalizador FIN en el encabezado de un
segmento. Luego, el servidor finaliza la conexión y envía un
segmento normal que contiene datos con el señalizador ACK
establecido utilizando el número de acuse de recibo, confirmando
así que se han recibido todos los bytes de datos.
Cuando se produce el acuse de recibo de todos los segmentos, se
cierra la sesión.

La sesión en la otra dirección se cierra mediante el mismo proceso.
El receptor indica que no existen más datos para enviar
estableciendo el señalizador FIN en el encabezado del segmento
enviado al origen. Un acuse de recibo de retorno confirma que
todos los bytes de datos han sido recibidos y, por lo tanto, se ha
cerrado la sesión.

Como se muestra en la figura, los señalizadores de control FIN y
ACK se establecen en el encabezado del segmento, cerrando por
lo tanto la sesión HTTP.

También es posible terminar la conexión mediante un enlace de
tres vías. Cuando el cliente no posee más datos para enviar, envía
un señalizador FIN al servidor. Si el servidor tampoco tiene más
datos para enviar, puede responder con los señalizadores FIN y
ACK, combinando dos pasos en uno. El cliente responde con un
ACK.

Actividad con Packet Tracer

En esta actividad, estudiará el protocolo de enlace de tres vías de
TCP para el establecimiento de sesión y el proceso TCP para la
terminación de la sesión. Muchos protocolos de aplicación utilizan
TCP y visualizar el establecimiento de la sesión y los procesos de
terminación con el Packet Tracer profundizará sus conocimientos.
Administración de sesiones TCP

Cuando los servicios envían datos utilizando TCP, los segmentos
pueden llegar a destinos desordenados. Para que el receptor
comprenda el mensaje original, los datos en estos segmentos se
reensamblan en el orden original. Para lograr esto, se asignan
números de secuencia en el encabezado de cada paquete.

Durante la configuración de la sesión, se establece un número de
secuencia inicial (ISN). Este número de secuencia inicial representa
el valor de inicio para los bytes de esta sesión que se transmitirán a
la aplicación receptora. A medida que se transmiten los datos
durante la sesión, el número de secuencia se incrementa en el
número de bytes que se han transmitido. Este rastreo de bytes de
datos permite que cada segmento se identifique y se envíe acuse
de recibo de manera exclusiva. Se pueden identificar segmentos
perdidos.

Los números de secuencia de segmento permiten la confiabilidad
indicando cómo reensamblar y reordenar los segmentos recibidos,
como se muestra en la figura.

El proceso TCP receptor coloca los datos del segmento en un búfer
de recepción. Los segmentos se colocan en el orden de número de
secuencia adecuado y se pasa a la capa de Aplicación cuando son
reensamblados. Todos los segmentos que llegan con números de
secuencia no contiguos se mantienen para su procesamiento
posterior. Luego, se procesan los segmentos cuando llegan con los
bytes perdidos.
Acuse de recibo de TCP con uso de ventanas

Una de las funciones de TCP es asegurar que cada segmento llegue
a su destino. Los servicios TCP en el host de destino envían a la
aplicación de origen un acuse de recibo de los datos recibidos.

El número de secuencia y el número de acuse de recibo del
encabezado del segmento se utilizan para confirmar la recepción de
los bytes de datos contenidos en los segmentos. El número de
secuencia es el número relativo de bytes que ha sido transmitido en
esta sesión más 1 (que es el número del primer byte de datos en el
segmento actual). TCP utiliza el número de reconocimiento en
segmentos que se vuelven a enviar al origen para indicar el próximo
byte de esta sesión que espera el receptor. Esto se llama acuse de
recibo de expectativa.
Se le informa al origen que el destino ha recibido todos los bytes de
este stream de datos, pero sin incluir, el byte especificado por el
número de acuse de recibo. Se espera que el host emisor envíe un
segmento que utiliza un número de secuencia igual al número de
acuse de recibo.

Recuerde que cada conexión se representa en realidad por dos
sesiones de una vía. Los números de secuencia y de acuse de recibo
se intercambian en ambas direcciones.

En el ejemplo de la figura, el host en la izquierda envía datos al host
de la derecha. Envía un segmento que contiene 10 bytes de datos
para esta sesión y un número de secuencia igual a 1 en el
encabezado.

El host receptor de la derecha recibe el segmento en la Capa 4 y
determina que el número de secuencia es 1 y que posee 10 bytes
de datos. Luego el host envía un segmento de vuelta al host de la
izquierda para acusar recibo de estos datos. En este segmento, el
host establece el número de acuse de recibo en 11 para indicar que
el próximo byte de datos que espera recibir en esta sesión es el
byte número 11.

Cuando el host emisor de la izquierda recibe este acuse de recibo,
puede enviar el próximo segmento que contiene datos para esta
sesión a partir del byte 11.

Observando este ejemplo, si el host emisor tuviera que esperar el
acuse de recibo por la recepción de cada uno de los 10 bytes, la red
estaría demasiado sobrecargada. Para reducir la sobrecarga de
estos acuses de recibo, los segmentos de datos múltiples pueden
enviarse previamente y ser reconocidos con un mensaje TCP simple
en la dirección opuesta. Este reconocimiento contiene un número
de acuse de recibo en base al número total de bytes recibidos en la
sesión.

Por ejemplo, si se comienza con un número de secuencia 2000, si se
reciben 10 segmentos de 1000 bytes cada uno, se devolverá al
origen un número de reconocimiento igual a 12001.

La cantidad de datos que un origen puede transmitir antes de que
un acuse de recibo deba ser recibido se denomina tamaño de la
ventana. El tamaño de la ventana es un campo en el encabezado
TCP que permite la administración de datos perdidos y el control
del flujo.
Retransmisión de TCP

Manejo de la pérdida de segmentos
Por óptimo que sea el diseño de una red, siempre se producirán
pérdidas ocasionales de datos. Por lo tanto, TCP cuenta con
métodos para gestionar dichas pérdidas de segmentos. Entre los
mismos existe un mecanismo para retransmitir segmentos con
datos no reconocidos.

Un servicio de host de destino que utiliza TCP, por lo general sólo
reconoce datos para secuencias de bytes contiguas. Si uno o más
segmentos se pierden, sólo se acusa recibo de los datos de los
segmentos que completan el stream.

Por ejemplo, si se reciben los segmentos con números de secuencia
de 1500 a 3000 y de 3400 a 3500, el número de acuse de recibo
será 3001. Esto sucede porque existen segmentos con números de
secuencia de 3001 a 3399 que no se recibieron.

Cuando TCP en el host de origen no recibe un acuse de recibo
pasado un tiempo predeterminado, volverá al último número de
acuse de recibo que recibió y retransmitirá los datos a partir de
éste.

El proceso de retransmisión no es especificado por RFC, sino que
depende de la implementación de TCP en particular.

Para una implementación de TCP típica, un host puede transmitir
un segmento, colocar una copia del segmento en una cola de
retransmisión e iniciar un temporizador. Cuando se recibe el acuse
de recibo de los datos, se elimina el segmento de la cola. Si no se
recibe el acuse de recibo antes de que el temporizador venza, el
segmento es retransmitido.
Los hosts actuales también suelen emplear una función opcional
llamada Acuses de recibo selectivos. Si ambos hosts admiten el
Acuse de recibo selectivo, es posible que el destino reconozca los
bytes de segmentos discontinuos y el host sólo necesitará
retransmitir los datos perdidos.

Control de congestión de TCP: Cómo minimizar la pérdida de
segmentos

Control del flujo

TCP si provee mecanismos para el control del flujo. El control del
flujo contribuye con la confiabilidad de la transmisión TCP
ajustando la tasa efectiva de flujo de datos entre los dos servicios
de la sesión. Cuando el origen advierte que se recibió la cantidad de
datos especificados en los segmentos, puede continuar enviando
más datos para esta sesión.

El campo Tamaño de la ventana en el encabezado TCP especifica la
cantidad de datos que puede transmitirse antes de que se reciba el
acuse de recibo. El tamaño de la ventana inicial se determina
durante el comienzo de la sesión a través del enlace de tres vías.

El mecanismo de retroalimentación de TCP ajusta la tasa de
transmisión de datos efectiva al flujo máximo que la red y el
dispositivo de destino pueden soportar sin sufrir pérdidas. TCP
intenta gestionar la tasa de transmisión de manera que todos los
datos se reciban y se reduzcan las retransmisiones.

Ver la figura para obtener una representación simplificada del
tamaño de la ventana y los acuses de recibo. En este ejemplo, el
tamaño de la ventana inicial para una sesión TCP representada se
establece en 3000 bytes. Cuando el emisor transmite 3000 bytes,
espera por un acuse de recibo de los mismos antes de transmitir
más segmentos para esta sesión.

Una vez que el emisor ha recibido este acuse de recibo del
receptor, ya puede transmitir 3000 bytes adicionales.

Durante la demora en la recepción del acuse de recibo, el emisor no
enviará ningún segmento adicional para esta sesión. En los
períodos en los que la red está congestionada o los recursos del
host receptor están exigidos, la demora puede aumentar. A medida
que aumenta esta demora, disminuye la tasa de transmisión
efectiva de los datos para esta sesión. La disminución de la tasa de
datos ayuda a reducir la contención de recursos.
Reducción del tamaño de la ventana
Otra forma de controlar el flujo de datos es utilizar tamaños
dinámicos de ventana. Cuando los recursos de la red son limitados,
TCP puede reducir el tamaño de la ventana para lograr que los
segmentos recibidos sean reconocidos con mayor frecuencia. Esto
disminuye de manera efectiva la tasa de transmisión, ya que el
origen espera que los datos sean recibidos con más frecuencia.

El host receptor TCP envía el valor del tamaño de la ventana al TCP
emisor para indicar el número de bytes que está preparado para
recibir como parte de la sesión. Si el destino necesita disminuir la
tasa de comunicación debido a limitaciones de memoria del búfer,
puede enviar un valor de tamaño de la ventana menor al origen
como parte de un acuse de recibo.

Como se muestra en la figura, si un host de recepción sufre una
congestión, puede responder al host emisor con un segmento con
el tamaño de la ventana reducido. En este gráfico, se produjo la
pérdida de uno de los segmentos. El receptor cambió el campo
ventana en el encabezado de los mensajes devueltos en esta
conversación de 3000 a 1500. Esto hizo que el emisor redujera el
tamaño de la ventana a 1500.

Después de períodos de transmisión sin pérdidas de datos o
recursos limitados, el receptor comenzará a aumentar el tamaño de
la ventana. Esto reduce la sobrecarga de la red, ya que se requiere
enviar menos acuses de recibo. El tamaño de la ventana continuará
aumentando hasta que haya pérdida de datos, lo que producirá una
disminución del tamaño de la ventana.

Estas disminuciones y aumentos dinámicos del tamaño de la
ventana representan un proceso continuo en TCP, que determina el
tamaño de la ventana óptimo para cada sesión TCP. En redes
altamente eficientes, los tamaños de la ventana pueden ser muy
grandes porque no se pierden datos. En redes donde se está
estresando la infraestructura subyacente, el tamaño de la ventana
probablemente permanecerá pequeño.

Enlaces

Detalles de las varias características de administración de la
congestión de TCP se pueden encontrar en RFC 2581.
Protocolo UDP

El protocolo TCP tiene la robustez, la confiabilidad y las
funcionalidades propias de un protocolo de transporte orientado a
conexión, pero a veces resulta demasiado complejo. Por ejemplo,
cualquier transmisión de información TCP requiere como mínimo el
intercambio de seis mensajes para establecer la comunicación y
terminarla; además mientras una conexión existe ocupa una serie
de recursos en el host.

Para casos en los que no es necesario tanto control de los datos
enviados la Capa de Transporte implementa también el Protocolo
de Datagrama de Usuario (UDP), protocolo no confiable y no
orientado a conexión para la entrega de mensajes discretos. En este
caso los paquetes enviados mediante el protocolo IP reciben el
nombre específico de datagramas, y estos se envían y ya está; no se
realiza una conexión definida entre los host ni un control de los
paquetes enviados y recibidos. Los datagramas se rutean
independientemente, por lo que deben llevar las dirección
completa de destino.

UDP es un protocolo estándar con número 6 de STD. Este protocolo
se describe en el RFC 768 - Protocolo de Datagrama de Usuario. Es
simple, eficiente e ideal para aplicaciones como el TFTP y el DNS.
Una dirección IP sirve para dirigir el datagrama hacia una máquina
en particular, y el número de puerto de destino en la cabecera UDP
se utiliza para dirigir el datagrama UDP a un proceso específico en
dicha máquina. La cabecera UDP también contiene un número de
puerto origen que permite al proceso recibido conocer cómo
responder al datagrama.

Es una alternativa al TCP en aquellos casos en los que no sea
necesaria tanta complejidad en el envío, por lo que se usa cuando
una entrega rápida es más importante que una entrega
garantizada, o en los casos en que se desea enviar tan poca
información que cabe en un único datagrama. Así, una de sus
utilidades más comunes es el envío de mensajes entre aplicaciones
de dos host.




Es por ello un protocolo del tipo best-effort (máximo esfuerzo),
porque hace lo que puede para transmitir los datagramas hacia la
aplicación, pero no puede garantizar que la aplicación los reciba.

Tampoco utiliza mecanismos de detección de errores. Cuando se
detecta un error en un datagrama, en lugar de entregarlo a la
aplicación destino, se descarta.

Cuando una aplicación envía datos a través de UDP, éstos llegan al
otro extremo como una unidad. Por ejemplo, si una aplicación
escribe 5 veces en el puerto UDP, la aplicación al otro extremo hará
5 lecturas del puerto UDP. Además, el tamaño de cada escritura
será igual que el tamaño de las lecturas.

AL igual que TCP, UDP usa al protocolo IP para transportar sus
segmentos. El formato del segmento UDP es el siguiente:

                           segmento UDP
 0                    10                 20                 30
 0123456789012345678901234567890 1
 Puerto UDP origen                Puerto UDP destino
 Longitud del datagrama           Checksum UDP
 Datos
 ...

Cuyos campos principales son:

  •    Puerto UDP de origen: campo opcional de 16 bits que
       especifica el puerto del host origen remitente del datagrama.
  •    Puerto UDP de destino: campo obligatorio de 16 bits que
       especifica el puerto del host destino al que se envía el
       datagrama.
  •    Longitud del datagrama: campo obligatorio de 16 bits que
       especifica la longitud en bytes del datagrama, incluyendo la
       cabecera. La longitud mínima es de 8 bytes. En realidad es la
       longitud del datagrama IP menos el tamaño de la cabecera IP.
       Como la longitud máxima del datagrama IP es de 65.535 bytes
       y la cabecera estándar de IP es de 20 bytes, la longitud
       máxima de un datagrama UDP es de 65.515 bytes.
  •    Checksum UDP: campo de 16 bits opcional que almacena una
       suma de comprobación de errores del datagrama, que se
       calcula a partir de una pseudo-cabecera.
Si el checksum es cero, quiere decir que no se calculó el
      checksum en el origen y que puede ser ignorado. Esto significa
      que el módulo UDP del computador origen puede o no
      generar checksums. Si Ethernet es el único tipo de red entre
      los dos módulos UDP que se comunican, entonces puede que
      no sea necesario calcular el checksum. Sin embargo, es
      recomendable habilitar la generación de checksums porque
      quizás en el futuro un cambio en la tabla de encaminamiento
      puede enviar los datos a través de un medio menos fiable que
      Ethernet.

      Si el checksum es válido (o cero), se examina el número de
      puerto destino y si hay una aplicación escuchando en ese
      puerto, un mensaje de aplicación queda en la cola de lectura
      de esa aplicación. Si no hay ninguna aplicación en ese puerto,
      el datagrama UDP se descarta. Si los datagramas UDP llegan
      más rápido de lo que la aplicación puede leerlos, la cola
      comenzará a llenarse; si se sobrepasa un valor máximo, los
      datagramas UDP siguientes serán descartados por UDP. UDP
      seguirá descartando datagramas hasta que haya espacio en la
      cola.

  •   Datos: campo obligatorio que contiene los datos que se
      envían las aplicaciones con el datagrama.

Algunos ejemplos de situaciones en las que es más conveniente un
servicio no orientado a conexión, en los que es más útil un
protocolo del tipo UDP, son:

  •   Aplicaciones tiempo real como audio o video, donde no se
      puede tolerar el retardo producido por los ACK.
  •   Consultas a servidores en que se requiere el envío de uno o
      dos mensajes únicamente como es el caso del DNS.
•   Situaciones en las que se necesita conectar con un ordenador
      de la propia red, usando para ello el nombre del sistema. Para
      ello hay que conectar primero con el servidor de red
      apropiado para que transforme dicha dirección de red en una
      dirección IP válida, siendo en este caso más apropiado el
      protocolo UDP.
  •   Cuando queremos transmitir información en modo multicast
      (a muchos destinos) o en modo broadcast (a todos los
      destinos) pues no tiene sentido esperar la confirmación de
      todos los destinos para continuar con la transmisión. También
      es importante tener en cuenta que si en una transmisión de
      este tipo los destinos enviarán confirmación, fácilmente el
      emisor se vería colapsado, pues por cada paquete que envía
      recibiría tantas confirmaciones como destinos hayan recibido
      el paquete.

Entre los protocolos superiores que usan UDP se incluyen TFTP
(Trivial File Transfer Protocol), DNS (Domain Name Server), SNMP
(Simple Network Management Protocol), NTP (Network Time
Protocol), NFS (Network File System), etc.

Más contenido relacionado

La actualidad más candente

Capa 4 diapositivas
Capa 4 diapositivasCapa 4 diapositivas
Capa 4 diapositivas
dardblader
 
Capa de enlace de datos y capa física del modelo osi.
Capa de enlace de datos y capa física del modelo osi.Capa de enlace de datos y capa física del modelo osi.
Capa de enlace de datos y capa física del modelo osi.
Deysi Sanchez Vazquez
 
Capitulo 4: Capa de transporte del modelo OSI
Capitulo 4: Capa de transporte del modelo OSICapitulo 4: Capa de transporte del modelo OSI
Capitulo 4: Capa de transporte del modelo OSI
Octavio
 
ComunicacióN De Datos Basadas En Capas
ComunicacióN De Datos Basadas En CapasComunicacióN De Datos Basadas En Capas
ComunicacióN De Datos Basadas En Capas
mario23
 
capa de transporte del modelo OSI
capa de transporte del modelo OSIcapa de transporte del modelo OSI
capa de transporte del modelo OSI
marcoantonioge
 
Capa de Enlace De Datos
Capa de Enlace De DatosCapa de Enlace De Datos
Capa de Enlace De Datos
Comdat4
 
Capa de transporte jose manosalva
Capa de transporte jose manosalvaCapa de transporte jose manosalva
Capa de transporte jose manosalva
J_MANOSALVA
 
Conmutacion de redes
Conmutacion de redesConmutacion de redes
Conmutacion de redes
Francisco Javier Velasco Méndez
 
ConmutacióN De Datos
ConmutacióN De DatosConmutacióN De Datos
ConmutacióN De Datos
trucco_59
 
Conceptual enlace de datos
Conceptual enlace de datosConceptual enlace de datos
Conceptual enlace de datos
gchv
 
COMERCIO ELECTRONICO UNIDAD III
COMERCIO ELECTRONICO UNIDAD IIICOMERCIO ELECTRONICO UNIDAD III
COMERCIO ELECTRONICO UNIDAD III
ALBAYCOTA
 
Funciones de la capa de enlace
Funciones de la capa de enlaceFunciones de la capa de enlace
Funciones de la capa de enlace
cleiver_antonio
 
Concepto de conmutacion
Concepto de conmutacionConcepto de conmutacion
Concepto de conmutacion
gpava
 
SIWTC Y HUB
SIWTC Y HUBSIWTC Y HUB
SIWTC Y HUB
Richard Ochoa
 
Elementos de protocolos de transporte
Elementos de protocolos de transporteElementos de protocolos de transporte
Elementos de protocolos de transporte
Freddy Hugo Estupiñan Batalla
 
Normas del Modelo OSI y modelo UTP
Normas del Modelo OSI y modelo UTPNormas del Modelo OSI y modelo UTP
Normas del Modelo OSI y modelo UTP
Hector Dario Ortega Velasquez
 
Descripción del modelo osi
Descripción del modelo osiDescripción del modelo osi
Descripción del modelo osi
luis_uriel
 
Tecnología frame relay
Tecnología frame relayTecnología frame relay
Tecnología frame relay
Jonathan Fabrizzio Argüello Valle
 
Conmutacion
ConmutacionConmutacion
Conmutacion
sosle
 
Reporte del capitulo 5
Reporte del capitulo 5Reporte del capitulo 5
Reporte del capitulo 5
Roshio Vaxquez
 

La actualidad más candente (20)

Capa 4 diapositivas
Capa 4 diapositivasCapa 4 diapositivas
Capa 4 diapositivas
 
Capa de enlace de datos y capa física del modelo osi.
Capa de enlace de datos y capa física del modelo osi.Capa de enlace de datos y capa física del modelo osi.
Capa de enlace de datos y capa física del modelo osi.
 
Capitulo 4: Capa de transporte del modelo OSI
Capitulo 4: Capa de transporte del modelo OSICapitulo 4: Capa de transporte del modelo OSI
Capitulo 4: Capa de transporte del modelo OSI
 
ComunicacióN De Datos Basadas En Capas
ComunicacióN De Datos Basadas En CapasComunicacióN De Datos Basadas En Capas
ComunicacióN De Datos Basadas En Capas
 
capa de transporte del modelo OSI
capa de transporte del modelo OSIcapa de transporte del modelo OSI
capa de transporte del modelo OSI
 
Capa de Enlace De Datos
Capa de Enlace De DatosCapa de Enlace De Datos
Capa de Enlace De Datos
 
Capa de transporte jose manosalva
Capa de transporte jose manosalvaCapa de transporte jose manosalva
Capa de transporte jose manosalva
 
Conmutacion de redes
Conmutacion de redesConmutacion de redes
Conmutacion de redes
 
ConmutacióN De Datos
ConmutacióN De DatosConmutacióN De Datos
ConmutacióN De Datos
 
Conceptual enlace de datos
Conceptual enlace de datosConceptual enlace de datos
Conceptual enlace de datos
 
COMERCIO ELECTRONICO UNIDAD III
COMERCIO ELECTRONICO UNIDAD IIICOMERCIO ELECTRONICO UNIDAD III
COMERCIO ELECTRONICO UNIDAD III
 
Funciones de la capa de enlace
Funciones de la capa de enlaceFunciones de la capa de enlace
Funciones de la capa de enlace
 
Concepto de conmutacion
Concepto de conmutacionConcepto de conmutacion
Concepto de conmutacion
 
SIWTC Y HUB
SIWTC Y HUBSIWTC Y HUB
SIWTC Y HUB
 
Elementos de protocolos de transporte
Elementos de protocolos de transporteElementos de protocolos de transporte
Elementos de protocolos de transporte
 
Normas del Modelo OSI y modelo UTP
Normas del Modelo OSI y modelo UTPNormas del Modelo OSI y modelo UTP
Normas del Modelo OSI y modelo UTP
 
Descripción del modelo osi
Descripción del modelo osiDescripción del modelo osi
Descripción del modelo osi
 
Tecnología frame relay
Tecnología frame relayTecnología frame relay
Tecnología frame relay
 
Conmutacion
ConmutacionConmutacion
Conmutacion
 
Reporte del capitulo 5
Reporte del capitulo 5Reporte del capitulo 5
Reporte del capitulo 5
 

Destacado

R2 b12 función raíz cuadrada
R2 b12  función raíz cuadradaR2 b12  función raíz cuadrada
R2 b12 función raíz cuadrada
Erick Guarneros Valera
 
Starting with You Tube
Starting with You TubeStarting with You Tube
Starting with You Tube
youtubetips
 
Uk pv market strategy execution cb
Uk pv market strategy execution cbUk pv market strategy execution cb
Uk pv market strategy execution cb
Christian Bogue
 
41 Pdfsam
41 Pdfsam41 Pdfsam
41 Pdfsam
Emanuel Mateus
 
Esas Personas
Esas PersonasEsas Personas
Esas Personas
iejcg
 
XPD Учет документов (Делопроизводство)
XPD Учет документов (Делопроизводство)XPD Учет документов (Делопроизводство)
XPD Учет документов (Делопроизводство)
ИНТЕРСОФТ
 
Curso enseñar y aprender con tic´s
Curso enseñar y aprender con tic´sCurso enseñar y aprender con tic´s
Curso enseñar y aprender con tic´s
Veronica Sala
 
Long range bluetooth dongle
Long range bluetooth dongleLong range bluetooth dongle
Long range bluetooth dongle
GuangZhou DeviceGate Technology Inc.
 
Triangles diffrent kinds top view side view powerpoint presentation templates.
Triangles diffrent kinds top view side view powerpoint presentation templates.Triangles diffrent kinds top view side view powerpoint presentation templates.
Triangles diffrent kinds top view side view powerpoint presentation templates.
SlideTeam.net
 
Lesage
LesageLesage
Lesage
eric_gautier
 
Neurodesarrollo
NeurodesarrolloNeurodesarrollo
Neurodesarrollo
silsst
 
Mapa conceptual de las tic
Mapa conceptual de las ticMapa conceptual de las tic
Mapa conceptual de las tic
diegoquintana10
 
Los sistemas operativos
Los sistemas operativosLos sistemas operativos
Los sistemas operativos
b2btic_dbuenoc
 
Tarta de galleta
Tarta de galletaTarta de galleta
Tarta de galleta
mallirilla
 
Jogo habbo por tropamascote8 c
Jogo habbo por tropamascote8 cJogo habbo por tropamascote8 c
Jogo habbo por tropamascote8 c
Tropamascote8
 
Xavi j.luis
Xavi j.luisXavi j.luis
Xavi j.luis
angelacerpa97
 
Introducción esteban
Introducción estebanIntroducción esteban
Introducción esteban
Jorge Marin Schmerzen
 
Proyecto de extensión feuah
Proyecto de extensión feuahProyecto de extensión feuah
Proyecto de extensión feuah
Magdalena Provis
 
Workshop for concurrent auditors conducted by Ashim Munshi
Workshop for concurrent auditors conducted by Ashim MunshiWorkshop for concurrent auditors conducted by Ashim Munshi
Workshop for concurrent auditors conducted by Ashim Munshi
ASHIM MUNSHI
 

Destacado (19)

R2 b12 función raíz cuadrada
R2 b12  función raíz cuadradaR2 b12  función raíz cuadrada
R2 b12 función raíz cuadrada
 
Starting with You Tube
Starting with You TubeStarting with You Tube
Starting with You Tube
 
Uk pv market strategy execution cb
Uk pv market strategy execution cbUk pv market strategy execution cb
Uk pv market strategy execution cb
 
41 Pdfsam
41 Pdfsam41 Pdfsam
41 Pdfsam
 
Esas Personas
Esas PersonasEsas Personas
Esas Personas
 
XPD Учет документов (Делопроизводство)
XPD Учет документов (Делопроизводство)XPD Учет документов (Делопроизводство)
XPD Учет документов (Делопроизводство)
 
Curso enseñar y aprender con tic´s
Curso enseñar y aprender con tic´sCurso enseñar y aprender con tic´s
Curso enseñar y aprender con tic´s
 
Long range bluetooth dongle
Long range bluetooth dongleLong range bluetooth dongle
Long range bluetooth dongle
 
Triangles diffrent kinds top view side view powerpoint presentation templates.
Triangles diffrent kinds top view side view powerpoint presentation templates.Triangles diffrent kinds top view side view powerpoint presentation templates.
Triangles diffrent kinds top view side view powerpoint presentation templates.
 
Lesage
LesageLesage
Lesage
 
Neurodesarrollo
NeurodesarrolloNeurodesarrollo
Neurodesarrollo
 
Mapa conceptual de las tic
Mapa conceptual de las ticMapa conceptual de las tic
Mapa conceptual de las tic
 
Los sistemas operativos
Los sistemas operativosLos sistemas operativos
Los sistemas operativos
 
Tarta de galleta
Tarta de galletaTarta de galleta
Tarta de galleta
 
Jogo habbo por tropamascote8 c
Jogo habbo por tropamascote8 cJogo habbo por tropamascote8 c
Jogo habbo por tropamascote8 c
 
Xavi j.luis
Xavi j.luisXavi j.luis
Xavi j.luis
 
Introducción esteban
Introducción estebanIntroducción esteban
Introducción esteban
 
Proyecto de extensión feuah
Proyecto de extensión feuahProyecto de extensión feuah
Proyecto de extensión feuah
 
Workshop for concurrent auditors conducted by Ashim Munshi
Workshop for concurrent auditors conducted by Ashim MunshiWorkshop for concurrent auditors conducted by Ashim Munshi
Workshop for concurrent auditors conducted by Ashim Munshi
 

Similar a Capa de transporte

CAPA DE TRANSPORTE.pptx
CAPA DE TRANSPORTE.pptxCAPA DE TRANSPORTE.pptx
CAPA DE TRANSPORTE.pptx
juan gonzalez
 
Capa 4
Capa 4Capa 4
Capa de transporte nivel enrutamiento - pat - nat
Capa de transporte   nivel enrutamiento - pat - natCapa de transporte   nivel enrutamiento - pat - nat
Capa de transporte nivel enrutamiento - pat - nat
Jairo Quiroz Cabanillas
 
TALLER N. 10- MODELO EN CAPAS ISO
TALLER N. 10- MODELO EN CAPAS  ISOTALLER N. 10- MODELO EN CAPAS  ISO
TALLER N. 10- MODELO EN CAPAS ISO
mario23
 
ELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptx
ELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptxELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptx
ELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptx
JOSUEELIANBETANCOURT
 
Modelo osi
Modelo osiModelo osi
Modelo osi
ComputadoresSmc
 
Niveles De Modelo Osi Capas Tres Y Cuatro
Niveles De Modelo Osi   Capas Tres Y CuatroNiveles De Modelo Osi   Capas Tres Y Cuatro
Niveles De Modelo Osi Capas Tres Y Cuatro
farud
 
Modelo Osi[1]
Modelo Osi[1]Modelo Osi[1]
Modelo Osi[1]
METALJUANA
 
CAPA DE RED.pptx
CAPA DE RED.pptxCAPA DE RED.pptx
CAPA DE RED.pptx
juan gonzalez
 
Resumen parte1 TCP/IP Equipo1
Resumen parte1 TCP/IP Equipo1Resumen parte1 TCP/IP Equipo1
Resumen parte1 TCP/IP Equipo1
David Guadarrama
 
Osi jhon mora 661399
Osi jhon mora 661399Osi jhon mora 661399
Osi jhon mora 661399
Anda Pero Si Es John
 
Capas de redes
Capas de redesCapas de redes
Capas de redes
Paola Naye Aranda
 
Capas de redes
Capas de redesCapas de redes
Capas de redes
nayearan
 
Sistemas Distribuidos
Sistemas  DistribuidosSistemas  Distribuidos
Sistemas Distribuidos
santiago
 
Transmisión de información
Transmisión de informaciónTransmisión de información
Transmisión de información
Alex Campiño
 
Capa de enlace de datos
Capa de enlace de datosCapa de enlace de datos
Capa de enlace de datos
Joohana Yañeez
 
Redes Cap10
Redes Cap10Redes Cap10
Redes Cap10
CJAO
 
SERVIDORES – GNU LINUX
SERVIDORES – GNU LINUXSERVIDORES – GNU LINUX
SERVIDORES – GNU LINUX
BenjaminAnilema
 
Modelo osi
Modelo osiModelo osi
Modelo osi
Richard Javiers
 
Tema2.b.nivel osi
Tema2.b.nivel osiTema2.b.nivel osi
Tema2.b.nivel osi
Alvaro Santero Martin
 

Similar a Capa de transporte (20)

CAPA DE TRANSPORTE.pptx
CAPA DE TRANSPORTE.pptxCAPA DE TRANSPORTE.pptx
CAPA DE TRANSPORTE.pptx
 
Capa 4
Capa 4Capa 4
Capa 4
 
Capa de transporte nivel enrutamiento - pat - nat
Capa de transporte   nivel enrutamiento - pat - natCapa de transporte   nivel enrutamiento - pat - nat
Capa de transporte nivel enrutamiento - pat - nat
 
TALLER N. 10- MODELO EN CAPAS ISO
TALLER N. 10- MODELO EN CAPAS  ISOTALLER N. 10- MODELO EN CAPAS  ISO
TALLER N. 10- MODELO EN CAPAS ISO
 
ELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptx
ELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptxELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptx
ELEMENTOS DEL PROTOCOLO DE TRANSPORTE.pptx
 
Modelo osi
Modelo osiModelo osi
Modelo osi
 
Niveles De Modelo Osi Capas Tres Y Cuatro
Niveles De Modelo Osi   Capas Tres Y CuatroNiveles De Modelo Osi   Capas Tres Y Cuatro
Niveles De Modelo Osi Capas Tres Y Cuatro
 
Modelo Osi[1]
Modelo Osi[1]Modelo Osi[1]
Modelo Osi[1]
 
CAPA DE RED.pptx
CAPA DE RED.pptxCAPA DE RED.pptx
CAPA DE RED.pptx
 
Resumen parte1 TCP/IP Equipo1
Resumen parte1 TCP/IP Equipo1Resumen parte1 TCP/IP Equipo1
Resumen parte1 TCP/IP Equipo1
 
Osi jhon mora 661399
Osi jhon mora 661399Osi jhon mora 661399
Osi jhon mora 661399
 
Capas de redes
Capas de redesCapas de redes
Capas de redes
 
Capas de redes
Capas de redesCapas de redes
Capas de redes
 
Sistemas Distribuidos
Sistemas  DistribuidosSistemas  Distribuidos
Sistemas Distribuidos
 
Transmisión de información
Transmisión de informaciónTransmisión de información
Transmisión de información
 
Capa de enlace de datos
Capa de enlace de datosCapa de enlace de datos
Capa de enlace de datos
 
Redes Cap10
Redes Cap10Redes Cap10
Redes Cap10
 
SERVIDORES – GNU LINUX
SERVIDORES – GNU LINUXSERVIDORES – GNU LINUX
SERVIDORES – GNU LINUX
 
Modelo osi
Modelo osiModelo osi
Modelo osi
 
Tema2.b.nivel osi
Tema2.b.nivel osiTema2.b.nivel osi
Tema2.b.nivel osi
 

Más de Fer Gilces

Pdu
PduPdu
Introduccion a redes
Introduccion a redesIntroduccion a redes
Introduccion a redes
Fer Gilces
 
Capa de aplicacion
Capa de aplicacionCapa de aplicacion
Capa de aplicacion
Fer Gilces
 
Capa de red
Capa de redCapa de red
Capa de red
Fer Gilces
 
Ethernet
EthernetEthernet
Ethernet
Fer Gilces
 
Modelo OSI y Arquitectura TCP IP
Modelo OSI y Arquitectura TCP IPModelo OSI y Arquitectura TCP IP
Modelo OSI y Arquitectura TCP IP
Fer Gilces
 
Direccionamiento IPv4
Direccionamiento IPv4Direccionamiento IPv4
Direccionamiento IPv4
Fer Gilces
 
Capa enlace de datos
Capa enlace de datosCapa enlace de datos
Capa enlace de datos
Fer Gilces
 
Armar un cable de red
Armar un cable de redArmar un cable de red
Armar un cable de red
Fer Gilces
 
Modelo osi y arquitectura tcp ip
Modelo osi y arquitectura tcp ipModelo osi y arquitectura tcp ip
Modelo osi y arquitectura tcp ip
Fer Gilces
 
Introduccion a redes
Introduccion a redesIntroduccion a redes
Introduccion a redes
Fer Gilces
 
Capa de Aplicacion
Capa de AplicacionCapa de Aplicacion
Capa de Aplicacion
Fer Gilces
 
Direccionamiento IPv4
Direccionamiento IPv4Direccionamiento IPv4
Direccionamiento IPv4
Fer Gilces
 
Capa Fisica
Capa FisicaCapa Fisica
Capa Fisica
Fer Gilces
 
Capa de red
Capa de redCapa de red
Capa de red
Fer Gilces
 
Capa de enlace de datos
Capa de enlace de datosCapa de enlace de datos
Capa de enlace de datos
Fer Gilces
 
Como armar un cable
Como armar un cableComo armar un cable
Como armar un cable
Fer Gilces
 
Ethernet
EthernetEthernet
Ethernet
Fer Gilces
 

Más de Fer Gilces (19)

Capa fisica
Capa fisicaCapa fisica
Capa fisica
 
Pdu
PduPdu
Pdu
 
Introduccion a redes
Introduccion a redesIntroduccion a redes
Introduccion a redes
 
Capa de aplicacion
Capa de aplicacionCapa de aplicacion
Capa de aplicacion
 
Capa de red
Capa de redCapa de red
Capa de red
 
Ethernet
EthernetEthernet
Ethernet
 
Modelo OSI y Arquitectura TCP IP
Modelo OSI y Arquitectura TCP IPModelo OSI y Arquitectura TCP IP
Modelo OSI y Arquitectura TCP IP
 
Direccionamiento IPv4
Direccionamiento IPv4Direccionamiento IPv4
Direccionamiento IPv4
 
Capa enlace de datos
Capa enlace de datosCapa enlace de datos
Capa enlace de datos
 
Armar un cable de red
Armar un cable de redArmar un cable de red
Armar un cable de red
 
Modelo osi y arquitectura tcp ip
Modelo osi y arquitectura tcp ipModelo osi y arquitectura tcp ip
Modelo osi y arquitectura tcp ip
 
Introduccion a redes
Introduccion a redesIntroduccion a redes
Introduccion a redes
 
Capa de Aplicacion
Capa de AplicacionCapa de Aplicacion
Capa de Aplicacion
 
Direccionamiento IPv4
Direccionamiento IPv4Direccionamiento IPv4
Direccionamiento IPv4
 
Capa Fisica
Capa FisicaCapa Fisica
Capa Fisica
 
Capa de red
Capa de redCapa de red
Capa de red
 
Capa de enlace de datos
Capa de enlace de datosCapa de enlace de datos
Capa de enlace de datos
 
Como armar un cable
Como armar un cableComo armar un cable
Como armar un cable
 
Ethernet
EthernetEthernet
Ethernet
 

Capa de transporte

  • 1. Capa de Transporte OSI El modelo de referencia de Interconexión de Sistemas Abiertos (OSI, Open System Interconnection) es el modelo de red descriptivo creado por la Organización Internacional para la Estandarización lanzado en 1984. Es decir, es un marco de referencia para la definición de arquitecturas de interconexión de sistemas de comunicación. El nivel de transporte o capa transporte es el cuarto nivel del modelo OSI encargado de la transferencia libre de errores de los datos entre el emisor y el receptor, aunque no estén directamente conectados, así como de mantener el flujo de la red. La tarea de esta capa es proporcionar un transporte de datos confiable y económico de la máquina de origen a la máquina destino, independientemente de la red de redes física en uno. Sin la capa transporte, el concepto total de los protocolos en capas tendría poco sentido. Capa encargada de efectuar el transporte de los datos (que se encuentran dentro del paquete) de la máquina origen a la de destino, independizándolo del tipo de red física que se esté utilizando. La PDU de la capa 4 se llama Segmento o Datagrama, dependiendo de si corresponde a TCP o UDP. Sus protocolos son TCP y UDP; el primero orientado a conexión y el otro sin conexión. Trabajan, por lo tanto, con puertos lógicos y junto con la capa red dan forma a los conocidos como Sockets IP:Puerto (192.168.1.1:80).
  • 2. Servicios Hay dos tipos de servicio en la capa transporte, orientado y no orientado a la conexión. En el servicio orientado a la conexión consta de tres partes: establecimiento, transferencia de datos, y liberación. En el servicio no orientado a la conexión se tratan los paquetes de forma individual. Es la primera capa que lleva a cabo la comunicación extremo a extremo, y esta condición ya se mantendrá en las capas superiores. Primitivas del servicio de transporte Para permitir que los usuarios accedan al servicio de transporte, la capa de transporte debe proporcionar algunas operaciones a los programas de aplicación, es decir, una interfaz del servicio de transporte. Cada servicio de transporte tiene su propia interfaz. Con el propósito de ver los aspectos básicos, en esta sección examinaremos primero un servicio de transporte sencillo y su interfaz. El servicio de transporte es parecido al servicio en red, pero hay algunas diferencias importantes. La principal, es que, el propósito del servicio de red es modelar el servicio ofrecido por las redes reales, con todos sus problemas. Las redes reales pueden perder paquetes, por lo que generalmente el servicio no es confiable. En cambio, el servicio de transporte (orientado a la conexión) si es confiable.
  • 3. Claro que las redes reales no están libres de errores, pero ése es precisamente el propósito de la capa de transporte: ofrecer un servicio confiable en una red no confiable. Otra diferencia entre la capa transporte y la de red es a quien van dirigidos sus servicios. El servicio de red lo usan únicamente las entidades de transporte. Pocos usuarios escriben sus entidades de transporte y pocos usuarios o programas llegan a ver los aspectos internos del servicio de red. En cambio, muchos programas ven primitivas de transporte. En consecuencia el servicio de transporte debe ser adecuado y fácil de usar. Las primitivas de un transporte sencillo serían: LISTEN: Se bloquea hasta que algún proceso intenta el contacto. CONNECT: Intenta activamente establecer una conexión. SEND: Envía información. RECEIVE: Se bloque hasta que llegue una TPDU de DATOS. DISCONNECT: Este lado quiere liberar la conexión. Y con estas primitivas podemos hacer un esquema sencillo de manejo de conexiones. Las transiciones escritas en cursiva son causadas por llegadas de paquetes. Las líneas continuas muestran la secuencia de estados del cliente y las líneas punteadas muestran la secuencia del servidor.
  • 4. Elementos de los protocolos de transporte El servicio de transporte se implementa mediante un protocolo de transporte entre dos entidades de transporte. En ciertos aspectos, los protocolos de transporte se parecen a los protocolos de red. Ambos se encargan del control de errores, la secuenciación y el control del flujo. Pero también existen diferencias importantes entre ambas, como los entornos en que operan, la capa transporte necesita el direccionamiento explícito de los destinos, mientras que la capa de red no, otra diferencia es la cantidad de datos, mucho mayor en la capa de transporte que en la de enlace de datos. DIRECCIONAMIENTO Cuando un proceso desea establecer una conexión con un proceso de aplicación remoto, debe especificar a cuál se conectará. (¿A quién mando el mensaje?) El método que normalmente se emplea es definir direcciones de transporte en las que los procesos pueden estar a la escucha de solicitudes de conexión. En Internet, estos puntos terminales se denominan puertos, pero usaremos el término genérico de TSAP (Punto de Acceso al Servicio de Transporte). Los puntos terminales análogos de la capa de red se llaman NSAP (Punto de Acceso al Servicio de Red). Las direcciones IP son ejemplos de NSAPs.
  • 5. Establecimiento de una conexión El establecimiento de una conexión parece fácil, pero en realidad es sorprendentemente difícil. A primera vista, parecería que es suficiente con mandar una TPDU (Unidad de Datos del Protocolo de Transporte) con la petición de conexión y esperar a que el otro acepte la conexión. El problema viene cuando la red puede perder, almacenar, o duplicar paquetes. El principal problema es la existencia de duplicados retrasados. Esto puede solucionarse de varias maneras (ninguna es muy satisfactoria). Una es utilizar direcciones de transporte desechables. En este enfoque cada vez que necesitemos una dirección la creamos. Al liberarse la conexión descartamos la dirección y no se vuelve a utilizar. O también asignar una secuencia dentro de los datos transmitidos, pero estos plantean los problemas de que si se pierde la conexión perdemos el orden del identificador y ya no funciona. Pero la solución sería más fácil si los paquetes viejos se eliminaran de la subred cada cierto tiempo de vida. Para ello podemos utilizar las siguientes técnicas: Un diseño de subred Restringido. Colocar un contador de saltos en cada paquete. Marcar el tiempo de cada paquete. Pero en la práctica no vale solo con hacer esto sino que tenemos que garantizar que todas las confirmaciones de los paquetes también se eliminan. Liberación de una conexión La liberación de una conexión es más fácil que su establecimiento. No obstante, hay más escollos de los que uno podría imaginar. Hay dos estilos de terminación de una conexión: liberación asimétrica y liberación simétrica. La liberación asimétrica es la manera en que funciona el mecanismo telefónico: cuando una parte cuelga, se interrumpe la conexión. La liberación simétrica trata la conexión como dos conexiones unidireccionales distintas, y requiere que
  • 6. cada una se libere por separado. La liberación asimétrica es abrupta y puede resultar en la perdida de datos. Por lo que es obvio que se requiere un protocolo de liberación más refinado para evitar la pérdida de datos. Una posibilidad es usar la liberación simétrica, en la que cada dirección se libera independientemente de la otra. Aquí, un host puede continuar recibiendo datos aun tras haber enviado una TPDU de desconexión. La liberación simétrica es ideal cuando un proceso tiene una cantidad fija de datos por enviar y sabe con certidumbre cuándo los ha enviado. En otras situaciones, la determinación de si se ha efectuado o no todo el trabajo y se debe terminarse o no la conexión no es tan obvia. Podríamos pensar en un protocolo en el que el host 1 diga:”Ya termine, ¿Terminaste también?”. Si el host 2 responde “Ya termine también. Adiós”, la conexión puede liberarse con seguridad. Pero no es tan fiable por el problema de que siempre tendremos que esperar la confirmación de los mensajes recibidos y si esta confirmación no llega no libera la conexión y después puede que necesite la confirmación de que llego la confirmación y entraríamos en un bucle del que no podemos salir. Podemos hacer que al host 1 si no le llega la confirmación después de N intentos (es que quiere la desconexión), se libere. Esto produce una conexión semiabierta en la que el host 1 está desconectado pero el host 2 no como no le llega la confirmación no se desconecta nunca. Para solucionar esto creamos una regla por la cual si al host 2 no le llega ninguna TPDU durante cierta cantidad de segundos, se libera automáticamente.
  • 7. CONTROL DE FLUJO Y ALMACENAMIENTO EN BUFFER Ya examinamos la conexión y la desconexión, veamos la manera en que se manejan las conexiones mientras están en uso. Uno de los aspectos clave es el control de flujo. Necesitamos un esquema para evitar que un emisor rápido desborde a un receptor lento. La diferencia principal es que un enrutador por lo regular tiene relativamente pocas líneas, y un host puede tener numerosas conexiones. Esta diferencia hace poco práctico emplear la implementación que se hace en la capa de enlace En esta capa lo que se hace es, si el servicio de red no es confiable, el emisor debe almacenar en un buffer todas las TPDUs enviadas, igual que en la capa enlace de datos. Sin embargo, con un servicio de red confiable son posibles otros arreglos. En particular, si el emisor sabe que el receptor siempre tiene espacio de buffer, no necesita tener copias de las TPDUs que envía. Sin embargo, si el receptor no garantiza que se aceptará cada TPDU que llegue, el emisor tendrá que usar buffers de todas maneras. En el último caso, el emisor no puede confiar en la confirmación de recepción de la capa red porque esto sólo significa que ha llegado la TPDU, no que ha sido aceptada. Los Buffers pueden ser de tres tipos, y usaremos cada uno de ellos cuando más nos convenga. El equilibrio óptimo entre el almacenamiento del buffer en el origen y en el destino depende del tipo de trafico transportado por la conexión.
  • 8. Multiplexión La multiplexión de varias conversaciones en conexiones, circuitos virtuales o enlaces físicos desempeña un papel importante en diferentes capas de la arquitectura de red. En la capa de transporte puede surgir la necesidad de multiplexión por varias razones. Por ejemplo, si en un host sólo se dispone de una dirección de red, todas la conexiones de transporte de esa máquina tendrán que utilizarla. Cuando llega una TPDU, se necesita algún mecanismo para saber a cuál proceso asignarla. Esta situación se conoce como multiplexión hacia arriba. La multiplexión también puede ser útil en la capa transporte para la utilización de circuitos virtuales, que dan más ancho de banda cuando se reasigna a cada circuito una tasa máxima de datos. La solución es abrir múltiples conexiones de red y distribuir el tráfico entre ellas. Esto se denomina multiplexión hacia abajo. RECUPERACIÓN DE CAÍDAS Si los hosts y los enrutadores están sujetos a caídas, la recuperación es fundamental. Si la entidad de transporte está por entero dentro de los hosts, la recuperación de caídas de red y de enrutadores es sencilla. Si la capa de red proporciona servicio de datagramas, las entidades de transporte esperan pérdida de algunas TPDUs todo el tiempo, y saben cómo manejarla. Si la capa de red proporciona servicio orientado a la conexión, entonces la pérdida de un circuito virtual se maneja estableciendo otro nuevo y sondeando la entidad de transporte remota para saber cuáles TPDUs ha recibido y cuáles no.
  • 9. Un problema más complicado es la manera de recuperarse de caídas del host. Al reactivarse, sus tablas están en el estado inicial y no sabe con precisión donde estaba. En un intento por recuperar su estado previo, el servidor podría enviar una TPDU de difusión a todos los demás host, anunciando que se acaba de caer y solicitando a todos sus clientes que le informen el estado de todas la conexiones abiertas.
  • 11. Funciones de la Capa De Trasporte • Esta capa debe proporcionar un transporte de datos confiable y económico desde la máquina origen a la máquina de destino, independientemente de la red o redes físicas en uso. • La capa de transporte es el corazón de la jerarquía de protocolos. • Permite aplicaciones múltiples para comunicarse en la red al mismo tiempo que en un dispositivo sencillo. • Asegura que, si es necesario, la aplicación correcta reciba todos los datos de forma confiable y en orden. • Emplea mecanismos de manejo de errores. • Define los mecanismos para mantener la confiabilidad de las comunicaciones en la red. • Su función es regular el flujo de mensajes, retransmisión de paquetes, inicio y término de sesiones entre nodos. Protocolo TCP El protocolo TCP es el encargado de dividir el mensaje original en segmentos de menor tamaño, más manejables, que serán luego empaquetados en datagramas o paquetes y dirigidos a través del protocolo IP de forma individual, y añade a cada uno de los datagramas información necesaria para su manejo, envío y control de errores en la transmisión.
  • 12. Comunicación con Confiabilidad La diferencia clave entre TCP y UDP es la confiabilidad La confiabilidad de la comunicación TCP se lleva a cabo utilizando sesiones orientadas a la conexión. Antes de que un host que utiliza TCP envíe datos a otro host, la capa de Transporte inicia un proceso para crear una conexión con el destino. Esta conexión permite el rastreo de una sesión o stream de comunicación entre los hosts. Este proceso asegura que cada host tenga conocimiento de la comunicación y se prepare. Una conversación TCP completa requiere el establecimiento de una sesión entre los hosts en ambas direcciones. Luego de establecida la sesión, el destino envía acuses de recibo al origen por los segmentos que recibe. Estos acuses de recibo forman la base de la confiabilidad dentro de la sesión TCP. Cuando el origen recibe un acuse de recibo, reconoce que los datos se han entregado con éxito y puede dejar de rastrearlos. Si el origen no recibe el acuse de recibo dentro de un tiempo predeterminado, retransmite esos datos al destino. Parte de la carga adicional que genera el uso de TCP es el tráfico de red generado por los acuses de recibo y las retransmisiones. El establecimiento de las sesiones genera cargas en forma de segmentos adicionales intercambiados. También existen cargas adicionales en los hosts individuales, generadas por la necesidad de mantener un seguimiento de los segmentos que esperan acuse de recibo y por el proceso de retransmisión.
  • 13. Esta confiabilidad se logra contando con campos en el segmento TCP, cada uno con una función específica. Procesos del servidor TCP Como se explicó en el capítulo anterior, los procesos de aplicación se ejecutan en servidores. Estos procesos esperan hasta que un cliente inicie comunicación con una solicitud de información o de otros servicios. Cada proceso de aplicación que se ejecuta en el servidor es configurado por el administrador del sistema para utilizar un número de puerto, de forma predeterminada o manual. Un servidor individual no puede tener dos servicios asignados al mismo número de puerto dentro de los mismos servicios de la capa de Transporte.
  • 14. Un host que ejecuta una aplicación de servidor Web y una de transferencia de archivos no puede configurar ambas para utilizar el mismo puerto (por ejemplo, el puerto TCP 8.080). Cuando una aplicación de servidor activa se asigna a un puerto específico, este puerto se considera "abierto" para el servidor. Esto significa que la capa de Transporte acepta y procesa segmentos direccionados a ese puerto. Toda solicitud entrante de un cliente direccionada al socket correcto es aceptada y los datos se envían a la aplicación del servidor. Pueden existir varios puertos simultáneos abiertos en un servidor, uno para cada aplicación de servidor activa. Es común que un servidor provea más de un servicio, como un servidor Web y un servidor FTP, al mismo tiempo.
  • 15. Una manera de mejorar la seguridad en un servidor es restringir el acceso al servidor a sólo aquellos puertos asociados con los servicios y aplicaciones accesibles a solicitantes autorizados. La figura muestra la asignación típica de puertos de origen y destino en operaciones de cliente o servidor TCP.
  • 16. Establecimiento y finalización de la conexión TCP Cuando dos hosts se comunican utilizando TCP, se establece una conexión antes de que puedan intercambiarse los datos. Luego de que se completa la comunicación, se cierran las sesiones y la conexión finaliza. Los mecanismos de conexión y de sesión habilitan la función de confiabilidad de TCP. Ver la figura para observar los pasos para establecer y finalizar una conexión TCP. El host rastrea cada segmento de datos dentro de una sesión e intercambia información sobre los datos recibidos por cada host a través de la información del encabezado TCP. Cada conexión representa dos streams de comunicación de una vía o sesiones. Para establecer la conexión los hosts realizan un intercambio de señales de tres vías. Los bits de control en el encabezado TCP indican el progreso y estado de la conexión. Enlace de tres vías: • Establece que el dispositivo de destino esté presente en la red. • Verifica que el dispositivo de destino tenga un servicio activo y esté aceptando las peticiones en el número de puerto de destino que el cliente que lo inicia intente usar para la sesión. • Informa al dispositivo de destino que el cliente de origen intenta establecer una sesión de comunicación en ese número de puerto.
  • 17. En conexiones TCP, el host que brinde el servicio como cliente inicia la sesión al servidor. Los tres pasos para el establecimiento de una conexión TCP son: 1. El cliente que inicia la conexión envía un segmento que contiene un valor de secuencia inicial, que actúa como solicitud para el servidor para comenzar una sesión de comunicación. 2. El servidor responde con un segmento que contiene un valor de reconocimiento igual al valor de secuencia recibido más 1, además de su propio valor de secuencia de sincronización. El valor es uno mayor que el número de secuencia porque el ACK es siempre el próximo Byte u Octeto esperado. Este valor de reconocimiento permite al cliente unir la respuesta al segmento original que fue enviado al servidor. 3. El cliente que inicia la conexión responde con un valor de reconocimiento igual al valor de secuencia que recibió más uno. Esto completa el proceso de establecimiento de la conexión. Para entender el proceso de enlace de tres vías, es importante observar los distintos valores que intercambian los dos hosts. Dentro del encabezado del segmento TCP, existen seis campos de 1 bit que contienen información de control utilizada para gestionar los procesos de TCP. Estos campos son los siguientes: URG: Urgente campo de señalizador significativo. ACK: Campo significativo de acuse de recibo. PSH: Función de empuje. RST: Reconfiguración de la conexión.
  • 18. SYN: Sincronizar números de secuencia. FIN: No hay más datos desde el emisor. A estos campos se los denomina señaladores porque el valor de uno de estos campos es sólo de 1 bit, entonces tiene sólo dos valores: 1 ó 0. Si el valor del bit se establece en 1, indica la información de control que contiene el segmento. Si se utiliza un proceso de cuatro pasos, los señalizadores se intercambian para finalizar la conexión TCP
  • 19. Terminación de la sesión TCP Para cerrar la conexión se debe establecer el señalizador de control FIN (Finalizar) en el encabezado del segmento. Para finalizar todas las sesiones TCP de una vía, se utiliza un enlace de dos vías, que consta de un segmento FIN y un segmento ACK. Por lo tanto, para terminar una conversación simple admitida por TCP, se requieren cuatro intercambios para finalizar ambas sesiones. Nota: En esta explicación se usan los términos cliente y servidor como referencia por simplicidad Pero la finalización del proceso puede ser iniciada por cualquiera de los dos hosts que completen la sesión: 1. Cuando el cliente no tiene más datos para enviar al stream, envía un segmento con el señalizador FIN establecido. 2. El servidor envía un ACK para acusar recibo de Fin y terminar la sesión del cliente al servidor. 3. El servidor envía un FIN al cliente para finalizar la sesión del servidor al cliente. 4. El cliente responde con un ACK para dar acuse de recibo de FIN desde el servidor. Cuando la finalización de sesión del cliente no tiene más datos para transferir, establece el señalizador FIN en el encabezado de un segmento. Luego, el servidor finaliza la conexión y envía un segmento normal que contiene datos con el señalizador ACK establecido utilizando el número de acuse de recibo, confirmando así que se han recibido todos los bytes de datos.
  • 20. Cuando se produce el acuse de recibo de todos los segmentos, se cierra la sesión. La sesión en la otra dirección se cierra mediante el mismo proceso. El receptor indica que no existen más datos para enviar estableciendo el señalizador FIN en el encabezado del segmento enviado al origen. Un acuse de recibo de retorno confirma que todos los bytes de datos han sido recibidos y, por lo tanto, se ha cerrado la sesión. Como se muestra en la figura, los señalizadores de control FIN y ACK se establecen en el encabezado del segmento, cerrando por lo tanto la sesión HTTP. También es posible terminar la conexión mediante un enlace de tres vías. Cuando el cliente no posee más datos para enviar, envía un señalizador FIN al servidor. Si el servidor tampoco tiene más datos para enviar, puede responder con los señalizadores FIN y ACK, combinando dos pasos en uno. El cliente responde con un ACK. Actividad con Packet Tracer En esta actividad, estudiará el protocolo de enlace de tres vías de TCP para el establecimiento de sesión y el proceso TCP para la terminación de la sesión. Muchos protocolos de aplicación utilizan TCP y visualizar el establecimiento de la sesión y los procesos de terminación con el Packet Tracer profundizará sus conocimientos.
  • 21. Administración de sesiones TCP Cuando los servicios envían datos utilizando TCP, los segmentos pueden llegar a destinos desordenados. Para que el receptor comprenda el mensaje original, los datos en estos segmentos se reensamblan en el orden original. Para lograr esto, se asignan números de secuencia en el encabezado de cada paquete. Durante la configuración de la sesión, se establece un número de secuencia inicial (ISN). Este número de secuencia inicial representa el valor de inicio para los bytes de esta sesión que se transmitirán a la aplicación receptora. A medida que se transmiten los datos durante la sesión, el número de secuencia se incrementa en el número de bytes que se han transmitido. Este rastreo de bytes de datos permite que cada segmento se identifique y se envíe acuse de recibo de manera exclusiva. Se pueden identificar segmentos perdidos. Los números de secuencia de segmento permiten la confiabilidad indicando cómo reensamblar y reordenar los segmentos recibidos, como se muestra en la figura. El proceso TCP receptor coloca los datos del segmento en un búfer de recepción. Los segmentos se colocan en el orden de número de secuencia adecuado y se pasa a la capa de Aplicación cuando son reensamblados. Todos los segmentos que llegan con números de secuencia no contiguos se mantienen para su procesamiento posterior. Luego, se procesan los segmentos cuando llegan con los bytes perdidos.
  • 22. Acuse de recibo de TCP con uso de ventanas Una de las funciones de TCP es asegurar que cada segmento llegue a su destino. Los servicios TCP en el host de destino envían a la aplicación de origen un acuse de recibo de los datos recibidos. El número de secuencia y el número de acuse de recibo del encabezado del segmento se utilizan para confirmar la recepción de los bytes de datos contenidos en los segmentos. El número de secuencia es el número relativo de bytes que ha sido transmitido en esta sesión más 1 (que es el número del primer byte de datos en el segmento actual). TCP utiliza el número de reconocimiento en segmentos que se vuelven a enviar al origen para indicar el próximo byte de esta sesión que espera el receptor. Esto se llama acuse de recibo de expectativa.
  • 23. Se le informa al origen que el destino ha recibido todos los bytes de este stream de datos, pero sin incluir, el byte especificado por el número de acuse de recibo. Se espera que el host emisor envíe un segmento que utiliza un número de secuencia igual al número de acuse de recibo. Recuerde que cada conexión se representa en realidad por dos sesiones de una vía. Los números de secuencia y de acuse de recibo se intercambian en ambas direcciones. En el ejemplo de la figura, el host en la izquierda envía datos al host de la derecha. Envía un segmento que contiene 10 bytes de datos para esta sesión y un número de secuencia igual a 1 en el encabezado. El host receptor de la derecha recibe el segmento en la Capa 4 y determina que el número de secuencia es 1 y que posee 10 bytes de datos. Luego el host envía un segmento de vuelta al host de la izquierda para acusar recibo de estos datos. En este segmento, el host establece el número de acuse de recibo en 11 para indicar que el próximo byte de datos que espera recibir en esta sesión es el byte número 11. Cuando el host emisor de la izquierda recibe este acuse de recibo, puede enviar el próximo segmento que contiene datos para esta sesión a partir del byte 11. Observando este ejemplo, si el host emisor tuviera que esperar el acuse de recibo por la recepción de cada uno de los 10 bytes, la red estaría demasiado sobrecargada. Para reducir la sobrecarga de estos acuses de recibo, los segmentos de datos múltiples pueden enviarse previamente y ser reconocidos con un mensaje TCP simple en la dirección opuesta. Este reconocimiento contiene un número
  • 24. de acuse de recibo en base al número total de bytes recibidos en la sesión. Por ejemplo, si se comienza con un número de secuencia 2000, si se reciben 10 segmentos de 1000 bytes cada uno, se devolverá al origen un número de reconocimiento igual a 12001. La cantidad de datos que un origen puede transmitir antes de que un acuse de recibo deba ser recibido se denomina tamaño de la ventana. El tamaño de la ventana es un campo en el encabezado TCP que permite la administración de datos perdidos y el control del flujo.
  • 25. Retransmisión de TCP Manejo de la pérdida de segmentos Por óptimo que sea el diseño de una red, siempre se producirán pérdidas ocasionales de datos. Por lo tanto, TCP cuenta con métodos para gestionar dichas pérdidas de segmentos. Entre los mismos existe un mecanismo para retransmitir segmentos con datos no reconocidos. Un servicio de host de destino que utiliza TCP, por lo general sólo reconoce datos para secuencias de bytes contiguas. Si uno o más segmentos se pierden, sólo se acusa recibo de los datos de los segmentos que completan el stream. Por ejemplo, si se reciben los segmentos con números de secuencia de 1500 a 3000 y de 3400 a 3500, el número de acuse de recibo será 3001. Esto sucede porque existen segmentos con números de secuencia de 3001 a 3399 que no se recibieron. Cuando TCP en el host de origen no recibe un acuse de recibo pasado un tiempo predeterminado, volverá al último número de acuse de recibo que recibió y retransmitirá los datos a partir de éste. El proceso de retransmisión no es especificado por RFC, sino que depende de la implementación de TCP en particular. Para una implementación de TCP típica, un host puede transmitir un segmento, colocar una copia del segmento en una cola de retransmisión e iniciar un temporizador. Cuando se recibe el acuse de recibo de los datos, se elimina el segmento de la cola. Si no se recibe el acuse de recibo antes de que el temporizador venza, el segmento es retransmitido.
  • 26. Los hosts actuales también suelen emplear una función opcional llamada Acuses de recibo selectivos. Si ambos hosts admiten el Acuse de recibo selectivo, es posible que el destino reconozca los bytes de segmentos discontinuos y el host sólo necesitará retransmitir los datos perdidos. Control de congestión de TCP: Cómo minimizar la pérdida de segmentos Control del flujo TCP si provee mecanismos para el control del flujo. El control del flujo contribuye con la confiabilidad de la transmisión TCP ajustando la tasa efectiva de flujo de datos entre los dos servicios de la sesión. Cuando el origen advierte que se recibió la cantidad de datos especificados en los segmentos, puede continuar enviando más datos para esta sesión. El campo Tamaño de la ventana en el encabezado TCP especifica la cantidad de datos que puede transmitirse antes de que se reciba el acuse de recibo. El tamaño de la ventana inicial se determina durante el comienzo de la sesión a través del enlace de tres vías. El mecanismo de retroalimentación de TCP ajusta la tasa de transmisión de datos efectiva al flujo máximo que la red y el dispositivo de destino pueden soportar sin sufrir pérdidas. TCP intenta gestionar la tasa de transmisión de manera que todos los datos se reciban y se reduzcan las retransmisiones. Ver la figura para obtener una representación simplificada del tamaño de la ventana y los acuses de recibo. En este ejemplo, el tamaño de la ventana inicial para una sesión TCP representada se establece en 3000 bytes. Cuando el emisor transmite 3000 bytes,
  • 27. espera por un acuse de recibo de los mismos antes de transmitir más segmentos para esta sesión. Una vez que el emisor ha recibido este acuse de recibo del receptor, ya puede transmitir 3000 bytes adicionales. Durante la demora en la recepción del acuse de recibo, el emisor no enviará ningún segmento adicional para esta sesión. En los períodos en los que la red está congestionada o los recursos del host receptor están exigidos, la demora puede aumentar. A medida que aumenta esta demora, disminuye la tasa de transmisión efectiva de los datos para esta sesión. La disminución de la tasa de datos ayuda a reducir la contención de recursos.
  • 28. Reducción del tamaño de la ventana Otra forma de controlar el flujo de datos es utilizar tamaños dinámicos de ventana. Cuando los recursos de la red son limitados, TCP puede reducir el tamaño de la ventana para lograr que los segmentos recibidos sean reconocidos con mayor frecuencia. Esto disminuye de manera efectiva la tasa de transmisión, ya que el origen espera que los datos sean recibidos con más frecuencia. El host receptor TCP envía el valor del tamaño de la ventana al TCP emisor para indicar el número de bytes que está preparado para recibir como parte de la sesión. Si el destino necesita disminuir la tasa de comunicación debido a limitaciones de memoria del búfer, puede enviar un valor de tamaño de la ventana menor al origen como parte de un acuse de recibo. Como se muestra en la figura, si un host de recepción sufre una congestión, puede responder al host emisor con un segmento con el tamaño de la ventana reducido. En este gráfico, se produjo la pérdida de uno de los segmentos. El receptor cambió el campo ventana en el encabezado de los mensajes devueltos en esta conversación de 3000 a 1500. Esto hizo que el emisor redujera el tamaño de la ventana a 1500. Después de períodos de transmisión sin pérdidas de datos o recursos limitados, el receptor comenzará a aumentar el tamaño de la ventana. Esto reduce la sobrecarga de la red, ya que se requiere enviar menos acuses de recibo. El tamaño de la ventana continuará aumentando hasta que haya pérdida de datos, lo que producirá una disminución del tamaño de la ventana. Estas disminuciones y aumentos dinámicos del tamaño de la ventana representan un proceso continuo en TCP, que determina el tamaño de la ventana óptimo para cada sesión TCP. En redes
  • 29. altamente eficientes, los tamaños de la ventana pueden ser muy grandes porque no se pierden datos. En redes donde se está estresando la infraestructura subyacente, el tamaño de la ventana probablemente permanecerá pequeño. Enlaces Detalles de las varias características de administración de la congestión de TCP se pueden encontrar en RFC 2581.
  • 30. Protocolo UDP El protocolo TCP tiene la robustez, la confiabilidad y las funcionalidades propias de un protocolo de transporte orientado a conexión, pero a veces resulta demasiado complejo. Por ejemplo, cualquier transmisión de información TCP requiere como mínimo el intercambio de seis mensajes para establecer la comunicación y terminarla; además mientras una conexión existe ocupa una serie de recursos en el host. Para casos en los que no es necesario tanto control de los datos enviados la Capa de Transporte implementa también el Protocolo de Datagrama de Usuario (UDP), protocolo no confiable y no orientado a conexión para la entrega de mensajes discretos. En este caso los paquetes enviados mediante el protocolo IP reciben el nombre específico de datagramas, y estos se envían y ya está; no se realiza una conexión definida entre los host ni un control de los paquetes enviados y recibidos. Los datagramas se rutean independientemente, por lo que deben llevar las dirección completa de destino. UDP es un protocolo estándar con número 6 de STD. Este protocolo se describe en el RFC 768 - Protocolo de Datagrama de Usuario. Es simple, eficiente e ideal para aplicaciones como el TFTP y el DNS. Una dirección IP sirve para dirigir el datagrama hacia una máquina en particular, y el número de puerto de destino en la cabecera UDP se utiliza para dirigir el datagrama UDP a un proceso específico en dicha máquina. La cabecera UDP también contiene un número de puerto origen que permite al proceso recibido conocer cómo responder al datagrama. Es una alternativa al TCP en aquellos casos en los que no sea necesaria tanta complejidad en el envío, por lo que se usa cuando
  • 31. una entrega rápida es más importante que una entrega garantizada, o en los casos en que se desea enviar tan poca información que cabe en un único datagrama. Así, una de sus utilidades más comunes es el envío de mensajes entre aplicaciones de dos host. Es por ello un protocolo del tipo best-effort (máximo esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la aplicación, pero no puede garantizar que la aplicación los reciba. Tampoco utiliza mecanismos de detección de errores. Cuando se detecta un error en un datagrama, en lugar de entregarlo a la aplicación destino, se descarta. Cuando una aplicación envía datos a través de UDP, éstos llegan al otro extremo como una unidad. Por ejemplo, si una aplicación escribe 5 veces en el puerto UDP, la aplicación al otro extremo hará
  • 32. 5 lecturas del puerto UDP. Además, el tamaño de cada escritura será igual que el tamaño de las lecturas. AL igual que TCP, UDP usa al protocolo IP para transportar sus segmentos. El formato del segmento UDP es el siguiente: segmento UDP 0 10 20 30 0123456789012345678901234567890 1 Puerto UDP origen Puerto UDP destino Longitud del datagrama Checksum UDP Datos ... Cuyos campos principales son: • Puerto UDP de origen: campo opcional de 16 bits que especifica el puerto del host origen remitente del datagrama. • Puerto UDP de destino: campo obligatorio de 16 bits que especifica el puerto del host destino al que se envía el datagrama. • Longitud del datagrama: campo obligatorio de 16 bits que especifica la longitud en bytes del datagrama, incluyendo la cabecera. La longitud mínima es de 8 bytes. En realidad es la longitud del datagrama IP menos el tamaño de la cabecera IP. Como la longitud máxima del datagrama IP es de 65.535 bytes y la cabecera estándar de IP es de 20 bytes, la longitud máxima de un datagrama UDP es de 65.515 bytes. • Checksum UDP: campo de 16 bits opcional que almacena una suma de comprobación de errores del datagrama, que se calcula a partir de una pseudo-cabecera.
  • 33. Si el checksum es cero, quiere decir que no se calculó el checksum en el origen y que puede ser ignorado. Esto significa que el módulo UDP del computador origen puede o no generar checksums. Si Ethernet es el único tipo de red entre los dos módulos UDP que se comunican, entonces puede que no sea necesario calcular el checksum. Sin embargo, es recomendable habilitar la generación de checksums porque quizás en el futuro un cambio en la tabla de encaminamiento puede enviar los datos a través de un medio menos fiable que Ethernet. Si el checksum es válido (o cero), se examina el número de puerto destino y si hay una aplicación escuchando en ese puerto, un mensaje de aplicación queda en la cola de lectura de esa aplicación. Si no hay ninguna aplicación en ese puerto, el datagrama UDP se descarta. Si los datagramas UDP llegan más rápido de lo que la aplicación puede leerlos, la cola comenzará a llenarse; si se sobrepasa un valor máximo, los datagramas UDP siguientes serán descartados por UDP. UDP seguirá descartando datagramas hasta que haya espacio en la cola. • Datos: campo obligatorio que contiene los datos que se envían las aplicaciones con el datagrama. Algunos ejemplos de situaciones en las que es más conveniente un servicio no orientado a conexión, en los que es más útil un protocolo del tipo UDP, son: • Aplicaciones tiempo real como audio o video, donde no se puede tolerar el retardo producido por los ACK. • Consultas a servidores en que se requiere el envío de uno o dos mensajes únicamente como es el caso del DNS.
  • 34. Situaciones en las que se necesita conectar con un ordenador de la propia red, usando para ello el nombre del sistema. Para ello hay que conectar primero con el servidor de red apropiado para que transforme dicha dirección de red en una dirección IP válida, siendo en este caso más apropiado el protocolo UDP. • Cuando queremos transmitir información en modo multicast (a muchos destinos) o en modo broadcast (a todos los destinos) pues no tiene sentido esperar la confirmación de todos los destinos para continuar con la transmisión. También es importante tener en cuenta que si en una transmisión de este tipo los destinos enviarán confirmación, fácilmente el emisor se vería colapsado, pues por cada paquete que envía recibiría tantas confirmaciones como destinos hayan recibido el paquete. Entre los protocolos superiores que usan UDP se incluyen TFTP (Trivial File Transfer Protocol), DNS (Domain Name Server), SNMP (Simple Network Management Protocol), NTP (Network Time Protocol), NFS (Network File System), etc.