EL NIVEL DE TRANSPORTE EN INTERNET

5 EL NIVEL DE TRANSPORTE EN INTERNET

Autor: Rogelio Montañana

5 EL NIVEL DE TRANSPORTE EN INTERNET 5-1

5.1 INTRODUCCIÓN 5-2

5.1.1 Primitivas del servicio de transporte 5-3

5.1.2 La interfaz sockets 5-3

5.2 ELEMENTOS DE PROTOCOLOS DE TRANSPORTE 5-4

5.2.1 Establecimiento de una conexión 5-5

5.2.2 Terminación de una conexión 5-6

5.2.3 Control de flujo y de buffers 5-6

5.2.4 Multiplexación 5-8

5.2.5 Recuperación de caídas 5-9

5.3 LOS PROTOCOLOS DE TRANSPORTE DE LA INTERNET: TCP Y UDP 5-9

5.3.1 TCP (Transport Control Protocol) 5-10

5.3.2 La cabecera de segmento TCP 5-11

5.3.3 Tamaño de segmento y fragmentación 5-13

5.3.4 Flujo de datos en TCP 5-14

5.3.5 Intercambio de información en TCP 5-15

5.3.6 Gestión de conexión TCP 5-15

5.3.7 Estados de TCP 5-17

5.3.8 Conexiones medio abiertas y timer de keepalive 5-19

5.3.9 Política de transmisión de TCP 5-20

5.3.10 Problemas de paquetes pequeños 5-20

5.3.10.1 Algoritmo de Nagle 5-20

5.3.10.2 Síndrome de la ventana tonta y solución de Clark 5-21

5.3.11 Control de congestión en TCP 5-21

5.3.12 Gestión de timers en TCP 5-23

5.3.13 Opciones del protocolo TCP 5-25

5.3.14 UDP (User Datagram Protocol) 5-26

5.4 EJERCICIOS 5-28

5.5 SOLUCIONES 5-31

5.1 INTRODUCCIÓN

El nivel de transporte se encarga de suministrar el servicio de transporte de bits a las aplicaciones. Éstas funcionan generalmente según el paradigma cliente-servidor, por el cual una aplicación (cliente) toma la iniciativa y solicita los servicios a la otra (servidor).

Como ya sabemos la comunicación 'peer to peer' entre dos entidades del nivel de transporte ocurre en realidad gracias a los servicios ofrecidos por el nivel de red. Mientras que el nivel de red se ocupa de resolver los problemas propios de la topología de ésta (rutas y congestión fundamentalmente) el nivel de transporte sólo existe en las dos entidades extremas de la comunicación, por lo que también se le llama nivel host-host o extremo a extremo. El nivel de transporte no es consciente, ni debe serlo, de la manera como físicamente están interconectados los dos hosts, que puede ser por una LAN, una WAN o una combinación de múltiples redes de ambos tipos.

La unidad básica de intercambio de información a nivel de enlace se denomina trama (porque los datos van 'rodeados' de información de control por delante y por detrás). En el nivel de red esta unidad básica se conoce como paquete. No existe un término equivalente para la unidad de transferencia de información en el nivel de transporte; a falta de mejor alternativa utilizaremos para este fin el término OSI TPDU (Transport Protocol Data Unit); en la Internet se suele utilizar el término mensaje en el caso de UDP (servicio no orientado a conexión), y segmento en el de TCP (servicio orientado a conexión), pero esta nomenclatura no es compartida por otros protocolos de transporte.

Generalmente las aplicaciones requieren que el nivel de transporte les garantice la entrega de los datos al destinatario, sin errores, pérdidas ni datos duplicados; para que esto sea posible el nivel de transporte ofrecerá normalmente un servicio orientado a conexión, con retransmisiones en caso necesario. Este es el caso por ejemplo del protocolo TCP de Internet, utilizado en muchas aplicaciones como FTP (File Transfer Protocol, transferencia de ficheros), SMTP (Simple Mail Transfer Protocol, correo electrónico) , HTTP (HyperText Transfer Protocol, usado en tráfico Web), etc.

En ocasiones las aplicaciones se conforman -o incluso prefieren- un servicio menos fiable en el que los mensajes se envían sin pedir confirmación, de forma independiente unos de otros. Este tipo de servicio se suministra normalmente con un protocolo no orientado a conexión. El protocolo UDP de Internet es un ejemplo de este tipo de servicio. Entre los casos en que se quiere un servicio de este tipo se encuentran por ejemplo las aplicaciones en tiempo real ya que en ese caso no se quiere incurrir en el retardo propio de un protocolo orientado a conexión.

Al igual que en Internet en OSI también hay dos protocolos de transporte, uno orientado a conexión y uno no orientado a conexión. La tabla 5.1 muestra los más importantes protocolos de nivel de red y de transporte de Internet y sus corresponidentes protocolos OSI.

Tipo de protocolo Internet OSI

Nivel de red IP (Internet Protocol) CLNP (ConnectionLess Network Protocol)

Routing interno OSPF (Open Shortest Path First) IS-IS ( Intermediate System to Intermediate System)

Routing externo BGP (Border Gateway Protocol) IDRP (InterDomain Routing Protocol)

Nivel de transporte, orientado a conexión TCP (Transmission Control Protocol) TP4 (Transport Protocol clase 4)

Nivel de transporte, no orientado a conexión UDP (User Datagram Protocol) TP0 (Transport Protocol clase 0)

Tabla 5.1.- Correspondencia de protocolos Internet y OSI a nivel de red y de transporte

Normalmente las entidades del nivel de transporte se implementan como procesos en el sistema operativo del host, o bien procesos de usuario. El sistema operativo puede ser monousuario o multiusuario. En muchos casos el host tiene una sola instancia del nivel de red, y una sola del de transporte, pero muchas de los niveles superiores (aplicación o sesión); el nivel de transporte se encarga de mutiplexar el tráfico recibido de las diversas entidades de nivel superior en una única conexión a través del nivel de red.

Los protocolos de transporte no orientados a conexión, como UDP, son protocolos muy sencillos, que existen únicamente para permitir la correcta conexión de la capa de aplicación y la de red; actúan como una capa de adaptación bastante primitiva. Por esto la mayoría de nuestra discusión se centrará en los protocolos orientados a conexión, a los que nos referiremos implícitamente la mayor parte del tiempo.

5.1.1 Primitivas del servicio de transporte

En un servicio de transporte básico orientado a conexión (CONS) la secuencia de primitivas podría ser algo como lo siguiente:

PRIMITIVA TPDU PRIMITIVA TPDU

CLIENTE ENVIADA SERVIDOR ENVIADA

Listen

(bloqueado)

Connect Petición conexión

(bloqueado)

Receive

Send Conexión aceptada

(bloqueado)

Receive

Send Datos

(bloqueado)

Receive

Send Datos

(bloqueado)

Receive

. . . . . .

Disconnect Petición desconexión

Receive

Disconnect Petición desconexión

(libera conexión)

(libera conexión) Listen

(bloqueado)

5.1.2 La interfaz sockets

Como ya vimos en el tema 1 la interfaz utilizada entre los diferentes niveles de un mismo sistema no forma parte de un protocolo de comunicaciones. Dos sistemas necesitan acordar las reglas que seguirá la comunicación entre ellos en cada uno de los niveles, pero la forma como se realiza la comunicación vertical, es decir , la que ocurre dentro de un sistema es asunto interno que no incumbe a los protocolos. Esa comunicación vertical se realiza normalmente mediante las denominadas APIs (Application Programming Interfaces).

Aunque no requerida por las comunicaciones, la estandarización de las APIs comporta unos beneficios evidentes por la posibilidad de aprovechar software entre sistemas diferentes. Esto es especialmente cierto en el nivel de transporte, ya que es aquí donde interaccionarán más programas diferentes, correspondientes a las diversas aplicaciones que se desarrollen. Muchas implementaciones de TCP/IP disponen de una API para programación aplicaciones denominada sockets (literalmente enchufes, aunque nunca se utiliza esta denominación). Los sockets se introdujeron con el sistema operativo UNIX BSD (Berkeley Software Distribution) en 1982. La interfaz sockets es multiprotocolo, soporta TCP, UDP y otros protocolos.

Aun cuando no forman parte de ningún estándar oficial ni están recogidos en ningún RFC, los sockets son la API más extendida en programación de aplicaciones TCP/IP y forman un estándar 'de facto'. Existen implementaciones para muchos sistemas operativos no UNIX, e incluso en casos en que el sistema operativo no los incorpora suele haber una librería de rutinas sockets que permite adaptar programas con relativa facilidad. Por ejemplo, la interfaz WinSock permite adaptar aplicaciones MS Windows sobre diversas implementaciones de TCP/IP. Al no ser un estándar puede haber pequeñas diferencias entre implementaciones, por lo que es conveniente disponer siempre de la documentación correspondiente al software que se utiliza.

La filosofía básica de los sockets deriva directamente del sistema de entrada/salida de UNIX, con ampliaciones que permiten por ejemplo a un proceso servidor ponerse 'a la escucha'. Algunas de las rutinas generan y envían las TPDUs a partir de sus argumentos; éstas (las TPDUs) sí forman parte del protocolo, por lo que deben de ser conformes con el estándar correspondiente.

5.2 ELEMENTOS DE PROTOCOLOS DE TRANSPORTE

Al ocuparse de la comunicación extremo

...