Protocolo orientado a conexión y protocolo no orientado a conexión
Generalmente los protocolos se clasifican en dos categorías según el nivel de control de datos requerido:
- protocolos orientados a conexión: estos protocolos controlan la transmisión de datos durante una comunicación establecida entre dos máquinas. En tal esquema, el equipo receptor envía acuses de recepción durante la comunicación, por lo cual el equipo remitente es responsable de la validez de los datos que está enviando. Los datos se envían entonces como flujo de datos. TCP es un protocolo orientado a conexión;
- protocolos no orientados a conexión: éste es un método de comunicación en el cual el equipo remitente envía datos sin avisarle al equipo receptor, y éste recibe los datos sin enviar una notificación de recepción al remitente. Los datos se envían entonces como bloques (datagramas). UDP es un protocolo no orientado a conexión.
Protocolo e implementación
Un protocolo define únicamente cómo deben comunicar los equipos, es decir, el formato y la secuencia de datos que van a intercambiar. Por el contrario, un protocolo no define cómo se programa el software para que sea compatible con el protocolo. Esto se denomina implementación o la conversión de un protocolo a un lenguaje de programación.
Las especificaciones de los protocolos nunca son exhaustivas. Asimismo, es común que las implementaciones estén sujetas a una determinada interpretación de las especificaciones, lo cual genera especificidades de ciertas implementaciones o, aún peor, incompatibilidad o fallas de seguridad.
protocolo 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. Dado que sólo nos ocupamos del protocolo HTTP, no se explicará la parte del procesamiento en el servidor en esta sección del artículo. Si este tema les interesa, puede consultar el articulo sobre el tratamiento de CGI.
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.
Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de línea):
MÉTODO VERSIÓN URL<crlf>
ENCABEZADO: Valor<crlf>
. . . ENCABEZADO: Valor<crlf>
Línea en blanco <crlf>
CUERPO DE LA SOLICITUD
A continuación se encuentra un ejemplo de una solicitud HTTP:
GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)
Comandos
| Comando | Descripción |
|---|
| GET | Solicita el recurso ubicado en la URL especificada |
| HEAD | Solicita el encabezado del recurso ubicado en la URL especificada |
| POST | Envía datos al programa ubicado en la URL especificada |
| PUT | Envía datos a la URL especificada |
| DELETE | Borra el recurso ubicado en la URL especificada |
Encabezados
| Nombre del encabezado | Descripción |
|---|
| Accept | Tipo de contenido aceptado por el navegador (por ejemplo, texto/html). Consulte Tipos de MIME |
| Accept-Charset | Juego de caracteres que el navegador espera |
| Accept-Encoding | Codificación de datos que el navegador acepta |
| Accept-Language | Idioma que el navegador espera (de forma predeterminada, inglés) |
| Authorization | Identificación del navegador en el servidor |
| Content-Encoding | Tipo de codificación para el cuerpo de la solicitud |
| Content-Language | Tipo de idioma en el cuerpo de la solicitud |
| Content-Length | Extensión del cuerpo de la solicitud |
| Content-Type | Tipo de contenido del cuerpo de la solicitud (por ejemplo, texto/html). Consulte Tipos de MIME |
| Date | Fecha en que comienza la transferencia de datos |
| Forwarded | Utilizado por equipos intermediarios entre el navegador y el servidor |
| From | Permite especificar la dirección de correo electrónico del cliente |
| From | Permite especificar que debe enviarse el documento si ha sido modificado desde una fecha en particular |
| Link | Vínculo entre dos direcciones URL |
| Orig-URL | Dirección URL donde se originó la solicitud |
| Referer | Dirección URL desde la cual se realizó la solicitud |
| User-Agent | Cadena con información sobre el cliente, por ejemplo, el nombre y la versión del navegador y el sistema operativo |
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.
Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de línea):
VERSIÓN-HTTP CÓDIGO EXPLICACIÓN <crlf>
ENCABEZADO: Valor<crlf>
. . . ENCABEZADO: Valor<crlf>
Línea en blanco <crlf>
CUERPO DE LA RESPUESTA
A continuación se encuentra un ejemplo de una respuesta HTTP:
HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT
Encabezados de respuesta
| Nombre del encabezado | Descripción |
|---|
| Content-Encoding | Tipo de codificación para el cuerpo de la respuesta |
| Content-Language | Tipo de idioma en el cuerpo de la respuesta |
| Content-Length | Extensión del cuerpo de la respuesta |
| Content-Type | Tipo de contenido del cuerpo de la respuesta (por ejemplo, texto/html). Consulte Tipos de MIME |
| Date | Fecha en que comienza la transferencia de datos |
| Expires | Fecha límite de uso de los datos |
| Forwarded | Utilizado por equipos intermediarios entre el navegador y el servidor |
| Location | Redireccionamiento a una nueva dirección URL asociada con el documento |
| Server | Características del servidor que envió la respuesta |
Los códigos de respuesta
Son los códigos que se ven cuando el navegador no puede mostrar la página solicitada. El código de respuesta está formado por tres dígitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error.
| Código | Mensaje | Descripción |
|---|
| 10x | Mensaje de información | Estos códigos no se utilizan en la versión 1.0 del protocolo |
|---|
| 20x | Éxito | Estos códigos indican la correcta ejecución de la transacción |
|---|
| 200 | OK | La solicitud se llevó a cabo de manera correcta |
| 201 | CREATED | Sigue a un comando POST e indica el éxito, la parte restante del cuerpo indica la dirección URL donde se ubicará el documento creado recientemente. |
| 202 | ACCEPTED | La solicitud ha sido aceptada, pero el procedimiento que sigue no se ha llevado a cabo |
| 203 | PARTIAL INFORMATION | Cuando se recibe este código en respuesta a un comando de GET indica que la respuesta no está completa. |
| 204 | NO RESPONSE | El servidor ha recibido la solicitud, pero no hay información de respuesta |
| 205 | RESET CONTENT | El servidor le indica al navegador que borre el contenido en los campos de un formulario |
| 206 | PARTIAL CONTENT | Es una respuesta a una solicitud que consiste en el encabezado range. El servidor debe indicar el encabezadocontent-Range |
| 30x | Redirección | Estos códigos indican que el recurso ya no se encuentra en la ubicación especificada |
|---|
| 301 | MOVED | Los datos solicitados han sido transferidos a una nueva dirección |
| 302 | FOUND | Los datos solicitados se encuentran en una nueva dirección URL, pero, no obstante, pueden haber sido trasladados |
| 303 | METHOD | Significa que el cliente debe intentarlo con una nueva dirección; es preferible que intente con otro método en vez de GET |
| 304 | NOT MODIFIED | Si el cliente llevó a cabo un comando GET condicional (con la solicitud relativa a si el documento ha sido modificado desde la última vez) y el documento no ha sido modificado, este código se envía como respuesta. |
| 40x | Error debido al cliente | Estos códigos indican que la solicitud es incorrecta |
|---|
| 400 | BAD REQUEST | La sintaxis de la solicitud se encuentra formulada de manera errónea o es imposible de responder |
| 401 | UNAUTHORIZED | Los parámetros del mensaje aportan las especificaciones de formularios de autorización que se admiten. El cliente debe reformular la solicitud con los datos de autorización correctos |
| 402 | PAYMENT REQUIRED | El cliente debe reformular la solicitud con los datos de pago correctos |
| 403 | FORBIDDEN | El acceso al recurso simplemente se deniega |
| 404 | NOT FOUND | Un clásico. El servidor no halló nada en la dirección especificada. Se ha abandonado sin dejar una dirección para redireccionar... :) |
| 50x | Error debido al servidor | Estos códigos indican que existe un error interno en el servidor |
|---|
| 500 | INTERNAL ERROR | El servidor encontró una condición inesperada que le impide seguir con la solicitud (una de esas cosas que les suceden a los servidores...) |
| 501 | NOT IMPLEMENTED | El servidor no admite el servicio solicitado (no puede saberlo todo...) |
| 502 | BAD GATEWAY | El servidor que actúa como una puerta de enlace o proxy ha recibido una respuesta no válida del servidor al que intenta acceder |
| 503 | SERVICE UNAVAILABLE | El servidor no puede responder en ese momento debido a que se encuentra congestionado (todas las líneas de comunicación se encuentran congestionadas, inténtelo de nuevo más adelante) |
| 504 | GATEWAY TIMEOUT | La respuesta del servidor ha llevado demasiado tiempo en relación al tiempo de espera que la puerta de enlace podía admitir (excedió el tiempo asignado...) |
protocolo 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.
Cuando un cliente FTP se conecta con un servidor FTP, el USUARIO PI inicia la conexión con el servidor de acuerdo con el protocolo Telnet. El cliente envía comandos FTP al servidor, el servidor los interpreta, ejecuta su DTP y después envía una respuesta estándar. Una vez que se establece la conexión, el servidor PI proporciona el puerto por el cual se enviarán los datos al Cliente DTP. El cliente DTP escucha el puerto especificado para los datos provenientes del servidor.
Es importante tener en cuenta que, debido a que los puertos de control y de datos son canales separados, es posible enviar comandos desde un equipo y recibir datos en otro. Entonces, por ejemplo, es posible transferir datos entre dos servidores FTP mediante el paso indirecto por un cliente para enviar instrucciones de control y la transferencia de información entre dos procesos del servidor conectados en el puerto correcto.
En esta configuración, el protocolo indica que los canales de control deben permanecer abiertos durante la transferencia de datos. De este modo, un servidor puede detener una transmisión si el canal de control es interrumpido durante la transmisión.
Los comandos FTP
Toda comunicación que se realice en el canal de control sigue las recomendaciones del protocolo Telnet. Por lo tanto, los comandos FTP son cadenas de caracteres Telnet (en código NVT-ASCII) que finalizan con el código de final de línea Telnet (es decir, la secuencia <CR>+<LF>, Retorno de carro seguido del carácter Avance de línea indicado como <CRLF>).
Si el comando FTP tiene un parámetro, éste se separa del comando con un espacio (<SP>).
Los comandos FTP hacen posible especificar:
- El puerto utilizado
- El método de transferencia de datos
- La estructura de datos
- La naturaleza de la acción que se va a realizar (Recuperar, Enumerar, Almacenar, etc.)
Existen tres tipos de comandos FTP diferentes:
- Comandos de control de acceso
- Comandos de parámetros de transferencia
- Comandos de servicio FTP
| Comandos de control de acceso |
|---|
| Comando | Descripción |
|---|
| USER | Cadena de caracteres que permite identificar al usuario. La identificación del usuario es necesaria para establecer la comunicación a través del canal de datos. |
| PASS | Cadena de caracteres que especifica la contraseña del usuario. Este comando debe ser inmediatamente precedida por el comando USER. El cliente debe decidir si esconder la visualización de este comando por razones de seguridad. |
| ACCT | Cadena de caracteres que especifica la cuenta del usuario. El comando generalmente no es necesario. Durante la respuesta que acepta la contraseña, si la respuesta es 230, esta etapa no es necesaria; Si la respuesta es 332, sí lo es. |
| CWD | Change Working Directory (Cambiar el directorio de trabajo): este comando permite cambiar el directorio actual. Este comando requiere la ruta de acceso al directorio para que se complete como un argumento. |
| CDUP | Change to Parent Directory (Cambiar al directorio principal): este comando permite regresar al directorio principal. Se introdujo para resolver los problemas de denominación del directorio principal según el sistema (generalmente ".."). |
| SMNT | Structure Mount (Montar estructura): |
| REIN | Reinitialize (Reinicializar): |
| QUIT | Comando que permite abandonar la sesión actual. Si es necesario, el servidor espera a que finalice la transferencia en progreso y después proporciona una respuesta antes de cerrar la conexión. |
| Comandos de parámetros de transferencia |
|---|
| Comando | Descripción |
|---|
| PORT | Cadena de caracteres que permite especificar el número de puerto utilizado. |
| PASV | Comando que permite indicar al servidor de DTP que permanezca a la espera de una conexión en un puerto específico elegido aleatoriamente entre los puertos disponibles. La respuesta a este comando es la dirección IP del equipo y el puerto. |
| TYPE | Este comando permite especificar el tipo de formato en el cual se enviarán los datos. |
| STRU | Carácter Telnet que especifica la estructura de archivos (F de File [Archivo], R de Record [Registro], P de Page [Página]). |
| MODE | Carácter Telnet que especifica el método de transferencia de datos (S deStream [Flujo], B de Block [Bloque], C de Compressed [Comprimido]). |
| Comandos de servicio FTP |
|---|
| Comando | Descripción |
|---|
| RETR | Este comando (RETRIEVE [RECUPERAR]) le pide al servidor de DTP una copia del archivo cuya ruta de acceso se da en los parámetros. |
| STOR | Este comando (store [almacenar]) le pide al servidor de DTP que acepte los datos enviados por el canal de datos y que los almacene en un archivo que lleve el nombre que se da en los parámetros. Si el archivo no existe, el servidor lo crea; de lo contrario, lo sobrescribe. |
| STOU | Este comando es idéntico al anterior, sólo le pide al servidor que cree un archivo cuyo nombre sea único. El nombre del archivo se envía en la respuesta. |
| APPE | Gracias a este comando (append [adjuntar]) los datos enviados se concatenan en el archivo que lleva el nombre dado en el parámetro si ya existe; si no es así, se crea. |
| ALLO | Este comando (allocate [reservar]) le pide al servidor que reserve un espacio de almacenamiento lo suficientemente grande como para recibir el archivo cuyo nombre se da en el argumento. |
| REST | Este comando (restart [reiniciar]) permite que se reinicie una transferencia desde donde se detuvo. Para hacer esto, el comando envía en el parámetro el marcador que representa la posición en el archivo donde la transferencia se había interrumpido. Después de este comando se debe enviar inmediatamente un comando de transferencia. |
| RNFR | Este comando (rename from [renombrar desde]) permite volver a nombrar un archivo. En los parámetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNTO. |
| RNTO | Este comando (rename from [renombrar a]) permite volver a nombrar un archivo. En los parámetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNFR. |
| ABOR | Este comando (abort [cancelar]) le indica al servidor de DTP que abandone todas las transferencias asociadas con el comando previo. Si no hay conexión de datos abierta, el servidor de DTP no realiza ninguna acción; de lo contrario, cierra la conexión. Sin embargo, el canal de control permanece abierto. |
| DELE | Este comando (delete [borrar]) permite que se borre un archivo, cuyo nombre se da en los parámetros. Este comando es irreversible y la confirmación sólo puede darse a nivel cliente. |
| RMD | Este comando (remove directory [eliminar directorio]) permite borrar un directorio. El nombre del directorio que se va a borrar se indica en los parámetros. |
| MKD | Este comando (make directory [crear directorio]) permite crear un directorio. El nombre del directorio que se va a crear se indica en los parámetros. |
| PWD | Este comando (print working directory [mostrar el directorio actual]) hace posible volver a enviar la ruta del directorio actual completa. |
| LIST | Este comando permite que se vuelva a enviar la lista de archivos y directorios presentes en el directorio actual. Esto se envía a través del DTP pasivo. Es posible indicar un nombre de directorio en el parámetro de este comando. El servidor de DTP enviará la lista de archivos del directorio ubicado en el parámetro. |
| NLST | Este comando (name list [lista de nombres]) permite enviar la lista de archivos y directorios presentes en el directorio actual. |
| SITE | Este comando (site parameters [parámetros del sistema]) hace que el servidor proporcione servicios específicos no definidos en el protocolo FTP. |
| SYST | Este comando (system [sistema]) permite el envío de información acerca del servidor remoto. |
| STAT | Este comando (Estado: [estado]) permite transmitir el estado del servidor; por ejemplo, permite conocer el progreso de una transferencia actual. Este comando acepta una ruta de acceso en el argumento y después devuelve la misma información que LISTA pero a través del canal de control. |
| HELP | Este comando permite conocer todos los comandos que el servidor comprende. La información se devuelve por el canal de control. |
| NOOP | Este comando (no operations [no operación]) sólo se utiliza para recibir un comando OK del servidor. Sólo se puede utilizar para no desconectarse después de un período de inactividad prolongado. |
Las respuestas FTP
Las respuestas FTP garantizan la sincronización entre el cliente y el servidor FTP. Por lo tanto, por cada comando enviado por el cliente, el servidor eventualmente llevará a cabo una acción y sistemáticamente enviará una respuesta.
Las respuestas están compuestas por un código de 3 dígitos que indica la manera en la que el comando enviado por el cliente ha sido procesado. Sin embargo, debido a que el código de 3 dígitos resulta difícil de leer para las personas, está acompañado de texto (cadena de caracteres Telnet separada del código numérico por un espacio).
Los códigos de respuesta están compuestos por 3 números, cuyos significados son los siguientes:
- El primer número indica el estatuto de la respuesta (exitosa o fallida)
- El segundo número indica a qué se refiere la respuesta.
- El tercer número brinda un significado más específico (relacionado con cada segundo dígito).
| Primer número |
|---|
| Dígito | Significado | Descripción |
|---|
| 1yz | Respuesta positiva preliminar | La acción solicitada está en progreso. Se debe obtener una segunda respuesta antes de enviar un segundo comando. |
| 2yz | Respuesta de finalización positiva | La acción solicitada se ha completado y puede enviarse un nuevo comando. |
| 3yz | Respuesta intermedia positiva | La acción solicita está temporalmente suspendida. Se espera información adicional del cliente. |
| 4yz | Respuesta de finalización negativa | La acción solicitada no se ha realizado debido a que el comando no se ha aceptado temporalmente. Se le solicita al cliente que intente más tarde. |
| 5yz | Respuesta negativa permanente | La acción solicitada no se ha realizado debido a que el comando no ha sido aceptado. Se le solicita al cliente que formule una solicitud diferente. |
| Segundo número |
|---|
| Dígito | Significado | Descripción |
|---|
| x0z | Sintaxis | La acción tiene un error de sintaxis o sino, es un comando que el servidor no comprende. |
| x1z | Información | Ésta es una respuesta que envía información (por ejemplo, una respuesta a un comando STAT). |
| x2z | Conexiones | La respuesta se refiere al canal de datos. |
| x3z | Autenticación y cuentas | La respuesta se refiere al inicio de sesión (USUARIO/CONTRASEÑA) o a la solicitud para cambiar la cuenta (CPT). |
| x4z | No utilizado por el protocolo FTP. | |
| x5z | Sistema de archivos | La respuesta se relaciona con el sistema de archivos remoto. |
protocolo ARP
El protocolo ARP tiene un papel clave entre los protocolos de capa de Internet relacionados con el protocolo TCP/IP, ya que permite que se conozca la dirección física de una tarjeta de interfaz de red correspondiente a una dirección IP. Por eso se llama Protocolo de Resolución de Dirección (en inglés ARP significa Address Resolution Protocol).
Cada equipo conectado a la red tiene un número de identificación de 48 bits. Éste es un número único establecido en la fábrica en el momento de fabricación de la tarjeta. Sin embargo, la comunicación en Internet no utiliza directamente este número (ya que las direcciones de los equipos deberían cambiarse cada vez que se cambia la tarjeta de interfaz de red), sino que utiliza una dirección lógica asignada por un organismo: la dirección IP.
Para que las direcciones físicas se puedan conectar con las direcciones lógicas, el protocolo ARP interroga a los equipos de la red para averiguar sus direcciones físicas y luego crea una tabla de búsqueda entre las direcciones lógicas y físicas en una memoria caché.
Cuando un equipo debe comunicarse con otro, consulta la tabla de búsqueda. Si la dirección requerida no se encuentra en la tabla, el protocolo ARP envía una solicitud a la red. Todos los equipos en la red comparan esta dirección lógica con la suya. Si alguno de ellos se identifica con esta dirección, el equipo responderá al ARP, que almacenará el par de direcciones en la tabla de búsqueda, y, a continuación, podrá establecerse la comunicación.
El protocolo RARP
El protocolo RARP (Protocolo de Resolución de Dirección Inversa) es mucho menos utilizado. Es un tipo de directorio inverso de direcciones lógicas y físicas.
En realidad, el protocolo RARP se usa esencialmente para las estaciones de trabajo sin discos duros que desean conocer su dirección física.
El protocolo RARP le permite a la estación de trabajo averiguar su dirección IP desde una tabla de búsqueda entre las direcciones MAC (direcciones físicas) y las direcciones IP alojadas por una pasarela ubicada en la misma red de área local (LAN).
Para poder hacerlo, el administrador debe definir los parámetros de la pasarela (router) con la tabla de búsqueda para las direcciones MAC/IP. A diferencia del ARP, este protocolo es estático. Por lo que la tabla de búsqueda debe estar siempre actualizada para permitir la conexión de nuevas tarjetas de interfaz de red.
El protocolo RARP tiene varias limitaciones. Se necesita mucho tiempo de administración para mantener las tablas importantes en los servidores. Esto se ve reflejado aun más en las grandes redes. Lo que plantea problemas de recursos humanos, necesarios para el mantenimiento de las tablas de búsqueda y de capacidad por parte del hardware que aloja la parte del servidor del protocolo RARP. Efectivamente, el protocolo RARP permite que varios servidores respondan a solicitudes, pero no prevé mecanismos que garanticen que todos los servidores puedan responder, ni que respondan en forma idéntica. Por lo que, en este tipo de arquitectura, no podemos confiar en que un servidor RARP sepa si una dirección MAC se puede conectar con una dirección IP, porque otros servidores ARP pueden tener una respuesta diferente. Otra limitación del protocolo RARP es que un servidor sólo puede servir a una LAN.
Para solucionar los dos primeros problemas de administración, el protocolo RARP se puede remplazar por el protocolo DRARP, que es su versión dinámica. Otro enfoque consiste en la utilización de un servidor DHCP (Protocolo de configuración de host dinámico), que permite una resolución dinámica de las direcciones. Además, el protocolo DHCP es compatible con el protocolo BOOTP (Protocolo de secuencia de arranque) y, al igual que este protocolo, es enrutable, lo que le permite servir varias LAN. Sólo interactúa con el protocolo IP.
Gestión de errores
ICMP (Protocolo de mensajes de control de Internet) es un protocolo que permite administrar información relacionada con errores de los equipos en red. Si se tienen en cuenta los escasos controles que lleva a cabo el protocolo IP, ICMP no permite corregir los errores sino que los notifica a los protocolos de capas cercanas. Por lo tanto, el protocolo ICMP es usado por todos los routers para indicar un error (llamado unproblema de entrega).
Los mensajes ICMP están encapsulados
Los mensajes de error ICMP se envían a través de la red en forma de datagramas, como cualquier otro dato. Por lo tanto, los mismos mensajes de error pueden contener errores.
Sin embargo, si existe un error en un datagrama que lleva un mensaje ICMP, no se envía ningún mensaje de error para evitar el efecto "bola de nieve", si hay un incidente en la red.
A continuación encontrará a qué se asemeja un mensaje ICMP encapsulado en un datagrama IP:
Mensaje ICMP
(8 bits) (8 bits) (16 bits) (tamaño variable)
Significado de los mensajes ICMP
PING. Este comando, que permite evaluar la red, envía un datagrama a un destino y solicita que regrese.
¿Qué es una dirección IP?
Los equipos comunican a través de Internet mediante el protocolo IP (Protocolo de Internet). Este protocolo utiliza direcciones numéricas denominadas direcciones IP compuestas por cuatro números enteros (4 bytes) entre 0 y 255, y escritos en el formato xxx.xxx.xxx.xxx. Por ejemplo, 194.153.205.26es una dirección IP en formato técnico.
Los equipos de una red utilizan estas direcciones para comunicarse, de manera que cada equipo de la red tiene una dirección IP exclusiva.
El organismo a cargo de asignar direcciones públicas de IP, es decir, direcciones IP para los equipos conectados directamente a la red pública de Internet, es el ICANN (Internet Corporation for Assigned Names and Numbers) que remplaza el IANA desde 1998 (Internet Assigned Numbers Agency).
Cómo descifrar una dirección IP
Una dirección IP es una dirección de 32 bits, escrita generalmente con el formato de 4 números enteros separados por puntos. Una dirección IP tiene dos partes diferenciadas:
- los números de la izquierda indican la red y se les denomina netID (identificador de red).
- los números de la derecha indican los equipos dentro de esta red y se les denomina host-ID(identificador de host).
Veamos el siguiente ejemplo:
Observe la red, a la izquierda 194.28.12.0. Contiene los siguientes equipos:
- 194.28.12.1 a 194.28.12.4
Observe la red de la derecha 178.12.0.0. Incluye los siguientes equipos:
- 178.12.77.1 a 178.12.77.6
En el caso anterior, las redes se escriben 194.28.12 y 178.12.77, y cada equipo dentro de la red se numera de forma incremental.
Tomemos una red escrita 58.0.0.0. Los equipos de esta red podrían tener direcciones IP que van desde58.0.0.1 a 58.255.255.254. Por lo tanto, se trata de asignar los números de forma que haya una estructura en la jerarquía de los equipos y los servidores.
Cuanto menor sea el número de bits reservados en la red, mayor será el número de equipos que puede contener.
De hecho, una red escrita 102.0.0.0 puede contener equipos cuyas direcciones IP varían entre 102.0.0.1 y 102.255.255.254 (256*256*256-2=16.777.214 posibilidades), mientras que una red escrita 194.24 puede contener solamente equipos con direcciones IP entre 194.26.0.1 y 194.26.255.254 (256*256-2=65.534 posibilidades); ésta es el concepto de clases de direcciones IP.
ESTOS PROTOCOLOS SON LOS QUE MAS SE USAN PERO ESTOS QUE HAY A CONTINUACIÓN TAMBIÉN SON MUY IMPORTANTES, SI QUIERES MÁS PROTOCOLOS PUEDES DAR CLICK EN LOS ENLACES:
