Topic outline

  • Présentation

    Collapse all Expand all

    Afin de communiquer entre eux, les ordinateurs ont besoin de partager les mêmes protocoles. Il en existe de nombreux, et chacun est destiné à une tâche spécifique. Un protocole détermine comment doit être interpréter le message d'un ordinateur "émetteur", vers un ordinateur "récepteur".

    Par exemple, la description d'un protocole pourrait se décrire comme ceci :

    • Je suis la machine A utilisant le logiciel B
    • Je veux parler au logiciel C de la machine D
    • J'ai E données à communiquer

    Voila, nous avons un protocole de communication entre deux machines. Si les deux savent à quoi correspondent A, B, C, D et E, alors elle vont pouvoir se comprendre et se répondre. Dans notre exemple, A, B, C, D sont ce que l'on appel généralement des "header" (entête), et E est la "payload" (charge utile). Pour simplifier, les headers décrivent les données essentielles à la bonne utilisation d'un paquet, et la payload est l'information que l'on souhaite réellement transmettre.

    Il existe des protocoles "bas niveau", tel que TCP/IP, qui correspond à une couche très basse de l'architecture informatique, et des protocoles "haut-niveau", tel que HTTP, qui s'appuient sur toutes les couches inférieures pour donner l'information finale à l'utilisateur.

    Voici une liste de protocoles fréquemment utilisés en développement web :

    • HTTP et HTTPS (HyperText Transfert Protocol : échange de pages web entre client / serveur)
    • FTP (File Transfert Protocol : utilisé pour l'envoi et réception de fichier)
    • POP / SMTP (Envoi et réception d'e-mail)
    • SSH (SecureShell : accès en ligne de commande à un ordinateur distant)
    • TCP-IP et UDP (protocoles bas niveau permettant le transfert de données)
    • etc...


    Différents protocoles utilisés en web, et leur emplacement dans les couches constituant un système informatique (le modèle OSI) :



    Exemple d'envoi de données via le protocole HTTP :


    Détail du contenu d'une trame :


  • HTTP

    Présentation

    L'Hypertext Transfer Protocol (HTTP, littéralement « protocole de transfert hypertexte ») est un protocole de communication client-serveur développé pour le World Wide Web. HTTPS (avec S pour secured, soit « sécurisé ») est la variante du HTTP sécurisée par l'usage des protocoles SSL ou TLS. HTTP est un protocole de la couche application. Dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise alors par défaut le port 80 (443 pour HTTPS). Les clients HTTP les plus connus sont les navigateurs Web permettant à un utilisateur d'accéder à un serveur contenant les données. Il existe aussi des systèmes pour récupérer automatiquement le contenu d'un site, tel que les aspirateurs de site Web ou les robots d'indexation.


    Historique

    HTTP a été inventé par Tim Berners-Lee avec les adresses Web et le langage HTML pour créer le World Wide Web. La première version de HTTP était très élémentaire, mais prévoyait déjà le support d'en-têtes MIME pour décrire les données transmises. Cette première version reste encore partiellement utilisable de nos jours, connue sous le nom de HTTP/0.9.

    En mai 1996, HTTP/1.0 voit le jour. Cette version supporte les serveurs HTTP virtuels, la gestion de cache et l'identification.

    En janvier 1997, HTTP/1.1 devient finalement standard.Cette version ajoute le support du transfert en pipeline (ou pipelinage) et la négociation de type de contenu (format de données, langue).



    Les méthodes proposées par HTTP

    Dans le protocole HTTP, une méthode est une commande spécifiant un type de requête, c'est-à-dire qu'elle demande au serveur d'effectuer une action. En général l'action concerne une ressource identifiée par l'URL qui suit le nom de la méthode. 

    Dans l'exemple ci-dessous, une requête GET est envoyée pour récupérer la page d'accueil du site web www.test.com. Cela peut-être envoyé par exemple par un navigateur web lorsque l'utilisateur clic sur un lien.

    GET / HTTP/1.1
    Host: www.test.com


    Méthode très utilisées

    GET : c'est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet. 

    La méthode GET permet tout simplement d'appeler une page web, c'est la méthode utilisée par défaut par le navigateur web. En revanche, on peux passer des paramètres à une URL, ce qui va permettre de "personnaliser" une requête sur une page.

    Exemples de GET :

    http://news.com/   -> Affiche la page d'accueil
    http://news.com/articles.php   -> Affiche les derniers articles
    http://news.com/article.php?id=58 -> Affiche l'article ayant l'id 58 (envoi du paramètre id dans l'url)



    POST : cette méthode est utilisée pour transmettre des données en vue d'un traitement à une ressource. Le plus souvent depuis un formulaire HTML, mais maintenant aussi via des API. 

    L'URI fourni est l'URI d'une ressource à laquelle s'appliqueront les données envoyées. Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP (pour Ajax) par certains navigateurs (et la norme HTML qui ne supporte que les méthodes GET et POST pour les formulaires), cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée pour la mise à jour de ressources.


    Méthode plus spécifiques (notamment pour l'utilisation des API)

    PUT : cette méthode permet de remplacer ou d'ajouter une ressource sur le serveur. L'URI fourni est celui de la ressource en question.

    PATCH : cette méthode permet, contrairement à PUT, de faire une modification partielle d'une ressource.

    DELETE : cette méthode permet de supprimer une ressource du serveur.


    Méthodes moins répandues

    HEAD : cette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même.

    OPTIONS : Cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général.

    CONNECT : Cette méthode permet d'utiliser un proxy comme un tunnel de communication.

    TRACE : Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion.



    Code de statut de réponse


    Voici un exemple de trois code de statut HTTP, l'un étant carrément entré dans la culture populaire. Ces codes reflètent le statut du traitement d'une requête par le serveur. Ils servent à avoir une idée précise de "l'état" du serveur concernant une réponse à une requête.

    200 : ok tout va bien (super !)
    404 : ressource non trouvées (bug)
    301 : redirection permanente vers une autre ressource (très utilisé en SEO)

    Voir la liste des codes de statut HTTP : https://fr.wikipedia.org/wiki/Liste_des_codes_HTTP


    Entêtes (headers)

    Les entêtes sont des méta-données incluses dans les requêtes et les réponses du protocole HTTP. Elles servent à envoyer des informations qui ne sont pas vraiment "utiles" à l'utilisateur, mais qui sont très importantes pour un bon fonctionnement. On va y stocker, par exemple, les éléments permettant d'optimiser la gestion du cache, le type de fichier contenu dans la réponse (html, jpg, pdf,...), etc...


    Headers HTTP

    Schéma

    Visualisation dans un navigateur web



    Host : Permet de préciser le site web concerné par la requête, ce qui est nécessaire pour un serveur hébergeant plusieurs sites à la même adresse IP (name based virtual host, hôte virtuel basé sur le nom). C'est le seul en-tête réellement important.

    Referer : Indique l'URI du document qui a donné un lien sur la ressource demandée. Cet en-tête permet aux webmasters d'observer d'où viennent les visiteurs.

    User-Agent : Indique le logiciel utilisé pour se connecter. Il s'agit généralement d'un navigateur web ou d'un robot d'indexation.

    Code de statut : voir liste des codes statut

    Date : Moment auquel le message est généré.

    Server : Indique quel modèle de serveur HTTP répond à la requête.

    Content-Type : Indique le type MIME de la ressource.

    Content-Length : Indique la taille en octets de la ressource.

    Expires : Indique le moment après lequel la ressource devrait être considérée obsolète ; permet aux navigateurs Web de déterminer jusqu'à quand garder la ressource en mémoire cache.

    Last-Modified : Indique la date de dernière modification de la ressource demandée.


    Liaison

    La liaison entre le client et le serveur n'est pas toujours directe, il peut exister des machines intermédiaires servant de relais :

    • Un proxy (ou serveur mandataire) peut modifier les réponses et requêtes qu'il reçoit et peut gérer un cache des ressources demandées.
    • Une passerelle (ou gateway) est un intermédiaire modifiant le protocole utilisé.
    • Un tunnel transmet les requêtes et les réponses sans aucune modification, ni mise en cache.


    Identification

    HTTP permet l'identification du visiteur par transmission d'un nom et d'un mot de passe. Il existe 2 modes d'identification : Basic et Digest (RFC 26176). Le premier mode transmet le mot de passe en clair, et ne doit donc être utilisé qu'avec le protocole HTTPS. Le deuxième mode permet une identification sans transmettre le mot de passe en clair. L'identification est cependant souvent effectuée par une couche applicative supérieure à HTTP.


    Évolutions

    Les soucis majeurs des deux premières versions du protocole HTTP sont d'une part le nombre important de connexions lors du chargement d'une page complexe (contenant beaucoup d'images ou d'animations) et d'autre part le temps d'ouverture d'une connexion entre client et serveur (l'établissement d'une connexion TCP prend un temps triple de la latence entre client et serveur). Des expérimentations de connexions persistantes ont cependant été effectuées avec HTTP 1.0 (notamment par l'emploi de l'en-tête Connection: Keep-Alive), mais cela n'a été définitivement mis au point qu'avec HTTP 1.1.

    Par défaut, HTTP 1.1 utilise des connexions persistantes, autrement dit la connexion n'est pas immédiatement fermée après une requête, mais reste disponible pour une nouvelle requête. On appelle souvent cette fonctionnalité keep-alive. Il est aussi permis à un client HTTP d'envoyer plusieurs requêtes sur la même connexion sans attendre les réponses. On appelle cette fonctionnalité pipelining. La persistance des connexions permet d'accélérer le chargement de pages contenant plusieurs ressources, tout en diminuant la charge du réseau.


    Liste de serveurs HTTP

    • C : Apache, Zeus Web Server, nginx, lighttpd, Cherokee, Hiawatha Webserver
    • Javascript : Node.js
    • ASP/ASP.Net(C#, VB.net) : IIS
    • Java : Tomcat, Jetty, GlassFish, JBoss, JOnAS, Vert.x
    • Python : Zope
    • Pike : Caudium
    • Ruby : WEBrick, Mongrel, Thin
    • Erlang : Yaws
    • Autres : (en) Comparison of web servers

  • HTTPS


    Le HTTPS est un protocole qui encapsule le protocole HTTP avec une couche de sécurité en plus. HTTP n'est pas crypté. Ce qui veux dire que si on arrive à intercepter les échanges entre client et serveur (trames IP), on peux retrouver les données échangées en "clair". 

    Telles que :

    • nom d'utilisateur et adresse e-mail
    • mots de passe
    • données bancaires
    • données personnelles "critiques" (vie privée, données médicales, etc...)
    • etc...


    Pour pallier à ce manque de sécurité intrinsèque à HTTP, les grands acteurs du web ont mis au point une norme permettant de crypter les données qui transitent entre un client et un serveur. C'est ce qu'on appel le HTTPS. Le HTTPS permet d'authentifier le serveur avec lequel on communique, de crypter les échanges, et de vérifier l'intégrité des données.


    Les autorités

    Afin de mettre en place HTTPS sur votre serveur, il vous suffit de demander un certificat à une entité qui fournit des certificats SSL ou TLS. Il y a des entités plus ou moins "sérieuses" et reconnues, telles que Let's Encrypt, ou Digicert. Let's Encrypt fourni des certificats gratuits, mais avec une faible "autorité", tandis que Digicert les vends, et est plus "officiel".

    Les prix d'un certificat peuvent être très variables : https://www.httpcs.com/fr/certificats-ssl, mais il faut compter en général quelques dizaines d'euros par an au minimum pour avoir un certificat reconnu.


    Protocoles

    Pour fonctionner, le HTTPS se base sur deux protocoles qui font la même chose mais qui ont quelques différences : le SSL et le TLS. Aujourd'hui, il me semble que le TLS est a prioriser.


    Port

    Contrairement au HTTP, le port par défaut du HTTPS est le 443. Donc toute votre configuration sur des domaines en HTTPS devra écouter le port 443, et non le 80 (VirtualHost, etc...).


    Chiffrage

    Pour crypter les données, les protocoles SSL et TLS utilisent des algorithmes de cryptage très poussés, et régulièrement mis à jour, afin d'éviter que les clés soient cassées trop facilement par des hackers.


    Hanshake

    Quand un client se connecte à un serveur sécurisé, il y a plusieurs aller retours entre client et serveur avant d'envoyer la charge utile. C'est ce qu'on appel le handshake :




    Installer un certificat

    L'installation d’HTTPS sur un serveur est relativement simple, et vous trouverez beaucoup de documentation selon votre serveur web

    Mise en place du certificat :

    • achat d’un certificat SSL auprès d’une autorité de certification (si l’on souhaite que le certificat soit utilisable sur Internet et reconnu comme valide)
    • installation du certificat SSL sur le serveur web (fichiers à copier)
    • configuration du serveur web

    Configuration du serveur web :

    • binding adresse IP-port / domaine du certificat
    • définition des protocoles autorisés (TLS/SSL)
    • choix des algorithmes et niveaux de chiffrement acceptés


    Renouveler un certificat

    Pour des raisons de sécurité, un certificat a une durée de validité limité. Il faudra donc penser à renouveler son certificat régulièrement. Certains ont des durées de vie assez courtes (3 mois), tandis que d'autres durent un an. Vous pouvez soit faire la manipulation manuellement quand votre certificat arrive a expiration, soit utiliser des logiciels conçus pour faire des renouvellements automatiques si vous utilisez des services tel que Let's Encrypt.


    HTTPS et Google

    Depuis quelques temps, Google prends en compte la sécurisation d'un site dans l'indexation des résultats de recherche, et dans le positionnement d'un site dans la SERP. C'est à dire que si votre site n'est pas sécurisé, vous prenez le risque d'être pénalisé dans votre SEO. Comme dans toutes les problématiques SEO, ceci n'est pas réellement tranché, mais Google incite fortement les webmasters à passer leurs sites en HTTPS. Une autre lecture serait de penser que Google détiens des intérêts financiers dans les entreprises qui fournissent des certificats, et qu'ils utilisent leur force de frappe énorme pour vendre encore plus de certificats. Et quand Google dit quelque chose, les gens suivent généralement.... :) Money, money, money,....


    Pour conclure, le HTTPS est quasiment obligatoire pour un site professionnel. Cela rassure les internautes, et offre une réelle sécurisation des données critiques (paiement, etc...). En revanche, cela peux avoir un coût plus ou moins élevé, et demander du temps de mise en place et de maintenance supplémentaire.


    Articles plus détaillés sur le sujet :

  • FTP

    FTP, pour File Transfer Protocol, est un protocole spécialisé dans l'échange de fichiers entre machines. Il est assez utilisé en développement web, mais cela dépendra du type de projet, et de l'environnement de développement. C'est un outils que tout développeur web doit connaitre et maîtriser, car il est facile à utiliser, et permet d'envoyer ou de récupérer facilement des fichiers vers ou depuis le serveur.

    Même si on peut théoriquement l'utiliser en CLI, on utilises souvent des GUI tel que l’indétrônable Filezilla.


    Pour faire du FTP, il faut déjà que votre serveur comporte un serveur FTP. Il est installé par défaut dans tous les hébergement mutualisés ou dans les packages d'administration de serveur web (virtuamin, cPanel, etc...).

    Une fois que votre serveur est correctement configuré, il vous suffit de récupérer trois données essentielles (pour une connexion classique) :

    • le nom de l'hôte (ex : ftp.monsite.com)
    • l'utilisateur avec le quel on souhaite se connecter (root, autre user, user créé spécifiquement pour le FTP, etc...)
    • le mot de passe de cet utilisateur




    Il vous suffira alors de créer un nouveau profil dans votre client préféré, puis de lancer une connexion vers l'hôte préalablement configuré. Dans certains cas, il vous faudra aussi spécifié vers quel répertoire pointe la connexion (un peu comme lorsque l'on configure un VirtualHost). Et cela peux vous éviter d'avoir à naviguer dans l'arborescence jusqu'au bon dossier lors de chaque connexion.

    Une fois connecté au serveur FTP, et à votre dossier distant, vous n'aurez plus qu'a envoyer ou télécharger des fichiers entre votre client et votre serveur. Voici un screenshot de l'interface de Filezilla :



    Attention : FTP est souvent couplé au protocole SSH afin d'améliorer la sécurité des échanges d'informations. On obtiens alors des protocoles légèrement différents, du type SFTP. Cela ne change pas grand chose pour vous (hormis la sécurité dans les échanges), mais le port du protocole n'est pas le même :

    • FTP : port 21
    • SFTP : port 22


    Certains hébergeurs force le FTP en SFTP, donc ne vous étonnez pas si votre connexion échoue sur du FTP standard, et testez la connexion SFTP sur le port 22 de votre hôte, tout devrai rentrer dans l'ordre... :)

  • SMTP / POP (e-mail)

  • TCP/IP et UDP

  • SSH