Tema 4 Instalacic3b3n y Administracic3b3n de Servicios Web Jesus Garcia
Tema 4 Instalacic3b3n y Administracic3b3n de Servicios Web Jesus Garcia
Tema 4 Instalacic3b3n y Administracic3b3n de Servicios Web Jesus Garcia
1
INDICE
Introducción
Características generales de un servicio Web.
Protocolo HTTP.
Configuración de un servidor Web.
Navegadores Web.
Seguridad del protocolo HTTP
Almacenamiento virtual de sitios web: «Hosts» virtuales.
- WWW
Características de la Web
Según su propio creador, Berners-Lee, la Web es un sistema que presenta las
siguientes características:
1) Hipermedial: en la Web podemos manejar información multimedial y navegar
a través de ella.
2) Distribuido: a diferencia de las antiguas y enormes bases de datos que
concentraban la información físicamente en un único lugar, la Web es un sistema
compuesto por miles de servidores localizados en cientos de ciudades del mundo
que están interconectadas entre sí.
3) Heterogéneo: por ser un servicio relativamente nuevo, la Web tiene la ventaja
de poder reunir servicios y protocolos más antiguos (como Gopher, los News, FTP,
e inclusive el correo electrónico), de modo tal de presentar la información desde
un único programa cliente.
Funcionamiento de la Web
El primer paso consiste en traducir la parte
nombre del servidor de la URL en una
dirección IP usando la base de datos
distribuida de Internet conocida como DNS.
Esta dirección IP es necesaria para contactar
con el servidor web y poder enviarle paquetes
de datos.
El siguiente paso es enviar una petición HTTP
al servidor Web solicitando el recurso. En el
caso de una página web típica, primero se
solicita el texto HTML y luego es
inmediatamente analizado por el navegador, el
cual, después, hace peticiones adicionales para
los gráficos y otros ficheros que formen parte de la página. Las estadísticas de
popularidad de un sitio web normalmente están basadas en el número de páginas
vistas o las peticiones de servidor asociadas, o peticiones de fichero, que tienen
lugar.
Al recibir los ficheros solicitados desde el servidor web, el navegador muestra la
página tal y como se describe en el código HTML, el CSS y otros lenguajes web. Al
final se incorporan las imágenes y otros recursos para producir la página que ve el
usuario en su pantalla
W3C son las siglas de World Wide Web Consortium, un consorcio fundado en
1994 para dirigir a la Web hacia su pleno potencial
mediante el desarrollo de protocolos comunes que
promuevan su evolución y aseguren su
interoperabilidad.
- Componentes y funcionamiento.
NOMBRES, DIRECCIONES
Algunos ejemplos de nombres e identificadores son las URL, los nombres de
dominio de Internet, los nombres de archivos… etc.
Podemos distinguir entre nombres puros (patrones de bits sin interpretar) y no
puros (contienen información sobre el objeto al que nombran (p. ej: la ubicación
del objeto)). En el otro extremo de un nombre puro se sitúa la dirección de un
objeto, la cual es eficaz para acceder a éste, pero está el problema de que un objeto
puede cambiar de localización.
Se dice que un nombre está resuelto cuando está traducido a datos relacionados
con el recurso en cuestión. La asociación entre un nombre y un objeto se llama
enlace. Los nombres suelen enlazarse a los atributos de los objetos y no a su
implementación. Un atributo es una propiedad de un objeto.
Identificadores de Recurso Unificados (URI): Un ejemplo de URI son los URL,
que son direcciones únicamente de recursos web, a los que se puede acceder con
facilidad (nombre DNS más un camino hacia el recurso). Pero si un recurso se
mueve o se borra, el URL no apuntará a nada (se dice comúnmente que está roto) o
apuntará a otro objeto (si ha sido referenciado igual que el anterior).
Otro tipo de URI son los Nombres Uniformes de Recurso (URN), que tratan de
resolver los anteriores problemas. Un servicio de búsqueda URN relaciona los URN
con su URL correspondiente, la cual puede variar en el tiempo (sin que varíe el
URN). Si un administrador cambia la URL, debe registrar la nueva en el servicio de
búsqueda.
URIs relativas
Las URIs relativas son URIs parciales, utilizadas para referirse a un documento
desde otro en la misma computadora. De esta forma, podemos definir una URI
relativa como la ruta que se debe seguir desde la ubicación del documento actual
(ruta de directorios) a la ubicación del recurso referido, además del nombre de
archivo.
Supongamos que el documento actual, localizado en
"http://servidor.es/documentos/index.asp", necesita apuntar a un documento
ubicado en "http://servidor.es/documentos/nuevos/mejores/dos.asp". La URI
relativa para referirse a ese recurso desde el documento actual será:
"nuevos/mejores/dos.asp"
El directorio especial ".." provee una forma de ir hacia atrás al directorio "padre".
De modo que para apuntar desde
"http://nuevoservidor.mil/documentos/nuevos/mejores/rec.htm" a
"http://nuevoservidor.mil/documentos/antiguos/mejores/junio.htm", la URI
relativa será: "../../antiguos/mejores/junio.htm"
¿Qué es un URL?
Los URLs (Uniform Resource Locator) son identificadores que permiten acceder a
recursos (páginas) web. En la misma forma en que los humanos utilizamos
direcciones para identificar y encontrar ubicaciones, los URLs le sirven al
navegador (y otros sistemas) para encontrar una página o recurso Web en el vasto
mundo del Internet.
- Páginas web
Características
Una página web está compuesta principalmente por información (sólo texto y/o
módulos multimedia) así como por hiperenlaces; además puede contener o asociar
datos de estilo para especificar cómo debe visualizarse, y también aplicaciones
embebidas para así hacerla interactiva.
Las páginas web son escritas en un lenguaje de marcado que provee la capacidad
de manejar e insertar hiperenlaces, generalmente HTML.
Las páginas dinámicas que se generan, al ser solicitadas, son creadas por una
aplicación en el servidor web que alberga las mismas.
- Sitios Web.
A veces se utiliza erróneamente el término página web para referirse a sitio web.
Una página web es parte de un sitio web y es un único archivo con un nombre de
archivo asignado, mientras que un sitio web es un conjunto de archivos llamados
páginas web.
Si lo comparáramos con un libro, un sitio web sería el libro entero y una página
web de ese sitio web sería un capítulo de ese libro. El título del libro sería el
nombre del dominio del sitio web. Un capítulo, al igual que una página web, tiene
un nombre que lo define. Decimos que sería un capítulo y no una página del libro
porque a menudo es necesario desplazarse hacia bajo en la pantalla para ver todo
el contenido de una página web, al igual que en un libro te desplazas a través de
varias páginas para ver todo el contenido de un capítulo. El índice de los capítulos
del libro sería el equivalente al mapa del sitio web (sitemap en inglés).
- Aplicación Web
Una aplicación web es cualquier aplicación que es accedida vía web por una red
como internet o una intranet.
Una de las ventajas de las aplicaciones web cargadas desde internet (u otra red) es
la facilidad de mantener y actualizar dichas aplicaciones sin la necesidad de
distribuir e instalar un software en, potencialmente, miles de clientes. También la
posibilidad de ser ejecutadas en múltiples plataformas.
Las aplicaciones web son utilizadas para implementar webmail, ventas online,
subastas online, wikis, foros de discusión, weblogs, MMORPGs, redes sociales,
juegos, etc.
- Si es por internet, el usuario puede entrar desde cualquier lugar del mundo
donde tenga un acceso a internet.
Prácticamente no hay limitaciones, las aplicaciones web pueden hacer casi todo lo
que está disponible para aplicaciones tradicionales: acceder al mouse, al teclado,
ejecutar audio o video, mostrar animaciones, soporte para arrastrar y soltar, y
otros tipos de tecnologías de interacción usuario-aplicación.
Desde el punto de vista de las comunicaciones, está soportado sobre los servicios
de conexión TCP/IP, y funciona de la misma forma que el resto de 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.
- Funcionamiento básico.
Cada vez que un cliente realiza una petición a un servidor, se ejecutan los
siguientes pasos:
- Comprensión.
Ventajas
Al comprimir información, esta se envía mucho más rápido desde el servidor hasta
el navegador del visitante, produciendo así una mejor experiencia en la visita del
sitio y recortando la cantidad de ancho de banda --y sus costos-- utilizado por el
sitio. En general se puede conseguir una compresión de entre 5:1 y 10:1 (y de
hasta 50:1), logrando así una reducción del tamaño de las páginas de, en promedio,
65% a 85%. Esto resulta generalmente en una transferencia de entre 3 a 6 veces
más rápido,
Google, Amazon, Yahoo, AT&T y una larga lista de gigantes utilizan esta tecnología.
Por ejemplo la pagina principal de Google tiene apenas 1.412 bytes, que sin
compresión hubiera tenido 3.873 bytes, logrando así un ahorro del 63.5%.
Desventajas
- Cookies.
Identificación por IP: un método muy poco fiable, pues bajo una misma IP
podían estar accediendo distintos usuarios (por ejemplo desde un cíber),
además que la dirección IP de un usuario puede cambiar.
- Mensajes HTTP.
Petición
Donde SP es un espacio, URI es la URI del recurso al que hace referencia la petición
y CRLF es un retorno de carro y nueva línea.
En el caso del protocolo HTTP/0.9 sólo se permite el método GET, con el protocolo
HTTP/1.0 GET, POST y HEAD y con el protocolo HTTP/1.1 OPTIONS, GET, HEAD,
POST, PUT, DELETE y TRACE. En caso de que un servidor tenga implementado un
método, pero no está permitido para el recurso que se pide, entonces ha de
devolver un código de estado 405 (método no permitido). Si lo que ocurre es que
no tiene implementado el método, entonces devuelve un código 501 (no
implementado). Los únicos métodos que deben soportar los servidores de forma
obligatoria son los métodos GET y HEAD.
El contenido (si está presente) está en un formato con una codificación definida en
las cabeceras de entidad.
Respuesta
Algunos de los códigos más comúnmente usados y las frases asociadas son:
100, continuar.
101, cambio de protocolo.
200, éxito.
201, creado.
202, aceptado.
203, información no autoritativa.
204, sin contenido.
205, contenido reestablecido.
206, contenido parcial.
300, múltiples elecciones.
301, movido permanentemente.
302, movido temporalmente.
303, ver otros.
304, no modificado.
305, usar proxy.
400, petición errónea.
401, no autorizado.
402, pago requerido.
403, prohibido.
404, no encontrado.
405, método no permitido.
406, no se puede aceptar.
407, se requiere autentificación proxy.
408, límite de tiempo de la petición.
409, conflicto.
410, gone.
411, tamaño requerido.
412, falla una precondición.
413, contenido de la petición muy largo.
414, URI de la petición muy largo.
415, campo media type requerido.
500, error interno del servidor.
501, no implementado.
502, puerta de enlace errónea.
503, servicio no disponible.
La frase explicativa, es eso, una frase corta que explica el código de estado enviado
al cliente.
Se pueden usar más códigos, pero las aplicaciones HTTP no tienen que conocer
todos los códigos definidos y su significado, pero sí están obligadas a conocer su
clase y tratar los códigos desconocidos como el primer código de la clase (x00).
En cuanto a las cabeceras de la respuesta, son de tres tipos: las cabeceras generales
las cabeceras de la respuesta y las cabeceras de entidad
Las cabeceras de respuesta permiten al servidor enviar información adicional al
cliente sobre la respuesta. Estos campos dan información sobre el servidor y
acceso al recurso pedido.
Un método se dice que es seguro si no provocan ninguna otra acción que no sea la
de devolver algo (no produce efectos laterales). Estos métodos son el método GET
y el método HEAD. Para realizar acciones inseguras (las que afectan a otras
acciones) se pueden usar los métodos POST, PUT y DELETE. Aunque esto está
definido así, no se puede asegurar que un método seguro no produzca efectos
laterales, porque depende de la implementación del servidor.
Método OPTIONS
Método GET
También hay un método GET parcial, con el que se envía sólo parte del contenido
del recurso requerido. Esto ocurre cuando la petición tiene una cabecera Range. Al
igual que el método GET condicional, el método GET parcial se creó para reducir el
tráfico en la red.
Método HEAD
El método HEAD es igual que el método GET, salvo que el servidor no tiene que
devolver el contenido, sólo las cabeceras. Estas cabeceras que se devuelven en el
método HEAD deberían ser las mismas que las que se devolverían si fuese una
petición GET.
Este método se puede usar para obtener información sobre el contenido que se va
a devolver en respuesta a la petición. Se suele usar también para chequear la
validez de links, accesibilidad y modificaciones recientes.
Método POST
El método POST se usa para hacer peticiones en las que el servidor destino acepta
el contenido de la petición como un nuevo subordinado del recurso pedido. El
método POST se creó para cubrir funciones como la de enviar un mensaje a grupos
de usuarios, dar un bloque de datos como resultado de un formulario a un proceso
de datos, añadir nuevos datos a una base de datos, ...
La función llevada a cabo por el método POST está determinada por el servidor y
suele depender de la URI de la petición. El resultado de la acción realizada por el
método POST puede ser un recurso que no sea identificable mediante una URI.
Método PUT
Método DELETE
Este método se usa para que el servidor borre el recurso indicado por la URI de la
petición. No se garantiza al cliente que la operación se lleve a cabo aunque la
respuesta sea satisfactoria.
Método TRACE
Este método se usa para saber si existe el receptor del mensaje y usar la
información para hacer un diagnóstico. En las cabeceras el campo Via sirve para
obtener la ruta que sigue el mensaje. Mediante el campo Max-Forwards se limita el
número de pasos intermedios que puede tomar. Esto es útil para evitar bucles
entre los proxy.
- Cabeceras.
Connection (conexión)
Permite especificar diferentes opciones para la conexión. Por ejemplo:
Connection: close
indica que la conexión debe cerrarse una vez transmitido el mensaje completo
Content-Language (idioma del contenido)
Esta cabecera indica el idioma de los destinatarios del recurso. Si no existe, se
entiende que el recurso está orientado a todos los usuarios, independientemente
del idioma. Esta cabecera permite listar varios idiomas. Por ejemplo, una
herramienta on-line de traducción inglés-francés, podría incluir en sus páginas la
cabecera:
Content-Language: es, fr
Es importante recalcar que esta cabecera no indica necesariamente el idioma del
documento, sino del público al que objetivamente se orienta. Una texto sencillo de
inglés para estudiantes hispanoparlantes incluiría la cabecera:
Content-Language: es
aunque el contenido pueda estar en inglés (y, por tanto, las metaetiquetas HTML
indiquen que se trata de un documento en inglés).
Content-Length (longitud del contenido)
Indica la longitud del cuerpo del recurso, expresada en número de octetos.
Content-Location (localización del contenido)
Dirección complementaria que ofrece el servidor en su respuesta. Esta nueva
dirección (una URI absoluta o relativa) no corrige la dirección original del recurso
solicitado por el cliente, sino que ofrece una ruta a un recurso que complementa al
solicitado originalmente.
Content-Type (tipo de contenido)
Indica, como su nombre indica, el tipo de contenido del recurso. Así, la cabecera
Content-Type: text/html; charset=ISO-8859-1
indica que el recurso es de tipo texto, concretamente código HTML, y codificado
según la especificación ISO-8859-1.
- Almacenamiento en cache.
Se llama caché web a la caché que almacena documentos web (es decir, páginas,
imágenes, etcétera) para reducir el ancho de banda consumido, la carga de los
servidores y el retardo en la descarga. Un caché web almacena copias de los
documentos que pasan por él, de forma que subsiguientes peticiones pueden ser
respondidas por el propio caché, si se cumplen ciertas condiciones.
Las cachés web pueden utilizarse de diversas formas. Las cachés de agente de
usuario (User-Agent), como las presentes en los navegadores web, son cachés
privados, que funcionan solo para un único usuario. También existen paquetes
específicos que se instalan como proxy local y actúan como caché además de
realizar otras tareas, como por ejemplo Proxomitron.
Los intermediarios que funcionan como caché realizan con frecuencia otras tareas,
tales como la autenticación de usuarios y el filtrado de contenidos. Varios cachés
pueden ser coordinados entre sí con las ayuda de protocolos específicos tales como
ICP o HTCP.
El protocolo HTTP define tres mecanismos básicos para controlar las cachés:
Frescura, que permite que una respuesta sea usada sin comprobar de
nuevo el servidor origen, y puede ser controlada tanto por el servidor como
el cliente. Por ejemplo, la cabecera de respuesta Expires facilita una fecha en
la que el documento caduca, y la directiva Cache-Control: max-age informa
al caché del número de segundos durante los que la respuesta será válida.
Validación, que puede usarse para comprobar si una respuesta cacheada
sigue siendo buena tras caducar. Por ejemplo, si la respuesta tiene una
cabecera Last-Modified, un caché puede hacer una petición condicional
usando la cabecera If-Modified-Since para saber si la página cambió.
Invalidación, que normalmente es un efecto secundario de otra petición
que pasa por la caché. Por ejemplo, si la URL asociada con una respuesta
cacheada es solicitada posteriormente mediante una petición POST, PUT o
DELETE, la respuesta cacheada quedará invalidada.
- Redirecciones.
Una redirección sirve para llevar al navegador del usuario a una página distinta.
Redirigir al navegador nos puede servir para enviarlo a otra dirección URL distinta
donde están los contenidos que desea ver.
Con PHP podemos redirigir al navegador con la función header(), que envía
informaciones en la cabecera del HTTP.
Por defecto PHP realiza una redirección temporal, de tipo 302. Pero nosotros
podemos indicarle otro tipo de redirección, también con la función header(),
indicando el tipo antes de hacer el Location.
Para hacer una redirección 301 (permanente), utilizaremos un código PHP como
este:
Para hacer una redirección 302 con PHP (temporal) el código sería así:
- Comprensión.
Ventajas
Al comprimir información, esta se envía mucho más rápido desde el servidor hasta
el navegador del visitante, produciendo así una mejor experiencia en la visita del
sitio y recortando la cantidad de ancho de banda --y sus costos-- utilizado por el
sitio. En general se puede conseguir una compresión de entre 5:1 y 10:1 (y de
hasta 50:1), logrando así una reducción del tamaño de las páginas de, en promedio,
65% a 85%. Esto resulta generalmente en una transferencia de entre 3 a 6 veces
más rápido,
Google, Amazon, Yahoo, AT&T y una larga lista de gigantes utilizan esta tecnología.
Por ejemplo la pagina principal de Google tiene apenas 1.412 bytes, que sin
compresión hubiera tenido 3.873 bytes, logrando así un ahorro del 63.5%.
Desventajas
- Cookies.
Identificación por IP: un método muy poco fiable, pues bajo una misma IP
podían estar accediendo distintos usuarios (por ejemplo desde un cíber),
además que la dirección IP de un usuario puede cambiar.
- Autenticación
Esquema de
Descripción
autenticación
- Conexiones persistentes
los errores se pueden divulgar sin la pena de cerrar la conexión del TCP
Según RFC 2616 (página 47), un cliente single-user no debe mantener más de 2
conexiones con ningún servidor o poder. A poder debe utilizar hasta las
conexiones 2*N a otro servidor o poder, donde está el número N de usuarios
simultáneamente activos. Estas pautas se piensan para mejorar tiempos de
reacción del HTTP y para evitar la congestión.
Netscape Navigator (desde por lo menos 4.05) y Internet Explorer (desde por lo
menos 4.01) apoye las conexiones persistentes a los servidores y a los poderes del
Web.
Todas las líneas que comienzan con el símbolo # son comentarios, explican en cada
sección las distintas opciones pero se encuentran en ingles.
1- Probar y ver las páginas web como verdaderamente van a mostrarse desde
internet antes de subirlas a un host o servidor en la red. Útil e indispensable si
tienes o vas a crear tu sitio por modesto que este sea.
2- Crear mediante el modulo Virtual Host múltiples sitios web en nuestra PC, que
podemos descargar con wget y acceder a ellos igual que en la red pero esta vez de
forma local.
3- Poder ver localmente páginas web hechas en lenguaje php.
4- Servir nuestras páginas o sitio web directamente a internet, a los que puede
acceder y conectarse cualquier persona desde el exterior, en este caso lógicamente
el funcionamiento del servidor estará limitado al tiempo que tengamos
funcionando la PC y a las posibilidades de nuestra conexión. Puede constituir una
experiencia muy alentadora para cualquier aficionado, esta posibilidad da la
ventaja de que no es necesario depender de ninguna compañía ni servidor remoto
para subir a la red el contenido que queremos mostrar. Es como montar una
pequeña estación de radio y empezar a transmitir, (una similitud) pero en este
caso el alcance es global.
5- Puede actuar como intermediario entre nuestra PC e internet lo que nos da
varias ventajas en el ámbito de la seguridad.
6- A través de él podemos servir internet a varias PC conectadas en una red local.
7- Es posible activar un módulo que permite guardar en cache todas las páginas
cargadas lo que mejorará el rendimiento de nuestra navegación.
Esquema de Descripción
autenticación
Básica La autenticación básica envía una cadena codificada por Base64 que
contiene un nombre de usuario y contraseña para el cliente. Base64 no
es una forma de cifrado y debe considerarse igual que enviar el nombre
de usuario y contraseña en texto no cifrado. Si un recurso necesita ser
protegido, considere fervientemente utilizar un esquema de
autenticación distinto de la autenticación básica.
Ahora bien, ¿En que nos sirve los logs para monitorear nuestro sistema? pues muy
sencillo, los principales archivos logs que estan en la carpeta /var/log van
almacenando informacion de casi todos los eventos que ocurren en tu PC
practicamente desde que la enciendes y en ellos podremos ver por ejemplo que
pasa internamente en Linux cuando conectas una Memoria USB, un Modem USB o
cuando estas conectado a internet puedes ver los intentos de entrada bloqueados
por tu firewall. En otras circunstancias podremos ser capaces de observar algun
mensaje de error que se pueda producir cuando estas conectando algun hardware
nuevo o si tienes un servicio web instalado podras ver quienes estan conectados a
tu equipo.
- Tipos MIME.
MIME está especificado en seis Request for Comments o RFC (en español "solicitud
de comentarios): RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077.
Los tipos de contenido definidos por el estándar MIME tienen gran importancia
también fuera del contexto de los mensajes electrónicos. Ejemplo de esto son
algunos protocolos de red tales como HTTP de la Web. HTTP requiere que los
Subtipos de Multiparte
Mixed
Message
] Digest
Alternative
Dado que es poco probable que un cliente quiera enviar una versión que es poco
fiel a la versión en texto plano, esta estructura ubica la versión en texto plano (si
existe) primero. Esto facilita la tarea de leer los mensajes para los usuarios de
clientes que no entienden mensajes multipartes.
Related
El subtipo multipart/related es usado para indicar que las partes del mensaje no
deben ser consideradas individualmente sino como agregados de un todo. El
mensaje consiste de una parte raíz (implícitamente la primera) que hace referencia
a otras partes, las que a su vez pueden hacer referencia a otras partes. Las partes
son comúnmente referenciadas por el encabezado: "Content-ID". La sintaxis de la
referencia no está especificada sino que está dictada por la codificación o el
protocolo usado en la parte que contiene la referencia.
Un uso común de este subtipo es para enviar páginas web completas con imágenes
en un único mensaje. La parte raíz contendría el documento HTML, que usaría
etiquetas HTML para imágenes, para referirse a las imágenes almacenadas en
partes subsiguientes.
Signed
Encrypted
Form Data
Mixed-Replace (Experimental)
Recurso es el nombre HTTP para una referencia que está apuntada por un
Identificador de Recursos Uniforme o URI (Uniform Resource Identifier).
Los estándares web son un conjunto de recomendaciones dadas por el World Wide
Web consortium W3C) y otras organizaciones internacionales acerca de como
crear e interpretar documentos basados en la web. Su objetivo es crear una web
que trabaje mejor para todos, con sitios accesibles a mas personas y que funcionen
en cualquier dispositivo de acceso a Internet.
Barra de Título
Barra de Menús
La barra de herramientas tiene botones para los comandos utilizados con más
frecuencia. Cuando el ratón pasa por encima de un botón, este se verá en colores y
parecerá en relieve. Algunos botones no se verán, si el tamaño de la ventana es
pequeño.
Barra de Direcciones
Puede escribir una URL en la Barra de Direcciones y apretar la tecla ENTRAR para
desplegar la página cuya ubicación ha escrito.
Un vínculo hacia otra página web, imagen, o archivo, debería verse como
extraordinaria. Un vínculo de texto por defecto, debería verse subrayado y el texto
en color azul. Usted hace un clic en un link para apuntar a su objetivo en el
navegador.
Barra de Estado
La Barra de Vínculos, es un lugar conveniente para los atajos hacia las páginas web
a las que accede con mayor frecuencia. IE ya viene con algunos sitios de Microsoft
que se ven en la Barra de Vínculos. Según las diferentes versiones, se verán sitios
algo distintos en la lista. Puede borrar aquellos sitios y agregar los suyos propios.
- Protocolo HTTPS.
El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado
(cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por
el cliente) más apropiado para el tráfico de información sensible que el protocolo
HTTP. De este modo se consigue que la información sensible (usuario y claves de
paso normalmente) no pueda ser usada por un atacante que haya conseguido
interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá
será un flujo de datos cifrados que le resultará imposible de descifrar.
Desarrollado por Netscape, SSL versión 3.0 se publicó en 1996, que más tarde
sirvió como base para desarrollar TLS versión 1.0, un estándar protocolo IETF
definido por primera vez en el RFC 2246. Visa, MasterCard, American Express y
muchas de las principales instituciones financieras han aprobado SSL para el
comercio sobre Internet.
SSL opera de una manera modular: sus autores lo diseñaron extensible, con
soporte para compatibilidad hacia delante y hacia atrás, y negociación entre las
partes (peer-to-peer).
Como el término lo indica basadas en IP, el servidor debe tener una dirección IP
diferente para cada host virtual basado en IP. Esto se puede lograr por la
máquina que tiene varias conexiones de red física, o por el uso de interfaces
virtuales que son compatibles con los sistemas operativos más modernos (consulte
la documentación del sistema para obtener más información, estos son
frecuentemente llamados "alias de IP", y es el "ifconfig" comando más comúnmente
utilizados para su realización).
Hay dos formas de configurar Apache para soportar múltiples hosts. Ya sea
mediante la ejecución de un separado httpd demonio para el nombre de host, o
mediante la ejecución de un solo demonio que apoya a todos los hosts virtuales.
Crea una partición httpd instalación para cada máquina virtual. Para cada
instalación, el uso de la Listen directiva en el fichero de configuración para
seleccionar el que los demonios dirección IP (o máquina virtual) que. por ejemplo,
Listen www.smallco.com:80
Para este caso, un httpd solo atenderá las solicitudes para el servidor principal y
todos los hosts virtuales. El VirtualHost directiva en el fichero de configuración se
utiliza para establecer los valores de ServerAdmin , ServerName , DocumentRoot ,
ErrorLog y TransferLog o CustomLog directivas de configuración para diferentes
valores para cada máquina virtual. por ejemplo,
<VirtualHost www.smallco.com>
ServerAdmin [email protected]
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
<VirtualHost www.baygroup.org>
ServerAdmin [email protected]
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>
Para usar hosting virtual basado en nombres, debe especificar en el servidor qué
dirección IP (y posiblemente qué puerto) se va a usar para atender las peticiones a
los diferentes hosts. Esto se hace con la directiva NameVirtualHost. Normalmente,
cualquiera o todas las direcciones IP del servidor pueden usarse, también puede
usar * como argumento para la directiva NameVirtualHost. Si va a usar más de un
puerto (por ejemplo si va usar SSL) debe añadir un puerto a cada argumento, por
ejemplo *:80. Tenga en cuenta que especificando una dirección IP en la directiva
NameVirtualHost no hace que el servidor escuche automáticamente en esa
dirección IP. Consulte la sección Especificar las direcciones y puertos que usa
Apache para obtener más información. Además, cualquier dirección IP especificada
debe asociarse con un dispositivo de red del servidor.
El siguiente paso es crear un bloque <VirtualHost> para cada host diferente que
quiera alojar en el servidor. El argumento de la directiva <VirtualHost> debe ser el
mismo que el argumento de la directiva NameVirtualHost (por ejemplo, una
dirección IP, o un * para usar todas las direcciones que tenga el servidor). Dentro
de cada bloque <VirtualHost>, necesitará como mínimo una directiva ServerName
para designar qué host se sirve y una directiva DocumentRoot para indicar dónde
están los contenidos a servir dentro del sistema de ficheros.
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost *:80>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
También puede que quiera que se acceda a un determinado sitio web usando
diferentes nombres. Esto es posible con la directiva ServerAlias, puesta dentro de
la sección <VirtualHost>. Por ejemplo, en el primer bloque <VirtualHost> de arriba,
la directiva ServerAlias indica la lista de nombres que pueden usarse para acceder
a un mismo sitio web:
entonces las peticiones para todos los hosts en el dominio domain.tld serán
servidas por el host virtual www.domain.tld. Los carácteres comodines * y ?
pueden usarse para encontrar equivalencias con los nombres. Por supuesto, no
puede inventarse nombres y ponerlos en la directiva ServerName o ServerAlias.
Primero debe tener su servidor de DNS debidamente configurado para que pueda
hacer corresponder esos nombres con una dirección IP de su servidor.
Cuando llega una petición, el servidor primero verifica si se está usando una
dirección IP que coincide con el valor de la directiva NameVirtualHost. Si es el caso,
mirará en cada sección <VirtualHost> cuya IP coincida e intentará encontrar si el
valor de la directiva ServerName o de la directiva ServerAlias coincide con el
nombre del sitio web de la petición. Si encuentra una coincidencia, usa la
configuración de ese servidor. Si no la encuentra, usa el primer host virtual de la
lista cuya dirección IP coincida con el de la petición.
Como consecuencia, el primer host virtual de la lista es el que se usa por defecto. La
directiva DocumentRoot del servidor principal no se usará nunca cuando una
dirección IP coincida con el valor de la directiva NameVirtualHost. Si quiere usar
una configuración especial para peticiones que no coinciden con ningún host
virtual en concreto, ponga esa configuración en una sección <VirtualHost> y
póngala la primera en el fichero de configuración.
El número de puerto por defecto para HTTP es 80. Sin embargo, la mayoría de
servidores web se puede configurar para funcionar en casi cualquier número de
puerto, siempre que el número de puerto no está en uso por cualquier otro
programa en el servidor.
Por ejemplo, un servidor puede alojar el sitio web www.example.com. Sin
embargo, si el propietario desea operar un segundo sitio, y no tiene acceso a la
configuración del nombre de dominio para su nombre de dominio y / o no posee
otras direcciones IP que pueden ser utilizados para servir el sitio de, en su lugar
podría utilizar otro número de puerto, por ejemplo, www.example.com:81 para el
puerto 81, www.example.com:8000 para el puerto 8000,
o www.example.com:8080 para el puerto 8080.
Sin embargo, este es un enfoque de usuario poco amigable. Los usuarios no se
puede esperar razonablemente que saber los números de puerto para sus sitios
web y móvil de un sitio entre los servidores puede requerir cambiar el número de
puerto. No se usen los números de puerto estándar también puede ser visto como
poco profesional y poco atractivo para los usuarios. Además, algunos firewalls
bloquear todos los puertos, pero la más común, provocando un sitio alojado en un
puerto no estándar que no aparecen disponibles para algunos usuarios.
No son tan baratos como los compartidos, ni tan caros como los dedicados. Sin
tantas ventajas técnicas como éstos últimos, pero sin tantos inconvenientes como
los primeros. Una buena elección intermedia.
Usos
Puente de servidores privados virtuales la brecha entre los servicios de
alojamiento web compartido y hosting dedicado , lo que la independencia de otros
clientes del servicio de VPS en términos de software, pero a menor costo que un
servidor dedicado físico. Como VPS ejecuta su propia copia de su sistema
operativo, los clientes tienen superusuario nivel de acceso a esa instancia del
sistema operativo, y se puede instalar casi cualquier software que se ejecuta en el
sistema operativo. Cierto tipo de software no funciona bien en un entorno
virtualizado, como virtualizers sí mismos, algunos proveedores de VPS imponer
mayores restricciones, pero en general son laxas en comparación con los entornos
de alojamiento compartido. Debido a la cantidad de clientes de virtualización
generalmente se ejecuta en una sola máquina, un VPS en general ha limitado el
tiempo de procesador, memoria RAM y espacio en disco.