Bonjour, je me forme sur le sujet tcp et udp socket.Donc peut-être que quelque chose m'échappe.
A vrai dire j'aimerais juste comprendre pourquoi utiliser une redirection 80 vers 443 alors que quand je créer mon serveur node http2 en écoute seulement sur le port 443, tout fonctionne comme prévu et seulement le port 443 dessert les ressources. J'ai regarder le pourquoi du comment au niveau de l'IANA et des attributions de ces port et leur dates de créations.Jusque la pas de souci, mais au jour d’aujourd’hui ou le https est imposer est t'il vraiment viable d'utiliser encore le port 80 dans le serveur de développement.
J'ai l'impression que ma question est idiote mais bon je ne trouve pas de réponse sur internet par rapport a cela. Que ce soit en local ou sur mon vps héberger, le site est directement pris en charge et c'est bien https qui est desservit directement. Merci pour les éclaircissements.
Déjà, il faut bien faire la différence entre HTTP et HTTPS (HTTP chiffré avec TLS). HTTP2 est une version de HTTP.
L'IANA a «attribuer» des ports à certaines applications. Disons que c'est plus une recommandation. Dans cette recommandation HTTP écoute sur le port 80 et HTTPS sur le port 443. C'est les ports standards pour ces deux protocoles.
Rien n'empêche de faire écouter ton serveur web (HTTP ou HTTPS) sur d'autres ports. Par exemple 8000, 8080, 8443, 9000 et 9443 sont des ports alternatifs pour le web qu'on retrouve souvent. Et ce n'est pas parce que ton serveur écoute sur le port 443 qu'il fait du HTTPS (il n'y a pas de relation de cause à effet entre les deux).
Selon la nature de ton serveur de développement, et ton environnement de développement, il n'est pas toujours nécessaire qu'il soit en écoute en HTTPS. Cela peut même nuire au développement en rendant le debug plus difficile notamment. Mis-à-part besoin spécifique, il n'y a aucune raison de faire écouter ton serveur de développement sur deux ports.
Aujourd'hui on préfère répartir les responsabilités sur plusieurs solutions. Ton serveur web en tant que tel (celui qui reçoit les requêtes HTTP et qui envoie les réponses) sera ton application (nodejs, python, Java, peu importe...). TLS sera géré par une autre solution qui se place entre ton application et internet. On appelle souvent cette solution un reverse proxy ou proxy SSL (SSL est l'ancienne version de TLS).
Ton proxy s'occupe de l'établissement de la communication chiffré avec le client et déchiffre le trafic que le client envoi. Ce trafic déchiffré est ensuite «passé» à ton application qui reçoit la requête et renvoi la réponse au proxy. Le proxy chiffre la réponse et «passe» cette réponse chiffrée au client.
Il y a une autre raison de faire comme ça: amélioré la sécurité de ton application.
En fait, ces ports que l'IANA recommande d'utiliser sont prit très au sérieux par la communauté. Les ports en dessous de 2048 sont souvent considérés comme «réservés» et ne devrait être utilisé que par les applications définis pour. À ce titre, les systèmes restreignent l'utilisation de ces ports par des programmes. Un programme pour écouter sur ces ports doit avoir des privilèges élevés. Hors la plupart des applications web n'ont pas besoin de ces privilèges. Si un attaquant utiliserai une faille dans l'application, il aurait alors potentiellement ces mêmes privilèges élevés sur le système. Alors que si ton application écoute sur un port plus random comme 8000, et bien, moins de privilèges, et l'attaquant sera plus restreint.
Donc idéalement, que tu utilises HTTPS ou non en développement, tu n'as pas besoin d'écouter sur le port 443.
Et en production, l'utilisation du port 80 qui fait juste une redirection vers 443 n'est pas une obligation (tout dépend si tu veux t'assurer de couvrir plus de cas possibles de connexion à ton serveur ou non). C'est à ton appréciation!
En espérant que c'est pas trop bordélique comme explication et que ça réponde au moins partiellement à ton questionnement
Oui c'est très clair, merci pour cette réponse détailler.Désolé de cette réponse tardive mais je ne pouvais pas me connecter sur openclassroom.
Apparemment le problème est résolu.Ok je m'intéresse ou signaux de terminaison applicatifs et serveur au niveau de node.
Et après le reverse proxy est une solution que j'avais vu et qui est intéressante, notamment le fait également d'établir un équilibreur de charge.
D'accord je cherche a établir une fondation solide de mon programme avant de lancer le développement de celle-ci.Je m'aperçois que le réseaux est tous un monde.Même si en tant que programmeur nous connaissons les bases.Mais quand on rentre en détails dans celui-ci, il y'a plein de choses importante a connaitre si nous voulons pas que certain détails ignorer plante le programme après x temps de récursivité.
Donc établir une connexion stable et chiffrée de protocole avec reverse proxy et équilibreur de charge + gestion erreurs applicatif et serveur + gestion des sockets tcp.
Après je pourrait développer tranquillement et enfin utiliser pm2 afin de pouvoir suivre efficacement le déploiement de l'application sur mon vps.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
C'est du Grand Mendez
C'est du Grand Mendez