UNIVERSIDAD INDOAMERICA

Semestre 7mo Sistemas

Alumno Carlos Suqui

COMUNICACIONES

Modalidad Semi presencial

UN PROTOCOLO DE TRANSPORTE SENCILLO

Es el corazón de toda la jerarquía de protocolos. 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 de destino, independiente de la red o redes físicas en uso. Sin la capa de transporte, el concepto total de los protocolos en capas tendría poco sentido.

Las primitivas de servicio de ejemplo

primitivas de transporteCONNECT es fácil: sencillamente tenemos un procedimiento de biblioteca connect que puede llamarse con los parámetros adecuados necesarios para establecer una conexión. Los parámetros son los TSAPs locales y remotos. Durante la llamada, el invocador se bloquea (es decir, se suspende) mientras la entidad de transporte intenta establecer la conexión. Si ésta tiene éxito, se desbloquea el invocador y puede comenzar la transmisión de datos. Llamadas entrantes, llama a listen, especificandoun TSAP en particular en el que quiere escuchar. El proceso entonces se bloquea hasta que algún proceso remoto intenta establecer una conexión con su TSAP. Ejemplo, es mantener la solicitud de conexión del lado receptor durante cierto intervalo de tiempo. Si un proceso de ese host llama a listen antes de que expire el temporizador, se establece la conexión; de otro modo se rechaza y se desbloquea al invocador, devolviéndole un error. Para liberar una conexión, usaremos un procedimiento disconnect. Cuando ambos lados se han desconectado, se libera la conexión. En otras palabras, estamos usando un modelo de deesconexión simétrico.

cinco primitivas: CONNECT,LISTEN, DISCONNECT, SEND y RECEIVE. connum = LISTEN(local) connum = CONNECT(local, remote) status = SEND(connum, buffer, bytes) status = RECEIVE(connum, buffer, bytes) status = DISCONNECT(connum)   La primitiva SEND transmite el contenido del búfer como mensaje por la conexión

de transporte indicada, posiblemente en varias unidades si es demasiado grande. Los errores posibles, devueltos en status, son falta de conexión, dirección de búfer ilegal y cuenta negativa.

La primitiva RECEIVE indica el deseo del invocador de aceptar datos. El tamaño del mensaje de entrada se pone en bytes. Si el proceso remoto ha liberado la conexión o la dirección de búfer es ilegal (por ejemplo, fuera del programa del usuario), status se establece a un código de error que indica la naturaleza del problema.

La primitiva DISCONNECT termina una conexión de transporte; el parámetro connum indica cuál. Los errores posibles son que connum pertenezca a otro proceso, o que connum no sea un identificador de conexión válido. El código de error, o 0 si todo funcionó bien, se devuelve en status.

La entidad de transporte de ejemplo La interfaz con la capa de red se establece mediante los procedimientos to_net y from_net (no se muestran). Cada uno tiene seis parámetros. Primero viene el identificador de conexión, que se relaciona uno a uno con los circuitos virtuales de la red. A continuación vienen los bits Q y M que, al estar establecidos en 1, indican “mensaje de control” y “continúan más datos de este mensaje en el siguiente paquete”, respectivamente. 

Cada conexión está siempre en uno de siete estados, a saber: 

Codificado

El ejemplo como máquina de estados finitos 

Figura 6-21. El protocolo de ejemplo como máquina de estados finitos. Cada entrada tiene un predicado opcional, una acción opcional y el estado nuevo. La tilde indica que no se realizó ninguna acción importante. Una barra sobre un predicado indica la negación del predicado. Las entradas en blanco corresponden a eventos imposibles o inválidos.

Las acciones A1 a A12 son las acciones principales, como el envío de paquetes y el inicio de temporizadores. No se listan todas las acciones menores, como la inicialización de los campos de un registro de conexión. Si una acción comprende despertar un proceso dormido, las acciones que siguen a su despertar también cuentan.

LOS PROTOCOLOS DE TRANSPORTE DE INTERNET: UDP Internet tiene dos protocolos principales en la capa de transporte, uno orientado y otro no orientado a la conexión. En las siguientes secciones analizaremos los dos. El protocolo no orientado a la conexión es UDP. El protocolo orientado a la conexión es TCP. Empezaremos con UDP porque es básicamente IP con un encabezado corto.

 

El conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a la conexión, UDP (Protocolo de Datagramas de Usuario). Este protocolo proporciona una forma para que las aplicaciones envíen datagramas IP encapsulados sin tener que establecer una conexión. UDP se describe en el RFC 768. UDP transmite segmentos que consisten en un encabezado de 8 bytes seguido por la carga útil.

CAPA DE TRANSPORTE

Llamada a procedimiento remoto En cierto sentido, enviar un mensaje a un host remoto y obtener una respuesta es muy parecido a hacer una llamada a función en un lenguaje de programación. En ambos casos, usted inicia con uno o más parámetros y obtiene un resultado. En la figura 6-24 se muestran los pasos reales para realizar una RPC. El paso 1 consiste en que el cliente llame al stub del cliente. Ésta es una llamada a procedimiento local, y los parámetros se colocan en la pila de la forma tradicional.  El paso 2 consiste en que el stub del cliente empaca los parámetros en un mensaje y realiza una llamada de sistema para enviar dicho mensaje. El empaquetamiento de los parámetros se conoce como marshaling.

El paso 3 consiste en que el kernel envía el mensaje desde la máquina cliente a la máquina servidor.  El paso 4 consiste en que el kernel pasa el paquete entrante al stub del servidor.  Por último, el paso 5 consiste en que el stub del servidor llame al procedimiento servidor con parámetros sin marshaling. La respuesta sigue la misma ruta en la dirección opuesta.

El protocolo de transporte en tiempo real El RPC cliente-servidor es un área en la que se utiliza ampliamente UDP. Otra son las aplicaciones multimedia en tiempo real. En particular, conforme el radio en Internet, la telefonía en Internet, la música bajo demanda, la videoconferencia, el vídeo bajo demanda y otras aplicaciones multimedia se volvían más comunes, las personas que descubrieron cada una de esas aplicaciones estaba reinventando más o menos el mismo protocolo de transporte de tiempo-real. RTP (Protocolo de Transporte en Tiempo Real) La aplicación multimedia consiste en múltiples flujos de audio, vídeo, texto, entre otros. Éstos se colocan en la biblioteca RTP, la cual está en el espacio de usuario junto con la aplicación. En la figura 6-25(a) se muestra la pila de protocolos para esta situación, y en la 6-25(b) se muestra el anidamiento de paquetes.

En la figura 6-26 se ilustra el encabezado RTP. Consiste de tres palabras de 32 bits y de algunas extensiones. La primera palabra contiene el campo Versión, que es la 2. Esperemos que esta versión esté muy cerca de la final debido a que sólo quedó pendiente un punto del código (aunque se puede definir como 3 dando a entender que la versión real estaba en una palabra de extensión).

El bit P indica que el paquete se ha rellenado a un múltiplo de 4 bytes. El último byte de relleno indica cuántos bytes se agregaron. El bit X indica que hay un encabezado de extensión. El formato y el significado de este encabezado no se definen. Lo único que se define es que la primera palabra de la extensión proporciona la longitud. Ésta es una puerta de escape para cualquier requerimiento imprevisto.El campo CC indica cuántos orígenes de contribución están presentes, de 0 a 15 (vea más adelante). El bit M es un bit marcador específico de la aplicación. Puede utilizarse para marcar el inicio de un cuadro de vídeo, el inicio de una palabra en un canal de audio, o algo más que la aplicación entienda. El campo Tipo de carga útil indica cuál algoritmo de codificación se ha utilizado (por ejemplo, audio de 8 bits sin compresión, MP3, etcétera). Puesto que cada paquete lleva este campo, la codificación puede cambiar durante la transmisión. El Número de secuencia es simplemente un contador que se incrementa en cada paquete RTP enviado. Se utiliza para detectar paquetes perdidos.

LOS PROTOCOLOS DE TRANSPORTE DE INTERNET: TCP

TCP (Protocolo de Control de Transmisión) se diseño específicamente para proporcionarun flujo de bytes confiable de extremo a extremo a través de una interred no confiable. Una interred difiere de una sola red debido a que diversas partes podrían tener diferentes topologías, anchos de banda, retardos, tamaños de paquete y otros parámetros.Cada máquina que soporta TCP tiene una entidad de transporte TCP, ya sea un procedimientode biblioteca, un proceso de usuario o parte del kernel. En todos los casos, maneja flujos TCPe interactúa con la capa IP. La capa IP no proporciona ninguna garantía de que los datagramas se entregarán de manera apropiada, por lo que corresponde a TCP terminar los temporizadores y retransmitir los datagramas conforme sea necesario.

El modelo del servicio TCP El servicio TCP se obtiene al hacer que tanto el servidor como el cliente creen puntos terminales, llamados sockets, como se mencionó en la sección 6.1.3. Cada socket tiene un número (dirección), que consiste en la dirección IP del host, y un número de 16 bits, que es local a ese host, llamado puerto. Un puerto es el nombre TCP para un TSAP.

Todas las conexiones TCP son de dúplex total y de punto a punto. Dúplex total significa que el tráfico puede ir en ambas direcciones al mismo tiempo. Punto a punto significa que cada conexión tiene exactamente dos puntos finales. TCP no soporta la multidifusión ni la difusión.

El protocolo TCPLa entidad TCP emisora y la receptora intercambian datos en forma de segmentos. Un segmento consiste en un encabezado TCP fijo de 20 bytes (más una parte opcional) seguido de cero o más bytes de datos. El encabezado del segmento TCP En la figura 6-29 se muestra la distribución de un segmento TCP. Cada segmento comienzacon un encabezado de formato fijo de 20 bytes. El encabezado fijo puede ir seguido de opcionesde encabezado. Tras las opciones, si las hay, pueden continuar hasta 65,535 − 20 − 20 = 65,495bytes de datos, donde los primeros 20 se refieren al encabezado IP y los segundos al encabezadoTCP.

Establecimiento de una conexión TCP En el TCP las conexiones se establecen usando el acuerdo de tres vías estudiado en la sección 6.2.2. Para establecer una conexión, un lado, digamos el servidor, espera pasivamente una conexión entrante ejecutando las primitivas LISTEN y ACCEPT y especificando cierto origen o bien nadie en particular.

Si algún proceso está escuchando en el puerto, ese proceso recibe el segmento TCP entrante y puede entonces aceptar o rechazar la conexión; si la acepta, se devuelve un segmento de confirmación de recepción. La secuencia de segmentos TCP enviados en el caso normal se muestra en la figura 6-31 

Liberación de una conexión TCP Aunque las conexiones TCP son dúplex total, para entender la manera en que se liberan las conexiones es mejor visualizarlas como un par de conexiones símplex. Cada conexión símplex se libera independientemente de su igual. Para liberar una conexión, cualquiera de las partes puede enviar un segmento TCP con el bit FIN establecido, lo que significa que no tiene más datos por transmitir. Al confirmarse la recepción del FIN, ese sentido se apaga. Sin embargo, puede continuar un flujo de datos indefinido en el otro sentido. Cuando ambos sentidos se han apagado, se libera la conexión. Normalmente se requieren cuatro segmentos TCP para liberar una conexión, un FIN y un ACK para cada sentido. Sin embargo, es posible que el primer ACK y el segundo FIN estén contenidos en el mismo segmento, reduciendo la cuenta total a tres. Modelado de administración de conexiones TCP Los pasos requeridos para establecer y liberar conexiones pueden representarse en una máquinade estados finitos con los 11 estados listados en la figura 6-32.Cada conexión comienza en el estado CLOSED (cerrado) y deja ese estado cuando hace una apertura pasiva (LISTEN), o una apertura activa (CONNECT). Si el otro lado realiza la acción opuesta, se establece una conexión y el estado se vuelve ESTABLISHED. La liberación de la conexión puede iniciarse desde cualquiera de los dos lados. Al completarse, el estado regresa a CLOSED.

Figura 6-33. Máquina de estados finitos de administración de conexiones TCP. La línea continua gruesa es la trayectoria normal de un cliente. La línea punteada gruesa es la trayectoria normal de un servidor. Las líneas delgadas son eventos poco comunes. Cada transición está indicada por el evento que la ocasiona y la acción resultante, separada por una diagonal. 

Política de transmisión del TCP Como ya vimos, la administración de ventanas en el TCP no está vinculada directamente a las confirmaciones de recepción como en la mayoría de los protocolos de enlace de datos. Por ejemplo, suponga que el receptor tiene un búfer de 4096 bytes, como se muestra en la figura 6-34. Si el emisor envía un segmento de 2048 bytes que se recibe correctamente, el receptor enviará la confirmación de recepción del segmento. Sin embargo, dado que ahora sólo tiene 2048 bytes de espacio de búfer (hasta que la aplicación retire algunos datos de éste), anunciará una ventana de 2048 comenzando con el siguiente byte esperado.

Control de congestión en TCPEn teoría, puede manejarse la congestión aprovechando un principio de física: la ley de conservación de los paquetes. La idea es no inyectar un paquete nuevo en la red hasta que salga uno viejo (es decir, se entregue). El TCP intenta lograr esta meta manipulando dinámicamente el tamaño de la ventana. En la figura 6-36 ilustramos este problema hidráulicamente. En la figura 6-36(a) vemos un tubo grueso que conduce a un receptor de poca capacidad. Mientras el emisor no envíe más agua de la que puede contener la cubeta, no se perderá agua. En la figura 6-36(b), el factor limitante no es la capacidad de la cubeta, sino la capacidad de conducción interna de la red. Si entra demasiada agua a alta velocidad, ésta retrocederá, perdiéndose algo (en este caso, por el desbordamiento del embudo). 

Administración de temporizadores del TCP El TCP usa varios temporizadores (al menos conceptualmente) para hacer su trabajo. El másimportante de éstos es el temporizador de retransmisión.

TCP y UDP inalámbricos el TCP no debería preocuparse si el IP está operando por fibra o por radio. En la práctica sí importa, puesto que la mayoría de las implementaciones de TCP han sido optimizadas cuidadosamente con base en supuestos que se cumplen en las redes alámbricas, pero no en las inalámbricas. Ignorar las propiedades de la transmisión inalámbrica puede conducir a implementaciones del TCP correctas desde el punto de vista lógico pero con un desempeño horrendo.  

UDP no tiene los mismos problemas que el TCP, la comunicación inalámbrica también le produce dificultades. El problema principal es que los programas usan el UDP pensando que es altamente confiable. Saben que no hay garantías, pero aun así esperan que sea casi perfecto.En un entorno inalámbrico, UDP estará muy lejos de serlo. En aquellos programas capaces de recuperarse de la pérdida de mensajes UDP, pasar repentinamente de un entorno en el que pueden perderse mensajes, pero rara vez ocurre, a uno en el que se pierden constantemente, puede dar pie a un desempeño desastroso.

TCP para Transacciones En la figura 6-40(a) se muestra la secuencia normal de paquetes para realizar una RPC en TCP. En el mejor de los casos se necesitan los siguientes nueve paquetes.

Observe que éste es el mejor de los casos. En el peor, la confirmación de recepción de la solicitud del cliente y del paquete FIN se realiza por separado, al igual que la respuesta y el paquete FIN del servidor.