6.1 Protocolos de transporte
Los protocolos de transporte proporcionan servicios de distribución de datos orientados a la conexión a través de redes. Fundamentalmente proporcionan intercambio de datos extremo a extremo en los cuales se mantienen sesiones o conexiones entre sistemas para el intercambio secuencial y fiable de los datos.
Los protocolos de transporte incluyen aquellos aquí enumerados:
1. Conexión de red avanzada par a par (APPN, Advanced Peer-to-Peer Networking) de IBM.
2. Servicio de transporte orientado a la conexión (COTS, Connection-Oriented Transport Service) y Servicios de transporte no orientados a la conexión (CLTs, Connectionless Transport Services de OSI).
3. Parte del Protocolo de control de transmisión (TCP, Transmission Control Protocol) del grupo de protocolos de TCP/IP de Internet y UNIX.
4. Parte de SPX del grupo de protocolos SPX/IPX de Novell.
5. Interfaces NetBIOS y NetBEUI de Microsoft.
6. Protocolo de mantenimiento de la tabla de encaminamiento (RTMP, Routing Table Mantenance Protocol) de AppleTalk, Protocolo de eco de AppleTalk (AEP, AppleTalk Echo Protocol), Protocolo de transacción de AppleTalk (ATP, AppleTalk Transaction Protocol), Protocolos de vinculación de nombre (NBP, Name Binding Protocol).
6.1.1 TCP
TCP (que significa Protocolo de Control de Transmisión) es uno de los principales protocolos de la capa de transporte del modelo TCP/IP. En el nivel de aplicación, posibilita la administración de datos que vienen del nivel más bajo del modelo, o van hacia él, (es decir, el protocolo IP). Cuando se proporcionan los datos al protocolo IP, los agrupa en datagramas IP, fijando el campo del protocolo en 6 (para que sepa con anticipación que el protocolo es TCP). TCP es un protocolo orientado a conexión, es decir, que permite que dos máquinas que están comunicadas controlen el estado de la transmisión.
Las principales características del protocolo TCP son las siguientes:
a) TCP permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP.
b) TCP permite que el monitoreo del flujo de los datos y así evitar la saturación de la red.
c) TCP permite que los datos se formen en segmentos de longitud variada para "entregarlos" al protocolo IP.
d) TCP 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.
e) Por último, TCP permite comenzar y finalizar la comunicación amablemente.
El objetivo de TCP
Con el uso del protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al sistema de acuse de recibo del protocolo TCP) independientemente de las capas inferiores. Esto significa que los routers (que funcionan en la capa de Internet) sólo tienen que enviar los datos en forma de datagramas, 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).
Durante una comunicación usando el protocolo TCP, las dos máquinas deben establecer una conexión. La máquina emisora (la que solicita la conexión) se llama cliente, y la máquina receptora se llamaservidor. Por eso es que decimos que estamos en un entorno Cliente-Servidor.
Las máquinas de dicho entorno se comunican en modo en línea, es decir, que la comunicación se realiza en ambas direcciones.
Para posibilitar la comunicación y que funcionen bien todos los controles que la acompañan, los datos se agrupan; es decir, que se agrega un encabezado a los paquetes de datos que permitirán sincronizar las transmisiones y garantizar su recepción.
Otra función del TCP es la capacidad de controlar la velocidad de los datos usando su capacidad para emitir mensajes de tamaño variable. Estos mensajes se llaman segmentos.
6.1.2 UDP
El protocolo UDP (Protocolo de datagrama de usuario) es un protocolo no orientado a conexión de la capa de transporte del modelo TCP/IP. Este protocolo es muy simple ya que no proporciona detección de errores (no es un protocolo orientado a conexión).
Por lo tanto, el encabezado del segmento UDP es muy simple:
|
puerto de origen
(16 bits);
|
puerto de destino
(16 bits);
|
|
longitud total
(16 bits);
|
suma de comprobación del encabezado
(16 bits);
|
|
Datos
(longitud variable).
|
Significado de los diferentes campos
Puerto de origen: es el número de puerto relacionado con la aplicación del remitente del segmento UDP. Este campo representa una dirección de respuesta para el destinatario. Por lo tanto, este campo es opcional. Esto significa que si el puerto de origen no está especificado, los 16 bits de este campo se pondrán en cero. En este caso, el destinatario no podrá responder (lo cual no es estrictamente necesario, en particular para mensajes unidireccionales).
Puerto de destino: este campo contiene el puerto correspondiente a la aplicación del equipo receptor al que se envía.
Longitud: este campo especifica la longitud total del segmento, con el encabezado incluido. Sin embargo, el encabezado tiene una longitud de 4 x 16 bits (que es 8 x 8 bits), por lo tanto la longitud del campo es necesariamente superior o igual a 8 bytes.
Suma de comprobación: es una suma de comprobación realizada de manera tal que permita controlar la integridad del segmento.
6.1.3 DNS
Cada equipo conectado directamente a Internet tiene al menos una dirección IP específica. Sin embargo, los usuarios no desean trabajar con direcciones numéricas, como por ejemplo 194.153.205.26, sino con un nombre de dominio o más específicamente, con direcciones (llamadas direcciones FQDN) como por ejemplo es.kioskea.net.
Es posible asociar nombres en lenguaje normal con direcciones numéricas gracias a un sistema llamado DNS (Sistema de Nombres de Dominio).
Esta correlación entre las direcciones IP y el nombre de dominio asociado se llama resolución de nombres de dominio (o resolución de direcciones).
Nombres del ordenador
Al comienzo de TCP/IP, puesto que las redes no eran muy extensas, o en otras palabras que el número de equipos conectados a la misma red era bajo, los administradores de red crearon archivos llamadostablas de conversión manual. Estas tablas de conversión manual eran archivos secuenciales, por lo general llamados hosts o hosts.txt, y asociaban en cada línea la dirección IP del equipo con el nombre literal relacionado, denominado nombre del ordenador.
Introducción al Sistema de Nombres de Dominio
Sin embargo, el anterior sistema de tablas de conversión exigía una actualización manual de las tablas para la totalidad de los equipos en caso de incluir o modificar el nombre de una máquina. Por lo tanto, con el aumento en tamaño de las redes y sus interconexiones, fue necesario implementar un sistema de gestión para los nombres que fuese jerárquico y fácil de administrar. El sistema llamado Sistema de Nombres de Dominio (DNS) fue desarrollado en noviembre de 1983 por Paul Mockapetris (RFC 882 y RFC 883) y luego revisado en 1987 en las RFC 1034 y 1035. El DNS ha sido sometido a varias RFC.
Este sistema ofrece:
• un espacio de nombre jerárquico que permite garantizar la singularidad de un nombre en una estructura arbórea, como por ejemplo sistemas de archivo Unix.
• un sistema de servidores de distribución que permite que el espacio de nombre esté disponible.
• un sistema de cliente que permite "resolver" nombres de dominio, es decir, interrogar a los servidores para encontrar la dirección IP que corresponde a un nombre.
Espacio de nombre
La estructura del sistema DNS se basa en una estructura de arbórea en donde se definen los dominios de nivel superior (llamados TLD, Dominios de Nivel Superior); esta estructura está conectada a un nodo raíz representado por un punto.
Cada nodo del árbol se llama nombre de dominio y tiene una etiqueta con una longitud máxima de 63 caracteres.
6.1.4 DHCP
DHCP significa Protocolo de configuración de host dinámico. Es un protocolo que permite que un equipo conectado a una red pueda obtener su configuración (principalmente, su configuración de red) en forma dinámica (es decir, sin intervención particular). Sólo tiene que especificarle al equipo, mediante DHCP, que encuentre una dirección IP de manera independiente. El objetivo principal es simplificar la administración de la red.
El protocolo DHCP sirve principalmente para distribuir direcciones IP en una red, pero desde sus inicios se diseñó como un complemento del protocolo BOOTP (Protocolo Bootstrap), que se utiliza, por ejemplo, cuando se instala un equipo a través de una red (BOOTP se usa junto con un servidor TFTP donde el cliente encontrará los archivos que se cargarán y copiarán en el disco duro). Un servidor DHCP puede devolver parámetros BOOTP o la configuración específica a un determinado host.
Funcionamiento del protocolo DHCP
Primero, se necesita un servidor DHCP que distribuya las direcciones IP. Este equipo será la base para todas las solicitudes DHCP por lo cual debe tener una dirección IP fija. Por lo tanto, en una red puede tener sólo un equipo con una dirección IP fija: el servidor DHCP.
El sistema básico de comunicación es BOOTP (con la trama UDP). Cuando un equipo se inicia no tiene información sobre su configuración de red y no hay nada especial que el usuario deba hacer para obtener una dirección IP. Para esto, la técnica que se usa es la transmisión: para encontrar y comunicarse con un servidor DHCP, el equipo simplemente enviará un paquete especial de transmisión (transmisión en 255.255.255.255 con información adicional como el tipo de solicitud, los puertos de conexión, etc.) a través de la red local.
Cuando el DHCP recibe el paquete de transmisión, contestará con otro paquete de transmisión (no olvide que el cliente no tiene una dirección IP y, por lo tanto, no es posible conectar directamente con él) que contiene toda la información solicitada por el cliente.
Se podría suponer que un único paquete es suficiente para que el protocolo funcione. En realidad, hay varios tipos de paquetes DHCP que pueden emitirse tanto desde el cliente hacia el servidor o servidores, como desde los servidores hacia un cliente:
• DHCPDISCOVER (para ubicar servidores DHCP disponibles)
• DHCPOFFER (respuesta del servidor a un paquete DHCPDISCOVER, que contiene los parámetros iniciales)
• DHCPREQUEST (solicitudes varias del cliente, por ejemplo, para extender su concesión)
• DHCPACK (respuesta del servidor que contiene los parámetros y la dirección IP del cliente)
• DHCPNAK (respuesta del servidor para indicarle al cliente que su concesión ha vencido o si el cliente anuncia una configuración de red errónea)
• DHCPDECLINE (el cliente le anuncia al servidor que la dirección ya está en uso)
• DHCPRELEASE (el cliente libera su dirección IP)
• DHCPINFORM (el cliente solicita parámetros locales, ya tiene su dirección IP)
El primer paquete emitido por el cliente es un paquete del tipo DHCPDISCOVER. El servidor responde con un paquete DHCPOFFER, fundamentalmente para enviarle una dirección IP al cliente. El cliente establece su configuración y luego realiza un DHCPREQUEST para validar su dirección IP (una solicitud de transmisión ya que DHCPOFFER no contiene la dirección IP) El servidor simplemente responde con un DHCPACK con la dirección IP para confirmar la asignación. Normalmente, esto es suficiente para que el cliente obtenga una configuración de red efectiva, pero puede tardar más o menos en función de que el cliente acepte o no la dirección IP..
6.1.5 SMTP
El protocolo SMTP (Protocolo simple de transferencia de correo) es el protocolo estándar que permite la transferencia de correo de un servidor a otro mediante una conexión punto a punto.
Éste es un protocolo que funciona en línea, encapsulado en una trama TCP/IP. El correo se envía directamente al servidor de correo del destinatario. El protocolo SMTP funciona con comandos de textos enviados al servidor SMTP (al puerto 25 de manera predeterminada). A cada comando enviado por el cliente (validado por la cadena de caracteres ASCII CR/LF, que equivale a presionar la tecla Enter) le sigue una respuesta del servidor SMTP compuesta por un número y un mensaje descriptivo.
A continuación se describe una situación en la que se realiza una solicitud para enviar correos a un servidor SMTP:
• Al abrir la sesión SMTP, el primer comando que se envía es el comando HELO seguido por un espacio (escrito <SP>) y el nombre de dominio de su equipo (para decir "hola, soy este equipo"), y después validado por Enter (escrito <CRLF>). Desde abril de 2001, las especificaciones para el protocolo SMTP, definidas en RFC 2821, indican que el comando HELO sea remplazado por el comando EHLO.
• El segundo comando es "MAIL FROM:" seguido de la dirección de correo electrónico del remitente. Si se acepta el comando, el servidor responde con un mensaje "250 OK".
• El siguiente comando es "RCPT TO:" seguido de la dirección de correo electrónico del destinatario. Si se acepta el comando, el servidor responde con un mensaje "250 OK".
• El comando DATA es la tercera etapa para enviar un correo electrónico. Anuncia el comienzo del cuerpo del mensaje. Si se acepta el comando, el servidor responde con un mensaje intermediario numerado 354 que indica que puede iniciarse el envío del cuerpo del mensaje y considera el conjunto de líneas siguientes hasta el final del mensaje indicado con una línea que contiene sólo un punto.
El cuerpo del correo electrónico eventualmente contenga algunos de los siguientes encabezados:
• Date (Fecha)
• Subject (Asunto)
• Cc
• Bcc (Cco)
• From (De)
6.1.6 FTP
El protocolo FTP (Protocolo de transferencia de archivos) es, como su nombre lo indica, un protocolo para transferir archivos.
La implementación del FTP se remonta a 1971 cuando se desarrolló un sistema de transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnológico de Massachusetts (MIT, Massachusetts Institute of Technology). Desde entonces, diversos documentos de RFC (petición de comentarios) han mejorado el protocolo básico, pero las innovaciones más importantes se llevaron a cabo en julio de 1973.
Actualmente, el protocolo FTP está definido por RFC 959 (Protocolo de transferencia de archivos (FTP) - Especificaciones).
La función del protocolo FTP
El protocolo FTP define la manera en que los datos deben ser transferidos a través de una red TCP/IP.
El objetivo del protocolo FTP es:
• permitir que equipos remotos puedan compartir archivos
• permitir la independencia entre los sistemas de archivo del equipo del cliente y del equipo del servidor
• permitir una transferencia de datos eficaz
El modelo FTP
El protocolo FTP está incluido dentro del modelo cliente-servidor, es decir, un equipo envía órdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor).
Durante una conexión FTP, se encuentran abiertos dos canales de transmisión:
• Un canal de comandos (canal de control)
• Un canal de datos
Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la administración de estos dos tipos de información:
• DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexión y de administrar el canal de datos. El DTP del lado del servidor se denomina SERVIDOR DE DTP y el DTP del lado del cliente se denomina USUARIO DE DTP.
• PI (Intérprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser controlado mediante los comandos recibidos a través del canal de control.
Esto es diferente en el cliente y el servidor:
• El SERVIDOR PI es responsable de escuchar los comandos que provienen de un USUARIO PI a través del canal de control en un puerto de datos, de establecer la conexión para el canal de control, de recibir los comandos FTP del USUARIO PI a través de éste, de responderles y de ejecutar el SERVIDOR DE DTP.
• El USUARIO PI es responsable de establecer la conexión con el servidor FTP, de enviar los comandos FTP, de recibir respuestas del SERVIDOR PI y de controlar al USUARIO DE DTP, si fuera necesario.
6.1.7 POP
El protocolo POP (Protocolo de oficina de correos), como su nombre lo indica, permite recoger el correo electrónico en un servidor remoto (servidor POP). Es necesario para las personas que no están permanentemente conectadas a Internet, ya que así pueden consultar sus correos electrónicos recibidos sin que ellos estén conectados.
Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan los puertos 109 y 110 respectivamente, y que funcionan utilizando comandos de texto radicalmente diferentes.
Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con comandos de texto enviados al servidor POP. Cada uno de estos comandos enviados por el cliente (validados por la cadena CR/LF) está compuesto por una palabra clave, posiblemente acompañada por uno o varios argumentos, y está seguido por una respuesta del servidor POP compuesta por un número y un mensaje descriptivo.
6.1.8 HTTP
Desde 1990, el protocolo HTTP (Protocolo de transferencia de hipertexto) es el protocolo más utilizado en Internet. La versión 0.9 sólo tenía la finalidad de transferir los datos a través de Internet (en particular páginas Web escritas en HTML). La versión 1.0 del protocolo (la más utilizada) permite la transferencia de mensajes con encabezados que describen el contenido de los mensajes mediante la codificación MIME.
El propósito del protocolo HTTP es permitir la transferencia de archivos (principalmente, en formato HTML). Entre un navegador (el cliente) y un servidor web (denominado, entre otros, httpd en equipos UNIX) localizado mediante una cadena de caracteres denominada dirección URL.
Comunicación entre el navegador y el servidor
La comunicación entre el navegador y el servidor se lleva a cabo en dos etapas:
El navegador realiza una solicitud HTTP
El servidor procesa la solicitud y después envía una respuesta HTTP
En realidad, la comunicación se realiza en más etapas si se considera el procesamiento de la solicitud en el servidor.
Solicitud HTTP
Una solicitud HTTP es un conjunto de líneas que el navegador envía al servidor. Incluye:
Una línea de solicitud: es una línea que especifica el tipo de documento solicitado, el método que se aplicará y la versión del protocolo utilizada. La línea está formada por tres elementos que deben estar separados por un espacio:
* el método
* la dirección URL
* la versión del protocolo utilizada por el cliente (por lo general, HTTP/1.0)
Los campos del encabezado de solicitud: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.
El cuerpo de la solicitud: es un conjunto de líneas opcionales que deben estar separadas de las líneas precedentes por una línea en blanco y, por ejemplo, permiten que se envíen datos por un comando POST durante la transmisión de datos al servidor utilizando un formulario.
Respuesta HTTP
Una respuesta HTTP es un conjunto de líneas que el servidor envía al navegador. Está constituida por: Incluye:
Una línea de estado: es una línea que especifica la versión del protocolo utilizada y el estado de la solicitud en proceso mediante un texto explicativo y un código. La línea está compuesta por tres elementos que deben estar separados por un espacio: La línea está formada por tres elementos que deben estar separados por un espacio:
* la versión del protocolo utilizada
* el código de estado
* el significado del código
Los campos del encabezado de respuesta: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la respuesta y/o el servidor. Cada una de estas líneas está compuesta por un nombre que califica el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.
El cuerpo de la respuesta: contiene el documento solicitado.
6.1.9 Telnet
El protocolo Telnet es un protocolo de Internet estándar que permite conectar terminales y aplicaciones en Internet. El protocolo proporciona reglas básicas que permiten vincular a un cliente (sistema compuesto de una pantalla y un teclado) con un intérprete de comandos (del lado del servidor).
El protocolo Telnet se aplica en una conexión TCP para enviar datos en formato ASCII codificados en 8 bits, entre los cuales se encuentran secuencias de verificación Telnet. Por lo tanto, brinda un sistema de comunicación orientado bidireccional (semidúplex) codificado en 8 bits y fácil de implementar.
El protocolo Telnet se basa en tres conceptos básicos:
• el paradigma Terminal virtual de red (NVT);
• el principio de opciones negociadas;
• las reglas de negociación.
Éste es un protocolo base, al que se le aplican otros protocolos del conjunto TCP/IP (FTP, SMTP, POP3, etc.). Las especificaciones Telnet no mencionan la autenticación porque Telnet se encuentra totalmente separado de las aplicaciones que lo utilizan (el protocolo FTP define una secuencia de autenticación sobre Telnet).
Además, el protocolo Telnet no es un protocolo de transferencia de datos seguro, ya que los datos que transmite circulan en la red como texto sin codificar (de manera no cifrada). Cuando se utiliza el protocolo Telnet para conectar un host remoto a un equipo que funciona como servidor, a este protocolo se le asigna el puerto 23.
Excepto por las opciones asociadas y las reglas de negociación, las especificaciones del protocolo Telnet son básicas. La transmisión de datos a través de Telnet consiste sólo en transmitir bytes en el flujo TCP (el protocolo Telnet específica que los datos deben agruparse de manera predeterminada —esto es, sin ninguna opción especifica lo contrario— en un búfer antes de enviarse. Específicamente, esto significa que de manera predeterminada los datos se envían línea por línea). Cuando se transmite el byte 255, el byte siguiente debe interpretarse como un comando. Por lo tanto, el byte 255 se denomina IAC(Interpretar como comando).
