jueves, 24 de mayo de 2012

¿QUE ES UN PROTOCOLO?



Un protocolo es un método estándar que permite la comunicación entre procesos (que potencialmente se ejecutan en diferentes equipos), es decir, es un conjunto de reglas y procedimientos que deben respetarse para el envío y la recepción de datos a través de una red. Existen diversos protocolos de acuerdo a cómo se espera que sea la comunicación. Algunos protocolos, por ejemplo, se especializarán en el intercambio de archivos (FTP); otros pueden utilizarse simplemente para administrar el estado de la transmisión y los errores (como es el caso de ICMP), etc.
En Internet, los protocolos utilizados pertenecen a una sucesión de protocolos o a un conjunto de protocolos relacionados entre sí. Este conjunto de protocolos se denomina TCP/IP. 
Entre otros, contiene los siguientes protocolos:
  • HTTP
  • FTP
  • ARP
  • ICMP
  • IP
  • TCP
  • UDP
  • SMTP
  • Telnet
  • NNTP

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:
Comunicación entre el navegador y el servidor
  • 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

ComandoDescripción
GETSolicita el recurso ubicado en la URL especificada
HEADSolicita el encabezado del recurso ubicado en la URL especificada
POSTEnvía datos al programa ubicado en la URL especificada
PUTEnvía datos a la URL especificada
DELETEBorra el recurso ubicado en la URL especificada

Encabezados

Nombre del encabezadoDescripción
AcceptTipo de contenido aceptado por el navegador (por ejemplo, texto/html). Consulte Tipos de MIME
Accept-CharsetJuego de caracteres que el navegador espera
Accept-EncodingCodificación de datos que el navegador acepta
Accept-LanguageIdioma que el navegador espera (de forma predeterminada, inglés)
AuthorizationIdentificación del navegador en el servidor
Content-EncodingTipo de codificación para el cuerpo de la solicitud
Content-LanguageTipo de idioma en el cuerpo de la solicitud
Content-LengthExtensión del cuerpo de la solicitud
Content-TypeTipo de contenido del cuerpo de la solicitud (por ejemplo, texto/html). Consulte Tipos de MIME
DateFecha en que comienza la transferencia de datos
ForwardedUtilizado por equipos intermediarios entre el navegador y el servidor
FromPermite especificar la dirección de correo electrónico del cliente
FromPermite especificar que debe enviarse el documento si ha sido modificado desde una fecha en particular
LinkVínculo entre dos direcciones URL
Orig-URLDirección URL donde se originó la solicitud
RefererDirección URL desde la cual se realizó la solicitud
User-AgentCadena 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 encabezadoDescripción
Content-EncodingTipo de codificación para el cuerpo de la respuesta
Content-LanguageTipo de idioma en el cuerpo de la respuesta
Content-LengthExtensión del cuerpo de la respuesta
Content-TypeTipo de contenido del cuerpo de la respuesta (por ejemplo, texto/html). Consulte Tipos de MIME
DateFecha en que comienza la transferencia de datos
ExpiresFecha límite de uso de los datos
ForwardedUtilizado por equipos intermediarios entre el navegador y el servidor
LocationRedireccionamiento a una nueva dirección URL asociada con el documento
ServerCaracterí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ódigoMensajeDescripción
10xMensaje de informaciónEstos códigos no se utilizan en la versión 1.0 del protocolo
20xÉxitoEstos códigos indican la correcta ejecución de la transacción
200OKLa solicitud se llevó a cabo de manera correcta
201CREATEDSigue 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.
202ACCEPTEDLa solicitud ha sido aceptada, pero el procedimiento que sigue no se ha llevado a cabo
203PARTIAL INFORMATIONCuando se recibe este código en respuesta a un comando de GET indica que la respuesta no está completa.
204NO RESPONSEEl servidor ha recibido la solicitud, pero no hay información de respuesta
205RESET CONTENTEl servidor le indica al navegador que borre el contenido en los campos de un formulario
206PARTIAL CONTENTEs una respuesta a una solicitud que consiste en el encabezado range. El servidor debe indicar el encabezadocontent-Range
30xRedirecciónEstos códigos indican que el recurso ya no se encuentra en la ubicación especificada
301MOVEDLos datos solicitados han sido transferidos a una nueva dirección
302FOUNDLos datos solicitados se encuentran en una nueva dirección URL, pero, no obstante, pueden haber sido trasladados
303METHODSignifica que el cliente debe intentarlo con una nueva dirección; es preferible que intente con otro método en vez de GET
304NOT MODIFIEDSi 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.
40xError debido al clienteEstos códigos indican que la solicitud es incorrecta
400BAD REQUESTLa sintaxis de la solicitud se encuentra formulada de manera errónea o es imposible de responder
401UNAUTHORIZEDLos 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
402PAYMENT REQUIREDEl cliente debe reformular la solicitud con los datos de pago correctos
403FORBIDDENEl acceso al recurso simplemente se deniega
404NOT FOUNDUn clásico. El servidor no halló nada en la dirección especificada. Se ha abandonado sin dejar una dirección para redireccionar... :)
50xError debido al servidorEstos códigos indican que existe un error interno en el servidor
500INTERNAL ERROREl servidor encontró una condición inesperada que le impide seguir con la solicitud (una de esas cosas que les suceden a los servidores...)
501NOT IMPLEMENTEDEl servidor no admite el servicio solicitado (no puede saberlo todo...)
502BAD GATEWAYEl servidor que actúa como una puerta de enlace o proxy ha recibido una respuesta no válida del servidor al que intenta acceder
503SERVICE UNAVAILABLEEl 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)
504GATEWAY TIMEOUTLa 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
El modelo FTP
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.
Transferencia de datos por FTP entre dos servidores
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
ComandoDescripción
USERCadena 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.
PASSCadena 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.
ACCTCadena 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.
CWDChange 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.
CDUPChange 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 "..").
SMNTStructure Mount (Montar estructura):
REINReinitialize (Reinicializar):
QUITComando 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
ComandoDescripción
PORTCadena de caracteres que permite especificar el número de puerto utilizado.
PASVComando 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.
TYPEEste comando permite especificar el tipo de formato en el cual se enviarán los datos.
STRUCarácter Telnet que especifica la estructura de archivos (F de File [Archivo], R de Record [Registro], P de Page [Página]).
MODECará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
ComandoDescripción
RETREste comando (RETRIEVE [RECUPERAR]) le pide al servidor de DTP una copia del archivo cuya ruta de acceso se da en los parámetros.
STOREste 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.
STOUEste 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.
APPEGracias 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.
ALLOEste 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.
RESTEste 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.
RNFREste 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.
RNTOEste 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.
ABOREste 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.
DELEEste 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.
RMDEste comando (remove directory [eliminar directorio]) permite borrar un directorio. El nombre del directorio que se va a borrar se indica en los parámetros.
MKDEste comando (make directory [crear directorio]) permite crear un directorio. El nombre del directorio que se va a crear se indica en los parámetros.
PWDEste comando (print working directory [mostrar el directorio actual]) hace posible volver a enviar la ruta del directorio actual completa.
LISTEste 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.
NLSTEste comando (name list [lista de nombres]) permite enviar la lista de archivos y directorios presentes en el directorio actual.
SITEEste comando (site parameters [parámetros del sistema]) hace que el servidor proporcione servicios específicos no definidos en el protocolo FTP.
SYSTEste comando (system [sistema]) permite el envío de información acerca del servidor remoto.
STATEste 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.
HELPEste comando permite conocer todos los comandos que el servidor comprende. La información se devuelve por el canal de control.
NOOPEste 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ígitoSignificadoDescripción
1yzRespuesta positiva preliminarLa acción solicitada está en progreso. Se debe obtener una segunda respuesta antes de enviar un segundo comando.
2yzRespuesta de finalización positivaLa acción solicitada se ha completado y puede enviarse un nuevo comando.
3yzRespuesta intermedia positivaLa acción solicita está temporalmente suspendida. Se espera información adicional del cliente.
4yzRespuesta de finalización negativaLa 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.
5yzRespuesta negativa permanenteLa 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ígitoSignificadoDescripción
x0zSintaxisLa acción tiene un error de sintaxis o sino, es un comando que el servidor no comprende.
x1zInformaciónÉsta es una respuesta que envía información (por ejemplo, una respuesta a un comando STAT).
x2zConexionesLa respuesta se refiere al canal de datos.
x3zAutenticación y cuentasLa respuesta se refiere al inicio de sesión (USUARIO/CONTRASEÑA) o a la solicitud para cambiar la cuenta (CPT).
x4zNo utilizado por el protocolo FTP.
x5zSistema de archivosLa 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:
ejemplo de red
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: 

No hay comentarios:

Publicar un comentario en la entrada