11 EL NIVEL DE APLICACIÓN EN INTERNET
2ª PARTE

11.1 FTP: File Transfer Protocol
11.1.1 Introducción
11.1.2 Comandos de FTP
11.1.3 Protocolo Trivial de Transferencia de Archivos (TFTP).
11.2 TELNET
11.2.1 Introducción.
11.2.2 Modelo de emulación de terminal de telnet.
11.2.3 Características de NVT.
11.2.4 Control de un cliente telnet de texto.
11.3 La World Wide Web.
11.3.1 Introducción.
11.3.2 El lado del cliente.
11.3.3 El lado del servidor.
C: telnet www.uv.es 80
11.3.4 HTTP: Protocolo de transferencia de hipertexto.

11.1 FTP: File Transfer Protocol
11.1.1 Introducción

En un entorno de red, es natural que se quiera copiar archivos entre distintas computadoras. ¿Por qué a veces es tan complicado?. Los fabricantes de computadoras han ideado cientos de sistemas de archivos. Estos sistemas difieren en docenas de detalles menores, y también en unos cuántos detalles importantes. No es sólo un problema de que haya múltiples fabricantes. A veces es difícil copiar archivos entre dos tipos diferentes de computadoras de un mismo fabricante.

Cuando se trabaja en un entorno multsistema pueden aparecer, entre otros, los siguientes problemas:

•	Convenciones diferentes para nombrar los archivos.

•	Reglas diferentes para recorrer los sistemas de directorios.

•	Restricciones de acceso a archivos.

•	Formas diferentes de representar texto y datos dentro de los archivos.

Los diseñadores del conjunto de protocolos de TCP/IP no trataron de crear una solución general muy complicada que resolviera cualquier problema de transferencia de archivos. En lugar de ello, crearon un protocolo de transferencia de archivos llamado FTP (File Transfer Protocol) bastante básico, pero elegante, útil y fácil de usar.

El protocolo de transferencia de archivos FTP fue diseñado para su uso de forma interactiva por usuarios finales o por programas de aplicación. Aquí limitaremos la explicación al servicio de FTP de usuario final interactivo más familiar, disponible en todas las implementaciones de TCP/IP.

La interfaz de usuario desarrollada para el cliente de transferencia de archivos del UNIX de Berkeley se ha implementado en muchos tipos de computadoras multiusuario. Las funciones esenciales de transferencia de archivos permiten a los usuarios copiar archivos de un sistema a otro, ver listados de directorios y realizar tareas normales, como cambiar de nombre o borrar archivos. Esas funciones forman parte del conjunto de protocolos normalizados de TCP/IP.

El protocolo trivial de transferencia de archivos TFTP (Trivial File Transfer Protocol), del que trataremos al final, es un protocolo de transferencia de archivos sencillo que se usa en situaciones especiales como cuando se carga software en encaminadores, puentes o estaciones de trabajo sin disco.

Normalmente los sistemas de computadoras piden al usuario que introduzca un identificador de conexión y una contraseña para poder ver o manipular los archivos. Sin embargo, a veces es útil crear un área pública de archivos. El FTP ofrece dos tipos de servicios para adaptarse tanto al acceso a información pública compartida como al acceso a archivos privados:

•	Acceso a archivos públicos por medio de conexiones “anónimas”.

•	Acceso a archivos privados, restringido a usuarios que poseen un identificador de conexión al sistema y una contraseña.

Veamos un sencillo acceso a los datos públicos de un ordenador:

> ftp glup.irobot.uv.es	El comando ftp hace que comience el programa de la interfaz de usuario del cliente de FTP. El usuario quiere conectarse al ordenador remoto glup.uv.es.
	
Connected to glup.irobot.uv.es.
	El cliente local de FTP avisa que se ha conectado con exito.
	
220 glup.irobot.uv.es FTP server (Version 1.7.111.1 Mon Apr 17 20:26:20 GMT 1995) ready.
	Mensaje de bienvenida del sistema remoto.	
Name (glup.uv.es:quique): anonymous	El cliente local de FTP pide un identificador de usuario. glup.uv.es aceptará anonymous.
	
331 Guest login ok, send ident as password.
Password:
	El cliente local de FTP pide una contraseña. Introducimos la respuesta apropiada, que es nuestro identificador de correo.

230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
	
El cursor ftp> significa ¿Qué quieres hacer ahora?.	
ftp> cd pub	El usuario cambia al directorio remoto pub, que contiene los documentos que desea.
	
250 CWD command successful.	El comando cd se envió al servidor como el comando formal cwd (cambio de directorio de trabajo, change working directory). El directorio en el servidor es ahora pub y ya se puede transferir el documento.

ftp> get Manual.doc MiManual.doc	Se quiere una copia del archivo remoto Manual.doc, dicha copia queremos que reciba el nombre local de MiManual.doc.
	
200 PORT command successful.	El cliente local de FTP ha obtenido un segundo puerto y ha enviado un comando PORT al servidor, diciéndole que se conecte a ese puerto.
	
150 Opening BINARY mode data connection for Manual.doc (1681920 bytes).
	Se abre la conexión de datos para la transferencia de archivos.	
226 Transfer complete.
1681920 bytes received in 1.67 seconds (980.66 Kbytes/s)
	La transferencia ha terminado.	
ftp> quit	Terminamos la sesión.
	
221 Goodbye.		

Como se puede observar del diálogo anterior, un usuario interacciona con un proceso del cliente local de FTP. El software del cliente local entabla una conversación formal con el proceso del servidor remoto de FTP a través de una conexión de control. Cuando el usuario final introduce un comando de transferencia o de gestión de archivos, el comando se traduce a uno de los acrónimos especiales de la conexión de control.

En el fondo, la conexión de control no es más que una simple sesión del NVT de telnet. El cliente envía comandos al servidor a través de la conexión de control y el servidor envía respuestas al cliente a través de la misma.

Si el usuario pide una transferencia de archivos, se abre una conexión de datos independiente y el archivo se copia a través de dicha conexión. También se utilizan conexiones de datos para transmitir los listados de directorios. En la figura siguiente se muestra este modelo. El servidor utiliza normalmente el puerto 20 para su extremo de la conexión de datos.

Figura 11.1: Esquema del funcionamiento de FTP.

Durante el diálogo anterior, el usuario final solicitó un cambio de directorio para copiar un archivo. Esta petición se convirtió en un comando formal de FTP y se envió al servidor remoto de FTP a través de la conexión de control. La transferencia de archivo se realizó por la conexión de datos independiente que se creó al efecto.
11.1.2 Comandos de FTP

¿Qué tipo de comandos se pueden enviar a través de la conexión de control?. Existen diversos tipos de comandos. Los más generales son los comandos de autentificación, que permiten a un usuario declarar el identificador, la contraseña y la cuenta que va a utilizar para un conjunto de actividades de FTP; los comandos de transferencia de archivos, que permiten al usuario copiar uno o varios archivos de un ordenador a otro, añadir un archivo local a un archivo remoto, etc., y los comandos de gestión de archivos, que permiten listar los archivos de un directorio, cambiar el directorio, crear y eliminar directorios, etc. Los comandos que se envían a través de la conexión de control tienen un formato normalizado. Se puede obtener un listado de los comandos admitidos por un servidor ftp mediante el comando help. Por ejemplo:

ftp> help
Commands may be abbreviated.  Commands are:

!            debug        mget         pwd          status
$            dir          mkdir        quit         struct
account      disconnect   mls          quote        system
append       form         mode         recv         sunique
ascii        get          modtime      reget        tenex
bell         glob         mput         rstatus      trace
binary       hash         newer        rhelp        type
bye          help         nmap         rename       user
case         idle         nlist        reset        umask
cd           image        ntrans       restart      verbose
cdup         lcd          open         rmdir        ?
chmod        ls           prompt       runique
close        macdef       proxy        send
cr           mdelete      sendport     site
delete       mdir         put          size
ftp>

El conjunto de comandos de FTP que se puede enviar sobre la conexión de control se resume a continuación. Este conjunto ha ido creciendo regularmente con los años y es bastante amplio. Sin embargo, los ordenadores no tienen por qué implementar todos los comandos que aparecen más adelante.

A veces la interfaz local no dispone directamente del comando que el usuario quiere enviar (pero está disponible en el ordenador remoto). Una buena implementación de FTP dispondrá del comando quote (citar literalmente), que permite escribir el comando formal tal como se quiere enviar. Esa expresión se transmitirá a través de la conexión de control exactamente como fue tecleada. Por tanto, puede resultar de utilidad conocer los comandos formales y sus parámetros. A partir de aquí mostraremos esos comandos en forma de tablas.

Comando	Definición	Parámetro(s)	
USER	Identifica al usuario	Identificador.	
PASS	Suministra una contraseña	Contraseña.	
ACCT	Suministra una cuenta	ID de la cuenta.	
REIN	Reinicializa al estado de comienzo	Ninguno.	
QUIT	Desconexión	Ninguno.	
ABOR	Aborta el comando anterior y la transferencia de datos asociada	Ninguno.	

Tabla 11.1: Comandos de autorización de acceso a archivos.

Comando	Definición	Parámetro(s)	
CWD	Cambia a otro directorio del servidor	Nombre de directorio.	
CDUP	Cambia al directorio padre	Ninguno.	
DELE	Borra un archivo	Nombre de archivo	
LIST	Lista información de archivos	Nombre de directorio, listado de archivos. Ninguno si se trata del directorio de trabajo	
MKD	Crea un directorio	Nombre de directorio	
NLST	Lista de archivos de un directorio	Nombre de directorio o ninguno para el directorio de trabajo	
PWD	Imprime el nombre del directorio de trabajo	Ninguno	
RMD	Elimina un directorio	Nombre de directorio	
RNFR	Identifica un archivo para cambiarlo de nombre	Nombre de archivo	
RNTO	Cambia de nombre un archivo	Nombre de archivo	
SMNT	Monta un sistema de archivos diferente	Identificador	

Tabla 11.2: Comandos de gestión de archivos y directorios.

Comando	Definición	Parámetro(s)	
TYPE	Identifica el tipo de datos y, opcionalmente, el formato de impresión, si existe, para la transferencia	A (ASCII), E (EBCDIC), I (Imagen binaria), N (No-impresión), T (telnet), C (ASA)	
STRU	Organización del archivo	F (archivo, file) o R (registro)	
MODE	Formato de transmisión	S (flujo, stream), B (bloque), C (comprimido)	

Tabla 11.3: Comandos que define el tipo, la estructura y el modo.

Comando	Definición	Parámetro(s)	
ALLO	Reserva (Allocate) espacio suficiente para los datos que siguen	Número entero de bytes	
APPE	Añade (Append) un archivo local a uno remoto	Nombres de los archivos	
PASV	Pide al servidor que identifique una dirección de IP y un puerto para que el cliente inicie una sesión de datos	Ninguno. El servidor devolverá una dirección de IP y un número de puerto.	
PORT	Identifica una dirección de red y un puerto para que el servidor inicie una conexión de datos	Dirección de IP y número de puerto	
REST	Identifica un marcador de reinicio (restart marker), seguido del comando de transferencia que hay que reiniciar	Valor del marcador	
RETR	Recupera (retrieve) un archivo	Nombre(s) de archivo(s)	
STOR	Guarda (store) un archivo	Nombre(s) de archivo(s)	
STOU	(Store unique): crea una versión de un archivo con un nombre único	Nombre de archivo	

Tabla 11.4: Comandos que realizan la transferencia de archivos.

Comando	Definición	Parámetro(s)	
HELP	Devuelve información sobre la implementación del servidor	Ninguno	
NOOP	Pide al servidor que responda <<OK>>	Ninguno	
SITE	Usado para subcomandos específicos del servidor que no forman parte del estándar, pero se pueden necesitar para ese servidor	Ninguno	
SYST	Pide al servidor que identifique su sistema operativo	Ninguno	
STAT	Solicita información sobre los parámetros y estado de la conexión	Ninguno	

Tabla 11.5: Otros comandos de información al usuario.

11.1.3 Protocolo Trivial de Transferencia de Archivos (TFTP).

Existen aplicaciones para copiar archivos que requieren un nivel de funcionalidad muy sencillo. Por ejemplo, el volcado inicial de software y archivos de configuración al arrancar un encaminador, un concentrador o una estación de trabajo sin disco se realiza mejor utilizando un protocolo que sea muy sencillo.

El protocolo trivial de transferencia de archivos ha demostrado ser de gran utilidad para el copiado básico de archivos entre computadoras. TFTP transfiere datos utilizando datagramas de UDP. El sistema que participa de un volcado de TFTP necesita ejecutar muy poco software de comunicaciones (sólo IP y UDP). TFTP ha demostrado ser de gran utilidad para inicializar dispositivos de red como encaminadores, puentes y concentradores.

El protocolo trivial de transferencia de archivos:

•	Envía bloques de datos de 512 octetos (excepto el último).

•	Añade una cabecera sencilla de 4 octetos a cada bloque de datos.

•	Numera los bloques empezando por 1.

•	Admite transferencia de octetos ASCII o binarios.

•	Se puede utilizar para leer o escribir un archivo remoto.

•	No contempla la autenticación del usuario.

En una interacción TFTP, un interlocutor envía bloques de datos numerados de tamaño uniforme y el otro interlocutor confirma (ACK) los datos según van llegando. El emisor tiene que esperar el ACK de un bloque antes de enviar el siguiente. Si no se recibe un ACK dentro de un plazo determinado se vuelve a enviar el bloque afectado. De forma similar, si el receptor no recibe datos durante un plazo determinado, retransmite un ACK.

Una sesión de TFTP comienza con una petición de lectura (Read Request) o con una petición de escritura (Write Request). El cliente TFTP comienza obteniendo un puerto, enviando a continuación el mensaje de petición de lectura o de petición de escritura al puerto 69 del servidor. Entonces el servidor identifica un puerto diferente para el resto de la transferencia de archivos. El servidor dirige sus mensajes al puerto del cliente. La transferencia de datos se realiza intercambiando bloques de datos y ACK.

Todos los bloques deben contener 512 octetos de datos, excepto el último, lo que sirve para señalar el fin de archivo. Si el tamaño del archivo es múltiplo de 512, el último bloque consta sólo de cabecera, sin datos. Los bloques de datos van numerados, empezando por 1. Cada ACK contiene el número de bloque de los datos que está confirmando. Hay cinco tipos de unidades de datos de protocolo:

•	Petición de lectura (RRQ - Read Request).

•	Petición de escritura (WRQ - Write Request)

•	Datos (DATA).

•	Confirmación (ACK - Acknowledgement)

•	Error (ERROR)

Los mensajes de error indican condiciones como “archivo no encontrado” o “falta de espacio para escribir el archivo en el disco”.

Cada cabecera de TFTP empieza con un código de operación que indica el tipo de unidad de datos de protocolo (PDU - Protocol Data Unit). El formato de las PDU se muestra a continuación:

Figura 11.2: Formato de las PDUs en TFTP.

Observe que el tamaño de las peticiones de lectura y de las peticiones de escritura varía dependiendo del tamaño de los campos de nombre de archivo y modo, que contienen cada uno una cadena de texto ASCII seguida de un byte todo a 0. El campo modo contiene <<netascii> (ASCII neto) u <<octet>> (octeto).

11.2 TELNET

11.2.1 Introducción.
¿De que sirve una red con una rica oferta en aplicaciones si los usuarios no pueden acceder a distintas computadoras y usar sus aplicaciones?. TCP ofrece la posibilidad de conexión entre computadoras, pero existen otros problemas. Durante mucho tiempo dio la impresión de que cada fabricante de computadoras estaba decidido a lanzar al mercado un entorno totalmente propietario. Sólo se podía acceder a una aplicación en el ordenador del fabricante desde terminales especiales manufacturados por él mismo.

El protocolo telnet (terminal networking) vence las diferencias entre fabricantes y permite a un usuario, conectado a un ordenador de una red, conectarse a cualquier otro ordenador. La emulación de terminal de telnet fue la primera aplicación de TCP/IP. El protocolo telnet se diseñó, además, como base para comunicaciones entre aplicaciones en general. Conforme las organizaciones se han ido alejando de la herencia de las aplicaciones basadas en terminal, se ha usado cada vez más telnet como herramienta para la creación de las aplicaciones cliente/servidor. De hecho, telnet es el soporte de las interacciones cliente/servidor en la transferencia de archivos, el correo electrónico y la World Wide Web (WWW).

Telnet permite la emulación de varios tipos de terminal, por lo que se puede acceder a computadoras UNIX, sistemas VAX/VMS o grandes computadoras de IBM. Algunas implementaciones de telnet disponen de procedimientos especiales de autentificación, como Kerberos, de forma que las contraseñas nunca van por la red y se utiliza un procedimiento especial de autentificación cifrada.

Si se ejecuta telnet desde un sistema multiusuario, probablemente se manejará una sencilla interfaz de usuario de texto. La utilización de un cliente telnet de texto es muy fácil. Basta con teclear:

> telnet <nombre del ordenador>

A menudo, la emulación del terminal IBM 3270 se suministra por separado y se accede a los hosts de IBM tecleando:

> tn3270 <nombre del ordenador>

La mayoría de la gente consigue utilizar telnet sin necesidad de saber nada más. A continuación se muestra una conexión a faeton.irobot.uv.es desde otra computadora.

> telnet faeton.irobot.uv.es
Trying...
Connected to faeton.irobot.uv.es.
Escape character is '^]'.
Local flow control on
Telnet TERMINAL-SPEED option ON

IRIX (faeton)

login: <nombre del usuario>
Password: 
IRIX Release 6.2 IP25 faeton
Copyright 1987-1996 Silicon Graphics, Inc. All Rights Reserved.
Last login: Wed Oct 14 12:00:47 PDT 1998 on :0

El puerto 23 es el puerto público normalizado para el terminal virtual de telnet. Cuando un cliente se conecta al puerto 23, la respuesta normal es un cursor para introducir un identificador de conexión y una contraseña. Pero, telnet se diseño como herramienta general de comunicaciones entre aplicaciones, por lo que incluye la posibilidad de conectar el cliente a cualquier puerto. Por ejemplo, en el diálogo que aparece a continuación se produce una conexión a un servidor de correo (popper) que funciona en el puerto 110.

> telnet post.uv.es 110
Trying...
Connected to gong.ci.uv.es.
Escape character is '^]'.
+OK gong POP3 Server (Version 2.5-UV) ready.
quit /* Comando tecleado para terminar la conexión */
+OK gong POP3 Server (Version 2.5-UV) shutdown.
Connection closed by foreign host.

La posibilidad de acceder con telnet a cualquier puerto ha demostrado ser muy conveniente. Sin embargo, se ha convertido en una potencial fuente de problemas de seguridad cuando los piratas informáticos invaden un lugar a través de un programa deficiente, que se ejecuta en algún puerto sin restricciones.
11.2.2 Modelo de emulación de terminal de telnet.

Como se muestra en la figura siguiente, un usuario de un terminal real interacciona con el programa cliente de telnet local. El programa cliente de telnet tiene que aceptar las pulsaciones del teclado del usuario, interpretarlas y mostrar la salida en la pantalla del usuario de forma consistente con la emulación en uso.

Figura 11.3: Esquema del funcionamiento de telnet.

El cliente telnet abre una conexión de TCP con el servidor telnet, al que se accede por el puerto público 23. El servidor telnet interacciona con las aplicaciones y asiste en la emulación de un terminal nativo.

Para conseguir iniciar una sesión, ambos extremos intercambian información utilizando un protocolo muy sencillo llamado terminal virtual de red NVT (Network Virtual Terminal). El protocolo de NVT se modeló en un antiguo teclado semidúplex y una impresora funcionando línea a línea. NVT posee unas características bien definidas:

•	Los datos del NVT se componen de caracteres USASCII de 7 bits aumentados a 8 bits por medio de un 0 inicial.

•	Los datos se envían línea a línea.

•	Cada línea termina con una combinación de caracteres ASCII de retorno de carro (CR - Carriage Return) y salto de línea (LF - Linefeed).

•	Los bytes cuyo bit inicial (más significativo) es 1 se usan para códigos de comandos.

•	El protocolo es semidúplex. Después de enviar una línea, el cliente espera hasta recibir una línea del servidor. El servidor envía sus datos y, a continuación, un comando <<Adelante>> (Go Ahead), indicando al cliente que ya puede enviar otra línea.

Normalmente el cliente y el servidor permanecen en modo NVT muy poco tiempo, lo necesario para negociar el tipo de terminal a emular, como un ASCII VT100 o un IBM 3270. En los años transcurridos desde que se introdujo telnet, se han añadido muchas emulaciones de terminal al protocolo. Las emulaciones más normales son las de terminales ASCII y las de terminales IBM 3270 y 5250.

Los terminales ASCII se usan con computadoras UNIX y VAX. Los terminales ASCII se caracterizan por:

•	Eco remoto de cada carácter. Esto es, cada carácter se envía al ordenador remoto y se reenvía de vuelta antes de aparecer en la pantalla del usuario. Es muy duro para la red.

•	Transmisión dúplex. Los caracteres viajan en las dos direcciones simultáneamente. El servidor no necesita enviar códigos de control de <<Adelante>>.

•	Soporte para aplicaciones interactivas de pantalla completa (con mucha carga de red).

•	Conjunto de caracteres ASCII mayor que el de NVT.

Las características básicas de los terminales ASCII se definen en las normas ANSI X3.64, ISO 6429 y ISO 2022. Han existido muchos productos de terminal ASCII, cada uno de ellos con alguna función extra (por ejemplo, ANSI, VT52, VT100, VT220, TVI950, TVI955, y WYSE50). A menudo, el tipo de terminal VT100 es el que se emula para las conexiones remotas a computadoras UNIX.

A diferencia de los terminales ASCII, los terminales de IBM estan optimizados para aplicaciones de procesado de datos que operaban en “modo de bloque”, lo que significa que un usuario trabaja con una pantalla de datos cada vez. Cuando el usuario pulsa INTRO u otra tecla de función, se envía al ordenador la información de la pantalla. El teclado se bloquea y el ordenador procesa los datos. A continuación el ordenador envía de vuelta una o más pantallas de datos. Cuando el ordenador termina, desbloquea el teclado. Los 3270 se caracterizan por:

•	Códigos EBCDIC de 8 bits.

•	Comunicación semidúplex.

•	Modo de bloque.

Los terminales IBM 5250, para acceder a computadoras AS/400, también tienen esas características.

Las características de emulación de terminal se establecen intercambiando comandos que negocian opciones telnet. Cualquiera de los extremos puede pedir a su corresponsal que realice (DO) un opción en particular, como <<hacer eco de caracteres individuales>>. El corresponsal puede aceptar o rehusar. Cualquiera de los extremos puede ofrecerse para realizar (WILL) alguna opción. De nuevo, el corresponsal puede aceptar o no. Existen cuatro intercambios petición/respuesta que suelen ocurrir durante la negociación de opciones:

Opción.	Descripción.	
DO (código de opción)	Pide al corresponsal que acepte una opción.	
WILL	El corresponsal acepta. Ahora la opción se realiza.	
DO	Pide al corresponsal que acepte una opción.	
WON’T	El corresponsal rehusa. El estado no cambia.	
WILL	Indica el deseo de comenzar una opción.	
DO	El corresponsal da permiso. Ahora la opción se realiza.	
WILL	Indica el deseo de comenzar una opción.	
DON’T	El corresponsal rehusa. El estado no cambia.	
WON’T	Confirma que el estado no va a cambiar.	

Tabla 11.6: Opciones de la negociación de una conexión telnet.

Al inicio de la conexión, hay muchas peticiones de opciones que van y vuelven entre los interlocutores. A veces, también se intercambian opciones en mitad de una sesión. Algunas opciones señalan el comienzo de subnegociaciones, en las cuales se intercambia información adicional. ¿Qué ocurre si ambas partes rechazan todas las peticiones de opciones?. La sesión se mantendrá en modo NVT.

Hay una opción muy importante, tipo de terminal, que utiliza subnegociación. Un cliente que envía WILL TERMINAL TYPE quiere indicarle al servidor los tipos de terminal que puede emular. Si el servidor está dispuesto a ver esta información, responde con DO TERMINAL TYPE.

Posteriormente, en una subnegociación, el servidor pide al cliente que indique uno de los tipos de terminal que puede emular y el cliente responde. El servidor puede repetir la petición hasta que, o bien el cliente proporciona un tipo que es aceptable para el servidor, o bien la lista de tipos disponibles por el cliente se termina. Los identificadores formales de tipo de terminal como DEC-VT100, HP-2648 o IBM-3278-2 se definen en el documento RFC (Assigned Numbers).

La peticiones de opciones de negociación y subnegociación se codifican con tres bytes: un código de IAC, un octeto de petición y un código de opciones. Por ejemplo, la representación de la secuencia para WILL TERMINAL TYPE es: 0xFF 0xFB 0x18. En las tablas siguientes se muestran los códigos de negociación y subnegociación y. los números de código asociados a algunas de las opciones más utilizadas.

Petición de negociación	Código	
WILL	251	
WON’T	252	
DO	253	
DON’T	254	
SB Start subnegotiation (Inicio de subnegociación)	250	
SE End Subnegotiation (Fin de subnegociación)	240	

Tabla 11.7: Codificación de las peticiones de negociación de una conexión telnet.

Códigos de opción del comando	Código	
Transmit Binary (Transmitir en binario)	0	
Echo (Eco)	1	
Suppress Go Ahead (Suprime Adelante)	3	
Status (Estado)	5	
Timing Mark (Marca de tiempo)	6	
Output Line Width (Ancho de línea de salida)	8	
Output Page Size (Tamaño de página de salida)	9	
Extended ASCII (ASCII extendido)	17	
Data Entry Terminal (Terminal de entrada de datos)	20	
Terminal Type (Tipo de terminal)	24	
End of Record (Fin de registro)	25	
Window Size (Tamaño de ventana)	31	
Terminal Speed (Velocidad del terminal)	32	
Remote Flow Control (Control de flujo remoto)	33	
Linemode (Modo de línea)	34	
Authentication (Autenticación)	37	
Encryption (Cifrado)	38	
Extended Options List (Lista extendida de opciones)	255	

Tabla 11.8: Códigos de opciones de una conexión telnet.

Se han escrito más de 30 RFC que detallan opciones para definir características especializadas. Algunas opciones interesantes incluyen:

•	La capacidad de sondear al corresponsal para saber los parámetros de la opción actual. Se envía una petición de estado y se recibe una respuesta por medio de una subnegociación.

•	La negociación del tamaño de la ventana. Los corresponsales acuerdan que el cliente puede realizar una subnegociación para informar al servidor del alto y ancho de la ventana que se va a usar para la sesión de telnet. Esta característica es útil cuando se ejecuta una sesión de telnet en una estación basada en ventanas.

No es necesario que una implementación permita todas, ni siquiera la mayoría, de las opciones definidas. Dos de las opciones que se utilizan para la emulación del 3270 tienen características especiales:

•	Transmitir en binario (Transmit Binary). Comenzar a transmitir datos binarios de 8 bits. Recuerde que las sesiones del 3270 de IBM se realizan en binario.

•	Fin de registro (End of Record). El interlocutor que recibe la orden de fin de registro (DO END-OF-RECORD) usará un código de control estándar de IAC 239 para señalar un fin de registro de flujo de datos.

Recuerde que, incluso después de pasar a modo binario, se pueden enviar los comandos de telnet al interlocutor duplicando los caracteres de escape de IAC.

En el diálogo de ejemplo que aparece a continuación, se ejecuta telnet y se introduce toggle options para hacer que telnet nos muestre sus negociaciones. Entonces se usan open para iniciar una conexión. Los interlocutores negocian una emulación ASCII VT100 seleccionando las siguientes características:

•	El servidor no enviará adelante (Go Ahead) porque la sesión será dúplex.

•	Se utilizara una subnegociación del tipo de terminal, velocidad de transferencia, para indicar el tipo concreto de terminal ASCII a emular.

•	El servidor hará eco de los caracteres del cliente.

Ninguna de las partes necesita esperar una respuesta a una petición de opción antes de enviar otra petición. Ni siquiera un negociador tiene que responder a las opciones en el mismo orden en que las recibió. Como resultado, a veces para entender una serie de negociaciones hay que desenredarla.

> telnet
telnet> toggle options
Will show option processing.
telnet> open faeton.irobot.uv.es
Trying...
Connected to faeton.irobot.uv.es.
Escape character is '^]'.
SENT do SUPPRESS GO AHEAD
SENT will TERMINAL TYPE (don't reply)
SENT will TERMSPEED (don't reply)
SENT will LFLOW (don't reply)
SENT will NAWS (don't reply)
RCVD do TERMINAL TYPE (don't reply)
RCVD do TERMSPEED (don't reply)
RCVD do 35 (reply)
SENT wont 35 (don't reply)
RCVD do 36 (reply)
SENT wont 36 (don't reply)
RCVD will SUPPRESS GO AHEAD (don't reply)
RCVD do LFLOW (don't reply)
Local flow control on
RCVD do NAWS (don't reply)
Sent suboption NAWS 0 0 (0) 0 0 (0)
Telnet TERMINAL-SPEED option ON
Received suboption TERMINAL-SPEED SEND ?0?Sent suboption TERMINAL-SPEED IS 19200
,19200ÿðReceived suboption Terminal type - request to send.
RCVD do ECHO (reply)
SENT wont ECHO (don't reply)
RCVD will STATUS (reply)
SENT dont STATUS (reply)
RCVD will ECHO (reply)
SENT do ECHO (reply)

IRIX (faeton)

login:
11.2.3 Características de NVT.

Después de completar la negociación de opciones, una emulación de terminal particular puede proporcionar un abundante repertorio de caracteres y símbolos gráficos para la interacción entre un usuario y una aplicación, abandonando el modo de terminal NVT. Sin embargo, cuando se usa telnet para construir aplicaciones cliente/servidor, a menudo la mayoría o todas las interacciones ocurren simplemente en modo NVT. Por lo cual, es interesante resaltar las características de una sesión NVT.

Los octetos que se envían en una sesión NVT representan caracteres USASCII y comandos de telnet. Existe 128 caracteres USASCII, 95 son letras, números, símbolos y signos de puntuación imprimibles; 33 son caracteres ASCII de control, como el tabulador horizontal. USASCII se diseñó como un conjunto de códigos de 7 bits. Los caracteres USASCII se transmiten como octetos con el bit más significativo a 0.

Durante una sesión básica NVT, el servidor de telnet envía caracteres y controles a la impresora de NVT del cliente, es decir, a la pantalla del usuario. La pantalla de NVT sólo puede mostrar los 95 caracteres USASCII imprimibles, que se corresponden con los caracteres ASCII del 32 al 126.

El servidor puede usar un pequeño repertorio de caracteres ASCII de control para manipular la pantalla del cliente. Este repertorio puede verse en la tabla siguiente.

Descripción	Código ASCII	
Nulo (Null) (para tiempo de relleno)	0	
Timbre (Bell), emite una señal audible	7	
Retroceso (Backspace), mover un espacio a la izquierda	8	
Tabulador horizontal (Horizontal tab)	9	
Salto de línea (Line feed)	10	
Tabulador vertical (Vertical tab)	11	
Salto de página (Form feed) (salta al comienzo de la página siguiente)	12	
Retorno de carro (Carriage return)	13	

Tabla 11.9: Juego de caracteres de ASCII de control de una sesión NVT.

Recuerde que una interacción de NVT es semidúplex, lo que significa que, en un momento dado, o bien el cliente de telnet o bien el servidor de telnet está al mando:

•	En cuanto el cliente de telnet envía una línea terminada con CR y LF, el control pasa al servidor.

•	El servidor envía líneas de salida al cliente. Al final de cada línea de salida, el servidor utiliza CR y LF para pasar a la siguiente línea de la pantalla del cliente.

•	El cliente de telnet acepta la salida del servidor y puede volver a introducir una entrada después de recibir del servidor la secuencia de códigos de control adelante (Go Ahead).

Observe que las líneas que se envían a través de la sesión de telnet terminan con CR LF, independientemente de lo que usen los ordenadores cliente y servidor como caracteres locales de fin de línea. Cada ordenador traduce sus caracteres de fin de línea a, y desde, los caracteres de fin de línea de telnet.

11.2.4 Control de un cliente telnet de texto.

En ciertas ocasiones, es necesario interaccionar con un cliente telnet para establecer o mostrar sus parámetros. Podemos obtener información de nuestra implentación ejecutando telnet y tecleando <<?>> o <<help>> para averiguar los comandos locales.

>telnet
telnet> ?
Commands may be abbreviated.  Commands are:

close           close current connection
display         display operating parameters
mode            try to enter line-by-line or character-at-a-time mode
open            connect to a site
quit            exit telnet
send            transmit special characters ('send ?' for more)
set             set operating parameters ('set ?' for more)
status          print status information
toggle          toggle operating parameters ('toggle ?' for more)
z               suspend telnet
!               shell escape
?               print help information
telnet>

¿Cómo puede cambiar un usuario las características de una sesión activa o abortar una sesión?. Siempre se reserva una secuencia de control del teclado que significa salida al modo de comandos de telnet. La secuencia de escape por defecto habitual es CONTROL y ], que se suele representar por ^]. Esta secuencia de escape la puede definir el usuario. Observe el comentario que aparece en la última conexión realizada a faeton.irobot.uv.es en la tercera línea:

Escape character is '^]'.

Continuemos el diálogo a partir de este punto. Después de introducir la secuencia de escape, aparece un cursor de telnet y podemos observar el estado de la sesión actual, los atributos, etc. Después de ejecutar un comando, se vuelve de forma automática al modo de emulación de terminal. Por ejemplo, si en la conexión a faeton.irobot.uv.es introducimos la secuencia de escape y preguntamos el estado de la sesión (status), obtenemos:

telnet> status
Connected to faeton.irobot.uv.es.
Operating in character-at-a-time mode.
Escape character is '^]'.

Antes de que las redes fueran algo habitual, los terminales se unían directamente a las computadoras. El sistema operativo de la computadora interpretaba inmediatamente las teclas que había pulsado el usuario.

Había algunas teclas especiales de control que hacían que el sistema operativo despertara y se diera cuenta. Por ejemplo, un usuario de un terminal ASCII podía pulsar las teclas CONTROL y C a la vez, escrito ^C, para pedir al sistema operativo que terminase la aplicación que se estaba ejecutando.

Durante una sesión de telnet, es necesario traducir los códigos de control a comandos de telnet y pasarlos al sistema operativo del extremo remoto de la conexión de red. Por lo tanto, el programa cliente de telnet tiene que manejar en bruto todas las teclas pulsadas por el usuario, traducir las teclas especiales de control a comandos de telnet y pasar estos comandos al servidor de telnet.

Los comandos de telnet se representan como un byte de “interpretar como comando” (IAC - Interpret As Command), seguido de uno o más bytes de código. El byte “interpretar como comando” es 0xFF, o en decimal, 255.

El cliente de telnet envía secuencias de comandos al servidor para realizar funciones útiles, como puede verse en la figura siguiente:

Comando.	Descripción.	
Pausa (BRK)	Envía una pausa o señal de atención al proceso de la aplicación remota.	
Interrumpir proceso (IP)	Indica al sistema operativo remoto que detenga el programa de la aplicación remota que está en ejecución, por ejemplo, para detener un programa que está en un bucle.	
Abortar la salida (AO)	Pide a la aplicación del servidor que no envíe el resto de la salida de la operación actual.	
¿Estás ahí? (AYT)	Solicita al servidor que muestre una indicación de que el servidor continúa en funcionamiento.	
Borrar carácter (EC)	Un usuario que teclea un carácter erróneo al escribir una línea de datos normalmente lo corrige utilizando la tecla de retroceso (Backspace) o de borrado (Del). Al operar en modo ASCII carácter a carácter, los caracteres ya se han enviado a la aplicación remota, por lo que debe enviarse el comando EC a través de la conexión.	
Borrar línea (EL)	Pide a la aplicación remota que borre la línea actual.	
Tab1a 11.10: Secuencias de comandos del cliente telnet al servidor.

Se pueden enviar los comandos incluso después de la negociación, cuando los interlocutores ya no están en modo NVT básico. Pero supongamos que la negociación permite a los interlocutores enviar datos binarios. ¿Cómo se puede reconocer una secuencia de comandos? La forma de hacerlo consiste en que cada vez que aparece 0xFF como dato, el emisor lo duplica. El receptor elimina el duplicado. Cuando el receptor ve llegar un único 0xFF, o un número impar de ellos, detecta que se trata de un comando.

Resulta sencillo ver lo útiles que pueden ser los comandos de telnet para el desarrollo de productos cliente/servidor. Por ejemplo, el resultado de pulsar el botón STOP de un editor de Web podría ser el envío de un comando Abortar la salida, para detener la carga de una imagen muy grande o de un documento muy extenso.

Por cierto, lo más sencillo para entender las posibilidades de telnet es pensar en un usuario final trabajando en el lado del cliente y una aplicación en el lado del servidor. Pero es importante destacar que cuando se usa telnet como herramienta de desarrollo, pueden enviarse comandos en ambas direcciones.

Sin embargo, para algunas funciones, como interrumpir proceso, el hecho de introducir un comando dentro del flujo de datos no sirve para resolver el problema. Cuando una terminal real envía una interrupción, el sistema operativo del ordenador la detecta de inmediato. El ordenador detiene enseguida la aplicación que se ejecuta en ese momento. Pero telnet se ejecuta sobre una sesión de TCP que entrega los datos en orden. Y, normalmente, el servidor remoto de telnet procesa todos los datos que recibe también en orden. Puede pasar algún tiempo antes de que el servidor de telnet vea el comando de interrupción escondido en el flujo de datos de entrada.

El cliente quiere captar la atención del servidor y decirle “Elimina todos los caracteres que no sean comandos y tengas almacenados hasta este momento”. El cliente indica al servidor que lo haga enviando un segmento especial de TCP denominado señal de sincronismo (Synch signal).

•	Este segmento aparece etiquetado como de datos urgentes.

•	El servidor eliminará todo lo que no sean comandos hasta que le llega un código especial de comando llamado de marca de datos (DM- Data Mark).

•	Una DM indica el punto en que el servidor deja de eliminar datos.

Cuando llega el segmento de señal de sincronismo, el servidor extrae del flujo de datos los comandos de NVT y desecha el resto, hasta que llega la marca de datos. El servidor ejecuta los comandos de NVT. Después de la marca de datos, continúa el funcionamiento normal. En la tabla siguiente puede verse la lista de acrónimos de los comandos más comunes, todos ellos van precedidos del valor 255 (0xFF) cuando se envían a través de la conexión de telnet.

Acrónimo	Comando	Código	
EOF	End Of File (Fin de archivo)	236	
SUSP	Suspend Current Process (Suspender proceso en curso)	237	
ABORT	Abort Process (Abortar proceso)	238	
EOR	End Of Record (Fin de registro)	239	
NOP	No Operation (Sin operación)	241	
DM	Data Mark (Marca de datos)	242	
BRK	Break (Pausa)	243	
IP	Interrupt Process (Interrumpir proceso)	244	
AO	Abort Output (Abortar la salida)	245	
AYT	Are You There (¿Estás ahí?)	246	
EC	Erase Character (Borrar carácter)	247	
EL	Erase Line (Borrar línea)	248	
GA	Go Ahead (Adelante)	249	

Tabla 11.11: Acrónimos de los comandos más comunes en una conexión telnet.

11.3 La World Wide Web.
11.3.1 Introducción.

La World Wide Web (WWW) es una armazón arquitectónico para acceder a documentos vinculados distribuidos en miles de máquinas de toda la Internet; en cinco años pasó de ser una manera de distribuir datos sobre física de alta energía a la aplicación que millones de personas piensan que es “Internet”. La Web comenzó en 1989 en el CERN, el Centro Europeo de Investigación Nuclear. El CERN lleva a cabo investigaciones sobre física de partículas con científicos de diversos países europeos. Estas investigaciones involucran a equipos formados por personas de media docena de países o más. La mayoría de los experimentos son altamente complejos y requieren años de planteamiento y construcción de equipo. La Web surgió por la necesidad de lograr que estos grandes conjuntos de investigadores dispersos internacionalmente colaboraran usando un conjunto siempre cambiante de informes, planos, dibujos, fotos y otros documentos.

La propuesta inicial de una red (web) de documentos vinculados surgió del físico del CERN Tim Berners-Lee en marzo de 1989. El primer prototipo (basado en texto) estaba en operación 18 meses después. En diciembre de 1991 se hizo una demostración pública en la conferencia Hypertext’91 en San Antonio, Texas. El desarrollo continuó durante el siguiente año, culminando con la liberación de la primera interfaz gráfica, Mosaic, en febrero de 1993.

Mosaic tuvo tanto éxito que, un año después, su autor, Marc Andreeseen, dejó el Centro Nacional de Aplicaciones de Supercómputo, donde se desarrolló Mosaic, para formar una compañía, Netscape Communications Corp., cuya meta fue desarrollar clientes, servidores y otros tipos de software de la Web. Cuando Netscape se volvió pública en 1995, los inversionistas, pensando que esta era la siguiente Microsoft, pagaron 1.500 millones de dólares por las acciones. Esta marca fue aún más sorprendente porque la compañía sólo tenía un producto, operaba con grandes pérdidas y había anunciado en su prospecto que no esperaba tener ganancias en un futuro cercano.

En 1994, el CERN y el M.I.T. firmaron un acuerdo para establecer el World Wide Web Consortium, una organización dedicada al desarrollo de la Web, la estandarización de protocolos y el fomento de interoperabilidad entre las instalaciones. Berners-Lee se convirtió en el director. En las secciones siguientes describiremos la Web desde el punto de vista del cliente y del servidor. Después veremos una introducción a los lenguajes de escritura de páginas Web (HTML, Java y JavaScript).

11.3.2 El lado del cliente.

Desde el punto de vista del usuario, la Web consiste en un enorme conjunto a nivel mundial de documentos, llamados páginas. Cada página puede contener vínculos (apuntadores) con otras páginas relacionadas en cualquier lugar del mundo. Los usuarios pueden seguir un vínculo (por ejemplo, haciendo clic en él), lo que los lleva a la página apuntada. Este proceso puede repetirse indefinidamente. Las páginas que apuntan unas a otras páginas usan hipertexto.

Las páginas se ven mediante un programa llamado visor, navegador o browser. Los dos más extendidos son Netscape y Explorer. El visor obtiene la página solicitada, interpreta el texto y los comandos de formateo que contiene y exhibe la página, adecuadamente formateada, en la pantalla. Un ejemplo de página Web puede verse a continuación:

Figura 11.4: Ejemplo de página web: www.uv.es

Al igual que la mayoría de páginas Web, está comienza con un título y contiene cadenas de texto que son vínculos a otras páginas, llamadas hipervínculos (hyperlinks). Estas cadenas se resaltan, ya sea mediante subrayado, presentación en color especial, o ambas cosas. Para seguir un vínculo, el usuario coloca el cursor en el área resaltada (usando el ratón o las teclas de flechas) y la selecciona (haciendo clic con un botón del ratón o pulsando ENTER). La mayoría de los visores tienen botones y características que simplifican la navegación en la Web. Muchos tienen un botón para regresar a la página anterior, un botón para avanzar a la pagina siguiente y un botón para ir directamente a la página base del usuario. Las páginas también pueden almacenarse en disco o imprimirse. Generalmente existen opciones disponibles para controlar la distribución de la pantalla y ajustar varias preferencias del usuario.

Además de texto normal (no subrayado) e hipertexto (subrayado), las páginas de la Web pueden contener iconos, dibujos de líneas, mapas y fotografías. Cada uno de estos puede vincularse (opcionalmente) con otra página. Hacer clic en uno de estos elementos causa que el visor traiga la página vinculada y la exhiba, igual que ocurre con el texto. En el caso de imágenes como fotografías y mapas, la página que se trae a continuación puede depender de la parte de la imagen en la que se hizo clic.

No todas las páginas pueden visualizarse de manera convencional. Por ejemplo, algunas páginas consisten en pistas de audio, fragmentos de vídeo, o ambas cosas. El resultado de mezclar páginas de hipertexto con otros medios se llama hipermedia. Algunos visores pueden presentar todos los tipos de hipermedia, pero otros no; en vez de ello, revisan un archivo de configuración para ver la manera de manejar los datos recibidos. Normalmente, el archivo de configuración indica el nombre de un programa, llamado visor externo o aplicación ayudante, que se ejecutará con la pagina como entrada. Si no hay un visor configurado, el visor generalmente le pide al usuario que escoja uno.

11.3.3 El lado del servidor.

Cada instalación de la Web tiene un proceso servidor que escucha el puerto TCP 80, esperando conexiones entrantes de los clientes (normalmente visores). Tras establecerse una conexión, el cliente envía una solicitud y el servidor envía una respuesta. Después se libera la conexión. El protocolo que define las solicitudes y respuestas legales se llama HTTP y lo estudiaremos con detalle a continuación. Un ejemplo sencillo de uso puede proporcionar una idea razonable sobre el funcionamiento de los servidores de la Web. Veamos la figura siguiente:

Figura 11.5: Esquema de funcionamiento del WWW.

Supongamos que el usuario acaba de hacer clic en alguna parte del texto o en un icono que apunta a una página cuyo nombre URL (Uniform Resource Locator) sea http://www.uv.es/index.html. Los pasos que se ejecutan entre el clic del usuario y la presentación de la página son los siguientes:

1.	El visualizador determina el URL.
2.	El visualizador solicita al DNS la dirección IP de www.uv.es
3.	El DNS contesta con 147.156.1.46.
4.	El visualizador establece una conexión TCP con el puerto 80 de 147.156.1.46.
5.	A continuación, el visualizador emite un comando GET /index.html HTTP/1.0.
6.	El servidor www.uv.es envía el archivo index.html.
7.	Se libera la conexión TCP.
8.	El visualizador presenta todo el texto de index.html.
9.	El visualizador trae y presenta todas las imágenes de index.html.

Muchos visualizadores presentan el paso que están ejecutando en cada momento en una línea de estado en la parte inferior de la pantalla, de forma que el usuario puede ver que esta haciendo y si sucede algún error a que es debido. Es necesario resaltar que para cada imagen en línea (icono, dibujo, fotografía, etc.) de una página, el visualizador establece una conexión TCP nueva con el servidor, con lo cual si una página contiene muchos iconos, todos en el mismo servidor, el establecer, usar y liberar una conexión nueva para cada uno no es muy eficiente, pero simplifica la implementación.

Puesto que HTTP es un protocolo ASCII como el SMTP, es bastante fácil que una persona en una terminal hable directamente con servidores de la Web. Todo lo que se necesita es una conexión TCP al puerto 80 del servidor. La manera más sencilla es usar el programa telnet. En la figura siguiente se muestra un ejemplo. El ejemplo muestra como un cliente, en este caso una persona, pero generalmente un visualizador, se conecta con el ordenador y le envía un comando solicitando una página en particular.Las líneas marcadas con C: son tecleadas por el usuario (cliente), las líneas marcadas con T: son producidas por el programa telnet y las líneas marcadas con S: son producidas por el servidor Web.

C: telnet www.uv.es 80
T: Triying
T: Connected to video.ci.uv.es.
T: Escape character is '^]'.
C: GET /index.html HTTP/1.0
C:
S: HTTP/1.1 200 OK
S: Date: Mon, 10 May 1999 15:51:26 GMT
S: Server: Apache/1.3.4 (Unix)
S: Connection: close
S: Content-Type: text/html
S: 
S: <TITLE>Servidor WWW de la Universitat de Valencia</TITLE>
S: <base href="http://www.uv.es/">
S: </HEAD>
S: <body>
S: <CENTER>
S: <IMG SRC="uval/pequescuT.gif"> <br>
S: <IMG SRC="uval/batt.gif" alt="Universitat de Val&egrave;ncia"><p>
S: <!--  <h1>UNIVERSITAT DE VAL&Egrave;NCIA</H1> -->
S:
S: <H2><a href="http://www.uv.es/~csegles">
S: 1499 - 1999: Cinc Segles de la Universitat de Val&egrave;ncia
S: </A></h2><p>
S: <!--
S: <P><A HREF="http://www.uv.es/rector.html"><B>Nota del Rector
S: </B></A></P>
S: -->
S:
S:
S: [
S: <a href="index_s.html">Versi&oacute;n en espa&ntilde;ol</a>
S: |
S:  <a href="index_e.html">English version</a>
S: |
S: <a href="index_eo.html">Esperanto-versio</a>
S:]
S: <p>
S:
S: <h2><a href="http://www.uv.es/~premsa/notes/leonn.htm"><font color="#005000">
S: Agra&iuml;ments des de Nicaragua</a></font></h2><p>
S:
S: <ADDRESS>
S: Contacteu amb el <A HREF=mailto:Servei.Estudiants@uv.es>Servei d'Estudiants</a>
S: per qualsevol informaci&oacute; sobre estudis, etc.<br>
S: Contacteu amb el <A HREF="http://www.uv.es/uval/webmaster.html">webmaster</a>
S: per qualsevol informaci&oacute; <b>t&egrave;cnica</b> sobre aquest servidor.<br>
S: </ADDRESS>
S: <p>
S: <a href="http:~vrplan/intro/sld001.html">Introducing the University</a><br>
S: </CENTER>
…
S: </body>

11.3.4 HTTP: Protocolo de transferencia de hipertexto.

El protocolo estándar de transferencia de la Web es el HTTP (HyperText Transfer Protocol). Cada interacción consiste en una solicitud ASCII seguida de una respuesta de tipo MIME RFC 822. Aunque es muy común el uso de TCP para la conexión de transporte, no es requerido formalmente por el estándar.

El HTTP evoluciona constantemente. Se usan varias versiones y se están desarrollando otras. Las versiones se especifican mediante un sistema de numeración del tipo <mayor>.<menor> para indicar las versiones del protocolo. De esta forma el emisor puede indicar el formato del mensaje y su capacidad para entender futuras comunicaciones HTTP. La versión del mensaje HTTP se indica en el campo HTTP-Version en la primera línea del mensaje, como en el siguiente ejemplo:

HTTP-Version: HTTP/1.0

En caso de no especificarse la versión del protocolo, el receptor del mensaje asume que el mensaje tiene el formato HTTP/1.0.

Las dos versiones principales existentes actualmente son la HTTP/1.0 y la HTTP/1.1. La diferencia principal entre ambas es que mientras la versión 1.0 obliga a que cada petición que un cliente realiza a un servidor genere una conexión TCP diferente, la versión 1.1 permite que una conexión albergue diferentes intercambios de solicitudes y respuestas.

El protocolo HTTP consiste en dos elementos bastante diferentes: el grupo de solicitudes de los visualizadores a los servidores y el grupo de respuestas en el otro sentido. Todas las versiones más recientes de HTTP reconocen dos tipos de solicitud: solicitudes sencillas y solicitudes completas. Una solicitud sencilla es sólo una línea GET que nombra la página deseada, sin la versión del protocolo. La respuesta es una página en bruto, sin cabeceras, sin MIME y sin codificación. Las solicitudes completas se indican por la presencia de la versión del protocolo en la línea de solicitud GET. Las solicitudes pueden consistir en múltiples líneas, seguidas de una línea en blanco. La primera línea de una solicitud completa contiene el comando, la página deseada y el protocolo/versión. Las líneas subsiguientes contienen cabeceras RFC 822 (cabeceras de correo electrónico).

Aunque el HTTP se diseñó para usarse en la Web, ha sido intencionalmente más general de lo necesario con miras a aplicaciones futuras orientadas a objetos. Por esta razón, la primera palabra de la línea de solicitud completa es sencillamente el nombre del método (comando) a ejecutar con la página de la Web (u objeto general). Los métodos existentes se listan en la tabla siguiente, siendo sensibles al contexto (mayúsculas y minúsculas), por lo cual GET es un método valido pero get no lo es.

Método	Descripción	
OPTIONS	Solicita información sobre las opciones de comunicación.	
GET	Solicita leer una página de Web.	
HEAD	Solicita leer la cabecera de una página de Web.	
POST	Adiciona a un recurso nombrado (p. ej., página de Web).	
PUT	Solicita almacenar una página de Web.	
DELETE	Elimina una página de Web.	
TRACE	Invoca una devolución del mensaje de solicitud.	

Tabla 11.12: Métodos existentes en HTTP.

El método OPTIONS solicita al servidor información sobre las opciones de comunicación disponibles para el recurso apuntado por un URL, generalmente un tipo MIME (text/html, etc.). De esta forma, el cliente puede determinar las posibilidades que tiene el servidor o las opciones asociadas a un recurso determinado.

El método GET solicita al servidor que envíe la página codificada adecuadamente en MIME. Sin embargo, si a la solicitud GET le sigue una cabecera If-Modified-Since, el servidor sólo envía los datos si fueron modificados después de la fecha proporcionada. Usando este mecanismo, un visualizador al que se solicitó una página que está en caché puede solicitarla condicionalmente al servidor.

El método HEAD simplemente pide la cabecera del mensaje, sin la página. Este método puede servir para obtener la hora de la última modificación, para recolectar información con fines de indexación, o simplemente para comprobar la validez de un URL.

El método POST se utiliza para solicitar al servidor que acepte la información que se envía adjunta al mensaje. Este método se utiliza generalmente para la publicación de un mensaje en un grupo de noticias y para proporcionar un bloque de datos al servidor (por ejemplo los datos rellenados en un formulario por el usuario).

El método PUT es el inverso de GET, en lugar de leer una página la escribe. Este método hace posible construir un conjunto de páginas de la Web en un servidor remoto. El cuerpo de la solicitud contiene la página y puede codificarse usando MIME, en cuyo caso las líneas que siguen a PUT podrían incluir cabeceras Content-Type y de validación de identificación, para demostrar que el solicitante tiene permisos de ejecución de la operación.

El método DELETE elimina la página. Como con PUT, la validación de identificación y los permisos desempeñan un papel principal. No hay garantía de que DELETE tendrá éxito, puesto que, incluso si el servidor HTTP remoto está dispuesto a borrar la página, el archivo subyacente puede tener un modo que prohiba al servidor HTTP su modificación o eliminación.

Por último, el método TRACE se utiliza para depurar aplicaciones. El servidor final debe devolver el mensaje de solicitud, reflejando que ha recibido de forma correcta el mensaje o bien el tipo de error detectado.

Cada solicitud recibe una respuesta que consiste en una línea de estado y, posiblemente, información adicional (por ejemplo, toda o parte de una página de la Web). La línea de estado contiene un código que consiste en un número de tres dígitos. 
Un ejemplo de línea de estado es el siguiente:

HTTP/1.0 200

Existen cinco tipos de códigos en función del primer dígito:

Código	Descripción	
1xx	Informativo. No utilizado, reservado para usos futuros.	
2xx	Éxito. La acción fue recibida y aceptada.	
3xx	Redirección. Se necesita una acción adicional para llevar a cabo la solicitud.	
4xx	Error del cliente. La solicitud contiene sintaxis errónea o no se puede conceder.	
5xx	Error del servidor. Error del servidor ante una solicitud aparentemente correcta.	

Tabla 11.13: Códigos de retorno en HHTP.

Una exposición más detalladas de los códigos y su descripción puede verse en la tabla siguiente:

Código	Descripción	
200	OK	
201	Creado	
202	Aceptado	
204	No contenido	
205	Reiniciar contenido	
206	Contenido parcial	
300	Opciones múltiples	
301	Cambiado permanentemente	
302	Cambiado temporalmente	
304	No modificado	
305	Utilizar proxy	
400	Solicitud errónea	
401	No autorizado	
402	Se requiere pago	
403	Prohibido	
404	No encontrado	
405	Método no permitido	
406	No aceptable	
407	Se requiere autentificación de proxy	
409	Conflicto	
411	Se requiere longitud	
413	Entidad solicitada es demasiado grande	
414	URL solicitada es demasiado grande	
500	Error interno del servidor	
501	No implementado	
502	Gateway erróneo	
503	Servicio no disponible	

Tabla 11.14: Exposición detallada de los códigos de retorno de HTTP.