J'ai utilisé un peu d'Ajax avec PHP pour des choses comme des formulaires de soumission et j'ai récemment commencé à regarder dans Webockets. J'ai suivi ce tutoriel pour comprendre les bases . D'après ce que je rassemble, les webockets gardent la connexion ouverte alors qu'Ajax s'ouvre et ferme une demande.
Ma question est que les websockets fournissent tout avantage sur Ajax si vous ne soumettez que des formulaires ou des tâches simples telles que Auto_Complete (qu'il existe un plugin JQUERY pour toute façon)? Peut-être que le didacticiel n'est pas le plus grand, mais il semble qu'il y ait un diable de beaucoup plus de code impliqué pour obtenir des websockets pour travailler (au moins avec PHP) qu'un simple appel AJAX (ou en utilisant JQuery qui le regroupe). J'ai lu dans quelques endroits qu'il est un peu plus rapide, mais si je travaille sur quelque chose qui ne reçoit pas de tonnes de demandes, cela fera-t-il vraiment une différence? Corrigez-moi si je me trompe, mais tous les navigateurs ne supportent pas les webockets non plus, non?
3 Réponses :
Websockets a deux avantages.
Ils ont beaucoup moins de frais généraux, ce qui entraîne une meilleure performance réseau
Ils permettent au serveur d'envoyer des données que le client n'a pas demandé explicitement.
Le second est l'avantage le plus important.
dans Ajax, tout ce que le serveur envoie doit être la réponse à une demande précédente du client et chaque demande ne peut être répondu qu'une seule fois. Mais dans de nombreuses applications, en particulier les applications multi-utilisateurs, les événements se produisent sur le serveur et ces événements doivent être poussés immédiatement aux clients. Il existe des solutions de contournement pour cela dans Ajax, comme retarder la réponse à une demande jusqu'à ce qu'il y ait quelque chose à signaler (interrogation long), mais ceux-ci sont assez sales. C'est pourquoi il y a des webockets. Avec une connexion WebSocket, le serveur peut envoyer des messages aux clients lorsqu'il souhaite et aussi souvent qu'il le souhaite, sans avoir à attendre une demande du client.
mais malheureusement, des schosques ont également des inconvénients:
L'icône "Stack Exchange" en haut de cette page utilise-t-elle des webockets (lorsqu'un nouveau message est reçu)? Je vois les avantages pour quelque chose comme ça, mais si vous soumettez simplement des formes, cela ne semble pas être une énorme différence. Le code sage Webockets semble être plus lourd. Est-ce juste l'exemple que j'ai énuméré qui semble être de cette façon? Avec 3-4 lignes de jQuery, je peux poster des informations avec Ajax. J'aime l'idée de webockets, je vais certainement regarder en plus loin.
Pour une simple soumission de formulaire, je préférerais suggérer d'utiliser Ajax, car dans ce cas, le serveur ne sera que réagir aux actions du client, pas acte .
Websockets est une technologie puissante et pourrait certainement répondre aux cas d'utilisation limitée que vous avez mentionné, mais il peut y avoir des problèmes de compatibilité avec les navigateurs et les intermédiaires de réseau plus anciens. En fait, certaines personnes recommandent même d'avoir un repliement HTTP dans le cas de WebSockets ne sont pas pris en charge.
sauf si vous avez des exigences qui nécessitent des webockets, telles que les communications bidirectionnelles complètes en duplex, par exemple, vous risquez d'être préférable d'utiliser des solutions basées sur AJAX existantes.
Si vous avez des exigences pour appuyer sur les notifications à votre interface utilisateur, les webockets peuvent être une bonne idée, mais si vous recherchez littéralement la soumission de formulaire et la totalité automatique, ces problèmes ont déjà été résolus à l'aide de Ajax.
Grâce à la plupart des navigateurs de bureau, la mise à jour automatiquement de nos jours, un repliement AJAX devient progressivement moins pertinent. Les seules platformances problématiques qui sont toujours là sont 1. IE9 (ce qui est particulièrement problématique, car IE10 n'est pas disponible pour les utilisateurs Windows XP et Vista) et 2. Tous les appareils Android (qui sont notoirement à jour - hostiles).
En réalité, Ajax et WebSockets sont deux catégories différentes. Ajax est un concept, une technique. Avec Ajax, vous pouvez effectuer (comme l'acronyme signifie) des demandes asynchrones, le navigateur n'a donc pas besoin de recharger / rafraîchir la page entière. C'est bon pour différentes choses, par exemple Vérification de la saisie de formulaire. Websockets sont un protocole, techniquement tout à fait identique que HTTP, à moins que la connexion ne soit pas fermée après la transition. Ceci est bon pour les choses, où le serveur Web devra peut-être contacter le client (HTTP ne peut pas le faire), comme un exemple de service de poussée (client de chat ou de messagerie où vous souhaitez mettre à jour l'interface utilisateur même lorsque l'utilisateur n'est pas actualisé la page ou les jeux). Et il tue la surcharge HTTP comme tout ce qui est à faire une fois au début.
Alors, leur à des fins différentes, même s'ils se chevauchent. Pour votre achèvement automatique, je pense que cela ne fera pas une réelle différence de performance. Et il est même une chose d'action / réaction, donc les types d'utilisateurs ou soumet (peu importe) ce qui peut provoquer une demande et le serveur répond.
Je pense que l'article lui-même résume bien:
Webockets peut remplacer le sondage long ...Disons que vous voulez vérifier automatiquement s'il existe un nouveau commentaire pour l'ajouter automatiquement au bas d'un article; Un interrogation longue signifie que vous vérifieriez toutes les xx secondes s'il y a quelque chose de nouveau, les commentaires Web-sockets Web peuvent venir automatiquement au fur et à mesure de leur affectation.
@Jeen merci, cela a du sens. Je peux comprendre pour quelque chose comme la vérification des messages ou des mises à jour, mais si vous venez de soumettre des formulaires, cela ne semble pas faire la différence. A-t-il besoin de plus de code pour être configuré ou est-ce que cet exemple vient de clunky?
Le côté client est assez simple, le problème est que vous devez configurer un serveur et fournir les mêmes solutions AJAX qu'auparavant pour les navigateurs qui ne prennent pas en charge les webockets.
Donc, vous dites si un navigateur ne prend pas en charge Webockets, vous devez configurer votre serveur pour pouvoir fournir lesdites informations de navigateur? ... Cela signifie essentiellement qu'il est possible, juste un travail supplémentaire?