redes

1. CAPA DE TRANSPORTE

2. El nivel de transporte o capa de transporte es el cuarto nivel del modelo OSI, y
está 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.
Es la base de toda la jerarquía de protocolo. 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 las de redes físicas en uno.
Sin la capa transporte, el concepto total de los protocolos en capas tendría poco
sentido.

3. SERVICIOS

4. Servicios proporcionados a las capas superiores
La meta final de la capa de transporte es proporcionar un servicio eficiente, confiable y económico a sus
usuarios, que normalmente son procesos de la capa de aplicación. Para lograr este objetivo, la capa de
transporte utiliza los servicios proporcionados por la capa de red. El hardware o software de la capa de
transporte que se encarga del transporte se llama entidad de transporte, la cual puede estar en
el núcleo del sistema operativo, en un proceso independiente, en un paquete de biblioteca o en la tarjeta
de red.
Hay dos tipos de servicio en la capa de 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..

5. 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 ese es precisamente el propósito de la capa
de transporte: ofrecer un servicio confiable en una red no confiable.

6. Otra diferencia entre la capa de 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 bloquea 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.

7. Sockets de Berkeley
Este es otro grupo de primitivas de transporte, las
primitivas usadas en UNIX para el TCP. En general son
muy parecidas a las anteriores pero ofrecen más
características y flexibilidad.
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.

8. Direccionamiento
Cuando un proceso desea establecer una conexión con un computador de aplicación remoto, debe
especificar a cuál se conectará (¿a quién le llegará 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 conexiones. 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.

9. 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 el problema de que si se pierde la conexión perdemos el orden del identificador y ya no
funciona. 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.

10. 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 pérdida 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 llegó 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.

11. Control de Flujo y almacenamiento en buffer
Respecto de la manera en que se manejan las conexiones mientras están en uso, uno de los aspectos clave
es el control de flujo. Se necesita 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 que 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 tráfico
transportado por la conexión.

12. 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 las 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.

13. 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 cuales TPDUs ha recibido y cuales 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.

14. PROTOCOLOS DE TRANSPORTE DE INTERNET

15. El protocolo de datagramas de usuario (en inglés: User Datagram Protocol o UDP) es un protocolo
del nivel de transporte (encapsulado entre la capa de red y la capa de aplicación del modelo OSI) basado
en la transmisión sin conexión de datagramas y representa una alternativa al protocolo TCP (Transmisión
Control Protocol). Ese protocolo permite el envío de datagramas de forma rápida en redes IP sin establecer
previamente una conexión, dado que el propio datagrama incorpora suficiente información sobre el
destinatario en su cabecera1. Tampoco tiene confirmación ni control de flujo, por lo que los paquetes pueden
adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmación de
entrega o recepción. Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás protocolos en
los que el intercambio de paquetes de la conexión/desconexión son mayores, o no son rentables con
respecto a la información transmitida, así como para la transmisión de audio y vídeo en tiempo real, donde
no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos.

16. User Datagram Protocol (UDP) es un protocolo mínimo de nivel de transporte orientado a mensajes
documentado en el RFC 768 de la IETF.
En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre la capa de red y
la capa de aplicación. UDP no otorga garantías para la entrega de sus mensajes (por lo que
realmente no se debería encontrar en la capa 4) y el origen UDP no retiene estados de los mensajes
UDP que han sido enviados a la red. UDP solo añade multiplexado de aplicación y suma de
verificación de la cabecera y la carga útil. Cualquier tipo de garantías para la transmisión de la
información deben ser implementadas en capas superiores.

17. La cabecera UDP consta de 4 campos de los cuales 2 son opcionales (con fondo rojo en la tabla). Los
campos de los puertos origen y destino son campos de 16 bits que identifican el proceso de emisión y
recepción. Ya que UDP carece de un servidor de estado y el origen UDP no solicita respuestas, el puerto
origen es opcional. En caso de no ser utilizado, el puerto origen debe ser puesto a cero. A los campos del
puerto destino le sigue un campo obligatorio que indica el tamaño en bytes del datagrama UDP incluidos
los datos. El valor mínimo es de 8 bytes. El campo de la cabecera restante es una suma de comprobación
de 16 bits que abarca una pseudo-cabecera IP (con las IP origen y destino, el protocolo y la longitud del
paquete UDP), la cabecera UDP, los datos y 0's hasta completar un múltiplo de 16. El checksum también
es opcional en IPv4, aunque generalmente se utiliza en la práctica (en IPv6 su uso es obligatorio). A
continuación se muestra los campos para el cálculo del checksum en IPv4, marcada en rojo la pseudo-
cabecera IP.
El protocolo UDP se utiliza por ejemplo cuando se necesita transmitir voz o vídeo y resulta más importante
transmitir con velocidad que garantizar el hecho de que lleguen absolutamente todos los bytes.

18. Principales Características
Las características principales de este protocolo son:
1.Trabaja sin conexión, es decir, que no emplea ninguna sincronización entre el origen y el destino.
2.Trabaja con paquetes o datagramas enteros, no con bytes individuales como TCP. Una aplicación que
emplea el protocolo UDP intercambia información en forma de bloques de bytes, de forma que por cada
bloque de bytes enviado de la capa de aplicación a la capa de transporte, se envía un paquete UDP.
3.No es fiable. No emplea control del flujo ni ordena los paquetes.
4.Su gran ventaja es que provoca poca carga adicional en la red ya que es sencillo y emplea cabeceras
muy simples.

19. Protocolo de control de transmisión
Protocolo de control de transmisión (en inglés Transmission Control Protocol o TCP) es uno de
los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint
Cerf y Robert Kahn.
El protocolo de control de transmisión (TCP) es, al igual que el protocolo UDP como el SCTP, un
protocolo de Internet que está ubicado en la capa de transporte del modelo OSI. El objetivo del
protocolo TCP es crear conexiones dentro de una red de datos compuesta por redes
de computadoras para intercambiar datos. Además, en cuanto a su funcionamiento, garantiza que los
datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron2.
También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma
máquina, a través del concepto de puerto.
TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio
de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP, SMTP, SSH y FTP.

20. Objetivos de TCP
Con el uso de protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al
"acuse de recibo" -ACK- del protocolo TCP) independientemente de las capas inferiores. Esto
significa que los routers (que funcionan en la capa de red) solo tienen que enviar los datos en
forma de segmentos, sin preocuparse con el monitoreo de datos porque esta función la cumple la
capa de transporte (o más específicamente el protocolo TCP).

21. Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de red (IP) y
la aplicación. Muchas veces las aplicaciones necesitan que la comunicación a través de la
red sea confiable. Para ello se implementa el protocolo TCP que asegura que los datos
que emite el cliente sean recibidos por el servidor sin errores y en el mismo orden que
fueron emitidos, a pesar de trabajar con los servicios de la capa IP, la cual no es
confiable. Es un protocolo orientado a la conexión, ya que el cliente y el servidor deben
anunciarse y aceptar la conexión antes de comenzar a transmitir los datos a ese usuario
que debe recibirlos.

22. Características del TCP
•Permite colocar los segmentos nuevamente en orden cuando vienen del protocolo IP.
•Permite el monitoreo del flujo de los datos y así evita la saturación de la red.
•Permite que los datos se formen en segmentos de longitud variada para "entregarlos" al
protocolo IP.
•Permite multiplexar los datos, es decir, que la información que viene de diferentes fuentes
(por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente.
•Por último, permite comenzar y finalizar la comunicación amablemente.

23. https://www.youtube.com/watch?v=pycUsfS2SmM