Différence entre socket et websocket

Bonjour,

Je viens de découvrir les websocket avec une API java. Je ne comprend pas la différence entre les sockets et les websockets. En effet, cela me parait très similaire pour le principe (connexion bidirectionnelle...).

Quelle est la différence et quand vaut-il mieux utiliser les sockets ou les websockets?

Bonjour,

Les websockets sont une surcouche du socket adapté au web, d'ailleurs c'est assez récent (c'est sorti avec HTML5).
Tu te sers des websockets lorsque tu veux établir une communication bidirectionnelle avec ton client web (je précise bien "web", donc ton client est un utilisateur avec un navigateur).
Généralement tu n'utilises pas directement les sockets (c'est assez bas niveau), tu te sers des API à ta disposition (rest, soap, rmi, corba, grpc etc), sauf si bien sur tu crées ta propre API.

Cordialement,

Merci pour ton retour. Pour m'entrainer sur la sécurisation des échanges, j'avais fais une messagerie instantannée où les échanges sont chiffrés. J'avais utilisé les sockets avec du ssl. Cependant, je devais paramétrer le routeur pour rediriger le traffic vers la bonne ip locale et le bon port et je devais paramétrer le pare feu pour ouvrir les ports. Bref, cela serait assez complexe pour des utilisateurs. On m'a alors évoqué les websockets qui utilisent un niveau plus élevé. On m'a dit que ca permettait d'éviter d'avoir par exemple à configurer le pare feu mais après avoir cherché sur internet, je ne comprend pas pourquoi. Pouvez-vous m'expliquer svp?
De plus, par rapport à ce que tu dis j'ai aussi vu des exemples où le client et le serveur étaient en java et il n'y avait pas nécessairement passage par un navigateur. Je ne comprend donc pas quand il est préférable d'utiliser les websockets par rapport aux sockets.

Tu es sur le forum Développement Web en Java, je pensais donc que tu allais utiliser du websocket dans une application Java EE (raison pour laquelle je te parle d'un navigateur pour le client).
Si je comprends bien, tu souhaites créer un tchat dans un client lourd, et pense utiliser les websockets parce que ça pourrait mieux passer à travers le réseaux que de simples socket je me trompe ?
Je ne sais pas pourquoi on t'as conseillé les websockets, tu peux rencontrer différents types de problèmes pour ce qui est de ton blocage, notamment à cause des routeurs et firewalls qui bloquent les ports que tu utilises, un avantage avec les websockets c'est qu'ils utilisent les ports 80 (HTTP) ou 443 (HTTPS) qui sont par défaut ouvert.

J'ai posté sur ce forum car les échanges passent par internet et dans websocket il y a "web" donc ce forum me semblait plus approprié.

Le but de ma messagerie est effectivement qu'un utilisateur lance un session (avec un socket serveur) et attend que le client en face rejoigne la session (socket client). Je voulais m'auto former sur la sécurisation des échanges. J'ai donc mis en place des sockets avec ssl. Cependant, cela était embêtant car il fallait à la fois que je configure le routeur et le pare-feu qui avec les sockets ne semble pas ouvrir de port tout seul.
Un collègue m'a alors parlé des websockets qui se trouve à un niveau plus élevé (il m'a dit au niveau de HTTP). Le fait que ca soit à un niveau plus élevé permettrait d'éviter le problème du pare-feu car java demanderait l'ouverture du port au lancement du serveur avec les websockets. Il y aurait alors juste le routeur à configurer pour que les requêtes distantes arrivent à bon port. C'est bien ca?

La différence entre socket et websocket se trouve juste au niveau du protocole utilisé?

J'ai cherché sur internet mais n'ai pas trouvé d'explication simple et clair sur la différence.

Les websockets peuvent utiliser le port 443 ouvert par défaut pour les échanges SSL? Ce port ne risque pas d'être utilisé par d'autres applis sur un PC?

Merci d'avance pour les réponses.

Le fait qu'un protocole soit à un niveau plus élevé que celui utilisé par une socket de base ne signifie pas que tu ne vas pas avoir de problème lié au pare-feu. Rien ne t'empêche d'utiliser les websockets dans ton client lourd, sauf que les websockets ont spécialement étés créés pour que les navigateurs puissent établir une communication bidirectionnelle avec un serveur, chose qui n'existait pas avant (avant tu avais d'autres techniques comme le polling pour créer un tchat). Les websockets ça marche d'accord mais ce n'est pas "magique", les navigateurs qui les implémentent ont les autorisations nécessaires (lorsque tu acceptes d'installer le soft) que ton client Java n'a pas forcément au démarrage de ton application. Enfin tu peux toujours essayer de régler les problèmes des droits au niveau de ton OS.

Pour ce qui est des conflits de port je pense que tu n'as pas à t'inquiéter, tu as pu remarquer que si tu as plusieurs navigateurs ouverts, et que tu envoies des requêtes en mode HTTP (80) ou HTTPS (443) en même temps, tu n'as pas de conflit, ce sont les hôtes que tu contactes qui utilisent ces ports, ce sont donc ces hôtes qui ne doivent pas avoir plus d'une application écoutant le même port avec le même protocole de couche 4.

Pour ce qui est de la configuration des routeurs, tout dépend de ton architecture (n'hésite pas à montrer ton schéma).

PS: Tu as fait une ISIAD ? :)

Ok merci pour ton retour. J'essayerais pour tester d'adapter ma messagerie utilisant les sockets pour utiliser les websockets et je verrais si j'aurais les mêmes problématiques. J'utiliserais le port 443 pour les échanges HTTPS (avec ssl ou plutot tls maintenant) et je verrais comment ce se comporte.

Pour la formation j'ai seulement fait un master miage en alternance (je n'avais jamais entendu parlé de la spécialité ISIAD qui ne devait pas encore exister) :).

Bonjour,

il y a de nos jours des solutions plus simples que les websockets. Les services de type publish-subscribe comme emitter.io.
Ils ont des démos très simples de chat, de paint multi-utilisateurs etc. https://emitter.io/develop/html5-chat