Différence entre socket et websocket?

Je construis une application Web qui doit communiquer avec une autre application à l'aide de connexions socket. C'est un nouveau territoire pour moi, alors je veux être sûr que les sockets sont différents des websockets . Il semble qu'ils ne soient similaires que sur le plan conceptuel.

Demander parce qu'au départ j'avais prévu d'utiliser Django comme base de mon projet, mais dans le message SO que j'ai lié ci-dessus, il est très clair que les websockets ne sont pas possibles (ou du moins pas fiables, même avec quelque chose comme django-websockets ) en utilisant la configuration Django préférée (Apache avec mod_wsgi). Pourtant, j'ai trouvé d'autres articles qui importent avec désinvolture le module socket de Python pour quelque chose d'aussi simple que de saisir le nom d'hôte du serveur .

Alors:

• Sont-ils vraiment différents?
• Y a-t-il une raison de ne pas utiliser Django pour un projet qui repose sur l'établissement de connexions socket avec un serveur extérieur?

Pour répondre à tes questions.

1. Même s'ils réalisent (en général) des choses similaires, oui , ils sont vraiment différents. Les WebSockets s'exécutent généralement à partir de navigateurs se connectant à Application Server via un protocole similaire à HTTP qui s'exécute sur TCP / IP . Ils sont donc principalement destinés aux applications Web qui nécessitent une connexion permanente à son serveur. D'un autre côté, les sockets simples sont plus puissants et génériques. Ils fonctionnent sur TCP / IP mais ils ne sont pas limités aux navigateurs ou au protocole HTTP . Ils pourraient être utilisés pour mettre en œuvre tout type de communication.
2. Non, il n'y a aucune raison.

Les Websockets utilisent des sockets dans leur implémentation. Les Websockets sont basés sur un protocole standard (maintenant en appel final, mais pas encore final) qui définit une connexion "handshake" et un message "frame". Les deux côtés passent par la procédure de prise de contact pour accepter mutuellement une connexion, puis utilisent le format de message standard («cadre») pour faire passer les messages dans les deux sens.

Je développe un framework qui vous permettra de communiquer directement de machine à machine avec le logiciel installé. Cela pourrait convenir à votre objectif. Vous pouvez suivre mon blog si vous le souhaitez: http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html

Vous devrez utiliser WebSockets (ou un module de protocole similaire, par exemple, pris en charge par le plugin Flash) car une application de navigateur normale ne peut tout simplement pas ouvrir une socket TCP pure.

Le Socket.IOmodule disponible pour node.jspeut aider beaucoup, mais notez qu'il ne s'agit pas d' un module WebSocket à part entière.

Il s'agit en fait d'un module de communication plus générique qui peut fonctionner sur divers autres protocoles réseau, y compris les WebSockets et les sockets Flash.

Par conséquent, si vous souhaitez utiliser Socket.IOsur le serveur, vous devez également utiliser leur code client et leurs objets. Vous ne pouvez pas facilement établir des WebSocketconnexions brutes à un socket.ioserveur car vous devrez émuler leur protocole de message.

WebSocket n'est qu'un autre protocole de niveau application sur protocole TCP, tout comme HTTP.

Quelques extraits de <Spring in Action 4> cités ci-dessous, espérons que cela vous aidera à mieux comprendre WebSocket.

Dans sa forme la plus simple, un WebSocket est juste un canal de communication entre deux applications (pas nécessairement un navigateur est impliqué) ... La communication WebSocket peut être utilisée entre tous les types d'applications , mais l'utilisation la plus courante de WebSocket est de faciliter la communication entre un une application serveur et une application basée sur un navigateur.

Concernant votre question (b), sachez que la spécification Websocket n'a pas été finalisée. Selon le W3C :

Les développeurs doivent être conscients que cette spécification n'est pas stable.

Personnellement, je considère Websockets comme étant trop avant-gardiste pour être utilisé actuellement. Bien que je les trouverai probablement utiles dans un an environ.