b'\n_START_ARTICLE_\nCapa de transporte\n_START_PARAGRAPH_\nEl nivel de transporte o capa de transporte es el cuarto nivel del modelo OSI,\xe2\x80\x8b y est\xc3\xa1 encargado de la transferencia libre de errores de los datos entre el emisor y el receptor, aunque no est\xc3\xa9n directamente conectados, as\xc3\xad como de mantener el flujo de la red. Es la base de toda la jerarqu\xc3\xada de protocolo. La tarea de esta capa es proporcionar un transporte de datos confiable y econ\xc3\xb3mico de la m\xc3\xa1quina de origen a la m\xc3\xa1quina destino, independientemente de las de redes f\xc3\xadsicas en uno.\xe2\x80\x8b Sin la capa transporte, el concepto total de los protocolos en capas tendr\xc3\xada poco sentido.\n_START_SECTION_\nServicios proporcionados a las capas superiores\n_START_PARAGRAPH_\nLa meta final de la capa de transporte es proporcionar un servicio eficiente, confiable y econ\xc3\xb3mico a sus usuarios, que normalmente son procesos de la capa de aplicaci\xc3\xb3n. 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\xc3\xbacleo del sistema operativo, en un proceso independiente, en un paquete de biblioteca o en la tarjeta de red._NEWLINE__NEWLINE_Hay dos tipos de servicio en la capa de transporte, orientado y no orientado a la conexi\xc3\xb3n. En el servicio orientado a la conexi\xc3\xb3n consta de tres partes: establecimiento, transferencia de datos, y liberaci\xc3\xb3n. En el servicio no orientado a la conexi\xc3\xb3n se tratan los paquetes de forma individual._NEWLINE_Es la primera capa que lleva a cabo la comunicaci\xc3\xb3n extremo a extremo, y esta condici\xc3\xb3n ya se mantendr\xc3\xa1 en las capas superiores..\n_START_SECTION_\nPrimitivas del servicio de transporte\n_START_PARAGRAPH_\nPara permitir que los usuarios accedan al servicio de transporte, la capa de transporte debe proporcionar algunas operaciones a los programas de aplicaci\xc3\xb3n, es decir, una interfaz del servicio de transporte. Cada servicio de transporte tiene su propia interfaz. Con el prop\xc3\xb3sito de ver los aspectos b\xc3\xa1sicos, en esta secci\xc3\xb3n examinaremos primero un servicio de transporte sencillo y su interfaz._NEWLINE_El servicio de transporte es parecido al servicio en red, pero hay algunas diferencias importantes. La principal, es que, el prop\xc3\xb3sito 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._NEWLINE_En cambio, el servicio de transporte (orientado a la conexi\xc3\xb3n) si es confiable. Claro que las redes reales no est\xc3\xa1n libres de errores, pero ese es precisamente el prop\xc3\xb3sito de la capa de transporte: ofrecer un servicio confiable en una red no confiable._NEWLINE_Otra diferencia entre la capa de transporte y la de red es a quien van dirigidos sus servicios. El servicio de red lo usan \xc3\xbanicamente 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\xc3\xa1cil de usar._NEWLINE_Las primitivas de un transporte sencillo ser\xc3\xadan:_NEWLINE_- LISTEN: Se bloquea hasta que alg\xc3\xban proceso intenta el contacto._NEWLINE_- CONNECT: Intenta activamente establecer una conexi\xc3\xb3n._NEWLINE_- SEND: Env\xc3\xada informaci\xc3\xb3n._NEWLINE_- RECEIVE: Se bloquea hasta que llegue una TPDU de DATOS._NEWLINE_- DISCONNECT: Este lado quiere liberar la conexi\xc3\xb3n._NEWLINE_Y con estas primitivas podemos hacer un esquema sencillo de manejo de conexiones.\n_START_SECTION_\nSockets de Berkeley\n_START_PARAGRAPH_\nEste 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\xc3\xa1s caracter\xc3\xadsticas y flexibilidad.\n_START_SECTION_\nElementos de los protocolos de transporte\n_START_PARAGRAPH_\nEl 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\xc3\xb3n y el control del flujo._NEWLINE_Pero tambi\xc3\xa9n existen diferencias importantes entre ambas, como los entornos en que operan, la capa transporte necesita el direccionamiento expl\xc3\xadcito de los destinos, mientras que la capa de red no, otra diferencia es la cantidad de datos, mucho mayor en la capa de transporte.\n_START_SECTION_\nDireccionamiento\n_START_PARAGRAPH_\nCuando un proceso desea establecer una conexi\xc3\xb3n con un computador de aplicaci\xc3\xb3n remoto, debe especificar a cu\xc3\xa1l se conectar\xc3\xa1 (\xc2\xbfa qui\xc3\xa9n le llegar\xc3\xa1 el mensaje?). El m\xc3\xa9todo 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\xc3\xa9rmino gen\xc3\xa9rico de TSAP (Punto de Acceso al Servicio de Transporte). Los puntos terminales an\xc3\xa1logos de la capa de red se llaman NSAP (Punto de Acceso al Servicio de Red). Las direcciones IP son ejemplos de NSAPS.\n_START_SECTION_\nEstablecimiento de una conexi\xc3\xb3n\n_START_PARAGRAPH_\nEl establecimiento de una conexi\xc3\xb3n parece f\xc3\xa1cil, pero en realidad es sorprendentemente dif\xc3\xadcil. A primera vista, parecer\xc3\xada que es suficiente con mandar una TPDU (Unidad de Datos del Protocolo de Transporte) con la petici\xc3\xb3n de conexi\xc3\xb3n y esperar a que el otro acepte la conexi\xc3\xb3n. El problema viene cuando la red puede perder, almacenar, o duplicar paquetes._NEWLINE_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\xc3\xb3n la creamos. Al liberarse la conexi\xc3\xb3n descartamos la direcci\xc3\xb3n y no se vuelve a utilizar. O tambi\xc3\xa9n asignar una secuencia dentro de los datos transmitidos, pero estos plantean el problema de que si se pierde la conexi\xc3\xb3n perdemos el orden del identificador y ya no funciona._NEWLINE_La soluci\xc3\xb3n seria m\xc3\xa1s f\xc3\xa1cil si los paquetes viejos se eliminaran de la subred cada cierto tiempo de vida. Para ello podemos utilizar las siguientes t\xc3\xa9cnicas: Un dise\xc3\xb1o de subred Restringido._NEWLINE_Colocar un contador de saltos en cada paquete._NEWLINE_Marcar el tiempo de cada paquete._NEWLINE_Pero en la pr\xc3\xa1ctica no vale solo con hacer esto sino que tenemos que garantizar que todas las confirmaciones de los paquetes tambi\xc3\xa9n se eliminan.\n_START_SECTION_\nLiberaci\xc3\xb3n de una conexi\xc3\xb3n\n_START_PARAGRAPH_\nLa liberaci\xc3\xb3n de una conexi\xc3\xb3n es m\xc3\xa1s f\xc3\xa1cil que su establecimiento. No obstante, hay m\xc3\xa1s escollos de los que uno podr\xc3\xada imaginar. Hay dos estilos de terminaci\xc3\xb3n de una conexi\xc3\xb3n: liberaci\xc3\xb3n asim\xc3\xa9trica y liberaci\xc3\xb3n sim\xc3\xa9trica. La liberaci\xc3\xb3n asim\xc3\xa9trica es la manera en que funciona el mecanismo telef\xc3\xb3nico: cuando una parte cuelga, se interrumpe la conexi\xc3\xb3n. La liberaci\xc3\xb3n sim\xc3\xa9trica trata la conexi\xc3\xb3n como dos conexiones unidireccionales distintas, y requiere que cada una se libere por separado._NEWLINE_La liberaci\xc3\xb3n asim\xc3\xa9trica es abrupta y puede resultar en la p\xc3\xa9rdida de datos. Por lo que es obvio que se requiere un protocolo de liberaci\xc3\xb3n m\xc3\xa1s refinado para evitar la p\xc3\xa9rdida de datos. Una posibilidad es usar la liberaci\xc3\xb3n sim\xc3\xa9trica, en la que cada direcci\xc3\xb3n se libera independientemente de la otra. Aqu\xc3\xad, un host puede continuar recibiendo datos aun tras haber enviado una TPDU de desconexi\xc3\xb3n._NEWLINE_La liberaci\xc3\xb3n sim\xc3\xa9trica es ideal cuando un proceso tiene una cantidad fija de datos por enviar y sabe con certidumbre cu\xc3\xa1ndo los ha enviado. En otras situaciones, la determinaci\xc3\xb3n de si se ha efectuado o no todo el trabajo y se debe terminarse o no la conexi\xc3\xb3n no es tan obvia. Podr\xc3\xadamos pensar en un protocolo en el que el host 1 diga:\xe2\x80\x9dYa termine, \xc2\xbfTerminaste tambi\xc3\xa9n?\xe2\x80\x9d. Si el host 2 responde \xe2\x80\x9cYa termine tambi\xc3\xa9n. Adi\xc3\xb3s\xe2\x80\x9d, la conexi\xc3\xb3n puede liberarse con seguridad._NEWLINE_Pero no es tan fiable por el problema de que siempre tendremos que esperar la confirmaci\xc3\xb3n de los mensajes recibidos y si esta confirmaci\xc3\xb3n no llega no libera la conexi\xc3\xb3n y despu\xc3\xa9s puede que necesite la confirmaci\xc3\xb3n de que lleg\xc3\xb3 la confirmaci\xc3\xb3n y entrar\xc3\xadamos en un bucle del que no podemos salir._NEWLINE_Podemos hacer que al host 1 si no le llega la confirmaci\xc3\xb3n despu\xc3\xa9s de N intentos (es que quiere la desconexi\xc3\xb3n), se libere. Esto produce una conexi\xc3\xb3n semiabierta en la que el host 1 est\xc3\xa1 desconectado pero el host 2 no como no le llega la confirmaci\xc3\xb3n 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\xc3\xa1ticamente.\n_START_SECTION_\nControl de Flujo y almacenamiento en buffer\n_START_PARAGRAPH_\nRespecto de la manera en que se manejan las conexiones mientras est\xc3\xa1n en uso, uno de los aspectos clave es el control de flujo. Se necesita un esquema para evitar que un emisor r\xc3\xa1pido desborde a un receptor lento. La diferencia principal es que un enrutador por lo regular tiene relativamente pocas l\xc3\xadneas, y un host puede tener numerosas conexiones. Esta diferencia hace poco pr\xc3\xa1ctico emplear la implementaci\xc3\xb3n que se hace en la capa de enlace._NEWLINE_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\xc3\xada. Sin embargo, si el receptor no garantiza que se aceptar\xc3\xa1 cada TPDU que llegue, el emisor tendr\xc3\xa1 que usar buffers de todas maneras. En el \xc3\xbaltimo caso, el emisor no puede confiar en la confirmaci\xc3\xb3n de recepci\xc3\xb3n de la capa red porque esto s\xc3\xb3lo significa que ha llegado la TPDU, no que ha sido aceptada. _NEWLINE_Los Buffers pueden ser de tres tipos, y usaremos cada uno de ellos cuando m\xc3\xa1s nos convenga. _NEWLINE_El equilibrio \xc3\xb3ptimo entre el almacenamiento del buffer en el origen y en el destino depende del tipo de tr\xc3\xa1fico transportado por la conexi\xc3\xb3n.\n_START_SECTION_\nMultiplexi\xc3\xb3n\n_START_PARAGRAPH_\nLa multiplexi\xc3\xb3n de varias conversaciones en conexiones, circuitos virtuales o enlaces f\xc3\xadsicos desempe\xc3\xb1a un papel importante en diferentes capas de la arquitectura de red. En la capa de transporte puede surgir la necesidad de multiplexi\xc3\xb3n por varias razones. Por ejemplo, si en un host s\xc3\xb3lo se dispone de una direcci\xc3\xb3n de red, todas las conexiones de transporte de esa m\xc3\xa1quina tendr\xc3\xa1n que utilizarla. Cuando llega una TPDU, se necesita alg\xc3\xban mecanismo para saber a cu\xc3\xa1l proceso asignarla. Esta situaci\xc3\xb3n se conoce como multiplexi\xc3\xb3n hacia arriba._NEWLINE_La multiplexi\xc3\xb3n tambi\xc3\xa9n puede ser \xc3\xbatil en la capa transporte para la utilizaci\xc3\xb3n de circuitos virtuales, que dan m\xc3\xa1s ancho de banda cuando se reasigna a cada circuito una tasa m\xc3\xa1xima de datos. La soluci\xc3\xb3n es abrir m\xc3\xbaltiples conexiones de red y distribuir el tr\xc3\xa1fico entre ellas. Esto se denomina multiplexi\xc3\xb3n hacia abajo.\n_START_SECTION_\nRecuperaci\xc3\xb3n de ca\xc3\xaddas\n_START_PARAGRAPH_\nSi los hosts y los enrutadores est\xc3\xa1n sujetos a ca\xc3\xaddas, la recuperaci\xc3\xb3n es fundamental. Si la entidad de transporte est\xc3\xa1 por entero dentro de los hosts, la recuperaci\xc3\xb3n de ca\xc3\xaddas de red y de enrutadores es sencilla. Si la capa de red proporciona servicio de datagramas, las entidades de transporte esperan p\xc3\xa9rdida de algunas TPDUs todo el tiempo, y saben c\xc3\xb3mo manejarla. Si la capa de red proporciona servicio orientado a la conexi\xc3\xb3n, entonces la p\xc3\xa9rdida 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._NEWLINE_Un problema m\xc3\xa1s complicado es la manera de recuperarse de ca\xc3\xaddas del host. Al reactivarse, sus tablas est\xc3\xa1n en el estado inicial y no sabe con precisi\xc3\xb3n donde estaba._NEWLINE_En un intento por recuperar su estado previo, el servidor podr\xc3\xada enviar una TPDU de difusi\xc3\xb3n a todos los dem\xc3\xa1s host, anunciando que se acaba de caer y solicitando a todos sus clientes que le informen el estado de todas la conexiones abiertas.\n_START_SECTION_\nProtocolos de transporte de internet\n_START_PARAGRAPH_\nInternet tiene dos protocolos principales en la capa de transporte, uno orientado a la conexi\xc3\xb3n y otro no orientado a la conexi\xc3\xb3n. El protocolo no orientado a la conexi\xc3\xb3n es el UDP y el orientado es el TCP.\n_START_SECTION_\nUDP\n_START_PARAGRAPH_\nEl conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a la conexi\xc3\xb3n UDP (protocolo de datagramas de usuario). Este protocolo proporciona una forma para que las aplicaciones env\xc3\xaden datagramas IP encapsulados sin tener una conexi\xc3\xb3n.\n_START_SECTION_\nTCP\n_START_PARAGRAPH_\nTCP (protocolo de control de transmisi\xc3\xb3n) se dise\xc3\xb1\xc3\xb3 espec\xc3\xadficamente para proporcionar un flujo de bytes confiable de extremo a extremo a trav\xc3\xa9s de una interred no confiable. Una interred difiere de una sola red debido a que diversas partes podr\xc3\xadan tener diferentes topolog\xc3\xadas, anchos de banda, retardos, tama\xc3\xb1os de paquete\xe2\x80\xa6 TCP tiene un dise\xc3\xb1o que se adapta de manera din\xc3\xa1mica a las propiedades de la interred y que se sobrepone a muchos tipos de situaciones.'