eMc2H 11 - Protocolos de red

eZine lover (@eZine)

Published in 

eMc2H

 · 2 years ago

El protocolo es un conjunto de reglas, estándares o normas de comportamiento que permite que programas de diferentes fabricantes, escritos en distintos lenguajes y ejecutados en máquinas diferentes puedan "Comunicarse " entre sí, haciendo uso de los diferentes elementos de la red y/o programas de los ordenadores conectados.

Una red es una configuración de computadora que intercambia información haciendo uso de un conjunto de reglas formales para su interacción. Estas reglas son los ya denominados protocolos. Un ejemplo claro de protocolo, es el conocidísimo TCP/IP, inventado en 1974 y adaptado al uso general en el año 1983.

A lo largo y ancho de la red, vamos a observar distintos tipo de protocolos, los cuales van a ser usados para distintos tipos de servicio, los usamos para transferir archivos, para mandar e-mails, para chatear, etc

Protocolo TCP/IP - Transfer Control Protocol/Internet Protocol

Empezamos con "la madre de todos los protocolos", el Protocolo TCP/IP (Transfer Control Protocol/Internet Protocol).

Diseñado con propósitos no comerciales, inició su curso como medio de interconectar la información entre universidades y centros de investigación.

Fue el primer protocolo, desarrollado y demostrado por primera vez en 1972 por el departamento de defensa de los Estados Unidos, ejecutándolo en el ARPANET una red de área extensa del departamento de defensa, actualmente sigue siendo el más usado, es utilizado por todo tipo de empresas, centros oficiales y usuarios particulares como medio de comunicación, y sirve de soporte a servicios como el correo electrónico, siendo también la base de la World Wide Web (www).

Se han desarrollado diferentes familias de protocolos para la comunicación por red de datos para los sistemas UNIX. El más ampliamente utilizado es el Internet Protocol Suite, conocido por nosotros como: TCP/IP.

El TCP/IP es una familia de protocolos de comunicación que por su diseño permite conectar la más grande entre todas las redes existentes: obviamente , nos referimos al Internet.
Sus principales características son que es abierta y gratuita y que tanto su desarrollo como las modificaciones se realizan por consenso.

Permite escribir programas o sistemas de comunicaciones que funcionarán de manera idéntica e independientemente a que se esté conectado con un módem, con una línea RDSI, ADSL o cualquier otra tecnología que pueda aparecer en el futuro. Su amplio uso lo hace especialmente idóneo para interconectar equipos de diferentes fabricantes, no sólo a Internet sino también en redes locales.

El TCP y el IP pertenecen a los denominados protocolos de bajo nivel, y de ellos dependen otros protocolos que gestionan funciones particulares como la transferencia de ficheros, el envío del correo electrónico, la conexión remota, el control de los usuarios que se han conectado a la red en un momento específico, etc.

Este protocolo DARPA (Defense Advanced Research Project Agency) nos permite proporcionar una transmisión fiable de paquetes de datos sobre redes. El nombre TCP / IP Proviene de dos protocolos importantes de la familia, el Transmission Contorl Protocol (TCP) y el Internet Protocol (IP). Todos juntos llegan a ser más de 100 protocolos diferentes definidos en este conjunto.

• El protocolo TCP está estructurado en capas (niveles) y representa el sistema de transporte de Internet. Se encarga de gestionar los datos que le suministran los protocolos de nivel superior, recuerda lo que ha sido enviado y lo vuelve a enviar en caso de que se hubiera perdido. Controla que todo se realice de forma transparente para el usuario.
• El protocolo IP es el de más bajo nivel de todos, y es utilizado por TCP para realizar determinadas acciones. De hecho, a pesar de que el TCP sea muy utilizado, existen protocolos que prefieren no usarlo y que para funcionar sólo necesitan las funciones que puede ofrecer el sencillo IP. Una red TCP/IP transfiere los datos mediante el ensamblaje de bloques de datos en paquetes, cada paquete tendrá una cabecera la cual contendrá información del control; tal como la dirección del destino, seguido de los datos. Cuando se envía un archivo por la red TCP/IP, su contenido se envía utilizando una serie de paquetes diferentes.
  

Para que la red TCP/IP esté activa y funcionado será necesario:

• Obtener una dirección Internet.
• Instalar las utilidades Internet en el sistema
• Configurar la red para TCP/IP
• Configurar los guiones de arranque TCP/IP
• Identificar otras máquinas ante el sistema
• Configurar la base de datos dependiendo del O.S
• Comenzar a ejecutar TCP/IP

Todo esto demuestra que el TCP/IP es una de las redes más comunes utilizadas para conectar computadoras con sistemas UNIX.

IRC (Internet Relay Chat)

Es un sistema que permite el intercambio de texto entre varios participantes simultáneamente a través de Internet (el famoso chat).
El sistema se fundamenta en un servidor IRC que se comunica con cada cliente IRC, es decir, con cada participante dentro de un mismo canal de charla, podemos bajar el cliente mIRC, nos conectamos al servidor IRC Undernet y entramos al canal #EmC2H ; P

SMTP (Simple Mail Transfer Protocol)

Este protocolo es utilizado para la gestión de correos en Internet de manera segura y eficaz. También conocido como E-mail, se basa en el envío de mensajes, a menudo sólo con texto, de un usuario a otro por medio de una red.

El SMTP está basado en la entrega punto-a-punto; un cliente SMTP contactará con el servidor SMTP del host de destino directamente para entregar el correo. Guardará el correo hasta que se haya copiado con éxito en el receptor. Esto difiere del principio de retransmisión común a muchos sistemas de correo en las que el correo atraviesa un número de host intermedios de la misma red y donde una transmisión con éxito implica sólo que el correo ha alcanzado el host correspondiente al siguiente salto.

En varias implementaciones, existe la posibilidad de intercambiar correo entre los sistemas de correo locales y SMTP. Estas aplicaciones se denominan pasarelas o puentes de correo. Enviar correo a través de una pasarela puede alterar la entrega punto-a-punto, ya que SMTP sólo garantiza la entrega fiable a la pasarela, no al host de destino, más allá de la red local. La transmisión punto SMTP en estos casos es host-pasarela, pasarela-host o pasarela-pasarela; SMTP no define lo que ocurre más allá de la pasarela.

Diseñada en principio como un servicio barato para interconectar centros científicos y de investigación, CSNET opera una pasarela que permite a sus suscriptores enviar y recibir correo en Internet con sólo un módem con dial. La pasarela sondea a los suscriptores a intervalos regulares, les entrega su correo y recoge el correo de salida. A pesar de no ser una entrega punto-a-punto, ha demostrado ser un sistema muy útil.

Cada mensaje tiene:

Una cabecera, o sobre, con estructura RFC 822.
La cabecera termina con una línea nula ( una línea con sólo la secuencia <CRLF>).

Contents
Todo lo que hay tras la línea nula es el cuerpo del mensaje, una secuencia de líneas con caracteres ASCII(aquellos con valor menor del 128 decimal).

El RFC 821 define un protocolo cliente/servidor.
Como siempre, el cliente SMTP es el que inicia la sesión (el emisor) y el servidor el que responde a la solicitud de sesión(el receptor). Sin embargo, como el cliente suele actuar como servidor para un programa de correo del usuario, es más sencillo referirse a él como emisor SMTP, y al servidor como receptor SMTP.

POP3 (Post Office Protocol Versión 3)

Es un protocolo para la gestión de correo en Internet. Es el más utilizado junto con SMTP, porque aunque en algunos nodos menores de Internet normalmente es poco práctico mantener un sistema de transporte de mensajes (MTS), es posible que una estación de trabajo no tenga recursos suficientes (espacio en disco, entre otros) para permitir que un servidor de SMTP [RFC821] y un sistema local asociado de entrega de correo estén residentes y continuamente en ejecución. De forma similar, puede ser caro (o incluso imposible) mantener una computadora personal interconectada a una red tipo IP durante grandes cantidades de tiempo (el nodo carece el recurso conocido como "connectivity"). A pesar de esto, a menudo es muy útil poder administrar correo sobre estos nodos, y frecuentemente soportan un user agent (UA agente de usuario) para ayudar en las tareas de manejo de correo. Para resolver el problema, un nodo que sí sea capaz de soportar un MTS ofrecerá a estos nodos menos dotados un servicio de maildrop. Se entiende por maildrop, el "lugar" en el sistema con el MTS donde el correo es almacenado para que los otros nodos puedan trabajar con él sin necesidad de mantener su propio MTS. El Protocolo de oficina de correos - Versión 3 (POP3) está destinado a permitir que una estación de trabajo acceda dinámicamente a un maildrop en un host servidor de forma útil y eficiente. Esto significa que el protocolo POP3 se usa para permitir a una estación de trabajo recobrar correo que el servidor tiene almacenado.

POP3 no está destinado a proveer de extensas operaciones de manipulación de correo sobre el servidor; normalmente, el correo es transmitido y entonces borrado. IMAP4 es un protocolo más avanzado y complejo y es tratado en [RFC1730] y revisado en [RFC 2060].

De aquí en adelante el termino (host) cliente se refiere a un host haciendo uso del servicio POP3 y host servidor al que ofrece este servicio. Inicialmente, el host servidor comienza el servicio POP3 leyendo el puerto 110 TCP. Cuando un host cliente desea de hacer uso del servicio, establece una conexión TCP con el host servidor. Cuando la conexión se establece, el servidor POP3 envía un saludo. Entonces, el cliente y el servidor de POP3 intercambian comandos y respuestas respectivamente hasta que la conexión se cierra o es abortada.

Los comandos en el POP3 consisten en una palabra clave (keyword), posiblemente seguida de uno o más argumentos. Todos los comandos terminan con un par CRLF. Las palabras clave y los argumentos consisten en caracteres ASCII imprimibles. Las palabras clave y los argumentos están cada uno separados por un único carácter de espacio. Las palabras clave son de una longitud de tres o cuatro caracteres, mientras que cada argumento puede ser de hasta 40 caracteres de longitud.

Las respuestas en el POP3 consisten de un indicador de estado y una palabra clave posiblemente seguida de información adicional. Todas las respuestas acaban en un par CLRF. Las respuestas pueden ser de hasta 512 caracteres de longitud, incluyendo el CRLF de terminación. También existen dos indicadores de estado: positivo o afirmativo ("+OK") y negativo ("-ERR"). Los servidores deben enviar el "+OK" y el "-ERR" en mayúsculas.

Las respuestas a ciertos comandos son multilínea (una respuesta compuesta de varias líneas). En estos casos, que se indican claramente más adelante, después de enviar la primera línea de la respuesta y un CRLF, se envía cualquier línea adicional, cada una terminada en un par CRLF. Cuando todas las líneas de la respuesta han sido enviadas, se envía una línea final, que consiste en un octeto de terminación (en decimal 046, ".") Y un par CRLF. Si alguna línea de la respuesta multilínea comienza con el octeto de terminación, se ponen bytes de relleno precedidos por el byte de terminación en esa línea de la respuesta. De aquí en adelante una respuesta multilínea termina con los cinco bytes "CRLF.CRLF". Al examinar una respuesta multilínea, el cliente comprueba si la línea comienza con el byte de terminación. Si es así y si siguen otros bytes a excepción del CRLF, el primer byte de la línea (el byte de terminación) es ignorado. De este modo si el CRLF sigue inmediatamente al carácter de terminación, entonces la respuesta desde el servidor POP termina y la línea conteniendo "CRLF " no es considerada como parte de la respuesta multilínea.

Una sesión POP3 progresa a través de una serie de estados a lo largo de su vida. Una vez la conexión TCP ha sido abierta y el servidor de POP3 ha enviado el "saludo" (línea especial que se utiliza cuando se establece la conexión), la sesión entra en el estado de autorización (AUTHORIZATION). En este estado, el cliente debe identificarse al servidor de POP3. Una vez el cliente ha hecho esto satisfactoriamente, el servidor adquiere los recursos asociados al maildrop del cliente, y la sesión entra en el estado de transacción (TRANSACTION). En este estado, el cliente realiza una serie de solicitudes al servidor de POP3. Cuando el cliente ha emitido el comando de finalización (QUIT), la sesión entra en el estado de actualización (UPDATE). En este estado, el servidor de POP3 libera cualesquiera recursos adquiridos durante el estado de transición, "dice adiós" y la conexión TCP se cierra.

Un servidor debe responder a comandos no reconocidos, no implementados, o sintácticamente incorrectos con un indicador negativo de estado (respuesta negativa). También debe responder con un indicador negativo de estado cuando la sesión se encuentra en un estado incorrecto. No hay un método general para que el cliente distinga entre un servidor que no implementa un comando opcional y un servidor que no esta dispuesto o es incapaz de procesar el comando.

Un servidor de POP3 puede disponer de un temporizador o cronómetro de inactividad (autologout inactivity timer). Tal cronómetro debe ser de por lo menos 10 minutos de duración. La recepción de cualquier comando desde el cliente durante este intervalo reinicia la cuenta de este cronómetro. Cuando el cronómetro llega a los diez minutos, la sesión no entra en el estado de actualización. Entonces, el servidor debería cerrar la conexión TCP sin eliminar ningún mensaje y sin enviar ninguna respuesta al cliente.

USER nombre

• Argumentos: una cadena identificando un mailbox, el cual solo tiene significado para el servidor
• Restricciones: solo puede darse en el estado de autorización después del saludo o de los comandos USER o PASS sin éxito.
  
• Definición: Para autentificar usando la combinación de los comandos USER y PASS, el cliente debe primero emitir el comando USER. Si el servidor responde afirmativamente (+OK), entonces el cliente puede responder con el comando PASS para completar la autentificación, o el comando QUIT para finalizar con la conexión. Si el servidor responde negativamente (-ERR) al comando USER, el cliente puede emitir un nuevo comando de autenticación o bien el comando QUIT.
  

El servidor puede devolver una respuesta afirmativa incluso a pesar de que no exista ningún mailbox. El servidor puede devolver una respuesta negativa si el mailbox existe, pero no permitir la autenticación.

PASS cadena

• Argumentos: palabra de acceso al mailbox Restricciones: solo puede darse en el estado de autorización inmediatamente después de un comando USER satisfactorio.
• Definición: Cuando el cliente el comando PASS, el servidor utiliza el par de argumentos de los comandos USER y PASS para determinar si al cliente se le debe dar acceso al maildrop apropiado.
  

Ya que el comando PASS tiene exactamente un argumento, un servidor de POP3 puede tratar los espacios como parte del password en lugar de cómo separadores de argumentos.

APOP nombre digest

• Argumentos: una cadena identificando un mailbox y una cadena digest MD5 Restricciones: solo puede darse en el estado de autorización después del saludo o de los comandos USER o PASS sin éxito.
• Definición: Normalmente, cada sesión POP3 comienza con intercambio USER/PASS. Esto tiene como resultado una clave de acceso específica enviada a través de la red. Para un uso intermitente del POP3, no conlleva un riesgo considerable. Sin embargo, muchas implementaciones de cliente POP3 conectan al servidor regularmente para comprobar si hay correo nuevo. Además, el intervalo de iniciación de la sesión puede ser del orden de 5 minutos. Por lo tanto, el riesgo de que la clave de acceso sea capturada es alto. Se requiere un método alternativo de autenticación que no implique el envío de claves de acceso a través de la red. Esta funcionalidad la proporciona el comando APOP.
  

Un servidor que implemente el comando APOP incluirá una marca de tiempo (timestamp) en sus "saludos". La sintaxis de la marca de tiempo corresponde al "msg-id" en la RFC 882 (actualizada por RFC 973 y después por RFC 1982), y debe ser diferente cada vez que el servidor envía un saludo. Por ejemplo, en una implementación UNIX en la cual un proceso UNIX separado es el encargado de cada instancia de servidor, la sintaxis de la marca de tiempo podría ser: process-ID.clock@hostname, donde process ID es el valor decimal del PID del proceso, clock es el valor decimal del reloj del sistema, y hostname es el nombre de dominio del host donde el servidor está funcionando.

El cliente recibe esta marca de tiempo y emite un comando APOP. El parámetro nombre tiene el mismo significado que el parámetro nombre del comando USER. EL parámetro digest se calcula aplicando el algoritmo MD5 (RFC 1321) a una cadena consistente en una marca de tiempo (incluyendo <) seguido de un secreto compartido. Este secreto compartido es una cadena conocida solo por el cliente y el servidor. Se debe tener un gran cuidado para prevenir una revelación no autorizada del secreto, ya que su conocimiento puede permitir a cualquier entidad hacerse pasar por el usuario. El parámetro digest es un valor de 16 bytes que se envía en formato hexadecimal, utilizando caracteres ASCII en minúsculas.

Cuando el servidor recibe el comando APOP, verifica el digest proporcionado . Si el digest es correcto, el servidor envía una respuesta afirmativa y la sesión entra en el estado de transacción. Si no, envía una respuesta negativa y la sesión permanece en el estado de autorización.

Notar que conforme incrementa la longitud de los secretos compartidos, aumenta la dificultad de derivarlos. Como tales, los secretos compartidos deben ser cadenas largas (considerablemente más largas que el ejemplo de 8 caracteres mostrado abajo).

AUTH mecanismo

• Argumentos: una cadena que identifique un mecanismo de autenticación IMAP4 (definición en IMAP4-AUTH).
• Restricciones: sólo puede darse en el estado de autorización.
  
• Definición: El comando AUTH se refiere a un mecanismo de autenticación al servidor por parte del cliente. Si el servidor soporta este mecanismo, lleva a cabo el protocolo para la identificación del usuario. Opcionalmente , también procede con un mecanismo de protección para las subsiguientes interacciones del protocolo. Si este mecanismo de autentificación no es soportado, el servidor debería rechazar el comando AUTH enviando una respuesta negativa.
  

El protocolo de autentificación consiste en una serie de cuestiones por parte del servidor y de unas respuestas del cliente, específicas de este mecanismo de autentificación. Una pregunta del servidor, es una línea que consiste en un carácter "+" seguido de un espacio y una cadena codificada en base 64. La respuesta del cliente es una línea que contiene otra cadena codificada en base 64. Si el cliente desea cancelar la autentificación, debe emitir una línea con un único "*". Si el servidor la recibe, rechazará el comando AUTH.

Un mecanismo de protección proporciona integridad y privacidad a la sesión del protocolo. Si se utiliza un mecanismo de protección, este será aplicado a todos los datos que se envíen en la conexión. El mecanismo de protección tiene efecto inmediatamente después de que un CLRF concluya con el proceso de autenticación del cliente y de la respuesta positiva del servidor. Una vez el mecanismo de protección se hace efectivo, el flujo de bytes de comandos y respuestas se procesa en buffers de ciphertext (texto cifrado). Cada buffer es transferido en la conexión como un flujo de bytes seguidos de un campo de 4 bytes que representan la longitud de los siguientes datos. La longitud máxima de los bufferes de ciphertext se define en el mecanismo de protección.

No es necesario que el servidor soporte algún mecanismo de autentificación, y tampoco es necesario que los mecanismos de autentificación soporten mecanismos de protección. Si un comando AUTH falla, la sesión permanece en el estado de autorización y el cliente puede probar con otro AUTH o bien con otro mecanismo como la combinación USER/PASS, o el comando APOP. En otras palabras, el cliente puede pedir tipos de autentificación en orden decreciente de preferencia, con USER/PASS o APOP como últimos recursos. Si el cliente completa la autentificación satisfactoriamente, el servidor de POP3 emite una respuesta afirmativa y se entra en el estado de transacción.

TOP mensaje

• Argumentos: un número de mensaje, que si aparece no se puede referir a ningún mensaje marcado como borrado; y un número no negativo de líneas.
• Restricciones: solo puede darse en el estado de transacción.
  
• Definición: Si el servidor emite una respuesta positiva, entonces ésta es multilínea. Después del +OK inicial, el servidor envía las cabeceras del mensaje, la línea en blanco separando las cabeceras del cuerpo, y luego el número de líneas del cuerpo del mensaje. Si el número de líneas requeridas por el cliente es mayor del número de líneas del cuerpo, el servidor envía el mensaje entero.
  

UIDL [mensaje]

• Argumentos: un número de mensaje opcional. Si está presente no debe referirse a un mensaje marcado como borrado.
• Restricciones: solo puede darse en el estado de transacción.
  
• Definición: Si se da un argumento, el servidor emite una respuesta afirmativa con una línea que contiene información del mensaje. Esta línea se llama unique-id listing. Si no se da ningún argumento y el servidor emite una respuesta afirmativa, la respuesta dada es multilínea. Después del +OK inicial, por cada mensaje en el maildrop, el servidor responde con una línea con información de ese mensaje.
  

Para simplificar el análisis, todos los servidores deben tener un mismo formato de unique-id listing, que consiste en el número de mensaje, un espacio y el unique-id del mensaje. Después no hay mas información. El unique-id listing de un mensaje es una cadena arbitraria determinada por el servidor, que consiste en 70 caracteres entre 0x21 y 0x7E (hexadecimal), los cuales identifican únicamente un mensaje en el maildrop y los cuales permanecen a lo largo de las distintas sesiones. Esta persistencia es requerida incluso si la sesión termina sin entrar en el estado de actualización. El servidor nunca debería rehusar el unique-id en un maildrop dado a lo largo de todo el tiempo de existencia de la entidad que usa el unique-id.

Mientras que generalmente es preferible para implementaciones de servidor almacenar los unique-id en el maildrop, la especificación tiene la intención de permitir que los unique-id sean calculados como trozos del mensaje. Los clientes deberían de ser capaces de manejar una situación en la que se den dos copias idénticas de un mensaje en un maildrop con el mismo unique-id.

FTP (File Transfer Protocol)

Es un protocolo para la transferencia de ficheros. Permite el correcto traslado de todo tipo de ficheros entre dos ordenadores conectados a Internet.

Los objetivos principales de este protocolo son:

• Posibilitar la compartición archivos entre computadoras (programas y/o datos)
• Posibilitar el uso remoto de las computadoras
• Transferir datos de una forma segura y optima entre computadoras

FTP mas que para ser usado por un usuario directamente es usado por los programas para comunicarse, lo que facilita al usuario despreocuparse de las características del sistema con que conecta. Se creo en 1971 con un modelo de transferencia llamado RFC 141 en M.I.T. Fue hasta después de muchas revisiones que llegó a RFC 265 cuando ya se le considera un protocolo de transferencia de archivos completa entre HOSTs (servidores de archivos) de ARPHANET. Al final de la edición de RFC 765 se incluyeron algunos de los que son ahora los comandos de este protocolo:

• CDUP Change to Parent Directory
• SMNT Structure Mount
• STOU Store Unique
• RMD Remove Directory
• MKD Make Directory
• PWD Print Directory
• SYST System

Tipos de datos en la transferencia por FTP:

• El tipo ASCII, es el mas común en el protocolo FTP. Se usa cuando se transfieren archivos de texto, la computadora que envía (sender), debe convertir cualquiera que sea su estructura de archivos interna, debe convertir sus datos al formato genérico de 8 bits, y el que recibe (receiver) lo debe convertir de nuevo a su formato propio.
• El tipo EBCDIC es el mas eficiente cuando ambos el que recibe y el que envía lo usan como formato propio, este tipo se representa también en 8 bits pero de forma EBCDIC. Lo único en lo que cambian es en la forma de reconocer los códigos de los caracteres.
  
• El formato de IMAGEN es cuando se compacta todo lo que se quiere enviar en cadenas seguidas de paquetes de 8 bits, esto es no importa el formato en que internamente se maneje la información, cuando se va a enviar se tiene que hacer una conversión de 8 bits en 8 bits y cuando el que recibe tiene todo el paquete, el mismo debe codificarlos de nuevo para que la transmisión sea completada.
  

En la estructura de datos en FTP se consideran tres tipos diferentes de archivos:

• File - structure donde no hay estructuras internas y el archivo es considerado una secuencia continua de bytes
• Record - structure donde los archivos contienen puros registros igualitos en estructura
  
• Page - structure donde los archivos contienen paginas enteras indexadas separadas.
  

Al establecer una conexión por FTP se debe tomar en cuenta que el mecanismo de transferencia consiste en colocar bien la transferencia de datos en los puertos adecuados y al concluir la conexión estos puertos deben ser cerrados adecuadamente. El tamaño de transferencia es de 8 bits, en ambos. El que va a transferir, debe escuchar desde el puerto hasta que el comando enviado sea recibido y este será el que de la Dirección de la transferencia . Una vez recibido el comando y establecido una transferencia del servidor a que solicita se inicializa la Comunicación de la transferencia para verificar la conexión, esta es una cabecera con un formato específico, después de esto se comienza a enviar las tramas de 8 bits sin importar el tipo de datos que sea (antes mencionado), y al finalizar se envía otra trama cabecera ya establecida confirmando la transferencia completada.

Modos de transferencia en FTP:

• STREAM MODE
• BLOCK MODE
• COMPRESSED MODE

Comandos frecuentes

De acceso:

• USER NAME (USER)
• PASSWORD (PASS
• ACCOUNT (ACCT)
• CHANGE WORKING DIRECTORY (CWD)
• CHANGE TO PARENT DIRECTORY (CDUP)
• REINITIALIZE (REIN)
• LOGOUT (QUIT)

De transferencia:

• DATA PORT (PORT)
• PASSIVE (PASV)
• FILE STRUCTURE (STRU)
• TRANSFER MODE (MODE)

De servicio:

• RETRIEVE (RETR)
• STORE (STOR)
• STORE UNIQUE (STOU)
• APPEND (with create) (APPE)
• ALLOCATE (ALLO)
• RENAME TO (RNTO)
• ABORT (ABOR)
• DELETE (DELE)
• REMOVE DIRECTORY (RMD)
• MAKE DIRECTORY (MKD)
• PRINT WORKING DIRECTORY (PWD)
• LIST (LIST)
• HELP (HELP)

Algunos de los códigos usados en la transferencia son los siguientes, estos códigos no son mas que mensajes enviados por el protocolo:

===================================== 
Códigos normales: 

200 Command ok. 

500 Syntax error, command unrecognized. 
This may include errors such as command line too long 

211 System status or systems help reply. 

212 Directory status. 

213 File status. 

227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). 

230 User logged in, proceed. 

530 not logged in. 

331 User name okay, need password. 

332 Need account for login. 

532 Need account for storing files. 
====================================== 

 
====================================== 
Códigos de mensajes con operaciones numéricas: 

110 Restart marker reply. 

120 Service ready in nnn minutes. 

125 Data connection already opens; transfer starting. 

150 File status okay; about to open data connection. 

200 Command okay. 

202 Command not implemented, superfluous at this site. 

211 System status, or system help reply. 

212 Directory status. 

213 File status. 
=======================================

HTTP (Hyper Tex Transfer Protocol)

Conjunto de normas que permiten a los navegadores interpretar adecuadamente la información contenida en páginas web. La indicación en una dirección web de la referencia http: // indica que el contenido de la información es compatible con el estándar HTTP.

_________

Protocolo: Hyper Text Transfer Protocol, Protocolo para la Transferencia de Hipertextos.

El protocolo HTTP se usa en los sistemas de información distribuidos que necesitan mostrar la información y pasarla por una comunicación normal haciendo uso de las ligas de este lenguaje articulando los intercambios de información entre los clientes Web y los servidores HTTP. El Protocolo fue implementado inicialmente por Tim Berners-Lee para WWW en 1991 como un protocolo rápido y sencillo que permite la transferencia de múltiples tipos de información de forma eficiente y rápida. Se denominó HTTP 0.9. El protocolo completo fue definido en 1992 e implementado en marzo de 1993.

Está soportado sobre los servicios de conexión TCP/IP, y funciona de la misma forma como los servicios comunes de los entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan Estos objetos Web (documento HTML, fichero multimedia o aplicación CGI) es conocido por su URL y están clasificados por su descripción MIME (descargando al protocolo de este aspecto).

Características principales

• Toda la comunicación entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato original.
• Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado está identificado por su clasificación MIME.
  
• Existen tres verbos básicos (hay más, pero por lo general no se utilizan) que un cliente puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar información al servidor y HEAD, para solicitar las características de un objeto.
  
• Cada operación HTTP implica una conexión con el servidor, que es liberada al término de la misma. Es decir, en una operación se puede recoger un único objeto.
  
• No mantiene estado. Cada petición de un cliente a un servidor no es influida por lastransacciones anteriores. El servidor trata cada petición como una operación totalmente independiente del resto.
  
• Cada objeto al que se aplican los verbos del protocolo está identificado a través de la información de situación del final de la URL.
  

Etapas de una transacción HTTP

Cada vez que un cliente realiza una petición a un servidor HTTP, se ejecutan los siguientes pasos:

1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el campo Location del cliente Web.
2. El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.
   
3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.
   
4. Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de información, que incluye datos sobre las capacidades del browser, datos opcionales para el servidor,
   
5. El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información de retorno, seguido de la propia información.
   
6. Se cierra la conexión TCP.
   

Comandos del protocolo

Los comandos o verbos de HTTP representan las diferentes operaciones que se pueden solicitar a un servidor HTTP. El formato general de un comando es:

Nombre del comando Objeto sobre el que se aplica Versión de HTTP utilizada Cada comando actúa sobre un objeto del servidor, normalmente un fichero o aplicación, que se toma de la URL de activación. La última parte de esta URL, que representa la dirección de un objeto dentro de un servidor HTTP, es el parámetro sobre el que se aplica el comando. Se compone de una serie de nombres de directorios y ficheros, además de parámetros opcionales para las aplicaciones CGI.

El estándar HTTP/1.0 recoge únicamente tres comandos, que representan las operaciones de recepción y envío de información y chequeo de estado:

• GET: Se utiliza para recoger cualquier tipo de información del servidor. Se utiliza siempre que se activa un enlace (pulsando) o se teclea directamente a una URL. Como resultado, el servidor HTTP envía el documento correspondiente a la URL seleccionada, o bien activa un módulo CGI, que generará a su vez la información de retorno.
• HEAD: Solicita información sobre un objeto (fichero): tamaño, tipo, fecha de modificación Es utilizado por los gestores de cachés de páginas o los servidores proxy, para conocer cuándo es necesario actualizar la copia que se mantiene de un fichero.
  
• POST: Sirve para enviar información al servidor, por ejemplo los datos contenidos en un formulario. El servidor pasará esta información a un proceso encargado de su tratamiento (generalmente una aplicación CGI). La operación que se realiza con la información proporcionada depende de la URL utilizada. Se utiliza, sobre todo, en los formularios.
  

El envío del contenido de un formulario utiliza GET o POST, en función del atributo de <FORM METHOD="...">. Además, si el cliente Web tiene un caché de páginas recientemente visitadas, puede utilizar HEAD para comprobar la última fecha de modificación de un fichero, antes de traer una nueva copia del mismo.

La última versión de HTTP, denominada 1.1, recoge otras novedades, como los siguientes comandos:

• PUT: Actualiza información sobre un objeto del servidor. Es similar a POST, pero en este caso, la información enviada al servidor debe ser almacenada en la URL que acompaña al comando. Así se puede actualizar el contenido de un documento.
• DELETE: Elimina el documento especificado del servidor.
  
• LINK: Crea una relación entre documentos.
  
• UNLINK: Elimina una relación existente entre documentos del servidor.
  

Las cabeceras de los mensajes HTTP

Son un conjunto de variables que se incluyen en los mensajes HTTP, para modificar su comportamiento o incluir información de interés. En función de su nombre, pueden aparecer en los requerimientos de un cliente, en las respuestas del servidor o en ambos tipos de mensajes. El formato general de una cabecera es:

Nombre de la variable : Cadena ASCII con su valor

Los nombres de variables se pueden escribir con cualquier combinación de mayúsculas y minúsculas. Además, se debe incluir un espacio en blanco entre el signo ": " y su valor. En caso de que el valor de una variable ocupe varias líneas, éstas deberán comenzar, al menos, con un espacio en blanco o un tabulador.

Tipos de Cabeceras

1. Cabeceras comunes para peticiones y respuestas

• Content-Type: descripción MIME de la información contenida en este mensaje. Es la referencia que utilizan las aplicaciones Web para dar el correcto tratamiento a los datos que reciben.
• Content-Length: longitud en bytes de los datos enviados, expresado en base decimal.
  
• Content-Encoding: formato de codificación de los datos enviados en este mensaje. Sirve, por ejemplo, para enviar datos comprimidos (x-gzip o x-compress) o encriptados.
  
• Date: fecha local de la operación. Las fechas deben incluir la zona horaria en que reside el sistema que genera la operación. Por ejemplo: Sunday, 12-Dec-96 12: 21: 22 GMT+01. No existe un formato único en las fechas; incluso es posible encontrar casos en los que no se dispone de la zona horaria correspondiente, con los problemas de sincronización que esto produce. Los formatos de fecha a emplear están recogidos en los RFC 1036 y 1123.
  
• Pragma: permite incluir información variada relacionada con el protocolo HTTP en el requerimiento o respuesta que se está realizando. Por ejemplo, un cliente envía un Pragma: no-cache para informar de que desea una copia nueva del recurso especificado.
  

2. Cabeceras sólo para peticiones del cliente

• Accept: campo opcional que contiene una lista de tipos MIME aceptados por el cliente. Se pueden utilizar * para indicar rangos de tipos de datos; tipo/* indica todos los subtipos de un determinado medio, mientras que */* representa a cualquier tipo de dato disponible.
• Authorization: clave de acceso que envía un cliente para acceder a un recurso de uso protegido o limitado. La información incluye el formato de autorización empleado, seguido de la clave de acceso propiamente dicha. La explicación se incluye más adelante.
  
• From: campo opcional que contiene la dirección de correo electrónico del usuario del cliente Web que realiza el acceso.
  
• If-Modified-Since: permite realizar operaciones GET condicionales, en función de si la fecha de modificación del objeto requerido es anterior o posterior a la fecha proporcionada. Puede ser utilizada por los sistemas de almacenamiento temporal de páginas. Es equivalente a realizar un HEAD seguido de un GET normal.
  
• Referer: contiene la URL del documento desde donde se ha activado este enlace. De esta forma, un servidor puede informar al creador de ese documento de cambios o actualizaciones en los enlaces que contiene. No todos los clientes lo envían.
  
• User-agent: cadena que identifica el tipo y versión del cliente que realiza la petición. Por ejemplo, los browsers de Netscape envían cadenas del tipo User-Agent: Mozilla/3.0 (WinNT; I)

3. Cabeceras sólo para respuestas del servidor HTTP.

• Allow: informa de los comandos HTTP opcionales que se pueden aplicar sobre el objeto al que se refiere esta respuesta. Por ejemplo, Allow: GET, POST.
• Expires: fecha de expiración del objeto enviado. Los sistemas de cache deben descartar las posibles copias del objeto pasada esta fecha. Por ejemplo, Expires: Thu, 12 Jan 97 00: 00: 00 GMT+1. No todos los sistemas lo envían. Puede cambiarse utilizando un en el encabezado de cada documento.
  
• Last-modified: fecha local de modificación del objeto devuelto. Se puede corresponder con la fecha de modificación de un fichero en disco, o, para información generada dinámicamente desde una base de datos, con la fecha de modificación del registro de datos correspondiente. Location: informa sobre la dirección exacta del recurso al que se ha accedido. Cuando el servidor proporciona un código de respuesta de la serie 3xx, este parámetro contiene la URL necesaria para accesos posteriores a este recurso.
  
• Server: cadena que identifica el tipo y versión del servidor HTTP. Por ejemplo, Server: NCSA 1.4.
  
• WWW-Autenticate: cuando se accede a un recurso protegido o de acceso restringido, el servidor devuelve un código de estado 401, y utiliza este campo para informar de los modelos de autentificación válidos para acceder a este recurso.
  

Códigos de estado del servidor

Ante cada transacción con un servidor HTTP, éste devuelve un código numérico que informa sobre el resultado de la operación, como primera línea del mensaje de respuesta. Estos códigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error (en ocasiones se presenta un mensaje de error más elaborado, en forma de documento HTML). El formato de la línea de estado es:

Versión de protocolo     Código numérico de estado     Descripción del código 
HTTP utilizada			(tres dígitos)			numérico

Existen cinco categorías de mensajes de estado, organizadas por el primer dígito del código numérico de la respuesta:

• 1xx : mensajes informativos. en HTTP/1.0 no se utilizan, y están reservados para un futuro uso.
• 2xx : mensajes asociados con operaciones realizadas correctamente.
• 3xx : mensajes de redirección, que informan de operaciones complementarias que se deben realizar para finalizar la operación.
• 4xx : errores del cliente; el requerimiento contiene algún error, o no puede ser realizado.
• 5xx : errores del servidor, que no ha podido llevar a cabo una solicitud.

Por ejemplo:

200 	  OK 		Operación realizada satisfactoriamente. 

404 	  Not 		Found La URL solicitada no existe. 

500     Internal  	El servidor ha tenido un error interno, 
      Server Error      y no puede continuar con el procesamiento.

________

Bueno, eso fue una introducción a los distintos tipos de protocolos, quizás para algun texto posterior se profundice algun tipo de protocolo, se despide momentaneamente ArCanHell o_O xS

arcanhell_jona@hotmail.com