Unidad IV: TCP/IP
4.4.3 http
El protocolo estándar de transferencia de la Web es el HTTP (HyperText Transfer Protocol, protocolo de transferencia de hipertexto). Cada interacción consiste en una solicitud ASCII seguida de una respuesta tipo MIME RFC 822. Aunque es muy común el uso del TCP para la conexión de transporte, no es requerido formalmente por el estándar. Si las redes ATM se vuelven lo bastante confiables, las solicitudes y respuestas HTTP podrían transportarse igualmente en mensajes AAL 5.
Unidad IV: TCP/IP
4.4.3 http
El HTTP está evolucionando constantemente. Se usan varias versiones y se están desarrollando otras. El material
presentado a continuación es relativamente básico y es poco probable que cambie su concepto, pero algunos detalles
podrían ser un poco diferentes en las versiones futuras. 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. Ahora los veremos por partes.
Unidad IV: TCP/IP
4.4.3 http
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 la página en bruto, sin cabeceras, sin MIME y sin codificación. Para ver su funcionamiento, intente
establecer una conexión Telnet con el puerto 80 de www.w3.org y luego teclee
Unidad IV: TCP/IP
4.4.3 http
pero esta vez sin HTTP/1.0. Se devolverá la página sin indicación de su tipo de contenido. Este mecanismo es necesario para la compatibilidad hacia atrás; su uso se reducirá a medida que los visualizadores y los servidores basados en solicitudes completas se vuelvan la regla.
Unidad IV: TCP/IP
4.4.3 http
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 para indicar el final de la solicitud. La primera línea de una solicitud completa contiene el
comando (GET es sólo una posibilidad), la página deseada y el protocolo/versión. Las líneas subsiguientes contienen
Unidad IV: TCP/IP
4.4.3 http
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 interconstruidos se listan en la tabla siguiente. Después de acceder a objetos generales, también pueden estar
disponibles métodos adicionales específicos para ese objeto. Los nombres son sensibles a mayúsculas y minúsculas, por lo que GET es un método legal, pero get no.
Unidad IV: TCP/IP
4.4.3 http
Método Descripción
GET Solicita leer una página de Web
HEAD Solicita leer la cabecera de una página de Web
PUT Solicita almacenar una página de Web POST Adiciona a un recurso nombrado (p. ej.,
página de Web)
DELETE Elimina la página de Web
LINK Conecta dos recursos existentes
UNLINK Rompe una conexión existente entre dos recursos
Unidad IV: TCP/IP
4.4.3 http
El método GET solicita al servidor que envíe la página (con lo que queremos decir objeto, en el caso más general),
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, dando la
hora de modificación asociada a la página. Si la página en caché aún es válida, el servidor simplemente devuelve una línea de estado anunciando el hecho, eliminando por tanto la carga extra de transferir de nuevo la página.
Unidad IV: TCP/IP
4.4.3 http
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 indización, o simplemente para probar la validez de un URL. No existen las solicitudes HEAD condicionales.
Unidad IV: TCP/IP
4.4.3 http
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
efectivamente tiene permiso de ejecutar la operación solicitada.
Unidad IV: TCP/IP
4.4.3 http
Algo parecido a PUT es el método POST: también lleva un URL pero, en lugar de reemplazar los datos existentes, se "anexa" a ellos en algún sentido generalizado. La
publicación de un mensaje en un grupo de noticias y la
adición de un archivo a un sistema de boletines electrónicos son ejemplos de anexión en este contexto. Claramente, la intención aquí es hacer que la Web asuma la funcionalidad del sistema de noticias USENET.
Unidad IV: TCP/IP
4.4.3 http
DELETE hace lo que podría esperarse: 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 prohíba al servidor HTTP su modificación o eliminación.
Unidad IV: TCP/IP
4.4.3 http
Los métodos LINK y UNLINK permiten establecer conexiones entre páginas existentes u otros recursos.
Cada solicitud recibe una respuesta que consiste en la 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 puede tener el código 200 (OK) o cualquiera de
varios códigos de error, por ejemplo 304 (no modificado), 400 (lista errónea) o 403 (prohibido).
Los estándares HTTP describen las cabeceras y los cuerpos de mensaje con considerable detalle. Basta decir que son muy parecidos a los mensajes MIME RFC 822, por lo que no los veremos aquí.
Unidad IV: TCP/IP
4.4.4 NFS
El Network File System (Sistema de archivos de red o NFS), que originalmente fue desarrollado por Sun Microsystem Incorporated, proporciona un acceso de archivos
compartidos en línea que es transparente e integrado; muchas de las localidades TCP/IP utilizan el NFS para
interconectar los archivos de sus computadoras. Desde la perspectiva del usuario, el NFS es casi invisible. Un usuario puede ejecutar un programa de aplicación arbitrario y
valerse de archivos arbitrarios de entrada o salida. Los
nombres de los archivos per se no muestran si son locales o remotos.
Unidad IV: TCP/IP
4.4.4 NFS
Implantación NFS
En la figura siguiente, se ilustra cómo es que el NFS está embebido en un sistema operativo. Cuando ejecuta un
programa de aplicación, se llama al sistema operativo para que abra un archivo o para que almacene y recupere datos en archivos. El mecanismo de acceso de archivos acepta la petición y la transmite de manera automática al software de sistema de archivo local o al cliente NFS, dependiendo de si el archivo está en el disco local o en una máquina remota. Cuando recibe una petición, el software de cliente utiliza el protocolo NFS para ponerse en contacto con el servidor
apropiado en una máquina remota y ejecutar la operación requerida. Cuando contesta el servidor remoto, software del cliente devuelve los resultados al programa de aplicación.
Unidad IV: TCP/IP
4.4.4 NFS
Unidad IV: TCP/IP
4.4.5 DNS
El esquema de nombres de Internet se llama sistema de nombres de dominio (DNS). En cuanto a la sintaxis, un nombre de computadora consta de una secuencia de segmentos alfanuméricos separados por puntos. Por ejemplo, una computadora del Instituto Tecnológico de Durango tiene el nombre de dominio:
correo.Itdurango.edu.mx
Los nombres de dominio son jerárquicos; la parte más significativa del nombre está a la derecha. La parte de la izquierda del nombre (correo) es el nombre de una
computadora. Los otros segmentos del nombre de dominio identifican el grupo al que pertenece el nombre. P. ej., el segmentoe itdurango indica nombre de universidad.
Unidad IV: TCP/IP
4.4.5 DNS
¿Cuántos segmentos tiene cada nombre y cómo se asignan? La respuesta es que, aparte de especificar la manera de
elegir los segmentos más significativos, el sistema de nombres de dominio no indica una cantidad exacta de
segmentos en el nombre ni lo que representan. En cambio, cada organización escoge los segmentos para las
computadoras que le pertenecen, así como lo que representan.
El sistema de nombres de dominio sí especifica los datos del segmento más significativo, que se llama nivel superior del DNS. La tabla siguiente es una lista de los dominios de nivel superior posibles:
Unidad IV: TCP/IP
4.4.5 DNS
Nombre de dominio Asignado a
corn Organización comercial edu Institución educativa
gov Organización gubernamental mil Grupo militar
net Centro principal de soporte de redes org Organización diferente a las anteriores arpa Dominio ARPA temporal (aún se usa) int Organización internacional
Unidad IV: TCP/IP
4.4.5 DNS
Cuando una organización quiere participar en el sistema de nombres de dominio, debe solicitar un nombre con uno de los dominios de nivel superior. Casi todas las corporaciones eligen registrarse con el dominio com. Por ejemplo, una
compañía llamada Foobar puede solicitar se le asigne el
dominio foobar con el dominio de nivel superior com. Si se aprueba su solicitud, la autoridad de Internet responsable de los nombres de dominio asignará a la Corporación Foobar el dominio:
Unidad IV: TCP/IP
4.4.5 DNS
Una vez asignado un dominio a una organización, se reserva el sufijo para ella. y ninguna otra recibirá el mismo sufijo de nombre. Por ejemplo, una vez asignado foobar.com, otra
organización llamada también Foobar pode a solicitar
foobar.edu o foobar.org, pero no foobar.com. En resumen:
Para obtener un dominio, una organización debe registrarse con la autoridad de Internet. Se asigna un sufijo de dominio único a cada organización.
Unidad IV: TCP/IP
4.4.5 DNS
Protocolos en TCP/IP
Todos los protocolos de alto nivel tienen algunas características en común:
Pueden ser aplicaciones escritas por el usuario o
aplicaciones estandarizadas y distribuidas con un producto TCP/IP. De hecho, la pila TCP/IP incluye protocolos de
aplicación tales como:
1. TELNET para el acceso interactivo de una terminal a un host remoto.
2. FTP ("File Transfer Protocol") para transferencias de alta velocidad de un disco a otro.
3. SMTP ("simple mail transfer protocol") como sistema de correo de Internet.
Unidad IV: TCP/IP
4.4.5 DNS
Protocolos en TCP/IP (Cont..)
Estas son las aplicaciones implementadas más ampliamente, pero existen muchas otras. Cada implementación TCP/IP
particular incluye un conjunto más o menos restringido de protocolos de aplicación.
Unidad IV: TCP/IP
4.4.5 DNS
Protocolos en TCP/IP (Cont..)
Usan UDP o TCP como mecanismo de transporte. Recordar que UDP no es fiable ni ofrece control de flujo, por lo que en este caso la aplicación ha de proporcionar sus propia rutinas de recuperación de errores y de control de flujo. Suele ser más fácil desarrollar aplicaciones sobre TCP, un protocolo fiable, orientado a conexión. La mayoría de los protocolos de aplicación utilizan TCP, pero algunas aplicaciones se
construyen sobre UDP para proporcionar un mejor
rendimiento reduciendo la carga del sistema que genera el protocolo.
La mayoría de ellas usa el modelo de interacción cliente/servidor.
Unidad IV: TCP/IP
4.4.5 DNS
El protocolo TELNET
TELNET es un protocolo estándar siendo su número STD de 8. Su status es recomendado. Se describe en el RFC 854
-Especificaciones del protocolo TELNET y RFC 855 - "TELNET Option Specifications".
El protocolo TELNET proporciona una interfaz estandarizada, a través de la cual un programa de un host(el cliente de
TELNET) puede acceder a los recursos de otro host (el
servidor de TELNET) como si el cliente fuera una terminal local conectada al servidor.
Unidad IV: TCP/IP
4.4.5 DNS
El protocolo TELNET (Cont..)
Por ejemplo, un usuario de una estación de trabajo situada en una LAN se puede conectar al host. Por supuesto, TELNET se puede usar tanto en LANs como en WANs.
Funcionamiento de TELNET
Unidad IV: TCP/IP
4.4.5 DNS
Funcionamiento de TELNET
1. El concepto de NVT(Network Virtual Terminal) (NVT). Una NVT es un dispositivo imaginario que posee una estructura básica común a una amplia gama de
terminales reales. Cada host mapea las características de su propia terminal sobre las de su correspondiente NVT, y asume todos los demás hosts harán lo mismo.
2. Una perspectiva simétrica de las terminales y los procesos.
Unidad IV: TCP/IP
4.4.5 DNS
Funcionamiento de TELNET (Cont..)
3. Negociación de las opciones de la terminal. El protocolo TELNET usa el principio de opciones negociadas, ya que muchos host pueden desear suministrar servicios
adicionales, más allá de los disponibles en la NVT. Se pueden negociar diversas opciones. El cliente y el
servidor utilizan una serie de convenciones para establecer las características operacionales de su conexión TELNET a través de los mecanismos "DO,
DON'T, WILL, WON'T"("hazlo, no lo hagas, lo harás, no lo harás")
Unidad IV: TCP/IP
4.4.5 DNS
Estructura de comandos en TELNET
La comunicación entre cliente y servidor es manejada por comandos internos, que no son accesibles a los usuarios. Todos los comandos internos de TELNET consisten en
secuencias de 2 o 3 bytes, dependiendo del tipo de comando.
El carácter IAC("Interpret As Command"; Interpretar Como Comando) es seguido de un código de comando. Si este
comando trata con opciones de negociación, el comando tendrá un tercer byte para mostrar el código asociado a la opción indicada.
Unidad IV: TCP/IP
4.4.5 DNS
Unidad IV: TCP/IP
4.4.5 DNS
Estructura de comandos en TELNET (Cont..)
El objetivo principal del protocolo TELNET es proporcionar una interfaz estándar para hosts en una red. Para permitir que comience una conexión. TELNET establece una
representación estándar para algunas funciones: IP
Interrumpir proceso AO
Unidad IV: TCP/IP
4.4.5 DNS
Estructura de comandos en TELNET (Cont..)
AYT ¿Estás ahí? EC Borrar carácter EL Borrar línea SYNCH Sincronizar
Unidad IV: TCP/IP
4.4.5 DNS
Negociación de opciones
Usando los comandos internos, TELNET es capaz de negociar opciones en cada host. La base inicial de la negociación es la NVT: cada host que se quiera conectar debe estar de
acuerdo con este mínimo. Cada opción se puede negociar haciendo uso de los cuatro códigos de comando "WILL, WON'T, DO, DON'T" descritos anteriormente. Además, algunas opciones tienen a su vez sub-opciones: si ambas partes acuerdan una opción, usarán los comandos SB y SE para llevar a cabo la sub-negociación.
