420-283 Programmation d'un serveur 1. L'environnement de travail L'objectif de ce cours est de développer des applications clients-serveur utilisant des bases de données. Le modèle selon lequel fonctionne ce type d'applications est le suivant : Session H-2009 2009, Marc-Gabriel Vallières page 1-1
1.1 Une station cliente Client HTTP Encodage SSL Client FTP Client SMTP Client POP Client NNTP HyperText Transfer Protocol Le client HTTP permet la réception et l'affichage sur la station de travail de pages codées en HTML (HyperText Markup Language) et stockées sur un serveur HTTP, d'objets référencés par ces pages (sons, images, documents, etc.) ainsi que l'interprétation des scripts imbriqués dans ces pages. Secure Socket Layer L'encodage SSL permet le transfert sécurisé d'informations dans des pages utilisant des sockets HTTPS où les informations sont encryptées. File Transfer Protocol Le client FTP permet le transfert de fichiers entre un serveur FTP et la station de travail. Simple Mail Transfer Protocol La communication avec un serveur SMTP permet l'envoi de messages de courriel. Post Office Protocol La communication avec un serveur POP permet la réception de messages stockés dans une boîte à malle située sur le serveur POP. Network News Transfer Protocol Le client NNTP permet la réception et l'affichage sur la station de travail de banques de messages («news») stockés dans un babillard (serveur NNTP). Session H-2009 2009, Marc-Gabriel Vallières page 1-2
1.2 Un serveur Internet (web et courrier) Serveur HTTP Encodage SSL/TSL Serveur FTP Serveur SMTP HyperText Transfer Protocol Le serveur HTTP permet la transmission vers des stations de travail clientes de pages codées en HTML ainsi que d'autres objets (images, sons, documents, etc.). Secure Socket Layer L'encodage SSL permet le transfert sécurisé d'informations dans des pages utilisant des sockets HTTPS où les informations sont encryptées. File Transfer Protocol Le serveur FTP permet le transfert de fichiers entre un serveur FTP et la station de travail ainsi que le contrôle des utilisateurs y ayant droit. Simple Mail Transfer Protocol Le serveur SMTP ne vise pas ici l'envoi de messages de courriel par une station cliente, mais bien l'expédition de messages par les applications et les scripts s'exécutant sur le serveur. Session H-2009 2009, Marc-Gabriel Vallières page 1-3
Langages de scripts PHP, par exemple Un ou plusieurs langages de scripts, installés sur le serveur, vont permettre l'exécution d'applications sur le serveur. Ces applications web vont recevoir les données des stations clientes à partir de formulaires de pages web, expédiées par les navigateurs web des stations clientes et vont communiquer avec ces clients en générant des pages web virtuelles en HTML, qui pourront être affichées par les navigateurs web de ces mêmes stations clientes. Session H-2009 2009, Marc-Gabriel Vallières page 1-4
1.3 Un environnement client-serveur web normal La communication entre l'application cliente et l'application serveur s'effectue au moyen de sockets. Un socket comprend une paire de fichiers, créé par TCP/IP sur les deux ordinateurs qui sont en communication. Tout ce que l'application cliente écrit dans son fichier du socket est automatiquement recopié par TCP/IP dans le fichier correspondant à ce socket sur le serveur. De même, tout ce que le serveur écrit dans son fichier du socket est automatiquement recopié par TCP/IP dans le fichier correspondant à ce socket sur la station cliente. Comme vous le verrez dans le cours d'architecture d'un réseau (420-275), un socket correspond à une adresse IP + un numéro du port. Le navigateur web «lit» donc toujours les pages web dans un fichier temporaire créé par TCP/IP: le socket. Session H-2009 2009, Marc-Gabriel Vallières page 1-5
1.4 La simulation dans le laboratoire Pour fins de test, il est possible d'utiliser le même ordinateur à la fois comme client et comme serveur. Si nous ouvrons un fichier au moyen d'un navigateur web, ce dernier lira le fichier comme s'il était un socket. C'est le cas, par exemple, lorsque nous ouvrons l'url: file:c MonRepertoire/MaPage.htm Ceci fonctionne bien pour un site composé exclusivement d'html, car c'est ce qui est reçu normalement dans un socket par le client. Si le site contient cependant des scripts qui doivent s'exécuter sur le serveur (pour lire une base de données, par exemple), ces scripts ne pourront être exécutés car le navigateur est un client, et non un serveur. Si le serveur web Apache est installé sur notre station de travail et que cette dernière se nomme MaStation («hostname»), nous pouvons faire exécuter les scripts serveurs en faisant ouvrir un socket par TCP/IP entre notre client et notre serveur, même s'ils sont tous deux situés sur la même station, au moyen de l'url: http://mastation/monsite/unscript.asp ou http://localhost/monsite/unscript.asp Session H-2009 2009, Marc-Gabriel Vallières page 1-6
Le navigateur croira alors qu'il est situé sur une station cliente et qu'il communique avec un serveur situé ailleurs sur internet. Apache, quant à lui, se comportera comme un serveur auquel une station cliente, située ailleurs sur internet, enverrait une requête. Aucune de ces deux applications ne saura que les deux extrémités du socket auront été ouvertes sur le même ordinateur. L'utilisation du nom localhost à la place du nom de la station permet de tester les pages web que vous développez sur d'autres ordinateurs. Cela est utile notamment pour remettre vos TP au prof pour qu'il puisse les corriger sans avoir à renommer son serveur! Notez qu'avec Apache, le site appelé ici MonSite correspondra habituellement à un sous-répertoire (dossier) dans le répertoire c:\program Files\Apache Software Foundation\Apache2.2\htdocs qui est le répertoire par défaut des sites web dans Apache. Session H-2009 2009, Marc-Gabriel Vallières page 1-7
1.5 Notre environnement serveur Afin de pouvoir profiter de la communication avec les bases de données, nous ajouterons en cours de session à la configuration serveur décrite précédemment, le serveur de base de données MySQL: L'installation de MySQL version 5.0 permet l'accès à des bases de données relationnelles SQL. Session H-2009 2009, Marc-Gabriel Vallières page 1-8