sábado, 22 de mayo de 2010

VirtualBox 3.2.0 disponible

Desde hace unos días -se ha liberado el 18 de Mayo- se encuentra disponible para su descarga la versión 3.2.0 de Virtual Box. Debido a la compra de la compañía por parte de Sun, ahora pasa a llamarse Oracle VM VirtualBox.


Entre las novedades que la nueva versión  promete, están la compatibilidad con los nuevos sistemas operativos de Microsoft, Linux, Solaris y su compatibilidad con los sistemas Mac OS X.


Lo cierto es que precisamente andaba estos días con problemas a la hora de instalar en la máquina virtual la nueva versión de Ubuntu - 10.04- y tras actualizarme a la nueva versión va la barrita de instalación en el 93% de hecho esta es la razón de comentar una actualización de un producto aquí, ya que no soy muy partidario de ir comentando cada versión de un programa.


P.D. espero que aprovechéis el buen tiempo este fin de semana y no os tengáis que "encerrar" para currar como el que  suscribe.
Enlaces:

viernes, 21 de mayo de 2010

Servidor LDAP en Ubuntu

Instalación y Configuración de OpenLDAP

El servido OpenLDAP nos provee de un modo sencillo de centralizar la autenticación de usuarios y servicios en una única base de datos de rápida lectura, de modo que podamos hacer que cualquier servicio ( ftp, web, correo,...) autoricen o no el acceso dependiendo de los datos, por ejemplo, de usuario y contraseña que hayamos configurado en el mismo.

1.- Instalación de OpenLDAP

En primer lugar instalamos el demonio servidor slapd, ldap-utils -paquete que contiene utilidades para el manejo de LDAP y db4.2-util – que proporciona herramientas para realizar algunas operaciones con bases de datos como pueden ser cargas, modificaciones o actualizaciones del formato de las mismas-:


sudo apt-get install slapd ldap-utils db4.2-util

Durante la instalación nos pedirá que introduzcamos una contraseña para identificar al administrador de ldap.

Por defecto, además, el sufijo del directorio coincidirá con el nombre de dominio del servidor. Por ejemplo si el FQDN (Fully Qualified Domain) es ldap.ejemplo.com, el sufijo por defecto será dc=example,dc=com. Si queremos cambiarlo lo podremos hacer usando dpkg-reconfigure dónde podremos configurar varias opciones de slapd (en nuestro caso no sería necesario ya que el dominio de nuestro equipo ya era el deseado: mczones.es).

sudo dpkg-reconfigure slapd

Nos aparecerá un asistente que nos pedirá los siguientes datos:

  • Si deseamos omitir la configuración del servidor LDAP. Obviamente responderemos que no, ya que precisamente lo que queremos es configurar el servidor LDAP.

  • Nuestro directorio LDAP base , habitualmente se utiliza el nombre del dominio. Ejemplo, si nuestro dominio es mczones.es, lo normal es que la base para nuestrodirectorio LDAP sea: dc=mczones,dc=es.

  • Nombre de nuestro dominio. Éste nombre lo utilizará para crear el nombre distinguido (DN) o dicho más claramente, nombre identificativo de la base de nuestrodirectorio LDAP: mczones.es.

  • Posteriormente nos preguntará por el nombre de nuestra organización: mczones.

  • Contraseña que deseamos poner al usuario admin (administrador) del servidor LDAP. La solicitará dos veces para evitar errores de tecleo. Podemos poner cualquier contraseña, por ejemplo 'root'.

  • Acto seguido nos informará sobre los posibles gestores de datos para almacenar el directorio y nos preguntará qué sistema utilizar. Lo recomendable es utilizar el sistema HDB.

  • Si queremos que se elimine la base de datos cuando quitemos slapd. Por si acaso, lo mejor es responder que no.

  • En el caso de que exista una base de datos LDAP previa, nos preguntará si deseamos moverla. Lo mejor es responder Sí, para evitar que interfiera en la nueva base de datos:

  • Luego nos preguntará si deseamos utilizar LDAP versión 2, respondemos que no ya que apenas se utiliza.

  • Finalmente nos da la oportunidad de omitir la configuración. Si respondemos que sí, será como que no hemos ejecutado el asistente, por lo tanto si nuestra intención es configurar el servidor LDAP responderemos no.

2.- Configuración del servidor OpenLDAP

En versiones anteriores openldap se configuraba el comportamiento del servidor empleando únicamente el fichero slapd.conf, actualmente podemos hacer modificaciones dinámicamente -con lo que no es necesario parar y reiniciar el demonio slapd para realizar cada cambio- desde la base cn=config; se puede acceder a ella desde phpldapadmin con el usuario cn=admin,cn=config y la contraseña del admin, para luego buscar como está configurado, también podremos emplear las herramientas de línea de comandos que hemos instalado. Por ejemplo para comprobar el árbol de directorio creado durante la instalación o tras la reconfiguración (nos pedirá la contraseña de administrador del sistema LDAP):

ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb

image

2.1 Instalación y configuración de phpLDAPadmin

PhpLDAPadmin es una aplicación web que nos permitirá acceder al directorio LDAP para poder crear y modificar elementos. Otros posibles exploradores LDAP libres podrían ser gq y Jxexplorer.

Para instalar phpldap admin:

sudo apt-get install phpldapadmin

Esto nos instalará también apache -el servidor web-. Si estamos en el servidor, simplemente teclearemos en la barra de direcciones de nuestro explorador web: http://localhost/phpldapadmin/. Si se produce el error : “Memory Limit Low. Your php memory limit is low -currently 16 M” deberemos aumentar la memoria, por ejemplo a 64M, en el fichero /etc/php5/apache2/php.ini
(editamos el fichero /etc/php5/apache2/php.ini y ponemos: memory_limit = 64M ; ) y reiniciamos el servidor apache: /etc/init.d/apache2 restart.

En la versión de phpLDAPadmin que he instalado (1.1.05-6) cuando entramos por primera vez, en el panel izquierdo nos aparece el dominio de ejemplo (example.com) en lugar del que hemos configurado; para solucionarlo editamos el fichero /etc/phpldapadmin/config.php y cambiamos las líneas:

$ldapservers->SetValue($i,'server','base',array('dc=example,dc=com')); por

$ldapservers->SetValue($i,'server','base',array('dc=mczones,dc=es'));

si además queremos que cuando nos solicite el login, también aparezca el dominio correcto en el campo nombre de usuario, deberemos sustituir también:

$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com'); por

$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com');

Tras realizar estos dos cambios deberemos reiniciar el servidor apache: /etc/init.d/apache2 restart.

En la versión de phpLDAPadmin que he instalado (1.1.05-6) cuando entramos por primera vez, en el panel izquierdo nos aparece el dominio de ejemplo (example.com) en lugar del que hemos configurado; para solucionarlo editamos el fichero /etc/phpldapadmin/config.php y cambiamos las líneas:

$ldapservers->SetValue($i,'server','base',array('dc=example,dc=com')); por

$ldapservers->SetValue($i,'server','base',array('dc=mczones,dc=es'));

si además queremos que cuando nos solicite el login, también aparezca el dominio correcto en el campo nombre de usuario, deberemos sustituir también:

$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com'); por

$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com');

Tras realizar estos dos cambios deberemos reiniciar el servidor apache: /etc/init.d/apache2 restart.

2.2 Creación de Unidades organizativas, grupos y usuarios con phpLDAPadmin

Una vez hemos entrado en el sistema como cn=admin,dc=mczones,dc=es y password -en mi caso- ldapadmin, podemos crear la estructura del dominio. Para ello pulsamos en crear nuevo objeto y seleccionamos “Organisational Unit” para crear las unidades organizativas, en mi caso:

image image

  • Grupos: Dentro de ella crearé los “Posix Groups” “contabilidad” , “desarrollo” y “otros” a los que pertenecerán todos los usuarios.
  •  

  • Usuarios: en ella crearé directamente los usuarios que pertenezcan al grupo “otros”. Igualmente para mantener el orden crearé dos unidades organizativas:

    • Contabilidad: En ella iré añadiendo los User Account de este departamento: c1 y c2 pertenecientes al posix group “contabilidad” con contraseña “1234”.

    • Desarrollo: en ella he añadido los “User Account” d1 y d2 pertenecientes al Posix Group Desarrollo con contraseña “1234”.

    • En la unidad organizativa Usuarios he creado el usuario juan.

3.- Configuración de los clientes: Autenticación con OpenLDAP

Una de las principales razones para usar LDAP es centralizar la autenticación de los usuarios en un único sistema servidor (ya sea para iniciar sesión, ftp, web, correo,...), en lugar de utilizar los clásicos archivos /etc/passwd, /etc/group y /etc/shadow. Para ello veremos las modificaciones que hay que realizar en un sistema Linux para que autentifique a los usuarios en un servidor LDAP, en primer lugar, será necesario instalar y configurar los paquetes libpam-ldap y libnss-ldap.

La librería pam-ldap permite que las aplicaciones que utilizan PAM para autentificarse, puedan hacerlo mediante un servidor LDAP. Para que el sistema linux se autentifique mediante un servidor LDAP es necesario instalar esta librería ya que utiliza PAM. El archivo de configuración de ésta librería es /etc/ldap.conf. Hay otras aplicaciones o servicios que utilizan PAM para la autentificación y por tanto podrían, gracias a la librería pam-ldap, autentificarse ante un servidor LDAP. Para especificar el modo de autentificación de cada servicio es necesario configurar los archivos que se encuentran en la carpeta /etc/pam.d/.

La librería nss-ldap permite que un servidor LDAP suplante a los archivos /etc/passwd, /etc/group y /etc/shadow como bases de datos del sistema. Su archivo de configuración se encuentra en /etc/libnss-ldap.conf (o /etc/ldap.conf en versiones recientes como la que he usado yo, la 2.4.2). Posteriormente deberemos configurar el arhivo /etc/nsswitch.conf para que se utilice LDAP como base de datos del sistema en lugar de los archivos passwd, group y shadow

3.1 Instalación y configuración de libpam-ldap

La instalación de la librería libpam-ldap se puede realizar ejecutando el comando (instalará ya todas librerías necesarias como libnss-ldap):

# apt-get install libpam-ldap

Nos lanzará un asistente que nos pedirá los siguientes datos, que se almacenarán en el fichero /etc/lapd.conf desde dónde podremos modificarlos en cualquier momento a posteriori (basado en la versión 2.4.2 de openldap):

  1. Quién es el servidor LDAP (nombre o IP) *en el caso de emplear la ip deberemos escribir ldap no ldapi, ya que sino resolverá el finger pero no nos permitirá autenticarnos: ldap://192.168.2.3/

  2. Cuál es la base de nuestro directorio LDAP (base DN): dc=mczones,dc=es

  3. Cuál es la versión de LDAP a utilizar: 3

  4. Hacer que las utiliadades password que usen ldap se comporte como si cambiaramos las locales:si

  5. Necesitamos conectarnos a la base de datos LDAP para recibir las entradas: NO

  6. Cuenta LDAP para el usuario root: cn=admin,dc=mczones,dc=es

  7. Contraseña del administrador.

Finalmente tendremos, por lo tanto, las siguientes líneas en el fichero /etc/ldap.conf

// Configurar en /etc/ldap.conf
host 192.168.2.3 //nombre o IP del servidor LDAP
base dc=mczones,dc=es
uri ldap://192.168.2.3
ldap_version 3
rootbinddn cn=admin,dc=mczones,dc=es
pam_password md5
nss_base_passwd ou=usuarios,dc=mczones,dc=es?sub
nss_base_shadow ou=usuarios,dc=mczones,dc=es?sub
nss_base_group  ou=grupos,dc=mczones,dc=es?sub
Tras el carácter “?”, se puede poner one (por defecto), base o sub; yo he empleado sub para que también compruebe los usuarios y contraseñas creados colgando de la unidad organizativa   “usuarios” -es decir en las unidades organizativas contabilidad y desarrollo-.



3.1 Configuración de NSS


Para que el servidor LDAP actúe como si se tratara de los archivos passwd, group y shadow, además de instalar las dos librerías anteriores, debemos indicar que se utilice LDAP como alternativa para autentificar usuarios. Para ello hay que añadir en las líneas que hacen referencia a passwd, group y shadow en el archivo /etc/nsswitch.conf, la palabra 'ldap' tras la palabra 'compat' quedando el archivo /etc/nsswitch.conf así:




// Archivo /etc/nsswitch.conf
# /etc/nsswitch.conf
passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis



3.2 Configuración de servicios PAM


Nuestro sistema ya estaría preparado para autentificarse por LDAP. Editando los archivos que hay en la carpeta /etc/pam.d, podemos configurar la forma en la que se autentifica cada uno de los servicios que requieren autentificación. Para no tener que configurar de cada uno de los servicios, existen unos archivos comunes cuyo nombre empieza por common que afectan a la mayoría de ellos y sus archivos de configuración los referencian mediante una línea @include a los archivos comunes causando el mismo el efecto que si el contenido de los archivos comunes estuviera copiado en el lugar de la línea @include. Los archivos comunes son:




  • /etc/pam.d/common-auth (para autentificarse)



  • /etc/pam.d/common-account (para disponer de una cuenta)



  • /etc/pam.d/common-session (para poder iniciar sesion)



  • /etc/pam.d/common-password (para poder cambiar password)




La configuración de los archivos comunes para emplear LDAP se puede hacer deimage modo automático tecleando en consola pam-auth-update que nos permite seleccionar el perfil a emplear. Si queremos que cada vez que entremos en una sesión se verifique si el usuario ya tiene un directorio personal (home) en el equipo para que si no es así sea creado (la primera vez me advertirá como se ve en la imagen que va a crear el directorio personal), deberíamos añadir la siguiente línea al final del fichero /etc/common-session:



session required pam_mkhomedir.so skel=/etc/skel/ umask=0022



Si deseamos que algún servicio se autentifique de forma diferente, podemos editar el archivo del servicio (ej: /etc/pam.d/su, /etc/pam.d/ssh, /etc/pam.d/ftp, etc...), eliminar la línea que comienza por @include e introducir la configuración particular que deseemos.



3.3 Probar la autentificación


image Ahora mismo ya deberíamos poder autentificarnos de modo correcto. Para probarlo podemos emplear el comando pamtest que está en el paquete libpam-dotfile:



sudo apt-get isntall libpam-dotfile



Podemos probar si funciona el cambo de contraseña sobre cualquier usuario sobre c2, por ejemplo.



También podemos usar el comando finger sobre usuarios que sólo estén en LDAP y en sistema local.image



Incluso podemos emplear, directamente el comando su desde la consola para cambiarnos a los usuarios que sólo estén dados de alta en el sistema LDAP.



Tras ello ya podremos cerrar sesión y entrar en los equipos como los usuarios dados de alta en LDAP:



image





image



4. Otros ficheros y directorios



Además de los citados ficheros se deberían tener presentes los siguientes:




  • Para logs: /var/log/syslog y /var/log/auth.log



  • Almacenar la Base de datos y los backups: /var/lib/ldap y /var/backups respectivamente



  • Fichero de configuración del demonio slapd en el servidor: /etc/default/slapd




para continuar viendo el resto de manuales Linux siga el enlace:administración de servidores con Linux


5. Enlaces







Samba PDC en Debian :: Improvisa :: Magazine Digital :: Informatica ...



Ubuntu Server PDC - Página 5 | jorge.herskovic | Jorge Herskovic



OpenLDAP-SambaPDC-OrgInfo-Posix - Community Ubuntu Documentation



Installing custom ldap schema 6.0 - Zimbra :: Wiki



OpenLDAPServer - Community Ubuntu Documentation



Linux Tutorial - Apache Web Login Authentication:



Configurar un servidor Controlador de Dominio con Samba y OpenLDAP en Ubuntu Server Hardy 8.04



En busca de la solución definitiva para la autenticación | CRySoL



How-To set up a LDAP server and its clients -- page 2 | Debian/Ubuntu ...



OpenLDAP Server


martes, 18 de mayo de 2010

O nivel de aplicación

Artículo copiado da páxina do IES S. Clemente de Santiago.

Contenido

 
 

Introdución

Neste tema descríbese toda unha serie de aplicacións ou programas que utilizan a rede como medio de comunicación, así como os protocolos de comunicacións que teñen asociados. Devanditas aplicacións coñécense como aplicacións distribuídas, posto que están formadas por diferentes partes e cada unha se atopa en máquinas diferentes. Por norma xeral, hai unha parte chamada servidor que se executa nun computador, á que se conectan os diferentes clientes (que se atopan noutros computadores remotos) para requirir os seus servizos (polo xeral, solicitan a execución dalgún tipo de operación).

Existe unha gran cantidade de aplicacións que seguen este modelo e que, nalgúns casos, usamos diariamente, entre elas: o correo electrónico, a navegación Web, a mensaxería instantánea, a telefonía IP, o acceso remoto a outros computadores, a vídeoconferencia, a computación paralela masiva, a compartición de ficheiros, os xogos en rede multiusuario, a descarga de vídeo e audio e un longo etc.

Estas aplicacións empregan protocolos concretos para poder entenderse. Este protocolos atópanse no nivel de aplicación.

Arquitecturas de aplicacións en rede

As aplicacións execútanse en diferentes computadores no que se coñece como sistemas finais, e comunícanse mediante a rede. Por exemplo: un programa que fai de servidor Web comunícase cun programa navegador. Xa que logo, a comunicación para unha aplicación en rede ten lugar entre sistemas finais no nivel de aplicación.

Hai tres tipos de arquitecturas para as aplicacións en rede:

  • Arquitectura Cliente/Servidor
  • Arquitectura Peer-to-peer (P2P)
  • Arquitectura híbrida entre cliente/servidor e P2P

Arquitectura cliente/servidor

O modelo ou arquitectura cliente/servidor está formado por dúas partes.

  • O servidor. Sempre está funcionando (24x7) e ten unha dirección IP permanente. Pódense instalar granxas ou clusters de servidores para dar servizo a un maior número de usuarios.
  • Os clientes. Poden estar conectados intermitentemente. As súas direccións IP son dinámicas. Os clientes non se comunican directamente entre eles, senón que o fan co servidor

Moitas das aplicacións de uso frecuente de Internet, como a navegación Web ou o correo electrónico, usan este modelo.

Arquitectura P2P pura

Este modelo ten unhas características diferenciadas respecto á cliente/servidor pura. Estas diferenzas son as seguintes:

  • Non existe un servidor acendido permanentemente
  • Non se distingue entre clientes e servidores, senón que existen sistemas arbitrarios finais, chamados peers, que se comunican directamente
  • Os peers están conectados intermitentemente e cambian a súa dirección IP con frecuencia
  • Todos os nodos teñen a mesma función, peso e importancia dentro da rede


Un exemplo de programa que usa unha arquitectura P2P pura é o software de intercambio de ficheiros Gnutella, que usa protocolo de distribución de ficheiros entre pares, sen un servidor central.


A principal vantaxe desta arquitectura fronte a anterior é que é moi escalable. Como contrapartida é máis difícil de xestionar.

Arquitecturas híbridas C/S e P2P

Son unha mistura das anteriores. De tal xeito que para algunhas funcións usan un servidor central e para outras fan unha comunicación directa con outro peer. Vexámolo con dúas aplicacións de exemplo:

  • eMule. No programa de intercambio de ficheiros eMule a transferencia de ficheiros realízase mediante P2P. Con todo, a busca de ficheiros é centralizada xa que os pares, ou peers, rexistran contido nun servidor central (os ficheiros que comparten). Para localizar un contido, o pares consultan un servidor central ou varios servidores distribuídos, pero para a transferencia usan P2P.
  • Mensaxería instantánea. As conversas que se manteñen entre dous usuarios realízase mediante P2P, pero o rexistro e localización é mediante C/S, é dicir, centralizada nun servidor. De feito, os usuarios rexistran a súa IP nun servidor cando arrincan o programa. Este servidor é un servidor central de contactos para IP de amigos.

Comunicación de procesos

Un proceso é un programa que se executa nun computador. Un proceso cliente é o que inicia a comunicación. Un proceso servidor é o que espera a ser contactado. Por exemplo: O programa dhclient lanza un proceso cliente que solicita unha dirección IP. O programa dhcpd espera a recibir peticións para respostar con direccións IP dinámicas aos clientes.

As aplicacións están formadas por varios procesos. No caso das arquitecturas P2P as aplicacións teñen procesos clientes e procesos servidores ao mesmo tempo.

Os procesos pertencen a un usuario que, normalmente, os lanza ou provoca que se lancen. Para ver os procesos dun usuario que se están executando nun computador para podes teclear:

ps ­-u nome_usuario


Nun computador pode haber varios procesos executándose polo que se identifican mediante un número de porto. Os procesos comunícanse uns cos outros a través dos sockets. Un socket especifica a dirección, o porto e o protocolo de transporte que se usa na comunicación. Por exemplo: (192.168.100.10, 80, TCP).




Protocolos do nivel de aplicación



Os procesos comunícanse enviándose mensaxes. As características destas mensaxes están determinadas no protocolo, o cal define:



  • Os tipos de mensaxes que se intercambian, i.e: mensaxes de solicitude e resposta
  • A sintaxe dos tipos de mensaxe, i.e: campos que terán as mensaxes
  • A semántica dos campos, é dicir, o que significa a información dos campos das mensaxes
  • As regras sobre cando e como os procesos poden enviar e respostar mensaxes


Os protocolos do nivel de aplicación poden ser de dominio público ou propietarios. No primeiro caso, están definidos nos RFC (Request For Comments). Ao estar publicamente accesibles permiten a interoperabilidade entre aplicacións de distintos fabricantes. Exemplos deste tipo de protcolos son HTTP (HyperText Transfer Protocol) ou o SMTP (Single Mail Transfer Protocol). No segundo caso é o fabricante dun determinado software quen o define e a interoperabilidade non está garantida. Un exemplo deste tipo de protocolos é o que usa a aplicación Skype.




O HTTP




Un pouco de historia



O HTTP naceu no 1989 no CERN (Centro Europeo de Investigación Nuclear). A Web xurdiu pola necesidade de lograr que os equipos de investigadores dispersos internacionalmente colaborasen, usando un conxunto sempre cambiante de informes, planos, debuxos, fotos e outros documentos.



A proposta inicial dunha rede (web) de documentos vinculados xurdiu do físico do CERN Tim Berners-Le. O primeiro prototipo estaba baseado só en texto. En decembro de 1991 fíxose unha demostración pública e o desenvolvemento continuou durante o seguinte ano, culminando coa liberación da primeira interface gráfica, Mosaic, no ano 1993. Mosaic tivo tanto éxito que, un ano despois, o seu autor, Marc Andreeseen formou a compañía, Netscape Communications Corp.



En 1994, o CERN e o M.I.T. asinaron un acordo para establecer o World Wide Web Consortium, unha organización adicada ao desenvolvemento da Web, a estandarización de protocolos e o fomento da interoperabilidade entre as instalacións. Berners-Le converteuse no director.




Conceptos previos



As páxinas Web están formadas por obxectos. Os obxectos poden ser ficheiros HTML, imaxes, ficheiros de audio, vídeo, etc. Unha páxina web é un ficheiro HTML base que inclúe varias referencias aos obxectos. A cada obxecto accédese mediante unURL (Uniform Resource Locator) que ten a seguinte forma:








Características





O HTTP é un protocolo do nivel de aplicación para a Web. Segue o modelo ouarquitectura cliente/servidor, tal e como se ve na figura. O cliente é un navegador (browser) que solicita, recibe, e mostra obxectos Web. O servidor Web envía obxectos como resposta ás peticións do cliente. Hai dúas versións do protocolo, o HTTP 1.0, especificada no RFC 1945, e o HTTP 1.1, especificado no RFC 2068.



HTTP utiliza TCP como protocolo de transporte. Os clientes inician conexións TCP (crean un socket) co servidor, no porto 80. Os servidores aceptan conexións TCP dos clientes. Unha vez establecida a conexión intercámbianse mensaxes HTTP (mensaxes do protocolo do nivel de aplicación) entre o cliente (cliente HTTP) e o servidor Web (servidor HTTP). Finalmente, péchase a conexión TCP.



HTTP non ten “estados” (stateless). Isto quere dicir que o servidor non mantén información sobre solicitudes anteriores dos clientes. Deseñouse así porque os protocolos que manteñen o estado son complexos, xa que hai que manter un histórico do que acontece (estado). Se o cliente ou o servidor fallan pode haber inconsistencias e deberán volver ao estado anterior, co correspondente consumo de recursos.




Tipos de conexións



As conexións HTTP poden ser de dous tipos:



  • Conexión non persistentes. Nelas, envíase un obxecto como máximo en cada conexión TCP. Para cada nova petición do cliente precísase unha nova conexión TCP. HTTP/1.0 utiliza HTTP non persistente. Por exemplo, se unha páxina Web ten referencias a 10 obxectos, abriranse 10 conexións TCP.
  • Conexións persistentes. Envíanse varios obxectos nunha única conexión TCP entre o cliente e o servidor. HTTP/1.1 utiliza conexións persistentes por defecto. As conexións persistentes supoñen menos sobrecarga para o SO xa que os navegadores non abren varias conexións TCP paralelas para conseguir os obxectos referenciados. O servidor deixa a conexión TCP aberta despois de enviar unha resposta, xa que logo, as mensaxes HTTP entre o mesmo cliente e servidor usan a mesma conexión TCP.



Mensaxes



En HTTP hai mensaxes de solicitude e mensaxes resposta. Ambas as dúas mensaxes están en formato ASCII, polo que poden verse e lerse se capturamos unha sesión HTTP cun analizador de rede como, por exemplo, o Wireshark.




Solicitudes



Unha mensaxe HTTP de solicitude ten o seguinte formato:







Se queremos facer unha solicitude de envío de datos (por exemplo, cando facemos unha consulta nun buscador enviámoslle ao servidor a palabra a buscar, ou cando enviamos un formulario) podemos usar dous métodos:



  • Método POST, no que os datos se envían ao servidor dentro da mensaxe de solicitude HTTP.
  • Método URL, tamén chamado método GET, no que os datos se envía na URL da liña de solicitude, por exemplowww.unsite.com/buscaAnimal?mono&banana


Dependendo da versión do protocolo que se use están soportadas distintas mensaxes HTTP (tamén coñecidas como métodos):



  • Para HTTP 1.0: están soportadas as mensaxes GET e POST xa vistas. Tamén está soportada a mensaxe HEAD que só devolve a cabeceira, non o obxecto referenciado
  • Para HTTP 1.1: están soportadas as tres mensaxes anteriores e tamén PUT, que permite subir o ficheiro especificado no URL ao servidor, e DELETE, que permite borrar o ficheiro especificado no URL.



Respostas



As mensaxes HTTP de resposta teñen un formato similar ás de solicitude:







As mensaxes de resposta inclúen un código dependendo do significado da mesma. Dito código vai na primeira liña da mensaxe (liña de estado). Algúns exemplos son os seguintes:





200 OK
Solicitude correcta, envíarase o obxecto solicitado nesta mensaxe   301 Moved Permanently
Obxecto solicitado noutro URL, especifícase a nova localización nesta mensaxe (Location:)   400 Bad Request
Mensaxe non entendida polo servidor   404 Not Found
Obxecto solicitado non atopado no servidor   505 HTTP Version Not Supported





As cookies





Dixemos que HTTP é un protocolo sen estado. Isto, ás veces, pode non ser o desexado. Por exemplo, supoñamos que temos unha web na que as súas páxinas están restrinxidas a determinados usuarios. Se non mantemos o estado do cliente teremos que estar solicitándolle para cada páxina que queira ver o seu nome de usuario e clave. HTTP resolve este escenario coas cookies.



As cookies están definidas no RFC 2109 e permiten monitorizar a navegación do usuario. Moitos sites usan cookies. Son útiles, por exemplo, para validar un usuario, escoller opcións personalizadas (idioma, etc.), rexistrar hábitos de navegación, etc. Están formadas por catro compoñentes:



  1. Liña de cabeceira da cookie na resposta HTTP.
  2. Liña de cabeceira da cookie na solicitude HTTP.
  3. Ficheiro que se mantén no computador do cliente, xestionado polo navegador.
  4. Base de datos no servidor.


Un exemplo de funcionamento das cookies podémolo ver na figura.




Servidores Proxy





Dun modo xenérico, pódese definir un proxy como un software que fai de intermediario entre un cliente e un servidor. Os proxies en HTTP úsanse, entre outras cousas, para facer de caché das páxinas visitadas. É o que se coñece como un Web cache e o seu obxectivo é respostar aos clientes sen interactuar co servidor, gañando en velocidade, xa que o proxy está normalmente na mesma rede ou máis cercano que o servidor Web que contén a páxina orixinal.



O proxy configúrase no navegador. É o navegador quen envía as solicitudes HTTP ao proxy. Se o obxecto está na cache o proxy é quen o devolve. Se non, o proxy solicita o obxecto ao servidor orixinal que á súa vez é enviado ao cliente. O proxy ten, xa que logo, unha parte cliente e outra servidor. Normalmente instálanse en universidades, compañías, ISP, etc., para axilizar o tráfico. Entre as vantaxes de usar un servidor proxy están as seguintes:



  • Reducir o tempo de resposta das solicitudes dos clientes.
  • Reducir o tráfico, e polo tanto ampliar o largo de banda.
  • Filtrar contido.






Un exemplo de software de servidor proxy é o Squid.




Instalación e configuración do Apache



Instalación e configuración do servidor Web Apache




O File Transfer Protocol



O FTP




O DNS



O DNS




O correo electrónico



O correo-e